Voici une astuce bien utile si votre serveur est complètement planté.
Il faut néanmoins pouvoir se connecter en SSH sur la machine et avoir un shell en root.

Dans mon cas, il s’agissait d’un problème d’accès disque, la plupart des commandes exécutées renvoyaient des erreurs d’entrée/sortie, y compris la commande reboot, qui a besoin d’exécuter les scripts d’init de niveau 6.

Mais tout n’est pas perdu, si vous n’avez pas d’accès physique à la machine ! On va passer par le pseudo système de fichier /proc pour parler directement au noyau et lui dire de redémarrer la machine.
Avant tout (et si il ne s’agit pas d’un problème disque), on tente de forcer la synchronisation du cache vers le disque :

sync

On active ensuite les magic sysrq key si elles ne le sont pas déjà :

echo 1 > /proc/sys/kernel/sysrq

Puis on modifie l’état de la machine :

echo b > /proc/sysrq-trigger

Cette dernière action a exactement le même effet que la combinaison Alt + Syst + b.

Après cela, priez pour que la machine redémarre correctement

Tout récemment, j’ai installé sur mon serveur StatusNet, le moteur de microblogging libre, utilisé notamment par Identi.ca. Dans l’ensemble, l’installation est bien documentée dans le README. Un fichier htaccess d’exemple est présent contenant les règles de réécriture d’URL. Si vous utilisez Apache, pas de problème, renommez le fichier en .htaccess et c’est parti. Seulement, si on utilise un autre serveur web, il faudra adapter ces règles à la syntaxe de son serveur. Voici comment faire avec Lighttpd.

Fichiers de configuration

Un petit rappel du contenu du htaccess de StatusNet :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<IfModule mod_rewrite.c>                                                                                                           
  RewriteEngine On
 
  # NOTE: change this to your actual StatusNet base URL path,
  # minus the domain part:
  #
  #   http://example.com/        => /
  #   http://example.com/mublog/ => /mublog/
  #
  RewriteBase /mublog/
 
  ## Uncomment these if having trouble with API authentication
  ## when PHP is running in CGI or FastCGI mode.
  #
  #RewriteCond %{HTTP:Authorization} ^(.*)
  #RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]
 
  RewriteCond %{REQUEST_FILENAME} !-f 
  RewriteCond %{REQUEST_FILENAME} !-d 
  RewriteRule (.*) index.php?p=$1 [L,QSA]
</IfModule>

Et voici son adaptation à la sauce lighty :

1
2
3
4
5
6

# Si mod_rewrite n'est pas activé, on l'active
server.modules += ( "mod_rewrite" )
# Équivalent de RewriteBase
base_url = "/" 
# La règle de redirection
url.rewrite-if-not-file = ( "^" + base_url + "(\w+)" => base_url + "index.php/$1" )

C’est plutôt… court

Explications

• Sous Lighttpd, il n’existe pas vraiment d’équivalent à RewriteBase, on utilise alors une simple variable, nommée ici base_url ;
• Conditions de réécriture : on utilise la directive url.rewrite-if-not-file. Cela a pour effet de réécrire seulement si l’URL pointe sur un fichier inexistant. Cependant, cela ne prend pas en compte les répertoires (pour remplacer RewriteCond %{REQUEST_FILENAME} !-d d’Apache).
  C’est là que je me suis posé la question de la présence de cette directive dans le htaccess. Je ne vois vraiment aucun cas où l’application aurait besoin d’accéder (donc de lister) un répertoire. De toute manière, le dir-listing est désactivé par défaut, donc le problème est clos ;
• Règle de réécriture et flags : Avant tout, on ne va pas s’embêter avec les paramètres GET dans l’URL, l’index.php permet convertir les URL du style /index.php/toto en /index.php?p=toto, et lighttpd le supporte.
  La regex ne change pas vraiment, en revanche pour ce qui est des flags Apache : [L] permet d’arrêter le traitement de réécriture d’URL, c’est le comportement par défaut du coté de lighty (sinon on aurait utilisé url.rewrite-repeat-if-not-file). Pour le flag [QSA], qui permet de ne pas tronquer l’URL en cas de paramètres GET multiples, il ne sert à rien puisqu’on utilise pas ce genre d’URL (Sinon la réponse se trouve dans le second lien en fin d’article).

Liens utiles

[1] Apache mod_rewrite
[2] Adaptation des règles de rewrite Apache -> Lighttpd
[3] Lighttpd mod_rewrite

Une petite astuce qui simplifie beaucoup la vie

Quoi de plus énervant que de redémarrer son serveur web après avoir tweaker sa config et de se faire jeter à causse d’une erreur de syntaxe. Surtout que pendant que vous corriger l’erreur dans le fichier, votre serveur web est down ; un temps de disponibilité bêtement perdu.

Alors heureusement, il existe avec la plupart des serveurs web une commande pour vérifier la syntaxe de la conf (lighttpd -t -f config_file sous Lighttpd et apache2ctl configtest sous Apache2). Mais il faut penser à l’exécuter avant chaque redémarrage, ce qui peut devenir très lourd, c’est pourquoi j’ai eu l’idée de l’intégrer dans le script d’init de Lighttpd. Avant chaque restart ou reload du serveur, il fera un test de la configuration et ne redémarrera que si elle est correcte.

