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! >> 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 "$@" 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-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jue2u5$thd$1...@dough.gmane.org