Daemons in schroot or how to start chroot automatically

[Ramon Hofer]

Hi all

I have some questions about starting daemons in a chroot environment or
rather about starting schroot on bootup.
The reason I want to do this is to clean up my server. It's a Squeeze
with an AMD64 kernel from backports. Some packages are from testing which
gives me problems because of dependencies that can't be fullfilled:
sabnzbdplus from testing depends on python so I can't install build-
essential...

So far I was able to setup a chroot with schroot and installed sid in it.
What I did:

Mounted a 327G partition to /srv
and created a new directory /srv/chroot/sid

Edited /etc/schroot/schroot.conf

[sid]
description=Debian sid (unstable)
directory=/srv/chroot/sid
users=hoferr
groups=hoferr
root-groups=root
aliases=unstable,default

Installed sid
$ sudo debootstrap sid /srv/chroot/sid/ http://ftp.ch.debian.org/debian/

Entered the chroot with
$ sudo schroot -p -c sid

Installed locales and reconfigured them. I also installed vim.
I noticed that auto-completion isn't working.
What packages should I install? Is auto-complete-el sufficient or is
there a meta package for some base system packages?

In the chroot I have created a new user called hoferr and am now able to
login without root privilieges.
But in there sudo is missing. Maybe this can be resolved by installing
the correct base system meta package mentioned above?


Aside some missing packages everything looks promising.
To get back to my main reason of doing this: After stopping the "old"
sabnzbdplus can I just install the chroot sabnzbplus with the "normal"
home partition mounted? It will probably start automatically when the
chroot is started and I should be able to access its web service from the
LAN.

But how can I start the chroot on bootup automatically. i probably just
have to write a init.d script and do a update.rc.

Is this enough as init.d script?
http://pastebin.com/raw.php?i=hHSvG30v

Or should I use the skeleton?
If yes what are the Required-Start/Stop variables?
And should I then just create a DAEMON script in /usr/sbin with the
following content?

#! /bin/sh
schroot -c sid





Best regards
Ramon


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/ju8usi$41g$1...@dough.gmane.org

[Bob Proulx]

Ramon Hofer wrote:
> Installed sid
> $ sudo debootstrap sid /srv/chroot/sid/ http://ftp.ch.debian.org/debian/

I haven't submitted a bug yet but I always have problems with sysvinit
postinst depending upon ischroot and ischroot getting it wrong and
that leaving a broken /run - /var/run behind. You might hit that too.

You should set up a usr/sbin/policy-rc.d script in your chroot.
Something like this:

#!/bin/sh
exit 101

That will prevent installations from starting daemons in the chroot.
Or if there is a daemon that you wish to start in the chroot then you
could use a script such as this:

#!/bin/sh
# /usr/sbin/policy-rc.d [options] <initscript ID> <actions>
# [<runlevel>]
# /usr/sbin/policy-rc.d [options] --list <initscript ID> [<runlevel>
# ...]
# See /usr/share/doc/sysv-rc/README.policy-rc.d for documentation.
# Live example found in ps:
# /bin/sh /usr/sbin/policy-rc.d x11-common stop unknown
while [ $# -gt 0 ]; do
case $1 in
--list) exit 101 ;;
--quiet) shift ;;
-*) shift ;;
cron) exit 0 ;;
nullmailer) exit 0 ;;
*) exit 101 ;;
esac
done
exit 101

See /usr/share/doc/sysv-rc/README.policy-rc.d.gz for documentation.

> Entered the chroot with
> $ sudo schroot -p -c sid
>
> Installed locales and reconfigured them. I also installed vim.

Seems reasonable so far. Some packages will require /proc. Some will
also require /dev. Some will require other things.

> I noticed that auto-completion isn't working.
> What packages should I install? Is auto-complete-el sufficient or is
> there a meta package for some base system packages?

apt-get install bash-completion

> In the chroot I have created a new user called hoferr and am now able to
> login without root privilieges.
> But in there sudo is missing. Maybe this can be resolved by installing
> the correct base system meta package mentioned above?

apt-get install sudo

> Aside some missing packages everything looks promising.

The premise of debootstrap is that it installs a very small system.
If you want something installed you are going to need to install it
yourself.

Perhaps you should consider using 'tasksel' to install a standard task
set of packages. That would pull in a lot. I prefer the small system
and only install what I need to install. But if you don't like that
then you may always install a larger set all at once.

> To get back to my main reason of doing this: After stopping the "old"
> sabnzbdplus can I just install the chroot sabnzbplus with the "normal"
> home partition mounted?

Yes.

> It will probably start automatically when the chroot is started

Wait! Hold it right there. What do you mean "when the chroot is
started"? Unless you are doing something "magical" there isn't
anything that "starts a chroot". I think right here there is a huge
misunderstanding of chroots. If you want a particular daemon to start
in the chroot then you will need to ensure that it is started.

> and I should be able to access its web service from the LAN.

Yes.

> But how can I start the chroot on bootup automatically. i probably just
> have to write a init.d script and do a update.rc.

Yes. By creating an init script.

> Is this enough as init.d script?
> http://pastebin.com/raw.php?i=hHSvG30v

No. That has a misunderstanding about this part:

start)
echo "Starting chroot sid"
schroot -c sid

But that would simply start an interactive shell there. That isn't
what you want at all.

> Or should I use the skeleton?

Yes. Please copy the skeleton and use it.

> And should I then just create a DAEMON script in /usr/sbin with the
> following content?
>
> #! /bin/sh
> schroot -c sid

No. That isn't what you want.

> If yes what are the Required-Start/Stop variables?

I would use the same header as in the original script.

For example I run 'nullmailer' in the chroot. Therefore I create an
initscript like this following. And I install it using update-rc.d.
Copy it to /etc/init.d/chroot-nullmailer and then install it with:

update-rc.d chroot-nullmailer defaults

In a chroot I usually run nullmailer and cron plus whatever else I
wanted the chroot for, such as apache.

Also there are a zillion other ways to do it too. This is just one
way.

Bob

#! /bin/sh
# nullmailer start/stop the nullmailer deamon in chroot
#
### BEGIN INIT INFO
# Provides: chrootnullmailer
# Required-Start: $remote_fs $syslog $network
# Required-Stop: $remote_fs $syslog $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
#
# Written by Bob Proulx <b...@proulx.com>
#
# update-rc.d chroot-nullmailer defaults

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=nullmailer
CHROOTS="sid"

set -e

for ROOT in $CHROOTS ; do
rootdir=/srv/chroot/$ROOT
case $1 in
start)
chroot $rootdir /etc/init.d/$NAME start
;;
stop)
chroot $rootdir /etc/init.d/$NAME stop
;;
reload)
chroot $rootdir /etc/init.d/$NAME reload
;;
restart)
chroot $rootdir /etc/init.d/$NAME restart
;;
force-reload)
chroot $rootdir /etc/init.d/$NAME force-reload
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac
done

exit 0

[Roger Leigh]

On Thu, Jul 19, 2012 at 09:28:52PM -0600, Bob Proulx wrote:
> Ramon Hofer wrote:
> > Installed sid
> > $ sudo debootstrap sid /srv/chroot/sid/ http://ftp.ch.debian.org/debian/
>
> I haven't submitted a bug yet but I always have problems with sysvinit
> postinst depending upon ischroot and ischroot getting it wrong and
> that leaving a broken /run - /var/run behind. You might hit that too.

If this is still happening, please file a serious bug against
ischroot (debianutils IIRC) with the details of your system.
It should not be getting it wrong in the simple case of a
chroot.


Thanks,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120720090...@codelibre.net

[Roger Leigh]

On Thu, Jul 19, 2012 at 12:34:26PM +0000, Ramon Hofer wrote:
> I have some questions about starting daemons in a chroot environment or
> rather about starting schroot on bootup.
> The reason I want to do this is to clean up my server. It's a Squeeze
> with an AMD64 kernel from backports. Some packages are from testing which
> gives me problems because of dependencies that can't be fullfilled:
> sabnzbdplus from testing depends on python so I can't install build-
> essential...
>
> So far I was able to setup a chroot with schroot and installed sid in it.
>

> [sid]
> description=Debian sid (unstable)
> directory=/srv/chroot/sid
> users=hoferr
> groups=hoferr
> root-groups=root
> aliases=unstable,default

set type=directory here

> Installed locales and reconfigured them. I also installed vim.
> I noticed that auto-completion isn't working.
> What packages should I install? Is auto-complete-el sufficient or is
> there a meta package for some base system packages?

You could run "tasksel" and install the "standard" system I guess.

> In the chroot I have created a new user called hoferr and am now able to
> login without root privilieges.
> But in there sudo is missing. Maybe this can be resolved by installing
> the correct base system meta package mentioned above?

You could install sudo. But why? This is what schroot /is/
(chroot + sudo). If you want to do stuff as root inside the chroot,
just add yourself to root-groups/root-users.

> Aside some missing packages everything looks promising.
> To get back to my main reason of doing this: After stopping the "old"
> sabnzbdplus can I just install the chroot sabnzbplus with the "normal"
> home partition mounted? It will probably start automatically when the
> chroot is started and I should be able to access its web service from the
> LAN.
>
> But how can I start the chroot on bootup automatically. i probably just
> have to write a init.d script and do a update.rc.
>
> Is this enough as init.d script?
> http://pastebin.com/raw.php?i=hHSvG30v

No. You need LSB dependencies (you'll need
Required-Start: $local_fs $remote_fs $network $syslog schroot
and the same for Required-Stop).
You will also need to start an schroot /session/, and then start
up the services inside that session. And you'll need to stop the
services and end the session on stop.

Note that schroot 1.6.x (in unstable) have a new facility for
starting and stopping services inside the chroot. In schroot.conf,
add "setup.services=service1,service2" etc. It won't handle LSB
ordering or anything advanced though--it just runs invoke-rc.d in
order on the list when you start a session, and stop in reverse
order on ending the session. Using this facility would avoid the
need to manually stop and start services in your init script; you'd
just need to create and end a session. Whether that's useful or
not depends on your specific needs, but it's there if you want to
try it out.


Regards,

Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120720094...@codelibre.net

[Ramon Hofer]

Thanks for your answer, Bob!

The program I'd like to jail is a daemon which means I should use the
longer script. Unfortunately I couldn't find anything about the initscript
ID in the policy-rc.d documentation.

Can I just copy/paste the script in my case to
/srv/chroot/sid/usr/sbin/policy-rc.d
and make it executable?

I found this:
"There is a provision for a "local initscript policy layer" (...),
which allows the local system administrator to control the behaviour of
invoke-rc.d for every initscript id and action"
http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

So this script controls the way and order the daemons are started?
Is it correct that without it I wouldn't be able to start the daemon from
outside the chroot because of this:

"Can I run a dæmons in a chroot?
(...) Unfortunately, this means schroot detects that the program
exited (the dæmon is a orphaned grandchild of this process) and it
then ends the session. (...)"
http://manpages.ubuntu.com/manpages/natty/man7/schroot-faq.7.html

>> Entered the chroot with $ sudo schroot -p -c sid
>>
>> Installed locales and reconfigured them. I also installed vim.
>
> Seems reasonable so far. Some packages will require /proc. Some will
> also require /dev. Some will require other things.

Oh, yes, I read about that but I forgot to update my /etc/fstab and mount
the directories. Should I also remount /sys?

Or is there a better way to do this? I mean can schroot handle it
directly so that when I create a new jail or copy one that the
directories are remounted there as well?

>> I noticed that auto-completion isn't working.
>> What packages should I install? Is auto-complete-el sufficient or is
>> there a meta package for some base system packages?
>
> apt-get install bash-completion
>
>> In the chroot I have created a new user called hoferr and am now able
>> to login without root privilieges.
>> But in there sudo is missing. Maybe this can be resolved by installing
>> the correct base system meta package mentioned above?
>
> apt-get install sudo

Thanks!

Btw I had to set the password for my user inside the chroot to be able to
use sudo.

>> Aside some missing packages everything looks promising.
>
> The premise of debootstrap is that it installs a very small system. If
> you want something installed you are going to need to install it
> yourself.
>
> Perhaps you should consider using 'tasksel' to install a standard task
> set of packages. That would pull in a lot. I prefer the small system
> and only install what I need to install. But if you don't like that
> then you may always install a larger set all at once.

Aha, the base system option of the Debian installer uses tasksel.

I think I'll try with the minimal installation as well and when I run
into serious problems I might install the rest with tasksel. It makes to
not install too much because I won't work in the chroot. So probably even
sudo and bash-completion are too much...

Btw In the jail I also did `dpkg-reconfigure tzdata` to set the time zone
(it was set to "Etc"). But I don't know if that makes any difference...

>> To get back to my main reason of doing this: After stopping the "old"
>> sabnzbdplus can I just install the chroot sabnzbplus with the "normal"
>> home partition mounted?
>
> Yes.

I could also just use /etc/schroot/default/copyfiles and put the config
directory .sabnzbd onto it. Like that I still have the configuration file
outside of the jail in my home dir and when I retsart the daemon the jail
gets restarted as well and the config dir is copied again.

Btw when I think about it: schroot manages the copying of the files. So
when I create a new jail the files are copied in there as well.
Is it possible to have a separate copyfiles for my sid jail like /etc/
schroot/sid/copyfiles instead of /etc/schroot/default/copyfiles?

And the "global" configuration should be possible for the remounts as
well. There isn't any configuration for global remounts is there?

>> It will probably start automatically when the chroot is started
>
> Wait! Hold it right there. What do you mean "when the chroot is
> started"? Unless you are doing something "magical" there isn't anything
> that "starts a chroot". I think right here there is a huge
> misunderstanding of chroots. If you want a particular daemon to start
> in the chroot then you will need to ensure that it is started.

I thought that starting a chroot is like starting a virtual machine. But
it's probably more like directly starting a program (in my case sabnzbd+)
for which schroot starts the jail?


> (...)

>
> I would use the same header as in the original script.

Unfortunately the init.d script for sabnzbd is quite cmplex and I don't
understand exactly what I have to change.

Probably I can just change the beginning which is.

DAEMON=/usr/bin/sabnzbdplus
SETTINGS=/etc/default/sabnzbdplus

([ -x $DAEMON ] && [ -r $SETTINGS ]) || exit 0

DESC="SABnzbd+ binary newsgrabber"
DEFOPTS="--daemon"
PYTHONEXEC="^$(sed -n '1s/^#\!\([a-z0-9\.\/]\+\)\(.*\)/\1(\2)?/p'
$DAEMON)"
PIDFILE=/var/run/sabnzbdplus.pid
SETTINGS_LOADED=FALSE

Here's the whole script:
http://pastebin.com/raw.php?i=6PKD1JP5

Since /usr/bin/sabnzbdplus is a python script python should probably also
be started in the jail.

> For example I run 'nullmailer' in the chroot. Therefore I create an
> initscript like this following. And I install it using update-rc.d.
> Copy it to /etc/init.d/chroot-nullmailer and then install it with:
>
> update-rc.d chroot-nullmailer defaults
>
> In a chroot I usually run nullmailer and cron plus whatever else I
> wanted the chroot for, such as apache.

Your script is much more understandable to me.

I have done it as follows:

Inside the chroot I created usr/sbin/policy-rc.d with your longer script
from above and made it executable.

Outside the chroot I have stopped sabnzbd+
Remounted /proc, /dev, /etc/default/sabnzbdplus, /home/hoferr/.sabnzbd
and the download location. (I couldn't use /etc/schroot/default/copyfiles
because the directory wasn't copied.)

Inside the chroot installed sabnzbd+ and was able to connect to it's
webinterface.

Outside chroot I created the sid-sabnzbd script
http://pastebin.com/raw.php?i=Lamy4K4a
Thanks for your example :-)
Updated-rc.d and removed sabnzbdplus.
Now I can `sudo /etc/init.d/sid-sabnzbdplus start / stop / ...` :-)


Thanks again for your help!

Best regards
Ramon


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jubhuo$b07$1...@dough.gmane.org

[Ramon Hofer]

On Fri, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:

> On Thu, Jul 19, 2012 at 12:34:26PM +0000, Ramon Hofer wrote:
>> I have some questions about starting daemons in a chroot environment or
>> rather about starting schroot on bootup.
>> The reason I want to do this is to clean up my server. It's a Squeeze
>> with an AMD64 kernel from backports. Some packages are from testing
>> which gives me problems because of dependencies that can't be
>> fullfilled: sabnzbdplus from testing depends on python so I can't
>> install build- essential...
>>
>> So far I was able to setup a chroot with schroot and installed sid in
>> it.
>>
>> [sid]
>> description=Debian sid (unstable)
>> directory=/srv/chroot/sid users=hoferr groups=hoferr root-groups=root
>> aliases=unstable,default
>
> set type=directory here

That sounds great what I can read in the schroot.conf manpage:
"In consequence, filesystems such as /proc are not mounted in
plain chroots; it is the responsibility of the system
administrator to configure such chroots by hand, whereas
directory chroots are automatically configured."

This means I can remove the remounts of /proc, /dev and /sys to /srv/
chroot/sid/... from my /etc/fstab?

But when I try this out and comment the proc and dev remounts and restart
the system sabnzbd+ isn't started automatically and when I try it when
the init.d script manually I get:
[....] Starting SABnzbd+ binary newsgrabber:start-stop-daemon: nothing
in /proc - not mounted?
failed!

>> In the chroot I have created a new user called hoferr and am now able
>> to login without root privilieges.
>> But in there sudo is missing. Maybe this can be resolved by installing
>> the correct base system meta package mentioned above?
>
> You could install sudo. But why? This is what schroot /is/ (chroot +
> sudo). If you want to do stuff as root inside the chroot,
> just add yourself to root-groups/root-users.

Or start it with `sudo schroot -p -c sid`.

I'm still using version 1.4.19. But this feature sounds very good!

Btw I have accidentally run `schroot -v` instead -V to get the version
number. First I got a little shock but now the prompt shows the name of
the chroot I'm logged into even if I only do `schroot -p -c sid`. That's
great :-)


Thanks
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jubk3h$b07$2...@dough.gmane.org

[Roger Leigh]

On Fri, Jul 20, 2012 at 12:48:49PM +0000, Ramon Hofer wrote:
> On Fri, 20 Jul 2012 10:42:58 +0100, Roger Leigh wrote:
>
> > On Thu, Jul 19, 2012 at 12:34:26PM +0000, Ramon Hofer wrote:
> >> I have some questions about starting daemons in a chroot environment or
> >> rather about starting schroot on bootup.
> >> The reason I want to do this is to clean up my server. It's a Squeeze
> >> with an AMD64 kernel from backports. Some packages are from testing
> >> which gives me problems because of dependencies that can't be
> >> fullfilled: sabnzbdplus from testing depends on python so I can't
> >> install build- essential...
> >>
> >> So far I was able to setup a chroot with schroot and installed sid in
> >> it.
> >>
> >> [sid]
> >> description=Debian sid (unstable)
> >> directory=/srv/chroot/sid users=hoferr groups=hoferr root-groups=root
> >> aliases=unstable,default
> >
> > set type=directory here
>
> That sounds great what I can read in the schroot.conf manpage:
> "In consequence, filesystems such as /proc are not mounted in
> plain chroots; it is the responsibility of the system
> administrator to configure such chroots by hand, whereas
> directory chroots are automatically configured."
>
> This means I can remove the remounts of /proc, /dev and /sys to /srv/
> chroot/sid/... from my /etc/fstab?

Yes, exactly. You still have an fstab--it's
/etc/schroot/default/fstab, though this is configurable (set
script=config with schroot 1.4.x, or profile= with schroot 1.6.x).

> But when I try this out and comment the proc and dev remounts and restart
> the system sabnzbd+ isn't started automatically and when I try it when
> the init.d script manually I get:
> [....] Starting SABnzbd+ binary newsgrabber:start-stop-daemon: nothing
> in /proc - not mounted?
> failed!

Hmm, it should have mounted it. Try looking at the information
reported with "-v"; you should see the 10mount script mount mounting
the filesystems. If it doesn't, you should see an error at this point.
Or, if the configuration is broken for some reason, maybe you'll see
an absence of mounting. You should see the reverse happen when you
end the session as well.

> >> In the chroot I have created a new user called hoferr and am now able
> >> to login without root privilieges.
> >> But in there sudo is missing. Maybe this can be resolved by installing
> >> the correct base system meta package mentioned above?
> >
> > You could install sudo. But why? This is what schroot /is/ (chroot +
> > sudo). If you want to do stuff as root inside the chroot,
> > just add yourself to root-groups/root-users.
>
> Or start it with `sudo schroot -p -c sid`.

That's a possibility, though I would personally just configure schroot
to give me root access directly.

> I'm still using version 1.4.19. But this feature sounds very good!
>
> Btw I have accidentally run `schroot -v` instead -V to get the version
> number. First I got a little shock but now the prompt shows the name of
> the chroot I'm logged into even if I only do `schroot -p -c sid`. That's
> great :-)

Fantastic! That's one of the little details set up by the setup
scripts (50chrootname). It will also handle other things like copying
over the passwd database so you have the same accounts inside the
chroot that you have on the host.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120720163...@codelibre.net

[Bob Proulx]

First I should say that schroot appears to have a lot more
functionality than I previously realized. I had thought it was just a
fancy suid chroot similar to 'dchroot' adding a security layer around
chroot(2). But it looks like it can do much more including building
chroots on the fly and other really fancy things. I know nothing
about that yet and will need to read up on it. But having said that I
will answer some of your questions anyway even if perhaps the answer
isn't relevant anymore in light of that.

Ramon Hofer wrote:
> The program I'd like to jail is a daemon which means I should use the
> longer script. Unfortunately I couldn't find anything about the initscript
> ID in the policy-rc.d documentation.

The "ID" is simply the name of the init.d script. For nullmailer it
is nullmailer. For cron it is cron. And so forth.

The problem that policy-rc.d solves is that a package upgrade in the
chroot would normally restart the associated daemon. For some things
such as nullmailer expected to be run from the chroot that is okay.
But for other things it is generally undesirable. For example I would
definitely not want to run the 'ntp' daemon within the chroot. I also
don't want a networking upgrade in the chroot to try to stop and
restart networking. Lots of bad things that should not happen.

I normally avoid installing packages that I don't want installed. But
some things are pulled in as dependencies and even a small chroot will
have extra stuff that isn't wanted. policy-rc.d gives an interface to
control all of them all at once.

> Can I just copy/paste the script in my case to
> /srv/chroot/sid/usr/sbin/policy-rc.d
> and make it executable?

Yes.

> I found this:
> "There is a provision for a "local initscript policy layer" (...),
> which allows the local system administrator to control the behaviour of
> invoke-rc.d for every initscript id and action"
> http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

Yes. That is the policy-rc.d script.

> So this script controls the way and order the daemons are started?

Yes.

> Is it correct that without it I wouldn't be able to start the daemon from
> outside the chroot because of this:

No. That is incorrect. A policy-rc.d script in the chroot will have
no effect on any daemon outside the chroot. Plus the default is that
everything is always enabled. The addition of the policy-rc.d script
enables you to *disable* what you don't want running. In the
implementation it is usually written so that everything is disabled
with the exception of specifically what you want to enable.

> "Can I run a dæmons in a chroot?
> (...) Unfortunately, this means schroot detects that the program
> exited (the dæmon is a orphaned grandchild of this process) and it
> then ends the session. (...)"
> http://manpages.ubuntu.com/manpages/natty/man7/schroot-faq.7.html

That appears to be some fancy schroot behavior that I am not familiar
and so will have to pass on saying anything about it. I have never
used that functionality myself.

> >> Entered the chroot with $ sudo schroot -p -c sid
> >>
> >> Installed locales and reconfigured them. I also installed vim.
> >
> > Seems reasonable so far. Some packages will require /proc. Some will
> > also require /dev. Some will require other things.
>
> Oh, yes, I read about that but I forgot to update my /etc/fstab and mount
> the directories. Should I also remount /sys?

I have never needed /sys in a chroot.

> Or is there a better way to do this? I mean can schroot handle it
> directly so that when I create a new jail or copy one that the
> directories are remounted there as well?

See my previous disclaimer.

> Btw I had to set the password for my user inside the chroot to be able to
> use sudo.

Yes, of course. Why does this surprise you? Building a chroot is
almost the same as building a competely different machine. If you
bought a new machine at the store, brought it home, installed an
operating system onto it, would you be surprised that you would need
to set up an account for you there? Of course not. Well, this is the
same thing. No difference. If you want it in the chroot then you
need to install it or set it up or whatever. If you build an
additional chroot then that is again a completely unique and separate
installation. If you want something there then you need to install it
there.

I frequently share things such as 'bind' mounting my /home directory
so that I have one home directory. For a very large install I might
have many directories bind mounted. For example:

/home /srv/chroot/sid-chromium/home none bind 0 0
/tmp /srv/chroot/sid-chromium/tmp none bind 0 0
/proc /srv/chroot/sid-chromium/proc none bind 0 0
/dev /srv/chroot/sid-chromium/dev none bind 0 0
/dev/shm /srv/chroot/sid-chromium/dev/shm none bind 0 0
/dev/pts /srv/chroot/sid-chromium/dev/pts none bind 0 0
/var/run /srv/chroot/sid-chromium/var/run none bind 0 0

In order to run the Unstable Sid Chromium on Stable Squeeze it wanted
all of the extras mounted and available. And then to run chromium
from it I launch it like this:

My local /usr/local/bin/chromium file:

#!/bin/sh
exec schroot -q -c sid -p -- chromium "$@"

> >> Aside some missing packages everything looks promising.
> >
> > The premise of debootstrap is that it installs a very small system. If
> > you want something installed you are going to need to install it
> > yourself.
> >
> > Perhaps you should consider using 'tasksel' to install a standard task
> > set of packages. That would pull in a lot. I prefer the small system
> > and only install what I need to install. But if you don't like that
> > then you may always install a larger set all at once.
>
> Aha, the base system option of the Debian installer uses tasksel.

Yes. You can run tasksel in test mode with 'tasksel -t' and see the
command it will run in each case.

> I think I'll try with the minimal installation as well and when I run
> into serious problems I might install the rest with tasksel. It makes to
> not install too much because I won't work in the chroot. So probably even
> sudo and bash-completion are too much...

I do often work in the chroot. For example I use it for web
development work in Rails. So for me having basics such as emacs,
less, bash-completion, and others are nice.

I don't see much use for sudo. I would normally use sudo outside the
chroot to become root in the chroot. Any of these. All about the same:

$ sudo chroot /srv/chroot/sid /bin/bash

$ sudo chroot /srv/chroot/sid su -

$ sudo schroot -c sid

> Btw In the jail I also did `dpkg-reconfigure tzdata` to set the time zone
> (it was set to "Etc"). But I don't know if that makes any difference...

It controls the default timezone in the chroot. See for example:

$ sudo schroot -c sid -- date -R

> I could also just use /etc/schroot/default/copyfiles and put the config
> directory .sabnzbd onto it.

I know nothing of the fancy features of schroot so will defer to Roger
on all such things.

> >> It will probably start automatically when the chroot is started
> >
> > Wait! Hold it right there. What do you mean "when the chroot is
> > started"? Unless you are doing something "magical" there isn't anything
> > that "starts a chroot". I think right here there is a huge
> > misunderstanding of chroots. If you want a particular daemon to start
> > in the chroot then you will need to ensure that it is started.
>
> I thought that starting a chroot is like starting a virtual machine. But
> it's probably more like directly starting a program (in my case sabnzbd+)
> for which schroot starts the jail?

As far as I know schroot doesn't start a VM or a Linux container or
anything super fancy such as those. I had always thought of it as a
security layer on top of chroot. I will have to read up on its fancy
features.

But the part I was talking about was simply the chroot(2) part.
Perhaps you should read the man page for chroot to see the basic
concepts.

man 2 chroot

It simply affects the path of / to be the specified one. This is
inherited by all children processes.

> > I would use the same header as in the original script.
>
> Unfortunately the init.d script for sabnzbd is quite cmplex and I don't
> understand exactly what I have to change.

Don't change it at all. Simply copy the LSB header from it. Use
cut-n-paste. Use an editor to copy the selection. Whatever. Don't
try to use the entire script.

I showed you an example that uses the LSB headers from nullmailer and
then simply launches it from the chroot. That is the actual script
that I use. Note that it is NOT a copy of the nullmailer init.d
script. That wouldn't work.

> Probably I can just change the beginning which is.
>
> DAEMON=/usr/bin/sabnzbdplus
> SETTINGS=/etc/default/sabnzbdplus

I would not do it that way.

I already gave you my best advice on how to do it. I showed you
exactly how I am doing it. As with any advice feel free to ignore it
and do your own thing. But I think you are doing it wrong. :-)

> Since /usr/bin/sabnzbdplus is a python script python should probably also
> be started in the jail.

What does it mean to "start python in the chroot jail"?

Python is an interpreter not a daemon. Of course you can write a
daemon using python as the implementation language. And you might
start the daemon in the chroot. But you don't start python in the
chroot.

> > For example I run 'nullmailer' in the chroot. Therefore I create an
> > initscript like this following. And I install it using update-rc.d.
> > Copy it to /etc/init.d/chroot-nullmailer and then install it with:
> >
> > update-rc.d chroot-nullmailer defaults
> >
> > In a chroot I usually run nullmailer and cron plus whatever else I
> > wanted the chroot for, such as apache.
>
> Your script is much more understandable to me.

Yay!

> I have done it as follows:
>
> Inside the chroot I created usr/sbin/policy-rc.d with your longer script
> from above and made it executable.

Good.

> Outside the chroot I have stopped sabnzbd+
> Remounted /proc, /dev,

Okay.

> /etc/default/sabnzbdplus, /home/hoferr/.sabnzbd and the download
> location.

Those appear to be files. Could you say exactly how you mounted
those? Did you 'bind' mount those files? Which is fine. I would
have 'bind' mounted all of /home so as to avoided the need for
individual files. I would have copied /etc/default/sabnzbdplus.

> (I couldn't use /etc/schroot/default/copyfiles
> because the directory wasn't copied.)

I have no info on this fancy feature of schroot. Others will need to
help there.

> Inside the chroot installed sabnzbd+ and was able to connect to it's
> webinterface.

Sounds good.

> Outside chroot I created the sid-sabnzbd script
> http://pastebin.com/raw.php?i=Lamy4K4a
> Thanks for your example :-)

Looks good!

> Updated-rc.d and removed sabnzbdplus.

And then added in the new sid-sabnzbdplus with:

# update-rc.d sid-sabnzbdplus defaults

> Now I can `sudo /etc/init.d/sid-sabnzbdplus start / stop / ...` :-)

Yay!

> Thanks again for your help!

Glad to have helped.

Bob

[Ramon Hofer]

On Fri, 20 Jul 2012 14:24:11 -0600, Bob Proulx wrote:

> First I should say that schroot appears to have a lot more functionality
> than I previously realized. I had thought it was just a fancy suid
> chroot similar to 'dchroot' adding a security layer around chroot(2).
> But it looks like it can do much more including building chroots on the
> fly and other really fancy things. I know nothing about that yet and
> will need to read up on it. But having said that I will answer some of
> your questions anyway even if perhaps the answer isn't relevant anymore
> in light of that.

I haven't used schroot or chroot before. So you're advice is helpful for
sure :-)

> Ramon Hofer wrote:
>> The program I'd like to jail is a daemon which means I should use the
>> longer script. Unfortunately I couldn't find anything about the
>> initscript ID in the policy-rc.d documentation.
>
> The "ID" is simply the name of the init.d script. For nullmailer it is
> nullmailer. For cron it is cron. And so forth.

It looked to me as if I should have to adapt the ID there manually.

> The problem that policy-rc.d solves is that a package upgrade in the
> chroot would normally restart the associated daemon. For some things
> such as nullmailer expected to be run from the chroot that is okay.
> But for other things it is generally undesirable. For example I would
> definitely not want to run the 'ntp' daemon within the chroot. I also
> don't want a networking upgrade in the chroot to try to stop and restart
> networking. Lots of bad things that should not happen.

Thanks for the explanation!

That's really cool too.
I will probably be using something like this in the near future :-)

> Yes. You can run tasksel in test mode with 'tasksel -t' and see the
> command it will run in each case.

Thanks!

In the installer there's an option which I can't see when I run taskesel -
t. In the installer it's called something like base system packages.

It's not important as I won't need it...

>> I think I'll try with the minimal installation as well and when I run
>> into serious problems I might install the rest with tasksel. It makes
>> to not install too much because I won't work in the chroot. So probably
>> even sudo and bash-completion are too much...
>
> I do often work in the chroot. For example I use it for web development
> work in Rails. So for me having basics such as emacs, less,
> bash-completion, and others are nice.
>
> I don't see much use for sudo. I would normally use sudo outside the
> chroot to become root in the chroot. Any of these. All about the same:
>
> $ sudo chroot /srv/chroot/sid /bin/bash
>
> $ sudo chroot /srv/chroot/sid su -
>
> $ sudo schroot -c sid

I don't know what "web development work in Rails" but I want to build
xbmc
and openelec for some other system and maybe this could be a way to do
it :-)

> As far as I know schroot doesn't start a VM or a Linux container or
> anything super fancy such as those. I had always thought of it as a
> security layer on top of chroot. I will have to read up on its fancy
> features.
>
> But the part I was talking about was simply the chroot(2) part.
> Perhaps you should read the man page for chroot to see the basic
> concepts.
>
> man 2 chroot
>
> It simply affects the path of / to be the specified one. This is
> inherited by all children processes.

I knew that it changes the root directory. But I couldn't imagine how
this could be helpful. I thought that a library from sid wouldn't run
with a Squeeze kernel...

>> /etc/default/sabnzbdplus, /home/hoferr/.sabnzbd and the download
>> location.
>
> Those appear to be files. Could you say exactly how you mounted those?
> Did you 'bind' mount those files? Which is fine. I would have 'bind'
> mounted all of /home so as to avoided the need for individual files. I
> would have copied /etc/default/sabnzbdplus.

Sorry I should have written it.

/etc/default/sabnzbdplus is a file and I have bind mounted it. I read
somewhere that this is no problem. But I could have copied it as well.

But /home/hoferr/.sabnzbd is a directory.

I don't want to mount the whole home directory because sabnzbd doesn't
need to have access to it...


Thanks again

Ramon



--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jue2u5$thd$1...@dough.gmane.org

[Ramon Hofer]

Very nice!
This is the default fstab which is used for all schroots right?

Is there another one which I can use to set specific mounts?
Like in my case the config dir in my home for sabnzbd?

And I should copy/bind another config file. Is it possible to have
different /etc/schroot/default/copyfiles for different schroot
environments?

Something like /etc/schroot/[SCHROOT]/fstab and /etc/schroot/[SCHROOT]/
copyfiles would be very handy :-)

>> But when I try this out and comment the proc and dev remounts and
>> restart the system sabnzbd+ isn't started automatically and when I try
>> it when the init.d script manually I get:
>> [....] Starting SABnzbd+ binary newsgrabber:start-stop-daemon: nothing
>> in /proc - not mounted?
>> failed!
>
> Hmm, it should have mounted it. Try looking at the information reported
> with "-v"; you should see the 10mount script mount mounting the
> filesystems. If it doesn't, you should see an error at this point.
> Or, if the configuration is broken for some reason, maybe you'll see an
> absence of mounting. You should see the reverse happen when you end the
> session as well.

I found what I did wrong: In the init.d script I used chroot instead of
schroot:
http://pastebin.com/raw.php?i=Lamy4K4a

Could you please help me with the correct command?
Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus start` can I
use `schroot -c sid sabnzbdplus start`?

Then this would be my new schroot script:
http://pastebin.com/raw.php?i=Lamy4K4a

>> >> In the chroot I have created a new user called hoferr and am now
>> >> able to login without root privilieges.
>> >> But in there sudo is missing. Maybe this can be resolved by
>> >> installing the correct base system meta package mentioned above?
>> >
>> > You could install sudo. But why? This is what schroot /is/ (chroot
>> > +
>> > sudo). If you want to do stuff as root inside the chroot,
>> > just add yourself to root-groups/root-users.
>>
>> Or start it with `sudo schroot -p -c sid`.
>
> That's a possibility, though I would personally just configure schroot
> to give me root access directly.

I have tried to set root-groups=root,sudo in /etc/schroot/schroot.conf
for the (only) but this doesn't give me root access (even though I'm
member of the sudo group outside the chroot and inside it as it seems
the /etc/group files are the same).

I've also tried to add my user directly to the root-groups without
success. What could I possibly do wrong?

>> I'm still using version 1.4.19. But this feature sounds very good!
>>
>> Btw I have accidentally run `schroot -v` instead -V to get the version
>> number. First I got a little shock but now the prompt shows the name of
>> the chroot I'm logged into even if I only do `schroot -p -c sid`.
>> That's great :-)
>
> Fantastic! That's one of the little details set up by the setup scripts
> (50chrootname). It will also handle other things like copying over the
> passwd database so you have the same accounts inside the chroot that you
> have on the host.

What do you mean by the setup script? Using the -v option?
Or is it `setup-start`? Should I run it after I've changed schroot.conf
which is maybe the solution to my problem with the permission from above?


Btw do you know a some documentation on how I schroot and chroot work? Is
it really only changing the root directory. I'm wondering because when I
install a package from sid it's not sure that it'll work with the Squeeze
kernel?


Cheers
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/jue5ai$thd$2...@dough.gmane.org

[Ramon Hofer]

On Sat, 21 Jul 2012 11:54:58 +0000, Ramon Hofer wrote:

> I found what I did wrong: In the init.d script I used chroot instead of
> schroot:
> http://pastebin.com/raw.php?i=Lamy4K4a
>
> Could you please help me with the correct command?
> Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus start` can I
> use `schroot -c sid sabnzbdplus start`?
>
> Then this would be my new schroot script:
> http://pastebin.com/raw.php?i=Lamy4K4a

I have made some changes to my script:
http://pastebin.com/raw.php?i=VFr77mwK

There's some mess with the output of the commands. So it's not really
nice but it's working.

I've tried to use the -q option for schroot but it's still talking...

Cheers
Ramon


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/juemo8$8ek$1...@dough.gmane.org

[Roger Leigh]

On Sat, Jul 21, 2012 at 04:52:24PM +0000, Ramon Hofer wrote:
> On Sat, 21 Jul 2012 11:54:58 +0000, Ramon Hofer wrote:
>
> > I found what I did wrong: In the init.d script I used chroot instead of
> > schroot:
> > http://pastebin.com/raw.php?i=Lamy4K4a
> >
> > Could you please help me with the correct command?
> > Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus start` can I
> > use `schroot -c sid sabnzbdplus start`?
> >
> > Then this would be my new schroot script:
> > http://pastebin.com/raw.php?i=Lamy4K4a
>
> I have made some changes to my script:
> http://pastebin.com/raw.php?i=VFr77mwK
>
> There's some mess with the output of the commands. So it's not really
> nice but it's working.
>
> I've tried to use the -q option for schroot but it's still talking...

Firstly, add schroot to Required-(Start|Stop), since you do
need it to be set up prior to starting new sessions.

I would also check the return status of schroot. If sid-sab
already exists, then session creation will fail, and you'll
reuse the old session. That might not be incorrect, but
in the general case, I'd recommend checking.

What "talking" are you seeing? --quiet should hide all the
messages, unless there's a problem.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120721210...@codelibre.net

[Roger Leigh]

Yes.

> Is there another one which I can use to set specific mounts?
> Like in my case the config dir in my home for sabnzbd?

Not provided with the package. You could just
sudo cp -r /etc/schroot/default /etc/schroot/sabnzbd
and then set
script-config=/etc/schroot/sabnzdb/config
(you'll need to edit this file to update the paths in it from
/etc/schroot/default to /etc/schroot/sabnzdb.

> And I should copy/bind another config file. Is it possible to have
> different /etc/schroot/default/copyfiles for different schroot
> environments?

> Something like /etc/schroot/[SCHROOT]/fstab and /etc/schroot/[SCHROOT]/
> copyfiles would be very handy :-)

Not using the same /etc/schroot/default/copyfiles file, but by
creating your own chroot-specific config directory as above, it's
definitely possible. See the other options like
/etc/schroot/desktop for pre-canned profiles provided as
alternatives to "default".

> >> But when I try this out and comment the proc and dev remounts and
> >> restart the system sabnzbd+ isn't started automatically and when I try
> >> it when the init.d script manually I get:
> >> [....] Starting SABnzbd+ binary newsgrabber:start-stop-daemon: nothing
> >> in /proc - not mounted?
> >> failed!
> >
> > Hmm, it should have mounted it. Try looking at the information reported
> > with "-v"; you should see the 10mount script mount mounting the
> > filesystems. If it doesn't, you should see an error at this point.
> > Or, if the configuration is broken for some reason, maybe you'll see an
> > absence of mounting. You should see the reverse happen when you end the
> > session as well.
>
> I found what I did wrong: In the init.d script I used chroot instead of
> schroot:
> http://pastebin.com/raw.php?i=Lamy4K4a
>
> Could you please help me with the correct command?
> Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus start` can I
> use `schroot -c sid sabnzbdplus start`?
>
> Then this would be my new schroot script:
> http://pastebin.com/raw.php?i=Lamy4K4a

I think I followed up on this one in your following mail.

> >> >> In the chroot I have created a new user called hoferr and am now
> >> >> able to login without root privilieges.
> >> >> But in there sudo is missing. Maybe this can be resolved by
> >> >> installing the correct base system meta package mentioned above?
> >> >
> >> > You could install sudo. But why? This is what schroot /is/ (chroot
> >> > +
> >> > sudo). If you want to do stuff as root inside the chroot,
> >> > just add yourself to root-groups/root-users.
> >>
> >> Or start it with `sudo schroot -p -c sid`.
> >
> > That's a possibility, though I would personally just configure schroot
> > to give me root access directly.
>
> I have tried to set root-groups=root,sudo in /etc/schroot/schroot.conf
> for the (only) but this doesn't give me root access (even though I'm
> member of the sudo group outside the chroot and inside it as it seems
> the /etc/group files are the same).
>
> I've also tried to add my user directly to the root-groups without
> success. What could I possibly do wrong?

Did you run with "-u root" to switch to the root user inside the
chroot? If you don't use "-u" it will just run as the current
user, rather than switching. So long as one of the groups you
are a member of is in root-groups or root-users, you'll be
allowed to switch without a password. If you aren't in one of those,
you'll be prompted for a password IIRC.

> >> I'm still using version 1.4.19. But this feature sounds very good!
> >>
> >> Btw I have accidentally run `schroot -v` instead -V to get the version
> >> number. First I got a little shock but now the prompt shows the name of
> >> the chroot I'm logged into even if I only do `schroot -p -c sid`.
> >> That's great :-)
> >
> > Fantastic! That's one of the little details set up by the setup scripts
> > (50chrootname). It will also handle other things like copying over the
> > passwd database so you have the same accounts inside the chroot that you
> > have on the host.
>
> What do you mean by the setup script? Using the -v option?
> Or is it `setup-start`? Should I run it after I've changed schroot.conf
> which is maybe the solution to my problem with the permission from above?

This is all done automatically, and irrespective of -v (this just
shows you want it's doing, it's still done when you don't use it).
The setup scripts are run when you begin or end a session using -b
or -e. If you don't use -b or -e, it's done all in the one command
automatically.

> Btw do you know a some documentation on how I schroot and chroot work? Is
> it really only changing the root directory. I'm wondering because when I
> install a package from sid it's not sure that it'll work with the Squeeze
> kernel?

Both are just changing the root directory. schroot does some additional
stuff as well such as creating/snapshotting the chroot and running the
setup scripts, and also handling authentication and user switching, but
ultimately both just call the chroot(2) system call, and then run a
shell or command.

If you run software in a sid chroot that uses specific features of the
sid kernel not available in squeeze, then it will fail. But all of the
important stuff like devices, procfs, sysfs are inherited from the
host system--the chroot is not a standalone environment, and does not
run the rcS scripts or anything at startup. So in practice it will
work for all but the most esoteric software. All of the Debian
autobuilders run squeeze, using sid chroots with schroot for package
building--issues arising from using a squeeze kernel and a sid chroot
are almost unheard of (and would be considered a bug in the package).

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120721211...@codelibre.net

[Ramon Hofer]

On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> On Sat, Jul 21, 2012 at 04:52:24PM +0000, Ramon Hofer wrote:
> > On Sat, 21 Jul 2012 11:54:58 +0000, Ramon Hofer wrote:
> >
> > > I found what I did wrong: In the init.d script I used chroot instead of
> > > schroot:
> > > http://pastebin.com/raw.php?i=Lamy4K4a
> > >
> > > Could you please help me with the correct command?
> > > Instead of `chroot /srv/chroot/sid /etc/init.d/sabnzbdplus start` can I
> > > use `schroot -c sid sabnzbdplus start`?
> > >
> > > Then this would be my new schroot script:
> > > http://pastebin.com/raw.php?i=Lamy4K4a
> >
> > I have made some changes to my script:
> > http://pastebin.com/raw.php?i=VFr77mwK
> >
> > There's some mess with the output of the commands. So it's not really
> > nice but it's working.
> >
> > I've tried to use the -q option for schroot but it's still talking...
>
> Firstly, add schroot to Required-(Start|Stop), since you do
> need it to be set up prior to starting new sessions.

Thanks for the hint!
I added $schroot at the end (don't know if the ordering matters...)

> I would also check the return status of schroot. If sid-sab
> already exists, then session creation will fail, and you'll
> reuse the old session. That might not be incorrect, but
> in the general case, I'd recommend checking.

I was thinking about this too. But I saw no need to create a new session
if the old is still there.
What could be drawbacks of doing so?

> What "talking" are you seeing? --quiet should hide all the
> messages, unless there's a problem.

I was wrong there. The only output I see is from
schroot -bq -n $NAME -c $SCHROOT

It returns $NAME. But I've already changed to sabnzbdplus init script
from the sid schroot to output something like
[ ok ] Starting SABnzbd+ binary newsgrabber in sid chroot:.

I have tried this
$NAME=$(schroot -bq -n $NAME -c $SCHROOT)

But when the init.d script is called the second time with start then it
return
E: /etc/init.d/sabnzbdplus: Chroot not found

That's why I have added >/dev/null to the creation command
schroot -bq -n $NAME -c $SCHROOT >/dev/null

Now everything seems to run as expected. Except maybe the re-usage of an
old schroot session?


Cheers
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1342963549.3...@hoferr-desktop.hofer.rummelring

[Roger Leigh]

On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> >
> > Firstly, add schroot to Required-(Start|Stop), since you do
> > need it to be set up prior to starting new sessions.
>
> Thanks for the hint!
> I added $schroot at the end (don't know if the ordering matters...)

It's "schroot", not "$schroot". '$' means it's a virtual
service provided by another script; without the '$' means the
script itself. e.g. "$network" is provided by "ifupdown".

> > I would also check the return status of schroot. If sid-sab
> > already exists, then session creation will fail, and you'll
> > reuse the old session. That might not be incorrect, but
> > in the general case, I'd recommend checking.
>
> I was thinking about this too. But I saw no need to create a new session
> if the old is still there.
> What could be drawbacks of doing so?

None really; they can even persist across reboots. (That's what
the "recover-session" action is for.)

> > What "talking" are you seeing? --quiet should hide all the
> > messages, unless there's a problem.
>

> I have tried this
> $NAME=$(schroot -bq -n $NAME -c $SCHROOT)
>
> But when the init.d script is called the second time with start then it
> return
> E: /etc/init.d/sabnzbdplus: Chroot not found
>
> That's why I have added >/dev/null to the creation command
> schroot -bq -n $NAME -c $SCHROOT >/dev/null

"/etc/init.d/sabnzbdplus" is an odd name for a chroot; It's not
even valid to have '/' in the name IIRC. Is "$NAME" correct here?

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120722145...@codelibre.net

[Ramon Hofer]

On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > >
> > > Firstly, add schroot to Required-(Start|Stop), since you do
> > > need it to be set up prior to starting new sessions.
> >
> > Thanks for the hint!
> > I added $schroot at the end (don't know if the ordering matters...)
>
> It's "schroot", not "$schroot". '$' means it's a virtual
> service provided by another script; without the '$' means the
> script itself. e.g. "$network" is provided by "ifupdown".

Thanks for the explanation :-)

> > > I would also check the return status of schroot. If sid-sab
> > > already exists, then session creation will fail, and you'll
> > > reuse the old session. That might not be incorrect, but
> > > in the general case, I'd recommend checking.
> >
> > I was thinking about this too. But I saw no need to create a new session
> > if the old is still there.
> > What could be drawbacks of doing so?
>
> None really; they can even persist across reboots. (That's what
> the "recover-session" action is for.)

Hmm, then maybe I should check if there'are lost sessions upon the start
of the script?
Or will either schroot -b or -r work with such a lost session?

> > > What "talking" are you seeing? --quiet should hide all the
> > > messages, unless there's a problem.
> >
> > I have tried this
> > $NAME=$(schroot -bq -n $NAME -c $SCHROOT)
> >
> > But when the init.d script is called the second time with start then it
> > return
> > E: /etc/init.d/sabnzbdplus: Chroot not found
> >
> > That's why I have added >/dev/null to the creation command
> > schroot -bq -n $NAME -c $SCHROOT >/dev/null
>
> "/etc/init.d/sabnzbdplus" is an odd name for a chroot; It's not
> even valid to have '/' in the name IIRC. Is "$NAME" correct here?

Yes but this error was printed when I had these two commands in the
start part of my init.d script:

$NAME=$(schroot -bq -n $NAME -c $SCHROOT)

schroot -rq -c $NAME /etc/init.d/sabnzbdplus start

NAME is set to "" after the first command and "/etc/init.d/sabnzbdplus"
is therefore the argument for -c in the second command.


Cheers
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1342970834.3...@hoferr-desktop.hofer.rummelring

[Ramon Hofer]

This has made me want to have a separate sid schroot for sabnzbd :-)

That's why I renamed /srv/chroot/sid to /srv/chroot/sid-sab and the
session name in /etc/schroot/schroot.conf to sid-sab too:

[sid-sab]
type=directory
description=Debian sid (unstable) for SABnzbd
directory=/srv/chroot/sid-sab
users=hoferr
groups=hoferr
root-groups=root,hoferr
script-config=/etc/schroot/sid-sab/config

After copying /etc/schroot/default to /etc/schroot/sid-sab I have
manually edited the three paths in /etc/schroot/sabnzdb/config:

FSTAB="/etc/schroot/sid-sab/fstab"
COPYFILES="/etc/schroot/sid-sab/copyfiles"
NSSDATABASES="/etc/schroot/sid-sab/nssdatabases"

Unfortunately when I started the schroot session I got
$ schroot -v -p -c sid-sab
I: Executing ‘00check setup-start ok’
E: 00check: error: script-config file
'/etc/schroot/etc/schroot/sid-sab/config' does not exist
...

That's why I changed script-config to
script-config=sid-sab/config

Now it's working. :-)

Because in my init.d script now both --session-name and --chroot are
sid-sab I feared that this would lead to problems. But doesn't seem to.
Is this true?

> > And I should copy/bind another config file. Is it possible to have
> > different /etc/schroot/default/copyfiles for different schroot
> > environments?
>
> > Something like /etc/schroot/[SCHROOT]/fstab and /etc/schroot/[SCHROOT]/
> > copyfiles would be very handy :-)
>
> Not using the same /etc/schroot/default/copyfiles file, but by
> creating your own chroot-specific config directory as above, it's
> definitely possible. See the other options like
> /etc/schroot/desktop for pre-canned profiles provided as
> alternatives to "default".

That's great! Thanks :-)
I will in the next weeks probably play a lot with it ;-)
Not only desktop/config but maybe also sbuild/config. I always wanted to
learn about building my own package :-)

