Arkanis Development

Again an English post. This time about a little problem I’ve stumbled across while doing some nice stuff with one of my SubVersion repositories. For readers who don’t know SubVersion is a version control system useful for working with the same files on multiple places and keeping a history of these files. But well, version control isn’t the topic of this post.

Actually I was trying to add a post-commit hook to one of my repositories. This hook should do a simple trick: updating a working copy on the same server after each commit. Not a big deal, or at least it shouldn’t be. Writing the hook was no problem:

#!/bin/sh

cd /path/to/working/copy/on/the/server
svn update

Looks easy… but doesn’t work. The svn update command just doesn’t update the working copy. As the SubVersion FAQ suggests I’ve tested the hook a bit. On the server SubVersion is used together with Apache 2 and therefore the post-commit hook is run by the user Apache 2 is running with. When I switched to that user and executed the post-commit hook by hand it became obvious what doesn’t work: The svn update command was asking me for my login to the repository and wanted me to confirm the self signed certificate we’re using on the server.

Well, the repository is accessed using HTTPS (with a self signed certificate) and requires a login. Usually the SubVersion client caches this information but since the user of Apache 2 is just a system user it can’t do so.

The login isn’t a problem, a quick look a the parameters of the svn command solved this:

svn update --username [myuser] --password [mypassword]

However there isn’t a parameter to confirm self signed certificates which aren’t signed by a trusted issuer. I tried it neverless but always ended up with an “issuer is not trusted” error. I tried searching around for several hours and found some people with the same problem. However there doesn’t seem to be a solution for this… at least none by using the svn command or one of it’s parameters.

This is why I tried some other approach: with Linux it’s quite easy to play around with the input and output streams. So why shouldn’t it be possible to fake the “p” key needed to confirm the certificate when the svn command asks for?

svn update --username [myuser] --password [mypassword] < /bin/echo 'p'

Using the normal input operator < (don’t really know how this is called) doesn’t work. The svn command just aborts in some strange way. However with a lucky look at Wikipedias Bash page I learned something new: Bash supports the “here document” syntax.

command <<< "string to be read as standard input"

So trying this for the svn command

#!/bin/sh

cd /path/to/working/copy/on/the/server
svn update --username [myuser] --password [mypassword] <<< "p"

and it worked! It used the login for the repository, accepted the self signed certificate and updated the working copy. So this was the solution for this… not by using the svn command but by using good old Bash.

After all it was funny playing around with this. I hope some other people find this useful. ;)

Another English post because this might come in handy for some people out there. Some Rails programmers out there may know the problem:

When updating your production server you’ve just run svn update to update the source of your Rails application. Because of cached code it is also necessary to restart the dispatchers of the Rails application.

Well, I have to admit, until now I simply restarted the Apache2 webserver or killed all dispatcher processes (killall dispatch.fcgi). However since there are quite a few Rails apps running on my server this always killed the other dispatchers, too. This isn’t really a problem but more of “unnecessary brute force”. The perfect solution would be to find the exact dispatcher of the Rails application I want to update and just kill this one.

But how? ps -A | grep dispatch.fcgi only prints out the PIDs of the dispatchers but not the paths. To work around this and I created a little script: find_dispatcher.rb

It analyses the Apache log file and shows the data of every log entry where an FCGID dispatcher was started.

ruby find_dispatcher.rb

1722    Fri Jul 06 18:59:01 2007  /path/to/project/a/public/dispatch.fcgi
1755    Fri Jul 06 19:11:52 2007  /path/to/project/b/public/dispatch.fcgi
4615    Sat Jul 07 14:49:14 2007  /path/to/project/c/public/dispatch.fcgi
4931    Sat Jul 07 16:20:30 2007  /path/to/project/d/public/dispatch.fcgi

It’s possible to specify a filter to just see the dispatchers created for a single project:

ruby find_dispatcher.rb -f project/b

1755    Fri Jul 06 19:11:52 2007  /path/to/project/b/public/dispatch.fcgi

To combine this script with others the --only-last-pid (or -p) option just prints out the last PID:

ruby find_dispatcher.rb -f project/b -p

1755

By default the script searches the /var/log/apache2/error.log file for matching entries. You can specify your own log file with the --log (-l for short) option.

ruby find_dispatcher.rb --log /my/own/log/file.log

This is it. --help will show an overview of all options. You can get the script directly out of my SubVersion repository: find_dispatcher.rb. Much fun with it.

UPDATE: I just found out that ps -Af also prints the path to the processes. Together with grep it’s no deal to get the PID of a specific dispatcher (eg. ps -Af | grep collaboa). This makes the script a bit useless. However it can be still interesting to know when your dispatchers where started.

