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. Lors du téléversement, Relution lit le fichier Distribution du paquet et en reprend l’identifiant de produit et la version. Les paquets sans fichier Distribution (simples paquets de composants) sont refusés comme fichier non pris en charge.

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 Compagnon macOS. Le Compagnon macOS doit pour cela être activé sous Paramètres → Applications client Relution via Activer le compagnon macOS. Il n’est pas disponible sur les Mac dotés d’une version de macOS antérieure à 12 ni sur les Mac inscrits par inscription utilisateur ; les applications DMG ne peuvent pas y être distribuées.

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 #

Les applications macOS natives sont créées dans le menu sous Apps → App Store. Le bouton Ajouter ouvre la boîte de dialogue Ajouter une nouvelle application. Sous Source, l’option Appli native est sélectionnée.

Après un clic sur Suivant, le fichier .pkg ou .dmg est téléversé via Choisissez un fichier. Ajouter des détails ouvre ensuite le formulaire Ajouter une application.

Les indications suivantes sont obligatoires dans le formulaire :

• Nom interne : pour les fichiers .pkg, l’identifiant de produit est repris du fichier Distribution. Pour les fichiers .dmg, le nom du fichier est prérempli comme espace réservé et remplacé par un nom unique. Si une application portant le même nom interne existe déjà, l’enregistrement crée une nouvelle version de cette application.
• Nom de la version : pour les fichiers .pkg, la version est reprise du fichier Distribution ; pour les fichiers .dmg, elle est saisie manuellement.
• Règles de détection : au moins une règle de détection est saisie dans la section du même nom – sans règle de détection, l’application ne peut pas être enregistrée (voir la section sur la règle de détection ci-dessous).

Après indication de l’État de la version 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 :

• Statut de production (Version dans le portail) : version distribuée et installée normalement via le Relution Agent.
• Développement ou statut de vérification (Critique dans le portail) : statuts des versions testées avant leur mise en production.
• Archive : statut d’une version antérieure remplacée par une version plus récente au statut Version.

À l’exception du statut Archive, chaque statut ne peut contenir qu’une seule version de l’application.

Tester une nouvelle version en parallèle #

Pour tester une nouvelle version en parallèle de la version en production, celle-ci est téléversée via le bouton Ajouter une nouvelle version puis placée dans le statut Développement ou Critique. Pour les fichiers .pkg, le nom interne de la nouvelle version doit correspondre à celui de l’application existante. Pour les fichiers .dmg, un écart peut être autorisé via Ignorer la non-concordance des noms d’applications internes.

Une date peut être indiquée pour la nouvelle version dans le champ Date de mise en ligne. La version ne passe automatiquement au statut Version à cette date que si un processus de validation des applications → est actif et que la version au statut Critique a franchi toutes les étapes de validation. Sans processus de validation actif, la date ne sert que de date souhaitée, et la version est placée manuellement au statut Version (voir ci-dessous).

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 #

Si la nouvelle version se trouve au statut Critique, elle est placée au statut Version sur la page de détail de l’application via le bouton Version. Si elle se trouve encore au statut Développement, le changement s’effectue via Déplacer vers → Version. Une version se trouvant déjà au statut Version est alors automatiquement déplacée vers l’Archive. Les versions publiées des applications globales ne peuvent pas être déplacées vers un autre statut.

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, le type de règle Nom du paquet est disponible à cet effet. Il contient l’identifiant de bundle de l’application installée (par exemple com.fabricant.nomapplication) ; seuls les lettres, chiffres, points et traits d’union sont autorisés. Cette valeur permet de vérifier dans la liste des applications installées de l’appareil si l’application est déjà présente et si une installation est considérée comme réussie.

Les règles de détection sont créées dans la section Règles de détection via Ajouter une nouvelle règle de détection – lors du téléversement dans le formulaire Ajouter une application, et pour les applications existantes sur la page de détail de l’application dans l’onglet Paramètres. En option, une vérification de la version compare en outre la version installée : sous Opérateur, La version est égale à (=) ou La version n’est pas égale à (≠) est sélectionné, et la version est saisie sous Valeur. Une application peut avoir plusieurs règles de détection, par exemple lorsqu’un paquet installe plusieurs applications. L’application n’est considérée comme installée que si toutes les règles sont remplies.

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 → Inventaire.
3. L’application est recherchée dans l’onglet Apps installées. L’identifiant de bundle figure dans la colonne Nom interne.
4. Cette valeur est saisie dans le champ Nom du paquet de la règle de détection.

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. Une installation automatique via la Conformité App ne convient pas dans ces cas : Relution ne reconnaît une application PKG ou DMG comme installée que si toutes les règles de détection sont remplies. Dans le cas contraire, l’installation est replanifiée à chaque vérification de conformité.

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.
• Distribution par action : l’action Déployer l’application Relution Store 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 pour un appareil individuel dans l’organisation globale : l’appareil est sélectionné dans l’inventaire des appareils, puis Activer la journalisation basée sur l’appareil est réglé via Modifier la journalisation des appareils pour la durée indiquée sous Durée (en minutes). Pendant cette période, les commandes telles que l’installation d’application sont journalisées avec la réponse de l’appareil. Les Journaux des appareils collectés sont téléchargés sous forme de fichier dans la même boîte de dialogue. 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 Compagnon macOS — 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 Supprimez <identifiant-de-bundle>.
• Automatiquement lors de la suppression de l’attribution : si une application installée automatiquement via la Conformité App (case cochée dans la colonne Installation automatique) n’est plus requise après une modification ou une suppression de la politique, Relution la désinstalle automatiquement. Contrairement à iOS, la configuration macOS Conformité App ne propose aucune option pour désactiver cette désinstallation.

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, le Compagnon macOS est en outre nécessaire ; s’il est désactivé ou inutilisable sur l’appareil (macOS antérieur à la version 12, inscription utilisateur), 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.