Last entries

Mon 15 Jun 2009

  • David Mentré

Niadomo épisode 4 : installation du paquet dokuwiki sur une Debian Lenny

DokuWiki Dans notre projet d'auto-hébergement (cf. les précédents épisodes de la série), nous avons besoin d'un wiki pour mettre à jour nos documentations internes, le journal de bord de la machine, etc. Nous avons décidé d'installer DokuWiki, un excellent wiki en PHP, en utilisant le paquet Debian.[1]

La première partie de l'installation est simple :

 $ sudo aptitude install dokuwiki

On répond à quelques questions d'aptitude :

 Dokuwiki Emplacement Root : /notrewiki
 Select web server: Apache2
 Purging pages on removal : Non

Il est préférable de ne pas mettre dokuwiki à l'URL habituelle, histoire de déranger les script kiddies, d'où le choix de /notrewiki pour l'emplacement du wiki.

Une fois ceci fait, la configuration véritable commence, tout d'abord en re-configurant le paquet :

 $ sudo dpkg-reconfigure dokuwiki
 Dokuwiki Emplacement Root : /notrewiki
 Select web server: Apache2
 Access control : Sans restriction
 Purging pages on removal : Non

Le paquet Debian de dokuwiki a fortement modifié l'emplacement des fichiers originaux de dokuwiki, pour respecter les règles Debian et pour améliorer la sécurité du paquet.[2]

La plupart des fichiers sont maintenant installés dans /usr/share/dokuwiki/. En particulier, des informations pour configurer Apache sont disponibles dans le fichier /usr/share/dokuwiki/.htaccess.

Le fichier de configuration de dokuwiki pour Apache est /etc/dokuwiki/apache.conf. Ce fichier se retrouve également dans la configuration d'Apache, avec un lien symbolique de /etc/apache2/conf.d/apache.conf vers /etc/dokuwiki/apache.conf.

Nous éditons la configurations de ce fichier, en en faisant préalablement une copie.

 $ sudo mkdir -p /root/etc/dokuwiki/
 $ sudo cp /etc/dokuwiki/apache.conf /root/etc/dokuwiki/apache.conf.2009-06-10
 $ sudo vi /etc/dokuwiki/apache.conf

Nous ajoutons des règles permettant d'avoir des URL simples et lisibles. Le nouveau contenu ajouté provient de /usr/share/dokuwiki/.htaccess.

 RewriteEngine on
 
 RewriteRule ^_media/(.*)              lib/exe/fetch.php?media=$1  [QSA,L]
 RewriteRule ^_detail/(.*)             lib/exe/detail.php?media=$1  [QSA,L]
 RewriteRule ^_export/([^/]+)/(.*)     doku.php?do=export_$1&id=$2  [QSA,L]
 RewriteRule ^$                        doku.php  [L]
 RewriteCond %{REQUEST_FILENAME}       !-f
 RewriteCond %{REQUEST_FILENAME}       !-d
 RewriteRule (.*)                      doku.php?id=$1 [QSA,L]
 RewriteRule ^index.php$               doku.php

Nous passons ensuite à la configuration de dokuwiki proprement dit. Dans le répertoire /etc/dokuwiki/, les fichiers en *.dist sont des fichiers de référence, que l'on peut copier et éditer en une version sans le suffixe .dist pour changer la configuration.

Les fichiers suivants sont à configurer :

  • /etc/dokuwiki/acl.auth.php : les droits d'accès des utilisateurs ;
  • /etc/dokuwiki/users.auth.php : les comptes des utilisateurs du wiki ;
  • /etc/dokuwiki/local.php : notre configuration de dokuwiki. Il est recommandé de ne pas modifier /etc/dokuwki/dokuwiki.php car ce fichier pourra être modifié lors de la mise à jour du paquet.
 $ sudo cp /etc/dokuwiki/local.php.dist /root/etc/dokuwiki/local.php.2009-06-10
 $ sudo vi /etc/dokuwiki/local.php

Nous ajoutons le contenu suivant :

// Le titre du wiki affichée dans la barre de titre
 $conf['title']       = 'Notre wiki tiptop';  
 // On veut utiliser les contrôles d'accès
 $conf['useacl']      = 1; 
 // Est super-utilisateur (alias administrateur) tous les membres du groupe (le @) niadomo
 $conf['superuser']   = '@niadomo'; 
 // On ne peut pas créer de compte avec génération de mot de passe
 $conf['autopasswd']  = 0; 
 // Groupe par défaut pour les nouveaux utilisateurs : niadomo
 $conf['defaultgroup']= 'niadomo'; 
 // Actions interdites : enregistrement de nouveaux comptes et l'envoi de mots de passe par courriel
 $conf['disableactions']= 'register,resendpwd'; 
 // Le wiki est en français
 $conf['lang']= 'fr'; 
 // Le courriel de provenance des messages envoyés par le wiki
 $conf['mailfrom']= 'webmaster@niadomo.net'; 
 // Le nom de la page de démarrage[3]
 $conf['start']= 'accueil'; 
 // On n'affiche pas les messages indiquant qu'une mise à jour de sécurité est disponible.[4]
 $conf['updatecheck']= 0; 
 // On a configuré Apache pour utiliser la ré-écriture d'URL, nous permettant d'avoir des URL propres
 $conf['userewrite']= 1;

