forum.opsi.org

Verfasst: **31 Aug 2016, 15:03**

Wie immer: the network is everything

Wenn du im configed-Log nachschaust, müsste da beim Versuch, einen Remote-WOL auszulösen, so etwas stehen wie

de.uib.opsicommand.JSONthroughHTTPS produceConnection, url; https://tst-srv-001.uib.local:4447/rpc

die Adresse ... 4447 müsste z.B. auch im Browser eine Seite produzieren. Wenn nicht, dann ist das Netzwerk nicht so, dass man sich mit dem Zielrechner
auf dem richtigen Port verbinden kann.

Viel Erfolg

Hallo Zusammen,

wir haben dasselbe Problem mit der WOL Funktion seit dem Update auf OPSI 4.0.7 auf einem Univention UCS 4.1 vor kurzem. Vorher (4.0.6 bzw. 5) ging WOL definitiv.

Configed wird remote via Browser (Java web start) via https://gate.domain.tld:15447/configed.jnlp gestartet, Port 15447 wird auf der Firewall auf den Standard-Port NATed.

Im Log sieht man schön, dass abweichend von sonstiger korrekter URL, bei den WOL Aufrufen die falsche lokale Domänen-Adresse verwendet wird: 'https://bigpapa.domain-main.local:4447/rpc' (2 mal am Ende).

Für mich sieht das nach Bug aus, ev. "nur" in der UCS-Integration.

Danke für jede Hilfe!
Grüße Robert

Code: Alles auswählen

xx@yyyyyy ~/.configed % zless configed.log | grep produceConnection
[3] (INFO)     [Okt 13  09:30:33.338  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:34.749  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:34.866  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:36.250  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:36.350  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:36.619  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:37.095  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:37.236  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:37.386  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:37.447  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:37.488  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:38.311  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:38.426  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:38.683  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:38.937  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:40.349  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:41.210  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:41.429  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:42.497  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:44.661  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:45.915  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:46.014  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:46.081  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:46.115  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:46.238  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:46.960  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:30:47.404  2016]    [Thread[Thread-32,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:32:37.356  2016]    [Thread[Thread-70,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:32:47.419  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:32:47.628  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:32:58.121  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:32:58.359  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:33:42.067  2016]    [Thread[Thread-89,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:34:15.453  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:34:15.700  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:34:20.727  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:37:27.665  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:37:30.631  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:37:31.823  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:37:32.963  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:38:12.153  2016]    [Thread[Thread-113,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://bigpapa.domain-main.local:4447/rpc
[3] (INFO)     [Okt 13  09:55:56.920  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  09:55:58.133  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  10:09:49.679  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  10:09:51.101  2016]    [Thread[AWT-EventQueue-1,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://gate.domain.tld:15447/rpc
[3] (INFO)     [Okt 13  10:10:02.370  2016]    [Thread[Thread-127,6,opsi-configed]]      de.uib.opsicommand.JSONthroughHTTPS   produceConnection, url; https://bigpapa.domain-main.local:4447/rpc

Für das WOL verwendet der configed die Depot-Server aus der Hosts-Tabelle, was steht denn da drin?

Hallo Herr Röder,

r.roeder hat geschrieben:Für das WOL verwendet der configed die Depot-Server aus der Hosts-Tabelle, was steht denn da drin?

Auf die Gefahr, dass die Frage dumm rüberkommt, aber ich weiß jetzt nicht welche Hosts-Tabelle Sie genau meinen?

-) der entfernte Admin PC wo configed via Java web start ausgeführt wird, kennt z.B. in /etc/hosts natürlich keine lokalen Domain-Adressen wie "bigpapa.domain-main.local", er kann diese auch nicht auflösen, weil er idR außerhalb der Domäne auch ohne VPN zugreift.

-) am einzigen OPSI & Depot-Server kann "bigpapa.domain-main.local" in /etc/hosts auch nur auf die interne IP-Adresse aufgelöst werden:
/etc/hosts:

Code: Alles auswählen

10.1.2.7        bigpapa.domain-main.local bigpapa

Die externe Domain 'gate.domain.tld' löst der Server aber via UCS DNS schon richtig auf:

Code: Alles auswählen

root@bigpapa ~ # host gate.domain.tld
gate.domain.tld has address 10.1.2.7

-) In der configed GUI sehe ich in der Depotserver-Liste und auch sonstwo die interne Domänen-Adresse "bigpapa.domain-main.local".

Irritierend ist für mich wie gesagt, dass WOL vor dem Update auf 4.0.7 definitiv mit diesem Setup funktionierte, ohne dass der entfernte Admin PC (auf dem configed via externer Adresse https://gate.domain.tld:15447 & Java web start ausgeführt wird) irgendwas unter "*.domain-main.local" auflösen konnte.

Danke für Ihre Mühe,
Robert

Hallo,

wegen der eventuellen Weiterleitung der WoL-Anfrage an (andere) Depotserver hat der configed in der releasten Version auch für den configserver den internen Namen des Configservers verwendet; den findet man aus der Host-Tabelle z.B. per

opsi-admin -d method host_getObjects '[]' '{"type": "OpsiConfigserver"}' | grep ident

und ist bei Ihnen anscheinend der bigpapa..

Ich habe das jetzt abgeändert, so dass der configed den Namen, unter dem er sich verbunden hat, als Namen des Configserver-Depots erkennt (so weit ich sehe

)

Heute oder möglicherweise wegen anderer Reparaturen erst in den nächsten Tagen wird der configed in der Version 4.0.7.3.3 als testing veröffentlicht. Dies allerdings zunächst nur als opsi-Paket zum lokalen Installieren, da der Aufwand zur Erstellung eines (notwendigerweise signierten) Pakets für den webstart nochmal mit allem, was dran hängt, mehrere Stunden beträgt. Da kann man dann gern als Supportkunde mit einem Auftrag wedeln.

Grüße
Rupert Röder

r.roeder hat geschrieben: opsi-admin -d method host_getObjects '[]' '{"type": "OpsiConfigserver"}' | grep ident

und ist bei Ihnen anscheinend der bigpapa.

Ja, das liefert

Code: Alles auswählen

"ident" : "bigpapa.domain-main.local",

r.roeder hat geschrieben: Heute oder möglicherweise wegen anderer Reparaturen erst in den nächsten Tagen wird der configed in der Version 4.0.7.3.3 als testing veröffentlicht. Dies allerdings zunächst nur als opsi-Paket zum lokalen Installieren, da der Aufwand zur Erstellung eines (notwendigerweise signierten) Pakets für den webstart nochmal mit allem, was dran hängt, mehrere Stunden beträgt. Da kann man dann gern als Supportkunde mit einem Auftrag wedeln.

Danke für die rasche Reaktion & den Fix, zeitlich ist das zumindest bei uns nicht wahnsinnig kritisch, sodass ich leider deswegen keinen Auftrag "unterbringe"

Ev. auch ein Anstoß, configed auch gleich lokal zu installieren

Grüße Robert

Verfasst: **04 Nov 2016, 14:50**

Hallo,

verstehe ich das richtig, dass mit OPSI 4.0.7 der opsi-configed nun direkt den zuständigen Depot-Server zu kontaktieren versucht, um ihm den Wake-On-LAN-Versuch "umzuhängen"?

Wenn ja, verbessert das die Situation eigentlich nicht, sondern verschlimmert sie gegenüber vorher. Zuvor hat der Master das WOL-Paket ausgesendet, damit mussten wir für den Master die entsprechenden Ports öffnen (9 oder 12287 oder was auch immer). Schickt nun der PC, auf dem der opsi-configed läuft, die WOL-Anforderung an den Depot-Server, müssen wir für den PC nun auch die Ports in Richtung Depotserver (4447 usw.) auf der Firewall aufgemachen. Habe ich das so richtig verstanden?

Mein Vorschlag war eigentlich dahingehend gedacht, dass der Master die WOL-Anforderung von opsi-configed erhält und diese an den zuständigen Depot-Server weiterleitet, statt selbst das WOL-Paket zu generieren. So müsste nur der Master offene Ports in Richtung Depot haben.

Jedenfalls haben wir das Problem mit der "UnknownHostException" auch, und zwar auch mit opsi-configed 4.0.7.3.5 vom 28.10.2016:

Code: Alles auswählen

Nov 04  14:47:31.648  2016 -- Exception on connecting, java.net.UnknownHostException: opsidepot01.xyz.local

Wir haben allerdings das Problem, dass die DNS-FQDNs der Depots nur am Master aufgelöst werden können (über dessen Hosts) und nicht vom z. B. Admin-PC, auf dem der opsi-configed läuft. Ich vermute mal, unser Problem rührt daher.

Edit: Ja, gerade überprüft, das ist so, wenn ich auf meinem PC die Depots in die Hosts eintrage, ändert sich die Fehlermeldung:

Code: Alles auswählen

Nov 04  14:45:36.486  2016 -- Exception on connecting, java.net.ConnectException: Connection refused: connect

Klar, ich habe zu den Depots keine Ports (4447, usw.) offen.

Also da war mir die alte WOL-Funktionalität noch lieber. (Sorry, wenn ich das so "undankbar" hinrotze ...)
Kann man das irgendwie konfigurieren/ändern?

Schöne Grüße
kinzi

Verfasst: **04 Nov 2016, 20:55**

Die alte Funktionalität ist doch einfach die, dass, vorausgesetzt das WOL geht eigentlich nie zu den entfernten Depotservern durch, dass WOL nur für Clients am Configserver funktioniert. Dann schickt man es einfach nur denen und hat die alte Funktionalität.

Wenn es doch anders wäre, fiele mir auch ein Hack ein: In den lokalen hosts die Depotserver als Aliase für den Configserver eintragen, dann würde der kontaktiert und könnte sich um das WOL kümmern.

Für Speziallösungen gibt es außerdem den bezahlten Support oder Python-Eigenbastelei

Verfasst: **07 Nov 2016, 09:42**

Hallo Robert,

sorry, das stimmt nach meinem Verständnis nicht ganz (ich lasse es mir gerne richtig erklären, wenn ich mich irre):

Man konnte bisher in /etc/opsi/backends/hostcontrol.conf folgenden Eintrag bearbeiten

Code: Alles auswählen

"broadcastAddresses": [ "255.255.255.255", "192.168.100.255", "192.168.200.225" ]

dann werden die WOL-Pakete (Broadcasts) vom Master (der bisher der einzige war, der vom opsi-configed dazu kontaktiert wurde) an diese Subnetze weitergeleitet. Dafür muss man dann aber auf der Firewall die entsprechenden Ports aufmachen und Broadcasts durchlassen usw.; ist also etwas Konfigurationsarbeit. Klappt sogar mit NAT, braucht aber unter Umständen mehrere "Anläufe" im opsi-configed, da Broadcast-Pakete nun mal verbindungslos sind und schon mal gerne verloren gehen.

Mit der neuen Lösung wird aber gar nicht mehr der Master, sondern das zuständige Depot des Clients direkt vom opsiconfd (= Admin-Client) kontaktiert und dadurch ein Fehler produziert, wenn die Ports zum Depot vom Admin-PC aus nicht offen sind. D. h. wir müssten für alle Admin-PCs Löcher in die Firewall bohren und das NAT entsprechend konfigurieren.

Ich kann daher gar nicht zur alten Funktion zurück, weil opsi-configed gar nicht mehr den Master kontaktiert beim WOL-Auftrag (außer ich setze einen alten opsi-configed ein, der noch das alte Verhalten zeigt). Falls ich mich hier irre, lasse ich mir gerne erklären, wie ich das mit OPSI 4.0.7 doch schaffe, bei uns klappt es jedenfalls nicht.

Mir erschiene es richtiger, wenn vom opsi-configed nur der Master mit dem WOL-Auftrag kontaktiert wird und dieser dann die WOL-Aufträge an sein(e) zuständige(n) Depot(s) schickt. Der Master muss ja die Dpeots sowieso erreichen können. Das WOL-Paket soll dann aber vom Depot erzeugt werden, da lokale Broadcasts wesentlich sinnvoller sind als welche, die über LAN-Grenzen, Firewalls und evtl. NATs hinweg weitergeleitet werden.

Wenn es doch anders wäre, fiele mir auch ein Hack ein: In den lokalen hosts die Depotserver als Aliase für den Configserver eintragen, dann würde der kontaktiert und könnte sich um das WOL kümmern.

Dann muss ich ja auf den Admin-PCs eine lokale Hosts pflegen - da kann ich auch gleich Löcher in die Firewall bohren lassen. Alles, was auf den/für die Admin-PCs extra konfiguriert werden muss ist doch zusätzlicher Aufwand, der leicht vergessen werden kann, wenn ein Admin-PC oder ein Depot wegfällt/hinzukommt, usw.

Es widerspricht doch auch einem Konzept eines zentralen Masters: Es ist unlogisch, einen zentralen Master für die ganze Config zu haben, der alles steuert, das WOL dann aber doch direkt auf die Depots zu machen. Klar, das ist meine Meinung - die Entwicklung macht ihr und wir sind auch "nur" Nutznießer der freien Lösung (und eines gekauften Moduls). Ich denke aber, dass wir nicht die einzigen sind, die das so einsetzen und dass es einfach vom Design her falsch ist. Das hat nichts mit einer "Speziallösung" zu tun.

Bitte nicht als Gemecker verstehen, sondern als kontruktiven Vorschlag.

Danke und schöne Grüße
kinzi

Verfasst: **07 Nov 2016, 10:49**

ok, jetzt sehe ich was das gewünschte Feature ist.

Dass allerdings die Depotserver, bei entsprechender Firewall-Konfiguration nur auf dem Port 4447, von jedem Rechner erreichbar sein können, hielte ich nicht gerade für ein Problem. Das neue Verhalten des configed beruhte natürlich auch auf einem dringenden Anwenderwunsch

, insbesondere da Broadcasts meistens gerade nicht in andere Subnetze geschickt werden können.

Aber man könnte natürlich ohne viel Aufwand konfigurierbar machen, dass das WoL für jeden Client an den Configserver geschickt wird. Das nehme ich mal als Feature-Request für das nächste Release (hoffentlich noch dieses Jahr) auf.

Dass der configserver statt des configed die WoL-Aufrufe dispatcht, ist u.U. (mit Netzlast-Einschränkungen) auch sinnvoll, aber wäre nicht meine Baustelle.

Grüße
R. Röder

forum.opsi.org

Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server

Re: Wake On LAN über Depot-Server