Posts Tagged ‘Mac OS X’

Sonntag, 16. August 2015

XPS-Dateien unter Mac OS X zu PDF konvertieren

… scheint mit quelloffener Software auf der Kommandozeile nicht — oder nur unter grösserem Aufwand — möglich zu sein: MacPorts hat dieses Paket nicht im Angebot (Nachtrag: Homebrew hingegen schon).

Ich bin deshalb auf meinen Linux-Server ausgewichen:

# apt-get install apt-get install libgxps-utils

Anschliessend konnte ich die XPS-Datei mit folgendem Befehl umwandeln:

$ xpstopdf datei.xps

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. April 2015

iPhoto 9 zickt unter OS X 10.9 in einer Zwei-Monitor-Konfiguration

Mein Arbeitsplatz zu Hause besteht aus einem Mac mini (2012), einem Dell Ultrasharp U2711 (27″, 2560×1440) sowie einem mittlerweile über 11 Jahre alten Eizo-Bildschirm (19″, 1280×768), welchen ich in den Porträt-Modus gedreht habe und rechts neben dem Dell als Zweitmonitor betreibe („Dual-Monitor-Setup“ auf neudeutsch).

Beim Einsatz von iPhoto laufe ich immer wieder in folgendes Problem: Das Programmfenster ist auf dem Dell in voller Grösse geöffnet. Ich wechsle in ein Programm, dessen Fenster auf dem Zweitmonitor angezeigt wird – beispielsweise Messages oder qTorrent. Wenn ich nun zu iPhoto zurückwechsle und dazu mit der Maus in die Oberfläche klicke, verschiebt sich das iPhoto-Programmfenster im besten Fall auf den zweiten Bildschirm, von wo ich es dann wieder auf den grossen Monitor ziehen muss. Im schlimmsten Fall stürzt iPhoto beim automatischen Verschieben aber auch einfach ab.

Ich bin nicht der einzige, der dieses Problem hat, wie eine Google-Suche aufgezeigt hat. Auf MacRumors gibt es sogar einen eigenen Thread zur Problematik:

iPhoto changing screens (Januar 2014)

Tags: , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 26. März 2015

monit unter Mac OS X neu starten

Vor einigen Tagen meldete mir die monit-Instanz aus einem anderen Subnet, dass die Web-Oberfläche der monit-Instanz auf meinem Mac mini nicht mehr ansprechbar war. Heute, nach unzähligen Warnmeldungen, habe ich mich um das Problem gekümmert.

Wie sich herausstellte, liess sich das Problem beheben, indem ich monit schlicht neu startete. Auf der Mac OS X-Kommandozeile geht dies so:

$ sudo launchctl unload /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist
$ sudo launchctl load /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist

Via: Monit

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 22. Februar 2015

ogv mit ffmpeg zu mp4 konvertieren

Das geht bei mir unter Mac OS X mit MacPorts und ffmpeg in der Version 2.5.3 folgendermassen:

$ ffmpeg -i "Selectric.ogv" -acodec aac -strict -2 -aq 80 -vcodec libx264 -preset slow -crf 25 -threads 0 "Selectric.mp4"

Via: ffmpeg unkown libfaac ubuntu 14.04

Obwohl ffmpeg folgende Fehlermeldungen ausspuckt, kann ich das Video anschliessend schauen:

[ogg @ 0x7f9884026c00] Broken file, keyframe not correctly marked.

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. Juni 2014

PHP kann unter Mac OS X nicht mit MySQL kommunizieren

Da war ich am Donnerstag in den beeindruckenden neuen Räumlichkeiten meines ehemaligen Arbeitgebers Liip und nahm am Hackday teil, wo ich mich anfänglich mit der Konfiguration von Docker befasste — und war dann auf meinem MacBook Air in einem anderen Zusammenhang mit Verbindungsproblemen zwischen PHP und der MySQL-Datenbank konfrontiert.

PHPs mysqli meldete:

Error: 2002 - No such file or directory

Das Problem lag gemäss dieser Diskussion auf Stack Overflow darin begründet, dass ich nach dem Upgrade auf Mavericks die mitgelieferte php.ini unter /etc/php.ini verwendete, welche für Mac OS X nicht anwendbare Standardwerte für die Verbindung zu MySQL enthielt.

Nachdem ich die Einträge

...
pdo_mysql.default_socket=/var/mysql/mysql.sock
mysql.default_socket = /var/mysql/mysql.sock
mysqli.default_socket = /var/mysql/mysql.sock
...

in

...
pdo_mysql.default_socket=/tmp/mysql.sock
mysql.default_socket = /tmp/mysql.sock
mysqli.default_socket = /tmp/mysql.sock
...

geändert hatte und Apache mittels

# apachectl graceful

neugestartet hatte, sprach PHP problemlos mit MySQL.

Solche Handstände sind künftig nicht mehr nötig, da ich nun endlich meine Vagrant-Installation vom Mac mini hier auf das MacBook transferiert habe.

Tags: , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 11. Juni 2014

