os::linux::local::plugin --mode=list-storages doesn't return an error on connection problems using ssh-backend sshcli or plink

[rmorandell-pgum]

Quick description

When I'm using the plugin os::linux::local::plugin with mode "list-storages" it doesn't terminate with an error when using wrong ssh credentials or the destination doesn't respond on ssh port.

The plugins responses with a empty xml and return code 0 for OK.

using the ssh-backend the plugin response is correct:

How to reproduce

Please provide below the initial conditions to reproduce the bug

• perl centreon_plugins.pl --hostname=<IP that has no SSH port open) --ssh-backend=sshcli --ssh-username=test --ssh-password='' --ssh-priv-key='' --sshcli-option='-o=StrictHostKeyChecking=no' --plugin=os::linux::local::plugin --mode=list-storages --ssh-port=22 --disco-show

Expected result

Same plugin with mode=uptime with ssh-backend=sshcli does it correct.

perl centreon_plugins.pl --hostname=10.10.100.23 --ssh-backend=sshcli --ssh-username=test --ssh-password='' --ssh-priv-key='' --sshcli-option='-o=StrictHostKeyChecking=no' --plugin=os::linux::local::plugin --mode=uptime --ssh-port=22
UNKNOWN: Command error: ssh: connect to host 10.10.100.23 port 22: Connection refused

So using the service discovery command I can't understand if the SSH communication is working and only there are no items for the filter used (empty list) or the communication is broken

[lucie-tirand]

Hello :)

Empty OK output represents a problem that we have already identified and which occurs in various situations where the result is absolutely not OK (globally an empty OK is not good news).

I've done a quick test which seems to fix the problem here but I'd have to check that it doesn't interfere with the normal working of the plugin (when the ssh connection is possible and the credentials are correct). If you want to test it you can add the following block to line 80 of the manage_selection function:

if (scalar(keys %{$results}) <= 0) {
        $self->{output}->add_option_msg(short_msg => 'No results found');
        $self->{output}->option_exit();
    }

This will returns:

<?xml version="1.0" encoding="utf-8"?>
<plugin>
  <name>os::linux::local::plugin</name>
  <mode>list-storages</mode>
  <exit>unknown</exit>
  <outputs>
    <output>
      <type>1</type>
      <exit>UNKNOWN</exit>
      <msg>UNKNOWN: Command error: ssh: connect to host localhost port 22: Connection refused</msg>
    </output>
  </outputs>
  <perfdatas/>
</plugin>

and

echo $?
3

If you want exactly the same answer than the uptime mode you can in the same manage_selection function remove the line 53 no_quit => 1 you should have this resullts:

<?xml version="1.0" encoding="utf-8"?>
<plugin>
  <name>os::linux::local::plugin</name>
  <mode>list-storages</mode>
  <exit>unknown</exit>
  <outputs>
    <output>
      <type>1</type>
      <exit>UNKNOWN</exit>
      <msg>UNKNOWN: Command error: ssh: connect to host localhost port 22: Connection refused</msg>
    </output>
  </outputs>
  <perfdatas/>
</plugin>

and

echo $?
3

But I'm not sure if we should remove this because it should had been added because of a reason (that I don't know for the moment).
You can try both and give us a feedback in real conditions if one of this break something or not.

[rmorandell-pgum]

Hi Lucie,

i think the solution is to remove the "no_quit => 1". This is working fine for me.

The first solution does return exit code 3 and "no results found".

What is not the exact error message because we don't no if there are storage because I can't even connect. So if I can connect and I have an empty list this is OK for me and not an error in this case.

thanks for help