Une certaine maîtrise de l'environnement GNU/Linux est conseillée. L'installation du système de base du serveur (un Gentoo fonctionnel avec disques montés) n'est pas décrite. Réferrez-vous aux docs d'installation sur http://www.gentoo.org pour plus d'informations sur l'installation.

De plus, pour la mise en place des quotas, une recompilation du noyau est à prévoir si vous n'avez pas utilisé genkernel lors de l'installation et que la gestion des quotas n'est pas incluse dans le noyau courant.

Dans cet article, nous allons monter un serveur sous Gentoo Linux, qui fera office de serveur de backup. Les clients (les machines qu'il faud backuper) seront soit des Macintoshs soit des stations GNU/Linux, peu importe la distribution. L'outil retenu est donc rsync du côté client qui présente les avantages suivants:

• Ne transfert que les modifications apportées aux fichiers.
• Permet de préserver de manière correcte les permissions des fichiers.
• Permet un transfert dans un tunnel ssh pour des connexions sécurisées.
• Disponible sur les machines Linux et Mac OS X.

De plus, nous allons voir la configuration d'un serveur FTP pour permettre aux utilisateurs d'accéder à ses documents de manière relativement simple. Cette solution ne satisfera pas forcemment l'administrateur soucieux de la sécurité car le login transite en clair sur le réseau.

Le serveur de backup doit disposer d'assez de place disque. Dans mon cas, j'offre un quota de 10 Go par utilisateur. La mise en place des quotas est traitée dans cet article.

En dehors de la gestion des disques qui peut être délicate pour de grandes quantités de données (NAS, SAN, RAID5 hardware ou software...) une installation standard sans interface graphique suffira largement. Il est cependant nécessaire d'installer rsync et ssh, ceux-ci sont normalement installés par défaut sous Gentoo. Vérifiez cependant que ssh est bien lancé au démarrage:

rc-update add sshd default
/etc/init.d/sshd start

Le montage de ma partition qui accueillera les sauvegardes (/dev/sda4) est effectué dans /data. La suite de cet article part de ce principe; adaptez donc les commaandes à votre environnement...

Dans la configuration, nous allons travailler conjointement avec un client de test à sauvegarder. Une doc plus précise sur l'installation des autres clients est disponible plus loin dans cet article.

J'ai utilisé un client Gentoo Linux (ma machine de travail) pour me connecter à distance. Mais n'importe quelle machine sous GNU/Linux ou Mac OS X fera l'affaire pour autant que ssh et rsync y soient installés.

La première chose à faire est de vous connecter en ssh depuis le client sur le serveur et de vérifier le fonctionnement de ssh. Si tout fonctionne bien, nous allons améliorer cette connexion, par authentification via clé publique.

Pour les principes ou la configuration de l'authentification par clé publique, vous pouvez vous réferrer à la documentation de Gentoo que vous trouverez ici: http://www.gentoo.org/doc/fr/keychain-guide.xml ou tout simplement continuer à lire cet article ;-)

Dans un premier temps, sur le client, nous allons générer une paire de clés (clé publique, clé privée), par la suite de commandes suivantes (en root):

mkdir /usr/share/keys
ssh-keygen -t dsa -b 2048 -f /usr/share/keys/key-rsync

La génération de la clé peut prendre un certain temps. Tapez [enter] lorsque le système vous demande une passphrase. Confirmez également par [enter].

Note: Il est important que vous ne tapiez pas de passphrase pour la suite!

Une fois votre clé générée, connectez-vous sur le serveur maintenant et créez un utilisateur de test, comme par exemple "test", par la commande:

useradd -d /home/test -m -s /bin/bash test

puis donnez un mot de passe à l'utilisateur test:

passwd test
New UNIX password: [mon pass]
Retype new UNIX password: [mon pass]

Maintenant, nous allons copier la clé publique sur le serveur, donc sur le client, tapez la commande suivante (remplacez SERVEUR par le nom DNS ou l'adresse IP de votre serveur de backup).

scp /usr/share/keys/key-rsync.pub test@SERVEUR:~/myhost.pub
Password: [mon pass] [enter]
key-rsync			100%	xxxx

La clé est copiée, il faut maintenant l'ajouter aux clés autorisées. Toujours depuis le client:

ssh test@SERVEUR "mkdir ~/.ssh/"
Password: [mon pass]
ssh test@SERVEUR "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
Password: [mon pass]
ssh test@SERVEUR "cat ~/.ssh/authorized_keys"
Password: [mon pass]

Normalement, maintenant, si vous essayez de vous connecter avec la commande suivante sur le serveur, vous devriez être connecté sans fournir de mot de passe. A tester depuis le client bien entendu:

ssh -i /usr/share/keys/key-rsync SERVEUR

Si tout fonctionne à ce niveau, on touche au but ;-), sinon, vérifiez que votre fichier /etc/sshd_config (sur le serveur) est correct. Il doit contenir quelque chose se rapprochant à ceci (sans les commentaires):

Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
UsePAM yes
Subsystem sftp /usr/lib/misc/sftp-server

Il nous faut maintenant créer un dossier pour effectuer le backup du client sur le serveur. Voici comment (adaptez bien évidemment les chemins à votre environnement):

mkdir -p /data/rsync/test
chown -R test /data/rsync/test

Puis, essayons de faire le premier backup avec rsync depuis le client. Créez donc sur le client un répértoire de test avec quelques fichier et répértoires dedans, par exemple /home/USER/test (remplacez USER par votre nom d'utilisateur). Lancez ensuite la commande suivante (depuis le client donc...):

rsync --backup --force --delete -av -e "ssh -i /usr/share/keys/key-rsync" /home/USER/test test@SERVER:/data/rsync/test

Vérifiez que sur le serveur de backup tout figure en bonne place (/data/rsync/test ou votre répértoire de backup).

Si c'est le cas, on peut considérer que le serveur fonctionne.

Pour éviter qu'un seul utilisateur ne prenne toute la place que vous mettez à disposition, il nous faut mettre en place des quotas. Ceci interdira à quiconque de mettre plus de données sur le serveur que ce dont il en a réelement le droit, à vous de fixer la limite en fonction de la place dont vous disposez et du nombre de machines à sauvegarder.

Toutes les commandes qui suivent doivent naturellement être effectuées sur le serveur.

Pour mettre en place des quotas, vous devez disposer des paquets suivants emergés sur votre serveur:

sys-fs/quota
sys-fs/quotatool

Une fois installés, nous allons configurer un quota de 2 Go pour notre utilisateur test. Plusieurs points sont à vérifier, comme la présence des modules noyau permattant de gérer les quotas. Pas de problèmes si vous avez utilisé genkernel, sinon, ca se passe dans:

File systems  --->
	[*] Quota support

Créez ensuite un fichier nommé aquota.user à la racine de votre partition de backup, pour moi:

touch /data/aquota.user

Il faut maintenant donner uniquement les droits de lécture/écriture à root sur ce fichier:

chmod 600 /data/aquota.user

Il faut maintenant modifier légèrement le fichier fstab pour ajouter l'option usrquota au montage de notre partition de backup. Voici l'entrée pour ma parition sda4:

/dev/hda4   /data   reiserfs   defaults,noatime,usrquota   0 0

Démarrez ensuite le service des quotas, et ajoutez-le automatiquement au boot (en root):

/etc/init.d/quota start
rc-update add quota default

Avant de commencer, un petit mot sur les blocs disques. En effet, vous devrez définir les quotas en blocs et non en mégas ou en gigas. La première chose à faire est donc d'obtenir la taille d'un bloc (en octets) sur votre système de fichier, grâce à la commande suivante (pour les systèmes de fichiers ext2 ou ext3):

dumpe2fs /dev/hda3 | grep "Block size"

Le résultat devrait ressmebler à ceci:

dumpe2fs 1.38 (30-Jun-2005)
Block size:   1024

Si vous utilisez un système de fichier reiserfs, la taille des blocs est de 4096 octets par défaut.

Pour calculer la valeur en bloc d'un méga, il faut utiliser le calcul suivant:

4'227'072 / TAILLE_BLOC = NB_BLOCS

Par exemple pour des blocs de taille 4096 (relativement répendu):

4'227'072 / 4096 = 1'032 blocs

Donc pour un quota de 1'000 Mo, il faudra entrer 1'032'000 blocs (1'032 * 1000), rien de plus simple.

Si vous n'avez rien compris, envoyez-moi un mail, j'essayerais de vous expliquer mieux que ça ;-)

