Fractalcenter

Da arbeitet man Wochen oder gar Monate an einem richtig genialen Projekt (Web 5.0 oder eine andere SuperDuperLikkerapplikation) und auf einmal kommt der Moment der Wahrheit immer näher. Man fragt sich dann, was muss ich denn jetzt eigentlich noch testen, welche Einstellungen muss ich denn noch verändern, damit die Webseite wie gewünscht starten kann? Zum Glück gibt es für Symfony-Entwickler eine eigene Seite, wo man die einzelnen Punkte abhaken kann. http://symfony-check.org/

Die meisten Sachen sind denk ich klar, aber gerade die Einstellungen für das Logging u.ä. sind vielleicht doch ein guter Tipp.

Über 80% aller Webserver laufen mit einem Unix Derivat, meist Linux. Um auf solche Maschinen zugreifen zu können benötigt man einen Shell/Bash Zugriff. Das geht recht einfach mit einem SSH.

Um z.B. auf einem Ubuntu System SSH einzurichten ist sehr gut auf der Wiki Seite von ubuntuusers.de beschreiben. http://wiki.ubuntuusers.de/SSH

Das Problem daran ist, dass der Zugang für alle offen ist, d.h. es kann jeder versuchen sich auf diesem Server ein zu loggen. Natürlich verwenden wir sichere Passwörter, aber dennoch wäre es doch schöner, wenn man den Zugriff für alle anderen, außer einem selbst und ggf. Mitentwickler, sperren könnte. Das geht und zwar relativ einfach, man muss nur einen SSH public/private Key erzeugen und diesen dann verwenden. Alle anderen Zugänge werden gesperrt. Unter http://www.systemengineers.de/linux/debian/key-basierte-ssh-logins-mit-putty ist der Vorgang sehr anschaulich für User beschrieben, die wie ich auf Arbeit ein Windows System mit putty benutzen.

Wenn die Fehlermeldung “Kann Standarddatenbank des Benutzers nicht öffnen” im “Microsoft SQL Server Management Studio” kommt, muss man die Standarddatenbank auf eine andere Datenbank zurück stellen. Um diese zurück zu setzen muss man sich auf dem Server direkt einloggen und dort folgendes ausführen:

use master
go
sp_defaultdb  
go

Dementsprechend den eigenen Loginnamen und die neue Standarddatenbank eintragen. Dann sollte die Fehlermeldung auch wieder weg sein.

Subversion ist eine Arbeitserleichterung, die ich nicht mehr missen möchte. Es hat aber auch seine Tücken. Wenn man damit ein Projekt entwickelt werden durch Subversion “.svn” Verzeichnisse angelegt, und das in rauen Mengen. Dadurch, dass ich auf einem Ubuntu-System entwickle, sehe ich diese Verzeichnisse gar nicht, da diese standardmäßig ausgeblendet werden. Wenn man dann seine Änderungen auf den Webserver spielen will, kann man das mit FTP machen, was sehr umständlich ist, oder durch einen SSH geschützen Tunnel per SVN. Wenn man ein
svn export macht, ist das auch OK, nur leider dauert das dann sehr lang. Wenn man dies bei einem Produktivsystem macht, läuft man Gefahr, dass die Internetseite nicht erreichbar ist. Also hat man ja noch die Möglichkeit mit einem svn update zu arbeiten. Es vergleicht die Dateien und schreibt nur die Veränderungen an den Dateien aus der letzte Revision. Im Prinzip ist das das Beste was einem passieren kann. Es gibt nur einen großen Haken! Die .svn Verzeichnisse sind standardmäßig im Internet erreichbar. Normalerweise ist das nicht sooo schlimm, da über das Internet nur das “web” Verzeichnis und nicht etwas das “lib” oder sonstige delikate Verzeichnisse erreichbar sind. Abhilfe kann man eigentlich recht einfach schaffen, indem man einfach die Verzeichnisse “.svn” im Apache direkt sperrt. Das geht über z.B. die apache.conf (/etc/apache2/apache2.conf)

<Directory ~  '*\.svn'>
Order Allow,Deny
Deny from All
</Directory>

Update 25.2.2010 :

In den Kommentaren zu Nils seinem Artikel habe ich eine interessante Alternative zu o.g. vorgehen gefunden.

Man kann eine kleines Shellscript schreiben, in dem erst “svn export” auf ein temporäres Verzeichnis gemacht wird und dann ein Symlink vom webroot auf dieses Verzeichnis gelegt wird.

Der Vorteil dabei: Man hat keine .svn Verzeichnisse auf dem Produktivsystem und die Ausfallzeiten sind fast null.

#/bin/sh
svn export svn://SVNSERVER /var/www/ROOT_DIR_TEMP
chown www-data /var/www/ROOT_DIR_TEMP
chmod 755 /var/www/ROOT_DIR_TEMP
mount --bind /var/www/ROOT_DIR_TEMP /var/www/ROOT_DIR

Man könnte natürlich das ganze noch mit ein oder zwei Variablen flexibler gestalten, damit das TEMP Verzeichnis nicht überschrieben wird. Aber ich denke so in etwa dürfte es funktionieren.