Just another Techblog
Commandline tool gallery-dl (bspw. via brew auf macOS installieren)
gallery-dl https://x.com/$PROFILE/media -u $USER -p $PASSWORDWenn 2. Faktor benötigt wird, bspw. Login & Cookies des Browsers nutzen:
gallery-dl https://x.com/$PROFILE/media -u $USER -p $PASSWORD --cookies-from-browser VivaldiSituation: Zwei Synology-NAS, deren „Freigegebene Ordner“ via Synology Drive ShareSync zwecks Backup synchronisiert werden. Setup ist seit Jahren in dieser Form existent.
Nun Austausch der Hardware (Backup-NAS / Zielsystem) und Upgrade von Version 6.x auf 7.x. (Quellsystem) werden die Dateien offensichtlich wie gewohnt synchronisiert, wobei der Sync eines einzelnen „Freigegebenen Ordners“ auch nach langer Wartezeit zu keinem Abschluss kommt.
Der Status in der Adminoberfläche bleibt stetig bei „Synchronisierung läuft…“ und es werden lt. Synchronisierungsprotokoll (in der GUI) keine weiteren Dateien übertragen.
Zahlreiche Tests mit Ordnern und wenigen Dateien sind stets erfolgreich. Lange Verzeichnis- oder Dateinahmen (vgl. Lange Dateinamen unter Linux finden) sind nicht existent. Tests mit div. Sonderzeichen sind alle erfolgreich. Ein Fehler in Zusammenhang mit Dateiberechtigungen konnte nicht festgestellt werden.
Im Zuge weiterer manueller Tests wurde festgestellt, dass gewisse Ordner in verschiedenen Varianten der Groß-/Kleinschreibung existieren. Das eingesetzte Dateisystem Btrfs unterstütz dies grundsätzlich. Der Sync schlägt jedoch genau bei diesen gleichbenannten Ordnern mit unterschiedlicher Groß-/Kleinschreibung fehl bzw. kommt zu keinem Abschluss. Nach Konsolidierung der Ordner wurde der Sync erfolgreich durchgeführt und abgeschlossen.
Fehler:
NAKIVO Backup & Replication v10.7.1:
System
12 Jan at 11:00 (UTC +01:00) The "NAKIVO Backup & Replication" application is about to run out of memory
Allocate more memory to the "NAKIVO Backup & Replication" application.Lösung:
# SVC_OPTIONS="-Dfile.encoding=UTF-8 -server -XX:+AggressiveOpts -XX:-OmitStackTraceInFastThrow -Xss512k -Xms256m -Xmx2g"
SVC_OPTIONS="-Dfile.encoding=UTF-8 -server -XX:+AggressiveOpts -XX:-OmitStackTraceInFastThrow -Xss1024k -Xms512m -Xmx4g"Quellen:
UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.
Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:
#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done
Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:
PubkeyAcceptedKeyTypes +ssh-dss
Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:
ssh -oHostKeyAlgorithms=+ssh-dss
Quellen:
OpenSSH