Anaconda as a template system versus an installer

[Colin Walters]

Anaconda is used in many different ways, there's things like the Live versus traditional, multiple architectures, etc.

One of those major axes is the difference between generating "images" or "templates" versus doing actual installations.

Current examples of templating are:
- Cloud image (via ImageFactory TinMan)
- Docker base image (via ImageFactory TinMan)

What's the difference between the two? A good example is /var/lib/systemd/random-seed:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n190

I would argue that Anaconda should be taking on the role of assisting with things like this. It shouldn't be for people to hack up in kickstart files.

Another *major* issue with Anaconda-as-templater is networking. See this thread for example:

https://lists.fedoraproject.org/pipermail/cloud/2014-November/004663.html

There needs to be some way to sanely distinguish between networking for the ImageFactory environment versus the *target* network configuration.

There's of course other stuff you can see in the cloud base, like yum history.

Another major bug we have is the systemd machine ID. This really needs to be generated on first boot, not hardcoded into the image. Systemd has bugs in this regard, but they're being fixed; see:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/025783.html

High level strawman: A kickstart verb like:

system --template

This would instruct anaconda to perform the equivalent of:
http://libguestfs.org/virt-sysprep.1.html

I'm not sure how to handle the networking issue. Perhaps a reasonable first step would be
network --template-environment=dhcp # for the ImageFactory run
network ... # applies to target

[Chris Lumens]

Post by Colin Walters
I would argue that Anaconda should be taking on the role of assisting
with things like this. It shouldn't be for people to hack up in
kickstart files.

Just throwing this out there given the hour and day...

It's always been my position that if there are things lots of people are
doing in their kickstart files, kickstart should grow to support those
things. This is why we now have user/group/services command support,
for instance.

Beyond that high level position, I am leaving it up to our resident
experts on networking and images to have opinions on the details here.

Note that there are ways to have anaconda not do certain major tasks -
for instance, running in dirinstall or image install mode disables
setting the timezone, screwing with the network, etc.

- Chris

[Matthew Miller]

Post by Colin Walters
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n190
I would argue that Anaconda should be taking on the role of assisting
with things like this. It shouldn't be for people to hack up in
kickstart files.

Yeah, there's some ugly stuff in there. For F21, at kind of the last
minute, a number of people expressed the wish to produce a
slightly-customized starting point for a cloud image by running
anaconda manually and then starting from the generated kickstart as a
base for future scripted image generation. But as you can see from the
current kickstart, that really won't get you very far, because without
all that, the result will be very unlike the official cloud image.

[Chris Lumens]

Post by Matthew Miller

Post by Colin Walters
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n190
I would argue that Anaconda should be taking on the role of assisting
with things like this. It shouldn't be for people to hack up in
kickstart files.

Yeah, there's some ugly stuff in there. For F21, at kind of the last
minute, a number of people expressed the wish to produce a
slightly-customized starting point for a cloud image by running
anaconda manually and then starting from the generated kickstart as a
base for future scripted image generation.

For these kinds of quirks, I suppose it'd be possible to add a kickstart
file snippet into data/post-scripts/ that runs if some command line flag
or kickstart command is provided.

- Chris

[Chris Lumens]

Post by Matthew Miller
Yeah, there's some ugly stuff in there.

Oh, hey, the firewalld and authconfig ugliness should all be able to
disappear out of that file now, right?

- Chris

[David Shea]

Post by Matthew Miller
Yeah, there's some ugly stuff in there.

I think you can remove the user and password stuff, too. What "older
versions of livecd-tools" to with rootpw seem irrelevant at this point,
and anaconda doesn't force you to make a user. Just don't make one.

Setting the systemd default runlevel to multi-user can be ensured with
"skipx". Removing linux-firmware would make more sense in %packages with
the reset of the packages being removed. There's a command for the
firstboot thing too but the firstboot in %post doesn't even exist
anymore. We have a list of files that get restoreconed by anaconda so if
the stuff at the end of the kickstart needs it we can do those too.

[David Shea]

Post by David Shea
and anaconda doesn't force you to make a user. Just don't make one

That might be a lie, forgot that the root account is locked. The other
paragraph is still true, though.

[Gene Czarcinski]

Post by David Shea

