Ports ändern

[RobertOpsi]

Hallo,

ich müsste den Opsi Client hinter einer Firewall verwenden, die ich selbst nicht konfigurieren kann.
Ich hätte Port 80 und Port 443 offen, in der /etc/opsi/opsiconfd.conf gibt es ja in den Service Settings die Möglichkeit den http oder https Port festzulegen.
In der virtuellen Testumgebung läuft alles einwandfrei, solange ich nicht versuche die Ports anzupassen.

Wenn ich jetzt sage ich möchte statt dem https Standardport 4447, auf 443 wechseln, lässt sich der Dienst nicht mehr starten.
Netstat bestätigt auch das kein anderer Dienst den Port bereits in Benutzung hat.

aus dem opsiconfd.log

Code: Alles auswählen

==================================================================
=             opsi configuration service starting                =
==================================================================
 (Logger.py|840)
[5] [May 08 08:39:14] Starting opsiconfd main thread (opsiconfd.py|447)
[5] [May 08 08:39:14] Opening socket /var/run/opsiconfd/opsiconfd.socket for interprocess communication. (opsiconfd.py|424)
[5] [May 08 08:39:14] Modules file signature verified (customer: ###) (MySQL.py|466)
[5] [May 08 08:39:14] Added static content '/' which points to directory '/usr/share/opsiconfd/static' (opsiconfd.py|283)
[5] [May 08 08:39:14] Running on depot server 'opsidemo.uib.local', exporting repository directory (opsiconfd.py|300)
[5] [May 08 08:39:14] Running on depot server 'opsidemo.uib.local', exporting depot directory (opsiconfd.py|313)
[5] [May 08 08:39:14] Added webdav content 'repository' which points to directory '/var/lib/opsi/repository' () (opsiconfd.py|346)
[5] [May 08 08:39:14] Added webdav content 'depot' which points to directory '/var/lib/opsi/depot' () (opsiconfd.py|346)
[5] [May 08 08:39:14] Added webdav content 'configed' which points to directory '/usr/lib/configed' (u'noauth',) (opsiconfd.py|346)
[2] [May 08 08:39:14] Traceback: (Logger.py|754)
[2] [May 08 08:39:14]      line 457 in 'run' in file '/usr/lib/pymodules/python2.7/opsiconfd/opsiconfd.py' (Logger.py|754)
[2] [May 08 08:39:14]      line 353 in '_startListening' in file '/usr/lib/pymodules/python2.7/opsiconfd/opsiconfd.py' (Logger.py|754)
[2] [May 08 08:39:14]      line 383 in '_startListeningHTTPS' in file '/usr/lib/pymodules/python2.7/opsiconfd/opsiconfd.py' (Logger.py|754)
[2] [May 08 08:39:14]      line 469 in 'listenSSL' in file '/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py' (Logger.py|754)
[2] [May 08 08:39:14]      line 436 in 'listenTCP' in file '/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py' (Logger.py|754)
[2] [May 08 08:39:14]      line 622 in 'startListening' in file '/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py' (Logger.py|754)
[2] [May 08 08:39:14]      ==>>> Couldn't listen on any:443: [Errno 13] Permission denied. (opsiconfd.py|469)
[5] [May 08 08:39:14] Stopping opsiconfd main thread (opsiconfd.py|175)
[5] [May 08 08:39:14] Deleting all sessions (Session.py|217)
[5] [May 08 08:39:14] Opsiconfd main thread exiting... (opsiconfd.py|472)

er lässt mich den Port aber wie es scheint nicht auf 443 für den Server setzen, das wäre doch aber die richtige Stelle, um den Port zu ändern?

Wäre dankbar wenn jemand eine Idee hätte wo ist ggfs. falsch abgebogen bin

gruß
Robert

[n.wenselowski]

Hallo Robert,

auf Ports unterhalb 1024 kann idR nur root binden.

Auch wenn es möglich ist, raten wir von der Verwendung eines anderen Ports grundsätzlich ab, da es nicht ausreicht einfach den Port am Server zu ändern, da bspw. die Clients auch über den neuen Port informiert werden müssen.

Dieser Ansatz mittels iptables Anfragen von :443 auf einen anderen Port umzuleiten finde ich relativ interessant, das könnte auch funktionieren.


Gruß

Niko

[RobertOpsi]

Hallo niko,

mein Problem besteht darin, das ich damit beauftragt wurde zu evaluieren, ob die von unserer Firma benötigten Anforderungen an die Softwareverteilung mit OPSI realisiert werden können. Ich muss dezentral Software über das WAN Modul verteilen und die Opsi Clientsoftware würde dann in Netzwerkumgebungen laufen, die wir nicht administrieren. Viele Kunden haben halt nur diese 2 Ports an ihrer Firewall offen (80/443) und würden uns die Opsi Standardport nicht öffnen, da heißt es dann findet eine andere Lösung.

Mir stellt sich jetzt die Frage: Ist es prinzipiell möglich Opsi dazu zubringen über diese Ports zu laufen oder geht das an sich gar nicht? Das wäre sonst ein K.O. Kriterium.

Wenn ich vielleicht an dieser Stelle noch eine andere Frage stellen könnte: geht opsi on_demand Softwareverteilung nur lokal?
Liesse sich die on_demand Steuerung auch über das WAN Modul verwenden? Ich würde gerne ohne rebooten zu müssen, die gecachte Software installieren. Im laufenden Betrieb einen Fremdserver restarten macht auf Dauer keinen Kunden glücklich, mit dem smb mount lief das lokal ohne Probleme, aber sobald ich das WAN Modul verwende, laufe ich in einen Fehler, daher auch hier die Frage ob das prinzipiell möglich ist, on_demand per wan ohne reboot zu installieren oder ob das nicht vorgesehen ist.

vielen Dank für deine Antwort,
mit freundlichen Grüßen

Robert

[SisterOfMercy]

Can't you do something with a VPN tunnel and/or local OPSI depots?
Ok, VPN will probably not work if only ports 80 and 443 (and a few more for dns, icmp) are open. But a requirement for 'Ipsec functionality' probably sounds a lot better than 'these ports need to be open' to the average paranoid BOFH.

[RobertOpsi]

@ SisterofMercy

VPN is somekind of last resort messure, the amount of vpn connection we would have to implement isnt small, so configuring the service to work with what we got, is less work in the long run and so far its going really good. but thank you for your input, much appreciated.

@niko

dem opsiconfd benutzer fehlten in der tat die recht um 443 zu binden, als linux neuling war mir das nicht bewusst. vielen dank für den hinweis!

hab den server jetzt auf 443 laufen, der client läuft ebenso auf port 443 bis ich software verteilen möchte. dort vergisst er scheinbar den neuen clientserviceport und versucht sich selbst wärend der softwareverteilung die dem anmeldeprozess vorgeschaltet ist auf "https:localhost:4441/rpc" zu erreichen, was natürlich wenig erfolg hat, da der service nicht mehr auf 4441 läuft.

habe den clientport in der hostcontrol.conf geändert und in der opsiclientd.conf aus dem opsi-client-agent/files/opsi/dist/opsiclientd verzeichnis.

bin der meinung alle config files durchsucht zu haben und keine weiteren einträge für den clientport gefunden zu haben.

Gibt es da ein Skript wo der Eintrag noch drin ist?

gruß
Robert

[n.wenselowski]

Hallo Robert,

ich würde mal auf dem Client überprüfen, ob die Konfigurationsdatei bei ihm auch entsprechend so aussieht, wie du willst.

Es gibt einen Punkt, bei dem der Client mit einer fest verdrahteten Adresse mit Port 4441 zu kommunizieren versucht.
Steht im Client log sowas wie Event '...' uses cached config and config caching is done?


Gruß

Niko

[RobertOpsi]

Hallo Niko,

ich würde mal auf dem Client überprüfen, ob die Konfigurationsdatei bei ihm auch entsprechend so aussieht, wie du willst.

auf dem client ist der server_control.port in der opsiclientd.conf auf "443" gestellt, als auch in der opsiclientd.conf auf dem server (wenn er die sich von da ziehen sollte zum cachen)

Steht im Client log sowas wie Event '...' uses cached config and config caching is done?

ja diese Zeile gibt es, ist das was gutes? Und wo speichert er denn diese gecachte config datei, würde gerne mal sehen was er da für Werte hat.

Code: Alles auswählen

[5] [May 14 09:42:23] [ event processing gui_startup{cache_ready}] Event 'gui_startup{cache_ready}' uses cached config and config caching is done   (EventProcessing.pyo|1172)

[n.wenselowski]

Hallo Robert,

Das Problem tritt dann in Zusammenarbeit mit der WAN-Erweiterung an dem Client auf - hier ist an einer Stelle noch der Port 4441 fest hinterlegt und es wird nicht der Wert aus der Config übernommen.
Bevor das passiert steht eben diese Meldung im Log.
Ich habe ein internes Ticket dazu aufgemacht.

Wie üblich kann die Umsetzung durch einen Support-Vertrag beschleunigt werden.


Gruß

Niko

[RobertOpsi]

Hallo

ich habe heute ein neues Packet installieren wollen und bin in einer Fehler gelaufen: durch die Umstellung des Service-ports lässt sich am Server kein Packet mehr installieren.

In der /usr/lib/pymodules/python2.7/opsi/backend/jsonrpc.py ist in der Klasse "JSONRPCBACKEND" der Wert self._defaultHttpsPort = 4447 festeingebaut und musste per Hand angepasst werden. Keine Ahnung ob das gewollt ist, bin drüber gestolpert und dachte ich reich das an euch weiter.

Gruß
Robert

[n.wenselowski]

Hallo Robert,

danke für den Hinweis, ich habe das ebenfalls aufgenommen.

Dieser Ansatz mittels iptables Anfragen von :443 auf einen anderen Port umzuleiten finde ich relativ interessant, das könnte auch funktionieren.

Den Ansatz will ich nochmal hervorheben. Hier könnte man den Clients hinter der FW clientconfig.configserver.url anpassen, für die anderen muss man nichts weiter ändern.


Gruß

Niko