So schlimm ist das ja nicht, kann ja mal passieren – wenigstens haben die sich für ihre Unannehmlichkeiten entschuldigt.

Also die Prüfung noch mal von vorne starten. Ein paar Minuten später dann dieses Bild:

Ok, seh ich ein, mein Satzbau ist ab und zu etwas verschwurbelt. Vor allem in technischen Dokumenten kommen ja immer viele englische Wörter und Fachbegriffe vor, da kann so eine Grammatikprüfung schon mal auf die Nase fallen. Ich habe die Grammatikprüfung deswegen abgeschaltet.

Also noch mal von vorne – dieses mal nur mit der Rechtschreibprüfung. Aber seht selbst:

*WTF*? Word, was erlaube? Soll ich denen jetzt echt glauben, dass sich das Programm unerwartet beendet hat – und diesmal entschuldigen die sich nicht mal mehr für die Unannehmlichkeiten.

Nach ca. 2 Stunden und mehrfachen Neustarts (immer wieder abbrechen, speichern, neu starten) war die Rechtschreibprüfung letztendlich abgeschlossen. Die Grammatikprüfung hat sich bis zum Schluss konsequent verweigert. Nächste Woche steht mir das Ganze erneut bevor, dann wird die endgültige Fassung fertig – ich freu mich schon!

[Update 2008-06-01: Plesk Version ist 8.3]

Mein Ziel war, Subversion so zu installieren, dass es mit Plesk nicht ins Gehege kommt. Nach einiger Recherche habe ich auf verschiedenen Seiten und in Foren Informationen gefunden, die beschreiben, was ungefähr getan werden muss. Allerdings habe ich nirgends eine zusammenhängende Anleitung gefunden, in der die komplette Einrichtung beschrieben ist.

Bevor jetzt irgendjemand anfängt und das nachmacht, was ich hier beschreibe ein wichtiger Hinweis:

Ich habe keine Ahnung, ob das was ich hier beschreibe auf jedem System funktioniert. Bitte macht auf jeden Fall ein Backup, bevor Ihr anfangt und lest Euch im Zweifel die verlinkte Dokumentation durch. Prüft, ob die von mir verwendeten Pfade und Benutzer bei Euch Sinn geben.

Vor allem macht mich nicht dafür verantwortlich, sollte etwas schief gehen…

Ihr braucht auf jeden Fall die Root-Rechte für Euren Server. Soweit nicht anders beschrieben, werden alle folgenden Schritte als Benutzer root ausgeführt.

Ich gehe davon aus, dass Ihr auf Eurem lokalen Rechner schon einen Subversion-Client installiert habt.

Schritte, die auf dem VPS ausgeführt werden müssen, sind mit

remote:~#

gekennzeichnet. Schritte, die Ihr auf Eurem lokalen Rechner ausführt, sind mit

local:~#

gekennzeichnet.

Hier eine Liste der Schritte, die für die Installation notwendig sind:

• 1. Subversion und Subversion-Server installieren
• 2. Subversion-Repository anlegen
• 3. Den Subversion-Server konfigurieren
• 4. Benutzer für das Repository anlegen
• 5. Der erste Zugriff auf den Server
• 6. Ein Projekt importieren

Darüber hinaus enthält der Artikel noch folgende Informationen:

• Ich möchte noch einmal mit einem frischen Repository starten
• Unschönheiten
• Weiterführende Dokumentation

Los geht’s!
1. Subversion und Subversion-Server installieren
Als erstes müssen die Software-Pakete subversion und subversion-server installiert werden. Hierzu in ein Terminal wechseln und als root-Benutzer folgendes Kommando absetzen:

remote:~# rug install subversion subversion-server

Falls Subversion schon installiert sein sollte, kommt folgende Fehlermeldung:

ERROR: 'subversion' is not available, or is fully up-to-date.

Ihr könnt prüfen, ob Subversion installiert ist, in dem Ihr folgendes Kommando abschickt:

