Same boat. $job has lots and lots of junk in %post to make machines smell like us post-kick. Bizarrely, we have been a cf2 shop for nearly a decade. The crux of this practice is that we kick machines and bop their network off post-firstboot since they have 1.) a 'consider-it-compromised' root passwd (even though no passwd ssh is allowed ... also configured @ %post) and 2.) no tripwire policy instantiated with keys+passphrases. Steps 1 and 2 of bringing our machine to life post-kick is to set root passwd and bootstrap tripwire interactively via iLO/DRAC (turn the network on before both of those and youll get your knuckles rapped. :)
Im a firm believer in disposable machines (no userland data on direct-attached disk + 100% of running config in cfg mgmt + multiple horizontal nodes == one can kick a node at any nearly anytime). I also think the several hundred lines of %post we have here is a bit insane given _I_ find the function of ks is to slice disk and drop enough binaries in-place to let cfg mgmt bootstrap and takeover the rest. Part of my selling $job to get us from here to there where we dismantle all the %post cruft is getting the above three things in place (data + runtime + multiples). Once there, its sellable to $mgmt that machines can have the kind of kicks you/I/whoever is talking about in this thread. FWIW ... On Tue, May 4, 2010 at 5:45 PM, Matt Lawrence <[email protected]> wrote: > I recently started a new job, getting information has been difficult and > there is a bit of a turf war from the existing sysadmin, who is almost > universally hated by the customer we both support. So, this is a touchy > situation politically. > > On the the issue. I have finally gotten access to the kickstart files > that are used to install most of the systems. The one I am looking at > right now is 1648 lines long, with about 1600 of them in the %post clause. > I am of the opinion this is a bad idea, a kickstart shouldn't do much more > than get a system up, running and able to talk to a configuration > management system. Naturally, there is no configuration management system > and systems are left as initially installed for years. > > So, I'm looking for references to best practices that I can take to my > boss and other management on the preferred way of doing RHEL kickstarts > and configuration management. Any suggestions? TAL? > > -- Matt > It's not what I know that counts. > It's what I can remember in time to use. > _______________________________________________ > Tech mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
