Ich dachte anfangs, dass aufgrund der Firewall und der im opsi config editor eingetragenen IP-Adresse des Clients (die nach der lease Dauer ja sich ändert), die Kommunikation zwischen Server und Client misslingt. Was dagegen spricht ist Wireshark sowie simplewall (s. Bild - der Daemon fragt am Client erfolgreich an). Es muss also an gewissen Einstellungen am Server oder direkt am opsi daemon liegen.
Mein Problem derzeit: software_on_demand, sowie push Meldungen oder sonstige Interaktionen laufen in ein time out.
Die inbound Regel für simplewall habe ich beim 2. mal aktiviert. Dennoch wird die jeweilige Aktion seitens des Clients nicht durchgeführt und infolgedessen kommt es auf dem Server zu einem time out. Dies ist fast bei jedem Client so, außer wenn dieser neu eingerichtet wird. Erst wenn der Rechner an dem Arbeitsplatz von unseren Mitarbeitern steht verhält sich der Daemon so. Auch wenn ich den Client wieder in unser IT-VLAN hin verschiebe ändert sich nichts dran.
Vielleicht hat einer von euch eine Idee wie ich am besten an so einem Verhalten dran gehe.
opsi config editor triggert nicht
Re: opsi config editor triggert nicht
Moin,
was sagen die Logs vom Server (opsiconfd) und in die des Clients (opsiclientd)?
was sagen die Logs vom Server (opsiconfd) und in die des Clients (opsiclientd)?
Re: opsi config editor triggert nicht
Vorab habe ich folgende Datenpunkte in den beigefügten Dateien abgeändert, um die Übersichtlichkeit zu verbessern und den Datenschutz zu bewahren:AlexB hat geschrieben:Moin,
was sagen die Logs vom Server (opsiconfd) und in die des Clients (opsiclientd)?
1. Computernamen durch CLIENT
1. Servernamen durch SERVER
2. Domänennamen durch FIRMA.LOCAL
3. IP-Adressen vom Client durch Client-IP
4. IP-Adressen vom Server durch Server-IP
Die Ergebnisse aus einem Wireshark Mitschnitt ergaben, dass eine Client-Server Kommunikation stattgefunden hat, aber augenscheinlich leider nicht die komplette. Nach meinem aktuellen Wissensstand werden ja die opsi-Pakete mittels TFTP vom opsi_workbench (Server) auf das Clientsystem mittels genanntem Protokoll übertragen und dann dort aufgespielt. Merkwürdigerweise sind alle Aktionen über die opsi Administration möglich, sofern der Rechner unmittelbar nach einer Neuinstallation angetriggert wird. Nach gewisser Zeit ist dies nicht mehr möglich. An Beispiel von Client und Neuer Client. Bei der neuen Client-Kommunikation gibt es einen Schlüsselaustausch via TLS, die essenziell für eine verschlüsselte Kommunikation ist. Bei dem alten Client kommt es erst gar nicht zu diesem Procedere.
Ich wäre euch allen ziemlich dankbar für jeden erdenklichen Ratschlag und bin jederzeit kompromissbereit.
Client:
opsiclientd.log = https://privatebin.net/?62aa53d495b6be6 ... 57QtEWnEZc
opsiclientd.log.1 = https://privatebin.net/?b5396107c9c8924 ... yK1NHkLXzE
Wireshark = https://framapic.org/yKdl4pA9kaGt/fTArwKZaEVup.png
Server:
clientconnect-client = https://privatebin.net/?52c11e5762d3214 ... 7MhzR9Nrf8
Wireshark = https://framapic.org/afrEGMDYpEPG/VgfzcKf6TsRw.png
Neuer Client:
Wireshark = https://framapic.org/KnzqEELUUoql/jiq4FoDGZfK0.png
Re: opsi config editor triggert nicht
push! jemand ne Idee?
-
- Beiträge: 439
- Registriert: 08 Jul 2017, 12:02
Re: opsi config editor triggert nicht
TFTP wird NUR für die erste netboot Geschichte genutzt.Whoops! hat geschrieben:Nach meinem aktuellen Wissensstand werden ja die opsi-Pakete mittels TFTP vom opsi_workbench (Server) auf das Clientsystem mittels genanntem Protokoll übertragen und dann dort aufgespielt. Merkwürdigerweise sind alle Aktionen über die opsi Administration möglich, sofern der Rechner unmittelbar nach einer Neuinstallation angetriggert wird. Nach gewisser Zeit ist dies nicht mehr möglich.
Ich wäre euch allen ziemlich dankbar für jeden erdenklichen Ratschlag und bin jederzeit kompromissbereit.
Nicht von Workbench, sondern von opsi_depot
Schau dir mal dein Bild an, ändere die Regel von Ausgehend in ein und ausgehend oder whiteliste die exe.
Re: opsi config editor triggert nicht
Nur mal so grundsätzlich... der Client nimmt in der Regel zum Server Kontakt auf über den Port TCP4447. Bei dem on_demand muss der Server den Client erreichen mit dem Port 4441. Das hat jetzt nix direkt mit dem Protokoll zu tun, aber es ist in beiden Richtungen HTTPS.
Habe nicht ganz verstanden, was jetzt das genaue Problem ist, aber vielleicht hilft es.
Ansonsten bieten wir auch Supportverträge an und Unterstützen gerne auch bei solchen Problemen
Habe nicht ganz verstanden, was jetzt das genaue Problem ist, aber vielleicht hilft es.
Ansonsten bieten wir auch Supportverträge an und Unterstützen gerne auch bei solchen Problemen
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de