Beiträge von kleintody

  • Separate System Partition/Volume, App-Speicherplatz, HDD Encryption Key

    Hallo allesamt,



    da das automatische Upgrade meines QNAP auf QTS 4.2 mit dem Fehler "App Default Volume does not exist" endete und auch alle Versuche eines manuellen Updates fehlschlugen, werde ich mein QNAP nun wohl noch einmal from scratch aufsetzen müssen.


    Hierfür werde ich meine beiden aktuellen HDDs (in RAID 1 laufend) rausnehmen und das System auf zwei neuen HDDs frisch installieren, um die Daten auf meinen alten Disks nicht zu riskieren.


    Folgende Fragen kamen diesbezeüglich nun auf. Vielleicht kann mir jemand ja Antworten/Tipps geben:


    1.) Gibt es einen praktikablen Weg, um sicherzustellen, dass im Zuge eines Upgrades oder Neuinstallation die Daten-Partition/Volume definitiv unangetastet bleibt? D.h. gibt es eine Möglichkeit, dem QNAP zu sagen, dass es bitteschön nur auf einer vordefinierten Parition/Volume arbeitet und die übrigen Bereiche der Disks nicht anfasst? Alle manuals, die ich zurückliegend gelesen habe, sagen sinngemäß: "Mach dir ein komplettes Backup, für den Fall das das Upgrade schief geht und die Disk gelöscht werden könnte." Dies ist aber ziemlich langwierig bei Festplatten von 6TB Größe, sodass das keinen Spaß macht...


    2.) Gibt es einen praktikablen Weg, um die Apps auf der Daten-Partition/Volume anstelle der System-Partition/Volume zu speichern?


    3.) Im Moment läuft mein QNAP mit aktualisiertem QTS 4.2 auf den alten Disks. Aber das Upgrade war, wie gesagt, unvollständig, sodass ich keine Apps installieren kann (-> Fehlermeldung "App Default Volume does not exist.") Meine Daten-Partition dagegen wurde nicht gelöscht und ich gehe davon aus, dass auch die App-Daten noch irgendwo anders rumliegen und lediglich nicht sauber eingebunden werden können. Kann mir jemand einen Hinweis geben, wo die rumliegen könnten (im Wesentlichen die Configs, aber auch Daten wie z.B. die xDove Mail-Directories)?!


    4.) Aus irgendeinem Grunde war bei meinem QNAP zurückliegend das HTTPS nicht nach dem Boot-Prozess bereits vorhanden. Stattdessen musste ich mich immer erst per HTTP einloggen und dann meine Festplatten manuell entschlüsseln (da ich nicht gewillt bin, die Festplattenschlüssel auf der Disk zu speichern!). Erst nach der Entschlüsselung des Daten-Volume war HTTPS verfügbar. Gibt es jemanden, der die gleiche Beobachtung gemacht hat? Was ist der Grund und gibt es eine Lösung bzw. einen Workaround?


    5.) Wie ich feststellen durfte, nutzt QNAP zwar dmcrypt, allerdings ist der in der Weboberfläche eingegebene Schlüssel *nicht* derjenige, welcher dann auch effektiv an dmcrypt zur Verschlüsselung/Entschlüsselung übergeben wird. Vielmehr wird aus dem Schlüssel irgendwie noch Hash oder ein zweiter Schlüssel abgeleitet und dieser dann an dmcrypt durchgereicht. Gibt es irgendeine Möglichkeit, dieses Verfahren auch auf Shellebene durchzuführen (bzw. in einem lauffähigen QTS herauszubekommen, welchen Schlüssel er sich aus der Eingabe effektiv abgeleitet hat), falls ein Upgrade mal wieder schief geht und man die Platten in einem anderen Linux-System einbinden und mounten will?

  • Daten noch vorhanden nach evtl. fehlgeschlagenem Update?

    Hallo allesamt!


    ich bin relativ neu in Sacen QNAP unterwegs. Habe mein NAS seit nem guten halben Jahr, aber noch nicht viel Zeit gehabt, mich mit den Details zu beschäftigen.
    Aufgrund der Unwetter der letzten Tage hatte ich mein QNAP trotz USV mit Überspannungsschutz lieber runtergefahren.
    Als ich es heute hochfahren wollte, kam ich über das Webinterface nicht mehr drauf (weder HTTP noch HTTPS).
    Lokal kann ich mich aber mit meinem Admin-Login noch einloggen und SSH funktioniert auch.


    Ich weiß, dass ich dieses Online-Update aktiviert hatte, ich weiß aber nicht mehr genau, ob ich eine Aktualisierung hatte durchführen lassen oder nicht. (Sorry für die Dummheit!)
    Nachdem ich grad von den Risiken eines Upgrades hier gelesen habe, mach ich mir grad ziemliche Sorgen über einen möglichen Verlust all meiner Daten.


    Kann mir jemand sagen, wie ich am besten vorgehen sollte?


    Ich habe zwei 6TB-Festplatten zu einem RADI1 verbunden und das Volume war verschlüsselt.
    Wie kann ich herausfinden, ob meine eigenen Daten noch auf den NAS-Festplatten enthalten sind, ohne da eventuell noch mehr kaputt zu machen?
    Auf die ganzen Systemdaten und Einstellungen kann ich bei Bedarf gern verzichten. Wichtig sind mir all die anderen Daten die auf dem verschlüsselten Volume drauf sind.


    Folgendes kann ich zu meinen Beobachtungen kund tun:


    Weil der Webservice nicht gestartet war, hatte ich ihn versucht, manuell anzustarten
    Ein Aufruf von /etc/init.d/Qthttpd liefert mir:

    Code
    Starting Qthttpd services:Failed. Web not found


    Das liegt wohl daran, dass von /share/Web ausgehende Link gegenwärtig ins Leere zeigt?! Der zeigt auf CE_CACHEDEV1_DATA/Web
    Aber unter /share gibt es kein Verzeichnis und kein Symlink CE_CACHEDEV1_DATA



    In der /etc/volume.conf steht:


    Code
    [Global]volBitmap=0x2pd_00000001_3_Vol_Bitmap=0x2pd_00000002_3_Vol_Bitmap=0x2[VOL_1]volId=1volName=raidId=1raidName=/dev/md1encryption=yesssdCache=nomappingName=/dev/mapper/ce_cachedev1qnapResize=nodelayAlloc=yesreadOnly=nowriteCache=yesinvisible=noraidLevel=1partNo=3status=-3filesystem=12internal=1time=Mon Aug 17 02:50:20 2015volType=1baseId=1baseName=/dev/mapper/cachedev1


    Das ist der Output von mount:


    Code
    /proc on /proc type proc (rw)devpts on /dev/pts type devpts (rw)sysfs on /sys type sysfs (rw)tmpfs on /tmp type tmpfs (rw,size=64M)tmpfs on /dev/shm type tmpfs (rw)none on /proc/bus/usb type usbfs (rw)/dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)/dev/md13 on /mnt/ext type ext3 (rw,data=ordered)none on /sys/kernel/config type configfs (rw)tmpfs on /.eaccelerator.tmp type tmpfs (rw,size=32M)


    Und hier der von cat /proc/mdstat:


    Code
    Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md1 : active raid1 sdb3[0] sda3[1]                 5850567616 blocks super 1.0 [2/2] [UU]md256 : active raid1 sda2[1] sdb2[0]                 530112 blocks super 1.0 [2/2] [UU]                 bitmap: 0/1 pages [0KB], 65536KB chunkmd13 : active raid1 sdb4[0] sda4[1]                 458880 blocks super 1.0 [24/2] [UU______________________]                 bitmap: 1/1 pages [4KB], 65536KB chunkmd9 : active raid1 sdb1[0] sda1[1]


    Und hier der von storage-util:

    Code
    [~] # storage_util --sys_startupDetect disk(8, 0)...Detect disk(8, 16)...Detect disk(8, 32)...ignore non-root enclosure disk(8, 32).[~] #[~] # storage_util --sys_startup_p2sys_startup_p2:got called count = -1


    Und das passert bei einem Aufruf von mount_all:


    Leider hatte ich das NAS zwischenzeitlch schon zweimal rebootet.
    Ein Mount von /dev/mapper/cachedev1 sagt mir, dass er es nicht in der fstab finden kann.
    Wie kann ich, ohne mehr kaputt zu machen, testen, ob die Daten noch da sind?
    NAS ohne Festplatten mounten, ...
    ... und dann?!?

  • Web-Frontend & Co nicht mehr lauffähig (nach automatischem Update?)

    Hallo allesamt,


    ich bin relativ neu in Sacen QNAP unterwegs. Habe mein NAS seit nem guten halben Jahr, aber noch nicht viel Zeit gehabt, mich mit den Details zu beschäftigen.
    Aufgrund der Unwetter der letzten Tage hatte ich mein QNAP trotz USV mit Überspannungsschutz lieber runtergefahren.
    Als ich es heute hochfahren wollte, kam ich über das Webinterface nicht mehr drauf (weder HTTP noch HTTPS).
    Lokal kann ich mich aber noch einloggen und SSH funktioniert auch.


    Leider habe ich auf Anhieb keine guten Tutorials finden können, die mal so einen Abriss der wichtigsten Tools in der Shell geben - alles nur übers Web-Frontend.
    Ich versuche nun möglichst strukturiert vorzugehen.


    1.) Firmware-Status
    Wo finde ich eine Info, welche Firmware-Version gerade auf dem System läuft und ob möglicherweise ein Update fehlgeschlagen ist?


    2.) Qthttpd:
    Gehe ich recht in der Annahme, dass Qthttpd der entsprechende Dienst ist, der mir das Web-Frontend bereitstellen sollte?
    Ein Aufruf von /etc/init.d/Qthttpd restart lieferte mir die Fehlermeldung:

    Code
    Starting Qthttpd services:Failed. Web not found


    Ich vermute, dass das daran liegt, dass von /share/Web ausgehende Link gegenwärtig ins Leere zeigt?!
    Der zeigt auf CE_CACHEDEV1_DATA/Web
    Frage ist: Was sollte als CE_CACHEDEV1_DATA gemounted sein?
    Irgendein internes Device des QNAP? Oder eine meiner Einschub-Festplatten?
    Letztere sind nämlich verschlüsselt und den Schlüssel habe ich nicht auf Platte ablegen lassen. Was mich zu meiner nächsten Frage bringt:
    In der /etc/volume.conf steht zumindest:

    Code
    [Global]volBitmap=0x2pd_00000001_3_Vol_Bitmap=0x2pd_00000002_3_Vol_Bitmap=0x2[VOL_1]volId=1volName=raidId=1raidName=/dev/md1encryption=yesssdCache=nomappingName=/dev/mapper/ce_cachedev1qnapResize=nodelayAlloc=yesreadOnly=nowriteCache=yesinvisible=noraidLevel=1partNo=3status=-3filesystem=12internal=1time=Mon Aug 17 02:50:20 2015volType=1baseId=1baseName=/dev/mapper/cachedev1


    Bitte sagt mir jetzt nicht, dass QWeb neuerdings indirekt erwartet, dass die Festplatte bereits gemounted und entschlüsselt ist?!?
    Es hat mich in dem halben Jahr schon immer angenervt, dass ich lediglich per HTTP auf das ohne entschlüsseltes Volume hochgefahrene NAS zugreifen konnte und HTTPS erst verfügbar war, sobald ich die Festplatte entschlüsselt hatte. Das ist jetzt doch nicht etwa generell notwendig?!


    3.) Sorry für die dumme Frage, aber: Wie kann ich ein Volume lokal in der Shell mounten und unlocken?


    Mhhh.. Könnte der Name "cachedev" darauf hindeuten, dass das eben keine Datenplatte ?! ;)
    Aber wie genau landet das im System? Als Mapper dient ja /dev/mapper/cachedev1
    Untd weiter? In /etc/fstab ist kein entsprechender eintrag hinterlegt.


    Falls es hilft, hier der Output von mount:


    Code
    /proc on /proc type proc (rw)devpts on /dev/pts type devpts (rw)sysfs on /sys type sysfs (rw)tmpfs on /tmp type tmpfs (rw,size=64M)tmpfs on /dev/shm type tmpfs (rw)none on /proc/bus/usb type usbfs (rw)/dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)/dev/md13 on /mnt/ext type ext3 (rw,data=ordered)none on /sys/kernel/config type configfs (rw)tmpfs on /.eaccelerator.tmp type tmpfs (rw,size=32M)


    Und hier der von cat /proc/mdstat:


    Code
    Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md1 : active raid1 sdb3[0] sda3[1]                 5850567616 blocks super 1.0 [2/2] [UU]md256 : active raid1 sda2[1] sdb2[0]                 530112 blocks super 1.0 [2/2] [UU]                 bitmap: 0/1 pages [0KB], 65536KB chunkmd13 : active raid1 sdb4[0] sda4[1]                 458880 blocks super 1.0 [24/2] [UU______________________]                 bitmap: 1/1 pages [4KB], 65536KB chunkmd9 : active raid1 sdb1[0] sda1[1]                 530112 blocks super 1.0 [24/2] [UU______________________]                 bitmap: 1/1 pages [4KB], 65536KB chunkunused devices: <none>


    Und hier das Ergebnis der beiden Aufrufe von storage_util:

    Code
    [~] # storage_util --sys_startupDetect disk(8, 0)...Detect disk(8, 16)...Detect disk(8, 32)...ignore non-root enclosure disk(8, 32).[~] #[~] # storage_util --sys_startup_p2sys_startup_p2:got called count = -1


    Das sieht mir jetzt soweit erstmal nicht falsch aus(?!?)


    Und hier nun der Aufruf von mountall: