Drop management of Init script

[baurmatt]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: All
• Ruby: All
• Distribution: All
• Module version: Since Custom config file name/path #240

What are you seeing

The module manages the init script for agent and server. This was done because some custom settings e.g. configdir require a change for startup values of the zabbix agent|server process. In my opinion managing the init file is bad because it leads to a lot of problems with e.g. updates and should only be done if there is no other option.

What behaviour did you expect instead

Use the OS's defaults file:

Debian -> /etc/default/zabbix-agent
RedHat -> /etc/sysconfig/zabbix-agent
SystemD -> /etc/systemd/system/zabbix-agent.service.d/override.conf

Output log

Any additional information you'd like to impart

Are you interested (and are willing to merge it ;)) in a PR which moves the configuration to the mentioned default files?

[bastelfreak]

mhm. So in general I agree, managing the init script should be the last option. Getting rid of it is annoying. At least for systemd this isn't too bad because our service files are in /etc/systemd/ and not /usr/lib/systemd/. Also we have acceptance tests to ensure that the scripts work. We can improve the support of the defaults file and add a parameter to manage / not manage the init files, but I'm not sure if we should disable it.

[baurmatt]

I'm not sure if it is a good idea to manage the defaults file and the init script, this would probably lead to more confusion for the users of the module. Can you explain why you hesitate to drop the init management?

[baurmatt]

@bastelfreak How should we proceed here?

[bastelfreak]

Honestly, I don't know. I am fine with managing the defaults files. But stopping the management of a file can lead to some errors. I am not sure what the best approach is. Maybe we actually stop it, make a new major release and add some acceptance tests that verify everything is still working.

[baurmatt]

Another day, another look, another problem :( Seems like the SystemV Init File for e.g. 3.0 doesn't have a DAEMON_OPTS variable which makes it hard to configure the config file path in them defaults file. I guess to much config options make life harder ;)

Will see if i can come up with an alternative.

[baurmatt]

So we discussed this internally and came up with the following idea: We add a parameter manage_init_script which defaults to true. As this might break some configuration if set to false we suggest to add a big bold warning in the docs that this parameter might not be used with others (agent_configfile_path, service_type, pidfile, additional_service_params, zabbix_user). Are you ok with that?

[bastelfreak]

Sounds fine to me!