I guess you could say that they are more "informational" files? They are unique to our process and not "owned" by any application... We have a couple of custom applications that use these files to define how the server/applications work. It's a server farm in which we have all servers doing the exact same thing. This server farm exists in many locations around the world and I don't necessariliy have direct access to all of them which is why I'd like to use this method. Just for my knowledge, someone else responded with another application that I will check into as well. If I can't do this through RPM perhaps I could deploy the other app through RPM and use it as well. However, I would like to keep all of this through one process. Does this help? On Wed, 28 Jul 2004, Paul Nasrat wrote: > On Wed, Jul 28, 2004 at 09:53:55AM -0500, sjohnson@xxxxxxxxxxx wrote: > > > > We've got about 200 linux servers that we need to modify different files > > (mainly text) on a regular basis. We already have an RPM deployment > > system in place for them. > > > > Is it possible to create an RPM that would deploy the text config files > > into the appropriate directories? > > Without a bit more context of the problem you are trying to solve it's hard > to say. > > Are the config files owned by any other packages, or do they purely exist in > your packages? > > Are the changes consistent amongst the servers or will there be different > setups/profiles? Do servers ever change there profile to another profile. > > What are the main causes for the "regular" updates, is that across all > packages or only a subset? > > Were you thinking of one shared config package, or use the individual packages to update? How are you consolidating upstream errata, etc? > > Some idle thoughts: > > RPM manages at the package level - so if your config file is owned by another package there will be a file conflict. At the moment there is a virtual config package provided with %config eg: > > config(httpd) = 2.0.50-2.1 > > But there is no mechanism to split it out (--withoutconfigs) and provide it > via a seperate package. > > My gut feeling is that you may be better suited with NIS/LDAP for configuration deployment, or maybe lcfg or cfengine. > > Paul > > > _______________________________________________ > 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
