Re: moving kickstart forward

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Red Hat General]     [CentOS Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux