moving kickstart forward

Sun Mar 6 17:12:02 UTC 2016

* 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?

-use ks to generate developer and production installs in a consistent and
flexible manner
- we have a large script that assembles all the components from a version
control repository into a disc image, then build an ISO, and also burn or
publish to a PXE boot server
- We are using Jinja to generate the final kickstart from what amounts to
kickstart snippets.
- our system allows us to have a common set of components and then have
individual "projects" that override certain snippets to customize aspects
of the build, including partitioning, users, security, etc...

* 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 kickstarts are quite extensive in the pre and post sections.
- We have MANY %post sections
- in the pre, we're doing all kinds of stuff to automagically determine
what drives are available, flexible partitioning, determining usb/removable
drives, as well as setting up your basic installation sources.
- In the post, we do everything.  we tweak bashrc files, setup kiosk
environments in gnome (which sucks by the way), tweak our environments
based on project needs, set up security items (firewalls, selinux, pam,
etc...)  Basically, everything you would normally do on a system after
install, we do in the post.
- I would love to see the following available in the PRE:
-- built in function to identify all removable USB type drives.  I
currently put these into an array for use later
-- built in function to identify all drives in available in the system.  I
currently have a function for this.
-- built in function to identify the PRIMARY boot drive, since sda is not
always the first drive. (this is a common issue).  I have a function for
this as well.
-- built in command for excluding drives from install/format/clearpart.  I
have a function to do this as well.  it's messy though at times.
-- needs to be a bit easier to determine install source and deal with it
accordingly.  Lots of issues have been had when trying to install from
various sources, like usb cdroms, usb drives, cdrom, etc...  Would be nice
if ks/anaconda just recognized where the source is an adjusted accordingly.
-- I've see other users overwrite their own install media.  Should be built
in protection for this.
-- we often have to go through annoying scripting to get the installation
media to be properly available in the post.  Should be a built in feature.
We do this because often in the post we are adding stuff that wasn't
available.  Has never made much sense to me that the install media wasn't
already just "available" in the post.

* other stuff:
- making logging easier.  I see a lot of questions about how to log
everything that's going on.  I know how to do this, but it seems that
logging everything should be a standard ks/anaconda directive somewhere.
- Partitioning is sometimes troublesome with errors being very cryptic as
to why or what ran out of space.  i.e. is it the logvol, pv, or vg that
wasn't defined with enough space?
- would be nice if when you use options in the partitioning sections that
if they are incompatible with each other, the dev was informed of the exact
error.
- Some errors that state that there's an issue at line no: xyz are not
exactly right.  If a dev doesn't know that he has to look at each
ks-xyz.log file and that the line number is referencing that particular
%post ks part, the line number is misleading.  In other words, more detail
in error reporting.
-  would be nice if there was a better ks GUI tool than
system-config-kickstart, but I don't know how many would use it.

I like KS a lot, but there are always just some cryptic stuff to deal with.

Thanks for whatever you might do with this!

-Andrew

On Wed, Mar 2, 2016 at 11:54 AM, Chris Lumens <clumens at redhat.com
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=clumens@redhat.com>>
wrote:

> Hey everyone, I've been maintaining pykickstart and kickstart support in
> anaconda in general for a very long time now, though I've not been very
> active on this list.
>
> I'm going to be looking at kickstart exclusively for the forseeable
> future.  Specifically, my focus is going to be on widening its adoption
> and making it more useful to everyone.  The first step in this process
> is information gathering.
>
> Here's what I would like to know from you guys:
>
> * 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?
>
> * 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?
>
> * 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?
>
> 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.
>
> I'd also like to emphasize that whatever I end up doing, I want to keep
> compatibility with kickstart as it exists today.  That's something I
> take seriously in pykickstart.
>
> - Chris
>
> _______________________________________________
> Kickstart-list mailing list
> Kickstart-list at redhat.com
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=Kickstart-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/kickstart-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20160306/57418ed6/attachment.htm>