Just because it's:

Archive for July, 2007

Problemlösung für langsames GNOME

Friday, July 20th, 2007

Vor ein paar Tagen hatte ich unter Arch Linux das Problem, dass die Anwendungen unter GNOME wirklich sehr langsam starteten. GEdit zum Beispiel brauchte in Spitzenzeiten ganze 30 Sekunden bis das Programm endgültig geladen war. Dieses doch sehr strange Problem lässt sich nicht unbedingt weniger strange aus der Welt schaffen. Gibt man in der Datei /etc/hosts anstelle von z.B. 'localhost.localdomain' einen vernümftigen Hostname (idealer weise den eigenen) an, klappt es auch mit GNOME wieder einwandfrei.

Vorher: 127.0.0.1 localhost.localdomain localhost

Nachher: 127.0.0.1 neuromancer localhost

Es wäre jetzt mal interessant zu wissen, ob das Ganze jetzt ein X oder eher ein GNOME eigenes Problem ist.

AGI mit Python

Friday, July 6th, 2007

Das Asterisk Gateway Interface (kurz AGI) ist die Schnittstelle der Asterisk Software Telefonanlage. AGI bietet nahezu jeder Programmiersprache die Möglichkeit mit dem Telefon-Server zu interagieren. Das Prinzip ist in etwa mit dem des Namensvetter Common Gateway Interface (CGI) bei Webservern zu vergleichen. Ein Request auf ein bestimmtes Dokument bzw. Telefonnummer erreicht den Server. Dann wird ein externer Interpreter gestartet, der ein Programm ausführt und dem Server das Ergebnis des Programmlaufs mitteilt.

Im Gegensatz zu CGI ist AGI von Natur aus auf ein kontinuierliche Verbindung ausgelegt. Das bedeutet, dass wenn eine neue Telefonsitzung angenommen wird, stehtig Daten rein und raus gehen können ohne die Verbindung zwischenzeitlich zu unterbrechen. Wohingegen CGI für paketbasierte Kommunikation entworfen wurde, und normalerweise nur einmal zu Beginn der Anfrage, Daten über die Umgebungsvariablen übergeben bekommt.

Wie bereits erwähnt, kann man AGI mit nahezu jeder Sprache ansprechen. Warum ist das so? Ganz einfach: AGI kommuniziert über die drei heiligen Datenkanäle STDIN, STDOUT und STDERR und nutzt im “Protokoll” Plaintext Befehle. Da praktisch jede Programmiersprache im PC bereich zumindest zwei dieser Kanäle unterstützen sollte um irgendwie existenzberechtigt zu sein, ist man bei der Wahl der Sprache ziemlich frei.

In meinem Fall habe ich mich für Python entschieden. Es gibt eine Menge freier AGI Bibliotheken für Python. Leider mangelt es wie so häufig an der API Dokumentation und/oder guten Beispielen. Aufgrund der einfachen Umgangs mit AGI und wegen des gewissen Lerneffekts, ist es auch eigentlich kein Problem sich direkt selbst mit dem Server zu unterhalten. Mit wenigen Zeilen Code lässt sich ein funktionierendes AGI Template bauen. Auf das Listing verzichte ich an dieser Stelle aus technischen Gründen einfach mal weil das Vimcolor Plugin suckt viel besser zu kopieren ist, wenn man sich den Quelltext direkt runterladen kann.

Eingebunden wird das AGI Programm in der /etc/asterisk/extensions.conf unter einem gültigen Kontext mit dem Befehl “AGI(/path/to/script)“.

Was mir bei AGI allerdings negativ aufgefallen ist, ist die beschränkte Möglichkeit des debuggens. Zwar hat man in der Asterisk Konsole die Möglichkeit, mit dem Befehl “agi debug” in den Debug Modus zu wechseln, was einem aber in der Regel nicht sehr viel weiter hilft, wenn es hart auf hart kommt. Eines meiner Lieblingszenarien ist, wenn Asterisk nicht die nötigen Rechte zum öffnen des AGI hat. Dann bekommt man nämlich keine Fehlermeldung, sondern wird vom AGI Debugger darüber Informiert, dass das Script gestartet wurde und mit Return-Code 0 (d.h. alles in Ordnung) beendet wurde. Folgende Arbeitsweisen haben sich für mich als gutes Workaround für die AGI-Debug problematik herausgestellt:

  1. Teste/Validiere das Programm bevor du es von Asterisk ausführen lässt. In Vim für Python z.B. mit dem Befehl “! python %” oder für Ruby mit “! ruby -c %
  2. Nutze ein eigenes Logging. Output Debugging über Asterisk ist meiner Meinung nach zweckentfremdung, denn alles was man zu Asterisk schickt sollten Befehle sein. Außerdem ist es hässlich zu lesen. Stattdessen besser in ein externes Logfile schreiben und im terminal mit “tail -f $my_logfile” das Geschehen live mitverfolgen.

Anbei noch ein paar nützliche Links zum Thema: