Installer des applications macOS natives

Relution permet de téléverser des applications macOS natives de manière centralisée dans l’App Store et de les distribuer sur les Mac gérés. Les formats de fichier pris en charge sont .pkg (paquet d’installation) et .dmg (image disque). Pour une distribution fiable et sans surveillance, la combinaison d’un format de paquet adapté, d’une règle de détection correcte et d’une signature valide est déterminante. Les sections suivantes décrivent ces éléments en détail.

Comparaison entre PKG et DMG #

Le choix du format de paquet détermine la manière dont une application est installée et si le processus peut être automatisé.

Un .pkg est le format le plus robuste pour la distribution automatisée, car la routine d’installation est contenue dans le paquet lui-même et peut s’exécuter silencieusement en arrière-plan. Les scripts intégrés au paquet peuvent prendre en charge des étapes supplémentaires, par exemple la création de fichiers de configuration.

Un .dmg est une image de support de données. Il ne convient à la distribution que s’il contient un seul fichier programme (.app) qui est copié vers /Applications. Les images comportant un assistant d’installation interactif ou plusieurs éléments ne peuvent pas être installées sans surveillance.

Une différence essentielle concerne le canal de distribution : les applications .pkg sont installées directement via le protocole MDM, tandis que les applications .dmg sont déployées via le Relution Companion. Pour la distribution d’applications DMG, le Companion doit donc être disponible sur le Mac.

Remarque : si une application est proposée à la fois en .pkg et en .dmg, le .pkg est à privilégier pour la distribution centralisée.

Créer une application native dans Relution #

Le téléversement s’effectue comme pour les autres applications natives, via l’inventaire des applications.

1. Dans le menu sous Apps → App Store, le type d’application Application native est sélectionné via Ajouter.
2. Le fichier .pkg ou .dmg correspondant est sélectionné et téléversé.
3. Ajouter des détails ouvre la page de détail de l’application. Le nom de version et — si nécessaire — la règle de détection y sont saisis.
4. Après indication du statut de publication souhaité, l’application est créée via Enregistrer.

Gestion des versions et statut de publication #

Les applications macOS natives permettent en outre une gestion des versions : différentes versions d’une application peuvent être mises à disposition en parallèle pour différents groupes de personnes. Une version peut ainsi être en usage productif pendant qu’une nouvelle version est testée par un groupe restreint, sans que les autres utilisateurs en soient affectés.

Chaque version passe par l’un des statuts suivants :

• Productif : version distribuée et installée normalement via le Relution Agent.
• Développement ou Vérification : statut des versions testées avant leur mise en production.
• Archive : statut d’une version antérieure remplacée par une version productive plus récente.

Tester une nouvelle version en parallèle #

Pour tester une nouvelle version en parallèle de la version productive existante, celle-ci est téléversée via le bouton Nouvelle version puis placée dans le statut Développement ou Vérification. Une date de publication peut éventuellement être renseignée, à laquelle la version passe automatiquement au statut Productif. Les deux versions restent consultables dans les propriétés de l’application ; les utilisateurs disposant des droits correspondants peuvent déjà voir, installer et tester la nouvelle version sur les appareils.

Mise en production manuelle #

En alternative au basculement automatique via la date de publication, une version peut être placée manuellement dans ce statut sur la page de détail de l’application, via le bouton Productif. Une version déjà productive est alors automatiquement déplacée vers le statut Archive.

Règle de détection via l’identifiant de bundle #

La règle de détection indique à Relution à quoi reconnaître l’état installé d’une application. Pour les applications macOS natives, cela passe par l’identifiant de bundle (par exemple com.fabricant.nomapplication). Cette valeur unique permet de vérifier sur l’appareil si l’application est déjà présente et si une installation est considérée comme réussie.

La méthode la plus fiable pour déterminer l’identifiant de bundle correct passe par un Mac déjà géré :

1. L’application est installée une fois manuellement sur un Mac géré dans Relution.
2. Dans le portail Relution, l’appareil est ouvert sous Appareils → Aperçu.
3. L’application est recherchée dans l’onglet des applications installées. L’identifiant de bundle qui y figure est relevé.
4. Cette valeur est saisie comme règle de détection sur la page de détail de l’application.

L’identifiant de bundle peut également être lu directement sur le Mac via le Terminal :

osascript -e 'id of app "Nom-de-l-application"'

Si le chemin du fichier programme est connu, la valeur peut aussi être lue dans les métadonnées du paquet :

mdls -name kMDItemCFBundleIdentifier -raw /Applications/Nom-de-l-application.app

Si la règle de détection doit être déterminée avant une installation, le contenu d’un .pkg peut être inspecté avec un outil tiers tel que Suspicious Package. Un tel outil affiche, outre les chemins d’installation et les scripts contenus, l’identifiant de bundle, sans que le paquet doive être exécuté.

Remarque : les outils tiers servent exclusivement à l’analyse. L’identifiant de bundle déterminant reste la valeur indiquée dans l’inventaire Relution après une installation.

Alternatives en l’absence de détection fonctionnelle #

Pour certaines applications natives, Relution ne peut pas vérifier de manière fiable l’état installé — par exemple parce qu’aucun identifiant de bundle unique n’existe ou parce que le paquet place l’application à un emplacement inhabituel. Dans ces cas, deux approches se passent d’une règle de détection fiable :

• Mise à disposition via l’App Store Relution : l’application est mise à disposition des utilisateurs dans le Relution Agent et y est installée manuellement. L’installation étant déclenchée activement, aucune vérification automatique de l’état n’est nécessaire. L’application peut éventuellement être liée à un utilisateur ou à un groupe d’utilisateurs comme application à installer automatiquement (auto-deploy).
• Distribution par action : une action Installer l’application sur des appareils ou des groupes sélectionnés déclenche l’installation de manière ciblée. La commande d’installation est transmise à l’appareil et y est exécutée, indépendamment d’une règle de détection.

Signature et notarisation #

macOS vérifie via Gatekeeper si un logiciel provient d’une source fiable. Les paquets qui ne sont ni signés ni notarisés par Apple peuvent être bloqués ou exiger une interaction de l’utilisateur, ce qui empêche une distribution sans surveillance.

• Signature : le paquet est signé avec un Developer ID valide. L’origine est ainsi traçable et toute manipulation exclue.
• Notarisation : le paquet a en outre été vérifié par Apple (notarisé). Ce n’est qu’alors qu’il est accepté sans avertissement sur les versions récentes de macOS.

La signature et la notarisation d’un paquet peuvent être vérifiées sur le Mac dans le Terminal :

spctl --assess --type install -vv /chemin/vers/App.pkg
pkgutil --check-signature /chemin/vers/App.pkg

Remarque : si une installation échoue silencieusement pour certains paquets seulement, l’absence de signature ou de notarisation en est l’une des causes les plus fréquentes.

Analyse des erreurs via les journaux et la journalisation des appareils #

Si une installation reste sans succès, les causes peuvent être circonscrites à l’aide de la journalisation.

Journalisation des appareils dans Relution #

La journalisation des appareils est activée au niveau global dans l’inventaire, via les appareils, et enregistre la communication entre le serveur et les appareils. Une fois activée, les commandes telles que l’installation d’application sont journalisées avec la réponse de l’appareil et peuvent être consultées dans le portail. Il devient ainsi visible si une commande d’installation a atteint l’appareil et avec quel statut elle a été acquittée.

Journaux d’installation sur le Mac #

En complément, les journaux système du Mac renseignent sur le déroulement de l’installation. Le déroulement d’une installation PKG est journalisé localement et peut être analysé dans le Terminal :

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

Pour une observation en continu pendant une installation, le flux en direct du journal système est adapté :

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

Ces sorties permettent de déterminer si le paquet a été décompressé, si un script a été exécuté ou si le processus a été interrompu par Gatekeeper.

Désinstallation #

Les applications macOS natives installées via Relution peuvent également être désinstallées via Relution — aussi bien les applications .pkg que .dmg. Un identifiant de bundle (règle de détection) est requis pour adresser l’application de manière univoque sur l’appareil. Sans identifiant de bundle valide, aucune désinstallation n’est déclenchée. Comme pour l’installation, la suppression passe par des canaux différents selon le format — .pkg via MDM, .dmg via le Companion — mais la procédure dans le portail est identique.

Deux voies existent pour la désinstallation :

• De manière ciblée via une action : l’action Supprimer l’application sur des appareils ou des groupes sélectionnés désinstalle l’application. Dans l’historique des commandes de l’appareil, l’opération apparaît sous la forme désinstaller <identifiant-de-bundle>.
• Automatiquement lors de la suppression de l’attribution : si une application précédemment mise à disposition automatiquement (auto-deploy) est retirée de la conformité des applications, Relution peut la désinstaller automatiquement. Cela ne fonctionne toutefois que si l’option de suppression des applications mises à disposition automatiquement est activée dans la configuration de conformité des applications — sinon, l’application reste installée sur l’appareil.

Ne peuvent pas être supprimées via Relution : les applications sans identifiant de bundle ainsi que les applications installées manuellement, en dehors de Relution. Pour les applications .dmg, un Relution Companion disponible est en outre nécessaire ; s’il est désactivé ou inutilisable sur l’appareil, aucune désinstallation via Relution n’est possible. Dans ces cas, la suppression est mise en œuvre par un script qui ferme l’application et supprime les répertoires associés, script distribué de manière ciblée via une action.