> 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. I've added the Satellite people to my list of people to email. > 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. Could default NIC names be abstracted out somehow, perhaps by kickstart providing data about the system or by exposing options passed on the boot command line? That might be one way we can allow you to reduce your number of files. Partitioning is always going to be different, I suppose. > 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.), We've talked a little bit in IRC here about defining classes of devices. I think we could use that concept to make it easier to avoid devices. > 2) register with our Satellite and pull down updates. It's sad we don't more closely integrate with satellite. I'll take a look at that. > 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. I'm also going to talk to the puppet people and see if there's anything we can do to work better with them. > 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. You can specify network devices a couple other ways, for instance "link" if it's the only one that has a cable plugged into it. You can also specify device by MAC address. When disk names started moving around all the time, we allowed people to specify disks in a lot of other forms (by UUID, by label, using globs, etc.) Would something similar for NICs make it easier? > 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. I think I responded to someone else about fs option stuff. We will be taking a look at what we can do here both from the kickstart side and from the blivet side. Because you're right, it's not very useful a lot of the times and it's kind of a mess in general. > 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. I know we don't test this on the installer team. I don't know if QA tests in an ipv6-only environment. Any bug reports you have here would be welcome. > The only place where I find myself wishing the kickstart DSL had > more functionality is conditionals for the partitioning primitives. This has come up once or twice already. We'll definitely be taking a look at what we can do for this. - Chris _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
