On Sat, Nov 03, 2012 at 06:13:33PM +0100, Reinhard Tartler wrote: > On Sat, Nov 3, 2012 at 6:01 PM, Roger Leigh <rle...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
