Nun will es der Zufall, dass ich Git für einige Webprojekte einsetze. Auf diversen Seiten, so auch auf Github gab es den Hinweis, in der Config folgendes Einzutragen:

Dies verhindert mögliche Probleme mit Windowsusern, wenn deren Editor mit LF Zeilenenden (Standard unter Unix und Linux Systemen, und eben auch unter Mac OS X) nicht zurecht kommt. Da viele Editoren unter Windows LF automatisch in CRLF (Windows Zeilenendsteuerzeichen) umwandeln, würde dies Änderungen in jeder Zeile einer geänderten Datei ergeben.

Daher solle man doch lieber gleich mit CRLF arbeiten, wenn ggf. Windowsuser mit ins Repository pushen.

So weit so gut. Bis vor einiger Zeit funktionierte das auch alles wunderbar, und funktioniert auch immer noch.

Allerdings macht das mit Homebrew Probleme. Homebrew ist ein Packetmanager für Mac OS X, ähnlich wie MacPorts oder Fink. Homebrew ist wesentlich schlanker als oben genannte Alternativen und setzt wenn möglich auf Versionen von Programmen, die bereits standardmäßig auf OS X vorhanden sind.

Auf jeden Fall hat der Aufruf von ‘brew’ mir folgende Fehlermeldung eingebracht:

Ich konnte mir erst keinen Reim darauf machen. Was ist passiert? brew hat beim Updaten sich selbst überschrieben und die Zeilenendsteuerzeichen von LF auf CRLF geändert und sich damit selbst ins Nirvana geschossen, da es Ruby nicht mehr aufrufen konnte.

Ich habe /usr/local/brew in Textmate geöffnet und neu unter gleichem Namen, jedoch mit LF statt CRLF gespeichert. In der Datei /usr/local/.git/config habe ich noch folgende Zeile eingetragen:

Das überschreibt den Wert aus ~/.gitconfig und verhindert das Umwandeln.
Vielleicht ist es auch einfach Sinnvoll Auto-CRLF nur zu setzen, wenn man es wirklich braucht. Keine Ahnung.

Jedenfalls wollte ich an dem Problem, bzw. dessen Lösung teilhaben lassen, da ich irgendwie keine sinnvollen Ergebnisse ergooglen konnte.

Ich will euch nun zeigen, wie ihr recht einfach mit UNIX-Bordmitteln entsprechende Backups ziehen könnt, ohne Shell-Zugriff auf den Webserver haben zu müssen. (Ein Backup mit Hilfe von rsync oder ähnlichem, per SSH ist dieser Methode definitiv vorzuziehen. Vorsicht, diese Methode sendet eure Logindaten unverschlüsselt übers Internet!)

Vorbereitung

Für dieses Tutorial braucht ihr das UNIX-Tool wget. Unter Mac OS X ist dies nicht standardmässig installiert, weshalb ihr es z.B. mit MacPorts, Fink oder Homebrew nachinstallieren solltet. Ich persönlich nutze Homebrew und habe darüber nicht nur wget, sondern auch andere nützliche Helferlein wie nmap, htop und einige andere installiert. Für Windows gibt es das Projekt Cygwin.

Anleitungen zur Installation dieser Paket-Manager findet ihr auf den entsprechenden Seiten. Bitte lest erst weiter wenn Ihr wget nachgerüstet habt.

Es empfiehlt sich nun, an passender Stelle eine Ordnerstruktur für eure Backups anzulegen. In meinem falle ist dies /Users/julius/Daten/websites/backups/. Wget legt dort für jede Website einen Unterordner an, um die einzelnen Backups auseinander zu halten.

Nun müssen wir ein bisschen schwarze Magie auf der Komandozeile ausführen. Aber keine Angst unter OS X gibt es Möglichkeiten, das Ganze später mit einem Mausklick oder per Cron-Job auszuführen.

Mit dieser einfachen Zeile im Terminal ladet ihr euch rekursiv den kompletten Inhalt des FTP-Servers in einen neuen bzw. bestehenden Ordner herunter.
Für viele ist hier schon Schluss, da es für einfache HTML-Webseiten ausreicht.

Wenn man möchte kann man nun diversen Voodo mit seiner Sicherheitskopie anstellen. Man kann ein rotierendes Backup erstellen, kann die Dateien mit Git Versionieren (das ist das, was ich momentan mache), sie komprimieren und auf dem Netzlaufwerk archivieren etc. Der Fantasie sind hier keine Grenzen gesetzt.

Sobald ich meinen Workflow so habe wie ich es mag, werde ich das noch mal etwas ausführlicher beschreiben.

Wie immer: Solltet ihr Fragen, Wünsche, Feedback haben, immer her damit!

Dies erzeugt einen Link der den Titel, die URL des Beitrages sowie euren Twitternamen an Twitter übergibt. Klar kann man dafür auch ein tolles Plugin basteln, aber wenn man das mit einer Zeile Code realisieren kann, warum so umständlich.

Dieser Codebaustein sollte am besten im Loop stehen. D.h. z.B. in der page.php, index.php und single.php an folgender oder ähnlicher Stelle:

Ich hoffe, das hat euch was gebracht. Wenn ihr den Codeschnipsel benutzen wollt, ändert doch bitte den eingetragenen Twitternamen auf euren. ;)

Webentwicklung auf dem laufenden Webserver auf dem die Zielseite liegt, kostet nicht nur Nerven und Traffic, nein es macht euch auch immer abhängig von einem Netzzugang. Warum kompliziert, wenn es auch einfach(er) geht?

So kann man ganz gemütlich in der Bahn oder im Bus weiterentwickeln und bastelt nicht am live System herum, sondern auf seiner ganz privaten Mampp Maschine (Mac Apache & MySQL & PHP & Perl).

Es gibt sogar “out of the Box” Lösungen wie etwa xampp für den Mac oder MAMPP. Ich möchte euch jedoch zeigen, wie ihr euren Mampp selbst einrichtet, um euch gleichzeitig das nötige Basiswissen an die Hand zu geben, wie ihr mit den Konfigurationsdateien umgeht, was euch bei der Konfiguration eures Live Systems helfen könnte.

Fangen wir also an:

Was brauchen wir? Wir brauchen MySQL und einen Apache Webserver, ich bevorzuge hier den Apache2, da der einige Features mehr mitbringt als der alte Apache1 und schon seit längerer Zeit ein quasi Standard ist.

Was also tun? Richtig, wir informieren uns, ob es den Apache2 für den Mac bereits irgendwo gibt. – Und siehe da: Unter dem Menüpunkt “Sharing” gibt es die Option “Websharing”. Hinter dieser Option versteckt sich bereits ein Apache2 der nun nur noch eingerichtet werden muss.

Was nun? Nun können wir uns einen Keks freuen, da der Apache scheinbar schon läuft. Das können wir nun überprüfen in dem wir http://localhost in unseren Browser eintippen.

Dann sollte das Ganze übrigens in etwa so aussehen:

Mac OS X hat euch eine private Seite in das Verzeichnis /Users/username/Sites oder im deutschen Finder “Websites” angelegt.

Soweit so gut.

Jetzt geht es darum, herauszufinden, wo der Apache liegt, und wo die entsprechenden Konfigurationsdateien zu finden sind.

Dazu gehen wir ins Terminal und versuchen es mal auf gut Glück mit dem Standartverzeichnis des Apache2 unter Unix Systemen und öffnen das Verzeichnis mit dem Befehl “open /etc/apache2/” (ohne Anführungsstriche). Jetzt öffnet sich ein Finder Fenster mit dem Ordner, an den man sonst ohne weiteres über den Finder nicht herankommt.

Im Ordner “users” befindet sich für jeden User auf dem System eine Datei in der den Ordner angibt, in dem die Website liegt. Diesen Ordner könnt ihr nach belieben ändern.

Okay, soweit so schön. Nun möchten wir aber nicht immer das Tildezeichen (~) welches ihr auf eurer Tastatur nicht findet (alt+n) eintippen, sondern einfach http://localhost oder http://127.0.0.1 was das gleiche ist.

Dafür müssen wir das Document Root des Webservers ändern. Dazu suchen wir in der httpd.conf nach “DocumentRoot”. Ich werde in Zeile 160 fündig und ändere den Eintrag entsprechend. Das gleiche noch in Zeile 191.

Ich möchte mit .htaccess Dateien arbeiten, da ich diese aus diversen Gründen auch in meinen Projekten einsetze. Daher muss ich noch festlegen, welche Optionen aus der .htaccess übernommen werden. Ich setze den Wert für “AllowOverride” auf All um möglichst große Freiheit zu haben. Da ich der einzige bin, der auf diesem Rechner Schreibrechte hat, ist das so auch in Ordnung.

Da der Webserver auf meinem Mac eine reine Entwicklungsumgebung werden soll, möchte ich nicht, dass jemand von ausserhalb darauf zugreifen darf. Daher schränke ich den Zugriff mit der Direktive Allow für dieses Verzeichnis ein. Ich setze als neuen Wert Allow from 127.0.0.1

Nun kann ich nur noch von meinem Rechner aus zugreifen. Und auch nur noch über http://127.0.0.1

Nun probieren wir das Ganze doch mal aus. Um eure Änderungen wirksam zu machen, müsst ihr den Apache neu starten. Das geht am einfachsten indem ihr in der Systemsteuerung das Websharing einmal aus- und dann wieder einschaltet. Natürlich geht das mit dem Terminal viel schneller, aber wir bleiben mal beim Einfachen weg.

So sieht das Ganze nun bei mir aus. Da ich keine index.html im DocumentRoot habe, werden mir die Ordner darin dank der Option Indexes in der httpd.conf angezeigt.

Herzlichen Glückwunsch schon mal. Dein Apache läuft und ist deinen Bedürfnissen angepasst. Nun gehts weiter im Text. Es fehlen noch PHP, MySQL und der Perl-Support. Ihr könnt aber auch noch ein wenig in der httpd.conf herumstöbern. Diese Konfigurationsdateien sind in der Regel recht gut dokumentiert.

Als nächstes gucken wir uns an, ob PHP nicht bereits läuft. Dafür legen wir eine Datei mit dem Namen info.php in das Verzeichnis und schreiben dort rein: <? phpinfo() ?>.

Und siehe da: PHP läuft bereits in der Version 5.3.0. Auf der Seite könnt ihr euch auch noch angucken, was bereits an Modulen geladen ist. So ist z.B. die Unterstützung für GD, eine Grafikbibliothek zur Manipulation von Bildern bereits geladen.

Da wir bereits vorher den Zugriff auf unseren Webserver eingeschränkt haben, und das Thema der Absicherung einer PHP-Installation erstens ganze Bücher füllen könnte, und ich zweitens auch in keinster Weise kompetent genug wäre, gehe ich darauf nicht weiter ein.

(Merke: In OS X 10.5 musste PHP explizit in der httpd.conf als Modul geladen werden!)

Nun kommt MySQL dran. Als erstes laden wir die Installationsdatei herunter: http://dev.mysql.com/downloads/mysql/5.1.html. Der Installer für 10.5. funktioniert auch unter 10.6. Auf der oben referenzierten Seite steht auch ein MD5-Hash für das Paket. Dies ist wichtig, da wir den Download verifizieren wollen. Haben wir die richtige Version? Wurde sie manipuliert oder können wir das Paket beruhig installieren?

Die beiden Hashes stimmen überein. Daher können wir davon ausgehen, dass an der Datei nichts manipuliert wurde. Soweit so gut.

Noch schnell das Prefpane und das Startupitem installieren und dann den Server gestartet:

Nun haben wir also einen Webserver mit PHP und MySQL. Um zu testen ob es läuft, verbinde ich mich mit Sequel Pro, einem coolen Programm zur Manipulation von MySQL Datenbanken auf Localhost mit dem Benutzernamen root (kein Passwort benötigt).

Und siehe da, es funktioniert. Wunderbar, was will man mehr? Ab diesem Punkt könnt ihr aufhören zu lesen. Ihr habt einen laufenden Webserver mit MySQL. Ihr solltet dennoch kurz weiterlesen. ;)

Nun sollten wir MySQL der PATH Variable in unserer Shell hinzufügen. Solltet ihr mit der Bash, der Standartshell unter Mac OS X ab 10.3 arbeiten, gebt einfach folgenden Befehl in eure Shell ein*:

open /Users/username/.bash_profile

und fügt folgende Zeilen hinzu:

export PATH=/usr/local/mysql/bin:$PATH

alias mysql=/usr/local/mysql/bin/mysql

alias mysqladmin=/usr/local/mysql/bin/mysqladmin
Solltet ihr eine andere Shell nutzen, wisst selbst warum, und werdet euch so gut mit eurem System auskennen, um die PATH Variable selbst anzupassen. ;)
Nun müsst ihr euer Terminal einmal schließen und wieder öffnen. Die Einstellungen aus der .bash_profile werden nur beim Start der Bash geladen. Wenn Ihr also Änderungen an der Datei vornehmt, müsst ihr nach dem Speichern eine neue Bash aufmachen, damit das funktioniert.

Nun könnt ihr mysql bzw. mysqladmin auch von der Befehlszeile aus nutzen, was manchmal von Vorteil ist.

Hier noch ein Hinweis von dev.mysql.com:

Das Mac OS X-PKG von MySQL installiert sich im Verzeichnis
/usr/local/mysql-VERSION.
Ferner wird eine symbolische Verknüpfung
/usr/local/mysql eingerichtet, die ebenfalls
auf die neue Position verweist. Ist ein Verzeichnis namens
/usr/local/mysql bereits vorhanden, dann wird
dieses zunächst in /usr/local/mysql.bak
umbenannt. Außerdem erstellt das Installationsprogramm die
Grant-Tabellen in der mysql-Datenbank. Hierzu
führt es den Befehl mysql_install_db aus.

Nun gehen wir daran, das System etwas sicherer zu machen. Momentan hat nämlich der Hauptuseraccount (root) unseres MySQL Servers gar kein Passwort… O.o
Das müssen wir schnell ändern.

Mit dem Befehl

sudo mysql_secure_installation

ruft ihr ein Script auf, dass euere MySQL Installation absichert (geht nur mit gesetzter $PATH Variable). Ihr müsst ein Passwort für den User Root angeben (bitte unbedingt merken. :D), solltet den Anonymen Login abschalten, den Login für Root von Remotehosts ausschalten, die Tabelle Test löschen, und die Tabellen neu laden.

Nun ist unsere MySQL Installation ersteinmal ausreichend gesichert.

Eure Test- und Entwicklungsumgebung sollte nun entsprechend laufen. Alles weitere ist nettes Beiwerk. Solltet ihr euch entscheiden das Ganze als Produktivumgebung, also als ernsten Webserver laufen zu lassen, wäre es sinnvoll, auch an SSL zu denken. Wenn ihr aber nur von localhost darauf zugreift, braucht ihr logischerweise auch kein SSL.

Ich installiere ein WordPress Blog um noch mal zu testen, ob wirklich alles läuft:

Läuft! :)

Ich werde mich in diesem Tutorial nicht mit weiterführenden Themen beschäftigen. Das Thema Perl, SSL o.ä. behandle ich ggf. später noch mal. Wer sich zum Thema SSL einlesen möchte, dem empfehle ich mein Tutorial zum Apache auf 10.5. Dort habe ich das Thema SSL (Zertifikatserzeugung, einbinden in den Apache, etc.) in epische Breite behandelt.

Wie immer: Kritik, Anregungen, Danksagungen etc. dürfen gern in Form von Kommentaren oder E-Mails geäussert werden.

Ihr kennt doch alle diese tollen “Web2.0″ Buttons und Badges. Ein solches habe ich für euch im Illustrator CS3 erstellt.
Da ein Video mehr als tausend Bilder sagt, hier das Video:

Download als High Ress
Download des fertigen Illustrator Dokuments

Über Feedback in den Kommentaren freue ich mich wie immer. ;)

Die technischen Details könnt ihr auf Wikipedia nachlesen. (openPGP bei Wikipedia)

PGP kann also Daten Signieren und damit die Unverfälschtheit und die Echtheit der Quelle sicher stellen (Wenn die Daten verändert wurden, oder der Absender nicht mit dem richtigen Schlüssel signiert hat, gibt es eine Fehlermeldung und der Empfänger muss davon ausgehen, dass der Inhalt der Mail nicht echt ist).

Es ist im Allgemeinen überhaupt nicht schwierig fremde E-Mails zu lesen. Entweder wird der Datenstrom von eurem Rechner zum Gateway (z.B. Router) belauscht, oder im Internet mitgeschnitten. Die für einen solchen “Lauschangriff” einzusetzenden Programme sind kinderleicht zu bedienen (selbst ich kann soetwas) und frei im Internet erhältlich. Alternativ kann jemand Zugang zu euren E-Mails erhalten, in dem er sich unberechtigter Weise Zugriff auf euren Mailserver verschafft. Kann er den Server z.B. durch das Ausnutzen einer bekannten Sicherheitslücke oder durch Ausspähen eines Administrator-/Rootpasswortes mit den nötigen Rechten ausgestattet nutzen, so kann er alle E-Mails die dort im Klartext abgelegt sind, lesen.

Wenn ihr nicht möchtet, dass irgendwer durch Abfangen eurer gesendeten Daten, oder den unberechtigten Zugriff auf den E-Mail Server z.B. geschäftliche Absprachen oder die E-Mails an die Liebste zu Hause lesen kann, könnt ihr die E-Mails zusätzlich zur Signierung auch noch verschlüsseln.

Zusätzlich könnt ihr auch eure Daten verschlüsseln. Zum Beispiel ist dies bei Backups sinnvoll. In der Regel enthalten diese sehr sensible Daten und sollten geschützt sein. Dafür gibt es natürlich mehrere Alternativen: Die Medien könnte man in einen Safe einschließen, oder sie, was einfacher ist, einfach verschlüsseln. Hat man erst einmal Zugriff auf fremde Backups die nicht verschlüsselt sind, kann man nach Belieben darin herumstöbern. Eine DVD mit gesicherten Daten achtlos auf dem Schreibtisch liegen gelassen, und schon könnte der Chef, Kollege, Nachbar oder Einbrecher eure Urlaubsbilder, Liebesbriefe, Tagebücher, gespeicherte Passwörter und was weiss ich nicht was lesen. Sind diese Daten aber verschlüsselt abgelegt, wird das fast unmöglich.
Nachem ich euch erklärt habe, wofür Ihr GnuPG einsetzen könnt, geht es jetzt ans Eingemachte: Die Installation und Verwendung.

Um Loszulegen brauchen wir erst einmal einige Programme:

• MacPG – GnuPG Quelldateien mit einem Installer für Mac OS X (Direktdownload für Mac OS X 10.4)
• GPG Schlüsselbund – Analog zum Mac OS X internen Schlüsselbund ein Tool mit dem die GPG Schlüssel bequem verwaltet werden können.
• GPGFileTool – Programm zum Verschlüsseln und Signieren von Dateien (Für Backups, etc.)
• GPGPreferences – Plugin für die Systemeinstellungen zum einfachen konfigurieren von GnuPG

Sowie eines der folgenden Plugins für euer Mailprogramm:

• GPGMail – Plugin für Apples “Mail”
• EntourageGPG – Plugin für Mircosofts Entourage
• Enigmail – Plugin für Mozilla Thunderbird

Habt ihr alles heruntergeladen, ist die Vorarbeit getan. Jetzt geht es wirklich los. GnuPG ist ein reines konsolenbasiertes Programm. Da wir aber ein wenig tippfaul sind, und die Konsole noch nie genutzt haben, hätten wir gern alles simpel und wie wir es gewohnt sind. Dafür die ganzen Programme. Die nun folgenden Schritte sollten in Etwa 10-20 Minuten in Anspruch nehmen. Danach kann man E-Mails signieren und, sofern man die Schlüssel mit dem anderen ausgetauscht hat, auch Verschlüsseln.

Installiere folgende Programme: MacPG (GnuPG), GPG Schlüsselbund, GPGFileTool und GPGPreferences.

Ist dies geschehen, rufst du GPGPreferences über deine Systemeinstellungen>Sonstiges auf. Die Einstellungen kannst du ungesehen übernehmen. Zur Sicherheit solltest du aber prüfen, ob 1. Die öffentlichen Schlüssel zum Prüfen einer Signatur automatisch vom Schlüsselserver heruntergeladen werden und ob du einen Schlüsselserver ausgewählt hast. (Register “Server”)

Nun kannst du mit dem GPG Schlüsselbund ein Schlüsselpaar erzeugen. Über “Schlüssel>Erzeugen” rufst du einen selbsterklärenden Assistenten auf, der dich durch den Prozess der Schlüsselerzeugung führt. Ich empfehle eine Schlüssellänge von 4096 Byte. Das ist zwar etwas rechenintensiver, hat jedoch den Vorteil einer stärkeren Verschlüsselung.

Wärend der Einrichtung muss eine Phassphrase eingegeben werden. Diese sollte wenn möglich nicht aus einem einzigen Wort bestehen. Sinnvoll sind längere Sätze in denen Zeichen z.B. Zahlen ausgetauscht werden. Eine mögliche Passphrase wäre also: 1ch b3nutze zum 3rsten M@l GPG/PGP und b1n sch0n ganz gespannt wie es läuft! (Diese Phassphrase natürlich bitte nicht nutzen!)

Hast du alle Angaben gemacht, werden die Schlüssel erzeugt. Hierfür benötigt der Rechner eine Menge Zufallszahlen und einiges an Zeit. Du solltest dich also nicht wundern, wenn der Prozess etwas länger dauert. Inzwischen kannst du dich im Internet ein wenig über PGP bzw. openPGP informieren.

Nun muss dein Schlüssel auf einen Schlüsselserver hochgeladen werden. Dies geht am einfachsten über das Programm “GPG Schlüsselbund”. Wenn du den Schlüssel auswählst, und “Schlüssel>Zum Schlüsselserver senden” ausführst, öffnet sich wieder eine Konsole die dir die Tipparbeit abnimmt.

Indem ihr das Plugin für eure favorisierte Mailing Anwendung installiert, macht ihr GnuPG für euer E-Mail Programm nutzbar. Hier könnt ihr noch diverse Einstellungen machen. Zum Beispiel, ob eure E-Mails generell digital signiert werden, ob immer dann, wenn es möglich ist, verschlüsselt gesendet werden soll, und wie lange eure Passphrase gespeichert werden soll. Die Möglichkeit, sie generell zu speichern, sollte mit Vorsicht genossen werden. Sie macht euren Schlüssel nicht unbedingt sicher. Jeder, der auf irgendeine Weise Zugriff auf euren Rechner hat, könnte den Schlüssel kompromitieren, da er neben dem geheimen Schlüssel nun auch die dazugehörige Passphrase hat. Ein guter Mittelweg ist es, den Key für die aktuelle Sitzung zu speichern. So kann niemand euren Key nutzen, ohne dass ihr vorher die Passphrase eingegeben habt.

Im allgemeinen ist die Anwendung z.B. zusammen mit “Mail” recht unkompliziert, simpel und selbsterklärend. Sollte ich mal wieder etwas Zeit haben, werde
ich diese kleine Anleitung auch mit diversen Screenshots würzen und noch etwas ausbauen.

Für alle, die genau wissen wollen, was hinter den ganzen Programmen abgeht, habe ich hier noch einen kleinen Text über die Erzeugung eines Schlüssels über die Konsole zusammengeschrieben. So schwer wie es vielleicht aussieht, ist es gar nicht. Ausserdem findet ihr so vielleicht Gefallen an der Konsole und deren Möglichkeiten.

Fink ist in der aktuellen Binärversion nicht für Mac OS X 10.5 verfügbar, lässt sich aber mit ein paar Kniffen trotzdem installieren:

Als erstes müssen wir folgende Datei herunterladen und entpacken:
http://sourceforge.net/project/downloading.php?groupname=fink&amp;filename=fink-0.28.0.tar.gz

Öffnet ein Terminal und wechselt mit cd in das entpackte Verzeichnis. (Tippt notfalls cd ins Terminal und zieht dann den Ordner aus dem Finder ins Terminal.)

Danach könnt ihr mit dem Befehl ./bootstrap die Installation starten.

Nun werdet ihr durch die Installation geführt. Beantwortet die Fragen. Meistens sind die voreingestellten Antworten nicht verkehrt. Wenn ihr mögt, könnt ihr euch andere Mirrors als die vorgegebenen aussuchen.

Wenn der Download und das Compilieren fertig ist, könnt ihr loslegen. Mit sudo fink selfupdate aktualisiert ihr Fink auf die aktuellste Version. Diesen Vorgang solltet ihr regelmäßig wiederholen. Nur ein aktuelles System ist einigermaßen sicher. Oder anders gesagt: Ein System das nicht auf dem aktuellen Stand ist, ist generell unsicher.

Ihr könnt nun auch die machtvollen Programme wie nmap, dsniff, wireshark o.ä. nutzen, um z.B. euer Netzwerk zu auditieren. Openoffice läuft unter X11 auch wunderbar und diverse kleine Helferlein, die ihr in der Linuxwelt schätzen gelernt habt, funktionieren mit großer Sicherheit auch.

Mit fink apropos Suchstring könnt ihr gucken ob es das gewünschte Programm auch gibt.

Vornweg: Die ntfs-3g Treiber funktionieren wunderbar auf meiner Virtuellen Maschine. Jetzt werde ich das ganze auf der lokalen Kiste hier zu Hause draufspielen.

Als erstes brauchen wir natürlich eine Shell auf dem System und wechseln dann als User Root in das Verzeichnis /tmp. Anschließend laden wir uns die beiden folgenden Dateien per wget herunter:

wget http://snapshot.debian.net/archive/2007/03/01/debian/pool/main/n/ntfs-3g/libntfs-3g0_0.0.0+20061031-6_i386.deb
wget http://snapshot.debian.net/archive/2007/03/01/debian/pool/main/n/ntfs-3g/ntfs-3g_0.0.0+20061031-6_i386.deb

Dann installieren wir uns noch die Abhängigkeiten mit aptitude install fuse-utils libfuse2.

Ist das geschehen, könnt ihr die beiden Pakete bequem mit dpkg -i installieren.

dpkg -i libntfs-3g0_0.0.0+20061031-6_i386.deb
dpkg -i ntfs-3g_0.0.0+20061031-6_i386.deb

Fertig ist der Lack. Nun könnt ihr mit dem Befehl

mount -t ntfs-3g /dev/festplatte /mount/point

Eure Platte einhängen.

Viel Spaß. ;)

Wie immer würde ich mich über einen kurzes Feedback in den Kommentaren freuen.

Ich bins mal wieder. Nach langer Zeit Blogabstinenz gibt es von mir neues im Bereich Crypto.
Wer nicht weiss, wozu man Verschlüsselung einsetzen soll, der mag sich nur mal überlegen, was z.B. passiert, wenn der Laptop geklaut wird, und die Urlaubsfotos, Rechnungen, Passwörter, TAN-Nummern, Kundendaten und was man auch immer auf seinem Rechner hat, von fremden gelesen werden können… Crypto ist nur was für Paranoide, Kriminelle, sog. Terroristen und Kinderpornosammler? Mitnichten!

Jeder der auch nur einigermaßen sensibles Material auf der Platte hat, handelt grob fahrlässig wenn diese in andere (vllt. sogar falsche) Hände geraten. Nicht auszudenken, wenn sensible Kundendaten o.ä. abhanden kommen.

Nachdem ich mit Truecrypt ein paar schöne Stunden verbracht habe, habe ich was neues für euch:

Ich habe mir heute mal EncFS unter Mac OS X angeguckt.
Das interessante an EncFS ist, dass im Gegensatz zu Apples Systemeigener Lösung oder z.B. Truecrypt die einzelnen Dateien verschlüsselt werden, und kein Container. So sind zwar die Dateigrößen und Metadaten auch im verschlüsselten Zustand sichtbar, nicht jedoch die Dateinamen, die auch verschlüsselt werden.

Netterweise muss man sich vorher nicht festlegen, wie groß das ganze wird, oder verbraucht durch ein Image fester größe Festplattenplatz der eigentlich gerade nicht genutzt wird. Zudem muss man bei Backups nun nicht mehr den kompletten Container backupen, sondern kann inkrementelle Backups auch der verschlüsselten Dateien fahren. Das empfiehlt sich vor allem, wenn eine der Backuplösungen übers Netzwerk bzw. Internet gefahren wird. So kann man z.B. wichtige Dinge auf einen Remote Server (z.B. per VPN/OpenVPN) backupen. Interessant ist das vor allem, um z.B. seine aktuellen Projekte auf Firmenrechnern vorrätig zu halten, ohne andere da dran zu lassen. Ob es die Möglichkeit gibt, die Dateien mittels geeigneter Authentifizierungsmechanismen auch auf anderen Systemen zu decrypten, muss ich noch ausprobieren. Logisch sollte da nix gegen sprechen.

Leider verliert man den Vorteil der Hidden Partition unter TrueCrypt. Dafür ist EncFS etwas erprobter und damit hoffentlich stabiler als das neue Truecrypt.

EncFS wird über Fuse gemountet. Dafür kann man sich MacFuse installieren, und obendrein MacFusion für ein GUI. MacFuse/MacFusion ist eh für jeden Mac User äusserst empfehlenswert. So können z.B. SSH oder FTP Server direkt im Userspace gemountet werden, und so einfach in den Finder eingebunden werden. Dafür gibt es ein entsprechendes Plugin für EncFS, so dass auch das direkt in den Finder eingebunden werden kann.

Allein die Nutzung von SSH Servern über SCP/SFTP um sie direkt in den Finder einzubinden erleichtert sicherlich vielen von uns das Leben. So kann man direkt im Finder mit den Kisten arbeiten und so z.B. Websites direkt auf dem Server entwickeln etc. Nun ist das Rumgeklicke in externen Programmen wie z.B. Cyberduck oder anderen SFTP/SCP/FTP Clients vorbei.

Zurück zu EncFS. Dieses kleine Helferlein hat noch eine weitere Zusatzapplikation: EncFSVault. Ein Ersatz für Apples FileVault. FileVault von Apple ist nicht open Source. Ergo konnte niemand den Code reviewen und es kann niemand sagen, wie das Ding wirklich arbeitet. Das ist bei EncFS und damit auch EncFSVault anders. EncFS ist open Source und soweit ich mitbekommen habe, auch im Review.

Hat man MacFUSE und damit die Umsetzung von FUSE für den Mac installiert und auch schon EncFS auf der Platte, kann man EncFSVault installieren. Per default wird dieses dabei eingeschaltet. Ist ein User nun nicht eingeloggt, und ich über den OS X eigenen Loginmechanismus authentifiziert, bleiben die Daten verschlüsselt.

Hier ein kurzer Überblick über die Befehle für EncFS Vault:

/usr/local/bin/encfsVaultCntrl –status zeigt euch den Status von EncFSVault an.

Die optionen –enable oder –disable sollten hier entsprechend für sich stehen.

Habt ihr einen neuen User eingerichtet und möchtet EncFS für diesen aktivieren, könnt ihr über eure Shell den Befehl

setupNewEncfsVaultUser ausführen.

Dort werdet ihr dann durch die Setupprozedur geleitet.

Solltet ihr mal in die Verlegenheit kommen, einen User löschen zu wollen, dessen HomeDir mit EncFSVault verschlüsselt ist, geht das auch ohne Probleme. Stellt zuerst sicher, dass das Home Verzeichnis nicht gemountet ist, oder forciert das Ganze mit sudo unmount /Users/username

Danach reicht ein rm -rf /Users/.username wobei der führende Punkt wichtig ist. Danach könnt ihr den User ganz normal über die Systemeinstellungen löschen.

Nun zurück von EncFSVault zu EncFS.

Habt ihr MacFuse und MacFusion installiert, sucht ihr nach dem EncFS Plugin für MacFusion. Google sollte da sehr gut helfen, ich hab den Link grad nicht parat. Nun könnt ihr euch für jedes FileSystem einen Ordner anlegen. Ich habe im Ordner /Users/meinuser/Daten alle möglichen Crypto Geschichten liegen. Also schwups ein neues Verzeichnis für EncFS angelegt, damit man mit Truecrypt usw. nicht durcheinander kommt, und dort ein paar Ordner rein. Jeder Ordner steht hier stellvertreten für ein EncFS File System.

Bei Crypto ist es generell immer am unsichersten, wenn die Daten im Klartext irgendwo rumfliegen. Daher habe ich differenziert und nicht alles zusammengefasst, sondern gestückelt. Rechnungen kommen in einen anderen Container bzw. EncFS File System als z.B. aktuelle Projekte oder Code. So binde ich nur das ein, was ich aktuell brauche. Das könnte man jetzt auch noch projektweise verfeinern indem man für jedes Projekt ein eigenes FS anlegt.

Ziel und zweck ist es, die Daten die man braucht auch nur dann ins System einzubinden, wenn man sie wirklich braucht. Ansonsten geht man nur ein unnötiges Risiko ein.

Kommen wir wieder auf die Ordner zurück. Für jeden Verwendungszweck (Rechnungen, MP3, Urlaubsbilder, foo, wasauchimmer) legt ihr einen Ordner an. Nun könnt ihr ganz gemütlich über MacFusion einen neuen Mount anlegen. Am besten tut ihr das gleich in den Favourites, dann bleiben die Mounts gespeichert. (Wenn ihr ganz paranoid seid, macht ihr alles über Quickmount. ;) )
Nun werde ihr aufgefordert, einen Namen für den Mount anzugeben und eine Location. Als location dienen eben jene vorhin angelegte Ordner. Nun müsst ihr noch die kleine Checkbox aktivieren, die das FileSystem dann auch anlegt, wenn es nicht bereits vorhanden ist. Passwort eingeben (und natürlich nicht im Schlüsselbund speichern) und fertig ist der Lack.

Soweit von mir. Ich werde damit noch mal etwas rumspielen und rumprobieren. Vor allem wäre interessant ob man die FileSystems auch z.B. auf Remote Hosts liegen haben kann (müsste ja eigentlich), wie die Performance ist, und ob man die auf eurem Mac angelegten FileSysteme auch z.B. unter Linux mounten kann.

Wie immer freue ich mich über Feedback in den Kommentaren. ;)

Hier die vergessenen Links:

MacFuse: http://code.google.com/p/macfuse/

MacFusion: http://www.macfusionapp.org/

EncFS Plugin für MacFuse: http://www.chuckknowsbest.com/ikrypt/download.html

(Danke an Peter Cramer für den Hinweis.)

Webentwicklung auf dem laufenden Webserver auf dem die Zielseite liegt, kostet nicht nur Nerven und Traffic, nein es macht euch auch immer abhängig von einem Netzzugang. Warum kompliziert, wenn es auch einfach(er) geht?

So kann man ganz gemütlich in der Bahn oder im Bus weiterentwickeln und bastelt nicht am live System herum, sondern auf seiner ganz privaten Mampp Maschine (Mac Apache & MySQL & PHP & Perl).

Es gibt sogar “out of the Box” Lösungen wie etwa xampp für den Mac oder MAMPP. Ich möchte euch jedoch zeigen, wie ihr euren Mampp selbst einrichtet, um euch gleichzeitig das nötige Basiswissen an die Hand zu geben, wie ihr mit den Konfigurationsdateien umgeht, was euch bei der Konfiguration eures Live Systems helfen könnte.

Fangen wir also an:

Was brauchen wir? Wir brauchen MySQL und einen Apache Webserver, ich bevorzuge hier den Apache2, da der einige Features mehr mitbringt als der alte Apache1 und schon seit längerer Zeit ein quasi Standart ist.

Was also tun? Richtig, wir informieren uns, ob es den Apache2 für den Mac bereits irgendwo gibt. – Und siehe da: Unter dem Menüpunkt “Sharing” gibt es die Option “Websharing”. Hinter dieser Option versteckt sich bereits ein Apache2 der nun nur noch eingerichtet werden muss.

Was nun? Nun können wir uns einen Keks freuen, da der Apache scheinbar schon läuft.
Das können wir nun überprüfen in dem wir http://localhost in unseren Browser eintippen.

Dann sollte das Ganze übrigens in etwa so aussehen:

Jetzt geht es darum, herauszufinden, wo der Apache liegt, und wo die entsprechenden Konfigurationsdateien zu finden sind.

Dazu gehen wir ins Terminal und versuchen es mal auf gut Glück mit dem Standartverzeichnis des Apache2 unter Unix Systemen und öffnen das Verzeichnis mit dem Befehl “open /etc/apache2/” (ohne Anführungsstriche). Jetzt öffnet sich ein Finder Fenster mit dem Ordner, an den man sonst ohne weiteres über den Finder nicht herankommt.

Nun öffnen wir die Datei httpd.conf mit dem Texteditor unserer Wahl. Ich bevorzuge TextMate, weil es ein einfach genialer Texteditor ist der jeden Cent seinter 48,75 EUR einfach wert ist. (Studenten bekommen Sonderkonditionen)

Nun gilt es, einige Zeilen zu editieren, so dass sie unseren Ansprüchen gerecht werden:

In Zeile 40 steht folgendes:

Listen 80

Dies ist der Wert der beeinflusst, auf welchem Port der Apache Webserver seinen Dienst verrichtet. In der Regel kann dieser Wert so stehen gelassen werden. Möchtet ihr jedoch, dass der Apache auf einem anderen Port lauscht, könnt ihr hier entsprechend einen anderen Port eintragen, müsst dann aber im Browser http://localhost:port (z.B. http://localhost:8080) eingeben um auf euren Webserver zugreifen zu können. Manchmal kann es sinnvoll sein den Port zu ändern, für dieses Setup belasse ich ihn jedoch auf Port 80. (Änderung des Ports wird erst nach einem Neustart des Apache2 wirksam)

Anschließend werden eine ganze Menge Module geladen. Wer nicht weiss, was er da tut, sollte diese Module ersteinmal aktiviert lassen. Wir kommen später dazu einige zu aktivieren oder zu deaktivieren.

Die nächste Zeile, die interessant ist, ist die Zeile 147, dort steht der Eintrag “ServerAdmin” der Wert dahinter sollte eure E-Mail Adresse beeinhalten. Trifft jemand auf eurem Produktivsystem auf eine Fehlerseite, erhält er so die Möglichkeit, euch per E-Mail darüber zu informieren. In eurem Testsystem ist das nicht so ganz relevant, aber wir werden den Eintrag auf jeden Fall editieren. Gebt eure E-Mail Adresse ein und gut ist.

Als nächstes kümmern wir uns um den Eintrag DocumentRoot.

# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot “/Library/WebServer/Documents”

Ein # am Anfang einer Zeile markiert einen Kommentar. Diese Zeilen werden in der Regel dazu genutzt die nachfolgende Option zu beschreiben. In diesem Falle handelt es sich um das so genannte Document Root, das wir uns gleich etwas genauer angucken werden.

Diese Option zeigt momentan noch auf das Verzeichnis in dem sich die Testwebsite des OS X Apache2 befindet. So kommt jeder User, der http://eure-lokale-ip eintippt auf diese Seite, sofern er nicht von dem Packetfilter (Firewall) geblockt wird.

Das wollen wir natürlich so gar nicht. Daher werden wir jetzt ein Verzeichnis anlegen, in dem die zukünftige StandartWebsite liegen soll, bzw. die entsprechenden Projekte die ihr bearbeiten wollt. So können wir z.B. in unserem Homeverzeichnis einen Ordner htdocs anlegen. (Wo ihr einen Ordner anlegt, und wie ihr ihn nennt, ist euch vollkommen selbst überlassen.)

Daher ändern wir den Eintrag für DocumentRoot wie folgt:

DocumentRoot “/pfad/zu/eurem/gewuenschten/verzeichnis”

Es empfiehlt sich, auf jeden Fall eine index.html in dieses Verzeichnis zu legen. Hier könnt ihr natürlich auch gern irgendwelche Informationen ablegen, sein muss das aber nicht. Wie wir am folgenden Eintrag sehen, ist das so genannte Directory Listing ausgestellt.

# Each directory to which Apache has access can be configured with respect
# to which services and features are allowed and/or disabled in that
# directory (and its subdirectories).
#
# First, we configure the “default” to be a very restrictive set of
# features.
#

Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all


#
# Note that from this point forward you must specifically allow
# particular features to be enabled – so if something’s not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

#
# This should be changed to whatever you set DocumentRoot to.
#

#
# Possible values for the Options directive are “None”, “All”,
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that “MultiViews” must be named *explicitly* — “Options All”
# doesn’t give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks MultiViews

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be “All”, “None”, or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None

#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all

Die orange markierte Zeile muss noch angepasst werden.

Jetzt kommen wir definitiv nicht mehr drum herum den apache neu zu starten. Unter Mac OS X geht das am besten mit dem Befehl “sudo apachectl stop” (schaltet den Apache aus) und “sudo apachectl start” (Startet ihn halt wieder. ;) ) Ich werde euch später zeigen, wie wir das ganze etwas automatisieren können.

Sudo lässt euch etwas als Systemadministrator ausführen. Sudo verlangt euer Passwort um entsprechende Berechtigung zum Ausführen des Befehls zu erlangen. Das eingegeben Passwort wird für eine gewisse Zeit gespeichert, so dass ihr es nicht immer neu eingeben müsst.

Nun haben wir das Document Root des Apache auf ein Verzeichnis unserer Wahl umgeleitet, haben den ServerAdministrator gesetzt und auf Wunsch auch noch den Port umgebogen.

Die restlichen Einträge in der httpd.conf sind wichtig, aber soweit nicht wirklich interessant. Wen die ganzen Optionen wirklich interessieren, sollte sie die entsprechenden Dokumentationen durchlesen. So könntet ihr z.B. den Ort an dem die Logfiles gespeichert werden, abändern und viele andere Dinge machen. Für unsere Zwecke reichen die Änderungen, die wir vorgenommen haben aber ersteinmal.

Die Konfiguration beeinhaltet jetzt ersteinmal einen apache2 Webserver ohne PHP, Perl und MySQL. Das müssen wir noch dringend ändern. ;)

Tippt ihr jetzt http://localhost in euren Browser ein und habt keine index.html in dem Verzeichnis, gibt es ein so genanntes Directory Listing. Dies ist generell nix schlimmes, kann aber unerwünschte Probleme nach sich ziehen. So kann ein “Angreifer” oder der neugierige Kollege sehen, was für Ordner ihr in dem entsprechenden Verzeichnis alles rumliegen habt. Wenn das so gewünscht ist, ist das in Ordnung. Generell solltet ihr aber darüber nachdenken eine index.html in jedes Verzeichnis zu legen, oder das Directory Listing auszuschalten.

Als nächstes machen wir uns daran, MySQL auf unserem Rechner zu installieren. Die aktuellen Pakete bekommt ihr unter http://dev.mysql.com/downloads/mysql/5.0.html#macosx-dmg. Ich habe mich dafür entschieden, MySQL in der Version 5 (aktuelle Version) herunter zu laden. Sucht euch das Paket für eure Rechnerarchitektur aus, und kopiert euch die MD5 Checksum in den Zwischenspeicher. Nun startet den Download.

Ihr werdet jetzt aufgefordert, euch einzuloggen, bzw. einen neuen Account anzulegen. Unter den beiden Feldern dafür gibt es jedoch den Link zum direkten Download ohne Registrierung.

(Achtung: Solltet ihr Mac OS 10.5 nutzen, könnt ihr trotzdem das Paket für 10.4 herunter laden.)

Ist der Download abgeschlossen, verifiziert ihr den MD5 Hash des Paketes in dem ihr in der Shell folgenden Befehl eintippt:

openssl md5 /pfad/zur/datei/dateiname

Nach dem Betätigen von Enter solltet ihr folgende Meldung sehen:

MD5(mysql-5.0.51a-osx10.4-i686.dmg)= 4abcc4c0d6edf8526d1c18ea72d4a6d6

Vergleicht diese Checksum nun mit der von der Website um zu verifizieren, dass das Paket auf dem Weg zu euch nicht verändert wurde, oder ihr das Paket aus einer bösen Quelle herunter geladen habt. Stimmen die Checksums überein, können wir weiter machen, indem wir das dmg per Doppelklick mounten.

Nun geht es los: Wir installieren MySQL. Während der Installation werdet ihr nach eurem Benutzerkennwort gefragt, dass ihr ohne Bedenken eingeben könnt. (Erinnert ihr euch: Das Paket wurde per Checksum als korrektes Paket identifiziert, und wir vertrauen den offiziellen Herstellern von MySQL genug um zu glauben, dass diese uns keinen bösen Code untergeschoben haben.)

Herzlichen Glückwunsch! MySQL ist auf deinem System installiert!

Als nächstes können wir noch das MySQL Startupitem und das Prefpane Programm installieren. So können wir erstens dafür sorgen, dass MySQL beim Rechnerstart immer mitgeladen wird, und über die Systemeinstellungen per Graphischem Interface den MySQL Server starten und stoppen.

Nun sollten wir MySQL der PATH Variable in unserer Shell hinzufügen. Solltet ihr mit der Bash, der Standartshell unter Mac OS X ab 10.3 arbeiten, gebt einfach folgenden Befehl in eure Shell ein*:

open /Users/username/.bash_profile

und fügt folgende Zeilen hinzu:

export PATH=/usr/local/mysql/bin:$PATH

alias mysql=/usr/local/mysql/bin/mysql

alias mysqladmin=/usr/local/mysql/bin/mysqladmin

Nun müsst ihr euer Terminal einmal schließen und wieder öffnen. Die Einstellungen aus der .bash_profile werden nur beim Start der Bash geladen. Wenn Ihr also Änderungen an der Datei vornehmt, müsst ihr nach dem Speichern eine neue Bash aufmachen, damit das funktioniert.

MYSQLCOM=-YES-

Wollt ihr den Autostart von MySQL wieder abschalten, geht dies über das Prefpane oder indem ihr die Datei so abändert, dass statt dem YES nund ein NO dort steht. (Bitte macht das nur, wenn ihr wisst, was ihr da macht, ansonsten lasst es bleiben.)

Jetzt geht es weiter mit der Installation:

sudo chown -R mysql /usr/local/mysql/data/

Um den Server zu starten, gebt ihr folgendes ein:

sudo ./bin/safe_mysql &

(Das müsst ihr nach einem Systemstart natürlich nicht mehr machen.)

Hier noch ein Hinweis von dev.mysql.com:

Das Mac OS X-PKG von MySQL installiert sich im Verzeichnis
/usr/local/mysql-VERSION.
Ferner wird eine symbolische Verknüpfung
/usr/local/mysql eingerichtet, die ebenfalls
auf die neue Position verweist. Ist ein Verzeichnis namens
/usr/local/mysql bereits vorhanden, dann wird
dieses zunächst in /usr/local/mysql.bak
umbenannt. Außerdem erstellt das Installationsprogramm die
Grant-Tabellen in der mysql-Datenbank. Hierzu
führt es den Befehl mysql_install_db aus.

Das müssen wir schnell ändern.

Mit dem Befehl

sudo mysql_secure_installation

ruft ihr ein Script auf, dass euere MySQL Installation absichert. Ihr müsst ein Passwort für den User Root angeben (bitte unbedingt merken. :D), solltet den Anonymen Login abschalten, den Login für Root von Remotehosts ausschalten, die Tabelle Test löschen, und die Tabellen neu laden.

Nun ist unsere MySQL Installation ersteinmal ausreichend gesichert.

Eure Test- und Entwicklungsumgebung sollte nun entsprechend laufen. Alles weitere ist nettes Beiwerk. Solltet ihr euch entscheiden das Ganze als Produktivumgebung, also als ernsten Webserver laufen zu lassen, wäre es sinnvoll, auch an SSL zu denken. Wenn ihr aber nur von localhost darauf zugreift, braucht ihr logischerweise auch kein SSL.

Alles was jetzt noch kommt, ist Work in Progress und nicht unbedingt notwendig.

SSL Verschlüsselung für den Apachen (Work in Progress!)

Als nächstes machen wir uns nun daran, mod_ssl für den Apache einzurichten. Wenn ihr rein lokal auf der Maschine arbeiten wollt, ist mod_ssl nicht wirklich sinnvoll, ist jedoch praktisch, wenn ihr ein genaues Abbild eures Webservers, also der Produktivumgebung darstellen wollt, oder andere Leute vom LAN oder vom Internet aus auf euren Rechner per SSL zugreifen können sollen.

Als erstes gehen wir daran, die Schlüssel zu erzeugen. Hier ist wieder ein wenig Akrobatik auf der Konsole notwendig, aber wer ernsthaft daran interessiert ist, sollte sich davon nicht abschrecken lassen, und die nötigen Grundbefehle zum Navigieren in Verzeichnisstrukturen und Dateimanipulationen erlernen. Ich werde hier Schritt für Schritt erklären, wie all das funktioniert.

Wir öffnen die Konsole und geben den Befehl ls -al ein. Dies gibt uns den Inhalt des aktuellen Verzeichnisses aus. Nicht erschrecken: Die Dateien mit einem Punkt davor, sind auf Unix Systemen standartmässig versteckte Dateien. Hier liegen einige Konfigurationseinstellungen.

Wir erzeugen nun einen neuen Ordner indem wir mkdir tmp eingeben. Dies erzeugt einen neuen Ordner mit dem Namen tmp. Nun wechseln wir mit dem Befehl cd tmp in das soeben angelegte Verzeichnis und erzeugen mit dem Befehl

openssl genrsa -des3 -out server.key 1024

einen neuen Key. Hierbei wird ein Password abgefragt, dass nicht so leicht zu erraten sein sollte. Allerdings müsst ihr es euch merken. Sonst bekommt ihr in der Zukunft einige Probleme. ;)

Nun sollte eine Datei in eurem Verzeichnis liegen, die server.key heisst. Überprüfen könnt ihr das mit dem neu erlernten Befehl ls -al.

Nun habt ihr einen Server Key, aber noch nichts weiter. Mit dem Befehl

openssl req -new -key server.key -out server.csr 

erzeugen wir ein CSR, ein sogenanntes Certificate Signing Request. Dieses könnt ihr zu einer CA wie z.B. Verisign oder CACert schicken, um es signieren zu lassen. Für die Testumgebung belassen wir es aber bei einem selbst signierten Zertifikat. Wie das geht erkläre ich dir jetzt. 

(Solltest du dein Zertifikat von einer richtigen CA signieren lassen wollen, fällt dieser Schritt natürlich weg.)

Wir erzeugen jetzt einen neuen Key für deine eigene CA. Diesen nenne ich im Beispiel ca.key, du kannst ihn aber auch foo_ca.key nenen. Das “ca” im Namen auftauchen zu lassen, bietet sich an, damit du weisst, was was ist.

openssl genrsa -des3 -out ca.key 1024

Haben wir den Key erzeugt, erzeugen wir nun ein Zertifikat: 

openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Nun laden wir uns am besten das Paket mod_ssl herunter, da Mac OS X das Paket zwar angeblich von Haus aus mitbringt, wir jedoch ein Shell Script benötigen das nicht mitgeliefert wird.

Das heruntergeladene Tarball können wir im Finder durch einen Doppelklick entpacken, in den Ordner reinnavigieren und das script sign.sh aus dem Unterordner pkg.contrib in den vorhin angelegten tmp Ordner kopieren.

chmod +x sign.sh

macht das Shellscript zu einem ausführbaren Programm, dass wir jetzt nutzen werden.

./sign.sh server.csr startet das Script und wir lassen uns durch das Interface führen.

Jetzt sind, wie ihr mit dem Befehl ls -al überprüfen könnt, einige neue Dateien aufgetaucht, die alle vom Script angelegt wurden.

Nun werden wir ein neues Verzeichnis anlegen in das wir gleich einige Dateien aus diesem Verzeichnis legen werden:

sudo mkdir /etc/httpd/ssl.key

Dieses Verzeichnis sieht nun aus wie eine Datei, da es eine .key Endung hat, ist aber tatsächlich ein Verzeichnis. Unix, und euer Mac OS X ist ein Unix, unterscheidet Dateien nicht über Endungen oder ähnliches, sondern über bestimmte Codes am Anfang der Datei. In diesem Falle ist die Datei ein Verzeichnis und keine .key Datei. OS X identifiziert Dateitypen also nicht über die Endung. Wohl aber weist OS X zu, welches Programm zum Öffnen der Datei genutzt wird.

Nun kopiert ihr alle Dateien in das soeben angelegte Verzeichnis:

cp -r * /etc/httpd/ssl.key/

!!! Dies ist ein großes Sicherheitsrisiko, das wir später noch minimieren werden.

WICHTIG:

Nun ist der Punkt gekommen, an dem ihr euch entscheiden müsst: Sicherheit, oder Bequemlichkeit…

Da ich eher auf Sicherheit stehe, werde ich später noch einige Dinge erklären, wie ihr euch das Leben einfacher machen könnt und trotzdem auf der sicheren Seite bleibt.

Wenn ihr wollt, dass der Apache direkt beim Systemstart geladen wird, bzw. über die Option Websharing ein und ausgeschaltet werden kann, müsst ihr das Passwort von eurem server.key entfernen. Sonst hängt sich das System beim Start auf und ihr seid ziemlich gearscht. ;) Wenn beim Start der Apache geladen wird, wird das System warten, bis ihr das Passwort für den server.key eingegeben habt. Da ihr aber keine Möglichkeit dazu habt, wir das System einfrieren.

Wenn ihr den Apache per Hand startet, ist der folgende Schritt irrelevant. Wenn ihr es aber einfach haben wollt, müsst ihr das Kennwort entfernen. Allerdings solltet ihr bedenken, dass ein Angreifer so mit eurem Key weitere Zertifikate ausstellen bzw. signieren kann.

Als erstes wechseln wir in das Verzeichnis und legen wir ein Backup von dem Schlüssel an:

cd /etc/httpd/ssl.keysudo cp server.key server.key.original

Das Passwort entfernt ihr mit dem Befehl:

sudo openssl rsa -in server.key.original -out server.key

Nun werdet ihr wieder nach dem sudo Passwort gefragt und nach dem Passwort für den server.key.

Ihr habt nun erfolgreich das Passwort von server.key entfernt und eine Sicherheitskopie von server.key als server.key.original angelegt.

Jetzt solltet ihr den Server stoppen, wir fassen die Konfigurationsdatei noch einmal an und schalten den mod_ssl Support an.

sudo apachectl stop

Wir wechseln mit den folgenden Befehlen ins Verzeichnis /etc/httpd, legen ein Backup der httpd.conf an und öffnen die httpd.conf mit einem Texteditor. Sollten wir später Probleme bekommen, können wir die Konfigurationsdatei bequem wieder auf den Stand zurück bringen, auf dem das System lauffähig war.

cd /etc/httpd
sudo cp httpd.con httpd.conf.backup
open httpd.conf

Nun kommentieren wir die Option Port aus in dem wir ein # vor die Zeile setzen. Danach fügen wir am Ende der Datei folgende Zeilen ein:

## SSL Support#### When we also provide SSL we have to listen to the## standard HTTP port (see above) and to the HTTPS port##

		Listen 443		Listen 80

Die folgenden beiden Zeilen müssen nun noch dekommentiert werden, indem ihr das # am Zeilenanfang entfernt:

#LoadModule ssl_module libexec/httpd/libssl.so
#AddModule mod_ssl.c

Nun kopieren wir noch folgende Zeilen an das Ende der httpd.conf. Sie regeln die SSL Handles.

# Some MIME-types for downloading Certificates and CRLs  AddType application/x-x509-ca-cert .crt  AddType application/x-pkcs7-crl .crl

# inintial Directives for SSL

  # enable SSLv3 but not SSLv2  SSLProtocol all -SSLv2  SSLPassPhraseDialog builtin  SSLSessionCache dbm:/var/run/ssl_scache  SSLSessionCacheTimeout 300  SSLMutex file:/var/run/ssl_mutex  SSLRandomSeed startup builtin  SSLLog /var/log/httpd/ssl_engine_log 		  SSLLogLevel info#### SSL Virtual Host Context##  #Just to keep things sane...    DocumentRoot "/Library/WebServer/Documents"    ServerName 127.0.0.1    ServerAdmin bobdavis@mac.com    SSLEngine off  # General setup for the virtual host    DocumentRoot "/Library/WebServer/Documents"  #ServerName has to match the server you entered into the CSR    ServerName 127.0.0.1    ServerAdmin bobdavis@mac.com    ErrorLog /var/log/httpd/error_log    TransferLog /var/log/httpd/access_log  # SSL Engine Switch:  # Enable/Disable SSL for this virtual host.    SSLEngine on    # enable SSLv3 but not SSLv2	SSLProtocol all -SSLv2    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL  # Path to your certificates and private key		    SSLCertificateFile /etc/httpd/ssl.key/server.crt    SSLCertificateKeyFile /etc/httpd/ssl.key/server.key          SSLOptions +StdEnvVars              SSLOptions +StdEnvVars    # correction for browsers that don't always handle SSL connections well    SetEnvIf User-Agent ".*MSIE.*" \    nokeepalive ssl-unclean-shutdown \    downgrade-1.0 force-response-1.0# Per-Server Logging:# The home of a custom SSL log file. Use this when you want a# compact non-error SSL logfile on a virtual host basis.    CustomLog /var/log/httpd/ssl_request_log \    "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Fertig! ;)

Nun kannst du den Erfolg deiner Einstellungen testen, indem du SSL anschaltest, und den Apache wieder startest.

sudo httpd -D SSL
sudo apachectl start

To be continued. Feedback in den Kommentaren oder per Mail erwünscht.

Ich plane, hier in Zukunft unter dem Menüpunkt “Security” einige kleine Texte zum Thema Computersicherheit und Datenschutz zu veröffentlichen. Also schaut einfach immer mal wieder rein.

Für die nächste Zukunft sind folgende Tutorials geplant:

• Einrichten von GnuPG für Windows
• Installation von TOR bzw. JAP zum Anonymen Surfen (Mac OS X/Windows)

Solltet Ihr Wünsche haben, werde ich auch gern zu anderen Themen ein Tutorial zusammentragen.