Tom Brown wrote:
> Hi
>
> During a 'normal' install i have to add a bunch of users and modify some
> files such as DNS, Syslog, ssh key files etc
>
> While i can do this with a shell script post install it would be VERY
> neat to just have all these changes packaged up into an rpm and i can
> then just rpm -i this post install.
I've had a look at such issues before a few times, and came to the
conclusion that rpm is the wrong place to be doing this, at the post
install stages. The main reason is that its good, on a managed system,
to retain package -> file relations. and overlap'ing stuff tends to get
in the way, a lot, and very often.
Also regulating an entire system out of 1 rpm only works if you have
dozens of identical machines ( but even then, you will need some state
based per-machine config rquirements, eg the network setttings, the host
specific cluster roles etc ). So you end up with lots of
per-role/package rpms ( eg. MyCompany-postfix-configs-1.2.1.noarch.rpm
and MyCompany-vsftpd-configs-1.2.1.noarch.rpm etc ).
And if you really need to make that much of an effort, cfengine and
puppet start looking a lot easier, functional and easier to manage. And
if you can get a svn backend going for the config's itself - that
extends the ability to manage multiple machines, roles, and be able to
version track the config's and settings per machine / per role / per
config set / per package. Its upto you, how far you want to drill down
and what levels you want to maintain.
The question that still does remain unanswered at this stage is howto
get the cfengine / puppet / raw-svn checkout, to run automatically post
install. Thats where Kickstart comes in. Build site specific rpms for
cfengine and a site specific cfengine-config rpm, and have kickstart
install them ( you can wget <url> and rpm -ivh <url> to get them from a
remote site, in the chroot, in the %post stage of your kickstart ).
The activation bit is really easy, and this is where the charm of using
s stable enterprise distro comes up. Kickstart is powerful in that it
lets you do funky things postinstall / and prep the machine. Similarly
on the startup there is Firstboot. A very very underrated app that gets
overlooked often. What Firstboot will do, and is best used for - is
custom python scripts as modules that are then run on the machine when
the machine boots, for the first time (= :) ). That is where the initial
cfengine activation can / should be run ( well, you can do lots and lots
of stuff ..... like I said, firstboot is very under-rated, but quite
powerful ).
> Can i do this and if so can anyone point me to a how-to that would help
> me through the steps required.
I just looked and found nothing RHEL/CentOS specific ( for the process I
just laid out ) - would you like to trial this method and write up
something on the wiki.centos.org site ? I'd be happy to help along the
process, as much as I can.
- KB
--
Karanbir Singh : http://www.karan.org/ : 2522219@icq
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
