Mittlerweile ist es ja sehr einfach geworden, das Android Custom ROM CyanogenMod zu installieren, aber bei meinem alten Galaxy Nexus i9250 bin ich trotzdem erstmal gescheitert. Nach viel hin und her, habe ich die Lösung hier gefunden: Universal ADB (Android Debug Bridge) Driver for Windows
Mit diesem Treiber hat dann alles mit dem automatischen Installer hervorragend geklappt.
Vor einiger Zeit hat WhatsApp angefangen, unter Android die lokale Datenbank auf dem Handy zu verschlüsseln. Das erhöht zwar (etwas) die Sicherheit, erschwert aber leider auch den Umzug alle WhatsApp Chats auf ein neues Handy. Im Endeffekt liegts am Google Account, mit dem das Android Handy eingerichtet ist. Auf meinem alten Handy war das noch eine @googlemail.com Adresse, auf dem neuen aber eine @gmail.com Adresse. Dadurch hat es nicht gereicht, einfach nur den WhatsApp Ordner vom alten aufs neue Handy zu kopieren. Es kam zwar die Meldung, dass das Backup wiederhergestellt werden konnte, aber ich habe nur meine ganzen Gruppen ohne Inhalt gesehen. Von den restlichen Chats fehlte jede Spur.
Was hat geholfen? Diese Anleitung aus dem Forum von www.android-hilfe.de. Das Tool, was man dazu benötigt, ist hier verlinkt.
Was ich abweichend von der Anleitung machen musste, die mit dem neuen @gmail.com Account verschlüsselte Datei auf dem neuen Handy von msgstore.db.re.crypt5 in msgstore.db.crypt5 umbenennen. Dann konnte ich WhatsApp installieren und das Backup mit ca. 25000 Nachrichten wurde wiederhergestellt.
Ach ja, soviel zum Thema Sicherheit & Verschlüsselung von WhatsApp Backups. 😉
Ich spiele mit dem Gedanken, mein altes Galaxy Nexus i9250 in Rente zu schicken und durch ein aktuelleres Modell zu ersetzen. Mein momentaner Favorit ist das Moto G von Motorala. Um grob abschätzen zu können, wie viel mehr Leistung das bringt, habe ich mal meine beiden Geräte mit AnTuTu benchmarken lassen:
Galaxy Nexus i9250
Nexus 7 (2012)
Das Moto G liegt bei gut 17.000 Punkten.
Hintergrund ist, dass meine Nikon 1 J1 zwar sehr schöne Videos macht, die aber leider recht groß sind. Ich stelle diese z.B. via Google Drive anderen Leuten zur Verfügung. Im Originalformat MOV spielt Google Drive diese leider im Browser nicht ab und die Videos müssen erst runtergeladen werden. Das Problem läßt sich umgehen, indem man das Video in MP4 mit H.264 und einem beliebigen Audio Codec (AAC, OGG, MP3, …) konvertiert, bevor man es in Google Drive ablegt.
Aber wie geht das genau? Ich mache das mit dem Tool HandBrake.
Nach der Installation das Programm starten und mit Source > Open File das Originalvideo öffnen. In meinem Beispiel heißt das DSC_2676.MOV und ist 99,4 MB groß.
Bei Destiantion ändere ich noch den Dateinamen von M4V in MP4 und passe den Pfad an, wo das neu kodierte Video dann landen soll.
Auf den Tabs Video und Audio können jetzt bei Bedarf noch Änderungen gemacht werden. Ich lasse das aber einfach mal so.
Jetzt nur noch auf Start klicken und warten. Je nach Leistung des PCs und der Größe des Videos kann die Kodierung schon mal einige Minuten dauern. Das Resultat ist in meinem Beispiel eine Datei Dsc 2676-1.mp4 die nur noch 21,6 groß ist und direkt von Google Drive im Browser abgespielt werden kann.
Wer beim Login in Plesk einen Fehlermeldung à la „502 Bad Gateway“ erhält, kann einen Blick in das Logfile /var/log/sw-cp-server/error_log werfen um ein paar mehr Details zu bekommen:
2014/04/10 19:14:48 [crit] 1077#0: *7 connect() to unix:/var/run/sw-engine.sock failed (13: Permission denied) while connecting to upstream, client: 37.201.xxx.xxx, server: , request: "GET /login_up.php3 HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "mein-vserver.de:8443" 2014/04/10 19:14:53 [crit] 1077#0: *7 connect() to unix:/var/run/sw-engine.sock failed (13: Permission denied) while connecting to upstream, client: 37.201.xxx.xxx, server: , request: "GET /login_up.php3 HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "mein-vserver.de:8443" 2014/04/10 19:15:24 [crit] 1077#0: *7 connect() to unix:/var/run/sw-engine.sock failed (13: Permission denied) while connecting to upstream, client: 37.201.xxx.xxx, server: , request: "GET /login_up.php3 HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "mein-vserver.de:8443" 2014/04/10 19:15:27 [crit] 1077#0: *7 connect() to unix:/var/run/sw-engine.sock failed (13: Permission denied) while connecting to upstream, client: 37.201.xxx.xxx, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "mein-vserver.de:8443"
Bei mir hat dann ein Neustart von Plesk geholfen: /etc/init.d/sw-cp-server restart
Ich benutze KeeFox u.a. um in KeePass gespeicherte Passwörter in mehreren Browsern nutzen zu können. Vor kurzem gabs ein Update auf Version 1.3.1 und seitdem sagt Firefox mir regelmäßig, es könnte keine Verbindung zu KeePass aufgebaut werden bzw. Firefox wäre nicht autorisiert dazu. Mit Version 1.2.7 von KeeFox habe ich das Problem nicht. Auch die Troubleshooting Seite konnte mir nicht helfen. Angeblich gibts Probleme mit Firewalls, Virenscannern oder sonstiger Security Software, die dazu führe, dass Firefox keine Verbindung zu KeePass aufbauen kann. Der Process Explorer zeigt mir aber an, dass eine Verbindung besteht:
Eine Lösung habe ich nicht wirklich gefunden. Ich bin nun zurück zu Version 1.2.7 und alles funktioniert wieder so, wie gewünscht. Allerdings musste ich dazu erst die Datei KeePassRPC.plgx aus dem plugins Verzeichnis von KeePass löschen (z.B. C:\Program Files (x86)\KeePass Password Safe 2\plugins) und dann noch das automatische Update des Addons in Firefox deaktivieren:
Sonst gibts direkt wieder die neue Version und das ganze Spiel geht von vorne los.
Update vom 10.04.2014: Fast vergessen, eine Alternative zu KeeFox ist PassIFox.
Dieses einfache Script geht davon aus, dass im Verzeichnis /var/data/my-ftp-backup-folder/ Backups vorliegen und fängt an, alte Dateien zu löschen, sobald mehr als 7 Dateien vorliegen. Die Dateien müssen dabei schon passend geordnet vorliegen, z.B.
backup1.zip
backup2.zip
backup3.zip
…
backup9.zip
#!/bin/bash # remove old backups automatically # Version 1.0 - 03.04.2014 # https://www.denniswilmsmann.de/2014/04/alte-backups-unter-linux-automatisch-loeschen/ # how many backups should be kept? let maxcount=7 let counter=0 for backupfile in /var/data/my-ftp-backup-folder/*; do let counter=$counter+1 echo $backupfile done echo "Backup count:" $counter if test $counter -gt $maxcount; then echo "Too many backups, forcing deletion..." let newcounter=0 for deletefile in /var/data/my-ftp-backup-folder/*; do let newcounter=$newcounter+1 # echo "newcounter" $newcounter let temp=$counter-$maxcount # echo "temp" $temp if test $newcounter -le $temp; then rm $deletefile echo "Deleting file" $deletefile fi done else echo "Nothing to do." fi
Falls Dateien gelöscht werden, wird der betroffene Dateiename ausgegeben. Falls 7 (oder weniger) Dateien vorliegen, wird die Meldung „Nothing to do.“ ausgegeben. Ich lasse das Script täglich als cronjob laufen, um zu vermeiden, dass mein Backupverzeichnis vollläuft.
Funktioniert zuverlässig. 🙂 In dem Beispiel oben mit den Backups von 1 bis 9 löscht das Script also backup1.zip und backup2.zip.