我们在安装一个 Debian 包时，可能需要在安装或者卸载时去处理一些额外的安装操作，比如：新建一个目录，停止一个正在运行的服务等。这时就要用到一些特殊的脚本，“维护者脚本”。顾名思义，这是我们的研发人员常常会用到的脚本。
常见维护者脚本报错
●“dpkg (subprocess): unable to execute installed post-installation script (/var/lib/dpkg/info/xxx.postinst)”
● 上面这个报错应该很常见，这就是在安装时执行维护者脚本出现问题的报错。下面将会介绍一下这些脚本。
一、四大维护者脚本文件 “preinst、postinst、prerm 和 postrm”
1、基本描述
binarypackage.preinst，binarypackage.postinst，binarypackage.prerm，binarypackage.postrm 这四类文件被称为维护者脚本，这些脚本被放置在 Debian 目录下的控制区内，并且被“dpkg”用来控制安装，升级和删除。
2、具体功能
这些文件是可执行脚本，在安装或删除包之前或之后自动运行。连同一个名为 control 的文件，所有这些文件都是 Debian 存档文件的 “control” 部分的一部分。下面 foo 代指二进制安装包名。
01 foo.preinst：软件安装前执行的脚本
在从 deb 文件中解压缩它所属的包之前执行此脚本。许多 preinst 脚本停止正在升级的包的服务，直到它们的安装或升级完成。
02 foo.postinst：软件安装后执行的脚本
一旦 foo 从它的 deb 文件中解包，这个脚本通常会完成包 foo 安装完成后的必需配置工作。通常，postinst 脚本会要求用户输入，或警告用户，如果他们接受默认值，他们应该记得返回并根据需要重新配置该包。一旦安装或升级了新包，许多 postinst 脚本就会执行脚本内的命令来启动或重启服务。
03 foo.prerm：软件卸载前执行的脚本
此脚本通常会停止与包关联的任何守护进程，它在卸载软件包的相关文件前执行。
04 foo.postrm：软件卸载后执行的脚本
这个脚本通常修改与 foo 相关的链接或其他文件，或删除由包创建的文件。
目前所有的控制文件都可以在/var/lib/dpkg/info 目录下找到。与包 foo 相关的文件以名称"foo"开头，并有适当的文件扩展名"preinst"， "postinst"等。
3、维护者脚本的执行流程
当你在执行安装或卸载命令时，维护者脚本的执行顺序如下：
● 首次安装某 deb 包时，执行“dpkg -i test_v1.deb”安装，Debian 下面控制脚本按如下顺序执行：
preinst --> postinst
● 若卸载 deb，但保留配置档，执行“dpkg -r test”，Debian 下面控制脚本按如下顺序执行：
prerm --> postrm
● 若卸载不保留配置档，执行“dpkg -P test”，Debian 下面控制脚本按如下顺序执行：
prerm --> postrm --> postrm
是不是以为写错了？其实没有，就是执行了两次 postrm。但是第一次执行 postrm 传入的$1为 remove，
第二次执行 postrm 传入的$1为 purge。更详细解释的可以查看 dpkg 命令的 man 手册。
● 若升级安装，例如执行 dpkg -i test_v2.deb，Debian 下面的控制脚本执行顺序如下：
prerm --> preinst --> postrm --> postinst
4、注意事项
作为一名维护人员，你应当避免手工编辑维护者脚本，因为它们常存在各种问题。如果你不听劝告，自己为一个软件包创建并定制了维护者脚本，你必须保证不仅测试 install 和 upgrade，还应测试 remove 和 purge。
如果软件包使用了这些需要严格测试的 maintainer scripts，请确保不仅测试 install，还要测试 remove、purge 和 upgrade。很多 maintainer scripts 的 Bug 都显现于卸载或彻底删除软件包时。整个测试过程应按照以下操作序列完成：
● 如果可能，安装前一个版本的软件包；
● 从前一个版本升级软件包；
● 降级软件包到前一个版本(可选)；
● 彻底删除该软件包；
● 全新安装该软件包；
● 卸载该软件包；
● 再次安装该软件包；
● 彻底删除该软件包。
二、配置文件列表 Conffiles
1、基本描述
这部分是对 Debian 包的一些拓展知识。那么什么是 Conffiles？Conffiles 是一个配置文件列表(通常放在“/etc”中)，当包升级时，包管理系统不会覆盖这些配置文件。这确保了这些文件内容的本地值将被保留，这是一个关键特性，可以在运行的系统上对包进行就地升级。
要确定在升级期间保存哪些文件，请运行“dpkg --status package”查看 Conffiles 下的内容。
Conffiles 的作用就是在软件包升级时，不同于其他文件只需要简单的暴力覆盖即可，放置于“ /etc”下的(配置)文件需要需要特殊考虑，是保留旧配置还是使用新配置，所以有了这个特殊的行为。
经常会遇到修改后的配置文件，在软件包升级时，出现如下询问窗口：
通过对 nginx-common 的 Deb 包解压，可以看到有 Conffiles 文件，里面存放的都是要放到“/etc”下的文件。
2、原理解析
首先，Conffile 指的是 Conffiles 文件中维护的/etc 下的任一文件，在使用“dpkg”安装 Deb 包时（apt/aptitute 同理），涉及文件的三个 hash 值（这里加个简称）：
01 hash_real：某 Conffile 文件的实际 hash
02 hash_old：某 Conffile 在旧版本安装时维护的 hash（维护在 /var/lib/dpkg/status 文件中，可通过命令 dpkg --status查看指定包的 Conffiles）
03 hash_new：某 Conffile 在即将安装的新版本中的 hash
大致的逻辑如下：
- 首先对比 hash_old 和 hash_new，如果相同，则保持原样（这个就是开始我遇到的问题，某个被误删掉的 Conffile，在新旧版本未变更，所以保持原样，也就是继续不存在）；
- 如果 Conffile 不存在且配置了 --force-confmiss，则会将文件重新安装上（这个就是上面遇到问题的解决方法）；
- 判断 hash_real 和 hash_old 是否一致，不一致则标识为“useredited”状态，即用户修改了 Conffile；
- 判断 hash_real 和 hash_new 是否一致，不一致则标识为 distedited 状态，即软件包升级会修改 Conffile；
- 然后进入 prompt 环节，也就是依据这些状态和 dpkg 的选项判断是否交互式询问是否覆盖或直接变更；
- 如果用户未修改 Conffile，且软件包升级会变更此文件，则任何 --force- 选项都无用，会自动更新 Conffile；
- 如果用户修改了 Conffile，且软件包升级不会变更此文件，则可以通过 --force-confask 进入提示是使用旧配置还是新配置；
- 如果用户修改了 Conffile，且软件包升级会变更此文件，则默认是 Confask 的行为，此时也可以通过“confold/confnew/confdef”来取消询问的步骤。
3、总结
对于 Deb 包升级时文件的更新机制，dpkg 有一套默认的方案：所有放到“/etc”目录下的文件都被归类为 Conffile，此类文件的升级方式大概如下：
- 如果用户未修改 Conffile，且软件包升级会变更此文件，会自动更新 Conffile；
- 如果用户修改了 Conffile，且软件包升级不会变更此文件，deb 包升级时不会更新该文件，保存用户修改的状态；
- 如果用户修改了 Conffile，且软件包升级会变更此文件，则默认是 confask 的行为，安装时会询问用户是使用最新的文件还是用户修改过的文件；
所以 Deb 包的开发者要注意这个规范，将需要保留用户配置的文件放“/etc”目录。
以上就是《Debian包的潜规则（脚本篇）》的全部内容，如果大家有疑问或任何建议，欢迎留言告诉我们~
本文来稿：麒麟团队 庞毅