* 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?
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?
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@xxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
