Miniguide software

Configurazione del fuss-server per abilitare l’invio di posta

La spedizione diretta di messaggi di posta elettronica dalle macchine della rete interna (LAN) del Fuss Server è disabilitata per motivi di sicurezza. Qualora per esigenze specifiche (ad esempio l’uso della funzionalità di «scan to mail» delle stampanti multifunzione), sia necessario consentire ad una macchina o un apparato di inviare posta, si possono utilizzare le seguenti istruzioni per potersi appoggiare al Fuss Server per l’invio.

Sul Fuss Server è infatti installato il server SMTP Postfix, che però è configurato per accettare posta da inviare solo da localhost. La direttiva mynetworks, che controlla quali macchine possono inviare posta passando dal server, si trova nel file /etc/postfix/main.cf ed il suo valore di default è il seguente:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Per consentire ad altre macchine o apparecchiature come una stampante multifunzione di inviare posta occorre anzitutto avere l’indirizzo IP; si deve inoltre avere cura di impostatalo in maniera statica in modo che non cambi ad un eventuale riavvio della stampante.

Una volta che l’indirizzo IP sia noto, occorrerà aggiungerlo all’elenco di quello consentiti da mynetworks. La direttiva, come dice il nome richiede una lista di reti pertanto se si indica un solo IP occorrerà usare la notazione CIDR aggiungendo il suffisso /32. L’elenco delle reti deve essere fornito come lista separata da spazi, si può andare a capo e scriverlo su più righe, avendo cura di iniziare ogni riga di estensione con degli spazi.

Per esempio se si hanno stampanti multifunzione che utilizzano lo «scan to mail» con indirizzi IP 192.168.0.10, 192.168.0.15, e 192.168.0.20 per consentirgli di spedire posta verso l’esterno passando dal Fuss Server occorrerà modificare la precedente configurazione in:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
   192.168.0.10/32 192.168.0.15/32 192.168.0.20/32

e riavviare il servizio con service postfix restart.

A questo punto si potrà configurare la stampante (o altro apparato) indicando come server SMTP il fuss server stesso.

Nota

si consiglia per sicurezza di usare l’indirizzo IP del server, che continuerà a funzionare anche qualora la stampante non sia in grado di risolvere i nomi assegnati alle macchine sulla rete interna.

Aggiornare Proxmox dalla versione 4 alla versione 5

La procedura è illustrata anche nella documentazione sul wiki di Proxmox alla pagina https://pve.proxmox.com/wiki/Upgrade_from_4.x_to_5.0; nella sezione «In-place upgrade» che tratta anche il caso dei cluster e dell’uso di CEPH che non si applica alla installazione tipica usata per FUSS.

Per quanto sia indicata come preferibile una reinstallazione da zero, seguita dalla reimportazione delle macchine virtuali, la procedura di aggiornamento in loco è stata verificata e portata avanti con successo senza nessun problema parecchie volte.

Predisposizione

Il primo passo prima di passare all’aggiornamento alla versione 5 è assicurarsi che la versione 4 sia completamente aggiornata, pertanto prima di iniziare si eseguano i comandi:

apt-get update
apt-get dist-upgrade

e qualora nell’aggiornamento venga installato un nuovo kernel si riavvii la macchina per usarlo.

Tutte le macchine virtuali devono essere spente (e qualora siano presenti, anche se non previsti nel caso di FUSS) anche eventuali container. Possono essere spente dalla riga comando con qm shutdown <VMID> e pct shutdown <VMID>.

É una buona precauzione eseguire comunque anche un dump delle macchine virtuali, anche se questo sarà necessario soltanto in caso di problemi (mai verificatosi in decine di aggiornamenti). Per questo sarà sufficiente eseguire il comando vzdump <VMID> -dumpdir /pathname dove /pathname è il nome di una directory su un filesystem dove ci sia spazio disco sufficiente a contenere l’immagine della macchina virtuale (ad esempio una directory del NAS montata con NFS).