> > >> >> In the chroot I have created a new user called hoferr and am now
> > >> >> able to login without root privilieges.
> > >> >> But in there sudo is missing. Maybe this can be resolved by
> > >> >> installing the correct base system meta package mentioned above?
> > >> >
> > >> > You could install sudo. But why? This is what schroot /is/ (chroot
> > >> > +
> > >> > sudo). If you want to do stuff as root inside the chroot,
> > >> > just add yourself to root-groups/root-users.
> > >>
> > >> Or start it with `sudo schroot -p -c sid`.
> > >
> > > That's a possibility, though I would personally just configure schroot
> > > to give me root access directly.
> >
> > I have tried to set root-groups=root,sudo in /etc/schroot/schroot.conf
> > for the (only) but this doesn't give me root access (even though I'm
> > member of the sudo group outside the chroot and inside it as it seems
> > the /etc/group files are the same).
> >
> > I've also tried to add my user directly to the root-groups without
> > success. What could I possibly do wrong?
>
> Did you run with "-u root" to switch to the root user inside the
> chroot? If you don't use "-u" it will just run as the current
> user, rather than switching. So long as one of the groups you
> are a member of is in root-groups or root-users, you'll be
> allowed to switch without a password. If you aren't in one of those,
> you'll be prompted for a password IIRC.

Aha, I thought my user would have the right to directly run commands
like apt-get without sudo.
But still when I run `sudo -u root` I get
sudo: effective uid is not 0, is sudo installed setuid root?

I read that this could be because the filesystem is mounted with
'nosuid' [1]. But this isn't the case. Here's my fstab for this schroot:

/proc /proc none rw,rbind 0 0
/sys /sys none rw,rbind 0 0
/dev /dev none rw,rbind 0 0
/home /home none rw,bind 0 0
/tmp /tmp none rw,bind 0 0

I did
(sid)# dpkg-reconfigure sudo
invoke-rc.d: policy-rc.d denied execution of stop.

This is my /usr/sbin/policy-rc.d inside the schroot session

while [ $# -gt 0 ]; do
case $1 in
--list) exit 101 ;;
--quiet) shift ;;
-*) shift ;;
cron) exit 0 ;;
nullmailer) exit 0 ;;
*) exit 101 ;;
esac
done
exit 101

> > >> I'm still using version 1.4.19. But this feature sounds very good!
> > >>
> > >> Btw I have accidentally run `schroot -v` instead -V to get the version
> > >> number. First I got a little shock but now the prompt shows the name of
> > >> the chroot I'm logged into even if I only do `schroot -p -c sid`.
> > >> That's great :-)
> > >
> > > Fantastic! That's one of the little details set up by the setup scripts
> > > (50chrootname). It will also handle other things like copying over the
> > > passwd database so you have the same accounts inside the chroot that you
> > > have on the host.
> >
> > What do you mean by the setup script? Using the -v option?
> > Or is it `setup-start`? Should I run it after I've changed schroot.conf
> > which is maybe the solution to my problem with the permission from above?
>
> This is all done automatically, and irrespective of -v (this just
> shows you want it's doing, it's still done when you don't use it).
> The setup scripts are run when you begin or end a session using -b
> or -e. If you don't use -b or -e, it's done all in the one command
> automatically.

I thought that when logging in before starting the first time with -v I
struggled knowing if I'm inside the chroot. But maybe I used a wrong
command. Can't remember exactly anymore :-?
But now it's working great :-D

> > Btw do you know a some documentation on how I schroot and chroot work? Is
> > it really only changing the root directory. I'm wondering because when I
> > install a package from sid it's not sure that it'll work with the Squeeze
> > kernel?
>
> Both are just changing the root directory. schroot does some additional
> stuff as well such as creating/snapshotting the chroot and running the
> setup scripts, and also handling authentication and user switching, but
> ultimately both just call the chroot(2) system call, and then run a
> shell or command.
>
> If you run software in a sid chroot that uses specific features of the
> sid kernel not available in squeeze, then it will fail. But all of the
> important stuff like devices, procfs, sysfs are inherited from the
> host system--the chroot is not a standalone environment, and does not
> run the rcS scripts or anything at startup. So in practice it will
> work for all but the most esoteric software. All of the Debian
> autobuilders run squeeze, using sid chroots with schroot for package
> building--issues arising from using a squeeze kernel and a sid chroot
> are almost unheard of (and would be considered a bug in the package).

Very interesting. Thanks for the explanation.

I read that chroot doesn't create any overhead except disk space. So
there's no drawback on using separate schroot environments for different
daemons except the extra disk space?
E.g. the python libraries are only loaded once for each sid session I
run? No matter if python is installed in /srv/chroot/sid-sab and as well
in a new /srv/chroot/sid-mythbackend?

And does it make sense to use different partitions for each chroot
environment: Should I put /srv/chroot/sid-sab to an own partition?
Atm I have a ~300 GB partition mounted to /srv. The /srv/chroot/sid-sab
directory uses 466 MB so I could create a 5 GB partition for it?


Sorry for all the question ;-)


Best regards
Ramon


[1] http://www.gratisoft.us/sudo/troubleshooting.html

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1342974708.3...@hoferr-desktop.hofer.rummelring

[Roger Leigh]

On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > > > I would also check the return status of schroot. If sid-sab
> > > > already exists, then session creation will fail, and you'll
> > > > reuse the old session. That might not be incorrect, but
> > > > in the general case, I'd recommend checking.
> > >
> > > I was thinking about this too. But I saw no need to create a new session
> > > if the old is still there.
> > > What could be drawbacks of doing so?
> >
> > None really; they can even persist across reboots. (That's what
> > the "recover-session" action is for.)
>
> Hmm, then maybe I should check if there'are lost sessions upon the start
> of the script?
> Or will either schroot -b or -r work with such a lost session?

By default, the schroot init script will automatically recover any
sessions at boot (see /etc/default/schroot). So you shouldn't have
to worry about that. It's basically just running the setup scripts
again to ensure that all filesystems are mounted, etc.


Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120723092...@codelibre.net

[Roger Leigh]

On Sun, Jul 22, 2012 at 06:31:48PM +0200, Ramon Hofer wrote:
> On Sam, 2012-07-21 at 22:18 +0100, Roger Leigh wrote:
> > On Sat, Jul 21, 2012 at 11:54:58AM +0000, Ramon Hofer wrote:
> >
> > > Is there another one which I can use to set specific mounts?
> > > Like in my case the config dir in my home for sabnzbd?
> >
> > Not provided with the package. You could just
> > sudo cp -r /etc/schroot/default /etc/schroot/sabnzbd
> > and then set
> > script-config=/etc/schroot/sabnzdb/config
> > (you'll need to edit this file to update the paths in it from
> > /etc/schroot/default to /etc/schroot/sabnzdb.
>
> This has made me want to have a separate sid schroot for sabnzbd :-)
>
> That's why I renamed /srv/chroot/sid to /srv/chroot/sid-sab and the
> session name in /etc/schroot/schroot.conf to sid-sab too:

This is one place where schroot's support for cloned sessions may be
useful; if you use e.g. type=file|lvm-snapshot|btrfs-snapshot, you
can clone a session just for sab, and then make others for other
purposes, without having to physically copy the base chroot. For
a long-term persistent one I'd recommend file for simplicity (it
just unpacks a tarball of your chroot), or btrfs-snapshot if you
already use btrfs.

They will all share the same profile though; though in 1.6.x you
can configure schroot to allow these to be overridden on a per-
session basis.

> Because in my init.d script now both --session-name and --chroot are
> sid-sab I feared that this would lead to problems. But doesn't seem to.
> Is this true?

No. chroot names and session names are in separate "namespaces", so
it's allowed. They are actually named "chroot:sid-sab" and
"session:sid-sab" (run schroot -l). At least for the version of
schroot in wheezy and sid; it might not be exposed in the squeeze
version.

> > Did you run with "-u root" to switch to the root user inside the
> > chroot? If you don't use "-u" it will just run as the current
> > user, rather than switching. So long as one of the groups you
> > are a member of is in root-groups or root-users, you'll be
> > allowed to switch without a password. If you aren't in one of those,
> > you'll be prompted for a password IIRC.
>
> Aha, I thought my user would have the right to directly run commands
> like apt-get without sudo.

Not sure what you mean here.
sudo apt-get dist-upgrade
is the same as
schroot -c $chroot -u root -- apt-get dist-upgrade
You just don't get the switch to root as the default behaviour.
You can certainly run commands as root directly.

> But still when I run `sudo -u root` I get
> sudo: effective uid is not 0, is sudo installed setuid root?

This is /inside/ the chroot?

> I read that this could be because the filesystem is mounted with
> 'nosuid' [1]. But this isn't the case. Here's my fstab for this schroot:

I've never seen this. It's almost certainly due to the specific
filesystems or setup you have. Check if it's really set setuid root.

> I read that chroot doesn't create any overhead except disk space. So
> there's no drawback on using separate schroot environments for different
> daemons except the extra disk space?

Not really. And if you use e.g. btrfs snapshots, you avoid even
the space overhead.

> E.g. the python libraries are only loaded once for each sid session I
> run? No matter if python is installed in /srv/chroot/sid-sab and as well
> in a new /srv/chroot/sid-mythbackend?

No, they'll be separate files in this case, and hence loaded twice.
But if you use LVM or Btrfs snapshots they would be the same physical
disc blocks; and in the case of Btrfs the same file (AFAICK).

> And does it make sense to use different partitions for each chroot
> environment: Should I put /srv/chroot/sid-sab to an own partition?
> Atm I have a ~300 GB partition mounted to /srv. The /srv/chroot/sid-sab
> directory uses 466 MB so I could create a 5 GB partition for it?

That would be fine. Personally, I have each chroot on a btrfs
subvolume, that way there's no restrictions on how much each may
grow, and they can be freely snapshotted. You can then use
type=btrfs-snapshot or type=directory.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120723103...@codelibre.net

[Ramon Hofer]

I could use the init.d script to change the binds...

And thanks for the suggestions. I have some material to read (and
decide).

> > Because in my init.d script now both --session-name and --chroot are
> > sid-sab I feared that this would lead to problems. But doesn't seem to.
> > Is this true?
>
> No. chroot names and session names are in separate "namespaces", so
> it's allowed. They are actually named "chroot:sid-sab" and
> "session:sid-sab" (run schroot -l). At least for the version of
> schroot in wheezy and sid; it might not be exposed in the squeeze
> version.

So far it seems to work find :-)

> > > Did you run with "-u root" to switch to the root user inside the
> > > chroot? If you don't use "-u" it will just run as the current
> > > user, rather than switching. So long as one of the groups you
> > > are a member of is in root-groups or root-users, you'll be
> > > allowed to switch without a password. If you aren't in one of those,
> > > you'll be prompted for a password IIRC.
> >
> > Aha, I thought my user would have the right to directly run commands
> > like apt-get without sudo.
>
> Not sure what you mean here.
> sudo apt-get dist-upgrade
> is the same as
> schroot -c $chroot -u root -- apt-get dist-upgrade
> You just don't get the switch to root as the default behaviour.
> You can certainly run commands as root directly.

I thought I could run
schroot -c $schroot -- apt-get dist-upgrade

But now I now that I have to do one of the following
sudo schroot -c $schroot -- apt-get dist-upgrade
schroot -c $schroot -u root -- apt-get dist-upgrade
...

> > But still when I run `sudo -u root` I get
> > sudo: effective uid is not 0, is sudo installed setuid root?
>
> This is /inside/ the chroot?

Yes.

> > I read that this could be because the filesystem is mounted with
> > 'nosuid' [1]. But this isn't the case. Here's my fstab for this schroot:
>
> I've never seen this. It's almost certainly due to the specific
> filesystems or setup you have. Check if it's really set setuid root.

I use ext4 for the /srv filesystem. And when I run ls -l for the schroot
directories (like `ls -l /srv/chroot/sid` or inside the schroot `ls
-l /`) the UID are root.

I haven't set the root password outside or inside so far.

But this is not so important atm. Maybe sometimes I'll find a
solution...
Or I'll just recreate the sid schroot if it'll bother me.

> > I read that chroot doesn't create any overhead except disk space. So
> > there's no drawback on using separate schroot environments for different
> > daemons except the extra disk space?
>
> Not really. And if you use e.g. btrfs snapshots, you avoid even
> the space overhead.

This sounds interesting. I'll learn more about this when I'll find
time :-)

> > E.g. the python libraries are only loaded once for each sid session I
> > run? No matter if python is installed in /srv/chroot/sid-sab and as well
> > in a new /srv/chroot/sid-mythbackend?
>
> No, they'll be separate files in this case, and hence loaded twice.
> But if you use LVM or Btrfs snapshots they would be the same physical
> disc blocks; and in the case of Btrfs the same file (AFAICK).

This really sounds great.
Thanks for the suggestion :-)

> > And does it make sense to use different partitions for each chroot
> > environment: Should I put /srv/chroot/sid-sab to an own partition?
> > Atm I have a ~300 GB partition mounted to /srv. The /srv/chroot/sid-sab
> > directory uses 466 MB so I could create a 5 GB partition for it?
>
> That would be fine. Personally, I have each chroot on a btrfs
> subvolume, that way there's no restrictions on how much each may
> grow, and they can be freely snapshotted. You can then use
> type=btrfs-snapshot or type=directory.

Great. Thanks again!!!


Cheers
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1343060527.4...@hoferr-desktop.hofer.rummelring

[Ramon Hofer]

On Mon, 2012-07-23 at 10:25 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> > On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > > > > I would also check the return status of schroot. If sid-sab
> > > > > already exists, then session creation will fail, and you'll
> > > > > reuse the old session. That might not be incorrect, but
> > > > > in the general case, I'd recommend checking.
> > > >
> > > > I was thinking about this too. But I saw no need to create a new session
> > > > if the old is still there.
> > > > What could be drawbacks of doing so?
> > >
> > > None really; they can even persist across reboots. (That's what
> > > the "recover-session" action is for.)
> >
> > Hmm, then maybe I should check if there'are lost sessions upon the start
> > of the script?
> > Or will either schroot -b or -r work with such a lost session?
>
> By default, the schroot init script will automatically recover any
> sessions at boot (see /etc/default/schroot). So you shouldn't have
> to worry about that. It's basically just running the setup scripts
> again to ensure that all filesystems are mounted, etc.

Ok, great!

I now changed the stop function to (added the if test) to get rid of
error messages when running `sid-sabnzbdplus stop` twice:
stop_sab() {
if [ -f /var/lib/schroot/session/sid-sab ]; then
schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
schroot -eq -c $NAME
else
echo "SABnzbd+ not running, not stooped" 2>&1
fi
}

Or is there a better way to test if a session is still available?
`schroot -l -c $NAME` didn't work because it returns the same error
message as e.q. `schroot -eq -c $NAME` when the session isn't running
anymore.


Cheers
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1343060842.4...@hoferr-desktop.hofer.rummelring

[Roger Leigh]

On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> I now changed the stop function to (added the if test) to get rid of
> error messages when running `sid-sabnzbdplus stop` twice:
> stop_sab() {
> if [ -f /var/lib/schroot/session/sid-sab ]; then
> schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
> schroot -eq -c $NAME
> else
> echo "SABnzbd+ not running, not stooped" 2>&1
> fi
> }
>
> Or is there a better way to test if a session is still available?
> `schroot -l -c $NAME` didn't work because it returns the same error
> message as e.q. `schroot -eq -c $NAME` when the session isn't running
> anymore.

That certainly works, but might break with future schroot versions,
since that directory is an implementation detail. You can do

schroot -l --all-sessions
==> session:sid-sbuild-28666af7-3e88-42cd-a83c-16267088d3f6

Note that this is also version-specific since only newer versions
add the session: namespace.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120723181...@codelibre.net

[Ramon Hofer]

On Mon, 2012-07-23 at 19:15 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> > I now changed the stop function to (added the if test) to get rid of
> > error messages when running `sid-sabnzbdplus stop` twice:
> > stop_sab() {
> > if [ -f /var/lib/schroot/session/sid-sab ]; then
> > schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
> > schroot -eq -c $NAME
> > else
> > echo "SABnzbd+ not running, not stooped" 2>&1
> > fi
> > }
> >
> > Or is there a better way to test if a session is still available?
> > `schroot -l -c $NAME` didn't work because it returns the same error
> > message as e.q. `schroot -eq -c $NAME` when the session isn't running
> > anymore.
>
> That certainly works, but might break with future schroot versions,
> since that directory is an implementation detail. You can do
>
> schroot -l --all-sessions
> ==> session:sid-sbuild-28666af7-3e88-42cd-a83c-16267088d3f6
>
> Note that this is also version-specific since only newer versions
> add the session: namespace.

Thanks alot for your help!

Now I'm testing with
[ "$(schroot -l --all-sessions)" = session:sid-sab ]
and hope that the output of future versions won't change 8-)


Best regards
Ramon

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1343077759....@hoferr-desktop.hofer.rummelring

[Bob Proulx]

Roger Leigh wrote:

> Bob Proulx wrote:
> > I haven't submitted a bug yet but I always have problems with sysvinit
> > postinst depending upon ischroot and ischroot getting it wrong and
> > that leaving a broken /run - /var/run behind. You might hit that too.
>
> If this is still happening, please file a serious bug against
> ischroot (debianutils IIRC) with the details of your system.
> It should not be getting it wrong in the simple case of a
> chroot.

While looking to file this bug I found that one had already been
filed on 26 Mar 2012.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827

There has been no response to this bug. With your advice I will add
more information to it and increase the severity to serious.

Bob

[Roger Leigh]

Note that this is a bug against initscripts, not debianutils.

Is the problem due to ischroot not working in your chroot?
Or is it due to initscripts not using the return value properly?

If it's a deficiency in the ischroot tool, then please file a
bug against debianutils about it. If it's the latter, then
a followup to the above bug is appropriate.

In the above bug's case, ischroot returns zero if it's a chroot,
1 if it's not a chroot, and 2 if it wasn't possible to tell. We
only run the chroot codepath if we get a zero value back,
otherwise we run the standard codepath for a base system. I'm
not sure that there's a more reasonable solution here--we don't
have the information to make a better choice if it's 2. So it
would be useful to know exactly what the return value of
ischroot is (it must be run as root), and why.


Regards,

Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120816001...@codelibre.net

[Bob Proulx]

Roger Leigh wrote:
> Bob Proulx wrote:

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827

>
> Note that this is a bug against initscripts, not debianutils.

Yes. But both are buggy! I also filed a bug against ischroot.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685034

> Is the problem due to ischroot not working in your chroot?
> Or is it due to initscripts not using the return value properly?

It is both. But the initscripts bug is the most grevious since it
ignores an error condition and leaves the system in a bad state. True
that ischroot returns the first error. But initscripts ignores the
error.

> If it's a deficiency in the ischroot tool, then please file a
> bug against debianutils about it. If it's the latter, then
> a followup to the above bug is appropriate.