At least it was an exciting programming practice. :)

Mir ist gerade etwas langweilig, während der Helion Webserver gerade SubVersion neue kompiliert bzw. die Ruby bindings prüft (zum x-ten mal heute). Ist aber eine andere Geschichte…

Seit gestern genieße ich die Vorzüge der neuen Skype Version 1.4 für Linux (noch Beta). Ich muss wirklich sagen, dass mich dieses Update sehr beeindruckt hat. Es passt sehr viel besser in den Gnome Desktop, die Bedienung ist einfacher und angenehmer und: es schaut besser aus. :)

Hab vor ein paar Tagen einen Überblick über die kommende Opera-Version 9.5 gelesen. Dort stand auch, dass sie nun Qt 4 verwenden und sich dadurch Opera sehr viel besser in Linux-Desktops einfügt. Für normale Menschen: Qt ist eine C++ Bibliothek, womit man plattformübergreifend Benutzeroberflächen programmieren kann.

Ich schätze mal, dass ein guter Teil des Skype-Updates auf die Nutzung von Qt 4 zurückgeht. Wenn das so ist, dann bin ich mal auf die neue Opera-Version gespannt.

Sehe gerade, dass der Helion Webserver fertig geackert hat. Werde dann mal weiter machen und hoffentlich noch ein paar Stunden Schlaf bekommen.

ps.: Der Helion Webserver ist durch ein neues SubVersion-Modul jetzt auch etwas schneller geworden. Die Zeit hat sich alleine deshalb schon gelohnt.

Schon seit der Helion Webserver online ist, wollte ich meinen eMail-Verkehr über diesen Server abwickeln. Allerdings handhabt der Helion Webserver eMails etwas anders, als die meisten “normalen” Anbieter. Bei GMX, Tiscali, usw. laufen die eMails auf dem Mailserver an und werden dort über POP3 vom Client herunter geladen. Das ist schön und gut, solange man nur einen Rechner hat, von dem aus man eMails schreibt. Da mein Laptop aber durch Ubuntu eine total unerwartete Renascence erlebt hat, reicht das für mich nicht mehr.

Der Helion Webserver handhabt eMails über IMAP. Hier bleiben alle eMails auf dem Server. Der Client läd z.B. die Kopfzeilen der eMails herunter (Betreff, Absender, usw.) und bei bedarf wird auch der eMail-Inhalt heruntergeladen. Was für mich aber viel wichtiger ist: alle eMails bleiben auf dem Server, also auch Antworten von mir, Entwürfe, usw. Dadurch kann man auch auf verschiedene Weise auf seine eMails zugreifen. Wo ich früher nur Operas eMail-Client verwenden konnte, kann ich jetzt mehere eMail-Clients parallel verwenden. Das “i-Tüpfelchen” ist für mich hier RoundCube, einer der besten WebMail-Clients, dich ich je gesehen hab, der auch auf den Helion Webserver läuft. So kann ich jetzt also von meinem Hauptrechner, meinem Laptop und auch aus dem Internet auf meine eMails zugreifen und auch neue schreiben. Und da die eMails zentral gespeichert sind ist alles immer schön aufgeräumt.

Aber leider hat die Umstellung nicht nur schöne Seiten. Sie war z.B. der Anlass, meine 2½ tausend gespeicherten eMails zu sortieren. Das war zwar etwas anstrengend, aber auch interessant (hätte nicht gedacht, dass man so viel vergisst…). Leider hab ich während dieser Sortiererei festgestellt, dass Opera nicht sehr gut mit IMAP klar kommt. Während ich das datenbankähnliche System von Opera sehr schätze, nervt es doch, dass man keine Orderhierarchien anlegen kann und dass das Verschieben von eMails recht lange dauert. Alles in allem macht IMAP bei Opera einen “angeflanschten” Eindruck.

Aus diesem Grund habe ich heute auch mal wieder Thunderbird ausprobiert. Wieder erwarten ist die IMAP-Unterstützung beeindruckend. Man kann fast genauso wie mit lokalen eMails arbeiten. Die Anzeige bzw. der Download von eMails ist sehr schnell und intelligend (zuerst wird der Text runtergeladen und angezeigt, dann erst Anhänge). Zusätzlich kann man Order zum offline lesen komplett herunter laden, was sich vor allem wegen dem Laptop als nützlich erweisen kann. Nicht so toll finde ich jedoch die Handhabung bzw. Erkennung der Zeichenkodierung (UTF-8 oder ISO-8859-15). Die Einstellung der Schriftarten macht ebenfalls Probleme (schlecht lesbar). Von der Suchfunktion her ist Opera auch um einiges schneller und angenehmer.

