Voici un résumé des outils d'archivage et de compression disponible sur le système Debian :

Voici un résumé d'outils simple de copie et de sauvegarde sur le système Debian system :

Copier des fichiers avec rsync(8) offres des fonctionnalités plus riches que les autres méthodes.

Voici quelques manières d'archiver et de désarchiver le contenu entier du répertoire « ./source » en utilisant différents outils.

GNU tar(1) :

$ tar cvzf archive.tar.gz ./source
$ tar xvzf archive.tar.gz

cpio(1) :

$ find ./source -xdev -print0 | cpio -ov --null > archive.cpio; gzip archive.cpio
$ zcat archive.cpio.gz | cpio -i

Voici quelques manières d'archiver et de désarchiver le contenu entier du répertoire « ./source » en utilisant différents outils.

rsync(8):

# cd ./source; rsync -av . /dest
# cd ./source; rsync -av . user@host.dom:/dest

Vous pouvez, en remplacement, utiliser la syntaxe « un slash en fin du répertoire source ».

# rsync -av ./source/ /dest
# rsync -av ./source/ user@host.dom:/dest

GNU cp(1) et openSSH scp(1) :

# cd ./source; cp -a . /dest
# cd ./source; scp -pr . user@host.dom:/dest

GNU tar(1) :

# (cd ./source && tar cf - . ) | (cd /dest && tar xvfp - )
# (cd ./source && tar cf - . ) | ssh user@host.dom '(cd /dest && tar xvfp - )'

cpio(1) :

# cd ./source; find . -print0 | cpio -pvdm --null --sparse /dest

Vous pouvez remplacer « . » par « truc » dans tous les exemples comportant « . » pour copier les fichiers du répertoire « ./source/truc » vers le répertoire « /dest/truc ».

Vous pouvez remplacer « . » par le chemin absolu « /chemin/vers/source/truc » dans tous les exemples comportant « . » pour éviter « cd ./source; ». Cela permet de copier les fichiers vers différents emplacements selon les outils utilisés de la manière suivante :

find(1) est utilisé pour la sélection de fichiers pour les commandes d'archive et de copie (consultez Section 10.1.3, « Idiomes pour les archive » et Section 10.1.4, « Idiomes pour la copie ») ou pour xargs(1) (consultez Section 9.5.9, « Répéter une commande en bouclant entre des fichiers »). Cela peut être amélioré en utilisant ces paramètres de commande.

La syntaxe de base de find(1) peut être résumée comme suit :

find(1) est souvent utilisé dans un style idiomatique comme ce qui suit :

# find /chemin/vers/ \
    -xdev -regextype posix-extended \
    -type f -regex ".*\.cpio|.*~" -prune -o \
    -type d -regex ".*/\.git" -prune -o \
    -type f -size +99M -prune -o \
    -type f -newer /chemin/vers/horodatage -print0

Cela signifie que les actions suivantes doivent être effectuées :

Remarquez l’utilisation idiomatique de « -prune -o » pour exclure les fichiers dans l’exemple ci-dessus.

Nous savons tous que les ordinateurs sont parfois victimes de pannes ou que des erreurs humaines provoquent des dommages au système et auxdonnées. Les opérations de sauvegarde et de restauration sont les parties essentielles d'une administration système réussie. Vous serez victime, un jour ou l’autre, de tous les modes de défaillance possibles.

Il y a 3 facteurs-clé qui permettent de définir une méthode pratique de sauvegarde et de restauration.

Comme pour l’enregistrement sécurisé de données, les données doivent se trouver de préférences sur différentes partitions de disque ou sur des disques différents ou des machines différentes afin de résister à une corruption du système de fichiers. Les données importantes seront, de préférence écrites sur des supports à écriture unique tels que les CD/DVD-R afin de prévenir l’écrasement accidentel des données (consultez Section 10.3, « Les données binaires » pour la manière d'écrire sur le support d'enregistrement depuis la ligne de commandes de l’interpréteur. L’interface graphique de l’environnement de bureau GNOME vous donne une accès facile depuis le menu : « Places→CD/DVD Creator :»).

Voici une liste d'utilitaires de sauvegarde notables disponibles sur le système Debian :

Les outils de sauvegarde ont chacun des objectifs particuliers.

Les outils de base décrits dans Section 10.1.1, « Outils d'archivage et de compression » et Section 10.1.2, « Outils de copie et de synchronisation » peuvent être utilisés pour faciliter la sauvegarde du système au moyen de scripts personnalisés. De tels scripts peuvent être améliorés comme suit :

Pour un système de bureau personnel Debian sur lequel tourne la version unstable, je n'ai besoin de protéger que les données personnelles et les données critiques. Je réinstalle cependant le système une fois par an. Je ne vois donc aucune raison de sauvegarder l’ensemble du système ou d'installer un utilitaire de sauvegarde ayant des fonctionnalités avancées.

J'utilise un simple script pour réaliser des archives de sauvegarde et les graver sur CD/DVD en utilisant une interface graphique. Voici un exemple de script pour ce faire :

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
BUUID=1000; USER=osamu # UID and name of a user who accesses backup files
BUDIR="/var/backups"
XDIR0=".+/Mail|.+/Desktop"
XDIR1=".+/\.thumbnails|.+/\.?Trash|.+/\.?[cC]ache|.+/\.gvfs|.+/sessions"
XDIR2=".+/CVS|.+/\.git|.+/\.svn|.+/Downloads|.+/Archive|.+/Checkout|.+/tmp"
XSFX=".+\.iso|.+\.tgz|.+\.tar\.gz|.+\.tar\.bz2|.+\.cpio|.+\.tmp|.+\.swp|.+~"
SIZE="+99M"
DATE=$(date --utc +"%Y%m%d-%H%M")
[ -d "$BUDIR" ] || mkdir -p "BUDIR"
umask 077
dpkg --get-selections \* > /var/lib/dpkg/dpkg-selections.list
debconf-get-selections > /var/cache/debconf/debconf-selections

{
find /etc /usr/local /opt /var/lib/dpkg/dpkg-selections.list \
     /var/cache/debconf/debconf-selections -xdev -print0
find /home/$USER /root -xdev -regextype posix-extended \
  -type d -regex "$XDIR0|$XDIR1" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
find /home/$USER/Mail/Inbox /home/$USER/Mail/Outbox -print0
find /home/$USER/Desktop  -xdev -regextype posix-extended \
  -type d -regex "$XDIR2" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
} | cpio -ov --null -O $BUDIR/BU$DATE.cpio
chown $BUUID $BUDIR/BU$DATE.cpio
touch $BUDIR/backup.stamp

C'est destiné à être un script d'exemple exécuté avec le compte de l’administrateur.

Vous devrez le modifier et l’exécuter comme suit :

Faites simple !

Pour les données se trouvant sous l’arborescence d'un répertoire, une copie avec « cp -a » permet une sauvegarde normale.

Pour un gros ensemble de données statiques ne devant pas être réécrites se trouvant dans une arborescence de répertoires telle que celle se trouvant sous le répertoire « /var/cache/apt/packages/ », les liens physiques avec « cp -al » fournissent une alternative à la sauvegarde normale avec une utilisation efficace de l’espace disque.

Voici un script de copie, que j'ai appelé bkup, destiné à la sauvegarde de données. Ce script copie tous les fichiers (non-VCS) du répertoire actuel vers le répertoire daté du répertoire parent ou sur une machine distante.

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
fdot(){ find . -type d \( -iname ".?*" -o -iname "CVS" \) -prune -o -print0;}
fall(){ find . -print0;}
mkdircd(){ mkdir -p "$1";chmod 700 "$1";cd "$1">/dev/null;}
FIND="fdot";OPT="-a";MODE="CPIOP";HOST="localhost";EXTP="$(hostname -f)"
BKUP="$(basename $(pwd)).bkup";TIME="$(date  +%Y%m%d-%H%M%S)";BU="$BKUP/$TIME"
while getopts gcCsStrlLaAxe:h:T f; do case $f in
g)  MODE="GNUCP";; # cp (GNU)
c)  MODE="CPIOP";; # cpio -p
C)  MODE="CPIOI";; # cpio -i
s)  MODE="CPIOSSH";; # cpio/ssh
t)  MODE="TARSSH";; # tar/ssh
r)  MODE="RSYNCSSH";; # rsync/ssh
l)  OPT="-alv";; # lien physique (GNU cp)
L)  OPT="-av";;  # copier (GNU cp)
a)  FIND="fall";; # tout rechercher
A)  FIND="fdot";; # rechercher ce qui n'est pas CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # utilisateur@remotehost.example.com
T)  MODE="TEST";; # tester le mode de recherche
\?) echo "utiliser -x pour une trace."
esac; done
shift $(expr $OPTIND - 1)
if [ $# -gt 0 ]; then
  for x in $@; do cp $OPT $x $x.$TIME; done
elif [ $MODE = GNUCP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU";cp $OPT . "../$BU/"
elif [ $MODE = CPIOP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU"
  $FIND|cpio --null --sparse -pvd ../$BU
elif [ $MODE = CPIOI ]; then
  $FIND|cpio -ov --null | ( mkdircd "../$BU"&&cpio -i )
elif [ $MODE = CPIOSSH ]; then
  $FIND|cpio -ov --null|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&cpio -i )"
elif [ $MODE = TARSSH ]; then
  (tar cvf - . )|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&& tar xvfp - )"
elif [ $MODE = RSYNCSSH ]; then
  rsync -rlpt ./ "${HOST}:${EXTP}-${BKUP}-${TIME}"
else
  echo "Une autre idée à sauvegarder ?"
  $FIND |xargs -0 -n 1 echo
fi

C'est destiné à être un exemple de commandes. Veuillez lire le script et le modifier vous-même avant de l’utiliser.

Les périphériques d'enregistrement amovibles possibles sont les suivants.

Ils peuvent être connectés à l'aide de n'importe quel moyen suivant.

Les environnements de bureau modernes comme GNOME et KDE peuvent monter ces périphériques amovibles automatiquement sans entrée correspondante dans « /etc/fstab »

Le point de montage sous les environnements de bureau modernes est choisi avec le nom « /media/<étiquette_disque> », il peut être personnalisé avec les outils suivants :

Lors du partage de données avec d'autres système à l’aide de périphériques de stockage amovibles, vous devez les formatez avec un système de fichiers pris en charge par les deux systèmes. Voici une liste de choix de systèmes de fichiers :

Le système de fichiers FAT est pris en charge par la plupart des systèmes d'exploitation modernes et est assez utile dans le but d'échanger des données par l’intermédiaire de supports du type disque dur amovible.

Pour le formatage de périphériques de type disque dur amovible pour l’échange de données entre plateformes avec un système de fichiers FAT, ce qui suit peut être le choix sûr :

Lors de l’utilisation des systèmes de fichiers FAT ou ISO9660 pour le partage de données ce qui suit sera une précaution sûre :

Lors du partage de données avec d'autres systèmes au travers du réseau, vous devrez utiliser un service commun. Voici quelques éléments :

Bien que ces systèmes de fichiers montés au travers du réseau et les méthodes de transfert au travers du réseau soient assez pratiques pour partager des données, elles peuvent être non sûres. Leur connexion réseau doit être sécurisée par ce qui suit :

consultez aussi Section 6.10, « Autres serveurs d'applications réseau » et Section 6.11, « Autres clients d'applications réseau ».

Lors du choix d'un support d'enregistrement de données informatiques destiné à l’archivage de données importantes, il faut faire attention à leurs limitations. Pour des petites sauvegardes de données personnelles, j'utilise des CD-R et des DVD-R provenant d'une grande marque et je les range dans un endroit frais, à l’ombre, sec et propre. (Les support d'archive sur bande semblent être populaires pour les utilisations professionnelles).

Durées de vie optimistes des moyens d'archivage trouvées sur le net (la plupart à partir d'informations des constructeurs).

Cela ne prend pas en compte les défaillances mécaniques dues aux manipulations, etc.

Nombre de cycles d'écriture optimistes des moyens d'archivage trouvées sur le net (la plupart à partir d'informations des constructeurs).

Le fichier image du disque, « disk.img » d'un périphérique non monté, par exemple, le second périphérique SCSI « /dev/sdb » peut être créé en utilisant cp(1) ou dd(1) par ce qui suit :

# cp /dev/sdb disque.img
# dd if=/dev/sdb of=disque.img

L’image disque du master boot record (MBR) (secteur principal d'amorçage) (consultez Section 9.3.2, « Configuration de la partition du disque ») qui se trouve sur le premier secteur du disque primaire IDE peut être faite en utilisant dd(1) comme suit :

# dd if=/dev/hda of=mbr.img bs=512 count=1
# dd if=/dev/hda of=mbr-nopart.img bs=446 count=1
# dd if=/dev/hda of=mbr-part.img skip=446 bs=1 count=66

Si vous avez un périphérique SCSI (y compris les nouveaux disques de type serial ATA) comme disque d'amorçage, remplacez « /dev/hda » avec « /dev/sda ».

Si vous réalisez une image d'une partition de disque du disque d'origine, remplacez « /dev/hda » par « /dev/hda1 », etc.

Le fichier image du disque « disk.img » peut être écrit vers un disque non monté, par exemple le second disque SCSI « /dev/sdb » avec la taille correspondante par ce qui suit :

# dd if=disk.img of=/dev/sdb

De la même manière, le fichier image de la partition du disque, « partition.img » peut être écrit sur une partition non montée, par exemple, la première partition du second disque SCSI « /dev/sdb1 » avec la taille correspondante comme suit :

# dd if=partition.img of=/dev/sdb1

L’image disque « partition.img », qui contient une partition image unique, peut être monté et démonter en utilisant le périphérique de rebouclage (loop device) de la manière suivante :

# losetup -v -f partition.img
Loop device is /dev/loop0
# mkdir -p /mnt/loop0
# mount -t auto /dev/loop0 /mnt/loop0
...hack...hack...hack
# umount /dev/loop0
# losetup -d /dev/loop0

Cela peut être simplifié de la manière suivante :

# mkdir -p /mnt/loop0
# mount -t auto -o loop partition.img /mnt/loop0
...hack...hack...hack
# umount partition.img

Chaque partition de l’image disque « disk.img » contenant plusieurs partitions peut être monté en utilisant le périphérique de rebouclage (loop device). Comme, par défaut, le périphérique de rebouclage ne gère par par partitions, il faut le réinitialiser de la manière suivante :

# modinfo -p loop # verify kernel capability
max_part:Maximum number of partitions per loop device
max_loop:Maximum number of loop devices
# losetup -a # verify nothing using the loop device
# rmmod loop
# modprobe loop max_part=16

Maintenant, le périphérique de rebouclage peut gérer jusqu’à 16 partitions.

# losetup -v -f disk.img
Loop device is /dev/loop0
# fdisk -l /dev/loop0

Disk /dev/loop0: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x452b6464

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1               1         600     4819468+  83  Linux
/dev/loop0p2             601         652      417690   83  Linux
# mkdir -p /mnt/loop0p1
# mount -t ext3 /dev/loop0p1 /mnt/loop0p1
# mkdir -p /mnt/loop0p2
# mount -t ext3 /dev/loop0p2 /mnt/loop0p2
...hack...hack...hack
# umount /dev/loop0p1
# umount /dev/loop0p2
# losetup -d /dev/loop0

En remplacement, des effets similaires peuvent être obtenus en utilisant les périphériques device mapper créés par kpartx(8) du paquet kpartx de la manière suivante :

# kpartx -a -v disk.img
...
# mkdir -p /mnt/loop0p2
# mount -t ext3 /dev/mapper/loop0p2 /mnt/loop0p2
...
...hack...hack...hack
# umount /dev/mapper/loop0p2
...
# kpartx -d /mnt/loop0

Un fichier image disque « disk.img » peut être nettoyé de tous les fichiers supprimés pour donner une image propre « new.img » de la manière suivante :

# mkdir old; mkdir new
# mount -t auto -o loop disk.img old
# dd bs=1 count=0 if=/dev/zero of=new.img seek=5G
# mount -t auto -o loop new.img new
# cd old
# cp -a --sparse=always ./ ../new/
# cd ..
# umount new.img
# umount disk.img

Si « disk.img » est un système de fichiers ext2 ou ext3, vous pouvez aussi utiliser zerofree(8) du paquet zerofree de la manière suivante :

# losetup -f -v disk.img
Loop device is /dev/loop3
# zerofree /dev/loop3
# cp --sparse=always disk.img new.img

Le fichier image du disque vide « sparse », qui pourra s'étendre jusqu'à 5Gio peut être faite en utilisant dd(1) et mke2fs(8) comme suit :

$ dd bs=1 count=0 if=/dev/zero of=disk.img seek=5G

Vous pouvez créer un système de fichiers ext3 sur cette image disque « disk.img » en utilisant le périphérique de rebouclage (loop device) de la manière suivante :

# losetup -f -v disk.img
Loop device is /dev/loop1
# mkfs.ext3 /dev/loop1
...hack...hack...hack
# losetup -d /dev/loop1
$ du  --apparent-size -h disk.img
5.0G  disk.img
$ du -h disk.img
83M disk.img

Pour « disk.img », sa taille de fichier de 5.0 Gio et son utilisation disque est uniquement de 83Mio. Cette discordance est possible car ext2fs sait maintenir un fichier sparse.

En utilisant des opérations similaires sur les périphériques créés par loop device ou les périphériques device mapper comme dans Section 10.2.3, « Monter le fichier image dur disque », vous pouvez partitionner cette image disque « disk.img » en utilisant parted(8) ou fdisk(8), et y créer un système de fichiers en utilisant mkfs.ext3(8), mkswap(8), etc.

On peut faire le fichier image ISO9660, « cd.iso », depuis l’arborescence de répertoire source située à « répertoire_source », en utilisant genisoimage(1) fourni parcdrkit de la manière suivante :

#  genisoimage -r -J -T -V volume_id -o cd.iso répertoire_source

De la même manière, on peut créer le fichier image ISO9660 amorçable « cdboot.iso » depuis une arborescence comme celle de debian-installer située en « source_directory », de la manière suivante :

#  genisoimage -r -o cdboot.iso -V volume_id \
   -b isolinux/isolinux.bin -c isolinux/boot.cat \
   -no-emul-boot -boot-load-size 4 -boot-info-table répertoire_source

Ici, le chargeur d'amorçage Isolinux (consultez Section 3.3, « Étage 2 : le chargeur initial ») est utilisé pour l’amorçage.

Vous pouvez calculer la valeur de la somme md5 (md5sum) et construire des image ISO9660 directement depuis un lecteur de CD-ROM de la manière suivante :

$ isoinfo -d -i /dev/cdrom
CD-ROM is in ISO 9660 format
...
Logical block size is: 2048
Volume size is: 23150592
...
# dd if=/dev/cdrom bs=2048 count=23150592 conv=notrunc,noerror | md5sum
# dd if=/dev/cdrom bs=2048 count=23150592 conv=notrunc,noerror > cd.iso

Vous pouvez rechercher un périphérique utilisable comme suit :

# wodim --devices

Le CD-R vierge est alors inséré dans le graveur de CD et le fichier image ISO9660 « cd.iso » est écrit vers le périphérique, par exemple; « /dev/hda » en utilisant wodim(1) de la manière suivante :

# wodim -v -eject dev=/dev/hda cd.iso

Si un CD-RW est utilisé à la place d'un CD-R, faites alors ce qui suit :

# wodim -v -eject blank=fast dev=/dev/hda cd.iso

Si « cd.iso » contient une image ISO9660, ce qui suit permet alors de le monter manuellement sur « /cdrom » :

# mount -t iso9660 -o ro,loop cd.iso /cdrom

La méthode la plus basique de visualiser des données binaires est d'utiliser la commande « od -t x1 ».

Il existe des outils permettant de lire et d'écrire des fichier sans avoir à monter le disque.

Les systèmes s'appuyant sur le RAID logiciel offert par le noyau Linux permettent une redondance des données au niveau du système de fichiers du noyau afin d'obtenir un haut niveau de fiabilité du système de stockage.

Il existe aussi des outils pour ajouter des données de redondance aux fichiers au niveau du programme applicatif permettant d'obtenir de hauts niveau de fiabilité de stockage.

Il y a des outils pour la récupération des données et l’analyse par autopsie.

Lorsque les données ont un volume trop important pour pouvoir être sauvegardée dans un seul fichier, vous pouvez en sauvegarder le contenu après l’avoir éclaté en morceaux de, par exemple, 2000Mio et réassembler ces morceaux par la suite sous la forme du fichier d'origine.

$ split -b 2000m gros_fichier
$ cat x* >gros_fichier

Pour effacer le contenu d'un fichier comme, par exemple, un fichier journal, n'utilisez pas la commande rm(1) pour supprimer le fichier et recréer ensuite un fichier vide parce qu'on peut encore accéder au fichier dans l’intervalle entre les commandes. Voici est la manière sûre d'effacer le contenu d'un fichier :

$ :>fichier_a_effacer

Les commandes suivantes créent des fichiers factices ou vides.

$ dd if=/dev/zero    of=5kb.file bs=1k count=5
$ dd if=/dev/urandom of=7mb.file bs=1M count=7
$ touch zero.file
$ : > alwayszero.file

Vous obtiendrez les fichiers suivants :

Il existe plusieurs manière d'effacer complètement les données d'un périphérique semblable à disque dur, par exemple, une clé USB se trouvant en « /dev/sda ».

Effacer tout le contenu du disque en réinitialisant toutes les données à 0 avec la commande suivante :

# dd if=/dev/zero of=/dev/sda

Tout effacer en écrasant les données existantes par des données aléatoires par la commande suivante :

# dd if=/dev/urandom of=/dev/sda

Effacer de manière très efficace toutes les données en les écrasant avec des données aléatoires par la commande suivante :

# shred -v -n 1 /dev/sda

Comme dd(1) est disponible depuis l’interpréteur de commandes de nombreux CD amorçables de Linux tels que le CD de l’installateur Debian, vous pouvez effacer complètement votre système installé en lançant la commande d'effacement du disque du disque dur du système, par exemple, « /dev/hda », « /dev/sda », etc. depuis un tel support,

Une zone inutilisée du disque dur (ou d’une clé mémoire USB), par ex. « /devsdb1 » peut encore contenir les données effacées elles-mêmes puisque elle ne sont que déliées du système de fichiers. Elles peuvent être nettoyées en les surchargeant.

# mount -t auto /dev/sdb1 /mnt/foo
# cd /mnt/foo
# dd if=/dev/zero of=junk
dd: writing to `junk': No space left on device
...
# sync
# umount /dev/sdb1

Même si vous avez accidentellement supprimé un fichier, tant que ce fichier est en cours d'utilisation par une application quelconque, (en mode lecture ou écriture); il est possible de récupérer un tel fichier.

Essayez, par exemple, ce qui suit :

$ echo toto > titi
$ less titi
$ ps aux | grep ' less[ ]'
bozo    4775  0.0  0.0  92200   884 pts/8    S+   00:18   0:00 less titi
$ rm titi
$ ls -l /proc/4775/fd | grep titi
lr-x------ 1 bozo bozo 64 2008-05-09 00:19 4 -> /home/bozo/titi (deleted)
$ cat /proc/4775/fd/4 >titi
$ ls -l
-rw-r--r-- 1 bozo bozo 4 2008-05-09 00:25 titi
$ cat titir
toto

Exécutez sur une autre terminal (lorsque vous avez le paquet lsofinstallé) comme suit

$ ls -li titi
2228329 -rw-r--r-- 1 bozo bozo 4 2008-05-11 11:02 titi
$ lsof |grep titi|grep less
less 4775 bozo 4r REG 8,3 4 2228329 /home/bozo/titi
$ rm titi
$ lsof |grep titi|grep less
less 4775 bozo 4r REG 8,3 4 2228329 /home/bozo/titi (deleted)
$ cat /proc/4775/fd/4 >titi
$ ls -li titi
2228302 -rw-r--r-- 1 bozo bozo 4 2008-05-11 11:05 titi
$ cat titi
toto

Les fichiers ayant des liens physiques peuvent être identifiés par « ls -li ».

$ ls -li
total 0
2738405 -rw-r--r-- 1 root root 0 2008-09-15 20:21 titi
2738404 -rw-r--r-- 2 root root 0 2008-09-15 20:21 tutu
2738404 -rw-r--r-- 2 root root 0 2008-09-15 20:21 toto

« tutu » et « toto » ont tous les deux un nombre de liens égal à "« 2 » (>1), ce qui indique qu'ils ont des liens physiques. Leur numéro d'inœud commun est « 2738404 ». Cela signifie qu'ils représentent le même fichier lié par des liens physiques. Si vous n'arrivez pas à trouver de fichiers liés par des liens physiques, vous pouvez les rechercher parinœud, par exemple « 2738404 », de la manière suivante :

# find /chemin/vers/point/de/montage -xdev -inum 2738404

Tous les fichiers supprimés par ouverts prennent de l’espace disque même s'il ne sont pas visible par la commande du(1) normale. On peut en afficher la liste avec leur taille par ce qui suit :

# lsof -s -X / |grep deleted

Voici les commandes de GNU Privacy Guard pour la gestion de base des clés :

Voici la signification du code de confiance

Ce qui suit permet d'envoyer ma clé « 1DD8D791 » vers le serveur de clé populaire « hkp://keys.gnupg.net » :

$ gpg --keyserver hkp://keys.gnupg.net --send-keys 1DD8D791

Une bonne configuration de serveur de clés dans « ~/.gnupg/gpg.conf » (ou à l’ancien emplacement « ~/.gnupg/options ») contient ce qui suit :

keyserver hkp://keys.gnupg.net

Ce qui suit obtient les clés inconnues du serveur de clés :

$ gpg --list-sigs --with-colons | grep '^sig.*\[User ID not found\]' |\
  cut -d ':' -f 5| sort | uniq | xargs gpg --recv-keys

Il y avait un bogue dans OpenPGP Public Key Server (pre version 0.9.6) qui corrompais les clés ayant plus de 2 sous-clés. Le paquet du serveur gnupg (>1.2.1-2) peut gérer ces sous-clés corrompues. Consultez gpg(1) sous l’option « --repair-pks-subkey-bug ».

Voici des exemples d'utilisation des commandes de GNU Privacy Guard sur des fichiers :

Ajoutez ce qui suit à « ~/.muttrc » afin d'éviter que GnuPG qui est lent ne démarre automatiquement, tout en permettant sont utilisation en entrant « S » depuis l’index du menu :

macro index S ":toggle pgp_verify_sig\n"
set pgp_verify_sig=no

Le greffon gnupg vous permet de lancer GnuPG de manière transparente pour les fichiers ayant l’extension « .gpg », « .asc » et « .ppg ».

# aptitude install vim-scripts vim-addon-manager
$ vim-addons install gnupg

md5sum(1) fournit un utilitaire permettant de créé un fichier de résumé en utilisant la méthode se trouvant dans rfc1321 et en l’utilisant pour vérifier chaque fichier qu'il contient.

$ md5sum toto titi >tutu.md5
$ cat tut.md5
d3b07384d113edec49eaa6238ad5ff00  toto
c157a79031e1c40f85931829bc5fc552  titi
$ md5sum -c tutu.md5
toto: OK
titi: OK

Suivez une des procédures suivantes pour extraire les différences entre deux fichiers sources et créer un fichier de différences unifiées « fichier.patch0 » ou « fichier.patch1 » selon l’emplacement du fichier.

$ diff -u fichier.ancien fichier.nouveau > fichier.patch0
$ diff -u ancien/fichier.nouveau/fichier > fichier.patch1

Le fichier de différence (« diff » (encore appelé fichier « patch » ou rustine) est utilisé pour envoyer une mise à jour de programme. Celui qui reçoit applique cette mise à jour à un autre fichier de la manière suivante :

$ patch -p0 fichier < fichier.patch0
$ patch -p1 fichier < fichier.patch1

Si vous avez trois versions d'un code source, vous pouvez effectuer de manière efficace une fusion des trois en utilisant diff3(1) de la manière suivante :

$ diff3 -m fichier.mien fichier.ancien fichier.votre > fichier

Voici une comparaison très simplifiée des commandes natives de VCS destinées à donner une vue d'ensemble. La séquences commandes typique peut demander des options et des paramètres.

La configuration suivante permet de ne faire des dépôts (« commit ») vers le dépôt du CVS que par les membres du groupe « src » et l’administration du CVS que par un membre du groupe « staff », réduisant ainsi la chance de se détruire soi-même.

# cd /var/lib; umask 002; mkdir cvs
# export CVSROOT=/srv/cvs/projet
# cd $CVSROOT
# chown root:src .
# chmod 2775 .
# cvs -d $CVSROOT init
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags

La variable « $CVSROOT » pointe vers le dépôt par défaut. Ce qui suit définit « $CVSROOT » pour l’accès local :

$ export CVSROOT=/srv/cvs/project

De nombreux serveurs CVS d'accès public fournissent un accès distant en lecture avec le nom de compte « anonymous » par l’intermédiaire du service pserver. Par exemple, le contenu du site web Debian est maintenu par l’intermédiaire du projet webwml sous le CVS du service alioth de Debian. Ce qui suit permet de configurer « $CVSROOT » pour un accès distant à ce dépôt CVS :

$ export CVSROOT=:pserver:anonymous@cvs.alioth.debian.org:/cvsroot/webwml
$ cvs login

Ce qui suit définit « $CVS_RSH » et » $CVSROOT » pour l’accès distant avec SSH au dépôt CVS du projet webwml :

$ export CVS_RSH=ssh
$ export CVSROOT=:ext:account@cvs.alioth.debian.org:/cvs/webwml

Vous pouvez aussi utiliser une clé publique d'authentification pour SSH, ce qui élimine l’invite à distance pour l’entrée du mot de passe.

Créez un nouvel emplacement d'arborescence locale des sources dans « ~/chemin/vers/module1 » par la commande suivante :

$ mkdir -p ~/chemin/vers/module1; cd ~/chemin/vers/module1

Mettez des fichiers dans la nouvelles arborescence locale de sources se trouvant en « ~/chemin/vers/module1 ».

Importez-les vers CVS avec les paramètres suivants :

$ cd ~/chemin/vers/module1
$ cvs import -m "Start module1" module1 Branche-principale Version-initiale
$ rm -Rf . # optionnel

CVS n'écrase pas un fichier du dépôt actuel mais le remplace par un autre. La permission en écriture vers le répertoire du dépôt est donc critique. Lancez ce qui suit, pour chaque nouveau module de « module1 » dans le dépôt à « /srv/cvs/projet », afin de vous assurer, si nécessaire, que cette condition est remplie :

# cd /srv/cvs/projet
# chown -R root:src module1
# chmod -R ug+rwX   module1
# chmod    2775     module1

Voici un exemple de flux de travail typique utilisant CVS.

Vérifiez tous les modules disponibles du projet CVS pointé par « $CVSROOT » comme suit :

$ cvs rls
CVSROOT
module1
module2
...

Récupérez le « module1 » depuis son répertoire par défaut « ./module1 » de la manière suivante :

$ cd ~/path/to
$ cvs co module1
$ cd module1

Effectuez les modifications de contenu au besoin.

Vérifiez les modifications par un équivalent de « diff -u [repository] [local] » de la manière suivante :

$ cvs diff -u

Vous-vous apercevez que vous avez cassé sévèrement un fichier appelé « fichier_à_restaurer » mais que les autres fichiers sont corrects.

Écrasez le fichier « fichier_à_restaurer » avec une copie propre venant du CVS de la manière suivante :

$ cvs up -C fichier_à_restaurer

Enregistrez l’arborescence source locale vers le CVS comme suit :

$ cvs ci -m "Décrire les modifications"

Créez et ajoutez le fichier « fichier_à_ajouter » au CVS comme suit :

$ vi fichier_à_ajouter
$ cvs add fichier_à_ajouter
$ cvs ci -m "Ajout de fichier_à_ajouter"

Fusionnez la dernière version depuis le CVS comme suit :

$ cvs up -d

Recherchez les lignes commençant par « C filename » qui indiquent des modifications en conflit.

Recherchez du code non modifié dans « .#nom_fichier.version ».

Recherchez « <<<<<<< » et « >>>>>>> » dans les fichiers qui indiquent des conflits de modifications.

Au besoin, éditez les fichiers pour résoudre les conflits.

Ajoutez l’étiquette de version (« release tag« ») « Version-1 » comme suit :

$ cvs ci -m "dernière proposition pour Version-1"
$ cvs tag Version-1

Poursuivez l’édition.

Supprimez l’étiquette de version « Version-1  » comme suit :

$ cvs tag -d Version-1

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "vraiment la dernière proposition pour Version-1"

Ajoutez de nouveau, de la manière suivante, l’étiquette « Version-1 » à HEAD de « main » du CVS mis à jour :

$ cvs tag Version-1

Créez une branche avec une étiquette de branche « collante » Version-initiale-corrections-de-bogues » depuis la version d'origine pointée par l’étiquette « Version-initiale » et exportez-la vers le répertoire ~/chemin/vers/ancien » comme suit :

$ cvs rtag -b -r Version-initiale Version-initiale-corrections-de-bogues module1
$ cd ~/chemin/vers
$ cvs co -r Version-initiale-corrections-de-bogues -d ancien module1
$ cd ancien

Travaillez sur cette arborescence locale possédant l’étiquette « collante » « Version-initiale-corrections-de-bogues » qui est basée sur la version d'origine.

Travaillez vous-même sur cette branche… jusqu'à ce que quelqu'un d'autre rejoigne cette branche « Version-initiale-corrections-de-bogues ».

Synchronisez les fichiers modifiés par d'autres sur cette branche, en créant de nouveaux répertoires si nécessaire, de la manière suivante :

$ cvs up -d

Au besoin, éditez les fichiers pour résoudre les conflits.

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "checked into this branch"

Mettez à jour l’arborescence locale depuis HEAD de main en supprimant l’étiquette collante (« sticky tag ») (« -A ») et sans expansion de mots-clés (« -kk ») comme suit :

$ cvs up -d -kk -A

Mettez à jour l’arborescence locale (contenu = HEAD de main) en fusionnant depuis la branche « Version-initiale-corrections-de-bogues » et sans expansion des mots-clés en faisant ce qui suit :

$ cvs up -d -kk -j Version-initiale-corrections-de-bogues

Corrigez les conflits avec l’éditeur.

Vérifiez les modifications du CVS comme suit :

$ cvs ci -m "Version-initiale-corrections-de-bogues fusionnée"

Réalisez une archive de la manière suivante :

$ cd ..
$ mv ancien ancien-module1-corrections_bogues
$ tar -cvzf ancien-module1-corrections_bogues.tar.gz ancien-module1-corrections_bogues
$ rm -rf ancien-module1-corrections_bogues

Pour obtenir les derniers fichiers du CVS, utilisez « tomorrow » comme suit :

$ cvs ex -D tomorrow nom_module

Ajoutez l’alias « mx » à un projet CVS (serveur local) de la manière suivante :

$ export CVSROOT=/srv/cvs/projet
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "mx -a module1" >>modules
$ cvs ci -m "mx est maintenant un alias de module1"
$ cvs release -d .

Vous pouvez maintenant vérifier « module1 » (alias : « mx ») depuis le CVS vers le répertoire « new » de la manière suivante :

$ cvs co -d nouveau mx
$ cd nouveau

Lorsque vous vérifiez des fichiers du CVS, leur bit d'autorisation en exécution est conservé.

Si vous rencontrez des problèmes de droits d'exécution avec un fichier récupéré, par exemple « nom_fichier », modifiez-en les permissions dans le répertoire correspondant du dépôt CVS par ce qui suit afin de corriger ce problème :

# chmod ugo-x nom_de_fichier

Actuellement, le paquet subversion ne configure pas le dépôt, on doit donc le faire manuellement. Un emplacement possible pour le dépôt se trouve en « /srv/svn/projet ».

Créez un répertoire de la manière suivante :

# mkdir -p        /srv/svn/projet

Créez la base de données du dépôt comme suit :

# svnadmin create /srv/svn/projet

Si vous n'avez accès au dépôt de Subversion que par un serveur Apache2, il vous suffira de ne rendre le dépôt accessible en écriture que par le serveur WWW de la manière suivante :

# chown -R www-data:www-data /srv/svn/projet

Ajouter (ou décommenter) ce qui suit dans « /etc/apache2/mods-available/dav_svn.conf » afin de permettre l’accès au dépôt avec une authentification de l’utilisateur.

<Location /projet>
  DAV svn
  SVNPath /srv/svn/projet
  AuthType Basic
  AuthName "Dépôt subversion"
  AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
</LimitExcept>
</Location>

Créer un fichier d'authentification des utilisateurs avec la commande suivante :

# htpasswd2 -c /etc/subversion/passwd nom_utilisateur

Redémarrez Apache2.

Votre nouveau dépôt Subversion est accessible à l’URL « http://localhost/projet » et « http://example.com/projet » depuis svn(1) (en supposant que l’URL du serveur web est « http://example.com/ »).

Ce qui suit configure le dépôt Subversion pour un accès local par un groupe, projet, par exemple :

# chmod  2775     /srv/svn/projet
# chown -R root:src /srv/svn/projet
# chmod -R ug+rwX   /srv/svn/projet

Votre nouveau dépôt Subversion est accessible aux utilisateurs locaux appartenant au groupe projetà l’URL « file:///localhost/srv/svn/projet » ou « file:///srv/svn/projet » depuis svn(1) . Vous devrez lancer des commandes comme svn, svnserve, svnlook et svnadmin avec « umask 002 » afin de permettre l’accès au groupe.

Un dépôt Subversion accessible à un groupe se trouve pour SSH à l’URL « example.com:/srv/svn/projet », vous pouvez y accéder avec svn(1) à l’URL « svn+ssh://example.com:/srv/svn/projet".

Afin de compenser le manque de branches et d'étiquettes, de nombreux projets utilisent une arborescence de répertoires semblable à la suivante pour Subversion :

  ----- module1
    |   |-- branches
    |   |-- tags
    |   |   |-- version-1.0
    |   |   `-- version-2.0
    |   |
    |   `-- trunk
    |       |-- fichier1
    |       |-- fichier2
    |       `-- fichier3
    |
    `-- module2

Créez un nouvel emplacement d'arborescence locale des sources dans « ~/chemin/vers/module1 » par la commande suivante :

$ mkdir -p ~/chemin/vers/module1; cd ~/chemin/vers/module1

Mettez des fichiers dans la nouvelles arborescence locale de sources se trouvant en « ~/chemin/vers/module1 ».

Importez-le dans Subversion avec les paramètres suivants :

$ cd ~/chemin/vers/module1
$ svn import file:///srv/svn/projet/module1/trunk -m "Lancement module1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-initiale

Ou encore, comme suit :

$ svn import ~/chemin/vers/module1 file:///srv/svn/projet/module1/trunk -m "Lancement module1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-initiale

Voici un exemple typique de flux de travail utilisant Subversion avec son client natif.

Vérifiez de la manière suivante tous les modules disponibles depuis le projet pointé par l’URL « file:///srv/svn/projet » :

$ svn list file:///srv/svn/projet
module1
module2
...

Récupérez « module1/trunk » dans un répertoire « module1 » comme suit :

$ cd ~/chemin/vers
$ svn co file:///srv/svn/projet/module1/trunk module1
$ cd module1

Effectuez les modifications de contenu au besoin.

Vérifiez les modifications par un équivalent de « diff -u [repository] [local] » de la manière suivante :

$ svn diff

Vous-vous apercevez que vous avez cassé sévèrement un fichier appelé « fichier_à_restaurer » mais que les autres fichiers sont corrects.

Écrasez le fichier « fichier_a_annuler » avec une nouvelle copie propre depuis Subversion comme suit :

$ svn revert fichier_a_annuler

Enregistrez l’arbre local des sources mis à jour vers Subversion comme suit :

$ svn ci -m "Décrire les modifications"

Créez et ajoutez le fichier « fichier_a_ajouter » dans Subversion comme suit :

$ vi fichier_a_ajouter
$ svn add fichier_a_ajouter
$ svn ci -m "fichier_a_ajouter ajouté"

Fusionnez la dernière version depuis Subversion comme suit :

$ svn up

Recherchez les lignes commençant par « C filename » qui indiquent des modifications en conflit.

Recherchez le code non modifié, par exemple « nom_fichier.r6 », « nom_fichier.r9 » et « nom_fichier.mien ».

Recherchez « <<<<<<< » et « >>>>>>> » dans les fichiers qui indiquent des conflits de modifications.

Au besoin, éditez les fichiers pour résoudre les conflits.

Ajoutez l’étiquette de version (« release tag« ») « Version-1 » comme suit :

$ svn ci -m "dernier « commit » pour la Release-1"
$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Release-1

Poursuivez l’édition.

Supprimez l’étiquette de version « Version-1  » comme suit :

$ svn rm file:///srv/svn/projet/module1/tags/Release-1

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "vraiment le dernier commit pour Release-1"

Ajoutez de nouveau la balise « Version-1 » depuis la version mise à jour de HEAD de trunk de Subversion comme suit :

$ svn cp file:///srv/svn/projet/module1/trunk file:///srv/svn/projet/module1/tags/Version-1

Créez une branche dont le chemin est « module1/branches/Release-initial-bugfixes » depuis la version initiale pointée par le chemin « module1/tags/Release-initial » et récupérez-le vers le répertoire « ~/chemin/vers/ancien » comme suit :

$ svn cp file:///srv/svn/projet/module1/tags/Version-initiale file:///srv/svn/projet/module1/branches/Version-initale-corrections-de-bogues
$ cd ~/chemin/vers
$ svn co file:///srv/svn/projet/module1/branches/Version-initiale-corrections-de-bogues ancien
$ cd ancien

Travaillez sur cet arbre de sources local pointant vers la branche « Version-initiale-corrections-de-bogues » qui est basée sur la version initiale.

Travaillez vous-même sur cette branche… jusqu'à ce que quelqu'un d'autre rejoigne cette branche « Version-initiale-corrections-de-bogues ».

Effectuez la synchronisation avec les fichiers de cette branche modifiés par d'autres comme suit :

$ svn up

Au besoin, éditez les fichiers pour résoudre les conflits.

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "récupérés dans cette branche"

Mettez à jour l’arborescence local avec HEAD de trunk de la manière suivante :

$ svn switch file:///srv/svn/projet/module1/trunk

Mettez à jour l’arborescence locale (contenu = HEAD de trunk) en fusionnant depuis la branche « Version-initiale-corrections-de-bogues » par ce qui suit :

$ svn merge file:///srv/svn/projet/module1/branches/Version-initiale-corrections-de-bogues

Corrigez les conflits avec l’éditeur.

Récupérez les modifications depuis Subversion comme suit :

$ svn ci -m "Version-initiale-corrections-de-bogues fusionnée"

Réalisez une archive de la manière suivante :

$ cd ..
$ mv ancien ancien-module1-corrections_bogues
$ tar -cvzf ancien-module1-corrections_bogues.tar.gz ancien-module1-corrections_bogues
$ rm -rf ancien-module1-corrections_bogues

Vous pourrez définir certains éléments de configuration globaux, comme votre nom et votre adresse de courriel utilisée par Git, dans « ~/.gitconfig » de la manière suivante :

$ git config --global nom.utilisateur "Prénom Nom"
$ git config --global nom-utilisateur.email votre-nom@example.com

Si vous avez l’habitude d'utiliser les commandes de CVS ou de Subversion, vous pourrez définir certains alias de commandes comme suit :

$ git config --global alias.ci "commit -a"
$ git config --global alias.co checkout

Vous pouvez vérifier votre configuration globale comme de la manière suivante :

$ git config --global --list

Consultez ce qui suit :

Les commandes git-gui(1) et gitk(1) rendent très facile l’utilisation de Git.

Même si votre source amont utilise un VCS différent, c'est une bonne idée d'utiliser git(1) pour l’activité locale parce qu'il vous permet de gérer votre copie locale de l’arborescence des sources sans connexion réseau amont. Voici quelques paquets et commandes utilisés avec git(1).

Un dépôt Subversion en « svn+ssh://svn.example.org/project/module/trunk » peut être extrait vers un dépôt Git local en « ./dest » puis renvoyé vers le dépôt subversion. Par exemple :

$ git svn clone -s -rHEAD svn+ssh://svn.example.org/project dest
$ cd dest
... effectuer des modifications
$ git commit -a
... travailler encore avec git
$ git svn dcommit

Vous pouvez enregistrer vous-même un historique chronologique de la configuration en utilisant les outils Git. Voici un exemple simple, pour vous exercer, d'enregistrement du contenu de « /etc/apt/ ».

$ cd /etc/apt/
$ sudo git init
$ sudo chmod 700 .git
$ sudo git add .
$ sudo git commit -a

Dépôt (« commit ») d'une configuration avec sa description

Effectuez les modifications dans les fichiers de configuration.

$ cd /etc/apt/
$ sudo git commit -a

Déposez (« commit ») la configuration avec sa description et retournez à vos occupations habituelles.

$ cd /etc/apt/
$ sudo gitk --all

Vous avez avec vous l’historique complet de la configuration.