Re: Daemons in schroot or how to start chroot automatically
On Mon, 2012-07-23 at 11:34 +0100, Roger Leigh wrote:
> 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.
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
Reply to: