Difference between revisions of "From Lenny kernel to Ben Green kernel/fr"

From Linux-VServer

Jump to: navigation, search
(Document changing VServer Kernel from Lenny 2.6.26 to Beng 2.6.31)
 
Line 103: Line 103:
  
 
: C'est un des problèmes qui affectent le 2.6.26 de Lenny.
 
: C'est un des problèmes qui affectent le 2.6.26 de Lenny.
 +
 +
* redémarrer les VServers actifs sur la machine :
 +
 +
~# for vs in $(ls -1 /srv/vservers)
 +
do
 +
vserver $vs restart
 +
done
 +
 +
(C'est ls -1 (un), pas -l (la lettre « -l »)
  
 
== Merci qui ? ==
 
== Merci qui ? ==

Revision as of 20:30, 9 April 2010

Contents

Changer de kernel VServer

La Debian Lenny fournit le 2.6.26, qu'il vaut mieux éviter « For your own good » (« pour votre propre bien »), selon Bertl. (Voyez Installation_on_Debian#Issues_with_the_current_2.6.26_Kernel pour les problèmes qui l'affectent.)

Alternative(s)

Une des possibilités qui s'offre aux debianistes est d'installer le kernel VServer 2.6.31.12 ou 2.6.33.1 de Ben Green.

C'est un kernel fourni en paquet .deb et debianisé en ce sens qu'il est compilé à la manière Debian, et à partir d'un '.config' Debian. La plupart des options sont compilées sous forme de modules chargeables (autant que possible) et un paquet .deb source est également fourni pour le cas où une compilation perso s'avérerait nécessaire.

Ben recommande :

  • d'utiliser le 2.6.31.12 en production, le patch VServer étant trop vieux dans le 2.6.33 ;
  • d'installer le méta-paquet 'linux-image-vserver-2.6.31-beng', dépendant toujours du dernier 2.6.31 compilé et dont il déclenchera l'installation lorsqu'il est mis à jour.

Petit disclaimer cependant :

  • l'installation se fait, comme d'usage, aux risques et périls exclusifs de l'utilisateur : ce kernel, bien qu'indiscutablement plus indiqué sous l'angle VServer, pourrait ne pas être aussi stable qu'un kernel Debian d'origine ;
  • il ne faudra donc pas assigner l'auteur, ou Ben, en cas de problème ;

Cela étant, ces kernels tournent en prod sur plusieurs serveurs, sans que des problèmes graves n'aient été rapportés.

Où trouver un autre kernel convenable ?

Ici : http://kernels.bristolwireless.net/, en ajoutant la ligne suivante dans /etc/apt/source.list, ou dans un source list dédié :

~# cat << EOF >> /etc/apt/sources.list.d/psand-vserver.list
deb http://repo.psand.net/ lenny main
EOF

Une installation habituelle s'effectura après sélection du paquet.

Que faire ensuite ?

Avant de rebooter, il faudrait :

  • installer aussi le paquet util-vserver présent dans le même dépôt. Prendre util-vserver-basic-debian (et non '-basic' tout court) si on upgrade un kernel Debian d'origine ;
  • s'assurer que make est installée sur la machine (le paquet util-vserver dont question ci-dessus ne déclare pas de dépendance sur make, mais il en a besoin au lancement des VServers) ;
  • changer le lien symbolique /etc/vservers/.default/vdirbase : (il pointe sur /var/lib/vservers par défaut) :
~# cd /etc/vservers/.default
~# rm vdirbase
~# ln -s /srv/vservers vdirbase

On peut ensuite rebooter la machine, qui devrait normalement démarrer les VServers existants.

Il reste ensuite quelques petites choses à faire pour rendre le système pleinement opérationnel :

  • vérifier et fixer la chroot barrier :
1. vérifier :
portalis:~# showattr /srv/
----buic- /srv/
----buic- /srv/kvm
----buic- /srv/lost+found
----Buic- /srv/vservers
2. fixer, si on n'a pas le « B » (majuscule --- en miniscule, il signifie que la barrière est plaçable, mais actuellement non placée)  :
~# setattr --barrier /srv/vservers

Si tous les VServers sont sous une seule arborescence dédiée (ici /srv/vservers), placer la barrière uniquement sur le parent de leur répertoire est suffisant. Sinon, il faut répéter l'opération.

  • repositionner le flag iunlink sur les fichiers hashifiés !
1. vérifier :
~# find /srv/vservers/.hash -type f

-----UIC- /srv/vservers/.hash/dd/76 /a83691887d3cd1fddcc6dcab2d5c7b8ee273-00000000
[...]
2. fixer, si on n'a pas le « U » (majuscule). Il y aura un « u » (miniscule), qui signie flag dispo, mais pas mis :
~# find /srv/vservers/.hash -type f -exec setattr --iunlink {} \;

(N.B. cette commande est suggérée dans la FAQ sous réserve de vérification. C'est fait, et elle fonctionne).

  • retirer les fichiers hashifiés inutiles (cad. qui n'ont qu'1 seul lien, ce qui signifie qu'ils n'existent que dans le hash, sans être liés à aucun VServer) :
1. commande :
~# find /srv/vservers/.hash -type f -print0 | xargs -0 -rm
2. NB très important : sans repositionner iunlink, il est impossible de faire des mises à jour des VServers : on ne sait pas remplacer les fichiers à modifier car les liens ne "cassent" pas comme ils devraient.
C'est un des problèmes qui affectent le 2.6.26 de Lenny.
  • redémarrer les VServers actifs sur la machine :
~# for vs in $(ls -1 /srv/vservers)
do
vserver $vs restart
done

(C'est ls -1 (un), pas -l (la lettre « -l »)

Merci qui ?

  • aux développeurs, pour VServer ;
  • à BenG, pour ses kernels ;
  • à l'auteur du paquet vserver-util-basic-debian (Ghislain, je crois ?)

(jfs)

Personal tools