[clug] init.d for chroot

jm jeffm at ghostgun.com
Fri Jul 14 06:00:00 UTC 2017

On 14/07/2017 14:31, steve jenkin wrote:
> Jeff,
> I would’ve hoped “localhost” worked with a remote monitoring environment, allowing you to avoid duplicated environments entirely.
> As you say, different incompatible package versions have left you with a difficult problem.
> chroot(2) was first implemented before /proc & /sys were added into Linux.
> Process control was done solely via syscalls and chroot’s did not provide ‘process control' isolation for safe sandboxes.
> Networking, BSD sockets, also came after chroot() and chroot’ed processes weren’t controlled there either. 
> The FreeBSD jail(2), circa 2000, was an attempt to provide strong process isolation / sandboxes.
> Linux containers, ending with the common LXC environment supported in the kernel, addressed these weaknesses, creating good ‘sandbox’ environments, as leveraged by Docker and others.
> Because ‘containers’ start with a chroot(), they need to create a full executable environment: why they need a mini-distribution installed in each.
> Creating a ‘simple’ working chroot environment requires a deal of work to make ‘enough’ of an running environment available.
> For example: If you haven’t mounted /proc into the chroot environment, nothing related to processes will work.
> If you haven’t created & populated /bin and /lib, you won’t be able to perform many actions, including opening new dynamic libraries.
> Not sure if the loader, needed to fork a process IIRC, will fail or not - there is no path to the userland component.
> If you’re having trouble returning a PID from a chroot’ed script, it may be because you need to create more of an environment within the chroot dirs.
> I’d include a ‘bind’ mount of /var/run for supervisord to store the PID - but you’d need two versions (names) of that file, one for the local version and another for the remote.
> I’m not sure of the process control isolation semantics applying to chroot() using /proc.
> I think they are spawned under a new ‘process group’, making them able to control only processes within that ‘group’ (e.g. kill).
> But I’d expect main system processes (not chrooted), would be able to control all processes, including with the chroot, as per normal semantics.
> Some “how to’s” on setting up chroot() environments.
> Perhaps there’s something you need to add to the chroot environment you’ve created for the older (?) package.
> CentOs:
> <https://wiki.centos.org/HowTos/ManualInstall>
> Random older page:
> How to build a chroot jail environment for CentOS
> <https://geek.co.il/2010/03/14/how-to-build-a-chroot-jail-environment-for-centos>
> Debian:
> [worth reading even for CentOS users, lists many steps, including all the ‘mount’ commands needed]
> <https://wiki.debian.org/chroot>
> stevej

To give more background. I'm untangling a preexisting environment. I've
created a CentOS environment via rpm and yum.  There are a number of
in-house application which hook into the program running in the chroot
environment so these have to go in as well. These are deployed using a
deploy script that is used to install in-house applications based on
settings held in a file. This script is only partially chroot aware as I
added the necessary features the last time I worked on this. It needs
more work as it tries to set up control (start/stop) of the applications
on the main host. Adding more chroot awareness to have it set up
control  with in the chroot environment would ease a move toward
possible containerisation further along. All this has to be done through
the orchestration software which is possibly ironically as it is package
having the clash that caused all this.

Regarding your comment on a bind mount for /var/run. Interesting idea.
It seems to be running alright at the moment. I can start and stop
supervisord with the init.d script I've created, so I may just leave it
as is.

I had avoided mounting /proc until now but it turns out that one of the
in-house applications uses pythons psutils which needs /proc/stat


More information about the linux mailing list