Implizite Informationen

Als Ende Februar 2011 bei ca. 150.000 Nutzern von Google Mail die dort gespeicherten E-Mails gelöscht wurde, dachte ich erst einmal "Puh, zum Glück bin ich nicht betroffen". Aber will ich das weiter hoffen? In den ersten Tagen danach war das Web voll von klugen Ratschlägen, wie man ein Backup anlegen kann. Alle diese Methoden haben einen Nachteil: sie sind für Mausschubser graphische Oberflächen optimiert und müssen manuell gestartet werden.

Nichts für mich. Ich brauche einen Mechanismus, der im Hintergrund alles für mich automatisch erledigt. Idealerweise sogar auf meinem kleinen Serverlein. So werden E-Mails auch gesichert, wenn mein Hauptrechner ausgeschaltet ist.

Es gibt einige Anleitungen, wie man mittels Fetchmail an die E-Mails bei Google herankommt. Auf Grund einiger Inkompabilitäten funktioniert das Ganze wohl auch, aber das Problem ist ein anderes: was mache ich mit den frisch gelesenen E-Mails? Fetchmail ist darauf hin optimiert, die E-Mails an einen lokalen Mail-Server weiter zu leiten. Den wollte ich nicht auch noch aufsetzen.

Gestolpert bin ich dann über einen etwas älteren Blogeintrag How to back up your Gmail on Linux in four easy steps. Die dort angesprochene Software getmail realisiert genau das, was ich brauche: die frisch gelesenen E-Mails werden als normale Textdatei(en) gespeichert und können zur Not von üblichen Mail-Programmen eingelesen werden.

Das Problem mit dem Blogeintrag: er nutzt ein Übertragungsprotokoll, dass einige Beschränkungen aufweist: POP3. Zum einen beschränkt Google die Menge an übertragenen E-Mails, nach ca. 320 E-Mails ist Schluss. Zum anderen werden damit nur die empfangenen E-Mails abgeholt, nicht die E-Mails, die ich selbst geschrieben und gesendet habe.

Google Mail erlaubt zum Glück den Zugriff via IMAP. Wie auch POP3 muss IMAP innerhalb von Google Mail aktiviert werden. Bei den Einstellungen innerhalb von Google Mail auf den Punkt "Weiterleitung und POP/IMAP" klicken und dort "IMAP aktivieren". Alles andere in der Standardeinstellung belassen.

Der geneigte Nutzer von Google Mail weiß, dass unter dem Label "Alle Nachrichten" wirklich alle E-Mails zugreifbar sind, bis auf die im Spam-Ordner. Aber wer will die schon sichern? Bei einem Zugriff via IMAP werden die Label von Google Mail zu sogenannten Ordnern. Der Posteingang heißt unter IMAP "INBOX". Den IMAP-Namen für "Alle Nachrichten" konnte ich mittels Thunderbird als "[Gmail]/Alle Nachrichten" ermitteln. Bei einer anderen als der deutschen Spracheinstellung muss der Name entsprechend angepasst werden. Erinnert mich an das frühe VBA, als selbst die Befehle eingedeutscht waren. Schrecklich. Aber nicht zu ändern.

Mit diesen Daten ist alles zum Konfigurieren von getmail beisammen. Wie Sie getmail installieren müssen, werde ich nicht erklären. Das ist zu systemspezifisch. Auf meinem Serverlein reichte ein einfacher Aufruf des Paketmanagers.

Legen Sie als erstes in Ihrem Benutzerverzeichnis "~" das Verzeichnis .getmail so an, dass nur Sie darauf zugreifen können:

mkdir -m 0700 ~/.getmail

Dann legen Sie die Konfigurationdatei an. USER ist Ihr Benutzername bei Google Mail, PASSWORD Ihr Kennwort.

cat <<EOF > ~/.getmail/getmailrc
[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = USER@gmail.com
password = PASSWORD
mailboxes = ("[Gmail]/Alle Nachrichten", )

[destination]
type = Maildir
path = ~/.getmail/gmail-backup/
[options]
verbose = 0
delivered_to = false
received = false
read_all = false
message_log = ~/.getmail/gmail.log
EOF

Jetzt müssen Sie nur noch das Verzeichnis gmail-backup anlegen. Dies erledigt getmail leider nicht automatisch.

mkdir -m 0700 -p ~/.getmail/gmail-backup/{cur,new,tmp}

Jetzt kommt der große Moment:

getmail -g ~/.getmail -v -v -v

Mit diesem Aufruf starten Sie getmail (der konkrete Befehl kann, je nach Installation, ein wenig variieren). Die drei Optionen -v bewirken, dass Sie die Zugriffe auf Google Mail gut nachvollziehen können. Die ganz Harten unter uns können auch --trace verwenden. Nun wird der gesamte Inhalt Ihres Google Mail Kontos heruntergeladen und im Verzeichnis ~/.getmail/gmail-backup/new in einer Datei pro E-Mail gespeichert. Das kann dauern.

Inzwischen erkläre ich den Inhalt von getmailrc. Der Abschnitt [retriever] dürfte soweit klar sein. Hier geben Sie alle Informationen, um auf Ihr Google Mail Konto zugreifen zu können. Unter mailboxes geben Sie eine Liste der zu sichernden Labels an. Im Abschnitt [destination] wird definiert, wo und in welchen Format die E-Mails abgelegt werden. Ich habe mich für das Maildir-Format entschieden, da es gegenüber dem konkurrierenden mbox-Format wesentlich robuster ist. Und darauf kommt es mir bei einem Backup an. Wer möchte, kann die E-Mails in beiden Formaten speichern. getmail kennt dazu das Konzept MultiDestination.

Einige Einträge im Abschnitt [options] sind wichtig. read_all muss auf den Wert false gesetzt werden. Sonst liest getmail bei einem zweiten Aufruf alle E-Mails erneut ein und speichert diese mehrfach. delivered_to und received besitzen ebenfalls den Wert false, damit getmail die sog. Headerinformationen nicht ergänzt / ändert. Alle Vorgänge können in der unter message_log benannten Datei nachvollzogen werden.

Sind alle E-Mails inzwischen heruntergeladen worden? Nein? Dann ist ja noch etwas Zeit einen cron-Job einzurichten. Wieder ist dies von der jeweiligen Installation abhängig. Wichtig ist aber, beim Aufruf von getmail die Option -q anzugeben. Dann teilt getmail nur im Fehlerfalle etwas mit. Ich habe mir eine Datei angelegt, die ich dann im cron-Job verwende:

cat <<EOF > ~/bin/backup-gmail.sh
#!/bin/sh
/usr/bin/getmail -q -g /home/dkr/.getmail
EOF
chmod 700 ~/bin/backup-gmail.sh

Die Datei backup-gmail.sh lasse ich periodisch einmal am Tag aufrufen:

crontab -u dkr -l
50  23  *   *   *   /home/dkr/bin/backup-gmail.sh

Pünktlich um 23:50 Uhr läuft dann auf meinem Server die (inkrementelle) Datensicherung an. Bis jetzt ohne Probleme. Wer möchte, kann die nun lokal vorhandenen E-Mails auch noch woanders hin sichern. Sicher ist sicher.

Das Backup muss nicht per cron gestartet werden. Wenn Sie kein Serverlein besitzen, kann backup-gmail.sh auch ganz normal beim Anmelden gestartet werden. Nach dem ersten Backup, der naturgemäß länger dauert, braucht getmail auf meinem System ca. 3 Minuten für das Sichern der neu hinzugekommenen E-Mails. Davon wird die meiste Zeit mit dem Erkennen der neuen E-Mails verbracht. Bei mir sind es aktuell ca. 10.000 E-Mails, deren Header-Informationen gelesen werden müssen. Verschmerzbar.

Auf einen Nachteil möchte ich hinweisen: ungelesene E-Mails werden nach einem Backup als gelesen markiert. Dies ist vom Autor von getmail so gewollt, aber auch nicht wirklich schlimm. Der Backup kann nach dem Lesen der E-Mails gestartet werden. Oder ich schaue mir die E-Mails in der Reihenfolge ihres Eingangs unter "Alle Nachrichten" an. Fertig.

Die Projektstudie verlief in diesem Semester leicht anders. Während sich die Auswahl der Werkzeuge stabilisiert hat, rückten Aspekte, wie die von mir geforderte Aufgabenrotation in den Vordergrund. Nichts ist so beständig wie die Änderung.

Aufgabenrotation

Nach den Erfahrungen der letzten Semester hatte ich entschieden, dass alle Teilnehmer jede Rolle wenigstens einmal ausüben sollte. Nach meiner Beobachtung "versteckten" sich früher immer wieder Teilnehmer hinter ihren Rollen bzw. wurden auf diese abgeschoben. Auch stellten einige Studierenden vor der Projektstudie die Frage, ob es wahr sei, dass ein Projektleiter eine bessere Note erhält, als ein Entwickler.

(Die Projektleiter bekamen in der Vergangenheit tendenziell bessere Noten, weil sie sich mehr engagiert hatten und bessere Ergebnisse erzielten. Teilweise zwingt sie ihre Rolle dazu.)

In der Projektstudie gibt es die Rollen "Projektleiter", "Entwickler", "Dokumentar", "Qualitätsmanager". Jeder Teilnehmer soll jede Rolle wenigstens ein. zwei Wochen ausüben. So meine Entscheidung. Wann ein Rollenwechsel stattfindet, überließ ich den Projektteams. Zusätzlich soll jeder Teilnehmer mindestens zwei der wöchentlichen Statusreports verfassen.

In der Realität verursachte meine Entscheidung Probleme. Einige Teams hatten die Zeitpunkte und die Verteilung der Rollen nicht gut durchdacht. So war zum Beispiel ein Teammitglied zu Beginn Projektleiter und wechselte mit Beginn der Entwicklungsarbeiten in die Entwicklerrolle. Ein anderes Teammitglied machte es umgekehrt. Der Effekt: das erste Teammitglied hatte zu Beginn wegen der Planungstätigkeiten viel Arbeit, ebenso später als Entwickler. Das andere Teammitglied hatte zu Beginn als Entwickler wenig zu tun, ebenso nach Beginn der Entwicklungsarbeiten als Projektleiter.

In der Halbzeitretrospektive äußerten sich die Teilnehmer:

• Einarbeitung zu aufwendig
• Aufgabenrotation ist nicht notwendig, da Stellvertreterregelung gelebt wird
• Ungeplante Aufgaben durch zusätzliche Kommunikation / Übergabe
• Ungleiche Arbeitsverteilung

Aber auch:

• Aufgabenrotation fördert Kommunikation
• Rotation ideal nach einer Iteration

Nach der Halbzeitretrospektive entschied ich, dass es nur noch eine Aufgabenrotation geben soll. Jeder Entwickler soll mindestens 3 Wochen in einer anderen Rolle arbeiten und umgekehrt. Jeder Teilnehmer erstellt mindestens zwei der wöchentlichen Statusreports.

Die Abschlussretrospektive bestätigte diese Entscheidung, die im kommenden Semester Bestand haben wird.

Aufgabenverteilung

In der Halbzeitretrospektive deutete es sich an, dass viele Teilnehmer zu sehr in ihren jeweiligen Rollen lebten, ohne das gesamte Projekt im Blick zu haben. Daher kam die Anregung, dass die Teams zukünftig die Planung gemeinsam durchführen (bis auf ein, zwei Mitglieder, die sich hauptsächlich um die Entwicklungsumgebung kümmern) und dies nicht nur dem Projektleiter überlassen. Während der eigentlichen Entwicklungsphase übernehmen dann alle Teilnehmer Entwicklungsaufgaben, mit unterschiedlichen Schwerpunkten. Ein, zwei Teammitglieder kümmern sich auch um das Qualitätsmanagement, ein Teammitglied erstellt auch die nötige Dokumentation. Protokolle, o.ä. werden reihum erstellt. Der Projektleiter koordiniert ggf. die Aktivitäten, entwickelt aber auch.

Ich selbst halte dieses Modell für angemessen. Es bedeutet ein gehöriges Maß an Teamgeist von Anfang an. Deshalb werde ich es in Zukunft fördern, nicht erzwingen.

Lernziele

Schön fand ich es, dass die Teilnehmer zur Halbzeit- und zur Abschlussretrospektive viele der Lernziele für sich erfüllt sahen:

• Kennenlernen der Kommilitonen
• Kommunikationsfähigkeiten ausbauen
• Arbeiten im Team
• Zusammenhalt, gegenseitige Hilfe
• Fehlerbehebung, Arbeiten unter Stress
• Terminmanagement ist wichtig, sowohl das persönliche als auch für das Team
• Verantwortung übernehmen
• Anwendung der Programmierkenntnisse
• Kennenlernen praxisnaher Werkzeuge (Trac, Mercurial, Maven, Jenkins, Liferay, ...)

Einige Teilnehmer meinten, dass die Erfahrung in der Projektarbeit nützlich für jede Bewerung sein wird. Ich hoffe das.

Coaches

In diesem Semester gab es zwei Coaches: ein Coach für das Projektmanagement und ein Coach für technische Fragen. Liferay und die Entwicklung von Portlets war für viele etwas ungewohnt.

Die Entscheidung für zwei Coaches wurde von allen positiv aufgenommen. Sie waren gute Ansprechpartner und haben mit Rat (und nicht mit Tat, so soll es sein) den Teams weitergeholfen.

Auch von mir ein "Dankeschön" an E.K. und M.A.!

Frag-würdiges

Zwei Punkte sind für die Teilnehmer fragwürdig gewesen. Zuerst den der Teamzusammensetzung.

Ich setze die Teams nach dem Zufallsprinzip zusammen. Entweder mit einem Würfel oder mit einer kleinen Session in Python. Zur Halbzeitretrospektive wurde diese Entscheidung hinterfragt.

Nach Meinung der meisten Teilnehmer sollte in jedem Team mindestens ein "guter" Entwickler sein, der zugleich Ansprechpartner für "schwache" Entwickler ist. Zugleich soll er die Rolle eines "Chef-Entwicklers" ausüben und für die Architektur verantwortlich sein, sowie den Quellcode der anderen überprüfen. Alle Teams sollten in etwa gleich stark sein.

Gut fand ich den Gedanken eines Teilnehmers, ob alles auf die Entwickler "geschoben" werden soll. Zur Abschlussretrospektive kamen Fragen auf, wie man erkennen kann, dass jemand "gut" ist. Gute Noten in den Programmierveranstaltungen lassen nicht unbedingt auf gute Fähigkeiten schließen. Rückblickend war es für alle schwierig zu entscheiden, was die einzelnen Teammitglieder wirklich können. Das hat sich erst während der Projektarbeit herauskristallisiert.

Abschließend haben sich alle mit der zufälligen Verteilung auf die Teams anfreunden können, zumal sie so ihre "Soft Skills" verbessern konnten. Manche kannten sich vorher nicht so gut, wie zum Ende hin.

Den anderen "frag-würdigen" Punkt finde ich ebenfalls bemerkenswert: ein Team überlegte, welchen (wirtschaftlichen) Wert ihre Arbeit besitzt. Dieses Team führte eine Kostenanalyse durch. Schön, wenn die Teilnehmer so Kenntnisse aus den BWL-Fächern vertiefen.

Tipps

Zum Abschluss noch Tipps der Teilnehmer, meine Anmerkungen sind kursiv:

• Klare Zielsetzung schaffen, zur Not mehrfach nachfragen.
  • Oh, ja!
• Beim Aufbau des Wikis nicht unbedingt auf die Vorgänger vertrauen.
  • Kann ich nur unterstützen. Die Vorgänger könnten das eine oder andere falsch gemacht haben. Also trotz Kopieren das Nachdenken nicht vergessen.
• Einarbeitung in vorhandenen Programmcode ist schwieriger als ein komplett neues Projekt zu beginnen.
  • Kommt auf den Programmcode an...
• Codepräsentation frühzeitig durchführen.
  • Ich kann verstehen, dass man Unangenehmes vor sich herschiebt. Bei der Codepräsentation, das de facto ein (bewertetes) Review ist, erhalten Sie Hinweise zur Verbesserung. Das hilft Ihnen und Ihrem Projekt.
• Einarbeitung in Liferay ist nicht einfach.
  • Hmm, das sollte durch frühere Veranstaltungen abgedeckt sein. Laut Dozent wurde es auch behandelt. Haben Sie das Thema übersprungen / nicht näher studiert?
• Schon in den ersten Semestern kleinere Entwicklungsprojekte durchführen.
  • Wird von einigen Dozenten verstärkt durchgeführt. Evtl. hilft auch die geplante neue Version der SPO.

Falls ich etwas vergessen oder ungeschickt dargestellt habe, senden Sie eine E-Mail / DM an mich. Oder hinterlassen Sie einen Kommentar zu diesem Blogeintrag.

Wieder einmal regen sich einige Leute auf. Dropbox soll die Benutzer "belogen" haben, was die Sicherheit ihrer Daten betrifft.

Unabhängig von möglichen Versprechungen auf der Website von Dropbox, wundert mich, dass jemand mit etwas technischem Verstand diese wirklich ernst genommen hat. Wenn Klartextdaten von einer Website herunter geladen werden können, dann muss der Betreiber auf diese Daten im Klartext Zugriff haben. Es sei denn, der Benutzer hat auf seinem Rechner zum Download eine spezielle Software installiert (direkt oder durch den Beteiber). Das ist aber bei Dropbox nicht der Fall.

Der Konkurrent Wuala verschlüsselt tatsächlich nur beim Benutzer, ein Webzugriff erfolgt über ein Java-Applet. Ist das sicherer? Vielleicht. Denn ich muss Wuala vertrauen, dass sie in den Verschlüsselungmethoden keine Hintertür eingebaut haben.

Bei allen Diensten, die ich nutze gilt: ich muss dem Administrator / Diensterbringer vertrauen. Alles andere funktioniert nicht. Oder ich betreibe alle Dienste selbst. Wenn ich meine Daten "sicher" haben möchte, dann packe ich einen TrueCrypt-Container in meine Dropbox. Oder in meinen Wuala-Space.

Mich wundert, weshalb Wired und Netzpolitik jetzt diese Kuh durch das digitale Dorf treiben. Haben wir schon das Sommerloch? Oder fehlt beiden das grobe technische Verständnis? Ich weiß nicht, was mich mehr beunruhigen sollte. Die "Lüge" von Dropbox oder der technische Mangel von technologie-orientierten Webseiten.

Neue Konzepte ausprobieren macht Spaß. Fossil ist eine interessante Mischung aus verteiltem Versionskontrollsystem, Wiki und Issue-Tracking-System. Für Eingeweihte: ein Trac verschmolzen mit Mercurial. Der große Vorteil: es wird kein zentraler Server benötigt. Der kleine Vorteil: Fossil besteht aus einer einzigen Datei, die Repositories ebenfalls.

Leider unterstützt Fossil nicht den Import von Mercurial-Repositories, noch Mercurial den Export in Fossil-Repositories. Was tun? Den Umweg über Git nehmen. Zwei Seiten helfen weiter:

• Converting from Mercurial to Git
• Fossil: Import And Export

Im ersten Schritt ist das Tool fast-export zu installieren:

cd /path/for/scripts
git clone git://repo.or.cz/fast-export.git

(Ich setze einmal voraus, dass auf dem System Git installiert ist ...)

Nun steht dem Konvertierungsvorgang nichts im Wege:

git init /tmp/git-repo
pushd /tmp/git-repo
/path/for/scripts/fast-export/hg-fast-export.sh -r /path/to/mercurial-repo
git fast-export --all | fossil import --git /path/to/fossil-repo
popd
rm -rf /tmp/git-repo

Hmm, das wäre ja ein Kandidat für ein eigenes Shell-Skript ;-).

Übrigens, erste Experimente zeigen, dass Fossil die Daten am besten komprimiert. Danach kommt Git und zum Schluss Mercurial. Aber alles innerhalb von ca. 20%, also nichts weltbewegendes.

Eben bin ich mal wieder über den Nerdtest gestolpert. Genauer gesagt, dessen zweite Version. Die erste Version hatte ich schon vor einiger Zeit gemacht. Damals war mein Ergebnis:

Der zweite Test ist etwas differenzierter. Hier mein heutiges Ergebnis:

Im Bereich Computer bin ich also etwas weniger nerdig geworden. Liegt vielleicht am Alter, ist aber im Rahmen der Messungenauigkeit ;-). Für die anderen Gebiete stimmt das Ergebnis in etwa mit meiner eigenen Wahrnehmung überein. Offenbar bin ich doch noch kein Trottel.

Mal sehen, wie das Ergebnis in einigen Jahren ausfällt. Nur Not vertiefe ich meine Lisp-Kenntnisse.