Quelle est la meilleure pratique pour maintenir à jour un serveur Linux Ubuntu (build packages, dist-upgrade, alt repos…)

Nous utilisons un serveur de production basé sur Ubuntu 9.10 Karmic Koala , le noyau est presque à jour (2.6.38.2-grsec-xxxx-grs-ipv6-64) mais le référentiel de packages karmic est maintenant ridiculement dépassé, par exemple. Nginx est 0.7.62 - vraiment buggé - tandis que la dernière version stable est 1.0.x !!

De plus, Karmic vient d'atteindre sa fin de vie.

Cette question: Meilleures pratiques pour maintenir à jour les packages UNIX? semble similaire mais ne comprend en fait que quelques suggestions sur les gestionnaires de packages; pas du tout ce dont j'ai besoin!

donc les options que je vois sont:

1. obtenir une nouvelle machine, l'installer à partir de zéro, migrer
2. mise à niveau de la distribution
3. utiliser un référentiel différent ( launchpad / ppa / backport / pinning )
4. construit le tien

Les inconvénients de 1. sont assez évidents.

Je n'ose pas faire un chemin de mise à niveau dist, car les temps d'arrêt et les conséquences catastrophiques possibles sont tout simplement impossibles à prévoir pour un serveur de production, et actuellement, je reconstruis principalement mes propres packages requis. Mais je suis sûr que j'en manquerai peut-être.

Il n'est pas vraiment clair pour moi quels sont les risques (stabilité / compatibilité) de l'utilisation des backports ubuntu, en plus rien n'est officiellement prévu pour 9.10. Launchpad sont des builds individuels, question similaire - comment est-ce mieux que de compiler le vôtre

La construction de packages semble correcte, mais: 1. j'ai parfois du mal à reproduire les options ./configure correctes afin de réutiliser mes fichiers de configuration existants 1. Je suis sûr qu'il y a des tonnes de packages et de dépendances qui sont maintenant assez obsolètes et source possible de bugs

Enfin ... qu'en est-il des "anciens" packages dans une distribution récente? Je suppose qu'il n'y a pas d'autre moyen que de les reconstruire moi-même? Une combinaison de 2. et 4. est-elle finalement le meilleur chemin?

Y a-t-il un consensus objectif sur la meilleure façon de procéder ou sur les raisons pour lesquelles certaines de mes options sont bonnes / pas bonnes?

Si vraiment il n'y en a pas, j'accepterai que la question soit close avant de créer un fil sans fin!

Le maintien de votre propre distribution représente beaucoup de travail. Même si vous maintenez les rétroportages, vous serez bientôt submergé par des problèmes de sécurité à corriger et devrez tirer des bibliothèques de bas niveau pour continuer à mettre à jour votre logiciel, ce qui pourrait casser d'autres choses (je maintiens des serveurs exécutant des distributions de 6 ans, c'est pas drôle).

La mise à niveau est généralement une bonne solution. do-release-upgradeest bien fait, et vous devriez pouvoir mettre à jour sans problème (surtout si vous n'utilisez que des packages officiels).

Ma solution préférée pourrait être le chemin de réinstallation. Plus précisément, vos serveurs doivent être gérés à l'aide d'un système de gestion de configuration tel que Puppet, Cfengine ou Chef. Si tous vos besoins de configuration / package sont spécifiés à l'aide d'un tel outil et que vos données sont en sécurité sur une partition distincte, il est beaucoup plus facile de réinstaller rapidement. Vous venez d'installer une nouvelle distribution sans effacer les partitions de données, puis exécutez l'outil de gestion de configuration pour réinitialiser vos packages / configurations. Je pense que c'est la façon la plus propre de le faire, surtout si vous avez plusieurs serveurs à gérer.

Si vous utilisez des packages non officiels, vous souhaiterez peut-être les identifier avant de mettre à niveau / réinstaller. maintenance-check peut vous aider à identifier les paquets qui ne sont pas officiellement maintenus par Ubuntu:

$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n

Si vous souhaitez réinstaller, vous pouvez également exporter la liste des packages installés:

$ dpkg --get-selections > myinstall.txt

et votre base de données debconf:

$ debconf-get-selections > debconf.txt # from the debconf-utils package

Remarque: étant donné que vous utilisez actuellement Karmic, la mise à niveau vers Lucid, qui est une version LTS, ne sera peut-être pas trop violente et sera toujours prise en charge jusqu'en 2015 pour les packages de serveurs principaux. Cela devrait vous laisser suffisamment de temps pour configurer une installation automatisée viable pour l'avenir.

Lorsque vous posez des questions sur les packages Launchpad, je suppose que vous parlez des PPA. Il existe des tonnes d'APP différents. Certains sont expérimentaux, certains sont stables. Certains sont gérés par des développeurs officiels d'Ubuntu, d'autres sont maintenus par des gens qui savent à peine comment faire un paquet correctement. Il est difficile de dire en général que si les packages que vous trouvez sur les PPA sont bons, il n'y a pas de règle générale. Le meilleur indice dans ce cas serait peut-être aussi de regarder le propriétaire des AAE pour se faire une idée de la qualité possible de leurs colis.

Si le serveur n'est pas exposé au monde et que vous faites entièrement confiance à vos utilisateurs (généralement ce n'est pas une bonne idée), alors si cela fonctionne, vous pouvez simplement le laisser.

S'il est en aucune façon exposé au monde extérieur et / ou si vous envisagez l'idée qu'un utilisateur légitime joue avec lui de manière illégitime, vous avez absolument besoin de correctifs et de correctifs pour votre logiciel installé.

Dans ce cas, vous avez deux options:

1. Exécutez une distribution prise en charge et obtenez des mises à jour de votre logiciel, ou

2. Rétroportez tous les correctifs à votre distribution non prise en charge, ce qui, à vrai dire, ne semble pas réalisable.

Je ne suis pas un utilisateur d'Ubuntu, donc je ne peux pas commenter l'exhaustivité des correctifs que vous obtiendriez grâce à votre option 3, mais si vous avez un doute, je suppose que vous n'aurez pas une couverture complète.

La meilleure solution est de passer à une version LTS d'Ubuntu, qui vous fournira un support pour les versions de package données pour un certain temps à venir. Avec le temps, certains packages seront obsolètes, mais votre environnement aura des correctifs de sécurité et sera stable (pas de sauts de version de package). D'après mon expérience, la stabilité d'un environnement de travail connu est généralement plus précieuse que les nouvelles fonctionnalités.

Il semble que votre position actuelle ne soit pas maintenable et vous devez vous déplacer. Le seul moyen sûr est d'obtenir une deuxième machine (ou une machine virtuelle) et de tester les migrations jusqu'à ce que vous ayez une procédure réussie reproductible, puis de l'appliquer à la machine de production. Si vous utilisez vos sauvegardes pour effectuer des migrations de test, vous aurez également une bonne occasion de tester vos procédures de sauvegarde.

La seule véritable voie à suivre est une mise à niveau de la distribution. Je peux comprendre que vous soyez nerveux à ce sujet, car vous allez maintenant sauter plusieurs versions à venir (11.04 vient de sortir).

Je recommanderais de faire un clone des lecteurs de cette machine, puis d'utiliser un ordinateur distinct pour exécuter les clones, et de l'utiliser pour effectuer une série de mises à niveau de test. Prenez note de tous les problèmes rencontrés et répétez jusqu'à ce que vous ayez une procédure claire pour chacun d'eux. Ensuite, appliquez cela à votre serveur en direct.

Si vous ne pouvez vous permettre aucun temps d'arrêt, la migration est votre seule issue. Oubliez l'épinglage et les rétroportages, qui ne vous maintiendront en vie que pendant une période de temps limitée. Et l'option «rouler soi-même» ne vaut même pas la peine d'être envisagée. Juste la valeur de mes deux sous.