When it’s ready…

Debian Wheezy est sortie le 4 mai 2013, en bon debianeux fanatique, je ne pouvais que me dépêcher de mettre à jour 😀

Si mes machines de travail sous sid/experimental (oui, oui, même celle du boulot) n'en ont pas eu besoin, mon brave petit serveur OVH (non, ce n'est pas de la pub, je suis juste content de leur boulot) lui, est passé à la moulinette.

Après avoir lu en entier les recommandations kivonbien, je me suis lancé dans la grande aventure… qui était finalement bien courte !

L'upgrade de mes containers s'est passé(e?) comme un charme, pas plus compliqué(e?) qu'un apt-get dist-upgrade.

Pour le dom0, j'ai par contre eu une petite frayeur : les containers se sont arrêtés lors de la procédure de mise à jour (jusque là, ça semble normal) mais ils n'ont pas voulu redémarrer !  (ouille) Mais alors vraiment pas, avec messages d'injures en anglais et tout et tout.

Après 3 secondes de recherches sur le web, il semblait que c'était à cause d'un noyau trop ancien pour la nouvelle version des outils lxc. Soit. Upgrade de noyau, reboot… et rien !

Panique, sueurs froides, apéro (si, si, j'ai une vie sociale ! J'ai juste eu la mauvaise idée de faire l'upgrade du dom0 avant d'aller boire un coup), pings négatifs pendant l'apéro, retour… et ouf ! Juste une vacherie de fsck (fallait s'y attendre) qui a fait que le reboot a pris un looooong moment. Ovh avait détecté que mon serveur était éteint et avait envoyé un technicien sur place, ils m'ont ensuite informé que tout allait bien et qu'il y avait eu un fsck. Ça m'a rassuré pour le coup, entre deux coups de rosé.

Plus qu'à relancer les containers à la main (je sais pas pourquoi ils n'ont pas redémarré automatiquement, à voir demain) et revoilà mon serveur en ligne.

Conclusion : la vie est belle et les mecs de chez Debian font un vache de bon boulot. Merci !

PS : c'est juste dommage d'avoir perdu un uptime de 281 jours. Bah ! D'ici Jessy, j'aurais bien 2 ans d'uptime si tout va bien 😀

PPS : non, c'est pas parce que je suis un admin en carton que je me casse boire un pot en plein reboot d'après mise à jour. C'est juste que j'ai ÉNORMÉMENT confiance en Debian…  que j'avais soif et que je ne m'appelle pas Google : un downtime de 4/5h sur un an, c'est pas trop grave quand même. 😉

5 réflexions au sujet de “When it’s ready…”

  1. A lire ton billet ainsi que celui de quelques autres, on croirait que la sortie d’une nouvelle release Debian relève du miracle !
    Je me demande donc comment dois-je qualifier les distributions en rolling release dont la mise à jour se fait en continu. .. il y a un mot qui puisse qualifier quelque chose de « plus fort » qu’un miracle ?
    Plus sérieusement, j’avais jusqu’ici une Debian sur mon serveur perso et je l’ai finalement remplacée par une CentOS dont le support d’OpenVZ est bien meilleur. Je n’ai pas l’intention de migrer vers LXC pour le moment car visiblement les mecs d’OpenVZ vont réussir à inclure leur patch dans le kernel mainstream (un peu comme pour Xen).
    Par contre, je pense sérieusement à migrer de CentOS à Gentoo pour pouvoir compiler un OS minimaliste et optimisé pour une plateforme à base d’Intel Atom.
    Pour en revenir à Debian, je pense qu’il leur faudra vraiment adopter une politique de release à 2 vitesses :
    1/ Des releases fréquentes avec un support court terme pour les installations de type desktop.
    2/ Des releases plus espacées avec un support plus long terme pour les installations de type serveur, là encore, il faudra penser à un moyen permettant tout de même d’avoir une mise à jour fréquente sur certains paquets.

    Ce mécanisme est très comparable à celui d’Ubuntu et sa déclinaison serveur, cette dernière a été préférée à Debian par bien des entreprises pour son meilleur support du matériel ainsi que la longévité de son support.

    • Un miracle, non, mais comme on attend toujours longtemps (par rapport aux autres distribs), c’est toujours un évènement ! Comme Debian a toujours des versions déjà un peu anciennes au moment de la release, imagine après 2 ans… On est bien contents d’avoir des paquets un peu plus frais 🙂
      Perso, j’avais qqs logiciels en testing, tout le reste en stable, sauf le serveur de mail (à cause de je sais plus quel logiciel que je voulais en version supérieure à la stable). Je peux te dire que j’avais un peu peur à chaque mise à jour du container de mail ! Donc là je suis repassé sur une stable pour tout, je vais beaucoup moins me poser de questions du coup.

      Pour ton histoire de Debian à 2 vitesses, on peut largement considérer la testing comme une rolling release, c’est très stable pour du desktop. De plus, il y a un projet en cours chez Debian pour proposer une rolling release officielle.

      Je vais pas rentrer dans le troll openvz/lxc. J’ai testé lxc quand je ne connaissais rien aux containers, j’ai monté mon serveur comme ça, j’ai pas envie de changer (un peu feignasse, ouais. Mais « If not broken, don’t fix it ! »).

      Je te souhaite bon courage pour ta Gentoo… tu pourrais faire des benchmarks sur CentOs maintenant et sur ta Gentoo après, histoire qu’on puisse comparer ? Parce qu’en fait j’ai quelques doutes sur le gain réel que ça va t’apporter 😉

      • Je peux essayer de benchmarker certaines choses comme la compression/décompression d’une archive. L’intérêt qu’offre Gentoo porte essentiellement sur l’espace disque utilisé ainsi que la consommation en mémoire vive, du fait que le kernel est minimaliste et que la compilation mieux adaptée à l’architecture de la plateforme.

        De plus, cela permet de compiler les applications avec juste les modules nécessaires offrant ainsi gain de place et meilleure sécurité/stabilité.

        Par contre, il est indéniable que Gentoo impose une certaine perte de temps à cause du la phase de compilation.

        Au niveau des VZ, j’ai un peu de tout : Debian, CentOS, Ubuntu et du Gentoo. Il n’y a pas de raisons particulières à cela si ce n’est l’envie de pouvoir manipuler chacune de ces distributions et ainsi garder la main.

        Pour l’heure, j’ai comme gros chantier la migration de mon blog de WordPress à Palican… ce qui ne s’avère pas vraiment trivial.

        • Sous Gentoo, faut vraiment faire attention à ce qu’on va mettre dans le options de build (ou ce qu’on ne va pas mettre).

          De plus jouer avec les -mtune et -march est susceptible d’attirer des emmerdes pour un gain en perf pas toujours pertinent.

          Question noyau, il faudra déjà forcer les CFLAGS personnalisés (KERNEL_CFLAGS il me semble) sinon ça ne sert à rien. De plus rien n’empêche de compiler son noyau sur n’importequelle distrib.

          Enfin la question de l’espace disque… heu bon, chacun fait ce qu’il veut mais gagner à peine quelques 100 de Mio, bof bof. Au mieux ça va être l’option mysql qui sera intéressante à enlever, et encore, ça ne compile normalement que la partie client.

          Je ne cherche à convaincre personne, ce n’est que mon avis 🙂

          • Ce n’est qu’un serveur perso donc ce n’est pas vraiment un problème de faire mumuse avec l’OS, d’ailleurs, au boulot la totalité de nos serveurs sont sous Gentoo et cela date de bien avant mon arrivée.

            Pour ce qui est des CFLAGS, c’est aujourd’hui un faux problème il me semble, les dernières version de GCC ayant une option -march=native celui-ci s’adapte automatiquement à la plateforme.

            Sinon, la customisation du système peut aller bien plus loin qu’une personnalisation du kernel, on peut aussi par exemple remplacer GlibC par UClibc et essayer de se faire un petit système embarqué.
            Il est aussi possible d’exploiter le patch PREEMPT-RT pour avoir un système temps réel et optimiser ainsi la virtualisation sous KVM.
            Bref, on peut s’amuser à bidouiller plein de paramètres.

            Debian c’est bien quand on veut dibouiller ses serveurs le moins souvent possible, ce qui n’est pas adéquat pour un serveur perso qui me sert aussi de plateforme de test et de bricolage.

Les commentaires sont fermés.