Re: Daemons in schroot or how to start chroot automatically
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
Reply to: