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 …

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.

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

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.

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:

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.

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.

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.

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.

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”.

In einer Domäne ist es recht einfach, einen Rechner remote heruterzufahren. Einfach an der Kommandozeile

eingeben und sofern der ausführende Benutzer innerhalb der Domäne die benötigten Rechte hat, führt der angegebene Rechner den Befehl klaglos aus.

Nicht so trivial ist das Szenario bei Rechnern im z.B. heimischen Umfeld, wo nur selten eine zentrale Benutzerverwaltung aktiv sein dürfte:

Als ersten Lösungsansatz stößt man meistens auf den Hinweis, sich zuerst mittels einer administrativen Netzerkverbindung gegenüber dem herunterfahrenden Rechner zu authentifizieren, wofür sich z.B. die Freigabe IPC$ anbietet:

Unter Windows XP war dies schon vollkommen ausreichend, unter Windows Vista und Windows 7 wird allerdings weiterhin der Zugriff verweigert. Wie der KnowledgeBase-Artikel “Description of User Account Control and remote restrictions in Windows Vista” erklärt, handelt es sich hierbei um ein Feature und keinen Bug:

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection by using the net use * \remotecomputer\Share$ command, for example, they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks.

Um auch über das Netzwerk verbundenen, lokalen Benutzern entsprechende Berechtigungen zu erteilen, ist das setzen des Registry-Schlüssels “LocalAccountTokenFilterPolicy” innerhalb des Pfades

notwendig, dieser muß als DWORD mit dem Wert 1 angelegt werden.

Wirft man einen Blick in die Verbrauchsanzeige eines Smartphones, so fällt auf, daß neben dem Display vor allem das ständige Offenhalten der Daten-Verbindung am Akku nagt. Sofern man damit leben kann, daß nicht jede Nachricht sekundengenau aufschlägt, lässt sich genau an dieser Stelle ansetzen und die mobile Datennutzung zeitlich steuern was die Standby-Zeiten deutlich verbessert.

Hierzu können z.B. in Llama, den “Location Profiles für Android” drei Regeln angelegt werden, welche die automatische Steuerung übernehmen:

Mobiles Netz automatisch aus

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten aktiviert sind

• um 2 Minuten verzögern und dann Datennetzmodus deaktivieren

Diese Regel sorgt dafür, daß bei ausgeschaltetem Display und eingeschalteten Mobildaten diese nach 2 Minuten automatisch deaktiviert werden.

Mobiles Netz automatisch ein

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten deaktiviert sind

• um 13 Minuten verzögern und dann Datennetzmodus aktivieren

Diese Regel ist das Gegenstück zu “Mobiles Netz automatisch ein” und sorgt dafür, daß bei ausgeschaltetem Display und Mobildaten diese nach 13 Minuten aktiviert werden.

Mobiles Netz mit Bildschirm ein

• Wenn sich der Bildschirm einschaltet

• Wenn Mobildaten deaktiviert sind

• Datennetzmodus aktivieren

Die letzte Regel dient dazu im Bedarfsfall zusammen mit dem Bildschirm auch die Mobildaten einzuschalten.

Natürlich sind der künstlerischen Freiheit beim Gestalten der Regeln keine Grenzen gesetzt. So kann zum Beispiel über eine Llama-Variable die automatische Steuerung ortsbezogen ein- oder ausgeschaltet oder auch eine Ruhezeit definiert werden, in der die Datenverbindung überhaupt nicht aktiviert wird.

Standardmäßig ist bei Debian die NumLock-Funktion auf der Konsole nach dem Boot deaktiviert. Ist dies bei physikalischen Servern in der Regel kein größeres Ärgernis, da man nur selten direkt an der Konsole arbeitet und noch seltener neu startet, kann es bei einer auf dem lokalen Arbeitsplatz betriebenen virtuellen Maschine nerven: je nach verwendeter Virtualisierungslösung wird beim Boot der VM auch unter Windows die NumLock-Taste ausgeschaltet, was mehr als nervig ist.

bis Debian 7 “Wheezy”:

Die Lösung ist recht einfach - ein Skript namens “enablenumlock”

ins Verzeichnis “/etc/init.d” gepackt, ausfrührbar gemacht und dann mittels

in den Systemstart eingebunden. Beim nächsten Boot wird NumLock automatisch aktiviert.

ab Debian 8 “Jessie”:

Durch den Umstieg von sysvinit zu systemd funktioniert die oben geschilderte Lösung nicht mehr zuverlässig. Einfache Abhilfe schafft der Ansatz aus dem archlinux Wiki, welcher dem Dienst “getty@.service” zwei Zeilen hinzufügt:

Nach einen Neustart ist Numlock dann wieder standardmäßig aktiviert. Wer sich an dem angezeigten Hint stört, findet im Wiki auch eine Möglichkeit, dessen Ausgabe zu unterdrücken.