Make user nagios managed

[rweigle]

It would be useful if the creation of the nagios user ist optional. In our enviroment due to check_by_ssh with forced_commands the user nagios must be managed separately (by the accounts module). This is in conflict with the icinga module.
A working diff (for Debian):

--- a/manifests/init.pp
+++ b/manifests/init.pp
@@ -39,7 +39,6 @@
 #
 class icinga(
   Boolean                              $ca,
-  Boolean                              $manage_user,
   String                               $this_zone,
   Hash[String, Hash]                   $zones,
   Enum['dsa','ecdsa','ed25519','rsa']  $ssh_key_type    = 'rsa',
@@ -135,12 +134,10 @@ class icinga(
             before => User['nagios'],
           }

-          if $manage_user==true {
-            user { 'nagios':
-              ensure => present,
-              shell  => $icinga_shell,
-              before => Class['icinga2'],
-            }
+          user { 'nagios':
+            ensure => present,
+            shell  => $icinga_shell,
+            before => Class['icinga2'],
           }
         } # Debian

[lbetz]

Hi,

thx for your issue and for using this module.

The module is an easy to use (like profiles) offer and prepared to use in a monitoring environment, also for check_by_ssh. If you need flexible classes, please use icinga/icinga2.

Bye
Lennart

[rweigle]

Hi Lennart,

We like the easy usage of the module to set up our icinga environment. We are aware that check_by_ssh is possible but in our case check_by_ssh is used with forced commands:

command="/usr/local/sbin/nagios_wrapper.sh",from="xxx.xxx.xxx.xxx",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa A...."

Therefore we need white spaces in the ssh key which are only supported in the puppetlabs-accounts Module but not with the build in puppet user resouce.
As other parameters of the module (e.g. repos) are already manageable it would be a nice enhancment (for us) if the user is manageable as well.

Thanks Rainer

[lbetz]

Sorry for the long wait. Currently I would not specify a pubkey, then no authorized_keys will be generated. The file must then be managed separately itself.
For the future I would plan to remove the pubkey part from this class and provide a separate class, since a scenario for ssh without agent is more likely anyway.