Heute nahm ich mir aus gegebenem Anlass mal wieder 30 Minuten Zeit und warf die Suchmaschine meines Vertrauens an. Und ich fand folgenden Foreneintrag der die Lösung brauchte:

Von O2 gibt es mitlerweile eine neue Software, mit der es wieder funktioniert. Den ConnectionManager 2.1.1. Hier eine Beschreibung: http://ploin.de/robertreiz/page/blogDetail.xhtml?locale=de_DE&id=73

Quelle: http://board.protecus.de/t37797.htm#ixzz0gAcKjwJE

Es geht um das Zusammenspiel zwischen dem JavaScript-basierten LightWindow (dient grob gesagt dazu, um ein Fenster im Fenster animiert anzuzeigen und zu steuern – Einsatz z.B. für Großansichten von Bildern) und AJAX-Aufrufen im Allgemeinen.

LightWindow im Einsatz beim CakePlanner

In meinem Fall habe ich eine CakePHP-Applikation, die auf Anforderung gewissen Seitenteile per AJAX austauscht. Sowohl auf der Startseite, als auch auf dem nachgeladenen Bereich sind Links verbaut, die die jeweils verlinkten Inhalte in einem LightWindow darstellen sollen.
Auf der Startseite funktionierte das beim Testen auch prächtig. Lud ich jedoch einen Seitenteil nach, wurden die LightWindow-Links unschön “ganz normal” im Browser geöffnet, anstatt im LightWindow.

Ursache: Beim Nachladen verliert LightWindow den Bezug zu den vorhandenen DOM-Objekten (z.B. den Links) und kann dann nicht mehr wie gewünscht auf ein onClick-Event reagieren.

Lösung: Nach dem Nachladen muss die jeweilige LightWindow-Instanz re-initialisiert werden.

Bei mir sah das dann so aus:


<script type="text/javascript">
myLightWindow.initialize();
</script>


Dieses Code-Snippet ziert nun den jeweiligen, nachgeladenen Bereich und siehe da: die Links wurden wieder sauber im LightWindow geöffnet.

[1] LightWindow: http://www.stickmanlabs.com/lightwindow/
[2] CakePHP: http://www.cakephp.org/
[3] CakePlanner: http://sourceforge.net/projects/cakeplanner/

Da der Leidensdruck mangels aktueller Dateien auf meinem Laptop jetzt aber doch stark Richtung “Ich kann so nicht arbeiten” schnellte, habe ich in einer ruhigen Minute eine Lösung zu folgender, sich mir offenbarenden Fehlermeldung gefunden:

Fehler: Überprüfung des Server-Schlüssels fehlgeschlagen Bitte wählen Sie einen anderen Betrachter und versuchen Sie es erneut.

Soll heißen: Ubuntu glaubt, jemand würde versuchen, ihm einen geklauten oder ungültigen SSH-Schlüssel unterzujubeln.
Woher Ubuntu das weiß?

Im Verzeichnis

~/.ssh/

gibt es eine Datei, die sich

known_hosts

nennt, also so viel wie “bekannte Hauptcomputer”. Hierin legt Ubuntu bekannte Schlüssel von bereits akzeptierten Hosts ab und kann so ankommende Anfragen abgleichen.

Um das Problem nun zu lösen, habe ich besagte Datei einfach gelöscht. Umbenennen tut’s im Zweifelsfall übrigens auch.

Die Folge ist, dass Ubuntu beim nächsten Verbindungsversuch, z.B. auf ssh://user123@192.168.1.42:443/ über Nautilus, den Benutzer darum bittet, den unbekannten Schlüssel zu akzeptieren (oder abzulehnen). Ist das Akzeptieren vertrauensvoll geschehen, läuft wieder alles wie am Schnürchen.

Jetzt stellte sich mir noch die Frage nach dem “Warum”, zumal bislang alles sauber funktionierte.

Kurzfassung:
Zu verdanken habe ich diesen Umstand offenbar meinem Router, der DHCP-Einstellung meines Fileservers und einem weiteren Laptop.

Aber langsam:
Bislang hörte der Fileserver auf eine IP-Adresse mit der Endziffer 20, der Rest der Rechner reihte sich dann per DCHP artig dahinter ein. Über die DCHP-Einstellung auf dem Fileserver (Debian) war die “20″ fest in der dhclient.conf verdrahtet, so dass trotz abgelaufener Lease-Time immer wieder die “20″ an ihn vergeben wurde.

Offenbar überschnitt sich aber in den letzten Tagen die Lease-Time des Fileservers mit einem Bootvorgang des oben genannten Laptops, der daraufhin die “20″ als IP-Adresse abstaubte, nun von meinen Sync-Tools  belästigt wurde, diesen aber die kalte Schulter zeigte.
Der Fileserver indes begnügte sich nach dem nächsten, allmorgendlichen Bootvorgang mit der “33″ (da die “20″ ja nun belegt war), was jedoch die gesamte IP-Adress-Landschaft in meinem kleinen Netzwerk durcheinander warf (ich nutze keinen DNS-Server…wäre wohl mal angebracht).

Die Erklärung:
Nachdem ich im Router-Log die IP-Adresse mit der Endziffer “33″ dem Fileserver zuordnen konnte, versuchte ich einen SSH-Connect auf diese Adresse – und scheiterte kläglich – eben weil Ubuntu wohl dachte, jemand wolle ihm da etwas unterschieben…

Fündig wurde ich bei fedorawiki.de, möchte Euch die Vorgehensweise aber hier auch noch einmal etwas ausführlicher erläutern.

Solltet Ihr noch kein ClamAV installiert haben, könnt Ihr das per

sudo apt-get install clamav

nachholen.

Für KDE gibt es auch noch eine GUI, die Ihr per

sudo apt-get install klamav

nachinstallieren könnt. Läuft natürlich auch unter Gnome, stürzt bei mir allerdings gelegentlich mal ab.

Zunächst erstellt Ihr eine neue Datei, beispielsweise clamav4evolution.script, speichert diese an einem geeigneten Ort ab (z.B. unter /home/[username]/scripts) und macht das Skript ausführbar:

chmod +x clamav4evolution.script

Nun öffnet Ihr Evolution und legt über Bearbeiten > Nachrichtenfilter einen neuen Eingangsfilter an.

Dann verpasst Ihr dem Filter noch einen treffenden Namen und füllt mit folgenden Daten (bei An Program weiterleiten tragt Ihr Euer erstelltes Skript ein):

Das Ganze bestätigt Ihr mit OK und zu guter Letzt setzt Ihr den Filter noch ganz nach oben in der Liste:

Ein letztes Mal OK drücken…fertig.