Skip to content

update fedora URLs #497

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

Closed

Conversation

lsm5
Copy link
Contributor

@lsm5 lsm5 commented Feb 17, 2015

This commit updates the URLs for fedora images which allow running systemd
inside container

Thanks to Vaclav Pavlin vpavlin@redhat.com for the image updates

Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org

@lsm5
Copy link
Contributor Author

lsm5 commented Feb 17, 2015

ping @yosifkit @tianon @vpavlin

@lsm5
Copy link
Contributor Author

lsm5 commented Feb 17, 2015

@tianon this doesn't include the fix for setting default timezone to UTC, that fix might take a while :|

@lsm5
Copy link
Contributor Author

lsm5 commented Feb 17, 2015

hmm, invalid ref :| ...will recheck and get back

This commit updates the URLs for fedora images which allow running systemd
inside container

Thanks to Vaclav Pavlin <vpavlin@redhat.com> for the image updates

Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
@lsm5 lsm5 force-pushed the fedora-systemd-updates branch from 049b2e1 to 330675e Compare February 17, 2015 16:50
@lsm5
Copy link
Contributor Author

lsm5 commented Feb 17, 2015

'latest' pointed to a stale commit earlier, fixed now

@yosifkit
Copy link
Member

Diff for latest/21:

diff --git a/Dockerfile b/Dockerfile
index b0d13f3..2cba2e6 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,3 +1,17 @@
 FROM scratch
 MAINTAINER Lokesh Mandvekar <lsm5@fedoraproject.org>
 ADD fedora-21-release.tar.xz /
+
+#systemd fails to mount stuff in containers due to missing sysadmin cap
+RUN systemctl mask systemd-remount-fs.service dev-hugepages.mount sys-fs-fuse-connections.mount systemd-logind.service getty.target console-getty.service
+
+#dbus.service fails to run due to missing caps for setting OOMScore
+RUN cp /usr/lib/systemd/system/dbus.service /etc/systemd/system/; sed -i 's/OOMScoreAdjust=-900//' /etc/systemd/system/dbus.service
+
+#systemd expects /run and /tmp to be mount points
+VOLUME ["/run", "/tmp"]
+
+#systemd expects env variable $container to define the virt type
+ENV container=docker
+
+CMD ["/usr/bin/bash"]

Diff for rawhide

diff --git a/Dockerfile b/Dockerfile
index b922d62..e701217 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,3 +1,8 @@
 FROM scratch
