Salut Je viens de recevoir une pré annonce sur la liste sécurité debian (que certains suivent, je pense) Le support régulier debian V6 s'arrête fin du mois, mais la distri va recevoir un support type LTS jusque février 2016. Annonce initiale sur https://lists.debian.org/debian-devel-announce/2014/03/msg00004.html Les détails sont à suivre mais y'a déjà quelques Q/R : - différence entre "support régulier" et "LTS" : LTS ne sera que pour i386 et amd64, et certains packages ne seront plus supportés. - il est possible que debian 7/8 suivent le même chemin de LTS (mais à voir) - le projet cherche de l'aide puisque la version LTS est suivie par une équipe différente de la sécurity team habituelle. Voilà Manu
Pourquoi ne pas simplement prolonger la période oldstable? Si la securityteam n'est plus sur Squeeze il devient important de migrer. De notre côté tout est déjà organisé, on s'est laissé un an pour migrer les 6 vers 7, il reste que quelques serveurs à gérer en attente de retour client. Squeeze a bien vécu, si on commence à ralonger les durées de vie, autant reporter les prochains freeze.
Le Thursday 17 Apr 2014 à 16:49:28 (+0200), Wallace a écrit :
Pourquoi ne pas simplement prolonger la période oldstable? Si la securityteam n'est plus sur Squeeze il devient important de migrer.
De notre côté tout est déjà organisé, on s'est laissé un an pour migrer les 6 vers 7, il reste que quelques serveurs à gérer en attente de retour client. Squeeze a bien vécu, si on commence à ralonger les durées de vie, autant reporter les prochains freeze.
Je pense qu'une liste de discussion debian serait plus appropriée pour troller sur la politique de la distribution. -- "My father rode a camel, I drive a Mercedes, and my son drives a Land Rover. My grandson will drive a Land Rover, but his son will ride a camel." Sheikh Rashid bin Saeed al Maktoum, Emir of Dubai 1958-1990
Non mais *de base* il est important de migrer, quand l'OS deviens oldstable. C'est comme les gérants de McDo qui font tourner du DOS parce que leur soft de compta date du siècle dernier (ça fais déjà 14 ans les gens !). Le 17/04/2014 16:49, Wallace a écrit :
Pourquoi ne pas simplement prolonger la période oldstable? Si la securityteam n'est plus sur Squeeze il devient important de migrer.
Le 17/04/2014 17:00, Edelwin Khaelos a écrit :
Non mais *de base* il est important de migrer, quand l'OS deviens oldstable. On est bien d'accord oldstable c'est censé laisser un délai pour ceux qui veulent pas se jeter tout de suite sur la nouvelle stable ou qui ont des clients avec des délais. 1 an après la sortie d'une nouvelle stable cela me semble suffisant mais faut croire que non pour certains.
Le 17/04/2014 18:10, Wallace a écrit :
Le 17/04/2014 17:00, Edelwin Khaelos a écrit :
Non mais *de base* il est important de migrer, quand l'OS deviens oldstable. On est bien d'accord oldstable c'est censé laisser un délai pour ceux qui veulent pas se jeter tout de suite sur la nouvelle stable ou qui ont des clients avec des délais. 1 an après la sortie d'une nouvelle stable cela me semble suffisant mais faut croire que non pour certains.
Non, on n'est pas d'accord. Je considère que le passage à oldstable est le signal d'alarme pour se mettre à jour. On n'est pas dans une logique Windows, y'a quand même une certaine continuité dans les version des OS tels que Debian, et à partir du moment où la continuité n'est plus assurée pour l'usage qu'on a de cet OS (prod, donc), on met en place des infras de test et d'expérimentation. Et ça veut pas dire louer une baie à TH2, avec la virtu de nos jours, un coup de LXC/KVM/whatever suffit... Et on ne s'y prend pas au dernier moment, faut être proactif merde !
Le 17/04/2014 18:18, Edelwin Khaelos a écrit :
Non, on n'est pas d'accord. Je considère que le passage à oldstable est le signal d'alarme pour se mettre à jour. On n'est pas dans une logique Windows, y'a quand même une certaine continuité dans les version des OS tels que Debian, et à partir du moment où la continuité n'est plus assurée pour l'usage qu'on a de cet OS (prod, donc), on met en place des infras de test et d'expérimentation. Et ça veut pas dire louer une baie à TH2, avec la virtu de nos jours, un coup de LXC/KVM/whatever suffit... Et on ne s'y prend pas au dernier moment, faut être proactif merde !
Pas obligé de s'énerver! Passer de suite à la nouvelle stable apporte toujours son lot de soucis notamment dans les scripts de mises à jours des packages. Attendre 3/4 mois me semble pas inconsidéré surtout que oldstable est toujours maintenue. Par contre toutes les nouvelles installations se font en stable depuis sa sortie. Pour les clients y a des évolutions du système qui sont bloquants, quand Debian considère que php 5.4 doit être présent en stable, nos clients sont informés de ce changement en amont mais de leur côté avec leur webagency il faut faire des changements et tester / valider. Même un an c'est trop court pour certains, par contre avec l'arrivée en fin de vie de oldstable on met un coup de pression tout simple, l'upgrade reste inclus dans l'infogérance tant qu'on supporte oldstable, quand oldstable n'est plus supporté (je ne parle pas de cette nouveauté de LTS soit en mai prochain) on considère que la mise à niveau est un nouveau projet donc facturé. J'ai des clients qui sont en test sur Debian 7 depuis des mois sur les infras de recette et qui ont pas finis de développer, à l'opposé j'ai des clients avec juste un serveur qui ne veulent pas de second serveur même pour 1 mois et qui disent faites la mise à jour on corrigera si y a des soucis. Bref on s'adapte aux clients en fonction des rythmes de Debian. Si LTS se fait les gens n'auront plus la pression pour migrer ce qui est en corrélation aussi avec les mises à jour de leurs applicatifs donc risque accrue de soucis et travail trop important quand il faudra se mettre à jour. Enfin bien sur c'est mon point de vue.
Le 17/04/2014 19:36, Wallace a écrit :
[...] par contre avec l'arrivée en fin de vie de oldstable on met un coup de pression tout simple, l'upgrade reste inclus dans l'infogérance tant qu'on supporte oldstable, quand oldstable n'est plus supporté (je ne parle pas de cette nouveauté de LTS soit en mai prochain) on considère que la mise à niveau est un nouveau projet donc facturé.
Là je suis d'accord avec toi pour dire que se mettre dans la seringue, c'est un bon motivateur pour amorcer des upgrades, même si le faire dans la panique/précipitation est vraiment assez moyen quand on a une réputation de boulot fiable et sérieux à tenir. Après, on peut avoir une politique système qui dit de se préparer continuellement aux nouvelles versions à venir, le « toujours prêt ! » de nos fiers scouts de l'admin sys.
Le 17/04/2014 19:36, Wallace a écrit :
Pour les clients y a des évolutions du système qui sont bloquants
Oui, en fait c'est ça que je cherche un peu à comprendre. Car si Debian se lance dans le LTS, si Ubuntu fait déjà, si des entreprises payent microsoft pour avoir un support post-EOL de XP.. c'est qu'il y sûrement un besoin, mais je ne l'ai jamais rencontré, donc je m'interroge un peu ..
Le Fri, 18 Apr 2014 10:20:18 +0200, Manu <manu@formidable-inc.net> a écrit :
Le 17/04/2014 19:36, Wallace a écrit :
Pour les clients y a des évolutions du système qui sont bloquants
Oui, en fait c'est ça que je cherche un peu à comprendre. Car si Debian se lance dans le LTS, si Ubuntu fait déjà, si des entreprises payent microsoft pour avoir un support post-EOL de XP.. c'est qu'il y sûrement un besoin, mais je ne l'ai jamais rencontré, donc je m'interroge un peu ..
Tu n'as jamais rencontré le cas d'un client développeur qui te fais monter une machine avec des services absolument pas à jour, genre des tomcat 5, des php 4... parce qu'ils ne veulent pas corriger leurs devs pour les rendre compatible avec les versions modernes ? Heureux homme.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello, Le 18 avr. 2014 à 10:27, Julien Gormotte <julien@gormotte.info> a écrit :
Le Fri, 18 Apr 2014 10:20:18 +0200, Manu <manu@formidable-inc.net> a écrit :
Le 17/04/2014 19:36, Wallace a écrit :
Pour les clients y a des évolutions du système qui sont bloquants
Oui, en fait c'est ça que je cherche un peu à comprendre. Car si Debian se lance dans le LTS, si Ubuntu fait déjà, si des entreprises payent microsoft pour avoir un support post-EOL de XP.. c'est qu'il y sûrement un besoin, mais je ne l'ai jamais rencontré, donc je m'interroge un peu ..
Tu n'as jamais rencontré le cas d'un client développeur qui te fais monter une machine avec des services absolument pas à jour, genre des tomcat 5, des php 4... parce qu'ils ne veulent pas corriger leurs devs pour les rendre compatible avec les versions modernes ? Heureux homme.
Si et en général, ils ont le droit a un avenant au contrat expliquant clairement qu'on dégage toute responsabilité en tant que prestataire en cas de hacking / xss / owning / deface / etc... et qu'ils ont la totale responsabilité des actes qui peuvent être commis via leur applis pourries et qu'ils sont donc responsable directement de tout usage illégal qui pourrais être fait sur leur services. En général, ca aide a les faire migrer... Xavier
Le 18/04/2014 10:29, « Xavier Beaudouin » <kiwi@oav.net> a écrit :
Hello,
Le 18 avr. 2014 à 10:27, Julien Gormotte <julien@gormotte.info> a écrit :
Le Fri, 18 Apr 2014 10:20:18 +0200, Manu <manu@formidable-inc.net> a écrit :
Le 17/04/2014 19:36, Wallace a écrit :
Pour les clients y a des évolutions du système qui sont bloquants
Oui, en fait c'est ça que je cherche un peu à comprendre. Car si Debian se lance dans le LTS, si Ubuntu fait déjà, si des entreprises payent microsoft pour avoir un support post-EOL de XP.. c'est qu'il y sûrement un besoin, mais je ne l'ai jamais rencontré, donc je m'interroge un peu ..
Tu n'as jamais rencontré le cas d'un client développeur qui te fais monter une machine avec des services absolument pas à jour, genre des tomcat 5, des php 4... parce qu'ils ne veulent pas corriger leurs devs pour les rendre compatible avec les versions modernes ? Heureux homme.
Si et en général, ils ont le droit a un avenant au contrat expliquant clairement qu'on dégage toute responsabilité en tant que prestataire en cas de hacking / xss / owning / deface / etc... et qu'ils ont la totale responsabilité des actes qui peuvent être commis via leur applis pourries et qu'ils sont donc responsable directement de tout usage illégal qui pourrais être fait sur leur services.
En général, ca aide a les faire migrer...
Xavier
Euh, on ne doit pas avoir les mêmes populations de client. Temps moyen de réaction du client face à ce genre de problème : 2 ans. Taux de migration : < 50% De plus, souvent, les développeurs sont des sous-traitants du client, et le client n¹aime pas re-payer le sous-traitant. S¹il existe toujoursŠ
Le Fri, 18 Apr 2014 10:29:35 +0200, Xavier Beaudouin <kiwi@oav.net> a écrit :
Si et en général, ils ont le droit a un avenant au contrat expliquant clairement qu'on dégage toute responsabilité en tant que prestataire en cas de hacking / xss / owning / deface / etc... et qu'ils ont la totale responsabilité des actes qui peuvent être commis via leur applis pourries et qu'ils sont donc responsable directement de tout usage illégal qui pourrais être fait sur leur services.
Pareil
En général, ca aide a les faire migrer...
Ah, de mon expérience personnelle, ca aide assez rarement tout de meme, ils signent.
Xavier
Hello, Le 18 avr. 2014 à 10:35, Julien Gormotte <julien@gormotte.info> a écrit :
Le Fri, 18 Apr 2014 10:29:35 +0200, Xavier Beaudouin <kiwi@oav.net> a écrit :
Si et en général, ils ont le droit a un avenant au contrat expliquant clairement qu'on dégage toute responsabilité en tant que prestataire en cas de hacking / xss / owning / deface / etc... et qu'ils ont la totale responsabilité des actes qui peuvent être commis via leur applis pourries et qu'ils sont donc responsable directement de tout usage illégal qui pourrais être fait sur leur services.
Pareil
En général, ca aide a les faire migrer...
Ah, de mon expérience personnelle, ca aide assez rarement tout de meme, ils signent.
Pas toute de suite, mais après un deface ou une req judiciaire chez le client, ca aide :) /Xavier
Le 17 avr. 2014 à 16:49, Wallace a écrit :
Pourquoi ne pas simplement prolonger la période oldstable? Si la securityteam n'est plus sur Squeeze il devient important de migrer.
Parce qu'il faut des gens pour le faire. Et une communauté basé entièrement sur du bénévolat n'a pas nécessairement que ça à faire...
De notre côté tout est déjà organisé, on s'est laissé un an pour migrer les 6 vers 7, il reste que quelques serveurs à gérer en attente de retour client. Squeeze a bien vécu, si on commence à ralonger les durées de vie, autant reporter les prochains freeze.
C'est un choix, ceci dit cela impose de migrer au même rythme que Debian, c'est à dire tous les deux ans, ce qui peut être soutenu pour certaines personnes. En comparaison, certains laissent des systèmes OpenBSD tourner pendant des années sans problème. Côté Linux, certaines distributions ont un support à long-terme de plusieurs années également pour les gens qui veulent avant tout de la stabilité. Dans tous les cas c'est un compromis et ça ne se règle pas en cinq minutes... Cordialement Emmanuel Thierry
Hello, Je dis pas grand chose, mais je vais placer ma pierre a l'édifice.
Pourquoi ne pas simplement prolonger la période oldstable? Si la securityteam n'est plus sur Squeeze il devient important de migrer.
Parce qu'il faut des gens pour le faire. Et une communauté basé entièrement sur du bénévolat n'a pas nécessairement que ça à faire...
+1 de plus si tu veux qu'il y du support a long terme et que ta boite utilise debian pour gagner de l'argent, il est peut-être intéressant de contribuer au projet debian. C'est ça l'opensource. Ca peux pas toujours se passer dans un sens : les gens bénévoles travaillent gratuitement pour ta boite. (Car c'est ça en fait qu'il se passe).
De notre côté tout est déjà organisé, on s'est laissé un an pour migrer les 6 vers 7, il reste que quelques serveurs à gérer en attente de retour client. Squeeze a bien vécu, si on commence à ralonger les durées de vie, autant reporter les prochains freeze.
C'est un choix, ceci dit cela impose de migrer au même rythme que Debian, c'est à dire tous les deux ans, ce qui peut être soutenu pour certaines personnes. En comparaison, certains laissent des systèmes OpenBSD tourner pendant des années sans problème. Côté Linux, certaines distributions ont un support à long-terme de plusieurs années également pour les gens qui veulent avant tout de la stabilité.
Dans tous les cas c'est un compromis et ça ne se règle pas en cinq minutes...
Je trouve que migrer tous les 2 ans n'est pas super soutenu. Car en deux ans, les technos bougent, les outils bougent, et dans l'informatique ne pas s'adapter c'est mourir. Oui effectivement si tu attends le dernier moment la tu en chie, car le code développé en PHP ne marche plus (bon bah c'est aussi la rançon de la gloire d'utiliser php, mais c'est un autre débat), les softs ont des bugs corrigé que tu as pu exploiter pour t'aider, les fichiers de conf partent du fichier plat a un délire a coup de ldapsearch/ldapadd.... bref le changement fais mal. Si par contre tu travailles proactivement avec les gens qui dev les outils, avec une plateforme de test, alors tu as l'habitude de changer rapidement de releases, tu as des choses qui utilisent les bonnes technos stabilisées, etc... Pour info, j'ai repris l'admin d'une boite ou ils ne voulaient JAMAIS upgrader quoi que ce soit... Résultat : - Un système d'info troué (mais pas avec heartbleed), - Des ubuntu 7.04 qui étaient en production, - Des bugs à la con avec les nouveaux OS (type mon Windows s'identifie pas avec l'AD... normal y a un patch, upgrade), - A chaque mise à jour on a des travaux énormes de tests qui peuvent durer plusieurs mois alors qui s'ils avaient suivit un peu les mises à jours on aurais moins de taf, - De l'instabilité latente dûes aux problèmes de cpu récents avec des OS pas prévu pour 8 coeurs ou plus, - ... Donc si tu veux pas trop mettre à jour, tu peux garder des openbsd (mais ca c'est un risque, vu les derniers commits dans le repo de openbsd, a toi de voir), ou rester sur des OS proprio tels que Solaris, ou les mise à jour major release = reinstall complete... Tu as de la chance avec Debian que les mises à jours sont faciles. Vas essayer CentOS ou RHEL, passer de RHEL 5 à 6 n'est pas super facile alors que debian ou ubuntu... c'est piece of cake. Arrêtez de ronchonner car des volontaires ont décidés qu'il faut arrêter de garder des vieilleries, c'est pour le bien de tous, et vous pouvez toujours forker debian et faire votre propre distribution et gérer vous même les patches de secu... Xavier
Arrêtez de ronchonner car des volontaires ont décidés qu'il faut arrêter de garder des vieilleries, c'est pour le bien de tous, et vous pouvez toujours forker debian et faire votre propre distribution et gérer vous même les patches de secu...
J'ai du mal à comprendre cette remarque. L'annonce est justement que des volontaires *vont* supporter des vieilleries. Debian 6 s'arrête comme prévu, mais on va avoir une version LTS avec support réduit pendant encore deux ans. Ça ne change rien pour les habitués des migrations rapides, et peut arranger du monde (au moins les entreprises volontaires pour le faire, sinon Debian n'aurait pas fait l'annonce). Sinon j'ai l'impression que le fil de discussion se concentre sur des technologies qui bougent énormément, de type web/php. J'ai dans un coin de France une Debian servant de "routeur/proxy compressant" pour économiser la bande passante, et migrer n'apportera aucune nouveauté (mais prendra beaucoup de temps à coup de changement de DVD. S'il est présent, c'est bien que l'accès au net est trop pourri pour faire rapidement une MAJ...).
participants (9)
-
Christophe Moille -
Edelwin Khaelos -
Emmanuel Thierry -
Florent Fourcot -
Julien Gormotte -
Manu -
Sylvain Donnet -
Wallace -
Xavier Beaudouin