Mon CV

Gérer son parc de Mac et déployer des packages avec Munki

4 juin 2013

Tous ceux qui gèrent un parc de machines sous OS X un peu important (on va dire à partir d’une quinzaine de machines) n’ont aucune excuse pour ne pas utiliser Munki.

C’est une solution puissante OpenSource de gestion d’un repository pour le déploiement de packages et applications sur vos Mac. Cette solution déploie aussi bien des packages ou méta-packages, les installeurs d’Adobe CS, ou bien encore directement les applications au format .app. Munki peut également être utilisé pour automatiser les mises à jours Apple (aussi bien en utilisant les serveurs standards d’Apple ou votre propre serveur de mise à jour). Bref, c’est une solution complète et simple, qui a le mérite d’être promue par une communauté importante. Enfin, des solutions complémentaires peuvent facilement s’ajouter, notamment pour disposer d’une interface graphique pour l’administration.

 

Prérequis

Il vous faudra disposer d’une machine avec un serveur web actif et joignable par votre parc, pas nécessairement un OS X Server, mais dans mon cas, ce le sera.

Munki requiert pour fonctionner Python 2.5 (ou ultérieur) et il fonctionne sur Leopard, Snow Leopard, Lion et Mountain Lion.

 

Etape 1 : installation de munki

Pour commencer il vous faudra récupérer la dernière version de munki sur la page de téléchargement du projet. Il faudra ensuite installer ce package sur l’ensemble des machines clientes à gérer mais également sur la machine serveur.

Le package d’installation installe les outils de ligne de commande munki dans /usr/local/munki/ et l’interface graphique du logiciel Managed Update.app dans /Applications/Utilitaires/.

A noter que l’installation de munki nécessite ensuite un redémarrage.

 

Etape 2 : préparation du repository

Sur la machine qui sera utilisée comme serveur munki, nous allons créer les dossiers nécessaires :

cd /Users/Shared/
mkdir munki_repo
mkdir munki_repo/catalogs
mkdir munki_repo/manifests
mkdir munki_repo/pkgs
mkdir munki_repo/pkgsinfo

Donnons ensuite les droits nécessaires à Apache à ce dossier (éventuellement, ajouter un chown -R selon votre configuration), puis créons un lien symbolique pour que ce dossier soit accessible et servi en HTTP :

chmod -R a+rX /users/shared/munki_repo
sudo ln -s /Users/Shared/munki_repo /Library/WebServer/Documents/

Libre à vous ensuite de définir vos règles d’accès à ce dossier, que ce soit en définissant des règles dans l’hôte virtuel Apache ou via votre firewall.

 

Etape 3 : réglage sur les postes clients

Sur les postes clients, il faut faire quelques réglages pour indiquer quelle est l’adresse du serveur web utilisé comme repository pour munki (ici http://monserveur.fr/munki_repo) et également quel est le manifest à utiliser (ici test_munki_client). Le manifest correspond à une liste de logiciels associés. Vous pouvez donc avez plusieurs configurations différentes avec  plusieurs manifests différents.

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://monserveur.fr/munki_repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"

Signalons tout de suite, que ces préférences peuvent être déployées en utilisant la fonction “Préférences gérées” de Mac OS X Server, en important manuellement le fichier xml /Library/Preferences/ManagedInstalls.

 

Etape 3 : configuration de notre repo

Pour le moment notre dépôt ne contient aucune application et n’est pas encore fonctionnel. Commençons par configurer l’outil d’import :

/usr/local/munki/munkiimport --configure
Path to munki repo (example: /Volumes/repo): /Users/Shared/munki_repo   
Repo fileshare URL (example: afp://munki.example.com/repo): <just hit return>
pkginfo extension (Example: .plist): <just hit return>
pkginfo editor (examples: /usr/bin/vi or TextMate.app): TextMate.app <substitute your favorite text editor>
Default catalog to use (example: testing): testing

La ligne Repo fileshare URL n’est à remplir que si vous stockez vos applications et packages sur une autre machine que celle qui fera office de serveur munki. Dans ce cas, munki doit pouvoir y accéder via un partage AFP ou SMB. Ici nous laisserons cette ligne blanche.

 

Etape 4 : importer une application dans un catalogue

Commençons par importer Firefox pour tester notre configuration. Il faut télécharger Firefox pour commencer. Les manipulations qui suivent sont évidemment à effectuer sur la machine qui accueille le serveur munki. Pour nos test, je partirai du principe que vous l’avez téléchargé dans votre dossier Downloads (Téléchargements). Dans un terminal, nous allons importer Firefox dans le catalog “testing” et donner les informations nécessaires. Le tout sera intégré dans un fichier xml, automatiquement ouvert à la fin du processus :

/usr/local/munki/munkiimport ~/Downloads/Firefox\ 10.0.dmg 
      Item name [Firefox]: 
   Display name []: Mozilla Firefox
    Description []: Web browser from Mozilla
        Version [10.0]: 
       Catalogs [testing]: 

      Item name: Firefox
   Display name: Mozilla Firefox
    Description: Web browser from Mozilla
        Version: 10.0
       Catalogs: testing

Import this item? [y/n] y
Upload item to subdirectory path []: 
Path /Users/Shared/munki_repo/pkgs doesn't exist. Create it? [y/n] y
Copying Firefox 10.0.dmg to /Users/Shared/munki_repo/pkgs/apps/mozilla/Firefox 10.0.dmg...
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/mozilla/Firefox-10.0...

Pour l’item “Catalogs”, pensez à bien affecter cette application à un des catalogues d’applications du repository munki, en l’occurrence ici “testing”, mais cela peut être modifié en fonction de votre configuration. Vous pouvez modifier le catalogue par défaut en relançant la commande de l’étape précédente.

Automatiquement, le système vous ouvre le fichier xml associé à l’application, au choix dans une application externer ou dans un éditeur via le terminal (nano, vi, etc.) selon le choix que vous avez effectué à l’étape précédente. Vous pouvez modifier ce fichier xml éventuellement (pour définir un OS minimum par exemple).

Retournez ensuite à votre terminal et répondez à la question :

Rebuild catalogs? [y/n] y
Adding apps/mozilla/Firefox-10.0 to testing...

C’est fait ! Pour vérifier que tout est correct, vous pouvez, à l’aide de votre navigateur, visiter l’adresse http://monserveur.fr/munki_repo/catalogs/testing (à adapter bien sur en fonction de votre configuration), vous devriez y retrouver votre application.

 

Etape 5 : affecter un application à un manifest

Maintenant que nous avons une application dans notre catalogue “testing” nous allons assigner cette application au manifest “test_munki_client” (cf. étape 2).

Vous pouvez évidemment gérer plusieurs manifests en fonction des différentes configuration que vous souhaitez mettre en place sur votre parc (par exemple une configuration “minimale” pour les stagiaires, une configuration “bureautique” et une configuration “production” contenant certains logiciels métier spécifiques).

Il nous faut donc d’abord créer le manifest puis y rattacher le catalogue “testing” :

/usr/local/munki/manifestutil 
Entering interactive mode... (type "help" for commands)
> new-manifest test_munki_client
> add-catalog testing --manifest test_munki_client
Added testing to catalogs of manifest test_munki_client.
> exit

Nous avons créé un manifest “test_munki_client” et y avons affecté la liste d’applications “testing”.

Pour affecter une application ou un package à un manifest, tout se fait encore depuis la ligne de commande :

/usr/local/munki/manifestutil 
Entering interactive mode... (type "help" for commands)
>add-pkg Firefox --manifest test_munki_client
Added Firefox to section managed_installs of manifest test_munki_client.
> exit

Désormais, si vous contrôlez votre fichier xml /Users/Shared/munki_repo/manifests/test_munki_client, vous devriez trouver ceci :

<?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>catalogs</key>
        <array>
                <string>testing</string>
        </array>
        <key>included_manifests</key>
        <array>
        </array>
        <key>managed_installs</key>
        <array>
                <string>Firefox</string>
        </array>
        <key>managed_uninstalls</key>
        <array>
        </array>
</dict>
</plist>

 

Etape 6 : vérifier que cela fonctionne

Pour vérifier que cela fonctionne, il nous faut prendre un poste client, où l’installation de munki a été effectée et où les réglages de l’étape 3 ont été effectués.

Pour vérifier la présence de mises à jours d’applications, vous pouvez utiliser l’application /Applications/Utilities/Managed Software Update.app (Mise à jour de logiciels) ou la ligne de commande :

sudo /usr/local/munki/managedsoftwareupdate 
Managed Software Update Tool
Copyright 2010-2012 The Munki Project
http://code.google.com/p/munki

Downloading Firefox 10.0.dmg...
        0..20..40..60..80..100
Verifying package integrity...
The following items will be installed or upgraded:
    + Firefox-10.0
        Web browser from Mozilla

Run managedsoftwareupdate --installonly to install the downloaded updates.

Pour aller plus loin…

Munki est à la fois simple est très puissant. Vous pourrez par exemple :

  • modifier le fichier de configuration client /Library/Preferences/ManagedInstalls.plist pour prendre en charge l’installation des mises à jour Apple (clef InstallAppleSoftwareUpdates) ou pour supprimer les notifications en cas de mise à jour (clef SuppressUserNotification). La documentation sur les entrées possibles dans ce fichier xml est disponible ici.
  • intégrer des scripts preflight et postflight qui seront exécutés automatiquement avant et après l’appel de la commande /usr/local/munki/managedsoftwareupdate. Ça peut être pratique pour par exemple envoyer un email automatiquement à l’administrateur en cas d’erreur, etc. C’est documenté correctement ici.
  • gérer des conditions pour chaque application,
  • etc.

 

Je vous proposerai bientôt quelques autres billets sur des astuces avec Munki …

Posted in Apple et Macintosh by Yvan GODARDTags: