Un peu de tout » Debian

Linux : augmenter la taille d’une partition ext3

Didier Misson — Sun, 22 Nov 2009 09:57:54 +0000

J’ai une partition presque pleine sur un serveur Linux. Comment l’agrandir ?

Heureusement il me reste de la place libre derrière cette partition. Ce serveur étant distant, je dois y accéder en SSH, donc il me faut des outils en ligne de commande…

Je me base sur l’excellent article How To Resize ext3 Partitions Without Losing Data, écrit par Falko Timme (suivez Falko sur Twitter) sur HowtoForge.

Cet article explique comment agrandir, mais aussi réduire, la taille d’une partition Linux ext3. Dans mon cas, je n’ai besoin que d’agrandir. C’est le cas le plus simple et je n’aborderai pas l’autre. Ce n’est pas beaucoup plus difficile et si vous avez besoin de réduire la taille d’une partition ext2 ou ext3, je vous conseille d’aller lire en détail l’article de HowtoForge. C’est en anglais, mais il n’est pas compliqué à comprendre (de toute façon, les commandes ne changent pas).

Je vais modifier une partition Linux dont le système de fichier est ext3. Les explications sont utilisables aussi pour ext2 (c’est encore plus simple). Par contre, je n’ai pas encore cherché pour ext4, qui est maintenant standard en Ubuntu 9.10 !

Notre serveur est en Debian Etch 4.0, mais vous pouvez certainement faire ce même genre de manipulation sur toutes distributions Linux, en particulier sous Ubuntu. Les commandes ne changeront pas. Éventuellement, le passage en « root » et l’installation éventuelle des utilitaires pourraient être différents.

Comme je n’ai pas accès à mon serveur physiquement, je ne peux pas booter sur un LiveCD. Je dois faire tout ça depuis une session SSH.

La partition que je dois modifier n’est PAS la partition système / …

Si c’était la partition racine, cela poserait de bien plus grand problèmes, en tout cas à distance. Si le serveur était chez vous, il suffirait de le faire à partir d’un Live CD, comme un CD Ubuntu.

Autre facilité (j’ai vraiment de la chance !), ma partition est la dernière dans la table des partitions, et … miracle… il me reste de la place non utilisée en fin de disque dur

Alors, on ne le dira jamais assez … si vous touchez à une partition, ou à la table des partitions, FAITES des BACKUPS AVANT ! Vous n’êtes pas à l’abri d’une erreur, un mauvais numéro de partition, un plantage…

Les commandes étant des commandes systèmes, elles doivent être faites en « root« . Vous devez passer en « root » avant de faire ces commandes.

Pour accéder à un serveur distant en ssh, et passer en root, en Debian :

$ ssh ks
didier@ks's password:
Debian GNU/Linux 4.0

ks:~$ su -
Password: 
(1) 23:39:50 root@ks:~$

Pour accéder à un serveur distant en ssh, et passer en root, en Ubuntu :

$ ssh abrasd03
didier@abrasd03′s password:

Linux abrasd03 2.6.24-25-server #1 SMP Tue Oct 20 08:12:40 UTC 2009 i686
Last login: Sat Nov 21 21:49:32 2009 from noname

didier@abrasd03:~$ sudo -s
[sudo] password for didier: 
root@abrasd03:~#

Vous allez modifier une partition. Elle ne doit évidemment pas être utilisée. Vérifiez et arrêtez si nécessaire les programmes qui l’utilisent.

Vérifions les partitions de départ :

Quelles partitions sont montées au démarrage ?

$ less /etc/fstab
/dev/sda1       /               ext3    errors=remount-ro       0       1
/dev/sda2       /tmp            ext3    defaults                0       2
/dev/sda3       /var/log        ext3    defaults                0       2
...
/dev/sda7       none            swap    defaults                0       0
/dev/sda8       /home           ext3    defaults                0       2
/dev/sda9       /home/user1     ext3    defaults                0       2
/dev/sda10      /home/didier    ext3    defaults                0       2
/dev/sda11      /backup         ext3    defaults                0       2
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

C’est la partition backup que je désire étendre. Elle va me servir à faire des backups d’un AUTRE serveur. Si je fais un backup de mes dossiers sur le serveur même, ça me protégera d’une erreur, mais pas d’une panne disque dur…

Espace libre :

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.0G  940M  1.9G  33% /
tmpfs                 996M     0  996M   0% /lib/init/rw
udev                   10M   60K   10M   1% /dev
tmpfs                 996M     0  996M   0% /dev/shm
/dev/sda2             4.6G  162M  4.5G   4% /tmp
...
/dev/sda8              14G  2.3G   12G  17% /home
/dev/sda9              46G  3.5G   43G   8% /home/user1
/dev/sda10             46G  7.9G   38G  18% /home/didier
/dev/sda11             37G   17G   20G  46% /backup

J’ai besoin de plus de 37 GB.

« df -h » affiche l’espace libre (disk free) sous forme « compréhensible » (human), mais vous pouvez aussi afficher cet espace en nombre de blocks de 1K, ou en nombre de blocks de 4K.

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              3099260    962280   1979548  33% /
tmpfs                  1019212         0   1019212   0% /lib/init/rw
udev                     10240        60     10180   1% /dev
tmpfs                  1019212         0   1019212   0% /dev/shm
/dev/sda2              4806936    165500   4641436   4% /tmp
...
/dev/sda8             14421344   2326000  12095344  17% /home
/dev/sda9             48062440   3572068  44490372   8% /home/user1
/dev/sda10            48062440   8276808  39785632  18% /home/didier
/dev/sda11            38448276  17595788  20852488  46% /backup

$ df -B 4k
Filesystem           4K-blocks      Used Available Use% Mounted on
/dev/sda1               774815    240570    494887  33% /
tmpfs                   254803         0    254803   0% /lib/init/rw
udev                      2560        15      2545   1% /dev
tmpfs                   254803         0    254803   0% /dev/shm
/dev/sda2              1201734     41375   1160359   4% /tmp
...
/dev/sda8              3605336    581500   3023836  17% /home
/dev/sda9             12015610    893017  11122593   8% /home/user1
/dev/sda10            12015610   2069202   9946408  18% /home/didier
/dev/sda11             9612069   4398947   5213122  46% /backup

L’espace libre en blocs de 4K, ça peut servir lorsque vous devez recréer une partition avec fdisk.

Les partitions :

On peut lister les partitions avec fdisk :

$ fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id System
/dev/sda1   *           1         392     3148708+ 83 Linux
/dev/sda2             393        1000     4883760   83 Linux
/dev/sda3            1001        2216     9767520   83 Linux
/dev/sda4            2217       23018   167092065    5 Extended
/dev/sda5            2217        3432     9767488+ 83 Linux
/dev/sda6            3433        3675     1951866   83 Linux
/dev/sda7            3676        4173     4000153+ 82 Linux swap / Solaris
/dev/sda8            4174        5997    14651248+ 83 Linux
/dev/sda9            5998       12076    48829536   83 Linux
/dev/sda10          12077       18155    48829536   83 Linux
/dev/sda11          18156       23018    39062016   83 Linux

et afficher la taille de la partition qui m’intéresse en nombre de BLOCS /dev/sda11 :

$ fdisk -s /dev/sda11
39062016

Cfdisk est intéressant par la façon claire dont il affiche les partitions (par défaut, cfdisk prend le 1er disque dur) .

$ cfdisk

cfdisk 2.12r

Disk Drive: /dev/sda
Size: 250059350016 bytes, 250.0 GB
Heads: 255   Sectors per Track: 63   Cylinders: 30401

Name      Flags    Part Type FS Type       [Label]      Size (MB)
------------------------------------------------------------------
sda1      Boot      Primary  Linux ext3    [/]            3224.31
sda2                Primary  Linux ext3                   5000.98
sda3                Primary  Linux ext3                  10001.95
sda5                Logical  Linux ext3                  10001.95
sda6                Logical  Linux ext3                   1998.75
sda7                Logical  Linux swap / Solaris         4096.19
sda8                Logical  Linux ext3                  15002.92
sda9                Logical  Linux ext3                  50001.48
sda10               Logical  Linux ext3                  50001.48
sda11               Logical  Linux ext3                  39999.54
Logical  Free Space                  60727.25

Il reste 60 GB en fin de disque dur. Je veux les ajouter dans la partition sda11 (/backup).

Commençons l’agrandissement de la partition.

Je dois démonter la partition avant de la modifier.
Je suppose que vous avez arrêté tous les programmes utilisant cette partition.

$ umount /dev/sda11

Je devrais à un moment, rebooter le serveur. C’est inévitable si on veut qu’une modification à la table des partitions soit prise en compte !

Evitons de faire un montage automatique de cette partition lors du reboot. Je vais mettre cette partition en commentaire dans fstab :

$ vi /etc/fstab

/dev/sda1       /               ext3    errors=remount-ro       0       1
/dev/sda2       /tmp            ext3    defaults                0       2
…
/dev/sda7       none            swap    defaults                0       0
/dev/sda8       /home           ext3    defaults                0       2
/dev/sda9       /home/user1 ext3    defaults                0       2
/dev/sda10      /home/didier    ext3    defaults                0       2
#/dev/sda11      /backup                ext3    defaults                0       2
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

J’insère un caractère « # » en début de la ligne pour la partition /backup, et je sauve.

Je peux maintenant travailler sur cette partition.

Je commence par la vérifier. On ne sait jamais… Autant ne pas travailler sur une partition avec des erreurs.

$ fsck -n /dev/sda11
fsck 1.40-WIP (14-Nov-2006)
e2fsck 1.40-WIP (14-Nov-2006)
/dev/sda11: clean, 101/4889248 files, 4552382/9765504 blocks

Ok, pas d’erreur

Les étapes :

