<HTTP Status Code #500> after update to 2.9.2

Question

Hi,

I updated the OCS server to the latest version (2.9.2) from previous version 2.4.
I also updated the client and everything seems to work but I get a HTTP 500 error when the client wants to connect:

Starting OCS Inventory Agent on Thursday, June 02, 2022 12:28:48.
AGENT => Running OCS Inventory Agent Version 2.9.2.0
AGENT => Using OCS Inventory FrameWork Version 2.9.2.0
AGENT => Loading plug-in(s)
AGENT => Using network connection with Communication Server
AGENT => Using Communication Provider <OCS Inventory cURL Communication Provider> Version <2.9.2.0>
AGENT => Sending Prolog
AGENT => Prolog successfully sent
AGENT => Inventory required
AGENT => Launching hardware and software checks
AGENT => Sending Inventory
INVENTORY => Inventory changed since last run
ERROR *** AGENT => Failed to send Inventory <HTTP Status Code #500>
AGENT =>  Communication Server asked for Package Download
DOWNLOAD => Download and setup tool successfully started
AGENT => Unloading communication provider
AGENT => Unloading plug-in(s)
AGENT => Execution duration: 00:00:09.

I understand that this error should normally be a wrong password but I checked
dbconfig details and the z-ocsinventory-server.conf and also the zz-ocsinventory-restapi.conf and all the credentials and passwords are fine.

So I have no idea why I get this error.
I can login in ocsreports and that seems to work fine.

Any idea? Thanks.

Answer 1

Thank you for the reply, I appreciate it.

Now I still have the following errors:

DBD::mysql::st execute failed: Column 'ID' in field list is ambiguous at /usr/local/share/perl5/Apache/Ocsinventory/Server/Capacities/Download.pm line 268.
DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /usr/local/share/perl5/Apache/Ocsinventory/Server/Capacities/Download.pm line 270.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Cache.pm line 77.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Cache.pm line 79.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Update.pm line 96.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Cache.pm line 77.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Cache.pm line 79.
DBD::mysql::db do failed: Table 'ocsweb.softwares' doesn't exist at /usr/local/share/perl5/Apache/Ocsinventory/Server/Inventory/Update.pm line 96.

I assume that I also have to create ocsweb.softwares like this?

CREATE TABLE `softwares_name_cache` (
  `ID` int NOT NULL AUTO_INCREMENT,
  `NAME` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `NAME` (`NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

...which I tried but still gives the same error.

Thank you

Answer 2

I reinstalled everything and I removed the database.

On my existing client I don't have have the error anymore:

==============================================================================
Starting OCS Inventory Agent on Monday, June 20, 2022 14:20:08.
AGENT => Running OCS Inventory Agent Version 2.9.2.0
AGENT => Using OCS Inventory FrameWork Version 2.9.2.0
AGENT => Loading plug-in(s)
AGENT => Using network connection with Communication Server
AGENT => Using Communication Provider <OCS Inventory cURL Communication Provider> Version <2.9.2.0>
AGENT => Sending Prolog
AGENT => Prolog successfully sent
AGENT => Inventory required
AGENT => Launching hardware and software checks
AGENT => Communication Server asks for IpDiscover
AGENT => Sending Inventory
INVENTORY => Inventory changed since last run
AGENT => Inventory successfully sent
AGENT =>  Communication Server asked for Package Download
AGENT => Unloading communication provider
AGENT => Unloading plug-in(s)
AGENT => Execution duration: 00:02:06.

But I have 2 other problems now:

1) I builded a package and it stays "waiting for notification".
Even if I fore a new sync from cli or the agent in the tray. The package is never downloaded or executed

2) Of course the ALL COMPUTERS is empty but it seems that the computers are making a connection with the ocs server but all fields are empty unless the field of my test computer with the agent 2.9.2 version. (don't know if that is the reason but an older agent should work also, right?).

Any idea to solve this?

Answer 3

After reinstalling, updating, posting questions and getting nowhere... we have decided to stop using OCS-NG and we will continue with GLPI.
OCS-NG looks like a good product but a product is only as good as the support and that is far from good enough, it's very poor. The forum has a lot of questions but a lot of them stay unanswered so then it stops of course.
Unfortunately, it is what it is.

Answer 4

I follow your questions, and I can see your approach about product.

- you upgrade version, but some tables are NOT upgraded or disappear : this is not OCS error

- you try downgrade php and you report error 500 on inventory (inventory use Perl not Php, as administration use Php : bad understanding

Myself I upgrade an 2.0.5 OCS installation for nearly 8k hardware : it was not obvious for example under 2.2, you need tu upgrade each version (starting from 2.2 there is SQL script for upgrade database schema). And OCS is a good product. (I upgraded up to 2.8.1 and not 2.9.2, due I test and it was not secure to do this big step.)

(One question : do you know that with GLPI 10, GLPI use an agent like OCS and not like FusionInventory ? = bad future for FusionInventory IMHO)

IMHO OCS is quite complex so it need reflexion to understand how it run ...

It's an OpenSource software with a forum, but you could buy support near FactorFX (Frankb are maybe from the company and give you good informations).

Understand how it run means read log, read source, try and listen : many time my first idea was false, many time I need to retry to analyse again ...

IMHO your research was not enough, your analysis was insufficient, your tries was reckless (why you database upgrade was not OK except you upgrade php to 8).

When I upgrade OCS, I also create a simple VM with a fresh install and database creation : I could compare each table, each columns, and look if it's a problem. That a secure approach of tries ...

My boss said : restart with a fresh database is NOT a solution, due the history in GLPI : somme GLPI ticket had a link to OCS hardware ! Some hardware use Windows and after years became on Linux : on OCS, we can see the existing OS and on GLPI it save all OS for a computer : difficult to understand !

Answer 5

Thanks for answering.
I did a complete new installation. Still the 500 error and the mysql credentials in all the files are correct I am sure of that.
Indeed I am not a programmer but installing a program on linux with all the step-by-step guides is not so hard and I do understand how everything is connected with each other.
There is probably a small error somewhere but I have no idea where and the support on this forum is poor. You can see that on a lot of other questions that are asked where there is no answer at all or no solution.

We installed GLPI 10 and we could install software directly from it so we will use that since OCS-NG is not possible anymore.

Installing software that already exists for a long time should not be so difficult and problem solving should be easier. This is not my fault.

My research was ok, upgrading a package is no rocket science or it shouldn't. I notice there is lack of information in the logfiles about the exact error. I work with multiple linux server packages and I never have a problem (for a long time) unless with OCS-NG.

It's too bad that it is not working for me anymore but that's how it is. I cannot put anymore energy in this.

Good luck, no hard feelings.

Answer 6

Never you give information about installation : it's mandatory : readers couldn't have ideas about your problem.

'I did a complete new installation. Still the 500 error' : you NEED to reconsider your method of installation ! (I am sure of that)

I write a tuto (for Debian 10/11) : using copy/paste with each line, it takes 20' to install OCS and there is no 500 error. Try ... and come back here to write result ...

Due the organisation (Perl + Php), it's quite difficult to install without a 'good tuto'

Your upgrade was incorrect because one table was not present : you never give an explanation, and it's not possible due the upgrade folder with sql script.

My own reflexion about upgrade is : you need to disconnect the server before upgrade, because the upgrade is done using php and inventory run Perl script for Inventory. My recommendation the best is : stop Apache, run directly sql script in command line, then restart Apache, so the upgrade of database as no impact. And this is NOT writen in official wiki. (for my OCS server, there is 7500 inventory each day, so it's really mandatory to not inventory during upgrade database : with this method, I did 2 upgrade with success, and keeping GLPI links ...). (Yes, I have some knowledge due I install my first linux host in 1994.)

When you don't have (enough) experience, wisdom recommends to have support ...

Answer 7

Indeed the error 500 is caused immediately when the default user credentials are changed as per the instructions on https://wiki.ocsinventory-ng.org/09.Extras/Secure-your-OCS-Inventory-NG-Server/. There are five lines mentioned where the ocs database users credentials are listed and can be manually changed, two of which appear to conflict with the other three.  

Unfortunately, like 99.999 % of  sysadmins, I am not a full-stack programmer so debugging a couple of hundred perl and php files when the answer might be in some unknowable database table is beyond me.   Support here consists mostly ignoring the question or posturing about how dumb the user must be if they can't work it out themself. If anyone really does know this product well and would like to explain an appropriate fix for the question OP asked I'd be glad to have it explained by a professional. 

The information on https://wiki.ocsinventory-ng.org/09.Extras/Secure-your-OCS-Inventory-NG-Server/  says to do the following.   This causes the error 500. 

db=ocsweb

SET PASSWORD FOR 'ocs'@'localhost' = PASSWORD ('ocsocsocsocs');

vi /usr/share/ocsinventory-reports/ocsreports/var.php ..

180 define('DFT_DB_CMPT', 'ocs');

181 define('DFT_DB_PSWD', 'ocsocsocsocs');

vi /etc/apache2/conf-available/z-ocsinventory-server.conf

31 PerlSetVar OCS_DB_PWD ocsocsocsocs

57 # PerlSetVar OCS_DB_SL_PWD ocsocsocsocs

vi /etc/ocsinventory-reports/dbconfig.inc.php

7 define("PSWD_BASE","ocsocsocsocs");

Restart apache2

Restart the database

Test on 2050

AGENT => Sending Prolog

ERROR *** AGENT => Failed to send Prolog <HTTP Status Code #500>

and this is just the password, no messing around with the actual user name.

Now I'm sure there's some simple explanation, but there are so many possibilities that looking for, and testing, every plausible option is too time consuming. This is exactly what (other) user support forums are supposed to be for. 

/rant? 

Answer 8

@cboff

An error 500 is generally a problem with MySQL/MariaDB account in z-ocsinventory-server.conf.

If you use 'ocs' as user, you have a message in ocsreports web interface, so you need to change user name : I recommend 'ocsuser'.

For changing password : SET PASSWORD FOR 'ocs'@'localhost = PASSWORD('newpas');

For create new user : GRANT ALL PRIVILEGES on *.ocsdb TO 'ocsuser'@'localhost' IDENTIFIED BY 'password'; (create user and give it privilege on database)

For applying without restart service : FLUSH PRIVILEGES;

When you change password or create a new user, you need to adjust config files :

- for ocsinventory : file /etc/apache/conf-available/z-ocsinventory-server.conf, lines OCS_DB_xxxx then restart Apache2

- ocsreports : file /usr/share/ocsinventory-reports/ocsreports/dbconfig.inc.php (may be var.php) then restart Apache2

I hope all of this instructions should be checked BEFORE asking about 500 error ...

Answer 9

@jacquesh 

As you can see from my initial comment, the instructions you gave have already been followed. This is because I did indeed check the documentation on the wiki and follow that procedure.

The problem still exists and the solution presented does not resolve it. 

Certainly a managed procedure from the web interface would remove the necessity to manually edit config files and be more controllable from the viewpoint of OCS support. 

I will reiterate what @versus has noted above.. 

• OCS-NG looks like a good product but a product is only as good as the support and that is far from good enough, it's very poor. The forum has a lot of questions but a lot of them stay unanswered so then it stops of course. Unfortunately, it is what it is.