Une sauvegarde FTP ordonnancée et simple, appliquée à Zimbra

Un commentaire sur Une sauvegarde FTP ordonnancée et simple, appliquée à Zimbra

août 16, 2010 at 9:54 Categorie :Zimbra

En informatique, rien n’est plus vrai que l’adage « un script qui peut le plus peut le moins ».
A ceci, j’aime rajouter son corollaire :  » un script qui peut le plus coûte cher et est relou à maintenir « …

Tout l’art consiste à choisir son camp en fonction des circonstances… Vous vous en doutez sans doute, mais là c’est le moment idéal pour placer un exemple de script rapide et fonctionnel, et je ne vais pas me gêner.

J’ai eu besoin récemment de programmer une sauvegarde régulière de l’ensemble du Zimbra que j’héberge pour usage familial. Pourquoi une sauvegarde? Il ne s’agit pas d’un environnement professionnel à haute criticité, alors à quoi bon s’embêter? Hum, bien sûr mon ami, mais je pense que tu ne t’es jamais retrouvé en face de membres de ta famille gémissant sur des mails perdus avec les photos du petit dernier. Lorsque le faciès de ta honte sera éternellement gravé dans les mémoires, tu regretteras de ne pas avoir prévu le crash du disque dur chez l’hébergeur.

Hop, voilà donc petit script pour exploiter l’espace FTP gracieusement mis à disposition à cet effet par mon hébergeur OVH et t’éviter une disgrâce familiale. Au menu :

– Rotation très poussée et configurable. Haha je plaisante, le but c’est de faire un script ultra simple.  On se contente de move et de del
– Utilisation de deux rsync avant le tar pour faire une longue sauvegarde à chaud puis une courte à froid pour minimiser le temps d’indisponibilité. NB: rsync et tar ont l’avantage de conserver les liens symboliques tels quels, contrairement à un simple cp.
– Dépôt FTP automatisé…
…Et c’est tout ! En effet Zimbra, même dans sa version communautaire, est plutôt simple à sauvegarder. Donc pas la peine de s’embêter avec des tonnes d’options.

Le voilà dans sa plus simple expression :

#!/bin/bash
SERVER=<serveur>
USERNAME=<login_ftp>
PASSWORD=<pwd_ftp>
DESTINATION=<chemin_destination> #chemin temporaire de travail pour faire les synchronisations et construire l'archive

function ftpfile {
   ftp -n <<EOF
   open $SERVER
   user $USERNAME $PASSWORD
   bin
   $1 $2 $3
   bye
   EOF
}

rsync -av --delete /opt/zimbra $DESTINATION
#/etc/init.d/zimbra stop
#rsync -av --delete /opt/zimbra $DESTINATION
#/etc/init.d/zimbra start
cd $DESTINATION
tar cvfz zimbra.tar.gz zimbra

ftpfile del zimbra.tar.gz.3
ftpfile rename zimbra.tar.gz.2 zimbra.tar.gz.3
ftpfile rename zimbra.tar.gz.1 zimbra.tar.gz.2
ftpfile rename zimbra.tar.gz zimbra.tar.gz.1
ftpfile put zimbra.tar.gz

Le script est à exécuter en tant que root (nécessaire pour conserver les propriétaires des fichiers).
Et on n’oubliera pas d’ajouter  une ligne idiote dans la crontab. Je ne vous fait pas l’affront de l’écrire à votre place, mais je me permets deux petits conseils :
– redirigez la sortie standard de votre opération de « tar » quelque part.
– mentionnez expressément l’interpréteur en tête de votre commande dans la ligne cron.
Pourquoi? Personne ne semble capable de l’expliquer, mais parfois le tar s’interrompt en plein milieu si  ceci n’est pas rajouté (j’ai pu le constater, avec beaucoup d’étonnement d’ailleurs). Ce qui donne par exemple :

0 3 * * *  /bin/bash <chemin>/sauvegarde.sh > /var/log/sauvegarde.log

Bonus : comment restaurer la sauvegarde

Rien de plus simple. Remplacer le répertoire /opt/zimbra par le contenu de votre tar.
S’il s’agit d’une nouvelle machine parce que l’impitoyable crash de votre disque dur à été total, n’oubliez pas de réinstaller la même version de Zimbra par la procédure standard avant d’extraire le tar. En effet les paquets doivent être proprement installés au moins une fois.

Thunderbird Portable 3 en français

2 commentaires sur Thunderbird Portable 3 en français

août 15, 2010 at 1:43 Categorie :Logiciels

Afin de satisfaire les besoins particuliers d’un proche, j’ai eu l’occasion de me pencher sur le logiciel Portable Thunderbird.
Qu’est ce que PT? C’est l’excellent paquage stand-alone de Thunderbird fourni par le non moins excellent site  » Portable Apps « . Aucune installation, paramètres et comptes sauvegardés directement dans l’arborescence, l’idéal pour transporter sur une clef usb.

Alors, si ce logiciel est si génial, pourquoi ai-je eu besoin de fouiller le net et pourquoi en fais-je un article? Parce que la seule version française, fournie par l’indispensable site Framasoft, date un peu (version 2.0). Heureusement après quelques recherches j’ai fini par trouver comment imposer une traduction, et ainsi composer une version portable française récente. Suivez le guide :

  1. Téléchargez la version Portable de Thunderbird sur «  Portable Apps « .
  2. Téléchargez et installez la version « normale » de Thunderbird (faites attention à bien récupérer la même version)
  3. Récupérez dans la version normale le fichier Mozilla Thunderbird\chrome\fr.jar
  4. Copiez le fr.jar dans le répertoire ThunderbirdPortable\App\Thunderbird\chrome et renommez le en en-US.jar en ayant bien pris soin de vous débarrasser de l’ancien préalablement.
  5. Ouvrez le nouveau en-US.jar avec un utilitaire d’archivage (je conseille l’excellent 7-zip). A l’intérieur renommez le répertoire locale/fr en locale/en-US.

Voilà, vous avez donc maintenant un beau fichier feinteur en français qui se fait passer pour une ressource de langue anglaise. C’est fourbe un Français. En lançant le programme vous constaterez qu’il est bien composé dans la langue de Molière, ni vu ni connu.

Bémol : les extensions

Malheureusement avec cette bidouille (appelons un chat un chat), les extensions s’installent en langue anglaise. En effet, malgré les apparences, celles-ci ont toujours à faire à une version Shakespearienne et donc continuent dans la lancée.

Heureusement la contre-feinte est facile : le même procédé que précédemment doit être appliqué. Les seules différences :

  1. Le fichier jar en français à récupérer dans l’installation « normale » est à chercher dans le répertoire utilisateur. En effet c’est là que s’installent les extensions. Exemple sous Windows 7 : 
    C:\Users\<utilisateur>\AppData\Roaming\Thunderbird\Profiles\<id_du_profile>\extensions\<id_extension>\chrome\<nom>.jar
  2. Le fichier jar à remplacer se trouve  ici : 
    ThunderbirdPortable\Data\profile\extensions\{id-extension}\chrome\<nom>.jar

La même feinte consistant à renommer le dossier locale/fr en locale/en-US à l’intérieur du .jar est bien sûr à employer.

Bonus

Pour les fainéants, voici Portable Thunderbird 3.0.2 en version française.


LIRC – Quelques explications

7 commentaires sur LIRC – Quelques explications

juillet 29, 2010 at 3:53 Categorie :PC Home Cinema

On trouve de nombreux tutoriels sur le net à propos de LIRC. « Fais ci », « édite ce fichier », et « relance ça comme ça ». Et puis « bidouille ce truc aussi s’il te plaît ! ». Bref, beaucoup d’actions opérées en aveugles et un bon paquet de lignes de commande absconces pour la plupart des utilisateurs. Plutôt que de « réécrire la roue » (magnifique figure de style, n’est ce pas ?) avec un autre tuto, je vais profiter de cet article pour faire quelque chose qu’on voit rarement : décrire le fonctionnement de l’application, le pourquoi des fichiers de configuration et leur rôle.
Attention : dans cette article je ne couvrirai que les systèmes basés sur Debian.

LIRC, mais c’est quoi en fait?

LIRC est une excellente suite logicielle visant à utiliser des télécommandes avec GNU/Linux. Sa compatibilité avec tout et n’importe quoi et sa versatilité en font un incontournable de tout PC orienté Home Cinema.
Concrètement, et c’est souvent ce qu’on a du mal à comprendre la première fois qu’on y touche,  LIRC est un mot fourre-tout pour ce qui est à la fois une paquet d’éxécutables  (sous forme de démon ou non), un framework (utilisable par les application tierces), et un ensemble de modules noyaux (pour piloter le hardware de vos récepteurs).
Mais assez de présentations, entrons dans le vif du sujet :

/etc/lirc/hardware.conf, le fichier de configuration du matériel

C’est ici qu’est défini le matériel. Ça vous l’aviez compris tout seul, non?
Par contre, et là je pense que je vous apprends quelque chose,  il ne fait pas partie de LIRC ! Ce fichier de configuration est une aide, laissée par les packageurs de votre distribution afin de simplifier l’utilisation des démons contrôlant LIRC. Il est donc nécessaire de faire attention à ce que vous lisez sur Internet, car en fonction de votre distribution les paramètres peuvent drastiquement changer. Le fichier peut même être totalement inutile. (Pour l’anecdote, je l’ai appris à mes dépends en perdant quelques heures lors d’une migration Ubuntu vers Debian)
Concrètement, ce fichier est lu par le script de démarrage de LIRC (/etc/init.d/lirc,  dont le contenu change selon les distributions). Celui-ci  prépare l’environnement et construit la ligne de commande adéquate pour lancer le démon LIRC.

Je ne vais pas tout couvrir, mais les paramètres les plus importants sont :

  • REMOTE : Ah non, en fait ce paramètre ne sert pas à grand chose. Je vous ai bien eu non? Il est principalement esthétique. Mettez y ce qu’on vous dit d’y mettre et puis c’est tout.
  • REMOTE_MODULE : Le script d’initialisation parcourt ce paramètre et avant toute opération charge les modules noyaux mentionnés ici. Bien entendu ces modules doivent être installés et compatibles avec le noyau que vous utilisez actuellement.  Où les trouver ? Ils sont généralement issue directement du projet LIRC. Soit vous avez de la chance et ils sont disponibles directement dans votre distribution, patiemment reconstruit par les packageurs à chaque nouvelle version de noyau, soit vous devrez les faire vous même avec la commande m-a, acronyme de module-assistant (reportez vous aux différents tuto sur le sujet). Pour vérifier que le module est OK, n’hésitez pas à vous amuser avec les commandes lsmod, modprobe et rmmod afin de voir si celui ci se charge correctement. Le chargement du module, si OK, devrait faire apparaître un fichier périphérique dans /dev/ (exemple /dev/ttyUSB0 pour mon USBuirt)
  • REMOTE_DRIVER : Ceci indique à LIRC quel pilote utiliser pour dialoguer. Cette notion de pilote est cette fois interne à LIRC  : Il ne s’agit pas de périphérique noyau mais juste de définir comment LIRC va dialoguer avec votre périphérique /dev/machin. La subtilité, c’est que LIRC peut très bien avoir été compilé sans le support du périphérique que vous voulez utiliser. Un petit coup de /usr/sbin/lircd -H help ôtera vos doutes rapidement.
  • REMOTE_DEVICE : C’est le fichier périphérique qui a été créé par le module noyau que vous avez chargé. Ceci indique au démon LIRC avec qui il va devoir dialoguer.
  • REMOTE_LIRCD_CONF : L’emplacement du fichier de configuration des télécommandes (habituellement /etc/lirc/lircd.conf, mais vous pouvez mettre ce que vous voulez) . Voir plus bas.

Alors, tout ce beau monde, qu’est ce que ça fait au final ?
Si je prends mon exemple personnel et relativement simple de boitier USBuirt, un passage de /etc/init.d/lirc start me donne maintenant un démon lancé comme ça:

/usr/sbin/lircd --driver=usb_uirt_raw --device=/dev/ttyUSB0 --output=/dev/lircd --listen

Tout ça pour ça, pourrait-on se dire…
Mais au moins, maintenant, à chaque fois que je lance LIRC par le script d’initialisation j’obtiens : des modules chargés, un périphérique bloc /dev/ttyUSB0 monté, un joli démon lancé sur ma machine pour dialoguer avec ce /dev/ttyUSB0 selon le langage « usb_uirt_raw », et ce même démon me crée une jolie socket unix /dev/lircd pour mes logiciels favoris (voir plus bas le rôle de cette socket). Pas mal non? C’est un bon début.

Le fichier de configuration /etc/init.d/lircd.conf

Jusqu’ici le démon lircd que vous pouvez maintenant lancer sait comment dialoguer avec votre périphérique émetteur ou récepteur. Mais il ne sait pas vraiment ce qu’il va trouver pendant son dialogue, qu’est ce qu’il doit garder et qu’est ce qu’il doit jeter. Ce fichier lircd.conf est là pour ça : c’est une sorte de « carte » de votre télécommande. A l’intérieur, des listes de télécommande (si vous en utilisez plusieurs) et pour chaque télécommande des touches avec des jolis noms « user-friendly » et les codes infrarouges correspondant.

Où trouver ce fichier de configuration? Par exemple ici.
Mais si il ne s’y trouve pas, vous pouvez le faire vous même. Vous allez devoir utiliser irrecord pour ça. C’est un exécutable livré ordinairement avec LIRC. Il prend grosso modo les même paramètres que le démon « lircd », donc si vous êtes capables de configurer le fichier hardware.conf et que celui ci vous génère à chaque lancement de /etc/init.d/lirc une belle ligne de commande, alors le plus gros du travail est fait.
Exemple :

irrecord --driver=usb_uirt_raw --device=/dev/ttyUSB0 monlircd.conf

Comme irrecord dialogue directement avec le bloc périphérique, comme lircd, il ne faut pas que ce dernier soit lancé (ils sont exclusifs et très jaloux).
Coté utilisation, c’est très facile : vous suivez les instructions, et il enregistre toutes vos touches les unes après les autres en leur attribuant le joli nom que vous souhaitez.

Mais alors, comment mes applications savent jouer avec LIRC ?

C’est simple, vous vous souvenez de la socket unix dont je parlais plus haut, celle qui est préparée par le démon LIRC? Et bien les applications  se connectent à celle-ci  et écoutent toutes les touches que vous pouvez taper.
Cette socket est nommée /dev/lircd le plus souvent. Si vous souhaitez donner son chemin vous même (par exemple si vous en avez plusieurs), il est défini par le paramètre –output du démon lircd. La plupart des application vont se connecter à /dev/lircd, mais certaines d’entre elles peuvent être configurées pour se connecter au chemin de votre choix (c’est le cas par exemple de mon cher mythtv qui possède ce paramètre dans un coin de la configuration du frontend). Je vous conseille de tout laisser par défaut, c’est suffisant pour 90% des cas.

Vous l’avez compris, mais je me permets de le rappeler : pour qu’une application fonctionne avec LIRC, il faut qu’elle se branche sur la socket unix, et donc qu’elle ait été codée pour çà ! Cela semble évident au premier abord mais c’est pourtant loin d’être automatique si l’on se réfère aux questions qu’on trouve souvent sur les forums.

Et la configuration de ces applications, où se fait-elle?

/home/<user>/.lircrc, où comment en avoir marre de tous ces fichiers de configuration

Les applications se connectent à la socket lircd, OK. Mais comment l’application sait quoi faire selon la touche pressée? C’est ici qu’intervient le fichier .lircrc.
Contrairement à une autre idée fréquemment répandue, ce n’est pas un fichier de configuration de LIRC. C’est un fichier de configuration de vos applications finales !
En effet, celles ci parcourent immanquablement le fichier ~/.lircrc (et les éventuels sous fichier inclus avec la directive include), y repèrent leur propre marqueur (c’est le rôle de l’attribut « prog« ), et enregistre la carte des événements déclenchés en fonction des touches appuyées. Exemple :

begin
remote = NOVA-T500
prog = mplayer
button = Play
config = pause
end

L’appui de la touche « Play » (touche nommée ainsi dans le fichier /etc/lirc/lircd.conf qui établit la correspondance nom <–> code infrarouge), provoque l’événement « pause » dans l’application mplayer.

Et voilà ! C’était pas si compliqué (hum…)

Une synthèse s’il te plaît, pour finir un article trop long !

Comme je suis attentif à vos remarques, la voici :
lircd est un démon qui s’interface avec un périphérique /dev/machinX (donc le fichier bloc est créé par un module noyau appartenant parfois au projet LIRC) selon un protocole de communication appelé « driver » par LIRC. Une fois que lircd est lancé, celui ci va à son tour lire un fichier de conf (/etc/lirc/lircd.conf par défaut). Ce fichier décrit les codes infrarouges susceptibles d’être échangés avec le périphérique (les codes sont regroupés en appareil). Le démon créé ensuite une socket de type /dev/lircdX avec lequel les programmes peuvent s’interfacer facilement.
Les programmes se connectent à cette belle socket, lisent un fichier de conf .lircrc dans le home de l’utilisateur, repèrent le mappage touche <–> événement à déclencher, et VOUS POUVEZ ENFIN REGARDER DES VIDEOS DEPUIS VOTRE CANAPE.

Article sous licence « Creative Common Merciciel ». Vous en faites ce vous voulez, mais je veux un merci si vous l’avez bien aimé.