SQLite ist eine hübsche kleine Datenbank mit vielen Möglichkeiten. Allerdings kennt sie keinen Client/Server Betrieb, so dass man nur lokal direkt auf die Daten zugreifen kann. Ich habe aktuell die Herausforderung, dass ich auf eine SQLite Datenbank über das Netz zugreifen muss, da ich mit den Daten quasi in Echtzeit auf einem anderen Rechner weiterverarbeite.
Konkret geht es um eine SQLite Datenbank auf einer Asterisk Telefonanlage, in der ich die Call Detail Records (CDR) abgreifern kann. Leider ist der Asterisk geschlossen und Module, die es mir leichter machen würden, die Daten gleich in eine externe Datenbank zu schreiben sind nicht vorhanden. Also brauche ich wohl oder übel die Trickkiste.
An welche Möglichkeiten habe ich schon gedacht?
- SQLite Datenbank (ca. 2MB) regelmäßig per rsync kopieren. Ist dann eben nicht in Echtzeit.
- Abfrage der Daten via ssh und sqlite Client auf der Telefonanlage. Ich bekomme dann aber nicht das benötigte Format oder ich bekomme zu viele Daten (Dump der kompletten DB) und es ist nicht in Echtzeit.
- Via sshfs das Verzeichnis auf dem externen Host einmounten und direkt auf die Datenbank zugreifen. Funktioniert sehr gut, bis auf das der Mount gelegentlich verschwindet. Eventuell kann ich das aber noch lösen.
Hat jemand noch weitere Ideen? Ich kann den SQLite auf der Telefonanlage nicht ersetzen und leider auch keine eigenen Module einbringen. Die schönen Module fehlen leider.
Was man nicht so alles findet, wenn man etwas über PuTTY, KiTTY und iTerm2 schreibt:
QuTTY - Successor to PuTTY with advanced features similar to iterm2
Zumindest ich habe ihn allerdings noch nicht getestet. Vielleicht demnächst, denn iTerm2 gefällt mir sogar besser als KiTTY.
Update 10.02.2013: Eben getestet. Das ist noch ein verdammt weiter Weg bis zu einem iTerm2 Putty... Im Moment sieht er nach einem Tabbed Putty aus, der ausser Tabs eigentlich noch nichts kann.
Wer PuTTY unter Windows als bevorzugten SSH Client verwendet, sollte einen Blick auf KiTTY werfen. KiTTY ist ein Fork von PuTTY 0.62 und bringt ein paar nette Features mit, die PuTTY fehlen. Zudem gibt es öfter Updates und Verbesserungen als bei PuTTY.
Einige bemerkenswerte Features:
- Sessions Suchfilter (sehr praktisch wenn man sehr viele gespeicherte Server Sessions hat)
- Kann Sessions und Einstellungen im Filesystem ablegen statt in der Registry (gut für portablen Einsatz oder synchronisieren mehrerer Rechner)
- Lokale Scripts können remote ausgeführt werden (praktisch bei sehr vielen Servern mit gleichen Aufgaben)
- Transparenz und Terminalhintergrundbild können frei gewählt werden (wer's braucht, wird damit glücklich sein...)
- Und vieles weitere
Und da ein Bild mehr sagt als tausend Worte: Mehr Screenshots von KiTTY gibt's auf der Homepage.
Das Postfach ist besiegt. Dauerte, wie vermutet, auch automatisiert ein Weilchen. Nebenbei habe ich einen kleinen IMAP Client für die Shell geschrieben, der automatisiert solche Dinge übernehmen kann. Kommt demnächst als Download.
RDP, das Remote Desktop Protocol, macht seine Arbeit beim Zugriff auf entfernte Server soweit ja ganz ordentlich. Mittlerweile liegt RDP in Version 6 vor und es gibt sogar unter Linux einen funktionierenden Client und auch einen funktionierenden RDP Server. Steht der zu steuernde Server allerdings hinter einer nicht ganz so breitbandigen Verbindung, lahmt RDP gelegentlich auch mal dahin. Selbst wenn man die Performance optimiert, fliesst es so la la, abhängig eben von der Upload-Bandbreite des Anschlusses an dem der Server hängt. Da auch ich oft auf RDP Server zugreife(n muss), die hinter einem normalen DSL Anschluss hängen kenne ich das Problem also auch aus erster Hand.
Interessant wird's, wenn man über den RDP Tellerrand hinausschaut. Dort gibt es zum Beispiel für den Betrieb von Linux Terminalservern von Nomachine ein Produkt namens NX, welches eine ordentliche Performance an den Tag legt und über normales SSH gefahren wird. NX kann aber auch mehr. Mit NX' Hilfe lassen sich beispielsweise auch RDP Connections beschleunigen.
Zum Beispiel baue ich eine Verbindung mit NX über eine DSL Leitung zu einem Linux Server auf, der im gleichen LAN wie der RDP Server steht. Auf diesem Linux Server starte ich nun meinen RDP Client und verbinde mich auf den RDP Server. Das alleine sorgt schon für einen ordentlichen Performancegewinn, mit dem die Arbeit auf einem Windows Terminal Server über RDP deutlich flüssiger von der Hand geht.
Ausprobieren empfohlen. Ich könnte vielleicht auch mal ein Video vom Unterschied machen, was allerdings Zeit kostet, die ich momentan in andere Dinge stecke. Weshalb sonst sollte ich auch RDP beschleunigen wollen? 
Mulberry Mail gilt als der E-Mail Client mit der derzeit besten IMAP-Unterstützung. Eben jener Mulberry ist jetzt Open Source und daher im Quelltext verfügbar. Die Oberfläche ist sicherlich nicht Jedermanns Sache, aber sicherlich einen Blick wert.
