我们正在运行基于Ubuntu 9.10 Karmic 考拉，内核几乎是最新的（2.6.38.2-grsec-xxxx-grs-ipv6-64），但是karmic 软件包存储库现在已经过时了，例如 Nginx 是 0.7.62 - 漏洞百出 - 而最新稳定版本是 1.0.x！
此外，Karmic 也刚刚到达了生命的终点。
这个问题：保持 UNIX 软件包最新的最佳实践？看起来很相似，但实际上只包含一些关于包管理器的建议；根本不是我需要的！
所以我看到的选项是：
#1 的缺点非常明显。
不过我不敢进行 dist-upgrade 路径，因为对于生产服务器来说，停机时间和可能的灾难性后果是无法预测的，目前我主要在重建我自己所需的包。但我确信我可能会遗漏一些。
我不太清楚使用 Ubuntu 反向移植的风险（稳定性/兼容性），此外，官方不再提供 9.10 版本。Launchpad 是单独构建的，类似的问题 - 这比我自己编译好多少？
构建包看起来不错，但是：
- 有时我无法重现正确的 ./configure 选项，以便重新使用我现有的配置文件
- 我确信有大量的软件包和依赖项现在已经过时并且可能是错误的来源
最后……最近发行版中的“旧”软件包怎么办？我猜除了自己重建它们之外没有别的办法了？2 和 4 的组合最终是最好的方法吗？
有没有客观的对于什么是最佳做法的共识，或者为什么我的某些选择可以/不可以？
如果确实没有，我会接受关闭该问题，然后再创建无休止的线程！
答案1
维护自己的发行版需要做很多工作。即使你维护了反向移植，你也会很快被需要修复的安全问题所淹没，并且必须提取低级库来不断更新软件，这可能会破坏其他东西（我维护运行 6 年前发行版的服务器，这并不好玩）。
升级通常是一个很好的解决方案。do-release-upgrade做得很好，你应该能够毫无问题地升级（特别是如果你只使用官方软件包）。
不过，我最喜欢的解决方案可能是重新安装路径。更具体地说，您的服务器应该使用配置管理系统（如 Puppet、Cfengine 或 Chef）进行管理。如果您使用此类工具指定了所有配置/包需求，并且您的数据安全地存储在单独的分区中，那么重新安装会更容易。您只需安装新的发行版而不擦除数据分区，然后运行配置管理工具来重置您的包/配置。我相信这是最干净的方法，特别是如果您有多个服务器需要管理。
如果您正在使用非官方软件包，您可能需要在升级/重新安装之前识别它们。维护检查可以帮助您识别未由 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，因此升级到 Lucid 可能并不太麻烦，因为 Lucid 是一个 LTS 版本，在 2015 年之前仍支持主服务器软件包。这应该会给您足够的时间来为未来设置可行的自动化安装。
当你问到 Launchpad 软件包时，我猜你指的是 PPA。PPA 有很多种。有些是实验性的，有些是稳定的。有些由官方 Ubuntu 开发人员维护，有些由几乎不知道如何正确制作软件包的人维护。一般来说，很难说你在 PPA 上找到的软件包是否好，没有一般规则。在这种情况下，最好的提示可能是查看 PPA 的所有者，以了解其软件包的可能质量。
答案2
如果服务器没有暴露给外界，并且您绝对信任您的用户（通常这不是一个好主意），那么如果它可以正常工作，您就可以让它保持原样。
如果它以任何方式暴露给外界，和/或您考虑合法用户以非法方式使用它，那么您绝对需要对已安装的软件进行修复和打补丁。
在这种情况下，您有两个选择：
运行受支持的发行版并获取软件更新，或者
将所有修复程序反向移植到不受支持的发行版，坦率地说，这似乎是不可行。
我不是 Ubuntu 用户，所以我无法评论您通过选项 3 获得的补丁的完整性，但如果您有任何疑问，我会假设您不会获得完整的覆盖。
最好的解决方案是迁移到 Ubuntu 的 LTS 版本，这将在未来一段时间内为您提供对给定软件包版本的支持。随着时间的推移，一些软件包将会过时，但您的环境将有安全补丁并且会很稳定（不会出现软件包版本波动）。根据我的经验，已知工作环境的稳定性通常比新功能更有价值。
看来，您目前的职位无法维持，您必须搬家。唯一安全的方法是获得第二台机器（或虚拟机）并测试迁移，直到您拥有可重复的成功程序，然后将其应用于生产机器。如果您使用备份进行测试迁移，那么您也将有很好的机会测试您的备份程序。
答案3
唯一真正的出路是发行版升级。我能理解你对此感到紧张，因为现在你将跳过几个版本（11.04 刚刚发布）。
我建议克隆这台机器中的驱动器，然后使用单独的计算机运行克隆，并使用它进行一系列测试升级。记下遇到的所有问题并重复，直到您对所有问题都有明确的程序。然后将其应用于您的实时服务器。
如果您无法承受任何停机时间，那么迁移是您唯一的出路。忘记固定和反向移植吧，它们只能让您存活一段有限的时间。而且“自行部署”选项甚至不值得考虑。这只是我的一点看法。