Si verifiche che sul filesystem della radice ci sia almeno un giga-byte di spazio disco disponibile (se si è alle strette si possono cancellare i pacchetti scaricati con apt-get clean e cancellare eventuali immagini ISO o template usati nelle installazione sotto /var/lib/vz/template/). Si verifichi anche che nel filesystem della directory /boot ci sia lo spazio sufficiente per installare un altro kernel (si possono cancellare le versioni più vecchie disinstallando i relativi pacchetti).

Aggiornamento

Una volta completate le operazioni preliminari è sufficiente modificare le fonti di APT di Debian da Jessie a Stretch con il comando:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

e quelle di Proxmox con:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list.d/pve-install-repo.list

ed eventualmente anche quella di /etc/apt/sources.list.d/pve-enterprise.list che comunque dovrebbe restare commentata.

Se sono presenti delle righe con riferimento a backports queste vanno commentate, ma se si sono seguite le istruzioni di questa guida queste non dovrebbero essere presenti.

Il comando che esegue l’aggiornamento sia di Debian che di Proxmox è:

apt-get dist-upgrade

durante la sua esecuzione verranno fatte da debconf alcune domande relative alla sovrascrittura dei file di configurazione, attinenti ai pacchetti Debian, cui in genere si può rispondere dicendo di installare la versione del file fornita dal manutentore del pacchetto, in particolare verrà chiesto:

• se sostituire /etc/issue
• se sostituire la configurazione di SSH (/etc/ssh/sshd_config)
• altre domande sono possibili se si sono installati software aggiuntivi come XFCE o l’interfaccia grafica

Una volta completato l’aggiornamento occorrerà riavviare per poter usare il nuovo kernel.

E” inoltre possibile che nell’aggiornamento /etc/apt/sources.list.d/pve-enterprise.list venga sovrascritto, ripristinando il contenuto originale, non commentato, in tal caso sarà necessario ricommentare lo stesso dato che il repository «enterprise» non è accessibile (e comunque non serve).

Troubleshooting

Durante l’aggiornamento periodico di Proxmox 5.x può comparire il seguente errore:

The following packages have unmet dependencies:
pve-firmware : Conflicts: firmware-linux-free but 3.4 is to be installed

In tal caso è sufficiente rimuovere il pacchetto linux-image-amd64:

apt remove linux-image-amd64

procedendo poi con gli aggiornamenti.

Problemi con CD e DVD

Montaggio dei CD-ROM

Problema nel montaggio

I CD-ROM vengono montati in automatico in /media/cdrom0. Questo è dovuto al fatto che in /etc/fstab si trova la seguente riga:

/dev/sr0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Per alcuni DVD didattici, come ad esempio i DVD della Zanichelli, questo è un problema serio, perchè lo script che viene lanciato richiede rigidamente che il DVD sia montato in /media/<nome-utente>.

Inoltre, il contenuto del CD non ha l’utente come proprietatrio, e tutti i file e le directory sono assegnate a nobody:nogroup (cioè non sono assegnati).

Soluzione del problema

Per poter fare ciò, bisogna fare in modo che in /etc/fstab non venga letta la riga sopra indicata.

Lo script seguente risolve il problema:

#! /bin/sh
if [ ! -f /etc/fstab-old ]
then
    cp /etc/fstab /etc/fstab-old
fi
sed -i 's/^\/dev\/sr0/#\/dev\/sr0/' /etc/fstab

Riavviato il PC il DVD-ROM è montato in /media/<nome-utente>/<nome-cd>

DVD Zanichelli

I DVD della Zanichelli della serie “Idee per insegnare con il digitale” si possono vedere con la nostra distribuzione, a patto di installare prima alcuni pacchetti, da cui dipende l’esecuzione del programma.

Lo script che segue permette l’installazione dei pacchetti che servono:

#! /bin/sh
echo "deb http://ftp.de.debian.org/debian/ jessie main" >>/etc/apt/sources.list
apt update && apt upgrade
apt install libpng12-0 gstreamer0.10-fluendo-mp3 gstreamer1.0-alsa gstreamer0.10-alsa

Aprire un terminale e come utente, digitare il seguente comando:

sh /media/<nome-utente>/<nome-cd>/BooktabZ-StartCD_lnx.sh

Installazione dei DVD-ROM Oxford su FUSS 9

Premessa

La seguente procedura è valida solo per macchine a 64 bit in quanto il software non è compatibile con Debian 9 a 32 bit. E” stata elaborata per i DVD-ROM della serie New Treetops ma è valida anche per altri prodotti Oxford come High Five .

Problema nel montaggio

I DVD-ROM vengono montati in automatico in /media/cdrom0 e di default non sono eseguibili. Questo è dovuto al fatto che in /etc/fstab si trova la seguente riga:

/dev/sr0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Soluzione del problema

Bisogna fare in modo che il DVD-ROM venga rimontato in modalità eseguibile. Inserire il cdrom e da terminale lanciare da root:

mount -o remount,exec,ro  /media/cdrom0

Installazione

Per installare, entrare in /media/cdrom0 e lanciare l’eseguibile setup-linux-x64 che apre il wizard di installazione. Terminata l’installazione, cliccare su Finish nel Wizard e su Ok nella finestra README. A questo punto si può smontare il DVD-ROM.

Avvio del programma

Nella home di chi installa viene creata una cartella ~/Oxford University Press/ che contiene una sottocartella per ciascun DVD-ROM della serie.

Per avviare ad esempio il secondo volume si segue il percorso:

~/Oxford University Press/New Treetops 2a/linux-x64/ # Ovviamente inserire i backslash se si lavora da terminale.

e si lancia l’eseguibile oup (nel volume 3 si lancia New Treetops 3a).

Installazione adobe-flashplugin

La visualizzare dei video dell’applicazione richiede adobe-flashplugin. Fortunatamente durante l’installazione viene creata una sottocartella nascosta (~/Oxford University Press/New Treetops 3a/.flash_installers/linux-x64/) che contiene alcuni pacchetti debian di adobe-flashplugin. Se è presente, rimuovere flashplayer-mozilla:

apt remove flashplayer-mozilla

Installare uno dei pacchetti adobe-flashplugin (è stato testato il file del comando che segue):

dpkg -i adobe-flashplugin_11.2.202.280-0precise1_amd64.deb

Cartella condivisa

La cartella contenente le installazioni dai DVD-ROM può essere copiata in una cartella condivisa dai docenti ed eventualmente dagli alunni. Il proprietario della cartella è preferibile sia root per evitare cancellazioni involontarie, mentre il gruppo proprietario deve avere solo permessi di lettura ed esecuzione. In alternativa si lascia permesso di lettura ed esecuzione a tutti.

Eventuale lanciatore da scrivania

Se si preferisce lanciare le applicazioni da scrivania si possono creare dei lanciatori:

1) Cliccare col tasto destro

2) Selezionare ``Crea avviatore``

3) Scegliere un nome ed il comando con l'accortezza di inserire i backslash prima degli spazi vuoti.
   Ad esempio il comando per lanciare New Treetops 2a sarà::

   ~/Oxford\ University\ Press/New\ Treetops\ 2a/linux-x64/oup

sostituendo alla tilde ~ il percorso completo della home dell'utente o della cartella condivisa.

Impostazioni chromium

Premessa

La seguente miniguida è nata dall’esigenza di risolvere due problemi:

1. All’avvio del browser chromium viene richiesto insistentemente di inserire la password di sblocco del portachiavi
2. Diversi utenti vorrebbero che le credenziali di accesso al proxy venissero memorizzate senza dover essere digitate ogni volta.

Soluzione al problema 1

1a) Da root

Modificare il lanciatore di chromium:

vim /usr/share/applications/chromium.desktop

Modificare all’interno del file il comando che deve essere:

Exec=/usr/bin/chromium -password-store=basic  %U

1b) Da utente normale

• Creare un lanciatore trascinando l’icona del browser chromium dal menù al pannello e confermando.
• Cliccare col tasto destro sul lanciatore e selezionare Proprietà. Si apre la finestra:

• Cliccare su Modifica l'elemento selezionato
• Aggiungere alla riga Comando la stringa -password-store=basic (eventualmente anche --incognito se si vuole navigare in modo «anonimo»).

Soluzione al problema 2

• L’offerta di salvataggio delle credenziali proxy si presenta in modo imprevedibile e difficilmente replicabile; a volte si verifica cancellando la cartella ./config/chromium e deselezionando Accesso automatico in Impostazioni > Persone > Password.
• Il modo più semplice e certo di ottenere il risultato è quello di utilizzare un’estensione scaricabile da Web store che memorizza le credenziali proxy, che non verranno più richieste. Ovviamente l’utente deve ricordarsi di aggiornarle quando la password dell’account viene cambiata.

Guida Veyon su Fuss 10

Avvertimento

A partire da FUSS Client 10.0.40, la configurazione di Veyon viene fatta in maniera completamente automatica.

Per la configurazione si faccia riferimento alla sezione Veyon in Gestione dei FUSS client

La seguente procedura di installazione e configurazione non è al momento più necessaria!!!

Sulla postazione principale installare veyon-master

apt install  veyon-master

Su tutte le macchine controllate installare veyon-service

apt install  veyon-service

Ciascuno dei due pacchetti porta con sè alcune dipendenze.

Abilitare in entrambi i casi veyon-service con il comando:

systemctl enable veyon-service

Sulla postazione principale, nel Menu delle applicazioni (sottomenù Internet) troviamo::

• Veyon Master
• Veyon configurator

Creazione gruppo veyon-client

Per impedire che chiunque (anche un docente) possa essere “controllato” attraverso Veyon: Creare un gruppo LDAP veyon-client (Attenzione: non deve essere gruppo primario per nessuno!) a cui aggiungere gli utenti che possono/devono essere controllati.

In ogni postazione controllata, per semplicita client :

inserire nella cartella:: /etc/fuss-client/session-setup-script (cartella in cui vengono inseriti gli script da lanciare all’avvio della sessione utente ma eseguiti da root) uno script con nome veyonStart (nome arbitrario) contenente:

#!/bin/bash

# si crea una lista di utenti aventi come gruppo secondario veyon-client

lista_utenti=("$(getent group veyon-client | awk -F ':' '{print $4}' | sed 's|,| |g')")

for i in  $lista_utenti
do
    # Se l’utente appartiene al gruppo  veyon-client vengono lanciati le istruzioni seguenti

    if [ "$i" == "$USER" ]
    then
        # Stoppa il servizio veyon-service
        systemctl stop veyon-service &
        # Rilancia il servizio per l’utente
        su -c veyon-service $USER &
    fi
done

Sempre in ogni client inserire nella cartella /etc/fuss-client/session-cleanup-script (cartella in cui vanno inseriti gli script da lanciare alla chiusura della sessione utente ma eseguiti da root) uno script con nome veyonStop (nome arbitrario) contenente:

#!/bin/bash
# vengono killati tutti i processi veyon e riavviato quello di root
pkill veyon &
# Questo riavvio permette il controllo dei pc anche quando non è loggato nessun utente
systemctl restart veyon-service

Ricordarsi di renderli eseguibili con:

chmod +x Nome-file

Sulla postazione principale :

Premessa:

Con la seguente configurazione si rilancia il servizio veyon-service permettendo il corretto funzionamento dei servizi di presentazione sul monitor. Lo script veyonStart è semplificato perchè può essere lanciato per tutti indipendentemente all’appartenenza ad un gruppo. Si veda in seguito le modifiche per permettere l’avvio dell’applicativo Veyon master solo ad un gruppo ristretto di utenti (ad es. un gruppo veyon-master).

Inserire nella cartella /etc/fuss-client/session-setup-script uno script con nome veyonStart (nome arbitrario) contenente:

#!/bin/bash
pkill veyon & # killa tutti i processi veyon
systemctl stop veyon-service &
su -c veyon-service $USER & # Rilancia il servizio veyon per l’utente

Sempre sul master inserire nella cartella /etc/fuss-client/session-cleanup-script uno script con nome veyonStop (nome arbitrario) contenente:

#!/bin/bash
# vengono killati tutti i processi veyon e riavviato quello di root
pkill veyon &
systemctl start veyon-service  # Questo riavvio permette il controllo dei pc anche quando non è loggato nessun utente

Configurazione su Veyon Configurator

Il resto della configurazione si esegue nell’applicazione Veyon Configurator lanciabile da Menu o da terminale con:

veyon-configurator.

Si può lanciare da root oppure da utente sudoer. La configurazione base è molto semplice (e quasi tutta di default); si consiglia di attenersi a questa perché le configurazioni alternative nel nostro sistema danno risultati imprevedibili.

Configurazione generale

Servizio

Principale

Non è necessario fare modifiche.

Controllo accessi

Chiavi di autenticazione

Lasciare invariato se non si decide di utilizzare le chiavi pubbliche e private per collegare master a client (non è necessario!).

Stanze & computer

Cliccando sul pulsante + si possono aggiungere stanze (aule) a sinistra ed i rispettivi Computer a destra. Importanti Nome e FQDM (es. computerX.scuola.blz, ma in genere funziona anche senza il dominio), consigliato al posto dell’IP, che può variare nel tempo;

https://veyon.nodebb.com/topic/23/i-can-usse-without-ip-statics

l'Indirizzo MAC si inserisce solo se si intende usare l’accensione e lo spegnimento da remoto.

Le altre configurazioni non sono necessarie e per il momento non vengono trattate.

RENDERE VEYON-MASTER ACCESSIBILE SOLO AI DOCENTI

Nel caso si sia deciso di installare veyon-master in tutte le postazioni, per evitare che un alunno possa controllare un altro utente si consiglia di disabilitare il programma per gli utenti che non appartengono al gruppo veyon-master e rendere l’applicazione visibile solo agli stessi utenti.

Si può ottenere questo risultato lanciando da root sulle postazioni che utilizzano veyon il seguente script o i comandi in esso contenuti:

#! /bin/bash
# I due seguenti comandi permettono solo agli utenti del gruppo veyon-master di lanciare il comando
chgrp  veyon-master /usr/bin/veyon-master
chmod 754 /usr/bin/veyon-master
# I due seguenti comandi permettono solo agli utenti del gruppo veyon-master di vedere l’applicazione nel menu
chgrp  veyon-master /usr/share/applications/veyon-master.desktop
chmod 640 /usr/share/applications/veyon-master.desktop

IMPORTANTE!!! Ricordarsi di aggiungere tutti gli utenti controllori (i docenti) al gruppo veyon-master e tutti gli utenti da controllare (studenti) al gruppo veyon-client.

Installazione del pacchetto giochi iprase

Premessa

