MyNakedGirlfriend.de

Es ist ein merkwürdiges Phänomen: Wenn ich mich von meinem Linux-Client (openSUSE 11.2) mit dem NX-Client von NoMachine (Version 3.4.0-5) zum FreeNX-Server (openSUSE 11.2, FreeNX 0.7.2) verbinde, fehlen mir bestimmte Key-Mappings. Bild-auf-/Bild-ab-Taste, Pfeiltasten und Tasten wie “Entf”, “Pos1″ usw. zeigen entweder keine Reaktion oder schlicht etwas völlig falsches.

Ausschlaggebend für das Problem scheint wohl das verwendete Client-Betriebssystem, denn baue ich die Verbindung über ein System mit openSUSE 11.1 auf, funtioniert alles wie erwartet. Die Behebung des beschriebenen Problems ist durch den Aufruf dieses Befehls innerhalb der NX-Sitzung möglich:

setxkbmap -model evdev -layout $LANGUAGE

also in meinem Fall

setxkbmap -model evdev -layout de

Wird dieser Befehl in die Datei “.bashrc” im Home-Verzeichnis des Users auf dem NX-Server eingetragen, wird er direkt beim Anmelden ausgeführt. Allerdings verursacht dies bei mir wieder Probleme, wenn ich mich nicht mit dem openSUSE 11.2 Client  zum Server verbinde.

Es sind nur noch wenige Tage bis zur Veröffentlichung von openSUSE 11.2. Beim Testen des RC2 stellte sich nun heraus, dass der SSH daemon standardmäßig deaktiviert sein soll. Grund hierfür ist scheinbar die dadurch erreichte höhere Sicherheit. Allerdings war geplant, den Dienst bei Remote-Installationen automatisch zu aktivieren, um den direkten Zugriff auf das installierte System nicht zu verlieren. Dies scheint aber nicht umgesetzt worden zu sein. Daher wurde nun ein kritischer Bug eingestellt, der dieses Problem in letzter Minute beseitigen soll.

UPDATE:
Wie sich herausstellte, funktioniert die Technik nun doch problemlos. Bei Remote-Installationen über SSH wird der Daemon automatisch aktiviert und in der Firewall freigeschaltet. Bei lokalen Installationen wird SSH dagegen nun standardmäßig deaktiviert. Dies lässt sich während der Installation bequem ändern, indem die entsprechende Schaltfläche (s. Screenshot) verwendet wird.

Ich würde trotzdem gerne wissen, wie viele User sich nach der Installation irritiert fragen werden, wieso der SSH-Aufruf lediglich mit “connection refused” endet…

UPDATE 2:
Wenn nun das Kind bereits in den Brunnen gefallen ist, helfen die zwei folgenden Kommandos, um den SSH-Server inkl. Autostart wieder zu aktivieren:

/sbin/chkconfig -a sshd
/usr/sbin/rcsshd start

Außerdem muss SSH noch in der Firewall (falls genutzt) freigeschaltet werden. Das geht bequem über YaST oder über die Datei /etc/sysconfig/SuSEfirewall2:

FW_CONFIGURATIONS_EXT="sshd"

Bereits am 9.9.2009 erhielt ich die Nachricht, dass ich nun eins von 25 Mitgliedern des neu gegründeten “openSUSE Testing Core Teams” bin. Ziel dieses Kern-Teams soll es sein, openSUSE systematischer als bisher testen und damit mehr Zuverlässigkeit in die offiziellen Versionen bringen. Dies umfasst neben den eigentlichen Tests auch die Entwicklung von Strategien und Plänen für zukünftige Tests.

Mittlerweile haben sich die Mitglieder eingefunden und die Diskussionen auf der eingerichteten Mailing-Liste laufen an. Geplant ist auch ein IRC-Meeting in den nächsten Tagen. Nähere Informationen zum Thema gibt es hier.

Das Warten hat sich gelohnt. Es ist soweit! openSUSE 11.1 ist nun für alle verfügbar.
Wie bereits auf der openSUSE-Homepage angekündigt, sind heute, um 14 Uhr Ortszeit, die FTP-Server freigegeben worden.

Bereits vor einigen Tagen tauchten die ISOs auf diversen Torrent-Seiten auf. Wer hier glaubte, der Zeit ein Schnippchen schlagen zu können, wurde arg enttäuscht, da die angebotenen Images eine falsche SHA1-Checksumme enthalten, was auf eine nicht authorisierte Manipulation an den Daten hinweist. Hier ist also höchste Vorischt geboten!

Mein Download läuft, ich bin sehr gespannt!

Die offizielle openSUSE-Homepage zeigt momentan noch das Release 11.0, die aktuelle Version ist z.B. über diesen Mirror erhältlich. Generell wird empfohlen, einen der Mirror-Server aus dieser Liste zu wählen.

Have a lot of fun!

Bei meinen installierten SuSE-Linux Systemen verwende ich überwiegend MD5 zur Passwortverschlüsselung. Seit openSUSE 11.0 schien dies allerdings nicht mehr korrekt zu funktionieren. Ich habe MD5 ausgewählt, aber nur DES bekommen. Keine Reaktion auf meine Anfrage im UseNet. Quasi auch keine Reaktion in den openSUSE-Foren. Also habe ich einen Bug-Request bei Novell eröffnet. Und siehe da! Es klappt. Dort wurde mein Request binnen weniger Tage bearbeitet und gelöst. Es wurden ein Patch und ein Security-Announcement veröffentlicht (CVE-2008-3188).

Ich habe gerade mal wieder an meinem Netzwerk, genauer gesagt, an meiner Proxy-Konfiguration geschraubt und dachte mir, dass daraus ein hilfreicher Artikel werden könnte.

Preface:

Ich betreibe u.a. einen DHCP-Server, einen Proxy-Server und einen Webserver.
Was liegt also näher, als diese drei Dienste miteinander zu koppeln, mit dem Ziel, die Information “Proxy-Server” automatisch zu verteilen, anstatt jedem Browser und jedem System im Netzwerk manuell einen Proxy-Server einzutragen. Außerdem betreibe ich auf verschiedenen Systemen “netz-interne” Webserver, die ich direkt aufrufen möchte, ohne den Proxy zu verwenden.

weiter lesen…