[buildd-tools-devel] Bug#579387: Bug#579387: schroot: Please allow to use variables in default/fstab

[Roger Leigh]

Hi Mike,

On Tue, Apr 27, 2010 at 03:58:49PM +0200, Mike Hommey wrote:
> I'm currently using the new unionfs support in schroot, which is an awesome
> addition, but it would be useful for my setup to be able to specify variables
> in some places of the fstab, so that I don't need to write extra setup
> scripts.

OK.  It's good to know it's all working correctly!

> Currently, I'm removing /home from the default fstab and mount it later with
> custom unionfs setup, and I also bind mount /var/cache/apt/archives from the
> original chroot, so that it is not part of the unionfs.

So you have both the chroot rootfs /and/ /home as separate unions?
Or do they share the same union overlay?

> It would be much simpler for me (and other users, for that matter), to be able
> to specify, say:
> 
> /home /home aufs br:${CHROOT_UNION_OVERLAY_DIRECTORY}/home:/home=ro 0 0
> ${CHROOT_DIRECTORY}/var/cache/apt/archives /var/cache/apt/archives none rw,bind 0 0
> 
> (though in my case, there would still be a problem, as
> ${CHROOT_UNION_OVERLAY_DIRECTORY}/home doesn't exist at first ; does
> schroot-mount create mount points when they don't exist ?)

Yes, missing mountpoints are created recursively.

The reason we don't /currently/ support variables in the configuration
files was for this reason: it exposes the internals of the setup
scripts, which would mean if we were to rename or alter their use in
the future, it could potentially break people's scripts.  For unionfs
at least, I wanted to be sure that things were working and stable and
wouldn't require further changes before allowing this.  So I'm not
opposed to the idea, I just want to make sure we have the possibility
of changing things down the line should be need to, and that we don't
break people's systems.  One nasty example would be if we remove the
variable and ${foo}/home evaluates to /home; for cleanup that could
purge one's data...

The other reason is purely technical; we read this file using
setmntent(3)/getmntent(3), which are the POSIX interfaces to
fstab(5) format files.  We would need to do the variable substitution
ourselves rather than allowing shell expansion.  One approach would
be to allow the shell setup script to evaluate and write out a
temporary file which we can then use.

I'm aware that aufs can do some fairly complex things, but in the
setup scripts we assume that (for the basic chroot) there's just
an read-only "underlay" and writable "overlay".  If that assumption
isn't always true, it would also be possible to teach the setup
scripts and configuration file to allow more sophisticated things.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100427/48c5b410/attachment.pgp>