-MAINTAINER Lokesh Mandvekar <lsm5@fedoraproject.org> - ./buildcontainers.sh
-ADD fedora-rawhide-medium.tar.xz /
+MAINTAINER Lokesh Mandvekar <lsm5@fedoraproject.org>
+ADD Fedora-Docker-Base-20150210-rawhide.x86_64.tar.xz /
+
+VOLUME ["/run", "/tmp"]
+ENV container=docker
+
+CMD ["/usr/bin/bash"]
diff --git a/Fedora-Docker-Base-20150210-rawhide.x86_64.tar.xz b/Fedora-Docker-Base-20150210-rawhide.x86_64.tar.xz
new file mode 100644
index 0000000..192c656
Binary files /dev/null and b/Fedora-Docker-Base-20150210-rawhide.x86_64.tar.xz differ
diff --git a/buildcontainers.sh b/buildcontainers.sh
deleted file mode 100755
index 0fa0ca0..0000000
--- a/buildcontainers.sh
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/bash -x
-sudo rm -rf /tmp/fedora*
-rm -rf *.tar.xz
-export LIBGUESTFS_BACKEND=direct
-sudo appliance-creator -c container-rawhide-medium.ks -d -v -t /tmp \
-    -o /tmp --name "fedora-rawhide-medium" --release rawhide \
-    --format=qcow2
-virt-tar-out -a \
-    /tmp/fedora-rawhide-medium/fedora-rawhide-medium-sda.qcow2 / - | \
-    xz --best > fedora-rawhide-medium.tar.xz
diff --git a/container-rawhide-medium.ks b/container-rawhide-medium.ks
deleted file mode 100644
index e3a4fac..0000000
--- a/container-rawhide-medium.ks
+++ /dev/null
@@ -1,140 +0,0 @@
-# This is a kickstart for making a non-bootable container environment.
-#
-# Convert the result to a tarfile with 
-#
-#   virt-tar-out -a fedora.qcow2 / - | bzip2 --best > fedora.tar.bz2
-#
-#
-# This kickstart file is designed to be used with appliance-creator and
-# may need slight modification for use with actual anaconda or other tools.
-# We intend to target anaconda-in-a-vm style image building for F20, but
-# not necessarily for containers -- that's yet to be worked out.
-
-lang en_US.UTF-8
-keyboard us
-timezone --utc Etc/UTC
-
-auth --useshadow --enablemd5
-selinux --enforcing
-rootpw --lock --iscrypted locked
-
-zerombr
-clearpart --all
-part / --size 1024 --fstype ext4
-
-# Repositories
-#repo --name=fedora --baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/rawhide/$basearch/os/
-repo --name=fedora --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch
-
-reboot
-
-# Package list.
-%packages
-@core
-tar
-rsync
-
-# https://bugzilla.redhat.com/show_bug.cgi?id=1004976
-firewalld
-
-# Some things from @core we can do without inside the container
--audit
--biosdevname
--dhclient
--e2fsprogs
--grubby
--iprutils
--kbd
--NetworkManager
--openssh-server
--parted
--plymouth   
--policycoreutils
--rsyslog
--selinux-policy-targeted
--sudo
-
-# remove openssl and packages dependent on it
--authconfig
--openssl
-
-%end
-
-%post --erroronfail
-
-# setup systemd to boot to the right runlevel
-echo -n "Setting default runlevel to multiuser text mode"
-rm -f /etc/systemd/system/default.target
-ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
-echo .
-
-# create devices which appliance-creator does not
-ln -s /proc/kcore /dev/core
-mknod -m 660 /dev/loop0 b 7 0
-mknod -m 660 /dev/loop1 b 7 1
-rm -rf /dev/console
-ln -s /dev/tty1 /dev/console
-
-echo -n "Network fixes"
-# initscripts don't like this file to be missing.
-cat > /etc/sysconfig/network << EOF
-NETWORKING=yes
-NOZEROCONF=yes
-EOF
-
-# For cloud images, 'eth0' _is_ the predictable device name, since
-# we don't want to be tied to specific virtual (!) hardware
-rm -f /etc/udev/rules.d/70*
-ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
-
-# simple eth0 config, again not hard-coded to the build hardware
-cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << EOF
-DEVICE="eth0"
-BOOTPROTO="dhcp"
-ONBOOT="yes"
-TYPE="Ethernet"
-EOF
-
-# generic localhost names
-cat > /etc/hosts << EOF
-127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
-::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
-
-EOF
-echo .
-
-# Because memory is scarce resource in most cloud/virt environments,
-# and because this impedes forensics, we are differing from the Fedora
-# default of having /tmp on tmpfs.
-echo "Disabling tmpfs for /tmp."
-systemctl mask tmp.mount
-
-echo "Removing random-seed so it's not the same in every image."
-rm -f /var/lib/random-seed
-
-echo "Compressing cracklib."
-gzip -9 /usr/share/cracklib/pw_dict.pwd
-
-echo "Removing extra packages."
-rm -vf /etc/yum/protected.d/
-yum -C -y remove firewalld --setopt="clean_requirements_on_remove=1"
-
-echo "Cleaning old yum repodata."
-yum clean all
-yum history new
-truncate -c -s 0 /var/log/yum.log
-
-echo "Removing boot, since we don't need that."
-rm -rf /boot/
-
-echo "Fixing SELinux contexts."
-/usr/sbin/fixfiles -R -a restore
-
-echo "Zeroing out empty space."
-# This forces the filesystem to reclaim space from deleted files
-dd bs=1M if=/dev/zero of=/var/tmp/zeros || :
-rm -f /var/tmp/zeros
-echo "(Don't worry -- that out-of-space error was expected.)"
-
-%end
-
diff --git a/fedora-docker-base-eab5b9e.ks b/fedora-docker-base-eab5b9e.ks
new file mode 100644
index 0000000..bb2efbc
--- /dev/null
+++ b/fedora-docker-base-eab5b9e.ks
@@ -0,0 +1,69 @@
+#version=DEVEL
+# Keyboard layouts
+keyboard 'us'
+# Reboot after installation
+reboot
+# Root password
+rootpw --plaintext qweqwe
+# System timezone
+timezone Etc/UTC --isUtc --nontp
+# Firewall configuration
+firewall --disabled
+# Network information
+network  --bootproto=dhcp --device=link --activate
+cmdline
+
+# System bootloader configuration
+bootloader --location=none
+# Clear the Master Boot Record
+zerombr
+# Partition clearing information
+clearpart --all
+# Disk partitioning information
+part / --fstype="ext4" --size=3000
+
+%post --logfile /tmp/anaconda-post.log
+# Set the language rpm nodocs transaction flag persistently in the
+# image yum.conf and rpm macros
+
+LANG="en_US"
+echo "%_install_lang $LANG" > /etc/rpm/macros.image-language-conf
+
+awk '(NF==0&&!done){print "override_install_langs='$LANG'\ntsflags=nodocs";done=1}{print}' \
+    < /etc/yum.conf > /etc/yum.conf.new
+mv /etc/yum.conf.new /etc/yum.conf
+
+echo "Import RPM GPG key"
+releasever=$(rpm -q --qf '%{version}\n' fedora-release)
+basearch=$(uname -i)
+rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
+
+rm -f /usr/lib/locale/locale-archive
+
+#Setup locale properly
+localedef -v -c -i en_US -f UTF-8 en_US.UTF-8
+
+rm -rf /var/cache/yum/*
+rm -f /tmp/ks-script*
+
+#Make it easier for systemd to run in Docker container
+cp /usr/lib/systemd/system/dbus.service /etc/systemd/system/
+sed -i 's/OOMScoreAdjust=-900//' /etc/systemd/system/dbus.service
+
+#Mask mount units and getty service so that we don't get login prompt
+systemctl mask systemd-remount-fs.service dev-hugepages.mount sys-fs-fuse-connections.mount systemd-logind.service getty.target console-getty.service
+
+rm -f /etc/machine-id
+
+%end
+
+%packages --excludedocs --nocore --instLangs=en
+bash
+fedora-release
+rootfiles
+vim-minimal
+yum
+-kernel
+
+%end
+url --url=http://kojipkgs.fedoraproject.org/mash/rawhide-20150210/rawhide/$basearch/os/
diff --git a/fedora-rawhide-medium.tar.xz b/fedora-rawhide-medium.tar.xz
deleted file mode 100644
index 0b64b1b..0000000
Binary files a/fedora-rawhide-medium.tar.xz and /dev/null differ

@tianon
Copy link
Member

tianon commented Feb 17, 2015

Re: UTC -- 😢

Re: the extra bits just for systemd-in-containers support, why not just document those tricks clearly instead of baking them directly into the image itself, especially ENV container=docker, but even for those other bits? I'm concerned that we're pushing further away from stock Fedora here, and it's "just" to get systemd running in a container.

@lsm5
Copy link
Contributor Author

lsm5 commented Feb 17, 2015

perhaps @vpavlin can comment better on this, but fwiw, I think in a stock Fedora we'd want to have systemd work by default, so that's why the additions. Or am I misreading your comment?

@vpavlin
Copy link

vpavlin commented Feb 18, 2015

@tianon Hi, I think this is exact opposite - systemd runs in stock Fedora without any tweaks to kernel cmdline or whatever but does not run like this in Docker containers. I'd like to get us as close to the state where I'll just say

FROM fedora
RUN yum -y install httpd
RUN systemctl enable httpd
CMD /usr/sbin/init

...build...

docker run -it my_fedora_httpd

And it would just work...well, we are not there yet, but these changes got us much closer. Docker run with these changes will be

docker run -it  -v /sys/fs/cgroup:/sys/fs/cgroup my_fedora_httpd

Especially ENV container=docker is imho completely harmless and can be helpful in other circumstances as well - I am f.e. working with abrt project on being able to run abrt in a container for Atomic Host and having container=docker set by default would make their life much easier in regards of figuring out whether or not they are running in a container...

Does it resonate with you?

@tianon
Copy link
Member

tianon commented Feb 18, 2015

Right, I don't disagree that having systemd running nicely in a container isn't a good goal -- the problem I have is that it's code that's now custom to this image, as opposed to sticking as closely to being a vanilla distribution of Fedora as we possibly can, especially since bits of this exactly how this works are still fiddly and fragile.

@vpavlin
Copy link

vpavlin commented Feb 19, 2015

I don't think you understand those changes completely

This is just a change of boot transaction - you can look at it as optimization for running in container. I am going to disable more services in cooperation with systemd folks in container as they are not needed. (and this will be done directly in KS file in next Fedora image releases)

RUN systemctl mask systemd-remount-fs.service dev-hugepages.mount sys-fs-fuse-connections.mount systemd-logind.service getty.target console-getty.service

I don't like this one either, although I think it's completely harmless. But I plan to follow up with dbus and systemd folks on how to solve it systematically - consider it a temporary workaround.

RUN cp /usr/lib/systemd/system/dbus.service /etc/systemd/system/; sed -i 's/OOMScoreAdjust=-900//' /etc/systemd/system/dbus.service

Well, this one is a bit controversial and basically (hopefully temporarily) workarounds moby/moby#8478

VOLUME ["/run", "/tmp"]

This one is simply necessary and I really don't see a reason why that should not be a default.

ENV container=docker

@tianon
Copy link
Member

tianon commented Feb 19, 2015

I definitely understand the changes -- I just don't agree that they belong directly in the Dockerfile of the Fedora image.

I feel like this is a combination of two issues.

The first issue is that systemd doesn't work as-is inside a Docker container, which I see as an upstream systemd issue and/or upstream Docker issue -- I'd love to see the conversations happening to fix that (and have been personally involved in similar discussions with both upstreams on that very topic in the past).

The second issue is a documentation issue for "how do I work around the reality of that first issue".

CentOS solved the "other packages systemd compatibility" issue with a new fakesystemd package baked directly in their image. Then they solved the second issue with documentation for the current set of hacks required to get systemd running (

For example, here's the documentation CentOS has: https://github.com/docker-library/docs/blob/4368a6f64642a7844b5e4243c2f6eea1a7d73553/centos/content.md#systemd-integration), which may change over time depending on systemd adding new features that also need to be hacked around or adding new support for running in a Docker container more directly with less hacks.

@vpavlin
Copy link

vpavlin commented Feb 23, 2015

I think the first issue is being worked on. Which does not mean we shouldn't provide workaround until it's solved.

The second...I am the original author of fakesystemd and it's was really bad idea to introduce it at all. We have dropped it from Fedora (and RHEL) pretty quickly (and afaik CentOS is going to do that also). There is no problem with having systemd in a container if it is not running - it does not break anything when it just sits there. Problems start when you try to run it. Documentation is fine and I am starting to see this PR is a dead end and the docs will have to be the solution.

I just prefer to have things working with simple workarounds applied then to provide non-working stuff with docs somewhere on the wiki...

@tianon
Copy link
Member

tianon commented Feb 23, 2015

I don't at all disagree that having systemd working in a container is a good goal. On the contrary, I think it's awesome. What I disagree with is the changes made here in order to accomplish that goal, which in the end are just hacks that ought to be documented or moved to a separate, dependent image instead.

ENV container=docker has been discussed many, many times, and the eventual consensus was that by default, it doesn't make sense, especially since it's so easy to add where necessary (moby/moby#1020, moby/moby#1244, moby/moby#2939, moby/moby#4326, moby/moby#7196). In the general case of "using a Fedora base image", it is not necessary. In the one very specific use-case of running systemd in a Fedora image, it becomes necessary. That's the difference here for me, and why I disagree with these changes at the base image level.

Additionally, adding /run and /tmp as volumes here will potentially break a non-zero number of Dockerfiles depending on this image, since there's no way to undo a VOLUME definition and it makes that directory no longer committable (and thus stuck "empty" for all dependent images), which is the exact problem that keeps that change from merging upstream.

@vpavlin
Copy link

vpavlin commented Feb 23, 2015

Ok, got you..You can close this PR..although I still don't agree about the ENV:)

The case for VOLUME makes sense now although you shouldn't store anything persistent in these two dirs...but yes, it might fall apart in some cases, I haven't realized that.

I'll put together some documentation. Thanks for being so patient:)

@tianon
Copy link
Member

tianon commented Feb 24, 2015

No worries! Glad we worked it out. Shouldn't this still be updated to just remove the extra lines from the Dockerfiles so we can at least get the updated rootfs tarballs? 😄

Re: ENV container -- I don't necessarily disagree, but I think that's a discussion to have in Docker itself, not here 👍

@lsm5
Copy link
Contributor Author

lsm5 commented Feb 25, 2015

i'll send another pr with the updated rootfs

@rhatdan
Copy link

rhatdan commented Mar 10, 2015

The solution is to get /run to run with a tmpfs on it, just like it is on all modern Linux Distributions. We have had a pull request out for a while, with the sticking point being how to get the contents of /run off the image into the tmpfs mounted on /run.

@crosbymichael and I have come to an agreement on how to attempt to get this to work, by adding some "PreMount" and PostMount handling to libcontainer so that callers of libcontainer can execute code just prior to the mount and just after the mount. Sadly we have not been able to get code working yet. Although I believe we are close.

ENV container=docker is a requirement of systemd to run within a container and since the standard has been provided by previous container tools LXC and libvirt-lxc. I don't agree with docker reluctance to add it. But now that we can do it in the Base Container, I really do not care. All base container images from Red Hat derived distributions should be built with the environment variable set.

I have other pull request to fully integrate systemd/journald and machinectl. Which will allow us to seemlessly gather container journal information out of the container onto the host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants