Last entries

Thu 23 Apr 2009

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

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