Postfix : résoudre l'erreur SASL "_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql" photo

Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”

postfix-logo

En vérifiant les logs de mon serveur mail, je me suis aperçu que, malgré mon certificat, la connexion du serveur à un serveur sortant n’était pas entièrement chiffrée.

Voici comment remédier à ce problème.

Postfix : “untrusted connection SMTP”

Concrètement, voici la transcription du log d’une connexion SMTP dite “untrusted connection SMTP” :

postfix/cleanup: message-id=<9@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25, delay=1.5, delays=0.12/0.06/0.55/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1430771763 z16si1523612wjr.190 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com>Code language: HTTP (http)

Comme on peut le constater, notre connexion TLS n’est pas chiffrée de bout en bout :

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)Code language: JavaScript (javascript)

Solution : ajouter la directive smtp_tls_CAfile

J’ai pour habitude de mettre les mêmes valeurs pour les directives smtp_* et smtpd_* mais dans ce cas précis, il faut modifier la valeur de la directive smtp_tls_CAfile.

On édite le fichier de configuration de Postfix :

nano /etc/postfix/main.cf

On modifie smtp_tls_CAfile pour pointer vers le fichier /etc/ssl/certs/ca-certificates.crt:

###
# Trusted TLS connection to gmail-smtp
# by Matt 
# https://www.skyminds.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###Code language: PHP (php)

et on redémarre Postfix :

service postfix restart

Trusted TLS connection established

Après un envoi de test, voici ce que nous donnent les logs:

postfix/cleanup: message-id=<a@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.136.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.136.27]:25, delay=1.1, delays=0.12/0.07/0.31/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1430772064 jt5si24487408wjc.48 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com></a@mail.example.com>Code language: HTML, XML (xml)

Et voilà, connexion vers les serveurs SMTP chiffrée et validée comme trusted!

debian-8-jessie

Serveur dédié : la mise à jour vers Debian 8 Jessie

Hier soir, j’ai mis à jour le serveur : nous passons de Debian 7.8 (wheezy) à 8.0 (jessie).

Tout s’est plutôt bien passé, il y a eu environ 10 minutes de downtime, le temps que je comprenne ce qui avait changé, notamment dans la configuration Apache et celle de Postfix.

Voici un petit compte-rendu de la mise à jour.

Mise à jour des dépôts

On édite notre fichier source APT :

nano /etc/apt/sources.listCode language: PHP (php)

et on remplace toutes les occurences de wheezy par jessie.

Chez moi, cela donne :

# DEBIAN
deb http://mirror.ovh.net/debian/ stable main contrib non-free
deb-src http://mirror.ovh.net/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

# mod security
deb http://ftp.debian.org/debian/ jessie-backports mainCode language: PHP (php)

Préparation à la mise à jour de Debian

J’ai commencé par vérifier qu’aucun paquet n’était à moitié installé :

dpkg --audit

ou en attente :

dpkg --get-selections | grep 'holdCode language: JavaScript (javascript)

Rien? Tout va bien, on continue et on simule une installation avec :

apt-get -o APT::Get::Trivial-Only=true dist-upgradeCode language: PHP (php)

Le résultat est une longue liste de paquets, suivie du message suivant:

439 upgraded, 192 newly installed, 5 to remove and 1 not upgraded.
Need to get 275 MB of archives.
After this operation, 259 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.Code language: JavaScript (javascript)

Nos sauvegardes sont faites, on se lance.

Mise à jour Debian

On rafraichit les dépôts et on lance l’installation:

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

On obtient un laïus avec ce qui change. J’aperçois plusieurs pages sur Apache, on y reviendra. Cela dure à peu près une dizaine de minutes, bien que je n’ai pas vraiment minuté.

Une fois l’installation terminée, on résout les dépendances et les paquets manquants avec :

apt-get dist-upgradeCode language: JavaScript (javascript)

Je lance le site pour voir : paf, erreur 403.

Lire la suite

WordPress : récupérer la liste emails des membres et commentateurs photo

Résoudre les lightbox vides dans l’administration WordPress

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.

J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

Load denied by X-Frame-Options.... X-Frame-Options does not permit framing.

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENYCode language: JavaScript (javascript)

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).

Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.

Lire la suite

PHP : résoudre l'erreur "Redefining already defined constructor for class ..." photo

Serveur dédié : mise à jour vers PHP 5.6

php-logo

Je viens de mettre à jour la version de PHP sur le serveur, histoire de tourner sur une version plus récente et bénéficiant des dernières nouveautés.

En moins de 3 minutes, je suis passé de PHP 5.4.39 à PHP 5.6.7 sur ma Debian, tout en douceur.

Voici la marche à suivre.

Ajout des dépôts Dotdeb

Si vous ne l’avez déjà fait, ajoutez les dépôts Dotdeb de Guillaume Plessis:

nano /etc/apt/sources.listCode language: PHP (php)

et ajoutez-y:

# Dotdeb default
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all
# PHP 5.6 on Debian 7 (without Zend thread safety)
deb http://packages.dotdeb.org wheezy-php56 all
deb-src http://packages.dotdeb.org wheezy-php56 allCode language: PHP (php)

Mise à jour de PHP

On met à jour nos dépôts :

apt-get updateCode language: JavaScript (javascript)

et on met à jour notre version de PHP-FPM avec:

apt-get install php5-fpm php5-ssh2 php-pear php5 php5-devCode language: JavaScript (javascript)

Résultat :

The following packages will be REMOVED:
  libssh2-php
The following NEW packages will be installed:
  libvpx1 php5-ssh2
The following packages will be upgraded:
  php5-cli php5-common php5-curl php5-fpm php5-gd php5-mcrypt php5-mysqlnd php-pear php5 php5-devCode language: PHP (php)

Cela met à jour les paquets PHP qui dépendent de la nouvelle version.

Bientôt PHP7!

Au passage, l’installation demande quoi faire avec les fichiers de configuration : j’ai choisi de garder les miens, pour ne pas avoir à tout reconfigurer.

Je pense que je partirai sur une configuration de base lorsque l’on passera à PHP7, qui devrait enfin faire décoller les performances et dont la sortie est prévue le 15 novembre 2015.

Il ne reste plus qu’à redémarrer Apache et PHP :

service apache2 restart && service php5-fpm restart

Et voilà! Une mise à jour toute en douceur et sans accrocs.

Serveur dédié : activer l'IP canonique du serveur sous Apache photo

Serveur dédié : activer l’IP canonique du serveur sous Apache

J’ai récemment procédé à quelques tests sur le serveur et me suis rendu compte que l’adresse IP du serveur ne renvoyait pas vers le nom de domaine : la canonisation de l’IP serveur n’était pas activée.

Mise en forme canonique de l’IP du serveur

La mise en forme canonique (canonicalization en anglais) est le procédé par lequel on convertit des données qui ont plusieurs représentations possibles vers un format standard.

Dans le cas des URL, cela va nous permettre d’associer une page à une seule adresse. Cela aide les moteurs de recherche à indexer uniquement les pages sur lesquelles se trouvent les contenus et évite le doublons d’indexation pénalisants.

Au cours d’un test, j’ai donc obtenu ce message :

Your site's IP does not redirect to your site's domain name. This could cause duplicate content problems if a search engine indexes your site under both its IP and domain name.Code language: JavaScript (javascript)

En soi, cela n’est pas gênant mais cela signifie que l’on peut accéder au site à partir de l’adresse IP et qu’il n’y a pas de redirection vers le nom de domaine.

Cela me dérange un peu donc nous allons voir comment l’activer en quelques secondes sous Apache.

Editer le VirtualHost par défaut

Sous Apache, il existe les VirtualHost que vous avez défini pour vos sites mais également un VirtualHost par défaut, activé par défaut.

C’est ce VirtualHost que nous allons éditer:

nano /etc/apache2/sites-available/defaultCode language: JavaScript (javascript)

On y garde simplement ceci :

    ServerAdmin webmaster@localhost
    DocumentRoot /
    
	Options FollowSymLinks
	AllowOverride None
	RewriteEngine On

	# redirect all domains to skyminds.net
	RewriteCond %{HTTP_HOST} !^((.*)\.skyminds\.net)?$
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]

	# Enforce www and canonicalization
	RewriteCond %{HTTP_HOST} !^www\.skyminds\.net [NC]
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]

	# IP to domain
	RewriteCond %{HTTP_HOST} ^xxx\.xxx\.xxx\.xxx
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]Code language: PHP (php)

Il vous suffit de remplacer mon domaine (skyminds.net) avec le votre et de modifier l’adresse IP de votre serveur.

Lire la suite

Bash : réparer les tables MySQL en cas de crash photo

Bash : message “there are stopped jobs” à la fermeture du terminal

Bash

Ce week-end, j’effectue quelques petites modifications sur les fichiers du serveur et, voulant annuler une faute de frappe, j’effectue un Ctrl + Z, par habitude.

Ma fenêtre d’édition du fichier se ferme. Surpris, je la rouvre puis continue mon travail. Au moment de fermer ma session SSH, lors du traditionnel exit, j’obtiens ce message :

logout
There are stopped jobs.

Et là, pas moyen de quitter la session proprement. Cela est dû à ce fameux Ctrl + Z.

Bash et les tâches de fond