FileVault 1 schrumpfen

Sicherheitsbewusste Mac-User werden das Phänomen kennen: Nach einigen Monaten wird das FileVault 1-Image eines Benutzerkontos fett und belegt trotz regelmässigen manuellen Säuberungsaktionen von Dateien und Ordnern (Disk Inventory X zu Hilfe!) unerklärbar viel Speicherplatz.

Apple verwendet das sogenannte .sparsebundle-Format, um die Daten im home-Verzeichnis eines Benutzers in einem verschlüsselten Image abzulegen. Das Image scheint die Eigenschaft zu haben Speicherplatz nicht immer automatisch freizugeben.

Dem kann Abhilfe geschafft werden:

  1. Über die Systemsteuerung einen zweiten Mac OS X-Benutzer einrichten
  2. Diesem Benutzer ist die Berechtigung zur Administration des Rechners zu geben
  3. Logout aus dem eigenen Konto
  4. Login in das zweite Konto
  5. Terminal öffnen
  6. $ sudo hdiutil compact /Users/.mario/mario.sparsebundle

    eingeben

  7. Logout aus dem fremden Konto
  8. Login in das eigene Konto

Nun könnte die Festplatte um einige Gigabytes leichter sein.

Problem

Führt man obiges Shell-Kommando auf einem Laptop durch, könnte einem folgende Fehlermeldung entgegengeworfen werden:

Initializing ...
Finishing ...
hdiutil: compact failed – Function not implemented

Ein grosses Bravo an Apple für völlig nutzlose, nichtssagende Fehlermeldungen! Die Ursache ist im Batteriebetrieb des Laptops zu suchen. Die Lösung des Problems ist deshalb die Verwendung der Option -batteryallowed:

$ sudo hdiutil compact /Users/.mario/mario.sparsebundle -batteryallowed

Quelle: Solution for hdiutil: compact failed – Function not implemented

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

curlftpfs unter Mac OS X

Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)

Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:

MacPorts

curlftpfs installiert man sich folgendermassen:

# port install curlftpfs

Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.

Geduldiges mounten

In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:

...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "

COUNTER=0
while [ ! -d "$SOURCE" ]
do
	let COUNTER=COUNTER+1
	echo -n "."
	
	if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
	then
		echo "Mountpoint still not available after $COUNTER iterations. Aborting."
		exit 1
	fi
done
...

In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.

Zugriff verweigert

Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?

Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):

$ curlftpfs -o defer_permissions ...

Zeichensalat

In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:

$ curlftpfs -o modules=iconv,from_code=latin1

Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71

Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.

Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:

$ iconv -l

In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 29. April 2014

Apples TextEdit unter Mac OS X Mavericks mit einer leeren, lokalen Textdatei starten

Sowohl unter Windows als auch unter Mac OS X starte ich die Text-Editoren notepad.exe respektive TextEdit.app mindestens einmal pro Tag, um formatierten Text in unformatierten Text umzuwandeln und so zwischen zwei Applikationen hin- und herzukopieren. Immerhin Microsoft Office verfügt mittlerweile über eine entsprechende Einfügen-Funktion, welche die Formatierungen automatisch entfernt. Doch für andere Anwendungsarten muss man weiterhin auf diesen lästigen Workaround zurückgreifen.

Unter Mac OS X wird dieses Unterfangen seit Mac OS X Mavericks deutlich erschwert, weil einem beim Starten von TextEdit nicht umgehend eine leere Textdatei entgegenstrahlt. Stattdessen fanden die Mac OS X-Entwickler (resp. deren übereifrigen Manager) die iCloud-Integration des neuen Betriebssystem offenbar so toll, dass sie den Benutzer immer zuerst fragen, ob er die neue Textdatei auf dem lokalen Rechner oder nicht aber doch lieber in iCloud ablegen möchte. Wenn einem dieses eher Microsoft zuzuschreibende Verhalten nicht den letzten Nerv raubt …

Um das vor Mavericks gewohnte Verhalten wieder hinzubekommen, behilft man sich der Kommandozeile:

defaults write -g NSShowAppCentricOpenPanelInsteadOfUntitledFile -bool false

Quelle: How to make TextEdit open with a blank file by default?

Tags: , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Samstag, 29. März 2014

Die Datei mach_kernel im Finder ausblenden

Aus einem mir unerklärlichen Grund wird bei mir die Datei mach_kernel, welche den Mac OS X Kernel enthält, im Finder angezeigt:

mach_kernel
image-5799

Mit folgendem Shell-Befehl wird die Datei im Finder inskünftig ausgeblendet:

# chflags hidden /mach_kernel

Via: mach_kernel now visible

Tags: , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

rsync braucht unter Mac OS X ewig für „building file list…“

rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei „building file list…“ stehen bleiben, sei folgender Rat gegeben:

Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.

Version 3 ist auf meinem System über MacPorts installiert:

# port install rsync

Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:

#RSYNC=$(which rsync)
RSYNC="/opt/local/bin/rsync/"

Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.

$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/
... 1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen