NEWS

新闻

了解优麒麟最新资讯,关注社区和产品动态。

NEWS

Learn about the latest news.

干货分享 - Debian包的潜规则(脚本篇)

2021-12-23 15:56:18
Document

          我们在安装一个 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

          大致的逻辑如下:

1. 首先对比 hash_old 和 hash_new,如果相同,则保持原样(这个就是开始我遇到的问题,某个被误删掉的 Conffile,在新旧版本未变更,所以保持原样,也就是继续不存在);

2. 如果 Conffile 不存在且配置了 --force-confmiss,则会将文件重新安装上(这个就是上面遇到问题的解决方法);

3. 判断 hash_real 和 hash_old 是否一致,不一致则标识为“useredited”状态,即用户修改了 Conffile;

4. 判断 hash_real 和 hash_new 是否一致,不一致则标识为 distedited 状态,即软件包升级会修改 Conffile;

5. 然后进入 prompt 环节,也就是依据这些状态和 dpkg 的选项判断是否交互式询问是否覆盖或直接变更;

6. 如果用户未修改 Conffile,且软件包升级会变更此文件,则任何 --force-                    选项都无用,会自动更新 Conffile;

7. 如果用户修改了 Conffile,且软件包升级不会变更此文件,则可以通过 --force-confask 进入提示是使用旧配置还是新配置;

8. 如果用户修改了 Conffile,且软件包升级会变更此文件,则默认是 Confask 的行为,此时也可以通过“confold/confnew/confdef”来取消询问的步骤。

3、总结

          对于 Deb 包升级时文件的更新机制,dpkg 有一套默认的方案:所有放到“/etc”目录下的文件都被归类为 Conffile,此类文件的升级方式大概如下:

          1. 如果用户未修改 Conffile,且软件包升级会变更此文件,会自动更新 Conffile;

          2. 如果用户修改了 Conffile,且软件包升级不会变更此文件,deb 包升级时不会更新该文件,保存用户修改的状态;

          3. 如果用户修改了 Conffile,且软件包升级会变更此文件,则默认是 confask 的行为,安装时会询问用户是使用最新的文件还是用户修改过的文件;

          所以 Deb 包的开发者要注意这个规范,将需要保留用户配置的文件放“/etc”目录。


          以上就是《Debian包的潜规则(脚本篇)》的全部内容,如果大家有疑问或任何建议,欢迎留言告诉我们~

本文来稿:麒麟团队 庞毅