So, nachdem ich auch einiges probiert habe, wollte ich kurz hier mitteilen wie es bei mir jetzt funktioniert.
Nachdem ich zuletzt mit einer DS211j zu tun hatte mußte ich mich bei der DS1812+ erstmal in die neuere Filesystem-Struktur einarbeiten.
- Mein SSL-Zertifikat habe ich von StartSSL.com (Class 1 server). Welche Unterschiede bei der eigenen CA, cert und key auftreten habe ich jetzt nicht getestet. crt/key habe ich via "Web-Interfache - Kontrollzentrum - DSM Einstellungen - HTTP-Dienst - Zertifikate" importiert.
- Meine Versuche beziehen sich auf die Installation des .spk aus dem "unzureichende" repository (
http://spk.unzureichende.info/)
http://www.synology-forum.de/showth....9-.spk-(x86)-alpha-Test&highlight=pyload+ssl
- Ebenfalls empfehlenswert ist der Config File Editor von (
http://www.mertymade.com/syno/#cfe)
Pfade:
- Meine via DSM importierten Zertifikate/Schlüssel sind hier gelandet
Rich (BBCode):
/usr/syno/etc/ssl/ssl.key/server.key
/usr/syno/etc/ssl/ssl.crt/server.crt
- Das Pyload Config Verzeichnis liegt bei mir unter
Rich (BBCode):
/volume1/@appstore/pyload/var/config/
Versuche:
Ich war schon fast soweit das spk wieder runter zu schmeißen und via IPKG eine manuelle Installation zu machen. Habe es aber dann doch noch einmal versucht. Mein Problem war die ganze Zeit, dass ich die Schlüssel auf der DS nicht gefunden hatte bzw. auch nicht wußte welche Schlüssel dann pyload verwendet. Zudem wollte ich eigentlich vermeiden weitere SSL Schlüssel benutzen zu müssen.
Experimentiert hatte ich mit symbolischen links aus dem Config in das ssl Verzeichnis und Manipulationen an der pyload config.
Das scheint aber entweder am DSM, Integration des spk oder anderen Dingen zu scheitern.
Am Ende bin ich jetzt aber bei folgendem gelandet:
Meine Lösung:
- login als root via ssh
- Kopiere server.crt/key aus dem ssl Verzeichnis als ssl.crt/key in das pyload config Verzeichnis
- Auszug aus meiner pyload config dazu sieht aus (standard)
Rich (BBCode):
remote - "Remote":
bool nolocalauth : "No authentication on local connections" = True
bool activated : "Activated" = False
int port : "Port" = 7227
ip listenaddr : "Adress" = 0.0.0.0
ssl - "SSL":
file cert : "SSL Certificate" = ssl.crt
bool activated : "Activated" = True
file key : "SSL Key" = ssl.key
webinterface - "Webinterface":
str template : "Template" = default
bool activated : "Activated" = True
str prefix : "Path Prefix" =
builtin;threaded;fastcgi;lightweight server : "Server" = threaded
ip host : "IP" = 0.0.0.0
bool https : "Use HTTPS" = True
int port : "Port" = 8000
Vorteile:
- Ich kann wieder per https auf meinen pyload-server zugreifen und dies auch von außerhalb (ohne hätte ich am Apache rum-doktorn müssen um einen Zugriffsschutz zu bekommen (was ich vielleicht zusätzlich noch mache)
Nachteile:
- Ich muß bei Erneuerungen des Zertifikats immer dran denken die Dateien erneut zu duplizieren
- Ob der Zugang via "Remote" klappt habe ich nicht probiert (habe ich noch nie benutzt, weil ich immer "remote-https" nehme). pyload läßt sich jedenfalls auch bei Einstellung "True" ohne Fehlermeldung (Package-Center, pyload, Protokoll anzeigen) starten.
- Ich weiß noch nicht, ob bei meiner wiederholten Installation des pyload.spk evtl. bei dessen Installation was daneben gegangen ist (weil ich glaube mich zu entsinnen, dass von Anfang an ein ssl.key/crt in dessen config Verzeichnis lag. Wo kam das her?).
So, jetzt mache ich mich mal dran meine Accounts etc. einzutragen und zu sehen ob dies nur ein Phyrrus-Sieg war oder der Rest jetzt ganz normal funktioniert wie auf meinem headless-ubuntu-server.
Fusion
