Bitwarden SSL erreichbar machen

macben

Benutzer
Mitglied seit
30. Jan 2013
Beiträge
159
Punkte für Reaktionen
0
Punkte
16
Hallo Zusammen,

ich habe mich entschieden Bitwarten als Passwortmanager einzusetzen. Nun möchte Bitwarden gerne eine SSL Verschlüsselung :)
Bitwarden habe ich in Docker installiert und dort folgende Einstellungen getätigt, welche man im Bild sieht.

Mittlerweile habe ich es hinbekommen, dass die Synology über SSL erreichbar ist - hierfür habe ich mir ein Zertifikat bei LE erstellt.
Nun ist Bitwarden zwar von extern über domain.de:5151 erreichbar aber eben nicht mit der App da diese eine SSL Verschlüsselung benötigt.

Ich habe im Docker schon den Port 80 auf 443 abgeändert, aber dies hat keinen Erfolg gebracht.

Wie kann ich denn den Port 5151 SSL verschlüsseln bzw. dann verschlüsselt auf den Docker Container zugreifen?

Danke Euch!
 

Anhänge

  • 2020-06-21_19-17-14.png
    2020-06-21_19-17-14.png
    212,9 KB · Aufrufe: 153

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Kannst probieren einen Reverse Proxy anzulegen (Systemsteuerung > Anwendungsportal) für einen Hostnamen und https und dir dafür ein LE Zertifikat holen.
Weitergeleitet auf localhost, http und 5151 (Container intern 80)
 

macben

Benutzer
Mitglied seit
30. Jan 2013
Beiträge
159
Punkte für Reaktionen
0
Punkte
16
Kann ich dafür nicht das vorhandene LE nehmen?

Weil welche Domain soll ich sonst eintragen? Wenn ich eine Subdomain vom Hoster nehme und wird es nicht funktionieren oder?
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Hängt davon ab wie deine Domain eingerichtet ist und wie die Auflösung auf deinen Anschluss erfolgt.
Prinzipiell spricht aber nichts gegen eine Subdomain.

Du kannst auch die vorhandene Domain nehmen wie sie eingerichtet ist. Aber dann antwortet auf diesen Hostname eben nur noch der Bitwarden Reverse Proxy. Der DSM oder der allgemeine Webserver ist damit nicht mehr erreichbar dann.
 

macben

Benutzer
Mitglied seit
30. Jan 2013
Beiträge
159
Punkte für Reaktionen
0
Punkte
16
Mhm ok dann doch eher die Subdomain.
Auf was sollte ich die Subdomain dann weiterleiten bzw wie sollte ich sie einrichten?

Wenn ich Name.synology.me nehme - so gelange ich aktuell auf die Synology ist es für LE ungünstig bzw für alles ungünstig oder?

Die Synology hängt hinter einer Fritzbox, falls dies wichtig ist.
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Hast du eine eigene Domain oder nur die dynDNS Adresse von synology.me?

Falls letzteres könnte es einfacher sein zu schauen, ob man den Docker Container eventuell doch auf https getrimmt bekommt.
Eine zweite synology.me habe ich noch nie auf ein und derselben DS probiert. Kannst ja selber schnell probieren ob das geht.

Alternativ wäre dann entweder den myfritz von AVM oder einen anderen dynDNS Dienst zu nehmen um an eine zweite Adresse zu kommen, wenn man keine eigene Domain mit Subdomains besitzt.
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.159
Punkte für Reaktionen
912
Punkte
424
Dann ist es ja nur eine Frage von dynDNS, Subdomain und CNAME Einträgen im DNS beim Domainanbieter, dass verschiedene Subdomains alle auf deinem Anschluss landen und du mehrere Hostnames zur Verfügung hast.
 

King3R

Benutzer
Mitglied seit
14. Mrz 2017
Beiträge
361
Punkte für Reaktionen
82
Punkte
28
Eine eigene vollwertige Domain ist vorhanden.
Hast du auch vollen Zugriff auf die DNS-Einstellungen deiner Domain? Wenn ja, sollte es ein Leichtes mit den von Fusion besagten Mitteln (DDNS, Subdomain und CNAME) sein. Läuft bei mir auch so. Hast du das LE-Zertifikat für deine Domain auf der Diskstation bezogen?

Wie ich in dem anderen ähnlichen Thread "https Aufruf nicht möglich" schon unter Beitrag #4 geschrieben habe, gibt es HIER eine Anleitung auf dem Github-Repository von Bitwarden_RS. Vielleicht hast du den Link ja einfach nur übersehen ...

Die Kurzfassung (Wie ICH es gemacht habe.):
  • DynDNS (ddns.example.org) vorzugsweise auf dem Router einrichten.
  • Port 80/443 vom Router auf die Diskstation weiterleiten.
  • In den DNS-Einstellungen der eigenen Domain über CNAME ein Subdomain (bw.example.org) auf die DynDNS-Adresse (ddns.example.org) weiterleiten.
  • Für die Subdomain (bw.example.org) eine Zertifikat beantragen.
    • Variante 1: In der Diskstation über Systemsteuerung > Sicherheit > Zertifikat ein neues Zertifikat beantragen
    • Varinate 2: Bei deinem Domain-Verwalter ein Zertifikat für die besagte Domain beantragen und dann in die Diskstation importieren.
  • Das Zertifikat in einem Ordner abspeichern, auf den der Docker-Container Zugriff hat, z.B. /volume1/docker/ssl
    • Variante 1: Zertifikat aus der Zertifikat-Verwaltung exportieren, die .zip öffnen und den Inhalt in den erstellten Ordner entpacken.
      Nachteil: Bei LE-Zertifikaten muss das alle 3 Monate durchgeführt werden.
    • Variante 2: Das Zertifikat beim Domain-Verwalter exportieren und gleiches Spiel wie oben.
      Nachteil: wie oben
    • Variante 3: Alle Zertifikate aus der Zertifikatverwaltung liegen unter /usr/syno/etc/certificate/_archive/. Man muss erst ermitteln, welches das Richtige ist. Dazu einfach das benötigte Zertifikat als Standard definieren. Somit wird es unter /usr/syno/etc/certificate/DEFAULT/ abgelegt. Der dort beinhaltete Ordner ist aber auch unter /usr/syno/etc/certificate/_archive/ vorhanden. Falls es kein Wildcard-Zertifikat ist, sollte man als weiterhin auf /usr/syno/etc/certificate/_archive/ verlinken, da sich das Standard-Zertifikat ja ändern kann. Man erstellt einen Symlink auf dieses Verzeichnis über
      Rich (BBCode):
      ln -s /usr/syno/etc/certificate/_archive/ /volume1/docker/ssl/
      Leider ist dieser Symlink nach einem Neustart nicht mehr vorhanden. Man können den Befehl aber über den Aufgabenplaner regelmäßig bzw. bei Neustart ausführen lassen.
      Vorteil: Kommt ohne kopieren aus, sofern man das Zertifikat über der Zertifikatverwaltung der Diskstation bezieht.
  • Jetzt den Docker-Container erstellen:
    Rich (BBCode):
    docker run -d --name bitwarden \
    -e ROCKET_TLS='{certs="/ssl/certs.pem",key="/ssl/key.pem"}' \ Die Bezeichnungen von certs.pem / key.pem müssen ggf. angepasst werden.
    -v /volume1/docker/ssl/:/ssl/ \ Die Ordner müssen ggf. auch angepasst werden, je nachdem wo du sie erstellt hast.
    -v /volume1/docker/bitwarden/bw-data/:/data/ \ Die Ordner müssen ggf. auch angepasst werden, je nachdem wo du sie erstellt hast.
    -p 55555:80 \ Ich würde einen hohen 5-stelligen Port verwenden.
    bitwardenrs/server:latest
  • Jetzt muss über den Reverse Proxy (Systemsteuerung > Anwendungsportal > Reverse Proxy) noch ein Eintrag erfolgen.
    Rich (BBCode):
    Bescheibgung: z.B. Docker - Bitwarden
    Quelle:
    Protokoll: HTTPS
    Hostname: bw.example.org
    Port: 443
    HTTP/2 aktivieren
    
    Ziel:
    Protokoll: HTTP
    Hostname: localhost oder die IP der Diskstation
    Port: 55555
Sofern ich nichts vergessen habe, sollte dein Bitwarden-Container nun extern unter bw.example.org aufrufbar sein. Des Weiteren sollte der Zugriff über die mobilen Apps funktionieren. Außerdem habe ich nach außen nur die beiden Ports 80/443 offen.
 
  • Like
Reaktionen: macben

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
-e ROCKET_TLS='{certs="/ssl/certs.pem",key="/ssl/key.pem"}' \ Die Bezeichnungen von certs.pem / key.pem müssen ggf. angepasst werden.
-v /volume1/docker/ssl/:/ssl/ \ Die Ordner müssen ggf. auch angepasst werden, je nachdem wo du sie erstellt hast.

Wenn der Reverse-Proxy den Container nur über http anspricht, dann kann man diese Angaben sparen. Werden eh nicht genutzt.
 

adahmen

Benutzer
Mitglied seit
12. Okt 2009
Beiträge
561
Punkte für Reaktionen
11
Punkte
38
Hallo Zusammen,

ich habe es komplett ohne Reverse-Proxy am laufen. Dabei ist Bitwarden per SSL unter dem Port 444 zu erreichen (dabei ist der Port 444 auf 8443 im Container gemappt).

In der config.yml von Bitwarden sind folgende Einträge:

Rich (BBCode):
# 
# Docker compose file port mapping for HTTP. Leave empty to remove the port mapping.
# Learn more: https://docs.docker.com/compose/compose-file/#ports
http_port: 81
# 
# Docker compose file port mapping for HTTPS. Leave empty to remove the port mapping.
# Learn more: https://docs.docker.com/compose/compose-file/#ports
https_port: 444
# 
# Docker compose file version. Leave empty for default.
# Learn more: https://docs.docker.com/compose/compose-file/compose-versioning/
compose_version: 
# 
# Configure Nginx for SSL.
ssl: true
# 
# SSL versions used by Nginx (ssl_protocols). Leave empty for recommended default.
# Learn more: https://wiki.mozilla.org/Security/Server_Side_TLS
ssl_versions: 
# 
# SSL ciphersuites used by Nginx (ssl_ciphers). Leave empty for recommended default.
# Learn more: https://wiki.mozilla.org/Security/Server_Side_TLS
ssl_ciphersuites: 
# 
# Installation uses a managed Let's Encrypt certificate.
ssl_managed_lets_encrypt: false
# 
# The actual certificate. (Required if using SSL without managed Let's Encrypt)
# Note: Path uses the container's ssl directory. The `./ssl` host directory is mapped to
# `/etc/ssl` within the container.
ssl_certificate_path: /etc/ssl/www.meinedomain.org/certificate.crt
# 
# The certificate's private key. (Required if using SSL without managed Let's Encrypt)
# Note: Path uses the container's ssl directory. The `./ssl` host directory is mapped to
# `/etc/ssl` within the container.
ssl_key_path: /etc/ssl/www.meinedomain.org/private.key
# 
# If the certificate is trusted by a CA, you should provide the CA's certificate.
# Note: Path uses the container's ssl directory. The `./ssl` host directory is mapped to
# `/etc/ssl` within the container.
ssl_ca_path: /etc/ssl/www.meinedomain.org/ca.crt


Und dann läuft noch folgendes Script einmal am Tag um zu prüfen, ob die DS ein neues Zertifikat von LetsEncrypt hat (das Script ist nicht von mir, sondern hier aus dem Forum):

Rich (BBCode):
#!/bin/bash
# domain certificate is valid for
    domain=www.meinedomain.org

# bitwarden certificate folder
    bitwarden_certs=/volume2/docker/bitwarden/bwdata/ssl/${domain}

# targetname of the crt and key file in the certificate folder
    bitwarden_crt=certificate.crt
    bitwarden_cacrt=ca.crt
    bitwarden_key=private.key


# uid:gid used to change ownership in certificate folder
    uid=root
    gid=root

# name of the docker image to restart
    image=bitwarden/nginx

for current_domain_cert in /usr/syno/etc/certificate/_archive/*; do
    if [ -d ${current_domain_cert} ] && [ -f ${current_domain_cert}/cert.pem ];then
        openssl x509 -in ${current_domain_cert}/cert.pem -text | grep DNS:${domain} > /dev/null 2>&1
        domain_found=$?
        if [ "${domain_found}" = "0" ]; then
            # time of last file change, seconds since Epoch
            last_change_cert_key=$(stat -c %Y ${current_domain_cert}/privkey.pem)
            if [ -f ${bitwarden_certs}/${bitwarden_key} ];then
                last_change_bitwarden_cert_key=$(stat -c %Y ${bitwarden_certs}/${bitwarden_key})
            else
                last_change_bitwarden_cert_key=0
            fi
            if [ ${last_change_bitwarden_cert_key} -le ${last_change_cert_key} ]; then
            
                echo "bitwarden ssl certificate is outdated… updating from domain certificate"
                cp ${current_domain_cert}/privkey.pem ${bitwarden_certs}/${bitwarden_key}
                cp ${current_domain_cert}/cert.pem ${bitwarden_certs}/${bitwarden_crt}
                cp ${current_domain_cert}/chain.pem ${bitwarden_certs}/${bitwarden_cacrt}
                # original:            cat ${current_domain_cert}/cert.pem ${current_domain_cert}/fullchain.pem > ${bitwarden_certs}/${bitwarden_crt}

                echo "changing ownership of gitlab certificates"
                chown ${uid}:${gid} ${bitwarden_certs}/*
                chmod 444 ${bitwarden_certs}/*

                echo "restarting bitwarden-nginx container to activate new certificate"
                container_id=$(docker ps | grep "${image}" | cut -c1-12)
                docker stop ${container_id}
                docker start ${container_id}
                echo "bitwarden ssl certificate update"

            else
                echo "nothing to do, bitwarden ssl certifiacte is same or newer than the domain ssl certificate"
            fi
        fi
    fi
done

So läuft es bei mir seit vielen vielen Monaten.
"Nachteil" -- Bitwarden ist nicht per Sub-Domain erreichbar und man muss immer den Port 444 mit angeben.
 

King3R

Benutzer
Mitglied seit
14. Mrz 2017
Beiträge
361
Punkte für Reaktionen
82
Punkte
28
Wenn der Reverse-Proxy den Container nur über http anspricht, dann kann man diese Angaben sparen. Werden eh nicht genutzt.
Du hast natürlich Recht. Der Reverse Proxy Eintrag muss wie nachfolgend aussehen.
Rich (BBCode):
Bescheibgung: z.B. Docker - Bitwarden
Quelle:
Protokoll: HTTPS
Hostname: bw.example.org
Port: 443
HTTP/2 aktivieren

Ziel:
Protokoll: HTTPS
Hostname: localhost oder die IP der Diskstation
Port: 55555

Hallo Zusammen,

ich habe es komplett ohne Reverse-Proxy am laufen. Dabei ist Bitwarden per SSL unter dem Port 444 zu erreichen (dabei ist der Port 444 auf 8443 im Container gemappt).

Du nutzt aber den offiziellen Bitwarden-Container und nicht Bitwarden_RS-Container, oder?
 

adahmen

Benutzer
Mitglied seit
12. Okt 2009
Beiträge
561
Punkte für Reaktionen
11
Punkte
38
Korrekt ... ich nutze die offizielle Version.
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Das Skript war ursprünglich mal von mir. Schön das es noch Verwendung findet :)

Euch beiden ist schon klar, dass wenn ihr im Reverse-Proxy TLS-Terminiert, der BW-Container überhaupt kein TLS-Zertifikat verwenden muss oder? Statt das Ziel-Protokoll auf HTTPS zu ändern, meinte ich eigentlich lass BW auf http stehen und entfernt die ROCKET_TLS Variable und das Bind-Mount Volume für das Zertifikate-Verzeichnis. Man macht sich sonst nur unnötig Zusatzaufwand.
 
  • Like
Reaktionen: Fusion

King3R

Benutzer
Mitglied seit
14. Mrz 2017
Beiträge
361
Punkte für Reaktionen
82
Punkte
28
Das ist mir bewusst, leider funktioniert das beim Bitwarden-RS-Container nur für den Webzugang. Jedoch bekommt man damit nicht die mobilen Apps zum laufen. Ohne hinterlegtes Zertifikat im Container bekommt man mit den Bitwarden-Apps für iOS und Android keine Zugriff auf den Server. Bei z. B. Enpass kann man die Zertifikatüberprüfung überspringen, das ist leider bei Bitwarden nicht vorgesehen. Wie gesagt, meine Aussage bezieht sich auf den Container von Bitwarden_RS, nicht auf den Offiziellen.
 

macben

Benutzer
Mitglied seit
30. Jan 2013
Beiträge
159
Punkte für Reaktionen
0
Punkte
16
Hast du auch vollen Zugriff auf die DNS-Einstellungen deiner Domain? Wenn ja, sollte es ein Leichtes mit den von Fusion besagten Mitteln (DDNS, Subdomain und CNAME) sein. Läuft bei mir auch so. Hast du das LE-Zertifikat für deine Domain auf der Diskstation bezogen?

Wie ich in dem anderen ähnlichen Thread "https Aufruf nicht möglich" schon unter Beitrag #4 geschrieben habe, gibt es HIER eine Anleitung auf dem Github-Repository von Bitwarden_RS. Vielleicht hast du den Link ja einfach nur übersehen ...

Die Kurzfassung (Wie ICH es gemacht habe.):
  • DynDNS (ddns.example.org) vorzugsweise auf dem Router einrichten.
  • Port 80/443 vom Router auf die Diskstation weiterleiten.
  • In den DNS-Einstellungen der eigenen Domain über CNAME ein Subdomain (bw.example.org) auf die DynDNS-Adresse (ddns.example.org) weiterleiten.
  • Für die Subdomain (bw.example.org) eine Zertifikat beantragen.
    • Variante 1: In der Diskstation über Systemsteuerung > Sicherheit > Zertifikat ein neues Zertifikat beantragen
    • Varinate 2: Bei deinem Domain-Verwalter ein Zertifikat für die besagte Domain beantragen und dann in die Diskstation importieren.
  • Das Zertifikat in einem Ordner abspeichern, auf den der Docker-Container Zugriff hat, z.B. /volume1/docker/ssl
    • Variante 1: Zertifikat aus der Zertifikat-Verwaltung exportieren, die .zip öffnen und den Inhalt in den erstellten Ordner entpacken.
      Nachteil: Bei LE-Zertifikaten muss das alle 3 Monate durchgeführt werden.
    • Variante 2: Das Zertifikat beim Domain-Verwalter exportieren und gleiches Spiel wie oben.
      Nachteil: wie oben
    • Variante 3: Alle Zertifikate aus der Zertifikatverwaltung liegen unter /usr/syno/etc/certificate/_archive/. Man muss erst ermitteln, welches das Richtige ist. Dazu einfach das benötigte Zertifikat als Standard definieren. Somit wird es unter /usr/syno/etc/certificate/DEFAULT/ abgelegt. Der dort beinhaltete Ordner ist aber auch unter /usr/syno/etc/certificate/_archive/ vorhanden. Falls es kein Wildcard-Zertifikat ist, sollte man als weiterhin auf /usr/syno/etc/certificate/_archive/ verlinken, da sich das Standard-Zertifikat ja ändern kann. Man erstellt einen Symlink auf dieses Verzeichnis über
      Rich (BBCode):
      ln -s /usr/syno/etc/certificate/_archive/ /volume1/docker/ssl/
      Leider ist dieser Symlink nach einem Neustart nicht mehr vorhanden. Man können den Befehl aber über den Aufgabenplaner regelmäßig bzw. bei Neustart ausführen lassen.
      Vorteil: Kommt ohne kopieren aus, sofern man das Zertifikat über der Zertifikatverwaltung der Diskstation bezieht.
  • Jetzt den Docker-Container erstellen:
    Rich (BBCode):
    docker run -d --name bitwarden \
    -e ROCKET_TLS='{certs="/ssl/certs.pem",key="/ssl/key.pem"}' \ Die Bezeichnungen von certs.pem / key.pem müssen ggf. angepasst werden.
    -v /volume1/docker/ssl/:/ssl/ \ Die Ordner müssen ggf. auch angepasst werden, je nachdem wo du sie erstellt hast.
    -v /volume1/docker/bitwarden/bw-data/:/data/ \ Die Ordner müssen ggf. auch angepasst werden, je nachdem wo du sie erstellt hast.
    -p 55555:80 \ Ich würde einen hohen 5-stelligen Port verwenden.
    bitwardenrs/server:latest
  • Jetzt muss über den Reverse Proxy (Systemsteuerung > Anwendungsportal > Reverse Proxy) noch ein Eintrag erfolgen.
    Rich (BBCode):
    Bescheibgung: z.B. Docker - Bitwarden
    Quelle:
    Protokoll: HTTPS
    Hostname: bw.example.org
    Port: 443
    HTTP/2 aktivieren
    
    Ziel:
    Protokoll: HTTP
    Hostname: localhost oder die IP der Diskstation
    Port: 55555
Sofern ich nichts vergessen habe, sollte dein Bitwarden-Container nun extern unter bw.example.org aufrufbar sein. Des Weiteren sollte der Zugriff über die mobilen Apps funktionieren. Außerdem habe ich nach außen nur die beiden Ports 80/443 offen.


Ich habe nun folgendes getan:
- Subdomain per CNAME auf eine DynDns eingerichtet
- Port 80 und 443 im Router freigegeben
- LE Zertifikat über die Synology erstellen lassen
- LE Zertifikat als Standard ausgewählt

Doch wo gebe ich dann den Code
Rich (BBCode):
ln -s /usr/syno/etc/certificate/_archive/ /volume1/docker/ssl/
ein? Und wo finde ich den Aufgabenplaner?

EDIT: Aufgabenplaner habe ich gerade gefunden. Und wenn ich es richtig verstanden habe, dann ist es ein "Ausgelöste Aufgabe" und den Befehl dann einfach bei "Benutzerdefiniertes Script" eintragen und als Ereignis "hochfahren" auswählen.

Und danach kommen die nächsten Fragezeichen :) Ich habe ja den Dockercontainer schon erstellt, wenn ich dann den Code für den Dockercontainer ausführe, lösche ich dann den vorhandenen Container? Und wo gebe ich den Code dann wieder ein?

Danke Euch für die Hilfe!
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
@King3R: Du hast im Grunde genommen eine TLS-Verbindung von aussen bis zum Reverse-Proxy - dort wird sie terminiert und Du baust eine weitere TLS-Verbindung zwischen Reverse-Proxy und App im Container auf.

ich verwende den selben Container seit Jahren (der Maintainer hat irgendwann im letzen Jahr gewechselt) ohne TLS im Container (ich hatte das zu Beginn mal kurz auch mit). Und bei mir läuft der mit Yubikey, so dass zwingend HTTPS von aussen braucht wird. HTTPS wird bei mir am Reverse-Proxy terminiert und zum Container wird HTTP verwendet. Schnurrt wie ne Katze. Das einzige Szenario in dem TLS im Container notwendig ist, ist wenn man mutual TLS benötigt, sprich wenn Client und Server gegenseitig die Zertifikate prüfen - aber dann hat der Reverse-Proxy nichts mehr dazwischen verloren und afaik bietet Bitwarden diese funktionialität auch nicht an.

Wenn es für Dich der Weg zur Lösung ist, dann nutze ihn so. Für alle anderen: es geht auch ohne :)
 
  • Like
Reaktionen: theexciter

King3R

Benutzer
Mitglied seit
14. Mrz 2017
Beiträge
361
Punkte für Reaktionen
82
Punkte
28
Doch wo gebe ich dann den Code
Entweder über ssh (z. B. über Putty) oder über Systemsteuerung > Aufgabenplaner.
Im Aufgabenplaner dann einfach auf
  • Erstellen > Geplante Aufgabe > Benutzerdefiniertes Skript für eine einmale Ausführung.
  • Allgemein
    • Vorgang: Symlink SSL Docker
    • Aktiviert: Nein
  • Zeitplan
    • zurückliegendes Datum auswählen
    • nicht wiederholen auswählen.
  • Aufgabeneinstellungen
    • Benutzerdefiniertes Skript
      Rich (BBCode):
      ln -s /usr/syno/etc/certificate/_archive/ /volume1/docker/ssl/
  • mit OK bestätigen
  • Danach kann man sie ausführen.
oder
  • Erstellen > Ausgelöste Aufgabe > Benutzerdefiniertes Skript für eine Ausführung nach dem Start.
  • Allgemein
    • Vorgang: Symlink SSL Docker
    • Benutzer: root
    • Ereignis: Hochfahren
    • Aktiviert: Ja
  • Aufgabeneinstellungen
    • Benutzerdefiniertes Skript
      Rich (BBCode):
      sleep 30
      ln -s /usr/syno/etc/certificate/_archive/ /volume1/docker/ssl/
  • mit OK bestätigen
Und danach kommen die nächsten Fragezeichen :) Ich habe ja den Dockercontainer schon erstellt, wenn ich dann den Code für den Dockercontainer ausführe, lösche ich dann den vorhandenen Container? Und wo gebe ich den Code dann wieder ein?
Du brauchst den Container normalerweise nicht löschen. Einfach beenden und die Sachen über bearbeiten ändern. Danach den Container wieder starten.

Wenn es für Dich der Weg zur Lösung ist, dann nutze ihn so. Für alle anderen: es geht auch ohne :)
Hast du zufälligerweise auch die mobilen Apps in Benutzung? Ich bekomme es unter iOS ohne das Zertifikat im Container nicht ans Laufen. Der Webzugriff funktioniert über den Reverse Proxy, wie du es beschrieben hast. Auch ohne HTTPS von Reverse Proxy zum Container ... Da bin ich im Moment ein bisschen ratlos ...
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Ich verwende den Mobilzugang mit mehrern Android-Geräten (da klappt es mit dem Yubikey dank NFC auch).

Der Snyc zwischen Browser/Mobil und BW findet über ein Rest-Service statt. Bei Mobilgeräten kommt da noch der Push der Änderungen von BW zum Mobilgerät hinzu. Bei der Webanwendung geht der Push über Websockets, wenn man die entsprechende Reverseproxy-Regel definiert hat. Ohne Push geht es auch, nur stehen dann neue oder geänderte Datensätzen nicht sofort zur Verfügung.
 

King3R

Benutzer
Mitglied seit
14. Mrz 2017
Beiträge
361
Punkte für Reaktionen
82
Punkte
28
Kann sein, dass es an iOS liegt. Ich werde das Ganze nochmal testen, wenn ich Zeit habe und dann hier berichten.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat