In regard to: moving kickstart forward, Chris Lumens said (at 11:54am on...: Thanks for the opportunity to provide feedback and be part of the improvement process.
* 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've been using kickstart a long time -- pre "Enterprise" in Red Hat Linux. Our original kickstart files were created manually, and we've just updated them for the slight syntax changes over the years. We have Red Hat Satellite, but we've never used its kickstart functionality. We're comfortable with hand-editing the kickstart files to get what we need. We have separate "template" files for RHEL 5 (32 & 64), RHEL 6 (32 & 64), and RHEL 7 on physical servers, and separate templates for those variants on VMware. The only real differences between the physical & virtual templates is the default NIC names and how we do partitioning. Those are also about the only two areas of our kickstart files that ever change from system to system. When I say "template", I really just mean a master copy that we make minor edits to (season to taste) for a particular system build. Like the environment that Spike mentioned in his post, we generally do static installs. We never use DHCP for servers and some of our admin team is uncomfortable with PXE being enabled for our server subnets, so kickstarting a box involves an admin using either a physical or a virtual console and feeding in the kickstart file via http.
* What do you do in your kickstart files? Do you have extensive %pre and %post sections?
Not so much %pre, but definitely %post. I'm very impressed with some of the %pre scripts I've seen posted here over the years, especially the ones that do smart things with partitioning (like avoiding SAN-attached devices, etc.), but we've kept our partitioning (mostly) fixed, manually selected, and just been careful to detach existing SAN devices during kickstart, etc. Our %post, which uses --log=/root/post-install.log --interpreter perl is lengthy, but does the exact same thing on all our hosts: 1) minimal fixups to what authconfig did for proper authentication (including fixups to Kerberos config & PAM for things that 'authconfig' doesn't allow us to configure), group, and user setup so that a sysadmin could get logged in to the system immediately after kickstart, in the event that something went wrong. 2) register with our Satellite and pull down updates. 3) set up a local repo, install puppet and get set up for puppet to manage the system for the remainder of its life. We used to do a lot more in our %post, but in general managing the state of our systems has moved into our configuration management system (currently puppet). Our %post is now minimal setup to get just the basics in place so that configuration management can take over.
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?
I knew about %traceback, but it hasn't been well-documented enough for me to invest in ever using it. If it were well documented, there's a good chance we would make use of it, as necessary.
Do you have unusual stuff going on in %packages?
We install our systems as minimally as possible (%packages --nobase). Configuration management then layers on just the appropriate packages for whatever the role the system is going to play. If you remove the comments, our packages section (at least for RHEL 7.x) never changes, and looks like: %packages --nobase -ivtv-firmware -atmel-firmware -zd1211-firmware perl wget authconfig openldap-clients pam_krb5 ntpdate %end
* What can I do to make your life easier?
The suggestion that others have had, about automatically providing more of the system details, either as environment variables or a JSON data structure or something similar is something I would echo. Having all of that automatically, without having to write a lot of code in %pre or %post to gather it, would be very useful.
What annoys you about kickstart right now?
I understand why upstream & Red Hat thought it was a good idea to move to "consistent NIC name", but that's actually been a major pain to deal with when kickstarting. Our templates now generally predict what the NIC name is going to be, but there's still plenty of times when I have to re-start a kickstart because the converged network adapter is e.g. p2p1 instead of p1p1, etc. Not kickstart's fault, but the move definitely impacts system management. We use software RAID extensively on our physical systems, so being able to pass more parameters to mdadm would be really handy. As it is, if I need to do anything esoteric, I have to skip using the kickstart primitives for partitioning and raid and do it all in a %pre. As far as I can tell, there's still no support for doing a network kickstart in a pure IPv6 environment. Having that would be nice, but I wouldn't call it high priority.
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?
The fact that we can choose the interpreter and write our %post script in a full-blown language of our choice gives us a lot of power & flexibility. The only place where I find myself wishing the kickstart DSL had more functionality is conditionals for the partitioning primitives. I'll agree with others that having more system details available automatically would be handy, but beyond that I don't know that I personally would get much value from additional domain-specific primitives. Tim -- Tim Mooney Tim.Mooney@xxxxxxxx Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
