GLPI e Semaphore su FUSS Server

Avvertimento

Questo articolo documenta una situazione sotto attivo sviluppo, quanto indicato potrà cambiare nel tempo fino a quando questo warning non verrà rimosso.

A partire dalla versione 13.0.35, sui FUSS Server vengono installate delle istanze di GLPI e Semaphore UI per la gestione dei computer della rete scolastica.

In particolare, GLPI viene usato per gestire l’inventario dei computer, mentre Semaphore permette di eseguire operazioni sugli stessi, tramite playbook ansible o script di shell.

L’obiettivo è di usarli in sostituzione della gestione macchine di Octonet, che verrà disabilitata in una futura versione (major release) di FUSS.

Architettura

GLPI e Semaphore sono raggiungibili sulla rete scolastica all’indirizzo https://glpi.<dominio> e https://semaphore.<dominio> rispettivamente.

Su entrambi è presente un account con accesso completo, con password la master password del server, rispettivamente glpi e admin.

Una volta che GLPI è stato installato sui FUSS Server, fuss-client verrà configurato per installare glpi-agent e configurarlo per inviare i dati delle macchine al server locale, oltre che eventualmente a quello della provincia di Bolzano (vedi FUSS Zone).

Semaphore

fuss-server configura Semaphore con un progetto FUSS, nel quale è presente l’integrazione con GLPI e la rete locale.

In particolare sono presenti:

l’inventory local GLPI, rigenerato ogni ora a partire dai dati di GPLI;
il keystore fuss_server_root, contenente la chiave ssh usata per collegarsi dal server ai client.

Inoltre è presente un repository FUSS Playbooks che punta ad un checkout locale di https://gitlab.fuss.bz.it/fuss/fuss-playbooks.git , aggiornato quotidianamente. Questo repository contiene dei playbook di uso comune distribuiti dal progetto FUSS.

HOWTO

Installare pacchetti sui client

Per installare un elenco di pacchetti .deb su una selezione di client è necessario creare un nuovo Task Template di tipo Ansible Playbook nella sezione relativa.

Si può dare un nome a piacere, quindi specificare plays/install_packages.yml come percorso del playbook, local GPLI come Inventory e FUSS Playbooks come Repository.

Nelle opzioni avanzate serve aggiungere una survey variable il cui nome sia packages alla quale si può impostare un valore di default che sia un elenco di pacchetti separati da virgole, senza spazi; questo valore si potrà poi comunque cambiare quando si lancia il task.

Nelle opzioni di Ansible si possono poi configurare dei limiti inserendo il nome di un gruppo al quale si vuole limitare l’installazione dei pacchetti.

A quel punto si può salvare il task template e premere RUN: verrà chiesto il valore della variabile packages, e quindi il playbook verrà applicato a tutti i computer del gruppo indicato.

Lanciare comandi arbitrari sui client

Similmente all’installazione dei pacchetti si può lanciare un comando arbitrario su un gruppo di client usando il playbook plays/run_cmd.yml e la variabile command.

Pianificare operazioni

Per pianificare operazioni perché vengano eseguite in una data futura (una volta o periodicamente) è necessario creare innanzitutto un Task Template come quelli negli esempi qui sopra.

Quindi nella sezione Schedule si può creare una nuova Schedule di tipo Cron per le esecuzioni ricorrente, o Run Once per un esecuzione singola pianificata, indicando il template che si è creato precedentemente, impostandone le relative variabili e l’ora e data di esecuzione.

Attenzione che l’esecuzione viene impostata in UTC, ma in fondo alla schermata si può vedere la data e ora della prossima esecuzione sia in UTC che nel fuso orario locale.

Migrazione da Octonet

Per ciascuna scuola è necessario scegliere una data nella quale la fonte ufficiale dei dati dei client passa da essere Octonet ad essere GLPI.

Pre-migrazione

Prima della migrazione è possibile iniziare ad usare GLPI per esplorare le macchine visibili sulla rete.

Per usare Semaphore per eseguire comandi, è necessario aggiungere le macchine manualmente a dei gruppi GLPI, in modo che siano visibili nell’inventory ansible.

Post-migrazione

Dopo la migrazione sarà possibile, ma sconsigliato, continuare ad usare Octonet per effettuare operazioni sui client.

Non lo si potrà però usare per gestire l’assegnazione dei client ai cluster: il file /etc/clusters verrà periodicamente rigenerato a partire dai dati GPLI, ignorando e sovrascrivendo eventuali modifiche fatte in altro modo.

Migrazione

Per supporare la migrazione è disponibile lo script load_locations_from_etc_clusters.py, da lanciare nel giorno scelto, che legge i cluster esistenti in /etc/clusters e li converte in Locations di GLPI, assegnandole alle macchine conosciute.

Una volta lanciato sarà opportuno controllare le Location generate, compilando eventuali altri campi utili.

È poi necessario importare in /etc/fuss-server/fuss-server-defaults.yaml la variabile legacy_authoritative_octonet a false e lanciare fuss-server, in modo che venga generata la generazione periodica (ogni ora) di /etc/clusters a partire dai dati GLPI.