supprimer le journal ext3 de la partition, car l’utilitaire de modification de taille ne peut fonctionner que sur des partitions ext2
supprimer la partition sda11 ! … Aucune donnée ne sera perdue. La partition est juste retirée de la table des partitions
créer une nouvelle partition qui va prendre toute la place disponible en fin de disque)
écrire la table des partitions modifiées sur disque
rebooter pour que Linux prenne connaissance de la nouvelle table des partitions
forcer une vérification de la partition sda11
étendre le système de fichiers pour qu’il prenne la nouvelle taille de la partition
revérifier le système de fichier
recréer le journal ext3
remonter la partition
remettre cette partition dans /etc/fstab (la partition est en commentaire)

Supprimer le journal ext3 :

$ tune2fs -O ^has_journal /dev/sda11
tune2fs 1.40-WIP (14-Nov-2006)

Je me rend compte que j’ai un problème de table des partitions dans fdisk :

$ fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End Blocks   Id System
/dev/sda1   *           1         392     3148708+ 83 Linux
/dev/sda2             393        1000     4883760   83 Linux
/dev/sda3            1001        2216     9767520   83 Linux
/dev/sda4            2217       23018 167092065    5 Extended
/dev/sda5            2217        3432     9767488+ 83 Linux
/dev/sda6            3433        3675     1951866   83 Linux
/dev/sda7            3676        4173     4000153+ 82 Linux swap / Solaris
/dev/sda8            4174        5997    14651248+ 83 Linux
/dev/sda9            5998       12076    48829536   83 Linux
/dev/sda10          12077       18155    48829536   83 Linux
/dev/sda11          18156       23018 39062016   83 Linux

La partition étendue sda4 se termine à la fin de la partition sda11…

Pourtant, cfdisk montre 60 GB d’espace libre après sda11 ! Il suffit de cumuler les tailles que cfdisk affiche pour voir qu’on n’a que 190 GB d’alloués sur les 250 GB de disque…

Si je vérifie la table des partitions avec fdisk :

$ fdisk /dev/sda

Command (m for help): v
118613494 unallocated sectors

Il peut y avoir quelques secteurs non alloués (même 4 ou 5000), mais pas 118 millions de secteurs non alloués (càd en dehors des limites de la table des partitions…). Remarquez que, avec une taille de secteur de 512 bytes (1/2 KB), cela fait bien dans les 60 GB qui sont bien en fin de disque dur.

Je vais utiliser cfdisk pour supprimer sda11 et recréer la partition, en espérant que cfdisk ajoute lui-même la taille de la partition étendue sda4…

$ cfdisk
cfdisk 2.12r

 Disk Drive: /dev/sda
 Size: 250059350016 bytes, 250.0 GB
 Heads: 255   Sectors per Track: 63   Cylinders: 30401

 Name       Flags    Part Type FS Type        [Label]       Size (MB)
 ---------------------------------------------------------------------
 sda1       Boot      Primary  Linux ext3     [/]             3224.31
 sda2                 Primary  Linux ext3                     5000.98
 sda3                 Primary  Linux ext3                    10001.95
 sda5                 Logical  Linux ext3                    10001.95
 sda6                 Logical  Linux ext3                     1998.75
 sda7                 Logical  Linux swap / Solaris           4096.19
 sda8                 Logical  Linux ext3                    15002.92
 sda9                 Logical  Linux ext3                    50001.48
 sda10                Logical  Linux ext3                    50001.48
 sda11                Logical  Linux ext2                    39999.54
 Logical  Free Space                    60727.25

 [Bootable]  [ Delete ]  [  Help  ]  [Maximize]  [ Print  ]
 [  Quit  ]  [  Type  ]  [ Units  ]  [ Write  ]

 Delete the current partition

Je recrée une partition sda11 de la taille maximale.

...
sda9                 Logical  Linux ext3                    50001.48
sda10                Logical  Linux ext3                    50001.48
Logical  Free Space                   100726.78

[  Help  ]  [  New   ]  [ Print  ]  [  Quit  ]  [ Units  ]
 [ Write  ]

 Create new partition from free space

cfdisk semble bien reconnaitre 100 GB d’espace libre.

...
sda9                 Logical  Linux ext3                    50001.48
sda10                Logical  Linux ext3                    50001.48
Logical  Free Space                   100726.78

Size (in MB): 100726.78

Ok, ça semble bon. La partition sda11 fait bien 100 GB :

...
sda9                 Logical  Linux ext3                    50001.48
sda10                Logical  Linux ext3                    50001.48
sda11                Logical  Linux                        100726.78

J’écris la table des partitions.

cfdisk me donne un message d’avertissement ! Effectivement, c’est une opération dangereuse… mais elle est voulue. Ok, j’écris la table des partitions !

Je réessaye fdisk :

$ fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id System
/dev/sda1   *           1         392     3148708+ 83 Linux
/dev/sda2             393        1000     4883760   83 Linux
/dev/sda3            1001        2216     9767520   83 Linux
/dev/sda4 2217       30401 226396012+   5 Extended
/dev/sda5            2217        3432     9767488+ 83 Linux
/dev/sda6            3433        3675     1951866   83 Linux
/dev/sda7            3676        4173     4000153+ 82 Linux swap / Solaris
/dev/sda8            4174        5997    14651248+ 83 Linux
/dev/sda9            5998       12076    48829536   83 Linux
/dev/sda10          12077       18155    48829536   83 Linux
/dev/sda11 18156     30401 98365963+ 83 Linux

Et fdisk me donne cette fois une partition étendue sda4 allant jusqu’à la fin du disque dur (30401 cylindres)

Ce problème vient probablement car j’avais créé les partitions, quand nous avons configuré ce serveur, avec cfdisk.
cfdisk semble donc adapter le secteur de fin de la partition étendue sda4 en fonction du dernier secteur utilisé par la dernière partition.

La table des partitions est écrite. Il faut rebooter le serveur.
(Ne vous trompez pas ! REBOOT et pas halt… à distance, un serveur power off, c’est génant)

$ reboot

The system is going down for reboot NOW!

Après quelques minutes, votre serveur répond de nouveau aux pings.

Ne paniquez pas trop vite si cela prend LONGTEMPS !
Si le serveur n’a pas redémarré depuis des mois, il est possible que Linux fasse automatiquement un fsck de certaines partitions. Ca peut prendre un « certain temps »

Faites un test forcé de la partition :

$ e2fsck -f /dev/sda11
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda11: 101/4889248 files (69.3% non-contiguous), 4519580/9765504 blocks

Le système de fichiers est correct, mais il ne remplit pas encore la totalité des 100 GB de la partition !

« resize2fs » va utiliser, par défaut, la totalité de la place libre :

$ resize2fs /dev/sda11
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/sda11 to 24591490 (4k) blocks.
The filesystem on /dev/sda11 is now 24591490 blocks long.

Refaites un test de la partition après resize :

$ fsck -n /dev/sda11
fsck 1.40-WIP (14-Nov-2006)
e2fsck 1.40-WIP (14-Nov-2006)
/dev/sda11: clean, 101/12280352 files, 4754531/24591490 blocks

La partitioon ext2 est correct. Il faut recréer un journal ext3 :

$ tune2fs -j /dev/sda11
tune2fs 1.40-WIP (14-Nov-2006)
Creating journal inode: done
This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Je devrais pouvoir remonter la partition /backup, avec sa nouvelle taille.

$ mount /dev/sda11 /backup

$ df -h
Filesystem            Size Used Avail Use% Mounted on
/dev/sda1             3.0G 940M 1.9G 33% /
…
/dev/sda10             46G   12G   34G 26% /home/didier
/dev/sda11             93G   17G   76G 19% /backup

