Nach meinem Umzug stand natuerlich auch noch eine neue Telefonanlage an. Da ich in diesen Sachen gerne selbst plane und mein Vermieter sowie auch ich beide relativ gerne an den Telefonanlagen basteln, dachte ich, ich baue eine eigene Asterisk. Ich besitze eh nur noch SIP-Telefone, kann Faxe auf einem Fax-Server empfangen und bediene mich fuer alles weitere einer sehr grossen Menge an Sipura/Linksys ATAs. Das reicht fuers Experimentieren und ist auch fuer mein geplantes Setup die geeignetste Loesung.
Zum Problem: In meiner alten Heimat steht bereits ein Asterisk-Server, der ueber das VPN von allen meinen Systemen aus erreichbar ist. Meine beiden Telefone hier in Dortmund verbinden zum Zweck der Kommunikation aktuell auch direkt ueber das VPN mit diesem Host. Das fuehrt zu unvorhergesehenen Sprachproblemen (Phone -> VPN Router DO -> VPN -> VPN Router Xanten -> Asterisk -> PSTN) bei Auslastung einer der DSL-Leitungen, hinter denen sich die VPN-Router aufhalten. Das ist relativ unpraktisch, auch wenn es aktuell das tut, was es soll. Meine Eltern koennen mich anrufen, ich kann das gleiche umgekehrt tun und zusaetzlich auch ueber meinen alten Telefonanschluss telefonieren und Telefonate empfangen. Das soll auch so bleiben. Ich haette allerdings gerne auch einen Uebergang ins Telefonnetz von Dortmund aus. Dies wuerde zu einer besseren Sprachqualitaet und angenehmeren Telefonaten fuehren und auf Dauer die Asterisk in Xanten nach und nach ueberfluessig machen. Was also tun?!
Ich dachte an das Einfuehren eines Zwischenschrittes… eine zwischen-Asterisk in Dortmund, die die Telefone an diesem Standort konzentriert und ueber IAX2 mit einer Asterisk in Netztechnischer Naehe zum VPN-Server in Duesseldorf verbindet. Die Asterisk in Xanten tut gleiches. So erreiche ich, dass ich weiterhin Telefonate von Dortmund nach Xanten und andersherum Routen kann und erreichbar bleibe. Zusaetzlich fuehre ich die inzwischen wachsende Zahl an Telefonanlagen an einem zentralen Punkt zusammen und erleichtere so den Ausbau der Infrastruktur. Sollte ich mich also klonen lassen -> kein Ding.
um diesen Zweck zu erfuellen, erreichen mich einige Hardware- und Softwareanforderungen, deren Erfuellung mit dem Minimax-Prinzip vergleichbar ist. Moeglichst viel Leistung und Aufgabenvereinigung in einem kleinen, stromsparenden und leisen – moeglichst geraeuschlosen Geraet. Mein Park an Hardware war also dahingehend zu durchforsten und: Ich hab was gefunden 
. Aus meiner Zeit in der alten Firma besitze ich einen beachtlichen Park an Maxdata Thinclients in diversen Geschmacksrichtungen. Eines der Geraete ist mit einem PCI und einem PCMCIA Slot ausgestattet und somit auch fuer den Einbau einer ISDN-Karte bestens geeignet.
Thinclient mit ISDN-Karte und leerem PCMCIA-Slot
Im Inneren werkelt ein VIA Samuel 2 mit etwas ueber 500Mhz, ein 128MB grosses Kurzzeitgedaechtnis auf einem handelsueblichen 133Mhz SD-DIMM und ein 4GB Microdrive aus einem anderweitig defekten iPod mini.
eingebaute ISDN-Karte und IDE-CF-carrier
Das Material-Lineup besteht also aus einem besagten Maxdata Thinclient (IGEL relabel eines IGEL 2 (232-CE4) mit OEM-Anpassungen), einem 4GB Microdrive, einer HFC-PCI ISDN-Karte mit HFC-s Chip und einem Schraubendreher (klar oder?)
^- Thats the crew! -^
Zu dem Microdrive muss ich ergaenzend etwas sagen: Es ist der einzige halbwegs grosse CF-Datentraeger gewesen, der da war. Bei ebay wechseln diese Drives fuer etwa 20-30 Euro den Besitzer – deutlich weniger als die normalen Microdrives mit 4GB, die nicht aus ausgeschlachteten MediaPlayern stammen. Dies hat den Grund, dass diese Drives keine “echten” microdrives sind und nicht im PCMCIA/CF Modus sondern lediglich im IDE Modus laufen. Dies ist eine Huerde fuer die meisten Cardreader und Digitalkameras, nicht aber fuer unseren Carrier. Die Karte wird ueber diesen als normales IDE-Geraet ohne DMA angesprochen und laeuft somit – langsam aber ohne Probleme.
Das Softwarelineup gestaltet sich etwas komplizierter. Da ich mich fuer eine Asterisk Telefonanlage entschieden habe und debian meine Distribution der Wahl ist, entscheide ich mich dafuer, diese beiden Komponenten zu einem Bootbaren Festplattenimage zu kombinieren. Hierzu habe ich einen Ordner angelegt und darin eine aktuelle stable-Version von Debian mit dem debootstrap-script positioniert. Via chroot muessen nun hier Kernel und kernel-header nachinstalliert werden, alternativ kann auch ein eigener Kernel fuer den Thinclient gebaut werden. Eine kernel config fuer diejenigen, die diesen Thinclient zufaellig auch einsetzen habe ich hier bereitgestellt. Sie enthaelt ein paar Module mehr als noetig, unter anderem TUN devices, soundtreiber, bluetooth support. Diese Funktionen brauche ich fuer die anderen Anwendungsgebiete, die dieses Geraet nacher haben soll.
Das selberbauen der Asterisk und der mISDN module wird in vielen vielen tutorials bereits beschrieben, ich spare mir das in diesem informationellen post einfach mal. Die build config der Asterisk beinhaltet zumindest so ziemlich alles, was die asterisk 1.4 kann. Als ISDN Channel driver soll wie bereits angedeutet mISDN zum Einsatz kommen.
Die Asterisk kompilierte ich in der chroot umgebung meines debootstrap folders mit einer installierten toolchain. Dies ging, da der ThinClient wie auch mein Host system i386-kompatibel waren. Ebenso verfuhr ich mit mISDN und mISDNuser. Hier muessen die Pfade zu den kernel headern pinibel angegeben werden, das mISDN in einem Verzeichnis nach diesen sucht, die es aus der aktuell laufenden Kernel-version generiert. Dies funktionierte bei einem eigenbau natuerlich nicht.
FreePBX folgt, da ich eine Trennung von Extensions und Endgeraeten vorsehe und keine Lust habe, mir alle Features der Anlage selber zu scripten.
Auf das Microdrive bringe ich die Daten und den kernel via “cp -rav”. Der Bootloader wird etwas knifflig. Hierzu muessen /proc und nach moeglichkeit /sys im chroot verfuegbar sein. Danach wird grub im chroot installiert. Wir benoetigen fuer die Installation von Grub eine device.map, die die Situation angibt, wie sie aktuell in unserem System vorliegt. Die Konfiguration spaeter schaut allerdings ganz anders aus. Mein Microdrive steckt aktuell in /dev/sdb, spaeter im Geraet allerdings in /dev/hda…
Wir brauchen also voruebergehend fuer die Installation etwas, was etwa so ausschaut in /boot/grub/device.map um Grub installieren zu koennen:
(hd0) /dev/sdb
Vermutlich existiert in /dev/ im chroot kein Devicenode fuer dieses Geraet. Wir koennen mittels “MAKEDEV generic” allerdings dort die generischen devicenodes anlegen. Weiterhin muessen wir in der /etc/fstab voruebergehend flunkern und dort als Mountpoints die entsprechenden Geraetenamen eintragen, die zum Zeitpunkt der Installation gueltig sind, insbesondere wenn /boot und / auf verschiedenen Partitionen liegen. Ist das der fall, so lohnt es sich, in /boot einen symlink von boot nach ./ anzulegen, da einige scripte sich darauf verlassen.
Damit nun grub-install die /boot Partition – so es denn eine gibt – auch findet, muessen wir noch die /etc/mtab entsprechend anpassen. Hierher bezienen mount und und umount die Informationen ueber gemountete Dateisysteme. Ich erzeuge dort 3 Eintraege, die ich aus /proc/mounts ableite:
/dev/sdb2 / ext2 rw 0 0
/dev/sdb1 /boot ext2 rw 0 0
proc /proc proc rw 0 0
Mit “mount” sieht man sehr schnell, ob man alles richtig gemacht hat. Anschliessend sollte “grub-install /dev/sdb” den Bootloader an die passende Stelle installieren. “update-grub” erzeugt uns nun eine aktuelle menu.lst und wir vergewissern uns, das alles richtig ist: In /boot/grub sollten nun die stages fuer unseren Grub bootloader liegen. Hier editieren wir auch noch schnell die device.map auf die spaetere Konfiguration im System. Wir passen die /etc/fstab wieder an, so dass spaeter die Devicenamen auch passen. Die /etc/mtab koennen wir mit aller zuversichtlichkeit loeschen, bitte aber direkt mittels touch wieder anlegen. Da die grub installation in aller Regel leider nicht erkennt, dass hda1 nicht das tatsaechliche root ist, erweitern wir in der menu.lst auch nich die zeile mit “kopt” um “root=/dev/hda2 hda=nodma panic=5″ und ersetzen das alte “root=”. Ein “update-grub” regelt die Einzelheiten. Nach getaner Arbeit verlassen wir das chroot und testen unseren Erfolg im qemu – nachdem wir alle Verweise und mounts auf /dev/sdb aufgeloest haben versteht sich.
Zeigt “qemu -hda /dev/sdb” ein grub-menue, hat unsere Arbeit Erfolg gehabt.
Das Geraet bootet und ich kann die Asterisk wie gewuenscht konfigurieren
