You are not logged in.
Pages: 1
Hi everyone,
Only just started to evaluate GLPI 10.0.2 but struggling to get the remote inventory to work. According to the error I see the feature is not enabled on the server side but I can't find where this will need setting up. Any hint at what's wrong here is highly appreciated:
glpi-agent --logger=stderr --tasks remoteinventory --debug
[debug] Logger backend Stderr initialized
[debug] GLPI Agent (1.4-1)
[debug] Configuration directory: /etc/glpi-agent
[debug] Data directory: /usr/share/glpi-agent
[debug] Storage directory: /var/lib/glpi-agent
[debug] Lib directory: /usr/share/glpi-agent/lib
[debug] [target server0] Next server contact planned for Fri Aug 19 13:14:00 2022
[debug] Available tasks:
[debug] - Inventory: 1.12
[debug] - RemoteInventory: 1.0
[debug] target server0: server http://helpdesk/marketplace/glpiinventory
[debug] Planned tasks for server0: RemoteInventory
[debug] Build on Linux fv-az206-808 5.13.0-1031-azure 3720.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNULinux
[debug] Source time: 2022-07-01 09:32:14 UTC
[debug] Running in foreground mode
[info] target server0: server http://helpdesk/marketplace/glpiinventory
[debug] [http client] EAE97CA1: Using Compress::Zlib for compression
[info] sending contact request to server0
[debug] server message: remoteinventory task not supported
[debug] [http client] Using Compress::Zlib for compression
[info] sending prolog request to server0
[debug] Skipping remote inventory task execution for 10.100.33.111-2022-08-18-11-42-48: Can't run simple command on remote, check server is up and ssh access is setup
[debug] Remote inventory task execution disabled: all 1 remotes are failing
Last edited by GuidoLondon (2022-08-18 17:17:27)
Full time system engineer, part time human being.
Offline
Hi @GuidoLondon,
the only interesting thing here are the following lines:
[debug] Skipping remote inventory task execution for 10.100.33.111-2022-08-18-11-42-48: Can't run simple command on remote, check server is up and ssh access is setup
[debug] Remote inventory task execution disabled: all 1 remotes are failing
With them, I can assume you used glpi-remote command to setup a ssh access to 10.100.33.111. Anyway it seems to fail there for some reason. You can try to add one more "--debug" option to enable debug2 level and you should see why it really fails at the moment.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
Thank you for getting back to me. We currently suspect the firewall being the root cause of the problem. If I increase the logging we get the following:
glpi-agent --logger=stderr --tasks remoteinventory --debug --debug
[debug] Logger backend Stderr initialized
[debug] GLPI Agent (1.4-1)
[debug] Configuration directory: /etc/glpi-agent
[debug] Data directory: /usr/share/glpi-agent
[debug] Storage directory: /var/lib/glpi-agent
[debug] Lib directory: /usr/share/glpi-agent/lib
[debug] [target server0] Next server contact planned for Fri Aug 19 16:31:17 2022
[debug2] getAvailableTasks() : add of task Inventory version 1.12
[debug2] getAvailableTasks() : add of task RemoteInventory version 1.0
[debug2] Preparing execution plan
[debug] Available tasks:
[debug] - Inventory: 1.12
[debug] - RemoteInventory: 1.0
[debug] target server0: server http://helpdesk/marketplace/glpiinventory
[debug] Planned tasks for server0: RemoteInventory
[debug] Build on Linux fv-az206-808 5.13.0-1031-azure 3720.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNULinux
[debug] Source time: 2022-07-01 09:32:14 UTC
[debug] Running in foreground mode
[info] target server0: server http://helpdesk/marketplace/glpiinventory
[debug] [http client] 4F4741BB: Using Compress::Zlib for compression
[info] sending contact request to server0
[debug2] [http client] 4F4741BB: sending message:
{
"action": "contact",
"deviceid": "helpdesk.co3m.local-2022-08-18-11-30-25",
"enabled-tasks": [
"remoteinventory"
],
"installed-tasks": [
"inventory",
"remoteinventory"
],
"name": "GLPI-Agent",
"version": "1.4-1"
}
[debug2] format: Zlib
[debug2] [http client] 4F4741BB: received message:
{"message":"remoteinventory task not supported","disabled":["remoteinventory"],"expiration":24,"status":"ok"}
[debug] server message: remoteinventory task not supported
[debug] [http client] Using Compress::Zlib for compression
[info] sending prolog request to server0
[debug2] [http client] sending message:
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<DEVICEID>helpdesk.co3m.local-2022-08-18-11-30-25</DEVICEID>
<QUERY>PROLOG</QUERY>
<TOKEN>12345678</TOKEN>
</REQUEST>
[debug2] format: Zlib
[debug2] [http client] receiving message:
<?xml version="1.0"?>
<REPLY><PROLOG_FREQ>24</PROLOG_FREQ><RESPONSE>SEND</RESPONSE></REPLY>
[debug2] executing ssh -q -o BatchMode=yes -l root 10.100.33.111 LANG=C id -u
[debug] Skipping remote inventory task execution for 10.100.33.111-2022-08-18-11-42-48: Can't run simple command on remote, check server is up and ssh access is setup
[debug] Remote inventory task execution disabled: all 1 remotes are failing
Last edited by GuidoLondon (2022-08-19 13:34:53)
Full time system engineer, part time human being.
Offline
How did you setup authentication for root on 10.100.33.111 ? with password or public authentication ? or what ?
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Yes with password. Very simple and basic to begin with.
Full time system engineer, part time human being.
Offline
Hi @gbougard,
I revisited this once more but still can't get any further. I simplified my setup as much as possible yet everything I try immediately fails with
Can't run simple command on remote, check server is up and ssh access is setup
Am I maybe missing something in the general setup or should this just work? Is the problem maybe that I'm using root as the account on the remote machine?
To maybe add some more context: I'm running the server and the agent on the same VM. Is this where I'm going wrong?
Any hint is highly appreciated
Last edited by GuidoLondon (2022-10-03 15:21:26)
Full time system engineer, part time human being.
Offline
Hi GuidoLondon,
can you try with a nightly build as there were some fixes since 1.4 around remoteinventory task ?
You are maybe just triggering a currently fixed issue.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
Thank you, I tried the latest nightly build (glpi-agent-1.5-git8a054db4-linux-installer.pl) but still no luck I'm afraid.
Full time system engineer, part time human being.
Offline
Are able to run yourself the simple command:
ssh -l root 10.100.33.111 id -u
Eventually add "-v" option just after "ssh" to have more diagnostic if it fails.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
As I said: I simplified my test setup with both the machine running the agent and the target machine being on the same VLAN so the IP has changed compared to my first test.
Here the output from both commands.
ssh -l root 10.26.2.175 id -u
root@10.26.2.175's password:
0
ssh -v -l root 10.26.2.175 id -u
OpenSSH_8.0p1, OpenSSL 1.1.1k FIPS 25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 10.26.2.175 [10.26.2.175] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.26.2.175:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:OgPGlhfoi8rEPSuKm9Snz1/erqjdwnJNXRV7og0mpwk
debug1: Host '10.26.2.175' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,hostbased
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_xmss
debug1: Next authentication method: password
root@10.26.2.175's password:
debug1: Authentication succeeded (password).
Authenticated to 10.26.2.175 ([10.26.2.175]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: id -u
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1900, received 2292 bytes, in 0.2 seconds
Bytes per second: sent 8935.4, received 10778.9
debug1: Exit status 0
Last edited by GuidoLondon (2022-10-10 16:25:40)
Full time system engineer, part time human being.
Offline
Hi @gbougard,
We installed the latest nightly build (v1.5-git53160126) but the error is still the same:
Can't run simple command on remote, check server is up and ssh access is setup
Full time system engineer, part time human being.
Offline
Hi GuidoLondon,
we probably missed a point... "ssh -q -o BatchMode=yes -l root 10.100.33.111 LANG=C id -u" won't work with password authentication. Password authentication requires libssh2 support on the system. I guess you're using redhat or centos based system which are known to not support libssh2. But you can try to use packages provided by the ligenix unofficial-repository.
Or you can try to configure ssh key-based authentication (which is more secure anyway) or switch to a debian/ubuntu based system.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
Thank you setting up key-based authentication between my two test hosts did the trick.
Thank you for your help
Full time system engineer, part time human being.
Offline
Nice.
Anyway, just for your information, libssh2 if far more performant than running a lot of ssh commands.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
Thank you for the hint re ligenix.
My question here: does this only need to be installed on the machine running the agent or is this required on each machine we want to add to the inventory?
Full time system engineer, part time human being.
Offline
This is only required on the agent which runs the remoteinventory task.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
That's good news. I will test this and report back.
Full time system engineer, part time human being.
Offline
Hi @gbougard,
So after a long break I finally found some time to do some more tests and have the remote inventory working now.
I rebuilt the server based on Ubuntu 22.04 and the remote inventory works now, however a couple of things still do not seem correct.
1. Since our company is fairly big with several offices I set up a root entity (company name) and underneath that one child entity for now (LDN = London office).
When running an inventory everything gets associated to the root entity. Is this something that can be configured on agent level or will this always be a post task (associating assets to the correct entity)?
2. As the inventory will grow very big is it advisable to run the agent on a dedicated machine or maybe even several agent machines or should one agent running alongside the server suffice?
Thank you for any hint here.
Full time system engineer, part time human being.
Offline
Hi GuidoLondon,
glad to see you didn't forgive and had it working.
For the first point, there's a dedicated engine for entity allocation in GLPI: you define a tag during the inventory and you'll have to create "Rules for assigning an item to an entity" rule to reach your goal. See the "Rules" section in "Administration" panel.
For the second point, you'll have to monitor your agent and the workload on the system it runs. One remote inventory can take time to be achieved but this can depends on a lot of parameters. For a big network, you should anyway dedicate few machines to share the workload and to avoid any bottleneck. One important point, GLPI-Agent 1.4 uses only one thread for remote inventory. With current nightly build, you can use more threads so this is handy for your kind of need.
GLPI-Agent developer from Teclib' and GLPI-Network team
Previously FusionInventory-Agent maintainer
Offline
Hi @gbougard,
Thank you once more for your help. I managed to get the entity association to work. Much simpler than I feared.
I did however run into a problem. I'm running GLPI 10.0.6 and the latest GLPI Agent build (1.5-git8529f898) and for one of the machines I'm pulling in I get seven line entries. It seems to pull in single components as separate computers.
I have the main computer (Dell R430) plus apcore-auth-swagger, apsearch-swagger and so on pulled in as additional computers.
Any idea what might be triggering this?
Last edited by GuidoLondon (2023-03-10 17:54:25)
Full time system engineer, part time human being.
Offline
Pages: 1