In un articolo precedente abbiamo trattato questa metodologia/tecnologia per l’installazione di applicativi su più macchine OsX dalle interessanti caratteristiche e sviluppata da Google per i suoi lab.

La caratteristica base è che il repository dei files può essere manutenuto su qualsiasi server Web (Apache), quindi può andare bene OsX ma anche Linux o un NAS.
Utilizzando il protocollo HTTP poi otteniamo alcuni vantaggi basilari: in particolar modo la velocità del deploy rispetto ad altri protocolli specifici o ad hoc, secondariamente un protocollo standard come HTTP non richiede di solito modifiche importanti sulle policy di sicurezza.
Per approfondire le caratteristiche comunque rimandiamo a questo articolo

Affrontiamo oggi un caso pratico sulla base della documentazione esistente.


La documentazione ufficiale fa riferimento a una installazione di munki client/server sulla stessa macchina. Il caso che affronteremo invece riguarda l’installazione del server (repo) su Linux (Ubuntu/Debian) e della parte Client (compresa l’amministrazione dei pacchetti) su un OsX 10.7 Lion.

Per ogni client OsX (e per la macchina amministrativa con la quale creeremo i pacchetti) è necessario scaricare il pacchetto qui ed installarlo (è richiesto un riavvio).

Per il server è necessario soltanto preparare una directory e un Virtual Host (per semplificare l’accesso) e mantenere ordinate le directory all’interno.
Munki per funzionare correttamente necessita di questa disposizione di cartelle nel repository (vedi anche foto):

/repo/catalogs
     /manifests
     /pkgs
     /pkgsinfo

Nella maggior parte dei casi (e specificatamente questo esempio), il software può essere utilizzato direttamente da un normalissimo file .dmg. E’ il caso di quegli applicativi che si installano drag-&-drop direttamente dall’immagine montata. Questi files .dmg vanno posti nella directory “pkgs”.
le altre tre cartelle conterranno dei files descrittivi e metadati nei quali si stabiliscono regole di deploy e informazioni di vario tipo e sono normalmente generati dai tools di munki.
Nella directory “catalogs” per esempio è contenuta la lista dei pacchetti disponibile, la directory “manifests” contiene i “manifesti” cioè una lista di ciò che deve essere installato e/o rimosso per una data macchina/client. Questi “manifesti” possono essere nidificati (sono in effetti dei files plist standard) e contenerne altri, per esempio si può fare un manifesto che contiene una lista completa di tutti i software disponibili per tutti i client e contenere a sua volta una lista di software installabili in più solo per determinati client.
Prepariamo quindi il repository (dando per scontato che su Linux Apache sia già installato e attivo).
Prima lo prepariamo in locale, con la struttura in cartelle di cui sopra, poi lo popoleremo con un applicativo e infine lo trasferiremo sul server.
Nel nostro esempio installeremo Google Chrome.
Potete scaricarlo direttamente dai link qui accanto e posizionare il file .dmg nella cartella /repo/pkg come indicato di seguito:

  • Inserire il pacchetto googlechrome.dmg nella cartella repo/pkgs
  • Creare il file pkginfo per i due software col seguente comando (ATTENZIONE: comando su un solo rigo):

/usr/local/munki/makepkginfo /pathtolocalrepo/pkgs/googlechrome.dmg > /pathtolocalrepo/pkgsinfo/googlechrome.pkginfo

  • Creare il catalogo:

/usr/local/munki/makecatalogs /pathtolocalrepo/

  • Creare un manifesto di prova (useremo il nome “testing”, da non usare ovviamente in ambienti di produzione:
< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">


        catalogs
        
                testing
        
        managed_installs
        
                Google Chrome
        


E salvarlo nella directory /pathtolocalrepo/manifests con il nome “testing” (senza estensione).
A questo punto il repository è pronto, possiamo trasferirlo tutto quanto (tutta la cartella “repo”) nel server che abbiamo scelto, su Linux si può portare tutto il repo nella cartella di default dalla quale apache serve i files html: /var/www, ma va bene qualunque altra soluzione: nel mio caso per es. ho utilizzato un piccolo server Ubuntu LTS, ho creato un virtual host del tipo repo.dominiointerno.lan e una volta istruito il mio DNS interno, ho configurato di conseguenza i client OsX a “pescare” da lì.

Per configurare i client OsX dobbiamo dire al Managed Software Update a scaricare dal nostro server web.
Dobbiamo farlo su ogni client, in questo caso usiamo la macchina OsX (10.7) sulla quale abbiamo scaricato e prodotto i pacchetti (e sulla quale teniamo una copia del repository). Digitiamo i seguenti 2 comandi:

sudo defaults write /Library/Preferences/ManagedInstalls.plist ClientIdentifier testing
sudo defaults write /Library/Preferences/ManagedInstalls.plist SoftwareRepoURL http://indirizzoserver/repo

A questo punto non ci rimane che lanciare l’update software, possiamo farlo via terminale con il seguente comando: “sudo /usr/local/munki/managedsoftwareupdate”
O molto piu semplicemente lanciando l’apposito programma che munki ha installato per noi e che trovate in: /Applications/Utilities/ e che si chiama “Managed Software Update.app”.
A questo punto potrete installare Chrome sui vostri Mac.

Nel prossimo articolo entremo in profondità nelle policy di installazione, deploy, rimozione, temporizzazione, hosting di Apple Updates, installazione con o senza approvazione utente e via dicendo: Munki a dispetto della sua apparente semplicità è uno strumento molto potente, flessibile e configurabile…

ENJOY!