GNU Screen und der Scrollback Buffer

GNU Screen ist ein Terminal Multiplexer, welcher einem über in der Manpage dokumentierte Tastenkombinationen die komfortable Steuerung mehrerer Terminal-Sitzungen über nur eine "echte" Konsole ermöglicht. Dieses kann man sich vorstellen wie "Tabs", welche man heutzutage von allen Internet Browsern her kennt. Ein weiterer Vorteil ist, das man so einen Container einfach mitsamt den darin laufenden Sitzungen in den Hintergrund schicken kann und die darin enthaltenen Sitzungen weiterhin ausgeführt werden. Dieses gilt auch für "unfreiwilliges" schließen der Verbindung; beispielsweise wenn die Internetverbindung abbricht, der Computer abstürzt, etc.

Ich suche mir jedes Mal die folgende Information neu aus dem Internet heraus, daher notiere ich sie mir einmal, leicht auffindbar, hier.

Man kann in Screen auch in jeder einzelnen Sitzung scrollen. Jedoch sind die Zeilen, die Screen dabei speichert, von Haus aus auf recht wenige eingestellt: 100 Zeilen; das ist, bei heutigen Auflösungen der meisten Konsolen, gerade mal etwas mehr als ein Bildschirm. Für mich ist das viel zu wenig! Daher erhöhe ich das meistens per Default auf 5000. Das kann, je nach Einsatzgebiet auch zu viel sein; wenn jemand nun 200 Konsolen darin startet und in jeder ein Logfile mit "tail -f" durchlaufen lässt, kann hierbei schonmal recht viel Arbeitsspeicher für belegt werden. Daher: Bitte diese Einstellung nicht ungeprüft übernehmen.

Es gibt zwei Konfigurationsdateien für GNU Screen:

  1. Globale Konfigurationsdatei : /etc/screenrc
  2. Userbezogene Konfigurationsdatei : \~/.screenrc

Beide verwenden soweit dieselbe Syntax; Details sind der Manpage zu Screen zu entnehmen.

Nun aber zum Kern des Artikels:

Man füge folgende Einstellung hinzu:

defscrollback 5000

Fertig :)

Teilen per: TwitterEmail


Konvertieren von SVN, CVS oder Git Repositories zu Mercurial

Diese Mini-Anleitung ist nur etwas für Leute, denen die Überschrift etwas sagt. Für alle anderen: Geduldet Euch; ich werde in nächster Zeit voraussichtlich einen umfassenderen Artikel zu Mercurial und (D)VCS im allgemeinen verfassen.

Also, zunächst einmal: Mercurial bringt bereits ein Kommando mit, um von einem SVN (Subversion), CVS oder Git Repository alle Daten, inklusive der kompletten Historie, in ein Mercurial Repository konvertieren zu können. Der Befehl heißt schlicht "convert", ist jedoch standardmäßig deaktiviert und steht als Extension zur Verfügung. BTW: Eine Übersicht über (de-)aktivierte Extensions bekommt ihr, wenn Ihr einfach folgende Hilfe aufruft:

hg help extensions

In dieser Ausgabe wird an sich das folgende auch bereits erklärt. Zudem ist hier die Zeile zu "convert" interessant:

convert  Importiert Änderungssätze von anderen Versionsverwaltungssystemen nach Mercurial

Genau was wir wollen also!
Man aktiviert diese Extension, indem man in "seiner" (\~/.hgrc) oder der globalen Mercurial Konfigurationsdatei folgende Zeilen einträgt:

[extensions]
convert =

Kein Fehler: Da kommt in der Tat nichts hinter das "=".

Nun kann man beliebig viele Repositories ganz einfach konvertieren, indem man die HTTP-URL eingibt, oder das lokale Quell- und Zielverzeichnis. Letzteres folgt als Beispiel:

#> hg convert python_spielwiese ../../hg/repos/python_spielwiese
Initialisiere Ziel-Projektarchiv ../../hg/repos/python_spielwiese
Durchsuche Quelle...
Sortiere...
Konvertiere...
1 Initial Import
0 Initial PyDev Checkout

Wie man sieht, übernimmt das Programm die komplette commit-History; in diesem Fall nur 2.
Easy Peasy :)

Teilen per: TwitterEmail


Der langweiligeste Ort im Universum und Multithreaded bzip2/gzip

So wurde mein Blog letztens von einem guten Kumpel bezeichnet - und recht hat der Sack auch noch ;)
Ich gelobe (wie immer ;D ) Besserung und fange mal mit einem technischen Artikel an. Diese kommen hier in letzter Zeit viel zu kurz und ich neige immer mehr dazu, alles im Kopf haben zu wollen, da ich mir die Zeit zum aufschreiben einfach nicht nehme. Stattdessen landet hier nur so ein privat-Blödsinn ... Ich erkläre hiermit das Ziel, diesem Blog wieder einen Schwerpunkt auf die IT und technische Hintergründe zu legen - bin selbst gespannt ... ;)

Beginnen möchte ich mit einem super geilen Tipp.

Ich verwende, wie wohl die meisten Linuxer auf der Welt auch, seit Jahr und Tag GNU bzip2 und GNU gzip zur Kompression von Daten auf der Shell. Was mir jedoch heute das erste Mal aufgefallen ist, ist das diese beiden Programme nur einen einzigen Core aktueller Multi-Core CPUs zu 100% auslasten, und die restlichen brach liegen. Gerade bei der Kompression von Daten dreht sich alles um die Leistungsfähigkeit des Prozessors - eine der wenigen Ausnahmen in meinem Arbeitsalltag, wo die Festplatten mal nicht der Flaschenhals sind. Von daher ist diese Verschwendung in der heutigen Okta-Core - Zeit schon ziemlich maßgeblich für manche Vorgänge, wie z.B. beim (De-)Komprimieren von MySQL Dumps, ISO Images von DVDs, Logfilerotation, etc.

Ich habe also etwas recherchiert und bin zunächst auf pbzip2 gestoßen; einem Re-Write des GNU bzip2 Programmes, welches Multicores unterstützt.
Hiermit hatte ich aber zunächst nur eine Lösung für bzip2, also suchte ich weiter.

Schließlich stieß ich auf einen guten, alten Bekannten, den in seiner GUI - Form sicherlich auch Nicht-Linuxer kennen: 7zip ! Kurzbeschreibung: 7zip ist ein freies Programm (GNU LGPL) für nahezu alle gängigen Betriebssysteme, welches sowohl nahezu alle gängigen Archivformate und Kompressionsalgorithmen beherrscht, sowie auch ein eigenes Format mitsamt Algorithmus mit sich bringt, welches in vielen Situationen sogar eine höhere Kompressionsrate erreicht als bzip2 (durchschnittlich etwa 50-70% höher als ZIP!).
Dieses beherrscht nicht nur die Archivformate 7z, zip, gzip, bzip2, tar und rar (beim reinen entpacken unterstützt es zudem sogar noch: ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT, HFS, ISO, LZH, LZMA, MBR, MSI, NSIS, NTFS, RAR, RPM, SquashFS, UDF, VHD, WIM, XAR und Z) , sondern auch Multi-Threading und ist somit die perfekte Lösung für Multicores. Es liegt beispielsweise im Ubuntu Lucid Lynx (10.04) Repository unter den Namen "p7zip", "p7zip-full" und "p7zip-rar" vor und kann somit ganz normal und einfach installiert werden.

Ich habe damit heute mal einen schnellen Test gemacht. Diese zahlen stammen von einem Quad-Core System, auf welchem neben diesen Tests auch meine ganz normale Arbeitsumgebung ausgeführt wird, also bitte dizzed mich nicht wegen "lamer"Ergebnisse ;)

Testbeschreibung

Ich habe das ISO Image kubuntu-9.10-alternate-i386.iso von einem Kubuntu - Mirror herunter geladen. Dieses werde ich mit dem bzip2 Algorithmus zunächst mit GNU bzip2 und 7zip auf höchster Kompressionsstufe (9) komprimieren. Diesen Prozess messe ich mit dem Linux-Tool "time". Anschließend entpacke ich beide Varianten mit GNU bzip2 und erzeuge für die Ergebnisse einen MD5 Hash, um die Kompatibilität mit der Refferenzimplementation sicher zu stellen.

Test mit GNU bzip2

root@archangel:~# time bzip2 ~mr/Downloads/ISO_Images/kubuntu-9.10-alternate-i386.iso -c -9 > bzip2.bz2

real    2m41.266s
user    2m29.250s
sys     0m1.400s

Test mit 7zip

root@archangel:~# time 7z a -tbzip2 -o. bzip2_7z.bz2 ~mr/Downloads/ISO_Images/kubuntu-9.10-alternate-i386.iso

7-Zip 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=de_DE.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Scanning

Creating archive bzip2_7z.bz2

Compressing  kubuntu-9.10-alternate-i386.iso

Everything is Ok

real    1m17.121s
user    4m6.090s
sys     0m1.420s

Auswertung

Ich habe dabei mit "htop -d 1" die CPU Auslastung beobachtet: Bei GNU bzip2 wurde erwartungsgemäß nur einer der 4 Cores zu 100% ausgelastet. Mit 7zip tatsächlich alle 4!

Das Ergebnis dieser Kompressionen war nahezu identisch. Nur ca 2 kb (bei einer Eingangsgröße von rund 700 MB) Abweichung war feststellbar, was ich für vernachlässigbar halte. Die MD5 Sums der mit GNU bzip2 entpackten Archive war identisch; die GNU bzip2 Kompatibilität des durch 7zip erzeugten Archives ist also gegeben.

Wie die obigen Zahlen zeigen, war 7zip ziemlich genau doppelt so schnell, wie die GNU bzip2 Refferenzimplementation. Ich hätte zwar mehr erwartet, jedoch wird ziemlich viel für die Threadverwaltung aufgewendet werden müsen.

Dasselbe lässt sich nun natürlich auch mit GNU gzip erreichen - Zahlen spare ich mir mal. Das kann jeder selbst mal messen :)

Teilen per: TwitterEmail


Postgres Datenbankbackups per Script erstellen

Ich habe damals, als ich noch 0 Ahnung von Datenbanken hatte, mit PostgreSQL angefangen. Ich dachte in der Tat, das MySQL ja eine kommerzielle Anwendung ist und es ja daher jederzeit vorbei sein kann mit der freien Verfügbarkeit. Da ich eh keine Ahnung hatte, und PostgreSQL im Community - Mund sehr viel mehr können sollte als MySQL, hatte ich mich dafür entschieden.

Inzwischen kenne ich mich wenigstens etwas mit MySQL und dessen Administration aus und habe das zu meiner Standard-Datenbank gemacht. Von PostgreSQL komme ich wegen eines phpBB2 - Forums aber nicht mehr los - also habe ich mich auf die Suche nach einer Möglickeit gemacht, auch PostgreSQL Datenbanken automatisiert per Script Backupen zu können. Standardmäßig hat das Kommandozeilenprogramm "pg_dump" keinen Parameter für das Passwort wie "mysql" und "mysqldump".

Es gibt dennoch einen ähnlich unsicheren Trick, wie man das ganze auf der Shell automatisieren kann: Die Umgebungsvariablen "PGUSER" und "PGPASSWORD". Über die beiden folgenden Methoden kann damit die Authentifikation an der Postgres Datenbank durchgeführt werden:

export PGUSER="postgres_user"
export PGPASSWORD="Passwort"
pg_dump -f /DB.pgsqldump -F c -C -D -h localhost DB

oder alles in einer Zeile:

PGUSER="postgres_user" PGPASSWORD="Passwort" pg_dump -f /DB.pgsqldump -F c -C -D -h localhost DB

Ich denke ich muss nicht erwähnen das dieses sehr unsicher ist. Während die Variablen gesetzt sind kann sie theoretisch fast jeder auf dem System auslesen. Daher sollte als Mindestsicherheitsmaßnahme unmittelbar nach dem dumpen der Inhalt der Variablen durch "unset PGUSER ; unset PGPASSWORD" wieder gelöscht werden. Aber es ist immerhin eine Möglickeit :)

Teilen per: TwitterEmail


Wenn der couriertcpd "malloc: Input/output error" meldet

Hab heute mal wieder eines dieser zunächst unerklärlichen Probleme gehabt:

  • Der courier-authdaemond und der courier-imapd laufen seit JAHREN unverändert problemfrei.
  • Ich habe nichts geändert.
  • Trotzdem bekomme ich im mail.info - Log diese Zeile:
    "couriertcpd: malloc: Input/output error"

