New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run /sbin/init #223

Closed
mojodna opened this Issue Mar 27, 2013 · 31 comments

Comments

Projects
None yet
@mojodna

mojodna commented Mar 27, 2013

This would allow docker to be used to manage containers in full-on instance mode vs. single-use containers.

@jpetazzo

This comment has been minimized.

Contributor

jpetazzo commented Mar 27, 2013

Docker currently overrides /sbin/init, but you can try the following hack:

  • copy /sbin/init to /sbin/init.real
  • start /sbin/init.real
    You will probably hit weird things since the init system will try to setup things that it really shouldn't mess up with (like network interfaces and filesystems) but that would be a good starting point.
@shykes

This comment has been minimized.

Collaborator

shykes commented Mar 27, 2013

Totally agree, this would be very useful and there is nothing in Docker's design preventing it.

Currently this will not work because of the following implementation detail: when starting a new container, docker mint-bounds itself as /sbin/init inside the container, hiding the real /sbin/init and in the proces smaking it unavailable for execution.

Once docker-as-init has been executed, the binary can be safely unmounted, un-hiding the real /sbin/init and making it available for execution. The problem is that unmounting must be done from outside the container, which requires cross-namespace synchronization between docker-as-init and dockerd. This can be implemented over a unix socket for example.

@sa2ajj

This comment has been minimized.

Contributor

sa2ajj commented Mar 27, 2013

(I'm not sure if it's totally relevant)

lxc comes with templates for various distributions, and those templates do heavy hacking of the freshly installed systems to make them runnable in a container (e.g. Debian template and Ubuntu template)

So if the filesystem is not "adjusted", users might run into other kind of problems...

@vsekhar

This comment has been minimized.

vsekhar commented Mar 28, 2013

Bringing up an entire system is a use case better served by virtualization. I'm not saying it should be impossible to do with docker, just that it's not the core value prop. Docker seems to be best at process-level isolation, not machine-level. I think encouraging developers to think this way is helpful, and adding complexity/fragility to support full instances seems like a poor tradeoff.

lxc is mostly the same and the hacks needed in their full-system templates are evidence of that.

@sa2ajj

This comment has been minimized.

Contributor

sa2ajj commented Mar 28, 2013

@vsekhar, I agree.

@shykes

This comment has been minimized.

Collaborator

shykes commented Mar 28, 2013

I agree also. The fix I propose is the right thing to do anyway - the less
side-effects on the guest filesystem, the better. If further changes are
necessary and those changes deviate from Docker's core value prop, we might
not implement them. At this time I'm not aware of any extra changes needed
though.

On Wed, Mar 27, 2013 at 5:21 PM, Mikhail Sobolev
notifications@github.comwrote:

@vsekhar https://github.com/vsekhar, I agree.


Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-15561614
.

@wereHamster

This comment has been minimized.

wereHamster commented Mar 29, 2013

Docker overwrites /sbin/init inside the container for three reasons: 1) set the default gateway route, 2) change the user and 3) clean up container from the environment. 1) can be solved by setting lxc.network.ipv4.gateway in the lxc config file, 2) could be left to the user run command (there are chpst, sudo, sysv init scripts, upstart, systemd can do it as well) and 3) what's the reason for that?

@jpetazzo

This comment has been minimized.

Contributor

jpetazzo commented Mar 29, 2013

  1. lxc.network.ipv4.gateway doesn't work with lxc userland tools 0.7, that's why we implemented it; we need to make sure that it works with the tools provided with 12.04.
  2. Setting the user from docker itself allows to run unprivileged processes without relying on something specific in the container (which in some cases is a nice feature)
  3. Not sure about that one!

I don't know if we are ready to drop the /sbin/init override yet, but it might become an option switch.

@shykes

This comment has been minimized.

Collaborator

shykes commented May 29, 2013

I feel like we could solve a big part of the problem simply by mounting docker as /sbin/docker-init instead of /sbin/init. Not perfect but should be good enough.
I know of at least one person who gave up on using docker in favor of a home-made script which did exactly that.

