[BUG] Server HTTP status returns Forbidden on /ocsinventory

[pbyzkn]

OCS Inventory version
Version : 2.12.1
Server: Ubuntu 22.04.3 LTS

Describe the bug
Similarly to #1568, OCS server seems to respond with 403 Forbidden to every single request from the agents.
I tried removing all files and reinstalling the server. I've modified the z-ocsinventory-server.conf file with proper authentication credentials for the database, I were able to return different response code by modifying apache configuration file for a moment to single out the issue to OCS perl module.

I did not set up any password for OCS server. I'm not using SSL to communicate with the server.

It doesn't seem like OCS generates any log files after setting LOGLEVEL to true so I'm unable to say if there are any errors. I've verified log directory (/var/log/ocsinventory-server) permissions with the documentation for OCS and it matches, yet no files are being created.

I'm attaching installation log.

Apache error log:

[Wed Dec 27 09:33:05.984036 2023] [mpm_prefork:notice] [pid 167081] AH00170: caught SIGWINCH, shutting down gracefully
ocsinventory-server: Bad setting. `GENERATE_OCS_FILES_SNMP` is not set. Default: `0`
ocsinventory-server: Bad setting. `SCAN_TYPE_IPDISCOVER` is not set. Default: `ICMP`
ocsinventory-server: Bad setting. `SCAN_TYPE_SNMP` is not set. Default: `ICMP`
ocsinventory-server: Bad setting. `SCAN_ARP_BANDWIDTH` is not set. Default: `256`
ocsinventory-server: Bad setting. `IPDISCOVER_LINK_TAG_NETWORK` is not set. Default: `0`
ocsinventory-server: Can't load SOAP::Transport::HTTP* - Web service will be unavailable
ocsinventory-server: Bad setting. `GENERATE_OCS_FILES_SNMP` is not set. Default: `0`
ocsinventory-server: Bad setting. `SCAN_TYPE_SNMP` is not set. Default: `ICMP`
ocsinventory-server: Bad setting. `SCAN_TYPE_IPDISCOVER` is not set. Default: `ICMP`
ocsinventory-server: Bad setting. `IPDISCOVER_LINK_TAG_NETWORK` is not set. Default: `0`
ocsinventory-server: Bad setting. `SCAN_ARP_BANDWIDTH` is not set. Default: `256`
ocsinventory-server: Can't load SOAP::Transport::HTTP* - Web service will be unavailable
[Wed Dec 27 09:33:06.603718 2023] [mpm_prefork:notice] [pid 168336] AH00163: Apache/2.4.52 (Ubuntu) mod_perl/2.0.12 Perl/v5.34.0 configured -- resuming normal operations
[Wed Dec 27 09:33:06.603761 2023] [core:notice] [pid 168336] AH00094: Command line: '/usr/sbin/apache2'

Agent log:

Starting OCS Inventory Agent on Wednesday, December 27, 2023 10:35:36.
AGENT => Running OCS Inventory Agent Version 2.10.1.0
AGENT => Using OCS Inventory FrameWork Version 2.10.1.0
AGENT => Loading plug-in(s)
	DLL PLUGIN => Searching for Plug-in DLL(s) in folder <C:\Program Files\OCS Inventory Agent\plugins>
	DLL PLUGIN => 0 DLL Plug-in(s) successfully loaded on 0 DLL(s) found
AGENT => Using network connection with Communication Server
	COM PROVIDER => Loading Communication Provider <C:\Program Files\OCS Inventory Agent\ComHTTP.dll>
AGENT => Using Communication Provider <OCS Inventory cURL Communication Provider> Version <2.10.1.0>
AGENT => Sending Prolog
	DID_CHECK => Read DeviceID <devicename> and MACs <macaddress> in file <ocsinventory.dat>
	COM SERVER => Initializing cURL library for sendRequest
	COM SERVER => Using cURL without server authentication
	COM SERVER => Disabling cURL proxy support
	COM SERVER => Enabling cURL SSL server validation support using CA Bundle <C:\ProgramData\OCS Inventory NG\Agent\cacert.pem>
	COM SERVER => Sending HTTP Post request to URL <http://OCSSERVERIPADDRESS/ocsinventory>
	COM SERVER => HTTP Post response received <HTTP Status Code #403>
	COM SERVER => Cleaning cURL library
================= TRACE START ===============

================= TRACE STOP ===============
ERROR *** AGENT => Failed to send Prolog <HTTP Status Code #403>

To Reproduce
Execute agent send inventory action.

Expected behavior
Inventory gets sent and is accepted by the server and machine added to the device inventory.

Log file (optional)
ocs_server_setup.log

[pbyzkn]

This was caused by invalid apache config conflicting with other site. Sorry for the inconviencence. The way I were able to confirm this was by strace attaching to apache processes.

[gillesdubois]

No issues, glad you managed to fix your problem :)

Regards,
Gilles DUBOIS.