Lösung 1:
Eine eigene Distribution zu pflegen ist eine Menge Arbeit. Selbst wenn Sie die Backports pflegen, werden Sie bald von Sicherheitsproblemen überwältigt sein, die behoben werden müssen, und müssen Low-Level-Bibliotheken abrufen, um Ihre Software weiter zu aktualisieren, was andere Dinge beschädigen könnte (ich betreue Server, auf denen 6 Jahre alte Distributionen ausgeführt werden, es ist kein Spaß).
Ein Upgrade ist im Allgemeinen eine gute Lösung. do-release-upgrade ist gut gemacht und Sie sollten ohne Probleme upgraden können (insbesondere wenn Sie nur offizielle Pakete verwendet haben).
Meine Lieblingslösung könnte jedoch der Neuinstallationspfad sein. Genauer gesagt sollten Ihre Server mit einem Konfigurationsmanagementsystem wie Puppet, Cfengine oder Chef verwaltet werden. Wenn alle Ihre Konfigurations-/Paketanforderungen mit einem solchen Tool angegeben sind und Ihre Daten auf einer separaten Partition sicher sind, ist eine schnelle Neuinstallation viel einfacher. Sie installieren einfach eine neue Distribution, ohne die Datenpartitionen zu löschen, und führen dann das Konfigurationsverwaltungstool aus, um Ihre Pakete/Konfigurationen zurückzusetzen. Ich glaube, das ist der sauberste Weg, besonders wenn Sie mehrere Server verwalten müssen.
Wenn Sie nicht offizielle Pakete verwenden, sollten Sie diese vor dem Upgrade/der Neuinstallation identifizieren. maintenance-check kann Ihnen helfen, die Pakete zu identifizieren, die nicht offiziell von Ubuntu gewartet werden:
$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n
Wenn Sie neu installieren möchten, können Sie auch die Liste der installierten Pakete exportieren:
$ dpkg --get-selections > myinstall.txt
und Ihre Debconf-Datenbank:
$ debconf-get-selections > debconf.txt # from the debconf-utils package
Da Sie derzeit Karmic verwenden, ist es möglicherweise nicht zu heftig, auf Lucid zu aktualisieren, eine LTS-Version, die noch bis 2015 für die Hauptserverpakete unterstützt wird. Dies sollte Ihnen genug Zeit lassen, um eine praktikable automatisierte Installation für die Zukunft einzurichten.
Wenn Sie nach Launchpad-Paketen fragen, meinen Sie vermutlich PPAs. Es gibt unzählige verschiedene PPAs. Einige sind experimentell, einige sind stabil. Einige werden von offiziellen Ubuntu-Entwicklern gepflegt, andere von Leuten, die kaum wissen, wie man ein Paket richtig macht. Es ist schwer zu sagen, ob Pakete, die Sie auf PPAs finden, gut sind, es gibt keine allgemeine Regel. Der beste Hinweis in diesem Fall ist vielleicht, sich den Eigentümer der PPAs anzusehen, um sich ein Bild von der möglichen Qualität seiner Pakete zu machen.
Lösung 2:
Wenn der Server nicht der Welt ausgesetzt ist und Sie Ihren Benutzern absolut vertrauen (im Allgemeinen ist das keine gute Idee), dann könnten Sie es einfach so lassen, wenn es funktioniert.
Wenn es in irgendeiner Weise der Außenwelt ausgesetzt ist und/oder Sie die Vorstellung haben, dass legitime Benutzer auf unrechtmäßige Weise damit spielen, benötigen Sie unbedingt Korrekturen und Patches für Ihre installierte Software.
In diesem Fall haben Sie zwei Möglichkeiten:
-
Führen Sie eine unterstützte Distribution aus und erhalten Sie Updates für Ihre Software, oder
-
Backportieren Sie alle Fixes auf Ihre nicht unterstützte Distribution, was ehrlich gesagt nicht machbar erscheint.
Ich bin kein Ubuntu-Benutzer, daher kann ich die Vollständigkeit der Patches, die Sie durch Ihre Option 3 erhalten würden, nicht kommentieren, aber wenn Sie irgendwelche Zweifel haben, gehe ich davon aus, dass Sie keine vollständige Abdeckung haben werden.
Die beste Lösung ist der Wechsel zu einer LTS-Version von Ubuntu, die Ihnen noch einige Zeit Unterstützung für die angegebenen Paketversionen bietet. Mit der Zeit werden einige der Pakete veraltet sein, aber Ihre Umgebung wird Sicherheitspatches haben und stabil sein (keine Paketversionssprünge). Aus meiner Erfahrung ist die Stabilität einer bekannten Arbeitsumgebung meist wertvoller als neue Features.
Es scheint, dass Ihre aktuelle Position nicht haltbar ist und Sie umziehen müssen. Der einzig sichere Weg besteht darin, eine zweite Maschine (oder eine virtuelle Maschine) zu erwerben und Migrationen zu testen, bis Sie ein wiederholbares erfolgreiches Verfahren haben, und es dann auf die Produktionsmaschine anzuwenden. Wenn Sie Ihre Backups für Testmigrationen verwenden, haben Sie eine gute Gelegenheit, auch Ihre Backup-Verfahren zu testen.
Lösung 3:
Der einzige wirkliche Weg nach vorne ist ein Distributions-Upgrade. Ich kann verstehen, dass Sie deswegen nervös sind, da Sie inzwischen mehrere Releases vorauseilen werden (11.04 wurde gerade veröffentlicht).
Ich würde empfehlen, einen Klon der Laufwerke in dieser Maschine zu erstellen und dann einen separaten Computer zu verwenden, um mit den Klonen zu arbeiten, und diesen zu verwenden, um eine Reihe von Test-Upgrades durchzuführen. Notieren Sie sich alle aufgetretenen Probleme und wiederholen Sie den Vorgang, bis Sie für alle ein klares Verfahren haben. Wenden Sie dies dann auf Ihren Live-Server an.
Wenn Sie sich keine Ausfallzeiten leisten können, ist die Migration Ihr einziger Ausweg. Vergessen Sie das Pinning und die Backports, die Sie nur für eine begrenzte Zeit am Leben erhalten. Und die Option „selbst rollen“ ist nicht einmal eine Überlegung wert. Nur meine zwei Cent wert.