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 wrote a module which writes a configuration for rsyslog in /etc/rsyslog.d/60-custconfig.conf using puppet.

When I add the module to the node, it works, but if I delete comment or delete the module call in the node, is it supposed to remove the file ? if not, is there a manner to rollback a configuration or installation ?

share|improve this question
add comment

4 Answers

You don't revert actions Puppet has carried out by removing the resource. By removing the resource from your manifests, you're only telling Puppet not to manage it (anymore).

Also, Puppet simply doesn't remember/know about the previous states, so it can't revert to that. It just tries to change the system to a state you define in the manifests.

One way I see here, is to include the file resource again, but now with ensure => absent:

file {
    '/etc/rsyslog.d/60-custconfig.conf':
    ensure => absent,
}

Also you could change the design of the Puppet modules in this way:

  • Manage all rsyslog configuration files in a rsyslog module.
  • Create virtual custom defined types from other modules requiring the change in rsyslog.
  • In the rsyslog module, collect the virtual configuration stanzas and instruct it to delete all undefined resources of that custom type.

Or even easier is to use the puppetlabs-concat module, define virtual concat::fragments in modules and collect them in the rsyslog module to build the '60-custconfig.conf' configuration file. If then the virtual resources get deleted from the other modules, the fragments gathered will result in a file without the fragments now unmanaged. Effectively, these will be deleted from the file.

share|improve this answer
    
Hmmm yeah, I was looking for a simpler solution like "ok you had this module configured and now you don't have it anymore, I assume I can delete it" you see what I mean ? –  DJYod Dec 6 '12 at 12:52
    
Yes, I know what you mean. However, Puppet only compares states about objects you tell him about and at this point in time. disclaimer: I'm not a Puppet expert. –  gertvdijk Dec 6 '12 at 12:54
add comment

You have to explicitly write code that will "undo" any specific actions that you want to revert.

For example, if you have a my_apache module that install a few packages, configures several files, and ensures a certain state, you will have to write another class inside this module, lets call it my_apache::uninstall, that undoes each of the things that your other module did. The undo class does not have to be inside, or part of the original module. It can be a completely separate class. A good way to change what classes are applied to a host, is to use an ENC.

share|improve this answer
    
Just so there isn't any confusion: technically my_apache::uninstall is a class which is part of the my_apache module. –  daff Dec 9 '12 at 20:03
    
@daff indeed. Edited my answer. –  Not Now Dec 9 '12 at 20:21
add comment

There is no simple answer for reverting or removing config changes in Puppet, but one simple method is to use a config dir that Puppet manages.

class rsyslog::config {

  file { '/etc/rsyslog.d':
    ensure  => directory,
    force   => true,
    purge   => true,
    recurse => true,
  }

  file { '/etc/rsyslog.conf':
    ensure  => present,
    content => template('rsyslog/rsyslog.conf.erb'),
  }

  file { '/etc/rsyslog.d/50-default.conf':
    ensure  => present,
    content => template('rsyslog/50-default.conf.erb'),
    require => File['/etc/rsyslog.d'],
  }

}

What the above does is tell Puppet to completely own anything in /etc/rsyslog.d/ and delete anything that Puppet does not manage within it. If the server was previously running haproxy and you have an config for that in your syslog, when you removed the happroxy module the reference to /etc/rsyslog.d/40-haproxy.conf would disappear and Puppet would remove it from the config dir. It also generates a notify event which you could use to have Puppet restart syslog as well though you'd need a notify or ~> chain to the service to do so.

share|improve this answer
    
Nice suggestion, but this will break stuff in default configurations. Several packages are installing rsyslog configurations in /etc/rsyslog.d, such as Postfix. Could be a nice solution if you know the directory should be empty in any case. –  gertvdijk Dec 14 '12 at 20:34
    
@gertvdijk which is why I said "own anything in /etc/rsyslog.d/ and delete anything that Puppet does not manage within it." –  kashani Dec 21 '12 at 6:33
add comment

To elaborate on the answers already posted: Puppet manages resources. Managing means it knows about the state of resources and makes sure a resource is in the desired state. You tell Puppet what to manage and in which way to manage it. And once Puppet no longer knows about a resource, it cannot longer manage it, obviously. That is the way Puppet works.

Imagine the havoc it would wreak on the system if Puppet simply deleted resources it no longer knows about. That in itself already sounds paradoxic; how do you delete anything you don't know about? But even if there were a way for Puppet to do that, it would probably destroy your system.

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.