Im Dezember wurden von Synology zwei kritische Sicherheitsupdates veröffentlicht die ich natürlich eingespielt habe. Dabei handelt es sich um die Updates 6.2.1 23824-3 / 23824-4. Nach der erfolgreichen, oder wie sich später herausstellte weniger erfolgreichen Installation liefen auf meiner DS718+ keine Dienste mehr, die auf den Nginx Server aufsetzen.
Nach dem DSM Update 6.2.1.23824-4 hatte ich keinen Zugriff mehr auf CalDAV und die Web Oberfläche des Kalenders. Alle angeschlossenen Geräte (iOS, macOS, Android, FHEM) verweigern geschlossen die Synchronisation. Das war die erste Diagnose mit der ich mich auch an den Synology Support gewandt hatte. Im weiteren Verlauf der Fehlersuche stellte sich heraus, das alle Dienste betroffen waren die Nginx als Unterlage benutzen. Kalender, Photostation, Audiostation oder auch der ReverseProxy waren nicht mehr zu erreichen.
Das Update Log und das messages.log förderten nicht viel zu Tage. Das Update war erfolgreich durchgelaufen und in der messages stand nichts verwertbares.
2019/01/03 05:02:46 Start of the update...
2019/01/03 05:03:30 Start of the update...
2019/01/03 05:03:30 Start of the update...
2019/01/03 05:03:30 Upgrade from version 6.2.23739 to version 6.2.1.23824
2019/01/03 05:04:12 Congratulations!! The update has been completed!! Do configupdate when next bootup.
2019/01/03 05:06:53 Update Config Event: rootfs_ready
2019/01/03 05:06:53 Update Type: upgrade
2019/01/03 05:07:18 Update Config Event: volume_ready
2019/01/03 05:07:18 Update Type: upgrade
2019/01/03 05:07:22 Update Config Event: share_ready
2019/01/03 05:07:22 Update Type: upgrade
2019/01/03 05:07:54 start critical update to buildnumber: 23824 original smallfixnumber: 1 new_smallfixnumber: 4 build date: 2018/12/25
2019/01/03 05:07:55 Start of the update...
2019/01/03 05:07:56 Failed to accomplish the update! (errno = 57)
2019/01/03 05:18:34 start critical update to buildnumber: 23824 original smallfixnumber: 1 new_smallfixnumber: 4 build date: 2018/12/25
2019/01/03 05:18:34 Start of the update...
2019/01/03 05:18:42 Congratulations!! The update has been completed!! Do configupdate when next bootup.
2019/01/03 05:19:03 Finished apply small update!
2019/01/03 05:19:03 Finished update before reboot!
Nachdem ich festgestellt hatte, dass der Fehler beim Nginx lag, konnte ich schon einmal in das entsprechende error.log sehen. Mich begrüßte eine Fehlermeldung vom Start des Nginx Servers.
2019/01/05 16:51:07 [emerg] 21802#21802: BIO_new_file("/run/le_cert_8kXidb.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/run/le_cert_8kXidb.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
In dieser Fehlermeldung wurde auf ein Zertifikat verwiesen das nicht vorhanden ist oder nicht gelesen werden konnte. Eine Suche auf der Synology fand das Zertifikat nicht. Da die Zertifikate beim Start des Nginx geladen werden habe ich mir die Konfigurationen im Pfad /etc/nginx angesehen. Ein Paar Konfigurationen hatte ich ja dort für den ReverseProxy erstellt. Es viel aber sofort eine Konfiguration auf, die ich dort nicht gespeichert hatte. Die Konfiguration mit dem Namen le_1VUUbY.conf enthielt dann auch den Verweis auf das fehlende Zertifikat. Also habe ich die Konfiguration mal aus dem Ordner verschoben und et voila schon starteten alle Dienste wieder einwandfrei. Die Konfiguration umbenennen funktioniert hier nicht, da alles was in diesem Pfad steht vom Nginx eingelesen wird.
Nachdem alle Dienste wieder liefen konnte ich alles testen. Dabei viel noch auf, das die Authentifikation am Nginx nicht funktionierte. Das Logbuch verwies auf eine fehlende basic_auth hin. Ein Blick in den Ordner zeigte das die Datei verschwunden war. Diese hatte ich bis vor dem Update aber mit Sicherheit in Benutzung und ich hatte diese Datei mit Sicherheit nicht selber gelöscht. Es kann nur bei dem letzten Update gelöscht worden sein. Also schnell noch die basic_auth mit
htpasswd -c /etc/nginx/basic_auth <Benutzername>
angelegt. Damit funktioniere die Authentifikation auch wieder.
Leider muss man mit diesen Problemen leben wenn man die Konfiguration im "Maschinenenraum" (an der Konsole) der Synology ändert. Damit rechnen die Entwickler nicht und Zack ist die eigene Konfiguration im Eimer.
In Zukunft werde ich mir auch von diesem Ordner eine Sicherung anfertigen und wenn nötig die mit der neuen vergleichen bzw zurückspielen.
Kommentare powered by CComment