> 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 What kind of information do you gather? How do you store it to make it accessible for the rest of the install? Is it in some sort of format? > - %pre script to do sophisticated partitioning and generated an %include > file(weeding out usb thumbdrives for instance) What other sorts of things are you doing here? I feel like we could be doing a lot better at either providing more high level partitioning commands, or tools that use blivet to inspect the system and generate kickstart chunks, or something. Weeding out classes of devices is definitely something we can look at. > - %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. Why do you need to remove packages in %post? Is it stuff that's dragged in as dependencies that you then want to force-remove later? Also, what kind of bootloader magic is required? > 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. Ugh, yeah, people are always wanting ways of keeping track of kickstart or doing logging or running something interatively. This tends to be pretty tough stuff to do, but we'll continue to look into it. > 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. Documentation is on my list, as well as adding lots of examples too. %traceback is still not really documented, no. Cleanup after a script fails is interesting. I'm not sure how to extend the syntax to allow for that, but I can think about it. You can already give scripts --erroronfail to cause them to display an error message and halt the installation. Scripts without this would not cause the installation to fail. > 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. Basically, some sort of ACL for commands in the kickstart file? That could get pretty complex in a hurry. This does remind me that people have wanted a way of not allowing the user to interact with the UI at all during a kickstart install. We could probably at least do that pretty easily. > 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. We probably should have taken this into account when working on newui. This is a long-standing request and we should take a look at how feasible it is. > 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. I'm definitely seeing a trend here - everyone wants more and better partitioning. I'm imagining tools either in blivet or kickstart that can help out. The more information and examples you can give, the better. > 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. I'll have to read up on this. Live and non-live installs are pretty separate in anaconda right now. > More built-in support for templating. I've considered adding a template language step around kickstart. There's a ton of options here. I just don't want to make a bigger mess of things given how a lot of people are already generating kickstarts using templates, or cobbler, etc. So I just need to do a lot of research here before deciding what I can do. > 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. This came up in another email. So you'd also like to see more around inspecting the system and making that data available either to the server where the kickstart file lives, or to the environment where the kickstart file is processed. > 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'd definitely be interested in any bug reports or patches around the logging command. It hasn't seen any activity in a long time. It does already support --host and --port, so I'd be curious what's going wrong. - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
