Beiträge von TorstenS

  • [Howto] rsync QNAP zu Strato HiDrive

    Ich habe es jetzt geschafft das Remote Backup zu Strato HiDrive auch per ssh mit der QNAP Weboberfläche einzurichten. Dazu musste ich allerdings einige Dateien des QNAP-Systems editieren. Die Sache ist also mit einiger Vorsicht durchzuführen, und wer sich bezüglich seiner Linux Kenntnisse nicht sicher ist, sollte vieleicht lieber auf die Modifikation verzichten. Die Modifikationen habe ich an meinem QNAP TS-109 II Pro mit Firmwarestand 3.1.0 Build 0708T durchgeführt. Damit dieses How To auch für andere Modelle möglichst nützlich ist, habe ich versucht, meine Modifikationen so gut es geht allgemeingültig zu beschreiben.


    Zunächst einmal muss man wie von SebaBeer weiter oben beschrieben einen ssh Schlüssel generieren und den öffentlichen Teil beim HiDrive eintragen. Danach sollte ein Backup über die Kommandozeile ohne Abfrage eines Passwords möglich sein. Am besten legt man sich dazu sowohl auf dem QNAP, als auch auf dem HiDrive einen Testordner an. In meinem Beispiel „rsynctest“.


    Code
    # rsync  -avv /share/Public/rsynctest/ <user>@rsync.hidrive.strato.com:/users/<user>/rsynctestopening connection using: ssh -l <user> rsync.hidrive.strato.com rsync --server -vvlogDtpre.is . /users/<user>/rsynctestsending incremental file listdelta-transmission enabledHiRsync.txt is uptodatetotal: matches=0  hash_hits=0  false_alarms=0 data=0sent 75 bytes  received 18 bytes  37.20 bytes/sectotal size is 10  speedup is 0.11


    Jetzt sollte man das auch einmal per QNAP Web Administration einrichten. Natürlich noch ohne ssh. Der einzutragende Zielpfad muss als root/users/<user>/rsynctest angegeben werden.
    Achtung, der Pfad beginnt NICHT mit einem Schrägstrich und im HiDrive müssen unverschlüsselte Verbindungen zugelassen sein.


    Wenn das geklappt hat, existiert ein Eintrag in /etc/config/rsync_schedule.conf

    Code
    [Schedule2]ID = 2Name = rsynctestRemote Volume = root/users/toschRemote Path = /rsynctestLocal Volume = PublicLocal Path = /rsynctestProtocol = 100Remote IP = rsync.hidrive.strato.comUser Name = toschPassword = xxxxSchedule Type = 1Week = 0Month = 0Hour = 0Minute = 0Compressed = FalseIncremental = FalseDelete Extra = FalseStop Net = FalseUse of SSH = FalseSSH PORT = 22RSYNC PORT = 873RSYNC MODE = 1Status = 7Finished Time = 1302353037


    Wenn man einen Zeitplan für die Replikation angegeben hat, so existiert auch ein Eintrag in der crontab.


    Code
    # crontab -l# m h dom m dow cmd20 1 * * * /etc/init.d/rsyncRR.sh Schedule2 2>/dev/null


    Die Remote-Replikation wird also durch das Shell-Skript rsyncRR.sh gesteuert, welches sich die Parameter aus rsync_schedule.conf ausliest. Die Weboberfläche erlaubt lediglich ein komfortables editieren dieser Einträge. Dummerweise ist aber sowohl das Shellskript, als auch die Weboberfläche fehlerhaft, so dass eine Remote-Replikation per ssh zum HiDrive zunächst unmöglich ist.


    Im Skript befnden sich insgesamt vier Stellen, wo rsync aufgerufen wird. Jeweils einmal mit debug Ausgaben oder ohne (-v option), sowie per ssh oder ohne (-e option).


    Code
    [~] # grep rsync /etc/init.d/rsyncRR.sh                /usr/bin/rsync -a --sever-mode=${RR_MODE} -e "${RR_com_ssh}" ${RR_options} --password="${Passwd}" --timeout=120 "${RR_local_path}/" "${UserName}"@${Remote_IP}::"${RR_remote_path}" -v -v -v 1>${RR_OUT} 2>&1                /usr/bin/rsync -a --sever-mode=${RR_MODE} ${RR_options} --password="${Passwd}" --timeout=120 --port=${RR_PORT} "${RR_local_path}/" "${UserName}"@${Remote_IP}::"${RR_remote_path}" -v -v -v 1>${RR_OUT} 2>&1                /usr/bin/rsync -a --sever-mode=${RR_MODE} -e "${RR_com_ssh}" ${RR_options} --password="${Passwd}" --timeout=120 "${RR_local_path}/" "${UserName}"@${Remote_IP}::"${RR_remote_path}" 1>${RR_OUT} 2>&1                /usr/bin/rsync -a --sever-mode=${RR_MODE} ${RR_options} --password="${Passwd}" --timeout=120 --port=${RR_PORT} "${RR_local_path}/" "${UserName}"@${Remote_IP}::"${RR_remote_path}" 1>${RR_OUT} 2>&1


    Auffällig ist, dass immer die Variante mit <remote-ip>::<remote-path> verwendet wird. Dies ist die Syntax (zwei Dopplepunkte), die für die Replikation ohne ssh vorgesehen ist. Der <remote-path> beginnt hierbei mit dem sogenannten Module Namen. Im Falle des HiDrive ist das einzige bekannte Module „root“. Für die Replikation per ssh ist die Syntax <remote-ip>:<remote-path> vorgesehen (ein Doppelpunkt). Der <remote-path> ist hier direkt der Pfad im Dateisystem des HiDrive, also ohne vorgestelltes „root“. Per Option -e kann man noch ein anderes remote shell Kommando angeben, oder noch zusätzliche Parameter an ssh, z.B. einen nicht standard Port. Default ist ssh an Port 22. Was auch immer ich versucht habe, eine Remote-Replikation per ssh ist mir nie mit der Syntax der zwei Doppelpunkte geglückt. Mit nur einem Doppelpunkt läuft es problemlos.


    Modifikation 1:


    An allen vier rsync Aufrufen im /etc/init.d/rsyncRR.sh die doppelten Doppelpunkte durch einen einzelnen Doppelpunkt ersetzen.


    Jetzt kann man schon von Hand in /etc/config/rsync_schedule.conf auf „Use of SSH = True“ umstellen. Im „Remote Volume“ Eintrag das „root“ noch löschen, und schon sollte der nächste Replikations-Auftrag per ssh ausgeführt werden.


    Um das jetzt auch komfortable per GUI zu machen sind weitere Modifikationen nötig.


    Modifikation 2:


    In /home/httpd/ajax_obj/js/backup_wiz.js die Funktion check_client_mode wie folgt ändern:


    Code
    var check_client_mode = function(){var rcm = $j('#RR_CLIENT_MODE');if( rcm.val() == 'QNAP_mode'){$j('input[@name=USE_OF_SSH]').enable();$j('input[@name=RR_SSH_PORT]').enable();}else{var o_USE_OF_SSH = document.getElementById('USE_OF_SSH');o_USE_OF_SSH.checked = true;$j('input[@name=USE_OF_SSH]').enable();$j('input[@name=RR_SSH_PORT]').enable();}}


    In /home/httpd/cgi-bin/backup/html/edit_remote_rep.js die Funktion check_edit_client_mode wie folgt ändern:

    Code
    function check_edit_client_mode(){var form = document.backup;if(form.RR_CLIENT_MODE.selectedIndex == 0){form.USE_OF_SSH.disabled = false;if(form.USE_OF_SSH.checked){form.RR_SSH_PORT.disabled=false;}else{form.RR_SSH_PORT.disabled=true;}SERVER_TYPE_IS_NAS = true;}else{//form.USE_OF_SSH.checked = false;//form.USE_OF_SSH.disabled = true;//form.RR_SSH_PORT.disabled = true;form.USE_OF_SSH.disabled = false;if(form.USE_OF_SSH.checked){form.RR_SSH_PORT.disabled=false;}else{form.RR_SSH_PORT.disabled=true;}SERVER_TYPE_IS_NAS = false;}}


    Jetzt kann man einen neuen Remote-Replikations Auftrag mit Benutzung von ssh per Wizard erzeugen und später auch editieren. Ein Remote-Host-Test und letztendlich auch ein Übernehmen der Änderungen ist aber nicht Möglich, da es hier immer zu Fehlermeldungen kommt. Der Remote-Host-Test, der offensichtlich auch jedesmal beim Übernehmen von Änderungen durchgeführt wird ist in der Datei /home/backup/cgi-bin/backup/backupRequest.cgi realisiert. Dummerweise ist diese Datei ein kompiliertes C Programm, so dass eine Analyse hier nicht so leicht möglich ist. Ein simples "string" fordert aber eine „verdächtige“ Zeichenkette zutage.


    Code
    # strings /home/httpd/cgi-bin/backup/backupRequest.cgi %s --dry-run --check-dest --sever-mode="%d" --port="%d" --timeout=30 --contimeout=30 --password="%s"  "%s"@%s::"%s" > %s 2>&1


    Das sieht sehr nach einem rsync Aufruf mit der zwei Doppelpunkte Syntax aus.


    Modifikation 3:


    In einem Hexeditor in backupRequest.cgi die obige Zeichenfolge suchen und ohne die Länge des Strings zu verändern durch folgende Zeichenfolge ersetzen.


    Code
    %s --dry-run --check-dest --sever-mode="%d" --port="%d" --timeout=30                 --password="%s"   "%s"@%s:"%s" > %s 2>&1


    Das wars.
    Da jetzt in allen rsync Aufrufen nur noch ein Doppelpunkt steht, muss man für eine Remote-Replikation ohne ssh den dann nötigen zweiten Doppelpunkt hinter den Remote-Server setzen. Also z.B. „rsync.hidrive.strato.com:“.


    Ich hoffe, meine Ausführungen sind verständlich genug. Wie gesagt, so ganz ohne Unix-Kenntnisse sollte man sich vieleicht nicht da rantrauen. Auf jeden Fall immer Backups anlegen. Und natürlich alles auf eigene Gefahr. Trotzdem viel Erfolg.


    Grüße
    Torsten Schumacher