moving kickstart forward

[Ross Smith]

>
>
> * How do you use kickstart right now?  What work flows do you have
> around it?  Do you generate kickstart files from some process?  Do you
> store them in version control?
>

We use kickstart now for deploying several classes of systems.  Right now
we have a static file for each class, but are moving towards generating
them on the fly.  These systems range from workstations to servers, to
virtual machines.

>
> * What do you do in your kickstart files?  Do you have extensive %pre
> and %post sections?  If so, what kinds of things are you doing in them?
> Are you doing anything that would be generally useful that I should be
> doing for you?  Do you ever use %traceback?  Do you have unusual stuff
> going on in %packages?
>

Our kickstart files generally follow the following pattern:
- all the static directives we can or have to place in the file
- %pre script to gather information for the rest of the install
- %pre script to authenticate the user or process that initiated the install
- %pre script to do sophisticated partitioning and generated an %include
file(weeding out usb thumbdrives for instance)
- (optional) %pre script to put a splash screen up on the display, also
keeps users from interfering with the load process.
- %packages contains  @base plus a few packages for our tooling to work
- %post script that sets a few things for our enivironment (remove
packages, set UID/GID limits) then runs our centralized management tool
several times to bring a system into configuration, and some magic for
setting up the bootloader.

We do some magic with fetching the actual %pre scripts from a remote system
and using tmux in EL7 to run them.  this allows us the flexibility to run a
non-blocking script (e.g. splash screen) and allows us to see the output on
the console as a tmux screen.

We currently don't use %traceback, although it's on our roadmap.

>
> * What can I do to make your life easier?  What annoys you about
> kickstart right now?  What do you wish it did?  What do you wish it
> didn't do?  Would making it more like a language be helpful?  Would
> making it easier to define site-specific commands be helpful?
>

More documentation around lesser used options.  it may have changed since I
last looked, but %traceback wasn't very well documented.  We'd really love
to see some more built in error handling so we wouldn't even have to rely
on %traceback.  maybe a way to run a cleanup block when an individual %post
or %pre script fails, or a way to define fatal/non-fatal blocks.

Along with this, a secured install is very important to us. we have the
unenviable position of loading workstations in buildings that are open to
the public.  We do a lot of work to verify the hardware and user are
allowed to get our load, and want to be able to control what can be changed
via a kickstart.  For instance, if it's an admin loading the machine, allow
them to change whatever,  if it's a employee from a different department,
allow only custom partitioning, and so on.  We'd be happy to configure that
via %pre scripts, but having the directives available is necessary for
that.

An officially supported way of interacting with users, or posting things to
the screen.  Imagine a user needed to login to generate a keytab, or
allowing a statusbar for user-defined parts of the install.

Improvements around partitioning would be great.  I'm imagining something
more along the lines of being able to say "ignore everything read-only or
on USB" or "these partitions go anywhere on any ssd or md.0"  These things
also might just be better suited to improvements in blivet than kickstart.

improved support for image based installs.  We'd like to be able to easily
generate a template filesystem image and throw that down over our
partitions in non-livecd environments.  That process was a bit cumbersome,
or required large imagefiles along the simpler path.   We're often chaining
this install after an automated windows install, so simplicity whenever we
can get it is beneficial.

More built-in support for templating.  Anaconda can send the mac address of
the system along in the initial get for a kickstart, but options to send
user defined data or other discovered data (e.g. hostname ) in any request
anaconda makes would be useful.  like %pre --url=
http://myserver/path/to/pre.py could send machine data.

A minor thing is an improved logging command.  we log via udp on port 515
for installs.  This keeps it all separate from our production logs, but we
can't just tell kickstart that right now.  I've definitely been lazy, and
haven't gotten that bug put in or a patch posted.


> I know this is all really vague stuff, but I am just starting out on
> this project.  I don't even really know where this is going to take me
> yet.
>

Thanks for focusing on it. I'm happy to lend a hand where I can, or provide
more feedback.


Ross Smith <rjsm at umich.edu>
College of Engineering - CAEN - Linux Support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20160306/8e38d4c5/attachment.htm>