On configure ensuite les droits d'accès :

 $ sudo vi /etc/dokuwiki/acl.auth.php

Et on rajoute dans ce fichier la ligne qui interdit par défaut toute action :

 *  @ALL   0

Par défaut, personne n'a accès au wiki, il faut donc ajouter les utilisateurs à la main.

On génère l'encodage du mot de passe à utiliser dans le fichier de configuration grâce à l'utilitaire md5sum :

 $ md5sum
 toto^D^D
 totof71dbe52628a3f83a77ab494817525c6  -

La partie en gras est ce qu'on entre au clavier, la partie en italique est produite par le programme. Le mot de passe toto n'est pas terrible. Même s'il est temporaire, vous pouvez utiliser un mot de passe un peu plus sûr. ;-)

On recopie la partie après toto (71dbe52628a3f83a77ab494817525c6) dans le fichier des mots de passe de dokuwiki :

 $ sudo vi /etc/dokuwiki/users.auth.php
 user1:71dbe52628a3f83a77ab494817525c6:User1:user1@niadomo.net:niadomo

Et voilà, dokuwiki est configuré. Il ne reste plus qu'à relancer Apache et à créer les autres utilisateurs :

$ sudo invoke-rc.d apache2 reload

On accède ensuite à notre wiki à l'URL https://niadomo.net/notrewiki.

On se connecte par le bouton Connexion et on ajoute des nouveaux utilisateurs dans le panneau accessible par le bouton Admin.

 Identifiant : 	user2
 Mot de passe :  un-bon-mot-de-passe
 Nom : 	User 2
 Courriel :  user2@niadomo.net
 Groupes :  niadomo
 Notifier l'utilisateur : 	[ ] (décochée, on ne doit pas envoyer les mots de passe par email en clair)

Ne pas oublier de changer le mot de passe du premier utilisateur (user1) s'il est faible !!

Et voilà, votre wiki est configuré et vous pouvez vous empresser de mettre à jour vos documentations. ;-)

Un dernier petit truc : si vous voulez modifier la licence par défaut, vous devez modifier le fichier /usr/lib/dokuwiki/tpl/default/footer.html.

Notes

[1] Vu la complexité de l'installation et la maturité du paquet, c'est à mon avis pas super judicieux, mais je ne suis pas le seul à décider. :-)

[2] Je ne suis pas convaincu de ce dernier point.

[3] Oui, je sais, moi aussi je préférais start. ;-)

[4] Vu que la version Debian est toujours en retard et que normalement le paquet Debian doit être mis à jour en cas de faille de sécurité.

Thu 07 May 2009

  • David Mentré

Niadomo épisode 3 : installation d'un serveur web et d'un webmail

Ce billet est sous licence Art Libre 1.3.

Après le précédent épisode, nous continuons l'installation de notre serveur d'auto-hébergement. Au programme aujourd'hui :

  • un script pour enregistrer les commandes ;
  • l'installation du serveur web ;
  • l'installation d'un webmail ;
  • accéder à des applications graphiques sur le serveur.

Un ch'tit script pour enregistrer les commandes

Quand on gère à plusieurs un serveur, il est indispensable de garder une trace précise de ce que chacun fait. C'est pour cela que nous avons créé la commande nia-script, à appeler avant de faire toute manipulation sur la machine. Le principe de ce petit shell script est très simple : appeler la commande script en demandant l'enregistrement des commandes dans un fichier nommé d'après la date et l'heure courantes.

Nous créons donc le fichier /usr/local/bin/nia-script qui a le contenu suivant :

#!/bin/sh

nom=$(date +%FT%T)
chemin=/root/nia-scripts
script -t -a 2>$chemin/$nom.time $chemin/$nom.typescript

Les enregistrements de commandes sont faites dans le répertoire /root/nia-scripts/ avec des fichiers de nom du style 2009-05-05T23:14:34.typescript. Nous créons donc ce répertoire de tel sorte que son contenu soit accessible en lecture/écriture uniquement par les membres du groupe adm, c'est à dire les gentils administrateurs bénévoles que nous sommes :

 $ sudo mkdir /root/nia-scripts
 $ sudo chown root:adm /root/nia-scripts
 $ sudo chmod 770 /root/nia-scripts

Après tout ça, avoir de faire quoi que ce soit sur la machine, il suffit de faire..

 $ nia-script

...et toutes les commandes sont maintenant enregistrées.

Installation du serveur web Apache 2

apache_feather.png Pour le serveur web de notre hébergement, nous utilisons très classiquement Apache 2. Nous aurions pu utiliser un autre serveur web plus performant, mais comme nous voulons que chaque hébergé puisse relativement facilement influencer la configuration du serveur relative à son espace personnel, nous pensons que Apache avec ses .htaccess convient bien.

L'installation est on ne peut plus simple :

 $ sudo aptitude install apache2

Petit rappel de la configuration d'Apache 2 dans une Debian :

  • les fichiers qui compose le site web sont dans /var/www/, avec en particulier le fichier /var/www/index.html qui est la page web affichée par le serveur fraichement installé ;
  • les fichiers de configuration spécifique d'Apache doivent être installés dans /etc/apache2/conf.d/ ;
  • les modules disponibles sont visibles dans /etc/apache2/mods-available/ alors que les modules effectivement utilisés par le serveur sont visibles dans /etc/apache2/mods-enabled/ (par des liens symboliques sur les fichiers du répertoire mods-available/) ;
  • de manière similaire, les sites web disponibles sont visibles dans /etc/apache2/sites-available/ alors que les sites web effectivement servis par le serveur sont visibles dans /etc/apache2/sites-enabled/ (par des liens symboliques sur les fichiers du répertoire sites-available/).

Pour activer ou désactiver un module on utilise les commandes a2enmod et a2dismod. De même, pour activer ou désactiver un site on utilise les commandes a2ensite et a2dissite.

Pour améliorer la sécurité de notre serveur, nous décidons de rendre le serveur Apache moins verbeux (il ne donnera plus son numéro de version) et de désactiver certaines commandes inutiles du protocoles HTTP en utilisation courante (TRACE qui peut être utilisé pour des attaques). Pour ce faire nous éditons le fichier de config' après en avoir fait une sauvegarde préalable[1] :

 $ mkdir -p /root/etc/apache2/conf.d/
 $ cp /etc/apache2/conf.d/security /root/etc/apache2/conf.d/security.2009-05-04
 $ sudo vi /etc/apache2/conf.d/security

Et nous modifions son contenu pour avoir la configuration suivante :

 ServerTokens Prod
   :
 ServerSignature Off
   :
 TraceEnable Off

Un petit redémarrage du serveur permet de prendre en compte la configuration :

 $ sudo invoke-rc.d apache2 reload

Une hiérarchie web par utilisateur

Pour faciliter la mise à jour de contenu de nos membres auto-hébergés, nous utilisons une configuration assez classique où le contenu du répertoire ~/public_html/ de l'utilisateur toto est accessible à l'URL http://niadomo.net/~toto/.

Pour réaliser cette configuration, il suffit juste d'activer le module Apache userdir !

 $ sudo /usr/sbin/a2enmod userdir
 $ sudo invoke-rc.d apache2 restart

Et voilà ! ;-)

Serveur web accessible en connexion sécurisée HTTPS

Nous voulons pouvoir accéder de manière sécurisée à notre serveur web, en particulier pour les données sensibles comme le webmail ou les authentification. Nous utilisons pour se faire le module Apache ssl et le site web default-ssl (inactif par défaut). Nous n'avons pas le temps de configurer les redirections de HTTP vers HTTPS (pour éviter les erreurs de manipulation) donc pour l'instant notre serveur web sera accessible uniquement en HTTPS (en désactivant le site web par défaut : default).

 $ sudo /usr/sbin/a2enmod ssl
 $ sudo /usr/sbin/a2ensite default-ssl
 $ sudo /usr/sbin/a2dissite default
 $ sudo invoke-rc.d apache2 restart

Nous vérifions que notre site web est toujours accessible à l'URL https://niadomo.net.

Configuration du webmail SquirrelMail

squirrelmail_logo.png Comme webmail, nous avons décidé d'installer SquirrelMail. Nous aurions préféré RoundCube ou un autre webmail plus moderne mais RoundCube n'est pas disponible comme paquet Debian dans Lenny. Donc nous avons choisi la voie de la facilité. ;-)

L'installation est simple :

 $ sudo aptitude install squirrelmail

La configuration est tout aussi simple :

 $ sudo squirrelmail-configure

Dans le menu de configuration qui apparait, nous choisissons :

  • la configuration pré-réglée pour Dovecot, notre serveur IMAP : choix « D » puis « dovecot », puis « R » pour revenir au menu principal ;
  • nous installons les plugins suivants par le menu « Plugins » :
    • mail_fetch
    • newmail
    • filters
    • message_details
    • squirrelspell
    • calendar
    • administrator
    • spamcop
  • nous configurons pour que le logiciel soit en Français par défaut par le menu « Languages »
    • Default Language: fr_FR
    • Default charset: iso-8859-1

Pour le reste, nous conservons la configuration par défaut. Un petit « S » pour sauvegarder la configuration et « Q » pour quitter l'utilitaire squirrelmail-configure.

Pour que la traduction française fonctionne, il faut que la locale ISO-8859-1 soit disponible. Nous l'ajoutons donc à notre configuration :

 $ sudo dpkg-reconfigure locales

On a choisit d'ajouter toutes les locales françaises :

  • fr_FR
  • fr_FR.UTF-8
  • fr_FR@euro

Il faut ensuite configurer Apache pour qu'il serve maintenant le site SquirrelMail, ce qui se fait avec un simple lien :

 $ sudo ln -s /etc/squirrelmail/apache.conf /etc/apache2/squirrelmail.conf

Une dernière modification de sécurité ! Par défaut, SquirrelMail est accessible à l'URL standard http://niadomo.net/squirrelmail. Pour éviter les attaques trop aisées, nous utilisons une autre URL par défaut, par exemple « monecureuil ». Pour se faire il faut modifier le fichier de configuration Apache de SquirrelMail :

 $ sudo vi /etc/squirrelmail/apache.conf

Et y modifier la première ligne en :

 Alias /monecureuil /usr/share/squirrelmail

