Lavoro di squadra tra software
In un precedente articolo abbiamo visto come ottimizzare gli script Powershell, arrivando a creare dei moduli contenenti le funzioni utilizzate per le proprie attività di manutenzione.
Il modulo è quel passaggio che consente di avere sottomano delle funzioni usabili da più procedure e usabili direttamente dalla console Powershell del computer e del server, la loro combinazione permette di semplificare il lavoro ottenendo un “lavoro di squadra”, dove i membri della squadra sono i moduli realizzati e legati tra loro delle procedure che li impiegano.
Per noi individuare lo User ID degli utenti collegati richiede un solo comando (Get-AllUSID) e non diversi cmdlet e filtri combinati.
Arrivati all’uso dei moduli, il passaggio successivo è il distribuirli posizionandoli nel giusto percorso e generare in modo automatico il relativo manifesto.
La generazione del manifesto è ben documentata da Microsoft e in diversi blog, per accedere a queste informazioni è sufficiente avvalersi del consulente Google.
Per praticità riportiamo alcuni link di riferimento:
- Cmdlet New-ModuleManifest per la creazione del manifesto (*.psd1)
- Cmdlet Update-ModuleManifest per modificare il manifesto (*.psd1)
- Scrittura di un manifesto Powershell per un modulo
Appresi gli elementi di base per rendere disponibile un modulo, diventa importante trovare una strategia che permetta di posizionarli seguendo uno standard, in tal senso diventa utile automatizzare, usando degli script che con pochi parametri permettano di compiere le operazioni necessarie alla delivery, ancora meglio se usando un RMM.
Tabella dei Contenuti
Gli elementi chiave per lo script Powershell
Lo script dovrà essere creato utilizzando i cmdlet standard i Powershell e non scorciatoie a comandi definiti nei moduli aggiuntivi, questo perché si tratta di un componente finalizzato all’installazione di moduli ed è necessario partire dal presupposto che ancora non ne siano stati installati.
Per rendere disponibile il modulo sono fondamentali due elementi:
- Un file contenente il codice e i relativi commenti per l’help con estensione psm1, basta cambiare l’estensione del ps1;
- Un file che definisce il manifesto con estensione psd1.
Il file del codice dovrà essere disponibile per l’upload, quindi dovrà essere ubicato in un percorso accessibile dalla procedura di delivery o incorporato nel componente del RMM.
La versione di Powershell
È importante accertarsi che sia disponibile sul computer/server almeno la versione 5.1 di Powershell, che integra una gestione specifica dei moduli. I moduli realizzati possono anche essere impiegati con versioni di Powershell a partire dalla 3.0, ma con degli accorgimenti di delivery.
Il seguente codice determina la versione di Powershell disponibile ed interrompe la procedura nel caso in cui caso non sia disponibile.
$PSVer = (get-host).version.major
if ($PSVer -lt 5) {
Write-Host "ERRORE - Versione di Powershell incompatibile ($PSVer)"
Exit 1
}
Parametri e variabili
Dovendo distribuire più moduli è importante poterli identificare e definire all’interno dello script, sapendo il nome del modulo su cui operare e le informazioni necessarie per la generazione del file di codice e del manifesto.
Una sezione del codice definisce queste informazioni di configurazione dello script.
$ModuleName = $ENV:ModuleName
$Path = "C:\Program Files\WindowsPowerShell\Modules\"
$ModulePath = $Path + $ModuleName
$ModuleManifestPath = $ModulePath + "\" + $ModuleName + ".psd1"
$ModuleRoot = $ModuleName + ".psm1"
Nella prima riga si ottiene il nome del modulo come sarà riconosciuto e scritto nel sistema operativo, nel caso specifico è adottata la sintassi usata per il prodotto Datto RMM. Dove possibile, con un RMM, può essere comodo utilizzare una definizione di argomenti che usa la modalità di select, in questo modo è sufficiente selezionare da un elenco il nome del modulo da distribuire.
Nella riga 3 è definito il percorso di installazione usato per i moduli, dove è assegnato il percorso relativo ai moduli accessibili per tutti gli utenti del sistema, si tratta di un percorso di default.
Nella riga 4 è definito il percorso che deve essere creato per contenere i file del modulo, si tratta di una directory con il nome del modulo.
Nella riga 5 è definito il percorso e il nome completo del manifesto.
Nella riga 6 è definito il nome del file con il codice.
Appare evidente che tutta la nomenclatura orbita attorno al nome del modulo.
Parametrizzazione del manifesto
Per la generazione di moduli di base la struttura del manifesto si differenzia per soli tre argomenti, è quindi necessario identificare questi tre valori partendo dal nome del modulo indicato nel parametro dello script, a tale scopo è possibile utilizzare il metodo switch usando come espressione il nome del modulo.
Con la creazione di nuovi moduli o l’aggiornamento di moduli esistenti è necessario aggiornare questa sezione di codice.
I valori da definire sono:
- Function – elenco delle funzioni da esportare, il modulo può contenere delle funzioni usate all’interno e da non rendere disponibili all’utenza.
- ModuleVersion – versione del modulo, importante per la gestione degli aggiornamenti.
- ModuleDescription – descrizione del modulo.
switch ($ModuleName) {
"EPFunctionString" {
$Function = @('Search-String', 'Search-Character')
$ModuleVersion = "2.0"
$ModuleDescription = "Modulo con funzioni relative alle azioni di ricerca e manipolazione delle stringhe."
}
}
Gestione dei moduli esistenti
Riteniamo importante generare una notifica nel caso in cui il modulo che si tenta di installare sia già presente, a tale scopo è sufficiente un controllo nei moduli disponibili ricorrendo al cmdlet Get-Module, dalle cui informazioni si verificherà la presenza del modulo in fase di installazione e la sua versione.
Il codice interrompe l’esecuzione dello script se il modulo in fase di distribuzione risulta già installato e restituisce una notifica informativa.
$ModuleInfo = Get-Module -ListAvailable | Where-Object { $_.Name -eq $ModuleName}
if ($ModuleInfo.Version -eq $ModuleVersion) {
Write-Host "INFO - Modulo già aggiornato ($ModuleName $ModuleVersion)."
Exit 0
}
Percorso e caricamento del codice del modulo
Il modulo deve essere posizionato in una specifica cartella con il medesimo nome dei file, tale cartella deve essere creata, se non presente, e al suo interno deve essere copiato il file psm1 reso disponibile in uno specifico percorso o nel componente del RMM.
if (!(Test-Path $ModulePath)) {
New-Item -Path $ModulePath -ItemType Directory -Force -Confirm:$false
}
Copy-Item -Path $ModuleRoot -Destination $ModulePath
Il codice determina se la cartella non esiste (cmdlet Test-Path) e in tal caso la crea, quindi copia (cmdlet Copy-Item) nel percorso specificato il file psm1 con il codice.
Creazione del manifesto
Con la struttura del file system pronta e i diversi parametri disponibili, è ora possibile creare il manifesto per il modulo di base con le funzioni personalizzate create.
Per prima cosa e per praticità di lettura, andiamo a creare un array con gli argomenti necessari per la creazione del manifesto, l’array contiene i parametri del cmdlet con i valori a loro assegnati.
L’array è quindi passato al cmdlet New-ModuleManifest, che elaborerà le informazioni creando il manifesto psd1.
$Params = @{
"Path" = $ModuleManifestPath
"Author" = 'Emilio Polenghi'
"CompanyName" = 'Emilio Polenghi Imp. Ind.'
"RootModule" = $ModuleRoot
"ModuleVersion" = $ModuleVersion
"CompatiblePSEditions" = @('Desktop','Core')
"FunctionsToExport" = $Function
"CmdletsToExport" = @()
"VariablesToExport" = ''
"AliasesToExport" = @()
"PowerShellVersion" = '5.1'
"Description" = $ModuleDescription
}
New-ModuleManifest @Params
Esito della distribuzione
È importante accertarsi che le azioni eseguite abbiano effettivamente distribuito il modulo, per questa ragione richiediamo con il cmdlet Get-Module se è il nuovo modulo è disponibile, in caso contrario viene attivata una notifica di errore. Se la creazione del modulo ha avuto successo, è disponibile anche l’output del cmdlet New-ModuleManifest.
Conclusioni
La complessità dell’operazione è legata alla varietà di azioni da eseguire; tuttavia, una volta compresa la logica del procedimento il tutto è molto semplice, in particolare nel momento in cui è disponibile uno script che esegue le azioni necessarie senza richiedere all’operatore di rammentare i comandi da eseguire.
A questo punto i moduli sono caricati e basterà eseguire uno dei nuovi comandi creati per rendersi conto della loro disponibilità un qualsiasi contesto li si voglia usare.
Negli articoli successivi spiegheremo come verifichiamo la presenza dei moduli sui sistemi e procediamo alla loro installazione e come ci muoviamo per eseguire gli aggiornamenti.
Per maggiori informazioni sull’uso e la realizzazione degli script di automazione leggi questo articolo e contattaci senza impegno.
I componenti distribuiti sono forniti senza alcuna garanzia. Non vi sono garanzie che il software soddisfi le vostre esigenze o sia esente da errori. In nessun caso gli sviluppatori saranno responsabili per eventuali danni.
I componenti proposti sono stati collaudati nel modo più esaustivo possibile e sono utilizzati in modo regolare in ambienti di produzione, durante il loro utilizzo non si sono verificate anomalie di funzionamento.
Articoli recenti
- ShellBag – un viaggio allucinante nei ricordi di Windows
- La donazione di sangue nei cani: importanza, modalità e compatibilità
- Il Manto del Cane: Un Viaggio alla Scoperta della Sua Pelle e del Suo Pelo
- Proteggi il tuo cane dal caldo: prevenzione e riconoscimento della disidratazione
- Monitoraggio e Verifica delle Configurazioni di Rete: Una Soluzione Efficace con PowerShell e Datto RMM