Post by Matthew Miller
Yeah, there's some ugly stuff in there.

I think you can remove the user and password stuff, too. What "older
versions of livecd-tools" to with rootpw seem irrelevant at this
point, and anaconda doesn't force you to make a user. Just don't make
one.
Setting the systemd default runlevel to multi-user can be ensured with
"skipx". Removing linux-firmware would make more sense in %packages
with the reset of the packages being removed. There's a command for
the firstboot thing too but the firstboot in %post doesn't even exist
anymore. We have a list of files that get restoreconed by anaconda so
if the stuff at the end of the kickstart needs it we can do those too.

Hold on minute! Not *requiring* some kickstart commands is one thing
but dropping support is a very different matter.

Starting with Fedora 21 I have changed my install/*re-install* process
to use a Live image rather than dvd or network install. In all cases I
use kickstart files to configure the systems as well as creating my
standard user accounts. It was only after I realized I could have a
kickstart install use liveimg instead of a package list that I switched.

The reason I emphasized *re-install* is because of my backup and
recovery strategy:

1. Do not mix system/application software and user data.
2. Backup all user data "early and often" Also, backup selected system
configuration variables. In case of some failure, restore from backups.
3. Never backup the "system". Instead, re-install it. Therefore, this
re-install process needs to be well defined with a hiogh level of
confidence that it will work.
4. Occasionally, practice recovery since you do not want to discover
how to do a re-install if you need to do it because of a failure.

Gene

[David Shea]

Post by Gene Czarcinski
Hold on minute! Not *requiring* some kickstart commands is one thing
but dropping support is a very different matter.

Slow down there, Hoss. We're not talking about dropping support for
anything, just some parts of the cloud spin-kickstart currently handled
through %post that could be handled through the regular part of the
kickstart.

[Leslie S Satenstein]

Hi Anaconda developers

I am a senior,retired and Fedora user. I promote Fedora Linux. I participate in Linux meet-ups and at times I make a presentation to some senior clubs. I go to these meetings with a few flash-drives, and some half dozen bootable DVDs. Together, after the meeting I have a group of curious enthusiasts do an installation of Fedora on their own laptops.
 
With the current process, if I use the official DVD iso dated "Go Live date", then after a few months I will easily be experiencing 700+ updates. Consider the club meeting environment, where, doing an installation of the "Go Live" DVD and subsequent running of yum for the large quantity of simultaneous downloads. This large set of follow up updates kills the club's limited internet capacity, and results in a negative disappointing way to demonstrate or experience Fedora.

In the past, (F19, F20) on the day prior to the meet-up, I run a prepared kickstart file with the live creator program. Using the DVD.iso I created, I burn some DVDs. These DVDs are the DVDs I distribute. They are up-to-date, and require no massive yum update following the reboot.

As I see it, there should be at least three required options for Fedora downloaders. One is a live version, the second a network install version and a third, the kickstart version. Using a live image or existing Fedora Linux, if the sysadmin or promoter of Fedora wants a current bootable ISO DVD image, he creates it from from the live image or he runs the live-dvd creator program from his existing Fedora Linux. The DVD iso download is more network efficient then the network installation when multiple installs are to be done. 

Has there been any thought to appending a current delta.iso file to the DVD iso image? This delta image may be referenced during an installation, as an optional appendage to the DVD iso. It would solve my problem of of not requiring much yum updates post boot.

Centos 7 developers are discussing monthly iso productions. Fedora has not done this in the past. It would also solve my presentation issue.

My objective is to limit the amount of post installation updates when presenting and installing Fedora within a group environment.
 

[Brian C. Lane]

Post by Colin Walters
Anaconda is used in many different ways, there's things like the Live versus traditional, multiple architectures, etc.
One of those major axes is the difference between generating "images" or "templates" versus doing actual installations.
- Cloud image (via ImageFactory TinMan)
- Docker base image (via ImageFactory TinMan)
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n190
I would argue that Anaconda should be taking on the role of assisting with things like this. It shouldn't be for people to hack up in kickstart files.

I agree with the first part of that -- that was the whole reason behind
livemedia-creator, to use anaconda to generate this wide variety of
things that people want.

But I think kickstart is the *right* place for some of these
customizations to happen. As I said (or think I did) in the discussion
about a docker autopart, there are just too many ways that people want
to customize things for Anaconda to stuff them all in.

Look at lmc, I've tried to be careful but I've ended up with more
switches than an airplane cockpit.

Projects could do a much better job of maintaining and distributing
their kickstart snippets. Kickstart even supports including other
kickstarts.

Post by Colin Walters
https://lists.fedoraproject.org/pipermail/cloud/2014-November/004663.html
There needs to be some way to sanely distinguish between networking for the ImageFactory environment versus the *target* network configuration.
There's of course other stuff you can see in the cloud base, like yum history.
http://lists.freedesktop.org/archives/systemd-devel/2014-December/025783.html

IIRC we run it at install time because systemd wouldn't boot without it.
If that's changed we can certainly reexamine that.

Post by Colin Walters
system --template
http://libguestfs.org/virt-sysprep.1.html

Look at the number of switches there. There is no one right way for us
to know which way the user wants it setup. For this specific case it
would be useful if virt-sysprep could run from %post, letting the user
configure the image the way they want.

[Colin Walters]

Post by Brian C. Lane
Projects could do a much better job of maintaining and distributing
their kickstart snippets. Kickstart even supports including other
kickstarts.

Yes. I'm doing that when generating Vagrant images, which inherit from the cloud
image. Though I did run into a small issue there that confused me for a while
with services --enabled vs disabled; see:

https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?id=de8e30948143f48d9cafe1c76c2e589ddae5fb0b

Post by Brian C. Lane
Look at the number of switches there. There is no one right way for us
to know which way the user wants it setup. For this specific case it
would be useful if virt-sysprep could run from %post, letting the user
configure the image the way they want.

Right. Though doing it in %post requires it to be in the install tree, which I think
most users won't want. Hmm, to make this really work we'd have to
extract the "delete files from a target filesystem" part of virt-sysprep
from the "mount and inspect VM disks using libguestfs" part. I haven't
looked to see how hard that would be. CC'd rjones.

Richard: This discussion is about anaconda-for-templating versus
anaconda-as-installer, and for the former we want a lot of the "sysprep" aspects
of virt-sysprep.

Anyways, I see your point. Of these issues though, I think the one that could really use
fixing in anaconda-for-templating is the networking issue. It's still possible to hack it
in kickstart, but the fewer places we have writing "initscripts" style ifcfg files, the better.

As far as priorities go though, good cloud-init integration is much higher. It'd enable some
cool new user-facing features, whereas this is mostly internal and for the much smaller
audience of people generating disk images.

[Radek Vykydal]

Post by Colin Walters
https://lists.fedoraproject.org/pipermail/cloud/2014-November/004663.html
There needs to be some way to sanely distinguish between networking for the ImageFactory environment versus the *target* network configuration.

We are talking about virt-install in ImageFactory right (ie we need a
way to distinguish between installer (VM) environment vs target
configuration)?I believe we can do better in Anaconda, depending on what
is required:

1) Don't copy installer network config (ifcfgs) to target system, so
what is done in cloud.ks %post works:

|# 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|


In anaconda native image install we already don't copy network
configuration to target system. We'd probably need a explicit
(kickstart) flagto do the same for virt-install image installations.


2) Bring up all network ifaces by NM with default config (dhcp) on
target system.

Additionally to the above we'd need to configure NM to run default
auto-connections on NM start (it is turned off on server by default, by
installing NetworkManager-config-server package).

* Bring up just one network device by NM with default config (dhcp) on
target system.

Ie generate the configuration (something what ifcfg file created in
%post does) in installer. This can be more tricky as afaik NM needs to
have some ifcfg value to match interface to be activated - iface name or
MAC - which we can't assume during installation as can be seen in the
mailing list thread mentioned above. I don't think NM has something that
matches --device=link kickstart configuration (use first device with link).

Also we might need to look for such configuration of target system that
is common for NM / non-NM (network service) target system installations.

3) Creating fully customized target system configuration would be
harder. It is true that we have been assuming network configuration of
installer to be used on target system, and it was also for technical
reasons as we are using NM to generate the configuration (ifcfg files)
which (AFAIK the current status) could be done only "live", generating
system (installer) ifcfg files.

Radek