Update: I made a Cocoa App for this. The AppleScript is obsolete.

So I found Ryans Automator to do this at iamthekiller but it was not 100% perfect, so I added some of JosteinB’s suggestions from his blog and out came an AppleScript Application called AirPortClown, which you can download here:

And it looks something like this:

The source code is of course included in the download. MacDaddyX didn’t work for me and aaspoof is Shareware.

Update: If you look though the comments you will see that there is still some development going on, this version up here is for OS X 10.6.3 and 10.6.4 but you can download the version for OS X 10.6.2 here. Make sure your Airport is turned ON first when using the latest version.

Zum einen möchte ich auf drei Artikel von Dirk Einecke hinweisen. Sie beschreiben sehr ausführlich und sehr leicht verständlich, wie PGP mit Mail.app zusammenarbeitet. Ich bin von Thunderbird sofort auf Mail.app umgestiegen, weil ich es bisher, wie gesagt, unterschätzt habe:

http://blog.dirkeinecke.de/2008/01/apple-mail-und-pgp.html

Des Weiteren beschreibt er, wie man von einem Key den man mal erstellt hat, die Emailadresse usw. ändern kann. Sehr schön beschrieben:

http://blog.dirkeinecke.de/2008/01/e-mail-adresse-pgp-gpg-key-hinzufuegen.html

Und dann noch eine Anleitung zum Backup seiner Keys. Alles mit tollen Bildchen dokumentiert :)

http://blog.dirkeinecke.de/2008/01/pgp-gpg-schluessel-backup.html

Und hier ein weiteres richtiges Schmuckstück. Der integrierte Safari Web Inspector. Es handelt sich um eine Art “Firebug” (das ist ein Firefox-Plugin) für Safari 3.0 – nur built-in. Damit kann man seine Webseiten debuggen, analysieren usw.

http://www.agenturblog.de/2007-11/der-safari-web-inspector/

Zuerst habe ich meinen Useraccount auf dem Server namens “future” in den gleichen Usernamen geändert, den ich lokal auf meinem PowerBook benutze. Nämlich “futurec”. Das Passwort habe ich ebenfalls so angepasst, dass es auf dem Server jetzt das selbe ist wie auf meinem lokalen Rechner. Zuletzt noch das Homeverzeichnis umbenannt:

usermod -l futurec future
passwd futurec
mv /home/future /home/futurec

Dann habe ich auf meinem PowerBook (nach dieser Anleitung) folgendes eingegeben und mehrmals Return für die Abfragen eingegeben (also Standardeinstellungen):

ssh-keygen -t dsa

Anschließend habe ich mit Cyberduck und SFTP die Datei ~/.ssh/id_dsa.pub auf den Server geladen. Dort habe ich dann (in dem Verzeichnis wo ich die Datei hochgeladen habe) folgendes eingegeben. So wurde mein SSH-Public-Key in die vom Server authorisierten Keys aufgenommen und die hochgeladene wieder Datei gelöscht:

cat id_dsa.pub >> /.ssh/authorized_keys
rm id_dsa.pub

Dann musste ich in der Datei /etc/ssh/sshd_config sicherstellen, dass man sich per SSH überhaupt mit Keys einloggen darf:

PubkeyAuthentication yes
AuthorizedKeysFile /.ssh/authorized_keys

SSH neu starten:

/etc/init.d/ssh restart

Ab dann war es mir möglich, mich ohne Passwort, aber mit dem private Key ~/.ssh/id_dsa in z. B. Cyberduck einzuloggen.

Lokal auf dem Laptop habe ich dann die Datei ~/.ssh/config angelegt:

Host = fs
HostName = 123.123.123.123
User = futurec
Port = 4444

Und schon kann ich mich jederzeit ganz einfach mit diesem Befehl per SSH auf dem Server einloggen ohne jegliches Passwort eingeben zu müssen:

ssh fs

:)

Verzeichnis für Repositories auf dem Server erstellen:

mkdir /var/svn

Jetzt wird aus diesem Verzeichnis ein subversion repository gemacht:

svnadmin create /var/svn

Da der Server bisher nur über einen root Zugang verfügte, erstmal Benutzer anlegen, die subversion später nutzen werden:

useradd future
useradd manuel

Diese bekommen dann noch schöne Passwörter verpasst. Bei Eingabe wird ein gewünschtes Passwort für den jeweiligen user abgefragt.

passwd future
passwd manuel

Jetzt noch die home-verzeichnisse anlegen:

mkdir /home/future
mkdir /home/manuel
chown future:users /home/future
chown manuel:users /home/manuel

Damit wir uns später Arbeit sparen, legen wir eine Gruppe an, und setzen die neuen User in diese Gruppe. So ist es später leichter, Rechte für die Nutzung von SVN zu vergeben.

adduser future subversion
adduser manuel subversion

Jetzt bekommt die Gruppe (und somit future und manuel) Zugriff auf das vorhin erstellte svn repository. Der -R Parameter steht für rekursive, also alle Unterverzeichnisse inbegriffen (auf o. a. Artikel gibt es etwas mehr Details hierzu).

chgrp -R subversion /var/svn
chmod -R o-rwx /var/svn
chmod -R g+rw /var/svn
chmod g+s /var/svn/db

Jetzt wird es nochmal etwas tricky. Wenn oben genannte User Dateien erstellen und so weiter, dann werden diesen Dateien bestimmte Rechte gegeben. Nun wollen wir aber sicher stellen, dass niemand aus Versehen nur Rechte für sich selbst einräumt.

Dafür verwenden wir den UNIX Befehl umask. Wenn wir “umask 002″ aufrufen, heißt dass, dass von jetzt an bei Dateierstellung volle Rechte für die eigene Gruppe und lese und execute Rechte für alle andere gesetzt werden soll.

Da nicht jeder ständig diesen Befehl eingeben wird und möchte, “automatisieren” wir das ganz schlau. Nutzt jemand unser SVN repository, wird die Datei “svnserve” aufgerufen. Wir wechseln in das Verzeichnis, wo diese Datei sich befindet (“which svnserve” verrät uns wo das ist) und bennennen die Datei um! und zwar nehmen wir das letzte “e” weg:

cd /usr/bin
mv svnserve svnserv

Anschließend legen wir eine bash-Datei an, die genau so heißt wie unser svnserve vorher. In diese Datei schreiben wir folgendes:
Inhalt von /usr/bin/svnserve

#!/bin/bash
umask 002
/usr/bin/svnserv $*

Das bewirkt, dass jedes Mal wenn jemand svnserve (mit oder ohne Parameter) startet, er unser kleines Progrämmchen startet, dadurch automatisch “umask 002″ ausführt und dann erst das original svnserv. Schlau oder? (Den Trick habe ich übrigens hier gefunden.)

Jetzt befassen wir uns mit der Datei /var/svn/conf/svnserve.conf. Es handelt sich um die Konfiguration unseres svn repositories. In ihr passen wir ein paar Einstellungen wie folgt an:

[general]
anon-access = none
auth-access = write
realm = funkensturm

Damit geben wir anonymen usern “none” Rechte, future und manuel “write” rechte und noch einen Namen für unser Repository.

Auf dieser Seite habe ich ein paar Einstellungen gefunden, wie man den SSH Login usw. sicherer macht. Außerdem müssen wir ja noch unserer Gruppe subversion den Login per SSH erlauben!
Also ran an die Datei /etc/ssh/sshd_config (vorher backup machen!).
Die Datei ist ziemlich lang. Worauf es ankommt sind letzten Endes diese Werte:

Port 4444
AllowGroups subversion
LoginGraceTime 30
PermitRootLogin no

Damit haben wir den SSH Port von 22 (Standard) auf (z. B.) 4444 erhöht, damit nicht jeder Depp direkt den Port scannen kann. AllowGroups ist neu hinzugekommen, damit alle user in der Gruppe “subversion” SSH benutzen können. Die LoginGraceTime wurde auf 30 Sekunden gesetzt (Zeit zum Passwort eingeben). Da manuel und future sich jetzt einloggen können, können wir den login als root via SSH verbieten mit PermitRootLogin no.

Jetzt noch schnell SSH neu starten und die Änderungen sind aktiv:

/etc/init.d/ssh restart

FERTIG!

Ab jetzt kann man sich per SSH so auf dem Server (natürlich mit der richtigen IP und nicht 123…) einloggen:

ssh future@123.123.123.123 -p 4444

ABER!

Leider kapiert dein lokales svn nicht, dass er bei svn+ssh nicht den Port 22 nehmen soll, sondern unseren 4444. Dafür müssen wir LOKAL (also auf DEINEM MacBook oder PowerBook ;) folgende Datei anpassen: ~/.subversion/config

[tunnels]
fs = /usr/bin/ssh -p 4444

Damit sagen wir, dass ab jetzt svn+fs:// mit Port 4444 aufgerufen wird. (Man könnte auch anstelle “fs” auch “ssh” in die config Datei schreiben, dann würde bei svn+ssh:// immer Port 5777 verwendet werden. Aber das will man mit an Sicherheit grenzender Wahrscheinlichkeit nicht.)

Wenn man sein Projekt auschecken möchte, wird für unseren Server also ab jetzt das hier benutzt:

svn co svn+fs://future@123.123.123.123/var/svn/projekt

Zum hochladen eines neuen Projektes:

svn import projektname svn+fs://future@123.123.123.123/var/svn/projektname -m "Beschreibung der Änderung"

YEAH BABY!

Das ganze ist aber eigentlich recht einfach. Jetzt steht der BasicAuth Code im vhost drin und das sieht dann so aus:

<proxy *>
AuthName “Nur mit Passwort”
AuthType Basic
AuthUserFile /pfad/zur/.htpasswd
require valid-user
</proxy>

ProxyRequests Off
ProxyPreserveHost On

ProxyPass / http://0.0.0.0:3000/
ProxyPassReverse / http://0.0.0.0:3000/
ErrorLog /pfad/zum/server.log

wichtig war die Direktive <proxy *> in der der BasicAuth Code stehen muss. Sonst wird es einfach ignoriert!

Update:
Und so wird es dann in Rails 2.0 gemacht: HTTP Basic Authentication

• Gnu Privacy Guard für Mac (» download 1.4.7)
• (Ggf. hier überprüfen ob es schon eine neuere Version als 1.4.7 gibt.)
• Thunderbird 2 für Mac (» download)
• Enigma Add-on für Thunderbird (» download)

GnuPGP zu installieren ist selbsterklärend. Wohin es installiert wurde ist allerdings eine Wer-wird-Millionär-Frage. Nur das Terminal hilft uns mit folgendem Befehl weiter: locate gpg Edit:Auf Wunsch von Nils hier eine Erklärung, wie man zum Terminal kommt:Programme -> Dienstprogramme -> Terminal starten (oder: Apfel + Leertaste und dann “terminal” eintippen.) und dann einfach locate pgp eintippen.

/usr/local/bin/gpg ist die richtige Antwort unter vielen:

Thunderbird 2 und das Enigma-Add-on zu installieren ist ebenfalls selbsterklärend. Jedoch brauchen wir bei der Einstellung von Enigmail die oben gefundene Antwort (sonst stand da immer “GnuPG konnte nicht gefunden werden”):

Das hat mich echt Nerven gekostet :)Der Rest ist ein Kinderspiel. Wenn man noch keine hat, erstellt man sich einen öffentlichen und privaten PGP-Key in Thunderbird (jetzt mit Enigma Add-on):

und dann:

Und schon kann es losgehen (sofern man die öffentlichen Schlüssel seiner gewünschten Empfänger kennt)!

Dies ist ein offizieller Wink mit dem Zaunpfal an Manuel. Schaff’ es dir an, ich will mit dir PGPen :)Und für alle die noch gar nicht wissen was PGP ist, hier ein mehr als ausführlicher Bericht.