Synology DS file zerstört Dateien beim Upload

17. Juni 2014 · Anwendungen · andreas · 2 Kommentare

Ich habe gestern von meinem Nexus 4 eine KeePass-Datei mit DS file auf mein Synology-NAS hochgeladen und anschließend von meinem Nexus 7 aus mit DS file wieder heruntergeladen. Beim Versuch, diese zu öffnen, hat sich KeePass über eine fehlerhafte Datei beschwert. Ein Vergleich der beiden Dateien hat gezeigt, daß die über das NAS kopierte Datei nur 49,00 kb hat, während die lokale Datei eine Größe von 49,01 kb aufweist.

In einem Versuch mit einer Textdatei ließ sich das Verhalten reproduzieren: die auf dem Nexus 4 noch 189 Byte große Datei ist nach dem Hochladen nur noch 180 Byte groß, es fehlen einige Zeichen am Ende. Auch bei einem testweisen Upload über das Nexus 7 wurden Dateien beschädigt.

Nachdem klar war, daß wohl tatsächlich ein Fehler besteht, habe ich gestern Abend direkt ein Support-Ticket mit folgendem Wortlauf bei Synology eröffnet:

Problem Explanation:

Hi,

I have the problem, that since the last update DS file seem to corrupt files when uploading to the DiskStation.

The Android device is a Google Nexus 4 running Android 4.4.3

I noticed the error when uploading a KeePass file to the DiskStation, downloaded it to a Nexus 7 (also running Android 4.4.3) and could’t open the file with KeePass complaining the file being corrupt.

I also couldn’t open the uploaded file when downloading it back to the Nexus 4 as KeePass also claimed the file being corrupt.

Problem Reproduce Steps:

I choose a textfile with some URLs (189 bytes on mobile phone), upload it to the DiskStation and the file size changes to 180 bytes. The last characters of the file are missing.

Sicherheitshalber habe ich parallel dazu auch noch eine Mail an Carsten Knobloch, den Betreiber von stadt-bremerhaven.de verschickt, der das Problem verifizieren konnte. Während er wenige Stunden nach seinem Blogeintrag bereits eine E-Mail von Synology mit dem Hinweis, daß die App vorübergehend aus dem PlayStore genommen wurde, erhielt warte ich 24 Stunden später noch immer auf eine Reaktion vom Support … Aber bestimmt erklären die mir irgendwann, daß das Problem doch längst behoben sei …


backupDB

29. Mai 2014 · Downloads · andreas · Kein Kommentar

backupDB is a PHP script to dump a MySQL database and send the dump to a given e-mail for backup purposes.
It was inspired by the backup function of the WordPress plugin “wp-dbmanager”.

Weiterlesen


The Dark Knight Rises

29. Mai 2014 · IMHO · andreas · Kein Kommentar

tdkr_posterWenn ein Film auf Platz 50 der Top 250 IMDb Charts landet, sollte man von diesem eigentlich jede Menge Besonderes erwarten können - umso erstaunlicher ist, wenn sich der Kandidat lediglich als maximal durchschnittliches Blockbuster-Machwerk entpuppt.