Un petit coup de redémarrage d'Apache ...

$ sudo invoke-rc.d apache2 restart

... et normalement notre nouveau webmail est accessible à l'URL http://niadomo.net/monecureuil.

Vérification de la configuration de SquirrelMail

La documentation de SquirrelMail[2] nous indique que l'on peut vérifier en local (c.-à-d. sur le serveur) la configuration de SquirrelMail en accédant à l'URL src/configtest.php :

 $ lynx https://127.0.0.1/monecureuil/src/configtest.php

Ce test nous indique que la configuration PHP5 magic_quotes_gpc doit être désactivée, ce que nous faisons :

 $ sudo vi /etc/php5/apache2/php.ini

Et nous modifions la ligne suivante en Off (au lieu de On) :

 magic_quotes_gpc = Off

Et voilà, nous avons maintenant un serveur web personnel et un webmail sécurisé à disposition ! Alors, c'est si difficile que ça l'auto-hébergement ? ;-)

Configuration pour utiliser une application graphique sur le serveur

Habituellement, sur un serveur, on ne met aucune application graphique et on utilise des éditeurs en mode texte comme vi ou nano pour éditer les fichiers de configuration. Quel que soit le système Unix que vous utiliserez, vous aurez toujours l'éditeur vi[3] à disposition donc il est recommandé de savoir au moins éditer trois lignes avec. ;-)

Mais bon, quand on débute, c'est parfois un peu compliqué donc voici les manipulations à faire pour pouvoir accéder à des applications graphiques (c.-à-d. utilisant le serveur X) sur votre serveur.

En premier lieu, installer le paquet xauth :

 $ sudo aptitude install xauth

Ensuite, lors de votre connexion en ssh sur le serveur, utilisez les options -X pour demander la propagation (forwarding) du terminal graphique X[4] et -C pour la compression :

 ssh -C -X toto@lumturo.niadomo.net

Et voilà, vous pouvez maintenant utiliser l'éditeur graphique qui vous convient, par exemple scite :

 $ sudo aptitude install scite
 $ sudo scite /etc/squirrelmail/apache.conf

Mais je le répète, c'est mieux d'apprendre les rudiments de vi et de se souvenir qu'il a deux modes : le mode qui bippe et le mode où l'on massacre son fichier. :-D

  • MàJ 2009-05-10: Ajout de la licence Art Libre pour ce billet.
  • MàJ 2009-08-18: correction typo.

Notes

[1] Nous utilisons pour l'instant une hiérarchie parallèle de fichiers de configuration dans /root/etc/... Une autre méthode plus robuste avec un gestionnaire de version sera utilisée par la suite.

[2] Documentation du paquet squirrelmail accessible dans /usr/share/doc/squirrelmail/README.Debian.gz.

[3] vi vient de Visual Editor. Ça peut vous surprendre mais vous n'avez jamais utilisé ed. ;-)

[4] Cela suppose que vous avez bien l'option X11Forwarding yes dans le fichier /etc/ssh/sshd_config de votre serveur.

Thu 23 Apr 2009

  • David Mentré

Niadomo deuxième épisode : première configuration d'un serveur de courriel

Ce billet est sous licence Art Libre 1.3.

Logo Lumturo - © 2009 Nono - Sous licence Art Libre Avec quelques amis, nous avons créés une association d'auto-hébergement, Niadomo. Après une première phase plus formelle où nous nous sommes regroupés pour rédiger et déposer les statuts, nous sommes passés aux choses sérieuses avec l'installation et la configuration de notre serveur. Après une après-midi de travail et d'explications, nous pouvons recevoir et envoyer des courriels par nos propres moyens ! \o/

En très simplifié, cette configuration s'est déroulée en cinq grandes phases :

  • Achat et installation d'un serveur Kimsufi sous Linux Debian ;
  • Configuration du DNS ;
  • Configuration de base du serveur : nettoyage, configuration de sécurité, ...
  • Création des comptes des membres ;
  • Configuration des services pour émettre et recevoir des courriels.

Pour faire cette installation, prévoir un vidéo-projecteur et des chouquettes.

Achat et installation du serveur Kimsufi

Nous avons acheté un serveur Kimsufi L chez OVH : 1 Go de mémoire, 250 Go de disque et un processeur récent pour environ 24 € TTC par mois.[1] Probablement l'offre la moins chère du marché.

Nous avons choisi l'installation suivante :

  • Système d'exploitation Debian Lenny 64 bits. Nous avons hésité entre 32 et 64 bits[2] et finalement choisi une 64 bits pour l'homogénéité avec nos machines de bureau[3] ;
  • Sur les 250 Go de disque, une partition unique « / » de 248,8 Go et un swap de 1,2 Go (légèrement supérieur à la mémoire).

Après environ 20-30 minutes d'installation, nous avions notre serveur prêt à l'utilisation, le mot de passe root et son adresse IP envoyés par courriel.

Dans la suite des explications, « # » désigne le prompt de root, « $ » celui d'un utilisateur normal.

Configuration du DNS[4]

On se connecte sur le Manager d'OVH et on choisit l'interface de gestion pour le nom de domaine « niadomo.net ».

On se rend sur la partie de configuration du DNS : Accueil > Mutualisé > Domaines & DNS > Zone DNS.

