Mein QNAP-NAS soll per eingebautem S3-Sync einen Teil der Daten regelmäßig mit Amazon S3 syncen. Das Ganze funktionierte 15 Monate rock solid bis plötzlich seit ein paar Tagen regelmäßig Authentifikatons-Fehler den Sync unmöglich machten.
An diesem Wochenende hatte ich endlich mal Zeit, mich darum zu kümmern.
Da ich an dem entsprechenden Teil der Konfiguration meines NAS nichts geändert und auch kein Update eingespielt hatte und auch kein Crash oder ähnliches Ereignis eingetreten war, war das Feld der möglichen Ursachen weit gesteckt und ich konnte zunächst nur die üblichen Checklisten abarbeiten:
- Die Sync-Tasks waren noch vorhanden. (Klar, sonst hätte es ja keine Fehlermeldungen gegeben; aber trotzdem…)
- Für Access Key ID und Secret Access Key waren Werte gesetzt.
- Im IAM-Bereich der AWS-Konsole war der entsprechenden Key-Satz aktiv gesetzt.
- Der entsprechende User1 konnte über die AWS-Konsole2 auf das entsprechenden Bucket und die Ordnerstruktur darunter zugreifen.
- Auch mit einem anderen Schlüsselsatz sowie einem frisch generierten Schlüsselsatz war ein Zugriff nicht möglich.
- Mit dem zweiten Schlüsselsatz war mit Transmit ebenfalls ein Zugriff auf die Daten möglich.
- Obwohl wegen der erfolgreichen Zugriffs über die Konsole und per App kein Problem der Zugriffsberechtigung sein konnte, richtet ich testweise einen vollen S3-Zugang für den User ein. Ebenfalls erfolglos.
- Laut den S3-Logs für das spezielle Bucket hatte alles bis zum 30.03.2014 (frühmorgens)3 funktioniert. Danach gab es keine Einträge und damit auch Hinweise auf mögliche Probleme.
- Ratlosigkeit. :-O
Wie oft in solcher Situation, zog ich Google zu rate. Beim dritten Versuch, landete ich bei diesem Forumseintrag. Sommerzeit! 30.03.2014!
Ein kurzes date
in der Konsole vom NAS zeigte, was ich auch im Web-Front-End hätte sehen können: Das NAS lief noch auf Winterzeit.
Per Klick im Web-Front-End schnell die Zeit per ntp-Zugriff gestellt und Alles funktioniert wieder.4
- Für jedes Gerät bzw. automatisierten Dienst richte ich im IAM einen extra User mit entsprechend eingeschränkten Rechten ein. Sofern das Gerät bzw. der Dienst mal kompromitiert wird, lässt sich im Optimalfall der Schaden dadurch begrenzen und ich kann den User bzw. den betroffenen Key-Satz einfach löschen. ↩
- War mal wieder ein interessantes und auch etwas frustriedendes Gefummel, wie die unterschiedlichen Zugriffe aus die AWS-Konsole als “echter” User und als IAM-(Unter)-User funtkionieren. ↩
- Hier hätte es klingeln können… ↩
- Nicht ganz. Ich hatte in der IAM-Konsole den bisher verwendeten Access Key (unnötigerweise) gelöscht und die Tests mit einem neuen Test-Sync-Auftrag durchgeführt. Die eigentlichen Sync-Aufträge hatten noch den alten, nun gelöschten Key-Satz und liefen daher auf einen neuen Authentifikations-Fehler. Der war dann mit einer Copy-Pasta-Orgie schnell gefixt. ↩