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