Ich habe die Configs überprüft, Rechte im Dateisystem, alles. Nichts gefunden.

Schließlich bin ich im Archiv der courier-users Mailingliste auf die Lösung gestoßen:
Der Courier IMAPd arbeitet Standardmäßig mit dem FAM (File Alteration Monitor) zusammen. Scheinbar kommt der hin und wieder mal ins Straucheln und sollte in diesem Fall, zusammen mit dem portmap Daemon, neu gestartet werden.

Jean-Marc Liotier, der diesen Fehler auf der Mailingliste gepostet hatte, und auch mein Problem ließen sich jedenfalls so beheben.

Schon fies der Fehler, da im Log ja nur der couriertcpd auftaucht, woraufhin man ja zunächst mal geneigt ist hier nach dem Fehler zu suchen ...

Teilen per: TwitterEmail


"Installed (but unpackaged) file(s) found" bei RPM Systemen

Und wieder etwas gelernt:

Ich habe versucht ein Source RPM auf einem unserer Server zu installieren. Dieses scheiterte mit folgender Meldung:

error: Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Inzwischen habe ich herausgefunden, das dieses ein Sicherheitsmechanismus ist, damit Dateien, die in einem Verzeichnis liegen, in die Dateien gleichen Namens aus dem RPM Paket installiert werden würden, nicht überschrieben werden.
Normalerweise lassen sich bei der Installation eines RPM Paketes Dateien ja zuvor installierten Paketen zuordnen. Installiert man jedoch nun etwas per Hand aus dem Sourcecode, ist es dem RPM System ja nicht möglich, diese Dateien einem Programm zuzuordnen. Daher bricht es lieber ab.

Hat man nun festgestellt, das die angemerkten Dateien überschrieben werden können, fügt man den kompletten Pfad mit den Dateinamen der Programmname.spec - Datei hinzu.
.spec Dateien sind eine Art Bauanleitung, um Sourcecode zu RPM Paketen zu verpacken.
Nachdem die Installation bereits einmal mit der obigen Fehlermeldung fehlgeschlagen ist, befindet sich unter /usr/src/packages/ das entpackte RPM Paket. Unter SPEC steht die .spec Datei, unter BUILD die Sourcen, etc.

Beim obigen Beispiel editieren wir also die Datei /usr/src/packages/SPECS/db3-cxx.spec .
Hier suchen wir nach einem Abschnitt, der %files heisst. Darunter fügen wir die angemeckerten Dateien ein, also:

Vorher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so

Nachher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Nun können wir das ganze nicht einfach erneut über das Source-RPM installieren, da unsere Änderungen sonst direkt wieder überschrieben würden.
Stattdessen wechseln wir in das Verzeichnis /usr/src/packages und führen folgenden Befehl aus:

rpmbuild -ba SPECS/db3-cxx.spec

ACHTUNG:

bei manchen RPM basierenden Distributionen/-versionen gibt es das rpmbuild Programm nicht. Früher wurde der obige Befehl über rpm aufgerufen. Probiert in diesem Fall also:

rpm -ba SPECS/db3-cxx.spec

Hierdurch wird das RPM Binär- und Quellpaket neu gebaut.
Diese Pakete liegen dann in den Unterverzeichnissen SRPMS und RPMS/architektur/ von /usr/src/packages .

Diese können nun Problemlos, wie ein offizielles RPM Paket, installiert werden:

rpm -Uvh /usr/src/packages/RPMS/i586/db3-cxx*.rpm

Teilen per: TwitterEmail



Modding der Fritzbox - Teil 1

Wie im Bericht zuvor angekündigt, werde ich diese neue Serie starten, die eine Art Logbuch zu meinen Erfahrungen beim Modden meiner Fritz Box Fon WLAN 7050 werden soll.

Jeden kleinen Erfolg, Misserfolg und neue Idee möchte ich hier gerne verewigen, um mir eine Referenz zu bieten, und anderen ein leicht verständliches Handbuch.

Was habe ich bisher gemacht?

Ich habe recherchiert.

Dabei bin ich auf diese, bisher hilfreichste Quelle, gestossen. Die Seite ist unheimlich schlecht geschrieben. Sehr amateurhaft und ich denke, das die wenigsten Autoren volljährig sind.

Egal - ich bin auch nicht unbedingt besser!

Was konnte ich hieraus lernen?:

Meine Fritz Box ist eine kleine Zicke ;) Man kriegt den telnet Server nicht wie bei den anderen per Telefoncode gestartet. Offenbar ist da erst garkein Daemon drin! Dieser wird beim hochladen einer Modifizierten Firmware nachinstalliert.

Zunächst einmal stellt man sicher, das man im Besitz des Webpasswortes der Box ist. Hierzu meldet man sich am besten direkt einmal an. Im lokalen Netzwerk gibt man einfach "fritz.box", oder die richtige IP der Box in das Adressfeld des Web-Browsers ein und meldet sich an.

Nun sollte sicherheitshalber ein Firmwareupdate der Box vorgenommen werden. Die folgenden Schritte setzen vorraus, das man im Fritz Box Webinterface die "Einstellungen - System - Ansicht - Expertenansicht aktivieren" - Option aktiviert hat.

Ist das der Fall, klickt man sich über "Einstellungen - System - Firmware-Update" zum Dialog "Automatisches Update". Hier hat man nicht viele Möglichkeiten: klickt auf "Neue Firmware suchen".

Wird eine gefunde, lasst sie installieren und startet die Box neu. Ihr werden durch alle notwendigen Schritte geleitet.

Nachdem nun alles auf dem neuesten Stand ist (dieses Logbuch basiert auf Firmware Version 14.04.33), geht es nun darum, einen telnet-Server auf das Ding zu kriegen.

Am besten, ihr ladet euch schonmal den Putty runter! (Bei Linux Usern unterstelle ich generell Kenntniss wie sie telnet und/oder SSH Sessions öffnen).

Nun versucht mal euch auf eure Fritz Box IP per Telnet zu verbinden - Es wird nicht klappen.

Dieses dient dem Vorher/Nachher - Vergleich :)

Nun ladet euch diese Datei herunter und speichert sie dort, wo ihr sie gut wieder findet (z.B. Desktop).

Hangelt euch nun im Fritz Box Webinterface wieder zu diesem Pfad: "Einstellungen - System - Firmware-Update", wählt aber dieses Mal "Firmware-Datei". Wählt das eben herunter geladene Script aus und klickt auf "Update starten".

Es folgt ein Hinweis, das es sich dabei um keine gültige Firmaware Datei handelt und das das System dabei ohne Garantieansprüche zerstört werden kann.

Nun, so ist das nunmal beim basteln ;)

Aber ich habe diesen Schritt gewagt und hatte keine Probleme. Achja: Ich hafte selbstverständlich auch für nichts!

Ausserdem werdet Ihr fortan mit folgendem Hinweis in eurem Web-Interface leben müssen:

Screenshot der Warnung nach
Update

Nachdem das blinken der LED aufgehört hat, probiert es nochmal mit dem Putty euch per telnet auf die Box zu schalten.

Nun werdet Ihr nach einem Passwort gefragt. Dieses ist dasselbe wie im Web Interface.

Gut, gut - nun will ich aber nicht, das die ganze Pracht nach dem nächsten Stromausfall wieder weg ist - was nun?

Also in den einschlägigen Foren stand, das man ein paar Moves machen muss, damit der Daemon beim nächsten Start wieder hochkommt.

Ich habe mir das Script /var/flash/debug.cfg im Dateisystem der Fritz Box mal angesehen. Für mein Verständniss sieht es es aus, als sei es bereits so, das es immer startet.

Einziges Problem wäre, wenn /var/flash ein flüchtiger Speicher wäre, dessen Inhalt einen Neustart nicht überlebt. Naja, da ich bereits einmal den Strom gezogen habe seitdem, denke ich das es kein flüchtiger Soeicher ist ;)

Ich muss mir das Script im "Image" mal ansehen. Was es genau tut. Ich habe was gelesen von, das es ein telnet Daemon Programm aus dem Internet herunterläd und dann installiert und startet.

Wenn dem so ist, würde ich das lieber gleich mit in das Pseudo Image legen, oder zumindest irgendwo, wo ich weiss das nichts mehr verändert wird.

Zwar scheint alles ganz gut zu funktionieren, ich möchte aber vermeiden, das die Seite von der der Daemon herunter geladen wird irgendwann nicht mehr erreichbar ist, oder, das (wie evtl. in diesem Fall geschehen, da auf einmal keine Vorkehrungen für ein automatisches starten mehr vorgenommen müssen) sich der Download-Teil irgendwann ändert, ohne das man es merkt und versäumt Dokus anzupassen oder ähnliches.

PS: HA! Ich habe einen Artikel gefunden, der teilweise Licht ins Dunkel von /var/flash bringt:

Wechseln Sie mit cd /var/flash zunächst das Verzeichnis. Hier finden Sie alle Konfigurationsdateien der Fritz!Box, die ihren Inhalt auch nach einem Reboot behalten. Mit dem Befehl echo "/usr/sbin/telnetd -l /sbin/ar7login" > /var/flash/debug.cfg schreiben Sie den Start des telnet-Daemons in die debug.cfg und binden ihn so fest in den Bootvorgang der Fritz!Box ein. Kontrollieren Sie den Eintrag mit einem cat debug.cfg . Dann können Sie die Fritz!Box mit /sbin/reboot neu starten, und der telnet-Login sollte anschließend immer noch möglich sein.

Teilen per: TwitterEmail


Ich werd' ISP!

Genau, denn wenn man sich sein eigenes Internet baut, dann muss man nicht immer die Seiten gucken die Arcor einem gibt!

... naja etwas mehr niveau hat dieser Artikel dann doch ;)

Ich bin Congstar Kunde und damit soweit auch ganz zufrieden. Ich wollte keine Verträge mehr, wo ich zum Dank blöd genug gewesen zu sein, mich wieder 2 Jahre an einen gleichbleibendem Tarif auf einem Markt sinkender Kosten gebunden zu haben, für ein Telefon zweiter Wahl entscheiden darf, das dann "nur noch" 10 € (plus die Reingewinne der Grundgebühr über 24 Monate hinweg kostet). Daher bin ich zu Congstar gewechselt.

Ich weiss: Die haben NICHTS, sind nicht die billigsten, bieten keine gescheiten Handys, und, und, und.

Aber für mich ist es ideal.

Ich habe für 10 € meine Festnetzflat, kann je nach Lebenssituation Optionen hinzubuchen oder kündigen, und - mal ehrlich: Wie oft habt ihr während einem Eurer Verträge mal mit dem Support telefoniert und wart mit deren Aussagen zufrieden?

Was schert's mich, da da die T-Mobile Ausschussware der Callagents sitzt für die 15 Minuten, die ich durchschnittlich im Jahr mit denen telefoniere?

Nun bin ich jedoch schon an die Grenzen des Congstar Angebotes gestoßen: KEINE DATENFLAT !!! *kreiiiiisch!!*

Was mache ich da nur?

Meine Idee©:

Ich modde meine Fritz Box Fon WLAN 7050 zum DialIn-Server um! Wie früher, wo man ein Modem hatte, ca. 50 km Kabel aus selbst zusammengelöteten Kabelteilenin der Telefondose verschwinden liess, Username, Passwort und Telefonnummer des Providers brauchte und sich dumm und dusselig bezahlt hat an Minutenpreisen.

Nur mit dem Unterschied, das ich dank der DSL Flatrate zuhause, damit verbundener ISDN Leitung bei Arcor und modding-fähiger Fritz Box und einer Festnetzflat im Handy keinen Cent dazu bezahlen werde! :)

Die Theorie ist so:

Ich richte mir im Handy eine Modemverbindung ein. Diese ruft auf einer meiner ISDN Nummern zuhause an. Nun soll die Fritz Box Anrufe auf dieser Nummer entgegen nehmen und Username/Passwort Authentifizierung betreiben. Stimmen die Daten, soll sie zwischen der Analogleitung zwischen angerufenem Anschluss und anrufendem Handy und der DSL Leitung routen.

Theoretisch dürfte das ganze so kostenfrei für mich bleiben :)

Ich habe mich mit so einer Technik nie beschäftigt. Ich weiss nichtmal, ob es dafür gescheite Software gibt, die man realistisch auf der Fritz Box laufen lassen kann.

Dieses kleine Erfahrungslogbuch wird's zeigen :D

Teilen per: TwitterEmail