Does anybody oppose this? Any negative side-effects I'm not thinking of?

@jpetazzo

This comment has been minimized.

Contributor

jpetazzo commented May 29, 2013

Might work, but remember that you need to create /sbin/docker-init then.
A good candidate for injection (that would almost always be there, and
could be created harmlessly if it's not) is /bin/true.

@shykes

This comment has been minimized.

Collaborator

shykes commented May 29, 2013

Couldn't we just create /sbin/docker-init? Especially if we're going to
have logic to create /bin/true if it doesn't exist anyway.

On Tue, May 28, 2013 at 6:15 PM, Jérôme Petazzoni
notifications@github.comwrote:

Might work, but remember that you need to create /sbin/docker-init then.
A good candidate for injection (that would almost always be there, and
could be created harmlessly if it's not) is /bin/true.


Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18590503
.

@jpetazzo

This comment has been minimized.

Contributor

jpetazzo commented May 29, 2013

That works too. Initially the point of bind-mounting init and resolv.conf
(vs. just copying) was to avoid modifying the existing image. Depends if
that's still a priority or not.

@shykes

This comment has been minimized.

Collaborator

shykes commented May 29, 2013

Should be simple enough to scope the bind-mount with a touch/rm in case it
doesn't exist, to cover all cases.

On Tue, May 28, 2013 at 6:31 PM, Jérôme Petazzoni
notifications@github.comwrote:

That works too. Initially the point of bind-mounting init and resolv.conf
(vs. just copying) was to avoid modifying the existing image. Depends if
that's still a priority or not.


Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18590992
.

@tianon

This comment has been minimized.

Member

tianon commented May 29, 2013

I'm not terribly well versed in the issues involved here, but had an idea I wanted to share in case it's useful. What if you check for the existence of /sbin/docker-init first, and if it is there, you use that (so that images prepared specifically with docker in mind can include it and get "upgraded" docker functionality, if you will), but if it isn't, you use /sbin/init (so images that aren't necessarily prepared with docker in mind still work properly).

Again, I'm not well versed in the issues, or have much opinion either way, but it was a thought I had so I figured I'd share in case I'm thinking of something useful (but might just be more complex than what is wanted).

@shykes

This comment has been minimized.

Collaborator

shykes commented May 29, 2013

Hey Tianon, what you're describing is indeed very useful, and you can
already do it by setting a default command in the container's metadata.
This way the container author doesn't need to create a specially named file

  • you can name it whatever you like and tell docker to run it by default.

One thing thing this doesn't allow is telling docker to execute an "entry
point" command every time the container is run, regardless of the command
specified by the user. That could be an interesting addition.

In any case, those 2 topics are different from what we're discussing -
specifically the ability for the user to type "docker run CONTAINER
/sbin/init" without having docker blow up :)

On Tue, May 28, 2013 at 7:59 PM, Tianon Gravi notifications@github.comwrote:

I'm not terribly well versed in the issues involved here, but had an idea
I wanted to share in case it's useful. What if you check for the existence
of /sbin/docker-init first, and if it is there, you use that (so that
images prepared specifically with docker in mind can include it and get
"upgraded" docker functionality, if you will), but if it isn't, you use
/sbin/init (so images that aren't necessarily prepared with docker in mind
still work properly).

Again, I'm not well versed in the issues, or have much opinion either way,
but it was a thought I had so I figured I'd share in case I'm thinking of
something useful (but might just be more complex than what is wanted).


Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18593352
.

@tianon

This comment has been minimized.

Member

tianon commented May 29, 2013

Ah, that makes much more sense. Thanks for clearing that up! :)

@shykes

This comment has been minimized.

Collaborator

shykes commented Jun 15, 2013

Hey guys, there's a pull request pending to make this possible: #898.

It looks like the base images will need some tweaking to boot properly (booting seems to hang on udev-related things for both ubuntu and centos), but I don't expect it to be too hard.

@shykes

This comment has been minimized.

Collaborator

shykes commented Aug 13, 2013

This has been merged into master, and is scheduled for the 0.6 stable release (target is August 21)

@epeli

This comment has been minimized.

epeli commented Nov 6, 2013

Ok, this should be in the release now. How do I in practice start the full container in Docker?

I've also posted this on Stackoverflow http://stackoverflow.com/questions/19332662/start-full-container-in-docker

@shykes

This comment has been minimized.

Collaborator

shykes commented Nov 14, 2013

@epeli if you want to start in "machine mode" you can 'docker run /sbin/init'

@chenyf

This comment has been minimized.

chenyf commented Nov 18, 2013

hi, @shykes , I start container with :
docker run -d ubuntu:12.04 /sbin/init
This start a container, but how can I login into this container or attach this container?

@tianon

This comment has been minimized.

Member

tianon commented Nov 18, 2013

You'd have to set the root password and install openssh-server. You probably want to use a Dockerfile or docker run bash then docker commit to get the image setup the way you want/need it before you run /sbin/init.

@chenyf

This comment has been minimized.

chenyf commented Nov 18, 2013

HI, @tianon ,
Now I try following steps:
1). docker run -i -t ubuntu:12.04 /bin/bash
2). inside container:

dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

install openssh-server inside it;

cd /etc/init
mv ssh.conf ssh.conf.bak

after these steps, I can start ssh server with both " service ssh start" or "/etc/init.d/ssh start"

3). commit the image
4). start a container with this new image and '/sbin/init'
docker run -d xxxxx /sbin/init

5).
ps auxf

I can't find ssh server inside container.

@chenyf

This comment has been minimized.

chenyf commented Nov 18, 2013

image

@chenyf

This comment has been minimized.

chenyf commented Nov 18, 2013

above is the screen snapshot, you can find /sbin/init inside container 8936xxxx

@chenyf

This comment has been minimized.

chenyf commented Nov 18, 2013

docker version is 0.6.6

@blalor

This comment has been minimized.

blalor commented Nov 20, 2013

docker run $IMAGE /sbin/init works perfectly. Thank you!

@chenyf

This comment has been minimized.

chenyf commented Nov 21, 2013

Hi, @blalor Could you give a detail step about how to use /sbin/init ? thanks!

@blalor

This comment has been minimized.

blalor commented Nov 21, 2013

@chenyf I'm not sure what you're looking for. I'm using the centos base image so life is apparently easier than dealing with ubuntu.

Dockerfile:

FROM centos
RUN yum install -y openssh-server
RUN yum install -y passwd
RUN echo d0cker | passwd --stdin root

## https://github.com/dotcloud/docker/issues/1240#issuecomment-21807183
RUN echo "NETWORKING=yes" > /etc/sysconfig/network

## http://gaijin-nippon.blogspot.com/2013/07/audit-on-lxc-host.html
RUN sed -i -e '/pam_loginuid\.so/ d' /etc/pam.d/sshd

EXPOSE 22
CMD /sbin/init

Run it: docker run -d -P $IMAGE
Find ssh port: docker port $CONTAINER 22
Connect: ssh -p $PORT root@localhost

@kiorky

This comment has been minimized.

Contributor

kiorky commented Nov 21, 2013

you may have a look to our ubuntu based containers
(https://github.com/makinacorpus/vms/tree/master/docker)
You can have also a look to this entry point for a bunch of bugs: #2276

@benbooth493

This comment has been minimized.

benbooth493 commented Jan 6, 2014

I'm looking to running squeeze inside a container as a full-blown vps using the tricks above, but I'm having no success.
Can anyone help?

rtyler pushed a commit to rtyler/docker that referenced this issue Feb 23, 2018

Merge pull request moby#223 from stigsb/configurable_uid_gid
Make user/group/uid/gid configurable with docker --build-arg
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment