Ajouter cette page à votre livre
Retirer cette page de votre livre
Voir ou modifier le livre ( 
Aide
==== SAVDEP ====
−Table des matières
Le but
Introduction
La haute disponibilité
Généralités sur la sauvegarde
Plan de sauvegarde
Conseil
Les outils de la sauvegarde
Les outils logiciels
Disponibilité du stockage
Bande et cartouches magnétiques
Baie de stockage
Storage virtualization
Sauvegarde hors site
Méthodes de sauvegarde les plus courantes
Sauvegarde complète (full backup)
Sauvegarde différentielle
Sauvegarde incrémentale ou incrémentielle
Sauvegarde Tour de Hanoi
Exemple : sauvegarde complète, incrémentale ou différentielle avec dump
Schéma de principe des TP
Cahier des charges
Impératifs
Annexe
A. Automatisation
1. Avec cron
2. Avec anacron
3. Avec at
4. TP
B. Processus d’un projet
1. Le cahier des charges
2. La décomposition du problème
3. La structure d’un script
4. Les tests et validation
5. La mise en production
Le but
Mettre en place une solution (triviale) de sauvegarde automatisée.
Introduction
Ne pas prévoir, c'est déjà gémir.
(Léonard de Vinci)
L'entreprise gagnante sera celle qui exploitera l'information plus vite et plus efficacement que les autres. Mais comment faire face à une croissance exponentielle de l'information qui peut atteindre 100 % par an dans les réseaux d'entreprise ? Comment “caser” les opérations de sauvegarde dans des fenêtre de temps de plus en plus réduites ?
Pour bien bien comprendre le défi que doivent relever les entreprises, il faut savoir que les hommes ont produit plus d'informations durant ces trente dernières années que pendant les cinq mille ans qui les ont précédées. La masse global d'information double tous les douze à dix huit mois !
En 1999, les spécialiste estimaient que seulement 4 % de la quantité mondiale d'information étaient disponible sous forme numérique. Les 96 % restant sont disponibles sous forme de papier, microfilms, microfiches, etc.
La conservation des informations sur la durée est un des challenges quotidiens de l'administrateurs système. Dans une entreprise, la perte de donnée, qu'elle soit du à un sinistre, à une panne ou à un mauvais usage de l'outils peut conduire à la faillite. La multiplication des postes informatiques dans les entreprises et la montée en volume des données à sauvegarder ont sonné le glas de la sauvegarde épisodique sur média amovibles. Une sauvegarde automatisée et intelligente et la seule solution pour se mettre en sécurité et penser à mettre en place un système de sauvegarde n'est pas suffisant : il faut faire éprouver sa solution !
La haute disponibilité
La haute disponibilité ne consiste pas à fournir un service, mais à garantir sa pérennité et son fonctionnement en toutes circonstances, dans la mesure du possible. C'est donc la mise en oeuvre de tous les moyens nécessaires permettant de garantir un taux de disponibilité convenable à une architecture ou un service informatique. Ceci s'articule autour de deux axes majeurs et complémentaires :
La mise en place d'une infrastructure matérielle et logiciel adaptée. Cette adaptation consiste généralement en la redondance des matériels et des logiciels avec des possibilités de bascule, afin de garantir un minimum d'indisponibilité.
La mise en place de norme et de processus de travail et d'organisation permettant de réduire le risque d'erreur humaines ou de conception.
La première partie est directement du domaine des compétence techniques de l'informaticien et notamment des architectes SI, des ingénieurs système et des ingénieurs réseau.
La seconde partie est du domaine de l'organisation, notamment des normes de fonctionnement de type ISO 900x ou ISO 20000, et des bonnes pratiques dans la gestion des services informatiques, comme ITIL.
La sauvegarde est l'élément le plus important en manière de reprise après incident. Mais la performant se base aussi sur quatre piliers essentiels, qui sont :
les temps de réponse (response time);
la disponibilité (availability);
la robustesse (robustness);
la capacité à monter en charge (scalability).
Pour atteindre ces objectifs le SI mobilise des techniques multiples :
L'accès au stockage : NAS, SAN, multipathing (regrouper n chemins vers un disque en un seul), ISCSI.
L'organisation des données avec la gestion des volume logiques : mirroring, striping, snapshot.
Une configuration avancée du réseau : alias d'interfaces, VLAN, adresses MAC virtuelles, le regroupement de plusieurs interfaces réseau (bonding, pilote team) pour améliorer les performances et la disponibilité, création de tunnel.
Équilibrer la charge des serveurs : LVS, keepalived, MakeAlive, bascule d'adresse IP automatique via le protocole VRRP.
La virtualisation : de serveurs, de postes de travail, d'applications
Le clustering : Pacemaker permettant la bascule et la surveillance de ressources au sein de plusieurs serveurs travaillant en collaboration, clustering des services avec openSVC
Généralités sur la sauvegarde
(todo : notion d'archivage des données)
Les principes d'une bonne stratégie de sauvegarde reste encore et cela même pour des administrateurs système aguerri, mal définis.
En cause :
Charge de travail importante.
Restauration jamais effectué.
Budget
…
Avez-vous déjà croisé un opérateur de sauvegarde, une personne chargé explicitement de cette tache ?
Souvent cette fonction est dévolue à une personne qui n'a pas su dire non ou au stagiaire du moment.
Toute parties d'un système informatique peut être remplacée (même l'administrateur), sauf les données !!
Pour l’utilisateur, il est évident qu'un tel système de récupération de données existe.
Qui veut être la personne qui annonce que la base de données clients sera hors service pendant 3 heures.
Ou qui envoi un mémo a l'ensemble de la société pour signifié que les commandes des deux derniers jours doivent être ressaisis.
Plan de sauvegarde
Il faut développer un plan de reprise d'activité. Ce plan sera activé en cas de sinistre.
Voici quelques questions qui peuvent vous aider à établir ce plan de sauvegarde :
Pourquoi ?
Pourquoi se prémunir contre un désastre ?
Cela est-il vraiment un problème si il y'a perte de données ?
Quelle est la nature des données et quelle en est la valeur ?
Quoi ?
Que faut-il sauvegardé : la machine dans son intégrité ou un volume de stockage particulier ?
Quel système d'exploitation faut-il sauvegardé ?
Quand ?
Quel est le meilleur moment pour faire une sauvegarde ?
La fréquence ?
Quand faire une sauvegarde incrémentale ?
OU ?
Ou faire la sauvegarde ?
Ou stocké les sauvegarde ?
Combien de temps conservera-t’on les sauvegardes ?
Qui ?
Qui va mettre en place le système de sauvegarde : matériels, logiciels, installation… ?
Comment ?
Quelle solution ?
Sauvegarde hors site
Système redondant
Raid
Virtualisation
…
Conseil
Centraliser vos sauvegardes : Utiliser les commandes de sauvegardes réseau ou les logiciels client/serveur.
Étiqueter vos sauvegardes. On doit indiquer :
l'hôte
le FS
type de sauvegarde : complète, incrémentale, différentielle.
la date
le format (tar, tar.gz, cpio, …)
Réaliser (au minimum) :
une sauvegarde incrémentale chaque jour
une sauvegarde complète le week-end (quand le système d'information est le moins sollicité).
Limiter la taille de vos FS à la taille des supports de sauvegarde.
Posséder une copie de vos sauvegardes sensible. Cette copie doit être dans un lieu différent de votre site d'exploitation.
Limiter (au possible) l'exploitation du système informatique durant la sauvegarde (sauvegarde de nuit).
Protéger les sauvegardes.
Les cartouche de sauvegarde ont un cycle de vie limité.
Tester votre plan de reprise d'activité ⇒ réaliser de véritables restaurations.
Les outils de la sauvegarde
Les outils logiciels
sauvegarde de fichier : tar, star, cpio, pax
sauvegarde physique : dd
sauvegarde d'image : partimage, clonezilla, ghost (produit commerciale)
sauvegarde système incrémentale de FS : dump/restore (Ext2/Ext3), wfsdump/xfsrestore (xfs)
sauvegarde complète (Bare Metal) : Mondo
sauvegarde client/serveur : BackupPC (libre), Bacula (libre), Amanda (libre), Arkeia, Veritas NetBackup, Networker, Tina, TSM, …
Synchronisation de répertoires : rsync
Disponibilité du stockage
(–komo– Section a travailler)
(todo cf livre archi. matérielle IUT BTS)
Bande et cartouches magnétiques
TP possible : installation et configuration du sous-systèmes Dell™ PowerVault™ 114T, boîtiers (rack 2U) de stockage sur bande .
Baie de stockage
Storage virtualization
La virtualisation du stockage sera vue dans le cours sur la virtualisation : http://komo.simoko.eu/dokuwiki/doku.php?id=cours:preparationcours:iscsi
Sauvegarde hors site
(–komo– A FAIRE)
TP possible : Stockage réseau - Mise en oeuvre et sécurisation (LM N°118, page 56)
Méthodes de sauvegarde les plus courantes
Sauvegarde complète (full backup)
Elle consiste à copier toutes les données à sauvegarder que celles-ci soient récentes, anciennes, modifiées ou non.
méthode la plus fiable
coûteuse en temps et d'espace disque.
une sauvegarde incrémentale (sens générale) consiste à ne sauvegarder que les modifications effectuées depuis une sauvegarde de référence, la sauvegarde complète.
Sauvegarde différentielle
On sauvegarde les modifications en se basant toujours sur la dernière sauvegarde complète.
Les sauvegardes sont de plus en plus longues et volumineuse.
La restauration complète ne nécessite que la sauvegarde complète et la dernière sauvegarde différentielle.
Cependant lorsqu'il s'agit de la restauration d'un fichier ou d'un répertoire qui a été sauvegardé le jour J+2 seule la sauvegarde du dit jour, ici la différentielle, est utile.
Sauvegarde incrémentale ou incrémentielle
Chaque sauvegarde incrémentale, devient la référence de la sauvegarde incrémentale suivante.
Les sauvegardes sont petites et courtes.
Une restauration complète nécessite de restaurer toutes les archives.
Cependant lorsqu'il s'agit de la restauration d'un fichier ou d'un répertoire qui a été sauvegardé le jour J+3, seule la sauvegarde du dit jour, ici incrémentielle, est utile.
Sauvegarde Tour de Hanoi
L'ordonnancement de la Tour de Hanoi est plus complexe. Il est basé sur l'algorithme ” Tour de Hanoi”.
Ses objectif sont de minimiser les temps de sauvegarde et de restauration et surtout de faire en sorte que chaque fichier soit sauvegardé au moins deux fois.
http://en.wikipedia.org/wiki/Backup_rotation_scheme
niveau 0 : sauvegarde complète
Dans une sauvegarde à un niveau donné, on ne sauvegarde que les modifications effectuées depuis la sauvegarde de niveau inférieur.
Exemple : sauvegarde complète, incrémentale ou différentielle avec dump
Utiliser ces commandes avec précautions, ainsi dump f /dev/sdc1 /rep la sauvegarde utilise tout l'espace disque et détruit le formatage du disque, i.e son organisation en tant que système de fichiers !!
Vaut mieux spécifier un fichier ordinaire contenu dans le disque.
0. Installer l'utilitaire dump :
# aptitude install dump
1. Peupler notre système de fichier (sur la clé USB)
Si on a pas de clé USB disponible, on pourra créer un système de fichiers dans un fichier :
mkdir mntTemp
touch virtualFS
dd if=/dev/zero of=virtualFS bs=128M count=1
mkfs.ext3 virtualFS
du -sh virtualFS
mount -o loop virtualFS mntTemp/
mount
touch mntTemp/file
ls mntTemp/
umount mntTemp/
mount
mohamed@KL-PO-A-MKO-01:/media$ sudo mount /dev/sdc1 cleusb/
root@KL-PO-A-MKO-01:/media/cleusb# cal > f1
root@KL-PO-A-MKO-01:/media/cleusb# date > f2
root@KL-PO-A-MKO-01:/media/cleusb# mkdir rep
root@KL-PO-A-MKO-01:/media/cleusb# uptime > rep/fic
root@KL-PO-A-MKO-01:/media/cleusb# cd
root@KL-PO-A-MKO-01:~#
2. Effectuer une sauvegarde complète du FS
root@KL-PO-A-MKO-01:~# dump 0uf /tmp/sauve_0.dump /dev/sdc1
On aurait pu indiquer /media/cleusb si le FS avait été inscrit dans le /etc/fstab
/var/lib/dumpdates contient l'historique des sauvegardes incrémentales.
root@KL-PO-A-MKO-01:~# cat /var/lib/dumpdates
/dev/sdc1 0 Mon Oct 20 00:58:01 2008 +0200
3. lister le contenu de la sauvegarde.
root@KL-PO-A-MKO-01:~# restore -tvf /tmp/sauve_0.dump
Verify tape and initialize maps
Input is from a local file/pipe
Input block size is 32
Dump date: Mon Oct 20 00:58:01 2008
Dumped from: the epoch
Level 0 dump of /media/cleusb on KL-PO-A-MKO-01:/dev/sdc1
Label: none
Extract directories from tape
Initialize symbol table.
Dir 2 .
dir 11 ./lost+found
leaf 6145 ./f1
leaf 6146 ./f2
dir 88065 ./rep
leaf 88066 ./rep/fic
4. Effectuer une sauvegarde incrémentale.
root@KL-PO-A-MKO-01:~# cp /etc/profile /media/cleusb
root@KL-PO-A-MKO-01:~# dump 1uf /tmp/sauve_1.dump /dev/sdc1
root@KL-PO-A-MKO-01:~# cat /var/lib/dumpdates
/dev/sdc1 0 Mon Oct 20 00:58:01 2008 +0200
/dev/sdc1 1 Mon Oct 20 01:07:55 2008 +0200
5. Restaurer l'intégralité du FS
root@KL-PO-A-MKO-01:~# mkfs.ext3 /dev/sdc1 <= on simule un probleme en reformatant la partition
root@KL-PO-A-MKO-01:/media/cleusb# restore -rvf /tmp/sauve_0.dump
Verify tape and initialize maps
Input is from a local file/pipe
Input block size is 32
Dump date: Mon Oct 20 00:58:01 2008
Dumped from: the epoch
Level 0 dump of /media/cleusb on KL-PO-A-MKO-01:/dev/sdc1
Label: none
Begin level 0 restore
Initialize symbol table.
Extract directories from tape
Calculate extraction list.
restore: ./lost+found: File exists
Make node ./rep
Extract new leaves.
Check pointing the restore
extract file ./f1
extract file ./f2
extract file ./rep/fic
Add links
Set directory mode, owner, and times.
Check the symbol table.
Check pointing the restore
root@KL-PO-A-MKO-01:/media/cleusb# restore -rvf /tmp/sauve_1.dump
Verify tape and initialize maps
Input is from a local file/pipe
Input block size is 32
Dump date: Mon Oct 20 01:07:55 2008
Dumped from: Mon Oct 20 00:58:01 2008
Level 1 dump of /media/cleusb on KL-PO-A-MKO-01:/dev/sdc1
Label: none
Begin incremental restore
Initialize symbol table.
Extract directories from tape
Mark entries to be removed.
Calculate node updates.
Find unreferenced names.
Remove old nodes (directories).
Extract new leaves.
Check pointing the restore
extract file ./rep/profile
Add links
Set directory mode, owner, and times.
Check the symbol table.
Check pointing the restore
root@KL-PO-A-MKO-01:/media/cleusb# find
.
./rep
./rep/fic
./rep/profile
./restoresymtable
./f1
./lost+found
./f2
On doit restaurer l'archive complète (de niveau 0) et ensuite l'archive incrèmentale (de niveau 1)
6. Restaurer un fichier.
a) on détruit un fichier par erreur
root@KL-PO-A-MKO-01:/media/cleusb# rm -f f1
b) on le restaure.
root@KL-PO-A-MKO-01:/media/cleusb# restore -xvaof /tmp/sauve_0.dump ./f1
root@KL-PO-A-MKO-01:/media/cleusb# ls -l f1
-rw-r--r-- 1 root root 168 2008-10-20 00:53 f1
7. Restaurer un fichier de manière interactive.
a) on détruit un fichier par erreur
root@KL-PO-A-MKO-01:/media/cleusb# rm -f f1
b) on le restaure.
root@KL-PO-A-MKO-01:/media/cleusb# restore -if /tmp/sauve_0.dump
restore > help
Available commands are:
ls [arg] - list directory
cd arg - change directory
pwd - print current directory
add [arg] - add `arg' to list of files to be extracted
delete [arg] - delete `arg' from list of files to be extracted
extract - extract requested files
setmodes - set modes of requested directories
quit - immediately exit program
what - list dump header information
verbose - toggle verbose flag (useful with ``ls'')
prompt - toggle the prompt display
help or `?' - print this list
If no `arg' is supplied, the current directory is used
restore > what
Dump date: Mon Oct 20 00:58:01 2008
Dumped from: the epoch
Level 0 dump of /media/cleusb on KL-PO-A-MKO-01:/dev/sdc1
Label: none
restore > ls
.:
f1 f2 lost+found/ rep/
restore > cd rep
restore > pwd
/rep
restore > ls
./rep:
fic
restore > add fic
restore: ./rep: File exists
restore > ls
./rep:
*fic
restore > del fic
restore > ls
./rep:
fic
restore > cd ..
restore > pwd
/
restore > add f1
restore > ls
.:
*f1 f2 lost+found/ *rep/
restore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume # (none if no more volumes): 1
set owner/mode for '.'? [yn] n
restore > quit
root@KL-PO-A-MKO-01:/media/cleusb# ls -l f1
-rw-r--r-- 1 root root 168 2008-10-20 00:53 f1
Pour un exemple avec la commande tar : http://doc.ubuntu-fr.org/tar et aussi http://linux-backup.net/Full_Inc/
Pour les autres commandes :
voir tache 2 : dd
voir tache 3 : Sauvegarde en réseau
voir tache 4 : Sauvegarde dump en réseau
Doc sur rsync :
http://www.linuxfocus.org/Francais/March2004/article326.shtml
http://www.mikerubel.org/computers/rsync_snapshots/
Schéma de principe des TP
environnement_reseau_tp.jpeg
Pour la mise en place de la topologie, vous pouvez suivre le document suivant : Répertoires utilisateurs déportés sur le serveur Freenas
Cahier des charges
Sauvegarde automatisée à travers le réseau des réperotires utilisateurs du serveur nas sur le servBackup.
Sauvegarde incrémentale.
On doit pouvoir restaurer le volume (ou le répertoire /home) dans son intégralité.
On doit pouvoir restaurer un fichier unique.
Le programme doit écrire dans un fichier journal (log).
– Pour komo – Un message sera transmis au mécanisme SYSLOG du serveur, pour indiquer si le script s’est terminé correctement ou avec des erreurs 1).
Envoi d'un mail de notification (états des opérations, fichiers sauvegardé…)
Le serveur nas est-il accessible ?
Ce script s’exécute à partir d’une crontab
Une exécution manuelle permet un affichage d’informations sur la sortie standard. Les sauvegardes doivent pouvoir être lancées manuellement ou automatiquement. L’exécution manuelle est nécessaire lors d’une sauvegarde prévue avant une manipulation d’administration sur le serveur.
Ce script est principalement conçu pour une exécution en arrière-plan ; donc un nombre limité de messages envoyés vers les sorties standard du système.
Questions :
Doit-on créer un utilisateur pour la sauvegarde (expl : usrbackup) et avec quels droits.
Doit-on créer un groupe (expl : grpadmin) qui donnera le droits a certains utilisateurs d'effectuer la sauvegarde.
A quel endroit de l'arborescence unix doit être stocké le script.
A quel endroit de l'arborescence unix doit être stocké le fichier de log.
…
Impératifs
Le TP est à faire en trinôme.
On utilisera un système de gestion de version distribué : git sur github (–komo– A VOIR).
Langage de programmation : bash, des cours sont disponibles ici et ici .
Le script tourne sur la machine SrvBackup
Un document détaillé sur la réalisation de la solution sera fourni sous la forme d'un wiki.
Une présentation orale appuyée par :
Un support de présentation
une démonstration des fonctionnalités de la solution
La réalisation du TP entre dans l’évaluation de l'ECF1
Annexe
A. Automatisation
1. Avec cron
a. Présentation
Le service cron permet la programmation d’événements à répétition. Il fonctionne à l’aide d’une table, appelée une crontab. C’est un fichier texte, éditable avec un simple éditeur, par exemple vi. Pour modifier votre crontab personnelle utilisez la commande crontab pour éditer la table, avec le paramètre -e.
Les fichiers crontab sont sauvés dans /var/spool/cron.
Le service cron doit tourner pour que les crontab soient actives.
debianKVM1:~# ps -ef|grep cron
root 1849 1 0 14:02 ? 00:00:00 /usr/sbin/cron
b. Formalisme
Le fichier crontab utilisateur est composé de deux types de lignes :
les lignes d'initialisation de variables d'environnement : elles permettent de définir l'environnement dans lequel les travaux cron doivent être exécutés.
Ce qui suit est tiré du man (man 5 crontab) :
Les lignes blanches, les espaces et tabulations en début de lignes sont ignorées. Les lignes dont le premier caractère non blanc est un dièse (#) sont considérées comme des commentaires, et sont également ignorées.
Une ligne d’affectation d’environnement est de la forme :
nom = valeur
La chaîne valeur ne supporte pas les substitutions environnementales, ainsi une ligne comme :
PATH = $HOME/bin:$PATH
ne fonctionnera pas comme attendu.
Plusieurs variables d’environnement sont automatiquement définies par le démon cron(8). SHELL prend la valeur /bin/sh, LOGNAME et HOME sont définies à partir de la ligne de /etc/passwd correspondant au propriétaire de la crontab. PATH est définie à /usr/bin:/bin. HOME, SHELL et PATH peuvent être réaffectées explicitement dans la crontab contrairement à LOGNAME, qui est l’utilisateur ayant lancé la tâche.
En plus de LOGNAME, HOME, et SHELL, cron(8) prendra en compte la variable MAILTO s’il doit envoyer le résultat d’une commande exécutée depuis « cette » crontab. Si MAILTO est définie (et non vide), le résultat est envoyé à l’utilisateur indiqué. Si MAILTO est définie mais vide (MAILTO=””), aucun courriel ne sera envoyé. Sinon, le courriel sera envoyé au propriétaire de la crontab.
les lignes de commandes pour le démon cron : elles définissent les travaux à lancer périodiquement.
Chaque ligne dispose de 5 champs de date et d’heure, suivis d’une commande et enfin d’un retour à la ligne (\n). Le système crontab (/etc/crontab) utilise le même format, si ce n’est que le champ utilisateur est indiqué après les champs de date et d’heure mais avant la commande. Les champs peuvent être séparés par des espaces ou des tabulations.
Le format d’un enregistrement de crontab est le suivant :
Utilisez le format suivant pour les valeurs périodiques :
Une valeur pour indiquer quand il faut exécuter la commande. Ex : la valeur 15 dans le champ minute signifie la quinzième minute.
Une liste de valeurs séparées par des virgules. Ex : 1,4,7,10 dans le champ mois pour janvier, avril, juillet, octobre.
Un intervalle de valeurs. Ex : 1-5 dans le champ jour de la semaine indique du lundi (1) au vendredi (5). Le 0 (ou 7) est le dimanche et le 6 le samedi.
Le caractère * pour toutes les valeurs possibles. Ex : * dans le champ jour du mois indique tous les jours du ou des mois.
À la place des cinq premiers champs peut apparaître l’une des huit chaînes spéciales :
chaîne signification
@reboot Exécuter une fois au démarrage.
@yearly Exécuter une fois par an, « 0 0 1 1 * ».
@annually (idem que @yearly)
@monthly Exécuter une fois par mois, « 0 0 1 * * ».
@weekly Exécuter une fois par semaine, « 0 0 * * 0 ».
@daily Exécuter une fois par jour, « 0 0 * * * ».
@midnight (idem que @daily)
@hourly Exécuter une fois par heure, « 0 * * * * ».
c. Exemples
Exécution de df tous les jours, toute l’année, tous les quarts d’heure :
0,15,30,45 * * * * df > /tmp/libre
Exécution d’une commande tous les jours ouvrables à 17 heures :
0 17 * * 1-5 fin_travail.sh
Lister les crontab actives :
$ crontab -l
Supprimer la crontab active :
$ crontab -r
Éditer la crontab d’un utilisateur particulier :
# crontab -u user -e
EXEMPLE DE FICHIER CRONTAB
# Utiliser /bin/bash pour lancer les commandes, plutôt que le shell par
# défaut /bin/sh
SHELL=/bin/bash
# Envoyer les résultats à Paul, sans tenir compte du propriétaire
MAILTO=paul
#
# Exécuter chaque jour, 5 minutes après minuit
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# Exécuter le premier de chaque mois à 14 h 15 - Résultat envoyé à Paul
15 14 1 * * $HOME/bin/monthly
# Énerver Joe du lundi au vendredi à 22 h
0 22 * * 1-5 mail -s "Il est 22 h" joe%Joe,%%Où sont tes enfants ?%
23 0-23/2 * * * echo "Tous les jours, 23 mn après 0 h, 2 h, 4 h..."
5 4 * * sun echo "Tous les dimanches à 4 h 05"
d. crontab système
La configuration crontab générale pour le système est dans /etc/crontab.
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
Ici tous les jours à 4h02 du matin run-parts /etc/cron.daily est exécuté. Le script run-parts accepte en paramètre un répertoire et exécute tous les programmes présents dans ce répertoire.
debianKVM1:~# ls /etc/cron.daily/
apt aptitude bsdmainutils exim4-base logrotate man-db mlocate standard
Parmi les programmes exécutés, remarquez logrotate qui permet d’effectuer des sauvegardes et de renommer des fichiers logs et des journaux du système afin que ceux-ci ne deviennent pas inexploitables à cause de leur taille.
Enfin, le répertoire /etc/cron.d contient des crontab supplémentaires.
e. Contrôle d’accès
Vous pouvez contrôler l’accès à la commande crontab par utilisateur avec les fichiers /etc/cron.allow et /etc/cron.deny.
Si le fichier /etc/cron.allow existe, alors vous devez être mentionné dans celui-ci pour pouvoir utiliser cette commande.
S’il n’existe pas, mais que le fichier /etc/cron.deny existe, alors vous ne devez pas être mentionné dans celui-ci si vous désirez utiliser cette commande.
Si aucun de ces deux fichiers n’existe, alors, selon la configuration du site, soit seul le superutilisateur a le droit d’utiliser cette commande, soit tous les utilisateurs le peuvent. Sur les systèmes Debian standards, tous les utilisateurs peuvent l’utiliser.
f. Crontab en mode graphique
http://doc.ubuntu-fr.org/gnome-schedule
2. Avec anacron
a. Présentation
Beaucoup de systèmes Unix sont configurés de façon à exécuter périodiquement un certain nombre de tâches de maintenance : suppression de fichiers inutilisés, archivage de journaux, indexation de fichiers, etc… On souhaite souvent que l'exécution de ces tâches se fasse dans une période où la charge système est faible, par exemple durant la nuit, pour ne pas contraindre l'utilisateur.
En utilisant cron, si le système est éteint au moment où la tâche était planifiée, elle ne s'effectuera pas cette fois-ci, et il faudra attendre l'occurrence suivante pour voir la tâche s'effectuer. anacron, à son démarrage, vérifie pour chaque tâche si elle a été lancée dans les n derniers jours, n étant la périodicité définie pour cette tâche. Si la réponse est non, anacron lance la commande relative à la tâche. Si donc, la machine était éteinte au moment exact où la tâche aurait dû s'effectuer pour respecter la période de n jours, on l'exécute au prochain démarrage d'anacron.
(WikiPédia)
On vérifie que le démon anacron existe :
ls -l /etc/init.d/anacron
lrwxrwxrwx 1 root root 21 2010-10-15 12:45 /etc/init.d/anacron -> /lib/init/upstart-job
b. Formalisme et exemples
Quand il fonctionne, anacron lit une liste de tâches définies dans un fichier de configuration, normalement /etc/anacrontab (voir anacrontab(5)). Ce fichier contient la liste des tâches qu'anacron contrôle. Chaque ligne de la liste précise une période en jours, un délai en minutes, un identifiant unique pour la tâche, et une commande d'un interpréteur de commandes.
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# These replace cron's entries
1 5 cron.daily nice run-parts --report /etc/cron.daily
7 10 cron.weekly nice run-parts --report /etc/cron.weekly
@monthly 15 cron.monthly nice run-parts --report /etc/cron.monthly
anacron n'est pas un daemon qui tourne en permanence sur une machine : il vérifie s'il y a des tâches à exécuter, les exécute éventuellement, puis se termine. Autrement dit, il doit y avoir un autre système qui s'assure qu'anacron est lancé périodiquement : il nécessite donc d'être lancé par des scripts de démarrage, par des tâches cron (on utilise bien souvent une tâche cron.hourly), ou encore d'être lancé manuellement.
debianKVM1:~# cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
Le démon anacron est lancé depuis le crontab système si celui-ci existe, sinon le démon cron exécute les fichiers présents dans le répertoire /etc/cron.daily.
3. Avec at
a. Présentation
La commande at et les commandes associées permettent une gestion des traitements batchs. Contrairement à la crontab les modifications sont volatiles : elles sont perdues lorsque la session est terminée. C’est à vous de placer la liste des commandes dans un éventuel fichier et de le charger au besoin via les scripts de votre profil.
Pour que at fonctionne le service atd (at daemon) doit fonctionner.
$ ps -ef | grep atd
daemon 1829 1 0 14:02 ? 00:00:00 /usr/sbin/atd
b. Formalisme et exemples
Pour simplifier, il y a deux moyens d’utiliser at :
en lui passant de manière interactive une ligne de commande,
en lui passant un fichier exécutable contenant les commandes à exécuter.
Dans les deux cas, vous devez fournir à at une heure d’exécution. Le formalisme de cette heure est assez souple. Pour programmer l’exécution d’une ligne de commande à 21h20 de manière interactive :
debianKVM1:~# tty
/dev/pts/0
debianKVM1:~# at 21:20
warning: commands will be executed using /bin/sh
at> echo salut > /dev/pts/0
at> <EOT>
job 12 at Sun Dec 5 21:20:00 2010
debianKVM1:~# salut
Heure
L’heure peut être formatée ainsi :
HHMM ou HH:MM.
L’heure peut être au format 12 ou 24h. Au format 12 heures, vous pouvez préciser AM (matin) ou PM (après-midi).
Midnight (minuit), noon (midi), teatime (16h00, typiquement anglais).
MMJJAA, MM/JJ/AA ou JJ.MM.AA pour une date précise.
Now : maintenant.
+ n minutes/hours/days/weeks : l’heure courante auquel on ajoute n minutes/heures/jours/semaines.
Si l’heure précisée est inférieure à l’heure actuelle, la commande est exécutée le lendemain.
$ at 21:30 09.05.2008
warning: commands will be executed using /bin/sh
at> echo salut !
at> <EOT>
job 9 at 2008-05-09 21:30
$ at now + 2 days
warning: commands will be executed using /bin/sh
at> echo dans deux jours
at> <EOT>
job 10 at 2008-05-10 21:29
Note : La commande batch exécute les commandes indiquées lorsque la charge système le permet, c’est à dire lorsque la charge du processeur descend sous 1.5, ou en dessous d’une valeur mentionnée explicitement durant l’invocation de atd.
c. Contrôle des tâches
La commande atq (at queue) permet de lister les tâches programmées :
debianKVM1:~# atq
14 Sun Dec 5 21:25:00 2010 a root
13 Sun Dec 5 21:20:00 2010 a root
Les jobs (tâches) sont placées dans le répertoire /var/spool/cron/atjobs/, à raison de un exécutable par tâche.
debianKVM1:~# ls -l /var/spool/cron/atjobs/
total 8
-rwx------ 1 root daemon 607 déc 5 17:25 a0000d01487744
-rwx------ 1 root daemon 638 déc 5 17:31 a0000e01487749
Si vous regardez le contenu de l’exécutable, vous voyez que votre commande n’est pas seule. Elle est située à la fin, mais le script positionne tout l’environnement lors de la création de l’entrée at.
debianKVM1:~# cat /var/spool/cron/atjobs/a0000d01487744
#!/bin/sh
# atrun uid=0 gid=0
# mail root 0
umask 22
SSH_CLIENT=192.168.0.11\ 44867\ 22; export SSH_CLIENT
SSH_TTY=/dev/pts/0; export SSH_TTY
USER=root; export USER
MAIL=/var/mail/root; export MAIL
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; export PATH
PWD=/root; export PWD
LANG=fr_FR.UTF-8; export LANG
PS1=\\h:\\w\\\$\ ; export PS1
SHLVL=1; export SHLVL
HOME=/root; export HOME
LOGNAME=root; export LOGNAME
SSH_CONNECTION=192.168.0.11\ 44867\ 192.168.0.218\ 22; export SSH_CONNECTION
cd /root || {
echo 'Execution directory inaccessible' >&2
exit 1
}
echo salut > /dev/pts/0
La commande atrm permet de supprimer une tâche :
debianKVM1:~# atq
14 Sun Dec 5 21:25:00 2010 a root
13 Sun Dec 5 21:20:00 2010 a root
debianKVM1:~# atrm 14
debianKVM1:~# atq
13 Sun Dec 5 21:20:00 2010 a root
d. Contrôle d'accès
Vous pouvez contrôler l’accès à la commande at par utilisateur avec les fichiers /etc/at.allow et /etc/at.deny.
Si le fichier /etc/at.allow existe, seuls les utilisateurs dont les noms sont mentionnés dans ce fichier peuvent utiliser at.
Si /etc/at.allow n’existe pas, at vérifie si /etc/at.deny existe, et tous les utilisateurs non mentionnés dans ce fichier ont alors le droit d’invoquer at.
Si aucun de ces deux fichiers n’existe, seul le superutilisateur a le droit d’appeler at.
Un fichier /etc/at.deny vide signifie que tous les utilisateurs ont le droit d’appeler ces commandes ; c’est la configuration par défaut.
4. TP
Cf livre “Linux Entraînez-vous à administrer le système” :
Énoncé : page 59 - 62
Corrigé : page 173 - 180
B. Processus d’un projet
1. Le cahier des charges
Le cahier des charges est un document contractuel du maître d’ouvrage (le demandeur) définissant le travail attendu par le maître d’œuvre (le réalisateur).
Il définit les besoins et les contraintes du projet que le maître d’œuvre doit respecter (environnement réseau, plate-forme de déploiement, conventions de nommage, etc).
Dans l’idéal, tous les besoins et contraintes doivent être définis dès le début, permettant au maître d’œuvre de proposer une solution à la problématique de son client. Le maître d’ouvrage demande une solution adaptée à son besoin sans avoir les connaissances techniques nécessaires pour avoir une idée de la solution la plus adaptée.
C’est au maître d’œuvre de proposer les différentes possibilités en exposant les avantages et inconvénients de chaque solution.
Au fur et à mesure de l’évolution du projet, le client peut demander une ou des modifications ; au maître d’œuvre d’accepter ou de refuser ces modifications en expliquant au client pourquoi les évolutions demandées ne sont pas pertinentes.
Il est important que le maître d’œuvre et le maître d’ouvrage soient bien d’accord avant de commencer le travail. Il faudra porter une attention toute particulière et bien différencier une contrainte (à respecter obligatoirement) d’une préférence (à respecter si on peut, en général si cela n’est pas trop contraignant).
2. La décomposition du problème
Lors de la rédaction d’un script, il faut bien analyser ce qui sera spécifique au script et ce qui sera commun à plusieurs scripts.
Dans un script, plusieurs tâches répétitives sont à effectuer, comme le contrôle d’erreurs. Il faudra alors faire appel à des fonctions pour réaliser ces tâches.
Il est important de bien structurer le script. Pour cela, on utilise souvent des fonctions. Leur avantage est qu’on peut les regrouper dans un fichier et indiquer au script grâce à une instruction include d’aller consulter le fichier pour la définition des fonctions utilisées au sein du script. Cette méthode de centralisation des fonctions au sein d’un fichier est très usitée. Si vous avez besoin au sein d’un autre script d’utiliser à nouveau cette fonction, il suffit d’ajouter l’instruction include correspondant.
La même méthode peut être utilisée pour définir des variables qui interviennent dans plusieurs scripts.
3. La structure d’un script
Il faut toujours structurer un programme de façon cohérente afin de le rendre le plus lisible possible. Pour cela, le script peut être indenté lors de l’utilisation de boucles, ce qui permet une lecture plus aisée.
Il est aussi conseillé de le commenter pour décrire ce que fait chaque partie du programme. Pour des actions récurrentes (test de cohérence par exemple), créer des fonctions est une pratique courante. Les fonctions sont toujours en début de script car elles doivent être déclarées quand on y fait appel.
Il faut aussi utiliser des variables plutôt que des chemins ou des valeurs qui apparaissent en « dur » dans votre script. Ainsi, si vous déportez votre script dans un autre environnement de travail, vous n’avez qu’à modifier quelques variables au début du script. Vous ne risquez pas d’oublier de modifier une valeur au sein de votre script.
4. Les tests et validation
Après avoir écrit le programme, il est important de le tester surtout pour avoir une meilleure idée des effets de bords. En effet, il faut que tous les cas de mauvaise utilisation du programme aient été prévus. Dans ce cas, un message d’aide est affiché indiquant la syntaxe d’utilisation du script.
Si vous soupçonnez un mauvais fonctionnement du script, vous pouvez faire afficher des messages visuels grâce à la commande echo. Cela permet d’être sûr que le programme passe bien par la boucle ou par l’instruction désirée.
Le script peut aussi être lancé en mode débogage pour avoir une meilleure idée des actions qu’il exécute.
Après exécution du script, vérifiez bien que les actions demandées ont été effectuées (création d’utilisateur, sauvegardes, etc).
5. La mise en production
Après avoir effectué tous les tests nécessaires sur des machines de tests, la solution est déployée sur les machines en production. Lors de cette phase, le maître d’ouvrage valide la solution mise en place par le maître d’œuvre.
Cette phase est appelée « recette » car le client réceptionne la solution que vous avez mis en place.
Le maître d’œuvre va vérifier par une série de tests si votre réalisation correspond bien à ce qui a été demandé dans le cahier des charges.
Le maître d’ouvrage signe alors le procès verbal de bon fonctionnement de votre solution, ce qui conclut le contrat.
Le client peut aussi signer une recette provisoire (si cela est spécifié dans le cahier des charges). Il signera la recette définitive qu’après une période de surveillance, lui permettant de s’assurer que le script ne génère pas des effets indésirables.
6. La période de surveillance
Après la validation du client, il faut tout de même durant une période définie s’assurer que le script ne génère pas des effets indésirables (encombrement réseau, ralentissement du serveur, etc.).
Pour cela, il est possible de visualiser les fichiers de journalisation (les logs) qu’il génère et de vérifier qu’il effectue bien les actions demandées.
Il sera aussi utile de surveiller la charge système qu’engendre les scripts en utilisant les commandes appropriées pour visualiser : la vitesse de lecture, d’écriture, la bande passante du réseau, etc. Cette surveillance peut mettre en évidence des goulots d’étranglement que ce soit au niveau du réseau ou au niveau des accès disque, ou tout simplement permettre d’identifier des périodes plus propices à l’exécution des scripts.
Voici quelques commandes de surveillance :
Pour la mémoire et les processus :
# free
# top
# vmstat
# vmstat 5 10 (10 requêtes, une toutes les 5 secondes)
Pour les statistiques d’entrée/sortie sur les disques :
# iostat
# iostat -d 3 10 (10 requêtes, une toutes les 3 secondes)
Pour l’activité CPU :
# sar
# sar -u 2 5 (5 requêtes, une toutes les 2 secondes)
# sadc
# mpstat
La commande sysstat regroupe la plupart des commandes de surveillance système ci-dessus.
1) http://www.unixgarden.com/index.php/gnu-linux-magazine-hs/installer-un-serveur-syslog
