On Sun, Nov 4, 2012 at 8:26 PM, Roger Leigh <[email protected]> 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 <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
