Centralizing and Standardizing Your Kickstart Files

Now that you have the CD content in place, I recommend also setting up your ks.cfg flies for your server, workstation, laptop loads, and so on out on a centralized web share with standard link names that point to the latest version (you'll see). Some place that anyone can get to (unless you have security concerns, and then it can be password protected). This will enable you to literally install a desktop from around the world over the Internet if the FTP file share and web share of ks.cfg files are available, all with nothing more than a network connection and a boot floppy. Very powerful. Very nice.

To make web-based file shares where our own (non-CD) kickstart-related files will go, simply make a directory on the web server called installs (we're using ssh remotely to do this for us) and then copy (scp) the ks.cfg files over to your web server's default website under your installs directory:

   #  ssh root@www.example.com mkdir /var/www/html/installs
   root@www.example.com's password:
   #  scp ks-files/ks-*.cfg root@www.example.com:/var/www/html/installs/
   root@www.example.com's password:
   ks-everything.cfg                             100% 1812    67.2KB/s    00:00
   ks-IT-desktop_2004-02-16.cfg                  100% 1446    98.0KB/s    00:00
   ks-IT-desktop_2004-02-20.cfg                  100% 1446     1.7MB/s    00:00
   ks-my-first-install_2004-02-21.cfg            100% 1877    89.0KB/s    00:00
   ks-server-laptop-install_2004-02-22.cfg       100% 1877     1.9MB/s    00:00
   ks-workstation_2004-02-19.cfg                 100% 1446     1.5MB/s    00:00
   ks-workstation_2004-02-20.cfg                 100% 1446     1.5MB/s    00:00

Note

In the kickstart example in this chapter we are using a centralized ks.cfg file that is accessed via HTTP. Once you load your ks.cfg file (either locally from disk or remotely) and get the kickstart up, you see (as somewhat seen in our ks.cfg file) how you can access data, scripts, and packages located on other data shares including HTTP, NFS, and FTP. This is done just to illustrate the various ways in which you can load your data over the network. So if you're going to set up your own kickstart server, you can mix and match data stores of NFS, FTP, or HTTP throughout the install process, or keep them in one unified share such as HTTP or NFS. It's up to you.

And then log in to the web server and set up standard symlink pointers from standard names that you reference from the client side of the kickstart, to point to the specific file names that you change, update, and have date stamps on the centralized web server:

   # ssh root@www.example.com
   root@www.example.com's password:
   Last login: Thu Feb 19 23:17:12 2004
   # cd /var/www/html/installs/
   #
   #  ls
   ks-everything.cfg                   ks-server-laptop-install_2004-02-22.cfg
   ks-IT-desktop_2004-02-16.cfg        ks-workstation_2004-02-19.cfg
   ks-IT-desktop_2004-02-20.cfg        ks-workstation_2004-02-20.cfg
   ks-my-first-install_2004-02-21.cfg

Set up your symlink pointers:

   # ln -s ks-server-laptop-install_2004-02-22.cfg ks-server.cfg
   # ln -s ks-workstation_2004-02-20.cfg ks-workstation.cfg
   # ln -s ks-IT-desktop_2004-02-20.cfg ks-desktop.cfg
   # ls -la | tr -s " "| cut -f9,10,11 -d" "
   .
   ..
   ks-desktop.cfg -> ks-IT-desktop_2004-02-20.cfg
   ks-everything.cfg
   ks-IT-desktop_2004-02-16.cfg
   ks-IT-desktop_2004-02-20.cfg
   ks-my-first-install_2004-02-21.cfg
   ks-server.cfg -> ks-server-laptop-install_2004-02-22.cfg
   ks-server-laptop-install_2004-02-22.cfg
   ks-workstation_2004-02-19.cfg
   ks-workstation_2004-02-20.cfg
   ks-workstation.cfg -> ks-workstation_2004-02-20.cfg
   # exit

The ls command was to keep the output clean and understandable. The point here is how the standard names that you are going to reference from your kickstart clients will be standardized file names, which are simply pointers to the actual newest version of each particular ks.cfg file.

Now your client site boot media will be able to point to standard ks.cfg file names like

http://www.example.com/installs/ks-server.cfg

http://www.example.com/installs/ks-workstation.cfg

while keeping some form of sanity and organization on the back side of things. Next comes the fun part: creating and testing the client-side boot media.