RPM - Preventing uninstall and file conflicts.

[Hajducko, Steven]

Alright, this is a stupid question so I'm sorry to be asking it. I've
searched the list back for the past 2 years and I couldn't find anyone
mentioning this and I'm stuck. That said, I still must ask. :)

We have systems in several different, independant tiers in several
different environments. Each tier has it's own general network settings
- /etc/resolv.conf, /etc/hosts.allow, ntp.conf, etc. Each tier is
entirely independant, they do not communicate with each other ( in most
cases ). We keep these config files for all the tiers in a source
revision system on a management system.

What we'd like to do is create RPM's for each set of tier configuration
files. So I'd like to have my 'configs-web-production-1.0.0' RPM with
/etc/hosts.allow, /etc/hosts, etc and then we simply install the correct
tier RPM for any given system, depending on which tier the system
resides in. As a side note, all these systems are either RHEL3 or
RHEL4.

Now for the issues:

I've had to do the test installs with --force, as some of these files (
/etc/ntp.conf ) are owned by other packages ( ntp ). 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 ).
So should I just continue to install our new config RPMs with --force or
does someone else have some advice on how to properly solve this?

The other issue that I have is that our config RPM really has no one
depending on it, so in truth, it could be uninstalled accidentally,
which would result in a system without some very important files. The
only thing I can come up with would to be install an empty RPM that
requires our config RPM ( somewhat like the redhat-lsb RPM works.. ).
Any suggestions on this would also be welcome.

Thanks.

--
sh

[Jos Vos]

Post by Hajducko, Steven
I've had to do the test installs with --force, as some of these files (
/etc/ntp.conf ) are owned by other packages ( ntp ). 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.

Post by Hajducko, Steven
So should I just continue to install our new config RPMs with --force or
does someone else have some advice on how to properly solve this?

There is a simple and elegant way to do this: use trigger scripts.

Basic idea:

* Your localconfig rpm contains config file in an own directory,
say /usr/local/lib/config. E.g., /usr/local/lib/config/ntp.conf
can be a file in that package.

* Your localconfig rpm contains a trigger script for every package
of which you want to manage config files yourself. The ntp example:

%triggerin -- ntp
cat /usr/local/lib/config/ntp.conf > /etc/ntp.conf
service ntpd condrestart

(note that I'm using cat i.s.o cp to be sure to preserve modes etc.)

* You can also do simple editting (sed -i -e ...) on config files, so
that you don't need to include complete config files in your
package. Or call some functions or Perl scripts that you include
in your package. The variations are unlimited...

* You can make a localconfig per "class" of system (if you have some
system categories).

* With adding "Requires" and "Obsoletes" lines (be carefull with the
last...) you can let extra packages be installed or removed for that
class of systems by just providing a new version of localconfig in
a local yum repo, that is automatically picked up with yum.

This is my "network-wide system management by RPM" guide in short ;-).

Post by Hajducko, Steven
The other issue that I have is that our config RPM really has no one
depending on it, so in truth, it could be uninstalled accidentally,
which would result in a system without some very important files. The

Well, if you "accidentally" remove the kernel or so, you're in trouble
too :-). But in my example, accidentally removing the localconfig
package would just disable the scripts that update the config files
after package installs/updates, so everything keeps running.

Post by Hajducko, Steven
Any suggestions on this would also be welcome.

Hope the above gives some hints...

[Bob Proulx]

Post by Jos Vos

Post by Hajducko, Steven
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.

Post by Jos Vos

Post by Hajducko, Steven
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.

Post by Jos Vos
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.

Post by Jos Vos
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

[Hajducko, Steven]

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-***@redhat.com on behalf of Bob Proulx
Sent: Wed 11/14/2007 5:34 PM
To: rpm-***@redhat.com
Subject: Re: RPM - Preventing uninstall and file conflicts.

Post by Jos Vos

Post by Hajducko, Steven
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.

Post by Jos Vos

Post by Hajducko, Steven
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.

Post by Jos Vos
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.

Post by Jos Vos
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

[Jos Vos]

Post by Bob Proulx
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 fully agree, almost all of mt "config stuff" is scripting, not files,
but in the example I referred to example the original poster gave.

Post by Bob Proulx
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.

I agree that the contents of the package (scripts, spec file, etc.)
should be in version control, but I would use that subversion repo
(or whatever) as the source for building tarballs, that are the
source for your config RPM. But there are many ways to deal with this.

[Paul Johnson]

On Nov 14, 2007 1:22 PM, Hajducko, Steven

Post by Hajducko, Steven
What we'd like to do is create RPM's for each set of tier configuration
files. So I'd like to have my 'configs-web-production-1.0.0' RPM with
/etc/hosts.allow, /etc/hosts, etc and then we simply install the correct
tier RPM for any given system, depending on which tier the system resides
in. As a side note, all these systems are either RHEL3 or RHEL4.

I've been there too, and asked a lot of questions, eventually gave up
trying to replace config files like that. I got a lot of suggestions.
Maybe the best was to set up a CVS server and have systems update
those config files against it. But I didn't do it because it's easier
to just re-make the RPMS I need and distribute them than it is to hack
up a config rpm.

But...

Why couldn't we try to use the alternatives framework for this.

Collect up the config files you want and install them anywhere you want.

Note how the system under /etc/alternatives works. THey are all
symbolic links that point to the real things. So after you install
your files somewhere--in a place that does not conflict, of course,
then the alternatives framework can be used to tell the system to use
your files. And if your RPM is removed, I believe the postun section
can be set to restore the links to the original files.

Well, probably not better than the trigger scheme described by
previous responder.

[Tim Mooney]

Post by Paul Johnson
On Nov 14, 2007 1:22 PM, Hajducko, Steven

Post by Hajducko, Steven
What we'd like to do is create RPM's for each set of tier configuration
files. So I'd like to have my 'configs-web-production-1.0.0' RPM with
/etc/hosts.allow, /etc/hosts, etc and then we simply install the correct
tier RPM for any given system, depending on which tier the system resides
in. As a side note, all these systems are either RHEL3 or RHEL4.

I've been there too, and asked a lot of questions, eventually gave up
trying to replace config files like that. I got a lot of suggestions.
Maybe the best was to set up a CVS server and have systems update
those config files against it. But I didn't do it because it's easier
to just re-make the RPMS I need and distribute them than it is to hack
up a config rpm.

Using a repository and a pull mechanism will work, but you might have
better luck using a host configuration management system. The one that's
probably the most well-known is cfengine, but I would suggest you have a
look at some of the other options, especially puppet.

Since all the systems are RHEL, you may also want to consider Red Hat
Network. There's an option available for it (I think it's the
"Management" entitlement) that allows some host configuration management
functionality.

Tim

[Hajducko, Steven]

Both options we've looked at and unfortunately, cannot use due to
security restrictions. Instead of cfengine we use Cendura Cohesion (
recently aquired by CA ) for our configuration management. Right now
I'm only dealing with RHEL systems but we have a mix of RHEL, AIX,
Windows and some Solaris and Cohesion had agents for all of those. I
haven't heard of puppet, so I'll take a look at that.

Alot of the difficulty in our situation stems from the multiple tiers
that are unable to communicate with each other, thus resulting in having
multiple servers of any type ( ie - 2 DNS servers per tier, 1 yum repos
per tier, a kickstart server per tier), none of which are able to use a
centrally managed machine to replicate from for all of their configs and
ata. Add ontop of that the fact that many of these tiers have no
internet access and you only see the tip of the iceberg.

The config RPMs were considered because they're easy to generate out of
our SVS and easy enough to replicate to the kickstart/yum repos in each
tier manually. I'm also trying to get webjob (
http://webjob.sourceforge.net ) implemented as a tool for RPM
installation and other adminstrative tasks, but that's a whole other
battle.

Again, I appreciate everyone's input on this.

--
sh


-----Original Message-----
From: rpm-list-***@redhat.com [mailto:rpm-list-***@redhat.com]
On Behalf Of Tim Mooney
Sent: Thursday, November 15, 2007 1:59 PM
To: RPM Package Manager
Subject: Re: RPM - Preventing uninstall and file conflicts.

In regard to: Re: RPM - Preventing uninstall and file conflicts.,

Post by Paul Johnson
On Nov 14, 2007 1:22 PM, Hajducko, Steven

Post by Hajducko, Steven
What we'd like to do is create RPM's for each set of tier
configuration files. So I'd like to have my
'configs-web-production-1.0.0' RPM with /etc/hosts.allow, /etc/hosts,
etc and then we simply install the correct tier RPM for any given
system, depending on which tier the system resides in. As a side

note, all these systems are either RHEL3 or RHEL4.

Post by Paul Johnson
I've been there too, and asked a lot of questions, eventually gave up
trying to replace config files like that. I got a lot of suggestions.
Maybe the best was to set up a CVS server and have systems update
those config files against it. But I didn't do it because it's easier
to just re-make the RPMS I need and distribute them than it is to hack
up a config rpm.

Using a repository and a pull mechanism will work, but you might have
better luck using a host configuration management system. The one
that's probably the most well-known is cfengine, but I would suggest you
have a look at some of the other options, especially puppet.

Since all the systems are RHEL, you may also want to consider Red Hat
Network. There's an option available for it (I think it's the
"Management" entitlement) that allows some host configuration management
functionality.

Tim