Serveur dédié : configurer Webmin en TLS avec un certificat SSL photo 1

Serveur dédié : configurer Webmin en TLS avec un certificat SSL

webmin-logo

Après avoir ajouté la couche TLS/SSL au serveur Apache puis configuré WordPress pour fonctionner uniquement en HTTPS, je me suis intéressé à Webmin.

Je n’utilise pas Webmin pour configurer le serveur parce que c’est une sacrée usine à gaz mais pour certaines choses, c’est utile.

Erreur Webmin : Secure Connection Failed

Après le passage aux connexions sécurisées, j’ai obtenu l’erreur suivante :

Secure Connection Failed

An error occurred during a connection to example.com:10000. The server presented a certificate with a key size that is too small to establish a secure connection. (Error code: mozilla_pkix_error_inadequate_key_size)

En substance, ce message d’erreur indique que la clé du certificat créé par Webmin lors de son installation est trop faible par rapport aux nouvelles exigences de notre certificat. Pas de problème, il suffit de créer un certificat spécialement pour Webmin.

Lire la suite

Serveur dédié : passer WordPress en HTTPS (TLS/SSL) photo

Serveur dédié : passer WordPress en HTTPS (TLS/SSL)

Vous avez sauté le pas et avez validé votre nom de domaine avec un certificat TLS/SSL. Très bien ! Voyons comment passer WordPress sur la version sécurisée de votre site.

Il existe des plugins WordPress entièrement dédiés à SSL pour rediriger vers les pages sécurisées mais on peut très bien faire sans, avec un peu d’huile de coude.

Le tutoriel est pour Debian et WordPress tourne sous Apache chez moi. Cela prend moins d’une heure pour configurer l’essentiel mais il est probable que vous ayez des petites corrections (thèmes, plugins) pour que tout soit servi en https.

Le but est de tout (oui, absolument tout!) servir via la connexion sécurisée.

Étape 1 : configurer Apache

On édite notre fichier de configuration :

nano /etc/apache2/sites-available/www.skyminds.net

et voici ce que garde pour VirtualHost *:80 :

ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/
Redirect 301 / https://www.skyminds.net/

La directive ServerName est nécessaire. Ensuite, une simple redirection renvoie toutes les requêtes du port 80 vers le port 443, sécurisé. Même pas besoin de mod_rewrite!

Lire la suite

Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy photo 1

Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy

Cela fait quelques mois que j’en parle mais aujourd’hui je le fais, je passe le site en HTTPS – ou techniquement en HTTP avec la couche TLS.

Après les révélations d’Edward Snowden et les multiples affaires concernant les écoutes et les fuites des données des citoyens, je pense qu’il est temps de reprendre un peu les choses en main et de nous intéresser au chiffrement de nos connexions.

La réalisation de ce tutoriel prend moins de 30 minutes, il y a peu de fichiers à éditer et de lignes à copier mais il faut être assez attentif aux diverses manipulations (notamment lors de la génération du certificat).

SSL ou TLS ?

Secure Sockets Layer (SSL) est un protocole cryptographique qui permet une communication sécurisée sur Internet. SSL a été développée par Netscape. SSL 2.0 date de 1995, SSL 3.0 de 1996. Les navigateurs actuels ne supportent plus SSL 2.0.

Transport Layer Security (TLS) est le successeur de SSL. TLS 1.0 date de 1999, TLS 1.1 de 2006 et TLS 1.2 de 2008.

Depuis septembre 2014, la dernière version de tous les navigateurs majeurs supporte SSL 3.0, TLS 1.0, 1.1, et 1.2 activés par défaut et les mitigations contre les attaques connues ont été implémentées.

Les navigateurs qui posent encore problème :

– support de TLS 1.1 and 1.2 mais désactivés par défaut : Internet Explorer (8–10 for Windows 7 / Server 2008 R2, 10 for Windows 8 / Server 2012, Mobile 10 for Windows Phone 8), Opera 12

– non-support de TLS 1.1 et 1.2: Internet Explorer (6-8 for Windows Server 2003, 7–9 for Windows Vista / Server 2008, Mobile 7 and 9 for Windows Phone 7.x), Safari 6 for Mac OS X 10.7 and 10.8

– mitigations contre les attaques connues non implémentées: Safari 6 for Mac OS X 10.7

HTTPS et TLS

Le protocole HTTPS (“Hypertext Transport Protocol Secure” ou protocole de transfert hypertexte sécurisé) protège l’intégrité et la confidentialité des informations des visiteurs d’un site.

Par exemple, lorsqu’un internaute saisit des informations dans un formulaire en ligne afin de recevoir des notifications ou d’acheter un produit, un site sécurisé protège les informations personnelles de cet internaute et garantit que ce dernier communique bien avec le propriétaire autorisé du site.

Avec le HTTPS, les informations sont sécurisées via le protocole Transport Layer Security (TLS), qui offre trois niveaux clés de protection.

1. le chiffrement : consiste à coder les données échangées pour les protéger des interceptions illicites. Cela signifie que lorsqu’un internaute navigue sur un site Web, personne ne peut “écouter” ses conversations, suivre ses activités sur diverses pages ni voler ses informations.

2. l’intégrité des données : les informations ne peuvent être ni modifiées, ni corrompues durant leur transfert, que ce soit délibérément ou autrement, sans être détectées.

3. l’authentication : prouve que les internautes communiquent avec le bon site Web. Cet élément protège contre les attaques de l’homme du milieu (“Man In The Middle” aka MITM) et instaure un climat de confiance pour l’internaute.

Lire la suite

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. 

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.com

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"

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.com

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-tools

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/relaxed

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

nano /etc/default/opendkim

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 12345

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 * 

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"

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/mail

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.net

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.net

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_milters

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.log

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 = 3

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.net

Et voilà, tout revient à la normale.

Linux : résoudre l'erreur cron

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 1
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/status

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.

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.net

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 all

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

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

Serveur dédié : mise en place de l'IPv6 photo 4

Serveur dédié : mise en place de l’IPv6

IPv6 (Internet Protocol version 6) est un protocole réseau sans connexion de la couche 3 du modèle OSI.

Grâce à des adresses de 128 bits au lieu de 32 bits, IPv6 dispose d’un espace d’adressage bien plus important qu’IPv4.

Cette quantité d’adresses considérable permet une plus grande flexibilité dans l’attribution des adresses et une meilleure agrégation des routes dans la table de routage d’Internet.

La traduction d’adresse, qui a été rendue populaire par le manque d’adresses IPv4, n’est plus nécessaire.

ipv6

Fin 2013, on estime le déploiement d’IPv6 à 2 %, et ce en dépit d’appels pressants à accélérer la migration, l’épuisement des adresses IPv4 publiques disponibles étant imminent.

Histoire d’assurer la pérennité de la connexion de notre serveur Kimsufi, voici comment mettre en place l’IPv6. Cela prend à peu près 15 minutes.

Etape 1 : récupérer l’adresse IPv6

Méthode graphique : identifiez-vous dans le Manager OVH et allez dans Serveur Dédié > Récapitulatif. Vous devriez obtenir quelques informations sur la connexion de votre Kimsufi, comme ceci :

ipv6-ovh

Méthode “terminal” : un autre moyen de trouver l’IPv6 est de lancer le terminal et taper la commande ifconfig :

ifconfig

Notez bien l’adresse IPv6 du serveur, nous allons nous en servir dans la prochaine étape.

Lire la suite

BIND9 : supprimer le message

BIND9 : supprimer le message “success resolving after reducing the advertised EDNS UDP packet size to 512 octets” des logs

Encore un autre message de mes fichiers logs, trouvé dans /var/log/daemon.log:

named: success resolving DOMAIN after reducing the advertised EDNS UDP packet size to 512 octets
named: success resolving DOMAIN after disabling EDNS

BIND envoie des requêtes EDNS, meme si DNSSEC n’est pas activé. Or il suffit qu’un équipement sur la route refuse les paquets UDP de plus de 512 octets pour que cela couine.

La solution est toute simple, il suffit d’éditer le fichier /etc/bind/named.conf.options :

nano /etc/bind/named.conf.options

et d’y ajouter :

logging {
category lame-servers {null; };
category edns-disabled { null; };
};

Et pour finir, on enregistre les modifications et on redémarre BIND :

/etc/init.d/bind9 restart

Et voilà, plus de messages de ce type dans les logs.

Postfix : résoudre l'erreur SASL

Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”

postfix-logo

En regardant le fichier log /var/log/mail.err, je me suis aperçu que WordPress ne m’envoyait plus les sauvegardes hebdomadaires de la base de données.

Voici les messages d’erreur des logs :

Aug  6 20:07:31 mail postfix/sendmail[6460]: fatal: www-data(33): message file too big
Aug 13 20:07:36 mail postfix/sendmail[2033]: fatal: www-data(33): message file too big
Aug 20 20:07:33 mail postfix/sendmail[30622]: fatal: www-data(33): message file too big
Aug 27 20:07:29 mail postfix/sendmail[16390]: fatal: www-data(33): message file too big

Après une rapide enquête, il se trouve que ma base de données fait plus de 8 Mo, ce qui dépasse la configuration par défaut de Postfix.

Augmenter la limite de poids des messages sous Postfix

Il nous faut donc relever la limite de poids des messages. Pour cela, il suffit d’éditer le fichier de configuration Postfix :

nano /etc/postfix/main.cf

et d’ajouter cette ligne à la fin du fichier :

message_size_limit = 51200000

Cela nous permet d’envoyer jusqu’à 50 Mo. Attention, il faut que la taille de message_size_limit soit inférieure à la taille de la boîte mail, virtual_mailbox_limit. Sur mon serveur, j’ai désactivé cette dernière :

virtual_mailbox_limit = 0

Il ne vous reste plus qu’à relancer Postfix :

/etc/init.d/postfix restart

Et voilà!

hourglass

Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim

Je classe volontairement cet article dans la série Serveur dédié, étant donné que nous allons utiliser la ligne de commande exclusivement. Si vous souhaitez faire la même chose sur votre machine personnelle, il vous suffit d’utiliser Trimage (qui en plus possède une GUI).

hourglass

Si vous possédez un site, blog ou une galerie d’images, il peut être très intéressant d’optimiser toutes vos images d’un seul coup et ce, de manière lossless : chargement plus rapide des pages et moindre consommation de bande passante.

Sous Linux, il existe plusieurs programmes pour le faire. Personnellement, j’ai choisi OptiPNG (pour optimiser les PNG) et JpegOptim (pour optimiser les JPG).

L’installation et la compression de vos répertoires d’images prend à peine quelques minutes.

Installation d’OptiPNG et JpegOptim

On installe nos deux paquets :

apt-get install jpegoptim optipng

et on RTFM :

man jpegoptim

et

man optipng

Optimisation des JPG

On navigue dans notre répertoire images et on fait une estimation des gains. Avant de commencer, vérifiez que vous avez la dernière version de jpegoptim et installez manuellement la dernière version des dépôts Sid.

Commençons par les JPG :

jpegoptim -n -t *.jpg

-n permet de simuler l’optimisation.
-t permet de calculer l’espace gagné

Résultat :

Average compression (2730 files): 0.95% (452k)

Cela peut sembler peu mais je compresse toutes mes images avant de les mettre sur le web. Visiblement, quelques unes sont passées au travers du filet !

Lire la suite