On supprime toutes les entrées pré-établies par OVH pour ne garder que quelques unes qui nous seront utiles :

    Champ 	 	Type 	 Cible 		
 .niadomo.net		NS 	ns13.ovh.net
 .niadomo.net		NS 	dns13.ovh.net
 .niadomo.net		MX 10 	lumturo.niadomo.net
 .niadomo.net		A 	213.251.175.16
 www.niadomo.net	A 	213.251.175.16
 lumturo.niadomo.net	A 	213.251.175.16
 imap.niadomo.net	CNAME 	lumturo.niadomo.net

Quelques explications (à compléter par les explications de Wikipédia) :

  • les deux premières lignes NS servent à indiquer quels seront les serveurs DNS pour notre domaine niadomo.net, en l'occurrence les serveurs d'OVH ;
  • la ligne MX indique que la machine lumturo.niadomo.net[5] recevra les courriels pour le domaine niadomo.net avec une priorité de 10 ;
  • les trois lignes A indiquent que les noms n.importe.quoi.niadomo.net, www.niadomo.net et lumturo.niadomo.net pointent tous sur notre serveur donné par son adresse IP ;
  • la dernière ligne CNAME indique que le nom imap.niadomo.net est un synonyme pour lumturo.niadomo.net (qui lui-même correspond à l'adresse IP de notre serveur).

Configuration reverse DNS

Tant qu'on y est, on configure le reverse DNS pour que l'adresse IP de notre serveur pointe sur le petit nom qu'on lui a choisi. Aller dans le Manager d'OVH, partie relative la configuration du serveur, dans Services > Reverse IPv4 et modifier la configuration en :

 213.251.175.16 	normal 	lumturo.niadomo.net

Configuration de base du serveur

On se connecte sur notre serveur par ssh.

 $ ssh 213.251.175.16

Première étape, changer le mot de passe root !

 # passwd

On choisit un bon mot de passe aléatoire, généré avec un petit programme C : dev-random-pass-gen.c.

Sécurisation minimale de la machine

On efface les clés SSH permettant aux administrateurs d'OVH de se connecter sur notre machine (par défaut, ils le peuvent !!) :

 # rm /root/.ssh/authorized_keys2

On efface des fichiers inutiles provenant de l'installation d'OVH :

 # rm /root/.p   # contenait le mot de passe root de l'installation !!
 # rm /root/.email

Configuration du nom de la machine

Notre machine s'appelle lumturo.niadomo.net, donc nous lui donnons ce nom :

 # vi /etc/hostname

Remplacer « ksNNNN.... » par « lumturo.niadomo.net » dans ce fichier.

On prend en compte ce nom :

 # invoke-rc.d hostname.sh restart

On configure la résolution de nom locale :

 # vi /etc/hosts

Rajouter « niadomo.lumturo.net » juste avant la ligne ksNNNNN correspondant à l'adresse IP de notre serveur (comme ça ce nom est pris en premier) :

 213.251.175.16 lumturo.niadomo.net ks34815.kimsufi.com

Au passage, on corrige un bug dans la config d'OVH en remplaçant un « o » (O) par « 0 » (zéro) sur la ligne :

 fe00::0 ip6-localnet

Configuration d'un serveur SMTP minimal pour recevoir les courriels adressés à root à l'extérieur

On installe et configure tout de suite le serveur SMTP Postfix comme ça on recevra les courriels envoyés à root lors de l'installation :

 # aptitude install postfix

On configure Postfix pour que les courriels destinés à root soient envoyés à une autre adresse de courriel :

 # vi /etc/aliases

Ajout d'une ligne :

 root: une-liste@un-autre-serveur.sur-internet.com

Régénération de la table des alias de courriels de Potsfix :

 # newaliases

De cette façon, nous recevrons tous les courriels envoyés à root sur notre liste « une-liste@un-autre-serveur.sur-internet.com », lisible par tous les membres de notre association.

On teste que tout ça marche en envoyant un email à root À niadomo.net.

Au passage, installation du paquet mailx pour avoir la commande Mail :

 # aptitude install mailx

Mise à jour de sécurité du système

La Debian installée par OVH n'est pas à jour, donc on installe les paquets nécessaires :

 # aptitude update
 # aptitude safe-upgrade
 # aptitude full-upgrade

On fait d'abord un safe-upgrade et ensuite un full-upgrade pour limiter la casse si des paquets n'ont pas été installés avec aptitude.

On installe tout de suite le paquet nécessaire pour avoir checkrestart (cf. ce précédent billet pour son utilité).

 # aptitude install debian-goodies

Installation du noyau officiel de Debian

Plutôt que le noyau Linux spécifique d'OVH, nous décidons d'utiliser le noyau officiel de Debian. Nous privilégions les choix de Debian sur ceux d'OVH (pourquoi pas) mais surtout nous éviterons des problèmes à l'avenir car le noyau Debian a été conçu pour répondre aux besoins des paquets de la distribution.

On installe d'abord GRUB :

 # aptitude install grub
 # grub-install "(hd0)"

Puis le noyau :

 # aptitude install linux-image-2.6-amd64

Et on supprime l'ancien LILO maintenant inutile (remplacé par GRUB) :

 # aptitude purge lilo

On vérifie que tout est correct en jetant un coup d'œil sur menu.lst de GRUB :

 # less /boot/grub/menu.lst

On reboot et normalement la machine revient correctement à la vie ! ;-)

 # reboot

Suite de la configuration de base

On installe un démon NTP (Network Time Protocol) pour que notre machine soit toujours à l'heure. On choisit OpenNTPD du projet OpenSSH plutôt que NTP du projet NTP car openntpd n'écoute par défaut sur aucun port, donc est plus sécurisé :

 # aptitude install openntpd

On supprime les paquets inutiles installés par OVH (oui, tout ça !) :

 # aptitude purge bind9 bind9-doc \
    dhcp3-client dhcp3-common gcc \
    gcc-4.2-base libdns43 libisc44 \
    libncurses5-dev manpages-cs \
    manpages-de manpages-de-dev \
    manpages-es manpages-es-extra \
    manpages-it manpages-pl \
    manpages-pl-dev manpages-pt manpages-pt-dev \
    manpages-ru reiserfsprogs

On reconfigure les locales pour n'utiliser que fr_FR.UTF-8 (et pas la vieille locale périmée fr_FR.ISO-8859.1@euro) :

 # dpkg-reconfigure locales

Création des comptes des membres

Chaque membre de Niadomo a un compte Unix sur la machine. Tout le monde est administrateur sur la machine, donc a les droits root.

Configuration de PAM pour sécuriser les mots de passe

PAM, Pluggable Authentication Modules, est l'infrastructure utilisée pour l'authentification dans un système Linux.

On installe un logiciel pour vérifier la qualité des mots de passe, avec le dictionnaire des mots français :

 # aptitude install libpam-cracklib wfrench

On fait en sorte que la commande su soit uniquement accessible aux comptes ayant les droits root (dans le groupe Unix root) :

 # vi /etc/pam.d/

On dé-commente la ligne :

 auth       required   pam_wheel.so

On fait en sorte que les mots de passe choisis par tout utilisateur soient un minimum complexes (c.-à-d. pas issus du dictionnaire) et distincts les uns des autres :

 # vi /etc/pam.d/common-password

On rajoute à la fin la ligne :

 password required         pam_cracklib.so retry=3 minlen=8

Création des comptes

On créé les comptes de nos utilisateurs :

 # adduser compte1
 # adduser compte2
 # adduser compte3
  :

On met chaque utilisateur dans le groupe root (pour qu'il puisse accéder aux commandes d'administration) et adm pour pouvoir par exemple lire les fichiers de log :

 # adduser compte1 root
 # adduser compte1 adm
 # adduser compte2 root
 # adduser compte2 adm
  :

Configuration de sudo

On a choisi d'utiliser la commande sudo avec mot de passe pour exécuter toutes les commandes à faire en tant que root. Cela a plusieurs avantages :

  • on log toutes les actions dans le fichier /var/log/auth.log pour une meilleur traçabilité ;
  • à terme on désactivera le login en root par ssh donc cela obligera, pour exécuter une commande root, à se connecter en tant qu'utilisateur normal puis à lancer sudo avec son mot de passe, ce qui améliore la sécurité.[6]

Installation de sudo :

 # aptitude install sudo

Configuration de sudo :

 # visudo

Ajout de la ligne :

 %root ALL=(ALL) PASSWD: ALL

Tous les membres du groupe Unix root pourront effectuer toutes les commandes en root, après avoir tapé leur mot de passe.

Configuration des courriels

On configure notre serveur de courriel pour pouvoir lire nos courriels avec le protocole IMAP (Internet Message Access Protocol) au travers d'une connexion sécurisée par TLS (Transport Layer Security). Cette configuration est supportée par la quasi-totalité des lecteurs de courriels. Nous utilisons le programme Dovecot comme serveur IMAP. Grâce au chiffrement et à l'authentification qu'apporte la couche TLS, on a un accès confidentiel à nos courriels sur le serveur.

Configuration de Postfix

On configure Postfix pour qu'il distribue les courriels reçus au format Maildir, un fichier par courriel dans un répertoire Maildir/ de chaque compte :

 # vi /etc/postfix/main.cf

On ajoute une ligne :

 home_mailbox = Maildir/

Installation de Dovecot

On installe Dovecot :

 # aptitude install dovecot-imapd

On configure le certificat de notre serveur IMAP. Ce certificat nous permettra de nous assurer que nous discutons bien avec notre serveur. Par rapport à la configuration Debian par défaut, on crée un certificat valable 10 ans :

 # openssl req -new -x509 -days 3652 \
     -nodes -out /etc/ssl/certs/dovecot.pem \
     -keyout /etc/ssl/private/dovecot.pem

On utilise les informations suivantes :

 Country name: FR
 State: France
 Locality:
 Organization: Niadomo
 Organisation Unit Name:
 Common name: imap.niadomo.net
 Email: postmaster À niadomo.net

On configure ensuite Dovecot pour utiliser les répertoires au format Maildir et n'accepter que IMAPS (c.-à-d. IMAP sur TLS) :

 # vi /etc/dovecot/dovecot.conf

On modifie les deux lignes :

 mail_location = maildir:~/Maildir
 protocols = imaps

