Native macOS-Apps installieren

Mit Relution lassen sich native macOS-Anwendungen zentral in den App Store hochladen und auf verwaltete Macs verteilen. Als Dateiformate werden .pkg (Installer-Paket) und .dmg (Disk Image) unterstützt. Für eine zuverlässige, unbeaufsichtigte Verteilung ist das Zusammenspiel aus passendem Paketformat, korrekter Erkennungsregel sowie gültiger Signierung entscheidend. Die nachfolgenden Abschnitte beschreiben diese Bestandteile im Detail.

PKG und DMG im Vergleich #

Die Wahl des Paketformats bestimmt, wie eine App installiert wird und ob sich der Vorgang automatisieren lässt.

Ein .pkg ist für die automatisierte Verteilung das robustere Format, da die Installationsroutine im Paket selbst hinterlegt ist und still im Hintergrund ausgeführt werden kann. Skripte innerhalb des Pakets können zusätzliche Schritte übernehmen, etwa das Anlegen von Konfigurationsdateien. Beim Hochladen liest Relution die Distribution-Datei des Pakets aus und übernimmt daraus Produkt-ID und Version. Pakete ohne Distribution-Datei (reine Komponentenpakete) werden als nicht unterstützte Datei abgelehnt.

Ein .dmg ist ein Datenträger-Abbild. Für die Verteilung ist es nur dann geeignet, wenn es eine einzelne Programmdatei (.app) enthält, die nach /Applications (im Finder: Programme) kopiert wird. Abbilder mit einem interaktiven Installations-Assistenten oder mehreren Elementen lassen sich nicht unbeaufsichtigt installieren.

Ein wesentlicher Unterschied betrifft den Verteilkanal: .pkg-Apps werden direkt über das MDM-Protokoll installiert, während .dmg-Apps über den macOS Companion ausgebracht werden. Voraussetzung ist, dass der macOS Companion unter Einstellungen → Relution Client Apps über macOS Companion aktivieren eingeschaltet ist. Auf Macs mit einer macOS-Version vor 12 sowie auf Macs mit Benutzer-Einschreibung steht der macOS Companion nicht zur Verfügung; DMG-Apps lassen sich dort nicht verteilen.

Hinweis: Steht eine App sowohl als .pkg als auch als .dmg zur Verfügung, ist für die zentrale Verteilung das .pkg vorzuziehen.

Native App in Relution anlegen #

Native macOS-Apps werden im Menü unter Apps → App Store angelegt. Die Schaltfläche Hinzufügen öffnet den Dialog Neue Apps hinzufügen. Unter Quelle wird Native App gewählt.

Nach einem Klick auf Weiter wird über Datei wählen die .pkg- oder .dmg-Datei hochgeladen. Details hinzufügen öffnet anschließend das Formular App hinzufügen.

Im Formular sind folgende Angaben erforderlich:

• Interner Name: Bei .pkg-Dateien wird die Produkt-ID aus der Distribution-Datei übernommen. Bei .dmg-Dateien ist der Dateiname als Platzhalter vorbelegt und wird durch einen eindeutigen Namen ersetzt. Existiert bereits eine App mit demselben internen Namen, wird beim Speichern eine neue Version dieser App angelegt.
• Versions-Name: Bei .pkg-Dateien wird die Version aus der Distribution-Datei übernommen, bei .dmg-Dateien wird sie von Hand eingetragen.
• Erkennungsregeln: Im gleichnamigen Abschnitt wird mindestens eine Erkennungsregel eingetragen – ohne Erkennungsregel lässt sich die App nicht speichern (siehe Abschnitt zur Erkennungsregel weiter unten).

Nach Angabe des gewünschten Freigabestatus wird die App über Speichern angelegt.

Versionsverwaltung und Freigabestatus #

Für native macOS-Apps lässt sich zusätzlich ein Release-Management betreiben: Verschiedene Versionen einer App können parallel für unterschiedliche Personengruppen bereitgestellt werden. So kann etwa eine Version im produktiven Einsatz sein, während eine neue Version durch eine ausgewählte Gruppe getestet wird, ohne dass die übrigen Anwender davon betroffen sind.

Jede Version durchläuft dabei einen der folgenden Status:

• Produktiv: Version, die regulär über den Relution Agent verteilt und installiert wird.
• Entwicklung bzw. Prüfung: Status für Versionen, die vor der Produktivsetzung getestet werden.
• Archiv: Status einer früheren Version, die durch eine neuere Produktiv-Version abgelöst wurde.

Mit Ausnahme des Status Archiv kann sich in jedem Freigabestatus nur eine Version der App befinden.

Neue Version parallel testen #

Soll eine neue Version parallel zur bestehenden produktiven Version getestet werden, wird diese über die Schaltfläche Neue Version hochgeladen und zunächst in den Status Entwicklung oder Prüfung versetzt. Bei .pkg-Dateien muss der interne Name der neuen Version mit dem der bestehenden App übereinstimmen. Bei .dmg-Dateien kann eine Abweichung über Nicht übereinstimmende interne App-Namen ignorieren zugelassen werden.

