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

[Roger Leigh]

On Mon, Nov 05, 2012 at 12:20:32PM +0100, Reinhard Tartler wrote:
> On Sun, Nov 4, 2012 at 8:26 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> >
> > 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?

Not any more.  With 1.6.x, you can just define arbitrary keys in
the configuration file, and these are treated as "user data", and
passed through to the setup scripts.  It just sets them as
environment variables.  There are some restrictions on the naming
(must have a dot) so that you can't set keys in the main schroot
internal namespace, but you can otherwise set what you like.

You can also mark individual keys as being user-modifiable, and
then the user can override them with "-o foo.bar=baz" on the
command-line.  Probably not useful in this specific case, but
on the master branch you can e.g. use "-o unshare.net=true", and it
will set up a separate network for a specific command run in
the chroot.

> > 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!

OK.

> 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.

That sounds fine.

> 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.

Supporting different configurations with additional options is just
fine; it's easy to add additional keys to the configuration file:
just document them in the schroot.conf manual page, and then use
the resulting environment variables in your script.

> > 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.

This shouldn't normally be made available in the chroot.
I just suggested it as a place to store the schroot-specific
pidfiles etc. if the standard autofs places don't make sense.

> > 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?

Normally, schroot runs in a "single shot" mode.  That is, each
schroot invocation runs, does its job, and exits.  There's nothing
persistent about an open session except for the mounted filesystems.
The current strategy for recovery simply unmounts and remounts the
filesystems, and that's about it.  We handle shutdown simply by
letting the filesystems get umounted by the initscripts, and then
recover on startup by remounting everything (one can configure it
to end all sessions on shutdown and startup in /etc/default/schroot).

But the point I'm trying to make is that we currently only support
ending (i.e. deleting) sessions; we don't have a means of suspending
it for re-use after reboot.  That's something we'd need to add to
support autofs properly.  At least if "/etc/init.d/autofs stop"
doesn't kill all the schroot-related autofs processes.  We can
certainly add this; it's just not been needed until this point.
We just need to add an extra setup-script $STAGE value for
stopping in addition to setup-stop, such as setup-suspend, and have
it behave similarly to stop, but not actually remove the session,
so that it's recoverable later.


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