Muss man ja auch erstmal wissen, wie das ohne iTunes geht: Einfach in der “Music-App” auf dem Podcast von links nach rechts “wischen”, und schon erscheint der Deletebutton.

Man lernt halt nie aus…

Allen die bei einer Entfernung von über 50cm (ist ja jetzt nicht wirklich viel zwischen MacPro und Bluetooth Gerät (MagicMouse / MightyMouse / Keyboard / etc.) Probleme mit der Verbindung haben, sei dieser Artikel bei MacRumours ans Herz gelegt. Mein MacPro (MacPro1,1 / Early 2007) hatte genau diese “falsche Verkabelung”, die dort in Step5 beschrieben ist.

Jetzt, nach Umverdrahtung der “Pigtails” klappt alles einwandfrei

Ha, da habe ich doch schon ewig nach gesucht (und bin immer wieder auf “Chicken of the VNC”, “Jolly VNC” oder andere Spaesse ausgewichen).

Gesucht war eine Tastenkombination mit der man beim Verbinden auf Windooze Kisten ein “CTRL-ALT-DEL” senden kann. Alle Standardkombinationen sind fehlgeschlagen. Jetzt weiss ich wie es geht. Man drücke nach dem Verbinden via “Command-K” und “vnc://ip.ad.dre.sse” einfach CTRL-ALT-COMMAND-DELETE.

Das Command war das fehlenden Glied

Fuer alle “alten” Mac-User: COMMAND = “Apfeltaste”

Oh wie wahr….

Mobile.Me ist ja irgendwie fein. Allerdings haben sich meine Macs strikt geweigert, auch nur im Ansatz die korrekten Inhalte des Kalenders zu synchronisieren. Nun woran lag es ?

Kurz und bündig: Die “SyncData” ist quasi “out of Sync”. Soll heissen: Der Mac weiss nicht (mehr) was er synchronisieren soll, und was nicht.

Auf einschlägigen Seiten (z.B. der KB von Apple) wird ein hierzu Reset der Sync Data empfohlen. Allerdings ist diese in den Systemeinstellungen für Mobile.Me nur halbherzig implementiert. Ein Blick ins /var/log/system.log bringt folgende Meldungen zu Tage:


Sep 16 19:03:11 powermac iCalExternalSync[822]: SyncServices precondition failure in [ISyncConcreteSession clientAcceptedChangesForRecordWithIdentifier:formatted-Record:newRecordIdentifier:]: you can't change the record identifier from BLUBB-DIWUPP-HEXKEY-WIEBEI-WINDOOFS to com.apple.ical.calendars.RootNode: it is already associated with a different record.

Dem Mac das abzugewöhnen war garnicht so einfach (Naja, der Weg dahin war steinig, der Rest ist leicht Fangen wir also an:

1. iCal, iTunes, Addressbook etc. schliessen
2. Unter ~/Library/Calendars selbiges Directory löschen (Die vorsichtigen unter euch dürfen es gern Backuppen)
3. iSync starten und unter Einstellungen die Synchronisierung DEAKTIVIEREN
4. Mobile.Me Account komplett unter den Systemeinstellungen DEAKTIVIEREN (Also “Abmelden” !!)
5. Unter ~/Library/Application Support/Sync Services/ das Directory “clientdata” löschen
6. In iSync sicherheitshalber nochmal auf “iSync-Verlauf zurücksetzen” clicken.
7. Mobile.Me wieder aktivieren und syncen
8. Fertig !

War der einzigste Weg bei mir, der ganze 3 Rechner wiederbelebt hat. Alle anderen “Tricks” aus irgendwelchen Apple-Foren haben garnichts gebracht. Die “Magic” steckt einzig und allein in Punkt 5 und 6 oben. Ich nehme an dass “iSync-Verlauf zurücksetzen” genau das tun sollte, was ich in Punkt 5 beschreibe. Macht es aber leider nicht. Naja, mit der Anleitung oben wird man dann auch glücklicher Mobile.Me Nutzer

Viel Spass

Oft gesehen, nie benutzt. Zu der Kategorie gehoert wohl das kleine aber feine Tool “at”. Quasi ein “Wegwerf”-CRON. Dabei ist das Ding totsimpel zu bedienen, und dazu noch extremst nützlich. Wie es funktioniert ? Folgendermassen:

Angenommen ich muss dringend noch ein paar Files per scp kopieren, kann das aber erst machen, wenn kein Betrieb mehr auf dem Produktionssystem herrscht. Erschwerend kommt jetzt noch hinzu dass, sagen wir, der Betrieb erst gegen 23:00 beendet ist. Ein klassischer Fall für at:

at 23:00 [CR] (danach befinden wir uns im Commandmode)
scp Datei user@system:/directory [CR]
[CTRL+D]


Nun lediglich den Rechner auf dem das Kommando abgesetzt wurde anlassen (oder noch besser: Auf einem Remotesystem ausführen und anschliessend ausloggen) und ab gehts um 23:00

Eine Besonderheit für Mac-User gibt es noch. Der Dienst der die at-jobs (Eine Liste derer gibts übrigens via “atq”) startet, ist defaultmässig nicht gestartet. Das kann man via:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist

nachholen.

Viel Spass beim “at”ten …

Mit bind geht das schon lange. Man hat 2 Netze, mit jeweils zwei unterschiedlichen Nameservern die die privaten Adressen im jeweiligen LAN auflösen. Will man jetzt, z.B. via VPN beide Nameserver aus den jeweiligen LANs nutzen, so konfiguriert man den bind für die jeweiligen Netze als forwarder (Jeweils für das Netz mit seinem Nameserver einen Eintrag). Ein Beispiel:

Gegeben seien ein LAN mit der Domäne Intranet1.de und dem Nameserver 192.168.0.222, und das LAN mit der Domain intranet2.de welches seinen DNS auf 10.0.0.222 liegen hat. Natürlich gibts noch einen öffentlichen Nameserver, der hat in unserem Beispiel die 212.121.212.111 als IP.

In der named.conf sieht das dann so aus:

options {
directory “/var/named”;
forwarders { 212.121.212.111;};
};

zone “intranet1.de” in {
type forward;
forwarders {192.168.0.222; };
forward only;
};

zone “intranet2.de” in {
type forward;
forwarders {10.0.0.222; };
forward only;
};

Beim Mac ist das viel simpler. Man lege ein Directory /etc/resolver an und lege dort einfach pro Zone ein File ab. In diesem Beispiel wäre das dann /etc/resolver/intranet1.de mit dem Inhalt “nameserver 192.168.0.222″ und eine zweite Datei mit /etc/resolver/intranet2.de mit Inhalt “nameserver 10.0.0.222″. Fertig. Dumm nur das das ganze nicht persistent ist. Nach dem Neustart ist alles weg. Nicht so wenn man sich die Dateien per Shellscript aus der /etc/rc.common erstellen lässt. Funktioniert prima und ist simpel.

Fuer den Fall der Faelle, in dem man ein simples Shellscript beim Aufwecken bzw. einschlafen seines Macs ein Script abfeuern moechte (kann ja hilfreich sein, um schnell noch was zu umounten, etc.), nehme man den Sleepwatcher von Berhard Baehr.
Das Ding gibts unter http:/www.bernhard-baehr.de kostenlos herunterzuladen.

Das ist wirklich bitter. Habe mich gerade gewundert wieso ca. 4 GB RAM auf meinem MacPro belegt sind, obwohl lediglich Mail.App, Firefox und ein Remotedesktop liefen.
Zuerst hatte ich den Firefox im Verdacht. Ein Blick auf top brachte dann jedoch Licht ins Dunkel: Ca. 1,8 GB (Ja GB für Gigabyte) RAM waren durch den RemotedesktopClient (übrigens Version 2.0) belegt.
Mann, da kann ich 3 x Windows unter Parallels für starten

Kennt jemand einen anderen gute RDP-Client für den Mac ? Bitte nicht CoRD, der kommt leider mit Fullscreen auf einem Multiscreensystem nicht klar. Ich suche was simpeles, schnelles und was ohne Memory Leaks…

Update (13.09.2010): Durch einen Hinweis aus der Leserschaft bin ich auf einen netten Vergleichschart hingewiesen worden. Hier stehen noch ein paar andere Clients zur Auswahl (Danke, Amy!)

Seit Wochen kämpfe ich nun unter Etch, trotz Gigabit, mit einem extrem langsamen Samba – nun endlich der Durchbruch.
Doch zu Vorgeschichte:

Nach den üblichen Anpassungen in der smb.conf (TCP_NODELAY und der ganze Schnickschnack) war ich fast schon am verzweifeln. Die einzigen Effekte die ich bekam, manifestierten sich in einer schwankenden Transferrate (sofern das Directory Listing auf dem Mac überhaupt in annehmbarer Zeit angekommen war) – mal hoch, und mal wieder runter.

Heute morgen habe ich dann man mit mii-tool und ethtool herumgespielt und das Interface einfach mal auf 100MBit heruntergedreht. Ergebnis: Ein Rasend schnelles samba – aber eben nur auf 100MBit.

Abhilfe schafft ein neuerer Realteak Treiber, den man hier herunterladen kann. Sobald der installiert ist kann man Samba in voller Breite, d.h. wieder mit 1000BaseTX, geniessen. Herrlich !!!
Der original-Treiber, für die RTL8168 der bei etch dabei ist war folglich etwas buggy…
Aber nun läuft es ja.

PS: OSX Leopard hat mit Netzen und Samba auch so seine Problemchen. Eine Lösung des OSX-Problems gibt es bei MacOsXhints