Topic: fusioninventory-agent 2.4.1 using HTTPS on RHEL5.11

Hello everybody,

I need to get the fusioninventory-agent 2.4.1 running on RHEL5.11 using HTTPS.
When I start the fusioninventory-agent in daemon-mode it starts contacting the server but fails with

[Tue Oct  2 14:34:24 2018][info] sending prolog request to server server0
[Tue Oct  2 14:34:24 2018][error] [h t t p client] communication error: 500 Can't connect to inventory.nashtech.com:443 (LWP::Protocol::h t t p::Socket: Timeout)
[Tue Oct  2 14:34:24 2018][error] No answer from server at [url]h t t p s://inventory.nashtech.com/plugins/fusioninventory/[/url]

Does anybody has an idea how to get this running?

The server is working fine, agents running on RHEL7.x can connect to it and report their data.

Best regards,

Ruediger

Re: fusioninventory-agent 2.4.1 using HTTPS on RHEL5.11

Hi rbulla,

have you first checked your server can connect to your GLPI using HTTPS ? Try with a command like wget or curl.

SSL support may be just wrong on such an old platform and related Perl module are probably too old.

If you can't upgrade the system, or even install recent Perl module by CPAN, you still can simply make a local inventory in a file, transfer the file to a recent server (via SSH/FTP/what you want) and use fusioninventory-injector to import the file toward your GLPI server.

Re: fusioninventory-agent 2.4.1 using HTTPS on RHEL5.11

Hello gbougard,

thanks for the quick reply! The server hosting GLPI and FusionInventory works fine with respect to SSL - all agents on RHEL7.x machines do their work and also connections from such RHEL7.x clients via wget/curl are working fine.

As wget/curl on the RHEL5.x machines also have similar problems with SSL (I traced with tcpdump and the symptoms look identical) I guess it's really the old platform having issues with the SSL support - unfortunately we're not allowed to upgrade those systems.

We decided to just use HTTP connections between fusioninventory-agent and GLPI for the RHEL5.x machines, shouldn't be an issue as we don't leave the internal network.

Best regards,

Ruediger