Mandriva Club - KB

Dans Konqueror, vous venez de cliquer sur un fichier et de presser les touches MAJ + SUPPR ? Eh mais… Saperlipopette ! Je ne devais pas effacer ça, nom de nom !!!! Trop tard, le fichier est définitivement irrécupérable avec votre travail de la journée… Ou alors, en console, vous venez de taper quelque chose comme ceci :

Pour éviter cette situation, il vous est proposé ici une "sauvegarde" systématique qui vous évitera de perdre inconsidérément vos données quand vous faites des bêtises en fin de journée, sous l'empire de la fatigue ou d'une bonne migraine.

ATTENTION ce qui est proposé ne tient lieu en aucune façon d'une véritable sauvegarde de vos disques locaux sur des disques externes ou sur des disques d'autres machines, sauvegarde qui reste en tout état de cause absolument indispensable !!

Nous exploitons dans ce qui suit les LIENS EN DUR. Je vous recommande donc de regarder, avant d'aller plus loin, la page sur les liens en dur et les liens symboliques et même, pour commencer, la page générale sur les liens. Nous supposerons ces contenus bien assimilés…

Les scripts proposés ici le sont évidemment sans garantie. Prenez-les comme des suggestions et n'hésitez pas à les modifier à votre guise.
Même si le problème posé plus haut ne vous paraît pas essentiel, notez bien que lire ces pages attentivement devrait être aussi pour vous une bonne occasion d'apprendre des choses sur les scripts et sur le système Linux.
Tout ce qui suit est une simple implémentation d'idées originales de FF_Olivier du forum de Geckozone.

Note sur l'installation des scripts

Il existe différentes façons d'installer un script sur son système pour le mettre à la disposition de l'ensemble des utilisateurs. Cette question est évidemment indépendante de notre propos. Néanmoins, pour fixer les idées et donner des exemples précis, je vais décrire brièvement comment je procède et donnerai dans la suite les exemples en fonction de cette description.

Le répertoire /opt contient les applications que j'installe moi-même sans passer par RPM, soit que je les compile moi-même, soit que je les installe par le biais d'archives précompilées. Bien que ce ne soit pas strictement indispensable, /opt est situé, chez moi, sur une partition différente de '/' (mais '/opt' est monté dans '/', bien sûr), de façon à pouvoir conserver son contenu en cas de réinstallation du système dans '/'.

C'est à la racine de /opt que je copierai donc les scripts dont il est question ici.

D'autre part, toutes les applications de /opt sont chez moi lancées par un lien situé dans le répertoire /usr/local/bin. Ce répertoire doit être dans le $PATH de chaque utilisateur. Je créerai donc dans /usr/local/bin un lien pour chacun des scripts proposés ici que j'utiliserai.

Dans ce qui suit, deux solutions concurrentes sont proposées. Vous pourrez employer :

Bien entendu, vous restez libre d'installer les scripts d'une autre manière qui vous conviendrait mieux ou vous serait plus habituelle.

Présentation générale de la protection

Effacer un fichier n'est irrémédiable que si ce fichier ne possède qu'un seul 'nom'. Créer un lien en dur pour un fichier c'est lui donner un 'nom' supplémentaire. L'idée de base de notre mécanisme de protection est donc de créer un lien en dur supplémentaire pour chacun des fichiers à protéger, lien qui sera stocké ailleurs sur le disque dur, bien à part : une fois ceci fait si, dans un répertoire protégé, vous effacez maintenant un fichier, alors vous pourrez encore y accéder (et le restaurer par copie) à partir du lien en dur créé par la procédure que nous proposons ici.

Vous trouverez ici un script appelé sauvliens.sh (cliquez sur son nom pour y accéder). Ce script peut être lancé avec ou sans l'argument 'init'.

Lorsque vous lancerez le script "sauvliens.sh" avec l'argument 'init' (sans les guillemets), comme ceci :

alors, le script créera, dans un certain sous-répertoire, une réplique complète de l'arborescence (c'est-à-dire de l'emboîtement des répertoires et sous-répertoires) du répertoire que vous souhaitez protéger. Ensuite, il créera, dans cette arborescence, un lien en dur pour chaque fichier régulier du répertoire à protéger.

Le répertoire qui contiendra les liens en dur créés par sauvliens.sh s'appellera, pour chaque utilisateur : .sauvliens (le point initial de son nom en fait un 'répertoire caché'). Il sera situé à la racine du répertoire à protéger. Si vous y tenez vraiment, vous pourrez modifier le nom du répertoire qui contiendra les liens en dur, ainsi que sa position dans l'arborescence, en changeant la valeur assignée dans le script à certaines variables : NOM_DIR_LIENS et DIR_LIENS.

Ensuite, il faudra faire en sorte d'étendre cette protection aux fichiers réguliers nouvellement créés. C'est ce que fera le script lorsqu'on l'appellera sans argument, simplement comme ceci :

Il ne restera plus qu'à lancer ce script toutes les cinq minutes. Le démon crond pourra s'en charger pour nous, si nous éditons notre crontab d'utilisateur de telle sorte qu'elle contienne une ligne comme celle-ci :

*/5 * * * * /usr/local/bin/sauvliens.sh

Notez bien que chaque utilisateur y compris root doit éditer ainsi sa propre crontab et doit le faire évidemment en lançant la commande crontab -e (ou éventuellement en exploitant les outils graphiques de Mandriva) sous sa propre identité. Pour plus de détails sur l'édition d'une crontab, voir la page sur crond.

Quel répertoire protéger ?

L'identité du répertoire sauvegardé varie selon que le script sauvliens.sh est lancé par un simple utilisateur ou par root. S'il est lancé par un utilisateur, c'est le répertoire personnel de l'utilisateur qui est protégé et s'il est lancé par root, c'est /etc qui le sera. L'identité du répertoire préservé peut cependant être aisément modifiée.

if [ "`id -un `"  != "root" ] ; then # si simple utilisateur on sauve tout le répertoire personnel DIR_A_SAUVER=$HOMEelse # si root on sauve seulement /etc DIR_A_SAUVER=/etcfi

Il serait facile de modifier cela et, par exemple, si vous souhaitiez restreindre le répertoire protégé, pour l'utilisateur, au répertoire Documents, et pour root, à X11, vous devriez modifier le passage qui précède de telle sorte qu'il corresponde à ceci :

if [ "`id -un `"  != "root" ] ; then # si simple utilisateur on sauve seulement le répertoire Documents DIR_A_SAUVER=$HOME/Documentselse # si root on sauve seulement /etc/X11 DIR_A_SAUVER=/etc/X11fi

Toutefois, notez bien que la logique du script sauvliens.sh est de sauvegarder un répertoire par utilisateur.

Cela me convient très bien et c'est ce que j'utilise. Mais on pourrait imaginer aussi que certains utilisateurs préfèrent sauvegarder plutôt de la sorte, non pas un unique vaste répertoire, mais un certain ensemble (éventuellement variable au fil du temps) de sous-répertoires. Nous verrons plus bas comment il serait possible d'obtenir cela, en ayant recours non plus à sauvliens.sh mais à un autre script : aSauver.sh.

Et si je crée un fichier juste avant d'arrêter le système ?

Imaginons que vous créez un fichier à 21h 01 et que vous arrêtez le système à 21h 03. Eh bien, si vous ne relancez pas votre ordinateur avant que cinq minutes ne s'écoulent… la dernière exécution du script sauvliens.sh par crond ayant eu lieu à 21h 00, donc avant la création du fichier, ce fichier ne serait évidemment pas protégé par la prochaine exécution du script, lancée plus de cinq minutes après sa création, et il resterait donc durablement dans une lamentable situation de vulnérabilité...

Pour éviter cela, il serait approprié de lancer la protection à chaque arrêt du système.

Arrêter le système, c'est le placer dans le niveau d'exécution 0. Les scripts arrêtés ou lancés à cette occasion le sont grâce à des liens symboliques placés dans le répertoire /etc/rc0.d, qui pointent vers des scripts de démarrage/arrêt de certaines applications stockés dans /etc/init.d.

Nous allons d'abord créer un script particulier, destiné à protéger, à l'arrêt du système, pour chaque utilisateur, les différents répertoires que sauvliens.sh protège toutes les cinq minutes lorsque le système est en état de marche. Ce script s'appelle sauvliens_stop.sh (cliquez sur son nom pour y accéder). Comme pour tous mes scripts, je le place dans /opt, avec un lien symbolique dans /usr/local/bin, répertoire qui figure dans le $PATH des utilisateurs, y compris root.

Dans /etc/init.d, nous allons placer un script sauvliens_stop (que je vous laisserai le soin de dactylographier vous-même) qui se réduira à appeler notre sauvliens_stop.sh :

#! /bin/sh# script /etc/init.d/sauvliens_stop/usr/local/bin/sauvliens_stop.shexit 0

et dans /etc/rc0.d, nous allons créer un lien symbolique qui pointera vers le script de /etc/init.d que nous venons de créer. Dans /etc/rc0.d, les seuls liens qui lancent une application sont pour l'instant - en tout cas dans mon système :

