Apple Mac OS X auf Standard PC Hardware (OSX86 / Hackintosh / HackMac) oder wie man günstig an einen Mac Pro kommt…

4. September 2011

Schon seit ein paar Jahren kann ich ich ja privat und am Arbeitsplatzrechner auf umfangreiche Wartungsarbeiten verzichten – weil der Mac OS Rechner in der Tat wenig Ärger macht. Ich kann mich somit zumeist meiner Arbeit widmen, statt Unzulänglichkeiten des Betriebssystems auszubaden.

Als nun ein neuer Rechner für daheim anstand, war das bevorzugte OS also bereits entschieden. Man könnte annehmen, dies sei auch bereits eine Hardwareentscheidung – dem ist aber nicht so, schließlich läuft das Mac OS X auch ganz wunderbar auf normaler PC-Hardware, wenn man die richtigen (also unterstützten) Komponenten auswählt.

Klar, so einfach mit mit “echter Mac Hardware” geht die Einrichtung natürlich nicht, aber es lohnt sich dennoch, weil…

  • so ein “Hack-Mac” unterm Strich viel mehr Leistung fürs Geld bietet als echte Mac Hardware (die im folgenden näher beschriebene Konfiguration kostete z.B. insgesamt ca. 1.240 EUR netto, entsprechend ca. 1.470 EUR inkl. Mehrwertsteuer – was in Anbetracht der Leistung mehr als erschwinglich ist)
  • man unter dem Tisch nicht sieht, ob der Rechner in einem hübschen Apple Gehäuse steckt oder nicht
  • man kann sich etwas sehr nettes genau nach den eigenen Vorstellungen zusammenstellen, und bekommt den Rechner, den nicht wenige bei Apple vermissen: das Modell zwischen dem Apple iMac 27 Zollund dem Apple Mac Pro (siehe auch dieser Apple Mac Pro)

weiterlesen »

Von AS | Abgelegt unter Allgemeines, Hardware, Off-topic: Apple/Mac & iPhone, Systemadministration | Mit Schlagworten , , , , , | Kommentare (0)

rsync zwischen MacOS (HFS+) und Linux (ext3) – und defekte Dateinamen

5. Januar 2011

Bei umfangreicheren rsync-Läufen hier im lokalen Netz (ging um ca. 4 TB die von einem Ubuntu Server mit ext3 auf einen Mac mit HFS+ gehen sollten) stellten sich 2 Probleme heraus, die beim Sync zwischen Linux Maschinen nicht auftraten:

  • Ein großer Teil der Daten (und zwar alle mit Leerzeichen oder Umlauten im Dateinamen) wurde bei jedem rsync Aufruf neu übertragen, obwohl die Dateien sich nicht geändert hatten.
  • Umlaute waren z.T. defekt.

Eine längere Herleitung spare ich mir hier mal – statt dessen nur das Ergebnis der Recherchen, da das ggf. noch für jemanden nützlich sein könnte:

Das Problem entstand durch unterschiedliche Charsets auf beiden Maschinen:

Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.

An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (\0303\0274), the file will get that character stored by the filesystem using 3 bytes (\0165\0314\0210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if –delete is enabled, and then recreate it).

You can avoid a charset problem by passing an appropriate –iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using –iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

(Die Erklärung stammt aus der rsync FAQ.)

Dem geneigten Mac-User fällt aber leider schnell auf, dass das mitgelieferte rsync den Parameter --iconv leider nicht versteht. Hier empfiehlt sich das Updaten z.B. über Macports – dazu hatte ich hier gerade schon ein paar Zeilen geschrieben.

Lange Rede, kurzer Sinn – nach dem rsync Update und der Angabe der Parameter schaut das bisher sehr gut aus. Folgender Kommandozeilenaufruf wird dabei verwendet:

rsync -a --modify-window=1 --stats --progress --exclude "*.frk"' --delete --iconv=UTF8-MAC,UTF8 root@SERVERNAME:/pfad/zum/Quell-Verzeichnis/ /pfad/zum/Ziel-Verzeichnis/

Von AS | Abgelegt unter Off-topic: Apple/Mac & iPhone, Systemadministration | Mit Schlagworten , , , , , | Kommentar (1)

Kurznotiz: Darwinports, Fink und Macports

5. Januar 2011

Nachdem Stefan in seinem Blog kurz und eindringlich von Darwinports abriet und Fink mich vor einiger Zeit schon nicht begeistert hatte, habe ich heute mal Macports eine Chance gegeben.

Kurzfazit:

  • Installation über einen Mac Installer (!), entsprechend problemlos und schnell
  • Installation von Paketen sehr einfach, automatische Auflösung von Abhängigkeiten klappt gut
  • binnen 15 min. gewechselt vom unerträglich schlechten RSYNC auf dem Mac zu einer aktuellen Version (rsync  version 3.0.7  protocol version 30)

Tipp der Redaktion, sozusagen ;-)

Von AS | Abgelegt unter Off-topic: Apple/Mac & iPhone, Software, Systemadministration | Mit Schlagworten , , , , , | Kommentare (0)

OpenVPN mit Mac OS – Viscosity oder Tunnelblick

30. Januar 2010

Tunnelblick-Logo-Big

In der Vergangenheit unterstützte der für Mac OS X (kompatibel zu 10.4, 10.5, 10.6 und wohl auch den Folgeversionen) verfügbare OpenVPN Client namens “Tunnelblick” leider keine DNS Auflösung. Konkret hiess das, dass man zwar die VPN Verbindung problemlos herstellen konnte, aber alle im VPN liegenden Adressen (z.B. bei uns den Firmen Mailserver, das Intranet oder die Entwicklungsserver) z.B. in die lokale Hosts Datei schreiben musste – wenig komfortabel.

screenshot_ 2010-01-30 um 15.49.12Um den Pflegeaufwand zu minimieren, kam nun einige Monate auch Viscosity zum Einsatz, ein kommerzieller VPN Client für Apple Systeme (und mit 9 $ auch erschwinglich). Eigentlich ist das ein recht durchdachtes Tool: Es importiert bestehende Verbindungen (z.B. aus Tunnelblick) hat ein aufgeräumtes Interface und bot eben die beschriebene DNS Unterstützung.

Seltsamerweise wollte Viscosity aber ab heute auf 2 Rechnern sein Icon in der Menüleiste nicht mehr anzeigen – was es de facto unbenutzbar macht (der “Verbinden”-Button ist nur über die Menüleiste zu erreichen). Das Programm lief zwar stets im Hintergrund, aufgrund der Nichtzugänglichkeit war dies aber wertlos..

Es scheint auch ein Problem vorzuliegen – zumindest lesen sich die Logfiles so:

(...) 30.01.10 13:01:11 Viscosity[360] : invalid literal for int() with base 10: 'unknown'

30.01.10 13:07:18 [0x0-0x29029].com.viscosityvpn.Viscosity[360]

Sat Jan 30 13:07:18 computername.tld Viscosity[360] : kCGErrorIllegalArgument: CGSUnregisterWindowWithSystemStatusBar: Invalid window

30.01.10 13:07:18 [0x0-0x29029].com.viscosityvpn.Viscosity[360]

Sat Jan 30 13:07:18 computername.tld Viscosity[360] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.

30.01.10 13:09:19 Viscosity[242] : invalid literal for int() with base 10: 'unknown' (...)

Falls jemand das gleiche Problem haben sollte (hier aufgetreten mit Mac OS X 10.6.2), lohnt vielleicht ein Blick in das Supportforum, wo ich die Beschreibung auch erfasst habe. Vielleicht kommt hier ja ein Lösungsweg durch den/die Entwickler: http://www.viscosityvpn.com/forum/viewtopic.php?f=3&t=219

Tunnelblick-LogoAufgrund des Viscosity Problems habe ich soeben mal wieder Tunnelblick probiert und siehe da: Die DNS Auflösung klappt problemlos, somit ist Viscosity ab sofort ohnehin nicht mehr das bevorzugte Produkt ;-) (Viscosity ist ein kommerzielles Produkt unter proprietärer Lizenz; Tunnelblick ist ein Open Source Produkt unter der GPL…)

Sehr interessant an Tunnelblick ist aber noch etwas anderes:

Im Tunnelblick Wiki gibt es eine eine Dokumentation dazu, wie man ein Deployment einrichten kann (also z.B. die Software zentral für die User innerhalb eines Firmennetzwerkes installieren und einrichten).

Mehr Infos zu Tunnelblick und der Download sind verfügbar auf der Google Code Seite des Projekts.

Von AS | Abgelegt unter Off-topic: Apple/Mac & iPhone, Software, Systemadministration | Mit Schlagworten , , , , , | Kommentare (0)