Debian offre les aussi la possibilité d'installer un chroot de
n'importe quelle version de Debian sur le même serveur en une
seule ligne de commande, ce qui est très pratique pour faire
tourner de vieux programmes sur un serveur récent.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Les changements de version Debian sont simples.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
A long-running problem in Debian is that several of our core teams are severely under-staffed.
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
par contre aucuns de nos serveurs CentOS 5 n'a été migré en 6
ou en 7.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 7.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Malgré ce qu'on croit, l'userspace est pas 100% indépendant du kernel http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
Mais voila, ça reste couteux en ressources. Le DPL dit d'ailleurs dans une interview ( http://www.itwire.com/business-it-news/open-source/67512-surviving-systemd-lucas-nussbaum-satisfied-with-init-system-outcome ) :
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?