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 ?

5 Answers 5


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 {
    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.

  • 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, 2012 at 12:52
  • 1
    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, 2012 at 12:54

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.

  • 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, 2012 at 20:03
  • @daff indeed. Edited my answer.
    – Not Now
    Dec 9, 2012 at 20:21

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.

  • 1
    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, 2012 at 20:34
  • 2
    @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, 2012 at 6:33

I guess it would be possible to use a pattern with anti-modules. For example...


This module would configure the host completely for zookeeper


This module would reverse anything done by the previous module.


This module would configure the host completely for lvs.


This module would reverse anything done by the previous module.

...and so on

Be careful though not to end up with competing modules where one present_module tries to set something and one not_present_module tries to undo that setting. This could happen where you have two modules requiring the same thing.

A way to solve that would perhaps be to break out that common setting to its own module and make the other two modules dependent on that one. However when no one longer requires that common module you will have to exchange it for the not_present_version of that module manually in the site.pp file.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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