Eine kurze Recherche förderte zu Tage, dass Snow Leopard (im Gegensatz zu seinen Vorgängern) auf Passwortverschlüsselung besteht, was standardmässig in Samba nicht eingeschaltet ist und schon viele Snow Leopard-Umsteiger geärgert hat. Das alleine kann ich als Ursache aber nicht gelten lassen, schliesslich konnte ich bis gestern problemlos von Snow Leopard auf die Freigaben des Servers zugreifen – ganz ohne Verschlüsselung. Hier wird wohl eher eine Kombination aus Snow Leopard und Samba-Version für das Problem verantwortlich zeichnen.

Aber alles halb so wild, es gibt ja Abhilfe:

• encrypt passwords = yes in die [global]-Sektion der smb.conf aufnehmen
• mittels smbpasswd das Passwort der Freigabe neu setzen

Anschliessend wollte der Schneeleopard wieder mit dem Pinguin spielen.

Ob dieses Problem auftritt oder nicht, liegt wohl daran, wie man das ISO erzeugt hat. Wer es wie ich einfach mit dd if=/dev/foo of=bar.iso erzeugt hat, wird vor diesem Problem stehen. Die technische Erklärung dafür hat mit dem internen Aufbau des ISOs zu tun und kann bei Rafael’s Within Windows nachgelesen werden. Dort gibt es auch gleich ein Tool, um das ISO so zu modifizieren, dass es vom MS-Tool “gefressen” wird.

Die nächste Hürde ist dann die, dass das MS-Tool die Datei bootsect.exe aus dem angegebenen ISO verwendet, um den USB-Stick bootbar zu machen. Wer jetzt unter einem 32bit-Windows einen Stick für ein 64bit-Windows präparieren möchte, steht jetzt schon wieder auf dem Schlauch. Abhilfe schafft hier nur die entsprechende 32bit-Version, die man aber leider nicht bei Microsoft herunterladen kann. Diese muss man stattdessem einer 32bit-Installations-DVD entnehmen, die man hoffentlich auch noch zur Verfügung hat. Anschliessend kopiert man diese Version dann ins Installationsverzeichnis des MS-Tools, wo sie fortan automatisch gefunden und benutzt wird.

Da sich der Befehl Rsync idealer weise  für Backups anbietet, aber selbst nicht die Möglichkeit, einen anderen SSH-Port anzugeben. Rsync bietet zwar eine Option zur Veränderung des Ports an, diese bezieht sich ausschließlich auf den Rsync-Server.

Mit diesem  Trick, kann Rsync über SSH auf einem anderen Port konektieren.

rsync -avze 'ssh -p abcd' Username@entfernterSSHServer:/entfertner/pfad/auf/quell/server/ /pfad/ziel

Dabei steht abcd für den entsprechenden Port (z.B. 1234, anstatt 22 ). Der Prot wird entsprechend in der Datei /etc/sshd/sshd.conf eingestellt.  Ob der SSH-Server die Quelle oder das Ziel ist spielt keine Rolle. In diesem Beispiel wird von einem SSH-Server auf ein lokales Verzeichnis kopiert. Die Rsync-Parameter sind bis auf -e austauschbar. Dabei muss -e als letzter Parameter vor ssh -p abcd stehen.

Verbindet man sich per SSH mit einem Server macht dieser eine reverse DNS Abfrage um den Hostnamen zu der IP aufzulösen von der aus man sich verbindet.

Dies kann bei DNS Problemen oder bei vermehrten Traffic unter Umständen dafür sorgen, dass die SSH Verbindung ein paar Sekunden einfriert. Diese Reverse DNS Abfrage lässt sich jedoch in der /etc/ssh/sshd_config deaktivieren. Dazu  muss folgender Eintrag in der Datein hinzugefügt werden.

UseDNS=no

Eine weitere Ursache kann auch ein ungültiger Eintrag in resolv.conf (reverse DNS-lookup) sein.

Unter Solaris sollten folgende Einträge in der /etc/ssh/sshd_config helfen.

LookupClientHostnames no

VerifyReverseMapping no

Jetzt habe ich mal recherchiert und die Ursache bzw. Lösung ist eine Einstellung für X11: “Pasteboard aktualisieren, wenn CLIPBOARD geändert wird” darf nicht aktiv sein.

Interessant daran ist, dass ich die Lösung aus dem Inkscape Wiki habe, das dort beschriebene Problem aber “kopierte Vektorformen werden als Bitmaps eingefügt” lautet. Das dürfte wohl daran liegen, dass sich der beschriebene Fehler auf Xquartz-X11 bezieht, auf meinem Rechner aber noch das Apple-X11 läuft.