Configurer vsftpd pour mettre à jour automatiquement WordPress

Jean-François VIAL — Sun, 17 May 2009 16:06:29 +0000

WordPress, intègre des possibilités de mise à jour automatique des plugins en utilisant le protocole FTP. Certains se poseront la question du pourquoi de l'utilisation de FTP pour cela alors que PHP est très à même de télécharger des fichiers depuis l'internet et lancer des commandes shell pour décompresser les archives, sans parler de la gestion des fichiers, mais ça n'est pas l'objet de cet article.

Afin de pouvoir utiliser cette fonctionnalité de mise à jour de WordPress, il vous faut un serveur FTP sur votre serveur. Je vais vous proposer vsftpd (pour Very Secure File Transfert Protocol Deamon : Service de Transfert de Fichiers Trés Sécurisé) alors que d'autres sont de fervents adeptes de Proftp. Ce choix s'explique par deux arguments, le premier étant la sécurité qu'il apporte (RedHat, OpenBSD et SuSE, notamment, l'utilisent pour leurs serveurs FTP publics), le deuxième étant sa simplicité de configuration.

Vsftpd permet de créer des utilisateurs virtuels Ces utilisateurs virtuels utilisent sur le système l'identité de l'utilisateur “ftp” pour effectuer les opérations sur le système de fichiers. Vsftpd permet aussi de n'écouter que certaines interfaces, ce qui nous permettra de sécuriser totalement notre serveur.

Comme d'habitude, nous allons prendre l'exemple d'une distribution basée sur Debian (Debian, Ubuntu et dérivés…) la première chose à faire étant d'installer vsftpd via un sudo apt-get install vsftpd (ou autre, selon votre distribution).

En suite, trois choses à configurer : PAM pour permettre l'utilisation des utilisateurs virtuels, vsftpd lui même par le biais de son fichier de configuration et les utilisateurs virtuels.

Enfin il conviendra de modifier quelque peu les droits d'écriture de certains répertoires et fichiers.

1. Configuration de PAM

Il faut, si ces bibliothèques ne sont pas déja présentes, installer le support des bases de données Berkeley : libdbX et dbX-util où X = la version, 4.4, 4.6 ou 4.7 soit, par exemple, sudo apt-get install libdb4.6 db4.6-util.

En suite, configurer PAM pour lui dire où chercher les informations de connexion : éditer le fichier /etc/pam.d/vsftpd (le créer si besoin, le vider si déjà présent) et y mettre :

auth required /lib/security/pam_userdb.so db=/etc/vsftpd/login
account required /lib/security/pam_userdb.so db=/etc/vsftpd/login

Si vous êtes en 64 bits, il conviendra peut être de remplacer lib par lib64.

Aller dans le répertoire /etc/vsftpd (le créer si besoin), et créer un fichier “login.txt” qui contiendra, en clair, les login et mots de passe de tous les utilisateurs virtuels. Ce fichier est de la forme :

login1
mot de passe de login1
login2
mot de passe de login2
…

Pour WordPress, on va y mettre, par exemple :

wordpress
wp-pass

Il faut en suite convertir ce fichier en base de données Berkeley à l'aide de la commande :

sudo db4.6_load -T -t hash -f /etc/vsftpd/login.txt /etc/vsftpd/login.db

Remarque : il conviendra de remplacer db4.6_load par db4.4_load ou db4.7_load selon la version disponnible.

Note: certains se demandent pourquoi faire ça (écrire les mots de passe dans un fichier en clair et le convertir en db) et ne pas directement utiliser le fichier en clair : c'est simplement qu'il sera, par la suite, plus simple pour ouvrir le serveur ftp au public. Il suffira de faire un chmod à 600 sur ces fichiers et/ou de supprimer la version en clair.

2. Configuration de vsftpd

Sauvegarder /etc/vsftpd.conf (par, par exemple un petit sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.bak), l'éditer, le vider et y mettre :

# Lancement de vsftpd en standalone
listen=YES
# vsftpd ne va accepter les connexion uniquement depuis le serveur lui même
listen_address=127.0.0.1
# activation des utilisateurs locaux (permet d'utiliser les utilisateurs virtuels)
local_enable=YES
# Afin de permettre la mise à jour, il *faut* permettre l'écriture
write_enable=YES
# activation explicite des utilisateurs virtuels
guest_enable=YES
# force les utilisateurs virtuels d'agir vis à vis du système comme l'utilisateur
guest_username=ftp
# force les utilisateurs à rester dans le ~ de l'utilisateur guest (spacifié juste au dessus soit '/home/ftp/')
chroot_local_user=YES
# active la configuration 'per user" permettant, de créer plusieurs utilisateurs virtuels si besoin par la suite, pour un autre WordPress par exemple
user_config_dir=/etc/vsftpd/users

Attention : si vous souhaitez, par la suite, ouvrir votre serveur ftp au public, veuillez ré-utiliser le fichier de configuration initial et le compléter avec les éléments de cet exemple. En effet, étant donné que notre WordPress est sur le même serveur que le serveur FTP, on n'a pas besoin de restreindre la sécurité outre mesure, ce qui ne convient évidement pas à une utilisation “publique”

3. Configuration des utilisateurs

On va utiliser ici une configuration “per user” qui permet de modifier la configuration pour chaque utilisateur virtuel (cas où on utilise plusieurs installations de WordPress sur le même serveur). Pour se faire, il nous faut simplement créer un fichier pour chaque utilisateur dans /etc/vsftpd/users (qu'il faudra créer via sudo mkdir /etc/vsftpd/users)

Nous avons créé plus haut un utilisateur nommé “wordpress”, créons donc ce fichier en le nommant “wordpress” : sudo nano /etc/vsftpd/users/wordpress et mettons ce qui suit dedans :

# l'utilisateur doit être enfermé dans un dossier contenu dans /home/ftp
# ce dossier sera un lien symbolique vers la racine (contenant le dossier wp-content)
# de votre installation de WordPress
local_root=/home/ftp/wordpress
# droit d'écriture
write_enable=YES
anon_upload_enable=YES
# droit créer des dossiers
anon_mkdir_write_enable=YES
# droit de renommer, supprimer...
anon_other_write_enable=YES
# signifie que l'utilisateur virtuel à les mêmes droits que l'utilisateur réel (ici ftp)
virtual_use_local_privs=YES
# définit l'umask pour les fichiers
local_umask=022

En suite il faut créer le lien symbolique dans /home/ftp, dans le fichier de configuration, nous avons spécifié “/home/ftp/wordpress”. Ce lien symbolique va devoir pointer vers le dossier racine de votre installation de WordPress (contenant wp-content) mettons /home/www/blog/, ce qui donne : sudo ln -s /home/www/blog /home/ftp/wordpress

4. Droits utilisateur

Il faut permettre à l'utilisateur ftp de créer des dossiers et des fichiers dans le dossier wp-content/upgrade (qu'il faudra créer, car il n'existe pas par défaut à moins que vous ne donniez ces droits au dossier wp-content). Même chose à tous les dossiers/fichiers contenus dans le dossier wp-content/plugins
Je vous laisse faire, après tout, si vous êtes arrivés jusqu'ici c'est que vous en êtes capable normalement.

5. Redémarrage de vsftpd et tests

Redémarrer vsftpd via sudo /etc/init.d/vsftpd restart et tester la mise à jour des plugins de WordPress : pour se faire, si vous n'avez pas de plugin à mettre à jour, vous pouvez toujours télécharger une ancienne version d'un plugin et chercher à le mettre à jour.

Dans WordPress, allez dans le menu “Extentions”, et cliquez sur “mise à jour automatique” sur la ligne d'un plugin à mettre à jour. Un formulaire apparaît, entrez-y “127.0.0.1” comme hôte, “wordpress” comme login, “wp-pass» comme mot de passe, et cochez “FTP” puis "mettre à jour". Si vous voyez une erreur lors de la mise à jour, lisez bien le message renvoyé par WordPress : il vous renseignera exactement sur ce qui ne va pas. Si WordPress n'arrive pas à créer ou supprimer un fichier/dossier dans un répertoire, vérifiez les droits, le plus souvent les problèmes viennent de là.

Si les droits s'emblent ok, vérifiez le fonctionnement du serveur directement avec le client ftp en ssh : une session "réussie" devrait ressembler à ça :

$ ftp 127.0.0.1
Connected to 127.0.0.1.
220 (vsFTPd 2.0.6)
Name (127.0.0.1:modulaweb): wordpress
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rwxrwxr-x    1 1002     33            397 May 25  2008 index.php
-rwxrwxr-x    1 1002     33          15410 Dec 06 07:47 license.txt
-rwxrwxr-x    1 1002     33           7638 Oct 29  2008 readme.html
drwxrwxrwx    3 1002     33           4096 May 17 13:20 upgrade
drwxrwxr-x    2 1002     33           4096 Apr 30 10:33 util
drwxrwxr-x    8 1002     33           4096 Apr 15 03:36 wp-admin
-rwxrwxr-x    1 1002     33          40271 Nov 28 21:04 wp-app.php
-rwxrwxr-x    1 1002     33            220 Oct 14  2008 wp-atom.php
-rwxrwxr-x    1 1002     33            274 May 25  2008 wp-blog-header.php
-rwxrwxr-x    1 1002     33           3483 Apr 16 23:27 wp-comments-post.php
-rwxrwxr-x    1 1002     33            238 Oct 14  2008 wp-commentsrss2.php
-rwxrwxr-x    1 1002     33           2497 Dec 16 08:33 wp-config-sample.php
-rwxrwxr-x    1 1002     33           2702 May 02 02:47 wp-config.php
drwxrwxr-x    7 1002     33           4096 May 17 13:39 wp-content
-rwxrwxr-x    1 1002     33           1242 Sep 18  2008 wp-cron.php
-rwxrwxr-x    1 1002     33            220 Oct 14  2008 wp-feed.php
drwxrwxr-x    6 1002     33           4096 May 01 16:19 wp-includes
-rwxrwxr-x    1 1002     33           1986 May 25  2008 wp-links-opml.php
-rwxrwxr-x    1 1002     33           2004 Oct 31  2008 wp-load.php
-rwxrwxr-x    1 1002     33          19738 Dec 03 19:04 wp-login.php
-rwxrwxr-x    1 1002     33           6932 Dec 09 18:03 wp-mail.php
-rwxrwxr-x    1 1002     33            487 May 25  2008 wp-pass.php
-rwxrwxr-x    1 1002     33            218 Oct 14  2008 wp-rdf.php
-rwxrwxr-x    1 1002     33            316 May 25  2008 wp-register.php
-rwxrwxr-x    1 1002     33            218 Oct 14  2008 wp-rss.php
-rwxrwxr-x    1 1002     33            220 Oct 14  2008 wp-rss2.php
-rwxrwxr-x    1 1002     33          18695 Jan 24 13:21 wp-settings.php
-rwxrwxr-x    1 1002     33           3434 May 25  2008 wp-trackback.php
-rwxrwxr-x    1 1002     33          92428 Jan 19 18:47 xmlrpc.php
226 Directory send OK.
ftp> exit
221 Goodbye.

N'hésitez pas à faire des suggestions ou remarques en commentaire.

Pour des sessions SSH qui durent

Jean-François VIAL — Mon, 23 Feb 2009 03:43:38 +0000

Qui n'a jamais été irrité de voir une session SSH "bloquée" car laissée sans activité ?
Qui n'a jamais eu son système bloqué pendant quelques instants car un montage de système de fichiers via SSH avait été déconnecté faute, là aussi, d'activité ?

À ce fléau qu'est la déconnexion intempestive, une solution existe, et elle est très simple : il suffisait de lire le man...

Le client SSH, peut envoyer des paquets "keep-alive" à intervalles réguliers lors de la session. Lorsque le serveur reçoit ces paquets, il sait que, bien que le client ne génère pas d'activité, il faut garder la connexion active. De même, le serveur SSH, peut lui aussi envoyer ces paquets... sauf que, par défaut, ils ne le font pas. Pour les forcer à le faire, il suffit d'éditer les fichiers de configuration du client et/ou du serveur, selon à quoi on a accès et selon ce qu'on veut faire. Le mieux est de se contenter du client lorsque c'est possible, évidement.

Pour activer la fonction coté client, écrire :

Host *
    ServerAliveInterval 60

dans "~/.ssh/config" (créer le fichier au besoin) pour appliquer à son propre utilisateur ou dans "/etc/ssh/ssh_config" pour l'activer sur tout le système, ou alors en en argument de l'option "-o" lors de l'appel à "ssh".

Coté serveur, même chose, mais l'option s'appelle "ClientAliveInterval".

"Host *" activera l'option sur tous les hôtes, mais vous pourriez utiliser un hote spécifique et créer ainsi une règle pour chaque hôte... le "60" indiquant "60 secondes", mais vous pourriez indiquer plus ou moins selon vos besoins.

Blog Modulaweb » ssh