On Thu, 13 Apr 2006 11:03:24 +1000 Anand Kumria wrote: > Long time, no speak.
Yeah. Was a nice couple of days back then :-) > On Wed, Apr 12, 2006 at 12:41:28PM +0200, Jonas Smedegaard wrote: > > Installing zeroconf in a chroot causes the daemon to be started > > there, disregarding policy.d settings. This causes the temporarily > > mounted /dev within the chroot to be unmountable until the daemon > > is located and killed. > > > > That's bad for lessdisks :-( > > Hmm, zeroconf doesn't start at system boot time but when an interface > is 'ifup'd. Yes, I noticed. > I am also wondering what would bring zeroconf into a chroot > environment. I hinted about lessdisks :-) Lessdisks is a tool to create and maintain an NFS rootfs for thin clients (and "half-thick" clients running apps locally). Putting zeroconf on such diskless clients means chroot'ing into their centrally stored rootfs and install the packages there. Another example is with generating real live-maintainable (as opposed to various read-only Knoppix-like) USB memory-stick Debian installations that is first created using cdebootstrap on another host machine, then unplugged and booted on the then independent (or not so independent, if using flashybrid to fit a live distro on only 128MB!) target machine. I use that for firewalls, an X11-based infoscreen, and is working on making a VoIP solution for my customers to have a hotline to me by simply plug in a USB stick which directly dials me when booting (perhaps useful as a digital "nanny" too?). > > I interpret policy as mandating daemons to always use invoke-rc.d > > and thus respect policy.d - but I am unsure about this > > interpretation, so lowering severity. Please raise it if you agree > > with my interpretation. > > I don't actually see a section in the online policy which talks about > policy.d -- however it has been a long time since I've read it. > Pointers welcome. §9.3.2: > Packages that include daemons for system services should place > scripts in `/etc/init.d' to start or stop services at boot time or > during a change of runlevel. §9.3.3: > Maintainers should use the abstraction layer provided by > the `update-rc.d' and `invoke-rc.d' programs to deal with initscripts > in their packages' scripts such as `postinst', `prerm' and `postrm'. Policy.d is implicit to those mandatory (for "system daemons", which I suspect your daemon is too) rc.d scripts. Read the manpage of invoke-rd.d, section "INIT SCRIPT POLICY" for details on policy.d. > There are a few options: > > - modify /etc/default/zeroconf and uncomment DISABLE Seems impossible to do conditionally only when chroot'ing, without interfering with concurrent NFS access to same rootfs. > > - create a file called /var/run/zeroconf.$IFACE.pid, which > will cause /etc/network/if-up.d/zeroconf to not run (well 0.8-2 > won't). Sounds ugly to try to chase whatever the package does and fake it. I suspect such approach isn't documented ;-) Also, this (and the above) means dealing specially with zeroconf. I would much prefer packages respecting a meta hinting about not starting daemons. > - determine why the chroot thinks that a network interface is > operational and fix that A network interface _is_ operational as the chroot is borrowing it from the host system. It is the assumption in postinst that starting additional daemons directly is ok, which is wrong imho. > - work out the reason that zeroconf is being brought into the > chroot and stop that from occuring Well, that was done on purpose - as I want the daemon in other situations than when initially chroot'ed, as explained above :-) > I think I've listed the options from easiest to hardest. I can't > think of a way of having zeroconf run via /etc/init.d/ and properly > operating (it is supposed to survive ifup/ifdown cycles). > > Your thoughts would be appreciated. How about simply avoid invoking the daemon in postinst. Or wrap it in a debconf question offering to start zeroconf immediately (with "no" as default!), at the same time informing that alternatively interfaces needs to be restarted before zeroconf is active. Adding hooks to ifupdown is ok, but assuming that interfaces already up was done using ifupdown (and can thus unconditionally be messed with directly) is wrong imho. Hope that all makes sense :-) - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n_r: http://www.shibumi.org/eoti.htm
pgp8v3M4FB0d8.pgp
Description: PGP signature
