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
Attachment:
signature.asc
Description: Digital signature