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

[Roger Leigh]

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?

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.

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

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.

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.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800