DAVROMANIAK
Le site de Cyril "Davromaniak" Lavier, sysadmin ascendant geek
Do I amaze you ?

mercredi 25 décembre 2013

Script de sauvegarde des mailbox pour Zimbra

Bonjour.

Depuis environ 2 semaines, j'avais un Zimbra Collaboration Suite (Open Source Edition) en test sur une VM, et parmi les tests que j'ai effectué, il y avait les sauvegardes/restauration de mails.

En cherchant sur le net, je suis tombé sur cette page du wiki de Zimbra contenant quelques scripts de sauvegarde. J'ai pris le script nommé "zimbraBackupAllAccounts.sh" (écrit par Richardson Lima), et j'ai commencé à le bidouiller pour l'adapter à mes besoins. Au final, je me suis retrouvé avec un script pas mal modifié.

Ayant finalisé ma migration vers Zimbra dans la journée d'hier, j'ai donc ajouté ce script dans la liste des actions de pré-backup effectuées par mon serveur backuppc.

Et je me suis dis que ce script pouvait être utile pour d'autres personnes. Donc j'ai créé un dépôt sur github et je lui ai donné un petit nom. Il s'appelle zimbashckup (pour Zimbra Bash Backup), vu qu'il est écrit en bash.

Le script fonctionne de façon non-interactive (afin d'être lancé en crontab ou par un système de backups) et permet de faire des sauvegardes par dossier. Ce qui est très utile quand on veut restaurer un seul dossier plutôt que toute la boite mail.

Ce script est capable de sauvegarder l'intégralité de chaque mailbox, y compris les dossiers/fichiers du porte document, les RDV du calendrier, les contacts de l'annuaire.

Cependant, quand un élément est partagé, seule la version du propriétaire est sauvegardé (c'est une limite de l'outil zmmailbox).

Pour le reste, je vous laisse lire le README qui est inclus dans le dépôt GIT (je pense qu'il est assez lisible :))..

Le dépôt GIT est dispo ici : https://github.com/davromaniak/zimbashckup

Bonne soirée !!!

mardi 27 août 2013

Imapsync

Bonjour.

Un petit billet rapide sur imapsync, un outil sympa quand on doit migrer de serveur mail en migrant aussi le format de stockage.

Cet outil a changé de licence, et il est passé payant récemment (le développeur a explicitement demandé à Debian de le retirer de ses dépôts), mais sous une licence propre au développeur (il me semble qu'il l'a créé spécialement). La licence permet de faire tout ce qu'on veut avec le code source, tant qu'on a payé les 50€ qu'il demande. Suite à ça, une personne a créé un dépôt github contenant la dernière version.

EDIT : L'auteur du logiciel, Gilles LAMIRAL a donné des précisions et des corrections dans le 1er commentaire de cet article, je vous invite donc à lire ce commentaire

Pour l'installer sous Debian Wheezy, il vous faut git et quelques libs. Cette gentille commande aptitude à lancer en root vous installe tout ce qu'il faut :) :

  • aptitude install makepasswd libmail-imapclient-perl libterm-readkey-perl git

Ensuite, pour l'installation :

  • En utilisateur non privilégié :
    • git clone https://github.com/imapsync/imapsync.git
    • cd imapsync
    • mkdir dist
    • > ./dist/path_1.558.txt
  • En root ou avec sudo :
    • make install

Ensuite, l'utilisation est simple : imapsync --host1 oldmx.domaine.tld --user1 jojothefrite@domaine.tld --password1 supermotdepassesécurisé --host2 newmx.domaine.tld --user2 jojothefrite@domaine.tld --password2 supermotdepassesécurisé

La vitesse dépend de pas mal de facteurs, mais pour ma part, ça a tourné à environ 5 messages par secondes, ce qui donne un peu moins de 8 heures pour transférer 125000 mails, sachant qu'en parallèle, on peut consulter et recevoir les nouveaux mails sur la boite de destination.

++

vendredi 16 août 2013

Utiliser xz avec logrotate

Bonjour.

XZ est un format de compression que j'apprécie fortement, notamment pour ses bons résultats sur la compression de fichiers texte. Et depuis pas mal de temps, je voulais l'utiliser avec logrotate.

Chose faite avec la configuration suivante (que j'ai mis dans le fichier /etc/logrotate.conf pour qu'elle soit utilisée pour tous les logs) :

compresscmd /usr/bin/xz
compressext .xz
uncompresscmd /usr/bin/unxz

L'option de compression par défaut est "-9" qui fonctionne aussi avec xz, donc pas besoin de la modifier.

Dans mon cas, logrotate ne traite que les fichiers de logs présents dans /var/log, donc ce petit find m'a servi à décompresser les fichiers GZIP et les recompresser au format XZ :

find /var/log -name "*.gz" | while read filename; do gunzip $filename && xz -vz9 ${filename%.gz}; done

Sous Debian, les outils qui gèrent les formats XZ (notamment xz et unxz utilisés ici) sont dispos dans le paquet xz-utils.

++

vendredi 21 septembre 2012

Inclure un fichier dans un autre en AWK

Bonjour.

Une fois n'est pas coutume, un peu d'informatique sur ce blog (ne vous inquiétez pas, ça ne durera pas longtemps, le prochain INT10 est prévu pour mercredi soir :D).

J'ai été confronté au besoin de remplacer une chaine de caractères par le contenu d'un fichier dans un fichier texte.

Exemple : je désire remplacer "##__youpi_tralala__##" par le contenu du fichier nommé "youpi_tralala".

J'ai essayé en sed, mais ça ne fonctionnait pas à tout les coups, avec sed qui voulait interpréter le contenu du fichier "youpi_tralala".

Donc j'ai sorti mes moufles et mon outil préféré (AWK).

Voici le résultat, le script include_file.awk :

{
	str=$0
	where=match(str,regexp)
	if (where) {
		while (("cat "file) | getline tstr > 0) {
			if (newstr == "") {
				newstr=tstr
			} else {
				newstr=newstr"\n"tstr
			}
		}
		close (tstr)
		sub(regexp,newstr,str)
	}
	print str
}

C'est un beau script AWK, qui s'appelle de la façon suivante : awk -v regexp="belle regexp" -v file=/chemin/vers/le/fichier/a/inclure -f include_file.awk fichier_contenant_la_regex

Je m'en sers souvent en LaTeX pour débugguer certains include un peu farfelus que je veux faire, pour savoir si c'est le contenu du fichier à inclure ou mon include qui cause le problème.

Pour l'utiliser avec LaTeX, voici un exemple :

awk -v regexp="^%%__paragraphe1__%%$" -v file=includes/paragraphe1.tex -f include_file.awk document.tex | pdflatex -jobname=document

Ici, la chaîne présente dans mon fichier document.tex est "%%__paragraphe1__%%".

Et comme on dit : "Ça marche mais c'est crado... C'est made in davro !!"

Merci.

dimanche 1 juillet 2012

Debian Wheezy a été freezé

Bonjour.

Hier soir, les migrations automatiques de paquets depuis Unstable vers Testing ont été arrêtées. Seul les paquets qui étaient en attente de cette migration ont reçu des autorisations.

Cela fait 8 ans que j'utilise Debian et je suis habitué aux processes de release. Mais je n'y ai jamais réellement porté attention jusqu'a ce que je contribue à Debian en 2011.

Cette freeze est importante pour moi car c'est la première fois que j'en vie une de l'autre côté, vu que j'aide à la maintenance des paquets Nginx (et audacious, mais j'ai été inactif ces derniers temps pour me concentrer pleinement sur Nginx jusqu'a ce que je retrouve une meilleure forme).

Le 27 Mai 2011, J'ai envoyé un mail à la mailing list debian-backports disant que j'ai réalisé un backport de Nginx 1.0.1 vers Squeeze et que j'espérait que quelqu'un l'uploaderait.

La première réponse provenait de Kartik Mistry, un des mainteneurs des paquets nginx (devenu le mainteneur principal depuis). Il a vérifié mon paquet et m'a proposé de l'aider dans la maintenance des paquets.

Ce fut le début d'un fabuleux périple au travers du projet Debian.

Au début, on a travaillés à synchroniser notre travail sur le packaging et le backporting, ensuite j'ai commencé à aider sur certains bugs. Mais j'ai surtout commencé à comprendre le processus de packaging.

Sur la dernière année, le plus gros travail sur le packaging Nginx n'a pas été technique, mais humain. Nous travaillons en équipe, dans laquelle chaque membre connait son rôle.

Je voudrai remercier quelques personnes :

  • Kartik Mistry et toute l'équipe de maintenance des paquets Nginx (Michael Lustfield, Jose Parrella, Fabio Tranchitella, Dmitry Oboukhov)
  • Sven Hoexter, qui sponsorise les backports nginx.
  • Benjamin Drung, qui m'a beaucoup aidé quand j'ai commencé à travailler sur les paquets audacious.
  • Et biensûr, tous les gens avec lesquels j'ai discuté sur les canaux IRC et les mailing lists.

Maintenant, quelques chiffres sur le packaging Nginx depuis la Squeeze freeze :

  • 68 commits sur le dépôt GIT
  • 262 commits sur le dépôt SVN
  • 78 bugs fermés grâce à un upload
  • 18 nouvelles versions de Nginx envoyées vers les dépôts debian.
  • 28 uploads
    • 19 par Kartik Mistry
    • 4 par Michael Lustfield
    • 4 par Moi
    • 1 par Dmitry Oboukhov

Si vous voulez discuter ou nous aider, vous pouvez venir sur le canal IRC #debian-nginx sur le réseau OFTC.

++

lundi 2 avril 2012

Arrêt du support des lenny-backports sur le DDB

Bonjour à tous et à toutes.

Debian arrêtant la maintenance pour la version 5.0 du système, j'ai décidé de faire de même sur le DDB.

Je continue toujours de maintenir les squeeze-backports et je déplacerai les backports lenny vers un autre dépôt, qui sera accessible depuis http://archives.ddb.davromaniak.eu dans les prochaines heures/jours.

Merci.

vendredi 24 février 2012

Mon pbuilderrc utilisant qemu-debootstrap

Bonjour à tous.

Comme vous le savez déjà, je passe beaucoup de temps sur tout ce qui est packaging Debian, tant sur le côté pratique que théorique de la chose.

Récemment, je suis devenu mainteneur Debian des paquets audacious et audacious-plugins. Et d'ici quelques semaines, je deviendrai co-mainteneur du paquet nginx sous debian.

En dehors de ça, j'essaye d'améliorer le travail en équipe au niveau du packaging nginx en fixant des objectifs à atteindre pour la prochaine freeze, et en essayant d'impliquer tous les co-mainteneurs dès qu'une décision importante doit être prise (upload d'une nouvelle version, ajout/suppression d'un module, etc...). Ce qui porte pas mal ses fruits, et on commence à bien travailler en équipe.

Mais sans environnement de compilation, le packaging Debian serait similaire au fait de jouer à la roulette russe avec une Gatling.

Pourquoi ?.

La raison est simple.

Avant d'uploader un paquet source dans Debian, il vaut mieux tester sa compilation dans un environnement le plus vierge possible, afin d'être certain des dépendances de compilation (les fameuses build-dep) et des dépendances binaires. Compiler un paquet en local ne garantit aucunement la bonne compilation d'un paquet, car comme tout utilisateur, on a déjà des paquets installés sur la machine, dont certains sont des dépendances de compilation, ce qui peut fausser l'appréciation de la justesse du paquet.

Pour avoir un environnement vierge, il existe plusieurs méthodes, dont voici une liste :

  • Des machines virtuelles qu'on réinstalle à chaque compile (méthode pour les gens patients et qui ont surtout beaucoup de temps libre).
  • La même chose, avec des machines physiques (fonctionnement sponsorisé par EDF, vu la conso électrique que ça doit engendrer, et pratique en hiver, ça permet de couper le chauffage).
  • Trouver un stagiaire, qui s'occupera des réinstall pendant que vous bossez sur les paquets sources (relativement cher, et peut engendrer une consommation excessive d'anti dépresseurs en tout genre de la part du stagiaire).
  • Faire des chroots à la main, à coup de debootstrap (on s'approche d'une solution pérènne, mais on doit recréer les chroots à chaque compile, pas pratique).
  • Utiliser des outils fournis par Debian, qui créent des chroots vierges (compressés dans des TGZ) et les décompressent afin de les utilisent pour lancer les compilation (ce que fait parfaitement pbuilder avec son pote debootstrap).

