Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.12.3 available

The official documentation can be found on http://wiki.ocsinventory-ng.org. Read it before asking your question.

Local Import = Error HTTP/1.1 400 Bad Request

Hi everyone,

after upgrading my OCS server to the v2.3.1 on a Debian Jessie server, I cannot make any local import since the management console, I obtain the error "HTTP / 1.1 Error 400 Bad Request" while the agents inventories do well.

  • In the OCS activity.log, there is no error message.
  • In the Apache access.log, I found this :

10.75.x.x - - [29/Mar/2017:10:26:23 +0200] "GET /ocsreports/index.php?function=admin_local_import HTTP/1.1" 200 3103 "http://ocsserver/ocsreports/index.php?function=admin_logs" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) $
::1 - - [29/Mar/2017:10:26:27 +0200] "POST /ocsinventory HTTP/1.1" 400 0 "-" "-"
10.75.x.x - - [29/Mar/2017:10:26:27 +0200] "POST /ocsreports/index.php?function=admin_local_import HTTP/1.1" 200 3171 "http://ocsserver/ocsreports/index.php?function=admin_local_import" "Mozilla/5.0 (Windows NT 10.0; Win$
::1 - - [29/Mar/2017:10:26:28 +0200] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) mod_perl/2.0.9dev Perl/v5.20.2 (internal dummy connection)"
::1 - - [29/Mar/2017:10:26:35 +0200] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.10 (Debian) mod_perl/2.0.9dev Perl/v5.20.2 (internal dummy connection)"

  • In the Apache error.log, I have this :

[Wed Mar 29 10:25:20.995195 2017] [mpm_prefork:notice] [pid 15489] AH00169: caught SIGTERM, shutting down
ocsinventory-server: Can't load SOAP::Transport::HTTP* - Web service will be unavailable
ocsinventory-server: Can't load SOAP::Transport::HTTP* - Web service will be unavailable
[Wed Mar 29 10:25:22.817099 2017] [mpm_prefork:notice] [pid 15593] AH00163: Apache/2.4.10 (Debian) mod_perl/2.0.9dev Perl/v5.20.2 configured -- resuming normal operations
[Wed Mar 29 10:25:22.817163 2017] [core:notice] [pid 15593] AH00094: Command line: '/usr/sbin/apache2'

Do you know where from it comes ?

We have several local inventories to be imported and that becomes annoying... :/

Thank you for your help,

Yann

in Administrative console by (460 points)

12 Answers

0 votes

Hey Yann,

Saw your post in the other Local Import ERROR thread.  There are a few things to check: 

- Verify that nothing changed in the config for your LOCAL_URI_SERVER setting.  It should be set to "By default (http://localhost:80/ocsinventory)".  I believe your "internal dummy" connections in the log you posted may cause this to happen.

