Re: [atomic-devel] The atomic command and setting hostname for containers

[Jan Pazdziora <jpazdziora redhat com>]

On Wed, Apr 20, 2016 at 02:31:22PM +0200, Jan Pazdziora wrote:
> On Tue, Apr 19, 2016 at 02:02:51PM -0700, Daniel J Walsh wrote:
> > 
> > But I like your example better.  atomic install should almost always be a
> > privileged container.
> 
> I think my only concern is that RUN will have to be privileged
> container (which will spawn an unprivileged one) as well because
> with atomic 1.9 we no longer can do
> 
> 	LABEL RUN 'docker run -h "$(cat /var/lib/${NAME}/hostname)" ...'

I got back to this problem while finalizing the IPA/IdM container
for release.

It looks like latest versions of atomic will show

	This container uses privileged security switches:
	INFO: --privileged 
	      This container runs without separation and should be considered the same as root on your system.

even if the only thing that the run.sh called from

	LABEL RUN 'docker run -ti --rm --privileged -v /:/host -e HOST=/host -e DATADIR=/var/lib/${NAME} -e IMAGE=${IMAGE} ${IMAGE} /bin/run.sh'

does is

	#!/bin/bash
	set -e
	HOSTNAME=$( cat "$HOST$DATADIR"/hostname )
	chroot "$HOST" /usr/bin/docker run -ti --rm \
		-v "$DATADIR":/data:Z -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
		--tmpfs /run --tmpfs /tmp -h "$HOSTNAME" "$IMAGE"

-- starting the real processes in another unprivileged container.

Do we plan to have a way to override this message? Users would likely
be concerned seeing it.

For me, the ideal approach would be adding ability to the atomic
command to read some location, specified by some LABEL like
RUN_OPTS_FILE and expose parameters found in file on that location
in place of some option in LABEL RUN.

So during atomic install, I could populate
$HOST/var/lib/${NAME}/docker-run-opts with things like

	-h ipa.example.test

or

	--net host

and I could say

	LABEL RUN_OPTS_FILE /var/lib/${NAME}/docker-run-opts
	LABEL RUN 'docker run ${RUN_OPTS} ...'

in the Dockerfile and the RUN-command would get parameters prepared
and persistently stored by the INSTALL-command.

Is that something that the team would be willing to consider?

-- 
Jan Pazdziora | adelton at #ipa*, #brno
Sr. Principal Software Engineer, Identity Management Special Projects, Red Hat