Fuer meine neue eierlegende Wollmilchsau wollte ich auch mal ein Debian Lenny x64 testen. Die Maschine ist ein Asus P5K SE mit einem Core2Quad Q6600 und hat 4GB Ram. Um die voll zu nutzen waere 64 Bit natuerlich schoen. Das Debian x64 kam nach allen aktuellen Updates mit einem 2.6.25-2-amd64 daher. Als ISDN-Interface verwende ich eine HFC-S ISDN Karte im PCI Slot (davon hat das Asus P5K zwei, im anderen steckt die Terratec fuer den zentralen Videorecorder) und moechte den zaphfc Treiber von Junghanns.net einsetzen. Leider war es mir nicht moeglich in dieser Konfiguration ein funktionierendes Setup zu bekommen. Wenn es schon so anfaengt, dann wirds sicher keine Freude das auf Dauer als Home-Server zu verwalten.
Daher versuche ich es jetzt mal mit einem x86 System. Und da klappt das auch sofort ohne irgendwelche Probleme. Hier mein detailliertes Vorgehen:
Als Basis dient eine Baseinstall Debian Lenny x86, nur Standard-System im tasksel ausgewaehlt. Folgende Pakete muessen dann nachinstalliert werden, damit die Asterisk spaeter durchkompiliert:
Anschliessend brauchen wir das Bri-Stuff-Asterisk-Paket von Junghanns.net. Es gibt auch Asterisk 1.4 Pakete, sogar Bri-Stuffed, aus dem debian-apt. Auch ist es moeglich die zaphfc-module ueber den module-assistant von debian zu bauen. Allerdings habe ich damit so meine Probleme gehabt. Ausserdem ist das Paket von Junghanns.net noch eine RC3 und bristuff ist ein sehr lebendiges Projekt. Da ist die Version aus dem apt schnell altbacken. Daher habe ich mich dafuer entschieden das Source-Paket direkt zu bauen und dokumentiere im Weiteren das Vorgehen:
Nachdem es bei Tools wie VMWare und auch den Manits-Treibern hilfreich war den Kompiler auf den zum Kernel passenden gcc-4.1 zu aendern, und auch bei der Asterisk-Install (vielmehr beim bauen von zaptel) Kernelmodule gebaut werden, dachte ich, es sei sinnvoll hier ebenfalls den gcc-4.1 Kompiler zu verwenden. Da ich im Betrieb keine Probleme hatte habe ich nicht getestet, ob und inwiefern das einen Effekt hat, wenn man stattdessen mit dem 4.3er GCC baut. Zum setzen des gcc-4.1 habe ich den zaptel-Part der compile.sh angepasst:
Danach dann das Script install.sh starten:
Es werden jetzt diverse Source-Pakete heruntergeladen und gepatched. Danach beginnt direkt der Kompilierprozess. Dieser stellt immer wieder Fragen. Wenn kein Fehler auftritt, dann kann man hier einfach durch druecken von Return weiter machen.
WICHTIG: Bei der Frage nach dem iLBC Codec ist es notwendig die Lizenzbestimmungen zu lesen. Vor allem bei einem gewerblichen Einsatz der Installation begeht man sonst womoeglich einen Lizenzverstoss. Im Zweifel den Codec nicht installieren. Es geht weitgehend auch ohne iLBC.
Wenn dann alles soweit geklappt hat, dann sind wir irgendwann hier:
Congratz 🙂 Dann ist die Installation schon mal abgeschlossen.
Jetzt gilt es die eben installierte Software in Betrieb zu nehmen. Dazu eigenen sich erstmal die mitgelieferten Beispiele. Diese kann man installieren, indem man folgendes macht.
Zuerst installieren wir die zaptel-configs und das init-script fuer zaptel:
danach muessen wir dann noch unser zaphfc modul in der Datei /etc/default/zaptel eintragen:
Dann in dieser Dateie alle Zeilen der folgende Art auskommentieren:
MODULES=”$MODULES tor2″ # T400P – Quad Span T1 Card
danach die Zeile einmal kopieren und unter der letzen MODULES-Zeile einfuegen. Dort dann das vorhandene Modul durch zaphfc ersetzen. Natuerlich nicht auskommentieren. Beispiel:
MODULES=”$MODULES zaphfc” # HFC ISDN Card
TIPP: Wer keine Zaptel Hardware hat, aber trotzdem mit den Zaptel-Features der Asterisk testen moechte kann hier das Modul ztdummy laden. Dies simuliert eine Zaptel-Interface Timing-Source.
Dann kopieren wir noch das Zaptel-Config-Beispiel von Junghanns.net an die richtige Stelle:
Damit ist die Konfiguration von zaptel abgeschlossen uns das ISDN-Interface sollte nach dem Reboot zur Verfuegung stehen. Natuerlich kann man das auch ohne Reboot testen. Ist ja kein Windows 😉 Einfach ein
ausfuehren. Dann sollte so eine Ausgabe kommen:
Je nach eigener Konfig ohne das ztdummy Module. Ich habe das in der Konfig, weil die ISDN-Karte aktuell noch im anderen Server steckt. Mit dmesg kann man dann auch die Ausgabe das HFC Treibers anschauen:
Wenn eine ISDN Karte drinn steckt, dann sollte der Treiber hier natuerlich keine “0” mehr melden. Nachdem wir also nun das zaptel fertig eingerichtet haben wenden wir uns der asterisk zu. Auch hier installieren wir erstmal die Beispielkonfigs:
Dann kopieren wir noch die Zaphfc Beispielkonfig von Junghanns.net. Vorher sichern wir die mit das asterisk gelieferte Default-Konfig:
Jetzt fehlt nur noch das Init-Script. Das leihe ich mir gerne bei Debian. Da laeuft die Asterisk dann auch unter dem User asterisk, was aus Sicherheitsgesichtspunkten natuerlich sinvoll ist. Damit das sauber klappt muessen wir erstmal den User anlegen:
Dann gibts hier das Init-Script zum herunterladen: asterisk Init-Script. Das muss dann in /etc/init.d platziert und ggf mit update-rc.d aktiviert werden:
Leider gibt es da noch ein kleines, aber feines, Problem 🙁 Die Asterisk im Junghanns.net Paket setzt das “localstatedir” unter Linux auf /var/run. Da darf aber der User asterisk nicht schreiben. Daher startet die Anlage nicht. Daher muss das “localstatedir” auf /var/run/asterisk angepasst werden und wir muessen die Anlagensoftware nochmal bauen. Dazu machen wir folgendes:
Dort passen wir dann die folgende Zeile an:
ASTVARRUNDIR=$(localstatedir)/run
ASTVARRUNDIR=$(localstatedir)/run/asterisk
und bauen die Software erneut durch:
Selbiges machen wir auch nochmal fuer die asterisk-addons gegen unseren neuen Build:
Dann muessen wir noch die entsprechenden Verzeichnisse dem User asterisk schenken:
Dann passen wir noch in der Datei /etc/asterisk/asterisk.conf die folgende Zeile an:
astrundir => /var/run
wird
astrundir => /var/run/asterisk
Und wir entfernen den Kommentar bei folgenden Optionen:
[options]
runuser = asterisk ; The user to run as
rungroup = asterisk ; The group to run as
So, wenn jetzt alles glatt geht, dann sollte die Asterisk starten.
Dann nachschauen ob der Prozess laeuft mit
Wenn sich in der Ausgabe eine solche Zeile befindet, dann wurde asterisk erfolgreich gestartet:
Wenn das geklappt hat kann man sich nun mit einer Remote-Konsole verbinden. Mehr “v” steigern die Gespraechigkeit der Anlage. Das “r” steht fuer reconnect einer bereits laufenden Anlagensoftware:
VORSICHT! Ab diesem Moment wird die Software automatisch beim booten gestartet. Das ist keine gute Idee, wenn die Kiste in einem offenen Netzwerk steht und eine Default-Konfig hat. Bitte die Maschine entsprechend absichern und die Sicherheitsdokumentation von asterisk lesen. Vor allem bei einem produktiven Einsatz ist es unabdingbar sich mit der Sicherheit auseinanderzusetzen. Die Loesungen hier sind nur fuer geschlossene Netze gedacht und nicht sicher !!!
Wenn zu diesem Zeitpunkt eine HFC ISDN Karte in der Kiste steckt und diese auch laut “dmesg” richtig konfiguriert wurde, dann kann man folgenden Test machen:
– ISDN Karte mit dem eigenen NTBA verbinden
– Alle anderen Telefone ausstecken
– eine der eigenen MSNs anrufen
– dann sollte die Demo der Asterisk zu hoeren sein
– durch die Eingabe von Ziffern kann durch die Menues navigiert werden
Wenn das klappt ist es als naechstes an der Zeit IP-Telefone einzubinden und eine eigenen Dialplan zu erstellen. Das wird in diesem Post nicht mehr behandelt. Hier aber noch ein paar Infos zum Einstieg:
Als IP-Telefone kann ich SNOM sehr empfehlen. Vor allem im gerweblichen Einsatz sehr gute Geraete und gute Integration mit asterisk. Dazu mal mehr in einem anderen Post. Dann habe ich noch erfolgreich ein Siemens S450IP im Einsatz. Als Softphones kann ich das freie Ekiga und das kostenlose X-ten Lite empfehlen.
Ab und zu kann es in den Logs (oder in dmesg) zu folgenden Fehlermeldungen kommen:
Es gibt im Internet viele verschiedene Aussagen und Meinungen wann und warum sowas passiert. Einig sind sich die meisten insofern, als es etwas mit dem Interrupt-Handling zu tun hat. Ich moechte hier nicht auch wieder darauf eingehen. Google hilft im Zweifel. Von mir nur so viel. Auf meinem P5K SE tritt der Fehler sehr selten auf und nur wenn die Kiste unter Last ist. Auf meinem vorherigen Server, einem P4P800 SE mit einem 3 Ghz P4 war der Fehler haeufiger zu beobachten. In beiden Faellen haben die Meldungen aber den stabilen Betrieb nicht beeinflusst. Es war lediglich ein Knacken in der Leitung wenn, man zum Zeitpunkt der Meldung telefoniert hat. Es ist in jedem Falle sinnvoll die PCI-Karten solange zu sortieren (oder unnoetige Onboard-komponenten abzuschalten), bis die HFC-Karte sich ihren Interrupt nicht mehr mit einer anderen Karte teilen muss. Pruefen kann man das mit:
Gut sieht so aus:
17: 404965966 405005448 IO-APIC-fasteoi zaphfc
sowas hier ist schlecht:
17: 404965966 405005448 IO-APIC-fasteoi zaphfc, eth0
Das ist bei mir sowohl auf dem P4P800 als auch auf dem P5K zu bewerkstelligen gewesen. Fuer den professionellen Einsatz sollte man sowieso eine Karte von Junghanns.net nehmen. Da gibt es diese Probleme nicht.
Hast du ein ./configure vor den make samples vergessen?
VG
Stefan
Ich denke nicht. Das Paket ist ja bereits konfiguriert, da das automatische Build-Script von Junghanns.net dies vor den bauen getan hat. Wenn ich also direkt nach Abschluss des automatischen Build ein “make samples” mache, dann kommen bei mir korrekte Konfig-Dateien in /etc/asterisk an.