Project:Omega.org

Aujourd’hui nous allons encore une fois nous occuper de cron. Vous allez apprendre comment obtenir votre propre système crontab de lancement régulier de script et d’envoi des rapports par courrier électronique de la même manière que le font les jobs (batchs) de cron. Votre nouveau script copiera un répertoire de votre choix vers un autre support pour le sauvegarder. Bien que ce ne soit pas une solution complète de remplacement à une solution commerciale de sauvegarde telle que Retrospect, par exemple, cela fournit au moins une solution simple et gratuite de s’assurer que ses données les plus importantes soient présentes sur deux supports.

Les lecteurs de l’article de Derrick Story, Taming the Entourage Database (en anglais - Apprivoiser la base de données d’Entourage), savent combien il est important de sauvegarder régulièrement le répertoire Utilisateurs Office X et j’emploierai ce répertoire comme exemple dans cet article. Si vous n’employez pas Entourage, vous pouvez au lieu de cela sauvegarder un autre répertoire, y compris votre répertoire ~/Documents en entier.

Choisir le bon outil

Le coeur de cette procédure étant la ligne de commande qui effectue la reproduction, c’est par là que nous commencerons. Comme avec la plupart des procédures Unix, il y a plusieurs manières d’éplucher une pomme de terre (pour reprendre une expression amicale), donc naturellement, Mac OS X est doté de plusieurs outils en ligne de commande qui peuvent copier des fichiers. Parmi ceux-ci, il y en a quatre que vous devriez considérer apte à ce travail, mais seulement un seul qui fera juste ce dont nous avons besoin.

Pour cette tâche, les considérations les plus importantes pour choisir l’outil de copie de fichiers est la capacité à préserver les permissions, les ressources et les codes créateur/type de fichier originaux. Si nous pouvons nous assurer que ces attributs de fichier seront maintenus, nous pouvons alors sans risque copier n’importe quel répertoire et être sûr que la copie sera aussi bonne que l’original. Voici comment les quatre outils respectent ces critères :

Utilitaire	Permissions préservées	Ressources et Créateur/Type conservés ?
cp	Oui	Non
cpmac	Non	Oui
ditto	Oui	Oui
rsync	Oui	Non

ditto

Comme vous pouvez le voir, un seul de ces utilitaires, ditto, remplit le contrat. Brièvement, ditto un outil développé par Apple pour la reproduction de répertoires entiers (mais pas de fichiers individuels). De manière plus importante, ditto est dôté d’une option -rsrc qui assure que les ressources tout autant que les codes créateur/type seront préservés lors des copies. Par exemple, cette commande copiera le répertoire Utilisateurs Office X de mon répertoire domestique vers le répertoire Backup du support externe “Secondary” :

ditto -V -rsrc ~/Documents/"Microsoft User Data/Office X
Identities" "/Volumes/Secondary/Backups/Office X Identities"

La commande du dessus est sur une ligne entière.

L’option complémentaire -V active le mode trace, qui charge ditto d’imprimer une ligne pour chaque répertoire et fichier copié. Ces lignes seront alors envoyées dans le rapport de cron envoyé par courrier électronique, qui ressemblera à peu près à cela :

>>> Copying Documents/Microsoft User Data/Office X Identities/
    copying file ./Main Identity/Database ... 340328640 bytes
    copying file ./Main Identity/Database Cache ... 17432 bytes
    copying file ./Main Identity/Mailing Lists ... 20784 bytes
    copying file ./Main Identity/Rules ... 20784 bytes
    copying file ./Main Identity/Signatures ... 12560 bytes
    copying file ./Newsgroup Cache ... 8 bytes

Voici quelques trucs que vous devriez remarquer dans les deux noms de chemin d’accès de la commande :

• Comme avec une commande cp, le premier nom de chemin nomme le répertoire source à copier et le second nomme son répertoire de destination.
• Normalement, vous devriez entourer un nom de chemin entier de guillements pour garantir l’interprétation des caractères spéciaux qu’il contient (des espaces dans ce cas). Cependant, le nom de chemin d’accès au répertoire source commence par un tilde (”~“), un caractère spécial dont nous voulons préserver la signification puisqu’il représente un raccourci au répertoire domestique. La manière de préserver notre raccourci et aussi nos espaces consiste à juste entourer de guillements la partie du nom du chemin d’accès qui contient les espaces. Nous pourrions à la place juste préfixer chaque espace avec un antislash, mais cela rend la syntaxe confuse.
• Dans presque tous les cas, le chemin d’accès à votre support externe et à vos volumes réseau commencent par /Volumes.
• Le fait de ne pas mettre de slashs à la fin des noms de chemin d’accès nous assurera que ditto créera correctement le répertoire de destination s’il n’existe pas déjà.

Pour en savoir plus sur ditto, consultez sa page man avec la commande man ditto.

Ainsi, pour atteindre notre objectif, l’emploi de ditto comme indiqué dans cet exemple permettra de faire juste ce que nous attendons. Il y a, cependant, une autre option dont vous devez être conscient : rsync.

Rsync

Rsync est un outil de synchronisation de répertoires assez intelligent pour copier seulement les fichiers nouveaux ou modifiés, accélérant ainsi significativement les sauvegardes. Si vous projetez de sauvegarder un grand répertoire qui ne change que partiellement de jour en jour (votre ~/Documents entier, par exemple), rsync semble être la meilleure solution. Malheureusement, comme vous le voyez dans le tableau, rsync ne préserve pas les ressources.

Cependant, la bonne nouvelle tient dans l’existance d’une version, en développement, de rsync qui préserve les ressources et qui s’appelle RsyncX. Elle est disponible ici. (L’installation contient aussi une interface GUI). Si vous décidez d’employer RsyncX au lieu de ditto, la documentation sur le site de RsyncX vous y aidera. Testez bien vos commandes RsyncX de façon à être sûr que toutes les données seront copiées correctement. Pour employer RsyncX à la place de ditto dans la ligne de commande ci-dessus vous taperiez :

rsync -ave /usr/bin/ssh ~/Documents/"Microsoft User Data/Office X Identities"
"/Volumes/Secondary/Backups/Office X Identities"

La commande ci-dessus est sur une ligne entière.

Notez que RsyncX emploie toujours la commande rsync. En fait, cette ligne de commande marchait avec la version originale de rsync installée avec Mac OS X, mais ne préservait pas les ressources ou le code créateur/type correctement. Notez aussi que, dans mes test, quand RsyncX copie un seul fichier, il le fait tant plus lentement que ditto. Dans le cas du répertoire Utilisateurs Office X, où la plupart des données changent entre deux sauvegardes, ditto effectuera en fait une sauvegarde plus rapide et sera donc le meilleur choix pour cette tâche.

Script shell

L’étape suivante doit consister à déterminer la commande ditto appropriée pour votre système et à la tester plusieurs fois pour s’assurer qu’il se lance régulièrement et que toutes les données copiées soient dans un bon état.

Une fois que vous avez mis au point une bonne ligne de commande ditto, l’étape suivante consiste à l’insérer dans un fichier script shell. Tout comme votre système crontab se réfère actuellement aux scripts quotidiens, hebdomadaires et mensuels qui font le gros du travail, il se réfèrera aussi à un script de “sauvegarde”. Le fait de mettre cette commande dans un fichier script séparé, vous permettra aussi de le lancer facilement à la main chaque fois que vous le souhaiterez.

La répertoire conventionnel pour le stockage des scripts utilisateur est ~/bin, que vous devez créer s’il n’existe pas déjà :

mkdir ~/bin

Le répertoire ~/bin est le bon endroit pour placer vos scripts sachant que, par défaut, le shell recherche les exécutables à cet endroit à chaque fois qu’il reçoit une commande. Ce chemin d’accès fait partie de ceux connus collectivement sous le nom de chemin de recherche. Cette liste permet au shell de rapidement exécuter un fichier sans qu’il ait à fouiller partout dans le système, ou sans que vous ayez à inclure le nom complet du chemin d’accès à chaque exécutable.

Nous appellerons le fichier backup.sh, de manière à respecter la convention de nommage des scripts shell Bourne avec l’extension .sh. Créez le fichier avec pico en tapant la commande :

pico ~/bin/backup.sh

Une fois dans pico, entrez cette première ligne qui indique au shell d’employer /bin/sh (le shell Bourne) pour lancer le script :

#!/bin/sh

Ensuite utiliser echo pour afficher ce qui deviendra la première ligne de votre rapport cron :

echo "Résultats de la sauvegarde quotidienne    :"

Entrez alors votre propre version de la commande ditto :

ditto -V -rsrc ~/Documents/"Microsoft User Data/Office X Identities"
"/Volumes/Secondary/Backups/Office X Identities"

Votre session pico doit alors ressembler à quelque chose dans ce genre :

Rappelez-vous que pico n’affiche pas les lignes trop longues, il emploie le symbole $ pour indiquer que la ligne a été tronquée.

Finalement, tapez “contrôle + O”, retour et “contrôle + X” pour sauvegarder le fichier et quitter pico comme d’habitude.

Le script fonctionnera de manière excellente tel quel quand il sera appelé par cron, mais si vous voulez le lancer directement à partir de la ligne de commande, vous devrez d’abord le rendre exécutable et faire en sorte que le shell reconstruise sa liste d’executables situés dans ses chemins de recherche. Pour faire cela, employez la commande chmod pour activer le caractère exécutable du fichier :

Chmod +x ~/bin/backup.sh

Entrez alors la commande rehash pour reconstruire la liste des exécutables :

[localhost:~]chris% rehash [localhost:~]chris%

Cela, alors, vous permettra d’exécuter le script en entrant simplement au nom du script :

[localhost:~]chris% backup.sh
Résultats de la sauvegarde quotidienne :
>>> Copying /Users/chris/Documents/Microsoft User Data/Office X Identities

Une fois que vous êtes sûrs que le script backup.sh est au point, il est alors temps de créer votre crontab.

Les crontabs utilisateur

Dans “Le Terminal de Mac OS X, Partie 1“, vous avez appris comment modifier le système crontab en l’ouvrant simplement dans un éditeur de texte. Cependant, pour cette procédure, vous devez créer un crontab utilisateur. Les crontabs (ou “tables cron”) utilisateur sont lancés sous des comptes utilisateur standard et non sous root, par conséquent leurs scripts ne peuvent avoir accès qu’aux répertoires et aux applications que l’utilisateur peut accéder. Cet arrangement permet à n’importe quel utilisateur de créer une liste personnelle de commandes automatisées sans risque pour les fichiers essentiels du système.
Les crontabs utilisateur diffère du crontab système de part le fait que vous ne pouvez pas éditer directement les crontabs utilisateur. D’une part, les crontabs utilisateur et le répertoire dans lequel ils résident appartiennent à root, donc inaccessible aux autres utilisateurs. La meilleure façon d’éditer les crontabs utilisateur est de se servir de l’outil crontab (à ne pas confondre avec les fichiers crontab qu’il crée). Connu comme étant un “programme root setuid”, crontab est dôté de permissions qui font qu’il sera toujours considéré comme l’utilisateur root, fonctionnalité qui vous relie aux emplacements qui autrement sont limités. Le programme crontab vérifie aussi que votre crontab est formaté correctement avant son installation dans /private/var/cron/tabs/username.

Avant de commencer à utiliser l’utilitaire crontab, vous devrez d’abord formuler et tester la ligne de commande que vous emploierez dans votre tache cron. Basez votre ligne de commande sur celle que j’ai utilisée sur ma machine :

30 18 * * * sh ~/bin/backup.sh 2>&1 | mail -s "Daily Backup Report"  chris

Cette ligne doit être facile à comprendre si vous vous rappelez le crontab système de la partie 1 de cette série de tutoriels. Ce qui diffère, cependant, est l’absence du sixième champ “utilisateur” dans le crontab utilisateur. Ce champ identifie le compte utilisateur sous-lequel le job doit être lancé. Le crontab utilisateur crontab tournant toujours sous le compte de l’utilisateur qui l’a créé, ce champ est donc inutile dans le crontab utilisateur.

Le champ suivant contient réellement la ligne de commande à lancer. En paraphrasant grossièrement :

D’abord, utilisez le shell Bourne pour lancer le script que nous avons créé sous le nom ~/bin/backup.sh :

Sh ~/bin/backup.sh

Ensuite, envoyez l’affichage de ce script, y compris les messages d’erreur, vers la commande suivante en employant le caractère pipe ("|“) pour indiquer que le résultat de la commande précédent le “|” doit être transmis à la commande qui le suit (on parle alors de “pipeline”) :

2>&1 |

Finalement, faites en sorte que mail reçoivent l’entrée du “pipe” en l’employant comme corps du nouveau message avec comme sujet “Rapport de sauvegarde quotidienne” et envoyez le à l’utilisateur “chris” :

mail -s "Daily Backup Report" chris

La ligne que vous devez entrer différera seulement de part les champs de planification et de nom de compte utilisés à la fin. Vous voudrez probablement planifier cette tache à un moment où vous ne serez pas occupé sur votre Mac, mais s’il vous arrivez de travailler au moment du démarrage de cette tache, vous ne remarquerez pas grand chose, si ce n’est le léger dérangement du au lancement de ditto en l’arrière-plan (selon les performances de votre machine, bien sûr).

Pour tester la commande à partir du prompt, passer d’abord en shell Bourne (tapez juste sh et retour) :

[localhost:~] chris% sh
localhost%

Entrez alors la ligne de commande (pas les champs de planification ou la commande sh) :

localhost% ~/bin/backup.sh 2>&1 | mail -s "Daily Backup Report" chris
localhost%

Si tout s’est bien passé, vous devrez juste recevoir un nouveau prompt et ensuite, au bout de quelques moments, le rapport expédié par mail devra arriver et ressembler à quelque chose dans ce genre :

From root Tue Jun 25 21:17:54 2002
Date: Tue, 25 Jun 2002 21:17:54 -0700 (PDT)
From: Chris <chris>
To: chris
Subject: Daily Backup Report
Rapport de sauvegarde quotidienne:
>>> Copying /Users/chris/Documents/Microsoft User Data/Office X Identities
copying file ./.DS_Store ... 6148 bytes
copying file ./Main Identity/Database ... 10047232 bytes
copying file ./Main Identity/Database Cache ... 17092 bytes
copying file ./Main Identity/Mailing Lists ... 20784 bytes
copying file ./Main Identity/Rules ... 20784 bytes
copying file ./Main Identity/Signatures ... 12560 bytes
copying file ./Newsgroup Cache ... 8 bytes

Quitter le shell Bourne et retourner à tcsh, tapez juste exit et vous obtiendrez de nouveau un prompt tcsh :

localhost% exit [localhost:~] chris%

Une fois que vous avez vérifié que les fichiers ont été copiés correctement, vous êtes prêts à employer l’utilitaire crontab, ce qui revient en réalité beaucoup plus à choisir un éditeur de texte. Par défaut, l’éditeur vi est utilisé. Si vous connaissez déjà vi et voulez l’employer pour éditer votre crontab, sauter la commande qui suit. Sinon, puisqu’à ce jour vous êtes probablement plus à l’aise avec pico, faites en votre éditeur par défaut avec cette commande :

Setenv EDITOR pico

Dans ce cas, la commande setenv positionne une variable d’environnement appelée EDITOR à la valeur pico. Ce réglage est provisoire uniquement pour la durée de la session shell en cours (c’est-à-dire jusqu’à ce que vous fermiez cette fenêtre Terminal). Donc, vous devrez taper cette commande à chaque session dans laquelle vous serez amené à éditer votre crontab. Il n’est pas difficile de rendre permanent ce réglage, mais je me dois de garder cette procédure pour un futur article.

Finalement, entrez cette commande pour créer et éditer votre crontab utilisateur :

crontab -e

( Les autres options crontab sont -l qui affiche votre crontab et -r qui le retire).

Ajoutez votre ligne à votre crontab dans pico comme vous le feriez avec un autre fichier. Mon exemple de job cron, bien sûr, a été réglé pour tourner quotidiennement à 18h30, mais vous voudrez peut être d’abord planifier le vôtre pour qu’il se lance juste quelques minutes après l’avoir sauvegardé pour voir s’il fonctionne correctement.

Assurez-vous d’ajouter une nouvelle ligne vide, ce que cron exige. Voici à quoi ressemble ma session pico :

Finalement, sauvegardez le fichier avec le nom provisoire donné et fermez ensuite pico comme d’habitude. Une fois que vous l’aurez fait, vous verrez une ligne affichée par crontab annonçant que votre nouveau crontab a été installé :

crontab: installing new crontab
[localhost:~] chris%

Vous pouvez avoir la confirmation du bon déroulement de son travail en attendant que le rapport email arrive, ou vous pouvez contrôler son activité en utilisant la commande d’observation des process top. Tout comme l’application GUI d’observation des processus située à l’intérieur du dossier /Applications/Utilities, top affiche les processus courants ligne par ligne. Si vous lancez top avec l’option -u, vous verrez la liste des processus dynamiquement ordonnée du plus actifau moins actif :

[localhost:~] chris% top -u 

Processes: 52 total, 2 running, 2 stuck, 48 sleeping... 137 threads 13:03:21
Load Avg: 0.91, 0.59, 0.41 CPU usage: 6.8% user, 29.9% sys, 63.2% idle
SharedLibs: num = 89, resident = 22.7M code, 1.52M data, 5.87M LinkEdit
MemRegions: num = 3185, resident = 91.2M + 8.32M private, 59.7M shared
PhysMem: 79.0M wired, 58.2M active, 340M inactive, 477M used, 419M free
VM: 2.08G + 44.6M 6656(0) pageins, 0(0) pageouts

PID COMMAND    %CPU   TIME    #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
434 ditto      11.9%  0:02.31   1    16     17  424K  296K  648K 1.79M
436 top         7.6%  0:00.38   1    14     17  268K  320K  524K 1.82M
383 Terminal    5.1%  0:13.65   8   117    243 2.89M 10.7M 8.84M  109M
375 Microsoft   3.4%  6:44.00   2    79    292 12.8M 18.0M 19.7M  119M
0   kernel_tas  2.5%  1:14.20  27     0      -     -     - 64.8M- 733M-
382 CPU Monito  2.5%  0:32.75   1    67     88 1.21M 6.29M 3.07M 100.0
356 Window Man  1.7%  0:59.54   3   156    152 2.01M 20.0M 21.8M 79.5M
376 Microsoft   0.8%  2:14.07   8   128    283 14.3M 31.0M 33.8M  142M
367 Finder      0.0%  0:35.43   2    93    365 21.0M 15.9M 26.1M  130M
377 TextEdit    0.0%  0:34.01   2    93    130 7.56M 9.22M 11.6M  109M

0 idle_threa   63.9%  24:26.99

Là au sommet de la liste vous pouvez voir ditto commencer à tourner. Une fois qu’il aura fini, ce processus quittera la liste. Pour arrêter top et retourner au prompt, pressez juste q. Comme vous pouvez le voir, top vous en dit beaucoup plus sur votre système, commencez donc par regarder sa page man (man top) pour tout en apprendre. Voici aussi une excellente page d’Apple qui décrit la commande top.

Enfin, une fois que vous serez sûr qu’il fonctionne correctement, n’oubliez pas de replanifier votre crontab au moment où vous voulez qu’il soit lancé régulièrement.

Cet article vous a introduit aux bases du scripting de shell et au crontab utilisateur, deux fonctionnalités très puissantes de l’Unix de Mac OS X. Resté branché pour de futurs articles qui vous montreront encore plus de manières d’utiliser cette puissance.

Textes originaux sur O’Reilly : Learning the Mac OS X Terminal : Part 5

Thierry Le Terminal de Mac OS X Mac OS X, shell, terminal, unix