[buildd-tools-devel] Bug#688750: Bug#688750: Bug#688750: schroot and autofs need better integration

[Reinhard Tartler]

On Sun, Nov 4, 2012 at 8:26 PM, Roger Leigh <rleigh at codelibre.net> wrote:
>
> On Sat, Nov 03, 2012 at 06:13:33PM +0100, Reinhard Tartler wrote:
> > On Sat, Nov 3, 2012 at 6:01 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> >
> > > I'm afraid I'm not an autofs expert by any means, so I can't give great
> > > feedback here.  Some questions:
> > >
> > > - what creates the new autofs map?  And what is it based upon?
> > >
> >
> > 71automount creates the new autofs map based on the contents of
> > /etc/auto.master
>
> OK.
>
> > - does this require any autofs-related stuff installed in the chroot,
> > >   or is it only required on the host?
> > >
> > No, the presented script uses everything from the host, so nothing
> > autofs-related is used nor required in the chroot
>
> OK.  I think this all looks absolutely fine, but some thoughts:
>
> I don't think this is something which should be run unconditionally,
> so I think it would be best if you added a configuration key such as
> autofs.enable=true and/or autofs.map=/etc/auto.master so that the
> map file would be configuable (if this makes sense).  These could be
> combined as a single key--if you don't specify a map, then it's not
> enabled.  These would appear in your script as AUTOFS_ENABLE and
> AUTOFS_MAP environment variables, respectively.  The names you use
> are entirely up to you--I just this this is something that should
> require the user to knowingly enable.  Or is schroot unusable without
> it?  Thoughts?


Yes, that seems like a good idea to me. AFAIUI, this requires changes
to the schroot binary, right?

>
>
> The other issue is locking: does any of this require restarting of
> the host autofs (maybe indirectly), or is the automount process for
> each chroot completely independent?  If it's completely isolated,
> that's great.  But if not, you might need to use a lock like 10mount
> does to lock the critical section in start_stop_autofs and/or the
> map creation.


I've done some additional research, and it seems that having
concurrent autofs5 daemons might cause trouble in some cases:
http://article.gmane.org/gmane.linux.kernel.autofs/4352 - I did not
notice any problems with that at my site, but as Ian points out, this
might be because in our setup we use indirect maps exclusively. Direct
maps is something that I did not test at all. But supporting direct
mount maps would require additional work anyways, as direct maps
contain absolute paths that need to be rewritten (i.e., have
CHROOT_PATH prefixed) as well!

Therefore, your suggestion to have an
autofs.map=/etc/schroot/auto.master switch fit excellent here. This
way, it remains the administrator's responsibility to ensure that only
working maps are listed here.  While I am not sure if we can support
all variants of nis or ldap maps, at least in my setup with indirect
mounts only, I would still be able to directly use /etc/auto.master.

What would avoid running a separate automount process would be to have
the hooks create the chroot specific auto.master in
/var/run/schroot/auto.master.d/$session-id-auto.master, and require
the user to add this to his /etc/auto.master:

  +dir:/var/run/schroot/auto.master.d

Instead of starting another instance of automount, the setup.d script
would then just restart automount. Note that this "dir" map-type is
available in autofs version 5.0.7 and later (i.e., just in time for
wheezy, but not available in squeeze, only squeeze-backports).

This approach would also allow supporting direct map mounts by placing
copies with the chroot prefix in them inside
/var/run/schroot/auto.master.d. Of course the rewritten auto.master
would reference these rewritten direct mount maps. Maybe this could be
implemented in addition with an extra schroot configuration option? I
think both modes make sense to support: While the one-instance
approach  does support indirect mounts, it also requires the user to
fiddle with his /etc/auto.master map, and is thus a bit more
complicated to setup.

Please tell me what you think about this.

>
> Portability: will this work with autofs on kfreebsd?  Or should the
> script be special-cased for linux platforms only?


it seems that there (currently) is no autofs package for kFreeBSD, so
no problem here :-)
cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539453

Seriously, the autofs package is pretty Linux-specific. I guess on
(k)FreeBSD, one would use the BSD "amd" (instead of autofs5)
http://www.freebsd.org/cgi/man.cgi?query=amd&sektion=8, but that does
not seem packaged in Debian. Btw, "amd" has a totally different syntax
compared to Linux autofs5, and has been removed from Debian in 2005.

>
> Also, if you're not using the standard autofs /var/run dirs, feel
> free to create /var/run/schroot/$session-id/ and place your autofs
> pidfile/config in there with an autofs prefix.


Great Idea, already incorporated into my thoughts above. I've used
/var/run because nowadays this is a symlink to /run, and thus
available in the chroot by default. But I do not see why that would be
necessary.

>
> How is system shutdown handled here?  Does this require all sessions
> to be ended in order to kill the autofs processes?  We could add a
> stop step similar to recover: shut down the chroot, but don't delete
> it, so that you can subsequently recover it.  This would also eliminate
> the need for the second script, since recovery will always run this
> prior to doing the recovery to clean up.


What happens during shutdown with open sessions? I guess all
processes, and this includes automount, get killed anyways, right?
Your question seems to indicate that this is not the case by default.
Can you perhaps elaborate here a bit more?

-- 
regards,
    Reinhard