Comme vous avez dû le deviner, je vais parler de l'outil pbuilder.

Pbuilder peut se configurer à l'aide d'un fichier nommé pbuilderrc, souvent placé dans $HOME/.pbuilderrc, qui est un script bash, que pbuilder lit et exécute avant de commencer à travailler selon les actions qu'on lui ordonne.

Comme déjà expliqué dans les billets La machine ultime pour compiler ses paquets debian et Pbuilder et tmpfs peuvent être bons amis, le fichier .pbuilderrc permet de configurer tous les aspects de la création et de l'utilisation de ces chroots.

À force de travailler pour personaliser ma configuration, j'en suis arrivé à écrire un pbuilderrc assez complet, qui peut gérer plusieurs aspects de l'utilisation des pbuilders, y compris l'utilisation de qemu-debootstrap, qui est un debootstrap plus évolué, qui peut utiliser qemu afin de virtualiser l'architecture matérielle du chroot. On peut donc compiler du arm sur une machine i386 ou amd64 sans avoir besoin de passer par la création d'un environnement de cross-compilation.

Avant d'utiliser ce pbuilderrc, il faut donc posséder qemu-debootstrap, compris dans le paquet "qemu-user-static". Ce paquet est dispo dans le dépôt squeeze-backports, wheezy et sid pour debian et à partir de Natty pour Ubuntu.

Il est aussi fortement recommandé d'avoir lu le billet La machine ultime pour compiler ses paquets debian avant de l'utiliser, afin d'avoir toutes les dépendances nécessaires pour utiliser pbuilder avec une telle configuration.

Le pbuilderrc est disponible sur mon dépôt GIT "scriptomaniak", disponible sur github.

Il est à placer dans le dossier /root/, sous le nom .pbuilderrc

N'hésitez pas à faire des remarques et à me proposer des patchs/pull requests si vous voulez l'améliorer.

Bonne lecture et merci :).

vendredi 30 décembre 2011

Thruk + NGINX + authentification

Quand une seule ligne vous manque, tout est dépeuplé.

Lire la suite...

mardi 29 novembre 2011

Machines virtuelles de compilation de paquets Debian/Ubuntu

Bonjour à tous.

Après quelques mois sans grande activité, le blog se réveille.

Comme vous le savez, je travaille souvent sur la compilation de paquets Debian.

Depuis quelques temps, je compile les paquets du DDB pour d'autres architectures (powerpc et mips).

Pour les autres architectures, j'ai ce qu'il faut en machines physiques, mais pour ces deux architectures, j'utilise des machines virtuelles qemu.

À force des les utiliser, je me suis décidé à vous les proposer, afin que vous puissiez compiler facilement des paquets Debian/Ubuntu.