Wie gut, dass man dank IMAP mehrere eMail-Clients gleichzeitig verwenden kann. :)

Ein Arbeitskollege von mir arbeitet seit einiger Zeit an der Webseite eines Kunden. Um die Website zu hosten, hatten wir wegen unsere bisherigen Erfahrungen Strato ausgewält. Zuerst hatten wir Ärger mit Strato, da bei ihnen der Webserver und der Mailserver einer Domain auf die gleiche IP-Addresse verweisen müssen (aus welchen Gründen auch immer…). Deshalb war unser Kunde schon gezwungen, den Mailserver von Strato zu verwenden, was natürlich für etwas Ärger gesorgt hat. Ach ja, von dieser Einschränkung stand nirgends was. Der Support hat uns anschließend verraten, dass man erst einen virtuellen Server braucht, um diese Dinge einstellen zu können. Bei anderen Anbietern ist das allerdings nicht so…

Ok, die Website lief schon seit einigen Tagen auf dem Server von Strato, als wir frühs rein kahmen und feststellten, dass die Domain gesperrt wurde (“Internetpräsenz nicht erreichbar, bla bla bal…”). Nach einem etwas hektischen Anruf bei der Service Hotline und 10 Minuten in der (kostenpflichtigen) Warteschleife haben wir von einem Servicemitarbeiter erfahren, dass die Erstrechnung nicht gezahlt wurde.

Ohne Mahnung, Benachrichtigung oder eine eMail wurde deshalb von einen Tag auf den anderen die Website einfach dicht gemacht. Einfach so, ohne Vorwarnung. Eine Website mit 2000 bis 3000 Besuchern täglich. Wir haben das natürlich mit dem Kunden abgeklärt und er hat dann auch den Rechnungsbetrag überwiesen. Logischer weise sollte die Seite so schnell wie mögich wieder online gehen… wir dachten da an so ca. 30 Minuten. Nach 3 Anrufen bei der Strato Servicehotline hatten wir den Zahlungsbeleg an 3 verschiedene Durchwahlen der Buchhaltung gefaxt… angeblich beschleunigt das die Sache. Wir haben dann auch eine nette eMail bekommen, dass unser Auftrag mit hoher Priorität verarbeitet wird.

Tja, die Seite ist nun schon seit 1½ Tagen gesperrt und die Buchhaltung (die erst das OK für die Freischalung geben muss) ist entweder gnadenlos überfordert oder einfach langsam. Oh, und wir haben natürlich gestern Abend, nach dem die Seite schon fast einen Tag gesperrt war, eine Mahnung bekommen, dass die Rechnung nicht gezahlt wurde.

Meine persönliche Lehre aus der Geschichte: Ich werde nie etwas bei Strato kaufen. Solange es läuft, OK, aber wenn es drauf ankommt… KO! Da liebe ich doch den eigenen Webserver. Wenn der steht kann man wenigstens aktiv was machen und muss nicht darauf warten, bis irgend welche hochmotivierten Leute etwas für einen erledigen.

Die Seite läuft nun endlich über das Apache Modul fcgid. Dadurch braucht der Server nun keine 2 bis 3 Sekunden Bedenkzeit mehr, wenn jemand eine Seite aufruft. Es war zwar etwas gefrackel, so wie vieles bei Debian Linux (wenn man nich all zu oft mit arbeitet), aber es läuft… und das gar nicht mal schlecht. Noch dazu hat Flo den HelionWeb Server noch etwas optimiert, so dass nun mehr freier Arbeitsspeicher zur verfügung steht. Der Server gefällt mir von mal zu mal besser. :)

Das wirklich schöne an dem Tag heute war, dass er für meine Verhältnisse “normal” war. Kirschen pflücken (in 5 Metern Höhe in einem Baur rumzuklettern macht jedem Spaß), im Schwimmteich tauchen und noch grillen… schön, wenn man merkt, dass man auch noch ein “normaler” Mensch ist. Das mag sich jetzt vielleicht etwas dumm anhöhren, aber wenn sich 5 oder 6 Tage in der Woche nur alles irgend wie um PCs, Internet und Programmieren dreht, ist man über sowas froh.

Heute früh hab ich mich auch noch mal an einem neuen Design für diese Seite hier probiert… hautsächlich um zu merken, dass mir in diesem Bereich noch sehr, sehr viel Übung und die richtige Denkweise fehlt. Was Design angeht, komme ich mir an der Arbeit oft wie der einäugige unter den blinden vor.

Naja, das Wochenende war schön und erholsam. Auf bald. :)