Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rmorandell-pgum opened this issue Dec 20, 2024 · 1 comment

Comments

@rmorandell-pgum
Copy link
Contributor

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.

image

using the ssh-backend the plugin response is correct:

image

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

image

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-dubrunfaut
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants