解決策 1:
独自のディストリビューションを維持するのは大変な作業です。バックポートを維持していても、すぐに修正すべきセキュリティの問題に圧倒され、ソフトウェアを更新し続けるために低レベルのライブラリをプルする必要があり、他のものが壊れる可能性があります (私は 6 年前のディストリビューションを実行しているサーバーを維持しています。面白くない)。
通常、アップグレードは適切な解決策です。 do-release-upgrade よくできており、問題なくアップグレードできるはずです (特に公式パッケージのみを使用した場合)。
私のお気に入りの解決策は、再インストールパスかもしれません。具体的には、Puppet、Cfengine、Chef などの構成管理システムを使用してサーバーを管理する必要があります。このようなツールを使用してすべての構成/パッケージのニーズが指定されていて、データが別のパーティションに安全に保管されている場合は、すばやく再インストールする方がはるかに簡単です。データ パーティションを消去せずに新しいディストリビューションをインストールし、構成管理ツールを実行してパッケージ/構成をリセットするだけです。特に管理するサーバーが複数ある場合は、これが最もクリーンな方法だと思います。
非公式パッケージを使用している場合は、アップグレード/再インストールする前にそれらを特定することをお勧めします。 maintenance-check は、Ubuntu によって公式に保守されていないパッケージを特定するのに役立ちます:
$ bzr branch lp:ubuntu-maintenance-check
$ cd ubuntu-maintenance-check
$ ./maintenance-check -f n
再インストールする場合は、インストール済みパッケージのリストをエクスポートすることもできます:
$ dpkg --get-selections > myinstall.txt
および debconf データベース:
$ debconf-get-selections > debconf.txt # from the debconf-utils package
注意として、現在 Karmic を使用しているため、LTS リリースである Lucid にアップグレードするのはそれほど激しくないかもしれません。メイン サーバー パッケージでは 2015 年までサポートされています。これにより、将来のために実行可能な自動インストールをセットアップするための十分な時間が残されます。
Launchpad パッケージについて尋ねると、PPA を意味すると思います。さまざまなPPAがたくさんあります。実験的なものもあれば、安定したものもあります。公式の Ubuntu 開発者によって保守されているものもあれば、パッケージを適切に行う方法をほとんど知らない人々によって保守されているものもあります。 PPA で見つけたパッケージが優れているかどうかを一般的に言うのは難しく、一般的なルールはありません。この場合の最良のヒントは、PPA の所有者を調べて、パッケージの可能な品質を把握することです。
解決策 2:
サーバーが外部に公開されておらず、ユーザーを完全に信頼している場合 (一般的には良い考えではありません)、サーバーが機能している場合はそのままにしておくことができます。
それが何らかの形で外の世界にさらされている場合、および/または正当なユーザーが違法な方法でそれを使用しているという考えを抱く場合は、インストールされているソフトウェアの修正とパッチが絶対に必要です.
この場合、次の 2 つのオプションがあります:
<オール>サポートされているディストリビューションを実行し、ソフトウェアのアップデートを入手する、または
率直に言って、サポートされていないディストリビューションにすべての修正をバックポートします。
私は Ubuntu ユーザーではないので、オプション 3 で得られるパッチの完全性についてコメントすることはできませんが、疑問がある場合は、完全にはカバーされていないと思います.
最善の解決策は、Ubuntu の LTS バージョンに移行することです。これにより、特定のパッケージ バージョンがしばらくの間サポートされます。やがて、一部のパッケージは古くなりますが、環境にはセキュリティ パッチが適用され、安定した状態になります (パッケージ バージョンのバンプはありません)。私の経験から、既知の作業環境の安定性は通常、新機能よりも価値があります。
あなたの現在の位置は維持できず、移動する必要があるようです。唯一の安全な方法は、2 台目のマシン (または仮想マシン) を入手し、手順が成功するまで移行をテストしてから、それを運用マシンに適用することです。バックアップを使用してテスト移行を行う場合は、バックアップ手順もテストする良い機会になります。
解決策 3:
唯一の本当の方法は、ディストリビューションのアップグレードです。あなたが緊張しているのは理解できます。なぜなら、今ではいくつかのリリースを先に進めているからです (11.04 がリリースされたばかりです)。
このマシンでドライブのクローンを作成し、別のコンピュータを使用してクローンを実行し、それを使用して一連のテスト アップグレードを行うことをお勧めします。発生したすべての問題をメモし、それらすべてに対する明確な手順ができるまで繰り返します。次に、これをライブ サーバーに適用します。
ダウンタイムを許容できない場合は、移行が唯一の解決策です。ピン留めとバックポートのことは忘れてください。これにより、限られた期間だけ生き続けることができます。そして、「独自のロール」オプションは検討する価値さえありません.ちょうど私の 2 ペニーの価値です。