Für die neue Version lässt sich im Feld Go-Live Datum ein Termin hinterlegen. Automatisch in den Status Produktiv wechselt die Version an diesem Tag nur, wenn ein App-Freigabeprozess → aktiv ist und die Version im Status Prüfung alle Freigabeschritte durchlaufen hat. Ohne aktiven Freigabeprozess dient das Datum nur als Wunschtermin, und die Version wird manuell in den Status Produktiv versetzt (siehe unten).

Beide Versionen sind währenddessen in den App-Eigenschaften einsehbar; Anwender mit entsprechender Berechtigung können die neue Version bereits auf Endgeräten sehen, installieren und testen.

Manuelle Produktivnahme #

Liegt die neue Version im Status Prüfung, wird sie auf der App-Detailseite über die Schaltfläche Produktiv in diesen Status versetzt. Liegt sie noch in Entwicklung, erfolgt der Wechsel über Verschieben → Produktiv. Eine bereits produktive Version wird dabei automatisch in den Status Archiv verschoben. Veröffentlichte Versionen globaler Apps lassen sich nicht in einen anderen Status verschieben.

Erkennungsregel über den Bundle-Identifier #

Die Erkennungsregel teilt Relution mit, woran der installierte Zustand einer App erkannt wird. Für native macOS-Apps steht dafür der Regeltyp Package Name zur Verfügung. Eingetragen wird der Bundle-Identifier der installierten App (z. B. com.hersteller.appname); zulässig sind Buchstaben, Ziffern, Punkte und Bindestriche. Anhand dieses Werts wird in der Liste der installierten Apps des Geräts geprüft, ob die App bereits vorhanden ist und ob eine Installation als erfolgreich gilt.

Erkennungsregeln werden im Abschnitt Erkennungsregeln über Neue Erkennungsregel hinzufügen angelegt – beim Hochladen im Formular App hinzufügen, bei bestehenden Apps auf der App-Detailseite im Reiter Einstellungen. Optional vergleicht ein Versionscheck zusätzlich die installierte Version: Unter Operator wird Version ist gleich (=) oder Version ist nicht gleich (≠) gewählt und unter Wert die Version eingetragen. Eine App kann mehrere Erkennungsregeln haben, etwa wenn ein Paket mehrere Apps installiert. Als installiert gilt die App nur, wenn alle Regeln zutreffen.

Der zuverlässigste Weg, den korrekten Bundle-Identifier zu ermitteln, führt über einen bereits verwalteten Mac:

1. Die App wird auf einem in Relution verwalteten Mac einmalig manuell installiert.
2. Im Relution-Portal wird das Gerät unter Geräte → Inventar geöffnet.
3. Auf dem Reiter Installierte Apps wird die App gesucht. Der Bundle-Identifier steht in der Spalte Interner Name.
4. Dieser Wert wird in der Erkennungsregel im Feld Package Name eingetragen.

Alternativ lässt sich der Bundle-Identifier direkt auf dem Mac über das Terminal auslesen:

osascript -e 'id of app "App-Name"'

Ist der Pfad der Programmdatei bekannt, kann der Wert auch aus dem Paket-Metadatum gelesen werden:

mdls -name kMDItemCFBundleIdentifier -raw /Applications/App-Name.app

Soll die Erkennungsregel bereits vor einer Installation ermittelt werden, kann der Inhalt eines .pkg mit einem Drittanbieter-Werkzeug wie Suspicious Package inspiziert werden. Ein solches Werkzeug zeigt neben den Installationspfaden und enthaltenen Skripten auch den Bundle-Identifier an, ohne dass das Paket ausgeführt werden muss.

Hinweis: Drittanbieter-Werkzeuge dienen ausschließlich der Analyse. Der maßgebliche Bundle-Identifier bleibt der Wert, der nach einer Installation im Relution-Inventar ausgewiesen wird.

Alternative Wege ohne funktionierende Erkennung #

Bei manchen nativen Apps kann Relution den installierten Zustand nicht zuverlässig prüfen – etwa weil kein eindeutiger Bundle-Identifier vorliegt oder das Paket die App an einen untypischen Ort ablegt. Eine automatische Installation über die App Konformität eignet sich in diesen Fällen nicht: Relution erkennt eine PKG- oder DMG-App nur dann als installiert, wenn alle Erkennungsregeln erfüllt sind. Andernfalls wird die Installation bei jeder Konformitätsprüfung erneut eingeplant.

Zwei Wege kommen ohne belastbare Erkennungsregel aus:

