[Buildd-tools-devel] schroot question

[Roger Leigh]

On Sun, Jan 11, 2009 at 10:14:51AM -0500, Steven Hirsch wrote:

[Please keep the list in the CC]

> On Sun, 11 Jan 2009, Roger Leigh wrote:
>
>>> Can anyone explain how I can get an arbitrary sequence of commands to
>>> execute as root user _after_ the session and the new root location has
>>> been established?
>>
>> You do this in the chroot setup sequence in setup.d.  The early scripts
>> do the chroot creation and then mount filesystems, then do any tweaking
>> needed to set up the environment.  You can add extra scripts here to do
>> whatever you like.  I would suggest for your usage a script after 10mount
>> such as 11autofs would be appropriate.  This will be run just the once
>> when the session is created, and again at the session end.
>
> Perhaps I'm confused, but empirically I'm finding that the chroot has NOT 
> occurred at the point where setup.d runs its scripts.
>
> For example, I created a tiny '70test' script that does nothing more than 
> do a directory listing of /net, then started a chroot session with  
> debugging turned on.  70test reports the contents of /net as seen by the  
> root session.  When the chroot-ed prompt appears, I see what it actually  
> looks like to the session in the absence of autofs:  empty.

This is correct.  The setup script runs on the host.  The chroot is
accessible under $CHROOT_MOUNT_LOCATION.

>> Seeing as you are mounting things, I suggest copying 10mount and copying
>> what you see there.  See 00check for a complete list of environment
>> variables you can use, as well as the sbuild-setup(5) manual page.  Note
>> that 10mount /might/ automatically clean up for you; but I'm not
>> personally familiar with autofs so you might need to manually umount
>> and/or stop the autofs service.
>
> If I start automount manually using sudo inside the chroot, 10mount seems 
> to clean up.  Actually, it does too thorough a job by removing not only  
> the mount, but the $CHROOT/net mountpoint directly as well!

do_umount_all should run schroot-listmounts to get a list of the
mounted filesystems and then umount each one.  It doesn't remove
any mountpoints at that stage.  Is something else doing this?

>>  As for exec scripts, these run on the
>> host, so you'll need to chroot(8) to start a daemon inside the chroot
>> and/or use the environment provided to get the path to the chroot.
>
> And this is where I get VERY confused:  If I start outside the chroot in  
> that manner and specify a path into the session directory, why would this 
> make any difference to the chroot session?  In particular, what is the  
> relationship between the session keyed directories under /var/lib and 
> what I actually end up seeing in, e.g. /var/chroot/hardy/...  (hardy is 
> the name of my chroot)?  Are there _two_ levels of indirection occurring 
> here, e.g. chroot ---> /var/lib/<session> ---> root environment?

If your chroot in /var/chroot/... is the location=... parameter in
schroot.conf, then this directory will get bind mounted under
/var/lib/schroot/<session>.  This latter location is the one which
is chrooted into.

This indirection allows us to support multiple chroot "sources" such
as devices, LVM snapshots and zip/tar files in a uniform manner (they
all are unpacked/mounted under /var/lib/schroot/<session>.

>> Seeing that autofs is a kernel filesystem, it might not allow more than
>> once instance, but it might be as simple as mounting it on /net.  This
>> is also why you can't bind/rbind mount it, but you might try binding
>> /net directly, rather than its submounts.
>
> Fortunately, the kernel does easily support multiple automount instances. 
> The restriction is that they cannot nest in any manner and must be 
> totally disjoint in the target filesystem.

OK, that makes sense.  This restriction shouldn't be a problem for us
unless you create your chroot under /net.

> The documentation states that schroot will execute a login shell in your  
> chroot-ed home directory.  So, I created a dummy directory called  
> /home/start in /var/chroot/hardy and placed a single '.profile' in it.  
> When I start the session with 'schroot -d /home/start', this file does 
> NOT get run!  I had to hack /etc/profile to explicitly run it by adding:
>
> . ./.profile
>
> (I think I'm failing to understand how schroot determines one's home  
> directory.  I'd have thought the argument to '-d' would be taken as the  
> home directory?)

Your home directory is determined using the same mechanism as for a
normal login.  i.e. $HOME and pass.pw_dir in the system passwd file.
The -d option only changes the directory the command is run in, by
chdir()ing to it.  This is independent of the $HOME/passwd home
directory, though you can use the -p option to pass $HOME through.

See set_user in sbuild/sbuild-auth.cc and
get_login_directories and run_child in sbuild/sbuild-session.cc
for more information.  

> Having done that, I put a sudo-ed command in there to start the  
> automounter (since I knew chroot would be established at that juncture).  
> This worked fine.
>
> Then I added a following line to set HOME in the environment to the  
> now-available automount location (/net/home/hirsch) and do a cd to it.  
> Now things really get weird:  It starts the automounter fine, but  
> immediately fails with a complaint that the directory does not exist.  
> Yet, when it next returns to the command prompt I can type 'cd' and end 
> up there without incident.  ???
>
> A race condition of some sort?

Maybe a delay in the userspace part of the automounter to work?
If it runs parallel to the user's script/shell, it could well race.

> Sorry for the million questions, but the structural aspects of the target 
> chroot environment are giving me a headache.

It's not a problem--that's what this list is for.


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