Voici à quoi ressemble le nouveau script d’init de lighttpd sous Debian (uniquement les cas reload et restart) :

    reload)
        log_daemon_msg "Checking $DESC configuration file"
        if $DAEMON -t $DAEMON_OPTS
        then
            log_daemon_msg "Reloading $DESC configuration" $NAME
            if start-stop-daemon --stop --signal 2 --oknodo --retry 30 --oknodo \
                --quiet --pidfile $PIDFILE --exec $DAEMON
            then
                if start-stop-daemon --start --quiet  \
                    --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
                    log_end_msg 0
                else
                    log_end_msg 1
                fi  
            else
                log_end_msg 1
            fi  
        fi  
        ;;  
    restart|force-reload)
        log_daemon_msg "Checking $DESC configuration file"
        if $DAEMON -t $DAEMON_OPTS
        then
            $0 stop
            test -r  $PIDFILE && while pidof lighttpd | \ 
            grep -q `cat $PIDFILE 2>/dev/null` 2>/dev/null ; do sleep 1; done
            $0 start
        fi  
        ;;  
    *)  
        echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
        exit 1
        ;;

Ou voici le patch (sans l’adaptation de l’indentation pour plus de lisibilité) si vous préférez :

--- lighttpd.old	2010-06-11 23:42:57.000000000 +0200
+++ /etc/init.d/lighttpd	2010-06-11 23:21:18.000000000 +0200
@@ -54,6 +54,9 @@
         fi
         ;;
     reload)
+		log_daemon_msg "Checking $DESC configuration file"
+		if $DAEMON -t $DAEMON_OPTS
+		then
 		log_daemon_msg "Reloading $DESC configuration" $NAME
 		if start-stop-daemon --stop --signal 2 --oknodo --retry 30 --oknodo \
 			--quiet --pidfile $PIDFILE --exec $DAEMON
@@ -67,12 +70,17 @@
 		else
 			log_end_msg 1
 		fi
+		fi
         ;;
     restart|force-reload)
+		log_daemon_msg "Checking $DESC configuration file"
+		if $DAEMON -t $DAEMON_OPTS
+		then
 		$0 stop
 		test -r  $PIDFILE && while pidof lighttpd | \
 		grep -q `cat $PIDFILE 2>/dev/null` 2>/dev/null ; do sleep 1; done
 		$0 start
+		fi
         ;;
     *)
         echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2

Vous trouvez votre serveur web lent, votre site comporte beaucoup de PHP ? Alors voici la solution qu’il vous faut : un cache opcode PHP. Plusieurs caches opcodes (aussi appelés accélérateurs PHP) existent, comme Eaccelerator, phpa… mais j’ai choisi Xcache, qui à l’avantage d’être stable et de supporter les dernières versions de PHP.

Comment cela fonctionne ?

Expliqué rapidement, le cache permet de garder en mémoire une version précompilé (appelé opcode) du code PHP. Ansi, on économise toute la phase d’interprétation du code php dès la seconde requête sur une page PHP, le module PHP ira chercher directement la page précompilée en mémoire et l’exécutera.

C’est efficace ?

Carrément ! Il est actuellement en place sur mon serveur, et les pages WordPress (donc énormément de PHP dedans) s’affichent beaucoup plus rapidement qu’avant. La charge CPU est également moins importante, ce qui permet de servir plus de requêtes par seconde. Malheureusement, je n’ai pas eu le temps de faire des benchs, mais vous pouvez jeter un œil ici, ou les faire vous même avec un Apache Bench ou un Siege.

En moyenne, d’après ce que j’ai trouvé sur Internet, le gain est environ de 3 (les pages s’affichent 3 fois plus vite). Mais il n’est pas rare d’avoir des gains bien meilleur, cela dépend aussi de l’application php exécutée (Moteurs de blogs, CMS, frameworks divers…).

Passons à la configuration

Xcache se trouve dans les dépôts Debian Lenny :

apt-get install php5-xcache

Xcache se charge en tant qu’extension PHP, vous trouverez donc sa configuration dans /etc/php5/conf.d/xcache.ini.
Les directives que vous avez intérêt à modifier son :

• xcache.size : la taille totale du cache. Plus celle ci est grande, plus Xcache pourra garder de page précompilée. Personnellement, je l’ai mis à 128 Mo, ayant 2 Go de RAM, c’est très largement suffisant pour un WordPress plus un RoundCube plus un DokuWiki. Il faut voir à l’usage ;
• xcache.count : en combien de morceaux la mémoire réservée au cache doit être divisée. C’est utile pour les processeurs multicores. Les développeurs de Xcache recommandent de mettre cette valeur à (Nb de processeurs)+1 ;
• xcache.ttl : le durée de vie des pages en cache. S’il n’y a pas foule sur votre site, je vous conseille de la mettre à 0 (durée de vie infinie), ou au pire à une très grande valeur, pour éviter de régénérer les pages cachées trop souvent.

Pour les autres directives, je vous laisse lire le wiki de Xcache.

Xcache dispose d’une interface web permettant de voir diverses statistiques (taux de remplissage du cache, fichiers cachés, etc…).
Son activation se fait dans le même fichier de configuration, en définissant les directives xcache.admin.user et xcache.admin.pass (attention, mot de passe à mettre hashé en md5).
Vous devez ensuite créer un alias dans la configuration de votre serveur web :

• Pour Lighttpd :

  alias.url += ( "/xcache-admin" => "/usr/share/xcache/admin/" )

• Pour Apache :

  Alias /xcache-admin /usr/share/xcache/admin

Aperçu de l’interface web

Taux de remplissage du cache

Liste des pages cachées

RoundCube est un webmail écrit en PHP, simple à prendre en main, beau, et surtout, il permet l’ajout de plugins.

Je ne vais pas faire de tuto sur son installation, elle me parait simple et bien documentée. Par contre je vais vous présenter une sélection de plugins que j’ai testé et que j’utilise, car il est toujours fastidieux de chercher un plugin, l’installer, le tester, s’apercevoir qu’il ne nous satisfait pas vraiment, le désinstaller, en chercher un autre, etc…

Installation d’un plugin

Un petit rappel avant d’aller plus loin sur l’installation des plugins sous RoundCube. L’installation se fait à la mano, en suivant cet ordre :
(NOTE : les chemins sont donnés en relatif à partir de votre répertoire d’installation de RoundCube (dans mon cas /var/www/webmail/))

• Téléchargez, puis décompressez le plugin en question sur votre machine. Vous obtenez un répertoire du même nom que le plugin, qu’il faudra déplacer dans le dossier plugins/ de RoundCube.
• Certains plugins ont un répertoire config/ avec un (ou plusieurs) fichiers nommés *.inc.php.dist. Vous devez les renommer en *.inc.php, et, si vous le souhaitez, modifier les valeurs de configuration à l’intérieur.
• Une fois le plugin configuré, il ne vous reste plus qu’à l’activer dans RoundCube. Pour cela, rajoutez son nom dans le tableau $rcmail_config['plugins'] du fichier config/main.inc.php de RoundCube :

  $rcmail_config['plugins'] = array('plugin1', 'plugin2', 'plugin3'); // etc…

• Vous pouvez recharger la page dans votre navigateur et vous verrez votre nouveau plugin. Si ce n’est pas le cas, jetez un œil dans les logs de RoundCube (fichier logs/errors), voir carrément ceux de votre serveur web.

6 plugins pour votre webmail

ManageSieve

LE plugin à avoir si votre serveur IMAP gère les filtres Sieve !
Il vous permet de créer facilement vos filtres à l’aide de listes déroulantes et de champs à remplir (voir les screenshots).

Le plugin crée un nouvel onglet « Filtres » dans la catégorie « Préférences » de RoundCube.

Téléchargement : Le plugin est déjà présent dans le répertoire plugins/, vous n’avez qu’à l’activer.

À noter qu’il existe un autre plugin pour gérer ses filtres Sieve, mais que je n’ai pas testé, nommé SieveRules.

ContextMenu

Un plugin tout simple qui affiche un menu contextuel lors d’un clic droit sur :

• un mail dans la liste de mail (actions possibles : marquer le message, répondre, transférer, déplacer vers…)
• un dossier (actions possibles : marquer le contenu, compacter, vider…)
• un contact dans le carnet d’adresse (actions possibles : écrire au contact, le modifier, le supprimer…)

Téléchargement : lien.

Automatic adressbook

Un plugin très pratique qui permet la complétion du champ d’adresse avec les adresses mail que vous avez déjà saisies. RoundCube est capable de compléter les adresses en cours de saisies dans le champ d’adresse en fonction de celles ajoutées à son carnet d’adresse. L’idée du plugin est donc de créer un second carnet d’adresse dans une table de la base de donnée dans lequel il ajoute automatiquement toutes les adresses que vous écrivez. Ainsi, RoundCube pourra s’en servir lors de la complétion, sans pour autant avoir une quantité monstrueuse d’adresses dans votre carnet d’adresses principal.

L’installation se déroule de la même manière que les précédentes, à la différence près que vous devez créer une nouvelle table pour le plugin. Heureusement, des scripts sont disponibles pour les bases MySQL, PostgreSQL, SQLite et MicrosoftSQL.
Exécution du script pour une base MySQL :

mysql -u $USER -p $TABLE < plugins/automatic_addressbook/SQL/mysql.initial.sql

Ensuite, il faut que vous activiez la fonctionnalité en allant dans "Préférence" > Section "Écriture des messages" et cocher la case "Utilisez le carnet d'adresse automatique".

À noter que l'auto-complétion de RoundCube est assez évoluée puisque il ne considère pas les premières lettres que vous tapez comme étant effectivement les premières lettre de l'adresse, mais comme pouvant se trouver n'importe où dans l'adresse (pratique pour rechercher suivant le nom de la personne et pas suivant son adresse mail).

Téléchargement : lien.

Forward as attachment

Ce plugin rajoute une fonction qui manque cruellement à RoundCube, la possibilité de transmettre un message en tant que pièce jointe.

Pour l'installation, comme indiqué dans le fichier forward_as_attachment.php du plugin, vous devez rajouter la balise suivante dans les fichiers skins/votre-thème/templates/{mail,message}.html :

<roundcube :container name="forwardatt" id="forwardatt" />

Vous pouvez choisir son emplacement, mais logiquement elle se place après la balise du bouton forward

<roundcube :button command="forward" type="link" ... />

Téléchargement : ce plugin fait partie d'un méta-paquet de plugins distribué sous le nom de MyRoundCube, et disponible ici.

Calendar

Comme vous vous en doutez, Calendar un plugin pour ajouter un calendrier. Il n'est pour l'instant qu'en version beta et ne dispose donc pas de beaucoup de fonctionnalités. Cependant, il a l'avantage d'être simple à utiliser.

Avant d'aller plus loin, sachez qu'il existe un autre plugin, webcalendar, que vous trouverez dans le paquet MyRoundCube et qui se charge d'intégrer au webmail ce calendrier, beaucoup plus complet mais assez déroutant à utiliser (je trouve).

Pour revenir au premier plugin, Calendar, voici ses principales fonctionnalités :

• Affichage en jours, semaines ou mois
• Possibilité d'ajouter des évènements associés à une heure du jour ou pas (dans ce cas ils seront affichés en tête de la colonne
• Possibilité de déplacer et redimensionner les évènements directement dans l'affichage du calendrier (par glissé déposé)
• Possibilité d'exporter le calendrier au format ICS
• Association d'un évènement à une catégorie (les catégories sont pour l'instant à définir dans le fichier de configuration, et communes à chaque utilisateur). Chaque évènement est alors représenté avec la couleur de sa catégorie

Pour l'installation, vous devez avant tout créer une nouvelle table dans la base de donnée de votre webmail. Un script pour MySQL est fournit dans le répertoire SQL/. La suite de l'installation ne change pas des autres plugins…

Vous devez également changer une ligne dans le fichier calendar.php, suite à un petit bug de chemin.

Remplacez (l. 23) :

