Client über config editor nicht erreichbar

[larsg]

Hallo,

ich habe ein Problem mit einem unserer Test-Rechner:

Der Rechner lässt sich nicht über den config editor anpingen, und ausführen von Aktionen "on_demand" laufen in einen Timeout.
In der Spalte "Session Informationen" steht "no response timed out".
Der opsi-client-agent läuft mit Version 4.0.5.4, wurde auch mehrfach neu installiert, nachdem der Client im config editor gelöscht wurde.
Die Windows-Firewall ist aktiviert mit einer Ausnahme für eingehende Verbindungen auf TCP/4441 (wird offenbar vom Setup automatisch konfiguriert)
Der Rechner lässt sich sowohl von anderen PC's als auch vom Depot-Server aus anpingen, ich komme mit psexec auf den Rechner, es gibt auch keinerlei sonstigen Zugriffsprobleme von dem Rechner / zu dem Rechner.
Das Problem tritt bislang nur an diesem einen PC auf, HW/SW-Konstellation ist weitgehend identisch zu anderen PC's, bei denen das Problem nicht auftritt.

Wird der Rechner neugestartet, dann werden die angeforderten Aktionen ohne Probleme ausgeführt.

Die Ausgabe von opsi-deploy-client-agent (test-client.local ist der betroffene Rechner; sah auch bis jetzt bei allen anderen Rechnern genau so aus):

Code: Alles auswählen

No translation for property 'COMPUTER_SYSTEM.sku' found
Starting deployment to host 'test-client.local'
Querying for ip address of host 'test-client.local'
Got ip address '192.168.1.21' from syscall
Pinging host 192.168.1.21 ...
Host 192.168.1.21 is up
Getting hardware ethernet address of host 'test-client.local'
Failed to get hardware ethernet address for IP 192.168.1.21
Creating client 'test-client.local'
Testing winexe
Patching config.ini
Copying installation files
Installing opsi-client-agent
opsi-client-agent successfully installed on 'test-client.local'

Im Log opsiconfd finde ich immer wieder diesen Eintrag:

Code: Alles auswählen

[4] [Jul 06 14:06:48] Failed to set rights for path '/var/lib/opsi/config/clients/test-client.local.ini': [Errno 1] Operation not permitted: '/var/lib/opsi/config/clients/test-client.local.ini' (File.py|284)

Da diese Meldung für keinen anderen Rechner kommt, liegt ein Zusammenhang auf der Hand.
Nachdem ich gestern opsi-set-rights ausgeführt hab, kommt die Meldung nicht mehr - Rechner ist jedoch nach wie vor nicht via config editor erreichbar.

Ich muss unbedingt wissen warum dieses Problem auftritt, wir planen einen großen Rollout mit OPSI, und solche Überraschungen haben da keinen Platz. Mir sind die Ideen ausgegangen wo ich weiter ansetzen könnte, und hoffe daher das hier jemand eine Idee hat.

[n.wenselowski]

Hallo,

der Server kann den Client nicht erreichen.
Zur Konfiguration mal ins Getting Started schauen. Da muss das Auflösen der IP vermutlich anders geregelt werden.

Bei großen Rollouts im Firmenumfeld ist es nie schlecht einen Supportvertrag zu haben


Gruß

Niko

[larsg]

Danke für die Antwort, und sorry wenn ich widersprechen muss, aber der Rechner ist sehr wohl vom server aus erreichbar -
per ping sowohl via IP als auch via DNS - nur nicht via config editor, oder opsi-admin.

Ich denke es handelt sich hierbei nur um ein Konfigurationsproblem - der Rollout an sich bereitet mir aktuell noch keine Kopfschmerzen.

Code: Alles auswählen

adminuser@opsi-depotserver:/var/lib/opsi> ping test-client.local
PING test-client.local (192.168.1.21) 56(84) bytes of data.
64 bytes from 192.168.1.21: icmp_seq=1 ttl=127 time=0.274 ms
64 bytes from 192.168.1.21: icmp_seq=2 ttl=127 time=0.298 ms
64 bytes from 192.168.1.21: icmp_seq=3 ttl=127 time=0.364 ms
64 bytes from 192.168.1.21: icmp_seq=4 ttl=127 time=5.69 ms
^C
--- test-client.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.274/1.658/5.698/2.332 ms

adminuser@opsi-depotserver:/var/lib/opsi> ping 192.168.1.21
PING 192.168.1.21 (192.168.1.21) 56(84) bytes of data.
64 bytes from 192.168.1.21: icmp_seq=1 ttl=127 time=0.358 ms
64 bytes from 192.168.1.21: icmp_seq=2 ttl=127 time=0.308 ms
64 bytes from 192.168.1.21: icmp_seq=3 ttl=127 time=0.307 ms
64 bytes from 192.168.1.21: icmp_seq=4 ttl=127 time=0.327 ms
^C
--- 192.168.1.21 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.307/0.325/0.358/0.020 ms

adminuser@opsi-depotserver:/var/lib/opsi> opsi-admin -d method hostControl_showPopup "test" "test-client.local"
{
"test-client.local" :
          {
          "result" : null,
          "error" : "Opsi timeout error: Timed out after 15 seconds (timed out)"
          }
}

[n.wenselowski]

Hallo,

ich vermute bei den Ausgaben, das Problem ist, dass der Client keinen gültigen FQDN hat. (Getting Started, Kapitel 2.3)
Bitte mal mit gültigem FQDN versuchen.


Gruß

Niko

[larsg]

Hi,

Der PC ist doch über den FQDN erreichbar, hab sogar die Ping-Auswertung vom Server als "Beweis" gepostet...

Wie viel gültiger kann ein FQDN denn sein? Oder was meinst du sonst? Ich bin gerade etwas verwirrt.



Ich habe an einer anderen Stelle was entdeckt.

Es scheint als würde eine Netzkomponente zwischen dem Server und dem Client den Zugriff auf Port 4441 blockieren.
Nmap zeigt den Port 4441 für Rechner mit dem Problem als "filtered" an.
Das ergibt zwar jetzt auch Sinn, weil der Rechner nun in einem anderem Netzsegment steht. Das Problem ist jedoch auch früher schon aufgetreten, als definitiv noch keine solche Netzkomponente dazwischen hing.

Ich werde sehen was ich weiter dazu rausbekomme.

[n.wenselowski]

Hallo,

Der PC ist doch über den FQDN erreichbar, hab sogar die Ping-Auswertung vom Server als "Beweis" gepostet...
Wie viel gültiger kann ein FQDN denn sein? Oder was meinst du sonst? Ich bin gerade etwas verwirrt.

hostname.domain.tld

Es scheint als würde eine Netzkomponente zwischen dem Server und dem Client den Zugriff auf Port 4441 blockieren.
Nmap zeigt den Port 4441 für Rechner mit dem Problem als "filtered" an.
Das ergibt zwar jetzt auch Sinn, weil der Rechner nun in einem anderem Netzsegment steht. Das Problem ist jedoch auch früher schon aufgetreten, als definitiv noch keine solche Netzkomponente dazwischen hing.

Wenn Netzwerkkomponenten oder Firewalls den Zugriff verhindern, dann kann das auch nicht


Gruß

Niko