remote:~# rug info subversion subversion-server

In der Ausgabe gibt es für jedes der beiden Pakete einen Abschnitt. In beiden Abschnitten müssen die Texte Installed: Yes und Status: up-to-date vorkommen.

Falls auf Eurem Server Subversion schon installiert war, kann das natürlich bedeuten, dass die im Folgenden beschriebenen Schritte eventuell nicht mehr funktionieren.

2. Subversion-Repository anlegen

Nachdem uns nun die Software zur Verfügung steht, können wir weiter machen. Damit wir unseren Subversion-Server testen können, brauchen wir ein Repository. Als Speicherort für das Repository habe ich mir /srv/svn/ ausgesucht. Das Repository habe ich einfach mal repos genannt.

Das Anlegen des Repositories erfolgt ebenfalls im Terminal:

remote:~# svnadmin create /srv/svn/repos

Damit der Apache das Repository lesen und beschreiben kann, müssen wir im die Rechte dazu geben:

remote:~# chown -R wwwrun:www /srv/svn/repos

3. Den Subversion-Server konfigurieren

Ich gehe im Folgenden davon aus, dass Ihr auf Eurem VPS eine Domain (im Beispiel example.com) liegen habt, über die der Zugriff auf Subversion erfolgen soll. Für den Zugriff auf die Repositories möchte ich die URL http://example.com/svn/repos nutzen.

Wechselt in das Verzeichnis, in dem die Konfigurationsdateien für Eure Domain liegen:

remote:~# cd /srv/www/vhost/example.com/conf

In diesem Verzeichnis müsst Ihr die Datei vhost.conf bearbeiten. Falls die Datei noch nicht existiert, könnt Ihr sie einfach anlegen.

In diese Datei müsst Ihr folgende Zeilen kopieren (falls Ihr auf 64bit-Systemen lauft, müsst Ihr statt /usr/lib den Pfad /usr/lib64 nehmen):

LoadModule dav_module /usr/lib/apache2-prefork/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/mod_dav_svn.so

<Location /svn>
 DAV svn
 SVNParentPath /srv/svn

 AuthType Basic
 AuthName "Authorization Realm"
 AuthUserFile /srv/svn/user_access/repos_passwdfile
 Require valid-user
</Location>

Damit die Konfiguration aus der vhost-Datei auch aktiv wird, muss die Konfiguration für den Webserver neu geschrieben und der Webserver durchgestartet werden. Dies wird mit folgendem Kommando durchgeführt:

remote:~# /usr/local/psa/admin/sbin/websrvmng −−reconfigure-vhost −−vhost-name=example.com −−restart

[Update 2008-03-05: Sollte später beim Aufruf der Repository-URL ein 404 auftreten, versucht es mal mit websrvmng -a -v und danach noch mal den reconfigure. Ich habe es nicht getestet, der Tipp stammt aus dem Kommentar von Micha (siehe unten)]

4. Benutzer für das Repository anlegen
Damit nicht jeder auf unser Repository zugreifen kann, habe ich einen Passwortschutz auf den Server gelegt. Die Benutzer und ihre Passworte werden in der Datei

/srv/svn/user_access/repos_passwdfile

gesucht. Um den ersten Benutzer test anzulegen verwendet Ihr folgenden Befehl:

remote:~# htpasswd2 -c /srv/svn/user_access/repos_passwdfile test

Ihr werdet nun nach dem Kennwort gefragt, das Ihr für den Benutzer test verwenden wollt. Das Kennwort müsst Ihr danach noch einmal bestätigen. Beim Anlegen weiterer Benutzer müsst Ihr den Schalter -c weglassen:

remote:~# htpasswd2 /srv/svn/user_access/repos_passwdfile noch_n_test

5. Der erste Zugriff auf den Server

