If we leave the root account w/o a password people will use it that way,
leading to insecure images. Also if we use a default password. So lock
the root account in the templates.
Users will need to do one of these things:
1. Use [[customizations.user]] in their blueprint to configure root or
another user.
2. Use [[customizations.sshkey]] to set a key for root
2. Install a package that configures a user at install time
3. Install a package that sets up a user at boot time (eg. cloud-init)
This also drops the auth line from the kickstart templates, allowing it
to use the default password algoritm instead of md5.
Resolves: rhbz#1626120
Currently we are making MBR disk images for qcow2 and partitioned disk,
so the UEFI packages aren't required at this point.
Move the clearpart command into compose.py so that in the futute it can
use clearpart --disklabel to create a GPT image, and add the required
packages to the package set.
The default size is always going to be wrong, so try to estimate a more
reasonable amount of space. This is more complicated than you would
expect, yum's installedsize doesn't take into account the block size of
the filesystem, nor any extra artifacts generated by pre/post scripts.
So in the end we end up with a minimum image size of 1GiB, a partition
that is 40% larger than the estimated space needed, and a disk image
that increases size in 1GiB increments. This is still better than having
a fixed 4GiB / partition that was either too large or too small.
This ended up requiring more intrusive changes, but it should be the
most complex of the output types. After moving the core of
livemedia-creator into a function I added more settings to compose_args,
and more defaults to start_build. It now pulls the release information
from /etc/os-release, and produces a bootable .iso
This adds the ability to build a tar output image. The /compose and
/compose/types API routes are now available.
To start a build POST a JSON body to /compose, like this:
{"recipe_name":"glusterfs", "compose_type":"tar", "branch":"master"}
This will return a unique build id:
{
"build_id": "4d13abb6-aa4e-4c80-a671-0b867e6e77f6",
"status": true
}
which will be used to keep track of the build status (routes for this
do not exist yet).
