Well at least I know someone has tread the path before me and I thank you for the insights Bob. However I'm curious as to why you would say to keep the scripts for generating the configuration files in source control, rather than the configurations themselves. I only ask this because:
a) The configurations are rather simple, 4 or 5 line configuration files. Nothing complicated
b) The configurations are mostly static, they do not change very often and generally there are rather few of them.
In other words, I don't think I'd have any scripts at all. Our current source control system works rather well. The thought of using config files for RPMs came from our recent implementation of Kickstart. Rather than scripting all the config file changes in the Kickstart configuration files, we wanted to put Tier-specific RPMs on the KS server and just install those during the Kickstart process. One thing led to another and it wound it's way to us considering implementing the tier config RPM's on all systems.
Jos, thanks for the information about the trigger scripts, I hadn't investigated those yet. I'm wary of having empty RPM's that just script changes to configuration files, for the reasons above and the additional reason that it prevents and admin from easily identifying the files stored in the RPM and they'd have to review the scripts. I do like the trigger ideas, with keeping the files on the system but just in another location and simply copying/catting them into the proper place.
When I meant about making the RPM 'sticky', I just was interested in making it a little more difficult to remove the RPM from a simple fat-fingering of flags. For instance, you cannot really just rpm -e kernel because of the dependencies and you must first remove those before you could even try to remove kernel. So in a sense, I wanted to create at least one dependency in order to provide a similar situation. Just a thought and more just brainstorming than anything.
I appreciate the links and I will definetly be reading through the pages.
--
sh
-----Original Message-----
From: rpm-list-bounces@xxxxxxxxxx on behalf of Bob Proulx
Sent: Wed 11/14/2007 5:34 PM
To: rpm-list@xxxxxxxxxx
Subject: Re: RPM - Preventing uninstall and file conflicts.
Jos Vos wrote:
> Hajducko, Steven wrote:
> > I've had to do the test installs with --force, as some of these files (
> > /etc/ntp.conf ) are owned by other packages ( ntp ).
I tried doing what you are now trying to do some time ago. My
experience from it led me away from packaging configuration files as a
system management technique. I now believe it to be good experience
about how not to do things. Instead I would manage configuration
files through other means where the root of that would be based in
revision control. (But that gives a lot of flexibility and leeway.
> > NTP actually isn't too much of an issue and could be repackaged,
> > but other RPMS such as 'setup', a RHEL specific RPM, is not
> > repackagable ( to my knowledge ).
>
> Everything can be repackaged, every RHEL rpm has a src.rpm (except for
> some in the supplementary - proprietary - channel), but that's a lot of
> work and a bad idea to do.
I would not repackage everything because it creates such a support
issue. Let's say you are trying to run a 3rd party application but it
has certain requirements and you need support for it. As soon as the
system is examined it will be found to be no longer a supported
system.
> There is a simple and elegant way to do this: use trigger scripts.
A good suggestion. All of the notes there I mostly agreed with. It
is not a bad way of doing things.
But actually I think putting configuration in packages is very heavy.
It makes making changes to the configuration a more labor intensive
process because new packages must be created.
> This is my "network-wide system management by RPM" guide in short ;-).
I want to emphasize that I think that list was all quite good! I want
to emphasize this because I am going to suggest that creating packages
for configuration, while a solid and reliable system, is too heavy.
Therefore I would not do it. I think it is better to keep the scripts
that configure the system in version control. To be clear I think it
is better to keep the scripts that set /etc/ config files in version
control, not the /etc/ config files themselves in version control.
I agree completely that using scripts to edit the configuration files
on the machine is definitely the way to go. But instead of putting
them in packages I would have them in version control and have the
system check them out from version control before running them. The
framework to implement this may certainly be put in a package and
distributed that way. But then when system changes are required I
would make the changes in version control and let them propagate.
A good place for further information on this type of thinking is the
Infrastructures site. Browse around there, perhaps join the mailing
list for discussion, and see what you think.
http://www.infrastructures.org/
Bob
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
