ubuntuusers.de

Hallo Leute,

möchte hier ein Erfahrungen einstellen, die ich bei der Verwendung verschiedener sogenannter Remaster-Tools für Ubuntu sammeln konnte. Ich hoffe hier im Forum ein paar Anregungen und/oder Links zu erhalten um mein Remaster-Vorhaben so gut wie möglich umsetzen zu können.

Mein Ziel: Erstellung einer angepassten Ubuntu Version für den Einsatz als Kommunikationsserver mit dem Schwerpunkt Asterisk. Das Remaster habe ich bis auf weiteres Callbuntu getauft.

Meine Basis (leider) Ubuntu Live-Desktop 7.10 Mit dem Asterisk aus den Paketquellen. Warum kein Hardy Server mit aktuellem Asterisk?!?

1. Mit Hardy hatte ich erhebliche Probleme die ISDN-Karten Fritz PCI und Sirrix-PCI4S0 zum laufen zu bekommen (Trotz workarrounds ging es nicht)

2. Ich habe auch einen selbstkompilierten Asterisk zwecks Fehlererkennung eingesetzt (Keine positive Veränderung bei ISDN 😢 ). Nach möglichkeit möchte ich aber so viel Software aus den Quellen verwenden wie möglich (+ Ubuntu-Konformität, + Updatefähig, + Systemintegrität, - Aktualität)

3. Die Verwendung des Server Kernels ist im zusammenhang mit der Fritz-Card-PCI anscheinend problematisch. Nach der im Wiki beschriebenen Vorgehensweise bei der Installation der Karte, wird der Server-Kernel gegen den Kernel mit der Endung 386 ausgetauscht. Hierdurch wird dann auch nicht mehr der "gehärtete" Server-Kernel eingesetzt.

4. Die wenigsten Probleme hatte ich im Betrieb mit der i386 7.10 Desktop mit dem generic-Kernel

Die Remaster-Tools

Vorweg haben alle genannten Tools die Voraussetzung, dass der Systembau auf derselben Ubuntu-Version stattfindet, wie der des Zielsystems. Verwenden tue ich die jeweils aktuellsten Versionen der Tools (siehe Beitragsdatum)

remastersys ist ein Tool aus Linux Mint (Ein Ubuntu Fork). Es erstellt mit der Option dist aus dem laufenden System eine Live-Disc. Die Anpassungen haben auch ziemlich gut funktioniert. Jedoch musste ich beim Test zwei nicht so schöne Eigenschaften von remastersys entdecken. Zum einen verwendet remastersys einen anderen Bootscreen (Der wahrscheinlich auch manuell gegen das Ubuntu-Schema beim Live-CD-Bootsplash getauscht werden kann, Zeit und Kenntnis vorausgesetzt 😉 ). Viel gravierender ist der Umstand, dass ich einen deutschen Live-Desktop erhalte (ist ja logisch), aber die Installationsroutine zwanghaft in Englisch durchgeführt werden muss, um durchzulaufen. In deutscher Sprache bleibt er bei 78 % der Installation hängen. Schade eigentlich :roll

Als zweiter Kandidat steht reconstructor im Feld. Reconstructor habe ich anfangs unberücksichtigt gelassen, da bei einer früheren Verwendung der Button für die chroot-Konsole nicht funktionierte. In den von mir verwendeten Versionen 2.7 und 2.8 funktionierte es hingegen, so dass ich, nach einigen Versuchen mit den anderen Tools, bis jetzt bei Reconstructor geblieben bin (wohlgemerkt: bis jetzt). Sehr positiv hat mich die einfache Designanpassung angesprochen, was mich allerdings auch ein bisschen zu ein paar Gimp-Sessions verleitet hat 😉 Aber auch Reconstructor hat aus meiner Sicht zwei gravierende Nachteile. Da wäre zum einen die ISO size. Anscheinend achtet Reconstructor beim Bau darauf einen gewissen Grundstock an Softwarepaketen "auf das ISO zu zwingen". Eine von Reconstructor aus dem chroot-System errechnete ISO-Größe von 753 MB wird dann zu einem tatsächlich 923 MB großen Image. Speziell den OpenOffice Kern und die wörterbücher tauchen wie von Geisterhand immer wieder installiert. Das weitere Problem betrifft das MySQL-Server Paket. (Wird im selben Fehler beim nächsten Tool erläutert)

Das Ubuntu Customisation Kit (UCK) war zuerst mein Fovorit. Die Anpassung durch die Dialoggesteuerte Programmführung ist Anwenderfreundlich und bietet trotzdem gute Möglichkeiten zur Anpassung. Sehr schön ist die Verwendung von Synaptic zum Entfernen von Paketen, da man einfach nur die Liste herunterarbeiten muss. Ein apt-cache search ist da ein wenig umständlicher, außer man weiß exakt welche Pakete runterkönnen ohne die Systemstabilität in Mitleidenschaft zu ziehen (z. B. deskbar-applets wenn man totem* deinstalliert 😉 Im Prinzip wäre ich bei UCK geblieben, aber da war noch das

MySQL-Problem

Es stellte sich schnell heraus, dass ein zentraler Bestandteil meines Zielsystems in Reconstructor und UCK Probleme bereitete: Der MySQL-Server. Bei der Installation in der chroot-Umgebung (egal, ob per apt-get oder Synaptic), kommt es zu Fehlermeldungen bei Ausführung des postinstall Scriptes. Dieses versucht am Ende der Installationsprozedur den MySQL-Server zu starten, was fehlschlägt. Bereigungen mittels dpkg --configure schlugen ebenso fehl. Das Paket musste ich also unkonfiguriert belassen und den Systembau fortgesetzt. Der Systembau stoppte dann aber immer reprouzierbar bei 96%. Nachdem ich bei launchpad davon berichtete, war am Ende des Beitrages ein angepasstes Paket zu finden, mit welchem Der Systembau nicht mehr unterbrochen wurde. Der Fehler bei der Installation tritt indes bis heute noch auf.

Folgen des MySQL-Problems

Das weitere Remastern dieses Images mit UCK wird reproduzierbar abgebrochen. Ich vermute wegen, der unvollständigen MySQL-Installation. In Reconstructor kann man aber glücklicherweise mit dem Image weitermachen. Jedoch taucht auf beiden Live-Medien der Fehler sofort in der Live Session in Form einer aport-Meldung auf. "Der MySQL-Server wurde beendet...". Installiert man das System, funktioniert dagegen alles Einwandfrei mit dem MySQL-Server. Dadurch, dass mysql nicht in der chroot-Umgebung läuft, weiß ich nicht, wie ich Datenbank-Dumps in die MySQL-Version vorinstallieren kann (Derzeit löse ich das durch ein Install-Script). Selbst wenn ich den mysql-server mit Reconstructor wieder vom Image entferne, habe ich es nicht geschafft, den Bau mit UCK dann fortzusetzen.

Bisher geändert in Kurzform Verschiedene Server Pakete installiert. build-essential für automatische kompilationsscripte. Kleinere eigene Programme. Zusätzlich webmin zur Serververwaltung, sowie die grafische Weboberfläche für den Asterisk (Welche ich zu gegebener Zeit öffentlich per subversion zugänglich machen werde). Design- und Menüanpassungen. Asterisk-Basiskonfiguration.

Mein Fazit

Mein absoluter Favorit wäre Reconstructor Customisation Sys 😉 Habe zwar noch nicht alle Kombinationen durch, aber ich denke mit Reconstructor bin ich bisher am besten gefahren, auch wenn ich wirklich kein OpenOffice, sondern lieber die 150 MB brauche 😕 Hier wäre jetzt UCK mein Mittel erster Wahl, wenn es denn klappen würde (bleibt derzeit vor der Anpassungskonsole beim Sprachpaket hängen). Mit UCK könnte ich bestimmt noch unter die CD-Kommen, da dieses Tool anscheinend keine Pakete zwangsinstalliert.

Meine Fragen

Kann irgendjemand meine Erfahrungen mit den Remaster-Tools bestätigen oder mir vielleicht den einen oder anderen Tipp geben, wie ich möglicherweise bessere Ergebnisse erzielen kann?

Gerne bin ich bereit merh Einzelheiten zu berichten, aber ich denke der Beitrag ist ja schon lang genug 😳

Danke an alle die bis hierhin durchgehalten haben 😉

André

Also ich benutze uck um eine cd zu remastern. Habe genannte Programme getestet und war mit keinem wirklich voll und ganz zufrieden, hauptsächlich da ich das ganze automatisieren wollte. Habe dann angefangen, mir eigene Skripte zu schreiben um das iso und und das Dateisystem zu entpacken. Nach einiger Zeit bin ich dann aber darauf gestoßen, das uck das alles schon fertig hat, also wieder zurück zu uck 😉 Man kann alles packen/entpacken und hat eine chroot Umgebung. Was braucht man mehr, die einzige Beschränkung sind die eigenen Linux Kentnisse.

Hab das ganze hier mal kurz getestet... mein Vorgehen:

1
2
3

sudo uck-remaster-unpack-iso ubuntu-8.04.1-desktop-i386.iso
sudo uck-remaster-unpack-rootfs
sudo uck-remaster-chroot-rootfs

Danach bin ich in der chroot und habe

1

apt-get install mysql-server

ausgeführt. Beim zweiten mal lief es ohne Probleme :roll

uck macht schon das was es soll. Wenn es Probleme gibt sind das eher Bedienfehler. Ich musste mich auch erst einarbeiten.

Zu deinem Problem. Beende mal bevor du mit dem remastern beginnst deinen mysql-server und deine Probleme sind Geschichte.

Der mysql-server belegt bereits Port 3306 dadurch gibt es Konflikte, wenn in der chroot versucht wird einen zweiten Server zu starten, da dieser versucht den selben Port zu nutzen.

MfG

Zu deinem Problem. Beende mal bevor du mit dem remastern beginnst deinen mysql-server und deine Probleme sind Geschichte.

Au backe ! Ich Idiot! Darauf bin ich nicht gekommen. Habe stattdessen immer probiert den mysql-server in der chroot-Umgebung zu beenden. Das ich vielleicht mal meinen eigenen ausstellen sollte, habe ich konsequent ignoriert. Da freue ich mich ja schon auf den nächsten Build 😀

Man kann alles packen/entpacken und hat eine chroot Umgebung. Was braucht man mehr, die einzige Beschränkung sind die eigenen Linux Kentnisse.

Dem stimme ich voll und ganz zu, wenn das oben funktioniert. Allerdings empfinde ich die einfache Installation der Design-Elemente in Reconstructor als echte Zeitersparnis. Aber im Grunde bin ich auch ein UCK-Fan, da man nur hier den nötigen Spielraum hat.

Vielleicht krieg ich das System ja doch noch auf CD-Größe. Allerdings werde ich wohl mit dem Build nochmal von vorne anfangen müssen, da UCK mein derzeitiges Image aus Reconstructor irgendwie nicht bearbeiten möchte, d. h. ich komme nicht bis zur Auswahl Synaptic → Chroot-Konsole 😢 (Hängt bei generating language de_AT) Gut das ich meine Schritte größtenteils sauber dokumentiert habe.

Ich werde Berichten, wenn ich das nächste Image fertig habe. Mit der derzeitigen Version bin ich soweit zufrieden. Besonders freut mich, dass die kompilier-installationsroutine für die 4-Port Karte von Sirrix hervorragend funktioniert hat. 3 Klicks und ein bisschen Wartezeit und der Treiber ist installiert und funktioniert. Schade dass checkinstall fehlgeschlagen ist, sonst gäbs das als deb-Paket dazu und die Installation dauerte nur Momente. Wenn der Zeitpunkt gekomen ist an dem ich die Distri öffentlich mache, dann gibts ja vielleicht den einen oder anderen, der mich dort unterstützen kann.

Vielen Dank für deine Anregungen!

André

Eine Frage noch:

Welche Meinung habt ihr zur Verwendung einer Desktop-Version als Server?

IMHO sollten sich doch hier keine Stolperfallen ergeben oder bringt der Server-Kernel so unermessliche Vorteile gegenüber dem generic-kernel?

Bin gespannt auf eure Antworten 😉

Also eine Desktop-Umgebung auf einem Server ist, denke ich nicht sehr willkommmen. Aber so wie ich das sehe, geht es dir primär um den Kernel.

Die genauen Unterschiede kann ich nicht nennen, mir fällt spontan ein, das mit dem Server Kernel die NVIDIA Treiber nicht funktionieren, das wäre aber schon alles.

Habe gerade mal ein wenig rumgespielt und versucht das ganze in einer Hardy-Desktop VM zu kompilieren. Mit den Asterisk Quellen aus den Repos scheint es allerdings nicht zu funktionieren.

1
2
3
4
5

/usr/include/asterisk/channel.h:926: Fehler: zu wenige Argumente für function »int ast_sendtext(ast_channel*, const char*, const char*, int)«
chan_sirrix.cpp:2101: Fehler: an dieser Stelle in der Datei
make[1]: *** [chan_sirrix.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/callbuntu/srx-pci/sirrix-pci/asterisk'
make: *** [asterisk] Fehler 2

Zu dem Fehler mal dieser Link.

EDIT/// Ich habe den Patch gefunden der die ast_sendtext Funktion ändert Link. Mal schauen, was man da drehen kann. Erstmal raus finden wofür der gut ist.

Mit den Originalquellen sollte man weiter kommen. (Bis zur nächsten Fehlermeldung? 😕 ) Werde das später nochmal testen.

liberavia schrieb:

3. Die Verwendung des Server Kernels ist im zusammenhang mit der Fritz-Card-PCI anscheinend problematisch. Nach der im Wiki beschriebenen Vorgehensweise bei der Installation der Karte, wird der Server-Kernel gegen den Kernel mit der Endung 386 ausgetauscht. Hierdurch wird dann auch nicht mehr der "gehärtete" Server-Kernel eingesetzt.

Magst du mir mal den Link zum dem genannten Wiki Artikel geben?

MfG

Zu deiner Kompilier-Fehlermeldung:

Die hatte ich auch mit dem Asterisk aus den quellen. Die Kompilation läuft durch, wenn du dir das Asterisk-Paket 1.4.17 besorgst und den include ordner auf der Platte gegen den aus dem Paket austauschst, bzw. nur die channel.h. Da hat sich anscheinend irgendwas eingeschlichen. Das Installieren und laden der Module klappt dann. Allerdings wird man, wie übrigens auch mit der Fritz-Card mit Fehlermeldungen zur Konvertierung überhäuft.

Die Fehlermeldung lautet dann in etwa "our native format changed from alaw to unknown" (Hab derzeit kein Hardy-Server am laufen, sondern verwende bereits callbuntu). Die Fehlermeldung kommt (hundertfach) sobald man den Hörer abhebt. Legt man auf, ist auch die Fehlermeldung weg.

Hier mein Link Zur Fritz-Karten-Installation: http://wiki.ubuntuusers.de/AVM_FRITZ!Card

Dabei ist noch zu beachten, dass es unter Hardy notwendig ist, sich noch ein AVM-Paket (Firmware tar.gz) zu besorgen und alle .ko Dateien per hand zum kernel zu kopieren. Macht man das nicht, so enthält das Kommando capiinfo keine sinnvollen Werte (Nur Nullen). Allerdings erhalte ich in Asterisk dann trotzdem oben genannte Meldung, die entsteht, sobald versucht wird ein Gespräch zu ISDN aufzubauen.

Hier sind wir übrigens bei dem Hauptgrund angekommen, warum ich hier gutsy einsetze, denn hier existieren diese Probleme nicht. Auch das kompilieren läuft mit dem asterisk-dev Paket einwandfrei durch und man kann anschließend auch zu isdn telefonieren.

Ich bin selber traurig nicht auf hardy setzen zu können, da der support für 7.10 ja im April ausläuft. Allerdings hoffe ich, dass sich bei Hardy noch was tut, so dass ich dann auf Hardy aufsetzen kann.

Nochmal zu X im Betrieb auf einem Server-System. Das lese ich häufig, dass man X besser nicht auf Servern verwenden sollte. Allerdings denke ich, dass das Sicherheitstechnische Gründe hat, die hier für ein Intranet-System eher am Rande zum Tragen kommen. Vielleicht lass ich X weg, wenn meine Webinterfaces einen ausreichenden Nutzwert für den Betrieb haben. Oder ich baue eine Option ein, mit welcher man den X-Server mit einen Schlag von der Platte bekommt. Webmin habe ich auf jeden Fall zur Distri vorinstalliert 😉

liberavia schrieb:

Zu deiner Kompilier-Fehlermeldung:

Die hatte ich auch mit dem Asterisk aus den quellen. Die Kompilation läuft durch, wenn du dir das Asterisk-Paket 1.4.17 besorgst und den include ordner auf der Platte gegen den aus dem Paket austauschst, bzw. nur die channel.h. Da hat sich anscheinend irgendwas eingeschlichen. Das Installieren und laden der Module klappt dann. Allerdings wird man, wie übrigens auch mit der Fritz-Card mit Fehlermeldungen zur Konvertierung überhäuft.

Ich kann dir jetzt genau sagen, was sich da "eingeschlichen" hat 😉

Irgendwann zwischen Gusty und Hardy ist die Hardwareunterstützung für HFC-S/HFC-4S-based ISDN BRI cards (Junghanns.NET, beroNet, Digium etc.) hinzugekommen. Diese Patches ändern die API, wodurch Patches, welche die original API benötigen nicht mehr funktionieren. Das ganze ist in die Debian Pakete eingeflossen und von dort aus zu Ubuntu, an diesem Umstand wird sich wohl auch in nächster Zeit nicht viel ändern. Ich weiss nicht, ob es so gut ist einfach die channel.h gegen eine Originalversion zu tauschen, da Asterisk mit der gepatchten kompiliert wurde. Ich habe eben mal komplett auf die Ubuntu Pakete verzichtet und Asterix von Hand kompiliert und installiert. Das anschliessende kompilieren der Sirrix Treiber verlief ohne Probleme. Das austauschen der channel.h erübrigte sich.

Um das ganze zu Lösen, müsste man aus den aktuellen Paketen die Patches für die BRI cards entfernen, oder dem Sirrix Patch beibringen, mit der neuen API klar zu kommen. Letzteres wäre die elegantere Lösung, da man dadurch auf nichts verzichten müsste und die Ubuntu Pakete in ruhe lässt.

Die Fehlermeldung lautet dann in etwa "our native format changed from alaw to unknown" (Hab derzeit kein Hardy-Server am laufen, sondern verwende bereits callbuntu). Die Fehlermeldung kommt (hundertfach) sobald man den Hörer abhebt. Legt man auf, ist auch die Fehlermeldung weg.

Hier mein Link Zur Fritz-Karten-Installation: http://wiki.ubuntuusers.de/AVM_FRITZ!Card

Dabei ist noch zu beachten, dass es unter Hardy notwendig ist, sich noch ein AVM-Paket (Firmware tar.gz) zu besorgen und alle .ko Dateien per hand zum kernel zu kopieren. Macht man das nicht, so enthält das Kommando capiinfo keine sinnvollen Werte (Nur Nullen). Allerdings erhalte ich in Asterisk dann trotzdem oben genannte Meldung, die entsteht, sobald versucht wird ein Gespräch zu ISDN aufzubauen.

Hier sind wir übrigens bei dem Hauptgrund angekommen, warum ich hier gutsy einsetze, denn hier existieren diese Probleme nicht. Auch das kompilieren läuft mit dem asterisk-dev Paket einwandfrei durch und man kann anschließend auch zu isdn telefonieren.

Ich bin selber traurig nicht auf hardy setzen zu können, da der support für 7.10 ja im April ausläuft. Allerdings hoffe ich, dass sich bei Hardy noch was tut, so dass ich dann auf Hardy aufsetzen kann.

Wie schon oben gesagt, wird sich da wohl nicht viel tun, die Treiberunterstützung für die BRI Hardware ist jetzt mit drin und ich denke nicht, das die wieder rausgenommen wird. Für Leute die diese Hardware nutzen ja auch eine tolle Sache. Entweder man baut sich einfach eigene Pakete, damit wäre dem ganzen Spuk ein ende bereitet, oder versucht das ganze wieder kompatibel zu machen.

Nochmal zu X im Betrieb auf einem Server-System. Das lese ich häufig, dass man X besser nicht auf Servern verwenden sollte. Allerdings denke ich, dass das Sicherheitstechnische Gründe hat, die hier für ein Intranet-System eher am Rande zum Tragen kommen. Vielleicht lass ich X weg, wenn meine Webinterfaces einen ausreichenden Nutzwert für den Betrieb haben. Oder ich baue eine Option ein, mit welcher man den X-Server mit einen Schlag von der Platte bekommt. Webmin habe ich auf jeden Fall zur Distri vorinstalliert 😉

Sicherheit und Performance. Da du ja auf ein Webinterface setzt ist ein X-Server nicht wirklich erforderlich. Wenn du am Ende für die Weboberfläche ein Paket erstellst, kann man das auf der Serverversion oder auf dem Desktop installieren... das spielt dann ja keine Rolle.

MfG

Denga schrieb:

Irgendwann zwischen Gusty und Hardy ist die Hardwareunterstützung für HFC-S/HFC-4S-based ISDN BRI cards (Junghanns.NET, beroNet, Digium etc.) hinzugekommen

Jetzt weiß ich zumindest warum in gutsy ein extra misdn-paket existiert und in hardy nicht 😉

Ich denke, ich werde erstmal bei gutsy mit der Version 1.4.10 aus den Quellen bleiben. Der Asterisk in dieser Version erfüllt alle meine geforderten Leistungsmerkmale.

Vielleicht werde ich einen paralellen Build mit hardy starten mit einem Kompilierten Asterisk, allerdings hatte ich auch in einem kompilierten Asterisk auf hardy die genannte Meldung "our native format changed from alaw to unknown" :roll

Ich will da lieber erstmal kein Risiko eingehen und wenn, dann wie gesagt in einem paralellen Build, wobei ich aktuell wohl nicht die Zeit dazu finden werde.

Baue gerade für die Webgui ein Callcenter-Wallboard auf Web-Basis und das klappt derzeit ganz gut. Auch für die Webgui gilt: Wenn der entsprechende Status erreicht ist, gibts eine öffentliche Subversion-Verbindung, außer meine Firma hat nicht genug Ubuntu 😉

Ich hab mir die Änderungen genauer angeschaut und einen Patch gemacht. Ich kann jetzt zum kompilieren das asterisk-dev Paket aus den Repos nutzen ohne das eine Fehlermeldung kommt. Würde mich freuen, wenn du das mal ausprobieren könntest. Habe hier nicht die nötige Hardware um das zu Testen.

1
2
3
4
5
6

tar xvfz sirrix-pci-release-xxxxxx.tgz
cd sirrix-pci
patch -Np1 -i /patch/zu/sirrix-pci-bristuff.patch
./configure
make
make install

MfG

OK, werd am Montag auf Arbeit noch eine FP mit Hardy aufsetzten und deinen Patch ausprobieren. Sollte das funktionieren, werd ich den Patch in mein Install-Script einbauen. Allerdings wollte ich am vormittag erstmal die Änderungen vom Freitag in mein Repository überführen (Hab nicht den checkout-code verwendet und muss per methode Zettel/Hand die neuen Daten einpflegen). Ich denke mal, dass ich dann so um 11 mit der Hardy-Installation beginne.

Danke, dass du dir die Mühe gemacht hast, denn mit perl bin ich bisher eher nur am Rande in Berührung gekommen, ich verwende eher Python.

Gruß

André

Im Prinzip wäre ja eine Server-Variante ja eh am besten.

Was sagst du eigentlich zur Installationsanleitung der Fritz-Card?

1. Mit dem Server 8.04 hatte ich damals die genannte Anleitung befolgt. Leider weiß ich nicht mehr warum ich den kernel 386 einsetzen musste. Die Linux-Headers sind ja auch für den Server-Kernel vorhanden. Ich denke, da war irgendeine Abhängigkeit, welche den kernel 386 aufspielt. Möglicherweise habe ich mich aber auch zu blöde angestellt. Ich denke ich sollte das mal inner VM ausprobieren...

2. Um mit capiinfo dann überhaupt sinnvolle Werte zu erhalten, bin ich nach den Empfehlungen von Vollkorn im Link unten vorgeganen und hatte dann meine sinnvollen Werte. Allerdings spuckt der Asterisk dann eben meine "Lieblingsmeldung" von oben aus solange die Verbindung läuft. U. u. stürzte Asterisk sogar komplett ab ☹

http://forum.ubuntuusers.de/topic/hardy-capi-%2B-fcpci-:-incoming-call-on-not-exi/?highlight=avm+fritz+pci+hardy#post-1407671

Ich habe am Wochenende mal versucht den Treiber für die Fritzcard zu kompilieren. Als erstes viel mir auf, das ich auch unter Hardy nicht ohne einige Patches weiterkam. Diese waren jedoch gleich dabei, also war das kein Problem. Ich hab mir über den Link im Wiki die src.rpm geholt, alles entpackt, patches angewendet und konnte zum Schluss alles kompilieren. Ob das jetzt so funktioniert kann ich noch nicht sagen, da mir eine isdn Karte fehlte. Habe gerade in meiner alten Rumpelkiste eine AVM-Fritzcard ausgegraben und werde das noch genauer testen. Wollte schon immer einen Anrufbeantworter haben 😉

Hab mir den von dir genannten Thread mal angeschaut, ob ich noch was extra kopieren muss weiss ich nicht, habe das make install, wegen fehlender Hardware weggelassen. Probiere ich aber noch aus.

Das das Ganze nur mit dem 386-generic Kernel funktioniert, kann ich mir nicht vorstellen, das wird ein Bedienungsfehler sein. Bei dem Sirrix Treiber kann man die Kernelversion zB. mit make KVER=‘uname -r‘ angeben, frag aber nicht, wie lange ich gebraucht habe das herauszufinden. Denke bei den capi Treibern ist ähnliches möglich.

Ich kompiliere und teste das ganze hier auch in einer VM, so kann man mit Hilfe von Sicherungspunkten schnell einen alten Zustand zurückholen.

PS: Baust du Weboberfläche auch mit Python?

MfG

Nur kurz: Bin grad im Stress:

Dein patch funktioniert einwandfrei, später mehr 😉

PS: Baust du Weboberfläche auch mit Python?

Nein, da nehme ich lieber PHP, weil mehr Erfahrung damit. Python habe ich erst vor kurzem entdeckt.

Bis Später

André

liberavia schrieb:

Dein patch funktioniert einwandfrei, später mehr 😉

Das freut mich sehr.

Nein, da nehme ich lieber PHP, weil mehr Erfahrung damit. Python habe ich erst vor kurzem entdeckt.

Geht mir ebenso, war jedoch Liebe auf den ersten Blick.

Ich schau mal das ich die isdn-Karte in meinen Rechner bekomme und berichte dann.

MfG

Ich schau mal das ich die isdn-Karte in meinen Rechner bekomme und berichte dann.

Also die Fritz PCI hab ich heut schon mal eingebaut. Aber doppelt testen hält eh besser 😉

Durchgeführt habe ich das mit der Sirrix auf Ubuntu-Server 8.04.1. Ich werde deinen patch in meinem Install-Script verarbeiten. Wie ich nämlich fesstellen musste, war ich so "schlau" im (von Sirrix geforderten) Lizenzaufruf gdialog anstatt dialog zu verwenden. Um zu erreichen, dass der User zuerst der Lizenz zustimmen muss, habe ich das Paket von Sirrix zwar bereits auf die Distri gepackt, aber gnupg verschlüsselt. Nur das dafür kompilierte C-Programm kann diese Datei entschlüsseln, wenn der Lizenz zugestimmt wurde. Sprich: Ich schnür das Paket eh wieder auf. Eine gute Gelegenheit deinen patch einzubauen 😉

Nochmal zur Fritz:

Wenn du die Installation per kompilieren ausprobierst, sollte ich vielleicht nochmal die Variante über die o.g. Anleitung testen. Vielleicht hatte die Fritz-Card einfach ein ähnliches Problem mit der ungepatchten Funktion. Schließlich handelte es sich auch hier um dieselben channel-Fehlermeldungen. Was meinst du?

Zu einer vernünftigen Meldung von capiinfo hab ichs damit ja immerhin geschafft. Nur Asterisk wollte nicht mitspielen. Sollte sich das als wahr herausstellen, ist auch hier ein Script fällig, was dann auch den letzten trunk von chan_capi integriert (bessere capicommand-Unterstützung → halten und vermitteln)

Hab als weitere Karten noch eine Eicon Diva und eine Longshine mit Cologne-Chipsatz zum Testen.

Wär echt super, wenn alles in der Server-Variante von 8.04 läuft, dann gibts keine Kompromisse mehr!

Geht mir ebenso, war jedoch Liebe auf den ersten Blick.

Für mich ist Python ist die erste wirklich universell einsetzbare Scriptsprache. Daher: Dito 😉

Bis denne

André