Netzwerk und HTTPS

Diese Seite beschreibt, wie TCMSOFT im Praxisnetz erreichbar ist: welche Ports der Server belegt, warum TCMSOFT im Host-Netz läuft, wie die Druckersuche funktioniert, was eine Firewall durchlassen muss und wie Sie HTTPS einrichten. Sie setzt voraus, dass TCMSOFT nach TCMSOFT einrichten läuft.

Kurz: TCMSOFT selbst spricht nur HTTP, auf der NAS über Port 8085. HTTPS übernimmt ein Reverse-Proxy davor: der Reverse-Proxy der NAS bzw. Caddy auf dem Mikroserver. HTTPS ist Pflicht für Agent suchen (Kopplung der Print Agents über den Browser) und empfohlen, bevor an Arbeitsplätzen Print Agents gekoppelt werden. Die Kopplung per Code geht auch über http://.

Wer verbindet sich wohin

Prismamed Agents (/api/agent), Handys (/api/companion) und Print Agents (Hub) nutzen denselben Web-Port wie der Browser. Einen eigenen Port brauchen sie am Server nicht.

Host-Netz

Wozu: Netzwerkdrucker melden sich per Bonjour (mDNS-Multicast) im Praxisnetz. Diese Meldungen erreichen einen Container nur im Host-Netz. Im Bridge-Netz von Docker bliebe die Druckersuche leer. Der Update-Dienst legt den Container tcmsoft deshalb immer mit --network host an. Daran müssen und können Sie nichts einstellen.

Folge: Der Container teilt sich alle Ports mit dem Gerät. Deshalb gilt:

• MongoDB und der Print Agent im Container lauschen nur auf 127.0.0.1.
• CUPS ist nur über einen Socket im Container erreichbar (/run/cups/cups.sock), nicht über einen Port. Ein CUPS der NAS bleibt unberührt.
• Ist ein Port schon belegt, meldet TCMSOFT das vor dem Start im Klartext (siehe unten).

Der Update-Dienst tcmsoft-updater selbst läuft im normalen Bridge-Netz von Docker. Er braucht nur ausgehend HTTPS.

Prüfen:

docker inspect -f '{{.HostConfig.NetworkMode}}' tcmsoft

Erwartet wird host.

Ports am Server

• Auf einer Synology sind die Ports 5000 und 5001 vom System belegt. Deshalb steht in tcmsoft.env der Port 8085.
• Der DICOM-Empfänger ist zunächst ausgeschaltet. Er lauscht erst, wenn unter Stammdaten › DICOM der Schalter Empfänger einschalten an ist und gespeichert wurde. Ports unter 1024 lehnt TCMSOFT ab: „Ports unter 1024 sind auf dem Server dem System vorbehalten. Bitte z.B. 11112 verwenden.“ Zeigt die Seite den Status „Gestört“, nennt die Warnkarte darunter den Grund, bei einem belegten Port „Der DICOM-Empfänger konnte nicht gestartet werden: Port … ist auf diesem Server bereits belegt oder darf nicht geöffnet werden. …“. Einzelheiten unter DICOM-Geräte und Mobilgeräte.

Wenn ein Port belegt ist

Vor dem Start prüft TCMSOFT bis zu 30 Sekunden lang, ob seine Ports frei werden. Sonst steht im Protokoll (docker logs tcmsoft, Zeilen mit [tcmsoft]) eine dieser Meldungen:

Bei den ersten beiden Meldungen startet TCMSOFT nicht. Bei der dritten startet es, druckt aber nicht über den Container.

Web-Port ändern

1. In <Datenordner>/tcmsoft.env die Zeile ASPNETCORE_URLS=http://+:8085 ändern, z. B. auf http://+:8086.

2. Den Container entfernen. Der Update-Dienst legt ihn kurz darauf (spätestens nach 10 Minuten) mit derselben Version und der neuen Einstellung wieder an:

   docker rm -f tcmsoft
   

3. Das Ziel des Reverse-Proxys auf den neuen Port stellen.

4. Die Arbeitsplätze nachziehen, siehe „Eine feste Adresse für den Server“.

Erfolg: In TCMSOFT meldet die Glocke „TCMSOFT … neu angelegt“, und TCMSOFT öffnet sich unter der neuen Adresse. Wenn nicht: TCMSOFT ist unter der neuen Adresse nicht erreichbar, und docker logs tcmsoft-updater meldet „TCMSOFT startet nicht: TCMSOFT … wurde neu angelegt, startet aber nicht. …“. Dann docker logs tcmsoft lesen, die Zeile in tcmsoft.env korrigieren und erneut docker rm -f tcmsoft ausführen. Läuft noch ein Update-Dienst vor 2026.10.7.1, vorher die Hinweise unter Datenordner und tcmsoft.env lesen.

Druckersuche (Bonjour und Avahi)

Wozu: Unter Stammdaten › Drucker › Drucker hinzufügen zeigt der Reiter Erkannte Drucker die Netzwerkdrucker, die sich per Bonjour/AirPrint melden. So muss niemand die Adresse eines Druckers kennen.

So funktioniert es:

• Im Container läuft Avahi, mit dem CUPS über D-Bus spricht. Avahi und D-Bus startet und überwacht der Container selbst; beendet sich einer davon, startet er ihn neu.
• Avahi sucht nur und kündigt nichts an (disable-publishing=yes, publish-addresses=no). Die NAS erscheint also nicht ein zweites Mal im Netz.
• Die „.local“-Namen der Drucker löst der Container über libnss-mdns auf.

Voraussetzungen:

• Am Drucker ist Bonjour/AirPrint bzw. mDNS eingeschaltet.
• Drucker und Server stehen im selben Netz, damit die Bonjour-Meldungen den Server erreichen.
• Die Suche dauert bis zu 30 Sekunden.

Prüfen:

docker exec tcmsoft avahi-browse -rt _ipp._tcp

zeigt die Bonjour-Meldungen der Drucker im Netz.

docker exec tcmsoft lpinfo -v

zeigt die Drucker, die das Drucksystem gefunden hat.

Wenn die Suche nichts findet:

• Drucker eingeschaltet, im selben Netz wie der Server, Bonjour/AirPrint am Drucker aktiv?
• Startet Avahi dreimal kurz nacheinander nicht, bleibt die Suche aus. Das Protokoll meldet dann „Die Druckersuche (Avahi) startet nicht - bitte das Protokoll oben prüfen. Drucker lassen sich weiterhin mit ihrer Adresse einrichten.“ bzw. „D-Bus startet nicht - die Druckersuche steht nicht zur Verfügung. …“.
• In jedem Fall lässt sich der Drucker mit seiner Adresse anlegen, z. B. ipp://192.168.1.50/ipp/print oder socket://192.168.1.50:9100.
• Freigaben anderer Rechner („Drucker @ Rechnername“) zeigt die Suche nur, wenn der Drucker selbst nicht im Netz erscheint, z. B. per USB an einem Mac. Sie drucken nur, solange dieser Rechner läuft.

Treiber, eigene PPD-Dateien und die Print Agents der Arbeitsplätze stehen unter Print Agent. Die Bedienung für die Praxis beschreibt das Benutzerhandbuch › Stammdaten: Praxis › Drucker.

Firewall

Am Server: eingehend

Aus dem Praxisnetz müssen erreichbar sein:

• der HTTPS-Port des Reverse-Proxys (nach dem Einrichten von HTTPS),
• 8085/tcp, solange ohne HTTPS gearbeitet wird oder Prismamed Agents bzw. Handys die http://-Adresse nutzen,
• 11112/tcp, nur wenn DICOM-Geräte Bilder senden.

MongoDB (27017), der Print Agent im Container (9632) und CUPS lauschen nur intern. Für sie keine Freigabe einrichten.

Die Druckersuche empfängt die Bonjour-Meldungen der Drucker (mDNS). Ob eine Firewall auf dem Server dafür etwas durchlassen muss, ist nicht getestet. Findet Erkannte Drucker bei eingeschalteter Firewall nichts, vor dem Einsatz beim TCMSOFT-Support nachfragen; die Drucker lassen sich in jedem Fall mit ihrer Adresse anlegen.

Läuft auf dem Server die Firewall ufw, geben Sie den DICOM-Port so frei, wie es die Mikroserver-Provisionierung tut. Sie gibt den Port nur frei, wenn ufw aktiv ist:

ufw allow 11112/tcp comment 'TCMSOFT DICOM'

Für eine andere Firewall der NAS gilt dasselbe sinngemäß. Wie das in der Oberfläche der jeweiligen NAS geht, ist hier nicht beschrieben.

Am Server: ausgehend

TCMSOFT und der Update-Dienst rufen diese Adressen auf. Die Adressen mit https:// laufen über HTTPS (Port 443) ins Internet; dafür braucht der Server Internet und eine funktionierende Namensauflösung (DNS). E-Mail, Datensicherung und Datenübernahme nutzen die Server und Ports, die in TCMSOFT eingetragen sind.

Ankommende Verbindungen aus dem Internet braucht keiner dieser Dienste. Auch das Portal der Online-Terminbuchung ruft TCMSOFT nicht auf; TCMSOFT holt die Buchungen selbst ab.

Prüfen (per SSH auf dem Server; auf ARM-Geräten arm64 statt x64):

curl -fsS -o /dev/null -w '%{http_code}\n' https://downloads.tcmsoft.de/docker/tcmsoft-updater-x64.json

Erwartet wird 200.

Woran man eine Sperre bemerkt:

• Unter Stammdaten › Backup, Karte Programmversion und Updates, steht „Die Versionsprüfung bei downloads.tcmsoft.de ist fehlgeschlagen - bitte die Internetverbindung des Servers prüfen (…).“
• Solange noch keine TCM-Bibliothek geladen ist, erscheint beim Öffnen von TCMSOFT „TCM-Bibliothek nicht verfügbar“. Alles andere funktioniert; die Bibliothek wird nachgeladen, sobald die Verbindung steht.

Ausgehender HTTP-Proxy: Ein Server, der nur über einen HTTP-Proxy ins Internet kommt, ist nicht vorgesehen und nicht getestet. Der Update-Dienst gibt bei seinem Selbst-Update nur TCMSOFT_DATEN, UPDATE_UHRZEIT, MANIFEST_BASIS und TZ an seinen Nachfolger weiter; eine von Hand gesetzte Proxy-Variable ginge dabei verloren. Vor dem Einsatz beim TCMSOFT-Support nachfragen.

An den Arbeitsplätzen

• Der Print Agent unter Windows lauscht auf Port 9632 an allen Netzwerkadressen, der Print Agent am Mac nur auf localhost. Für Agent suchen genügt die Verbindung über 127.0.0.1 am selben Rechner; eine Freigabe aus dem Netz wird dafür nicht gebraucht. Ob Windows beim ersten Start des Print Agent eine Firewall-Rückfrage zeigt, ist nicht dokumentiert.
• Handys müssen im selben WLAN sein wie TCMSOFT.
• Einzelheiten: Prismamed Agent, Print Agent, Updates der Agenten.

Eine feste Adresse für den Server

Die Adresse des Servers steht an vielen Stellen. Geben Sie dem Server deshalb eine feste Adresse und legen Sie sie fest, bevor Arbeitsplätze und Geräte eingerichtet werden.

Dasselbe gilt, wenn sich der Port ändert.

HTTPS einrichten

Warum HTTPS nötig ist

Pflicht für „Agent suchen“. Die Kopplung per Code (Stammdaten › Drucker › Arbeitsplatz koppeln) geht auch ohne HTTPS. Beim Koppeln über Stammdaten › Drucker › Agent suchen fragt die TCMSOFT-Seite im Browser den Print Agent desselben Rechners unter http://127.0.0.1:9632 ab und übergibt ihm die Kopplung. Chrome und Edge erlauben einer Seite diesen Zugriff auf Geräte im lokalen Netzwerk nur, wenn die Seite selbst über HTTPS geöffnet ist. Beim ersten Mal fragt der Browser außerdem nach dem Zugriff auf Geräte im lokalen Netzwerk; dort Zulassen wählen. Ausnahme: Auf dem Rechner, auf dem TCMSOFT selbst läuft, genügt http://localhost.

Danach verbindet sich der Print Agent von sich aus mit TCMSOFT, und zwar unter der Adresse, unter der TCMSOFT beim Koppeln im Browser geöffnet war. Deshalb muss der Rechner dem Zertifikat dieser Adresse vertrauen.

„Agent suchen“ in Safari ist nicht geprüft. Empfohlen sind Chrome oder Edge.

Ohne Zwang, aber empfohlen für alles andere: Mit HTTPS laufen Anmeldung und Patientendaten verschlüsselt durchs Praxisnetz. Der Prismamed Agent und die Handys funktionieren auch mit einer http://-Adresse. Der Prismamed Agent nimmt beide an; nutzt er https://, muss auch sein Rechner dem Zertifikat vertrauen.

So ist es aufgebaut

• Im Container gibt es kein TLS und keine Umleitung auf HTTPS (Server__HttpsRedirect=false setzt das Image).
• Ein Reverse-Proxy nimmt HTTPS an und reicht die Anfragen unverschlüsselt an TCMSOFT weiter: auf der NAS an http://localhost:8085, auf dem Mikroserver an 127.0.0.1:5000.
• TCMSOFT wertet im Container die Kopfzeilen X-Forwarded-Proto und X-Forwarded-For aus, und zwar von jedem Absender. Der Proxy sollte sie mitschicken. Ohne X-Forwarded-Proto hält TCMSOFT die Verbindung für http://; dann scheitert z. B. die Anmeldung mit Passkeys. Ohne X-Forwarded-For steht im Anmeldeprotokoll für jeden Arbeitsplatz die Adresse des Proxys.
• Der Proxy muss WebSockets durchreichen. Ohne sie läuft TCMSOFT, aber spürbar langsamer.

Synology

1. Systemsteuerung › Anmeldeportal › Erweitert › Reverse Proxy öffnen und einen Eintrag anlegen.
2. Als Quelle HTTPS mit dem Namen wählen, unter dem die Arbeitsplätze TCMSOFT öffnen sollen. Als Ziel http://localhost:8085 eintragen.
3. Im selben Eintrag unter Benutzerdefinierter Header › Erstellen › WebSocket die WebSocket-Kopfzeilen eintragen.
4. Dem Namen ein Zertifikat zuordnen (siehe „Das Zertifikat“).
5. Danach Server__SichereCookies einschalten (siehe unten).

Welcher Quell-Port sich neben den DSM-Ports 5000/5001 bewährt hat, ist nicht dokumentiert. Ebenso nicht geprüft ist, ob der Reverse-Proxy der Synology X-Forwarded-Proto und X-Forwarded-For von sich aus mitschickt. Im Zweifel beim TCMSOFT-Support nachfragen.

Mikroserver mit Caddy

Auf dem Mikroserver bleibt Caddy der Webserver. Bei der Einrichtung schreibt der Befehl aus TCMSOFT einrichten diese tcmsoft.env:

ASPNETCORE_URLS=http://127.0.0.1:5000
Server__SichereCookies=true

Für Salvia Software steht zusätzlich Produkt=Salvia darin. TCMSOFT lauscht dann nur auf 127.0.0.1:5000. Von außen geht es nur über Caddy, dessen Konfiguration (reverse_proxy :5000) unverändert bleibt.

Die Mikroserver-Provisionierung hat bei der früheren Installation diese /etc/caddy/Caddyfile geschrieben:

:80 {
reverse_proxy :5000
tls internal
}

Achtung, nicht geklärt: Ob die Mikroserver damit HTTPS mit einem Zertifikat ausliefern, dem die Arbeitsplätze vertrauen, ist nicht geprüft. Öffnen Sie TCMSOFT nach der Einrichtung an einem Arbeitsplatz. Klappt das nur über http://, hält die Anmeldung wegen Server__SichereCookies=true nicht. Dann vor dem Einsatz beim TCMSOFT-Support nachfragen. Als Notlösung die Zeile in tcmsoft.env mit # auskommentieren und docker rm -f tcmsoft ausführen.

Andere NAS