E` una raccolta di giochi didattici per bambini della scuola dell’obbligo. IPRASE, aderendo al progetto sperimentale nell’ambito delle attività a cofinanziamento del Fondo Sociale Europeo sulla Didattica assistita dalle nuove tecnologie, ha realizzato una sperimentazione nella scuola dell’obbligo per tre anni consecutivi a partire dall’anno scolastico 2001-2002. Obiettivo dell’iniziativa era quello di fornire strumenti utili all’introduzione delle nuove tecnologie nella didattica e nella prassi di lavoro quotidiana dei docenti. La sperimentazione era rivolta a insegnanti ed alunni della scuola elementare e della scuola media. Si proponeva l’utilizzo di giochi ed eserciziari da fare al computer e riguardanti conoscenze ed abilità nelle seguenti discipline: Italiano, Geografia, Matematica. Nonostante siano trascorsi diversi anni, i giochi sono ancora molto apprezzati. Il loro uso e pacchettizzazione è stato consentito.

Aggiunta dell’architettura i386

Per funzionare, l’applicazione (basata su eseguibili .exe), richiede l’utilizzo di wine e l’architettura i386, che si può aggiungere con il comando:

dpkg --add-architecture i386

Per aggiornare la cache coi pacchetti i386 si lancia:

apt update

Infine si installa l’applicazione con:

apt install iprase

Installazione in locale con pacchetto .deb

Nel caso si sia scaricato in locale il pacchetto iprase_1.1.deb, aggiungere l’architettura i386 e dopo apt update e apt dist-upgrade è sufficiente lanciare:

dpkg -i iprase_1.1.deb

Share Samba con struttura di sottocartelle

La struttura di share Samba supportata da OctoNet permette solo una lista piatta di condivisioni.

In casi particolari può essere necessaria una struttura gerarchica, come ad esempio la seguente, in cui ci sono due cartelle, docenti e alunni, e:

• alla cartella docenti può accedere solo chi appartiene al gruppo docenti;
• la cartella alunni ha al suo interno le cartelle di classe a cui possono accedere:
  • gli alunni appartenenti al gruppo classe, alla sola cartella della loro classe;
  • i docenti, alle cartelle delle classi al cui gruppo appartengono (come assegnazione di gruppo secondario da OctoNet).

In questo caso è necessario creare delle cartelle con i seguenti permessi sul filesystem:

root@serverlnx:~# ls -l /home/SAMBA/pubblica/ -a
totale 16
drwxrwsr-x 4 root insegnanti 4096 mar 12 15:41 .
drwxr-xr-x 9 root root       4096 mar 12 15:41 ..
drwxrwsr-x 5 root insegnanti 4096 mar 12 15:41 alunni
drwxrws--- 2 root insegnanti 4096 mar 12 15:41 docenti

(2775 per le directory cui devono accedere anche gli alunni (/home/SAMBA/pubblica/ e /home/SAMBA/pubblica/alunni) e 2770 per docenti dove non devono arrivare); e:

root@serverlnx:~# ls -l /home/SAMBA/pubblica/alunni/
totale 12
drwxrws--- 2 root 1a 4096 mar 12 15:41 1A
drwxrws--- 2 root 1b 4096 mar 12 15:41 1B
drwxrws--- 2 root 1c 4096 mar 12 15:41 1C

(permessi 2770 e gruppo assegnato alla classe).

La configurazione di samba, da aggiungere in shares.conf sarà allora:

[pubblica]
path = /home/SAMBA/pubblica
guestok = no
readonly = no
create mask = 0660
directory mask = 2770
readlist = @Domain+Users
writelist = @insegnanti

Aggiornamento dei fuss-client tramite fuss-cru

Per aggiornare i fuss-client da una versione fuss alla successiva si può usare il pacchetto fuss-cru. Le versioni 11.* di tale pacchetto supportano l’aggiornamento da fuss 10 (buster) a fuss 11 (bullseye).

• Innanzitutto assicurarsi di aver aggiornato fuss-server almeno alla versione 10.0.45, e di aver lanciato fuss-server upgrade: questo è necessario per abilitare il caching dei pacchetti debian e rendere più veloce l’aggiornamento.
• Installare sul fuss-server il pacchetto fuss-cru; questo creerà automaticamente un nuovo script in octonet.
• aggiungere un’esecuzione dello script clientupgrade su octonet e programmarla come di consueto.

Nota

Ricordarsi che octonet-client cerca gli script da eseguire al boot ed ogni 5 minuti, e quindi l’esecuzione non è istantanea.

Configurazione per l’uso dell’agent di OCS inventory

L’agent può essere installato sulle macchine fisiche (quindi proxmox e i client) all’interno della rete di una scuola. L’agent viene installato sui client in maniera automatica da fuss-client (a partire dalla versione 10.0.51) sia in fase di collegamento del client al server, che in caso di aggiornamento. È necessario che sia presente sul FUSS server la corretta configurazione, da impostare con le modalità che illustreremo più avanti.

Per installarlo su Proxmox, o su qualunque altra macchina (Debian) raggiungibile dal FUSS Server, occorrerà invece lanciare sullo stesso il playbook ocs-agent-inst (installato in /usr/share/fuss-server/) che viene fornito con il pacchetto fuss-server a partire dalla versione 10.0.52. Lo script è usabile anche per un client, ma è preferibile evitarne l’uso dato che la configurazione viene comunque generata da fuss-client, in modo leggermente diverso, per essere aggiornabile automaticamente da future versioni del pacchetto.

Per poter funzionare, l’agent ha bisogno di raggiungere via rete la macchina su cui è ospitato il server di OCS inventory; questo viene contattato via web e pertanto è necessario come primo passo abilitarne la raggiungibilità. Questa operazione deve essere fatta preliminarmente sul FUSS server aggiungendo una opportuna regola di accesso per il proxy, che consenta di arrivare al server OCS inventory senza necessità di autenticazione; allo scopo basterà aggiungere al file /etc/squid/squid-added-repo.conf la riga:

acl repositories url_regex ocs.inventory.server

dove ocs.inventory.server è l’indirizzo del server OCS inventory che si intende utilizzare. Dopo la modifica si dovrà eseguire un reload di squid con systemctl reload squid.

Il passo successivo prevede di:

• (se il certificato del server è autofirmato), scaricarlo dal sito, nominarlo server.crt e copiarlo sul server FUSS nella cartella /var/www/fuss-data-conf/
• creare nella stessa cartella il file ocsinventory.yml (con sintassi YAML) contenente i paramenti di configurazione da usare successivamente sui client. Questo file verrà poi scaricato su ciascun client al momento del lancio del fuss-client.

Il file prevede la definizione di tre variabili, le prime due sono obbligatorie, la terza è opzionale:

• ocs_server : l’indicazione della URL del server, ad esempio https://ocs.inventory.server/ocsinventory
• ocs_tag : il tag che identifica la scuola, ad esempio il codice (LASIS) numerico della scuola
• ocs_cert : (opzionale) il nome del certificato da usare per la connessione SSL (necessario solo se il server ha un certificato autofirmato); se definita detto file deve essere installato sotto /var/www/fuss-data-conf/ .

Un esempio di questo file è il seguente:

# template for ocsinventory variables needed for fuss-client
ocs_server: https://ocs.inventory.server/ocsinventory
ocs_tag: change-me
ocs_cert: server.crt

Per evitare che un aggiornamento eseguito su un client durante la configurazione trovi un file ocsinventory.yml scritto parzialmente, con conseguenti errori, si suggerisce di crearlo in un altra directory, spostandolo a destinazione una volta completo (insieme al file del certificato preventivamente caricato sul server, quando necessario) con:

mv ocsinventory.yml /var/www/fuss-data-conf/

Nota

si consiglia, se possibile, di configurare il server di OCS inventory con un certificato valido (ad esempio usando Let’s Encrypt) evitando l’uso di un certificato autofirmato; in tal caso la variabile ocs_cert non è necessaria, come non lo è il certificato.

A questo punto, per l’installazione dell’agent è sufficiente eseguire fuss-client. Il file di configurazione (ocsinventory.yml), quando presente, viene scaricato nell’esecuzione del comando (sia quando su usa -a o -H per collegare un nuovo client, che quando si usa -U per un aggiornamento), e viene salvato in /etc/fuss-client/. Quando tale file viene trovato, viene poi eseguita la configurazione e l’installazione di ocsinventory-agent. Se invece il file non viene trovato sul server, il programma prosegue senza installare nulla.

Nel caso in cui ci si dimenticasse di copiare sul server FUSS il certificato server.crt prima di aver lanciato il fuss-client, si può correggere il problema (dopo aver copiato il certificato sul server) rilanciando il comando fuss-client -U.

Installazione di ocs agent su una macchina generica (non joinata)

Per installare l’agent su una macchina generica si può invece utilizzare il playbook ocs-agent-inst presente sul FUSS server. Questo esegue l’installazione di ocsinventory-agent su una macchina generica da indicare come parte dell’inventario Il comando deve cioè essere eseguito sul FUSS server come:

/usr/share/fuss-server/scripts/ocs-agent-inst -i <client.address.or.ip>,

avendo cura di mettere una virgola dopo l’indirizzo del client in modo che venga riconosciuto come elenco di indirizzi e non come nome di file.

Si tenga presente che il playbook richiede l’accesso via SSH alla macchina indicata; qualora non si abbia un accesso diretto con le chiavi, occorrerà richiedere l’uso della password (di root) aggiungendo l’opzione -K.