[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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




On 08/17/2016 04:00 AM, Jan Pazdziora wrote:
> 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?
>
Sure I would consider this.  Please open a PULL Request. We would
probably want to add one for INSTALL, UNINSTALL, RUN ...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]