Mais pour ceux qui ont compris, rassurez-vous, ça continue. Maintenant, un peu de théorie sur les quotas... En fixant un quota, nous avons la possibilité de fixer deux limites, une limite soft et une limite hard. A partir de la limite soft, il reçevra des avertissements, et une fois qu'il atteindra la limite hard, il ne pourra plus copier de données supplémentaires.

Cependant, comme l'utilisateur n'est jamais en "relation directe" avec le serveur (uniquement via des scripts automatique), je fixe la limite hard et soft au même niveau, et je fais une surveillance du côté serveur pour un éventuel dépassement des quotas.

Vous pouvez éditer les quotas avec la commande suivante:

edquota -u test

Vous allez vous retrouver avec un fichier texte à éditer avec votre éditeur favori (nano par défaut sous Gentoo). Voici à quoi il ressemble:

Disk quotas for user test (uid 1000):
Filesystem   blocks    soft    hard    inodes    soft    hard
/dev/hda4    XXXXXX    0       0         0       0       0

Il nous suffit donc de mettre sous la colonne "soft" la limite soft en blocs, et sous la colonne hard la limite hard en blocs. Pour fixer un quota de 2'000 Mo par exemple (et toujours avec des blocs de 4096 octets), on mettra comme valeur 2'064'000.

Disk quotas for user test (uid 1000):
Filesystem   blocks    soft    hard    inodes    soft    hard
/dev/hda4    XXXXXXX  2064000  2064000    0         0       0

Sachez également que vous pouvez fixer des limites d'inodes, donc limiter le nombre de fichiers crées par l'utilisateur, cependant, elle n'est pas utilisée dans cet article.

Voilà donc pour la mise en place des quotas.

Il ne nous reste plus qu'à trouver une solution pour que nos clients puissent accéder à leur backup d'une manière plus simple que par la ligne de commande. J'ai choisi le FTP, grâce auquel ils auront un accès en lecture seule sur leur répértoire de backup. Ceci permet deux choses; la première c'est de controler par eux-mêmes que le backup se fait correctement, et de deux ils pourront éventuellement récupérer des fichiers de manière assez simple.

J'ai choisi de configurer le serveur proftpd. Sous Gentoo, il suffit de l'emerger:

emerge proftpd

Si vous souhaitez faire un serveur sFTP, n'oubliez pas d'ajouter "ssl" dans les USE flags à utiliser...

Ensuite, un peu de configuration, ca se passe dans le fichier /etc/proftpd/proftpd.conf. Voici une configuration de base, un peu commentée:

# Nom du serveur et options standard
ServerName		"Backup server FTP access"
ServerType		standalone
DefaultServer		on
RequireValidShell	off
AuthPAM			off
AuthPAMConfig		ftp

# Port sur lequel écouter:
Port			21

# Umask par défaut, inutile en ro:
Umask			022

# Nombre de connexion simultanées max:
MaxInstances		10

# Dir. Par défaut, le home:
<Global>
        DefaultRoot ~/backup/
        AllowLogSymlinks on
        ShowSymlinks on
	 # Interdire l'écriture à n'importe qui.
        <Limit WRITE>
                DenyAll
        </Limit>
</Global>

Il nous suffit ensuite donc de placer ces quelques ligne dans le fichier /etc/proftpd/proftpd.conf. Ensuite, il reste à créer un lien symbolique nommé "backup" dans le home qui pointe vers /data/rsync/USER, comme ceci:

su test
ln -s /data/rsync/test /home/test/backup
exit

Il ne reste plus à l'utilisateur à se loguer en FTP avec son username / password et d'arriver droit dans son répértoire de backup. N'est-ce pas merveilleux ?

Sur le serveur, nous allons écrire quelques scripts qui vont nous simplifier les tâches administratives, comme la création d'un utilisateur. Voici un exemple très simple, mais qui fait plus ou moins ce qu'on lui demande:

#!/bin/bash
		
NEWUSER = "$1"
PATHTOSYNC = "/data/rsync"
PATHTOHOME = "/home"

# Création de l'utilisateur:
useradd -d /$PATHTOHOME/$NEWUSER -m -s /bin/bash $NEWUSER

# Création du répértoire de config ssh
mkdir /$PATHTOHOME/$NEWUSER/.ssh

# Création du répértoire de backup
mkdir /data/rsync/$NEWUSER

# Mettre correctement les droits:
chown -R $NEWUSER /$PATHTOSYNC/$NEWUSER

# Créer le lien pour le FTP:
ln -s $PATHTOSYNC/$NEWUSER $PATHTOHOME/$NEWUSER/backup
chown $NEWUSER $PATHTOHOME/$NEWUSER/backup

# Demande de création du mot de passe
passwd $NEWUSER

Il faut encore éditer les quotas à la main, avec la commande:

edquota -u USER

Voilà notre travail grandement facilité.

Comme je l'ai déjà expliqué, il faut que rsync eet ssh soient installés sur la machine cliente que l'on souhaite ajouter. Qu'il s'agisse d'un Mac OS X ou d'un Linux, les commandes sont les mêmes. Un utilisateur doit déjà avoir été créé sur le serveur. Soyez sûr d'être en root avant de commencer...

En premier, il suffit de générer une paire de clés:

mkdir /usr/share/keys
ssh-keygen -t dsa -b 2048 -f /usr/share/keys/key-rsync

Veillez à ne pas entrer de passphrase.

Ensuite, pousser la clé sur le serveur:

scp /usr/share/keys/key-rsync.pub USER@SERVEUR:~/myhost.pub
Password: [mon pass]

Après, enregistrer la clé ssh sur le serveur pour authoriser la connexion (à executer sur le serveur):

cd /home/USER
cat myhost.pub >> .ssh/authorized_keys
chown USER .ssh/authorized_keys

Ensuite, tout devrait fonctionner. Il ne reste plus qu'à écrire un petit script sur le client contenant la commande rsyc, par exemple:

#!/bin/bash
rsync --backup --force --delete -av -e "ssh -i /usr/share/keys/key-rsync" /home/USER_LOCAL/USER@SERVEUR:/data/rsync/USER

J'enregistre personnellement ce script dans /usr/share/scripts, mais peu importe ou il se trouve. Ajoutez-le ensuite au crontab de root (ça évite de donner l'accès en lecture à l'utilisateur au fichier /usr/share/keys/key-rsync). Je planifie en général cette sauvegarde entre 12 et 14 heures tous les jours, afin d'optimiser les chances de présence sur le réseau.

Note concernant le Macintosh: le programme rsync est intégré à Mac OS X, en tout cas 10.4. Le dossier home des utilisateur ne se situe pas dans /home mais dans /Users, adaptez vos scripts en conséquence !