Right you may all moan, and groan, but I would like to add a bit to the thread 1) I have done as has been mentioned larger installs on various machines. 2) I have done them on various platforms. 3) We know the limitations that's why there's a list so we can correlate all the information and understand why and how. 4) hacked together ?, so are most things, my first iterations work and then I try to tidy them up, but it's "easy for me to say :-)" that once the gods in charge see that it works I get a new load of work to clear down. If I made every project "work" in my eyes as it should, (i believe i speak for many on this point) the world would be a much "easier" place to work in. 5) I noticed a change with 7.2, o.k. it has some bugs, but on the whole it's a lot smother, the point ? maybe now redhat has seen the light and has decided to concentrated on the distro and not third party apps here there and everywhere we may be heading for a more refined OS, if that happens maybe the guys will find time to revise ks as a whole. I use ks a lot, have had it doing PXE boots from an igloo install off an alpha, have had it installing from X.500 (that was fun :-))had boxes installing via dhcp no stiffy, have made boot CD's, have customised anaconda and i agree it's not the easiest thing in the world, but neither was my degree, and neither is life. In the end it comes down to this, you have a range of boxes and you want to roll them out, you define the builds, test them out, hack away using the LUG and a bit of CSense (Thanks to all who have helped along the way) for guidance, get it working and supply something that's a base. test it, refine it, upgrade it, and if you did it right (and i mean this) you get free time. It's not what you do it's how you do it. To be honest though all I need to add is have you ever compared a kickstart roll out to a microsofts SMS roll out ? I am not being biased but, KickStart maybe hacked, it may generate errors, it may be a pain to get the drivers in, linked and working, but after starting my life with MS i'm not going back, because in the end, a bit of forward planning i.e. Define what it is exactly you are setting out to get from the build. Define what it should contain. Define the operational characteristics of the server/install. you then do a standard install on each platform drop the build using mkkickstart start your bolt down process $echo "my changes" >>.your_post_script_file munge the files together make a ks floppy (ks off of nfs) add them to an nfs server (quickest way to build it seems, but may be wrong) test the blighter (destroy and rebuild) munge any new %post in build a few rpms for your custom bits (easy install/upgrade/delete paths) munge your custom rpms into the build and you will find that within a week (maybe 2 days) you have something that makes sense. So ref: "The problem is with the growing use in large enterprises" a large enterprise normally has a structured approach to it's installs, jumpstart (Solaris) has been around for a while now, (and it is a lot of work) ignite (HP) has been around for a while, (and is a lot of work) SMS has been around for a while (ever tried to set one up, let alone use it) kickstart is the baby of this lot, she has not been around to long and has bugs.... BUT At least she's quick. I can address the problems directly or via you guys at the LUG. If that fails i can mail redhat and get an answer from someone who is in general interested in what i am trying to do. At least (in general) I get errors pointing at what i have done wrong. Yes KickStart has a way to go, and for all the moans and groans in the LUG I still think it's a dam good RELIABLE tool, that can relieve some of the work i need to get done in my life. If you are an enterprise just do a cost comparison, across the methods shown above, a time comparison on getting the builds to market/implementation, and do an ongoing cost comparison for support and maintenance, you will then realise "what's a few bugs, a bit of CSense, and a completed build ahead of schedule, between friends" (What a waffler :-)) yours Alan.r.b. Seeing as how we are into sig files. ############################################################################ ###### Independent Contractor/consultant Fire-fighter, NOC builder, GlobalIS, IS, BUPA International (20 servers) Post Office (excess 100 servers) BodyShop (73 countries 1473 sites) just three of us :-) best yet (one I can't mention (53 countries approx 2000 servers) C&W IMAP (1 NOC 2x147,000 sq.ft, to many servers) BT/BSKYB (nice) Quadriga (Ongoing but a lot) P-commerce (A few tight servers) You only do the biggies by kickstart. Alan ############################################################################ ####### -----Original Message----- From: kickstart-list-admin@xxxxxxxxxx [mailto:kickstart-list-admin@xxxxxxxxxx]On Behalf Of Matt Fahrner Sent: 13 November 2001 15:27 To: kickstart-list@xxxxxxxxxx Subject: Re: thoughts on kickstart 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 --------------------------------------------------------------------- _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/kickstart-list
