Große ZIP-Datei verschicken – eine Google-Odyssee

Ein ehemaliger Kommilitone wollte ein paar Dinge geschickt haben; gesagt, getan: 36 20 Megabyte. Seltsamerweise wollte das Mac-like Drag ‚n‘ Drop des Verzeichnisses nicht. Die Fehlermeldung, das „googlemail.com“ nur 34 Megabyte zulässt, veranlasste mich daher, etwas aufzuräumen. :) Aber auch die 20 Megabyte wollten nicht, diesmal ohne weitere Erklärung. Auch ein anderer GoogleMail-Account wollte nicht.

Okay, also über das Webinterface (Nervstufe 1). Im Safari wählte ich die Datei und schrieb den kleinen Satz und drückte „Senden“ — und da fiel mir auf, das die Mail gar keinen Anhang hatte? Also, nochmal „Neue Mail“, Datei wählen.. und nix. Kein Anhang.

Okay, also über den Firefox (Nervstufe 2). Die letzten Schritte wiederholt, und er lud auch brav die Datei mit Fortschrittsbalken hoch, nur um mir dann bei gefühlten 99, 999999999999999% (will heißen: die letzten 5 % haben mindestens 10x so lange wie die vorherigen 95% gebraucht) mitzuteilen, dass das Archiv wegen einer ausführbaren Datei nicht akzeptiert wird. Was? Hä? :)

Okay, prüfen wir die verf… Dateien (Nervstufe 3). Nun habe ich jede Datei geprüft, aber leider außer gefährlichen PDFs, sensiblen PNGs und potenziell terroristischen JPGs nur eine wirklich – naja, *hüstel* – nennenswerte Datei in irgendeinem Unterordner finden können: dateiname.chm. Warum auch immer. Umbenannt, wieder das Spielchen von vorne, keine Veränderung, Archiv immer noch illegal. (Nervfaktor 4).

Schlussendlich habe ich danach das Archiv.zip in Archiv.zip.itsonlyafuckingzipfile umbenannt und hochgeladen (via Mail).. und alles war wunderbar.

Google

Google hat also nebst so Allerweltssachen wie Mails, Cloud, Docs und Search also auch

  • ein paar Javascript Tools
  • verlinken als CDN die bekanntesten JS-Frameworks, gleichzeitig Anbieter von entsprechenden APIs für Maps, Analytics & Co.
  • Google Wave, „was vollkommen neues“, was irgendwie noch keiner (nicht viele) richtig einzurordnen / anzuwenden kann
  • ein eigenes Dateisystem (hm, man sieht noch nicht viel davon)
  • ein eigenes Betriebssystem (soll ja kommen, man hört nichts mehr)
  • ein eigenen Browser mitsamt Javascriptengine
  • just eine Internet-Protokollerweiterung/ersetzung namens SPDY von/für HTTP – mitsamt Spezifikationen, also nichts halbgares
  • „nur ein paar“ technische Paper, etwa zu Map/Reduce oder BigTable
  • nebst den nicht zählbaren Rechenzentren (geschweige Containern, ganz zu schweigen Rechnern) auch noch eigene Datenleitungen…

Und die Leute haben da noch Angst vor der Datenkrake – da bahnt sich doch ein ganz anderes – liebes? – Monster an.

Und Hinweise, Links? Google! Ha!

Ersatz für Thawte (personal e-mail certificates)

Kleine Randnotiz und Hinweis für diejenigen, die auch eine Alternative für Thawte suchen – zur Erinnerung: Die kostenlosen E-Mail-Zertifikate bzw. der Dienst dafür läuft in wenigen Tagen ab.

Eine Alternative ist TrustCenter mit seinem Angebot TC Internet ID. Auch dies ist ein E-Mail-Adressen basiertes und kostenloses Zertifikat – und dieses PKI-Zertifikat ist auch beim „Rest“ installiert und bekannt.

Howto: trac auf Mac OS X 10.6

Für den privaten Gebrauch – und für unterwegs, auf dem mobilen – kann sowohl ein Subversion als auch trac sicherlich eine Offline-Alternative sein.

Tatsächlich suchte ich nun eine Möglichkeit, „mal eben“ eine trac-Instanz aufzusetzen: Auf dem Webserver erschien mir zu komplex und kompliziert, eine neue VM auf dem Macbook etwas ineffizient, oder? :) Also warum nicht direkt unter OS X, bzw. technisch gesehen BSD?

Die initiale Suche nach der Thematik bringt einen schnell zu einer Fink-Lösung – also mal ehrlich, schon etwas aufwendig?

Tatsächlich gibt es auch einfachere Varianten, etwa hier. Aber auch hier wird noch einiges runtergeladen, kompiliert.. ach, Informatiker sind von Grund her faul. Nein, das ist es auch nicht.

# python2.6 ist bereits installiert.
python -version
> Python 2.6.1

Die abgespeckte, und funktionstüchtige Methode lautet daher – kurz und knapp:

sudo easy_install Pygments
sudo easy_install Genshi
sudo easy_install Trac

Das war es, trac ist installiert.

Für diejenigen, die nun auch eine Schnelleinweisung in eine erste Konfiguration brauchen, ein Schnelldurchlauf. Bemerk: Natürlich können auch andere Pfade für die Repositories verwendet werden, wichtig ist nur: Der eigene Benutzer muss später Lese- und Schreibrechte besitzen. Das heißt im Klartext: Entweder nachher „umgranten“ mit chown, oder woanders hinpacken. Auf /usr/local hat in der Regel nur der Superuser Zugriff, d.h. hier muss mit sudo gearbeitet werden.

# ein neues Subversion Repository anlegen
svnadmin create /usr/local/svn
# ein neues trac Repository anlegen - man kann alle Standardwerte nutzen, evtl. Pfad ändern
trac-admin /usr/local/trac initenv

Trac liefert einen kleinen Miniserver mit, der für diesen Zweck erst einmal reicht.

tracd --port 8000 /usr/local/trac/

Voilá.

Selbstverständlich brauchen wir noch einen User, zum Einloggen. Beispiel für den Benutzer user.

htpasswd -c /usr/local/trac/trac.htpasswd admin
> New password:
> New password:
> Re-type new password:
> Adding password for user admin
htpasswd /usr/local/trac/trac.htpasswd knalli
> New password:
> New password:
> Re-type new password:
> Adding password for user knalli

Jetzt den Server mit erweiterteten Parametern starten, also beispielsweise:

tracd --port 8000 --basic-auth=trac,/usr/local/trac/trac.htpasswd,trac /usr/local/trac

Eine Konfiguration über Apache2 ist dauerhaft eventuell zu empfehlen, aber für’s erste reicht es auch so. Ebenfalls empfiehlt die Dokumenation den Einsatz des Parameters –auth (Digest), dazu bitte jene konsultieren.