Ça semble correct ! Les 100 GB sont là.
(enfin… les 93 GB, ça dépend si on compte en multiple de 1000 ou de 1024

Un petit contrôle, et oui, les fichiers sont là !

La partition est étendue de 40 à 100 GB et les données sont intactes

ATTENTION, il reste UNE étape importante : le fichier fstab !

J’avais mis en commentaire sda11 pour ne pas avoir son montage lors du reboot.

Je dois éditer /etc/fstab pour remettre sda11. Sinon, au prochain reboot, ma partition /backup ne sera plus là !

$ vi /etc/fstab
/dev/sda1       /               ext3    errors=remount-ro       0       1
...
/dev/sda10      /home/didier    ext3    defaults                0       2
/dev/sda11      /backup         ext3    defaults                0       2
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Retirer le « # » en début de ligne, et sauvez le fichier /etc/fstab.

Voilà, la partition est étendue.

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil et Maxime Legrand.

Deeebian ? Eeebuntu eeevolue vers Debian !

Didier Misson — Tue, 20 Oct 2009 17:46:31 +0000

Etonnant quand on sait le succès d’ Ubuntu, Eeebuntu annonce que leur version 4.0 sera basée sur Debian instable.

L’équipe de développement dit vouloir plus de liberté de personnalisation et ne plus être lié à une sortie tous les 6 mois. Il pourrait y avoir des images ISO tous les trimestres.

Ca ne devrait pas trop changer les choses pour l’utilisateur, Ubuntu étant lui-même basé sur Debian. Le système de package est le même, la qualité aussi. Et si Ubuntu est maintenant bien plus connue et utilisée par le grand public que Debian, Debian pour moi est une distribution d’une grande qualité et qui est aussi facile d’installation et d’utilisation.

Eeedebian, ou Debeee, ou Deebian, va aussi s’ouvrir à l’environnement Desktop, et ne sera plus réservée au Netbooks.

Pour moi, cette ouverture est positive (en espérant que l’équipe de développement soit assez solide pour tenir ce surcroit de travail). Si Eeebuntu/Debian a le succès que j’espère, cela ouvrira une alternative solide à Ubuntu ! Ok, Debian était déjà là… mais une « Debian » personnalisée Desktop et Netbooks, ça devrait être intéressant

Eeebuntu… ça va faire bizarre pour une distribution basée sur Debian !

Un changement de nom ? Possible… Les discutions sont ouvertes

« Eeebuntu 4.0 Debian » devrait sortir en décembre 2009… sous ce nom ou sous un autre !

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil.

ProFTPd : invalid shell !

Didier Misson — Mon, 07 Sep 2009 22:01:50 +0000

J’ai installé ProFTPd sur notre serveur Debian Etch 4.0 (voir mon billet du 23 août).

Notre idée est d’utiliser FTP pour certains clients qui doivent pouvoir uploader leur site Web sur le serveur.
Pour cela, ils utilisent, soit un client FTP (Filezilla sous Windows par exemple, en Linux Gnome et je suppose KDE savent très bien faire cela), soit un programme de conception Web (CMS ou autre) sur leur PC qui permet de publier directement le site par FTP.

Simple oui… mais nous avons eu des problèmes avec certains utilisateurs !

Malgré un mot de passe correct, ProFTPd refusait le logon.
Dans le log on trouve des messages « (Login failed): Invalid shell« .

Le logon de certains utilisateurs est donc refusé. Voyons le message complet :

$ less /var/log/proftpd/proftpd.log

Sep 05 16:09:45 monserveur.com proftpd[29208] monserveur.com: ProFTPD 1.3.0 (stable) (built Tue Nov 4 14:54:12 UTC 2008) standalone mode STARTUP
Sep 05 16:15:57 monserveur.com proftpd[31033] monserveur.com (213.219.152.97.adsl.dyn.edpnet.net[213.219.152.97]):
FTP session opened.
Sep 05 16:16:14 monserveur.com proftpd[31033] monserveur.com (213.219.152.97.adsl.dyn.edpnet.net[213.219.152.97]):
USER christian (Login failed): Invalid shell: '/bin/false'

D’où vient ce shell « /bin/false » ?

Et bien, c’est nous qui l’avons configuré dans le fichier Passwd !

En effet, nous avons quelques utilisateurs administrateurs, qui évidemment doivent avoir le plein contrôle sur le serveur, mais aussi plusieurs utilisateurs qui n’ont accès qu’à un nombre réduit de possibilités. Par exemple :

utilisateurs mails : accès en IMAPs ou en Webmail.
utilisateurs FTP pour uploader des sites Web

Dans ces 2 cas, le userid doit exister en Linux pour l’authentification (user / mot de passe), le dossier « home » de l’utilisateur doit exister car c’est là que se trouve sa boîte mails locale, et c’est aussi dans son dossier « home » qu’il pourra uploader son site Web.

Mais dans ces 2 cas, nous ne désirons pas que cet utilisateur puisse faire logon en SSH !

La façon la plus simple de bloquer le logon en SSH est de modifier la shell que prendrait l’utilisateur au logon. En mettant un shell « bidon », on bloque son logon.

Cela se fait en éditant le fichier /etc/passwd :

$ vi /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
...
didier  :1002:1002:Didier Misson,,,:/home/didier:/bin/bash
christian  :1005:1007:Christian,,,,client site Web:/home/christian:/bin/false

Didier peut se connecter en FTP, mais pas Christian…

ProFTPd réclamerait dont un shell valide ?

Effectivement ! Si j’édite le fichier « passwd » et que je remets « /bin/bash » comme shell pour Christian, cela fonctionne. Il peut se connecter en FTP !

Oui… mais il peut aussi se connecter en console en SSH !

Je pourrais chercher du côté OpenSSH pour bloquer certains utilisateurs, mais il y a plus simple !

La réelle question est « pourquoi ProFTPd exige-t-il un shell valide ? »

Et bien… je ne sais pas !

Je ne sais pas, et je vais désactiver ce contrôle de shell valide !

On peut le faire de 2 façons.

Soit on configure ProFTPd pour ne plus vérifier au logon si le shell de l’utilisateur est valide :

Cela se fait en ajoutant la ligne suivante dans le fichier de configuration de ProFTPd :

$ vi /etc/proftpd/proftpd.conf

# Require a valid shell from /etc/shells.
RequireValidShell off

Sauver le fichier de configuration et redémarrer ProFTPd

$ /etc/init.d/proftpd restart

Soit on inclut le shell bidon « /bin/false » dans la liste des shells valides :

$ vi /etc/shells

# /etc/shells: valid login shells
/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/bash
/bin/rbash
/usr/bin/screen
/usr/bin/rssh
/bin/false

La commande « add-shell /bin/false » pourrait aussi être utilisée pour ajouter « /bin/false » au fichier.

Personnellement, je ne vois pas pourquoi on devrait bricoler pour forcer ProFTPd à « valider » un shell qui est par nature « invalide » ! Le plus logique et simple est pour moi de dire à ProFTPd de ne plus faire cette validation !

Donc, la solution 1 avec « RequireValidShell off » a ma préférence.

ps : une explication sur le rôle des « valids shells » dans l’envoie de mails… C’est déjà instructif. A creuser…

installation de ProFTP

Didier Misson — Sun, 23 Aug 2009 03:57:12 +0000

Ayant besoin d’un accès FTP vers mon serveur Debian, je décide d’installer un serveur FTP… mais le quel ?

Les choix sont nombreux, principalement :

Ils semblent tous aussi valables, et si vous parcourez les forums, ou en cherchant sur Google, vous trouverez des personnes conseillant ou déconseillant n’importe le quel de ces serveurs FTP !

J’ai finalement décidé d’installer ProFTP, et cette installation devra permettre à ProFTP de fonctionner en TLS de façon à sécuriser la connexion et que les mots de passe ne circulent pas en clair sur le réseau.Voici différentes documentations trouvées pour ProFTDd sur le Web :

Setting up an FTP server on Debian : je suivrai ces explications
Proftp Server Configuration in Debian
FTP Server setup with TLS (Transport Layer Security) on Debian
Settingup an FTP Server on Ubuntu with ProFTPD
Serveur FTP : PROFTPD
List of directives

L’installation est assez classique, ProFTPd se trouvant dans la liste des packages Debian. En Ubuntu, et dans la majorité des distributions également. En Ubuntu, utilisez « sudo » devant vos commandes système.

A la question « Run proftpd from inetd or standalone? », il est préférable de répondre « standalone »

$ su -
Password:

:~$ aptitude install proftpd

Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following NEW packages will be installed:

 proftpd 

0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 855kB of archives. After unpacking 2720kB will be used.
Writing extended state information... Done
Get:1 http://mir1.ovh.net etch/main proftpd 1.3.0-19etch2 [855kB]
Fetched 855kB in 0s (3060kB/s)
Preconfiguring packages ...
Selecting previously deselected package proftpd.
(Reading database ... 32752 files and directories currently installed.)
Unpacking proftpd (from .../proftpd_1.3.0-19etch2_amd64.deb) ...
Setting up proftpd (1.3.0-19etch2) ...
Adding system user `proftpd' (UID 109) ...
Adding new user `proftpd' (UID 109) with group `nogroup' ...
Not creating home directory `/var/run/proftpd'.
Adding system user `ftp' (UID 110) ...
Adding new user `ftp' (UID 110) with group `nogroup' ...
Creating home directory `/home/ftp' ...
`/usr/share/proftpd/templates/welcome.msg' -> `/home/ftp/welcome.msg.proftpd-new'
Starting ftp server: proftpd - IPv6 getaddrinfo 'azerty.monserveur.com' error: Name or service not known
.

Visiblement ProFTPd essaye de démarrer un service FTP également en IPv6.

Arrêtons ProFTPd pour vérifier sa configuration :

$ /etc/init.d/proftpd stop
Stopping ftp server: proftpd.

La configuration de ProFTPd se trouve dans :

$ vi /etc/proftpd/proftpd.conf

Désactivons l’IPv6 (si votre serveur est correctement configuré pour l’ IPv6, laissez le actif).

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6                         off

Il est possible d’autoriser le logon « anonymous » en décommentant les lignes en fin du fichier de configuration. Ce n’est PAS du tout conseillé, sauf si votre serveur est un FTP grand publique.

J’ai réduit le nombre maximum de connexions FTP simultanées. 30 est trop élevé dans notre cas, le FTP étant exeptionel. J’ai réduit à 8 :

MaxInstances                    8

Il est conseillé de ne pas permettre à tous les utilisateurs de se promener (lire et écrire) dans tous vos dossiers et fichiers !
Pour restreindre l’accès au dossier « Home » de chaque utilisateur et pour que Pro-FTPd fasse automatiquement un « chroot » sur le dossier de l’utilisateur, ajoutez ces lignes dans le fichier de configuration :

# Dossier par défaut (chroot ProFTPd)
DefaultRoot ~

Sécurité : configuration du TLS (fortement conseillé)

Pour configuré le TLS, il faut d’abord générer un certificat (ou le demander à votre fournisseur de CA : Verisign, etc…). Vous pouvez le générer vous-même.

Si ce n’est pas encore fait, installer OpenSSL :

aptitude install openssl

Il faut créer un certificat SSL pour utiliser TLS. Je le place dans un sous-dossier /etc/proftpd/ssl :

$ mkdir /etc/proftpd/ssl

$ cd /etc/proftpd/ssl/

$ openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd

Generating a 1024 bit RSA private key
.....................++++++
............................++++++
writing new private key to '/etc/proftpd/ssl/proftpd.key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BE
State or Province Name (full name) [Some-State]:Belgium
Locality Name (eg, city) []:Brussels
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Henri Dupont
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:ftp.dupont.com
Email Address []:henri@dupont.com

$ ls -l
-rw-r--r-- 1 root root 1314 2009-08-23 07:07 proftpd.cert.pem
-rw-r--r-- 1 root root  887 2009-08-23 07:07 proftpd.key.pem

Il faut maintenant configurer ProFTPd pour utiliser ce certificat et fonctionner avec TLS.

$ vi /etc/proftpd/proftpd.conf

Remplacez ces lignes dans la configuration de ProFTPd :

TLSEngine off

par la configuration suivante :


TLSEngine                  on
TLSLog                     /var/log/proftpd/tls.log
TLSProtocol                SSLv23
TLSOptions                 NoCertRequest
TLSRSACertificateFile      /etc/proftpd/ssl/proftpd.cert.pem
TLSRSACertificateKeyFile   /etc/proftpd/ssl/proftpd.key.pem
TLSVerifyClient            off
TLSRequired                on

La variable TLSProtocol permet de choisir, soit SSLv23 qui autorise à la fois le SSLv3 et le TLSv1 (TLS est préférable car plus sécurisé).

La variable TLSRequired, si à « on », bloque l’accès au client qui ne sont pas en SSL ou TLS !
Si vous voulez que le « simple » FTP non sécurisé soit encore possible, mettez cette variable à « off ».

Sauvez ( :wq en Vi) et redémarrez ProFTPd :

$ /etc/init.d/proftpd start
Starting ftp server: proftpd.

Vous pouvez faire un essais en vous connectant avec un client FTP qui supporte le SSL ou le TLS.
Vérifiez dans les logs si le SSL a bien fonctionné :

$ less /var/log/proftpd/tls.log

Aug 23 07:25:13 mod_tls/2.1.1[17124]: using default OpenSSL verification locations (see $SSL_CERT_DIR environment variable)
Aug 23 07:25:13 mod_tls/2.1.1[17124]: TLS/TLS-C requested, starting TLS handshake
Aug 23 07:25:13 mod_tls/2.1.1[17124]: TLSv1/SSLv3 connection accepted, using cipher DHE-RSA-AES256-SHA (256 bits)
Aug 23 07:25:13 mod_tls/2.1.1[17124]: Protection set to Private
Aug 23 07:25:13 mod_tls/2.1.1[17124]: starting TLS negotiation on data connection
Aug 23 07:25:13 mod_tls/2.1.1[17124]: TLSv1/SSLv3 data connection accepted, using cipher DHE-RSA-AES256-SHA (256 bits)
Aug 23 07:25:26 mod_tls/2.1.1[17126]: using default OpenSSL verification locations (see $SSL_CERT_DIR environment variable)
Aug 23 07:25:26 mod_tls/2.1.1[17126]: TLS/TLS-C requested, starting TLS handshake
Aug 23 07:25:26 mod_tls/2.1.1[17126]: TLSv1/SSLv3 connection accepted, using cipher DHE-RSA-AES256-SHA (256 bits)
Aug 23 07:25:26 mod_tls/2.1.1[17126]: Protection set to Private
...

Le SSL/TLS est bien obligatoire dans ma configuration (option « TLSRequired on »).
Si j’essaye de me connecter avec un client sans utiliser SSL, j’obtiens un message d’erreur :

Warning:  ftp_login() [function.ftp-login]: SSL/TLS required on the control channel in /home/didier/...

Le message d’erreur varie en fonction de votre client, mais dans mon cas, il est très clair « SSL/TLS required » !

Les logs de ProFTPd vont dans /var/log/proftpd.

Il est intéressant d’utiliser Logrotate pour les faire tourner tous les jours :

$ vi /etc/logrotate.d/proftpd

/var/log/proftpd/*.log {
missingok
notifempty
postrotate
/usr/bin/kill -HUP `cat /var/run/proftpd.pid 2>/dev/null` 2>/dev/null || true
endscript
}

Je dois encore vérifier demain, si le logrotate fonctionne correctement

Debian Lenny 5.0 est disponible

Didier Misson — Sun, 15 Feb 2009 12:27:06 +0000

Debian Lenny 5.0 était annoncé pour ce samedi 14 février. Et bien c’est fait! Debian Lenny est sortie. C’est officiel sur le site Debian.

Ce dimanche (en tenant compte du décalage horaire avec d’autres parties du monde) les différents mirroirs devraient se mettrent à jour progressivement.

BackupPC : installation et configuration

Didier Misson — Sat, 24 May 2008 04:06:37 +0000

Un backup régulier est essentiel !

Les risques de perte ou corruption de vos données, documents, photos numériques, vidéos, sont trop nombreux pour faire confiance à la chance…

BackupPC est un utilitaire efficace pour ce genre de tâche, que ce soit pour un usage privé ou professionnel, pour la sauvegarde de données venant d’une machine Linux ou Windows, en local ou située à 3000 Km…

Je vais faire cette installation sur un serveur Ubuntu, mais la méthode devrait être similaire sous Debian, et assez proche (hors installation des packages) sur toutes les autres distributions.

J’ai été aidé par Alain Barbason qui a fait assez bien d’essais et qui m’a passé une première documentation sur son installation de BackupPC.

De quoi avez-vous besoin pour installer BackupPC ?

BackupPC est un programme qui s’installe normalement sur un serveur et qui s’occupera de faire vos backups.

Donc :

un serveur Linux
Apache2 pour profiter de l’interface Web très conviviale
assez de place disque pour la quantité de données à sauver et le nombre de backup à conserver (on peut comprimer pour réduire la place)

Je suppose que vous avez déjà un serveur avec Apache fonctionnel, et assez de place disque.

BackuPC est dans la liste des packages Ubuntu et Debian. L’installation est donc assez facile.

Pour éviter en Ubuntu, de devoir ajouter « sudo » devant toutes mes commandes systèmes (la majorité ici), j’utilise cette astuce pour passer en « root » :

didier@abrasd03:~$ sudo bash

[sudo] password for didier:

root@abrasd03:~#

L’installation est classique :

~# aptitude install backuppc
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Lecture de l'information d'état étendu       
Initialisation de l'état des paquets... Fait
Construction de la base de données des étiquettes... Fait
Les NOUVEAUX paquets suivants vont être automatiquement installés :
  libarchive-zip-perl libcompress-raw-zlib-perl libcompress-zlib-perl libfile-rsyncp-perl
  libio-compress-base-perl libio-compress-zlib-perl libperl5.8 perl-suid
Les NOUVEAUX paquets suivants vont être installés :
  backuppc libarchive-zip-perl libcompress-raw-zlib-perl libcompress-zlib-perl libfile-rsyncp-perl
  libio-compress-base-perl libio-compress-zlib-perl libperl5.8 perl-suid
0 paquets mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 1563ko d'archives. Après dépaquetage, 5431ko seront utilisés.
Voulez-vous continuer ? [Y/n/?]

On remarque l’installation de plusieurs librairies Perl pour le support de la compression.

Sur mon serveur, j’avais déjà le package « rsync » installé.

Voulez-vous continuer ? [Y/n/?]
ATTENTION : des versions non certifiées des paquets suivants vont
être installées.

Des paquets non certifiés peuvent compromettre la sécurité de votre
système. Vous ne devriez les installer que si vous êtes certain
que c'est bien votre intention.

  backuppc libio-compress-zlib-perl libcompress-raw-zlib-perl libcompress-zlib-perl libperl5.8
  libio-compress-base-perl libarchive-zip-perl perl-suid libfile-rsyncp-perl 

Voulez-vous ignorer cet avertissement et continuer quand même ?
Pour continuer, entrer « Oui ». Pour interrompre l'installation, entrer « Non » : oui

Je répond « oui » et je continue.

L’installation me pose quelques questions :

Je sélection « apache2″ comme serveur Web.

BackuPC crée un utilisateur « backuppc » et génère un mot de passe, que je note !

Si nécessaire, je peux modifier ce mot de passe par la commande

htpasswd /etc/backuppc/htpasswd backuppc

Le message suivant m’indique qu’une modification est nécessaire sur un répertoire :

adduser : Attention: Le répertoire personnel /var/lib/backuppc n'appartient pas à l'utilisateur que vous êtes en train de créer.

Adding password for user backuppc

L’utilisateur »backuppc » a en effet le dossier « /var/lib/backuppc » comme « home ».

Pourtant, que je vérifie ce dossier, les droits sont corrects :

root@abrasd03:/var/lib# ls -l

drwxr-x---  7 backuppc backuppc 4096 2008-05-24 07:02 backuppc

Je ne change donc pas les droits.

BackupPC permet plusieurs moyens de connexion et de sauvegarde.

Dans mon cas, pour le serveur distant (le client) que je compte sauvegarder, les sessions se feront en SSH et les sauvegarde avec rsync à l’intérieur de ces sessions SSH.

La première chose à faire est donc de configurer SSH, en particulier les clés SSH, sur le serveur BackupPC et sur le client distant.

Il est nécessaire de configurer des clés pour permettre un logon automatique, sans devoir taper manuellement un mot de passe lors de la session SSH.

C’est l’utilisateur « backuppc » qui fera logon, depuis votre serveur de backup, en « root » vers votre machine distante.

Le logon en root est nécessaire, pas impossible mais difficile à éviter, pour que BackupPC puisse faire la sauvegarde, et le restore éventuel, de tous vos fichiers, y compris les fichiers de tous les utilisateurs (avec des droits différents) et les fichiers systèmes. Je vais donc laisser ce logon ssh avec « root ».

Je dois générer une clé rsa publique pour l’utilisateur « backuppc » et la mettre dans la liste des clés autorisées sur la machine distante.

root@abrasd03:~# su - backuppc
$ pwd
/var/lib/backuppc

Je répond 3 fois aux questions suivantes (dossier par défaut et pas de mot de passe sur cette clé)

$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/var/lib/backuppc/.ssh/id_rsa):

Created directory '/var/lib/backuppc/.ssh'.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /var/lib/backuppc/.ssh/id_rsa.

Your public key has been saved in /var/lib/backuppc/.ssh/id_rsa.pub.

The key fingerprint is:

dc:49:..:..:...   ... backuppc@abrasd03

Les clés sont générées :

$ ls -l /var/lib/backuppc/.ssh

-rw------- 1 backuppc backuppc 1675 2008-05-24 07:26 id_rsa

-rw-r--r-- 1 backuppc backuppc  399 2008-05-24 07:26 id_rsa.pub

J’ai plusieurs moyens pour copier cette clé publique sur la machine distante (ks12345.kimsufi.com). Je peux même simplement ouvrir un éditeur comme Vi, et la recopier avec un copy/pass en texte.

Mais une commande SSH est spécialement prévue pour cette copie de clé (merci Alain de me l’avoir fait découvrir) :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@ks12345.kimsufi.com
Password:
Now try logging into the machine, with "ssh 'root@ks12345.kimsufi.com'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Vous devriez maintenant pouvoir faire logon en SSH avec la clé, sans devoir taper de mot de passe :

$ ssh root@ks12345.kimsufi.com

S’il vous demande un mot de passe ou que votre session SSH est refusé, c’est que vous avez un problème de clé, de copie de cette clé, ou que la configuration du serveur SSH sur le client distant n’est pas correcte.

Vérifiez sur la machine distante que le serveur SSH autorise le logon en root et les clés publiques :

ks12345:~# vi /etc/ssh/sshd_config

...

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

Il reste à configurer quelques options dans BackupPC et quelle machine et quels dossiers il doit sauvegarder.

La plupart des options générales peuvent se configurer dans une superbe interface Web, mais je n’ai pas trouvé d’options pour des configurations propres à une machine client en particulier.

Je vais indiquer à la fois les configurations en console en texte, et en graphique via l’interface Web. Vous utilisez celle que vous préférez. (il semble que dans Debian Etch, l’interface Web ne contienne pas les menus administrations…).

# vi /etc/backuppc/config.pl

Je modifie la langue par défaut (en) et je mets français :

# Currently the Language setting applies to the CGI interface and email

# messages sent to users.  Log files and other text are still in English.

$Conf{Language} = 'fr';

Si vous préférez le faire via l’interface Web :

http://192.168.168.251/backuppc (l’adresse IP ou le nom de votre serveur Web, et logon avec « backuppc » et le mot de passe généré à l’installation)

Allez dans le menu à gauche « Edit config », dans « CGI », et sélectionnez « fr » dans le menu « language »

Dans mon cas, je veux modifier l’endroit de sauvegarde car ma partition /var n’a pas assez de place libre pour les backups que je désire faire. J’ai une partition /data de 94 GB disponible, et j’y ai créé un dossier backupp.

Dans mon cas, je dois donc modifier le dossier de backup « TopDir » en /data/backuppc.

# Important installation directories:
#
#   TopDir     - where all the backup data is stored

### $Conf{TopDir}      = '/var/lib/backuppc';
$Conf{TopDir}      = '/data/backuppc';

ou dans l’interface Web, dans le menu « Modifier la configuration » / « Serveur » (en bas, la variable « TopDir ») :

Par défaut, la totalité des dossiers et fichiers d’une machine sont sauvegardés. Ce n’est pas toujours indispensable. En Linux il est souvent plus rapide de réinstaller une distribution et de ne restaurer que les données et quelques fichiers de configuration. Adaptez ce paramètre suivant vos besoins :

# This can also be a list of multiple file system paths or modules.
# For example, by adding --one-file-system to $Conf{RsyncArgs} you
# can backup each file system separately, which makes restoring one
# bad file system easier.  In this case you would list all of the mount
# points:
#
#     $Conf{RsyncShareName} = ['/', '/var', '/data', '/boot'];
#
#$Conf{RsyncShareName} = '/';
$Conf{RsyncShareName} = ['/etc', '/home', '/var/www'];

ou en graphique dans « modifier la configuration » / « xfer », sélectionnez « rsync » et remplacez ou ajouter des dossiers :

Définir les machines à sauvegarder :

# vi /etc/backuppc/hosts

# The first non-comment non-empty line gives the field names and should
# not be edited!!
#

host        dhcp    user    moreUsers     # <--- do not edit this line
#farside    0       craig   jill,jeff     # <--- example static IP host entry
#larson     1       bill                  # <--- example DHCP host entry
localhost   0       backuppc
ks12345.kimsufi.com     0       backuppc

ou dans l’interface web : « Modifier les machines », cliquer sur « ajouter », introduire le nom de votre machine distante et le userid utilisé (backuppc). N’oubliez pas de cliquer sur sauvegarder.

Il est également possible de définir des options machine par machine, par exemple si vous désirez faire la sauvegarde de machines qui ne restent pas branchées 24h/24 ou des sauvegardes de dossiers différents sur certaines machines.

Créez un dossier et un fichier de configuration « config.pl » propre à cette machine dans /var/lib/backuppc/pc (il existe peut-être déjà)

# cd /var/lib/backuppc/pc/
# mkdir ks36586.kimsufi.com
# vi ks36586.kimsufi.com/config.pl

et ajouté y ces lignes, modifiées en fonction des dossiers que vous désirez sauvegarder, ou de toute autre option.

Une option définie dans un fichier /var/lib/backuppc/pc/nom_de_la_machine/config.pl sera prise en priorité pou cette machine, avant les options définies dans le fichier général /etc/backuppc/config.pl.

ATTENTION : n’oubliez pas de mettre « backuppc » comme propriétaire de ce dossier, sinon vous aurez une erreur lors des sauvegarde car BackupPC n’arrivera pas à écrire les logs pour cette machine :

chown -R backuppc:backuppc ks12345.kimsufi.com

Il vous reste maintenant, via l’interface Web, à démarrer votre premier backup.

Si ça coince, regarder les logs : c’est souvent un problème de clés, d’autorisation…

Personnellement, en essayant de faire le backup de notre serveur chez OVH, j’ai eu des erreurs « ping too slow« .

Il semble que par défaut, BackupPC fixe le ping maximum à 20 msec de façon à empécher des sauvegardes très lentes via modem et dialup. Effectivement, mes pings étaient entre 21 et 23 msec.

Cela ne me semble pas un problème de faire des sauvegardes sur le Net via ADSL. Il est évident que c’est plus lent que sur un Lan à 100 Mbps chez soi !

Ne l’oubliez pas, surtout en cas de restore, car si la vitesse en ADSL ou ADSL2 en descendant (download), càd de votre machine distante sur le Net vers votre PC à la maison est souvent de 4, 6 ou même jusque 20 Mbps, la vitesse montante (upload), càd de votre PC qui a fait les backup vers votre machine client distante sera BEAUCOUP plus lente !

Couramment, les vitesses d’upload ADSLsont entre 384 Kbps et 1 Mbps. Si vous devez par exemple restaurer 1 GB de donnée sur votre serveur chez OVH ou Dedibox, avec une vitesse d’upload de 512 Kbps (64 Kbytes / sec), cela vous prendra mathématiquement au minimum 16.384 secondes… Environ 4h30, probablement le DOUBLE sans compression. « Heureusement », BackupPC faisant une compression, j’espère (pas fait le test) que le restore sera dans les 4h par Giga bytes de données à restorer

Ce n’est pas une limitation de BackupPC, mais bien une limitation de vitesse en upload sur votre ligne ADSL… Si vous avez besoin d’un backup / restore plus rapide, ne changer pas de soft ! Mais faite le backup sur une machine avec une ligne plus rapide (par exemple sur un 2ème serveur chez OVH ou Dedibox : les 2 serveurs communiqueraient alors à 100 Mbps)

Le paramètre à modifier pour augmenter le ping maximum sur trouve sur la page « Paramètres de sauvegarde » (et profitez en pour vérifier si la compression est activée : 3 est un bon choix).

Vous devriez maintenant pouvoir lancer votre premier backup.

BackupPC : pourquoi sauvegarder vos données ?

Didier Misson — Sat, 24 May 2008 03:47:23 +0000

On ne le dira jamais assez : un backup est indispensable pour sauvegarder vos données, que ce soit votre serveur Web critique, votre blog, ou vos documents personnels. Il n’y a pas que ces documents ou sites. Et vos souvenirs familiaux ? Les appareils photos numériques sont de plus en plus courants, performants et abodables. Et si vous perdiez la totalité des photos du mariage de votre frère, de la naissance de votre fille, ou de votre safari au Kenia (je n’y ai malheureusement pas été) pour un « bête » problème de panne de disque dur, de virus (si elles sont sauvegardées sur un PC Windows)… ou (ça arrive) à cause d’une fausse manoeuvre (rm ou format erroné) ?

Ces choses ARRIVENT. Il ne faut pas que se reposer sur la chance !

Vous espérez bien conserver certaines de ces données, et vos photos et vidéos, pendant de longues années. Même sans fausse manoeuvre ni virus (quoi que… ça arrive aussi, faut pas rêver), le disque dur où vous avez stocker ces fichiers n’est pas éternel…

Alors que faire ?

Sauvegarder ! Faire un ou plusieurs backup !

La tâche vous est facilitée par le prix très faible des disques durs, internes ou externes, et leurs grandes capacités. Ce serait dommage de ne pas avoir de sauvegarde alors qu’un disque dur de 320 GB coute actuellement 60 €.

Un 2ème disque dur dans le même Pc ?C’est bien. Ca vous protège au moins contre la simple panne hardware de votre disque dur. Mais pas des éventuels virus ou hacking de votre serveur !

Le fonctionnement en RAID, c’est pratique aussi, mais ça n’enlève pas la nécessité d’un sauvetage de vos données, car si vous effacez accidentellement un dossier, ou de nouveau le problème de virus ou hacking, ou d’un bug applicatif, vos données seront effacées de vos DEUX disques en Raid

Non, pour ces raisons, il est préférable d’avoir votre copie de sauvegarde sur une autre machine.

Mettre votre backup sur une autre machine va aussi améliorer sa sécurité en vous protégeant contre un plus grand nombre de « problèmes » hardware telque une panne d’alimentation qui enverrait une forte sur-tension dans votre système, ou des problèmes secteurs (sur-tension ou foudre).

Une ou des copies de sauvegarde, c’est nécessaire.

Mais automatiser vos sauvegardes l’est aussi, pour ne pas oublier de les faire (c’est toujours quand on est pressé, qu’on ne fait pas de backup pendant 3 semaines et que la panne arrive !), pour avoir un moyen efficace de les faire et de restorer vos données si nécessaire, et pour avoir une réelle méthode de backup en définissant par exemple combien de sauvegarde il faut conserver…

En résumé :

Où faire votre copie de sauvegarde ?

aucune copie de vos données :
- vous aimez le risque !
- un jour vos enfants vous demanderons « Pourquoi on n’a aucune photos de votre mariage, ou de quand nous étions petits ? » … (parce que le disque dur de papa est tombé en panne…)
- vous êtes à la merci de la moindre panne hardware, sur-tension, vol ou destruction de votre Pc (feu, foudre) et de toutes erreurs de manipulations (effacement, formatage)
copie de vos données en double sur le MÊME disque dur :
- première protection contre les erreurs de manipulation (effacement, format SI sur une partition différente)
- aucune sécurité si panne hardware du disque dur ou alimentation, ni en cas de vol du Pc ou d’incendie
- processus en général manuel : si vous oubliez de faire ces copies régulièrement..
disques durs en RAID :
- facile. C’est automatique
- il faut monitorer son Raid ! Par exemple, si vous ne surveillez pas les messages d’alerte de votre Raid (software ou hardware), vous risquez de ne pas voir la défaillance d’un de vos disques durs, et vous vous retrouver alors sur un disque unique et sans filet…
- cela ne vous protège PAS contre certaines erreurs de manipulation, ni contre des virus (si Pc Windows) ou hacking : si un fichier est effacé ou corrompu, il le sera automatiquement sur vos DEUX disques Raid !
- ne protège pas contre de gros problèmes comme certaines pannes d’alimentation, sur-tension, feu, foudre, ni contre le vol : vos 2 disques durs ou même la totalité de votre PC peuvent être impactés !
copie de vos données en double sur un 2ème disque dur (non Raid) du même Pc :
- ce n’est pas automatique : faut pas oublier de faire cette copie
- ne protège pas contre les virus ou hacking : en cas d’attaque, il est très probable que tous vos disques durs et toutes vos partitions seront contaminées ou détruites !
- ne protège pas contre de gros problèmes comme certaines pannes d’alimentation, sur-tensions, le feu, la foudre, ni contre le vol : vos 2 disques durs ou même la totalité de votre PC peuvent être impactés !
- protège mieux contre certaines erreurs de manipulation : si vous perdez un fichier, sa copie est disponible sur l’autre disque dur.
copie de vos données sur 2 disques durs de Pc différents :
- ce n’est pas automatique.
- bonne protection contre les virus ou hacking : en cas d’attaque, en général un seul Pc ou serveur est concerné (à condition de ne pas avoir de partage de disque dur actif en permanence, sinon le virus ou attaquant à directement accès aux fichiers de votre 2ème machine)
- très bonne protection contre de gros problèmes comme certaines pannes d’alimentation
- bonne protection contre les sur-tensions, feu, foudre, et le vol si vos 2 machines sont dans des pièces différentes, sur des circuits électriques différentes… ou mieux… dans des habitations différentes
- protège bien contre certaines erreurs de manipulation : si vous perdez un fichier, sa copie est disponible sur l’autre machine.

L’idéal est donc d’avoir votre ou vos sauvegardes sur une 2ème machine, physiquement séparée de la première. La sécurité maximale étant de les avoir dans des habitations séparées : chez un ami, un parent (vous pouvez leur offrir un 2ème disque dur pour vos backups), ou sur un hébergement ou serveur dédié extérieur.
Voilà, vous faites donc une copie de vos données sur le disque dur d’une 2ème machine « distante ». Vous êtes donc protégé… Et bien… oui, mais… pas toujours à 100% !

Cela dépend de votre méthode de backup.

copie manuelle :
- dépendant de votre régularité… ne pas oublier !
- la aussi vous pouvez faire des erreurs
copie automatique : une seule copie :
- automatique, pas de risque d’oublier
- risque si vous ne vous rendez pas compte immédiatement de la corruption ou perte d’un fichier : la copie automatique (à 23h par exemple) risque d’écraser l’unique sauvegarde de votre fichier.
copies multiples :
- net progrès, mais dépend du nombre de copies et de la durée de conservation
- garder un nombre élevé de version n’est pas la meilleure solution : ça prend beaucoup de place
programme et méthode de backup précise :
- automatique : pas de risque d’oublier
- conserve plusieures versions, éventuellement sur plusieurs mois ou même années : permet de retrouver un fichier même si on se rend compte du problème longtemps après
- on peut planifier ses backups sans que cela ne prenne nécessairement une place gigantesque : conserver 1 par nuit la première semaine, puis 1 par mois pendant 3 mois, et un dernier avec 1 an de recul
- gestion facile des méthodes de backup, complète ou incrémental, et de la compression : ce qui limite la place occupée

Et l’utilitaire miracle pour faire cela ?, qui plus est, gratuit et libre, et pouvant faire la sauvegarde aussi bien d’un PC Linux que d’un sous Windows ?

BackupPC :

libre et gratuit : Open Source et GPL
sauvegarde de PC clients Linux ou Windows
sauvegarde de PC clients locaux (Lan) ou distant (via Internet)
interface de gestion Web
compression
configuration du nombre de backups, fréquence, etc
sauvegarde complète et incrémentale
restore facile (… ce qui est important dans une situation critique de restoration d’un serveur par exemple)
sélection facile d’une version précise d’un fichier précis dans la liste des backups.
installation facile
besoin assez simple (serveur Linux, Apache…)

Mon prochain billet sera donc sur l’installation et la configuration de BackupPC

Faille OpenSSL : regénérer les clés SSH

Didier Misson — Thu, 15 May 2008 22:10:23 +0000

Avec cette faille OpenSSL connue de tous, il est urgent de corriger le problème, c’est à dire :

mettre à jour sa distribution Debian ou Ubuntu (ou autre dérivée de Debian)
regénérer les clés utilisées

Mettre à jour sa distribution, vous savez certainement tous le faire :

aptitude update

aptitude dist-upgrade

Éventuellement, ajoutez le sudo si vous êtes en Ubuntu.

La regénération des clés SSH est pourtant indispensable, car même avec les packages corrigés, les clés host restent celles qui avaient été générées à l’installation du serveur : elles sont donc faibles et crackables !

Avant de continuer, je rappelle que cette faille n’est pas due au package OpenSSL lui-même, mais à une modification du code source faite par un développeur Debian il y a déjà plus de 2 ans…

Cela n’enlève rien à la très grande qualité de cette distribution, les erreurs de ce genre étant rares, et encore plus rarement dues à l’équipe Debian elle-même. De plus, les failles de sécurité sont en général corrigées très rapidement.

En Ubuntu, distribution dérivée de Debian et incorporant le même bug, j’ai eu l’agréable surprise que celui-ci me regénère automatiquement les clés SSH. Après la mise à jour des packages et la regénération, je retrouve ceci :

$ cd /etc/ssh

$ ls -l

-rw-r--r-- 1 root root 2064867 2008-05-13 14:10 blacklist.DSA-1024

-rw-r--r-- 1 root root 2064867 2008-05-13 14:10 blacklist.RSA-2048

-rw-r--r-- 1 root root  132777 2007-10-05 00:52 moduli

-rw-r--r-- 1 root root    1532 2007-10-05 00:52 ssh_config

-rw-r--r-- 1 root root    1873 2007-11-13 00:25 sshd_config

-rw------- 1 root root     668 2008-05-14 00:41 ssh_host_dsa_key

-rw------- 1 root root     668 2007-11-11 05:25 ssh_host_dsa_key.broken

-rw-r--r-- 1 root root     603 2008-05-14 00:41 ssh_host_dsa_key.pub

-rw-r--r-- 1 root root     603 2007-11-11 05:25 ssh_host_dsa_key.pub.broken

-rw------- 1 root root    1675 2008-05-14 00:41 ssh_host_rsa_key

-rw------- 1 root root    1675 2007-11-11 05:25 ssh_host_rsa_key.broken

-rw-r--r-- 1 root root     395 2008-05-14 00:41 ssh_host_rsa_key.pub

-rw-r--r-- 1 root root     395 2007-11-11 05:25 ssh_host_rsa_key.pub.broken

Les anciennes clés non sécures ont été renomées « .broken » et de nouvelles clés ont été crées.

En Debian, j’ai eu droit à la mise à jour des packages, mais pas à la regénération des clés. Il faut donc les regénérer soi-même.

Ce billet de Jean-Christophe Dubacq donne la commande à passer pour regénérer ces clés.

Voici d’abord une explication détaillée pour bien comprendre la manipulation. Mais attention, ce n’est pas la façon de faire conseillée pour une machine distante !

# cd /etc/ssh

# mkdir backup

# mv ssh_host_* backup

# dpkg-reconfigure -plow openssh-server

Creating SSH2 RSA key; this may take some time ...

Creating SSH2 DSA key; this may take some time ...

Restarting OpenBSD Secure Shell server: sshd.

Vérifiez votre dossier :

# ls -l

drwxr-xr-x 2 root root    4096 2008-05-16 01:09 backup

-rw-r--r-- 1 root root 2064867 2008-05-13 16:23 blacklist.DSA-1024

-rw-r--r-- 1 root root 2064867 2008-05-13 16:23 blacklist.RSA-2048

-rw-r--r-- 1 root root  132777 2007-04-29 03:37 moduli

-rw-r--r-- 1 root root    1424 2007-04-29 03:37 ssh_config

-rw-r--r-- 1 root root    1749 2007-04-29 03:44 sshd_config

-rw------- 1 root root     672 2008-05-16 01:12 ssh_host_dsa_key

-rw-r--r-- 1 root root     603 2008-05-16 01:12 ssh_host_dsa_key.pub

-rw------- 1 root root    1675 2008-05-16 01:12 ssh_host_rsa_key

-rw-r--r-- 1 root root     395 2008-05-16 01:12 ssh_host_rsa_key.pub

Les nouvelles clés ont été générées. Ca devrait fonctionner.

AVANT de couper votre session SSH, vérifiez que tout est ok en établissant une 2ème session SSH depuis votre poste de travail :

didier@didier-desktop:~$ ssh 192.168.168.250

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

f3:17:1e:0f:6d:c8:6b:17:ca:98:d3:7a:55:58:f2:0c.

Please contact your system administrator.

Add correct host key in /home/didier/.ssh/known_hosts to get rid of this message.

Offending key in /home/didier/.ssh/known_hosts:4

RSA host key for 192.168.168.250 has changed and you have requested strict checking.

Host key verification failed.

La session est refusée et c’est NORMAL !

Votre client SSH vous protège ainsi et vous averti que la clé du serveur que vous contactez n’est plus la même. Il a raison: ce pourrait être une attaque pour capturer votre logon.

Mais ici bien évidemment, la situation est correcte puisque c’est vous même qui venez de changer la clé du serveur

Supprimez la clé du fichier known_hosts. Vous avez le numéro de la ligne a supprimer dans le message précédent (la clé 4 dans mon cas).

$ vi .ssh/known_hosts   (supprimer la ligne 4)

Je refais ma session SSH. Cette fois je peux l’établir après avoir reçu ce message de warning disant que cette machine est inconnue (puisque j’ai supprimé son ancienne clé du fichier known_hosts)

didier@didier-desktop:~$ ssh 192.168.168.250
The authenticity of host ’192.168.168.250 (192.168.168.250)’ can’t be established.
RSA key fingerprint is f3:17:1e:0f:6d:c8:6b:17:ca:98:d3:7a:55:58:f2:0c.
Are you sure you want to continue connecting (yes/no)? yes

Si vous essayez d’établir la connexion SSH depuis un poste Windows avec PuTTY, vous recevrez un message d’avertissement de ce genre :

Là aussi, c’est normal puisque vous avez vous-même changer la clé Host. Il suffit donc de cliquer sur « Yes ».

Voilà, cela fonctionne avec de nouvelles clés hosts. Votre machine est de nouveau sécure !

Il vous reste à supprimer le backup que nous avions fait. Il ne sert plus à rien.

La méthode fonctionne, mais je ne la conseille pas en tant que telle pour un serveur distant.

Pourquoi ?

Simplement car, même si le risque est faible, vous pouvez être déconnecté en cours d’opération. Un ADSL qui coupe, ça arrive… ou tout autre raison (un orage, une coupure de courant, un plantage de votre PC, les batteries de votre laptop vide ou votre fils de 3 ans qui se prend les pieds dans la prise…)

Si cette coupure arrive entre le déplacement ou la suppression de vos anciennes clés et la génération des nouvelles, votre serveur SSH n’aura plus aucune clé pour accepter une session SSH ! Ce serait pour le moins gênant de se retrouver avec le SSH en panne, sur un serveur à l’autre bout de la planète.

L’opération n’étant pas réellement compliquée, le mieux est de tout mettre sur une seule ligne de commande pour que le serveur exécute toutes les commandes à la suite. Même si vous êtes déconnecté en cours d’exécution, votre serveur terminera les commandes entrées et regénérera les clés

La commande donnée par Jean-Christophe est parfaite. Je ne vais pas me compliqué la vie à la réécrire

C’est donc simplement un delete (rm) des anciennes clés (sans backup, pas vraiment nécessaire) suivit ( ; ) directement de la regénération des clés :

rm /etc/ssh/ssh_host*key*;dpkg-reconfigure -plow openssh-server

Voilà, en une seule ligne, les nouvelles clés RSA et DSA sont générées.

Testez quand même une seconde session SSH avant de couper la première, mais ça devrait être bon, et sécure maintenant.

Merci à Jean-Christophe Dubacq pour « la-commande-qui-va-bien »

Debian : faille de sécurité dans OpenSSL

Didier Misson — Thu, 15 May 2008 14:41:19 +0000

Vous l’avez peut-être déjà lu, mais une faille de sécurité assez critique affecte OpenSSL dans les distributions Debian et dérivés (Ubuntu par exemple). OpenSSL est utilisé pour les connexions « sécurisées » en SSH et les certificats SSL des sites web. Ce sont les applications les plus connues, mais d’autres utilisent également OpenSSL, comme OpenVPN, IMAPS, POPS…

dessin en licence CC by nc du site Xkcd

Le problème, propre à la version inclue dans Debian, est que le générateur de nombre aléatoire utilisé pour générer la clé, n’est pas vraiment aléatoire… Pas aléatoire veut dire prédictible, c’est à dire qu’on peut trouver votre clé et entrer en SSH dans votre serveur ou se faire passer pour vous en générant un faux certificat SSL, etc…

Je ne vais pas tout réexpliquer en détail. Les articles suivants vous en disent un peu plus :

La première chose à faire est de mettre à jour sa distribution. Ainsi les modules corrigés seront installés :

aptitude update

aptitude dist-upgrade

Mais ce n’est PAS suffisant !

Les clés faibles (càd facilement crackables) sont encore utilisées sur votre machine.

Il est nécessaire de recréer ces clés !

La procédure varie suivant le programme en cause.

Je reviens sur cette regénération des clés dans mon prochain billet.

packages Debian / Ubuntu : APT-CACHER

Didier Misson — Tue, 18 Dec 2007 09:47:47 +0000

Lors d’une installation, ou pour les mises à jour, Debian et Ubuntu se connectent aux dépôts pour télécharger les paquets.

C’est facile et pratique si vous avez un ou deux PC.

Si vous en avez 4 ou 5, ou si vous devez régulièrement faire l’installation de PC clients, cela présente 3 inconvénients :

cela prend à chaque installation plusieurs centaines de MB, génant si vous avez un quota mensuel.
il faut être connecté… Ce qui peut poser des problèmes pour des Linux Copy Party dans des endroits sans connexion ou avec une connexion lente.
ça prend un certain temps… variable… suivant la vitesse de votre connexion et suivant que cette connexion est chargée ou pas (si vous êtes à plusieurs sur cette ligne, ou si quelqu’un fait du peer to peer, ça peut être lent)

APT-CACHER peut apporter une solution, ou une nette amélioration, à ces problèmes

Quel est le principe d’un proxy APT ? :

vous installez ce proxy APT sur un serveur, ou sur un de vos PC
c’est cette machine qui va chercher les paquets sur les dépôts Debian ou Ubuntu
vos PC clients sont configurés (sources.list) pour s’adresser, non pas aux dépôts habituels, mais à votre serveur apt-proxy
le proxy APT vérifie si le paquet demandé est dans son cache, et à jour, sinon il va le chercher dans les dépôts

L’intéret est double :

si vous faites plusieurs installations, les paquets restent en cache et ne sont téléchargés qu’une seule fois
si le paquet est déjà en cache, votre serveur vous l’envoie sur votre réseau local, nettement plus rapidement que via Internet

Donc, si vous faites des mises à jour ou des installations multiples, après la 1ère, les suivants seront bien plus rapides et sans consommer votre quota.

Plusieurs solutions existent pour faire un cache APT :

apt-proxy, le plus connu
approx, une amélioration de apt-proxy
apt-cacher, lui aussi une amélioration de apt-proxy
apt-cacher-ng, une réécriture de apt-cacher, mais qui n’est pas dans Ubuntu 7.10 ni Debian Etch, seulement dans les branches instables.
configurer un proxy HTTP normal tel que Squid

J’évite apt-proxy qui semble avoir quelques inconvénients, et apt-cacher-ng qui n’est pas encore inclu dans Debian et Ubuntu stable. J’évite aussi Squid.

Entre apt-cacher et approx, le choix n’est pas du tout évident ! Peu d’articles les comparent…

J’ai malgré tout trouvé cette page de Ealden Escañan, qui, si elle n’est pas récente, me semblait malgré tout intéressante.

Je choisi d’essayer apt-cacher, car il semble être plus simple dans sa configuration de base et il dispose de plus d’options.

L’article écrit par Jonathan Oxer DebianUniverse.com donne de bonnes explications sur l’installation de APT-CACHER.

Comment installer APT-CACHER ?

Comme souvent, il existe déjà un paquet aussi bien en Debian qu’en Ubuntu.
L’installation est classique.

$ sudo aptitude install apt-cacher Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Lecture de l'information d'état étendu Initialisation de l'état des paquets... Fait Construction de la base de données des étiquettes... Fait Les NOUVEAUX paquets suivants vont être installés :   apt-cacher 0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 61,2ko d'archives. Après dépaquetage, 291ko seront utilisés. Écriture de l'information d'état étendu... Fait Prendre :1 http://be.archive.ubuntu.com gutsy/universe apt-cacher 1.5.3 [61,2kB] 61,2ko téléchargés en 0s (278ko/s) Sélection du paquet apt-cacher précédemment désélectionné. (Lecture de la base de données... 22754 fichiers et répertoires déjà installés.) Dépaquetage de apt-cacher (à partir de .../apt-cacher_1.5.3_all.deb) ... Paramétrage de apt-cacher (1.5.3) ... Running apt-cacher's install script... Assuming www-data is the user ID used to run apt-cacher Doing mkdir(/var/cache/apt-cacher, 0755) Doing mkdir(/var/log/apt-cacher, 0755) Doing mkdir(/var/cache/apt-cacher/private, 0755) Doing mkdir(/var/cache/apt-cacher/import, 0755) Doing mkdir(/var/cache/apt-cacher/packages, 0755) Doing mkdir(/var/cache/apt-cacher/headers, 0755) Doing mkdir(/var/cache/apt-cacher/temp, 0755) Starting Apt-Cacher: apt-cacher (not enabled in /etc/default/apt-cacher). ...

Par défaut, apt-cacher n’est pas démarré.
Pour le démarrer automatiquement au reboot, il faut modifier une variable dans :

$ sudo vi /etc/default/apt-cacher

# apt-cacher startup configuration file # IMPORTANT: check the apt-cacher.conf file before using apt-cacher as daemon. # set to 1 to start the daemon at boot time AUTOSTART=1 # extra settings to override the ones in apt-cacher.conf # EXTRAOPT=" daemon_port=3142 limit=30 "

Le fichier de configuration de apt-cacher se trouve dans /etc/apt-cacher (original non ?)

$ cd /etc/apt-cacher/ $ ls -l -rw-r--r-- 1 root root  212 2006-06-22 05:42 apache.conf -rw-r--r-- 1 root root 6851 2006-06-22 05:42 apt-cacher.conf -rw-r--r-- 1 root root  357 2006-06-22 05:42 checksumming.conf

apt-cacher peut fonctionner en mode autonome (daemon) ou dans Apache.
Le mieux est de conserver la configuration le faisant tourner en daemon.

Je n’active pas le « checksumming » pour le moment.

Vérifions la configuration :

$ sudo vi /etc/apt-cacher/apt-cacher.conf

Vérifions quelques lignes :

################################################################# # This is the config file for apt-cacher. On most Debian systems # you can safely leave the defaults alone. ################################################################# # cache_dir is used to set the location of the local cache. This can # become quite large, so make sure it is somewhere with plenty of space. cache_dir=/var/cache/apt-cacher

Aucune raison de changer ce dossier.

# The email address of the administrator is displayed in the info page # and traffic reports. admin_email=root@localhost

Ce n’est pas fondamental si ce serveur est uniquement accessible sur votre réseau local, mais vous pouvez y mettre votre adresse mail, ou celle du Webmaster.

# For the daemon startup settings please edit the file /etc/default/apt-cacher.

C’est déjà activé.

# Daemon port setting, only useful in stand-alone mode. You need to run the # daemon as root to use privileged ports (<1024). daemon_port=3142

Le port par défaut est le 3142, ce qui me convient très bien.

# optional settings, user and group to run the daemon as. Make sure they have # sufficient permissions on the cache and log directories. Comment the settings # to run apt-cacher as the native user. group=www-data user=www-data

« www-data » est le userid utilisé par Apache. Nous pouvons conserver « www-data » pour apt-cacher.

# Apt-cacher can generate usage reports every 24 hours if you set this # directive to 1. You can view the reports in a web browser by pointing # to your cache machine with '/apt-cacher/report' on the end, like this: #      http://yourcache.example.com/apt-cacher/report # Generating reports is very fast even with many thousands of logfile # lines, so you can safely turn this on without creating much # additional system load. generate_reports=1

C’est toujours intéressant d’avoir un rapport.
Nous verrons plus tard comment y accéder.

# Use of an external proxy can be turned on or off with this flag. # Value should be either 0 (off) or 1 (on). use_proxy=0 use_proxy_auth=0

Le proxy ici est pour passer à travers un éventuel serveur Proxy.
Par exemple, certaines configurations en entreprises interdisent la sortie sur le Net sauf en passant via un Proxy qui sert alors aussi souvent de filtre pour interdire certaines sites web, et d’anti-virus.
Ce n’est pas notre cas.

Ok, le proxy apt-cacher est presque prêt à être utilisé…

Presque… car son cache est vide !

Si je ne fais rien, ce cache se remplira et tout fonctionnera correctement.
Mais j’ai déjà, à la fois sur le serveur Ubuntu, et sur mon laptop, fait l’installation et des mises à jour.
Des packages ont déjà été téléchargé…
Pourquoi les télécharger à nouveau lors de la prochaine installation ?

Avec APT-CACHER, l’importation de packages existants est assez simple.

Recopier les packages existants depuis le cache APT existant sur votre PC ou votre serveur :

Depuis votre Desktop ou Laptop, pour avoir préchargés tous les packages d’une station de travail (Gnome, Firefox, OOo…), avec un moyen que vous maitrisez (scp, ftp, samba, etc).
Dans mon cas, cela fait 155 paquets et un total de 168 MB (ça représente les mises à jour depuis l’installation depuis le CDR Ubntun 7.10)

Depuis le cache de votre serveur pour avoir en cache tous les packages serveur du genre LAMP, Bind, etc :

$ sudo cp /var/cache/apt/archives/*  /var/cache/apt-cacher/import/

La taille du dossier /var/cache/apt-cacher/import/ est maintenant de 280 MB. Pour inclure ces paquets dans le cache de apt-cacher, il faut entrer la commande :

$ sudo /usr/share/apt-cacher/apt-cacher-import.pl No import directory specified as the first argument, using /var/cache/apt-cacher/import Importing: adduser_3.103ubuntu1_all.deb Importing: alsa-base_1.0.14-1ubuntu2_all.deb Importing: alsa-utils_1.0.14-1ubuntu4_i386.deb Importing: apt-cacher_1.5.3_all.deb Importing: apt-utils_0.7.6ubuntu14_i386.deb Importing: apt_0.7.6ubuntu14_i386.deb Importing: aptitude_0.4.6.1-1ubuntu3_i386.deb ... Importing: wireless-tools_29~pre20-1ubuntu1_i386.deb Importing: wpasupplicant_0.6.0+0.5.8-0ubuntu1_i386.deb Importing: x11-common_7.2-5ubuntu13_i386.deb Importing: xkb-data_0.9-4ubuntu3_all.deb Importing: zlib1g_1.2.3.3.dfsg-5ubuntu2_i386.deb Done. Packages imported: 348

Nous pouvons démarrer apt-cacher.

$ sudo /etc/init.d/apt-cacher start Starting Apt-Cacher: apt-cacher.

La tâche est bien en machine, et si j’essaye un telnet sur le port 3142 depuis un autre PC, le serveur répond.

$ telnet 192.168.168.251 3142 Trying 192.168.168.251... Connected to 192.168.168.251. Escape character is '^]'. help HTTP/1.1 403 Could not understand help Connection closed by foreign host.

Le serveur est là et répond.

Vous auriez pu aussi, simplement, y accéder avec votre navigateur préféré sur le port 3142 :

http://192.168.1.100:3142/

ou par :

http://192.168.1.100/apt-cacher/

et… surprise… vous voyez là le rapport de fonctionnement de apt-cacher.

Il reste à modifier le fonctionnement de l’ APT standard, pour passer via le proxy apt-cacher.

Rien n’empêche de configurer le serveur lui-même de cette façon.
Comme cela, ses propres mises à jour participeront aussi au remplissage du cache du proxy, et consommeront moins de bande passante.

$ sudo vi /etc/apt/sources.list

Pour faire passer les accès aux dépôts par le proxy apt-cacher, il suffit de faire précéder les références des dépôts HTTP par « ip-adresse:3142″ (ou le nom de votre serveur si vous avez un DNS sur votre Lan) :

deb http://be.archive.ubuntu.com/ubuntu/ gutsy main restricted deb-src http://be.archive.ubuntu.com/ubuntu/ gutsy main restricted

Utilisez une commande change en VI du genre : :%s!be.archive.!127.0.0.1/apt-cacher/be.archive.!g Si vous utilisez un autre éditeur, changer la commande en fonction, ou éditer manuellement les lignes.

Vous devez ajouter en début des lignes http : « 127.0.0.1/apt-cacher » ou « 127.0.0.1:3142″ Cela donne des lignes du genre :

deb http://127.0.0.1/apt-cacher/be.archive.ubuntu.com/ubuntu/ gutsy main restricted deb-src http://127.0.0.1/apt-cacher/be.archive.ubuntu.com/ubuntu/ gutsy main restricted

Ne pas oublier les dépôts « security » :

:%s!security.ubuntu!127.0.0.1/apt-cacher/security.ubuntu!g

 deb http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security main restricted deb-src http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security main restricted deb http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security universe deb-src http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security universe deb http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security multiverse deb-src http://127.0.0.1/apt-cacher/security.ubuntu.com/ubuntu gutsy-security multiverse

Pour un autre PC, il faut évidemment spécifier l’adresse IP ou le nom de votre serveur et pas 127.0.0.1

deb http://192.168.1.100/apt-cacher/be.archive.ubuntu.com/pub/ubuntu.com/ubuntu/ gutsy main restricted universe multiverse deb-src http://192.168.1.100/apt-cacher/be.archive.ubuntu.com/pub/ubuntu.com/ubuntu/ gutsy main restricted universe multiverse

Ensuite, tout devrait aller comme d’habitude :

$ sudo aptitude update [sudo] password for didier: Prendre :1 http://127.0.0.1 gutsy Release.gpg [191B] Ign http://127.0.0.1 gutsy/main Translation-fr Ign http://127.0.0.1 gutsy/restricted Translation-fr Ign http://127.0.0.1 gutsy/universe Translation-fr Ign http://127.0.0.1 gutsy/multiverse Translation-fr Prendre :2 http://127.0.0.1 gutsy-updates Release.gpg [191B] Ign http://127.0.0.1 gutsy-updates/main Translation-fr ...

J’ai essayé « sudo aptitude dist-upgrade » … mais mon système était déjà à jour.
Ce sera pour une prochaine fois
et de toute façon, j’ai un PC à réinstaller et 2 autres en Ubuntu 6.10 à upgrader.

Je viens de réinstaller un PC en Ubuntu 7.10.

En fin d’installation, AVANT le reboot, j’ai modifié le fichier /etc/apt/sources.list

Attention, on est encore sur le Live-CD. Il faut pointer vers target.

J’ai fait un remplacement en VI :

sudo vi /target/etc/fstab

:%s!http://!http://192.168.1.100/apt-cacher/!g

Et j’ai seulement rebooté ensuite

Je n’ai pas vraiment gagné de temps, mais c’est la première installation que je fais depuis que j’ai activé apt-cacher, donc probablement que très peu de paquets étaient déjà en cache.

Par contre, je viens sur un autre PC d’installer VIM.
Je l’avais déjà installé avant sur le PC que je venais de réinstaller…

Et bien, là, la différence est flagrante :

sudo aptitude install gim ... Prendre :1 http://192.168.1.100 gusty/main vim-runtime 1:7.1-0.56+2ubuntu2 [5471kB] Prendre :1 http://192.168.1.100 gusty/main vim 1:7.1-0.56+2ubuntu2 [746kB] téléchargés en 1 s (5194ko/s)

Joli !
Ce sont des KBytes, donc ça fait plus de 41 Mbits / sec…

Comparé à mon ADSL qui est en 6400 Kbits / sec (vitesse physique ATM, en vitesse « data », c’est moins)

Je vais dans les prochains jours encore réinstaller un autre PC Ubuntu.
Je mettrai à jour ce billet pour indiquer mes impressions niveau vitesse

Mise à jour le 22 décembre 2007 : Pour le moment, tout se passe normalement.
Mon desktop Ubuntu 7.10 détecte automatiquement et installe correctement les mises à jour.