g-bougard
commented
2 months ago Hello @erique-souza
first of all, I see in your issue more a support request than a real agent issue. You're speaking about 20000 agents trying to submit requests to one proxy agent. This is definitively not a context for which this feature was developed. I see also few big mistakes in the proxy configuration showing you didn't understood few basic principles.
For example, you changed max_pass_through to 10000 and this has no sens: it means you permited to chain until 10000 glpi-agent proxies which seems very far from your real configuration. The default limitation of 5 is here to prevent wrong configuration in the case you not intentionally chained together 2 glpi-agent proxies in a loop. With your configuration, this case will result into a loop of 5000 requests between the 2 chain-together agents. Also setting max_proxy_threads to 10000 will probably exhaust your OS resources until make the proxy agent unresponsive.
So I'll first move your issue as a discussion before fully continuing.
Bug reporting acknowledgment
Yes, I read it
Professional support
Still not applicable
Describe the bug
I have a scenario with a park of approximately 20 thousand assets that have glpi-agent installed, these agents are installed and pointing to a proxy server using the glpi-agent native proxy plugin, but from what we noticed after some analysis it is that even with a relatively high inventory frequency, which is currently 168 hours (7 days), there are a lot of requests in a short space of time, I believe that as a result the proxy's ssl service ends up falling, that is, becoming inoperative
As the proxy plugin does not have a more extensive configuration module as is the case with conventional web services such as apache, ngnix, etc.. I tested some configurations of the proxy plugin itself to try to minimize requests as well as increase the inventory frequency. , using the documentation at https://glpi-agent.readthedocs.io/en/latest/plugins/proxy-server-plugin.html as a basis
Also change the maxrate together with maxrate_period to a very high number Change it so that instead of being the active proxy that receives the inventory and then forwards it, it is passive that receives the inventory and stores it internally in a folder, using the only_local_store = yes and local_store = /inventario function
And even testing for very high numbers max_proxy_threads = 10000 and max_pass_through = 10000
However, it seems that none of these measures have yet been able to solve the problem we are facing, which is: The Proxy Server Going Offline in its web version, on port 443, with SSL everything correctly active
Doing this when an agent is trying to communicate, many times, the vast majority of the time they are unable to do their inventory
I am attaching the log from the proxy side below, because in the proxy the requests are registered and some manage to execute as expected, which are the few that manage to communicate and record their file, and the vast majority end up being rejected from their inventory, with the error messages
[ssl server plugin] HTTPD can't start SSL session: Failed to upgrade socket to SSL: SSL wants a read first [http server] HTTPD can't start SSL session
I am also sending below the proxy settings and also the ssl configuration on the proxy for analysis
glpi-agent.log
proxy_server_conf.txt
ssl_conf.txt
To reproduce
Expected behavior
Device inventory locally on the proxy
Operating system
Linux
GLPI Agent version
v1.11
GLPI version
Not applicable
GLPIInventory plugin or other plugin version
Not applicable
Additional context
No response