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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343060527.4271.17.camel@hoferr-desktop.hofer.rummelring
