[CentOS] Kickstart help

[Filipe Brandenburger]

Hi,

On Thu, Sep 3, 2009 at 20:16, Daniel Burkland<dan at 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