Topic: bizaar behaviour from REMI ocsinventory server.

hello folks,

I'm having a problem with the latest ocsinventory-server packages from here. (2.1.1)


All of the latest remi ocsinventory pages are installed:

ocsinventory-server-2.1.1-1.el6.remi.noarch
ocsinventory-reports-2.1.1-1.el6.remi.noarch
ocsinventory-2.1.1-1.el6.remi.noarch
ocsinventory-agent-2.1.1-1.el6.remi.x86_64

so 2.1.1 across the board.  The ocsreports is working perfectly.


However, none of the 2.1.1 agents work.  they return bad request 400 errors in the server error log.

In the ocsinventory-server activity log I see this:

Wed Jun 25 18:47:16 2014;3870;400;android-acf149ea8d5a7282-2014-06-13-18-42-54;130.95.27.232;OCS-NG_Android_agent_v2.1;useragent;Bad agent or agent version $
Wed Jun 25 18:47:16 2014;3870;106;android-acf149ea8d5a7282-2014-06-13-18-42-54;130.95.27.232;OCS-NG_Android_agent_v2.1;prolog;stopped by module
Wed Jun 25 18:47:16 2014;3870;515;android-acf149ea8d5a7282-2014-06-13-18-42-54;130.95.27.232;OCS-NG_Android_agent_v2.1;end;bad_request

That was the v2.1 android agent I was testing with.

The actual remi agent 2.1.1 seems to be getting identified by ocsserver as newer than 2.1.1


Wed Jun 25 19:02:14 2014;3859;400;druggat-2014-04-04-15-18-05;130.95.4.101;OCS-NG_unified_unix_agent_v2.1.1;useragent;Bad agent or agent version too recent for server !!
Wed Jun 25 19:02:14 2014;3859;106;druggat-2014-04-04-15-18-05;130.95.4.101;OCS-NG_unified_unix_agent_v2.1.1;prolog;stopped by module
Wed Jun 25 19:02:14 2014;3859;515;druggat-2014-04-04-15-18-05;130.95.4.101;OCS-NG_unified_unix_agent_v2.1.1;end;bad_request
Wed Jun 25 19:02:36 2014;3872;400;altarian-2014-06-25-16-50-53;130.95.4.131;OCS-NG_unified_unix_agent_v2.1.1;useragent;Bad agent or agent version too recent

but the older agents are still working fine:
Wed Jun 25 19:03:36 2014;3862;100;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;prolog;accepted
Wed Jun 25 19:03:36 2014;3862;311;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;session;started
Wed Jun 25 19:04:04 2014;3861;319;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;session;found
Wed Jun 25 19:04:04 2014;3861;104;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;inventory;incoming
Wed Jun 25 19:04:04 2014;3861;113;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;inventory;u:drives
Wed Jun 25 19:04:04 2014;3861;320;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;session;end
Wed Jun 25 19:04:04 2014;3861;101;WIN2008ENT-2014-04-04-15-36-55;130.95.4.82;OCS-NG_WINDOWS_AGENT_v2.0.5.0;inventory;transmitted


I thought this might be some old legacy from the upgrade.. so I blew it all away and installed from scratch and I'm getting the same issue. (only kept the old database as it has lots of work in it.)

What could be causing this error?

Any help would be much appreciated.

regards

Frank

Re: bizaar behaviour from REMI ocsinventory server.

Strange:

Wed Jun 25 11:01:02 2014;1835;100;schrodingerscat-2014-02-13-14-48-51;127.0.0.1;OCS-NG_unified_unix_agent_v2.1.1;prolog;accepted
Wed Jun 25 11:01:02 2014;1835;314;schrodingerscat-2014-02-13-14-48-51;127.0.0.1;OCS-NG_unified_unix_agent_v2.1.1;session;clean(check)
Wed Jun 25 11:01:02 2014;1835;311;schrodingerscat-2014-02-13-14-48-51;127.0.0.1;OCS-NG_unified_unix_agent_v2.1.1;session;started
...
Wed Jun 25 11:01:35 2014;1840;320;schrodingerscat-2014-02-13-14-48-51;127.0.0.1;OCS-NG_unified_unix_agent_v2.1.1;session;end
Wed Jun 25 11:01:35 2014;1840;101;schrodingerscat-2014-02-13-14-48-51;127.0.0.1;OCS-NG_unified_unix_agent_v2.1.1;inventory;transmitted
Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: bizaar behaviour from REMI ocsinventory server.

Weird.... I completely removed one of the agents from a linux machine and removed any and all references to ocsinventory.. then reinstalled from scratch and reconfigured it... same problem... so it must be something in the ocsinventory-server database that is causing the issue since other than that it's a completely clean install too.

very odd...  I've just created an account on the ocsinventory forum and I'll ask if they have seen this before.. nothing on their forum shows up in searches.

Re: bizaar behaviour from REMI ocsinventory server.

ok. turns out it was a duplicate Ocsinventory.pm from the original imagine in the path but in a different location to the one installed by Remi's package.. naturally apache picked the wrong one and ran with it. deleting that file and restarting apache solved the problem.

big thankyou to Remi for helping me on the IRC channel!

Re: bizaar behaviour from REMI ocsinventory server.

smile

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi