Tag: script

MythTV, les SSD et le démarrage trop rapide

Aucun commentaire sur MythTV, les SSD et le démarrage trop rapide

29 août 2010 at 2 h 56 minCategorie :PC Home Cinema

Souvent, les nouvelles technologies ont des problèmes de jeunesse. Fréquemment, elles n’apportent pas vraiment tous les bénéfices auxquelles on s’attendait. Et parfois même, elles marchent trop bien.

La drôle d’expérience que j’ai eu l’occasion de vivre avec un SSD fait partie de ce dernier cas.

Un des avantages du disque SSD, bien connu et qui fait baver de nombreux adeptes des benchmark, est la rapidité de démarrage du système. Dans le contexte d’un PC Home Cinema, cette caractéristique en fait un véritable « must-have », un petit plus pouvant drastiquement améliorer le WAF. C’est donc tout naturellement que, après l’achat, j’ai pris un plaisir non dénué de fierté puéril à découvrir que mon système pouvait être « prêt » (frontend MythTV lancé) en moins de 20 secondes, départ arrêté depuis grub, et ce sans optimisation particulière et alors même que j’utilise un environnement de bureau plutôt lourd (KDE). Bref, tout à fait ce que j’attendais.

Mais oh, surprise, les démons de l’informatique ont déterminé qu’il était important de me fournir matière à article, et ont donc introduit un effet de bord particulièrement vicieux : mon système démarre parfois trop vite. Ou plus exactement, MythTV se lance trop rapidement ! Alors même que je ne suis pas passé au massivement parallèle Upstart, restant fidèle au bon vieux init de System V que je maîtrise bien, le démarrage pourtant essentiellement séquentiel de mon système arrive quand même à faire des siennes. J’explique :

Symptôme : le vilain écran me demandant de rentrer les paramètres du backend à la main apparaît une fois sur deux, car le backend mentionné dans la configuration n’est pas joignable.
Cause : l’interface réseau est trop lente à se rendre disponible, les logiciels sont chargés bien plus vite que la normale, et les requêtes TCP à destination d’autres machines de mon réseau local n’aboutissent parfois  pas au moment du démarrage.
Remède : un petit script quick-and-dirty super simple qui ping ma machine principale avant de lancer MythTV. Il suffit ensuite d’appeler ce script par votre lanceur habituel en lieu et place du lanceur du frontend MythTV.

#!/bin/bash

killall mythfrontend
killall mythwelcome

ping -c2 192.168.0.1 > /dev/null
result=$?
while [ $result -ne 0 ]
do
sleep 1
#bonus : vous pouvez glisser ici un petit réveil par le réseau.
#wakeonlan -i 192.168.0.255 <adresse_mac>
ping -c2  > /dev/null
result=$?
done

mythfrontend &

Bonus

La même chose peut être valable pour lancer le backend sur une machine trop rapide. Il faut donc adapter le script /etc/init.d/mythbackend et ajouter le même genre de test simplet.
Je vous offre une petite subtilité gratuite qui mérite à elle seule cette section bonus : attention à ne pas oublier de commenter l’éventuelle ligne « set -e » ! Celle-ci à pour intéressante (et détestable dans notre cas) particularité de commander l’interruption complète du script dès lors qu’une des commandes n’a pas retourner le code ok (zéro en bash). Vous vous doutez bien que cette option est invalidante quand on cherche à tester par ping une machine susceptible de ne pas répondre.

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

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

16 août 2010 at 21 h 54 minCategorie :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.