Chaque machine est fournie pré-configurée en accord avec le billet posté en mars dernier et les pbuilder pour Debian Lenny, Squeeze, Wheezy et Sid et Ubuntu Hardy, Karmic, Lucid, Maverick, Natty, Oneiric et Precise. De plus, un fichier README contenant toutes les informations utiles pour le lancement des machines.

Donc les voici :

Voici les sommes MD5, afin de pouvoir vérifier si le téléchargement s'est bien passé :

  • AMD64 : 3e55dd81c20c2a6f67a43a97d7eab986
  • I386 : 75c10975e65b1f816bc0a0711e9d12f3
  • MIPS : 9192d16ec83d31b3de0b381179e6eeef
  • MIPSEL : e01b1b1cdae64786d56b278c97e90c65
  • POWERPC : 63d0d2ceac849de0b0c1ad51eea4ee44

Pour finir, je tiens à remercier Aurélien Jarno (aurel32), car il fournit des machines virtuelles qemu pour différentes architectures, qui ont servi de base à ces machines de compilation.

Merci.

samedi 6 août 2011

Moments de joie et backports

Bonjour à tous.

Un mois est passé depuis la proposition (sur mentors) du backport de audacious 2.4.4 vers Debian Squeeze. Alors que je me faisais à l'idée que ces paquets n'allaient pas finir dans les backports, j'ai reçu 3 mails de Kilian Krause, qui accepte de sponsoriser les paquets (audacious, audacious-plugins et libmowgli)

