forum.opsi.org

ist das jetzt by Design oder Bug

dark alex hat geschrieben:ist das jetzt by Design oder Bug

Das liegt im Auge des betrachters. Für dich ist es ein Bug, für die meisten anderen da draußen ist das by Design. Die Fallbacks, die dort verbaut wurden sorgen dafür, dass opsi arbeitet auch wenn das DNS mal nicht so top aktuell ist oder gut läuft. Für eure Umgebung gibt es da andere Probleme, die bewältigt werden müssen.

Warum der nur schaut und sich nicht versucht ein zu loggen ist pur aus Performancegründen so gebaut. Da man den Webservice überladen kann, kannst du dir die Methode auch selber Implementieren oder über einen Supportvertrag wünschen, wie diese Methode arbeiten soll, dann bauen wir das für euch.

wolfbardo hat geschrieben:ok, die Methode

Code: Alles auswählen

hostControlSafe_reachable

schaut wohl nur nach, ob opsiclientd auf 4441 antwortet und nicht ob es der richtige Client ist.

"Früher" funktionierte der Fallback von DNS auf IP nicht, das ist gefixt, aber ob der richtige Client antwortet weiss man in über diese Methode nicht.

Gruss
Bardo Wolf

So wie ich das sehe wird eine Verbindung zur IP von "Client A" aufgebaut so wie sie im Backend steht. Wenn dort aber jetzt eine IP steht die aktuell "Client B" zugewiesen ist wird "Client A" als online anzeigt weil "Client B" online ist. Liege ich da falsch und die Verbindung wird über den Hostname aufgebaut ?

Ich glaube wir reden hier alle über das selbe. Normalerweise wird über den Namen kontakt aufgenommen. Zunächst wird ein Resolve gemacht, der in diesem Fall zurecht nichts zurückliefert, weil der Client nicht mehr existiert. Dann wird als Fallback die Addresse aus der opsi-DB gezogen. Die Verbindung wird auf socket-Ebene auf IP-Basis aufgebaut. Das ist auch gar nicht das Problem, sondern dass hier IPs dynamisch vergeben werden und die opsi-DB nicht synchron mit der Infrastruktur mitläuft. Das sollte man versuchen zu fixen. Da ich jetzt auch schon durch andere Threads weiß, dass Ihr AD verwendet, wäre hier der neue opsi-directory-connector (alias AD-Connector), der bald erscheint interessant. Der versucht das Problem zu addressieren, dass das AD das federführende System in der Infrastruktur wird. Anwender aus dem UCS-Bereich kennen das verfahren schon länger.

Wenn cih hier wieder "Modul" lese wette ich, dass mein Chef ein Wort mit 4 Buchstaben parat hat...

Dann sag nicht Modul dazu, sondern überlebensnotwendige Maßnahme. Entweder das oder Umbau der Infrastruktur....

ueluekmen hat geschrieben:Zunächst wird ein Resolve gemacht, der in diesem Fall zurecht nichts zurückliefert, weil der Client nicht mehr existiert.

Der Eintrag kann trotzdem noch im DNS sein. Außerdem kann eine IP mehrere Einträge im DNS haben. Der DNS könnte also bei Abfrage von "Client A" die IP liefern die mittlerweile "Client B" belegt.
Ich gehe hier davon aus das DDNS verwendet wird [1]. dark alex du solltest mal konkretisieren wie die Infrastruktur aufgebaut ist.

[1] https://de.wikipedia.org/wiki/Dynamisch ... .A4nkungen

Richtig. Es könnte sein. Aber der gute schrieb, dass die DNS-Auflösung nicht mehr klappt, weil der Client nicht mehr existiert. Und dann zieht der Fallback von opsi, dass die IP aus dem backend genutzt wird. Wenn der Client sich aber nicht aktualisiert hat, dann bleibt die IP-Adresse da bestehen. Wir könnten auch versuchen zu verhindern, dass zweimal die selbe IP reingeschrieben werden kann. Aber dann gibt es ärger mit Umgebung die mit NAT arbeiten und wir wollen auch nicht wirklich jemanden bevormunden. Ich erinnere mich noch an die Diskussion mit dem Unterstrich im Hostnamen, was gegen die entspr. RFC verstoßen hat. Aber das, was diese Einschränkung für Diskussionen verursacht hat. Wenn man mich heute Fragen würde, hätte ich wahrscheinlich eine andere Meinung zu dieser Sache als damals.

Und die Ursprüngliche Anfrage war doch, dass die reachable-Funktion einen Client als aktiv zeigt, der aber ein anderer Client ist. Deshalb hatte ich vorher schon mal geschrieben, dass man auch die reachable umbauen kann. Wenn man versucht sich an dem client-Port zu authentifizieren, dann merkt man, dass da was nicht stimmt. Aber das würde noch mehr IO produzieren, deshalb machen wir das nicht generell so, aber der Webservice lässt sich ja überladen. Damit kann man für sich selber die Methoden implementieren, wie man will oder Sie implementieren lassen, wie man Sie gerne für sich hätte.

Kann man eigentlich den Fallback auf die "known IP" einfach abschalten? Oder findet das auch direkt in der Methode statt, sodass man es durch überladen der API rausbauen kann? Das wäre für uns das sinnvollste. Wenn unser DNS nicht funktioniert, ist OPSI unser letztes Problem.

Zur Umgebung:
Microsoft DHCP&DNS-Server, die DHCP-Clients updaten ihre Hostnames im DNS dynamisch.
Wir haben derzeit 4 Domänen (Forest) und auch ein paar Workgroup-Rechner
Das AD-Modul wäre wohl für uns eh noch nicht relevant.