TuXxX Blog

Les Conteneurs Linux

stratus — Mon, 02 Aug 2010 15:31:26 +0000

Petite révolution dans la demeure, je vais encore chambouler notre architecture domestique. En effet, puisqu’aujourd’hui je travaille exclusivement dans mon garage (le vieux rêve que voilà -;), je n’ai plus le courage d’éteindre la bête de course qui me sert de poste de travail. Du coup, le petit serveur miniITX a perdu sa raison d’être et l’envie m’a pris de la virtualiser sur la grosse bête. Quoi de plus logique au fond, tant qu’à consommer des watts, autant que cela soit le plus rentable possible.

Malgré tout, virtualiser “à la KVM, XEN ou VirtualBox” ne me plaisait pas des masses. Trop lourd pour le besoin. Quant à chrooter tout cela, pas assez fiable. C’est alors qu’un ami (coucou Daniel) m’a suggéré la solution OpenVZ. Ce n’est finalement pas elle que je vais mettre ici en oeuvre mais c’est ainsi que j’ai mis le doigt sur un concept de super-chroot alliant isolation et performance.

Hôte, conteneur, isolation et performances

La virtualisation est un vaste et complexe sujet (que je ne maîtrise pas !). Mais au fond, cela revient à une chose simple permettre de faire fonctionner un (ou plusieurs) système d’exploitation (et/ou des applications) comme s’il était sur sa propre machine, alors qu’en réalité il tourneau sein d’un système d’exploitation hôte. Et pour arriver à ce résultat, il y a en gros trois approches :

La virtualisation par isolation - cela consiste à mettre en place des contextes permettant de redéfinir ce que voit le conteneur. C’est typiquement ce que fait chroot qui cache la racine réelle du serveur pur ne montrer aux processus enfant qu’une partie de l’arborescence. C’est aussi ce que font de manière beaucoup plus complète OpenVZ, VServer ou encore les zones d’OpenSolaris.
La machine virtuelle - le principe est d’émuler un ensemble de matériel (carte réseau, carte écran, disque dur, etc) pour faire croire à l’OS du conteneur qu’il évolue sur une véritable machine. Si celui-ci est compilé pour le même processeur que la machine physique, il est possible de faire l’économie de l’émulation du processeur, ce qui apporte un énorme gain de temps. C’est ce que permettent KVM, le couple Qemu/Kquemu ou encore VirtualBox. Si l’OS est prévu pour un autre processeur, alors il faut aussi l’émuler comme le permet Qemu-ARM, Bochs, les émulateurs de console, etc.
La paravirtualisation - (ou hyperviseur) qui tente de ménager la chèvre et le choux en modifiant utilisant des OS conteneur qui ont “conscience” d’être hébergé chez un hôte, ce qui permet de jouer tantôt de l’isolation, tantôt de la virtualisation. C’est typiquement ce que permet XEN (et UML il me semble).

Finalement, ce que l’on peut en déduire à notre niveau, c’est que plus l’isolation entre le conteneur et l’hôte est forte, plus la partie logicielle qui va gérer le conteneur est complexe, et de manière incidente, plus les performances au sein du conteneur s’éloignent d’un système natif. Chroot étant d’un côté du spectre avec une très faible isolation mais des performances natives, à qemu-arm, totalement isolé mais avec de bien moindre performances.

Un Chroot totalement isolé

Pour commencer, un point très important à noter, les considérations de sécurité ne sont pas le sujet de ce papier. Et cela tombe bien car un chroot est tout sauf sécurisé. Cela passe très bien pour l’enfermement d’une poignée de services, mais cela deviendrait critique pour le chrootage d’un OS complet. En effet, le conteneur chrooté partage son /proc et son /dev avec l’hôte, et il a donc tout liberté pour s’introduire dans le système. Libertés que nous allons grandement restreindre mais je ne donne aucune garanti sur la résistance à l’intrusion.

Mais au delà des considérations de sécurité, un conteneur chroot, de par sa faible isolation, n’est pas pratique du tout dés qu’il s’agit de faire tourner plein de services dedans. En effet, si le système de fichier du conteneur est correctement isolé, il n’en est pas de même pour les processus (le conteneur “voit” ceux de l’hôte). Enfin concernant les interfaces réseau, il est bien évidement possible de créer un bridge ou un alias utilisé par l’environnement chrooté mais nombre de services deviennent de véritables empoisonneurs dés qu’il s’agit de les obliger à écouter une seule interface (ex. typiquement les RPC comme NFS ou YP). L’idéal serait donc de pouvoir disposer d’un chroot à géométrie variable, capable de disposer, au minimum, de son propre contexte processus et réseau.

Ce type de chroot est l’équivalent des zones de Solaris ou les Jails de BSD. Dans l’univers Linux il existe plusieurs possibilités allant dans ce sens avec des outils comme OpenVZ ou Linux VServer. Mais ces solutions ont un inconvénient de taille, ils ne fonctionnent qu’avec un patch du kernel et ont toujours un bon nombre de versions de retard. Ce ne serait pas un problème si de nos jours, certains outils aussi idiots qu’indispensables (udev pour ne pas le nommer) n’avaient pas le mauvais goût de fonctionner en user-land (où il n’a rien à foutre à mon sens) et donc imposer des versions récentes de kernel (c’est encore le cas récemment avec la dernière version d’udev qui impose un kernel 2.6.26, ou plus, à cause d’un appel à sa nouvelle fonction signalfs).

Linux Containers

Fort heureusement, une nouvelle solution commence à pointer le bout de son nez sous le nom de Linux Containers (ou LXC). Il s’agit là d’un jeu de nouvelles options dans le kernel qui ont la particularité d’être intégré en mainstream. Cela comprend un ensemble d’isolateurs (ou namespace) et cgroup (pour control group file system) permettant de contrôler de manière unifiée un jeu de processus et leurs enfants. Les isolateurs ajoutés sont nombreux et fonctionnent comme chroot pour la racine :

UTS namespace qui permet d’avoir pour chaque conteneur son propre hostname/domainame distinct de celui de l’hôte.
IPC Namespace qui permet d’avoir pour chaque conteneur son jeu privé de fonctions sem, shm, msg, etc.
User Namespace qui permet d’avoir par conteneur des utilisateurs de l’hôte distinct (y compris root !!), même s’ils partagent le même UID/GID.
PID Namespace – un apport énorme sur chroot, permettant au conteneur de disposer de sa propre liste de processus. Les processus host ne sont donc plus visible du conteneur.
Network namespace – la aussi une avancée très importante permettant au conteneur de disposer de ses propres interfaces réseaux (y compris localhost!).

L’ensemble de ces fonctionnalités (namespaces et cgroup) permet de créer relativement facilement un super-chroot beaucoup plus isolant que la version d’origine. C’est ce que cherche à obtenir le projet Linux Containers. Ce dernier fournit une batterie de nouvelles commandes qui à partir d’une simple racine (identique à celle utilisée pour un chroot), permettent de créer, démarrer, arrêter ou encore monitorer un conteneur.

Maintenant que nous avons la théorie en tête passons à la pratique.

Préparation de la machine hôte

Le kernel

L’utilisation du nouveau système de serveurs virtuels privés implique l’activation d’un certains nombre d’options dans le noyau. S’agissant de la distribution Mandriva, les paquets appelés kernel-server ont déjà ces options d’activées, il n’y a donc aucun noyau à recompiler si vous les utilisez. Pour les autres, vous devez tout d’abord ajouter le contrôle par groupe.

General setup —>
[*] Group CPU scheduler
[*] Group scheduling for SCHED_OTHER
[_] Group scheduling for SCHED_RR/FIFO
Basis for grouping tasks (Control groups)
(X) Control groups

[*] Control Group support —>
[ ] Example debug cgroup subsystem
[*] Namespace cgroup subsystem
[*] Freezer cgroup subsystem
[*] Device controller for cgroups
[*] Cpuset support
[*] Include legacy /proc/ /cpuset file
[*] Simple CPU accounting cgroup subsystem
[*] Resource counters
[*] Memory Resource Controller for Control Groups
[*] Memory Resource Controller Swap Extension(EXPERIMENTAL)

Activation du contrôle par groupe dans le kernel

Ensuite vous devez activer la prise en charge des espaces de nom :

General setup —>
[*] Namespaces support
[*] UTS namespace
[*] IPC namespace
[*] User namespace (EXPERIMENTAL)
[*] PID Namespaces (EXPERIMENTAL)
[*] Network namespace

Activation des namespaces dans le kernel

Vous n’avez plus qu’à recompiler le noyau et à démarrer dessus.

Montage de cgroup

cgroup est un psoeudo système de fichier, comme proc ou feu udevfs. Pour l’utiliser, vous devez donc créer un dossier sur lequel ce système sera monté. Pour automatiser cela, nous allons ajouter ce montage à fstab.

root#mkdir /cgroup

root#echo “none /cgroup cgroup rw 0 0″ >> /etc/fstab

root#mount /cgroup

montage du psoeudo filesystem cgroup

Mise en place du réseau

Là c’est la partie un peu “touchy” de l’histoire. En effet, chacun de nos conteneurs va à terme disposer de sa propre adresse IP. Il va donc nous falloir créer autant d’interface ethernet virtuels (veth) que de conteneur. Ensuite nous allons relier ces interfaces à un bridge. Le rôle du bridge va être de faire circuler l’information et peut être vu comme une sorte de switch.

Enfin, lorsque nous avons nos interfaces virtuelles connectés au bridge, il faudra encore y connecter l’interface physique de l’hôte (eth0) et assigner l’ancienne adresse IP ce cet interface au bridge lui-même. A partir de là notre switch virtuel est fonctionnel.

Ça c’est la théorie, et pour une fois la pratique est un peu plus simple. La seule chose que nous allons devoir faire est de créer le bridge et d’y associer l’interface physique. Les interfaces virtuels seront créés, connectés et paramétrés automatiquement lors du démarrage du conteneur correspondant.

Pour mettre en place le bridge, vous devez installer le paquet bridge-tools qui nous fournit, entre autre, la commande brctl. La création manuelle se passerait comme ceci :

# Création du bridge nommé br0

root#brctl addbr br0

# Paramétrage du bridge, ici nous réglons à 0 le délai de transfert (Forward Delay)

root#brctl setfd br0 0

# Ajout de l’interface physique au bridge

root#brctl addif br0 eth0

# On vide l’adresse IP de l’interface physique (remplacez eth0 par votre propre interface) …

root#ifconfig eth0 0.0.0.0

# … pour l’assigner au bridge (changer l’IP pour l’IP de votre host)

root#ifconfig br0 10.0.0.1

# Ajout d’une route pour que le bridge communique avec votre routeur (adresse à change pour vos besoins)

root#route add -net default gw 10.0.0.100 br0

Création manuelle d’un bridge

Voilà, c’est tout. Normalement, vous devez pouvoir pinger le monde extérieur et de l’extérieur pouvoir pinger votre host. Ceci étant dit, ça va être vite galère de faire cela à chaque fois. Chaque distribution permet d’automatiser ce genre de montage et sous Mandriva cela se fait simplement en commençant par arrêter le réseau (service network stop) puis en recopiant /etc/sysconfig/network-scripts/ifcfg-eth0 vers /etc/sysconfig/network-scripts/ifcfg-zbr0. Notez le “z” devant le “br0″ qui est une astuce stupide pour que cet interface se monte après eth0. Ceci fait, modifiez ifcfg-eth0 pour qu’il commence comme ceci :

DEVICE=eth0
BRIDGE=br0
BOOTPROTO=static
IPADDR=0.0.0.0
NETMASK=255.255.255.0
GATEWAY=0.0.0.0
ONBOOT=yes

Script de paramétrage de l’interface réseau physique

Puis modifier ifcfg-zbr0 pour qu’il commence comme cela :

DEVICE=br0
TYPE=bridge
DELAY=0
STP=off
BOOTPROTO=static
IPADDR=10.0.0.1
NETMASK=255.255.255.0
GATEWAY=10.0.0.100
DNS1=212.27.40.240
ONBOOT=yes

Script de paramétrage du bridge

Pour que cela fonctionne chez vous, vous devez bien évidement changer l’adresse de la passerelle (GATEWAY) et du serveur de nom (DNS1). Vous n’avez maintenant plus qu’à redémarrer le réseau (service network restart) et à tester comme précédemment pour voir si tout répond correctement. Le mieux est même de redémarrer la machine pour être certain que le montage est reproductible. Vous devriez ainsi obtenir les traces suivantes :

root#ifconfig

br0 Link encap:Ethernet HWaddr 00:1A:4D:5C:9A:04

inet adr:10.0.0.1 Bcast:10.0.0.255 Masque:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:11105 errors:0 dropped:0 overruns:0 frame:0

TX packets:11398 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:0

RX bytes:6019978 (5.7 MiB) TX bytes:1566064 (1.4 MiB)

eth0 Link encap:Ethernet HWaddr 00:1A:4D:5C:9A:04

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:2683832 errors:0 dropped:0 overruns:0 frame:0

TX packets:2128799 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:1000

RX bytes:3418220009 (3.1 GiB) TX bytes:1255231891 (1.1 GiB)

Interruption:28 Adresse de base:0×6000

root#route

Table de routage IP du noyau

Destination Passerelle Genmask Indic Metric Ref Use Iface

10.0.0.0 * 255.255.255.0 U 0 0 0 br0

link-local * 255.255.0.0 U 1262 0 0 br0

default 10.0.0.100 0.0.0.0 UG 10 0 0 br0

Preuve de fonctionnement du bridge

Lutter contre uDev

Dans la majorité des distributions “modernes”, udev prend en charge la détection des nouvelles interfaces réseau pour passer la main à un outil de paramétrage. Pour la Mandriva, cet outil va chercher à détecter la présence d’un script de configuration pour cette interface et le cas échéant en créer un. Ensuite il va donner la main à ifplugd pour que ce dernier monitore l’interface et le paramètre à l’aide du script lorsqu’il détectera son activité (link beat).

Ceci est très bien dans la majorité des cas mais bien ennuyeux concernant nos futures conteneurs. En effet, comme nous l’avons vu, LXC va créer automatiquement une interface ethernet virtuelle qu’il va rattacher au bridge. Comme pour l’interface physique, elle ne devra pas avoir d’adresse IP au niveau de l’hôte (elle en aura une au niveau du conteneur). Pour corser le tout, LXC nomme l’interface virtuelle veth_XXXXX, où XXXX est le pid du processus racine du conteneur. Du coup, udev va flanquer tout cela par terre et appelant la procédure de configuration automatique qui va créer un script pour chaque interface créée, c’est à dire à chaque redémarrage du conteneur (normal, le pid est à chaque fois différent). Et comme il n’a aucune information sur cette interface, la procédure va aller au plus simple en lui affectant une recherche d’IP via DHCP. Ifplug va récupérer cela et reconfigurer l’interface virtuelle avec l’IP que lui donnera un DHCP du réseau, ce qui va la déconnecter du bridge.

Pour régler ce problème, il faut paramétrer uDev pour ignorer les interfaces de type veth. Pour cela, il faut aller dans /lib/udev/rules.d/76-net.rules (cela peut varier d’une distro à l’autre) et ajouter la ligne sur veth suivante :

SUBSYSTEM!=“net”, GOTO=“mdv_net_end”
ENV{INTERFACE}==“”, GOTO=“mdv_net_end”
KERNEL==“veth*”, GOTO=“mdv_net_end”

ACTION==“add”, RUN+=“net_create_ifcfg”
ACTION==“add|remove”, RUN+=“net_action”

LABEL=“mdv_net_end”

Paramétrage d’uDev

Ceci fait, un petit coup de pkill udevd, udevd -d pour relancer, et le problème devra être réglé. Nous vérifierons cela un peu plus loin.

Récupération des outils Linux Containers

Comme dit plus haut, le nouveau système Linux Containers dispose d’une série d’outils user-land permettant de gérer les conteneurs. Si vous avez déjà cela en paquet dans votre distribution, installez-le, sinon, il suffit d’aller les chercher et les compiler :

#git clone git://lxc.git.sourceforge.net/gitroot/lxc/lxc

…

#cd lxc

#./autogen

…

#./configure –prefix=

…

#make

…

#make install

…

#ls /bin/lxc-*

/bin/lxc-cgroup* /bin/lxc-console* /bin/lxc-destroy* /bin/lxc-freeze* /bin/lxc-monitor* /bin/lxc-restart* /bin/lxc-start* /bin/lxc-unshare*

/bin/lxc-checkconfig* /bin/lxc-create* /bin/lxc-execute* /bin/lxc-info* /bin/lxc-netstat* /bin/lxc-setcap* /bin/lxc-stop* /bin/lxc-version*

/bin/lxc-checkpoint* /bin/lxc-debian* /bin/lxc-fedora* /bin/lxc-ls* /bin/lxc-ps* /bin/lxc-sshd* /bin/lxc-unfreeze* /bin/lxc-wait*

Compilation des outils LXC

Tout est maintenant enfin prêt pour créer notre premier conteneur.

Utilisation de Linux Container

Création d’un conteneur mandriva

Les conteneurs LXC sont stockés dans le dossier /var/lib/lxc (personnellement j’ai fais un symlink vers un dossier plus adéquat). Chaque conteneur aura là dedans un dossier à son nom (ex. /var/lib/lxc/mon_serveur pour le conteneur mon_serveur). Dans chacun de ces dossiers se trouvera un sous-dossier rootfs qui correspond à la racine du système virtualisé (comme pour chroot). La première chose à faire est donc de créer la structure d’accueil. Pour cela nous allons commencer par créer un fichier de configuration pour la nouvelle machine, nommons le mon_serveur.conf à la racine du dossier home.

lxc.utsname = mon_serveur
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 10.0.0.10/24
lxc.network.name = eth0

lxc.pts=1023
lxc.tty=12

// Droits sur null et zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm

// Droits sur random et urandom
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm

// Droits sur l‘horloge
lxc.cgroup.devices.allow = c 254:0 rwm

// droits sur les consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm

~/mon_server.conf

Ce fichier de configuration contient principalement le nom du serveur et le paramétrage réseau de celui-ci. Le gros bloc à la fin correspond aux droits du group de processus représenté par le conteneur. En effet, nous allons grâce à cgroup pouvoir paramétrer finement ce que le conteneur a le droit de faire. Il nous paramétrons cgroup pour autoriser l’accès aux devices important du sous-système (/dev/null, /dev/urandom, etc.).

Nous allons maintenant utiliser cette configuration pour créer le conteneur :

root#lxc-create -n mon_serveur -f ~/mon_serveur.conf

Création du conteneur

La structure est maintenant créée, ce que nous pouvons vérifier facilement :

# tree /var/lib/lxc/mon_serveur/

/var/lib/lxc/mon_serveur/

|– config

|– network

| `– veth0

| |– ipv4

| | `– addresses

| |– link

| |– name

| `– up

|– pts

|– state

|– tty

`– utsname

Structure du conteneur

Bien évidement il s’agit là que d’une configuration initiale qu’il est possible d’étendre par la suite. La configuration que se trouve la racine est un peu comme celle d’un kernel linux dans /boot. Elle est là à titre indicatif et je n’ai constaté aucun impact en la modifiant, sauf pour le paramétrage du cgroup. Pour le reste, si vous désirez changer la configuration, il faut toucher aux éléments suivants :

network/vethX – pour les paramètres réseau
pts – pour le nombre de /dev/pts.
tty – pour le nombre de tty alloué.
utsname – pour le nom de la machine.

Création de la racine

Comme vous l’avez déjà constaté, il manque pour l’instant le dossier rootfs qui va contenir la racine de notre système. Pour la créer nous allons utiliser la même technique que pour la création d’un GNU/Linux en chroot :

root#Création de la racine

# mkdir /var/lib/lxc/mon_serveur/rootfs

root#population d’une mandriva (utilisez basesystem-mini pour une version encore plus compact)

# urpmi basesystem urpmi locales-fr drakxtools-curses –root /var/lib/lxc/mon_serveur/rootfs

Peuplement de la racine

Notez que vous pouvez installer une version 32bits de GNU/Linux dans un conteneur pour un hôte 64bits sans aucun problème. Vous pouvez aussi installer n’importe quelle distribution linux pour peu qu’elle soit compatible avec le kernel hôte.

Notez enfin que vous pouvez ajouter d’autres paquets à l’installation en relançant la commande urpmi ... --root ....

Préparation de /dev

Il s’agit là d’une étape optionnelle. En effet, urpmi nous a créé un dossier /dev correctement peuplé. Mais certains paranoïaques voudront limiter au maximum le nombre de devices disponibles dans ce dossier. La procédure qui suit permet de vider le dossier /dev, et d’y mettre le stricte nécessaire :

# chroot rootfs

# cd /dev

# rm -rf *

# mkdir pts

# mkdir shm

# mknod -m 777 null c 1 3

# mknod -m 777 zero c 1 5

# mknod -m 644 random c 1 8

# mknod -m 644 urandom c 1 9

# chown root:root random urandom

# exit

Le minimum dans le dossier /dev

Paramétrage du réseau et des services

Pour que tout soit fonctionnel, il y a encore quelques paramétrages à faire. Pas la peine de lancer le conteneur pour cela, un chroot rootfs devrait suffire.

Tout d’abord nous allons installer les services nécessaires au conteneur (openssh-server est un minimum pour avoir une console, etc) en passant par upmi. Ensuite il suffira d’utiliser chkconfig ou drakxservices pour déterminer les services à lancer.

Nous allons ensuite vider /etc/fstab de son contenu pour éviter les montages intempestifs et y ajouter les montages importants. Au final, votre fichier /etc/fstab devra ressembler à ceci :

/proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
/sys /sys sysfs defaults 0 0

/etc/fstab du conteneur

Après cela, il nous faut créer un fichier /etc/sysconfig/network-scripts/ifcfg-eth0 qui contiendra quelque chose comme cela :

DEVICE=eth0
ONBOOT=yes
IPADDR=10.0.0.10
NETMASK=255.255.255.255
GATEWAY=10.0.0.100
DNS1=DNS1=212.27.40.240

Gestion du démarrage/arrêt

# Création d’un faux “init” (à voir plus loin) # mv /sbin/init /sbin/init.old # echo “echo ‘Bienvenue sur le conteneur’” > /sbin/init # echo “/bin/sh” >> /sbin/init # exit

Normalement il ne devrait rien y avoir de plus à faire. Malgré tout, nous allons avoir quelques problèmes avec /sbin/init :

Comme nous avons installé dans rootfs une distribution tout ce qu’il y a de plus standard, le processus d’initialisation va tenter, via rc.sysinit, de monter des tas de choses inutiles voir nuisibles au conteneur (ex. udev). Ce serait facile à régler en vidant rc.sysinit de son contenu.
Je n’ai pas trouvé le moyen d’éteindre proprement les services lancés par un halt, shutdown ou encore /etc/rc.d/rc.shutdown.
Malgré tous mes efforts, je n’ai pas réussi à créer au sein du conteneur un seul tty valide. Ce qui dans le cadre d’un init standard pose problème car le lancement des consoles (mgetty ou mingetty) plante entraînant un plantage de l’init lui-même (too many respawn).

Pour régler tout cela, ma solution (un peu pourrie j’en conviens) consiste à créer notre propre remplacement de /sbin/init qui ressemblera à cela :

#!/bin/sh

# Réseau
. /etc/sysconfig/network
. /etc/sysconfig/network-scripts/ifcfg-eth0
route add -net default gw $GATEWAY eth0
hostname ${HOSTNAME}

# Set the NIS domain name
if [ -n "$NISDOMAIN" ]; then
nisdomainname $NISDOMAIN
fi

# arrêt/démarrage des services
function process() {
for service in $(ls /etc/rc.d/rc$1.d/* | sort); do
case $service in
*network* | *halt* | *kill*) ;;
*)
$service $2
;;
esac
done
}

# Montage des psoeudos systèmes de fichier
mount -t proc /proc /proc
mount -t sysfs /sys /sys
mount -t tmpfs none /dev/shm
mount -a

# Démarrage des services
process 5 start

# Attente de la mise mort de la machine
rm -rf /.dead
> /.running
while [ -f /.running ] ; do
sleep 1
done

# Arrêt des services
process 0 stop

# Démontage des systèmes de fichier
umount /proc
umount /sys
umount /dev/shm
umount -a

/sbin/init dans le conteneur

Telle que cette initialisation est conçue, elle commence par monter les systèmes de fichiers utiles (sauf /dev/pts est pris en charge par lxc) et ensuite va démarrer les services actifs. La partie bien stupide qui suit permet de palier à l’absence de tty. Il s’agit d’une simple boucle d’attente sur la présence du fichier /.running. Ainsi pour arrêter le conteneur, il suffit de détruire ce fichier. Les services alors proprement sont déchargés et les systèmes de fichier démontés. Le conteneur s’arrêtera alors de lui-même.

Lancement du conteneur

Le conteneur est maintenant prêt à être lancé, cela se passe avec la commande lxc-start :

# lxc-start -n mon_serveur

Starting sshd [ OK ]

Lancement du conteneur

Et c’est tout, le conteneur est en route et dispose d’une logiquement adresse IP. Vous pouvez donc la “pinger” de l’extérieur pour vérifier. Vous constaterez au passage sur l’hôte l’apparition d’une interface veth0 qui est l’équivalent d’eth0 pour le conteneur. Vous pouvez éteindre le conteneur en vous connectant en ssh dessus et en détruisant le fichier /.running.

hostssh mon_user@10.0.0.10

mon_user@10.0.0.10’s password:

mon_user@mon_serveur [~] $ su -

Password:

root@mon_serveur [~] rm -rf /.running

root@mon_serveur [~] Connection to 10.0.0.10 closed by remote host.

Connection to 192.168.154.103 closed.

Connexion au conteneur et extinction

Conclusion

Il est possible de se rendre la vie plus agréable en ajoutant, comme pour OpenVZ, la possibilité que certains conteneurs se lancent au démarrage de l’hôte. C’est le rôle de ce script qui est à placer en /etc/init.d et à activer avec chkconfig ou drakxservices. Pour l’utiliser il suffit de rajouter à la configuration du conteneur un paramètre lxc.onboot=yes qui impliquera son démarrage automatique. Ce script exploite un autre script de mon cru, lxcctl qui simplifie le lancement et l’extinction d’un conteneur. Il fournit ainsi les commandes lxcctl start mon_conteneur, lxcctl stop mon_conteneur et lxcctl info mon_conteneur. En espérant que ceci finisse par être intégré à LXC directement (sous réserve que les tty fonctionnent évidement).

Voilà, c’est la fin de ce “petit” papier sur ce projet très prometteur qu’est LXC. Personnellement j’ai un peu trouvé ce que je cherchais depuis très longtemps et que j’avais effleuré avec chroot. Grâce à LXC, je peux non seulement virtualiser le serveur domestique, mais aussi dupliquer à volonté des conteneurs pour mes projets (un conteneur “type” pour le développement WEB, un autre pour Android, etc.). Et tout cela sans souffrir de la moindre perte de performance.

L’installation d’Hadopi sous Linux enfin possible !

stratus — Mon, 28 Jun 2010 11:53:21 +0000

Ça y est ! J’ai trouvé !
Il est anéfé possible d’installer le logiciel d’Hadopi sous Linux. Voici la procédure d’installation depuis un terminal ( [troll] Linux oblige [/troll] ) qui vous rafraîchira un peu les idées après l’ivresse des fêtes :

Code :

albanel@majors$ sudo apt-get install hadopi
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
 lib-bypass-constitution-francaise lib-propagande
 lib-autorite-administrative-avec-tous-les-droits
E Les paquets suivants ont des dépendances non satisfaites : hadopi dépend de lo
bby-vivendi, mais lobby-vivendi est en conflit avec lib-information-impartiale.
Les actions suivantes permettront de résoudre ces dépendances :
 s-asseoir-sur-les-libertés-fondamentales
Accepter cette solution [O/n] ? O

Les paquets suivants seront enlevés :
 lib-presomption-d-innocence lib-droits-de-la-defense
 lib-separation-des-pouvoirs lib-information-impartiale
Les NOUVEAUX paquets suivants seront installés :
 hadopi lib-bypass-constitution-francaise lib-propagande
 lib-autorite-administrative-avec-tous-les-droits lobby-vivendi
0 mis à jour, 5 nouvellement installés, 4 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 70 heures de débats à l'Assemblée Nationale et un n
ombre indéterminé d'heures de propagande dans les médias.
Après cette opération, 500000€ d'argent public supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? O

Suppression de lib-presomption-d-innocence...
Suppression de lib-droits-de-la-defense...
Suppression de lib-separation-des-pouvoirs...
Suppression de lib-information-impartiale...

Réception de : 1 http://www.vivendi.fr lobby/control lib-bypass-constitution-fra
ncaise réceptionnés en 1s
Réception de : 2 http://www.vivendi.fr lobby/control lobby-vivendi réceptionnés
en 1s
Réception de : 3 http://www.vivendi.fr lobby/control lib-propagande réceptionnés
 en 1s
Réception de : 4 http://www.sarkozy.fr util/rights lib-autorite-administrative-a
vec-tous-les-droits réceptionnés en 1s

Dépaquetage de lib-bypass-constitution-francaise...
Dépaquetage de lobby-vivendi...
I lobby-vivendi était déjà présent et très bien intégré au système.
Dépaquetage de lib-propagande...
Dépaquetage de lib-autorite-administrative-avec-tous-les-droits...

Génération de hadopi...
Refus de discussions...
Rejet des amendements proposés (utilisation du module anéfé-rejeté)...
Compilation de oofirewall...
Compilation de arguments-fallacieux...
 Compilation de les-accords-de-l-elysee...
 Compilation de les-ventes-de-cd-chutent-de-50%-et-celles-des-cassettes-audio-d
e-90%-c-est-inadmissible...
 Compilation de la-creation-est-en-train-de-mourir-a-cause-de-gens-qui-attaquen
t-les-bateaux...

W Le module 5-gus-dans-un-garage semble poser des problèmes de compilation de ar
guments-fallacieux.

E Problème lors de la génération de hadopi : des composants cachés derrière des
rideaux sont apparus de manière inattendue. Réessayer [O/n] ? O

Pour éviter que le problème ne se reproduise, il est nécessaire de mettre à jour
le module deputes-godillots. Souhaitez-vous mettre à jour [O/n] ? O

Compilation de cope-rabat-les-troupes...
Compilation de laver-l-affront...
Mise à jour de deputes-godillots...

W De nombreux paquets de type amendement ralentissent l'installation d'hadopi.

L'installation de hadopi semble avoir réussi.

Vérification de la compatibilité avec la constitution française...
E Le module lib-bypass-constitution-francaise a été détecté par le conseil const
itutionnel.
E Le module répression a dû être désactivé pour protéger la constitution.

Installation obligatoire de internet-liberte-fondamentale.
Réception de : 1 http://www.constitution.fr rights internet-liberte-fondamentale
 réceptionnés en 1s
Dépaquetage de internet-liberte-fondamentale...

albanel@majors$ for m in media; do echo 'Je prends acte de la décision du consei
l constitutionnel. 95% du texte a été validé.'; done

E lobby-vivendi panic détecté.
Prise en charge de l'erreur par sarkozy et lobby-vivendi.

exit

sarkozy@majors# deluser albanel
sarkozy@majors# ls gauche/corrompus/*
 Trop de résultats ont été trouvés : affichage des premiers résultats.
 jack_lang frederic_mitterrand
sarkozy@majors# adduser lang
 > opération échouée
sarkozy@majors# adduser mitterrand
sarkozy@majors# su mitterrand

mitterrand@majors$ sudo /etc/init.d/pantind start
 * Starting PantinServer [ OK ]
mitterrand@majors$ pantin -verbose
Attente des ordres...
Exécution à distance de "apt-get install hadopi2"...
L'installation du paquet hadopi2 peut corriger le problème. Tenter [O/n] ? O
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
 ordonnance-penale negligence-caracterisee
 on-vous-prend-vraiment-pour-des-cons
Les NOUVEAUX paquets suivants seront installés :
 hadopi2 ordonnance-penale negligence-caracterisee
 on-vous-prend-vraiment-pour-des-cons
Les paquets suivants seront mis à jour :
 lib-bypass-constitution-francaise
0 mis à jour, 4 nouvellement installés, 0 à enlever et 1 non mis à jour.
Il est nécessaire de prendre 40 heures de débats à l'Assemblée Nationale.
Après cette opération, 300000€ d'argent public supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? O

Réception de : 1 http://justice-expeditive.fr tools ordonnance-penale réceptionn
és en 1s
Réception de : 2 http://justice-expeditive.fr tools negligence-caracterisee réce
ptionnés en 1s
Réception de : 3 http://habitudes.gouv.fr kernel on-vous-prend-vraiment-pour-des
-cons réceptionnés en 1s
Réception de : 4 http://henrard.fr control lib-bypass-constitution-francaise réc
eptionnés en 5 minutes

Dépaquetage de ordonnance-penale...
Dépaquetage de negligence-caracterisee...
Dépaquetage de on-vous-prend-vraiment-pour-des-cons...
I En fait ce module était déjà présent sur le système depuis un moment.
Dépaquetage de lib-bypass-constitution-francaise...

Paramétrage de on-vous-prend-vraiment-pour-des-cons...
Paramétrage de lib-bypass-constitution-francaise...

Génération de hadopi2...
Refus de TOUTES discussions (ignorer-analyses-pertinentes activé)...
Rejet de TOUS les amendements proposés (utilisation du module anéfé-rejeté-en-ra
fale)...
Le paquet arguments-fallacieux existait déjà, mais il nécessite maintenant les d
épendances arguments-fallacieux-negligence-caracterisee et arguments-fallacieux-
ordonnance-pénale. Installer [O/n] ? O

Réception de : 1 http://henrard.fr control arguments-fallacieux-negligence-carac
terisee réceptionnés en 2 jours
Réception de : 2 http://henrard.fr control arguments-fallacieux-ordonnance-pénal
e réceptionnés en 1 jour

Dépaquetage de arguments-fallacieux-negligence-caracterisee...
Dépaquetage de arguments-fallacieux-ordonnance-pénale...

W hadopi2-senat-1 est moins performant que hadopi-senat-*.
I deputes-godillots utilisé pour compiler le module vote-solennel.
W Problème éventuel de sécurité. Des éléments de compilation de vote-solennel on
t peut-être été contrôlés à distance : des incohérences entre leurs données et l
eurs actions ont été détectées.
La compilation de vote-solennel a réussi.

W L'installation de hadopi2-senat-2 a fonctionné, mais il semble que 90% du code
source du paquet n'ait pas été utilisé.

Compilation de vote-solennel-2...
I deputes-godillots fonctionne à merveille.
La compilation de vote-solennel-2 a réussi.

Vérification de la compatibilité avec la constitution française...
E Le module on-vous-prend-vraiment-pour-des-cons a fortement déplu au conseil co
nstitutionnel.
E Le paquet hadopi2 a été tagué "censuré" par le conseil constitutionnel.

Attente des ordres...
Ordre reçu de lobby-vivendi : créer une taxe sur les fournisseurs d'accès sans c
ontrepartie.
Résolution du problème trouver-des-arguments-bidons-pour-faire-passer-ça-et-refu
ser-la-contribution-créative en cours...
Réception de : 1 http://www.majors.fr help toubon réceptionnés en 1s
Réception de : 2 http://www.majors.fr help zelnik réceptionnés en 1s

Attente des ordres...

Quel suspense !

Hormis l’objectif de divertissement proposé par ce déroulement d’installation quelque peu singulier et le parti pris flagrant dans ce processus, il s’agit également d’une rétrospective détaillée du processus de création et de (tentative) de mise en place d’Hadopi.

La suite au prochain épisode ?

( source : http://blog.rom1v.com/2009/09/apt-get-install-hadopi/ )

Moving Backuppc Data Dir

stratus — Fri, 11 Jun 2010 01:51:11 +0000

Tech Recipe for Backuppc

I will explain briefly how to move the Backuppc __TOP_DIR__ to another disk. The main reason of this long data processing is the performance improvement. I’ve tried several Filesystems and different under layer block device ( RAID5, RAID10) alwaysover LVM.

For the moment the best seems to be RAID10 with 32K chunksize and a reiserfs filesystem mounted with (notail,noatime) options.

The backup speed is not that much faster than on ext3 filesystem, but the main advantage of Reiserfs is that compare to ext3 the disk usage is reduced from 34G in ext3 to 27G in Reiserfs.

The next step will be to test Btrfs performance but for that I first need to migrate from kernel 2.6.18 to 2.6.28 or higher

So let start the recipe

Copy the real Files (the pool or cpool) to the new disk

I do prefer rsync but other method are possible (simple cp, tar, …)

cd /var/lib/backuppc rsync -aq --exclude=pc/ ./ /new_drive/new_backuppc/

be patient this can be long… to see what’s going on replace -aq by -avP

Use an Internal backuppc command (BackupPC_tarPCCopy) to copy each PC hardlinks structure

this is also very long treatement. A huge amount of small hardlinks are read and relinked to the new destination

su __BACKUPPCUSER__ cd NEW_TOPDIR mkdir pc cd pc __INSTALLDIR__/bin/BackupPC_tarPCCopy __TOPDIR__/pc | tar xPf -

too keep an eye on the progress I’ve found a small tool pretty handy to monitor piped data: “bar”

/usr/share/backuppc/bin/BackupPC_tarPCCopy /var/lib/backuppc/pc | bar -dan -bs 4096 | tar xPf -

Here you are for the moment

Glad to hear any comment from your backup experience.

Vi VimDiff

stratus — Fri, 04 Jun 2010 17:41:36 +0000

Usefull vimdiff commands to view diff and merge

October 15, 2008 @ 8:20 am · Filed under Linux

Diffing the files and merging them is one of the very common task we do everyday. Following are few very useful commands to view the diff using vim and merge them using the vimdiff commands instead of copying and pasting from one file to another.

To diff two files using vim :

vimdiff file1 file2
or
vim -d file1 file2

Ofcourse you can use gvim also but I don’t prefer using GVIM.

gvimdiff file1 file2

Commands :

[c : Jump to previous diff
]c : Jump to the next diff

do or :diffget : Diff obtain (get the changes to the current buffer/file from the other buffer)
dp or :diffput : Diff Put (Put the changes from the current buffer/file to the other buffer)

As this being one of very command task I do, I have mapped them to single keys for the easy access.

nmap [czz
nmap ]czz
nmap do
nmap dp

The zz in the end of the command [c will center at the point of the diff so that we can view the diff clearly.

~Enjoy Vim

WebDAV CGI

stratus — Wed, 12 May 2010 10:14:06 +0000

… is a Perl CGI script that enables the WebDAV protocol (class 1,2,3) for web server. If you need correct permissions for files and folders you can install this WebDAV CGI script and a UID/GID wrapper. The Apache module mod_dav does not support UID/GID wrapping, so this implementation fills up this gap as a (most complete) replacement.

Content of this topic:

Features
Download
Installation
Licensing
Links

Features

WebDAV CGI …

supports WebDAV compliance classes 1, 2 and 3
implements CGI interface
offers a simple web interface for file/folder management
is wrappable to change UID/GID for file permissions other than web server permissions

My test environment:

Ubuntu 8.04 LTS
Apache 2.2.x
Perl 5.8.8

WebDAV CGI is tested with following WebDAV clients (licensing):

Firefox web browser – for folder listing, POST uploads and download tests (free)
M$ Internet Explorer 7 – for web interface tests (commercial)
cadaver – a Linux command line WebDAV client (free)
nautilus – the Gnome file manager (free)
konqueror – the KDE browser (free)
OpenOffice (free)
Web Folders – Windows XP & Windows Vista (build-in)
Novell netdrive (commercial)
BitKinex WebDAV Client (free)

Known Problems:

Windows Web Folder tries to read folders without ‘/’ at the end and Apache responses with a redirect (Workaround: use Apache rewrite rule instead of direct folder access)
Windows 7 does not support SSL with Web Folders (yet) and has some trouble with HTTP Basic authentication (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel should be 2(DWORD))
Amaya upload does not work yet
DAVExplorer has some trouble with XML parsing (PROPFIND) … sometimes.
Adobe Dreamweaver has some trouble to read folders
nautilus cannot copy folders via clipboard

Download

TuXxX Blog download : [filebase:file:file3]

Latest version: 0.3.3 (Changes: see webdav.pl)

webdav.pl – the WebDAV CGI
Downloads: 35
webdavwrapper.c – a sample UID/GID wrapper: takes UID from the file/folder or if file/folder does not exists takes the UID of the authenticated user (REMOTE_USER)
Downloads: 18

The latest BETA release is also available: webdav-beta.pl (Downloads:

Installation

install required CPAN modules (Debian/Ubuntu package name):
- CGI (libcgi-perl)
- DBI (libdbi-perl) and a database driver, e.g. DBD::SQLite (libdbd-sqlite3-perl)
- Date::Parse (libtimedate-perl)
- File::Copy::Recursive (libfile-copy-recursive-perl)
- OSSP::uuid (libossp-uuid-perl)
- XML::Simple (libxml-simple-perl)
You can do that with ‘perl -MCPAN -e "install "‘ or with ‘apt-get install ‘.

compile your wrapper, change the permissions and put it into your cgi-bin, e.g:

gcc -o webdavwrapper webdavwrapper.c
strip webdavwrapper

chown root:root webdavwrapper
chmod ug+s webdavwrapper

cp -p webdavwrapper /srv/www/cgi-bin/

put the WebDAV CGI webdav.pl into your cgi-bin; edit webdav.pl to setup and change permissions, e.g:
```
cp webdav.pl /srv/www/cgi-bin
vim webdav.pl
chmod a+rx webdav.pl
```

configure your web server:

you can do that with rewrite rules
or with a handler action

Here is an example Apache 2.x configuration:

Action webdav-cgi /cgi-bin/webdavwrapper

	SetHandler webdav-cgi
	#necessary for PUT, MKCOL and LOCK:
	ErrorDocument  404  /cgi-bin/webdavwrapper
	#fix Windows requests to folders without slash (handle redirects):
	ErrorDocument  301  /cgi-bin/webdavwrapper
	AuthType Basic
	AuthName "WebDAV space"
	AuthUserFile /path-to-my-auth-file
	Require valid-user

# if you want to map this to a real path, do that:
# (end setup VIRTUAL_BASE)
RewriteRule  ^/mywebdavspace(.*) /cgi-bin/webdavwrapper \
	[L,E=PATH_TRANSLATED:/srv/www/htdocs$1]

Licensing

GPLv3

Free Software Foundation réplique

stratus — Tue, 04 May 2010 12:09:21 +0000

Voici un nouveau rebondissement dans l’affaire qui oppose Adobe à Apple concernant la technologie Flash. Pour mémoire, le

The Gnu Guru

PDG de la firme de Cupertino s’était exprimé au travers d’un communiqué de presse afin de justifier l’absence de Flash sur l’iPhone, l’iPod Touch et l’iPad. Steve Jobs déclarait en effet que l’avenir des technologies mobiles devait passer par des standards ouverts tel que HTML, CSS et JavaScript plutôt que par une technologie propriétaire telle que Flash.

De son côté Adobe soulignait la compatibilité de son lecteur avec une multitude de plateformes simplifiant alors la tâche pour l’éditeur qui ne devra pas développer une version de son application spécifiquement pour le système propriétaire de l’iPhone OS.

C’est désormais au tour de la Free Software Foundation, l’organisme chargé de défendre et promouvoir les valeurs du logiciel libre, de s’exprimer sur le sujet au travers d’un communiqué de presse. En effet, le porte -parole et activiste John Sullivan, invité sur le magazine Arstechnica, pointe du doigt l’hypocrisie des deux sociétés promouvant des standards ouverts sans pour autant suivre leurs propres principes. John Sullivan souligne en effet que Steve Jobs n’a fourni aucune explication pour le choix de technologies web ouvertes. « S’il avait dit quoique ce soit sur l’importance de la liberté de l’utilisateur sur le web, son hypocrisie serait devenue explicite », déclare ainsi M.Sullivan.

Sullivan rappelle également qu’Apple utilise le format vidéo H.264 et non le codec open source Ogg Theora choisi par Firefox et Opera. Par ailleurs le web libre que Steve Jobs souhaite déployer ne reste accessible qu’au travers d’un système propriétaire, qu’il s’agisse de l’iPhone OS ou de Mac OS X. John Sullivan conclut ainsi : « un web libre nécessite un logiciel libre. Vous n’aurez pas d’Internet libre si votre logiciel accédant à la Toile est limité à un nombre arbitraire d’ordinateurs ». Au sein du débat pour un Internet libre et ouvert, la fondation souhaite alors recentrer ce dernier vers le logiciel libre.

Bacula, Sauvegarde sur Disque Dur

stratus — Tue, 06 Apr 2010 06:19:57 +0000

Introduction

Le volume de données utilisées en entreprise croît de façon exponentielle depuis plusieurs années, leur criticité aussi.

Quand on sait que 70% des entreprises qui subissent un crach informatique majeur font faillite dans les 2ans, on comprend que préserver l’intégrité des données est primordial.
Un système de sauvegarde fiable, robuste et performant n’est donc pas du luxe pour quiconque manipule plusieurs giga octets de données quotidiennement.

La sauvegarde est une tâche gourmande en place et en temps de réalisation, il faut donc trouver une solution de sauvegarde mutualisée qui rende cette tâche la plus sûre et la moins fastidieuse possible.
Cette article est basé sur la suite logiciel Bacula qui vous allez le voir est une solution de sauvegarde de niveau profesionnel.

1. Les différentes solutions de sauvegarde

1.1. Solutions libres

Il existe un grand nombre de projets de sauvegarde mutualisée client/serveur en open source, parmi lesquels Amanda, Remote Backup & Bacula.
Nombre de ces projets sont encore en developpement et comportent des bugs, il convient donc d’être très vigilant quand à la solution à adopter en production puisqu’il serait cocace que votre système de sauvegarde, sur lequel vous misez tous vos espoirs en cas de coup dur souffre d’un bug au moment de la récupération des données critiques.

J’ai choisi le projet Bacula (www.bacula.org) car il a acquit une certaine maturité et est développé par une équipe de professionnels. De plus, il possède un panel de fonctionnalités epoustouflant, bien que certaines ne soient pas encore implémentées.
Ce projet est porté sur la distribution Debian, il est donc très aisé à maintenir.
Sa prise en main et sa configuration restent néanmoins deux choses particulièrement délicates et déroutantes, je vous invite donc à vous réferez au copieux manuel (491 pages) après avoir lu cet article.

1.2. Solutions commerciales

Tous les grands constructeurs de matériel informatique proposent des matériels accompagnés de solutions logicielles de sauvegardes, propriétaires ou non.
Vu la spécificité de chacune des ces solutions et surtout leur coût de déploiement et de fonctionnement, je ne m’y interesserais pas dans cet article.

1.3. Pourquoi un système de sauvegarde sur Disque?

Historiquement la sauvegarde utilisait comme media les bandes magnétiques, permettant de stocker un volume collossal de données.
La donne a légérement changé ces dernières années, en effet :
- La taille des Disques Durs a considérablement augmenté (de quelques Gigaoctets il y a peu à plusieurs centaines maintenant).
- Le prix de revient du Gigaoctet sur disque dur à baissé de façon significative.
- Les disques IDE durs nouvelle génération ont gagné indéniablement en fiabilité.

La sauvegarde sur Disque Dur permet donc :
- Une sécurité des données proche de celle des Bandes magnétiques avec l’utilisation de la technologie RAID.
- Une vitesse des phases de sauvegarde mais surtout de restauration multipliée par 30 par rapport aux sauvegardes sur bandes.
- Une mise en place à moindre coût puisqu’il n’est plus nécessaire d’acheter de matériel onéreux, toutes les cartes mères sont équipées de controleurs IDE, il suffit donc d’acheter les disques nécessaires à la sauvegarde.

L’utilisation des Bandes magnétiques permet cependant une fiabilité supérieure de part la nature du support (insensible aux chocs) et offre la possibilité d’emmener les bandes quotidiennement dans un lieu sécurisé, permettant une récupération en cas de gros dégats matériels sur le serveur de stockage.
L’utilisation couplée de ces 2 systèmes est une éventualité qui offre une très grande souplesse, mais peut se révéler complexe a mettre en oeuvre au début.

2. Le projet Bacula

2.1. Présentation

Bacula est un projet de sauvegarde réseau client/serveur professionel ambitieux.
Il offre une modularité hors du commun, en effet chaque étape de la sauvegarde est décomposée en un “daemon” associé et permet donc d’assouplir considérablement l’architecture du sytème de sauvegarde.
Il permet de sauvegarder sur de nombreux médias (Disques dur, bandes magnétiques, prise en charge des chargeurs de bandes…), cependant je ne traiterais ici que les fonctionnalités de sauvegarde sur disques puisque c’est le thème de cet article.

On peut assimilier Bacula à une suite de plusieurs logiciels, chacun affecté à une tâche propre (une des bases de la philosophie linux).
Bacula est sous licence GPLv2.

2.2. Architecture du logiciel

Un schéma vaut parfois mieux que de longues explication, je reprend ici celui du manuel qui est très bien fait :

2.2.1 Le directeur

C’est le coeur du système de sauvegarde, c’est lui qui “commande” et qui unit les différents éléments.
Il se présente sour la forme d’un daemon : bacula-dir qui écoute sur le port 9101.
Il ne peut y avoir qu’un directeur par architecture de sauvegarde (pas de réplication).

2.2.2 Le Storage Daemon

Il est chargé de l’enregistrement physique des données qui lui sont fournies, c’est lui qui gère l’interaction avec le matériel, dans cet article il s’agira de disques durs. Le matériel doit donc être connecté “logiquement” au serveur qui éxécute ce storage daemon (il doit être “monté”).
Ce daemon, bacula-sd, écoute sur le port 9103.
Il reçoit les ordres du directeur mais aussi et surtout les données directement du Filer Daemon (voir ci dessous).
A noter qu’il peut evidemment y avoir plusieurs storage daemon par architecture de sauvegarde.

2.2.3 Le Filer Daemon

C’est la partie cliente à proprement parler du logiciel puisque c’est ce daemon qui sera executé sur les machines contenant les données à sauvegarder.
Il s’appelle bacula-fd, écoute sur le port 9102, reçoit les ordres du directeur et envoie les données directement au Storage Daemon.
La compression (optionnelle) a lieu au niveau de ce daemon, limitant ainsi la charge sur les machines executant le directeur et les storage daemon et permettant aussi de limiter le volume de données transitant sur le réseau.

Note : il existe en version Unix/linux & windows

2.2.4 La console

C’est elle qui permet de contrôler le directeur, mais aussi directement les filer et storage daemons.
Elle peut être executée sur une machine disctinte (connexion par le port 9101).
Il existe une version gnome, mais celle ci ne présente pour l’instant que très peu d’intérêt.

2.2.5 Le catalogue

C’est la base de données du système de sauvegarde, elle contient les attributs et caractéristiques de vos fichiers et de vos différentes sauvegardes, elle est stockée dans une base de type MySQL, SQLLite ou postgresql qui peut être hebergée sur une machine tierce. (communication par le port 3106 avec le directeur).
SQLLite est implétmenté en natif dans le projet Bacula, c’est donc lui qui est proposé par défaut et qui est conseillé si aucun sgbd n’est installé sur la machine.

3. Définition d’un plan de sauvegarde

3.1. Les types de sauvegarde

Je vais faire ici un rappel des différents types de sauvegarde qui existent et que l’on retrouve dans Bacula.

3.1.1 Sauvegarde complète

Tous les fichiers selectionnés sont sauvegardés, qu’ils aient changé ou pas, et sont marqués comme tels dans le catalog.
Ce niveau de sauvegarde est de loin le plus gourmand en temps et en espace disque, mais il est evidemment nécessaire à tout plan de sauvegarde, c’est la base de la sauvegarde.

3.1.2 Sauvegarde differentielle

Seuls les fichiers ayant été crées ou modifiés depuis la dernière sauvegarde COMPLETE sont sauvegardés.
Ce niveau de sauvegarde permet de ne sauvegarder que les modifications et est donc plus rapide à executer et moins gourmand en terme de place.

3.1.3 Sauvegarde incrementielle

Tout comme la sauvegarde differentielle, la sauvegarde incrementielle ne concerne que les fichiers crées ou modifiés.
Ce qui différencie ces 2 niveaux de sauvegarde c’est qu’à l’instar de la sauvegarde differentielle qui se réfère à la derniere sauvegarde complete connue, la sauvegarde incrementielle se réfère à la dernière sauvegarde quelque soit son type, qu’elle soit complete, differentielle ou même incrementielle.
Le gros avantage est que l’on gagne encore en place et en temps de sauvegarde.

3.1.4 Différences pratiques entre sauvegardes differentielle et incrementielle

Nous l’avons vu precedemment, le sauvegarde incrementielle ne sauvegarde que ce qui a été modifié depuis la derniere sauvegarde, ce qui permet donc de sauvegarder moins.
Le principal risque est que si vous perdez un volume sur lequel est stockée une sauvegarde incrementielle à laquelle une autre sauvegarde incrementielle plus recente s’est référée, vous perdez l’historique des données.
Alors que dans le cas de 2 sauvegardes différentielles, vous n’auriez rien perdu puisque la seconde se serait référée non pas à la premiere mais directement à la sauvegarde complete originale.
Il y a dans ce cas redondance de l’information concernant les modification effectuées, mais aussi plus grande sécurité.

3.2. Exemples de stratégies

Une stratégie de sauvegarde est essentielle, elle permet de définir les données à sauvegarder, les eventuels historiques à conserver et elle permet surtout d’approximer l’espace nécessaire. Attention, prévoyez toujours très large! L’espace occupé par les données est toujours fortemment croissant!
De plus, il est toujours très difficile d’estimer la quantité de données crées ou modifiées chaque jour, il s’agira là d’approximations.
Afin d’éclaircir les choses, mettons en pratique les différents types de sauvegarde à travers des plans de sauvegarde concrets.

3.2.1 Cas concret n°1

Vous possédez 100Go de données critiques, accédées quotidiennement du lundi au samedi.
Ces données sont frequemment modifiées, à raison d’environ 1Go / jour et du fait de leur criticité vous souhaitez conserver un certain historique de ces modifications.

Exemple de plan de sauvegarde:
- sauvegarde complete mensuelle le premier dimanche du mois, convervée 2 mois.
- sauvegarde différentielle hebdomadaire le dimanche, conservée 5 semaines.
- sauvegarde incrementielle journaliere la nuit, conservée 14 jours.

Espace necessaire:

2 sauvegardes completes : 2*100Go = 200Go
—> On conserve la sauvegarde complete en cours et la précendente.
5 sauvegardes différentielles : 6+12+18+24+30 = 90Go
—> On conserve 5 semaines d’historique de sauvegarde différentielle hedbomadaire.

RAPPEL : cette sauvegarde se base sur la derniere sauvegarde complete, le volume de données augmente donc d’autant plus que la sauvegarde complète est ancienne.

12 sauvegardes incrementielles : 12*1Go = 12Go
—> On conserve 2 semaines soit 12 jours (le dimanche la sauvegarde differentielle a lieu) de sauvegarde incrementielle.

Total : 302Go nécessaires soit environ 3 fois la taille de vos données.

Ceci permet à n’importe quel moment d’avoir:
- un historique journalier des modifications pour les 14 derniers jours
- un historique hebdomadaire des modifications pour les 5 dernieres semaines
- deux historiques mensuels.

3.2.2 Cas concret n°2

Vous possédez 20Go de données critiques, ces données bougent peu (env. 100Mo modifiés/jour) et le suivi des modifications n’est pas essentiel pour vous.

Exemple de plan de sauvegarde:
- sauvegarde complete hebdomadaire, conservée 2 semaines.
- sauvegarde incrementielle journaliere, conservée 7 jours.

Espace necessaire:
2 sauvegarde complètes : 2*20Go = 40Go
6 sauvegardes incrementielles : 6*100Mo = 600Mo

Total : 40,6Go

4. Configuration de Bacula

4.1. Installation

4.1.1 Debian

Bacula est porté sur la distribution Debian, il est donc très facile à installer.

Pour installer la suite complète :
DebianBox:~#Apt-get install bacula

A noter qu’avec cette méthode c’est le paquet bacula-director-sqlite qui sera installé par défaut, libre à vous de choisir bacula-director-mysql ou bacula-director-pgsql.

Pour n’installer que la partie FD (FilerDaemon) sur un serveur “à sauvegarder”:
DebianBox:~#Apt-get install bacula-fd

Pour n’installer que la console d’administration, sur une machine qui servira à controler le directeur, les StorageDaemons ou FilerDaemons:
Pour la version texte :
DebianBox:~#Apt-get install bacula-console

Pour la version Gnome :
DebianBox:~#Apt-get install bacula-console-gnome

4.1.2 Rpm & “from source”

Bacula existe aussi en RPM, pour cela je vous conseille www.rpmfind.net afin de trouver le paquet le plus récent.
Si vous souhaitez compiler Bacula à partir des sources afin qu’il corresponde exactement à vos attentes en environnement de production, je vous invite à vous reporter au manuel officiel sur www.bacula.org, le nombre d’options étant assez conséquent.

4.2. Configuration des FD

Une fois Bacula installé sur vos différents serveurs, il faut configurer les Filer Daemons qui tourneront, je vous le rappelle, sur les machines contenant les données à sauvegarder.
Le fichier de configuration se nomme bacula-fd.conf et se trouve dans /etc/bacula sous debian.
Il est composé de 3 éléments :
- la définition des Directeurs autorisés à l’administrer
- la configuration du FD en lui-même
- la configuration de l’envoi des messages.

Pour autoriser un Directeur à se connecter à un FD, il faut donner le nom du directeur et lui associer un mot de passe:
Director {
Name = nom-du-serveur-executant-le-directeur
Password = “password”
}

Le champ FilerDaemon traite de la configuration en elle-même du FD
Il faut définir le nom qui sera utilisé pour l’identifier depuis la console d’administration et spécifier le port sur lequel il va écouter (9102 par défaut).

Le champ Messages gère les messages spontanemment envoyés au directeur par le FD, indiquez ici le nom du directeur qui doit recevoir ces messages.

Info : par défaut, debian configure ce fichier en mettant partout le nom de la machine sur lequel le paquet est installé, veuillez donc à rectifier si la machine n’est pas le directeur.

ATTENTION, ces fichiers de configuration sont à placer en local sur les machines executant les FD, c’est à dire les machines “à sauvegarder”.

Télécharger le fichier d’exemple de configuration du FD du serveur 1

Télécharger le fichier d’exemple de configuration du FD du serveur 2

4.3. Configuration du SD

Sur le même principe que le FD, le fichier de configuration du SD (bacula-sd.conf) possède un objet Storage dans lequel il faut définir un nom pour ce Storage Daemon et un port sur lequel il tournera, un objet Director dans lequel il faut indiquer le directeur autorisé à administrer ce SD et un objet Messages concernant les messages envoyés au directeur.

Il possède en plus des objets Device qui concernent dans notre cas le(s) volume(s) Disque sur lequel vous souhaitez stocker vos sauvegardes.
Il peut y avoir autant de Device que necessaire et idéalement un par serveur sauvegardé.

Télécharger le fichier d’exemple de configuration du Storage Daemon

4.4. Configuration du directeur

Le SD et le FD sont maintenant configurés, il nous reste le gros du travail : le Directeur qui est au centre du système.
Le fichier de configuration se nomme bacula-dir.conf

L’objet Director touche à la configuration du directeur lui-même, comme partout il faut le nommer et définir le password (necessaire pour contrôler ce directeur depuis la console).
A noter la propriété “Maximum Concurrent Jobs” qui définit le nombre de tâches que Bacula peut lancer simultanement.

L’objet FileSet définit l’ensemble des fichiers à sauvegarder, généralement pour un serveur donné. (les chemins d’accès aux données étant différent d’un serveur à l’autre).
Il convient donc d’en créer autant que necessaire, en incluant de préférence le nom du serveur concerné dans le nom de FileSet afin de savoir de quoi il retourne.
C’est à ce niveau que l’on définit la compression et/ou la signature des fichiers.
Bacula gère les algorythmes SHA1 et MDA pour la signature et GZIP(GZIP6) et GZIP9 pour la compression.
Je vous rappelle que cette compression a lieu en local sur le serveur de fichiers avant l’envoi des données par le réseau, elle impactera donc sur la charge de celui-ci.

L’objet Schedule définit un modèle de planification (voir exemple).

L’objet Client donne les informations concernant les différents FD au directeur (nom, adresse, mot de passe, port…)
On définit à ce niveau combien de temps les fichiers et les jobs sont conservé dans le Catalog.
Si l’option AutoPrune est définit à YES, ces infos sont effacées automatiquement du Catalog lorsque le laps de temps est ecoulé.

L’objet Storage donne les informations concernant les différents SD au directeur, et se réfère a un Device (précedemment définis dans le fichier bacula-sd.conf).
Dans notre cas, il faut mettre Media Type = File puisque l’on va sauvegarder sur un Disque Dur.

L’objet Catalog contient les paramètres de la base de donnée utilisée pour stocker les informations.

L’objet pool définit des ensembles de volumes(dans notre cas un volume sera un fichier) et permet par exemple de stocker toutes les sauvegardes de type “Full” ensembles etc.
A noter qu’un pool par défaut est necessaire.

Il reste maintenant l’objet Job qui definit une tâche de sauvegarde à proprement parler, il y en aura donc autant que nécéssaire.
Un job peut être de plusieurs types : Backup, Restore, Verify & Admin.
- Backup, comme son nom l’indique définira une tâche de sauvegarde.
- Verify permet de vérifier que les informations de sauvegardes stockées dans le Catalog correspondent bien à ce qui est stocké physiquement sur le support.
- Restore permet de récuperer des données sauvegardées.

ATTENTION, je vous conseille fortemment de définir vos jobs “restore” en même temps que vos jobs “Backup”, il n’est en effet pas possible de restaurer quelques données que ce soit sans qu’un job restore soit convenablement défini et il est rageant de perdre un temps précieux à définir ce type de job lorsque l’on a besoin de restaurer des données.

Je ne traiterais pas du type Admin dans cet article.

Pour un Job de type Backup, il vous faut spécifier les Client, FileSet, Schedule, Storage et Pool que nous avons précedemment déclarés.
L’option Write Boostrap permet de conserver le Bootstrap d’un disque dur sauvegardé avec Bacula, de façon a pouvoir remettre sur pied un système crashé le plus rapidement possible.
L’option Priority définit quel Job s’executera en premier lorsque plusieurs Jobs sont planifiés en même temps.

Télécharger le fichier d’exemple de configuration du Director

4.5. Prise en main de la console

Autant vous le dire tout de suite, la console d’administration n’est pas le point fort de Bacula. Elle existe en version Gnome mais n’offre selon moi aucun interet supplémentaire par rapport à la version texte.
Pour la lancer, placer vous dans /etc/bacula et executez bconsole.
Voici une liste non-exhaustive des commandes qui vous permetront de démarrer:
HELP : permet de lister toutes les commandes disponibles ainsi qu’une description sommaire.
RUN : permet de forcer le démarrage d’un job, à des fins de tests par exemple.
LIST (pools | jobs | jobtotals | media | files jobid=) : affiche le contenu du catalog.
STATUS : affiche l’état des jobs en cours. Cette commande se connecte directement au directeur, au SD ou au FD.

Télécharger le fichier d’exemple de configuration de la console

Conclusion

Cet article vous a présenté les principales fonctionnalités de Bacula dans son utilisation en tant que serveur de sauvegarde sur Disque dur.
J’espère que ce logiciel vous aura convaincu et je vous invite si c’est le cas à vous plonger dans le copieux mais complet manuel d’utilisation.
A noter que la sauvegarde mutualisée sur disque n’est qu’une infime partie des possibilités qu’offre Bacula, cet article n’a pas la prétention d’en faire une présentation exhausitive.

Infos et téléchargements : www.bacula.org

[filebase:file:file4]

SVK versionning

stratus — Mon, 05 Apr 2010 18:12:43 +0000

SVK

Article publié dans Linux Magazine 94, mai 2007.

Chapeau de l’article

Cet article est un tutoriel pour le logiciel de gestion de versions SVK, qui est parti du constat que, ayant besoin de SVK et ne le connaissant pas bien, le meilleur moyen de le maîtriser était d’approfondir mes connaissances et de les organiser dans un tutoriel à destination d’un public le plus large possible.

Introduction

Pour Wikipédia, la gestion de versions est « une activité qui consiste à maintenir l’ensemble des versions d’un logiciel ». Si vous êtes développeur, il y a de bonnes chances que vous ayez à gérer cette activité et que vous connaissiez déjà un outil de gestion de versions comme CVS, Subversion ou équivalent.

Écrit il y a plus de 20 ans, CVS est sans doute le grand-père le plus connu des outils de gestion de versions libre. Bien qu’encore très utilisé de par le monde, il a un certain nombre de faiblesses gênantes (impossible de déplacer des fichiers en conservant l’historique, pas d’atomicité des transactions, pas de dépôts décentralisés, etc.) que les nouveaux outils n’ont plus.

De nombreux remplaçants ont vu le jour. Certains sont généralistes (Bazaar, Subversion, SVK, Mercurial, etc.) tandis que d’autres sont développés spécifiquement pour un projet (Git pour le noyau linux).

Dans cet article, je parlerai de SVK qui est un client. Pourquoi celui-ci et pas un autre ? Plusieurs raisons à cela :

ça fait un certain temps que j’en entends parler dans la communauté Perl ;
il apporte des fonctionnalités déterminantes par rapport à ses concurrents (dépôts décentralisés, permet de réaliser des opérations même si l’on a pas accès au réseau, systèmes de branches et de fusions très évolués, etc.) ;
SVK est un client qui sait communiquer avec plusieurs serveurs de gestion de versions dont Subversion, logiciel de plus en plus répandu, mais aussi CVS et Perforce même si c’est avec des fonctionnalités plus réduites ;
et enfin parce que les Mongueurs de Perl viennent de migrer leur dépôt de CVS vers Subversion (cf point précédent) et que j’ai besoin d’y avoir accès.

SVK a été développé en 2003 par Chia-liang Kao pour ses besoins. Il s’est appuyé sur le système de fichiers de Subversion (svn) et a redéveloppé toute la couche haute. Les commandes utilisées sont néanmoins très proches de celle de Subversion et de CVS, les utilisateurs de ces produits ne seront donc pas totalement dépaysés. SVK a été acquis par Best Practical (le fameux éditeur de Request Tracker) en 2006 et Chia-liang Kao est devenu partenaire de Jesse Vincent chez Best Practical.

Installation

L’installation de SVK est d’une simplicité légendaire s’il est disponible sous forme de paquets :

  % sudo aptitude install svk       # Debian et dérivées
  % sudo urpmi svk                  # Mandriva

Sous Windows il existe un portage trouvable ici http://home.comcast.net/~klight/svk/

Si aucun paquet de SVK n’existe pour votre distribution, vous allez devoir passer par un shell d’installation Perl, CPAN ou CPANPLUS.

  % sudo cpan SVK       # avec CPAN.pm
  % cpanp i SVK         # avec CPANPLUS

Comme me le souffle un camarade, une installation « à la main » n’est pas des plus simples car il vous faudra installer ou compiler un Subversion avec les bindings Perl. Vous pourrez trouver de l’aide sur le wiki de SVK : http://svk.bestpractical.com/view/InstallingSVK.

Utilisation simple

Avant d’entrer dans le vif du sujet, nous allons aborder quelques notions utilisées par les logiciels de gestion de versions, et par SVK en particulier.

Le dépôt (repository en anglais) est un système de fichiers spécial dans lequel sont stockées toutes les données (fichiers et répertoires) ainsi que toutes les modifications apportées au fur et à mesure. Il est, au choix, local ou déporté sur une machine distante. On peut y accéder par différents protocoles et il peut être utilisé par plusieurs personnes en même temps. C’est la partie principale d’un outil de gestion de versions. Un même dépôt peut contenir autant de projets différents que vous le désirez.
La « copie de travail » est un vrai répertoire contenant des… fichiers et des répertoires se trouvant également dans le dépôt. C’est dans ce répertoire que vous travaillerez (seul) sur votre projet avant de publier vos modifications sur le dépôt pour les rendre accessibles à tout le monde (ou du moins à tous les gens qui ont accès au dépôt). Vous pouvez avoir autant de copies de travail que vous voulez.

Pour ne pas vous surcharger dès l’introduction de notions plus ou moins complexes sans avoir pratiqué, je reviendrai au fur et à mesure de cet article sur quelques autres notions importantes.

Création d’un dépôt local

La première étape est de créer un dépôt sur votre machine :

  % svk depotmap --init
  Repository /home/test/.svk/local does not exist, create? (y/n)y

Comme indiqué dans le retour de la commande, elle crée votre dépôt dans votre répertoire personnel dans le répertoire .svk/local.

Afin de promouvoir le plus tôt possible les bonnes pratiques, nous allons dès maintenant structurer le contenu de ce dépôt de façon à organiser judicieusement les travaux à venir. Nous verrons plus tard l’intérêt direct de l’organisation proposée.

  % svk mkdir //local/ -m 'creation du repertoire local'
  Committed revision 1.

Quand je parle de répertoire, il s’agit bel et bien de cela. Mais celui-ci n’est pas sur votre système de fichier, il se trouve dans le dépôt SVK, c’est pour cela qu’on les appelle « depot path » ou « chemin de dépôt ». Pour ne pas confondre les chemins du système de fichier avec ceux du dépôt SVK, le chemin de dépôt par défaut est préfixé de deux slashes (/). //local est donc votre premier chemin de dépôt.

Travailler sur un projet déjà dans un dépôt

La syntaxe normale pour récupérer les fichiers d’un dépôt centralisé est :

  % svk checkout protocole://le.serveur.net/le/chemin/mon/appli repertoire

Quand vous allez taper cette commande pour la première fois, svk va vous poser trois questions :

de quoi faire le miroir (en fait l’action checkout va conserver une copie locale du dépôt). Vous pouvez laisser la configuration par défaut.
quel chemin utiliser pour créer ce miroir. Je vous conseille de le mettre sous //mirror/nomduprojet/ nous verrons plus tard pourquoi.
si vous voulez récupérer toutes les versions ou seulement les plus récentes. La réponse par défaut convient dans tous les cas bien que pouvant être plus longue. C’est donc celle que je vous conseille.

Juste pour information, nous venons de voir notre second chemin de dépot à savoir //mirror/. Celui-ci est en fait un chemin spécial qui, par convention, sert à stocker tous les miroirs que l’on va faire avec SVK. Vous pourrez voir la liste de tous les miroirs que vous avez créés en faisant :

  % svk mirror --list
  Path                	Source
  ============================================================
  //mirror/mesprojets    	https://mon.serveur.com/svn
  //mirror/mongueurs
       svn+ssh://autre.serveur.com/home/nc/.svk/local/local/mongueurs/trunk

Voyons maintenant un exemple (pour redmine, voir dans les références à la fin de cet article) :

  % svk checkout svn://rubyforge.org/var/svn/redmine/
  New URI encountered: svn://rubyforge.org/var/svn/redmine/
  Choose a base URI to mirror from (press enter to use the full URI): 

  [...]

  Depot path: [//mirror/redmine] 

  [...]

  a)ll, h)ead, -count, revision? [a]
  Syncing svn://rubyforge.org/var/svn/redmine
  Retrieving log information from 1 to 21
  Committed revision 10297 from revision 1.
  [...]
  Syncing //mirror/redmine(/mirror/redmine) in /home/nc/tmp/redmine to
     10317.

Toutes les commandes de svk peuvent être raccourcies. En l’occurrence, le raccourci de checkout est co.

Si le dépôt utilise un serveur SVN, le protocole sera svn, si le serveur utilise WebDAV, le protocole sera http ou https :

  % svk checkout svn://rubyforge.org/var/svn/redmine/trunk redmine

  % svk checkout https://rubyforge.org/var/svn/redmine/trunk redmine

Ou encore si vous avez accès au dépôt par ssh :

  % svk checkout svn+ssh://rubyforge.org/var/svn/redmine/trunk redmine

Vous avez dû remarquer que j’ai utilisé le chemin /var/svn/redmine/trunk. Pourquoi trunk (tronc en français), pourquoi pas directement redmine ? Parce que trunk représente le développement principal et qu’il y a également des répertoires tags et branches permettant des « branches » de développements parallèles ainsi que la conservation de versions particulièrement intéressantes, mais n’avançons pas trop vite, nous verrons un peu plus loin pourquoi et comment nous en servir.

Créer un nouveau projet à partir de fichiers existants

Vous avez déjà un répertoire que vous souhaitez gérer avec SVK. La commande à utiliser est import :

  % svk import --message 'import initial' monprojet/ //local/monprojet

Avant de passer cette commande, je vous suggère fortement à la lumière de notre (très) rapide aperçu des branches, tags et trunk d’organiser un peu vos répertoires. Déplacez vos fichiers de travail dans trunk et créez les répertoires branches et tags afin d’obtenir dès maintenant une organisation comme celle-ci :

  monprojet/branches/
            tags/
            trunk/

Nous voyons maintenant à quoi nous sert d’avoir créé le répertoire //local. Cela permet de placer vos projets dans une arborescence dédiée et de ne pas tout avoir à la racine de votre dépôt.

Une fois l’import réalisé, vous allez pouvoir faire un checkout comme vu dans la partie précédente et commencer à travailler réellement. Pour ne récupérer que la version en cours de développement (soit trunk) et non toute l’arborescence, la commande à passer est :

  % svk checkout //local/monprojet/trunk monprojet

Vous auriez pu transformer directement le répertoire utilisé en version de travail en ajoutant l’option --to-checkout (ou -t) :

  % svk import --message 'import initial' -t monprojet/ //local/monprojet

Travailler sur votre projet

Ça y est, vous avez bien avancé sur votre nouvelle implémentation de logiciel de blog et vous voulez passer en revue vos modifications.

Plusieurs commandes vous seront utiles :

svk diff
Vous donne un diff entre la version d’origine du dépôt et votre copie de travail. Cette commande peut prendre en argument un ou plusieurs fichiers/répertoires, vous ne verrez alors que leurs différences.
svk add
Ajoute des fichiers ou des répertoires dans le dépôt

Les fichiers ne seront réellement ajoutés qu’au prochain commit (cf point suivant).
```
  % svk add rep
  A   rep
  A   rep/a
  A   rep/b
```
Cette commande est récursive, si vous ajoutez un répertoire, tous les fichiers contenus seront également ajoutés.

Vous pouvez ajouter tous les nouveaux répertoires et fichiers d’un seul coup en faisant :
```
  % svk add .
```
Un point intéressant à savoir, svk est (plus ou moins) intelligent, il n’ajoutera pas les fichiers de finissant par un « ~ » ainsi qu’un certain nombre d’autres motifs. La liste complète par défaut est : *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
svk commit
Permet d’enregistrer vos modifications dans le dépôt. Cette commande prend en option un commentaire, ce commentaire sert à décrire la ou les modifications apportées.
```
  % svk ci -m 'quelques modifications'
  Committed revision 3.
```
Je vous suggère (fortement) d’être le plus précis possible dans les messages que vous associez aux commits. Cela vous permettra d’avoir une trace fiable.

Définition : révision

Cela fait déjà quelques fois que nous rencontrons ce terme de « révision » dans les sorties écran de svk. À chaque fois que vous faites un commit (ou une opération faisant un commit sans vous le dire comme par exemple pull ou smerge que nous verrons plus tard), svk va créer dans le dépôt un nouvel état du système de fichier contenant toutes vos modifications, ces états sont appelés des révisions.
svk delete
Permet de supprimer un fichier dans le dépôt. Supprimer un fichier sur votre système de fichier n’avertit pas svk, cette commande lui précise que ce fichier n’existe plus. Dans le dépôt, svk ne supprime pas réellement le fichier, il garde bien sûr une trace de toutes les modifications qui y ont été apportées. Vous pourrez donc retrouver toutes ses versions si besoin est.
svk rename
Permet de renommer un fichier ou un répertoire. Si vous déplacez le fichier par les commandes liées à votre OS, svk ne pourra pas le savoir. Vous devez utiliser cette commande :
```
  % svk rename config/ etc/
```
Comme add et delete, cette commande ne prend effet réellement qu’après le prochain commit.

svk revert

Permet de « défaire » les éditions locales. Si vous avez modifié un fichier ou bien exécuté une commande add ou delete par exemple mais que vous n’avez pas encore commité, vous pouvez revenir à l’état d’avant ce add ou ce delete :

  % svk status
  # on crée un nouveau fichier
  % touch yyyyy
  # ce fichier est marqué comme inconnu par svk
  % svk status
  ?   yyyyy
  # on l'ajoute par svk, il le marque comme à ajouter
  % svk add yyyyy
  A   yyyyy
  # on le 'revert'
  % svk revert yyyyy
  Reverted yyyyy
  # il est à nouveau marqué comme inconnu
  % svk status
  ?   yyyyy

svk status
Vous permet de voir rapidement l’état de vos fichiers
```
  % svk status
  M   a.c
  !   a.h
  ?   b.c
  ?   b.h
```
Le M indique que le fichier a été modifié, le ! que le fichier n’existe plus dans les fichiers locaux et le ? que le fichier n’existe pas dans le dépôt. Pour une liste complète, référez vous au SVK Book.

Mettre à jour les fichiers locaux à partir du dépôt

Si vous êtes plusieurs à travailler sur votre projet, vous allez vouloir à un moment ou à un autre mettre à jour vos fichiers. Pour cela, utilisez la commande suivante depuis le répertoire de travail :

  % svk update

Le problème que vous voyez peut-être déjà c’est comment ça se passe si votre collègue/copain a modifié un fichier que vous avez modifié localement vous aussi. Voyons ça :

  % svk update
  Syncing //local/monprojet/trunk(/local/monprojet/trunk) in
  /home/test/monprojet to 6.
  Conflict found in a.c:
  e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e]

svk s’est rendu compte du problème et vous propose plusieurs choix. Dans l’immédiat nous n’allons utiliser qu’une des options (je vous laisse découvrir les autres), à savoir l’option "s". Cette dernière intègre les modifications apportées par les co-éditeurs du fichiers. À vous de rêgler le conflit :

Verrouillage ou conflit ?

Les logiciels de gestion de versions se séparent en deux catégories, ceux qui verrouillent (« lock ») les fichiers pour éviter les conflits et ceux qui autorisent les conflits et laissent les utilisateurs les gérer. Si la première catégorie semble plus sure, elle n’est pas forcément la plus efficace. À l’usage on se rend compte que les conflits ne sont ni si courants ni si graves et que cela apporte une souplesse non négligeable. Si néanmoins vous constatez que vous avez beaucoup de conflits, allez lire les conseils méthodologiques à la fin de cet article.

  % cat a.c
  >>>> YOUR VERSION a.c 115722413378427
  #include "d.h"
  ==== ORIGINAL VERSION a.c 115722413378427
  #include "b.h"
  ==== THEIR VERSION a.c 115722413378427
  #include "e.h"
  <<<< 115722413378427

Comme indiqué dans le texte, svk indique les différentes versions à l’origine du conflit à savoir, votre version actuelle, la dernière version commitée ainsi que la version du co-éditeur.

La résolution d’un conflit de ce type n’est pas tant un problème informatique que humain. Pour le résoudre vous aurez sans doute besoin de contacter la personne ayant fait la modification pour en parler avec elle avant de garder ou de modifier la version adéquate.

Après avoir résolu le conflit, vous devrez prévenir svk avec :

   % svk resolved a.c

Et ensuite vous pourrez commiter cette modification afin de ne pas laisser traîner le conflit :

  % svk commit a.c

Une chose à savoir, les commandes commit et update ne sont pas liées. Vous pouvez faire (et ferez souvent) l’une sans l’autre.

Regarder l’historique des modifications

Pour voir toutes les actions réalisées, vous pouvez faire svk log.

Cette commande ne fait que vous afficher les commentaires que vous mettez quand vous commitez, c’est donc dans votre intérêt d’être le plus précis possible.

Par défaut svk log ne vous montre que l’historique que depuis la dernière copie effectuée. Si vous travaillez sur un miroir, vous devrez utiliser l’option --cross qui permet de voir également les modifications recopiées depuis un autre dépôt. L’option --verbose permet d’avoir une sortie un peu plus complète (fichiers concernés entre autre).

Pour regarder plus précisément un fichier, la commande svk annotate peut vous aider, elle permet de voir quelles lignes viennent de quelle version.

svk cat permet de voir l’état d’un fichier dans le dépôt. Nous verrons un peu plus loin un argument idéal à utiliser avec cette commande.

Quelques autres commandes

Voici quelques autres commandes qui pourront vous être utiles au cours de votre utilisation de svk :

Si vous voulez exporter un projet sans le conserver dans la gestion de versions, vous pouvez utilisez l’option --export :
```
  % svk checkout --export //local/redmine/trunk redmine
```
Si vous voulez voir ce qu’il y a dans votre dépôt vous pouvez utiliser la commande list avec le chemin de dépôt qui vous intéresse :
```
  % svk list //mirror
  articles/
  monprojet/
  mongueurs/
  redmine/
  tracks/
```
Cette commande accepte plusieurs options dont une peut vous intéresser tout de suite : svk list -R // liste récursivement tous les répertoires. Très pratique pour avoir une visualisation en arbre de votre arborescence de dépôt.
Si vous avez besoin de créer un nouveau répertoire dans votre copie de travail, vous pouvez utiliser directement la commande svk mkdir, le répertoire sera ajouté au prochain commit. Et comme nous l’avons vu au début de cet article, elle permet également de créer un nouveau répertoire de dépôt (pour organiser un peu votre dépôt par exemple) :
```
  % svk mkdir monrepertoire
  % svk mkdir //local/quelquechose
```

Parfois vous voudrez savoir d’où vient telle copie de travail ou tel répertoire de votre dépôt. svk info vous donnera toutes les informations utiles :

  % svk info
  Checkout Path: /home/nc/travail/rails/redmine
  Depot Path: //local/redmine/trunk/redmine
  Revision: 10389
  Last Changed Rev.: 10389
  Copied From: /mirror/redmine/trunk/redmine, Rev. 10375
  Merged From: /mirror/redmine/trunk/redmine, Rev. 10388

  % svk info //mirror/redmine
  Depot Path: //mirror/redmine
  Revision: 10410
  Last Changed Rev.: 10388
  Mirrored From: svn://rubyforge.org/var/svn/redmine, Rev. 22

Quelques options bien utiles

Un certain nombre de commandes acceptent des arguments. Vous trouverez la liste complète dans le SVK Book mais je vais rapidement donner ici celles qui peuvent vous être utile tout de suite :

Les commandes diff, log, update et cat acceptent un argument -r pour indiquer une révision. Cet argument est soit le numéro de révision, soit une date. Par exemple, pour avoir les modifications faites entre le 9 juillet et le 10 juillet il suffit de faire :

  % svk diff -r {2006-07-09}:{2006-07-10}
  === redmine/app/helpers/search_filter_helper.rb
  ==================================================================
  --- redmine/app/helpers/search_filter_helper.rb (revision 10337)
  +++ redmine/app/helpers/search_filter_helper.rb (revision 10340)
  @@ -29,10 +29,12 @@
     end

Pour préciser que vous voulez comparer par rapport à la dernière version utilisez HEAD :

  % svk diff -r {2006-07-09}:HEAD

Et comme promis antérieurement, cette option est très pratique avec svk cat pour voir l’état d’un fichier dans telle révision ou à telle date :

  % svk cat -r {2006-07-09} redmine/app/helpers/search_filter_helper.rb

checkout et update acceptent également un argument -r qui permet de préciser à partir de quelle révision on veut se mettre à jour.

Nous avons déjà vu la commande checkout. Elle dispose d’une option bien pratique au bout de quelque temps pour retrouver ses petits, il s’agit de --list qui affiche la liste des répertoires de travail :

  % svk checkout --list
    Depot Path                            Path
  ========================================================================
    //local/mesprojets/bbrails/trunk         /home/nc/travail/rails/bbrails
    //local/mesprojets/fpw2006               /home/nc/travail/rails/fpw2006
    //local/mesprojets/gestapp/trunk         /home/nc/travail/rails/gestapp
    //local/mongueurs/trunk               /home/nc/travail/mongueurs
    //local/redmine/trunk/redmine         /home/nc/travail/rails/redmine
  ? //local/mesprojets/test                  /home/nc/tmp/prosper

Le ? indique que le répertoire de travail n’existe plus. Vous pouvez alors supprimer cette référence en faisant :

  % svk checkout --purge
  Purge checkout of //local/mesprojets/test to non-existing directory
  /home/nc/tmp/prosper?
  (y/n) y
  Checkout path '/home/nc/tmp/prosper' detached.

Ça y est vous maîtrisez les commandes de base et vous pouvez utiliser SVK au quotidien mais il serait dommage de s’arrêter là alors qu’il y a tant à faire. Ceci nous amène naturellement sur le chapitre suivant ‘utilisation avancée

Utilisation avancée

Les branches et les tags

Cette partie demande quelques explications. Imaginons que vous écriviez un nouveau logiciel allant révolutionner le monde (un logiciel de blog par exemple). Vous venez de sortir la version 1.0 et vous voudriez bien pouvoir développer la future version 2.0, tout en continuant à corriger les bugs de la version 1.0. Pour utiliser le jargon, vous aimeriez bien avoir plusieurs branches de développement, une branche stable et une branche instable. Une solution simple existe dans la plupart des logiciels de gestion de versions, la notion de tag et de branches.

Les mises en œuvre de ces mécanismes différent d’un logiciel à l’autre mais pour SVK, cela se traduit tout simplement par trois répertoires créés dans le dépôt (et non au niveau du système de fichier) :

  branches/ - les différentes versions de développement
  tags/     - des images figées
  trunk/    - la dernière version en cours de développement

Dans SVK nous verrons que branches et tags sont gérés de la même façon, ils ne différent que par l’utilisation que l’on en fait : les branches sont utilisées pour développer les différentes versions en parallèle, tandis que les tags servent à conserver des versions spécifiques sur lesquelles vous ne travaillez pas. On ne commite pas dans les tags.

Création de branches et de tags

La commande utilisée pour créer des tags et des branches est la même, il s’agit de svk copy :

  % svk copy //local/monprojet/trunk \
    //local/monprojet/branches/monprojet-1.0 \
    -m 'creation de la branches 1.0'
  Committed revision 5.

Comme tout le monde s’en doutait, cela va créer un nouveau répertoire de dépôt dans branches contenant tous les fichiers dans l’état actuel de trunk :

  % svk list //local/monprojet/branches/
  monprojet-1.0/

Vous allez pouvoir faire un checkout de cette version 1.0 et travailler dessus tout en continuant à développer la version future dans trunk.

Une fois votre version 1.0 prête à être diffusée, vous voudriez bien garder une trace exacte de cette version. Bien sûr, vous pourriez utiliser l’option -r, que nous avons vue à la fin du chapitre précédent, avec le numéro de révision ou bien la date mais ça n’est pas très intuitif. Une meilleure façon est de tagger cette version :

  % svk copy //local/monprojet/branches/monprojet-1.0 \
     //local/monprojet/tags/monprojet-1.0 -m 'version 1.0 diffusée'
  Committed revision 7.

Un utilisateur vous soumet un bug ? Vous corrigez le bug dans la branche version-1.0 et quand vous diffusez une version 1.0.1 vous n’avez qu’à la copier dans tags sous le nom monprojet-1.0.1 pour en garder une trace.

Même si SVK s’arrêtait là la notion de tags et de branches serait un outil fantastique mais heureusement, SVK va beaucoup plus loin…

Passer votre copie de travail d’une branche à une autre

Si votre copie de travail est un checkout d’une branche et que vous voulez passer dans une autre, placez-vous dans le répertoire de la copie de travail et utilisez la commande svk switch :

  % svk switch //local/monprojet/branches/monprojet-1.0/

Pour repasser dans trunk il suffit de faire :

  % svk switch //local/monprojet/trunk/

La fusion

Vous avez vos deux versions, celle de trunk et celle de version-1.0. Vous corrigez plusieurs bugs dans version-1.0 et vous aimeriez bien les corriger aussi dans trunk. Plutôt que de reporter vos corrections à la main dans trunk, vous pouvez utilisez la fonction smerge :

  % svk smerge -Il //local/monprojet/branches/monprojet-1.0 \
    //local/monprojet/trunk
  Auto-merging (0,  /local/monprojet/branches/monprojet-1.0 to
     /local/monprojet/trunk (base /local/monprojet/trunk:4).
  ===> Auto-merging (0, 5) /local/monprojet/branches/monprojet-1.0 to
     /local/monprojet/trunk (base /local/monprojet/trunk:4).
  Empty merge.
  ===> Auto-merging (5,  /local/monprojet/branches/monprojet-1.0 to
     /local/monprojet/trunk (base /local/monprojet/trunk:4).
  U   db/migrate/001_setup.rb
  New merge ticket:
  0aca4fd4-bb1c-0410-adf5-ecdeea5a58f8:
     /local/monprojet/branches/monprojet-1.0:8
  Committed revision 9.

Cette commande va reporter toutes les modifications que vous avez faites dans version-1.0 dans le trunk. Évidemment, si vous avez déjà modifié le trunk dans un endroit où vous avez également corrigé un bug vous risquez d’avoir un conflit, charge à vous de le résoudre.

Attention, contrairement à la résolution de conflit que nous avons vue précédemment, vous ne pourrez pas faire skip pour résoudre votre problème plus tard. Vous devrez le résoudre tout de suite grâce aux options diff (pour voir le conflit) et edit (pour le modifier). Si vous faites skip, cette partie ne sera pas fusionnée, néanmoins vous pourrez la refusionner plus tard. Suite à votre édition, svk vous demandera si vous voulez accepter la modification :

  % svk smerge -Il //local/monprojet/branches/monprojet-1.0 \
       //local/monprojet/trunk
  Auto-merging (8, 11) /local/monprojet/branches/monprojet-1.0 to
   /local/monprojet/trunk (base /local/monprojet/branches/monprojet-1.0:8).
  ===> Auto-merging (8, 11) /local/monprojet/branches/monprojet-1.0 to
   /local/monprojet/trunk (base /local/monprojet/branches/monprojet-1.0:8).
  Conflict found in config/config_custom.rb:
  e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] e
  Waiting for editor...
  Merged config/config_custom.rb:
  a)ccept, e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [a] a
  G   config/config_custom.rb
  New merge ticket: 0aca4fd4-bb1c-0410-adf5-ecdeea5a58f8:
   /local/monprojet/branches/monprojet-1.0:11
  Committed revision 12.

Une bonne méthode de travail consiste à regarder avant de faire le svk smerge si vous allez avoir des conflits en faisant utilisant l’option -C : svk smerge -C.

Quelques jours après cette fusion corrigeant des bugs, vos utilisateurs vous soumettent à nouveau plusieurs bugs bloquants. Vous les corrigez et vous aimeriez bien pouvoir faire la même manipulation pour les corriger dans trunk. Et bien j’ai une bonne nouvelle, vous pouvez la recommencer autant de fois que vous le voulez. Contrairement à certains autres logiciels (dont SVN et CVS entre autres) pour lesquels les fusions à répétitions entre branches sont non triviales (il faut préciser à la fonction merge la dernière révision pour laquelle on a déjà fait une fusion), SVK implémente dans smerge une fonction de fusion sophistiquée, appelée star-merge, qui permet de fusionner successivement les mêmes branches sans se poser de question.

Vous pouvez utiliser svk smerge entre deux dépôts comme nous venons de le voir mais aussi entre un dépôt et une copie de travail en spécifiant le chemin de votre copie de travail en seconde position comme ceci :

  % svk smerge -Il //local/monprojet/branches/monprojet-1.0 \
    /ma/copie/de/travail

Fusionner seulement quelques révisions

Aussi parfois appelé « cherry picking » (cueillette de cerise).

Imaginons maintenant le cas inverse, vous développez dans trunk et trouvez des bugs. Après correction vous aimeriez bien les reporter dans votre branche monprojet-1.0. Seul problème, vous avez aussi fait des modifications substantielles dans d’autres parties de trunk que vous ne voulez pas voir apparaître dans la branche.

smerge ne sait pas faire ça, il va falloir se rabattre sur la commande merge.

Avant toute chose on va chercher les révisions que l’on veut fusionner dans notre branche, la commande log va nous trouver ça :

  % svk log
  ----------------------------------------------------------------------
  r16:  test | 2006-09-06 15:23:04 +0200

  ajout d'une fonctionnalite pour la v2.0
  ----------------------------------------------------------------------
  r15:  test | 2006-09-06 15:22:32 +0200

  correction bug bloquant
  ----------------------------------------------------------------------
  r14:  test | 2006-09-06 15:22:14 +0200

  ajout d'une fonctionnalite pour la v2.0

Le bug a été corrigé dans la révision 15, nous pouvons vérifier la correction de bug en faisant un diff :

  % svk diff -r 14:15 //local/monlogiciel/trunk/
  === generate
  ==================================================================
  --- generate    (revision 14)
  +++ generate    (revision 15)
  @@ -1,4 +1,4 @@
   #!/usr/bin/env ruby
   # commentaire
  -requir File.dirname(__FILE__) + '/../config/boot'
  +require File.dirname(__FILE__) + '/../config/boot'
   require 'commands/generate'

C’est bien cette correction de bug que nous voulons fusionner. Nous pouvons donc appliquer le patch. Nous pouvons l’appliquer soit directement sur le dépôt (comme vu avec smerge), soit en se plaçant directement dans un répertoire de travail contenant notre branche et en faisant :

  % svk merge  -r 14:15 //local/monlogiciel/trunk/
  U   generate

Il vous faudra alors commiter ces modifications.

L’avantage de faire la fusion directement sur le dépôt est que vous n’aurez pas à faire le commit ensuite.

Cette partie suppose que vos commits forment un tout homogène. Un commit pour les corrections de bug, un commit pour l’ajout de tel fonctionnalité, etc.

Gérer des modifications locales dans un logiciel

Nous allons étudier un cas relativement classique : vous utilisez un logiciel que vous avez adapté à votre environnement. À chaque nouvelle version vous devez réintégrer vos modifications à la main ce qui est long, fastidieux et contrevient clairement à une des vertus cardinales de l’informaticien, la paresse. SVK peut vous aider.

Créez une arborescence standard branches/tags/trunk
```
  mkdir -p monlogiciel/{branches,tags,trunk}
```
Récupérez une archive de votre logiciel et décompactez-la directement dans trunk.

faites un import de toute l’arborescence

  % svk import -m "premier import de monlogiciel" monlogiciel \
     //local/monlogiciel

faites une copie de trunk vers une branche sur laquelle vous ferez vos modifications :

  % svk copy -m "creation de la copie locale" //local/monlogiciel/trunk \
     //local/monlogiciel/branches/monlogiciel-local

Faites un checkout de cette branche et faites toutes les modifications désirées dans cette branche et commitez-les.
Une nouvelle version de monlogiciel est sortie, récupérez-la à nouveau et décompactez-la.
```
  % svk import -m "import de monlogiciel v1.2" monlogiciel \
    //local/monlogiciel/trunk
```

Essayez de fusionner le nouveau trunk avec votre version locale :

  % svk smerge -C //local/monlogiciel/trunk \
    //local/monlogiciel/branches/monlogiciel-local
  Auto-merging (2, 5) /local/monlogiciel/trunk to
    /local/monlogiciel/branches/monlogiciel-local
    (base /local/monlogiciel/trunk:2).
  U   console
  New merge ticket: 6d4c1533-f1fa-4670-b606-7b3ba989afbe:
    /local/monlogiciel/trunk:5

Seul le fichier console a été modifié et SVK ne détecte aucun conflit. Vous pouvez donc faire le smerge en toute confiance :

  % svk smerge -Il //local/monlogiciel/trunk \
     //local/monlogiciel/branches/monlogiciel-local
  Auto-merging (2, 5) /local/monlogiciel/trunk to
     /local/monlogiciel/branches/monlogiciel-local (base
     /local/monlogiciel/trunk:2).
  ===> Auto-merging (2, 5) /local/monlogiciel/trunk to
     /local/monlogiciel/branches/monlogiciel-local (base
     /local/monlogiciel/trunk:2).
  U   console
  New merge ticket: 6d4c1533-f1fa-4670-b606-7b3ba989afbe:
     /local/monlogiciel/trunk:5
  Committed revision 6.

Recommencez la procédure ci-dessus ad-nauseam à chaque nouvelle version de votre logiciel.

Évidemment, si la nouvelle version est une réécriture complète cela risque de ne pas marcher aussi bien que voulu mais si c’est une version de bugfix le travail sera nettement moins fastidieux qu’à la main.

Travailler en mode déconnecté

Un des gros problèmes rencontrés quand vous utilisez un dépôt sur Internet est comment travailler quand vous n’avez pas accès à Internet pendant quelque temps. Vous pouvez revenir aux (pas si) bonnes vieilles méthodes, à savoir copier vos fichiers modifiés avec une extension précisant la date de modification ou la modification, et vous retrouvez rapidement avec des répertoires comme celui-ci :

  projet/a.c
        /a.c-version_de_debuggage
        /a.c-1
        /a.c-2
        /a.c-bug_machin
        /...

Cela devient vite horrible et inutilisable (bien que des gens utilisent encore cette méthode).

SVK propose une solution simple et esthétique, un dépôt déconnecté. Pour faire cela il faut utiliser la notion de miroir.

  % svk mirror https://rubyforge.org/var/svn/redmine/ //mirror/redmine
  % svk sync //mirror/redmine

La première commande va créer le miroir, la seconde va importer toutes les données du dépôt distant dans votre miroir. Quand vous faites un checkout directement depuis un serveur Subversion, c’est en fait ce que svk fait dans votre dos (rappelez-vous les questions qu’il vous a posées au début de ce tutoriel).

Une fois cette étape réalisée, vous allez faire une copie locale des données récupérées :

  % svk copy //mirror/redmine //local/redmine

À partir de ce moment, vous pouvez faire un checkout de votre projet et commencer à travailler dessus hors-ligne en commitant régulièrement vos modifications.

Oui, mais si c’est en mode hors-ligne, comment répliquer vos modifications sur le dépôt central et récupérer les dernières modifications du dépôt central ? En utilisant les commandes svk push et svk pull.

Vous revenez de deux semaines sans accès à Internet, vous avez commité de nombreuses modifications et vous voudriez bien que vos petits collègues en profitent. Commencez par récupérer leurs modifications :

  % svk pull

Cette commande va d’abord mettre à jour votre miroir et ensuite faire un update de votre répertoire de travail. Vous aurez peut-être des conflits à résoudre. Une fois ces conflits résolus et commités, vous pouvez leur envoyer vos modifications :

  % svk push

Ces commandes sont en fait des habillages un peu plus sexy d’autres commandes, mais ne vous préoccupez pas trop de ça si vous n’en avez pas besoin. Et si vous en avez besoin, lisez le SVK Book.

Vous pouvez voir les modifications en attente d’être poussées en utilisant la commande diff comme ceci :

  % svk diff //mirror/monprojet/ //local/monprojet/

Proposer des modifications quand vous n’avez pas les droits d’écriture sur le dépôt

Il n’est pas rare de proposer des patchs sur des projets pour lesquels vous n’avez pas les droits d’écriture sur le dépôt. Vous pouvez bien sûr utiliser la commande diff présente sur votre système ou bien la commande diff de SVK mais ce dernier vous permet de faire mieux avec l’option --patch utilisable avec commit, push et smerge.

Pour l’utiliser, commitez vos modifications normalement dans votre dépôt local et ensuite utilisez push avec l’option --patch :

  % svk push --patch svk_correction_bug
  Auto-merging (10574, 10606) /local/mongueurs/trunk to
     /mirror/mongueurs/trunk (base /mirror/mongueurs/trunk:10604).
  Patching locally against mirror source svn://svn.mongueurs.net/articles.
  U   magazines/Applications/svk.pod
  Patch svk_correction_bug created.

Le patch est déposé dans ~/.svk/patch.

Vous pouvez lister vos patchs en faisant :

  % svk patch --list
  svk.pod@1:
  svk_correction_bug@1:

Quand votre correspondant recevra le fichier de patch il n’aura qu’a le déposer dans son fichier ~/.svk/patch et le rejouer en faisant :

  % svk patch apply svk_correction_bug

Répliquer un dépôt local sur un dépôt distant

Ça y est, votre logiciel est prêt à affronter la critique de vos contemporains et vous voudriez leur donner accès aux sources. Vous avez juste deux problèmes : votre dépôt est sur votre disque et vous ne voulez pas donner accès à tous vos projets. La solution, répliquer votre projet sur un autre serveur SVN, par exemple sur une forge sur internet.

Pour cette recette, vous avez normalement besoin d’un serveur svn extérieur mais nous allons contourner le problème en créant un autre dépot local.

D’abord, un petit mot sur les dépôts. Au début de cet article nous en avons créé un en faisant svk depotmap --init. Cette commande créé un dépôt par défaut que l’on peut ensuite utilisé en utilisant //. Même si cette possibilité est rarement utile et n’est pas forcément recommandée, SVK peut gérer plusieurs dépôts.

Créons donc ce second dépôt nommé « remote » dans le répertoire /tmp/remote (chemin pas forcément judicieux si vous comptez faire plus qu’un test…)

  % svk depotmap remote /tmp/remote
  New depot map saved.
  Repository /tmp/remote does not exist, create? (y/n)y

Le dépôt est créé. On peut voir la liste des dépôts gérés par SVK en faisant :

  % svk depotmap --list
  Depot                   Path
  ============================================================
  //                      /home/nc/.svk/local
  /remote/                /tmp/remote

Ce nouveau dépôt est accessible en préfixant les chemins par /remote/ à la place de // mais nous allons l’utiliser comme si c’était un dépôt distant et commencer par créer un miroir dans le dépôt par défaut :

  % svk list file:///tmp/remote

svk va vous poser des questions pour créer un miroir local dans le dépôt par défaut //. Répondez par défaut, cela va créer un nouveau chemin de dépôt //mirror/remote.

Synchronisez vos deux dépôts :

  % svk sync //mirror/remote

Créez le répertoire monprojet qui va accueillir votre projet sur le miroir :

  % svk mkdir //mirror/remote/monprojet/ \
        -m 'creation du repertoire de monprojet'

Faites un smerge de votre dépôt local vers votre dépôt :

  % svk smerge --baseless --incremental //local/monprojet \
       //mirror/remote/monprojet

L’option baseless indique que svk doit faire le smerge même si les deux projets n’ont pas de racine commune et incremental que chaque changement doit être appliqué individuellement.

Ça y est le miroir est fait. Vous aurez juste à penser à mettre à jour votre dépôt externe en lançant de temps en temps la commande :

  % svk smerge --incremental -m "mise a jour" //local/monprojet/ \
     //mirror/remote/monprojet/

Malheureusement vous ne pourrez pas utiliser la commande svk push pour mettre à jour cette copie. À ce niveau, plusieurs solutions s’offre à vous :

soit vous faites le smerge vu ci-dessus à la main de temps en temps.
soit vous voulez vraiment utiliser les commandes push et pull. Vous devez alors utiliser ce nouveau dépôt comme dépot « racine » et créer une nouvelle copie dans //local comme vu dans la section « travailler en mode déconnecté ». Vous pourrez alors supprimer l’ancienne copie locale (pensez à commiter toutes vos modifications avant de commencer cette manipulation) :
```
  % svk copy -m "creation" //mirror/remote/monprojet/ \
    //local/monprojet-nouveau
```
(Attention, avec la version 2 de SVK que j’utilise, je ne peux pas réutiliser le même chemin de dépôt dans //local, d’où le « -nouveau ».)

Voila, vous pouvez maintenant faire un checkout de //local/monprojet-nouveau et travailler dessus :
```
  % svk checkout //local/monprojet-nouveau
  % cd monprojet-nouveau
  % svk push
  Auto-merging (0, 13238) /local/monprojet-nouveau to
      /mirror/remote/monprojet (base /mirror/remote/monprojet:13223).
  ===> Auto-merging (0, 13238) /local/monprojet-nouveau to
      /mirror/remote/monprojet (base /mirror/remote/monprojet:13223).
  Merging back to mirror source file:///tmp/remote.
  Empty merge.
```
soit, dernière solution, vous utilisez une nouvelle notion pour vous, les hooks, pour mettre à jour automatiquement le miroir.

Les hooks sont des programmes déclenchés par SVK sur certains évènements précis. Vous pouvez les trouver dans ~/.svk/local/hooks qui par défaut ne contient que des modèles :
```
  % ls ~/.svk/local/hooks
  post-commit.tmpl  post-revprop-change.tmpl  pre-commit.tmpl
  pre-revprop-change.tmpl start-commit.tmpl
```
Voici le hook utilisé dans le cas présent :
```
  % cat ~/.svk/local/hooks/post-commit
  #!/bin/sh

  svk smerge --incremental //local/monprojet //mirror/remote/monprojet
```
Pensez à le rendre exécutable :
```
  % chmod +x ~/.svk/local/hooks/post-commit
```
Et voilà, celui-ci va lancer la commande smerge pour mettre à jour votre miroir à chaque commit que vous ferez y compris ceux ne concernant pas monprojet. Nous pourrions sans doute affiner cela mais je vous laisse regarder ça vous même.

L’inconvénient de cette dernière solution est que, si certaines personnes écrivent dans le nouveau dépôt, vous devrez penser à synchroniser les deux dépôts avec svk sync //mirror/remote pour récupérer leurs modifications. Néanmoins, dans le cadre d’un dépôt en lecture seule cela ne pose pas vraiment de problème…

Métadonnées ou propriétés

Les métadonnées sont des données servant à décrire ou à ajouter de l’information à d’autres données. Dans un système de fichiers, les droits du fichier sont un exemple de métadonnées, ils ne font pas partie du fichier mais servent à ajouter une information à ce fichier.

SVK (ainsi que Subversion) appelle ces métadonnées des « propriétés ». Ces propriétés sont manipulables avec les commandes proplist, propget, propset, propedit et propdel qui respectivement, liste toutes les propriétés et retourne, modifie, lance un éditeur pour modifier et enfin supprime une propriété. Voyons un exemple :

  % svk proplist README
  % svk propset copyright 'NBC 2007' script/server
   M  script/server
  % svk propset copyright 'NBC 2007' README
   M  README
  % svk proplist README
  Properties on README:
    copyright
  % svk propget copyright README
  NBC 2007
  % svk propdel copyright README
   M  README
  % svk proplist README

Les propriétés sont représentées par un nom et une valeur. Ces propriétés sont versionnées exactement comme le fichier. Vous pouvez faire dessus des commit, des revert et toutes les opérations classiques. Elles seront également accessible à toutes les personnes utilisant SVK ou Subversion pour travailler sur votre projet.

Si vous faites un svk diff sur un fichier auquel vous avez ajouté une propriété, vous verrez quelque chose comme :

  % svk diff README 

  Property changes on: README
  ___________________________________________________________________
  Name: copyright
   +NBC 2007

Voici un certain nombre de propriétés utiles :

svn:executable
permet de rendre un fichier exécutable
```
  % svk propset svn:executable 1 script/*
```
rendra tous les fichiers du répertoire script exécutables suite à une commande checkout ou update.
svn:eol-style
permet de traiter le « problème » des fins de ligne qui sont différentes suivant les systèmes d’exploitation. En utilisant la valeur « native », SVK utilisera automatiquement la fin de ligne normale du système sur lequel vous travaillez au moment de créer un fichier et non celle utilisée par le créateur du fichier :
```
  % svk propset svn:eol-style native **/*.rb
```
Vous pouvez aussi forcer un type de fin de ligne en utilisant les valeurs CRLF, CR ou LF.
svn:ignore
permet d’ignorer certains répertoires et fichiers qui n’ont pas à être journalisés :
```
  % svk propset svn:ignore "*" tmp/
```
ignorera tous les fichiers créés dans tmp/

Vous pourrez trouver une liste plus complète des propriétés dans la documentation de Subversion http://svnbook.red-bean.com/. Attention, toutes les propriétés existantes dans Subversion ne sont pas forcément implémentées dans SVK.

Configuration de SVK

Comme nous l’avons déjà vu, SVK s’appuie sur Subversion pour la partie système de fichiers et pour la gestion des propriétés. Il s’appuie également dessus pour la partie configuration. Le fichier utilisé pour le configurer est ~/.subversion/config. Par défaut il est entièrement commenté.

Nous avons vu un peu plus haut (dans la section parlant de la commande add) que SVK ignorait certains fichiers. Cette liste est évidemment paramétrable. Pour cela, ajoutez dans le fichier de configuration :

  [miscellany]
  global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

Une deuxième configuration potentiellement intéressante est de fixer automatiquement les propriétés des fichiers suivants leur extension :

  [miscellany]
  enable-auto-props = yes
  [auto-props]
  *.rb = svn:eol-style=native
  *.pl = svn:eol-style=native
  *.png = svn:mime-type=image/png
  ...

À ma connaissance, ce sont les deux seules configurations possibles dans SVK. Ceci dit, l’information étant difficile à trouver en dehors du code source, j’ai pu en louper certaines.

Éléments de méthode de travail

Cette partie n’essaye pas de proposer une méthode de travail générique, elle donne juste quelques pistes pour travailler le mieux possible avec SVK. Elle s’applique sans doute à beaucoup d’autres outils de gestion de versions.

évitez de travailler directement sur un dépôt miroir, préférez une copie locale.
faites des update régulièrement et entre autre avant chaque commit, cela réduit les risques de conflit si vous travaillez à plusieurs.
un commit doit porter sur un changement unitaire (ne mélangez pas corrections de bugs et ajout de nouvelles fonctionnalités), doit être accompagné d’un message explicite des modifications apportées et doit laisser le logiciel dans un état stable (lancez vos tests unitaires avant de commiter).
Ne versionnez que les fichiers utiles au projet, i.e. ne versionnez pas les journaux, les fichiers intermédiaires, etc. Pour cela, vous pouvez bien sur utiliser la propriété svn:ignore vu dans la section sur les propriétés au niveau de chaque projet ou bien le global-ignores vu dans la section sur configuration au niveau global.
SVK ne remplace pas la communication inter-humain.

Voici un diagramme récapitulant les flux des commandes importantes de SVK :

SVK version 2

Pour écrire cet article je me suis appuyé sur la version 1 mais le développement est très actif et la version 2 est sortie le 28 décembre 2006. Elle apporte, en plus des corrections de bogues, plusieurs fonctionnalités dont certaines sont vraiment très intéressantes comme :

les commits interactifs
Sans doute la plus intéressante à première vue, la commande (svk commit --interactive) vous montre les différentes modifications effectuées et vous permet de sélectionner celles que vous voulez effectivement commiter, les autres restant à l’état de modifications dans votre copie de travail ;
l’amélioration de la sortie des journaux
Vous pouvez maintenant y appliquer des filtres (recherche par exemple) et modifier la sortie (standard, XML, …) ;
l’apparition des vues
Les vues peuvent être vues comme les vues des bases de données ou comme des liens symboliques unix. Elles permettent de référencer une arborescence sous un autre nom (plus parlant).

Une liste complète des modifications de la version 2 est disponible sur le CPAN : http://search.cpan.org/src/CLKAO/SVK-v2.0.0/CHANGES

Seul inconvénient, mais de taille à mon avis, cette version n’est, sauf erreur, pas encore disponible en paquetage (sauf peut-être pour Mac OS X), vous devrez donc l’installer à la main. À moins d’en avoir besoin et de savoir ce que vous faites, je vous conseille de rester à la version installée par votre système de gestion de paquetages et d’attendre qu’elle soit disponible dans votre système d’exploitation ou distribution préféré. Ceci étant dit, cette nouvelle version fonctionne très bien pour moi depuis quelque temps déjà.

Quelques idées en l’air

Si les outils de gestion de versions sont généralement utilisés pour gérer les sources d’un programme, il serait dommage de les limiter à cela. Ils peuvent être détournés pour faire plein de choses intéressantes et SVK a certains atouts non négligeables à détourner :

Plutôt Plutôt que de sauvegarder le répertoire ~/.svk, utilisez toute la puissance de SVK en faisant une copie de //local sur un autre serveur. Vous pouvez par exemple sur ce second serveur faire :
```
  svk ls svn+ssh://mon.serveur.principal/home/nc/.svk/local/
```
et reprendre ce que nous avons vu précédemment pour déclarer ce miroir. Vous aurez une sauvegarde à peu de frais entièrement gérée par SVK en lançant régulièrement
```
  svk pull //mirror/serveurprincipal/
```
Vous pouvez aussi bien sur utiliser la recette pour répliquer un dépôt local sur un dépôt distant. À vous de voir ce qui vous convient le mieux.
comme il n’est pas limité aux fichiers textes, il peut gérer les versions d’images ou de documents d’une suite bureautique. Bien sûr vous ne pourrez pas faire de diff entre deux versions.

Quoique, si vous utilisez OpenOffice.org et le format OpenDocument, il devrait être possible d’écrire un oodiff et d’utiliser la variable SVKDIFF pour l’utiliser à la place du diff standard…

Et comme il peut être associé à un serveur HTTP ou Subversion, il peut même servir à faire du travail collaboratif à plus ou moins grande échelle.
pour gérer plus facilement la traduction de documents comme expliqué par le développeur de SVK lui-même : http://www.onlamp.com/pub/a/onlamp/2004/09/09/svk_translation.html.
vous pouvez imaginer versionner tout ou partie de votre répertoire personnel sous SVK et faire un miroir de tout cela sur vos différents ordinateurs. Cela permet d’avoir un backup à peu de frais et/ou de synchroniser certains fichiers intéressants (.zshrc, …)
il peut servir à un administrateur système pour versionner les fichiers de configuration de ses serveurs avec le gros avantages sur certains autres outils du même type de ne pas avoir besoin d’un répertoire spécial comme CVS ou .svn et de pouvoir importer sur place un répertoire. Imaginez par exemple que sur tous vos serveurs vous fassiez :
```
 % svk import --to-checkout /etc/ //local/etc-serveur1
```
et qu’ensuite pour poussiez tout cela sur un serveur SVK centralisé grâce à la recette vu plus haut pour répliquer un dépot local sur un dépot distant. Cerise sur le gateau, vous pouvez même le faire sans ouvrir de trou dans votre pare-feu en utilisant les redirections de SSH.

Depuis votre serveur central vous pouvez voir toutes les modifications apportées à vos fichiers de configuration (bonjour ITIL). Vous pouvez comparer la version locale avec la version distante pour vérifier que rien n’a changé (voire automatiser cela et envoyer un mail en cas de changement).

Comme vous le voyez, les possibilités sont larges.

Conclusion

Notre tour d’horizon de SVK s’arrête là, il resterait bien sûr encore des choses à dire pour être complet, comme développer tout ce que l’on peut faire avec les hooks par exemple, mais cela n’a jamais été l’ambition de cet article. J’espère seulement qu’il vous aura donné envie d’utiliser un outil de gestion de versions si vous n’en utilisez pas encore que ça soit pour développer ou pour gérer vos serveurs, et de regarder de plus près SVK si vous en utilisez déjà un.

Les liens

http://svk.elixus.org/ — La page du projet
http://svkbook.elixus.org/ — Le manuel (en cours d’écriture)
http://svk.bestpractical.com/ — Le wiki de SVK
http://www.redmine.org — rien à voir avec SVK mais c’est un application web de gestion de projets GPL qui mérite vraiment le détour. Simple, de bon gout et pourtant vraiment puissant.

Ours

Nicolas Chuche –

Nicolas Chuche est ingénieur système au ministère de l’Équipement et utilisateur de systèmes GNU/Linux et Unix depuis une dizaine d’années.

Merci aux Mongueurs de toute la Francophonie qui ont assuré la relecture de cet article.

Sed Text filtering

stratus — Wed, 31 Mar 2010 12:52:20 +0000

Quelques commandes utiles avec Sed:

filtrage des commantaires:

sed ‘/^#/d;; s/#.*$//’

Suppression des lignes vides ou pleine d’espace

sed ‘/^[[:space:]]*$/d’

Mise en colonnes avec Awk:

df -m | awk ‘{printf “%-20s \t %-9s \t %-4s \t %s\n”,$1,$3,$4,$7}’

Memo éditeur de texte VI et VIM

stratus — Wed, 31 Mar 2010 12:34:14 +0000

Commandes d’insertion de texte

i insert insertion avant le curseur
I insert insertion au début de la ligne
a append insertion après le curseur
A append insertion à la fin de la ligne
o open ouvre une ligne blanche en dessous de la ligne courante
O open ouvre une ligne blanche au dessus de la ligne courante

Pour abandonner le mode insertion et retourner au mode commande, appuyer sur la touche

insert insertion d’un caractère de contrôle

Commande de concaténation

J concatenate concatène la ligne suivante à la fin de la ligne courante

Commandes de déplacements

/\ curseur déplacement d’une ligne vers le haut
\/ curseur déplacement d’une ligne vers le bas
<= curseur déplacement d’un caractère vers la gauche
=> curseur déplacement d’un caractère vers la droite
w word avance au début du mot suivant
F forward page suivante
B backward page précédente
^ ou 0 début de la ligne courante
$ fin de la ligne courante

Recherche d’un chaîne de caractères

/toutou recherche la chaîne “toutou” à partir de la position actuelle du curseur vers le bas du fichier
?toutou recherche la chaîne “toutou” à partir de la position actuelle du curseur vers le haut du fichier
n new recherche la prochaine occurence de la chaîne “toutou” recherche vers le bas du fichier
N new recherche l’occurence précédente de la chaîne “toutou” recherche vers le haut du fichier

Suppression et utilisation du buffer

x suppression du caractère sous le curseur
X suppression du caractère précédent le curseur
dd delete suppression de la ligne courante
yy yank copie la ligne courante dans le buffer
p paste colle la ligne contenu dans le buffer après la ligne courante
P paste colle la ligne contenu dans le buffer avant la ligne courante
u undo annule la dernière commande et seulement la dernière

Les commandes x, X, dd, et yy peuvent être précédées d’un facteur multiplicateur de leur action. Par exemple 7dd supprimera la ligne courante et les 6 lignes suivantes.

Remplacement

r replace remplace le caractère sous le curseur par un nouveau caractère
R replace remplace tous les caractères par de nouveaux caractères. Pour terminer appuyer sur la touche
C change remplace la fin de la ligne par de nouveaux caractères. Pour terminer appuyer sur la touche

Expressions régulières et mode commande globale

Les expressions régulières servent à manipuler le fichier texte dans son ensemble.

. représente un caractère quelconque
* multiplicateur du caractère précédent
^ début de ligne
$ fin de ligne ou fin de fichier
\ permet de représenter les caractères . * ^ $ en le mettant devant. Exemple : \* ou \$
\1 permet la réécriture de l’expression régulière lors d’une substitution
s commande de substitution
d commande de destruction de lignes
: passage en mode commande globale
g parcours global du fichier ou de la ligne

Exemples :

:1,$s/neant/bof/g de la ligne 1 à la dernière ligne, substitution de la chaîne neant par la chaîne bof
:1,$s/neant/bof/ idem mais seulement pour la première occurence de la chaîne neant par ligne
:1,3s/^.*=/BRAVO/ de la ligne 1 à la ligne 3, substitution du début de la ligne (^) jusqu’au (.*) caractère = par la chaîne BRAVO
1,$s/B.*O/\1 Veinard/ rajoute aux mots commençant par B et terminant par O, le mot “Veinard”
:1,$s/.$// suppression du dernier ($) caractère quel qu’il soit (.)
:10,20d suppression des lignes 10 à 20
:g/^#/d suppression des lignes commençant par un #
:g/^M/s//^M/g suppression des ^M en milieu de ligne et substitution par un vrai retour à la ligne. Taper sur “Enter” pour obtenir le ^M.

Divers mais utiles

:set showmode indique le mode (insertion ou commande) en bas de la fenêtre
:set number affiche le numéro de chaque ligne
:155 positionne sur la ligne 155
:set filetype=unix transforme le type DOS d’un fichier en type UNIX

Sauvegarder et quitter

:w write sauvegarde le fichier en cours d’édition
:q quit abandonne l’édition
:q ! quit abandonne l’édition sans sauvegarder le fichier
exit sauvegarde le fichier en cours d’édition et abandonne l’édition (idem :wq)

TuXxX Blog

Les Conteneurs Linux

Hôte, conteneur, isolation et performances

Un Chroot totalement isolé

Linux Containers

Préparation de la machine hôte

Le kernel

Montage de cgroup

Mise en place du réseau

Lutter contre uDev

Récupération des outils Linux Containers

Utilisation de Linux Container

Création d’un conteneur mandriva

Création de la racine

Préparation de /dev

Paramétrage du réseau et des services

Gestion du démarrage/arrêt

Lancement du conteneur

Conclusion

L’installation d’Hadopi sous Linux enfin possible !

Moving Backuppc Data Dir

Tech Recipe for Backuppc

Copy the real Files (the pool or cpool) to the new disk

Use an Internal backuppc command (BackupPC_tarPCCopy) to copy each PC hardlinks structure

Vi VimDiff

WebDAV CGI

Features

Download

Installation

Licensing

Links

Free Software Foundation réplique

Bacula, Sauvegarde sur Disque Dur

Introduction

1. Les différentes solutions de sauvegarde

1.1. Solutions libres

1.2. Solutions commerciales

1.3. Pourquoi un système de sauvegarde sur Disque?

2. Le projet Bacula

2.1. Présentation

2.2. Architecture du logiciel

2.2.1 Le directeur

2.2.2 Le Storage Daemon

2.2.3 Le Filer Daemon

2.2.4 La console

2.2.5 Le catalogue

3. Définition d’un plan de sauvegarde

3.1. Les types de sauvegarde

3.1.1 Sauvegarde complète

3.1.2 Sauvegarde differentielle

3.1.3 Sauvegarde incrementielle

3.1.4 Différences pratiques entre sauvegardes differentielle et incrementielle

3.2. Exemples de stratégies

3.2.1 Cas concret n°1

3.2.2 Cas concret n°2

4. Configuration de Bacula

4.1. Installation

4.1.1 Debian

4.1.2 Rpm & “from source”

4.2. Configuration des FD

4.3. Configuration du SD

4.4. Configuration du directeur

4.5. Prise en main de la console

Conclusion

SVK versionning

SVK

Chapeau de l’article

Sed Text filtering

Memo éditeur de texte VI et VIM