Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I need to provide some configuration customization to several servers in our small department network. We are using RHEL5 currently and since I don't want to repeat work, I'd like to create RPMs with that configuration and upload them to our RHN.

Now the problem: assuming I want to distribute NTP configuration via /etc/ntp.conf. Sadly, there is no /etc/ntp.d/ to put my files into, thus I'd have to overwrite the ntp.conf with my RPM. How do I do that properly, i.e. without losing that configuration when ntp is updated and also without possible configuration files conflicts?

share|improve this question
add comment

5 Answers 5

up vote 5 down vote accepted

Go with David's solution of using puppet instead. Really.

However, if you're determined, what you can do is create a package rassie-ntp-conf that contains "/etc/ntp.conf.rassie". In the spec file, you'll need a %post that copies your config over the default config and also a "%triggerin -- ntp-server" that does the same. That way if a later upgrade overwrites the config, the trigger will copy back over it. Maybe drop something into /etc/cron.daily to do the same to be really sure... Probably need to have all those scripts do a service ntpd condrestart after the cp, too.

That's the basics. If you want to do it for more packages, you might instead build a standard script that runs through /etc/rassie/ to find configs to copy over into /etc and have the %post and %triggerin stuff run that instead.

But, really, ignore that and use puppet or Chef or cfengine... This kind of "pushing configuration out via RPM" scheme is fraught with subtle problems stemming from the fundamental problem that RPM isn't designed to have two different packages fight over a single file. Hard to test, hard to debug, exactly the sort of clever solution that will make you later wish you'd gone with puppet in the first place.

share|improve this answer
    
+1 - RPM isn't for doing what you're trying to do. RPM is great for distributing binaries to servers (which isn't something that a configuration management system like Puppet is for). "I want to pound a nail but all I have to pound with is this package of eggs. What should I do?" –  Evan Anderson Jul 13 '09 at 12:38
add comment

Can I suggest an alternative solution? You might find that a configuration management tool like Puppet or Cfengine2 does what you want. You write manifest files that describe how you want a system to look and it goes away and changes the system so it looks like that. Notice the important distinction that you are describing how the system should look, not how you change the system. An example for ntp might be:

class ntp {
   package {"ntpd":
       ensure => latest,
   }
   file { "/etc/ntp/ntp.conf":
       source => "puppet:///ntp/ntp.conf",
       owner => "root",
       group => "root",
       mode => 644,
       require => Package["ntpd"],
   }
   service { "ntpd":
       ensure => running,
       enable => true,
       subscribe => File["/etc/ntp/ntp.conf"],
   }
}

When you include this class in a particular node, you will install the ntpd package, copy your file across to the server and make sure the daemon is running. If puppet makes any changes to ntp.conf, it will restart the ntp daemon (thanks to the subscribe line).

How does this solve your problems? Well, when a new version of ntp is installed, if the package overwrites the config file, puppet will copy the old one back. If there are any differences, it will display a diff as it changes it, so you can see what changes have been made, so you can notice any differences and update your central version if you want those changes.

share|improve this answer
add comment

Regardless of how you decide to push out the changes, if you need to modify ntp.conf (or any config file, really) and do not want to wholesale replace the file, take a look at Augeas (http://augeas.net). There is a little bit of a learning curve, but it removes a lot of the complexity of parsing/editing files.

share|improve this answer
1  
It's worth pointing out that Puppet has Augeas support, so you can get the power of easily modifying config files with the power of configuration management :) –  David Pashley Jul 13 '09 at 23:02
    
Indeed. I edited that out of my response, but puppet + augeas is how I address service configuration issues in my environment. –  Chad Huneycutt Jul 13 '09 at 23:19
add comment

I think Puppet or CFEngine is the way to go in the long run. But as a first step that easier to implement a version control system such as subversion or git should work. You'll want to keep your change history of configuration files even under Puppet and CFEngine.

share|improve this answer
add comment

I've tried to handle using only rpms to. Only when your config files are very simple it's possible.

The best approach, but it's not to simple to implement is using tools like puppet and cfengine as everyone suggested.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.