# [openvz] update udev et devtmpfs

## chris972

Bonjour,

J'ai un serveur avec gentoo légèrement pas à jour (juste quelques petits mois). Et je sais (suite à maj sur d'autres machines) que lorsque je vais lancer la mise à jour, et que udev va passer, au prochain boot, il va gueuler si je n'ai pas DEVTMPFS activé dans le noyau.

Or, j'ai un noyau OpenVZ qui ne comporte pas cette option (elle a volontairement été virée par les dev openvz car elle ferait très mauvais ménage avec vz, selon le résultat de mes recherches).

Il me reste donc comme solution :

- ne pas utiliser openvz, mais bon, ça serait embêtant pour moi.

- ne pas mettre à jour udev, mais j'imagine que je vais vite être bloqué dans les mises à jour du reste

- ne plus mettre à jour ma machine, et là, ça serait vite une catastrophe.

- LA SUPERBE IDÉE QUE VOUS ALLEZ ME SUGGÉRER

Merci d'avance.

----------

## GentooUser@Clubic

Salut,

Tu as quoi comme dépendances explicites à udev (equery depends udev) sans moyen de virer l'useflag ? Normalement sur un serveur pas grand-chose.

Si la réponse est rien tu peux virer l'useflag "udev", ajouter l'useflag "build" à ton noyau (sinon il dépend de virtual/dev-manager), et bloquer la MàJ de udev ou passer à un /dev statique sans problème.

Sinon demander aux devs d'OpenVZ, y'a 4 "dev-manager" dynamiques sous linux et ils dépendent tous de DEVTMPFS, leur position est intenable.

EDIT: Le noyau openvz pour RHEL6 contient DEVTMPFS http://wiki.openvz.org/Download/kernel/rhel6/042stab072.10 en plus il est juste au dessus de la version minimale requise par eudev, y'a surement moyen de l'utiliser en attendant.

----------

## chris972

Tout d'abord, merci pour ta réponse et le mal que tu sembles t'être donné pour t'informer sur le sujet, à moins que tu ne le maitrises déjà.

 *GentooUser@Clubic wrote:*   

> Salut,
> 
> Tu as quoi comme dépendances explicites à udev (equery depends udev) sans moyen de virer l'useflag ? Normalement sur un serveur pas grand-chose.

 

Bon, serveur oui, mais serveur perso, donc contient énormément de petites choses plus ou moins utiles. Pas dans l'optique serveur pro qui contient le minimum.

```
equery depends udev

 * These packages depend on udev:

net-print/hplip-3.12.10a (kernel_linux ? virtual/udev)

sys-apps/util-linux-2.21.2 (udev ? virtual/udev)

sys-power/nut-2.6.3 (virtual/udev)

virtual/dev-manager-0 (virtual/udev)
```

 *Quote:*   

> Si la réponse est rien tu peux virer l'useflag "udev", ajouter l'useflag "build" à ton noyau (sinon il dépend de virtual/dev-manager), et bloquer la MàJ de udev ou passer à un /dev statique sans problème.

 

J'attends tes suggestions en rapport avec le résultat plus haut.

 *Quote:*   

> Sinon demander aux devs d'OpenVZ, y'a 4 "dev-manager" dynamiques sous linux et ils dépendent tous de DEVTMPFS, leur position est intenable.

  j'ai vu que je ne suis pas le seul dans cette situation, mais n'ai vu aucune solution.

 *Quote:*   

> EDIT: Le noyau openvz pour RHEL6 contient DEVTMPFS http://wiki.openvz.org/Download/kernel/rhel6/042stab072.10 en plus il est juste au dessus de la version minimale requise par eudev, y'a surement moyen de l'utiliser en attendant.

 

Et donc sortir du openvz-sources ? J'ai pas encore étudié le lien, mais c'est un binaire ?

Parce que sinon https://forums.gentoo.org/viewtopic-t-877405.html#6704051 indique comment "rajouter" l'option DEVTMPSFS au noyau qui ne l'a pas, mais semble émettre des doutes sur la fiabilité.

Si cette solution suffit, elle me conviendra parfaitement, en attendant un noyau officiel incorporant devtmpfs

----------

## GentooUser@Clubic

Tu a en effet deux paquets qui dépendent impérativement de udev, mais sans version minimum, tu doit donc pouvoir MàJ en restant pour l’instant sur virtual/udev-171

Concernant le noyau RHEL, normalement ça boot sans problème, faut juste avoir 3 choses : le noyau, son initrd, et le /lib/module/<kernel_version> correspondant. Sinon t'a le patch à appliquer au vanilla-sources-2.6.32 aussi sur la page.

----------

## chris972

Je n'ai pas répondu, non pas que je ne fasse pas cas de ta réponse, bien au contraire, mais parce que justement, je suis dessus, j'en ai tenu compte, et je regarde comment je m'en sors avant de revenir rendre compte.

Merci encore.

----------

## lmarcini

 *chris972 wrote:*   

> - ne pas utiliser openvz, mais bon, ça serait embêtant pour moi.

 

Et pourquoi pas LXC ? Changer serait embêtant à court terme mais l'avenir est plus à LXC qu'à OpenVZ...

----------

## xaviermiller

Pour ma part, je préconiserais plutôt de bloquer les nouvelles versions de UDEV jusqu'au moment où ce qu'il faut est implémenté en openvz.

----------

## El_Goretto

 *lmarcini wrote:*   

> Et pourquoi pas LXC ? Changer serait embêtant à court terme mais l'avenir est plus à LXC qu'à OpenVZ...

 

Tant que LXC n'est pas complètement implémenté, c'est plus dangereux qu'autre chose (faux sentiment de "sécurité").

----------

## lmarcini

Comment cela pas complètement implémenté ? Les cgroups sont natifs depuis belle lurette. Les outils d'admin ne sont pas encore au niveau de ceux d'OpenVZ mais, en attendant que cela arrive, rien d'empêche de se créer des scripts "ad minima". 

Et puis concernant la sécurité (ou fausse sécurité), c'est discutable. Les patches OpenVZ sont valables pour des noyaux 2.32  (et encore sur des RHEL). Sur un noyau stable de la branche 3, une solution "upstream" me semble plus sûre qu'un patch...

Et question stabilité, LXC me semble plus robuste qu'OpenVZ (expérience basée sur la quinzaine de containers que je gère à titre professionnel et que j'ai migré d'OpenVZ à LXC en 2012). OpenVZ était la meilleure solution il y a 2/3 ans mais son intégration au noyau n'est pas tip-top(*).

Laurent.

(*) Je ne vais pas raconter ma vie mais professionnellement, j'utilisais des Debian Squeeze avec le noyau en saveur "openvz" en 2.6.32 ... Au gré des mises-à-jour de sécurité du noyau, j'ai eu de plus en plus d'effets de bord sur mes containers OpenVZ. Mauvaise intégration par Debian ? Possible. Des tests avec une solution "porcine", à savoir un méchant "alien" sur le kernel RHEL-OpenVZ a résolu certains problèmes mais en a créé d'autres. Depuis que suis passé à un noyau backporté 3.2 (avec LXC backporté également), je n'ai plus aucun souci de stabilité des containers et de performances...

----------

## chris972

 *XavierMiller wrote:*   

> Pour ma part, je préconiserais plutôt de bloquer les nouvelles versions de UDEV jusqu'au moment où ce qu'il faut est implémenté en openvz.

 

A part qu'absolument rien ne laisse envisager à l'heure actuelle que la situation ait une chance d'évoluer dans ce sens côté openvz...

Pour la solution LXC, j'avoue que openvz me convient très bien pour ce que je fais. Y passer serait quand même un changement radical qui ne me tente guère. Même si force est de constater que c'est une solution, pour l'instant, elle ne m'attire pas.

----------

## El_Goretto

lmarcini: pour faire court, LXC n'est pas complètement implémenté, dans le sens où l'isolation n'est pas complète (cf http://en.gentoo-wiki.com/wiki/LXC#MAJOR_Temporary_Problems_with_LXC_-_READ_THIS)

Ça fait des années que c'est comme çà, et cela rend le projet non viable à mes yeux tant que ce trou béant côté "implémentation" n'est pas colmaté.

Fin du OFF, et des "à mon sens/à mes yeux"  :Wink: 

----------

## PabOu

Salut,

J'ai plusieurs containers sous Gentoo, j'ai simplement désactivé l'utilisation de udev, je gère le /dev manuellement.

Ça se fait dans /etc/conf.d/rc : RC_DEVICES="static".

Il y a aussi une option dans /etc/rc : rc_sys="openvz" (mais je ne pense pas qu'elle soit nécessaire pour /dev)

----------

## chris972

Pour l'instant, j'en suis au blocage de udev-197 (ce qui ne pourra sans doute pas durer éternellement). Et je conserve mon noyau actuel vu qu'aucun openvz-sources plus récent ne compile sur ma machine (bug signalé depuis des mois).

Je vais voir comment tout ça évolue pour voir quelle direction prendre.

Merci à tous.

----------