J'étais très surpris et heureux, car ce backport est très différent de celui de nginx.

Comme certains le savent, j'utilise nginx régulièrement. Le site utilise nginx, je travaille dessus dans le cadre de mon travail, donc contribuer à nginx et réaliser le backport était naturel pour moi.

Mais pour audacious, c'est différent. Vers la mi-Juin, rent0n envoie une demande de backport d'audacious sur la mailing list backports. Je lui ai répondu, en ajoutant les mainteneurs en CC, et en disant qu'il serait plus judicieux d'attendre que la version 2.5.1 arrive dans unstable. Mais quelques jours après, aucune réponse des mainteneurs, alors je me suis demandé si ce backport est possible. Je l'ai fais, et ça fonctionnait, sauf que j'ai dû recompiler 10-15 paquets (pour un premier test, je n'ai pas voulu changer la version des dépendances, afin juste de voir si le reste du système était bon pour la compilation). 2 jours, j'ai nettoyé le paquet, testé chaque dépendance de compilation, and il s'est avéré que je n'avais besoin de backporter que la libmowgli. Donc j'ai proposé à rent0n de tester le paquet, il était content, donc pour moi, c'était bon, j'ai juste demandé si quelqu'un voulait valider et uploader le paquet. Mais je ne l'ai pas envoyé sur mentors.debian.net, car je ne pensais pas à une inclusion dans le dépôt officiel, pensant que les mainteneurs le feront mieux que moi. Après, je suis parti en vacances, donc j'ai un peu décroché de tout ça, mais pas rent0n, qui m'a proposé de l'envoyer vers mentors. Son enthousiame était tel qu'il était communicatif, donc j'ai envoyé le paquet sur mentors.

1 mois après, le paquet a été sponsorisé, et est maintenant en attente des dernières étapes de validation.

Donc voila, c'est la seconde fois qu'un de mes backports est sponsorisé et inclus. Bizarrement, ça me fait le même effet que si c'était la première fois. Un peu d'excitation, d'impatience par rapport aux prochaines étapes. Ensuite, j'irai voir son status sur le buildd presque une fois par jour, et ensuite, je vais être tiraillé entre 2 sentiments. Le premier, le soulagement, le travail est fait, tous ces moments passés à travailler sur le paquet sont maintenant des souvenirs. Le second, c'est la joie, car des personnes ont estimés que mon travail est d'assez bonne qualité pour mériter une inclusion officielle.

De plus, pour chaque paquet que je backport, je m'inscrit à page QA, pour être courant des bugs, mises à jour, et des infos du paquet.

Maintenant, parlons de DDB.

J'ai décidé de supprimer toute référence au backport de chromium, car je ne suis pas capable de le maintenir à jour, et que le paquet est si peu propre, que j'ai préféré le supprimer. Cependant, je pense créer une section "dev" pour le DDB, mais pas dans l'immédiat.

D'ailleurs, j'ai mis à jour le backport de nginx en version 1.1.0. Je l'ai envoyé sur mentors, mais devra attendre au moins une semaine avant un upload.

Voila, c'est tout :).

- page 1 de 2