Für UGREEN und andere Geräte ist der Weg zum Reverse-Proxy nicht beschrieben. Die Anforderungen sind dieselben: HTTPS annehmen, an http://localhost:8085 weiterreichen, WebSockets durchreichen, X-Forwarded-Proto und X-Forwarded-For mitschicken, ein vertrauenswürdiges Zertifikat für den Namen.

Das Zertifikat

• Es muss für genau die Adresse gelten, unter der die Arbeitsplätze TCMSOFT öffnen.
• Windows bzw. macOS an jedem Arbeitsplatz muss ihm vertrauen. Zeigt der Browser eine Zertifikatswarnung, verbindet sich der Print Agent nicht.
• Der Name muss an jedem Arbeitsplatz auf den Server zeigen.

Zwei Wege:

• Zertifikat einer anerkannten Stelle, z. B. Let's Encrypt mit festem Namen. Dann ist an den Arbeitsplätzen nichts zu tun.
• Zertifikat der NAS an jedem Arbeitsplatz als vertrauenswürdige Stammzertifizierungsstelle importieren. Am Mac: in der Schlüsselbundverwaltung importieren und „Immer vertrauen“ wählen.

Server__SichereCookies einschalten

Wozu: Mit Server__SichereCookies=true setzt TCMSOFT die Anmelde-Cookies nur noch für HTTPS. Im Image ist die Einstellung aus, damit die Anmeldung im Praxisnetz auch ohne Proxy über http:// funktioniert.

Erst einschalten, wenn TCMSOFT über HTTPS läuft. Browser verwerfen solche Cookies auf jeder http://-Adresse außer localhost. Die Anmeldung „gelingt“ dann, hält aber nicht: Man landet sofort wieder auf der Anmeldeseite.

1. Prüfen, ob die Zeile in tcmsoft.env steht. Der Update-Dienst legt sie auskommentiert an (# Server__SichereCookies=true):

   grep SichereCookies <Datenordner>/tcmsoft.env
   

2. Die Zeile einschalten:

   sed -i 's/^# *Server__SichereCookies=true/Server__SichereCookies=true/' <Datenordner>/tcmsoft.env
   

   Gab Schritt 1 nichts aus, die Zeile stattdessen anhängen:

   echo 'Server__SichereCookies=true' >> <Datenordner>/tcmsoft.env
   

3. Den Container entfernen; der Update-Dienst legt ihn mit derselben Version und der neuen Einstellung wieder an (spätestens nach 10 Minuten):

   docker rm -f tcmsoft
   

   Läuft noch ein Update-Dienst vor 2026.10.7.1, vorher die Hinweise unter Datenordner und tcmsoft.env lesen.

4. An allen Arbeitsplätzen TCMSOFT nur noch über die HTTPS-Adresse öffnen und Lesezeichen umstellen.

docker restart tcmsoft genügt nicht: Docker liest tcmsoft.env nur beim Anlegen des Containers.

Erfolg prüfen

1. grep SichereCookies <Datenordner>/tcmsoft.env zeigt Server__SichereCookies=true ohne #.
2. Die Glocke in TCMSOFT meldet „TCMSOFT … neu angelegt“.
3. An einem Arbeitsplatz öffnet sich die HTTPS-Adresse ohne Zertifikatswarnung, und die Anmeldung hält.
4. An einem Arbeitsplatz mit Print Agent meldet Stammdaten › Drucker › Agent suchen „Print Agent verbunden“.

Wenn etwas nicht klappt

Weitere Meldungen der Print Agents stehen unter Print Agent und Meldungen und ihre Bedeutung.

Noch nicht entschieden

Nach dem Einrichten von HTTPS bleibt TCMSOFT zusätzlich unverschlüsselt unter http://<Server-Adresse>:8085 im Praxisnetz erreichbar, und TCMSOFT übernimmt X-Forwarded-* von jedem Absender. Ob man den Web-Port dann auf die NAS selbst begrenzen soll (ASPNETCORE_URLS=http://127.0.0.1:8085), ist nicht entschieden und nicht getestet. Prismamed Agents und Handys mit einer http://-Adresse würden TCMSOFT dann nicht mehr erreichen. Vor einer solchen Änderung beim TCMSOFT-Support nachfragen.