Bug#1041489: ocsinventory-reports: version inconsistency between GUI and perl libraries

[Krzysztof Jastrzębski]

Package: ocsinventory-reports
Version: 2.8.1+dfsg1+~2.11.1-1
Severity: important

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
ii ocsinventory-reports 2.8.1+dfsg1+~2.11.1-1
ii ocsinventory-server 2.8.1+dfsg1+~2.11.1-1

grep GUI_VER /usr/share/ocsinventory-reports/var.php
define('GUI_VER', '7069');
define('GUI_VER_SHOW', '2.11.1');

But perl libraries left in 2.8.1:
grep "Ocsinventory::VERSION" /usr/share/perl5/Apache/Ocsinventory.pm
$Apache::Ocsinventory::VERSION = '2.8.1';

In upstream sources
(https://github.com/OCSInventory-NG/OCSInventory-ocsreports/releases/download/2.11.1/OCSNG_UNIX_SERVER-2.11.1.tar.gz)
this libraries are the same versions as GUI:
grep "Ocsinventory::VERSION"
/tmp/OCSNG_UNIX_SERVER-2.11.1/Apache/Ocsinventory.pm
$Apache::Ocsinventory::VERSION = '2.11.1';

After upgrade from bullseye to bookworm, ocsinventory-reports upgrades
database:
Existing database updated
Current version:7039=>Expected version:7069

This causes many errors during updates by agents and during inventory with:
/ocsreports/index.php?function=admin_dico; function=soft_cat; and
probably more.

For example CATEGORY field was migrated in 7045:
grep -a1 "DROP CATEGORY"
/usr/share/ocsinventory-reports/files/update/7045.sql
-- DROP CATEGORY column from software_name
ALTER TABLE `software_name` DROP COLUMN `CATEGORY

But old (2.8.1) function uses it:
grep software_name
/usr/share/perl5/Apache/Ocsinventory/Server/Inventory/Software.pm
_insert_software_name
sub _insert_software_name {
$sql = "SELECT ID, CATEGORY FROM software_name WHERE NAME = ?";
$sql = "INSERT INTO software_name (NAME) VALUES(?)";
$sql = "INSERT INTO software_name (NAME,CATEGORY) VALUES(?,?)";
$sql = "SELECT ID FROM software_name WHERE NAME = ?";
my $sqlUpdate = "UPDATE software_name SET CATEGORY = ?
WHERE ID = ?";
$arrayValue{NAME_ID} = _insert_software_name($name,
$software->{CATEGORY});

Upstream sources are completely rewritten:
grep software_name
/tmp/OCSNG_UNIX_SERVER-2.11.1/Apache/Ocsinventory/Server/Inventory/Software.pm
$arrayValue{NAME_ID} = _get_info_software($name,
"software_name", "NAME");

This makes the 2.8.1+dfsg1+~2.11.1-1 package useless and I am not sure
if after the activity of the agents the database was not disintegrated
and does not need to be restored from the backup.

--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

[Krzysztof Jastrzębski]

W dniu 19.07.2023 o 18:27, Krzysztof Jastrzębski pisze:

> Package: ocsinventory-reports
> Version: 2.8.1+dfsg1+~2.11.1-1
> Severity: important

[...]

> This makes the 2.8.1+dfsg1+~2.11.1-1 package useless and I am not sure
> if after the activity of the agents the database was not disintegrated
> and does not need to be restored from the backup.

I can confirm that inconsistency between ocsinventory-server and
ocsinventory-reports perl libraries versions, completely disintegrates
database, after first GUI use and first inventory done by agent.
First step is a2disconf ocsinventory-*.conf, comment out the crontabs on
all agents and save the last good database dump for later recovery.
Final one, is maybe to purge server and reports packages and install
from upstream source (2.12.0 has some PHP8 fixes; perl libs go to
/usr/local).
Restoring database from last good backup is necessary.

[Meik Hellmund]

I can confirm bugs #1037473 and #1041489

The following worked for me:

- install the ocsinventory 2.12.0 deb packages provided by the ocsinventory team as described here:
http://wiki.ocsinventory-ng.org/03.Basic-documentation/Setting-up-a-OCS-Inventory-Server-with-rpm/#install-ocs-inventory-server-with-apt
- cp /etc/ocsinventory/dbconfig.inc.php /etc/ocsinventory-reports/
- chown www-data:www-data /var/lib/ocsinventory-reports
- edit ocsinventory files in /etc/apache2/sites-enabled/z-* and correct user/pw for mariadb access
- go to your ocsreports webpage and let it upgrade the db structure



--
Meik Hellmund
Mathematisches Institut, Uni Leipzig