Serveur dédié : ajouter l'authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim photo 1

Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim

dkim-spf-200

Cela fait quelques années maintenant que mon serveur tourne et je trouvais le serveur de mail (postfix) bien fonctionnel plutôt bien jusqu’à ce que je reçoive des messages de la part de Gmail comme quoi les emails envoyés par le site sont considérés comme spam!

Et c’est à ce moment que l’on réalise qu’être bloqué par son fournisseur email, ce n’est pas cool du tout : à chaque fois qu’un nouveau commentaire est publié et que quelqu’un y est abonné, l’erreur se déclenche et le mail part en mail delivery service.

Voici le message type que l’on reçoit de Gmail dans ce cas:

Final-Recipient: rfc822; ***@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit
    https://support.google.com/mail/answer/81126 to review our Bulk Email Senders Guidelines. Code language: JavaScript (javascript)

Lorsque l’on monte un serveur email, rien n’est sécurisé par défaut. Avec tout le spam en circulation, il y a des entêtes à ajouter lors de l’envoi pour que le courrier ne soit pas considéré comme indésirable :

dkim-spf-schema

Il est donc temps de sécuriser un peu notre serveur de mail.

Étape 1 : diagnostics

Sur le serveur dans le terminal, on envoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Résultat:

==========================================================
Summary of Results
==========================================================
SPF check:          softfail
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    softfail
SpamAssassin check: ham

Du fail et du neutral, ce n’est pas trop bon! Nous allons commencer par activer SPF et Sender-ID.

Étape 2 : ajouter SPF et Sender-ID à BIND

Nous allons donc ajouter l’authentification SPF (Sender Policy Framework) à notre enregistrement DNS. On édite le fichier de configuration BIND de notre domaine :

nano /etc/bind/skyminds.net.hosts

Et on y ajoute à la fin du fichier :

;SPF
skyminds.net. IN TXT "v=spf1 ip4:IP4SERVEUR mx -all"
skyminds.net. IN SPF "v=spf1 ip4:IP4SERVEUR mx -all"
mail.skyminds.net. IN  TXT  "v=spf1 ip4:IP4SERVEUR a -all"
mail.skyminds.net. IN  SPF  "v=spf1 ip4:IP4SERVEUR a -all"Code language: JavaScript (javascript)

Remplacez IP4SERVEUR par l’IPv4 de votre serveur et skyminds.net par votre nom de domaine. Enregistrez le fichier et relancez BIND :

/etc/init.d/bind9 restart

On renvoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Nouveau résultat :

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

Pas mal, on vient d’activer le SPF et le Sender-ID en 2 minutes !

Étape 3 : installation de l’authentification DKIM

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique : DKIM fonctionne par signature cryptographique du corps du message et d’une partie de ses en-têtes.

Une signature DKIM vérifie donc l’authenticité du domaine expéditeur et garantit l’intégrité du message. Idéal pour lutter contre le spam.

1. On installe opendkim :

apt-get install opendkim opendkim-toolsCode language: JavaScript (javascript)

Et on édite le fichier de configuration:

nano /etc/opendkim.conf

On supprime tout le contenu de ce fichier et on met :

 # Enable Logging
Syslog yes
SyslogSuccess yes
LogWhy yes

# User mask
UMask 002

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From

# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

# Trusted Hosts
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

# Hashing Algorithm
SignatureAlgorithm rsa-sha256

# Auto restart when the failure occurs. CAUTION: This may cause a tight fork loops
AutoRestart Yes
DNSTimeout  5

# Set the user and group to opendkim user
UserID opendkim:opendkim

# Specify the working socket
Socket inet:12345@localhost

Canonicalization relaxed/relaxedCode language: PHP (php)

2. On édite la configuration par défaut d’opendkim:

nano /etc/default/opendkimCode language: JavaScript (javascript)

Avec :

# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
#
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
#SOCKET="local:/var/run/opendkim/opendkim.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:12345@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345Code language: PHP (php)

3. On crée un nouveau répertoire pour notre clé et on assigne les droits à l’utilisateur opendkim, du groupe opendkim:

mkdir -pv /etc/opendkim/skyminds.net/
chown -Rv opendkim:opendkim /etc/opendkim
chmod go-rwx /etc/opendkim/* 

Ensuite, on crée une paire de clés pour chaque domaine :

cd /etc/opendkim/skyminds.net/
opendkim-genkey -r -h rsa-sha256 -d skyminds.net -s mail -b 4096
mv -v mail.private mail
chown opendkim:opendkim *
chmod u=rw,go-rwx * Code language: PHP (php)

Cela nous crée 2 fichiers : un fichier mail (clé privée) et un fichier mail.txt qui contiendra notre clé publique.

4. On ajoute notre clé publique à l’enregistrement DNS du domaine dans BIND:

nano /etc/bind/skyminds.net.hosts

On y copie notre clé publique (/etc/opendkim/skyminds.net/mail.txt) à la fin du fichier :

;DKIM
_domainkey.skyminds.net. IN TXT "t=y; o=-;"
mail._domainkey.skyminds.net. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6YG5lJXmZxgz1eFprQfEV8oqUjYceMNPctuhi/Fo+oE+4oeDwMTDyPJcGCuJMp2XZxL2X3a8/Q9g3StekiHWqPehY7cyrnYZg6ttTCdbJYGAc/t0rVCKut/2baiGw9lcMq5sbUG9YywEEI/rN4Fu0PCU1A6BkqtNAepPhDwVRAQIDAQAB; t=s"; ----- DKIM key mail for skyminds.net
_adsp._domainkey.skyminds.net. IN TXT "dkim=unknown"Code language: JavaScript (javascript)

On enregistre le fichier et on relance BIND :

/etc/init.d/bind9 restart

5. On associe les domaines avec les clés :

nano  /etc/opendkim/KeyTable

La syntaxe du fichier est la suivante :
KeyID Domain:Selector:PathToPrivateKey

Nous ajoutons donc :

skyminds.net skyminds.net:mail:/etc/opendkim/skyminds.net/mailCode language: JavaScript (javascript)

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.netCode language: CSS (css)

7. On définit les domaines considérés comme trusted :

nano /etc/opendkim/TrustedHosts

Avec :

127.0.0.1
localhost
ns.kimsufi.com
skyminds.netCode language: CSS (css)

Il ne faut pas oublier d’ajouter le DNS de votre hébergeur (ns.kimsufi.com chez moi).

8. On applique maintenant les bons droits à nos fichiers :

chown opendkim:opendkim /etc/opendkim/KeyTable
chown opendkim:opendkim /etc/opendkim/SigningTable
chown opendkim:opendkim /etc/opendkim/TrustedHosts 

9. On édite maintenant la configuration Postfix :

nano /etc/postfix/main.cf

Et on rajoute :

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = $smtpd_miltersCode language: PHP (php)

On redémarre bind, opendkim et postfix pour vérifier que tout va bien :

/etc/init.d/bind9 restart
/etc/init.d/opendkim restart
/etc/init.d/postfix restart

10. On vérifie qu’opendkim est bien lancé sur le serveur :

ps aux | grep dkim
netstat -tanp | grep dkim 

Étape 4 : tests et vérifications

Il faut maintenant attendre que la propagation DNS prenne effet, cela peut prendre quelques heures.

Vous pouvez lancer un test DKIM ici : http://www.brandonchecketts.com/emailtest.php

Vérifiez les erreurs mail dans les logs :

tail -f /var/log/mail.logCode language: JavaScript (javascript)

Envoyez-vous un email via le terminal. Voici ce que vous devriez obtenir :

dkim-spf-signed

Étape 5 : optimiser la vitesse d’envoi

Quelques jours après la réalisation et la mise en place du tutoriel, je me suis aperçu que Gmail grognait toujours à cause de la vitesse à laquelle étaient envoyés les emails, notamment lorsque beaucoup de gens sont abonnés aux commentaires : en cas de nouveau commentaire, une flopée de notifications partent au même moment – ce qui déclenche le message d’erreur chez Gmail.

Pour améliorer cela, on édite à nouveau le fichier de configuration postfix :

nano /etc/postfix/main.cf

Et on y rajoute :

# Matt : NOT TOO FAST COWBOY!
# This means that postfix will up to two concurrent
# connections per receiving domains. The default value is 20.
default_destination_concurrency_limit = 2
# Postfix will add a delay between each message to the same receiving domain.
default_destination_rate_delay = 5s
# Limit the number of recipients of each message.
# If a message had 20 recipients on the same domain, postfix will break it out
default_extra_recipient_limit = 3Code language: PHP (php)

Cela se connecte au maximum avec 2 connexions par domaine, avec un délai de 5 secondes entre chaque message s’ils sont envoyés au même domaine et on envoie par tranche de 3 messages. Un peu alambiqué mais cela semble satisfaire Google.

Voilà, c’est fini. Les messages de votre serveur de mail devraient maintenant être un peu plus acceptés dans les boîtes de réception !

Serveur dédié : créer et activer un Virtual Host sous Apache photo

Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403

Le problème : l’adresse du site sans WWW renvoie une erreur

icon-apache2

Après avoir ajouté un sous-domaine pour mes images, j’ai remarqué qu’en lançant skyminds.net sans le www, je tombais sur une erreur 403 alors que le domaine avait toujours été redirigé vers l’adresse en www jusqu’à présent.

En analysant les logs Apache, je me suis rendu compte que le domaine seul tentait d’afficher le contenu de mon sous-domaine. Or ce contenu est caché étant donné qu’il ne contient que des images.

La solution : indiquer le nom de domaine seul dans ServerAlias

La solution est d’ajouter le nom de domaine seul dans la directive ServerAlias du VirtualHost principal :

ServerName www.skyminds.net
ServerAlias skyminds.netCode language: CSS (css)

Et voilà, tout revient à la normale.

Linux : résoudre l'erreur cron "line too long in state file /var/lib/logrotate/status" photo

Linux : résoudre l’erreur cron “line too long in state file /var/lib/logrotate/status”

Ce matin, j’ai reçu ce message d’erreur de mon serveur par email :

/etc/cron.daily/logrotate:
error: line 672139 too long in state file /var/lib/logrotate/status
error: could not read state file, will not attempt to write into it
run-parts: /etc/cron.daily/logrotate exited with return code 1Code language: JavaScript (javascript)
log-rotate

Sous les systèmes GNU/linux, logrotate est le service qui archive les fichiers log de manière à ne pas travailler sur des fichiers trop lourds.

Les fichiers sont donc archivés plus ou moins régulièrement, selon leur taille et leur utilisation : certains sont archivés tous les jours, d’autres toutes les semaines.

Or, si logrotate ne fonctionne pas correctement, la taille des fichiers explose, ce qui posera tôt ou tard un souci sur le serveur.

Lorsque logrotate n’arrive pas à lire ou à écrire dans le fichier /var/lib/logrotate/status, il faut :

1. supprimer le fichier /var/lib/logrotate/status :

rm -rf /var/lib/logrotate/statusCode language: JavaScript (javascript)

2. et relancer logrotate :

logrotate -f /etc/logrotate.conf

Le fichier /var/lib/logrotate/status ne sert finalement qu’à garder une trace de la dernière rotation des fichiers logs. Ce fichier ne devrait pas contenir énormément de lignes.

Ps : si vous utilisez Varnish, commentez les lignes le concernant dans /etc/logrotate.conf, il est peu utile d’encombrer le serveur avec les logs de ressources statiques.

disk-doctor

Linux : résoudre l’erreur de montage/démontage de disque dur “Error unmounting: umount exited with exit code 1: helper failed with: umount: only root can unmount”

Sur mon ordinateur, surnommé The Reaper, j’ai plusieurs disques dur : mon disque principal est un disque formaté en EXT4, entièrement dédié à Linux.

Les deux autres disques durs sont formatés en NTFS car ils datent du temps où j’avais Windows dessus.

Le problème : un disque en lecture seule

disk-doctor

L’autre jour, Cécile cherche à sauvegarder ses fichiers sur son disque externe, qui ne semble pas être détecté.

Je lui propose alors le mien et le branche sur ma machine pour voir s’il reste de la place dessus.

Je le monte et là je m’aperçois qu’il est en mode lecture seule (aka read-only ou r-o) : impossible de copier le moindre fichier dessus alors qu’avant c’était bien possible.

Après de multiples recherches, essais, installations de paquets divers et variés, la situation a un peu changé : mes 2 disques internes se montent maintenant automatiquement au démarrage du système (ce que je ne veux absolument pas).

Lorsque je veux les démonter, j’obtiens le fameux message d’erreur “Error unmounting: umount exited with exit code 1: helper failed with: umount: only root can unmount” qui me dit en substance que seul l’utilisateur root peut monter ou démonter le disque.

Bref, je tombe de Charybde en Scylla. Voici comment régler la situation une bonne fois pour toute, disques internes et externes à la fois.

1. On liste les disques du système avec :

df

2. On démonte les disques en question (sda chez moi) :

sudo umount /dev/sda1

3. On installe le paquet ntfs-config :

sudo apt-get install ntfs-configCode language: JavaScript (javascript)

4. On lance ntfs-config depuis Applications > Outils Système > Outil de configuration NTFS ou depuis le terminal avec :

gksudo ntfs-config

5. On active l’écriture des disques internes et externes :

ntfs-config

6. On édite le fichier de configuration /etc/fstab :

sudo nano /etc/fstab

et on retire les lignes qui correspondent aux disques durs dont on ne veut pas le montage automatique. Vous pouvez commenter les lignes pour plus de sécurité.

7. Voilà, vous devriez être en mesure d’accéder à vos disques durs normalement.

Conclusion

J’ai beaucoup joué avec les options avancées de ntfs-config mais je ne suis pas sûr d’en maîtriser toutes les subtilités.

J’ai retrouvé un accès complet à mes disques en montage/démontage/lecture/écriture en éditant le fichier /etc/fstab et en supprimant les lignes relatives aux disques incriminés. Et depuis tout va bien.

utorrent-logo

Retirer toutes les publicités du client uTorrent

utorrent-logo

Lors de notre petite réunion familiale annuelle, j’ai aidé ma soeur à mettre quelques unes de ses applications à jour.

Il se trouve que l’on a utilisé uTorrent sur sa machine Windows et j’ai été surpris de constater qu’il y avait maintenant une foule de publicités dans l’interface.

Cela fait bien longtemps que je n’avais pas utilisé ce logiciel, étant donné que j’utilise Transmission sur mes machines (linux).

Voici donc comment retirer les publicités d’uTorrent, en quelques clics et directement depuis les options du logiciel.

Etape 1 : ouvrez les préférences du logiciel

Ouvrez uTorrent puis allez dans le menu Options > Preferences > Advanced.

Etape 2 : modifiez les options relatives à l’affichage des publicités

Recherchez les options suivantes et modifiez leur valeur à “Non” (ou “false” si vous utilisez la version anglaise) :

  • gui.show_plus_upsell
  • gui.show_notorrents_node
  • offers.content_offer_autoexec
  • offers.featured_content_notifications_enabled
  • offers.featured_content_rss_enabled
  • offers.featured_content_rss_randomize
  • offers.left_rail_offer_enabled
  • offers.sponsored_torrent_offer_enabled

Cliquez sur OK pour valider les changements puis relancez uTorrent.

Toutes les publicités ont maintenant disparu.

Lire un CD ou DVD de DivX avec la Freebox Revolution photo

Lire un CD ou DVD de DivX avec la Freebox

J’ai tenté de lire un DVD contenant des DivX hier sur ma Freebox Revolution. J’insère le disque dans le lecteur bluray, appuie sur Lecture et me retrouve avec un message d’erreur :

Impossible de lire le DVD

Pas cool ! En cherchant un peu, j’ai trouvé la solution à ce problème.

Lire un CD ou DVD sur la Freebox Revolution

Mettez le disque dans la fente du lecteur.

Mettez la Freebox sous tension.

Naviguez dans Bluray > Insérer le disque pour insérer le disque.

Attendez que l’option Lire le disque soit disponible mais ne cliquez pas dessus (important!).

Allez dans le menu à droite, Mes Disques, et sélectionnez le lecteur DVD.

Le contenu du disque DVD s’affiche, vous n’avez plus qu’à lancer votre fichier.

Je trouve cette fonctionnalité de la Freebox peu intuitive. Il faut vraiment veiller à bien respecter l’étape 4.

sdcard-recovery-testdisk

Linux : réparer la table de partition d’une carte SD (erreur : “can’t read superblock”)

Le problème : une carte SD non détectée

sdcard-recovery-testdisk

Aujourd’hui, je me rends compte que la carte microSD de mon téléphone Android n’est plus reconnue. Je ne l’ai pas vu tout de suite donc il est fort possible que cela fasse un petit bout de temps que cette situation perdure.

Je la branche sur un lecteur de carte pour voir ce qui se passe et j’obtiens ce message d’erreur :

Error mounting: mount: /dev/sdh1: can't read superblockCode language: JavaScript (javascript)

On vérifie que la carte est détectée :

sudo fdisk -l

Résultat :

Disk /dev/sdh: 16.6 GB, 16574840832 bytes
28 têtes, 60 secteurs/piste, 19269 cylindres, total 32372736 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00000000

Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sdh1            8192    32372735    16182272    c  W95 FAT32 (LBA)

La carte est bien détectée mais elle ne peut être montée. On vérifie maintenant le système de fichiers. Ma carte est en FAT32 donc on lance :

sudo fsck.msdos /dev/sdh1

Résultat :

dosfsck 3.0.12, 29 Oct 2011, FAT32, LFN
/
  Contains a free cluster (2). Assuming EOF.
FAT32 root dir starts with a bad cluster!
Code language: JavaScript (javascript)

Nous avons donc bien des clusters corrompus qui empêchent de monter le sytème de fichier. Nous allons donc utiliser l’utilitaire testdisk pour réparer les mauvais clusters.

La solution : testdisk

On installe testdisk:

sudo apt-get install testdiskCode language: JavaScript (javascript)

et on le lance :

sudo testdisk

Voici ensuite les étapes à suivre dans l’interface sommaire de testdisk :

  1. → Create a new log file
  2. [ choisir le disque qui correspond à la carte SD dans la liste ]
  3. → Intel/PC partition
  4. → Advanced
  5. [ choisir la partition ]
  6. → Boot
  7. → Repair FAT
  8. [ accepter la configuration par défaut et sélectionner Write]
  9. → appuyez sur (Q)uit jusqu’à sortir de l’application.

Et voilà! Quelques secondes plus tard la carte peut de nouveau être montée. Je précise que toutes les données présentes sur la carte avant l’opération sont toujours là, rien n’a été perdu.

A garder sous le coude au cas où cela recommencerait.

WordPress : héberger les images sur un sous-domaine photo 1

WordPress : héberger les images sur un sous-domaine

Cela fait des années que je parle d’héberger les images du site sur un sous-domaine mais j’ai toujours remis cela à plus tard.

Je pensais que la configuration me prendrait un temps infini mais au final cela ne m’aura pris qu’un peu de réflexion et quelques minutes pour tout finaliser.

Le plus long aura été d’écrire ce tutoriel!

Aujourd’hui, c’est chose faite : les images des articles du site sont donc placées sur un sous-domaine pour des raisons de performances.

subdomains

Voici donc un petit tutoriel qui détaille toutes les étapes. Cela prend environ 20 minutes.

Principe de fonctionnement

Les fichiers du site sont présentement servis par Apache. Le domaine est skyminds.net et nous allons créer un sous-domaine, qui est en fait un répertoire au niveau de l’arborescence du site, qui contiendra toutes les images de nos articles.

Par défaut, WordPress place tous les fichiers uploadés via l’interface d’administration dans /wp-content/uploads.

Nous allons donc créer un sous-domaine (static.skyminds.net) qui pointera vers le répertoire /wp-content/uploads.

L’intérêt est que nous n’avons pas à copier ou à déplacer de fichiers. Cela permet aussi de revenir à une installation plus classique à tout moment, sans intervention majeure.

Une fois ce VirtualHost créé, il ne reste plus qu’à modifier les options de WordPress pour les futurs articles et changer les anciennes URI des images dans les anciens articles. P

our finir, nous redirigerons les anciennes URI vers les nouvelles via .htaccess.

Etape 1 : on crée le sous-domaine sur le serveur Apache

Commençons par créer un nouveau VirtualHost pour notre sous-domaine:

nano /etc/apache2/sites-available/static.skyminds.netCode language: JavaScript (javascript)

et ajoutons-y ceci :

ServerAdmin webmaster@localhost
DocumentRoot /home/skyminds/public_html/wp-content/uploads
ServerName static.skyminds.net
ErrorLog /var/log/apache2/www-error.log

        
          AllowOverride None
          RequestHeader unset Cookie
          Header unset Set-Cookie
          Options FollowSymLinks
          Order allow,deny
          Allow from allCode language: JavaScript (javascript)

Plusieurs choses sont importantes à noter dans ce fichier de configuration Apache:

  • DocumentRoot pointe vers le répertoire /home/skyminds/public_html/wp-content/uploads
  • on retire tous les cookies servis par static.skyminds.net

Pas de cookies, pas de soucis et un site qui gagne en rapidité !

Lire la suite

enceintes-bluetooth-novodio-puresound

Ubuntu : associer une clé bluetooth avec des enceintes bluetooth Novodio PureSound

Pour mon anniversaire, j’ai eu la bonne surprise de découvrir mon cadeau : des enceintes Bluetooth Novodio PureSound, pour écouter de la musique ou des podcasts dans le salon sans pour autant rester planté devant l’ordinateur du bureau.

J’ai récupéré une vieille clé bluetooth. Je la branche, elle est détectée instantanément sous Ubuntu sans avoir à installer de pilotes additionnels. Génial.

Etape 1 : installation des paquets bluetooth

Pour commencer, j’avais enlevé il y a quelques années tous les pilotes et applications relatifs à bluetooth, étant donné que je n’avais rien sur cette machine qui disposait de cette technologie.

Du coup, il me faut réinstaller le paquet gnome-bluetooth

sudo apt-get install gnome-bluetoothCode language: JavaScript (javascript)

Etape 2 : établir une connexion permanente

Mettez l’enceinte sous tension et appuyez sur le gros bouton broadcast au dos de l’appareil pour qu’il puisse être détecté.

On lance le scan des appareils Bluetooth à portée :

hcitool scan

Résultat:

Scanning ...
	DC:2C:26:10:09:8D	Novodio PureSoundCode language: CSS (css)

Notre enceinte bluetooth Novodio PureSound est bien détectée. hcitool nous donne également son adresse MAC, que nous allons ajouter à notre configuration :

sudo nano /etc/bluetooth/hcid.conf

et on ajoute les informations relatives à notre enceinte :

device DC:2C:26:10:09:8D {
         name "Novodio PureSound"
         auth enable;
         encrypt enable;
 }Code language: JavaScript (javascript)

et on redémarre le service bluetooth

sudo service bluetooth start

Il existe une manière plus graphique d’ajouter l’enceinte : il suffit de cliquer sur Applications > Outils Système > Paramètres Systèmes > Bluetooth.

Lire la suite

WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod photo 2

WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod

Il est primordial d’accorder les bonnes permissions aux fichiers et dossiers d’un site sur un serveur web. Si ces permissions sont trop permissives, l’administrateur du site s’expose à la compromission du site, voire du serveur.

Sous WordPress, c’est la même chose : les fichiers et dossiers du site doivent avoir les bonnes permissions.

Le problème : des permissions trop larges

chmod-007-permis-executer-300

Sur le site, j’ai eu pendant trop longtemps un problème avec les fichiers et répertoires de thèmes ou de plugins.

Je m’explique : à chaque fois qu’un plugin voulait créer des fichiers (dans un répertoire /cache par exemple), la seule solution était de mettre les permissions de ce répertoire à 777, le mal absolu puisque cela permet au monde entier de lire, écrire et exécuter des fichiers dans ce dossier.

Pour les fichiers de thèmes éditables par WordPress, il fallait que leurs permissions soient à 666, ce qui là aussi posait un gros souci de sécurité.

Voici donc un tuto pour apprendre comment mettre les bonnes permissions à vos fichiers et dossiers pour votre site, qu’il tourne sous WordPress ou non.

Étape 1 : définir le bon propriétaire et groupe pour les fichiers

Les fichiers du site doivent appartenir au propriétaire et au groupe qui les fait tourner.

En règle générale; les serveurs de fichiers (comme Apache ou NginX) ont comme propriétaire www-data et comme groupe groupe www-data.

Dans mon cas, ayant installé les fichiers via SSH, les fichiers étaient détenus par l’utilisateur root. Je crée donc un nouvel utilisateur pour mon site:

adduser caddy www-data

Je vais donc assigner à l’utilisateur caddyet au groupe www-data la permission d’être propriétaire de mes fichiers, avec la commande chown.

Pensez à changer caddypour le nom de votre utilisateur web ou FTP.

Lire la suite

thunar-bulk-renamer

Linux : renommer des fichier en masse avec Thunar Bulk Renamer

Il peut être très utile d’avoir sous la main un petit utilitaire qui permet de renommer des fichiers en masse facilement.

Sous Linux, j’utilise l’outil Thunar Bulk Renamer (Thunar Renommer en masse en français) qui ressemble à ceci :

thunar-bulk-renamer

Thunar Renommer en masse

Thunar est un gestionnaire de fichiers puissant pour XFCE, dont les fonctions peuvent être étendues à l’aide de plugins.

Renommer en masse est un plugin qui permet de renommer toute une liste de fichiers très facilement, avec une interface simple et intuitive. Il permet de :

  • insérer et remplacer des noms de fichiers
  • insérer diverses manières de numéroter
  • rechercher, remplacer, supprimer des caractères
  • changer la casse

Installation de Thunar

Pour installer Thunar, il suffit de lancer :

sudo apt-get install thunarCode language: JavaScript (javascript)

Le raccourci vers l’application Thunar Bulk Renamer se trouve dans Applications > Outils Système > Renommer en masse.

Si le raccourci n’est pas créé, il suffit d’ajouter un nouveau raccourci sur le tableau de bord comme ceci :

1. clic droit sur le tableau de bord > ajouter au tableau de bord > lanceur d’application personnalisé

thunar-bulk-renamer-lanceur

2. entrez la commande suivante :

thunar --bulk-rename

3. choisissez une icône (engrampa.svg m’a semblée adéquate!) et validez.

Thunar Renommer en masse supporte aussi les expressions régulières (regex), c’est un vrai plaisir à utiliser (voir copie d’écran). Un vrai gain de temps également.

Et vous, qu’est-ce que vous utilisez pour renommer vos fichiers ?

Le logo VirtualBox d'Oracle, représentant un cube 3D avec les lettres VM, signifie ses capacités en tant que logiciel de virtualisation permettant aux utilisateurs d'exécuter plusieurs systèmes d'exploitation sur un seul ordinateur, y compris Linux.

Linux : installer VirtualBox via le PPA d’Oracle

J’ai toujours eu un peu de mal avec l’installation et la mise à jour de VirtualBox sous Linux. Il ne faut pas l’installer via les dépôts Ubuntu car ceux-ci deviennent vite obsolètes et ne seront proposées que les mises à jour de sécurité.

Il vaut donc mieux installer VirtualBox directement depuis Oracle, en installant d’abord le noyau linux, les entêtes du noyau et dkms pour éviter toutes les erreurs récurrentes au démarrage de l’application.

Voici ce que j’utilise désormais : tout est automatisé et ne prend que quelques secondes.

Etape 1 : installation des paquets pré-requis

On installe dkms et le noyau linux pour résoudre tous problèmes de dépendances ultérieurs :

sudo apt-get install build-essential dkms linux-source linux-headers-`uname -r`Code language: JavaScript (javascript)

Cela évite, entre autres, de tomber sur cette erreur lors du lancement d’une machine virtuelle :

Kernel driver not installed The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
‘/etc/init.d/vboxdrv setup’
as root.

Etape 2 : installation de VirtualBox avec le PPA d’Oracle

Installation de VirtualBox en une seule commande :

echo "deb http://download.virtualbox.org/virtualbox/debian `lsb_release -sc` contrib" | sudo tee -a /etc/apt/sources.list.d/virtualbox.list && wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add - && sudo apt-get update && sudo apt-get install virtualbox-4.3Code language: PHP (php)

Avec cette commande, on télécharge la clé Oracle pour VirtualBox, on installe le dépôt de VirtualBox en fonction de notre version de Linux, on rafraichit la liste des paquets et on installe la dernière version de VirtualBox.

Lire la suite