Debian Bug report logs - #579387
schroot: Please allow to use variables in default/fstab

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh+reportbug@glandium.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: schroot: Please allow to use variables in default/fstab

Date: Tue, 27 Apr 2010 15:58:49 +0200

Package: schroot
Version: 1.4.1-2
Severity: wishlist

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.

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.

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

Cheers,

Mike

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.40 1.40.0-6+b1      filesystem operations (portable pa
ii  libboost-program-option 1.40.0-6+b1      program options library for C++
ii  libboost-regex1.40.0    1.40.0-6+b1      regular expression library for C++
ii  libboost-system1.40.0   1.40.0-6+b1      Operating system (e.g. diagnostics
ii  libc6                   2.10.2-7         Embedded GNU C Library: Shared lib
ii  libgcc1                 1:4.5-20100404-1 GCC support library
ii  liblockdev1             1.0.3-1.4        Run-time shared library for lockin
ii  libpam0g                1.1.1-2          Pluggable Authentication Modules l
ii  libstdc++6              4.5-20100404-1   The GNU Standard C++ Library v3
ii  libuuid1                2.16.2-0         Universally Unique ID library
ii  schroot-common          1.4.1-2          common files for schroot

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-module <none>     (no description available)
ii  debootstrap                   1.0.22     Bootstrap a basic Debian system
ii  lvm2                          2.02.62-1  The Linux Logical Volume Manager
ii  unzip                         6.0-4      De-archiver for .zip files

-- Configuration Files:
/etc/schroot/default/fstab changed [not included]
/etc/schroot/schroot.conf changed [not included]

-- no debconf information

Message #10 received at 579387@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Mike Hommey <mh+reportbug@glandium.org>, 579387@bugs.debian.org

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

Date: Tue, 27 Apr 2010 16:45:04 +0100

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 579387@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 579387@bugs.debian.org

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

Date: Wed, 28 Apr 2010 11:18:58 +0200

On Tue, Apr 27, 2010 at 04:45:04PM +0100, Roger Leigh wrote:
> 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?

They share the same overlay, though they have to be separate mounts.

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

OTOH, custom scripts also can use these variables, and break when the
variables names change.

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

Note that in the /home case in my usecase, I'm only really interested
in having the same setup for the root directory and /home, as they are
separate mount points and as such the default setup doesn't use a union
for /home. A special syntax for that case would work for me, too.

Mike

Send a report that this bug log contains spam.