How to revert a configuration with puppet

Question

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 ?

Solution 1

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.

Solution 2

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.

Solution 3

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

zookeeper_present

This module would configure the host completely for zookeeper

 zookeeper_not_present

This module would reverse anything done by the previous module.

lvs_present

This module would configure the host completely for lvs.

lvs_not_present

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.

Solution 4

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.

View more solutions

Comments

[DJYod]

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 ?

[gertvdijk]

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.

[daff]

Just so there isn't any confusion: technically my_apache::uninstall is a class which is part of the my_apache module.

[Not Now]

@daff indeed. Edited my answer.

[gertvdijk]

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.

[kashani]

@gertvdijk which is why I said "own anything in /etc/rsyslog.d/ and delete anything that Puppet does not manage within it."