GuiGui2's thoughts

Si vous suivez les mêmes blogs qui moi, ce titre vous rappelera forcément quelquechose.

Depuis un peu plus de 2ans, j'anime le site NetBSDfr, site de nouvelles en français sur le système d'exploitation NetBSD. J'utilise ce système depuis bien plus longtemps, 4 ans au moins maintenant - la première évocation de NetBSD sur mon wiki remonte à Avril 2006. Mon activité autour de ce système est toutefois plus importante depuis la renaissance de NetBSDfr: nouvelles, stands sur des salons, conférences, pkgsrc.

Fin Novembre dernier, iMil@, en concertation 2 autres développeurs du projet, m'a fait une proposition que je ne pouvais pas refuser: devenir développeur officiel du projet NetBSD à mon tour. Après plusieurs semaines d'attente angoissée, la réponse est arrivée le 05 Janvier. J'ai dorénavant mon nom dans LA liste.

Je kiffe, là, et pas qu'un peu!
iMil, stacktic, sarah, j'vous kiffe aussi :)

Depuis un certain temps déjà (mi-2007, d'après les archives du site), je suis derrière NetBSDfr.org, le site de la communauté NetBSD francophone.
Petit à petit, ça prend. Les utilisateurs fidèles nous rejoignent - grosso modo, à chaque fois qu'on est présent sur un salon, on gagne 2 à 3 utilisateurs - et remplissent le wiki, le site et les logs du canal IRC #netbsdfr@freenode.

Depuis 6 mois environs, l'équipe derrière NetBSDfr a lancé une série d'interviews de développeurs NetBSD, "Discutons avec un développeur".

Ce billet fait suite à la publication en fin de semaine dernière de la 4ème interview de la série, celle d'Alistair G Crooks, aka Dieu, actuel président de la Fondation NetBSD, et membre de core@, l'équipe qui dirige le projet.
Cette interview a bien évidemment été publiée sur le site NetBSDfr. Mais jusqu'à maintenant, les 2 versions été publiées sur le site. Dorénavant, la version anglaise sera publiée en même temps (ou quasiment) que la version française sur le blog officiel du projet NetBSD, b.n.o.
Premier signe de reconnaissance de notre travail de promotion du projet NetBSD. C'est à la demande de Sarah, marketing@, que les interviews sont postés de cette manière, la VF sur NetBSDfr, la VO sur b.n.o.

Deuxième signe de reconnaissance, un mail d'agc@ que j'ai reçu suite à la publication des interviews, nous remerciant de notre boulot. Et venant de lui, ça m'a fait _très_ plaisir.

Enfin, l'apothéose: iMil a publié l'article sur OSNews, qui est un site à trafic bien plus important que b.n.o ou même DLFP, sur lequel on était posté les interviews jusqu'à maintenant.

Petit à petit, ça paye. Et j'avoue, je caresse doucement le rêve d'un @. Un jour ptête.

J'avais prévu, pour mon premier week-end aux US, de me rendre à Randall's Park Island, entre Brooklyn et Manhattan, au niveau de la 125ème rue, pour assister aux sets des DJs de l'ElectricZoo Festival.

Auparavant, j'étais passé chez Stef - la copine d'un pote qui vit à New-York, et qui avait proposé de m'héberger la nuit de Samedi à Dimanche, entre les 2 jours de concert - à Brooklyn, pour poser mes affaires.

Brooklyn -> Randall's Island, au bas mot, c'est 1h30 de métro, à un poil prêt.
Je suis arrivé à Grand Central vers 13h30, j'étais chez Stef à 14h30 environ. Je pose mes affaires, je discute un moment avec mon hôtesse, et je reprend le métro pour Randall's Park vers 15h30. Léger, juste mon téléphone, des sous, et mon appareil photo.

Vers 17h00, j'arrive enfin en vue en du site. La musique (enfin, surtout les basses) se fait entendre depuis un moment, m'accompagnant dans ma traversée du pont qui enjambe l'East River depuis Manhattan.
Je me pointe dans la queue pour présenter mon ticket. Le vigile à l'entrée me fait ouvrir le sac qui contient mon appareil, et me dit que je ne peux pas rentrer avec une "Professional Camera"....
Je vais causer avec le superviseur, je lui propose de balancer la carte SD, les batteries que j'avais dans le sac, histoire que je puis pas faire de photos "professionnelles". Rien à faire. Pas moyen de rentrer.

Dégouté, je reprend le métro dans l'autre sens et rentre à Brooklyn.
Dé-gou-té.
Du coup, après avoir discuté une paire d'heures avec Stef, je suis rentré direct à Poughkeepsie, étant certain de ne pas pouvoir rentrer Dimanche non plus avec ma maison sur mon dos.

Ou comment balancer 120$ par la fenêtre.
Tout ça parce que j'avais avec moi un appareil photo un peu trop gros pour les organisateurs, alors que même le plus con des téléphones portables (iPhone et co) font des photos d'aussi loin, avec un aussi gros zoom....
Bref.
Ca commence pas bien :/

Je suis abonné à un nombre croissant de liste de diffusion, notamment celles liées au projet NetBSD. Jusqu'à maintenant, j'effectuais le tri des mails côté client, grâce aux fonctionnalités de Thunderbird. Sauf que je ne relève pas mes mails toujours du même ordinateur, ce qui m'oblige à maintenir plusieurs séries de filtres dans des endroits différents. Du coup, fatalement, les filtres ne sont pas synchronisés.

Depuis un moment déjà, je voulais mettre en oeuvre les filtres côté serveur. Je m'y suis attaqué cette semaine, ce post me servira de pense-bête.

Pour filtrer des mails côté serveur, on a 2 solutions essentiellement:

• procmail
• sieve

J'ai personnellement opté pour sieve, et en particulier l'implémentation de dovecot, parce que c'est une solution plus "standardisée" que procmail. Mais jusqu'à présent, j'utilisais les serveurs de mail courier-*. Il a donc fallu commencé par migrer de courier à dovecot.

1- Installer le serveur Dovecot et le plugin pour Sieve

sudo pkg_add dovecot-1.0.15p1-postgresql dovecot-sieve-1.0.3-postgresql

2- On commence par configurer les serveurs Dovecot de telle manière qu'on puisse remplacer courier-* pour la consultation des mails. Ci dessous, le fichier dovecot.conf qui correspond à mon setup:

base_dir = /var/dovecot/
protocols = imap imaps pop3 pop3s
disable_plaintext_auth = yes
ssl_cert_file = /etc/ssl/dovecotcert.pem
ssl_key_file = /etc/ssl/private/dovecot.pem
login_dir = /var/dovecot/login
login_user = _dovecot 
mail_location = maildir:/var/spool/postfix/virtual/%d/%n
mail_privileged_group = _vmail
mmap_no_write = yes
mbox_write_locks = fcntl
protocol imap {
 imap_client_workarounds = delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep
}
protocol pop3 {
 pop3_uidl_format = %08Xu%08Xv
 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh 
}
auth default {
 mechanisms = digest-md5 cram-md5 login plain
passdb sql {
   args = /etc/dovecot-postgresql.conf
 userdb static {
   args = uid=1005 gid=1004 home=/var/spool/postfix/virtual/%d/%n allow_all_users=yes
 }
 user = root
 socket listen {
   master {
     # Master socket provides access to userdb information. It's typically
     # used to give Dovecot's local delivery agent access to userdb so it
     # can find mailbox locations.
     path = /var/run/dovecot/auth-master
     mode = 0600
     # Default user/group is the one who started dovecot-auth (root)
     user = _vmail
     #group = 
   }
   client {
     # The client socket is generally safe to export to everyone. Typical use
     # is to export it to your SMTP server so it can do SMTP AUTH lookups
     # using it.
     path = /var/spool/postfix/private/auth
     mode = 0660
     user = _postfix
     group = _postfix
   }
 }
}
dict {
}

A noter que Dovecot a besoin de 3 utilisateurs différents: root, pour le lancement du process, _dovecot, pour toutes les opérations internes au serveur, _vmail, pour l'accès au système de fichiers. Pas la peine d'essayer de ne faire qu'avec 2 utilisateurs, ça juste pamarche.

Ici, donc:

• on configure les protocoles pop3(s) et imap(s).
• on utilise des certificats x509, signés par CACert.
• l'utilisateur interne de Dovecot est _dovecot
• les mails sont stockés dans un maildir dans le répertoire /var/spool/postfix/virtual/nomdedoma.ine/user.
• on précise quelques options pour les clients IMAP ou PO3 mal gaulés
• on précise enfin comment se fait l'authentification de nos utilisateurs. En l'occurence ici, les mots de passe sont récupérés par un lookup dans une base PostgreSQL, les utilisateurs sont eux mappés sur le user _vmail:_vmail. Le allow_all_users = yes est nécessaire pour deliver.
• Enfin, on précise les emplacements des sockets client (utilisée par Postfix pour se connecter au serveur d'authentification) et "master" (utilisée plus tard par le local delivery agent de Dovecot).

3- On teste que les serveurs IMAP et POP3 fonctionnent correctement, en testant la connection au serveur en local.

4- On rajoute la configuration du Local Delivery Agent à la configuration de dovecot:

protocol lda {
  postmaster_address = postmaster@whateveryoudomainis.net
  mail_plugins = cmusieve
  mail_plugin_dir = /usr/local/lib/dovecot/lda
  auth_socket_path = /var/run/dovecot/auth-master
  log_path = /var/log/dovecot-deliver.log
  info_log_path = /var/log/dovecot-deliver.log
 }

• On précise l'adresse du postmaster
• On indique à quel endroit se trouve le binaire du plugin, puis le path vers la socket.
• Enfin, on renseigne les fichiers de logs de deliver, le lda.

5- Avant de tester le lda, il faut modifier la configuration de Postfix pour lui indiquer qu'on utilise un delivery agent externe en lieu et place du sien, avec les bons paramètres. Pour se faire, on édite le fichier /etc/postfix/master.cf, dans lequel on rajoute la ligne suivante:

dovecot   unix  -       n       n       -       -       pipe
    flags=DRhu user=_vmail:_vmail argv=/usr/local/libexec/dovecot/deliver -d ${recipient}

Là encore, inutile d'essayer de faire marcher deliver avec autre chose que le user _vmail, ça ne marche pas. deliver a besoin d'accéder au file system pour livrer les messages, il faut le lancer avec l'identité _vmail.

6- On relance postfix et Dovecot:

$ sudo postfix reload
$ sudo kill -HUP pidofdovecot

7- On surveille les logs pour vérifier que c'est bien deliver, le lda de dovecot, qui prend en charge les mails:

Sep  2 14:58:25 bsdedibox postfix/qmgr[18852]: 1CE2F5ACC4B: from=<tagadatsointsoin@fraisetaga.da>, size=2987, nrcpt=1 (queue active)
Sep  2 14:58:25 bsdedibox postfix/pipe[7446]: 1CE2F5ACC4B: to=<moi@moimeme>, relay=dovecot, delay=0.45, delays=0.4/0.01/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service)

8- Reste à mettre en place le filtre sieve, le plus simple étant de le poser dans le maildir de chacun des users. Pour se faire, on crée un fichier .dovecot.sieve dans le maildir de chacun de nos utilisateurs, contenant les règles de filtrage voulues:

% sudo cat /var/spool/postfix/virtual/guigui2.net/guigui2/.dovecot.sieve
require ["fileinto"];
if header :contains ["to", "cc"] "source-changes@NetBSD.org" {
  fileinto "NetBSD.source-changes"; stop;
}
[...]
if header :contains ["to", "cc"] "april@april.org" {
  fileinto "\[April\ -\ April\]"; stop;
}

9- Et donc, si on a rien oublié, les mails sont rangés tous seuls comme des grands dans leurs boîtes aux lettres respectives:

 deliver(moi@moimeme): Sep 02 15:00:53 Info: msgid= <20090902130039.D1736175D0@cvs.netbsd.org>: saved mail to NetBSD.source- changes 
 deliver(moi@moimeme): Sep 02 15:02:56 Info: msgid=<4A9E6CE2.2010200@valcom.com>: saved mail to NetBSD.netbsd-users 
 deliver(moi@moimeme): Sep 02 15:08:57 Info: msgid=<9efd46e20909020607i74c2c490i411668fbb98371ed@mail.gmail.com>: saved mail to [VaRouler] 
 deliver(moi@moimeme): Sep 02 15:24:35 Info: msgid=<JBSQ02D00048V020000D8Y0I081133@ev001.net>: saved mail to INBOX 

C'est pas du boulot! Ca fait .... pfiouuu... oui, au moins. Voire ptet même plus.... que j'administre une petite machine dédiée dans un Datacenter parisien. Celle sur laquelle tourne ce blog, entre autres. Et pendant tout ce temps, jamais j'ai fait un backup. Ja-mais. Oué, je sais, c'est pas du boulot.
Maintenant, sur cette boîte, tourne également un site bien plus critique à mes yeux que le bête site où je raconte ma vie: NetBSDfr. Et celui-là, quand il plante, je le sais rapidement, vu qu'il commence à avoir une audience respectable.
Donc voilà, je me suis mis en tête de mettre (enfin!) en place une politique de backup présentable.

iMil m'a envoyé un lien vers le script qu'il a mis en oeuvre pour le backup de ces environnements, que je n'ai eu qu'à adapter à mes besoins.
Ce script met en oeuvre rsync.

La machine à backuper est un OpenBSD, sur laquelle on installe donc rsync par les ports:

# pkg_add -v rsync

Le script d'iMil s'appuie sur /etc/hosts.allow et /ec/hosts.deny pour s'assurer que les IPs qui se connectent au serveur rsync sont bien autorisées à le faire. Oui mais voilà, chez SFR, j'ai une IP pas tout à fait fixe... Elle change de temps en temps, au renouvellement du bail (je suis pas certain d'avoir 2 fois de suite la même IP). Et comme j'ai pas envie de m'ennuyer avec un DynDNS, j'ai adapté le script pour faire du rsync over ssh.
Sur la box d'où on va faire le backup, on crée un user qui va être dédié au backup, et on lui crée une clé ssh qui va bien:

# useradd -m -g bkp -G users bkp
# su - bkp
~ ssh-keygen -t rsa -b 4096

La clé de notre user bkp est sauvegardée dans /home/bkp/.ssh/id_rsa.pub.

On recopie cette clé publique sur le host à backuper, dans le fichier authorized_keys, par le moyen qu'on veut. On s'assure que depuis la machine qui exécutera le script de backup, on peut se logguer en ssh (en tant que user bkp) sans password sur la box à backuper:

~ sudo su - bkp
# ssh bkp@www.icanhazback.up
$ bkp@icanhazback.up:

OK, c'est tout bon.
Le setup côté box à backuper est fini, reste le script qu'on va utiliser pour le backup, que voilà:

 zezette$ cat ./bkp.sh 
 #!/bin/sh
 # Simple rsync client script
 # if "console" is specified, verbose output and --delete are implied
 # iMil 
 # Modified GuiGui2 Aug. 18, 2009.
 RSYNC="/usr/pkg/bin/rsync"
 usage()
 {
       echo "usage: $0    "
        exit 1
 }
 if [ $# != 4 ]
 then
        usage
 fi                       
 HOST=$2
 FROM=$3
 TO=$4
 ROOT_TO="/home/bkp/backups"
 EXCLUDE="/home/bkp/rsync.exclude"
 #SECRET="/home/bkp/rsync.secret"
 USER="bkp"
 OPTIONS="--compress -a --recursive --times --perms --links"
 if [ -f ${EXCLUDE} ]; then
        OPTIONS="${OPTIONS} --exclude-from=${EXCLUDE}"
 fi
 #if [ -f ${SECRET} ]; then
 #        OPTIONS="${OPTIONS} --password-file=${SECRET}"
 #fi
 case $1 in
        console)
               CONSOLE="--verbose --progress --stats --delete"
               ;;
        cron)
               CONSOLE=""
               ;;
        *)
               usage
               ;;
 esac

 CMD="${RSYNC} ${CONSOLE} ${OPTIONS} -e ssh ${USER}@${HOST}:${FROM}  ${ROOT_TO}/${TO}"

 echo running: ${CMD}

 eval ${CMD}

On teste que tout fonctionne:

$ ./bkp.sh console www.icanhazback.up /home/bkp/manyfilestobackup files
running: /usr/pkg/bin/rsync --verbose --progress --stats --delete --compress -a --recursive --times --perms --links --exclude-from=/home/bkp/rsync.exclude -e ssh bkp@www.icanhazback.up:/home/bkp/manyfilestobackup /home/bkp/backups/files
receiving incremental file list

Number of files: 3
Number of files transferred: 0
Total file size: 19690257 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 106
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 36
Total bytes received: 127

sent 36 bytes  received 127 bytes  65.20 bytes/sec
total size is 19690257  speedup is 120799.12

Et quand tout est au poil, on cron:

0 3 * * * /home/bkp/bkp.sh cron www.icanhazback.up /var/www/htdocs/icanhazback.up www/back.up

Et voilà. Plus d'excuses :)
Cette méthode présente aussi un autre avantage.

On a possibilité de faire les backups depuis plusieurs machines. Typiquement, je pars en déplacement loin de chez moi pendant 5 semaines, je laisse pas mon serveur à la maison allumé.

Je ferai donc les backups avec mon lappy depuis mon lieu de déplacement, moyennant un peu de préparation auparavant (création du user, de la clé, et une première synchro tant qu'on est à la maison).

Oué, ben non! Vous ne trouverez finalement pas le récit de ma Grande Traversée du Massif Central. Pas le temps, plus l'envie maintenant que j'ai réalisé un album chez Photoways pour raconter mes aventures. Donc non. Pas de photos, pas de récit. J'ai les souvenirs dans ma tête :-) Désolé pour ceux qui attendait ça ici (il y en avait, d'ailleurs ? )

J'en parlais il y a longtemps sur ce blog, mais c'est maintenant une réalité. Nous sommes partis du 01er au 09 Mai pour la Grande Traversée du Massif Central, aussi connue sous le nom de GTMC.
Le programme était le suivant:

• 01 Mai: Lac de Servières -> Brion
  
• 02 Mai: Brion -> Neussargues
  
• 03 Mai: Neussargues -> Paulhac en Margeride
  
• 04 Mai: Paulhac en margeride -> Laubert
  
• 05 Mai: Laubert -> Pont de Montvert
  
• 06 Mai: Pont de Montvert -> Mas St-Chely
  
• 07 Mai: Mas St-Chely -> L'Esperou
  
• 08 Mai: L'Esperou -> Sauclières
  
• 09 Mai: Sauclières -> St Jean de Fos
  

Au programme, une 60aine de kms par jour, avec du dénivellé le plus souvent: on a quand même escaladé le Mont Mouchet, le Mont Lozère, l'Aigoual et le Pic Baudille durant la semaine :-)
En tout, environ 570km, pour pas loin de 10km de D+.

En tout cas, une magnifique aventure!

Oué, bon, je sais.

Ca fait des lustres que j'ai rien publié sur ce site, mais y'avait une bonne raison; j'avais rien à raconter.
Nouvelle année, çà veut dire nouvelles résolutions.
Pour moi, 2009, çà devrait être une grosse année vélo, avec, au programme:

• la Grande Traversée du Massif Central du 01er au 09 Mai, avec Jacques, Stan et Pascale.
• la semaine de la Méga à l'Alpe d'Huez, enchaînée avec la semaine de la Mountain of Hell aux 2 Alpes avec mes potes de Toulouse, en Juillet.
• la Maxi de Val Tho un peu plus tard - en Août - toujours avec les mêmes.
• la ronde des Lacs à Aydat début Septembre
• le Roch des Monts d'Arrée en Bretagne fin Septembre
• et pour finir, le Roc d'Azur début Octobre.

Plus de détails à venir, en particulier sur la GTMC.