乐趣区

关于linux:干货分享-Debian包的潜规则脚本篇

咱们在装置一个 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 包的潜规则(脚本篇)》的全部内容,如果大家有疑难或任何倡议,欢送留言通知咱们~

本文来稿:麒麟团队 庞毅

退出移动版