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/wwwl/installs root@www.example.com's password: # scp ks-/image/library/english/10027_ks-*.cfg root@www.example.com: /var/wwwl/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
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/wwwl/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
or
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.