Anaconda (kickstart handling) idea.

kbn at daimi.au.dk kbn at daimi.au.dk
Tue May 18 15:51:21 UTC 2004



Brad Smith wrote:

>>Mind you that the whole idea of kickstart is to be non-interactive when
>>done correctly, and your idea blows that to smithereens. I think you
>>could better use DNS to select the best ks.cfg, see man dhcpd.conf,
>>although that would be less flexible.
>>    
>>
Shouldn't that be DHCP, not DNS ?? :)
Actually it's quite easy to use dhcp to select the correct kickstart 
file. I've included a working example from our dhcp server:

group {
  option domain-name-servers 10.0.0.10;
  # Server where kickstart file resides
  next-server kickstartserver;
  # Kickstart filename
  filename 
"/a/home/kickstartserver/RedHat/kickstart/delta_frontier_1200-6.2.ks";
  # Router (gateway)
  option routers centauri;

  host whatever {
                hardware ethernet 00:00:00:00:00:00;
                fixed-address whatever;
        
}                                                                                                                                              

}

I've anonymized the data, for our own protection, but the example should 
be quite easy to follow. Please notice, that kickstartserver is the 
server, where the kickstartfile resides. In our setup, it's also the 
server where the install files is located, and the same server also runs 
an apache  server, which  only serves to provide the install files via http.

Another way is to use pxe installation:

http://www.stanford.edu/~alfw/PXE-Kickstart/PXE-Kickstart.html#toc6

I prefer to use pxe installation, as I can sit on my flat butt, when 
proberly configured, and reinstall all the machines...

>
>
>...a couple of other suggestions:
>
>Remember that the other end of the url you give kickstart doesn't need
>to be a static file. It can be a cgi script that writes a custom ks.cfg
>based on url arguments, dns, subnet, or whatever.
>
>Also, I once had a student who wrote self-writing kickstart files. by
>having the %pre script modify /tmp/ks.cfg based on, well, whatever. 
>
>That said, while I agree that the point of kickstart is to be
>non-interactive, I don't think it would "blow that out of the water" to
>have one non-default mode of operation that employs an interactive, but
>very useful, menu system with less trouble than burning a custom
>boot.iso every time you want to add an option.
>
>--Brad
>
>
>  
>

In our setup, we also loads a custom %post script into the kickstart 
file, to setup the machine to our liking...

Regards
/kbn





More information about the fedora-devel-list mailing list