Jetzt solltet Ihr schon in der Lage sein, auf Euer – noch leeres – Repository zuzugreifen. Ruft im Browser folgende URL auf:
http://example.com/svn/reposIhr werdet nach einem Benutzer und einem Kennwort gefragt. Hier gebt Ihr test und Euer Passwort an.

Wenn Ihr alles richtig gemacht habt, müsstet Ihr Euer leeres Repository sehen.

6. Ein Projekt importieren
Wir machen ein kleines Test-Projekt, das wir in das Repository legen wollen. Dazu baut Ihr Euch auf Eurem lokalen Rechner folgenden Verzeichnissbaum auf (dies müsst Ihr nun nicht mehr als root machen):

./test/branches/
./test/tags/
./test/trunk/
./test/trunk/README

In die Datei README könnt Ihr irgendetwas x-beliebiges reinschreiben.

Importiert das Test-Projekt von Eurem lokalen Rechner in das Repository:

local:~# svn import test http://example.com/svn/repos/test

Wenn Ihr nun erneut über den Browser auf Euren Server schaut, seht Ihr Euer Test-Projekt mit den Unterverzeichnissen und der Datei README.

Ab jetzt könnt Ihr mit Eurem Repository spielen, testen, etc.

Ich möchte noch einmal mit einem frischen Repository starten
Wenn Ihr Euer Repository noch einmal frisch anlegen wollt, löscht einfach das Verzeichnis /srv/svn/repos samt Inhalt und führt danach den Schritt 2 noch einmal aus.

Unschönheiten
Ein kleines Problem hat die oben beschriebene Vorgehensweise: Da ich die LoadModule-Direktiven in die vhost-Datei geschrieben habe, lässt sich auf einem VPS nur genau ein Subversion-Server für genau eine Domain betreiben. Wenn ein zweites Repository auf einer weiteren Domain genutzt werden soll, würden die LoadModule-Direktiven Fehlermeldungen auslösen.

Es wäre eventuell auch möglich die LoadModule-Direktiven in die Datei /etc/apache2/sysconfig.d/loadmodule.conf zu legen – ich wollte aber keine direkten Veränderungen am Apachen vornehmen…

Weiterführende Dokumentation
Um tiefer in die Materie zu kommen, empfehle ich folgende Dokumente und Webseiten:

Subversion

http://subversion.tigris.org – die offizielle Homepage von Subversion

Version Control with Subversion – das Buch über Subversion

Plesk

Dokumentation zu Plesk – hier insbesondere der Administrator’s Guide

Alle, die den von mir beschriebenen Workaround angewendet haben, müssen vor der Installation der Beta die gleichen Schritte noch einmal machen – allerdings muss dieses Mal das Attribut “Geschützt” entfernt werden.

Danach kann Skype in den Programme-Ordner gezogen werden.

Mit der aktuellen Version kommen auch 640×480-Pixel Videos auf den Mac. Genügend Leistungsreserven voraussgesetzt (Core 2 Duo), sollen so bis zu 25 Bilder pro Sekunde übertragen werden können.

Wie immer gilt beim Einsatz von Beta-Versionen: Nicht wundern, wenn etwas nicht so tut, wie es soll…

Skype und WoW prüfen jedoch beim Start die Integrität des Programmcodes anhand einer eigenen Signatur. So wird sichergestellt, dass es sich um die unveränderte(n) Datei(en) des Herstellers handelt und nicht etwa um einen Schädling. Das ist prinzipiell ja auch keine schlechte Idee!

Durch die Signatur von Leopard hat sich jedoch leider die Programmdatei von Skype verändert und Skype verweigert (zu Recht) seinen Dienst.

Eine echte Abhilfe kann nur der Hersteller liefern, aber es gibt einen Workaround:

There’s a simple workaround for this problem:
- Copy Skype from the download image to your Applications folder
- Right-click on Skype and select “Show Package Content” (or similar, I don’t have an english version of OS X)
- Select “Framework”, “Mac OS” and “Resources” within the folder “Contents” and set files to “protected” via the information window (command+i)

