Wake On LAN über Depot-Server
Re: Wake On LAN über Depot-Server
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
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
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Wake On LAN über Depot-Server
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
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
Re: Wake On LAN über Depot-Server
Für das WOL verwendet der configed die Depot-Server aus der Hosts-Tabelle, was steht denn da drin?
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Wake On LAN über Depot-Server
Hallo Herr Röder,
-) 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:
Die externe Domain 'gate.domain.tld' löst der Server aber via UCS DNS schon richtig auf:
-) 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
Auf die Gefahr, dass die Frage dumm rüberkommt, aber ich weiß jetzt nicht welche Hosts-Tabelle Sie genau meinen?r.roeder hat geschrieben:Für das WOL verwendet der configed die Depot-Server aus der Hosts-Tabelle, was steht denn da drin?
-) 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
Code: Alles auswählen
root@bigpapa ~ # host gate.domain.tld
gate.domain.tld has address 10.1.2.7
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
Re: Wake On LAN über Depot-Server
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
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
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Wake On LAN über Depot-Server
Ja, das liefertr.roeder hat geschrieben: opsi-admin -d method host_getObjects '[]' '{"type": "OpsiConfigserver"}' | grep ident
und ist bei Ihnen anscheinend der bigpapa.
Code: Alles auswählen
"ident" : "bigpapa.domain-main.local",
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 installierenr.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.
Grüße Robert
Re: Wake On LAN über Depot-Server
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:
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:
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
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
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
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
Re: Wake On LAN über Depot-Server
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
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
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Wake On LAN über Depot-Server
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
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.
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
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" ]
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.
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.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.
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
Re: Wake On LAN über Depot-Server
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
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
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.