init.d for chroot

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

init.d for chroot

Samba - linux mailing list

Due to a package clash between one version of a program used to support
other hosts that has to run on this host and the one used to support
this host I've set up a chrooted environment. I'm to the stage where I'm
trying to start it from an init.d script - This is a CentOS 6 (yes, 6)
box. The init.d script needs to start supervisord within the chroot
which will then watch over the few processes that need to run chrooted
for this to work. The problem here is that I can't work out how to get
the pid of the chrooted process to record it later for the stop part of
the script. I can't kill it be name via killproc as there is already a
supervisord process on the host.

The the key parts of the script in skeleton form at the moment is,

start () {
  echo -n $"Starting chrootname supervisord: "
  chroot /chrootpath /usr/bin/supervisord -c /etc/supervisord.conf
  # Store pid of supervisord
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/chrootname-supervisord
}

stop () {
  echo -n $"Stopping chrootenv supervisord: "
  # Get stored pid and kill process
}

Does anyone have any experience with scripts like this or thoughts on
how to do this? I'm currently think about putting a wrapper around
supervisor that runs in the chroot env to record the pid in the chroot env.

Jeff.



--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In this case I found that supervisord can be shutdown via "supervisorctl
shutdown", so

  chroot /chrootpath /usr/bin/supervisorctl shutdown


In general, I'd still like to know if I wasn't dealing with a process
with a shutdown command how I could have recorded the pid to kill it later.

Jeff.

On 12/07/2017 14:44, jm via linux wrote:
> Does anyone have any experience with scripts like this or thoughts on
> how to do this? I'm currently think about putting a wrapper around
> supervisor that runs in the chroot env to record the pid in the chroot env.
>
> Jeff.
>
>
>


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
On 12/07/17 15:09, jm via linux wrote:

> In this case I found that supervisord can be shutdown via "supervisorctl
> shutdown", so
>
>   chroot /chrootpath /usr/bin/supervisorctl shutdown
>
>
> In general, I'd still like to know if I wasn't dealing with a process
> with a shutdown command how I could have recorded the pid to kill it later.
>
> Jeff.

Linux Containers (lxc) (and equivalent docker etc.) are like chroot on
steroids - in this case keeping processes isolated, so you can run an
init.d (as pid 1) in the container, and also run supervisord etc. in
the container, separately to the host's versions of the same.

Not sure what support Centos 6 has for containers, though...

cheers,

Bob Edwards.

>
> On 12/07/2017 14:44, jm via linux wrote:
>> Does anyone have any experience with scripts like this or thoughts on
>> how to do this? I'm currently think about putting a wrapper around
>> supervisor that runs in the chroot env to record the pid in the chroot env.
>>
>> Jeff.
>>
>>
>>
>
>


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In this case I'm just trying to avoid a package clash. I'll probably end
up at containers in the end anyway. For some things here I've got my eye
on unikernels though I'd still like a separation between kernel and user
space. The idea of a minimal kernel is interesting from a security and
performance perspective, but the lack of builtin monitoring could be a
concern.

Jeff.


On 12/07/2017 16:35, Bob Edwards via linux wrote:

>
> Linux Containers (lxc) (and equivalent docker etc.) are like chroot on
> steroids - in this case keeping processes isolated, so you can run an
> init.d (as pid 1) in the container, and also run supervisord etc. in
> the container, separately to the host's versions of the same.
>
> Not sure what support Centos 6 has for containers, though...
>
> cheers,
>
> Bob Edwards.


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In reply to this post by Samba - linux mailing list
jm via linux <[hidden email]> writes:

> Due to a package clash between one version of a program used to support
> other hosts that has to run on this host and the one used to support
> this host I've set up a chrooted environment. I'm to the stage where I'm
> trying to start it from an init.d script - This is a CentOS 6 (yes, 6)
> box. The init.d script needs to start supervisord within the chroot
> which will then watch over the few processes that need to run chrooted
> for this to work. The problem here is that I can't work out how to get
> the pid of the chrooted process to record it later for the stop part of
> the script. I can't kill it be name via killproc as there is already a
> supervisord process on the host.
>
> The the key parts of the script in skeleton form at the moment is,
>
> start () {
>   echo -n $"Starting chrootname supervisord: "
>   chroot /chrootpath /usr/bin/supervisord -c /etc/supervisord.conf
>   # Store pid of supervisord
>   RETVAL=$?
>   echo
>   [ $RETVAL -eq 0 ] && touch /var/lock/subsys/chrootname-supervisord
> }
>
> stop () {
>   echo -n $"Stopping chrootenv supervisord: "
>   # Get stored pid and kill process
> }
>
> Does anyone have any experience with scripts like this or thoughts on
> how to do this? I'm currently think about putting a wrapper around
> supervisor that runs in the chroot env to record the pid in the chroot env.

supervisor does or at least can write the pid file itself, though
possibly you have an old version which doesn't have that option?

cheers

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In reply to this post by Samba - linux mailing list

> On 12 Jul 2017, at 14:44, jm via linux <[hidden email]> wrote:
>
>
> Due to a package clash between one version of a program used to support
> other hosts that has to run on this host and the one used to support
> this host I've set up a chrooted environment. I'm to the stage where I'm
> trying to start it from an init.d script - This is a CentOS 6 (yes, 6)
> box. The init.d script needs to start supervisord within the chroot
> which will then watch over the few processes that need to run chrooted
> for this to work. The problem here is that I can't work out how to get
> the pid of the chrooted process to record it later for the stop part of
> the script. I can't kill it be name via killproc as there is already a
> supervisord process on the host.
>
> The the key parts of the script in skeleton form at the moment is,
>
> start () {
>  echo -n $"Starting chrootname supervisord: "
>  chroot /chrootpath /usr/bin/supervisord -c /etc/supervisord.conf
>  # Store pid of supervisord
>  RETVAL=$?
>  echo
>  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/chrootname-supervisord
> }
>
> stop () {
>  echo -n $"Stopping chrootenv supervisord: "
>  # Get stored pid and kill process
> }
>
> Does anyone have any experience with scripts like this or thoughts on
> how to do this? I'm currently think about putting a wrapper around
> supervisor that runs in the chroot env to record the pid in the chroot env.
>
> Jeff.


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>

HTH
stevej

--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:[hidden email] http://members.tip.net.au/~sjenkin


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
While you're thinking about chroots and containers etc, I suggest having a
quick read of Jessie Frazelle's blog. She writes very well on the topic:
https://blog.jessfraz.com/

--
MC
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
On 14/07/17 14:45, Mike Carden via linux wrote:
> While you're thinking about chroots and containers etc, I suggest having a
> quick read of Jessie Frazelle's blog. She writes very well on the topic:
> https://blog.jessfraz.com/
>

Looks cool. She does write well, but aimed well above my head.

Looking at:
https://blog.jessfraz.com/post/docker-containers-on-the-desktop/
can anyone suggest how I can follow her lead on running lynx inside
a Docker container (point 4. Lynx)?

So far:
  sudo apt-get install docker.io
('cause the Debian "docker" package is not docker...)
futz around to get a shell with me in the docker group...

  docker run -it --name lynx bob/lynx
(changed jess/lynx to bob/lynx - no idea what this is about).
gives me:
Unable to find image 'bob/lynx:latest' locally
Pulling repository bob/lynx
FATA[0003] Error: image bob/lynx:latest not found

Looked at the link "Dockerfile" - not sure what to do with this
file...

Any tips for a lazy Friday arvo hacker?

cheers,

Bob Edwards.

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In reply to this post by Samba - linux mailing list
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>
>
> HTH
> 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



Jeff.




--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: init.d for chroot

Samba - linux mailing list
In reply to this post by Samba - linux mailing list
Bob Edwards via linux <[hidden email]> writes:

> On 14/07/17 14:45, Mike Carden via linux wrote:
>> While you're thinking about chroots and containers etc, I suggest having a
>> quick read of Jessie Frazelle's blog. She writes very well on the topic:
>> https://blog.jessfraz.com/
>>
>
> Looks cool. She does write well, but aimed well above my head.
>
> Looking at:
> https://blog.jessfraz.com/post/docker-containers-on-the-desktop/
> can anyone suggest how I can follow her lead on running lynx inside
> a Docker container (point 4. Lynx)?
>
> So far:
>   sudo apt-get install docker.io
> ('cause the Debian "docker" package is not docker...)
> futz around to get a shell with me in the docker group...
>
>   docker run -it --name lynx bob/lynx
> (changed jess/lynx to bob/lynx - no idea what this is about).

The jess/lynx is the name of the image. Think of it like a tarball of
the root filesystem + metadata.

To create a container you use docker run and give it the name of the
image.

> gives me:
> Unable to find image 'bob/lynx:latest' locally
> Pulling repository bob/lynx
> FATA[0003] Error: image bob/lynx:latest not found

You need to have a bob/lynx image to run. You didn't, so it tried to
pull it (download it) from docker hub (website with lots of images on
it).

> Looked at the link "Dockerfile" - not sure what to do with this
> file...

The Dockerfile is meant to be analagous to a Makefile, but it builds a
docker image not a software package. They're actually quite different in
detail though.

If you look at her Dockerfile:

  FROM debian:stretch

That says "start with a root filesystem that has debian stretch on it".

  LABEL maintainer "Jessie Frazelle <[hidden email]>"
 
That just gives the image a maintainer, you can drop it or change it to you.

  RUN apt-get update && apt-get install -y \
  lynx \
  --no-install-recommends \
  && rm -rf /var/lib/apt/lists/*
 
This is a bit gross because of some of the details of how docker works,
but the key thing is that it RUNs a command. It starts by doing an
apt-get update, because the debian root filesystem you start from has
no/out-of-date package lists. Then it just apt-get installs lynx, and
finally it deletes the apt lists because you don't want to carry them
around in your image for ever.

  ENTRYPOINT [ "lynx" ]

That just says "when someone docker runs this image, run lynx".


To actually build the image you want to:

  $ mkdir whatever
  $ cd whatever
  $ wget https://raw.githubusercontent.com/jessfraz/dockerfiles/master/lynx/Dockerfile
  $ docker build -t bob/lynx .

Output will be ~=:

Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM debian:stretch
stretch: Pulling from library/debian
c75480ad9aaf: Pull complete
Digest: sha256:7d067f77d2ae5a23fe6920f8fbc2936c4b0d417e9d01b26372561860750815f0
Status: Downloaded newer image for debian:stretch
 ---> a2ff708b7413
Step 2/4 : LABEL maintainer "Jessie Frazelle <[hidden email]>"
 ---> Running in aeeb879cb468
 ---> 2a0a34fa5c4a
Removing intermediate container aeeb879cb468
Step 3/4 : RUN apt-get update && apt-get install -y lynx --no-install-recommends && rm -rf /var/lib/apt/lists/*
 ---> Running in 8766b0977ac7
Get:1 http://security.debian.org stretch/updates InRelease [62.9 kB]
Ign:2 http://deb.debian.org/debian stretch InRelease
Get:3 http://deb.debian.org/debian stretch-updates InRelease [88.5 kB]
Get:4 http://security.debian.org stretch/updates/main amd64 Packages [76.6 kB]
Get:5 http://deb.debian.org/debian stretch Release [113 kB]
Get:6 http://deb.debian.org/debian stretch Release.gpg [3108 B]
Get:7 http://deb.debian.org/debian stretch/main amd64 Packages [9497 kB]
Fetched 9841 kB in 5s (1708 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libbsd0 libffi6 libgmp10 libgnutls30 libhogweed4 libidn11 libnettle6
  libp11-kit0 libtasn1-6 lynx-common
Suggested packages:
  gnutls-bin
Recommended packages:
  mime-support
The following NEW packages will be installed:
  libbsd0 libffi6 libgmp10 libgnutls30 libhogweed4 libidn11 libnettle6
  libp11-kit0 libtasn1-6 lynx lynx-common
0 upgraded, 11 newly installed, 0 to remove and 1 not upgraded.
Need to get 3585 kB of archives.
After this operation, 10.4 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian stretch/main amd64 libgmp10 amd64 2:6.1.2+dfsg-1 [253 kB]
<snip>
Get:11 http://deb.debian.org/debian stretch/main amd64 lynx amd64 2.8.9dev11-1 [632 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 3585 kB in 1s (2346 kB/s)
Selecting previously unselected package libgmp10:amd64.
(Reading database ... 6491 files and directories currently installed.)
Preparing to unpack .../00-libgmp10_2%3a6.1.2+dfsg-1_amd64.deb ...
<snip>
Setting up lynx (2.8.9dev11-1) ...
update-alternatives: using /usr/bin/lynx to provide /usr/bin/www-browser (www-browser) in auto mode
Processing triggers for libc-bin (2.24-11+deb9u1) ...
 ---> 4de94b48575c
Removing intermediate container 8766b0977ac7
Step 4/4 : ENTRYPOINT lynx
 ---> Running in 526873907d34
 ---> 8f5ad0738bd7
Removing intermediate container 526873907d34
Successfully built 8f5ad0738bd7
Successfully tagged bob/lynx:latest


Then:

$ docker images
REPOSITORY           TAG                 IMAGE ID            CREATED              SIZE
bob/lynx             latest              8f5ad0738bd7        About a minute ago   110MB

The ID will be different.

And then you can do:

$ docker run -it --name lynx bob/lynx

Once you quit out of lynx you can do:

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
b9544063b465        bob/lynx            "lynx"              31 seconds ago      Exited (0) 26 seconds ago                       lynx

You can run that container again with:

$ docker start -ia b9544063b465

Or delete it with:

$ docker rm b9544063b465

If you want to have a look around inside the image do:

$ docker run -it --entrypoint=/bin/sh bob/lynx
# cat /etc/issue
Debian GNU/Linux 9 \n \l
# id
uid=0(root) gid=0(root) groups=0(root)

etc.

cheers

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Loading...