• Bereitstellung über den Relution App Store: Die App wird den Benutzern im Relution Agent bereitgestellt und dort manuell installiert. Da die Installation aktiv angestoßen wird, ist keine automatische Zustandsprüfung nötig.
• Verteilung per Aktion: Über die Aktion Relution Store App bereitstellen auf ausgewählten Geräten oder Gruppen wird die Installation gezielt ausgelöst. Der Installationsbefehl wird an das Gerät übertragen und dort ausgeführt, unabhängig von einer Erkennungsregel.

Signierung und Notarisierung #

macOS prüft über Gatekeeper, ob Software aus einer vertrauenswürdigen Quelle stammt. Pakete, die weder signiert noch von Apple notarisiert sind, können blockiert werden oder eine Nutzerinteraktion erfordern – was eine unbeaufsichtigte Verteilung verhindert.

• Signierung: Das Paket ist mit einer gültigen Developer ID signiert. Dadurch ist die Herkunft nachvollziehbar und Manipulation ausgeschlossen.
• Notarisierung: Das Paket wurde zusätzlich von Apple geprüft (notarisiert). Erst dadurch wird es auf aktuellen macOS-Versionen ohne Warnhinweis akzeptiert.

Ob ein Paket korrekt signiert und notarisiert ist, kann auf dem Mac im Terminal überprüft werden:

spctl --assess --type install -vv /Pfad/zur/App.pkg
pkgutil --check-signature /Pfad/zur/App.pkg

Hinweis: Schlägt eine Installation nur bei einzelnen Paketen still fehl, ist eine fehlende Signierung oder Notarisierung eine der häufigsten Ursachen.

Fehleranalyse per Logs und Geräteprotokollierung #

Bleibt eine Installation ohne Erfolg, lassen sich die Ursachen über die Protokollierung eingrenzen.

Geräteprotokollierung in Relution #

Die Geräteprotokollierung wird in der globalen Organisation für ein einzelnes Gerät eingeschaltet: Im Geräte-Inventar wird das Gerät ausgewählt und über Geräteprotokollierung verwalten die Option Gerätebasierte Protokollierung aktivieren für die unter Dauer (in Minuten) angegebene Zeit gesetzt. In diesem Zeitraum werden Befehle wie die App-Installation samt Rückmeldung des Geräts protokolliert. Die erfassten Geräteprotokolle werden im selben Dialog als Datei heruntergeladen. Auf diese Weise wird sichtbar, ob ein Installationsbefehl das Gerät erreicht hat und mit welchem Status er quittiert wurde.

Installationslogs am Mac #

Ergänzend geben die Systemprotokolle des Macs Aufschluss über den Installationsvorgang. Der Verlauf einer PKG-Installation wird lokal protokolliert und kann im Terminal ausgewertet werden:

tail -n 100 /var/log/install.log

Für die laufende Beobachtung während einer Installation eignet sich der Live-Datenstrom des Systemprotokolls:

log stream --predicate 'process == "installer"' --info

Aus diesen Ausgaben lässt sich ablesen, ob das Paket entpackt, ein Skript ausgeführt oder der Vorgang durch Gatekeeper abgebrochen wurde.

Deinstallation #

Native macOS-Apps, die über Relution installiert wurden, lassen sich über Relution auch wieder deinstallieren – sowohl .pkg- als auch .dmg-Apps. Voraussetzung ist ein Bundle-Identifier (Erkennungsregel), über den die App auf dem Gerät eindeutig adressiert wird. Ohne gültigen Bundle-Identifier wird keine Deinstallation ausgelöst. Wie schon bei der Installation läuft die Entfernung je nach Format über unterschiedliche Kanäle – .pkg über MDM, .dmg über den macOS Companion –, das Vorgehen im Portal ist jedoch identisch.

Für die Deinstallation bestehen zwei Wege:

• Gezielt über eine Aktion: Über die Aktion App entfernen auf ausgewählten Geräten oder Gruppen wird die App deinstalliert. In der Befehlshistorie des Geräts erscheint der Vorgang als <Bundle-Identifier> deinstallieren.
• Automatisch beim Wegfall der Zuweisung: Wird eine App, die über die App Konformität automatisch installiert wurde (Häkchen in der Spalte Auto Installation), nach einer Änderung oder Entfernung der Richtlinie nicht mehr gefordert, deinstalliert Relution sie automatisch. Anders als unter iOS bietet die macOS-Konfiguration App Konformität keine Option, diese Deinstallation abzuschalten.

Nicht über Relution entfernen lassen sich Apps ohne Bundle-Identifier sowie manuell – außerhalb von Relution – installierte Apps. Bei .dmg-Apps ist zusätzlich der macOS Companion erforderlich; ist dieser deaktiviert oder auf dem Gerät nicht einsetzbar (macOS vor Version 12, Benutzer-Einschreibung), ist keine Deinstallation über Relution möglich. In diesen Fällen wird die Entfernung über ein Skript umgesetzt, das die App beendet und die zugehörigen Verzeichnisse entfernt und gezielt über eine Aktion verteilt wird.