Open nbriche opened 6 years ago
nbriche
commented
6 years ago It just occurred to me that using the IP is not necessarily a good idea. In DHCP environments, if the client has been shut down for longer than its lease's TTL, it will (probably) get a new IP on the next boot.
That IP will admittedly be updated in FusionInventory on the next round, but not having to rely on IP addresses is what DNS is for in the first place.
ddurieux
commented
6 years ago Ok, so need add an option to define the information to wake up the agent:
nbriche
commented
6 years ago After looking deeper into it, I found that the problem isn't quite what I thought it was. The existing code already looks up for hostname, FQDN and IP for agent awakening; which made me wonder what was going on.
It turns out that the culprit is (probably) the way GLPI is structured here: an HAProxy fronting two GLPI webservers. The default behavior for a FI client is to not trust anyone but itself and the control server. But here, the client only knows the HAProxy's IP, not the web backends that actually do the controlling. I've added the hostnames for the two web backends to httpd-trust on one client and it seems to do the trick. I'll update my GPO to update all the other clients and report the results.
On a computer's form, FusionInventory displays the computer's agent URL. That URL seems to be used to force an inventory from the server. Unfortunately, that URL is constructed from the hostname, not the FQDN. In a multiple-domains configuration, if the GLPI server is not in the same DNS domain as the computer, forcing the inventory fails (agent unreacheable). Since the contact IP is also displayed, the server should either: 1) Make a rDNS request to construct the URL with the FQDN (although it seems to be included in the XML, so, yeah) 2) Use the IP address to force an inventory.
We're not yet at the point where we can test tasks and package deployments, but this issue may well be present in that part too. We'll see.