Linux组件升级方案的一些反思

正常情况下，产品每半年一个版本，比如13年上半年是13.1R1，下半年是13.2R1，到了14年就是14.1R1和14.2R1。但特殊情况下也会为了某些重要的客户增加几个例外版本，比如13.3R1，13.3R2等等。

从2013年6月份至今，为了满足国外某大客户的安全性需求，开始在版本中增加安全加固的代码，其中绝大部分是修改Linux操作系统及安装软件如MySQL的配置文件，增删改一些配置条目。本来以为一个版本就会完成相关需求，但是客户在后续陆陆续续又提过来很多相关问题，同时还有一些前面改过后来又发现的相同问题。下面仅从升级脚本的设计规划角度分析一下存在的问题及可能的改进方法。

目前升级脚本是这样设计的，

系统全新安装时，不论哪个版本，都会执行到本版本为止的所有安全加固脚本（就是图中的securityConfigChang*.sh)，比如安装13.3版本（图中绿线），那么securityConfigChange131.sh，securityConfigChange132.sh和securityConfigChange133.sh都会被执行；升级时，由于版本是链式升级的，比如从13.1升级到13.3，那实际升级路径是13.1->13.2->13.3（图中黄线），会执行的安全加固脚本是securityConfigChange132.sh和securityConfigChange133.sh，securityConfigChange131.sh不会被执行，因为当前版本是13.1，已经包含本版本的安全加固内容了。每一个脚本里面都散布着各种安全加固设置，比如某配置文件的，系统参数的，等等。

从目前看，不论全新安装还是升级都没什么问题，所有该执行的都执行了。但是在实际中却发现了一些回归问题，比如问题A在13.1已经解决了，但是升级到13.3就又出现了，而全新安装的没有问题，这是怎么回事呢？

经过分析，因为在版本升级过程中我们也会升级软件的rpm包，这样就导致有些系统设置被重置！比如服务的自启动状态及默认配置，升完级后安全加固的配置就没有了。

问题就是这样，如何解决呢？仅是理论性分析，未经验证

类似于面向切面的编程，如果从另外一个角度规划升级脚本，将每一类的问题作为一个文件，比如，系统的sysctl配置，file permission设置，服务自启动状态设置，以及各重要服务自己的配置文件，比如Apache httpd，MySQL等，从每一类问题的角度来划分脚本。

这种划分方式要注意的一点是要保证脚本可重入性，也就是保证脚本多次被执行不会发生错误，也就需要判断当前状态来进行设置。比如从13.1升级到13.3，需要执行两次安全加固脚本，但第二次执行的内部可能包含第一次的，也就是第一次的配置相当于被执行了两遍。

这种方式最大的好处是解决了升级过程的配置遗漏，保证从每一个“切面”上的安全脚本都被执行过。但是不适合耗时费资源的内容，因为会被执行多次。

是否存在其他问题呢？欢迎补充

补充：

经过最近几天的讨论，组里面其他同学也基本都认识到这个问题，对方案有了进一步的优化：

对于像httpd, mysql等有相关配置文件的升级，可以每个版本在配置库中保存一份完整的配置文件模板，也就是所有安全性配置都已经在里面了，每次全新安装或者升级直接将这个文件覆盖安装后的配置文件，然后进行必要的变量替换，比如换一下IP地址，主机名之类的。这样又进一步简化了配置过程，而且不容易出错。