这对我来说是个问题.
我发现自己需要管理用于构建LXC容器的模板.有几个容器,每个容器对应一个Debian或Ubuntu版本. (还有基于Red Hat的容器,但它们在这里不相关.)
/var/lib/libvirt/filesystems/debian6_template /var/lib/libvirt/filesystems/debian7_template /var/lib/libvirt/filesystems/ubuntu1004_template /var/lib/libvirt/filesystems/ubuntu1204_template
偶尔我会发现模板缺少包或需要进行其他更改,因此我将chroot到它们来安装包.不幸的是,当我这样做时,我最终得到了包裹服务的几个副本！
举个例子,我发现模板没有syslog守护进程,所以我安装了一个：
for template in /var/lib/libvirt/filesystems/{debian,ubuntu}*_template; do
chroot $template apt-get install rsyslog
done
并迅速完成了四个rsyslog运行副本.更不用说两份exim4了.哎呀！
我在某个地方读过(虽然我现在再也找不到它),它不应该在chroot中运行时启动服务,但这显然不会发生在这里.
一个可能可行的nasty hack调用暂时替换实际启动服务的各种命令,例如start-stop-daemon和initctl,尽管这比我真正想做的工作要多得多.如果我别无选择,不过……
这里理想的解决方案是基于Debian的系统停止做这个废话,但是失败了,也许是apt-get的一个模糊或无证的命令行选项？
如果不清楚,我真的想保留与模板之外的模板管理相关的任何内容,如果可能的话.
A package’s maintainer scripts are supposed to only interface with the init system by means of invoke-rc.d,update-rc.d and the LSB init script headers…
invoke-rc.d will,before taking its action,check whether
/usr/sbin/policy-rc.d is executable,will call it with the respective
service name and the current runlevel number on its command line and
act according to its exit code. For example,a return value of 101
will prevent the planned action from being taken. This includes the
automated start of the service upon package installation as well as
the stop of the service on package removal and reduces the
stop-upgrade-restart ritual during package upgrades to just performing
the upgrade which might leave the old version of the service running
由于您不希望任何服务启动,因此您的policy-rc.d脚本可以很简单
#!/bin/sh exit 101
这是pbuilder和Docker的mkimage-debootstrap等工具使用的技术.
不幸的是,这种技术does not work with Ubuntu chroots.与upstart init系统集成的软件包在安装期间调用/usr/sbin / initctl而不是invoke-rc.d,而initctl不会参考policy-rc.d. According to upstart’s author解决方法是将/ sbin / initctl替换为chroot中的/ bin / true符号链接.你可以在mkimage-debootstrap中看到这个,他们也可以
dpkg-divert --local --rename --add /sbin/initctl ln -sf /bin/true sbin/initctl
