So is seems that if you remove the machine-id file it won't regenerate the file
but if you touch the file and leave it empty on boot it'll put a new machine-id
in the empty file. So work around this bug ("feature"?) by touching the file
so we don't have other issues in the process.
We're track the outcome of this in RHBZ 1379800
As referenced on the arm list [1] and as already being done on the docker image we
should remove the unique /etc/machine-id file on compose artifacts to ensure it's
regenerated and unique on each deployed host/device. This unifies the process across
all base ks so it's inherited for each artifact.
[1] https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/message/Q3YZVF5P2OLLPUJQ2LYZSTKWGGDIU6QO/
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
We were getting grub2 in the base image again. Apparently
for a while Anaconda has supported a cleaner syntax for this, and
since it fixes the bug, let's use it.
https://bugzilla.redhat.com/show_bug.cgi?id=1222132
Best practice is to use unprivileged service daemons inside Docker
containers. But with this hardcoded root password, in the case of
remote code execution, an attacker could trivially escalate their
privileges to root/uid 0. And while that's uid 0 inside a container,
that's a much larger attack surface.
Instead, do the same thing we're doing for the Cloud images: lock the
root password, create a user to make Anaconda happy, then delete the
user in %post.
https://bugzilla.redhat.com/show_bug.cgi?id=1175997
Even though it's silly, the ImageFactory-in-Koji use case calls into
libguestfs to introspect the target system, and libguestfs relies on
/etc/fstab to detect installed operating systems.