Auf Deutsch (mit eigenen Ergänzungen):

1. Die aktuelle Version von Skype herunterladen und (erneut) in den Ordner Programme legen.
2. Skype starten – jedoch auf Nachfrage von Leopard keine Netzwerkverbindung erlauben.
3. Die Benutzereinstellungen den eigenen Bedürfnissen anpassen
4. Die Anwendung Skype im Ordner Programme suchen.
5. Skype beenden.
6. Im Ordner Programme die Anwendung Skype suchen und darauf die rechte Maustaste klicken (es öffnet sich ein neues Finder-Fenster mit einem Ordner “Contents”).
7. Den Ordner Contents öffnen.
8. Die darin enthaltenen Ordner “Frameworks”, “MacOS” und “Resources” auswählen.
9. Rechte Maustaste klicken und den Menupunkt “Informationen” auswählen (es öffnen sich drei Fenster).
10. In jedem der drei Fenster die Option “Geschützt” ankreuzen und das Fenster wieder schließen.

Jetzt kann Skype wieder gestartet werden. Nach dem Start fragt die Firewall, ob man den Netzwerkzugriff erlauben möchte. Da die relevanten Programmordner nun geschützt sind, kann diese Frage mit “erlauben” beantwortet werden.

Einziger Nachteil: Leopard fragt jetzt bei jedem Start von Skype erneut. Das lässt sich jedoch leichter verschmerzen als die Empfehlung, die Firewall zu deaktivieren um Skype nutzen zu können.

Jetzt fange ich gerade an, mich mit dem Kätzchen anzufreunden. Momentan sind für mich das die Highlights:

• Coverflow im Finder
• Time Machine
• Notes und ToDos in Mail (höre ich jemanden “das kann Outlook schon lange” sagen?)

Ein weiteres “Highlight” ist das Icon, das für Windows-Rechner im Netz vergeben wird – seht selbst:

Während der Entwicklung von Leopard wurde gemunkelt, es würde sich um einen Scherz der Entwickler handeln und das Icon mit dem Windows-BSOD würde das Final-Release nicht überleben…

Hier mein aktueller Stack (das Wichtigste liegt, wie immer, ganz unten. Nebenher läuft Marsheux Hanging On – siehe Video):

1. Mit anderem Kollegen über Punkt 5 sprechen
2. Blogeintrag schreiben
3. Webseite über N.A.D.D. schließen
4. E-Mail schreiben
5. Kommunikation mit einem Kollegen über ein Problem in einem anderen Projekt (Chat)
6. Letzte Fehler aus einer Software ausbauen, diese zur Installation fertig machen (PHP)

Und weiter geht’s…
[gv data="DKF-owJe5C0"][/gv]

Zum Ausgleich gab es heute Abend leckeres Abendessen. Ich habe mich an einen schönen, genussvollen Abend im März diesen Jahres erinnert. Am Morgen danach hat der andere Peter ein göttliches Omelett gezaubert. Das Rezept habe ich vorhin nachgekocht. Bis auf das Einrollen (es geriet mehr zu einem Einwürfeln) ist mir alles gut gelungen. Sehr lecker!

Noch was: Warum heißen Maultaschen “Maultaschen”? Weil der Paul mault wenn er sie essen muss…

Pech gehabt: Es ist der linke Lüfter. Um die Lüfter auszutauschen muss man das ganze Notebook auseinander nehmen, da sie unter dem Motherboard auf dem Boden des Notebooks liegen. Somit stecke ich nun das Geld statt in den Kaufpreis einer größeren Platte in die Arbeitszeit eines Technikers…

Previous Next Dem Macbook unter die Haube geschaut.

Previous Next Der kaputte Lüfter im Macbook.

Zum nachmachen: Bei PowerbookMedic kann man sich PDF-Dokumente herunterladen, die beschreiben, wie man die verschiedenen Notebooks von Apple auseinander- und (viel wichtiger) wieder zusammenbauen kann.