Setting ensure => absent deletes /etc when used as configdir

[slugbucket]

I am deploying logstash-forwarder to a number of nodes but wanted to exclude the logstash master.

I have done this through Hiera and the following settings:

classes:

• logstashforwarder

logstashforwarder::servers:

• ip.ad.d.re.ss
  logstashforwarder::package_url: http://packages.elasticsearch.org/logstashforwar
  der/debian/pool/main/l/logstashforwarder/logstash-forwarder_0.4.0_amd64.deb
  logstashforwarder::configdir: /etc
  logstashforwarder::ssl_ca: /etc/pki/tls/certs/logstash-forwarder.crt

When the logstash master is set to exclude the forwarder with,

logstashforwarder::ensure: absent

Running,
puppet agent --test
notice: /Stage[main]/Logstashforwarder::Config/File[/etc]/ensure: removed

And /etc is no more. Package removal scripts typically take a more forgiving approach to directories that have other data in them.

[electrical]

Hi,

The configdir part is indeed fully removed since i assumed people would select a reasonable subdir and not something like /etc :-)
Package removal scripts indeed are more forgiving but in this case puppet removes it.

I'm thinking of a sensible solution for this and hopefully get it in a next release.

[slugbucket]

Hi Richard

I get the comment about choosing a safe configdir but this was on a node
where logstash-forwarder was not installed, where nothing needed to be
removed.
The intention was to prevent installation; 20 other nodes will install the
package through common Hiera data; an exception is the master where it
should be absent.

/etc was chosen as configdir to match hosts where the package had been
installed manually.

Kind regards,
Julian
On 12 Jul 2015 9:49 pm, "Richard Pijnenburg" notifications@github.com
wrote:

Hi,

The configdir part is indeed fully removed since i assumed people would
select a reasonable subdir and not something like /etc :-)
Package removal scripts indeed are more forgiving but in this case puppet
removes it.

I'm thinking of a sensible solution for this and hopefully get it in a
next release.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

[oloc]

Hi Julian,

If I may, let me propose you this way to manage old installation.
You should write a PFS (Package / File / Service) which describes the old installation, and put the ensure parameter to absent, and a before like that :

ensure => absent,
# others parameters
before => Class['logstashforwarder'],

and add the new installation with the logstashforwarder module.

This can clean your old installation and install the new one, and that will prevent from future manual installation.

[slugbucket]

Many thanks for the replies.

modules/logstashforwarder/manifests/config.pp:
...
} elsif ( $logstashforwarder::ensure == 'absent' ) {
file { $logstashforwarder::configdir:
ensure => 'absent',
recurse => true,
force => true
}
}

Maybe neither the force nor recurse are necessary if the package installation should attempt to purge the configdir. Or perhaps give the user control over whether to force removal with a more forgiving default.
I may have been confused in my case in thinking that logstash-forwarder.conf is installed in the configdir which is why I chose /etc as that directory.
My case was more about preventing an initial installation of the forwarder on a node running the master. Management by exception of a platform where every other host would have the forwarder.