共计 3736 个字符，预计需要花费 10 分钟才能阅读完成。
咱们在装置一个 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”下的 (配置) 文件须要须要非凡思考，是保留旧配置还是应用新配置，所以有了这个非凡的行为。
常常会遇到批改后的配置文件，在软件包降级时，呈现如下询问窗口：
Configuration file ‘/etc/default/nginx’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
* nginx (Y/I/N/O/D/Z) [default=N] ?
通过对 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 包的潜规则（脚本篇）》的全部内容，如果大家有疑难或任何倡议，欢送留言通知咱们~
本文来稿：麒麟团队 庞毅
