一个偏执的系统管理员如何能够自信地保持与最新的稳定 PHP 版本同步？（安全修复已经相当定期地发布）。
这是一台生产服务器，所以“破坏东西”让我的人害怕得要死。维护停机时间不是问题。
具体来说，我们正在运行最新的 Suse Enterprise Linux，但通用或更通用的答案也是完全可以接受的。
您如何处理生产机器的安全更新？我们到底不知道什么，以至于这个人害怕使用包管理器来“更新”？
有什么建议吗？
答案1
我处理 PHP 的方式与处理其他所有事情的方式相同：首先升级开发环境（生产的 VMWare 克隆），对其进行回归测试，然后使用我们用于 VMWare 主机的相同部署模板将其提升到生产环境。（如果您使用包管理器进行升级，则可以使用相同的包）。
作为额外的隔离层，我们的生产环境由成对的冗余主机组成，并且将一台主机从生产轮换中取出进行升级，然后在切换到该主机升级其配对主机之前进行彻底的测试。
一般来说，安全更新会尽快应用，而非安全/非关键的错误修复更新则每季度应用一次，以最大限度地减少停机时间。
答案2
PHP 是我最希望保持更新到最新版本的东西之一。我对它的信任程度低于大多数东西。
最终，最好的选择是检查从当前版本到最新版本的每个更改日志，并切实权衡风险。
如果您说的是升级小版本，例如从 5.3.1 升级到 5.3.2，我不会太担心。
如果您从 5.2.x 升级到 5.3.x，可能会遇到一些兼容性问题。
如果您使用系统软件包，通常发行版不会引入会破坏现有性能的升级。RHEL 和 CentOS 会修补旧版本，直到主要发行版发布。他们通常会为您进行测试，从而降低风险。我希望 SuSE企业相似。
对于升级路径，最好的选择是在升级生产之前构建一个测试服务器并针对最新版本测试应用程序。
答案3
另一个不太受欢迎的答案是建立允许的 URL 和功能的白名单。在 Apache 中，您可以通过结合代理和重写功能来实现这一点。
基本上，您需要进行两次安装，一次安装具有精简配置：代理、重写且无代码执行；等等。任何“允许”的 URL（带有参数等）都会被代理到第二次安装。
然后，将自己添加到 PHP 的开发人员列表中，并仔细监视发行说明。每当您发现某些东西可能存在安全漏洞时，您都会在第一次安装时构建一个垫片来检测此类故障，并向用户发送错误。
在这样的设置中，您需要将 POST 重定向到一个过滤器（如果您确实需要 POST；有些网站通过只允许来自某些 IP 地址的 POST 就可以正常工作！），该过滤器可以查找允许的来源并预先验证所有内容。
这样的白名单设置起来非常耗时，但对于需要运行时间超过 PHP 稳定寿命（似乎只有几年）的关键任务应用程序来说，这是一种利用大量 PHP 应用程序而不会受到其漏洞影响的绝佳方法。
答案4
除上述操作外，您还可以启用包回滚以防万一。
那么如果生产过程中确实出现问题完全确定开发工作顺利，您至少可以在解决问题之前快速撤消更改。
看回滚 YUM 包以 Yum 为例。我相信其他包管理系统也有类似的。
我知道这是万全之策，我同意 Warner 的观点，只发布少量版本。小改动不会破坏任何东西。就我个人而言，在 PHP 升级中我没有遇到任何问题，但谨慎总是比后悔好。