Schon die Eröffnungssequenz nach dem Strickmuster “großer Flieger fängt kleinen Flieger und der böse ist der Mann mit der Maske” hat man bei “Star Wars” (Platz #18 der Charts) bereits 35 Jahre vorher besser gesehen. Wenn man einem Schurken schon jegliche Möglichkeit zur Mimik nimmt, sollte man diesen wenigstens so einführen, daß klar ist “Der sprengt auch Planeten!” statt ihn als X-beliebigen Schläger daherkommen zu lassen.

Aber auch der Rest der Charaktere kann nicht sonderlich glänzen: Chrisitan Bale liefert eine Performance irgendwo zwischen Hayden Christensen und Mel Gibson ab, so daß sich die Frage stellt, warum überhaupt jemand gegen die Neubesetzung mit Ben Afflek Sturm läuft und wer Gary Oldman in “Dame, König, As, Spion” gesehen hat weiß, wozu der Mann eigentlich in der Lage ist, wenn man ihm die richtige Brille aufsetzt. Dazu kommt noch ein deutlich unter seinen Möglichkeiten agierender Morgan Freeman und Anne Hathaway als Selina Kyle / Catwoman, die aber leider wenig mysteriös rätselhaft sondern eher pubertierend dämlich daherkommt. Lediglich die Verzweiflung von Michael Caine als Alfred wirkt halbwegs echt, so als hätte ihn sein Agent gezwungen, die kurze Rolle in “The Dark Knight Rises” zu übernehmen.

Bleiben noch Plot und Spezialeffekte, die den Film vielleicht retten könnten:

Vom Plot bleibt leider nicht viel übrig, denn daß Miranda Tate nicht die vertrauenswürdige Freundin ist, als die sie sich ausgibt ist eigentlich jedem außer den restlichen Protagonisten klar und auch das textuell aufgebauschte mysteriöse Gefängnis entpuppt sich beim Hinsehen leider als ziemlich gewöhnliches Loch. Die Bombe-wer-hat-den-Zünder und Halten-wir-das-noch-in-den-letzten-Sekunden-auf-Story wurde auch bereits zu oft auf Zelluloid gebannt um noch Spannung zu erzeugen und die Anarcho-Atmosphäre bereits in John Carpenter’s “Die Klapperschlange” deutlich glaubwürdiger umgesetzt.

Das Beste am Film sind eindeutig die Spezialeffekte, die über weite Strecken so gut gelungen sind, daß sie eben nicht als Spezialeffekte auffallen und nur in wenigen Szenen unangenehm in den Vordergrund treten.


Debian auf SSD umziehen

20. Mai 2014 · Betriebssysteme · andreas · 2 Kommentare

Durch den anhaltenden Preisverfall ist der Gedanke naheliegend, auch bei Systemen, die nicht direkt als Arbeitsplatz-Rechner im Einsatz sind, die konventionelle HD durch eine SSD zu ersetzen. Ein typischer Kandidat hierfür ist zum Beispiel ein in der Ecke stehender VDR, der seine Bootzeit nicht nur auf unter 10 Sekunden (inklusive BIOS und GRUB) verkürzt, sondern mit SSD auch so gut wie geräuschlos arbeitet.

Als Windows-orientierter Anwender schwirren bei der Umzugsplanung zunächst Begriffe wie “Disk-Imager” und ähnliches durch den Kopf, unter Linux reichen - wie so oft - in der Regel Bordmittel.

Als erstes sollte geklärt werden, wie groß die benötigte SSD mindestens sein muß. Die Ausgabe von “df -h” liefert den zur Zeit belegten Festplattenplatz, der mit 4,2GB so gering ausfällt, daß selbst eine 60GB SSD vollkommen überdimensioniert scheint.

root@vdr:~# df -h
Dateisystem                                           Größe Benutzt Verf. Verw% Eingehängt auf
rootfs                                                 143G    4,2G  132G    4% /
udev                                                    10M       0   10M    0% /dev
tmpfs                                                  203M    324K  203M    1% /run
/dev/disk/by-uuid/dcb30b21-2bd8-465b-8e45-f8d7d6c50560 143G    4,2G  132G    4% /
tmpfs                                                  5,0M       0  5,0M    0% /run/lock
tmpfs                                                  1,2G       0  1,2G    0% /run/shm

Die SSD wird zunächst als zweite Platte ins System eingebaut und “fdisk” schafft Klarheit über die Verhältnisse:

root@vdr:~# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   304205823   152101888   83  Linux
/dev/sda2       304207870   312580095     4186113    5  Extended
/dev/sda5       304207872   312580095     4186112   82  Linux swap / Solaris

Disk /dev/sdb: 60.0 GB, 60022480896 bytes
...
Device Boot Start End Blocks Id System

Wie der Ausgabe zu entnehmen ist die HD eine 160GB-Platte, unter “/dev/sda” zu erreichen, die SSD ist eine 60GB-Platte, die als “/dev/sdb” zur Verfügung steht. Insgesamt wurden auf der HD 2 Partitionen angelegt: eine Linux-Partition für Betriebssystem und Daten sowie eine SWAP-Partition.

Im nächsten Schritt kann nun die SSD analog zur HD aufgeteilt werden, das passende Werkzeug hierfür ist wiederum “fdisk”. Beim Anlegen der Systempartition sollte daran gedacht werden, das “Boot”-Flag für diese Partition zu setzen.

root@vdr:~# fdisk -l /dev/sdb

Disk /dev/sdb: 60.0 GB, 60022480896 bytes
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048    83888127    41943040   83  Linux
/dev/sdb2        83888128   100665343     8388608   82  Linux swap / Solaris

Ob hierbei die ursprüngliche Partitionierung mit einer primären und einer erweiterten Partition plus logischem Laufwerk beibehalten oder auf zwei primäre Partitionen geändert wird, spielt für den Umzug keine Rolle.

Nach dem Anlegen der Partitionen werden die Dateisysteme erzeugt, was von “mkfs.ext4” bzw. “mkswap” erledigt wird:

root@vdr:~# mkfs.ext4 /dev/sdb1
...
Platz für Gruppentabellen wird angefordert: erledigt
Inode-Tabellen werden geschrieben: erledigt
Erstelle Journal (32768 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt

root@vdr:~# mkswap /dev/sdb2
Setting up swapspace version 1, size = 8388604 KiB
no label, UUID=f5dbddec-78e4-452d-96b3-c304a056d4db

Nach dem Erstellen der Dateisysteme wird ein Verzeichnis angelegt und die Systempartition der SSD in dieses Verzeichnis eingebunden. Anschließend wird mittels “rsync” der Inhalt der HD auf die SSD kopiert. Wichtig ist der Parameter “one-file-system”, der dafür sorgt, daß sich rsync nicht im soeben angelegten Ordner in einer Endlosschleife verrennt.

root@vdr:~# mkdir /mnt/ssd

root@vdr:~# mount /dev/sdb1 /mnt/ssd

root@vdr:~# rsync -av --one-file-system / /mnt/ssd

Im nächsten Schritt muß die Datei “/etc/fstab” für die SSD angepasst werden. Während “früher” die einzelnen Partitionen als “/dev/sdb1” etc angesprochen wurden, werden in neueren Systemen die UUIDs verwendet.

root@vdr:~# blkid

/dev/sda5: UUID="3d134e82-5338-4876-9a01-589259eb1569" TYPE="swap"
/dev/sda1: UUID="dcb30b21-2bd8-465b-8e45-f8d7d6c50560" TYPE="ext4"
/dev/sdb1: UUID="87111054-e9dc-4208-af1d-36657c13da4c" TYPE="ext4"
/dev/sdb2: UUID="f5dbddec-78e4-452d-96b3-c304a056d4db" TYPE="swap"

Eine Liste der im System vorhandenen UUIDs kann mittels des Befehls “blkid” ermittelt werden, anschließend sind in der Datei “/mnt/ssd/etc/fstab” die UUIDs anzupassen, d.h. alle Einträge der UUID “3d134e82-5338-4876-9a01-589259eb1569” durch “f5dbddec-78e4-452d-96b3-c304a056d4db” und alle einträge der UUID “dcb30b21-2bd8-465b-8e45-f8d7d6c50560” durch “87111054-e9dc-4208-af1d-36657c13da4c” zu ersetzen.

root@vdr:~# vi /mnt/ssd/etc/fstab

Damit letztendlich von der Platte gestartet werden kann, muß noch der Bootloader “GRUB” entsprechend eingerichtet werden.

Hierzu wird mittels “chroot” das Rootverzeichnis temporär geändert und GRUB auf der SSD installiert. Wichtig ist, vor der Installation die Datei “/boot/grub/grub.cfg” anzupassen, hier müssen analog zur fstab die UUIDs ersetzt werden.

root@vdr:~# mount --bind /dev /mnt/ssd/dev

root@vdr:~# mount --bind /proc /mnt/ssd/proc

root@vdr:~# chroot /mnt/ssd

root@vdr:/# vi /boot/grub/grub.cfg

root@vdr:/# grub-install /dev/sdb
Installation finished. No error reported.

root@vdr:/# exit
exit

Nach dem Verlassen des chroots mittels “exit” kann das System heruntergefahren und die HD abgeklemmt werden. Das System sollte nun von der SSD starten.

Nach erfolgtem Systemstart sind noch zwei Parameter in der Datei “/etc/fstab” hinzuzufügen, die sich hoffentlich positiv auf die Performance und Lebensdauer der SSD auswirken: “discard” sowie “relatime”. “discard” sorgt dafür, daß die SSD mit Hilfe des TRIM-Kommandos nicht mehr genutzte Speicherblöcke effektiver zu verwalten, “relatime” ist die sinnvolle Alternative zummeist vorgeschlagenen “noatime”.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# # / was on /dev/sda1 during installation
UUID=87111054-e9dc-4208-af1d-36657c13da4c /               ext4    discard,relatime,errors=remount-ro 0       1
UUID=f5dbddec-78e4-452d-96b3-c304a056d4db none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Trust in German Sicherheit

10. Mai 2014 · IMHO · andreas · Kein Kommentar
gdata_trustingermansicherheit

Als hätten sich Douglas (“Come in and find out”), Schlecker (“For you. vor Ort.”) , Mitsubishi (““Drive Alive”) und Konsorten noch nicht genug blamiert, startet nun auch G Data einen verzweifelten Versuch, Anglizismen möglichst sinnbefreit unterzubringen.

Hatte ich bei den Werbeanzeigen in der c’t noch auf eine einmalige Entgleisung gehofft, darf ich den Spruch seit dem Update heute Morgen auch auf meinem PC bewundern.