Hi,
On Thu, Sep 3, 2009 at 20:16, Daniel Burklanddan@dburkland.com wrote:
variables in the individual scripts I believe are getting parsed by Kickstart. The parsing of these variables is preventing them from being written to the respective file.
You need to put the EOF string between single quotes, like this:
cat <<'EOF' >/path/to/file ... EOF
BTW, you may use the same EOF string for all the files, you don't have to add a different number to each of them.
I am having one issue and that is distributing a script (yum-check) via the kickstart file (in %post section). I am wondering if any of you have ever distributed a shell script via kickstart before and if so how did you do it?
As said above, there is an easy fix to your specific problem, but I would advise you *not* to create scripts from the %post section of your kickstart (unless for trivial stuff), otherwise it might become a maintenance nightmare in the future. If you need to update the script, not only will you have to update the kickstart but also all the machines installed with an old version of that kickstart file. Also, you will tipically need more than one kickstart for machines with slightly different hardware and partitioning information, so you will start getting many copies of that script and that may quickly become a mess of old versions if you ever need to update it.
Although it would take more work, I would advise you to create an RPM package with all your internal scripts. If you need to tweak config of software packages (like the chkconfig's above or disabling IPv6) you can even do it in the %post of that RPM package instead of in the %post of your kickstart (provided that you check if the RPM package is being upgraded, or better yet if a particular setting has already been done, so that you don't do it twice which can make a difference when appending). Then set up a small yum repository and refer to it from your kickstarts. Add the package to your packagelist and you're done.
The advantage is that, if you ever need to change *anything* in your scripts or base configuration, all you have to do is generate a new RPM with a new version, publish it to your yum repository and that's it! Any new machine installed with that kickstart will get the new one automatically, and any old machine will get updated as soon as you run "yum update" there. Plus, if you want to check which version is running on a specific machine, a "rpm -q <packagename>" is all you need to find that out. Bonus points if you keep the scripts and specfile in a source code repository like Subversion and keep the %changelog of the specfile always updated to track which changes were introduced where. Extra kudos if you get your RPM package signed with a GPG key.
Yes, I know it's a lot of work, but in the end it pays off. If you manage as many machines as to make it worth to use kickstarts, it's certainly enough to make it worth to keep your scripts in an RPM in a yum repository as well.
An alternative, as already suggested, is using "puppet" (or the older "cfengine") to automate this kind of tasks. From my point of view, it offers some extra features, but it's not as good to track versions as with an RPM... YMMV.
HTH, Filipe