À partir d’un certain nombre de machines dans un réseau, la gestion des logiciels et des mises à jour peut devenir un vrai cauchemar.
Pour s’en sortir il est nécessaire de prévoir un catalogue logiciel standardisé et centralisé et de disposer un outil de publication automatique (ou sur demande) de ces logiciels et ne nécessitant pas de droit administrateur pour être exécuté coté client. C’est le rôle de munki, maintenir un catalogue logiciel, des dépendances, et installer la chose sur les stations de travail.
Cependant, munki a besoin d’être alimenté, il faut lui indiquer quel logiciel installer, et quelle mise à jour, et dans quel ordre. De fait, il est nécessaire de rester attentif à la sortie de mise à jour des logiciels en catalogue pour les télécharger et les mettre à disposition. Pour automatiser cette tâche, il y a AutoPkg, un outil permettant d’interroger les services de mise à jour des différents logiciels qui vous intéresse pour trouver les mises à jour et les installer sur votre système ou les pousser vers munki.
L’objet de cet article est la prise en main de ces deux outils des plus puissants.
munki
Préparation du serveur
La première chose à faire est de déployer munki sur votre réseau. Munki est un outil extrêmement simple et intelligent. Tout ce qu’il fait, c’est maintenir une base de fichier de dossiers et de fichiers qui feront office de base de données pour les clients. Cette base pouvant être rendu accessible aux clients par HTTP, NFS, etc.
Pour correspondre au plus de situations possible, munki gère plusieurs types de données :
- l’ensemble des applications importées dans la base ;
- des catalogues de logiciel créés à partir de la liste des logiciels disponibles ;
- des manifestes de logiciel créés à partir d’un ou plusieurs catalogues et mettant à disposition tout ou partie des logiciels en référence.
Lorsqu’une station de travail est configurée pour utiliser munki, il est nécessaire de lui indiquer l’adresse du dépôt munki ainsi que le nom du manifeste à utiliser.
Ainsi, un groupe universitaire pourra disposer d’un service munki géré de manière centralisée et maintenir un catalogue logiciel par unité économique, et pour chaque unité, les administrateurs pourront définir des profils de machine de travail (étudiant, enseignant, administratif, etc.).
Pour installer munki, c’est très simple. Il suffit d’un espace de partage de document accessible en lecture seule aux postes clients et en lecture / écriture aux postes administrateurs. Dans les faits, le serveur n’a même pas besoin de disposer de munki, cela peut être un simple partage NFS, WebDAV ou encore un DFS. L’important étant que les postes clients disposent d’un accès consistant à ce partage : chaque poste client étant configuré avec une URL locale ou réseau pour accéder au dépôt, elle doit donc être stable.
Dans mon exemple, je vais mettre à disposition mon dépôt munki à mes postes clients en lecture seule via HTTPS et j’y accèderais comme administrateur via un chemin local.
Commençons par mettre en place les points de partage. Sur un OS X Server, créons simplement un nouveau site web munki.office.storymaker.fr accessible via HTTPS et utilisant un certificat valide.
Dans le dossier créé par OS X Server pour nous, ajoutons un dossier « repos » qui servira de dépôt de travail. Ce dossier doit être accessible en lecture seule pour le service web et en accès complet pour les administrateurs.
Chose légèrement idiote avec munki, l’outil n’est pas capable de créer sa structure de travail tout seul. Aussi, il faudra les créer pour lui.
office:~ ladmin$ cd /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos office:repos ladmin$ mkdir catalogs office:repos ladmin$ mkdir manifests office:repos ladmin$ mkdir pkgs office:repos ladmin$ mkdir pkgsinfo |
Le dépôt étant prêt, installons munki. Pour cela, rendez-vous sur la page de téléchargement du projet munki sur Google Code et récupérez le dmg munkitool puis installez-le sur votre serveur.
Note : à l’heure actuelle, munki est en v1, la v2 est en bêta et ne devrait pas tarder à passer en version finale. Elle fonctionne globalement de la même manière. Si lorsque vous lisez ces lignes, munki 2 est disponible, prenez cette version.
Attention, c’est assez rare, mais munki demande à ce que le système soit redémarré après la première installation. Si vous voulez éviter de redémarrer vos serveurs pour rien, n’hésitez pas à installer munki sur votre machine d’administrateur et à le configurer pour accéder à votre dépôt via un accès en contrôle complet.
Une fois installé, vous disposez d’outils en ligne de commande pour gérer le dépôt munki dans /usr/loca/munki. De plus, une nouvelle application « Mise à jour de logiciels » (« Managed Software Update » en anglais) est disponible dans vos utilitaires pour installer les applications disponibles pour votre machine.
Les outils munki étant installés, il faut configurer le serveur pour s’en servir. Cela se passe en ligne de commande, depuis un compte administrateur. La chose est simple, il suffit de répondre aux questions de l’assistant de configuration.
office:~ ladmin$ munkiimport --configure Path to munki repo (example: /Volumes/repo): /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos Repo fileshare URL (example: afp://munki.example.com/repo): pkginfo extension (Example: .plist): .plist pkginfo editor (examples: /usr/bin/vi or TextMate.app): /usr/bin/nano Default catalog to use (example: testing): default |
Dans l’ordre, les questions posées permettent de configurer :
- le chemin d’accès local au dépôt munki s’il n’est pas distant ;
- le chemin d’accès distant au dépôt munki s’il n’est pas local ;
- l’extension à utiliser pour les fichiers d’information des applications (ce sont des fichiers PLIST/XML) ;
- votre outil préféré pour éditer les fichiers plist (utilisé dans le scénario d’import pour configurer certaines choses comme les dépendances entre logiciels) ;
- le nom du catalogue logiciel par défaut lors de l’import.
Dès à présent, munki est prêt à charger des applications dans sa base. Pour cela, prenons l’exemple du logiciel TextWrangler, un éditeur de texte bien connu.
Chargement d’applications dans la base munki
Une fois le fichier dmg téléchargé sur le site de l’éditeur, inutile d’ouvrir l’image disque, les outils munki sont capable de reconnaitre la majorité des modes de distribution usuels sous Mac. Ainsi, vous pouvez alimenter la base avec des dmg, des pkg et des app directement.
Pour charger TextWrangler dans la base munki, il suffira d’une commande et de quelques indications à donner.
office:~ ladmin$ munkiimport Downloads/TextWrangler_4.5.9.dmg Item name [TextWrangler]: Display name: Description: Le meilleur éditeur de texte ! Version [4.5.9]: Catalogs [default]: Item name: TextWrangler Display name: Description: Le meilleur éditeur de texte ! Version: 4.5.9 Catalogs: default Import this item? [y/n] y Upload item to subdirectory path []: apps Path /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/apps doesn't exist. Create it? [y/n] y Copying TextWrangler_4.5.9.dmg to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/apps/TextWrangler_4.5.9.dmg... Saving pkginfo to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgsinfo/apps/TextWrangler-4.5.9.plist... Rebuild catalogs? [y/n] y Rebuilding catalogs at /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos... |
Comme vous pouvez le voir, munkiimport est capable de trouver la plupart des informations importantes à propos de l’élément importé, et vous pouvez surcharger l’ensemble de ces valeurs.
Durant la phase d’import, vous pouvez également indiquer à munki un sous-dossier pour le stockage des données en elles-mêmes. Cela permet par exemple de classer les éléments par type (apps, updates, office, etc.), très pratique lorsque vous avez une grosse base de logiciel et qu’il faut faire du vide.
Lors de la phase « Saving pkginfo », votre éditeur de fichier plist est automatiquement ouvert pour vous (en l’occurrence, nano), pour vous permettre une édition immédiate du fichier de règles d’installation. Cela permet bien des choses :
- ajouter des scripts de pre et post installation ;
- indiquer que le contenu est une mise à jour pour une application existante, permettant ainsi d’installer la mise à jour automatiquement lors de l’installation du logiciel d’origine ;
- indiquer que le contenu nécessite un autre outil pour fonctionner, pour installer Java avant d’installer Lotus Domino ;
et biens d’autres options encore que je vous laisse découvrir dans la documentation des clefs pkginfo supporté par munki.
Le logiciel étant chargé dans la base munki est accessible via le catalogue « default », il ne reste plus qu’à créer un manifeste pour nos futurs clients.
Si d’aventure vous venez à modifier les fichiers plist de la base munki en dehors du processus d’import (ce qui serait tout à fait normal), il faudra indiquer à munki de prendre en compte ces changements en recréant la base de catalogue via la commande makecatalogs :
office:~ ladmin$ makecatalogs Using repo path: /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos Adding apps/TextWrangler-4.5.9.plist to default... Created catalog /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/catalogs/default... Created catalog /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/catalogs/all... |
Comme vous pouvez le constater, en plus du catalogue que nous avions demandé, munki maintient un catalogue général « all ».
Création d’un manifeste
Pour créer un manifeste, il suffit d’utiliser le shell dédié manifestutil:
office:~ ladmin$ manifestutil Entering interactive mode... (type "help" for commands) > new-manifest dev > add-catalog default --manifest dev Added default to catalogs of manifest dev. > add-pkg TextWrangler --manifest dev Added TextWrangler to section managed_installs of manifest dev. > exit |
Ici, nous commençons par créer un nouveau manifeste nommé dev, il sera utilisé pour désigner les machines de travail dédiées aux développeurs. Ensuite, nous décidons d’ajouter un nouveau catalogue de logiciel disponible pour le manifeste dev. Enfin, nous décidons d’ajouter le paquet TextWrangler à notre manifeste dev pour que celui-ci soit installé automatiquement.
Le nom de paquet utilisé ici et le nom spécifié en « Item Name » durant la phase d’import.
Dès lors, tous clients utilisant notre serveur ainsi que ce manifeste seront incités à installer le logiciel.
Préparation et configuration des postes clients
Du côté des postes clients, il est également nécessaire d’installer les munkitools puis de les configurer. C’est une bonne idée que d’effectuer ces opérations durant votre phase de déploiement du système de base. Dans DeployStudio par exemple.
Une fois les munkitools installés, la configuration est très simple, il suffit d’indiquer l’adresse du serveur et le nom du manifeste à utiliser dans le fichier de configuration du client munki. Cela peut se faire avec la commande defaults et depuis un accès root.
Mac-A:~ ladmin$ sudo -s Password: bash-3.2# defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "https://munki.office.storymaker.fr/repos" bash-3.2# defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "dev" |
Ici, nous avons simplement indiqué l’adresse du serveur web hébergeant le dépôt munki ainsi que le nom du manifeste à utiliser. Ces réglages peuvent également être appliqué via MCX.
Il ne reste plus qu’à lancer l’application « Mise à jour de logiciels » se trouvant dans votre utilitaire. Cette application va rechercher le serveur munki ainsi que la liste des logiciels qu’il doit installer.
Ensuite, le client va regarder les logiciels qu’il doit installer et les mettre en cache sur le disque local.
Enfin, le client va présenter à l’utilisateur la liste des logiciels qu’il doit installer dans une interface des plus familières.
Lorsque l’utilisateur cliquera sur « Mettre à jour », le logiciel lui proposera d’effectuer les opérations en fermant sa session ou en la laissant ouverte.
L’idée est simple ici, les utilisateurs étant globalement indiscipliné, vous pouvez forcer certaines applications à imposer la déconnexion de l’utilisateur pour que la mise à jour se fasse. La chose est automatiquement faite lorsque le logiciel impose un redémarrage après installation.
Note : l’interface de munki 2 a été revue et reprend les canons du Mac App Store.
En arrivant jusque là, vous venez de créer un catalogue logiciel et vous venez de déléguer l’action de mise à jour à vos utilisateurs standard. Dès lorsque vous avez mis à disposition une version validée de vos outils, vos utilisateurs peuvent l’installer sans que vous ayez à lancer des commandes en tant qu’administrateur sur toutes les machines.
Pour finir, munki dispose d’une dernière option particulièrement utile : vous pouvez demander à munki d’installer également les mises à jour système d’Apple. Une simple option supplémentaire dans le fichier de configuration de munki permet cela.
bash-3.2# defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool True |
Une seule chose à faire attention avec cette option, munki dispose de son propre client de mise à jour et ne relis pas les préférences de celui d’Apple. De fait, si vous disposez d’un serveur de mise à jour interne, vous devez l’indiquer à munki également via la clef SoftwareUpdateServerURL.
Il ne reste plus qu’à jouer du munkiimport à chaque mise à jour, et du manifestutil à chaque nouveau logiciel.
AutoPkg
Principe de fonctionnement
AutoPkg est un logiciel qui porte mal son nom de mon point de vue. À tel point que je ne m’étais même pas donné la peine de regarder son fonctionnement au début.
Ce logiciel n’est pas juste un logiciel de création de packages automatisé.
AutoPkg est tout simplement un outil de gestion automatisé de logiciels. Il fonctionne sur une base communautaire de fichier de recettes permettant de savoir où télécharger les logiciels et leurs mises à jour et de s’en servir comme contenu pour des actions pré déterminé.
Ces actions peuvent être le simple téléchargement du logiciel, sa mise en package, ou beaucoup plus intéressant, l’injection du logiciel dans la base munki.
De plus, ce système est totalement extensible, vous pouvez adapter les recettes existantes pour qu’elles ciblent d’autres destinations que celles existantes.
Installation et configuration
Pour que AutoPkg fonctionne au mieux de ses capacités, il est fortement recommandé d’installer git. Git est un système de gestion de version très puissant essentiellement utilisé par les développeurs, mais pas d’inquiétude, vous n’aurez pas à vous en servir directement.
Pour installer git, le plus simple sur un système récent est d’ouvrir un terminal et de taper la commande git. Cela lancera l’outil de mise à jour système qui vous proposera d’installer les outils de développeur en ligne de commande.
Tout ce que vous avez à faire, c’est cliquer sur installer et laisser les choses se faire.
Une fois git installé, il faut installer AutoPkg en téléchargeant la dernière version disponible.
Dans notre scénario, la première chose à faire après l’installation d’AutoPkg est de lui configurer l’emplacement du dépôt munki.
office:~ ladmin$ defaults write com.github.autopkg MUNKI_REPO /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos |
Nul besoin d’être root pour utiliser AutoPkg, la majorité des actions est effectuée en espace utilisateur. Il vous faudra simplement les droits pour écrire dans le dossier de munki.
Ensuite, il vous faut spécifier à AutoPkg un ou plusieurs dépôts de recettes permettant d’obtenir les logiciels qui vous intéressent. Plusieurs sources sont disponibles à cet effet. Nous pouvons commencer par ajouter la source du projet en lui même :
office:~ ladmin$ autopkg repo-add http://github.com/autopkg/recipes.git Attempting git clone... Adding /Users/ladmin/Library/AutoPkg/RecipeRepos/com.github.autopkg.recipes to RECIPE_SEARCH_DIRS... Updated search path: '.' '~/Library/AutoPkg/Recipes' '/Library/AutoPkg/Recipes' '/Users/ladmin/Library/AutoPkg/RecipeRepos/com.github.autopkg.recipes' |
Maintenant qu’un dépôt est configuré, une autre ligne de commande permet de lister les recettes disponibles :
office:~ ladmin$ autopkg list-recipes Adium.download Adium.munki Adium.pkg AdobeAIR.pkg AdobeAcrobatPro9Update.download AdobeAcrobatPro9Update.munki AdobeAcrobatProXUpdate.download AdobeAcrobatProXUpdate.munki AdobeAir.munki AdobeFlashPlayer.download AdobeFlashPlayer.munki AdobeFlashPlayer.pkg AdobeFlashPlayerExtractPackage.munki … VLC.download VLC.munki VLC.pkg XLD.munki XQuartz.download XQuartz.munki munkitools.munki munkitools2.munki |
La liste est longue, actuellement j’ai 106 entrées dans cet unique dépôt.
Comme vous pouvez le remarquer, certains noms sont présents plusieurs fois, seule l’extension du fichier étant différente.
Par pur chauvinisme, prenons l’exemple de VLC et essayons de lancer le scénario VLC.munki qui semble correspondre le mieux à notre cas d’usage.
Pour lancer une recette en particulier il suffit d’utiliser la commande autopkg avec le verbe run. Le commutateur -v permettant d’avoir un peu plus de détail sur ce qu’il se passe.
office:~ ladmin$ autopkg run -v VLC.munki Processing VLC.munki... SparkleUpdateInfoProvider SparkleUpdateInfoProvider: Version retrieved from appcast: 2.1.4 SparkleUpdateInfoProvider: Found URL http://get.videolan.org/vlc/2.1.4/macosx/vlc-2.1.4.dmg URLDownloader URLDownloader: Storing new Last-Modified header: Fri, 21 Feb 2014 17:25:46 GMT URLDownloader: Storing new ETag header: "ce7430c-205b8c1-4f2ede987ba80" URLDownloader: Downloaded /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.VLC/downloads/VLC.dmg EndOfCheckPhase MunkiPkginfoMerger MunkiPkginfoMerger: Merged {} into pkginfo MunkiImporter MunkiImporter: Copied pkginfo to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgsinfo/apps/VLC/VLC-2.1.4.plist MunkiImporter: Copied pkg to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/apps/VLC/VLC-2.1.4.dmg Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.VLC/receipts/VLC-receipt-20140719-122235.plist The following new items were downloaded: /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.VLC/downloads/VLC.dmg The following new items were imported: Name Version Catalogs Pkginfo Path ---- ------- -------- ------------ VLC 2.1.4 testing apps/VLC/VLC-2.1.4.plist |
La première chose que l’on remarque c’est que munki est ici capable d’aller lire les informations Sparkle publiées par VLC. Sparkle est un framework bien connu des développeurs et que vous avez tous utilisé ici, sans forcément le savoir. Il permet de gérer tout le processus de publication de mise à jour d’un logiciel.
Ce qu’a fait AutoPkg ici en lisant ce fichier de recette est très intéressant. Il est allé rechercher sur la source de publication officielle de VLC le lien à jour pour la dernière version disponible et l’a téléchargé.
Ensuite, le fichier téléchargé a été automatiquement importé dans munki. La seule chose problématique semble être le nom du catalogue par défaut. En effet, AutoPkg a automatiquement importé VLC dans le catalogue « testing » qui n’est pas le catalogue qui nous intéresse ici.
Si vous essayez les autres types de recettes liés à VLC, vous verrez que l’option download va simplement mettre en cache VLC en le téléchargeant dans le dossier spécifique d’AutoPkg.
office:~ ladmin$ autopkg run -v VLC.download Processing VLC.download... SparkleUpdateInfoProvider SparkleUpdateInfoProvider: Version retrieved from appcast: 2.1.4 SparkleUpdateInfoProvider: Found URL http://get.videolan.org/vlc/2.1.4/macosx/vlc-2.1.4.dmg URLDownloader URLDownloader: Storing new Last-Modified header: Fri, 21 Feb 2014 17:25:46 GMT URLDownloader: Storing new ETag header: "ce7430c-205b8c1-4f2ede987ba80" URLDownloader: Downloaded /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.download.VLC/downloads/VLC.dmg EndOfCheckPhase Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.download.VLC/receipts/VLC-receipt-20140719-123045.plist The following new items were downloaded: /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.download.VLC/downloads/VLC.dmg |
Enfin, l’option pkg donne la signification au nom du produit, il permet de télécharger l’application pour en faire un package.
office:~ ladmin$ autopkg run -v VLC.pkg Processing VLC.pkg... SparkleUpdateInfoProvider SparkleUpdateInfoProvider: Version retrieved from appcast: 2.1.4 SparkleUpdateInfoProvider: Found URL http://get.videolan.org/vlc/2.1.4/macosx/vlc-2.1.4.dmg URLDownloader URLDownloader: Storing new Last-Modified header: Fri, 21 Feb 2014 17:25:46 GMT URLDownloader: Storing new ETag header: "ce7430c-205b8c1-4f2ede987ba80" URLDownloader: Downloaded /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/downloads/VLC.dmg EndOfCheckPhase AppDmgVersioner AppDmgVersioner: Mounted disk image /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/downloads/VLC.dmg AppDmgVersioner: BundleID: org.videolan.vlc AppDmgVersioner: Version: 2.1.4 PkgRootCreator PkgRootCreator: Created /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/VLC PkgRootCreator: Created /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/VLC/Applications Copier Copier: Mounted disk image /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/downloads/VLC.dmg Copier: Copied /private/tmp/dmg.y0J2BW/VLC.app to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/VLC/Applications/VLC.app PkgInfoCreator PkgCreator PkgCreator: Connecting PkgCreator: Sending packaging request PkgCreator: Disconnecting Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/receipts/VLC-receipt-20140719-123351.plist The following new items were downloaded: /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/downloads/VLC.dmg The following packages were built: Identifier Version Pkg path ---------- ------- -------- org.videolan.vlc.pkg 2.1.4 /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.pkg.VLC/VLC-2.1.4.pkg |
Utilisation d’AutoPkg avec munki
Revenons maintenant à l’usage d’AutoPkg avec munki.
Comme vous le savez, après l’édition de la base munki, il faut recréer les catalogues. Lorsque vous utilisez munkiimport, la commande vous demande si vous souhaitez le faire ou non.
Dans le cas de l’intégration avec AutoPkg, la recréation automatique des catalogues n’est pas active. Aussi, une action spécifiquement dédiée à cela existante dans AutoPkg : MakeCatalogs.munki.
Cette action lance bien la commande makecatalog, mais uniquement si quelque chose a influé sur munki durant la même session.
Car oui, autopkg peut être utilisé pour lancer plusieurs action à la suite en une même commande.
Essayons par exemple d’importer Java 8 et Adobe Reader dans munki.
office:~ ladmin$ autopkg run -v OracleJava8.munki AdobeReader.munki MakeCatalogs.munki Processing OracleJava8.munki... URLTextSearcher URLTextSearcher: Found matching text (url): http://download.oracle.com/otn-pub/java/jdk/8u11-b12/jre-8u11-macosx-x64.dmg URLTextSearcher: Found matching text (match): http://download.oracle.com/otn-pub/java/jdk/8u11-b12/jre-8u11-macosx-x64.dmg URLDownloader URLDownloader: Storing new Last-Modified header: Tue, 17 Jun 2014 18:59:32 GMT URLDownloader: Storing new ETag header: "12be8abaaf5bbd4d3e7d9d566da4d179:1403034296" URLDownloader: Downloaded /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/downloads/OracleJava8.dmg EndOfCheckPhase FlatPkgUnpacker FlatPkgUnpacker: Mounted disk image /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/downloads/OracleJava8.dmg FlatPkgUnpacker: Unpacked /private/tmp/dmg.byIPED/Java 8 Update 11.pkg to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack PkgRootCreator PkgRootCreator: Created /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack/root/Library/Internet Plug-Ins/JavaAppletPlugin.plugin PkgPayloadUnpacker PkgPayloadUnpacker: Unpacked /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack/javaappletplugin.pkg/Payload to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack/root/Library/Internet Plug-Ins/JavaAppletPlugin.plugin MunkiInstallsItemsCreator MunkiInstallsItemsCreator: Created installs item for /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane MunkiPkginfoMerger MunkiPkginfoMerger: Merged {'installs': ( { CFBundleShortVersionString = "1.8.0_11"; CFBundleVersion = "11.11.2.12"; path = "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/deploy/JavaControlPanel.prefPane"; type = bundle; "version_comparison_key" = CFBundleVersion; } )} into pkginfo Versioner Versioner: Found version 1.8.11.12 in file /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack/root/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Enabled.plist MunkiPkginfoMerger MunkiPkginfoMerger: Merged { version = "1.8.11.12"; } into pkginfo PathDeleter PathDeleter: Deleted /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/unpack MunkiImporter MunkiImporter: Copied pkginfo to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgsinfo/plugins/Java/OracleJava8-1.8.11.12.plist MunkiImporter: Copied pkg to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/plugins/Java/OracleJava8-1.8.11.12.dmg Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/receipts/OracleJava8-receipt-20140719-124559.plist Processing AdobeReader.munki... AdobeReaderURLProvider AdobeReaderURLProvider: Found URL http://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.07/en_US/AdbeRdr11007_en_US.dmg URLDownloader URLDownloader: Storing new Last-Modified header: Sat, 10 May 2014 11:40:46 GMT URLDownloader: Storing new ETag header: "5f369-62dc358-4f90a2f560b80" URLDownloader: Downloaded /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/downloads/AdobeReader.dmg EndOfCheckPhase FlatPkgUnpacker FlatPkgUnpacker: Mounted disk image /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/downloads/AdobeReader.dmg FlatPkgUnpacker: Unpacked /private/tmp/dmg.VeiBQP/Adobe Reader XI Installer.pkg to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/pkg_unpack PkgRootCreator PkgRootCreator: Created /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/application_payload/Applications PkgPayloadUnpacker PkgPayloadUnpacker: Unpacked /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/pkg_unpack/application.pkg/Payload to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/application_payload/Applications MunkiInstallsItemsCreator MunkiInstallsItemsCreator: Created installs item for /Applications/Adobe Reader.app MunkiPkginfoMerger MunkiPkginfoMerger: Merged {'installs': ( { CFBundleIdentifier = "com.adobe.Reader"; CFBundleName = "Adobe Reader"; CFBundleShortVersionString = "11.0.07"; CFBundleVersion = "11.0.07"; minosversion = "10.4.3"; path = "/Applications/Adobe Reader.app"; type = application; "version_comparison_key" = CFBundleShortVersionString; } )} into pkginfo MunkiImporter MunkiImporter: Copied pkginfo to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgsinfo/apps/Adobe/AdobeReader-11.0.07.plist MunkiImporter: Copied pkg to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/apps/Adobe/AdobeReader-11.0.07.dmg Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/receipts/AdobeReader-receipt-20140719-124716.plist Processing MakeCatalogs.munki... MakeCatalogsProcessor MakeCatalogsProcessor: Munki catalogs rebuilt! Receipt written to /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.makecatalogs/receipts/MakeCatalogs-receipt-20140719-124717.plist The following new items were downloaded: /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.OracleJava8/downloads/OracleJava8.dmg /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeReader/downloads/AdobeReader.dmg The following new items were imported: Name Version Catalogs Pkginfo Path ---- ------- -------- ------------ OracleJava8 1.8.11.12 testing plugins/Java/OracleJava8-1.8.11.12.plist AdobeReader 11.0.07 testing apps/Adobe/AdobeReader-11.0.07.plist |
Pas mal hein ? N’hésitez pas à remercier les développeurs de ce projet qui nous fournissent ici un outil des plus puissant, et ce, gratuitement.
Adapter les recettes AutoPkg à votre configuration munki
Dans ce que fait AutoPkg, il y a peut-être des choses qui ne vous plaisent pas. Par exemple le catalogue de destination choisi par les différentes recettes ou encore le sous-dossier munki.
Pour ces réglages en particulier, c’est globalement le bordel. Il n’y a pas de règle, les contributeurs mettent un peu ce qu’ils veulent.
L’idée est d’utiliser le système de surcharge des réglages AutoPkg pour aller changer le catalogue cible.
Pour cela, la première chose à faire est d’inspecter une recette existante avec le verbe info de la commande autopkg.
office:~ ladmin$ autopkg info AdobeAir.munki Description: Downloads the latest Adobe AIR installer and repackages it for unattended, silent installation, then imports into Munki. Based on jamesz's work here: https://github.com/jamesez/automunki/tree/master/adobe-air Identifier: com.github.autopkg.munki.AdobeAIR Munki import recipe: True Has check phase: True Builds package: True Recipe file path: /Users/ladmin/Library/AutoPkg/RecipeRepos/com.github.autopkg.recipes/AdobeAIR/AdobeAir.munki.recipe Parent recipe(s): /Users/ladmin/Library/AutoPkg/RecipeRepos/com.github.autopkg.recipes/AdobeAIR/AdobeAIR.pkg.recipe Input values: "MUNKI_REPO_SUBDIR" = "apps/adobe"; NAME = AdobeAIR; URL = "http://airdownload.adobe.com/air/mac/download/latest/AdobeAIR.dmg"; pkginfo = { catalogs = ( testing ); description = "The Adobe AIR runtime enables developers to package the same code into native applications and games for Windows and Mac OS desktops as well as iOS and Android devices, reaching over a billion desktop systems and mobile app stores for over 500 million devices."; "display_name" = "Adobe\U00ae Integrated Runtime"; name = "%NAME%"; "unattended_install" = 1; }; |
Cela nous permet de voir comment la recette fonctionne et quelles sont les valeurs d’entrées utilisées.
Nous pouvons ainsi remarquer que le réglage du catalogue cible se retrouve dans une structure complexe, un tableau dans un dictionnaire lui-même dans un autre dictionnaire alors que le réglage du sous-dossier est une simple clef de premier niveau.
Pour changer cette simple clef de premier niveau, rien de plus simple, il suffit d’utiliser le commutateur -k pour la surcharger.
office:~ ladmin$ autopkg run -k MUNKI_REPO_SUBDIR=autopkg AdobeAir.munki
Processing AdobeAir.munki...
The following new items were downloaded:
/Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeAIR/downloads/AdobeAIR.dmg
The following packages were built:
Identifier Version Pkg path
---------- ------- --------
com.adobe.pkg.AIR 14.0.0.110 /Users/ladmin/Library/AutoPkg/Cache/com.github.autopkg.munki.AdobeAIR/AdobeAIR-14.0.0.110.pkg
The following new items were imported:
Name Version Catalogs Pkginfo Path
---- ------- -------- ------------
AdobeAIR 14.0.0.110 testing autopkg/AdobeAIR-14.0.0.110.plist
Le résumé de fin indique bien que notre surcharge a été prise en compte, le paquet AdobeAIR se trouve bien dans le sous-dossier autopkg de munki.
Intéressons-nous maintenant au catalogue cible. Pour le charger, le simple système de clef valeur ne nous est d’aucune utilité, cela ne permet pas de changer un système complexe comme un tableau encapsulé dans un double dictionnaire.
La seule solution à cet instant est d’utiliser une surcharge de la recette cible. C’est assez lourd et fastidieux, car cela demande un fichier de configuration par recette, mais c’est la seule solution.
Pour cela, autopkg dispose d’une commande permettant de créer le fichier de surcharge de base qui contiendra l’ensemble des valeurs actuelles de la recette.
office:~ ladmin$ autopkg make-override AdobeFlashPlayer.munki
Override file saved to /Users/ladmin/Library/AutoPkg/RecipeOverrides/AdobeFlashPlayer.munki.recipe.
Le fichier /Users/ladmin/Library/AutoPkg/RecipeOverrides/AdobeFlashPlayer.munki.recipe ainsi créé est un fichier Plist contenant toutes les valeurs par défaut de la recette.
Il ne vous reste plus qu’à modifier le contenu du fichier pour correspondre à vos attentes.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Identifier</key> <string>local.munki.AdobeFlashPlayer</string> <key>Input</key> <dict> <key>MAKEPKGINFO_PKGNAME</key> <string>Install Adobe Flash Player.app/Contents/Resources/Adobe Flash Player.pkg</string> <key>MUNKI_REPO_SUBDIR</key> <string>plugins/internet</string> <key>NAME</key> <string>AdobeFlashPlayer</string> <key>pkginfo</key> <dict> <key>catalogs</key> <array> <string>default</string> </array> <key>description</key> <string>Adobe® Flash® Player is a cross-platform browser-based application runtime that delivers uncompromised viewing of expressive applications, content, and videos across screens and browsers.</string> <key>display_name</key> <string>Adobe Flash Player</string> <key>name</key> <string>%NAME%</string> <key>unattended_install</key> <true/> </dict> </dict> <key>ParentRecipe</key> <string>com.github.autopkg.munki.FlashPlayerNoRepackage</string> </dict> </plist> |
Ainsi, lorsque vous exécuterez la recette, AutoPkg s’occupera de fusionner la recette d’origine avec vos nouvelles valeurs.
office:~ ladmin$ autopkg run AdobeFlashPlayer.munki
Processing AdobeFlashPlayer.munki...
The following new items were downloaded:
/Users/ladmin/Library/AutoPkg/Cache/local.munki.AdobeFlashPlayer/downloads/AdobeFlashPlayer.dmg
The following new items were imported:
Name Version Catalogs Pkginfo Path
---- ------- -------- ------------
Adobe Flash Player 14.0.0.145 default plugins/internet/Adobe Flash Player-14.0.0.145.plist |
Mise à jour automatique
Une fois vos recettes correctement préparées, il ne vous reste plus qu’à exécuter périodiquement AutoPkg pour qu’il installe les mises à jour.
Créez un cron ou un service launchd pour lancer un script périodiquement et dans se script, incluez toutes les commandes autopkg run que vous souhaitez.
N’oubliez pas de placer la recette MakeCatalogs.munki à la fin de chaque commande de run !
Une interface d’administration pour munki
Tout ce scénario est très bien, mais à la fin, il faut toujours manipuler munki pour intégrer vos applications dans l’un ou l’autre de vos manifestes.
De même, il serait intéressant d’avoir une remontée des clients histoire de savoir si tout s’est bien passé.
C’est ici qu’entre en jeu MunkiWebAdmin.
MunkiWebAdmin fait partie du projet munki, c’est une interface web basée sur le framework Django permettant de manipuler la base munki et d’y apporter quelques fonctionnalités.
Installation de MunkiWebAdmin
Ici nous allons installer MunkiWebAdmin sur le même serveur OS X que notre dépôt munki, cependant, il peut tout à fait utiliser un autre serveur, tournant sur un autre OS. Encore une fois, la seule chose nécessaire, c’est l’accès en lecture écriture au dépôt munki.
L’application MunkiWebAdmin utilise une vieille version de Django, aussi pour ne pas avoir de problème de conflits avec un autre service utilisant ce framework dans une version plus moderne, nous allons devoir créer un environnement virtuel pour python. Cela est assez simple, mais nécessite un minimum d’organisation.
office:~ ladmin$ sudo easy_install virtualenv office:~ ladmin$ sudo mkdir /Volumes/DataHD/Library/PythonVirtualEnv office:~ ladmin$ cd /Volumes/DataHD/Library/PythonVirtualEnv office:PythonVirtualEnv ladmin$ sudo virtualenv MunkiWebAdmin office:PythonVirtualEnv ladmin$ cd MunkiWebAdmin/ office:MunkiWebAdmin ladmin$ source bin/activate (MunkiWebAdmin)office:MunkiWebAdmin ladmin$ |
Pour toute la suite de l’installation, faites bien attention à rester dans l’environnement MunkiWebAdmin.
(MunkiWebAdmin)office:MunkiWebAdmin ladmin$ sudo pip install django==1.5.1 |
Ensuite, nous allons récupérer l’application MunkiWebAdmin en elle-même et l’installer dans un dossier dédié, non-accessible par le web, mais appartenant à l’utilisateur et au groupe Apache.
(MunkiWebAdmin)office:~ ladmin$ cd /Volumes/DataHD/Library/Server/Web/Data/WebApps/ (MunkiWebAdmin)office:WebApps ladmin$ git clone https://code.google.com/p/munki.munkiwebadmin/ munkiwebadmin |
Une fois les sources de MunkiWebAdmin récupérées, il faut créer le fichier settings.py à partir de settings_template.py en prenant soin de modifier les réglages suivants :
- ADMINS, changer le contenu de cette liste pour spécifier vos administrateurs ;
- si vous avez un grand nombre de client, n’utilisez pas la base de données SQLite ;
- TIME_ZONE, pour y mettre Europe/Paris par exemple ;
- SECRET_KEY, assurez-vous de disposer d’une clef unique ;
- MUNKI_REPO_DIR, pour indiquer le chemin d’accès local au dépôt munki (cela peut être un point d’automontage).
Une fois le fichier de réglages configuré, assurez-vous de placer votre shell dans le dossier source munkiwebadmin et exécutez la commande suivante pour préparer votre base de données et créer votre compte administrateur.
(MunkiWebAdmin)office:munkiwebadmin ladmin$ python manage.py syncdb Creating tables ... Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table auth_user_groups Creating table auth_user_user_permissions Creating table auth_user Creating table django_content_type Creating table django_session Creating table django_admin_log Creating table reports_machine Creating table reports_munkireport Creating table inventory_inventory Creating table inventory_inventoryitem Creating table licenses_license You just installed Django's auth system, which means you don't have any superusers defined. Would you like to create one now? (yes/no): yes Username (leave blank to use 'ladmin'): admin Email address: yoann@storymaker.fr Password: Password (again): Superuser created successfully. Installing custom SQL ... Installing indexes ... Installed 0 object(s) from 0 fixture(s) |
Il ne vous reste plus qu’à vous assurer que les dossiers sources MunkiWebAdmin et le dépôt munki appartiennent bien à l’utilisateur Apache.
(MunkiWebAdmin)office:~ ladmin$ sudo chown -R www:www /Volumes/DataHD/Library/Server/Web/Data/WebApps/munkiwebadmin (MunkiWebAdmin)office:~ ladmin$ sudo chown -R www:www /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos |
Note : vous pouvez également ajouter une ACL sur ces dossiers pour garantir que l’utilisateur Apache conserve toujours les droits sur les éléments enfants.
Configuration du service web
MunkiWebAdmin étant maintenant installé, il est nécessaire de configurer le service web pour s’en servir.
Nous allons ici utiliser la fonctionnalité de WebApps incluse dans OS X Server. Elle est très puissante et sous-utilisée aujourd’hui. C’est une bonne occasion pour la prendre en main.
Ce que nous devons faire, c’est rendre accessible l’application MunkiWebAdmin à travers notre service web, directement à l’URL https://muniki.office.storymaker.fr/.
Pour cela, nous aurons besoin de deux fichiers. Le premier de type Plist indiquera le fonctionnement de l’application web, le seconde de type TXT contiendra les configurations spécifiques à charger dans Apache.
Dans le dossier /Library/Server/Web/Config/apache2/webapps, ajoutez le fichier com.googlecode.munki.munkiwebadmin.plist avec le contenu suivant :
<?xml version="1.0" encoding="UTF-7"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>name</key> <string>com.googlecode.munki.munkiwebadmin</string> <key>displayName</key> <string>MunkiWebAdmin (mounted at root)</string> <key>launchKeys</key> <array/> <key>proxies</key> <dict/> <key>installationIndicatorFilePath</key> <string>/Volumes/DataHD/Library/Server/Web/Data/WebApps/munkiwebadmin/wsgi.py</string> <key>includeFiles</key> <array> <string>/Library/Server/Web/Config/apache2/httpd_munki_munkiwebadmin.conf</string> </array> <key>requiredModuleNames</key> <array> <string>wsgi_module</string> </array> </dict> </plist> |
Puis ajoutez dans /Library/Server/Web/Config/apache2 le fichier httpd_munki_munkiwebadmin.conf avec le contenu suivant :
Alias /repos /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos WSGIScriptAlias / /Volumes/DataHD/Library/Server/Web/Data/WebApps/munkiwebadmin/wsgi.py WSGIDaemonProcess com.googlecode.munki.munkiwebadmin python-path=/Volumes/DataHD/Library/Server/Web/Data/WebApps:/Volumes/DataHD/Library/Server/Web/Data/WebApps/munkiwebadmin:/Volumes/DataHD/Library/PythonVirtualEnv/MunkiWebAdmin/lib/python2.7/site-packages WSGIProcessGroup com.googlecode.munki.munkiwebadminAllow from all Order deny,allow AddHandler wsgi-script .py Options +ExecCGI
Attention à bien vérifier l’exactitude des chemins d’accès, entre autres des numéros de version de Python.
Note : La première directive Alias a pour but de garantir que les requêtes à destination du dépôt soient bien traitées par Apache. Sans cette directive, c’est MunkiWebAdmin qui traiterait la requête, menant à une erreur.
Dès lors, vous pouvez vous rendre dans votre application Server, dans la configuration du service web munki précédemment créé, puis dans les réglages avancés, activez votre nouveau service web.
MunkiWebAdmin devrait être disponible maintenant. Rendez-vous à l’adresse https://munki.office.storymaker.fr/ et constatez le résultat.
Une fois authentifié, vous avez accès à des rapports d’état des différents clients, la liste des catalogues disponible, les manifestes et enfin un mini inventaire des clients.
Seul problème de cet outil d’administration, il ne permet pas d’éditer les catalogues. De fait, si AutoPkg vous a chargé un logiciel dans un mauvais catalogue, vous ne pourrez pas utiliser MunkiWebAdmin pour corriger la chose.
Seules deux options sont disponibles pour le problème des catalogues avec AutoPkg :
- surcharger tous les paquets que vous installez ;
- laisser autopkg foutre le bordel dans vos catalogues et se servir de tous dans vos manifestes.
Configuration des clients pour MunkiWebAdmin
Pour que les postes clients rapportent leurs informations dans MunkiWebAdmin, une configuration est nécessaire.
Vous trouverez dans les sources MunkiWebAdmin un script nommé create-mwa-scripts-installer.sh permettant de créer un package d’installation des outils supplémentaires pour les postes clients. Durant la génération de ce package, le script vous demandera l’URL d’accès à MunkiWebAdmin pour le configurer par la même occasion sur les clients.
Il vous demandera également une liste de préfixe IP permettant de bloquer le fonctionnement de munki hors de cette plage.
office:munkiwebadmin ladmin$ sudo ./scripts/create-mwa-scripts-installer.sh Password: Enter the FQDN of your MWA server: https://munki.office.storymaker.fr/ You can specify a list of allowed network prefixes. Doing so will prevent munki from running on any other network. Leave this blank if you want munki to check for updates everywhere. EXAMPLE: '192.168 172.16' <-- only allows execution on 2 networks Specify allowed network prefixes: 192.168.42 pkgbuild: Inferring bundle components from contents of /tmp/create-mwa-scripts-installer.sh.5fVXa0 pkgbuild: Wrote package to munkiwebadmin_scripts-2014.07.20.pkg Cleaning up... Finished building munkiwebadmin_scripts-2014.07.20.pkg |
Vous pouvez déployer ce package sur les clients existant via munki lui-même ou encore l’intégrer à votre système de déploiement DeployStudio.
Dans le cas présent, nous allons passer par munki et utiliser MunkiWebAdmin pour ajouter l’élément au manifeste dev.
office:munkiwebadmin ladmin$ munkiimport munkiwebadmin_scripts-2014.07.20.pkg
Item name [munkiwebadmin_scripts]:
Display name [munkiwebadmin_scripts-2014.07.20]:
Description:
Version [2014.07.20]:
Catalogs [default]:
Item name: munkiwebadmin_scripts
Display name: munkiwebadmin_scripts-2014.07.20
Description:
Version: 2014.07.20
Catalogs: default
Import this item? [y/n] y
Upload item to subdirectory path []:
Copying munkiwebadmin_scripts-2014.07.20.pkg to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgs/munkiwebadmin_scripts-2014.07.20.pkg...
Saving pkginfo to /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos/pkgsinfo/munkiwebadmin_scripts-2014.07.20.plist...
Rebuild catalogs? [y/n] y
Rebuilding catalogs at /Volumes/DataHD/Library/Server/Web/Data/Sites/munki.office.storymaker.fr/repos... |
Note : faites attention, la configuration des clients munki pour MunkiWebAdmin embarque le certificat public de votre serveur pour plus de sécurité. De fait, il est impératif de prévoir une mise à jour des clients en cas de changement du certificat.
Maintenant que le client est configuré pour travailler avec le service web, vous le retrouvez dans la section client, avec la liste des paquets actuellement installés, les erreurs, ainsi que des informations d’inventaire.
Avertissement de fin
La chaine est maintenant complète. La partie munki est relativement stable et fiable. Faites cependant attention à AutoPkg.
En effet, ce système demande de faire confiance à des tiers pour la récupération et l’installation de vos logiciels.
Faites donc attention et vérifiez un minimum ce qu’il se passe.
Entre autres, il est intéressant de mettre en place un parc de pré production pour vous assurer du bon fonctionnement des outils que vous obtenez de cette manière.
Et les mises à jours Adobe Creative Suite/Cloud on en parle ? :-/
Bonjour,
Lorsque tu déploie le client munki, comment sais tu pour ne pas installer « les outils d’admin. de munki » ?
Merci
Je les installes quand même. Ça n’a rien de grave de les laisser.
Bonjour,
Pour completer l’article, et pour les non fan de la ligne de commande au quotidien
il y a AutoPkgr qui est un GUI pour Autopkg
et MunkiAdmin qui est un GUI pour la gestion des paquets, catalogues et manifests…