常见掩护者脚本报错
“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 <package> 查看指定包的 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-<things> 选项都无用，会自动更新 Conffile；如果用户修正了 Conffile，且软件包升级不会变更此文件，则可以通过 --force-confask 进入提示是利用旧配置还是新配置；如果用户修正了 Conffile，且软件包升级会变更此文件，则默认是 Confask 的行为，此时也可以通过“confold/confnew/confdef”来取消讯问的步骤。3、总结
对付 Deb 包升级时文件的更新机制，dpkg 有一套默认的方案：所有放到“/etc”目录下的文件都被归类为 Conffile，此类文件的升级办法大概如下：
如果用户未修正 Conffile，且软件包升级会变更此文件，会自动更新 Conffile；如果用户修正了 Conffile，且软件包升级不会变更此文件，deb 包升级时不会更新该文件，保存用户修正的状态；如果用户修正了 Conffile，且软件包升级会变更此文件，则默认是 confask 的行为，安装时会讯问用户是利用最新的文件还是用户修正过的文件；以是 Deb 包的开拓者要把稳这个规范，将须要保留用户配置的文件放“/etc”目录。
以上便是《Debian包的潜规则（脚本篇）》的全部内容，如果大家有疑问或任何建议，欢迎留言见告我们~
本文来稿：麒麟团队 庞毅
