OS X 10.11 El Capitan, RVM und MacPorts

Dieser Artikel dient nur als Bestätigung von meiner Anleitung OS X 10.10 Yosemite, RVM und MacPorts/HomeBrew für das neue OS X 10.11 El Capitan.

Mehr oder weniger stimmt die Anleitung auch für El Capitan. Anmerkungen habe ich dabei (Stand 17. September 2015) nur folgende:

  • Basis:
    • OS X 10.11 El Capitan GM
    • Xcode 7 GM
    • sudo xcode-select –install
  • Die MacPorts gibt es noch nicht als Binary für 10.11; daher muss man sich das selber kompilieren, was aber kein großes Problem ist. Ich bin dieser Anleitung gefolgt, wobei man natürlich manche Schritte nicht als sudo machen müsste. Die saubere PATH habe ich aber befolgt. (Update 04.10.15: MacPorts ist in einer neuen Version veröffentlicht worden.)
  • gpg habe ich mittels sudo port install gnupg installiert. Hat seltsamerweise zwei Anläufe gebraucht, vielleicht war es auch nur ein Verbindungsproblem.
  • RVM hat wohl die Skripte mittlerweile angepasst und stolpert nicht mehr über das fehlende apple-gcc42
  • RVM dann wie gehabt installieren. Seltsamerweise war bei mir automatisch homebrew aktiv (obwohl MacPorts verfügbar sind); lässt sich bekanntlich aber mit rvm autolibs macports lösen. (Update 04.10.15: Das Problem hatte ich auf einem anderen System nicht mehr.)

OS X 10.10 Yosemite, RVM und MacPorts/HomeBrew

Nach dem Update auf Yosemite funktionieren die bisher installierten Rubies via RVM nicht mehr, und man muss diese neu installieren. Schlimmer noch, das dies aber nicht so ohne weiteres geht.

Legen wir los.

1. Aktuelles Xcode

Nach der Installation sollte man das aktuelle Xcode 6.1 installieren. Das ist aktuell noch nicht via MAS (Mac App Store) verfügbar, liegt aber im Apple Developer Center zur Verfügung.

Angeblich reichen mittlerweile auch die Command Line Utils, das habe ich nicht ausprobiert. (Xcode bietet ja auch den iOS Simulator, daher ganz praktisch…)

Gegebenenfalls muss man den MAS nochmals aufsuchen und die Updates prüfen. Bei mir erschienen da Folge-Updates für Xcode; die hießen zwar Command Line Utils, waren es aber scheinbar nicht?!

2. Command Line Utils

In dem Terminal kann man mit xcode-select –install dafür sorgen, dass die Verfügbarkeit der Command Line Utils gewährleistet ist. Falls nicht, dann den kommenden Dialog bejahen und warten.

3.1 MacPorts

Falls die MacPorts vor dem Update installiert waren, dann muss man eine Migration durchführen (einfach port ausführen, dann erhält man den Hinweis). Falls man nicht unbedingt die alten Ports braucht (man installiert sich die notwendigen dann eh neu), dann kann man auch einfach alle weg schmeißen: (a) Einfach die neuen MacPorts via macports.org runterladen und neu installieren, dann (b) alle deinstallieren mit sudo port -f uninstall installed und anschließend (c) alles Informationen löschen sudo port clean all ausführen. Die letzten beiden Schritte dauern ein paar Minuten.

3.2 HomeBrew

Falls HomeBrew installiert war, dann hier schauen, aber das sollte man sich überlegen. Ich würde da im Zweifel auch eher einen Kahlschlag machen. Man hat da eh meistens in der Vergangenheit Dinge installiert, die man gar nicht mehr braucht.

4 RVM

Wir brauchen auf jeden Fall die neuste Version: rvm get stable

Bei mir hat RVM bei einem Upgrade die Autolibs (also den zu verwendenen Default Package Manager) von MacPorts zu HomeBrew gewechselt, daher muss man ggf. rvm autolibs macports ausführen. (Hinweis: Das gilt ab sofort, das heißt bereits offene Shells laufen noch mit der alten Einstellung!)

Da bereits Rubies und Gemsets vorhanden sein werden, sollte man diese alle entfernen (sie linken teilweise auf nicht mehr korrekte Ports/Brews): rvm remove all

Auch löschen wir alle lokalen Informationen: rvm cleanup all

4.1 RVM und apple-gcc42

Sowohl die Variante über MacPorts als auch HomeBrew stolpern aktuell bei der Installation von älteren Rubyversionen über den Compiler apple-gcc42. Beide wollen diesen installieren, aber das funktioniert nicht (mehr?) unter OS X 10.10 / Darwin 14.

Allerdings braucht das Kompilieren von Ruby nicht zwangsläufig GCC, sondern läuft auch mit clang: rvm install 1.9.3 –with-gcc=clang läuft wunderbar — sowohl unter MacPorts als auch HomeBrew. Beim aktuellen Ruby 2.1.3 ist das nicht mehr notwendig.

5. RVM Autoinstall

Unter Berücksichtigung von Projekten mit alten Rubies (siehe Schritt 4.1), funktioniert jetzt die automatische Installation von Ruby, Gemset und deren Path-Aktivierung auch für Gemfile. Die ~/.rvmrc benötigt dafür ja nur:

rvm_install_on_use_flag=1
rvm_autoinstall_bundler_flag=1
rvm_gemset_create_on_use_flag=1

Broken Java Key&Trust Store on OSX

Sometimes Java applications do not find the internal Key- and Truststore (where all well known SSL roots are listed). Last one was Minecraft on OS X 10.9 with installed JRE6, JDK7 and JDK8. Even a pre-defined $JAVA_HOME did not help.

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Hopefully, this fix should help you. 

# Sometimes some Java applications will not work because the internal references to the trusted libs are broken.
# Unless '/System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security' does not exist, this should help
$ sudo mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
$ cd /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
$ sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/security/cacerts
$ sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/security/blacklist
$ sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/lib/security/trusted.libraries

OS X 10.9 Mavericks: SourceTree funktioniert nicht mehr, kein Git-Svn mehr?

Auch nach einer manuellen Neuinstallation der MacPorts funktioniert Git-Svn und damit auch Tools wie SourceTree nicht mehr, weil Libraries (hier zu Perl) nicht mehr gefunden werden.

Temporäre Abhilfe verschaffen hier  zwei Symlinks.

sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/SVN /System/Library/Perl/Extras/5.16/SVN
sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/auto/SVN/ /System/Library/Perl/Extras/5.16/auto/SVN

OS X 10.9 Mavericks: Kostenloses iWorks Update für DVD-Kunden

Aktuell wird für Kunden, die die iWorks Suite noch von einem DVD-Datenträger installiert haben (und eben nicht via Mac App Store), kein kostenloses Update für Keynote, Pages und Numbers angeboten — zumindest in Deutschland.

Stellt man seine Systemsprache auf Englisch und bootet neu (vielleicht reicht auch aus- und einloggen), dann werden die kostenlosen Updates angeboten.

Danke für den Tipp!

Ach ja, übrigens: Weil das Upgrade durchaus Features weniger hat, empfiehlt sich unter Umständen ein Backup der alten Software. Prinzipiell sind die ja auch beide parallel lauffähig.

OS X 10.9 Mavericks: Kein M2_HOME mehr in IntelliJ IDEA

Nach dem Update auf Mavericks hat sich auch unter der Haube einiges an Libraries getan. So ist nicht nur das System-Ruby auf Version 2 angehoben worden, sondern auch Maven wurde nebst Java jetzt wirklich komplett entfernt.

Damit man in IntelliJ IDEA nicht in jedem Projekt separat die Maven-Konfiguration nachpflegen muss, muss man nun Maven auch selber installieen (musste man vorher auch, wenn man eine andere Version als den Default haben wollte). Leider erhalten GUI-Anwendungen unter OS X nicht einfach alle Umgebungsvariablen (aus dem Enviroment, ~/.bash_profile usw.). Seit 10.8 und 10.9 muss man wohl tatsächlich, will man globale Variablen anlegen, diese im Launch Daemon registrieren. Dies wiederum kann man aber bspw. in seiner ~/.bash_profile machen.

Das sieht bei mir nun wie folgt aus:

export M2_HOME=~/bin/apache-maven-3.0.5
export M2=$M2_HOME/bin
launchctl setenv M2_HOME $M2_HOME
launchctl setenv M2 $M2

Darüber hinaus schadet es auch nicht, eine funktionierende JAVA_HOME Variable anzulegen, weil manche stumpfsinnigen OSX-Anwendungen einfach nicht in der Lage sind ohne auszukommen:

export JAVA_HOME=$(/usr/libexec/java_home)
launchctl setenv JAVA_HOME $JAVA_HOME

Und wenn wir einmal dabei sind, aktualisieren wir noch den Pfad.

launchctl setenv PATH $PATH

Wahlweise kann man hier natürlich auch das $M2 hinzufügen ($PATH:$M2), wenn man den Befehl „mvn“ auch im Pfad haben will.

Kurz notiert: Installieren von git-svn mit den aktuellen MacPorts unter OS X Lion [Update]

Unter Updating Xcode and MacPorts for OSX Lion findet man die schnelle Antwort, was man machen muss.

Kurz: port install git +svn ist die Lösung!

Update (29. Mai 2012): Seit MacPorts 2.1 hat sich das nun geändert: port install git-core +svn

Ändern einer IP-Route als User (Mac OS X) // sudoers [Update]

Im Zuge einer Überarbeitung meiner VPN-Firewall-Gateway-VM stolperte ich wieder über den Routing-Activator. Dieses kleine Script macht nichts anderes, als das externe VPN-Netzwerk über eine Gateway-VM zu routen. Da jedoch route zwingend root-Rechte benötigt, musste ich bei jedem VPN-Aufbau (sprich: Starten der VPN-Gateway-VM) oder einem Netzwerk-Neustart ein sudo /path/to/your/script via Terminal abfeuern — inklusive lästiger Passworteingabe.

Okay. Gehen wir das Problem an!

Das eigentliche Problem ist, das route nur als superuser ausgeführt werden darf. Für solche Fälle gibt es die sudoers-Datei, welche in Kurzform beschreibt, welche User welche Befehle als superuser ausführen dürfen. In der Regel landen dort manchmal Services (wenn ein Service bspw. zwar als Superuser gestartet werden muss, aber eigentlich im Kontext eines normalen Benutzers läuft und gesteuert wird) oder bestimmte Systembefehle.

Nun könnte man natürlich route für den eigenen Benutzer komplett freischießen, aber dann gelte dieser Freibrief für alle Prozesse. Nein, das will man auch nicht. Eigentlich soll ja nur die eine Route erlaubt werden. Und da praktischerweise diese Konfiguration bereits als ein Script — /path/to/your/script — vorliegt, wird einfach dieses dort eingetragen. Dabei sind jedoch einige Vorsichtsmaßnahmen zu treffen.

  1. Mit dem Befehl sudo visudo öffnet man eine spezielle Instanz von vi zum Editieren der sudoers.
  2. Ganz am Ende trägt man eine weitere Zeile an (man kann sich an den Beispielen orientieren):

    Damit erlaubt man dem Benutzer USER das Ausführen des definierten Commands ohne Passwortabfrage.
    Sollte das Script natürlich woanders liegen, so muss das angepasst werden (irgendwie klar, oder?) Man kann auch andere Muster (beispielsweise ganze Gruppen) oder andere Modi wählen (siehe dazu man sudoers).
  3. Wichtig: Um jegliches Sicherheitsrisiko zu vermeiden, sollte man unbedingt das Script danach abschotten. Dazu werden die Rechte auf das mindeste entfernt.
    1. sudo chmod -w /path/to/your/script entfernt für alle Benutzer das Schreibrecht (muss man es dennoch editieren, geht es mit sudo vi und einem abschließenden :wq! natürlich dennoch).
    2. sudo chown root /path/to/your/script übertragt das Script dem Root-Benutzer, um eine nachträgliche Rechte-Änderung ohne Passwort zu verhindern.
  4. Fertig. Das Script kann nun mit sudo /path/to/your/script nun mit Rechten des superuser gestartet werden (ohne Passwort) und ist gleichzeitig ohne administrative Rechte nicht mehr änderbar.

Skype 5 for Mac: Themes

Gerade herausgefunden: Skype unterstützt Themes für die Nachrichten.

Allerdings muss man erstmal suchen, denn es findet sich weder eine In-App Download-Möglichkeit noch ein Verzeichnis von Skype selber. Vor über einem Jahr haben die zwar macthemes.sykpe.com präsentiert, diese Domain ist jedoch mittlerweile offline.

Es gibt aber dann immerhin ein kleine Liste unter joemiller.me/2011/05/24/alternative-skins-for-skype-5-on-mac-osx. Gefallen tut mir da spontan Brief (Webseite, Sourcen bei GitHub). Ist etwas kompakter und im Skype/Mac-Style. Schön.

Zum Installieren reicht dieses Snippet. Danach einfach Skype neu starten.