Good message. This is not to put down the developers in any way, but Kickstart, the anaconda install, and RPMs all seem like forgotten children of RedHat. It seems like they were thrown together to solve a need in the early days of Linux, but the needs have evolved and the resources to keep up with those needs aren't there. For instance the scripts etc. to put together a bootable install CD while being sufficient for RedHat's needs are totally undocumented and clearly hacked together (one RedHat person said so much on this list), building your own custom boot disks with additional drivers is a nightmare best left to true hackers, and the RPM docs are hopelessly out of date and lacking much of the new command syntax. The problem is with the growing use in large enterprises, this is exactly the sort of area that is most critical. Half of the battle is the install, and large companies need to do lots of them on diverse platforms with consistent results. Again, this is not to put down the developers, who I've always found very helpful especially considering the demands that must be placed on them. I also must admit that this is all "easy for me to say", knowing that the work will not fall on my lap. - Matt rpjday wrote: > > given that i've finished my reading of the kickstart docs, and > having previously messed with it to some extent, i'm going to wax > verbose, then i'll shut the heck up. while kickstart is obviously > an essential tool for installation automation, i want to point out > what i think are some significant flaws. i know i mentioned some > of this before, but i wanted to summarize everything in one place. > > i'm going to pass over the limitations of ksconfig, in > that it doesn't support the full flexibility of the kickstart file. > i appreciate that the config file is a moving target, so i'll just > leave that be. and now, what i see are the weaknesses in kickstart > that have to be addressed. > > 1) as i mentioned in a previous posting, there's the glaring > inconsistency in using "=" in some places and not in others, in the > following example in the very same directive: > > --nisdomain <domain name> > --ldapserver=<ldap server name> > > not to put too fine a point on it, make a decision: "=" or no "=". > it's going to be a pain to have to keep checking the docs to keep > things straight. > > 2) --useLilo. what on earth is an upper case letter doing there, > sticking out like a sore thumb? once again, consistency. > > 3) in most cases, a single word directive seems to mean that that > directive is in effect, such as "text" or "reboot". so what's the > deal with "zerombr yes"? according to the docs, there is no other > valid "zerombr" directive, so doesn't that make the word "yes" > just a tad redundant, and inconsistent with the pattern of the > rest of the directives? > > (oh, and while i'm harping about zerombr, it's probably worth > mentioning that, regardless what it suggests, it does *not* > zero the mbr. it clears any invalid partition tables, a far > cry from zeroing the mbr.) > > 4) a lack of symmetry in directive options. for example, the > "bootloader" directive has the --useLilo option, but no --useGrub > option. any particular reason for this? > > and i'm still baffled by the "bootloader" directive (which, according > to the docs, "specifies how the bootloader should be installed ..."), > having a "--location=" possible value of "none", which means "do not > install the bootloader". cripes. talk about confusing. > > but the problems now get worse ... > > 5) what does it mean to skip a directive completely? the customization > guide says that "Omitting any required item will result in the > installation program prompting the user for an answer to the related > item...". but as i pointed out in a previous message, in an earlier > version of kickstart, when i omitted the "network" directive (listed > as optional), i was prompted for that info. i finally got around > this by adding a bare "network" directive, and that solved the > problem. this was a *totally* non-intuitive solution. > > as i see it, a kickstart directive should allow for four choices: > > a) giving the information > b) skipping that directive completely > c) prompting the user for the info > d) auto-detecting or auto-probing for that info, doing the best > it can > > all of the above are perfectly reasonable choices, and are represented > by things like "xconfig", "skipx", "mouse" and so on. in fact, the > docs list the "mouse" directive as required, but if you don't include > that directive, the docs say that the installation program will > attempt to autodetect the mouse. well, then -- it isn't "required", > is it? > > all of this could be solved if you added a couple of options for > any directive, such as "--probe" or "--auto", and "--skip" or > "--prompt". or whatever. it's horrifically inconsistent to not > know what's going to happen if you deliberately leave out a directive. > *all* directives should behave the same way. > > 6) along with the previous point, the biggest drawback with the k.s. > config file is its inconsistency with the grouping of directives and > their possible options. consider: > > auth ......... > > note that what comes after "auth" is everything related to authentication. > perfectly reasonable. what is *not* reasonable is to have the two totally > separate, mutually exclusive directives "install" and "upgrade". these > are clearly options that belong to a single directive, and should be > specified that way, as in: > > installtype --install > installtype --upgrade > > to be consistent with other directives. the same holds for the different > places to get the installation packages: > > nfs > cdrom > harddrive > > and so on. bad. these again, like "auth", should be part of a single > directive, as in: > > packagelocation --nfs ... > packagelocation --cdrom ... > > or something like that. (and what's with the "--" prefix on so many > of the options? i notice you don't type "zerombr --yes". but > i'm not going to harp on that too much.) > > 7) oh, and one final, real nitpicky point. the docs suggest *very* > strongly that you must write the directives in a specific order. > this wasn't true with earlier versions of kickstart -- you had some > flexibility. has that changed? > > i could go on, but i think you get my drift. and why am i being so > nitpicky? simple. as red hat gets more complex, people are going to > continue to ask for more sophisticated options in their kickstart > files, perhaps similar to jumpstart files in solaris, in which you > can code conditionals to check for the underlying architecture, the > number of disks, the size of the disk(s) and so on. > > what this suggests is that kickstart file directives are going to evolve > into a simple programming language. (sound familiar? check out the > RedHat/base/comps file, which defines what rpms get loaded at install > time. that file has conditional constructs which check if other rpms > have been loaded, what the architecture is, etc.) > > and that's why a lot of this raging inconsistency needs to be addressed > now. as it stands now, the aesthetics of that file are a mess, and > will make future improvements that much harder. now would be a > good time to clean it up. > > rday > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/kickstart-list -- --------------------------------------------------------------------- Matt Fahrner 2 South Park St. Manager of Networking Willis House Burlington Coat Factory Warehouse Lebanon, N.H. 03766 TEL: (603) 448-4100 xt 5150 USA FAX: (603) 443-6190 Matt.Fahrner@xxxxxxxx ---------------------------------------------------------------------