I did that too.

> In the above bug's case, ischroot returns zero if it's a chroot,
> 1 if it's not a chroot, and 2 if it wasn't possible to tell. We
> only run the chroot codepath if we get a zero value back,
> otherwise we run the standard codepath for a base system. I'm
> not sure that there's a more reasonable solution here--we don't
> have the information to make a better choice if it's 2. So it
> would be useful to know exactly what the return value of
> ischroot is (it must be run as root), and why.

There are two issues. And I know that the /run transition was
discussed at length in debian-devel. Unfortunately I wasn't following
it then and only run into this problem now. I think using bind mounts
in either of the two cases is an unfortunate choice. I *really*
dislike it. So for me one issue is that the transition uses bind
mounts at all. But I am still investigating. I haven't figured out
why initscripts takes two different paths depending upon being in a
chroot or not. I think that is the root cause of the problem.
Whatever it decides to do it should to the same thing in either case.

Regardless the chroot problem is that initscripts upgrade in a chroot
leaves the host system with three additional bind mounts in the
chroot. These make working with the chroot by traditional means
difficult. For example in my test case I ended up with these
additional mounts which are invisible inside the chroot.

/dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run/lock ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run/shm ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0

Which means that basic operations on the chroot fail:

# rm -rf squeeze-test
rm: cannot remove `squeeze-test/run/lock': Device or resource busy
rm: cannot remove `squeeze-test/run/shm': Device or resource busy
rm: cannot remove `squeeze-test/var/run/lock': Device or resource busy
rm: cannot remove `squeeze-test/var/run/shm': Device or resource busy

# find squeeze-test -print
squeeze-test
squeeze-test/run
squeeze-test/run/lock
squeeze-test/run/shm
squeeze-test/var
squeeze-test/var/run
squeeze-test/var/run/lock
squeeze-test/var/run/shm

# umount /srv/chroot/squeeze-test/run/shm
# umount /srv/chroot/squeeze-test/run/lock
# umount /srv/chroot/squeeze-test/run
# rm -rf squeeze-test

But worse is that in order to continue to use the chroot that the /run
configuration needs to be manually re-stitched.

Bob

[Roger Leigh]

On Wed, Aug 15, 2012 at 06:54:56PM -0600, Bob Proulx wrote:
> There are two issues. And I know that the /run transition was
> discussed at length in debian-devel. Unfortunately I wasn't following
> it then and only run into this problem now. I think using bind mounts
> in either of the two cases is an unfortunate choice. I *really*
> dislike it. So for me one issue is that the transition uses bind
> mounts at all. But I am still investigating. I haven't figured out
> why initscripts takes two different paths depending upon being in a
> chroot or not. I think that is the root cause of the problem.
> Whatever it decides to do it should to the same thing in either case.

So one key question here: do you have /proc mounted inside the
chroot? That's required by ischroot to detect that it's in a chroot;
but more importantly, it's required for lots of things to work
properly, including libc, so it's something which is expected to be
present. Note that it's also used by package maintainer scripts, so
during an upgrade, it's also required.

The reason for the bind mounts. We are migrating:
/var/run -> /run
/var/lock -> /run/lock
/dev/shm -> /run/shm
/lib/init/rw -> [removed]
We are also doing this on a live system. We can't move the locations
except at boot time, but we want it to be functional as soon as
initscripts is configured. Then packages can simply Depend on
(initscripts >= $version) and get a functional /run. So it works in
two stages:
1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any
programs with open files on these filesystems will be unaffected.
Programs can use both the old and new paths without problems.
2) On reboot, mount a tmpfs on /run and replace these directories
with symlinks. Programs can use both the old and new paths.
This works very well. See
http://wiki.debian.org/ReleaseGoals/RunDirectory
for the detail.
However, it won't work in a chroot: chroots don't run init scripts at
boot, so on reboot, the bind mounts will be lost and the migration
won't complete. chroots are a special case, and because we can't
move the directories while they might be in use, we have to adopt a
different strategy. See the latest initscripts postinst in unstable
for what we have to deal with. It's really nasty; but we don't have a
choice. We also have little control over what parts of the host
system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need
to take extra special care never to modify them, lest we break the
host system.

One thing we could do here is check if /proc is mounted with
"mountpoint -q", and then assume we're in a chroot if it fails,
since having /proc not mounted is very unlikely on the host system.
However, it will need careful consideration, since the chroots are
the special case here--we never want to run the special case setup
for a chroot on the host system unintentionally. "Unlikely" isn't
a good enough guarantee here--we need to be absolutely certain.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120816105...@codelibre.net

[Bob Proulx]

Roger Leigh wrote:
> Bob Proulx wrote:

> > There are two issues. ...

>
> So one key question here: do you have /proc mounted inside the
> chroot?

No. I only do that if the task and applications I am running in the
chroot require it. But for my typical chroot these are rarely
required. Sure they are required to run Chromium, required to run
Apache, required to run a long list of things. But they have never
been required to compile a program for example. Being able to compile
using a specified environment is my usual need for specific
environments.

> That's required by ischroot to detect that it's in a chroot;

Apparently. But I call that a bug since it seems remarkably
insufficient to determine if the process is running in a chroot.
Having or not having /proc mounted isn't related to whether the root
directory of the calling process has been changed to a different root
directory. In practice I think that if there isn't a /proc mounted
then that would be a pretty strong indication that a chroot is in
effect.

Traditional Unix filesystems including ext{2,3,4} set the inode of the
root filesystem to 2. Inodes are uniquely numbered over the
filesystem. When a chroot has changed root to a different directory
then the root inode will be a number other than 2. That has been the
only sure way to know if the process is in a chroot. However I do not
know if all filesystems behave that way and I would bet that they do
not and therefore that test would be insufficient on other
filesystems. Those are the most common for root filesystems though
and using that test on those filesystems would be correct.

> but more importantly, it's required for lots of things to work
> properly, including libc, so it's something which is expected to be
> present.

I am not disagreeing that if we look at the sum total of all code
everywhere that a system expects to have various parts available. But
in the simple case for example of creating a chroot for compiling
software and other simple tasks there hasn't previously been a
requirement for having /proc or other extras mounted. If things are
moved to require it then I think that is a very bad direction of
movement. It makes things that would otherwise be very simple much
more complicated. That is bad.

Note that I did specify a policy-rc.d script to disallow running any
daemons other than those listed in the example.

So I do disagree that a simple chroot requires /proc. It never needed
it for Squeeze. If it has become so now then that is a terrible
misfeature and should be improved so as not to require it anymore.

> Note that it's also used by package maintainer scripts, so
> during an upgrade, it's also required.

Other than the 'initscripts' package what others in the basic
debootstrap related packages require it?

I think it is unfortunate to the point of being a bug that initscripts
has this dependency. Fortunately it is only during an upgrade and it
seems to work okay subsequently without it. So I only need to bridge
the gap of an upgrade. It definitely goes in my documentation of
special handling that is required for an upgrade.

I understand that Chromium, Apache, others, need /proc and other
extras. I am not disputing the long list of packages in the entire
repository. But in the basic system there hasn't been a need for it
previously. I am talking debootstrapping a basic installation and
installing basic things like build-essential. And I think that
includes the entire history of Unix-like systems since the early days.
I have been using chroots for a very long time. It is a very useful
feature.

> > And I know that the /run transition was
> > discussed at length in debian-devel. Unfortunately I wasn't following
> > it then and only run into this problem now. I think using bind mounts
> > in either of the two cases is an unfortunate choice. I *really*
> > dislike it. So for me one issue is that the transition uses bind
> > mounts at all. But I am still investigating. I haven't figured out
> > why initscripts takes two different paths depending upon being in a
> > chroot or not. I think that is the root cause of the problem.
> > Whatever it decides to do it should to the same thing in either case.
>

> The reason for the bind mounts. We are migrating:
> /var/run -> /run
> /var/lock -> /run/lock
> /dev/shm -> /run/shm
> /lib/init/rw -> [removed]
> We are also doing this on a live system. We can't move the locations
> except at boot time, but we want it to be functional as soon as
> initscripts is configured. Then packages can simply Depend on
> (initscripts >= $version) and get a functional /run. So it works in
> two stages:
> 1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any
> programs with open files on these filesystems will be unaffected.
> Programs can use both the old and new paths without problems.
> 2) On reboot, mount a tmpfs on /run and replace these directories
> with symlinks. Programs can use both the old and new paths.
> This works very well. See
> http://wiki.debian.org/ReleaseGoals/RunDirectory
> for the detail.

Thank you very much for that nice summary! It helps me a lot.

> However, it won't work in a chroot: chroots don't run init scripts at
> boot, so on reboot, the bind mounts will be lost and the migration
> won't complete.

And in the case of a simple chroot the bind mounts make the
directories "busy" and create a sumbling block. Until the system is
rebooted and then things return to a non-blocked state. But of course
then the /run related dirs need to be fixed up.

> chroots are a special case, and because we can't
> move the directories while they might be in use, we have to adopt a
> different strategy. See the latest initscripts postinst in unstable
> for what we have to deal with.

I will read through them.

> It's really nasty; but we don't have a choice.

You always have choices. You may not like the current ones. There
will always be possibilities you have not thought of yet. They are
many and uncountable.

Perhaps a better statement would be that among the choices considered
the least objectionable choice was taken.

> We also have little control over what parts of the host
> system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need
> to take extra special care never to modify them, lest we break the
> host system.

Agreed.

> One thing we could do here is check if /proc is mounted with
> "mountpoint -q", and then assume we're in a chroot if it fails,
> since having /proc not mounted is very unlikely on the host system.

Yes. That would definitely improve things.

At the least if ischroot returns an error then you know there is
already problem with the postinst assumptions. That case is
definitely not handled correctly.

> However, it will need careful consideration, since the chroots are
> the special case here--we never want to run the special case setup
> for a chroot on the host system unintentionally. "Unlikely" isn't
> a good enough guarantee here--we need to be absolutely certain.

Given the choice between host system breakage and chroot system
breakage I would of course always choose breaking the chroot over
breaking the host system.

But if that is a possibility to break something then improved
documentation in the form of yet another critical package NEWS item
should explain the reason for the breakage and what needs to be done
to work around it.

Bob