lrwxrwxrwx  1 root root 17 nov 24 16:55 S00killall -> ../init.d/killall*
lrwxrwxrwx  1 root root 14 nov 24 16:55 S01halt -> ../init.d/halt*

Je vais d'abord décaler leur 'ordre d'entrée en scène', puis créer le nouveau lien par la ligne de commande suivante :

mv S01halt S02halt && mv S00killall S01killall && ln -s ../init.d/sauvliens_stop S00sauvliens_stop

Il serait prudent de refaire une manoeuvre équivalente dans le répertoire /etc/rc6.d, afin d'obtenir le même résultat en cas de redémarrage.

Voici désormais à quoi ressemblent les liens de démarrage de /etc/rc0.d et /etc/rc6.d :

lrwxrwxrwx  1 root root 24 mar 17 18:56 S00sauvliens_stop -> ../init.d/sauvliens_stop*
lrwxrwxrwx  1 root root 17 nov 24 16:55 S01killall -> ../init.d/killall*
lrwxrwxrwx  1 root root 14 nov 24 16:55 S02halt -> ../init.d/halt*

N'oubliez pas de rendre les scripts /etc/init.d/sauvliens_stop et /opt/sauvliens_stop.sh exécutables via chmod.

Et voilà, votre script sauvliens_stop.sh sera exécuté maintenant à chaque arrêt du système.

Attention : ce sera à l'administrateur 'root' de mettre à jour, chaque fois que ce sera nécessaire, la liste des répertoires à protéger à l'arrêt pour les différents utilisateurs, en éditant la ligne suivante de sauvliens_stop.sh

LISTE_REP="/etc:/home/toto"

les répertoires sont séparés par deux-points, pour ajouter le répertoire personnel de julie on devrait écrire :

LISTE_REP="/etc:/home/toto:/home/julie"

Et pour protéger un ensemble de sous-répertoires ?

Si vous souhaitez non pas protéger la totalité de votre répertoire personnel, mais plutôt un ensemble de sous-répertoires soigneusement choisi par vous, le système proposé jusqu'ici ne convient pas.

Dans ce cas, pour chaque utilisateur, y compris root, dans un certain répertoire (qui sera ici $HOME/Reps_A_Sauver), nous plaçons un lien symbolique (je dis bien 'symbolique'...) vers chacun des répertoires que nous souhaitons protéger.

Il sera très facile, par la suite, d'ajouter ou d'enlever un tel lien à n'importe quel moment, pour modifier l'inventaire des sous-répertoires à protéger.

Le script inspectera ce répertoire et créera des liens en dur pour tous les fichiers que contiennent les sous-répertoires vers lesquels pointent les liens symboliques. Ces liens en dur seront eux-mêmes placés dans un répertoire des liens en dur qui, dans ce script-ci est $HOME/.sauv (un répertoire qui joue ici le même rôle que $HOME/.sauvliens dans le script sauvliens.sh dont nous avons parlé précédemment).

Ce système est plus souple, c'est la protection 'à la carte'. Pour régler le célèbre "problème des cinq dernières minutes", il faudra utiliser le script aSauver_stop.sh et procéder à des manoeuvres analogues à celles effectuées dans le cas précédent et que nous vous laisserons le soin de détailler. Il vous faudra aussi, chaque fois que nécessaire, indiquer, dans le script aSauver_stop.sh, la liste des utilisateurs concernés, root éventuellement compris, dans la ligne consacrée à la variable UTILISATEURS (n'oubliez pas de séparer les noms des utilisateurs par des deux points).

Ne pas oublier l'initialisation et le nettoyage

Lorsqu'ils sont employés sans argument, les scripts sauvliens.sh ou aSauver.sh, selon ce que vous aurez choisi, sont conçus pour être lancés toutes les cinq minutes et traiter uniquement les fichiers qui ont été créés depuis leur précédente exécution.

Mais il est bien sûr nécessaire de protéger la totalité des fichiers réguliers des répertoires que vous avez décidé de protéger.

Pour cela il est indispensable de lancer avant tout, au démarrage de la protection, celui de ces scripts que vous avez retenu avec l'argument init pour initialiser l'ensemble du dispositif, comme nous l'avons mentionné au début de cette page. Cela créera un lien en dur pour tous les fichiers du ou des répertoire(s) à protéger.

Mais l'argument init sert aussi dans un autre type de cas. Notre système de protection a pour conséquence que dans le répertoire protégé aucun fichier régulier n'est vraiment effacé ! Tant que le lien en dur est là, le fichier reste présent sur le disque. Il est donc concevable que de temps en temps, si vous manquez d'espace disque, vous ayez besoin de faire disparaître vraiment tous les fichiers que vous avez effacés et de 'vider' pour cela le répertoire des liens. C'est ce que vous pourrez obtenir à tout moment en lançant le script avec l'argument init.

Quelques apparentes bizarreries découlant de l'option -mmin de la commande 'find'

Nos quatre scripts se terminent par des appels, essentiels, à la commande find.

Un appel de commande comme find . -type f -mmin -5 trouve des fichiers créés dans les cinq minutes qui précèdent. Mais il trouvera aussi des fichiers qui ont été simplement modifiés (mais non créés) pendant cette période. Dans ce cas la partie "-exec' de la ligne du script recréera donc - inutilement - un lien en dur vers le fichier modifié, il s'agira d'une recréation "à vide" d'un lien de même nom, vers le même fichier et doué des mêmes propriétés que le lien précédent. Rien de bien grave donc.

Lorsqu'on a affaire à un dossier modifié, il en va de même. Un dossier au sein duquel on a créé un nouveau fichier est réputé modifié (son horodatage change, du reste) et ce répertoire sera trouvé par une commande find . -type d -mmin -5. Dans ce cas le script essaiera de créer une réplique du fichier dans le répertoire contenant les liens en dur (.sauvliens ou .sauv). Mais comme mkdir ne peut pas recréer un répertoire existant, la tentative avortera et vous aurez simplement un message d'erreur du type :

mkdir: Ne peut créer le répertoire  `./.sauvliens/./Documents': Le fichier existe.

Les messages d'erreur

Les éventuels messages d'erreur générés par l'exécution de nos scripts seront visibles lorsque vous les lancerez en console, à titre d'essai. Dans leur usage normal, lorsque les scripts seront lancés par le démon crond aucune console ne sera ouverte et les messages n'apparaîtront pas. Toutefois, les messages d'erreur vous seront automatiquement expédiés par courrier électronique, si vous avez pris soin d'activer votre mail local.

Tout cela, qui, encore une fois, est sans gravité, pourrait être évité si l'on pouvait chercher des fichiers ou des répertoires en se fondant uniquement sur leur date de création. Je n'en ai pas trouvé le moyen.

Et si j'efface 'exprès' un fichier et le recrée ensuite ? - l'option -f de la commande 'ln'

La commande 'ln' utilisée dans les différents scripts proposés, permet de créer un lien en dur (à condition de ne pas être employée avec l'option -s, qui créerait, elle, un lien symbolique). Par exemple, la commande suivante :

ln /home/toto/Documents/fich1

Si un fichier fich1 (qui peut être un lien en dur que vous avez créé précédemment) existe déjà dans votre répertoire de travail, le nouveau lien ne sera pas créé et vous obtiendrez simplement un message d'erreur :

ln: `./fich1': fichier existant.

Pour que, dans des cas de genre, l'ancien fichier soit écrasé et que le nouveau lien soit donc tout de même créé, vous pouvez faire usage de l'option -f. La ligne de commande :

ln -f /home/toto/Documents/fich1

écrasera un éventuel fichier fich1 déjà présent dans votre répertoire de travail et créera le lien souhaité vers /home/toto/Documents/fich1.

Supposons que vous effaciez un fichier, disons /home/toto/Documents/fichouille, faisant partie de l'ensemble des fichiers protégés par notre dispositif.

Si, un peu plus tard, vous décidez de créer, en définitive, une nouvelle version de fichouille, de même nom que l'ancienne et au même endroit, que se passera-t-il ? Quelle version de fichouille sera protégée et récupérable à partir d'un lien en dur de 'sauvegarde', l'ancienne version ou la nouvelle ?

La réponse est simple : si les appels à 'ln' ne contenaient pas, dans nos scripts, l'option '-f', le lien en dur de protection fichouille continuerait à pointer vers l'ancien fichier. Le nouveau fichier resterait non protégé, puisque 'ln' ne pourrait pas créer un nouveau lien pointant vers lui, en écrasant l'ancien lien. Cette situation durerait aussi longtemps que le script protecteur ne serait pas lancé avec l'argument 'init'.

Tels qu'ils sont écrits, avec l'option '-f' toujours spécifiée pour 'ln', les scripts assurent, au contraire, qu'un lien en dur sera, dans ce cas, créé vers la nouvelle version de fichouille (tandis que l'ancienne version sera, quant à elle, irrémédiablement perdue cinq minutes tout au plus après la création de la nouvelle version...).

Attachments: 4 Attachments by ptyxs ...

Une protection contre les effacements accidentels : ou de l'utilité des liens en dur

Le problème