On redémarre tous les démons :

 # invoke-rc.d dovecot restart
 # invoke-rc.d postfix restart

Et enfin on vérifie qu'on peut bien recevoir les courriels envoyés à compte1 À niadomo.net en se connectant avec un lecteur de courriel par IMAP sur le port 993 de imap.niadomo.net.

Pour conclure

Voilà, ça a été un peu long mais on a maintenant un serveur de courriel complet qui nous permet de recevoir nos courriels et de les organiser comme nous le voulons sur notre serveur IMAP. Pas si mal pour une première journée ! :-)

Merci à tous les membres de Niadomo, le contenu de ce billet est le leur.

Notes

[1] Pas de frais de mise en service si on prend le serveur tout de suite pour un an.

[2] Pas de réel avantage du 64 bits avec seulement 1 Go de mémoire et léger surcoût (20 à 30%) dans les caches à cause de la taille double des pointeurs et des entiers.

[3] Oui, je sais l'argument est peu convaincant. ;-)

[4] En réalité, le DNS n'a pas été configuré en une seule étape et exactement à ce moment là mais je regroupe tout par simplicité. Vous pouvez le faire tous ces réglages dès que vous avez l'adresse IP de votre serveur.

[5] Il ne nous a fallu que 1min22s pour choisir ce nom ! ;-) Pour l'explication du nom : .

[6] On améliore la sécurité en mettant des couches de défenses l'une derrière l'autre, en profondeur.

Thu 26 Mar 2009

  • David Mentré

Niadomo saison 1 : l'auto-hébergement par l'exemple. Premier épisode : les statuts

Ce billet est sous licence Art Libre 1.3.

La grande mode actuellement, c'est le Cloud Computing : on stocke nos données et calculs quelque part dans le réseau (le nuage ou cloud) et y on accède par un simple navigateur web (ou au pire un client léger). C'est très pratique, cela permet d'être nomade, mais il y a un gros problème : qui possède le nuage ?

Généralement, on utilise des sociétés privées comme Google (GMail, Bloger, Picasa), Microsoft ou Yahoo! pour héberger ses données, sociétés privées à qui on ne fait pas trop confiance. Qui dit que les administrateurs de Yahoo! ne lisent pas nos courriels ou que les administrateurs de Google ne regardent pas nos photo privées ? Pour en être vraiment sûr, il faut le faire soit-même sur une infrastructure que l'on maitrise.

C'est pour répondre à ce besoin qu'est né le projet Niadomo (« notre maison » en Esperanto) : se regrouper à quelques uns (moins d'une dizaine) pour mettre en place une solution d'auto-hébergement. Tout le monde est administrateur (root) sur la machine, on partage une infrastructure commune (gestion des courriels, serveur web, ...) et chacun a son espace privé pour son blogs, ses courriels ou autre. Il y a bien évidemment une confiance très forte entre nous.

Une autre ambition du projet, c'est de permettre à d'autres de faire de même. Donc nous allons nous efforcer de documenter notre travail, expliquer nos choix et rendre tout ceci public.

Voici donc le premier épisode de la série : les statuts de Niadomo, rédigés par Gwen et que nous avons signé le 19 mars 2009.

Pour les résumer, ce sont des statuts horizontaux[1], fortement inspirés des statuts de Gulliver et de Rhizomes, mais simplifiés (pas de distinction entre simple membre et membre du conseil d'administration) et fermés : l'entrée de nouveaux membres se fait par cooptation à l'unanimité. Nous serons en assemblée générale permanente (pour pouvoir prendre des décisions à tout moment) et nous utiliserons a priori exclusivement des logiciels libres.[2]

Dans la foulée, nous avons également enregistré le nom de domaine niadomo.net chez OVH.

Les statuts de Niadomo

Les parties notées FIXME sont à modifier pour votre propre association, ainsi qu'évidemment le nom Zeassos.

Article 1 : Dénomination

Il est fondé entre les adhérents aux présents statuts, une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901, ayant pour nom « Zeassos ».

Article 2 : Objet

Zeassos a pour objet la mise à disposition de ses membres d’un service d’auto-hébergement partagé à l’aide de logiciels libres. Un logiciel est dit libre si toute personne qui le possède a le droit :

  • de l’utiliser pour tout usage ;
  • de l’étudier ;
  • de le modifier pour tout usage ;
  • de le distribuer, modifié ou non ;
  • d’en distribuer une copie, modifiée ou non.

Article 3 : Siège social

Le siège social de l’association est indiqué dans le règlement intérieur. Il est initialement fixé au FIXME.

Article 4 : Durée

La durée de l’association est illimitée.

Article 5 : Moyens

Les ressources financières de l’association comprennent :

  • cotisations des membres ;
  • produits des activités de l’association ;
  • dons ;
  • tout autre revenu, en conformité avec la loi.

Les moyens humains comprennent le temps bénévole des membres.

Les administrateurs se réserve le droit de refuser certains revenus.

Le montant des cotisations est défini dans le règlement intérieur.

Article 6 : Composition

Sont membres de l’association les personnes physiques qui adhèrent aux présents statuts, ont versé leur cotisation annuelle et ont été cooptés par les membres à l’unanimité de l’assemblée générale permanente.

Article 7 : Perte de la qualité de membre

La qualité de membre se perd :

  • par décès ;
  • par démission écrite adressée à l’assemblée générale permanente ;
  • par exclusion prononcée par l’assemblée générale permanente pour le non respect des présents statuts ou du règlement intérieur.

Avant de prononcer une mesure d’exclusion ou de radiation, l’assemblée générale permanente exprime ses motifs au membre concerné. Elle l’invite à fournir une réponse avant la tenue de l’assemblée générale permanente statuant sur l’exclusion. L’ensemble de la procédure doit être réalisé par écrit. En cas d’exclusion, le membre concerné peut, sous dix jours, faire appel de la décision en demandant la convocation d’une assemblée générale extraordinaire.

Article 8 : Assemblée générale permanente

L’association est dirigée par l’ensemble de ses membres constitués en assemblée générale permanente. Ces derniers devront avoir rempli les formalités légales pour être administrateurs de l’association.

Les décisions sont prises à la majorité des votes exprimés si aucune autre modalité n’est précisée dans le règlement intérieur. Un membre de l’assemblée générale permanente peut donner procuration à un autre membre de l’assemblée générale permanente. Toutefois, nul ne peut être porteur de plus d’une procuration.

L’assemblée générale permanente se réunit en séance ordinaire au moins une fois par semestre. L’annonce en est faite individuellement au moins une semaine à l’avance.

Les réunions physiques de l’assemblée générale permanente sont privées. L’assemblée générale permanente peut décider de les ouvrir à des personnes non membres.

Article 9 : Mandats

Un mandat est une responsabilité confiée par l’assemblée générale permanente à un ou des membres de l’association avec leur accord. Le mandat doit être strictement défini dans son objet et sa durée. Cette durée est limitée à un an maximum.

L’assemblée générale permanente peut retirer cette responsabilité si par exemple les obligations liées au mandat n’ont pas été respectées. Toute personne peut démissionner de son mandat.

Deux mandats doivent être obligatoirement assurés : trésorier et responsable des formalités administratives. Ces deux mandats sont attribués à un ou des membres de l’assemblée générale permanente.

Article 10 : Assemblée générale annuelle

L’assemblée générale annuelle est composée de tous les membres de l’association. Un membre de l’association peut donner procuration à un autre membre. Toutefois, nul ne peut être porteur de plus d’une procuration.

L’annonce de l’assemblée générale annuelle est faite individuellement au moins deux semaines à l’avance.

L’assemblée générale annuelle vote le bilan moral et financier de l’année écoulée. Elle peut révoquer tout mandat.

Les décisions sont prises à la majorité absolue des membres présents et représentés. Les votes se font à bulletin secret si au moins un membre le demande.

Article 11 : Assemblée générale extraordinaire

L’assemblée générale extraordinaire est composée de tous les membres de l’association. Un membre de l’association peut donner procuration à un autre membre. Toutefois, nul ne peut être porteur de plus d’une procuration.

L’assemblée générale extraordinaire se réunit aussi souvent que nécessaire à la demande de l’assemblée permanente, d’au moins vingt-cinq pour cent des membres ou d’un membre faisant appel d’une décision d’exclusion. L’annonce en est faite individuellement au moins deux semaines à l’avance.

En plus des pouvoirs normaux de toute assemblée générale annuelle, l’assemblée générale extraordinaire se prononce sur les modifications statutaires, la dissolution de l’association et se prononce sur l’exclusion d’un membre suite à son appel de décision. Elle peut aussi modifier le règlement intérieur.

En cas de modifications statutaires et de dissolution de l’association, la moitié des membres de l’association devront être présents ou régulièrement représentés. Si ce quorum n’est pas atteint, une seconde assemblée générale extraordinaire est convoquée dans un délai de trois mois maximum sans condition de quorum.

Les décisions sont prises à la majorité absolue des membres présents et représentés. Les votes se font à bulletin secret si au moins un membre le demande.

Article 12 : Dissolution

En cas de dissolution prononcée par l’assemblée générale extraordinaire, celle-ci nomme un ou plusieurs liquidateurs qui seront chargés de la liquidation des biens de l’association. Leurs pouvoirs sont déterminés par l’assemblée générale extraordinaire. En aucun cas, les membres de l’association ne pourront se voir attribuer une part quelconque des biens de l’association. L’actif net subsistant sera dévolu à une ou plusieurs associations poursuivant des buts similaires et nommément désignées par l’assemblée.

Article 13 : Règlement intérieur

L’association dispose d’un règlement intérieur. Celui-ci fixe divers points non prévus dans les présents statuts. L’assemblée générale permanente peut modifier le règlement intérieur à la majorité absolue des membres de l’assemblée générale permanente.

Fait à FIXME le FIXME.

Anthony Armand - Béatrice Bétune - Charles Champion - Denis Diderot

Mises à jour :

  • 2009-03-27, ajout que nos statuts sont également inspirées de ceux de Rhizome ;
  • 2009-04-20, ajout de la licence Art Libre pour ce billet.

Notes

[1] « Tout le monde a les mêmes droits, tout le monde est président, tout le monde est responsable, tout le monde va en prison. » ;-)

[2] Étonnant non ? (à dire sur le ton de Desproges).