* 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="" href="http://myserver/path/to/pre.py" target="_blank">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.
College of Engineering - CAEN - Linux Support
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
