Inventories not received after upgrade to 2.4

Question

Hello,

Since upgrading our OCS to v2.4, no agents are able to successfully send their inventories.

I am seeing errors in my /var/log/httpd/error_log as follows:

[Tue Feb 06 08:57:42 2018] [error] [client 10.11.23.178] Can't call method "do" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/Apache/Ocsinventory/Server/System.pm line 189.\n
[Tue Feb 06 08:57:52 2018] [error] [client 10.11.26.101] Can't call method "do" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/Apache/Ocsinventory/Server/System.pm line 189.\n

Line 189 of the script is:

$dbh->do("SET sql_mode='NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'");

I hit this problem last time I upgraded, but it was fixed by updating our DB access details: http://ocsinventory12.rssing.com/browser.php?indx=50766537&item=1567

This time, however, our details are correct, but we still have the problem.

Please can someone guide me on where to start looking to fix this problem?

Thank you.

EJ

System Details:

OS Name : Linux x86_64
Version : 2.6.18-419.el5.centos.plus
RAM installed : 7979 MB
CPU : Quad-Core AMD Opteron(tm) Processor 1354
PHP Version : 5.6.30
Web Server : Apache
Database Server : MySQL Community Server (GPL) by Remi version 5.5.54
Version OCSReports: 2.4

Answer 1

I also have this problem, installed the 2.4 version of OCS, using a previous database of 2.1 version.

Everything works nicely, but I can't receive the inventory from agents.

Username and password of database works fine.

I can write data from the interface of OCS reports to my database.

Creating new tags or updating and doing other things, but no new inventories.

From /var/log/ocsinventory-server/activity.log I have this:

Mon Feb  5 14:55:55 2018;27761;318;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;missing
Mon Feb  5 14:55:55 2018;27761;114;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;no_session
Mon Feb  5 14:55:55 2018;27761;104;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;incoming
Mon Feb  5 14:55:55 2018;27761;515;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;end;error
Mon Feb  5 14:56:07 2018;13082;103;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;prolog;new_deviceid
Mon Feb  5 14:56:07 2018;13082;100;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;prolog;accepted
Mon Feb  5 14:56:07 2018;13082;311;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;started
Mon Feb  5 14:56:14 2018;25101;318;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;missing
Mon Feb  5 14:56:14 2018;25101;114;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;no_session
Mon Feb  5 14:56:14 2018;25101;104;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;incoming
Mon Feb  5 14:56:14 2018;25101;515;PANOVA-2018-02-02-17-16-18;192.168.204.210;OCS-NG_WINDOWS_AGENT_v2.3.1.1;end;error
Tue Feb  6 07:57:57 2018;4039;103;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;prolog;new_deviceid
Tue Feb  6 07:57:57 2018;4039;100;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;prolog;accepted
Tue Feb  6 07:57:57 2018;4039;311;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;session;started
Tue Feb  6 07:58:02 2018;4043;318;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;session;missing
Tue Feb  6 07:58:02 2018;4043;114;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;inventory;no_session
Tue Feb  6 07:58:02 2018;4043;104;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;inventory;incoming
Tue Feb  6 07:58:02 2018;4043;528;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;accountinfos;missing
Tue Feb  6 07:58:02 2018;4043;515;dsvadriano-2018-02-06-07-57-56;192.168.204.198;OCS-NG_unified_unix_agent_v2.0.5;end;error

Answer 2

I have found the answer to our problem.

Even though I updated /etc/ocsinventory/ocsinventory-reports/dbconfig.inc.php and /etc/httpd/conf.d/z-ocsinventory-server.conf, we found that /etc/httpd/conf.d/zz-ocsinventory-restapi.conf also has to be updated.

It appears that the DB creds in /etc/httpd/conf.d/z-ocsinventory-server.conf get replaced by /etc/httpd/conf.d/zz-ocsinventory-restapi.conf, even though we're not using the API.

Answer 3

Yes, I've checked this file too, both have the same dbuser and dbpass but keep the same error. :-(

I'm still searching for a solution.

Answer 4

Great, searching for more log info, I've found this:

http://ask.ocsinventory-ng.org/7744/error-500-when-adding-software-to-the-inventory

Then I found this too:

https://github.com/OCSInventory-NG/OCSInventory-ocsreports/commit/8debb5318702b9adc91a0a5df6cf4a7a7ba6d92e#diff-c8757528cc2972f62bd8228450833705

So, I updated the table networks with the command:

ALTER TABLE `networks` ADD `MTU` VARCHAR(255) NULL DEFAULT NULL AFTER `SPEED`;

Now the machines (Linux or Windows) can send the inventories.

Cheers!