if(file_exists("./plugins/calendar/config.inc.php")) {

par :

if(file_exists("./plugins/calendar/config/config.inc.php")) {

Téléchargement : lien

Template_objects

Ce plugin modifie quelques objets propres à RoundCube et permet, entre autre, l'ajout d'un filtre d'affichage. On peut ainsi n'afficher que les mails non lus, marqués comme importants, auxquels on a pas répondus…

Téléchargement : ce plugin fait partie d'un méta-paquet de plugins distribué sous le nom de MyRoundCube, et disponible ici.

Et encore…

Il est évident que je n'ai pas listé ici tous les plugins, mais uniquement ceux dont je me sert. D'autres mériteraient également d'avoir une place ici, comme DKIMStatus ou encore des plugins orientés gestion des spams. J'en reparlerai sûrement quand j'aborderai ces sujets.

En attendant, pour découvrir d'autres plugins, je vous invite à suivre ces 2 liens :

• Liste de plugins sur le wiki de RoundCube
• Projet MyRoundCube

Dans un précédent article, j’avais parlé de corkscrew. Le but était de pouvoir se connecter en SSH sur son serveur en étant derrière un proxy, en utilisant le port 443 (réservé au HTTPS).
Mais il y avais quand même un gros inconvénient à cette technique : coté serveur, le serveur SSH occupait le port 443, ce qui empêchait toute utilisation de HTTPS par le serveur web

Mais bien sûr, il est possible de résoudre ce problème : vous devez choisir entre HTTP+SSL et SSH ? choisissez SSLH

Principe de fonctionnement

SSLH est un multiplexeur de port : c’est un démon qui écoute sur le port 443 du serveur, et en fonction des paquets qu’il reçoit ou pas, il les transmettra soit au serveur web qui n’écoutera plus que sur l’interface locale, soit au serveur SSH qui sera sur un port différent.
Voici un petit schéma explicatif :

Schéma de fonctionnement de SSLH

La question qui vient juste après est : mais comment fait-il pour différencier les paquets SSH des paquets HTTPS. Effectivement, les deux sont chiffrés et il ne doit pas pouvoir les déchiffrer.
En fait, c’est tout simple : un client HTTPS (donc un navigateur web typiquement) commence à parler le premier (par exemple pour faire un GET sur une page web) alors qu’un client SSH attend une réponse du serveur (l’envoi d’une bannière).
Ainsi, SSLH attend un certain moment (par défaut 2 secondes) que le client envoi un paquet. Si il en a envoyé, c’était alors une connexion HTTPS, sinon c’était du SSH.

Installation et Configuration

Un peu d’apt-pinning

Malheureusement, SSLH n’est pas présent dans les dépôts stable de Debian, mais on le trouve dans les dépôts testing. Un apt-get install ne suffit plus, mais ce n’est guère plus compliqué.

Premièrement, nous allons ajouter le dépôt testing à notre sources.list :

vim /etc/apt/sources.list

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free

Ensuite, comme on ne veut pas mettre à jour tout le système vers la testing (ce qui serait le cas si vous faites un apt-get update puis upgrade), il faut définir des priorités (c’est de l’apt-pinning) :
Si vous faites un

apt-cache policy

vous verrez les dépôts ainsi que leur priorité :

...
 500 http://debian.mines.inpl-nancy.fr lenny/main Packages
     release v=5.0.4,o=Debian,a=stable,l=Debian,c=main
     origin debian.mines.inpl-nancy.fr
...

Il faut donc s’arranger pour que les dépôts testing soient utilisés seulement si le paquet n’est pas présent dans les dépôts stable, donc leur définir une priorité plus faible.
Cela ce fait dans le fichier /etc/apt/preferences (créez le si il n’existe pas) :

vim /etc/apt/preferences

Ajoutez y ceci :

Package: sslh
Pin: release a=testing
Pin-Priority: 600
 
Package: *
Pin: release a=testing
Pin-Priority: 1

Un nouveau apt-cache policy doit vous indiquer que le dépôt testing a maintenant une priorité de 1 (la plus basse).
Vous pouvez maintenant installer le paquet sslh, après avoir rechargé la liste des paquets :

apt-get install sslh

Configuration

On va commencer par s’occuper du serveur web (ici Lighttpd, mais la procédure est la même pour n’importe quel serveur web). Éditez le fichier de configuration de SSL pour n’écouter plus que sur l’IP locale (127.0.0.1) :

vim /etc/lighttpd/conf-available/10-ssl.conf

Remplacez la ligne

$SERVER["socket"] == ":443"

par celle-ci :

$SERVER["socket"] == "127.0.0.1:443"

Enregistrez et redémarrez lighty.

Vérifiez que lighty n’écoute que sur localhost, avec un

netstat -atn |grep 443

Vous devriez voir une ligne du type

tcp        0      0 127.0.0.1:443           0.0.0.0:*               LISTEN

Une fois ceci fait, allez dans la configuration de SSLH pour l’activer :

vim /etc/default/sslh

Rajouter à la fin

RUN=yes

comme indiqué et changez éventuellement le port de votre serveur SSH si celui-ci n’écoute pas sur le 22.
Vous devez également changer l’IP 0.0.0.0 par celle de votre serveur (192.168.0.10 par exemple)

Enfin, démarrez le démon SSLH et vous aurez la joie de profiter à la fois du HTTPS et du SSH dernière les proxy sur le même serveur

Cet article fait parti d’une longue série d’articles sur la configuration d’un home serveur. Tous les articles de cette série sont disponibles dans la catégorie « Configuration d’un home serveur ».

Ça faisait un moment que je ne m’étais plus occupé du serveur. Il faut dire qu’en ce moment je suis pas mal pris entre les études et…
Bon j’évite de raconter ma vie et je passe aux choses sérieuses.

Aujourd’hui, pas de gros tutoriels en vue, mais quelques petites astuces pour vous simplifier la vie.

apticron, où comment être prévenu d’une mise à jour

Le problème : comment savoir si il y a des mises à jour à faire sur le serveur ?
Deux solutions :

• Soit vous vous connectez régulièrement sur le serveur et faites un

  sudo apt-get update && sudo apt-get upgrade

  C’est pas très marrant et je doute que vous y pensez chaque matin en vous réveillant ;

• Soit vous utilisez apticron .

Apticron est en fait un script bash qui est appelé régulièrement par cron (par défaut tous les jours à 22h11). Il vérifie si il y a des mises à jour (par un simple apt-get dist-upgrade) et envoi son rapport par mail à root.

Pour l’installer, comme d’hab’ :

 sudo apt-get install apticron

Ensuite vous pouvez changer l’heure et la périodicité d’exécution du script :

sudo vim /etc/cron.d/apticron

Je vous conseille le mettre vers les 06h (au lieu des 22h), car c’est là où il y a très peu d’activité (du moins pour un serveur web).

Vous pouvez également changer l’adresse email de destination (directive « EMAIL ») dans le fichier /etc/apticron/apticron.conf, ainsi que diverses options.

Si mises à jour il y a, vous recevrez un mail listant les paquets à mettre à jour, ainsi que les changelogs de chaque paquet :

Aperçu d'un rapport apticron envoyé par mail

Synchronisation automatique de l’heure

Un serveur à l’heure est important, ne serait ce que pour les logs. Malheureusement, l’horloge des cartes mère à tendance à avancer/retarder au fil du temps. Vous pouvez alors vous synchroniser à des serveurs de temps via NTP (Network Time Protocol).

Il vous suffit d’installer ntp, un démon qui va synchroniser régulièrement l’heure système à un ou plusieurs serveurs de temps.

sudo apt-get install ntp

Le démon fonctionne dès l’installation, vous pouvez changer les serveurs de temps et d’autres options de configuration dans le fichier /etc/ntp.conf.

Attention quand même : Lors de la première synchro, mon heure système avançait d’un peu plus de 39 secondes (J’ai trouvé ça beaucoup d’ailleurs). Le changement d’heure brutal peut ne pas plaire à tous le monde (notamment à dovecot et postfix). Pensez à regarder les logs !

tail /var/log/syslog

Jan 10 15:50:15 heimdall ntpd[7605]: kernel time sync status 0040
Jan 10 15:50:23 heimdall ntpd[7605]: synchronized to 91.121.121.160, stratum 2
Jan 10 15:49:43 heimdall ntpd[7605]: time reset -39.551643 s
Jan 10 15:49:44 heimdall dovecot: Time just moved backwards by 39 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jan 10 15:51:12 heimdall postfix/smtpd[7616]: warning: SASL: Connect to private/auth failed: Connection refused
Jan 10 15:51:12 heimdall postfix/smtpd[7616]: fatal: no SASL authentication mechanisms
Jan 10 15:51:13 heimdall postfix/master[6285]: warning: process /usr/lib/postfix/smtpd pid 7616 exit status 1

En général, il suffit de les redémarrer :

sudo /etc/init.d/dovecot restart

sudo /etc/init.d/postfix restart

Pour voir l’heure système :

date

Cet article fait parti d’une longue série d’article sur la configuration d’un home serveur. Tous les articles de cette série sont disponibles dans la catégorie « Configuration d’un home serveur ».

Enfin le serveur web .

J’ai choisi d’utiliser lighttpd (prononcez lighty, c’est plus simple). Il est moins gourmand qu’Apache en terme d’utilisation mémoire et de charge CPU, tout en étant aussi performant et sécurisé bien sûr, donc parfait pour notre petit serveur. Par contre, il est moins complet qu’Apache : par exemple, il ne supporte pas les fichiers .htaccess, il faut tout définir dans le fichier de configuration général.

Installation

La présentation étant faite, vous pouvez commencer à installer le paquet :

sudo apt-get install lighttpd

Voilà votre serveur web fonctionne déjà ! Mais nous n’allons pas nous arrêter là, c’est pas intéressant quand tous marche du premier coup .

Quelques optimisations

En fonction du système utilisé :

Si vous avez un noyau Linux 2.6 (dans 99% des cas), rajoutez ces 2 lignes dans le fichier /etc/lighttpd/lighttpd.conf :

server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

Sinon, allez voir la doc pour savoir quelles valeurs mettre

Compression :

Si ce module est activé, et si le navigateur du client le supporte, les données envoyées seront compressées pour réduire l’utilisation de la bande passante. Ça peut être intéressant pour un home serveur, puisque les FAI fournissent en général une bande passante en upload minable.

Vérifiez qu’il est bien chargé (à priori il l’est) :

server.modules = (
        ...
        "mod_compress",
        ...
)

PHP & MySQL

Tout dépend de ce que vous voulez mettre sur votre serveur, mais vous aurez très probablement besoin de PHP et MySQL.

Pour les installer :

sudo apt-get install php5-cgi php5-mysql mysql-serveur-5.0

Configuration de PHP :

D’abord, il faut activer le module dans votre lighttpd.conf, comme ceci :

server.modules = (
        ...
        "mod_fastcgi"
)

Puis définir quelques chemins :

fastcgi.server  = ( ".php" => ((
        "bin-path"  => "/usr/bin/php5-cgi",
        "socket"    => "/var/run/lighttpd/php-fastcgi.socket"
)))

Ensuite, je vous conseille d’aller faire un petit tour dans le fichier /etc/php5/cgi/php.ini. C’est le fichier de configuration géréral de php, et il y a de quoi faire si vous voulez augmenter un peu la sécurité de votre serveur. System-linux a fait un très bon article dessus, j’en ferai peut être un si je trouve des trucs à rajouter.

Configuration de MySQL :

Normalement, lors de l’installation vous avez dû entrer un mot de passe root pour la base. Si ce n’est pas le cas :

sudo dpkg-reconfigure mysql-serveur-5.0

Votre base est prête à l’emploi. Comme pour PHP, on reviendra peut être dessus pour l’optimiser et la sécuriser un peu mieux.

Un groupe webadmin

Un petit truc pratique pour pouvoir gérer votre site correctement sans être root. Rappelez vous, on avait créé un groupe sysadmin, pour avoir le droit d’utiliser sudo. Maintenant, on va créer un groupe webadmin, qui aura tous les droits dans le répertoire /var/www :

sudo addgroup webadmin

sudo chgrp -R webadmin /var/www

sudo chmod g+ws -R /var/www

Enfin, vous pouvez vous ajouter au groupe :

sudo votre-login webadmin

Ouverture dans le pare feu

Quand vous serez près à ouvrir votre site au monde entier ( ), ouvrez le port 80 sur votre routeur et dans le script d’iptables.

Pour fail2ban, il ne gère pas nativement lighttpd. Mais ce n’est pas grave, un certain Buanzo a déjà écrit la regexp qui faut. Téléchargez le fichier puis placez le dans /etc/fail2ban/filter.d/.
Ensuite, éditez le fichier /etc/fail2ban/jail.conf pour y mettre ceci :

[lighttpd-fastcgi]
 
enabled = true
port    = http,https
filter  = lighttpd-fastcgi
logpath = /var/log/lighttpd/error.log
maxretry = 6

Et relancez votre pare feu bien sûr.

Voila pour le serveur web. Suivant, ce que j’aurai fait sur mon serveur je ferai sûrement des tutos pour la gestion du https, de l’URL rewriting (pour WordPress par exemple), l’utilisation de Xcache (pour éviter de ré exécuter le php des pages à chaque requêtes), l’installation d’un webmail (si ce n’est pas aussi simple qu’un WordPress), etc…

Donc ce n’est pas fini !

Cet article fait parti d’une longue série d’article sur la configuration d’un home serveur. Tous les articles de cette série sont disponible dans la catégorie « Configuration d’un home serveur ».

Maintenant que vous gérez votre serveur mail, c’est vous qui en êtes responsable. Autrement dit, si vous perdez vos mails vous ne pourrez vous en prendre qu’à vous. Personnellement je vois ça comme un avantage, mais vous le prenez comme vous voulez, toujours est-il qu’il vaut mieux penser à faire des sauvegardes régulières des maildirs.

Bonne nouvelle pour vous, j’ai réalisé un script qui s’occupe de cette tâche. Il est en Perl et sous licence GNU GPL (ça va de soit ).
C’est ici pour le télécharger.

Vu que je l’ai fait surtout pour répondre à mon cas à moi, il se peut qu’il ne vous convienne pas. Si vous le modifiez, n’hésitez pas à me dire ce que vous avez amélioré d’ailleurs. Vous pouvez aussi me proposer certaines idées à rajouter, j’essaierai de les ajouter dans la limite de mon temps libre.

Une petite présentation rapide du script

Voici, ce qu’il fait :

• Il récupère la liste des utilisateurs ainsi que leur home depuis le fichier /etc/passwd.
• Il arrête les services postfix et dovecot (pour éviter que l’un deux écrive dans la maildir alors qu’on est en train de la sauvegarder).
• Pour chaque utilisateur, il fait appel à rsync (donc ne copie que ce qui a été ajouté ou modifié) pour sauvegarder sa maildir vers un dossier local.
• Il redémarre postfix et dovecot une fois la copie terminée.
• Si un périphérique externe est présent (clé/disque USB, montage NFS, …) il fait de nouveau un rsync depuis les maildirs copiées localement vers le périphérique externe spécifié.
• Éventuellement, démontage du périphérique si il était démonté avant l’exécution.

Déjà, une petite explication sur le double rsync, qui peut paraître lourd. Effectivement, pourquoi ne pas sauvegarder directement la maildirs vers le périphérique externe ?
Plusieurs raisons :

• D’abord, comme Postfix est arrêté pendant la copie, il faut éviter qu’il le soit trop longtemps ; si vous n’avez pas de chance et qu’un serveur smtp essaye de contacter le votre pour lui envoyer un mail, personne ne répondra (bon normalement, il réessayera plus tard mais bon on sait jamais). Donc la manière la plus rapide de copier la maildir et encore de la copier sur le disque dur lui même. Ensuite on aura tout le temps pour la copier ailleurs.
• Deuxièmement, la copie d’un endroit à l’autre du disque est ce qu’il y a de plus sûr. Imaginez que votre script s’exécute la nuit et que, pas de chance, la veille vous aviez retiré la clé USB pour vous en servir et ne l’aviez pas rebranché (la fatigue, toussa…). Ou alors que le serveur de fichier sur lequel vous copiez habituellement vos sauvegardes ne répond pas par exemple. À ce moment là, vous êtes bien content d’avoir quand même une copie sur le disque dur qui s’est faite.
• Et puis imaginez que ce n’est pas le disque qui lâche, mais juste que vous avez fait une fausse manip ou un bug de dovecot ou votre client mail. Le fait d’avoir une copie en local accélérera beaucoup la récupération, que de devoir allez chercher le tout depuis un autre endroit.

Ensuite, vous constaterez qu’au début du script, vous avez la possibilité de définir pas mal de truc : les répertoires de sauvegarde local et distant, le périphérique à utiliser, les options à passer à rsync (que ce soit pour la copie locale ou distante, …).

À noter quand même : je me suis aperçu que peu de systèmes de fichier n’apprécient le noms des fichiers des maildirs (du style 1257622696.P32064Q174M509794.heimdall:2,S), à commencer par le FAT. Donc pensez, si vous utilisez une clé USB à la passer en ext2 par exemple. Sinon, une autre solution peut être d’utiliser tar -u. Ainsi tar va archiver tous les fichiers en un seul (donc plus de problème avec les noms de fichier) et -u (pour –update) va mettre à jour l’archive avec les fichiers modifiés ou ajoutés (un peu comme rsync).

Ajout du script à cron

Pour pouvoir l’exécuter périodiquement, vous allez faire appel à cron. Placez le script dans /etc/cron.daily, /etc/cron.weekly, … ou modifiez la crontab si aucun ne vous conviennent (au choix, c’est vous qui voyez).

sudo mv backup.pl /etc/cron.daily/backup

(Attention à bien enlever le .pl, sinon le cron n’exécutera pas le script)
Rendez le bien sûr exécutable, et c’est terminé :

sudo chmod +x /etc/cron.daily/backup.pl

Vous recevrez alors un mail à chaque fois qu’il sera exécuté. Si ça vous embête, rajoutez

MAILTO=/dev/null

dans le fichier /etc/crontab.

Voila, pour la prochaine fois, je pense qu’on attaquera le serveur web (j’hésite encore sur celui que je vais choisir, même si je penche sur Lighttpd). Mais on reviendra sur le serveur mail pour l’antispam et le webmail.

Cet article fait parti d’une longue série d’article sur la configuration d’un home serveur. Tous les articles de cette série sont disponible dans la catégorie « Configuration d’un home serveur ».

Maintenant que vous avez un beau serveur mail tout neuf, vous pouvez rapatrier le courrier de vos différents comptes dessus. Certains fournisseurs de services comme Gmail vous permettent de rediriger votre courrier vers une autre boite mail, mais ce n’est pas le cas de tous. Dans ce cas c’est à votre serveur d’aller récupérer le courrier.

C’est très simple à faire grâce à fetchmail, un petit utilitaire qui va se connecter périodiquement au(x) serveur(s) que vous voulez pour vous ramener le courrier (comme n’importe quel client mail en fait).

Commencez donc par l’installer :

sudo apt-get install fetchmail

Maintenant vous devez créer un fichier .fetchmailrc dans le home de chacun des utilisateurs qui ont besoin de récupérer leurs mails venant d’autres serveurs. Ce fichier décrira à fetchmail les comptes à surveiller. Vous pouvez d’ailleurs l’écrire un peu comme vous voulez, fetchmail a une syntaxe très laxiste. Vous pouvez par exemple écrire :

poll pops.mailoo.org protocol pop3 username "xx@mailoo.org" password "xx"

ou bien :

poll pops.mailoo.org proto pop3
             user "xx@mailoo.org", with password "xx", is "romain" here;

En fait, vous pouvez mettre autant de tabulations, de retours à la ligne, de ponctuations ( « , », « ; » et « : » ), de petits mots du style « is », « with », « and », « has », « wants » et « options » que vous voulez ! Vous pouvez aussi abréger les mots clé : protocol en proto, username en user, …

Vous pouvez aussi fixer la périodicité de vérification des mails (en secondes), en mettant au début du fichier

set daemon 300

Bien sûr, d’autres options sont disponibles mais je ne les trouvent pas essentielles pour un usage basique comme ici. Vous pouvez jeter un œil sur la doc officielle.

Enfin, comme le fichier contient vos mots de passe, il est nécessaire de restreindre les droits dessus (d’ailleurs, fetchmail ne démarrera pas si vous n’avez pas mis les bons droits) :

chmod 600 .fetchmailrc

Quand tout est prêt, vous pouvez lancer le démon Fetchmail avec la commande fetchmail (sans sudo devant). Fetchmail est un processus utilisateur, par conséquant il doit être lancé par chaque utilisateur qui en a besoin. Il est possible de le lancer en tant que root (via le script /etc/init.d/fetchmail) mais cette utilisation est mal adapté pour un système multiutilisateurs car tous les comptes mail des utilisateurs doivent être regroupé dans /etc/fetchmailrc. L’administrateur a alors accès à tout les mot de passe des compte mail des utilisateur…

Bref, c’est pourquoi il est mieux (de mon point de vue bien sûr) d’utiliser le fetchmail en mode utilisateur uniquement. Le problème (il y en a quand même un), c’est que ce sont les utilisateurs qui doivent lancer manuellement leur fetchmail après chaque reboot du serveur (chose qui devrait arriver de tant en tant quand même ). Pour éviter ça, vous allez remplacer le script /etc/init.d/fetchmail par celui ci (le télécharger) :

#!/bin/sh
#
# Script d'init des démons fetchmail de chaque utilisateur
# possédant un ~/.fetchmailrc.
 
 
# Defaults
DAEMON=/usr/bin/fetchmail
OPTIONS=""
 
CONFFILE=".fetchmailrc"
PIDFILE=".fetchmail.pid"
 
function start() {
	for user in `cat /etc/passwd |grep -e ":[0-9][0-9][0-9][0-9]:" |cut -d: -f1`
	do
		if [ -e "/home/$user/$CONFFILE" ]
		then
			if [ ! -e "/home/$user/$PIDFILE" ]
			then
				echo -n "Exécution de fetchmail pour l'utilisateur $user..."
				su -c "$DAEMON $OPTION" $user
				if [ $? -eq 0 ]
				then
					echo "[OK]"
				else
					echo "[Fail]"
				fi
			else
				echo "Fetchmail s'exécute déjà pour l'utilisateur $user."
			fi
		else
			echo "Pas de configuration définit pour l'utilisateur $user."
		fi
	done
}
 
function stop() {
	for user in `cat /etc/passwd |grep -e ":[0-9][0-9][0-9][0-9]:" |cut -d: -f1`
	do
		if [ -e "/home/$user/$PIDFILE" ]
		then
			echo -n "Arrêt de fetchmail pour l'utilisateur $user..."
			kill `cat "/home/$user/$PIDFILE" |head -1`
			if [ $? -eq 0 ]
			then
				echo "[OK]"
			else
				echo "[Fail]"
			fi
		else
			echo "Fetchmail ne s'exécutait pas pour l'utilisateur $user."
		fi
	done
}
 
case "$1" in
 
	start)
		start
		;;
 
	stop)
		stop
		;;
 
	restart)
		stop
		sleep 1
		start
		;;
 
	*)
		echo "Usage: /etc/init.d/fetchmail {start|stop|restart}"
		exit 1
		;;
esac
 
exit 0

Le script que j’ai écrit se contente simplement de lancer/arrêter fetchmail pour chaque utilisateur de la machine qui ont définit un .fetchmailrc dans leur home.

Vérifiez quand même que fetchmail sera lancé au démarrage, mais à priori il l’ai :

find /etc/rc*.d -name "*fetchmail"