[Buildd-tools-devel] schroot question

[Roger Leigh]

On Sun, Jan 18, 2009 at 01:53:35PM -0500, Steven Hirsch wrote:
> On Sat, 17 Jan 2009, Roger Leigh wrote:
>
>> On Sat, Jan 17, 2009 at 02:24:20PM -0500, Steven Hirsch wrote:
>>> On Sat, 17 Jan 2009, Roger Leigh wrote:
>>>
>>>>> If it is not imminent, I'd like to implement a sort of
>>>>> init-script facility that runs in the actual process space of the user's
>>>>> chroot-ed session.
>>>>
>>>> I'll be happy to consider any patches or suggestions you have to do this
>>>> as an interim measure.
>>>
>>> I'll see what I can come up with.  To avoid a lot of wheel-reinvention,
>>> can you give me a hand-waving idea of where you have primitives I can
>>> steal to do this?  I'm thinking the framework that runs the setup.d
>>> scripts might be easily adaptable.
>
>> The setup.d mechanism is the same as run-parts(8), which executes all the
>> scripts in a directory, except it's all done in C++ by the run_parts class
>> (sbuild/sbuild-run-parts.h) which gets used by the session class
>> (sbuild/sbuild-session.cc in setup_chroot).  This function (you can ignore
>> most of the top half) sets up the environment and a run_parts object, then
>> forks and runs all the child processes.  You can probably copy most of the
>> ideas in here.
>>
>> You need to do the run_parts in run_impl() just before the run_chroot()
>> call, I suggest as a separate method call at this point.  You'll also need
>> to look at run_child() to see how to chroot and chdir, and set up things
>> (but since you're staying as root, you can skip most of it).  Essentially,
>> combining the relevant parts of these two methods into a new one which
>> just chroots, chdirs and calls run_parts will do the job.
>>
>> One point to note: The setup scripts will need to be *inside* the chroot
>> so that you can run them once inside, otherwise they will not be
>> accessible.  If you want to store them in /etc/schroot/something.d
>> (which would be nice), you'll need to come up with a strategy to copy
>> that directory inside the chroot e.g. with a setup.d script, or else
>> put them all inside by hand (but this is less ideal for maintaining a
>> large number of chroots).
>
> Ok, code speaks louder than words.  Here is a quickly hacked-up patch 
> that executes scripts from /etc/schroot/init.d in the chroot environment. 
>  It runs them with the arg of 'start' before forking the user session and 
> then with the arg of 'stop' after that session exits.

[...]

> Your comments appreciated.  Again, this was merely a quick hack as  
> proof-of-concept.

Many thanks!

I have had a quick look through and I do like it.  I'll need to go
through it more methodically before I have some proper comments; I
probably won't have time until Tuesday night, I'm afraid.  However,
it all looked sensible and well written.

The only initial comment I have is how you get the scripts into the
chroot (I think I already mentioned that, above).  However, this is
not important at this stage.

I'll try to get some proper feedback to you as soon as I have some
free time to devote to it.


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/20090118/b2d4b60b/attachment.pgp