- Check your configuration settings in the /etc/apache2/*.conf files.

This is a starting point for things to check.  I can't exactly tell by what you posted what the cause of your issue could be.

Questions for you - What OCS server version did you upgrade from?  Did you do any other changes along with the upgrade (i.e upgrade Apache, change IP / DNS, change access to the server (http/https/other port))?

by (310 points)
0 votes

Hi Vinman and Vincent_n, thank you for your answers.

@vinman : first of all, my LOCAL_URI_SERVER seems to be correctly parametrized : "default (http://localhost:80/ocsinventory)", is there a way to test localy if the URL work ? (I'm not a Debian/Linux specialist)

For the conf files, there is the differences between 2.3.1 and 2.2 z-ocsinventory-server.conf files :

# diff /etc/apache2/conf-enabled/z-ocsinventory-server.conf z-ocsinventory-server.conf.20170308backup
52c52
<   PerlSetEnv OCS_OPT_DBI_PRINT_ERROR 1
---
>   PerlSetEnv OCS_OPT_DBI_PRINT_ERROR 0
90,91d89
<   # Specify if agent take contact on service startup
<   PerlSetEnv OCS_OPT_INVENTORY_ON_STARTUP 0
314c312
<   <Location /ocsplugins>
---
>   <Location /plugins>

There is no differences between 2.3.1 and 2.2 ocsinventory-reports.conf files.

Originally I've upgraded of the version 2.2 towards 2.3 then 2.3.1 a few days later. In 2.2.1 everything worked correctly but I did not have to test the local import in 2.3 before updating in 2.3.1 

@ vincent_n : Yes, I've already seen this post and no, I don't have any errors on optional dependences except that concerning Apache2::SOAP, take a look :

+----------------------------------------------------------+
| Checking for required Perl Modules...                    |
+----------------------------------------------------------+

Checking for DBI PERL module...
Found that PERL module DBI is available.
Checking for Apache::DBI PERL module...
Found that PERL module Apache::DBI is available.
Checking for DBD::mysql PERL module...
Found that PERL module DBD::mysql is available.
Checking for Compress::Zlib PERL module...
Found that PERL module Compress::Zlib is available.
Checking for XML::Simple PERL module...
Found that PERL module XML::Simple is available.
Checking for Net::IP PERL module...
Found that PERL module Net::IP is available.
Checking for SOAP::Lite Perl module...
Found that PERL module SOAP::Lite is available.
Checking for Archive::Zip Perl module...
Found that PERL module Archive::Zip is available.

+----------------------------------------------------------+
|         Checking for optional Perl Modules...            |
+----------------------------------------------------------+

Checking for Apache2::SOAP PERL module...
*** Warning: PERL module Apache2::SOAP is not installed !
This module is only required by OCS Inventory NG SOAP Web Service.
Do you wish to continue ([y]/n] ?y
Checking for XML::Entities PERL module...
Found that PERL module XML::Entities is available.
by (460 points)
edited by
0 votes

Yannc,

I think we have 2 separate problems.  The "Can't load SOAP::Transport::HTTP*" messages in the error log should not have anything to do with the inability to perform a local inventory upload.  Looking at the access log, the "::1" and "10.75.x.x" messages suggests your server is using ipv4 and ipv6.  Is there a possibility that ipv6 is causing an issue with your local imports?  You could temporarily disable it and retry the import.

Aside from what I see in the logs above, you may need to look deeper.  Check your /var/log files for corresponding time stamp messages that may help in solving the issue.

Hope this helps.

Vinman  

by (310 points)
0 votes
Hi vinman,

I have nothing concerning my problem in any logs into my /var/log folder :(

For the "Can't load SOAP::Transport::HTTP*", it's ok, I've found the solution yesterday, sorry : installing SOAP::Transport::HTTP2.

For IPv6, I've just made a test, unsuccessfully.
by (460 points)
0 votes
Hi,

someone has an idea, please ?
by (460 points)
0 votes
Hi,

From which version have you upgraded?

Regards, Frank
by (89.1k points)
0 votes
Hi frankb,

I've upgraded from 2.2 or 2.2.1 to 2.3 before the latest 2.3.1.

I don't have the problem when I was in 2.2 (or 2.2.1) and I don't import local inventory when I was in 2.3 so I don't know if the local import is broken since the 2.2 > 2.3 upgrade or the 2.3 > 2.3.1 upgrade.

For information, I made reinstallation after renaming all the ocs folder (I don't remember how many, sorry)... Unfortunately, the problem is still here.

So, the only things I don't touch at this time is the database, maybe we can search this way ?
by (460 points)
0 votes
Hello

I am in the same basket.

I upgrade from release 2.1.2 to 2.3.1 and now the local import does not run.

THe database was translated during the process.

What I tested too is the manual import : and this one is OK, we can found the record in the database.

so I do not think that database is the way to follow.

But where is the solution ?
by (220 points)
0 votes
Hello again,

A tip to continue to use ocs wihtout the Local import.

I used the injector script supplied with the server directly on it and it rans fine.

One good news : it can import many files at a time.

in my example the ocs files are in the mnt/nas/SUIVI/OCS directory

root@Sxxx:/home/sxxxx/tmp/OCSNG_UNIX_SERVER-2.3.1/binutils# perl ./ocsinventory-injector.pl --url http://localhost/ocsinventory -d /mnt/nas/SUIVI/OCS
by (220 points)
 
Powered by Question2Answer
...