Dans Bash, un “stopped job” est une tâche qui a été reléguée temporairement en tâche de fond. Elle n’est pas active mais continue de consommer des ressources comme la mémoire système.

Cette tâche n’étant pas attachée à notre fenêtre de terminal, elle n’envoie rien en sortie et ne reçoit rien en entrée de la part de l’utilisateur.

Reprendre la main sur le shell

Pour savoir quelles sont les tâches de fond en cours sur le système, il suffit de taper la commande jobs:

jobs

Cela liste toutes les tâches reléguées au second plan.

Ensuite, il suffit de taper la commande fg (foreground) pour basculer la tâche de fond vers notre fenêtre active. Si nous voulons basculer vers la première tâche, nous entrons :

fg 1

Il suffit alors de quitter proprement la tâche pour pouvoir ensuite fermer notre session.

Serveur dédié : installer la dernière version d'OpenSSL sous Debian photo

Serveur dédié : installer la dernière version d’OpenSSL sous Debian

Aujourd’hui, on s’intéresse à la mise à jour d’OpenSSL sur un serveur Debian, en utilisant les dépôts sid.

Cela va nous permettre d’installer la dernière mise à jour d’OpenSSL, responsable du chiffrement des connexions de plusieurs services (serveur de fichier, serveur mail, serveur DNS…), pour plus de sécurité sur le serveur.

Ce tutoriel ne prend que quelques minutes et quatre étapes mais il faut bien le suivre jusqu’au bout.

Vérification de la version d’OpenSSL

On commence par vérifier la version d’OpenSSL installée sur notre Debian, pourtant à jour :

openssl version

résultat :

OpenSSL 1.0.1e 11 Feb 2013Code language: CSS (css)

Ouch! Ah oui, ça date un peu! Vérifions les versions disponibles :

apt-cache policy openssl

résultat :

openssl:
  Installed: 1.0.1e-2+deb7u14
  Candidate: 1.0.1e-2+deb7u14
  Version table:
 *** 1.0.1e-2+deb7u14 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.1e-2+deb7u13 0
        500 http://mirror.ovh.net/debian/ wheezy/main amd64 PackagesCode language: JavaScript (javascript)

Nous avons la dernière version stable qui correspond aux dernières mises à jour de notre distribution mais c’est loin d’être la dernière version disponible.

Mise à jour de nos dépôts avec la version sid (unstable)

Nous allons tous simplement installer la dernière version d’OpenSSL qui se trouve dans les dépôts sid, réputés instables car non-testés de manière exhaustive.

On édite la liste de nos dépôts :

nano  /etc/apt/sources.listCode language: PHP (php)

et on y ajoute les dépôts sid :

deb http://ftp.debian.org/debian sid main
deb-src http://ftp.debian.org/debian sid mainCode language: JavaScript (javascript)

On met à jour nos dépôts:

apt-get updateCode language: JavaScript (javascript)

On vérifie les versions d’OpenSSL disponibles :

apt-cache policy openssl

Résultat :

openssl:
  Installed: 1.0.1e-2+deb7u14
  Candidate: 1.0.1k-1
  Version table:
     1.0.1k-1 0
        500 http://ftp.debian.org/debian/ sid/main amd64 Packages
 *** 1.0.1e-2+deb7u14 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.1e-2+deb7u13 0
        500 http://mirror.ovh.net/debian/ wheezy/main amd64 PackagesCode language: JavaScript (javascript)

Pas mal : nous pouvons passer de la version 1.0.1e à la version 1.0.1k et donc bénéficier de tous les mises à jour récentes d’OpenSSL.

Lire la suite

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS photo

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS

J’ai vraiment aimé jouer avec Varnish.

Le problème, c’est qu’en passant l’intégralité du site en HTTPS, il m’est devenu inutile.

Varnish est incompatible avec HTTPS et ne le sera probablement jamais puisque les connexions chiffrées ne doivent, par définition, jamais être mises en cache.

Par conséquent, j’ai décidé de le retirer temporairement du serveur : cela me fera un service de moins à gérer.

Notez que je ne le désinstalle pas, je m’assure juste qu’on ne fait pas appel à lui. Cela me permettra de le remettre en route si jamais j’héberge un jour un site en HTTP simple.

Ce tutoriel part du principe que vous avez suivi les tutoriels précédents et que votre serveur tourne avec Apache et Varnish comme reverse-proxy.

Configuration d’Apache

On doit éditer plusieurs fichiers :

1. le fichier /etc/apache2/ports.conf :

 nano /etc/apache2/ports.conf 

On remet les valeurs par défaut et on écoute sur le port 80 :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

# SkyMinds.Net
# Quand Varnish est actif
# NameVirtualHost *:8080
# Listen 8080

# Apache only
NameVirtualHost *:80
Listen 80


    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.

   NameVirtualHost *:443
   Listen 443



    Listen 443
Code language: PHP (php)

2. les fichiers de chacun de nos VirtualHosts :

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

On écoutait sur le port 8080, on se remet sur le port 80 :

#<virtualhost *:8080="">
<virtualhost *:80="">
Code language: HTML, XML (xml)

Lire la suite

Postfix : résoudre l'erreur SASL "_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql" photo

Postfix : résoudre l’erreur “close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)”

postfix-logo

En jetant un oeil sur les logs du serveur du mail, je me suis aperçu que le même message d’erreur revenait à intervalles réguliers, entre quelques statistiques.

Il s’agit de Postfix qui donne le message suivant :

close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)

Selon le créateur de Postfix, ce n’est pas un bug mais juste un message sans conséquence. N’empêche que l’on peut s’en passer facilement.

Solution : ajouter address_verify_map à la configuration Postfix

Cette erreur survient lorsque le fichier de configuration Postfix n’est pas tout à fait complet.

Lire la suite

PHP : solution pour l'erreur "preg_match(): Compilation failed: invalid range in character class" photo

PHP : résoudre l’erreur “Redefining already defined constructor for class …”

php-logo

Il vous est peut-être déjà arrivé d’obtenir l’erreur PHP suivante en mode strict sous PHP 5.4 et versions ultérieures:

Redefining already defined constructor for class {nom_de_la_classe}

Cela arrive lorsque – dans le code d’une classe -, le code PHP4 précède le code PHP5 avec le constructeur de classe.

Le problème : une fonction PHP4 précédant le constructeur PHP5

Voici un petit exemple pour bien comprendre, avec une classe SkymindsExampleClass, une fonction qui s’appelle SkymindsExampleClass() et donc porte le même nom, et la fonction constructeur __construct().

L’exemple suivant produit l’erreur Redefining already defined constructor for class parce que la fonction PHP4 SkymindsExampleClass() se trouve avant la fonction PHP5 __construct() :

<?php
// This example outputs a PHP error in strict mode
class SkymindsExampleClass {
	//PHP4
	function SkymindsExampleClass()
	{
		$this->__construct();
	}
	//PHP5
	public function __construct()
	{
		$this->admin_page();
	}
}Code language: HTML, XML (xml)

La solution : placer le code PHP5 avant le code PHP4

Pour supprimer l’erreur PHP stricte, il suffit de placer la fonction PHP5 avant la fonction PHP4.

Lire la suite

MySQL : résoudre l'erreur "mysql_connect(): Headers and client library minor version mismatch" photo

MySQL : résoudre l’erreur “mysql_connect(): Headers and client library minor version mismatch”

Après la mise à jour vers MySQL 5.6, certaines applications peuvent renvoyer l’avertissement PHP suivant :

PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:50535 Library:50617Code language: CSS (css)
icon-mysql

C’est le cas lorsqu’une application est liée à l’utilisation d’une version spécifique de libmysqlclient18 alors qu’elle est connectée à un serveur MySQL qui tourne sur une version différente.

C’est libmysqlclient18 qui renvoie cet avertissement mais dans certains cas, cela peut impacter l’application et tient plus de l’erreur que de l’avertissement.

MySQL Native Driver

La solution est toute simple : il suffit d’utiliser le pilote MySQL Native Driver php5-mysqlnd au lieu du paquet php5-mysql.

Les avantages de php5-mysqlnd sont multiples : il vient en remplacement de php5-mysql, n’est pas lié à la librairie libmysqlclient, ne renvoie pas d’avertissement “version mismatch” et possède pas mal d’autres caractéristiques intéressantes.

Lire la suite

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy photo

Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy

Aujourd’hui, on va s’atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.

Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d’utilisateurs virtuels, c’est-à-dire que le serveur de mail doit déjà être opérationnel.

Vérification du fonctionnement du serveur de mail

On commence par vérifier que le serveur est capable d’envoyer des mails avec :

echo "test" | mail -s testsubject user@example.comCode language: PHP (php)

Si le mail est reçu, passez à l’étape suivante.

Configuration du certificat SSL

Nous allons concaténer la clé et le certificat pour Courier :

cd /etc/ssl
cat skyminds.net.key  skyminds_net.crt >> courier-key-crt-dh.pem

et on va y inclure un échange de clés Diffie-Hellman :

openssl dhparam 2048 >> courier-key-crt-dh.pemCode language: CSS (css)

On ajoute une autre clé DH en 2048 bits:

openssl gendh -out /etc/postfix/dh_2048.pem -2 2048

L’échange de clés Diffie-Hellman – du nom de ses auteurs Whitfield Diffie et Martin Hellman – est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d’accord sur un nombre (qu’ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l’échange.

Lire la suite