FUSS - Manuale per il tecnico 12.0 documentazione

Cloud-Init

FUSS - Manuale per il tecnico

Il presente manuale è una guida rivolta ai tecnici FUSS per la
manutenzione di un’installazione FUSS GNU/Linux
basata su Debian 12 «Bookworm».
La versione più recente di questo manuale è leggibile all’indirizzo
https://fuss-tech-guide.readthedocs.io/it/latest/

Guida rapida all’installazione
Questo capitolo è dedicato a chi vuole vedere velocemente come
installare un server FUSS ed un client.

Topologia di una tipica rete didattica
Prima di mostrare come installare server e client, vediamo nella
seguente figura la tipica topologia di rete dove FUSS può trovare
applicazione.

Tipica topologia di una rete FUSS

Un server FUSS deve avere almeno 2 interfacce di rete. La prima serve
per la connessione alla WAN (Wide Area Network) mentre la seconda è
collegata alla rete locale (LAN-1) della scuola. La presenza di una
terza porta Ethernet sul server e di una seconda LAN nella scuola alla
quale sono connessi degli access point WiFi sono i presupposti per poter
installare sul server FUSS un captive-portal che offre la possibilità a
dispositivi satellite di accedere ad internet previa autenticazione.

Installazione di FUSS server dal template cloud-init ready
A partire dalla versione 10 è disponibile una modalità di installazione più
veloce del FUSS server partendo da una immagine di macchina virtuale
preinstallata con il supporto per la tecnologia di autoconfigurazione
cloud-init.
Questa modalità può essere utilizzata solo con un sistema di virtualizzazione,
qui verrà illustrato come farlo con la piattaforma di virtualizzazione
Proxmox, adottata dal progetto, che supporta la tecnologia indicata
consentendo di gestire tutte le caratteristiche della macchina virtuale
direttamente dalla sua interfaccia web.
In particolare diventa possibile:

gestire indirizzi di rete, gateway e DNS dall’interfaccia web
gestire hostname e dominio dell’interfaccia web
allargare automaticamente il disco radice una volta ridimensionato
sull’interfaccia web

Installazione della macchina virtuale
Il primo passo è scaricare l’immagine predisposta dal progetto per
inserirla fra i dump disponibili per il ripristino. Questa è disponibile
all’indirizzo
http://iso.fuss.bz.it/cloud-init/vzdump-qemu-fuss-server-12-latest.vma.zst
e la cosa più semplice è scaricarla direttamente sul server Proxmox su
cui sarà utilizzata collegandosi con SSH ed eseguendo:
# cd /var/lib/vz/dump/
# wget http://iso.fuss.bz.it/cloud-init/vzdump-qemu-fuss-server-12-latest.vma.zst

Nota
se si è configurato in Proxmox uno storage diverso da local per
le immagini dei dump ci si ponga nella rispettiva directory invece
che sotto /var/lib/vz/dump/.

Nota
le immagini più recenti sono compresse con il formato zstd ed il
file ha estenzione .zst, alcune delle prime immagini (il cui uso
è comunque sconsigliato) sono in formato lzo ed hanno estensione
.lzo.

Una volta completato il download l’immagine comparirà fra in contenuti
dello storage (dall’interfaccia web) e si potrà iniziare il ripristino
anche direttamente dall’interfaccia selezionandola ed usando il pulsante
«Restore» che creerà una nuova macchina virtuale sul primo VMID libero,
l’interfaccia comunque consente di indicarne uno specifico diverso. Si
abbia cura di indicare, sempre nella finestra di ripristino, l’uso di
local-lvm come storage di ripristino e mettere la spunta sulla
casella «Unique».
Si tenga presente che perché questo funzioni regolarmente occorre avere
configurato Proxmox per l’uso di FUSS, la macchina virtuale infatti assume la
presenza di almeno due diverse interfacce di rete, una sulla rete esterna
(vmbr0) ed una sulla rete interna (vmbr1); qualora non fosse così si
potranno comunque cambiare le assegnazioni delle interfacce una volta
ripristinata la macchina virtuale.
Alternativamente si può eseguire il ripristino dalla riga di comando (si
assume che si sia configurato lo storage su LVM con il nome utilizzato nella
installazione di default di Proxmox) con:
qmrestore /var/lib/vz/dump/vzdump-qemu-000-0000_00_00-00_00_00.vma.zst \
   106 -storage local-lvm -unique

dove al posto di 106 si può usare un qualunque VMID libero. Lo storage
deve essere local-lvm (come l’installazione diretta) e l’uso di -unique
consente di generare un MAC address della nuova VM che non confligga con altri
eventualmente presenti (è poco probabile, a meno che non si reistallino più
machine dalla stessa immagine di partenza, ma è buona norma farlo).
Una volta ripristinata l’immagine gli si deve associare l’immagine del disco
di configurazione con:
qm set 106 --ide2 local-lvm:cloudinit

Nota
se si ottiene un errore del tipo:
lvcreate 'pve/vm-106-cloudinit' error:   Logical Volume "vm-106-cloudinit" already exists in volume group "pve"

si rimuova la precedente istanza del volume logico con:
lvremove pve/vm-106-cloudinit

e si ripeta il comando.

A questo punto prima di avviare la macchina per la prima volta si potrà
configurare la rete dall’interfaccia web, nella sezione Cloud-Init,
impostando: gli IP sulle interfacce di rete, il default gateway per
l’interfaccia esterna, una chiave SSH di accesso a root, il dominio ed il
server DNS. Quest’ultimo deve essere sempre 127.0.0.1, ed il nome a
dominio dovrà essere quello che verrà poi utilizzato nella configurazione
finale eseguita dal comando fuss-server.

Avvertimento
si deve sempre configurare il server DNS come 127.0.0.1 e
il nome a dominio uguale a quello che verrà usato poi con il comando
fuss-server altrimenti si rischia che in una successiva esecuzione di
fuss-server, o nella riesecuzione dell’inizializzazione di cloud-init,
ci siano interferenze e sovrascritture reciproche

Tutte queste operazioni si possono fare anche a riga di comando; per inserire
i suddetti parametri nelle configurazioni di cloud-init (si adattino gli
indirizzi di rete alle proprie esigenze) si esegua:
qm set 106 --ipconfig0 ip=10.0.101.79/24,gw=10.0.101.1
qm set 106 --ipconfig1 ip=192.168.0.1/24
qm set 106 --searchdomain fusslab.blz
qm set 106 --nameserver 127.0.0.1
qm set 106 --sshkey ~/.ssh/id_rsa.pub

l’ultimo comando, se si ha un elenco di chiavi, può essere sostituito da:
qm set 106 --sshkey elencochiavissh.txt

dove elencochiavissh.txt è un file contenente l’elenco di chiavi pubbliche
(una per riga) che verranno abilitate per la macchina in questione; lo si può
generare da un elenco di file di chiavi con qualcosa tipo cat *.pub >
elencochiavissh.txt.
Oltre alla configurazione della rete è opportuno impostare dall’interfaccia
web anche l’hostname della macchina. Questa corrisponde di default al nome
usato da Proxmox per la relativa VM (quello mostrato insieme al VMID
nell’interfaccia). Nell’immagine distribuita si è usato come nome di default
fuss-server-base-image che si potrà modificare nella sezione Options
dell’interfaccia web. Anche in questo caso la modifica si può fare a riga di
comando con:
qm set 106 --name serverhostname

Avvertimento
benché sia possibile impostare l’hostname della macchina in un
secondo tempo all’interno della stessa con hostnamectl, dato
che la configurazione iniziale della rete viene gestita comunque
da cloud-init, è opportuno configurare l’hostname direttamente in
questa sezione e verrà correttamente propagato anche nelle varie
configurazioni.

Avvertimento
si tenga presente che se si cambia uno qualunque di questi
parametri in un secondo tempo, tutte le configurazioni da lui
gestite verranno rigenerate da cloud-init al successivo
riavvio. Questo comprende anche le chiavi SSH del server, con la
conseguenza che le precedenti non saranno più valide; per cui se
ci si è già collegati alla macchina si otterrà il solito avviso
che le fingerprint delle chiavi del server non corrispondono, e
sarà necessario rimuoverle e riaccettarle da capo.

Si dovranno inoltre modificare i parametri hardware della macchina virtuale
(dalla omonima sezione Hardware nell’interfaccia web), per aumentare la
memoria ed allargare il disco quanto necessario, ed eventualmente aggiungere
le interfacce di rete mancanti (ad esempio quella per il captive portal). Si
dovrà anche abilitare l’accensione automatica della macchina virtuale
all’avvio, dalla sezione Options.  Anche per modificare queste
caratteristiche si può continuare ad operare direttamente a riga di comando,
con qualcosa del tipo:
qm set 106 --memory 4096
qm set 106 --onboot 1
qm resize 106 scsi0 500G

dove si aumenta la RAM assegnata alla macchina virtuale a 4G, si richiede il
lancio automatico al riavvio di Proxmox, e si allarga il disco a 500G. Se però
si decide di dedicare un disco separato per le home quest’ultima operazione
non deve essere eseguita, a meno che i 32G assegnati nell’immagine di default
al disco della radice risultino insufficienti, nel qual caso comunque la si
esegua con una dimensione opportuna.
Le immagini fornite hanno già attivato il discard sul disco di installazione
(quest’ultima opzione ha senso solo se, come nell’esempio, si ha un disco che
è stato estratto da uno storage che supporta il discard, come LVM-thin),
qualora fosse assente o non necessario lo si può attivare/disattivare
rispettivamente con:
qm set 106 --scsi0 local-lvm:vm-106-disk-0,discard=on
qm set 106 --scsi0 local-lvm:vm-106-disk-0,discard=off

Si tenga presente che le opzioni indicate verranno applicate al successivo
riavvio, anche per la parte di allargamento del disco, che verrà eseguita
automaticamente da cloud-init (con l’avvertenza però che questo è
possibile solo grazie allo specifico partizionamento usato dall’immagine
fornita dal progetto).
Alla fine del primo avvio della macchina virtuale vengono mostrate nella
console (accessibile dall’interfaccia web di Proxmox) le fingerprint delle
chiavi generate per il server SSH, che è possibile usare per verificarne la
correttezza alla prima connessione. Le si possono trovare in un secondo tempo
nel file /var/log/cloud-init-output.log.

Configurazioni post-installazione
Una volta finita l’installazione non è in genere necessario eseguire nessuna
altra configurazione, a meno di non avere necessità di mantere le home su un
disco separato, che è una buona pratica qualora serva mantenere le quote
disco, e che consentirà, in futuro, di eseguire un aggiornamento solo per la
parte di sistema, senza dover reinstallare i file nella home.
Si perde però in questo caso la capacità di avere un ridimensionamento
automatico del disco come avviene per il filesystem di root, in quanto
cloud-init gestisce questa funzionalità solo per quest’ultimo. Essendoci pro e
contro si lascia la valutazione dell’uso delle home separate a chi esegue
l’installazione, tratteremo comunque qui le modalità per configurare le home
su disco separato.

Creazione di un disco aggiuntivo per le home
Per installare le home su un disco separato si provveda ad aggiungere un disco
di dimensione opportuna alla macchina virtuale dall’interfaccia web (sezione
«Hardware», «Add->Hard Disk»). Si può eseguire la stessa operazione dalla riga
di comando con qualcosa del tipo:
pvesm alloc local-lvm 106 '' 100G
qm set 106 --scsi1 local-lvm:vm-106-disk-1,discard=on

(di nuovo l’opzione discard=on ha senso solo se si usa uno storage come
local-lvm).
A questo punto una volta avviato il server disco verrà visto all’avvio come
/dev/sdb.  Ci si colleghi come root e si verifichi che il disco sia
effettivamente riconosciuto come /dev/sdb; a questo punto lo si dovrà
partizionare e creare il filesystem per le home, questo si può fare con:
echo "start=2048, type=83" | sfdisk /dev/sdb
mkfs.ext4 /dev/sdb1

si recuperi l’UUID del disco e lo aggiunga a /etc/fstab, questo si può
fare con:
echo -e "# /home was on /dev/sdb1 during installation" >> /etc/fstab
echo -e "$(blkid -o export /dev/sdb1|grep ^UUID=) /home  ext4  defaults,grpquota,usrquota  0  2" >> /etc/fstab

Si sostituisca /dev/sdb1 con l’opportuno file di dispositivo se se ne è
usato un altro. A parte l’aggiunta di un commento esplicativo il comando
estrae l’UUID del filesystem appena creato e crea una voce corretta per le
home con le opzioni per avere le quote e il giusto numero di sequenza nella
scansione iniziale del filesystem check.
Una volta verificato che nella installazione di cloud-init non ci siano file o
directory sotto /home (potrebbe restare la home dell’utente ausiliario di
installazione debian, che può essere rimosso con userdel -r debian) si
potrà montare il disco home con mount -a.

Configurazione iniziale per le quote
Sia che si sia usato un disco aggiuntivo per /home, sia che si siano
attivate successivamente le quote sulla radice (aggiungendo
grpquota,usrquota alla sua voce in /etc/fstab) è necessario
inizializzare le quote con:
quotacheck -a -f
quotacheck -ag -f

dove l’opzione - f è necessaria qualora (come avviene se si aggiungono le
opzioni di mount per le quote sulla radice) per forzare la scrittura dei file
delle quote a sistema attivo. Si possono ignorare gli avvertimenti che i dati
potrebbero essere imprecisi, verranno comunque corretti al primo riavvio.
Una volta attive le quote si potranno usare i comandi repquota e
repquota -g per verificare la effettiva presenza delle quote. Se detti
comandi non sono presenti si possono installare con apt install quotatool
(sono stati comunque inclusi nell’immagine di cloud-init).
Se non si riavvia la macchina dopo aver eseguito i comandi precedenti ed
attivato le quote nelle opzioni di montaggio, o se si aggiungono le opzioni
grpquota,usrquota in un secondo tempo rimontando il filesystem, e si forza
il calcolo delle quote a filesystem montato usando anche l’opzione -m con
i due comandi precedenti, occorrerà anche attivare le quote esplicitamente
con:
quotaon -a

Installazione di FUSS server tradizionale
Per installare FUSS Server su una macchina fisica, è necessario partire
da un’installazione di Debian Bookworm, su cui è basato il FUSS server.
Le immagini si possono ottenere dall’indirizzo
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
prendendo il file debian-<versione>-amd64-netinst.iso.
Per le installazioni nelle scuole di Bolzano quest’immagine andrà caricata sul
server proxmox precedentemente configurato,
proseguendo quindi con la creazione della macchina virtuale fino al boot
della stessa. Ma in questo caso è preferibile utilizzare la procedura
illustrata nel paragrafo precedente.
Per installare invece direttamente sul server è necessaria una
chiavetta USB della capacità minima di 1 GB sulla quale va copiata
l’immagine ISO scaricata. In GNU/Linux si può usare il comando dd.
Dopo aver inserito la chiavetta nel PC ove è disponibile l’immagine,
verificare con il comando lsscsi quale dispositivo è stato assegnato alla
chiavetta. Nell’esempio usiamo /dev/sdX dove X può essere una delle
lettere a, b, c ecc.  Come root, dare il comando:
# dd if=/PERCORSO_IMMAGINE/fuss-server-8.0-amd64-201708221233.iso \
  of=/dev/sdX bs=4M status=progress

Preparata la chiavetta USB, inserirla nel server e dopo averlo avviato
premurarsi di scegliere come dispositivo di boot la chiavetta stessa.

Installazione di Debian

Configurazioni iniziali
Se si è correttamente configurato l’avvio della macchina virtuale dalla ISO
del Netinstall si otterrà la seguente schermata iniziale:

si scelga una installazione testuale, verranno chieste nell’ordine la lingua:

e si scelga l’italiano; la posizione (per il fuso orario):

e si scelga Italia; la tastiera:

e si scelga quella italiana.
Per la rete si usi come interfaccia per l’installazione quella corrispondente
alla WAN del server (quella che si affaccia su Internet):

l’installer tenterà la configurazione automatica della rete, che deve essere
interrotta (si prema invio durante l’acquisizione per cancellarla, o si torni
indietro qualora sia avvenuta). In questo modo si potrà selezionare
esplicitamente una configurazione manuale per l’IP «esterno» del fuss-server:

e si effettuino le impostazioni standard della rete (indirizzo IP, netmask e
default gateway e DNS):

Verrà poi chiesto il nome della macchina, si inserisca subito quello
definitivo:

si prosegua poi impostando il dominio:

verranno poi chieste la password di root e l’utente iniziale, da impostare a
piacere.
Si dovrà poi effettuare il partizionamento dei dischi per l’installazione del
sistema.
La scelta più sicura, per evitare problemi di riempimento della radice,
è usare filesystem separati per /home, /var, /tmp. Questo
però con il partizionamento diretto rende meno flessibile la eventuale
riallocazione dello spazio disco.
Si tenga presente infatti che anche avendo disponibile spazio disco per
poter allargare le partizioni, l’allargamento avverrebbe sul «fondo»
pertanto sarebbe facile ridimensionare soltanto l’ultima partizione (nel
caso la /home, che pur essendo quella più probabile, non è detto sia
davvero quella che ha bisogno dello spazio disco aggiuntivo).
Per questo si suggerisce, per avere maggiore flessibilità, al costo di
una leggera perdita di prestazioni in I/O, di installare usando LVM,
selezionando «guidato - usa l’intero disco e imposta LVM»:

quindi selezionare il disco da partizionare:

l’uso dei filesystem separati:

e confermare la configurazione di LVM:

e l’uso di tutto lo spazio disponibile per il gruppo di volumi:

e poi la formattazione finale:

Una volta completato il partizionamento ed esaurita l’installazione del
sistema base verrà chiesto se aggiungere ulteriori CD o DVD, rispondere
di No:

quindi alla richiesta di configurare i repository dei pacchetti, si
utilizzi il mirror più vicino, non sarà necessario, essendo sulla WAN,
utilizzare un proxy.

Si risponda come si preferisce alla richiesta di partecipare o meno alla
indagine del popularity contest, e nella selezione del software si scelgano
soltanto le voci «server SSH» e «utilità di sistema standard»:

e si completi l’installazione con GRUB installato sul Master Boot Record del
disco:

Completata l’installazione si riavvi il server, eventualmente rimuovendo
il CD di installazione e ripristinando l’ordine di avvio al boot.

Configurazioni post-installazione
Completata l’installazione di Debian occorre finalizzare le configurazioni
iniziali della macchina prima di poter lanciare fuss-server create. Il
primo passo è configurare la seconda interfaccia di rete per la LAN, si dovrà
modificare /etc/network/interfaces per aggiungere la relativa
configurazione con qualcosa del tipo:
# lan
allow-hotplug enp2s0
iface enp2s0 inet static
      address 192.168.0.1
      netmask 255.255.255.0
      network 192.168.0.0

ed attivare l’interfaccia con ifup enp2s0.
Occorrerà poi configurare le sorgenti software per i pacchetti,
aggiungendo in /etc/apt/sources.list le righe per il repository di
backports e per quello di FUSS:
deb http://deb.debian.org/debian/ bookworm-backports main
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main

infine si dovrà importare la chiave GPG del repository di FUSS con:
# apt install gnupg
# wget -qO /usr/share/keyrings/fuss-keyring.gpg https://archive.fuss.bz.it/apt.gpg
# apt update

a questo punto si potrà installare il pacchetto del fuss-server:
# apt install fuss-server

Una volta completata la configurazione iniziale della macchina, si potrà
proseguire con la configurazione del fuss-server come già illustrato nella
sezione Configurazione del server.

Installazione tradizionale di FUSS Client
Si passa ora all’installazione del primo client.

Preparazione chiavetta USB
Come prima cosa è necessario scaricare l’ultima versione dell’immagine
ISO live Xfce di Debian 12 «bookworm» prendendo dall’indirizzo
https://cdimage.debian.org/mirror/cdimage/release/current-live/amd64/iso-hybrid/
il file debian-live-<versione>amd64-xfce.iso
È necessaria una chiavetta USB con taglia  minima di almeno 4 GB sulla
quale va copiata l’immagine ISO scaricata. Come detto anche sopra, in
GNU/Linux si può usare il comando dd. Dopo aver inserito la
chiavetta nel PC ove è disponibile l’immagine, verificare con il comando
lsscsi quale dispositivo è stato assegnato alla chiavetta.
Nell’esempio usiamo /dev/sdX dove X può essere una delle lettere
a, b, c ecc.
Nell’ipotesi che la ISO scaricata si per architettura amd64, come root,
dare il comando
dd if=/PERCORSO_IMMAGINE/debian-live-<versione>-amd64-xfce.iso of=/dev/sdX bs=4M status=progress

Preparata la chiavetta USB, inserirla nel PC/notebook e dopo averlo
avviato premurarsi di scegliere come dispositivo di boot la chiavetta
stessa.

Procedura di installazione guidata
Per immagini viene mostrata di seguito la procedura di installazione del
primo client. Si è scelto l’installer da console (Debian Installer). In
alternativa si può optare per l’installer grafico (Graphical Debian
Installer).

Nota
Se si vuole utilizzare FUSS in modalità LIVE, si scelga la
prima opzione. Le credenziali dell’utente di default sono user -
live.

Scelta di lingua e tastiera.

Inserire il nome del host.

Il dominio interno nel quale si colloca il host, come definito durante
l’installazione del server.

Impostazione della password di root.

Creazione di un utente locale.

Partizionamento dei dischi. Si scelga il partizionamento manuale
impostando una partizione di swap ed una per la radice (/ o root) del
filesystem.

Al termine scrivere le modifiche sul disco.

Inizia l’installazione del sistema.

L’installer cerca i pacchetti nel CD-ROM di installazione che non
esiste. Semplicemente ignorare l’errore e proseguire premendo
Continua.

Scegliere un mirror di rete.

Impostare il proxy a http://proxy:8080 dove proxy risponde al
FUSS Server.

Installare il boot loader GRUB nel master boot record del disco sul
quale si sta installando il sistema.

Al termine la macchina va riavviata.

Configurazione FUSS Client
Dopo il riavvio si acceda come root. La password preimpostata è fuss
e si consiglia di cambiarla con il comando passwd.
È necessario configurare i repository FUSS. Abilitare pertanto sia i
repository FUSS che bookworm-backports in /etc/apt/sources.list:
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main
deb http://httpredir.debian.org/debian bookworm-backports main

La sources.list dovrebbe pertanto risultare ad esempio:
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian bookworm main
deb-src http://deb.debian.org/debian bookworm main

deb http://deb.debian.org/debian bookworm-updates main
deb-src http://deb.debian.org/debian bookworm-updates main

deb http://security.debian.org/debian-security/ bookworm-security main
deb-src http://security.debian.org/debian-security/ bookworm-security main

# bookworm-backports
deb http://httpredir.debian.org/debian bookworm-backports main

deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main

Se invece si ha la necessità di scaricare anche i pacchetti non-free si
aggiungano a «main» anche «contrib», «non-free» e «non-free-firmware»:
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian bookworm main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware non-free

deb http://deb.debian.org/debian bookworm-updates main contrib non-free-firmware non-free
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free-firmware non-free

deb http://security.debian.org/debian-security/ bookworm-security main contrib non-free-firmware non-free
deb-src http://security.debian.org/debian-security/ bookworm-security main contrib non-free-firmware non-free

# bookworm-backports
deb http://httpredir.debian.org/debian bookworm-backports main contrib non-free-firmware non-free

deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg]  http://archive.fuss.bz.it/ bookworm main contrib non-free

Nota
Se si è dietro un FUSS server, perché sia possibile scaricare
la chiave di firma di APT, occorre prima definire export
http_proxy=http://proxy:8080  ed export
https_proxy=http://proxy:8080

Installare, se non già presente, il pacchetto wget:
apt update
apt install wget

Aggiungere la chiave di firma del repository archive.fuss.bz.it e
aggiornare con apt i pacchetti.
wget -qO - https://archive.fuss.bz.it/apt.key | gpg --dearmour > /usr/share/keyrings/fuss-keyring.gpg
apt update
apt dist-upgrade

All’occorrenza aggiungere i pacchetti Debian necessari a seconda del
contesto in cui viene installato il FUSS Client.

Creazione di un’immagine del client con Clonezilla
Al fine di velocizzare l’installazione del FUSS Client sui PC/notebook
rimanenti, si consiglia di creare con Clonezilla un’immagine del primo
FUSS Client. Il FUSS Server monta un’istanza di Clonezilla, eseguibile
da qualsiasi macchina presente nella LAN via PXE Boot (network boot).
Pertanto, riavviando il FUSS CLient appena creato e scegliendo l’opzione
di boot «PXE Boot», verrà caricato Clonezilla dal server e sarà
possibile creare un’immagine del primo client che verrà salvata nella
cartella /var/clonezilla sul server. Clonezilla chiederà la password
dell’utente clonezilla, che è memorizzata sul server nel file
/root/clonezilla_cred.txt.
Al termine della procedura di salvataggio del clone sul server, sarà
possibile installare agevolmente nuovi client lanciando parimenti
Clonezilla via network boot e scegliendo di fare il restore di
un’immagine.
Ad ogni client va attribuito un nome di host diverso. E` necessario
intervenire, pertanto, sui file /etc/hostname ed /etc/host
riavviando al termine il client.

Join del client al server
Infine va effettuato il join del client al server lanciando da terminale
il comando fuss-client come segue:
fuss-client -a

Come unica interazione viene chiesto, qualora configurato, a quale
cluster associare il host (es: aula-01, aula-insegnanti, ecc.).
Inoltre va inserita per tre volte la password di root del server.

Installazione con FUSS-FUCC
FUCC è l’acronimo di Fully Unattended Clonezilla Cloning

Compilazione della lista dei computer
Nella cartella /srv/clonezilla (normalmente cartella standard di
clonezilla) o su altra cartella sul server FUSS che contiene le immagini
da clonare, si trova il file computerList.txt in cui bisogna
elencare i nomi che si vogliono assegnare ai computer specificando
il mac-address e l’immagine di clonezilla che si vuole
installare sul computer.
Sono possibili le seguenti opzioni (e parametri, ove richiesti):
[ join CLUSTER [ wifi ] || standalone ] [ light ] [ locale LOCALE ] [ keyboard KBD ]

join Seguito dal parametro CLUSTER, permette di agganciare il computer al dominio e di includerlo nel gruppo CLUSTER.
wifi Consente di configurare i client per permettergli di contattare automaticamente il server attraverso la WLAN. I parametri wifi-ssid e wifi-pass vengono letti nel file /srv/clonezilla/clientScripts/wireless_conf, se esiste e i parametri non sono vuoti, altrimenti ci viene chiesto di inserirli interattivamente. Esempio di file wireless_conf:
wifissid: FUSS_LAN
wifipass: MYSUPERSECRETPASSWORD

standalone Alternativo a join, permette di installare la macchina standalone.
light Nel caso si parta da un’immagine clonezilla light  permette di installare la macchina (joinata o standalone) senza i pacchetti fuss-kids, fuss-children e fuss-education.
locale Seguito dal parametro LOCALE, permette di modificare la lingua di sistema (default it_IT.UTF-8). L’elenco dei possibili locale si può trovare nel file /srv/clonezilla/clientScripts/locale.txt
keyboard Seguito dal parametro KBD, permette di modificare il layout della tastiera (default it). L’elenco dei possibili layout si può trovare nel file /srv/clonezilla/clientScripts/keyboard_layout.txt

Esempi:
dm-info1-03 00:0b:fe:d7:4a:cc cloneImage-img join aula_info1
arc-aula37 7a:2d:b4:59:d6:f3 cloneImage-img join piano-primo locale de_IT.UTF-8 keyboard de
aula-04 6c:4b:90:26:4d:72 cloneImage-img standalone light locale es_ES.UTF-8 keyboard es
lab-102 3c:7b:30:46:1e:8a cloneImage-img join piano-terzo wifi keyboard us locale en_GB.UTF-8 light

Nota
Si noti che l’ordine non ha importanza, purchè si rispettino la sintassi e la corrispondenza tra opzione e parametro.

La creazione del file /srv/clonezilla/computerList.txt può essere
effettuata anche automaticamente lanciando lo script:
fuss-fucc octolist NOME-IMMAGINE-CLONEZILLA

Viene creato il file computerList.txt.octo-new che può essere
copiato al posto di /srv/clonezilla/computerList.txt. Verificare che
la lista contenga tutti i pc che si intende aggiornare.
In questo modo, se si reinstalla in modalità automatica, ai client
vengono assegnati gli stessi hostname e cluster di prima.

Nota
Le opzioni standalone, light, locale, keyboard, wifi dovranno
eventualmente essere aggiunte a mano.

Installazione del client
Una volta eseguito quanto sopra indicato si avviino in network
boot(PXE) i PC da installare (in genere si preme il tasto F12 ma
potrebbe variare a seconda del computer).
Il menu presenta due possibili scelte, automatica o manuale ,
come indicato nello screenshot seguente. La modalità automatica è il
default ma richiede ovviamente che il file computerList.txt sia
compilato correttamente.
In modalità automatica non occorre praticamente fare nulla, l’immagine
viene copiata, il client viene rinominato e joinato o meno alla rete ed
eseguite le altre opzioni come indicato in computerList.txt. Nel caso la
computerList contenga errori o incongruenze ci verranno poste delle
domande in modo interattivo.

clonezilla boot

Sempre in modalità automatica, se il mac-address non compare
nella computerList ci verrà chiesto di inserire le varie opzioni interattivamente
anche attraverso finestre di scelta che possono semplificare parecchio il lavoro.
In caso qualcosa non vada a buon fine, si può optare per
l’installazione manuale. In tal caso il client carica clonezilla, ma per
il resto si installa il client quasi come se si usasse una chiavetta, la
partizione contenente le immagini viene montata previa autenticazione
con password (si scelga skip al momento di scegliere la sorgente).
Clonata l’immagine bisognerà lanciare:
fuss-client -H <hostname>

per rinominare il client ed agganciarlo al server.

Configurazione del cambio automatico della password di root
FUCC è in grado di modificare automaticamente la password di root dei
client clonati con una criptata che gli viene passata. Per
configurare il cambio password eseguire sul server lo script:
fuss-fucc rootpw

ed inserire due volte la password di root da dare ai client. Di norma
questo script dev’essere ovviamente eseguito prima di iniziare a
clonare le macchine.

Accesso all’interfaccia di amministrazione OctoNet
Aprendo il browser da un qualsiasi PC/notebook della LAN all’indirizzo
http://proxy:13402, è possibile accedere all’interfaccia OctoNet di
configurazione della rete didattica e da questa, tra le altre funzioni, si
possono creare le utenze della rete didattica. L’amministratore è l’utente
root e la password è la Master Password impostata durante l’esecuzione di
fuss-server.
Questa modalità però comporta che tutto il traffico passi in chiaro, pertanto
è fortemente sconsigliata, si utilizzi un tunnel SSH come illustrato nel
paragrafo dedicato all’uso di OctoNet, che non espone al rischio di
intercettazione delle credenziali di accesso.

Rete WiFi WPA-Enterprise
La configurazione della rete WiFi deve essere effettuata una volta che
si sia correttamente installato il Fuss Server (secondo le istruzioni
di Installazione di FUSS server tradizionale). In particolare si suppone che
siano già correttamente configurate le interfacce di rete per la rete
interna (quella rivolta verso le macchine dell’aula) ed esterna (quella
da cui si accede ad internet).
Per poter utilizzare il WiFi è necessario disporre di una
terza interfaccia di rete sulla quale sia già assegnato un IP statico da
destinare al server.
Questa interfaccia sarà quella che dovrà essere collegata fisicamente al
tratto di rete (fisicamente separato dalla rete interna
del server) al quale afferiranno gli Access Point (ad esempio vi si
potrà attaccare un access point senza autenticazione). Negli esempi
successivi assumeremo che si tratti di ens20.
Per installare il necessario a gestire la rete Wi-Fi con la nuova
infrastruttura occorre eseguire il comando:
fuss-server cp

che provvederà a richiedere, qualora non siano già definiti, i dati
necessari alla configurazione. Come per gli altri questi vengono
mantenuti nel file /etc/fuss-server/fuss-server.yaml In particolare
saranno richiesti:

interfaccia di rete su cui attestare la rete WiFi (nell”
esempio ens20)
indicazione della rete IP e relativa maschera (ad esempio
10.10.0.0/22)

Un esempio di sessione di installazione è il seguente:
root@fuss-server-iso:~# fuss-server cp
################################################################################
Please insert Hot Spot Interface

The Hotspot interface of the server, ex. 'eth3'
Your choice? ens20
################################################################################
Please insert Hot Spot Network (CIDR)

The Hotspot network of the server, ex. '10.1.0.0/24'
Your choice? 10.10.0.0/22
...

Il server FUSS, una volta ultimata la configurazione, esporrà la porta
1812 per l’autenticazione RADIUS da parte del controller / degli
access point e permetterà (ma registrerà) il traffico verso la WAN.
Solo le porte 80 e 443 sono permesse.

Avvertimento
Se si sta aggiornando un’infrastruttura esistente, si tenga presente
che, una volta operativo, il traffico verso internet sarà sempre
consentito. Valutare pertanto di scollegare gli Access Point
o impostare preventivamente una password alla rete WiFi per
evitare accessi imprevisti prima che WPA Enterprise sia operativo.

Nota
l’installazione della rete WiFi crea il gruppo wifi (si
vedano a tal proposito i due file /etc/group ed
/etc/octofuss/octofuss.conf). Di default gli utenti di una rete
scolastica non appartengono al gruppo wifi e pertanto non hanno
l’autorizzazione per accedere al captive portal; devono essere
esplicitamente autorizzati in OctoNet.

Abilitazione di un IP ad eseguire query verso FreeRadius
La policy di default configurata da FUSS Server prevede di rigettare
tutte le query che pervengono a FreeRadius.
Si rende pertanto necessario inserire il controller ed altri eventuali
dispositivi che dovranno contattare FreeRadius nel file
/etc/freeradius/3.0/clients.conf:
# FUSS ARUBA AP
client 10.1.1.250/32 {
     secret = testing123
     nas_type = other
}
...

Sostituire il parametro secret, qui valorizzato con testing123,
con un’opportuna password generata randomicamente.

Autenticazione via RADIUS su controller Aruba
Come prima cosa è necessario collegarsi via browser all’interfaccia
web di management del controller ed eseguire l’accesso.
Selezionare quindi «Configurazione» > «Reti».
I parametri da modificare sono i medesimi sia se si crea una nuova
rete sia se se ne modifica una esistente.
Una volta aperta la procedura di creazione/modifica della rete WiFi,
selezionare «Mostra opzioni avanzate» in basso a sinistra.
Giungere allo step 3 (Sicurezza).
Una volta selezionato «Enterprise» come «Livello di sicurezza» e
«WPA2-Enterprise» come «Gestione chiavi», la voce
«Server di autentic. 1» diventa configurabile.
Crearne uno nuovo (o selezionare quello già creato se più reti WiFi
sono presenti) come in figura.

La configurazione della rete risulterà quindi come di seguito:

È possibile salvare la configurazione della rete e constatare
che questa funzioni correttamente in modalità WPA2-Enterprise.

Postazioni prive di collegamento cablato alla LAN FUSS
In un’ottica di costante miglioramento dal punto di vista tecnologico e
dell’esperienza utente, a partire dal FUSS Server 12 la rete WiFi non
viene più gestita tramite Captive Portal. Il server espone la porta del
servizio FreeRadius e demanda agli AccessPoint, attraverso il protocollo
WPA Enterprise, l’autenticazione degli utenti.
Questo aggiornamento complica ulteriormente la gestione ibrida fatta fino
ad ora dei portatili condivisi e collegati tramite WiFi, utilizzati
con l’utenza Guest. Da questo il cambio di paradigma nella gestione dei
portatili discussa nel presente documento.

Nota
Apparato condiviso: dispositivo utilizzato esclusivamente nella
sede scolastica, condiviso da più utenti e senza una connessione
cablata alla LAN.
Ad esempio: PC portatile utilizzato come PC d’aula.

Schema di funzionamento
Attraverso il multi-SSID e l’utilizzo delle VLAN, gli apparati
condivisi privi di connessione cablata vengono equiparati a
quelli che invece ne sono dotati. La LAN viene trasportata
sull’infrastruttura WiFi e consegnata sull’apparato condiviso.
Divenendo, di fatto, come qualsiasi altro PC presente nella
rete, una volta configurato il suo funzionamento al di fuori
della portata della rete WiFi sarà impossibile.
L’esperienza utente sarà del tutto equiparata ai PC fissi,
permettendo di accedere ai file memorizzati nella home,
le cartelle condivise, ecc.

Interconnessione della LAN all’infrastruttura WiFi
Si rende necessario far sì che gli AccessPoint dispongano di
un collegamento verso la rete LAN perché venga trasmessa
attraverso un SSID dedicato. La soluzione più rapida è quella
di trasportare la LAN sulla rete del WiFi attraverso una VLAN.
Di seguito sono descritti i due possibili approcci alla
creazione di una seconda VLAN su rete WiFi.

Cross-connection degli switch

Consiste nel realizzare l’interconnessione con una patch direttamente
tra lo switch LAN e quello WiFi. Richiede che lo switch lato rete WiFi
sia di tipo managed. In questo caso è sufficiente configurare la porta
di prelievo della LAN sullo switch WiFi come “port to VLAN” ovvero
prelievo in untagged e trasporto tagged.
In alternativa, qualora fosse supportato, è possibile usare il
re-mapping della VLAN 1 verso una tagged sulla porta di consegna verso il WiFi.
Pro:

da un punto di vista della topologia di rete, il WiFi è in cascata come qualsiasi altro switch;
evita traffico inutile attraverso le schede di rete e la CPU del server.

Contro:

un reset imprevisto dello switch o lo spostamento della patch su porte diverse
rispetto a quelle configurate causerebbe un collasso delle due reti.

Consegna del bridge su interfacce multiple lato PVE
Consiste nel riconfigurare il virtual bridge dedicato alla LAN per consegnare
su più di una porta, più specificamente sia sulla scheda di rete dedicata
alla LAN sia su una VLAN sulla scheda di rete del WiFi.
Pro:

realizzabile anche con soli switch unmanaged;
resiliente ad eventuali modifiche fisiche.

Contro:

il traffico broadcast e inter-client (LAN trasportata su WiFi verso LAN fisica)
deve attraversare entrambe le schede di rete del server e la CPU.

Esempio di configurazione
Si prenda come esempio la seguente configurazione iniziale:

In questo esempio i bridge sono configurati come di seguito:

vmbr0, dedicato alla WAN, ha come interfaccia genitore eth0;
vmbr1, dedicato alla LAN, ha come interfaccia genitore eth1;
vmbr3, dedicato al WiFi, ha come interfaccia genitore ens5f1.

Sarà sufficiente modificare la configurazione del vmbr1 aggiungendo la
stessa interfaccia del WiFi e la VLAN di consegna separate da un punto.

Configurazione degli AP Aruba
Collegarsi al controller Aruba Instant On quindi, dal menu laterale,
scegliere “Configurazione” → “Reti”. Premere sul pulsante di aggiunta “+”.
Al primo passo, inserire il nome della rete e lasciare le altre
impostazioni come predefinite.

Al secondo passo, selezionare “Statica” come “Assegnazione VLAN client”
ed inserire l’ID VLAN scelto in precedenza.

Al terzo passo, impostare la passphrase per l’accesso tramite “WPA2-Personal”.

Terminare l’ultimo passo confermando le impostazioni predefinite.
Per evitare confusione da parte degli utenti, è possibile modificare la rete appena creata,
selezionare “Mostra opzioni avanzate in basso a sinistra” e, sotto “Varie”,
selezionare “Nascondi” per SSID per rendere la rete nascosta.

Provisioning degli apparati condivisi
È consigliabile eseguire la prima configurazione del client utilizzando la rete cablata.
Può essere eseguito il provisioning classico utilizzando FUSS FUCC.
Una volta effettuato il join del client alla rete sarà sufficiente eseguire
fuss-client passando come argomenti l’SSID della rete WiFi estensione della LAN e la password.
Verrà automaticamente riattivato Network Manager ed impostata la connessione alla rete all’avvio.:
fuss-client -U --wifi-ssid 'FUSS_LAN' --wifi-pass 'PASSWORD'

Fatto questo la connessione cablata non sarà più richiesta all’avvio ed
il client contatterà automaticamente il server attraverso la WLAN.
Prima di riavviare il client, verificare che il wifi non sia disabilitato:
nmcli radio wifi

Qualora risulti disabled, attivarlo con:
nmcli radio wifi on

Architettura

Servizi presenti su Fuss Server

Servizi

Servizio
Descrizione

apache
Server web

bind
DNS locale

e2guardian
Filtro sui contenuti internet (se non disabilitato)

isc-dhcp-server
DHCP per la rete locale

iptables
Firewall

fuss-fucc
Gestione dell’installazione automatizzata dei client

fuss-manager
Gestore delle macchine su reti locali (nuova versione
sperimentale)

kerberos
Autenticazione e autorizzazione

ldap
Autenticazione

nfs-kernel-server
Home condivise

Octonet
Gestione di macchine ed utenti (legacy)

Samba
Condivisione file

squid
Proxy web

Gestione dei FUSS server

Configurazione del server
Una volta completata l’installazione di base della macchina si deve avere cura
di configurare correttamente la rete, identificando le interfacce di rete
interna (quella rivolta verso le macchine dell’aula) ed esterna (quella da cui
si accede ad internet). Si deve anche impostare l’hostname ed il nome e
dominio della macchina su cui si lavora.

Avvertimento
Impostare l’hostname della macchina al suo valore finale prima di eseguire
procedura di configurazione è importante, cambiare l’impostazione in
seguito è problematico. In genere lo si fa in fase di installazione del
sistema operativo, ma qualora questo non fosse quello voluto la correzione
deve essere applicata prima di lanciare il comando
fuss-server. L’hostname della macchina infatti viene usato nel playbook
di configurazione per la creazione di vari file che poi vengono
referenziati, cambiarlo successivamente può non avere impatto immediato nel
funzionamento del server, ma può averlo nella successiva esecuzione (ad
esempio per aggiornamento) di fuss-server.

Per eseguire la creazione della configurazione è necessario eseguire il
comando:
# fuss-server create

questo, se non è già stata eseguita in precedenza una configurazione,
chiederà una serie di dati. In particolari saranno richiesti:

la rete locale che verrà utilizzata (es. 192.168.1.0/24);
il nome a dominio della rete (es. scuola.bzn);
il workgroup per il dominio windows (es. SCUOLA);
un intervallo di indirizzi per il DHCP (es. 192.168.1.10 192.168.1.100);
la master password del server (usarne una lunga e complicata!);
la località (es. Bolzano);
l’interfaccia della rete esterna (es. ens18);
l’interfaccia della rete interna (es. ens19);

Il programma per la richiesta dei dati userà l’interfaccia testuale nel
terminale.
Alla fine dell’inserimento verrà eseguito un controllo di correttezza
dei dati inseriti; in caso di problemi verrà riaperta una nuova finestra
di immissione con i soli dati problematici, fino a quando non si ottiene
una configurazione completamente valida.
Infine il programma procederà automaticamente alla configurazione di
tutto quanto necessario, compresa l’eventuale installazione di
dipendenze.
Qualora non si voglia che questo avvenga, ad esempio perché si vogliono
modificare da subito i parametri di default con cui avviene l’installazione,
si può eseguire al posto di fuss-server create il comando fuss-server
configure che esegue solo la richiesta delle precedenti informazioni e
genera il corrispondente file di configurazione
/etc/fuss-server/fuss-server.yaml; è in questo file che poi dovranno
essere ridefinite (rispetto ai valori contenuti in
/etc/fuss-server/fuss-server-default.yaml) le variabili di controllo che
si vogliono modificare. Una volta fatte le modifiche si potrà passare alla
configurazione lanciando allora fuss-server create.
Nel caso in cui il programma si interrompesse a causa di problemi
temporanei (ad esempio una caduta della connessione ad internet) è
possibile rilanciarlo con: fuss-server create; ovviamente non verrà
richiesta la configurazione, ma il programma procederà automaticamente
con la sua fase automatica.

Accesso al server
L’accesso al server è consentito, oltre che dalla console, via SSH,
anche per l’utente root, con autenticazione a chiavi. Le chiavi devono
essere installate nel file /root/.ssh/authorized_keys.
Gli utenti normali possono accedere al server in SSH con username e
password con un loro utente solo se fanno parte del gruppo
sshaccess. Il gruppo viene creato come gruppo locale sul server
all’esecuzione di fuss-server ed SSH è configurato per l’accesso in
/etc/ssh/sshd_config con la riga:
AllowGroups root sshaccess

che consente l’accesso a root ed ai membri del gruppo.
Questa impostazione viene effettuata dal comando fuss-server con
usando una direttiva blockinfile di ansible, le eventuali modifiche
effettuate all’interno del blocco verranno sovrascritte ad una
successiva invocazione del comando. L’uso della direttiva
AllowGroups è incompatibile con l’uso di AllowUsers che pertanto
non deve essere usata.
Per fornire l’accesso SSH agli utenti sarà sufficiente aggiungerli al
gruppo locale sshaccess con il comando: adduser utente
sshaccess.

Nota
se l’utente localadmin non riesce a entrare in SSH sul server
controllate che appartenga al gruppo sshaccess

I principali file di configurazione
Sotto /etc/fuss-server sono installati una serie di file che mantengono
dati di configurazione usati dai servizi del server, dettagliati nei
paragrafi seguenti, gestiti tramite octofuss. Ovviamente non devono
essere cancellati, pena il malfunzionamento dei servizi cui fanno
riferimento.

File di configurazione del Fuss Server
Nel file /etc/fuss-server/fuss-server.yaml si trova la
configurazione generale del Fuss Server. Il formato è un file di
variabili di ansible
ovvero un semplice dizionario chiave - valore in yaml, ad esempio:
chiave: valore
altra_chiave: nuovo valore

Deve contenere i valori predefiniti descritti in
Configurazione del server; contrariamente agli altri file può
essere cancellato, e in quel caso viene ricreato a partire da un esempio
vuoto.
Per modificare le impostazioni in tale file, si può anche lanciare:
# fuss-server configure -r

(l’opzione -r è necessaria, perché se le impostazioni sono presenti il
programma non le richiede).
Per applicare le modifiche lanciare:
# fuss-server upgrade

che farà la verifica di coerenza dei valori presenti nel file e li
applicherà al sistema.
Dato che il file può venire riscritto dal comando fuss-server, è
opportuno non usarlo per configurazioni aggiuntive, per le quali è
invece presente il file descritto nella sezione successiva.

File dei default del Fuss Server
Sotto /etc/fuss-server/ viene installato anche secondo file,
fuss-server-defaults.yaml, sempre in formato yaml, nel quale si
possono impostare altre variabili per personalizzare l’installazione.
Questo file può essere vuoto (la versione di default installata dal
pacchetto contiene solo commenti), ma non deve essere cancellato,
altrimenti fuss-server darà errore non trovandolo.
La tabella seguente descrive le variabili che possono essere definite in
questo file per controllare alcune caratteristiche assunte
dall’installazione.

Variabile
Significato
Contenuto
Default

dans_maxchild
Numero massimo di processi figli di e2guardian.
Intero
600

proxy_win_exclude
Configura Squid per escludere i client Windows.
Booleano
yes

dans_exclude_localnet
Esclude la rete locale dal filtraggio di e2guardian.
Booleano
yes

dhcp_default_lease_time
Durata di default di una lease dhcp.
Intero
86400

dhcp_max_lease_time
Durata massima di una lease dhcp.
Intero
172800

squid_filedescriptors
Massimo numero di filedescriptor per squid
Intero
10240

e2guardian_install
Se installare o meno e2guardian
Booleano
yes

e2_nofile
Limite di file aperti per e2guardian
Intero
8192

e2_workers
Limite di httpworker per e2guardian
Intero
1024

samba_logon_path
Valore di logon path di samba
Stringa
(vuoto)

samba_logon_home
Valore di logon home di samba
Stringa
(vuoto)

samba_logon_drive
Valore di logon drive di samba
Stringa
(vuoto)

samba_logon_script
Valore di logon script di samba
Stringa
(vuoto)

squid_require_internet_group
Se appartenere al gruppo internet è richiesto per navigare
Booleano
yes

É possibile modificare questi valori di default, in modo che la relativa
configurazione non venga cambiata in caso di aggiornamento del fuss-server, ad
esempio se si vuole riabilitare l’accesso ad internet da parte di macchine
Windows si può cambiare il valore di proxy_win_exclude da yes a
no, o se si vuole riabilitare il filtro dei contenuti sulla rete locale
(non necessario nelle scuole del progetto per la presenza di un filtraggio a
monte) si può modificare dans_exclude_localnet da yes a no.
Tutte le volte che si effettua una modifica di una di queste variabili, perché
la relativa configurazione venga applicata, occorrerà eseguire fuss-server
upgrade. Dato che fuss-server-defaults.yaml è marcato come file di
configurazione, non verrà sovrascritto in caso di aggiornamento del
pacchetto e le modifiche fatte verranno mantenute.

Server DHCP
Il file /etc/dhcp/dhcp-reservations contiene le assegnazioni
statiche degli indirizzi per il client , che viene incluso nella
configurazione ed installato vuoto in fase di creazione del fuss-server.
Il contenuto di questo file viene gestito tramite octofuss ed usa il
formato previsto da dhcp.conf per le «_reservation_», vale a dire una
serie di voci nella forma:
host nomeclient {
        hardware ethernet 00:XX:XX:XX:XX:XX;
        fixed-address nomeclient.dominio.it;
}

se nomeclient.dominio.it è definito nel DNS, oppure:
host nomeclient {
        hardware ethernet 00:XX:XX:XX:XX:XX;
        fixed-address IP.AD.DR.ES;
}

usando un IP fuori dal range del DHCP (che di default prende gli
indirizzi fra 1/4 e 3/4 della rete usata per la LAN). Se il file
/etc/dhcp/dhcp-reservations viene eliminato, il servizio non
viene avviato.

Firewall
I file di configurazione per il firewall sono tutti nel formato:
valore:descrizione

con l’eccezione di quello che descrive macchine interne consentite e
servizi esterni raggiungibili, che è nella forma:
host:servizio:descrizione

Le righe che iniziano con un # sono considerate commenti e vengono
ignorate, inoltre quanto non compare all’interno del blocco marcato
ANSIBLE MANAGED BLOCK non viene sovrascritto dalla riesecuzione del
comando di installazione del fuss-server.
Se si specifica un host questo deve essere o un nome a dominio o un
indirizzo IP, si tenga conto però del fatto che il firewall effettua la
risoluzione dell’indirizzo IP al suo avvio, pertanto usare un nome a
dominio è rischioso, specie quando ad esso possono corrispondere a
diversi indirizzi (ad esempio www.google.com) perché il firewall farà
riferimento soltanto a quello risolto in fase di avvio.
Quando si specifica un servizio invece questo deve essere nella forma
porta/protocollo (ad esempio 123/udp o 2628/tcp). Si raccomanda di usare
le minuscole ed i valori numerici.
La descrizione può essere omessa, verrà comunque inserita una
descrizione standard.
I file utilizzati sono i seguenti; vengono abilitati su firewall nella
sequenza in cui sono indicati nella tabella (questo significa che un
host nel primo file non potrà raggiungere comunque nessun servizio
esterno, neanche quelli resi accessibili con gli altri file):

File
Contenuto
Formato

/etc/fuss-server/firewall-denied-lan-hosts
Host che non possono raggiungere alcun servizio sulla rete
internet
IP-address

/etc/fuss-server/firewall-allowed-lan-hosts
Elenco di host che possono accedere ai servizi della rete internet
senza alcun filtro e/o limitazione
IP-address

/etc/fuss-server/firewall-allowed-wan-hosts
Elenco di host sulla rete internet che possono essere acceduti senza
alcun filtro e/o limitazione
IP-address

/etc/fuss-server/firewall-allowed-wan-services
Servizi sulla rete internet che possono essere raggiunti senza
limitazioni e/o controllo. Devono essere indicate le porte da
utilizzare per il servizio
porta/protocollo

/etc/fuss-server/firewall-external-services
Servizi offerti dal server sulla rete esterna
porta/protocollo

/etc/fuss-server/firewall-allowed-wan-host-services
Servizi sulla rete internet raggiungibili da specifici host della
rete interna senza alcun limite.
IP-address:porta/protocollo

/etc/fuss-server/firewall-custom-rules
Regole iptables custom.
iptables <options>

Si ricordi che dopo aver eseguito modifiche manuali sui suddetti file
occorre rilanciare il firewall perché esse diventino effettive, con:
/etc/init.d/firewall restart

Nel caso si sia installato anche il Captive Portal il firewall usa
l’ulteriore file /etc/fuss-server/fuss-captive-portal.conf, per ottenere
la rete usata dallo stesso e abilitare gli accessi necessari. Detto file
non deve essere cancellato, pena la mancanza dei suddetti accessi ed il
conseguente non funzionamento del Captive Portal in caso di riavvio del
firewall.

squid (web proxy)
Il file /etc/squid3/squid-added-repo.conf permette di aggiungere
siti web all’acl repositories ai quali l’accesso è sempre permesso
senza autenticazione.
I contenuti devono essere della forma:
acl repositories url_regex XXX

dove XXX è l’espressione regolare che rappresenta il sito che
vogliamo abilitare; esempi di sintassi sono presenti in squid.conf,
come:
acl repositories url_regex ^http://.*.debian.org/

e2guardian (filtro contenuti)
Nel file /etc/fuss-server/content-filter-allowed-sites viene mantenuta una
lista dei siti cui viene comunque garantito accesso da e2guardian (successore
di Dansguardian). Questa lista può essere gestita anche dall’interfaccia web
di OctoNet dal menu Filtro web, che consente anche di configurare altri
file di configurazione sotto /etc/e2guardian/lists/.

Attenzione
il filtro contenuti richiede risorse significative sul server; nelle
scuole in cui è già presente una protezione a monte può convenire
escludere gli IP della rete locale dal filtraggio aggiungendo a tali
file i range dei PC da escludere o i singoli IP se tali PC hanno IP
statico.

dhcpd
Il file /etc/dhcp/dhcpd-added.conf permette di aggiungere parametri
di configurazione del demone dhcp oltre a quanto gestito dal
fuss-server.
Tale file viene caricato alla fine di /etc/dhcp/dhcpd.conf, e ne
condivide la sintassi.

bind (DNS)
Il file /etc/bind/named.added.conf.local permette di aggiungere
parametri di configurazione di bind oltre a quanto gestito dal
fuss-server.
Tale file viene caricato alla fine di /etc/bind/named.conf.local, e ne
condivide la sintassi.

Aggiornamenti
Dalla versione 8.0 il funzionamento di fuss-server create è stato
cambiato ed è ora possibile lanciare più volte fuss-server create: le
modifiche già applicate rimangono costanti.

Aggiornamenti di sistema
Gli aggiornamenti di sistema possono essere eseguiti manualmente con la
modalità ordinaria di Debian, vale a dire collegandosi al server come root ed
eseguendo i comandi:
# apt update
# apt upgrade

rispondendo positivamente alla richiesta di installazione dei pacchetti
aggiornati.

Aggiornamenti minori di fuss-server
Nel caso ci siano degli aggiornamenti di minor version (10.0.x →
10.0.(x+1)) di fuss-server per applicarli è sufficiente, da root:

scaricare ed installare il pacchetto aggiornato:
# apt update
# apt install fuss-server

riapplicare le nuove configurazioni:
# fuss-server upgrade

Aggiornamenti dei file di configurazione
fuss-server upgrade ripristina i contenuti di molti file di
configurazione ai valori desiderati per il fuss-server.
Per alcuni servizi per i quali è più comune dover mantenere delle
modifiche locali sono presenti dei file apposta, inclusi dal file
generale e non toccati da fuss-server, ma questo non è vero in ogni
caso.
Tuttavia, quando un file di configurazione viene modificato ne viene
salvata una copia di backup nel formato <nome del file>.<un
numero>.YYYY-MM-DD@HH:MM:SS~; da questo file si possono recuperare
eventuali personalizzazioni da ripristinare.
Per trovare i file modificati subito dopo il lancio di fuss-server si
può usare il comando:
# find /etc -mmin -10

che trova tutti i file modificati negli ultimi 10 minuti.
Per trovare tutti i file di backup generati da fuss-server update
nel 2020 si può invece usare:
# find /etc/ -name "*.*.2020-*@*~"

o, per essere più precisi e trovare ad esempio le modifiche di giugno
2020:
# find /etc/ -name "*.*.2020-06*@*~"

Avvertimento
Copiare semplicemente il vecchio file di configurazione su quello
nuovo è una pratica sconsigliata: generalmente gli aggiornamenti
introducono modifiche di tali file al fine di migliorare il
funzionamento del fuss-server o risolvere bug, e annullare tali
modifiche annulla tale vantaggio.
Piuttosto è opportuno verificare le modifiche tra le due versioni del
file, ad esempio con:
# diff <nome file> <nome file backup>

e riapplicare solo quanto effettivamente necessario per
l’installazione locale.

Backup con fuss-backup
Il pacchetto fuss-backup installa un nuovo programma di backup basato su
borg che fornisce al contempo anche le
funzionalità di dump dei database (LDAP, eventuali MySQL e Postgres)
installati sul server. Per questi ultimi viene creato un dump sotto
/var/backups (rispettivamente nelle sottodirectory slapd, mysql,
pgsql) in cui vengono mantenute gli ultimi sette dump testuali per un
accesso immediato. La directory /var/backups è inserita di default nel
backup su disco esterno o NAS.

Pianificazione del backup
Per la pianificazione del backup viene installato dal pacchetto il file di
CRON /etc/cron.d/fuss-backup in cui è programmata l’esecuzione dello
script di backup ogni lunedì alle 13:15. Il backup può essere eseguito
manualmente (invocando il comando fuss-backup) in qualunque momento.
Il dispositivo esterno viene montato prima dell’esecuzione del backup e
smontato al suo completamento. Questo consente, in caso di dischi esterni, una
rimozione ed eventuale rotazione.

Configurazione
Per il funzionamento del backup è richiesta la presenza di una configurazione
valida in /etc/fuss-backup/fuss-backup.conf. In particolare deve essere
impostata la variabile START=yes e indicato nella variabile DISK il
dispositivo su cui viene eseguito lo stesso (maggiori dettagli in seguito).

Avvertimento
l’installazione del pacchetto installa un file di configurazione
che blocca l’esecuzione del backup (START=no e DISK
vuota), occorre pertanto effettuare la configurazione manualmente
in quanto non è noto a priori il nome del dispositivo esterno su
cui si fanno i backup.

Variabili di configurazione
La tabella seguente riporta le variabili presenti nel file di configurazione
ed il relativo significato. Nel file sono state commentate con ulteriori
dettagli.

Variabile
Significato
Default

START
se diversa da yes il backup non viene eseguito
no

DISK
il dispositivo su cui viene effettuato il backup
vuoto

PATHS
le directory di cui viene eseguito il backup (stringa separata da
spazi)
/etc /home /var/backups /var/lib /var/log
/var/mail /var/local

MAILTO
indirizzi cui inviare l’email dei risultati
root

RETENTION
numero minimo di backup (1 per giorno) da tenere in archivio (uso
interno)
7

BASEDIR
directory dove montare il dispositivo di archiviazione
/mnt/backup

BACKUP_DIR
sotto-directory della precedente dove creare l’archivio
borgdata

RECOVERDIR
directory dove montare i backup per il recupero
/mnt/recover

Esempio di configurazione
Per configurare ed attivare il backup modificando
/etc/fuss-backup/fuss-backup.conf sono pertanto sono indispensabili i
seguenti passi:

definire START=yes
definire un valore opportuno per DISK, se ad esempio si dispone di un
disco esterno se ne dovrà indicare il nome di dispositivo, ad esempio:
DISK=/dev/sdc1

se si dispone di un NAS occorrerà indicare l’indirizzo IP a cui è
raggiungibile e la directory che questo esporta in NFS con la sintassi
IP.DEL.NAS.LOCALE:/directory/esportata/dalnas, ad esempio nel caso del
NAS-QNAPTVS653 usato per le prove si avrà:
DISK="192.168.10.5:/share/CACHEDEV1_DATA/Public"

Per trovare la directory esportata sul NAS-QNAPTVS653 ci si può collegare allo
stesso con SSH ed esaminare il contenuto del file /etc/exports, il cui
contenuto riflette le directory definite nella sezione «Shared folders» del
pannello di controllo accessibile via WEB (nel caso illustrato quella
disponibile era Public).
Il formato del file /etc/exports prevede una directory esportata per
riga (se ne dovrà scegliere una qualora ne esistano diverse), con campi
separati da spazi; il primo campo è la directory da usare nella
variabile DISK (nel caso in esempio appunto
/share/CACHEDEV1_DATA/Public).
Come ulteriore configurazione si possono elencare le directory del server di
cui si vuole il backup modificando la variabile PATHS, da specificare nella
forma di un elenco separato da spazi, ad esempio:
PATHS="/etc /home /var/backups /var/lib /var/log /var/mail /var/local /opt/altridati"

È opportuno anche configurare un indirizzo di posta cui verranno inviate le
email con le notifiche del backup, sia predisponendo un opportuno alias per
l’utente root che indicando una lista di destinatari (sempre separata da
spazi) nella variabile MAILTO, ad esempio:
MAILTO="root localsysadmin@fuss.bz.it"

Infine qualora si voglia mantenere uno storico più consistente si può
aumentare il valore della variabile RETENTION che indica il numero minimo
di backup mantenuti (nel numero massimo di uno a giorno, nel caso in cui in
uno stesso giorno vengano eseguiti più backup verrà mantenuto solo il più
recente). Si tenga presente che borg supporta la deduplicazione, e che non
esiste il concetto di backup incrementale, ogni backup è sempre completo.

Esclusione
I file che corrispondono al file di esclusione fuss-backup.exclude
(installato di default per escludere MPT, AVI e immagini ISO) non vengono
inclusi nel backup. Se il file è assente il backup viene eseguito senza
escludere nulla.
Nella forma più elementare il formato del file di esclusione prevede un
pattern di shell (ex. *.iso) per riga, i file il cui pathname corrisponde
al pattern vengono esclusi. Per maggiori dettagli (ed esempi di pattern più
complessi con uso di espressioni regolari) si rimanda alla documentazione
ottenibile con il comando borg help patterns.
Il default installato dal pacchetto prevede che vengano esclusi dai backup
alcune tipi di file (identificati per estensione, in particolare *.iso,
*.mp3 e *.avi, e tutte le directory .cache che contenendo una
grande quantità di file possono rendere molto lenta l’esecuzione del backup.
In caso di necessità il programma può essere interrotto, quanto salvato da
borgbackup fino all’ultimo checkpoint (di default sono ogni mezz’ora) non
verrà perso.

Ripristino
Il ripristino può essere effettuato manualmente montando il disco (o la
directory condivisa via NFS sul NAS) che contiene il repository dei backup, ed
usando il comando borg per recuperare direttamente i file da uno dei
salvataggi. Si legga la documentazione dei comandi borg list (per elencare
i backup disponibili) e borg extract (per estrarre i dati) con i relativi
esempi qualora si voglia usare questa strada.
Per semplificare le operazioni il comando fuss-backup può essere
utilizzato in forma interattiva con i comandi fuss-backup mount e
fuss-backup umount per montare e smontare i dati del backup in modo che
possano essere acceduti direttamente attraverso il filesystem.
Con fuss-backup mount viene montato il disco (o la directory NFS)
contenente il repository dei dati secondo quando configurato nella variabile
BASEDIR (il default è /mnt/backup) e poi viene reso disponibile via
FUSE il contenuto dei backup nella directory configurata dalla variabile
RECOVERDIR (il default è /mnt/recover).
In questo modo si può accedere direttamente ai file presenti nel backup resi
disponibili attraverso altrettante directory presenti sotto /mnt/recover
nella forma fuss-server-DATA-ORA (data e ora fanno riferimento al momento
di esecuzione del backup), ad esempio si potrà avere qualcosa del tipo:
root@fuss-server:~# ls /mnt/recover/ -l
totale 0
drwxr-xr-x 1 root root 0 gen 25 09:48 fuss-server-2017-01-20T17:39:56
drwxr-xr-x 1 root root 0 gen 25 09:48 fuss-server-2017-01-25T09:40:51

per cui se si vogliono recuperare i file del backup del 20 Gennaio si dovranno
cercare i file sotto fuss-server-2017-01-20T17:39:56 mentre per quelli del
25 si dovrà cercare sotto fuss-server-2017-01-25T09:40:51.
Al di sotto di ciascuna directory apparirà poi l’albero delle directory
che si sono coperte con il backup secondo il valore della variabile
PATHS. L’albero delle directory viene riportato a partire dalla
radice per cui nel caso dei valori di default di PATHS illustrato in
precedenza, avremo sotto fuss-server-2017-01-25T09:40:51 le
directory etc, home e var. A questo punto si potranno
copiare/esaminare i file dal backup navigando il filesystem sotto
/mnt/recover con un qualunque strumento di gestione dei file.
Una volta completate le operazioni di recupero si deve procedere a smontare le
directory ed i dati, con il comando fuss-server umount.

Avvertimento
ci si ricordi sempre di eseguire il comando fuss-backup
umount, altrimenti l’esecuzione ordinaria dei backup fallirà.

Pulizia delle Home
Fuss-server imposta un cronjob notturno home-cleanup, tutte le sere
alle 22:00, che effettua una pulizia delle home, cancellando i file:
.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml
.cache/chromium/*
.cache/google-chrome/*
.cache/mozilla/firefox/*

di tutti gli utenti LDAP, ad eccezione di admin e nobody, ed
ignorando gli utenti locali.
A partire dalla versione 10.0.33 l’orario di questo cronjob è
modificabile tramite variabili in
/etc/fuss-server/fuss-server-defaults.yaml:
home_cleanup_time_hour: 22
home_cleanup_time_minute: 0

Modifiche della netmask
Su un fuss-server configurato è possibile modificare la netmask della
rete interna: innanzitutto si deve cambiare la configurazione della rete
in /etc/network/interfaces o /etc/network/interfaces.d/,
impostando la nuova netmask, e ricaricare le nuove impostazioni ad
esempio riavviando il server.

Suggerimento
La configurazione di rete si può ricaricare anche tramite service
networking restart o con ifupdown2 (disponibile nei repository
debian ma non preinstallato sul fuss-server).

Quindi si può cambiare la configurazione in
/etc/fuss-server/fuss-server.yaml e lanciare fuss-server create
per riapplicare la configurazione di rete ovunque sia necessario.

Nota
Nel caso in cui gli indirizzi destinati al DHCP non siano compresi
nella netmask selezionata, fuss-server provvederà a chiedere un nuovo
range all’inizio della run.

Troubleshooting - Risoluzione di problemi

Reset password amministrative del fuss-server

Cambio password di root
Per cambiare la password di root del fuss-server non è necessaria nessuna
procedura particolare, basta eseguire semplicemente il comando passwd da
root.

Cambio password generale dei servizi (master password)
La situazione è più complessa qualora invece si voglia cambiare la «master
password» che si è usata in fase di creazione del server (quella che viene
mantenuta nella variabile pass del file
/etc/fuss-server/fuss-server.yaml).
In tal caso le operazioni da eseguire sono molte, in quanto essa viene usata
estensivamente nella configurazione di tutti i servizi, pertanto si è fornito
uno script di gestione apposito (mpwchange.sh, installato come gli altri
script in /usr/share/fuss-server/scripts) che consente di effettuarle in
una volta sola.
Per effettuare il cambio è sufficiente eseguire:
/usr/share/fuss-server/scripts/mpwchange.sh vecchia_password nuova_password

lo script controlla in /etc/fuss-server/fuss-server.yaml che la vecchia
password corrisponde e poi la cambia per i vari servizi (ed in
/etc/fuss-server/fuss-server.yaml stesso).
Qualora il comando desse un errore, si possono eseguire i singoli passi
manualmente come sotto indicato:

«Preparare» il seguente comando facendo attenzione a riempire
correttamente i seguenti 5 campi contenuti i dati di quella specifica
scuola e la nuova password:
ldappasswd -v -x -h 127.0.0.1 -D "cn=admin,dc=___,dc=___" -W -A -s "_NUOVA-PASSWORD_" "cn=admin,dc=__,dc=__"

Campi da riempire (5):
* dc= *1* (es.appiano)
* dc= *2*  (es.blz)
* "_NUOVA-PASSWORD_" (dove la nuova password rimane all'interno delle virgolette " ")
* dc= *3* (es.appiano)
* dc= *4*  (es.blz)

Esempio:
"_NUOVA-PASSWORD_"= LUNA.69

Il comando da lanciare è nell’esempio:
ldappasswd -v -x -h 127.0.0.1 -D "cn=admin,dc=appiano,dc=blz" -W -A -s "LUNA.69" "cn=admin,dc=appiano,dc=blz"

N.B.: Viene richiesta (3 volte) solamente la vecchia-password ,
in quanto la nuova password viene “passata” già dal comando dal
parametro -s
* Enter LDAP Password:            *(vecchia-password)
* Re-enter old password:          *(vecchia-password)
* Enter LDAP Password:            *(vecchia-password)

L’operazione si sarà conclusa correttamente se verrà restituito il
seguente OUTPUT
Result: Success (0)

Modificare i seguenti file, sostituendo la vecchia-password con
la nuova-password.
vim /root/.ldapvirc

Lanciare il seguente comando seguito dalla nuova password al posto
del campo _________:
smbpasswd -w _________

Verrà restituito un output come il seguente:
Setting stored password for "cn=admin,dc=appiano,dc=blz" in secrets.tdb

Modificare i seguenti file, sostituendo (2 volte) la
vecchia-password con la nuova-password .
vim /etc/smbldap-tools/smbldap_bind.conf

Lanciare il seguente comando e inserire (2 volte) la
nuova-password:
/usr/sbin/smbldap-passwd admin

Changing UNIX and samba passwords for admin
* New password: ____________
* Retype new password:____________

Modificare il seguente file sostituendo la password:
vim /etc/octofuss/octofuss.conf

Riavviare il servizio:
service octofussd restart

Lanciare il seguente comando seguito dalla nuova password al posto
del campo _________
octofussd --reset-root-password ___________

Verrà restituito un output come il seguente:
System check identified some issues:
WARNINGS:
?: (1_7.W001) MIDDLEWARE_CLASSES is not set.
HINT: Django 1.7 changed the global defaults for the MIDDLEWARE_CLASSES. django.contrib.sessions.middleware.SessionMiddleware, django.contrib.auth.middleware.AuthenticationMiddleware, and django.contrib.messages.middleware.MessageMiddleware were removed from the defaults. If your project needs these middleware then you should configure this setting.
Operations to perform:
Apply all migrations: data
Running migrations:
No migrations to apply.

Lanciare il seguente comando (ATTENZIONE: modalità «interattiva» di
kerberos!):
kadmin.local

ATTENZIONE: si entra in una modalità «interattiva» di kerberos e
verrà visualizzata la seguente riga:
kadmin.local:

dopo la quale bisognerà copiare il seguente comando:
cpw root/admin

Alla fine sul terminale si dovrà visualizzare la seguente riga:
kadmin.local: cpw root/admin

Premere il tasto INVIO: verrà chiesta 2 volte la nuova password:
* Enter password for principal ``root/admin@APPIANO.BLZ`` : ____________
* Re-enter password for principal ``root/admin@APPIANO.BLZ`` : ____________

a schermo poi si apre il seguente prompt:
kadmin.local:

Uscire da questa modalità interattiva digitando:
exit

Editare il seguente file per sostituire la MASTER-PASSWORD:
vim /etc/fuss-server/fuss-server.yaml

Procedure facoltative consigliate

Se si vuole che la master password coincida con la password di
root, aggiornare anche quest’ultima:
passwd root

Nuova password:_________

Reimmettere la nuova password: ________

Si potrà poi andare nella history ed eliminare le tracce dei comandi
contenenti la nuova password. La procedura è la seguente:

Visualizzare la lista dei comandi ed il loro numero progressivo
lanciando il comando:
history

Eliminare lo specifico comando (poniamo che sia il numero 764 della
lista) con:
history -d 764

Confermare le modifiche con:
history -w

A questo punto eventualmente aggiornare il server.

Ripristino LDAP da un backup
Lo script di backup del pacchetto fuss-backup (vedi
Backup con fuss-backup) si occupa di effettuare un dump dei dati
della directory LDAP, vedremo ora quale è la procedura per il suo
ripristino.
I dump del database LDAP vengono salvati da fuss-backup in
/var/backups/slapd ad ogni esecuzione (cancellando quelli più vecchi) in
file compressi con gzip nella forma slapd-$DATA.ldif.gz*, ma si
possono anche generare in qualunque momento con il comando slapcat >
backup.ldif.
È preferibile ripristinare i dati del server a partire da un dump generato
con slapcat perché questo contiene tutte le informazioni presenti
nell’LDAP originale (compresi i metadati, quali ad esempio i timestamp delle
varie modifiche). La procedura di ripristino è la seguente:
systemctl stop slapd.service
rm -rf /var/lib/ldap/*
slapadd < backup.ldif
chown openldap:openldap /var/lib/ldap/*
systemctl start slapd.service

(dove backup.ldif è il file del backup, se si usa uno dei dump di
fuss-backup questo prima deve essere decompresso).

Troubleshooting LDAP

L’utente non fa login su Windows
Cose banali da controllare prima:

l’utente esiste?
è stato fatto correttamente il join al dominio?
nome del dominio e dell’host sono corretti?
capslock?
cavo di rete? :-)

Potrebbe a questo punto essere un problema di LDAP, o meglio di come è
stato creato/modificato l’utente su LDAP Se windows vi dice che l’utente
è disabilitato, probabilmente il record sambaAcctFlags non è
impostato correttamente. Il flag D indica che l’utente è disabilitato,
un utente normalmente dovrebbe riportare il flag U o al massimo i flag
UX
Per correggere la situazione si usi il comando:
smbldap-usermod -H U nomeutente

o si usi ldapvi
Nel caso in cui gli utenti da migrare siano molti si può creare un file
docenti.txt contenente l’elenco dei nomi utenti dei docenti, uno per
riga, e quindi usare il comando:
for utente in $(cat docenti.txt); do smbldap-usermod -H U $utente; done

Troubleshooting DNS

Mancata risoluzione di macchine reinstallate con lo stesso nome
Il fuss-server utilizza il DNS dinamico per creare automaticamente delle voci
con i nomi delle macchine all’interno della zona locale della scuola, con la
direttiva ddns-update-style standard in /etc/dhcp/dhcpd.conf.  Il
meccanismo prevede che ogni volta che un client ottiene un indirizzo dinamico
dal DHCP venga inserita una voce con il suo nome (che viene invitato dal
client stesso, e corrisponde al suo hostname) all’interno della zona locale e
della zona inversa del DNS in modo da potercisi riferire direttamente per
nome.
I dati vengono inseriti nel file /var/cache/bind/db.local che contiene i
dati della zona DNS usata per la rete interna della scuola (quelli della
risoluzione interna in /var/cache/bind/db.192.168.XX.YY che dipende dal
range di indirizzi assegnati), dove compariranno delle voci nella forma:
test-client             A       192.168.13.57
                        DHCID   ( AAIBP7QJ7mJsQfNKCJli4K991QOr0lDOCeqRUWvz1A1U
                              SUE= ) ; 2 1 32

La voce è composta dall’IP assegnato e da un campo DHCID che è un hash
identificativo del client (in genere hostname e MAC address, ma dipende dal
client stesso) che serve ad evitare che un altra macchina possa tentare di
intrufolarsi nel DNS assumendo lo stesso nome e che due macchine cui si è
assegnato (erroneamente) lo stesso nome si sovrascrivano reciprocamente la
voce sul DNS.
Questi record vengono in genere cancellati automaticamente al rilascio dell’IP
da parte del client, ma può capitare, quando questo non avviene correttamente
(ad esempio perché viene spento senza shutdown), che restino nel file. Di
norma non costituiscono un problema fintanto che non si reinstalla un client
con lo stesso nome, che avrà un DHCID diverso per cui non sarà in grado di
riutilizzare il nome, né di rimuovere la voce.
Una soluzione di emergenza può essere quella di aggiungere a
/etc/dhcp/dhcpd.conf la direttiva update-conflict-detection no
immediatamente sotto la precedente ddns-update-style standard, questo
consente la riscrittura, ma comporta che i controlli di conflitti non ci sono
più, e si potranno ottenere situazioni in cui i problemi, manifestandosi in
forma casuale, sono molto più difficili da diagnosticare e
riconoscere. Pertanto è una soluzione di emergenza da non usare mai per più
dello stretto tempo necessario a risolvere un problema immediato, la soluzione
corretta è quella di rimuovere i record che danno il problema, con la
procedura illustrata di seguito.
Per la rimozione occorre modificare manualmente i file di zona citati in
precedenza (/var/cache/bind/db.local e
/var/cache/bind/db.192.168.XX.00), ma dato che l’assegnazione è dinamica,
il contenuto di questi file non è detto sia aggiornato alla situazione
corrente (i dati temporanei sono mantenuti in forma binaria in corrispondenti
file .jnl), ed inoltre i dati potrebbero ulteriormente aggiornati durante
la modifica, per cui prima di iniziare occorre «congelare» la situazione con
il comando:
rndc freeze

che salva tutti i dati temporanei e blocca gli aggiornamenti del DNS da parte
del DHCP.
Si potranno a quel punto cercare dentro /var/cache/bind/db.local le voci
dinamiche da rimuovere analoghe a quella illustrata. Si tenga presente che in
alcuni casi queste sono introdotte da una riga del tipo:
$TTL 3600       ; 1 hour

che indica il tempo di vita delle voci elencate di seguito (il valore indicato
può esser diverso a seconda delle impostazioni date al server DHCP). Questo
valore viene impostato, tutte le volte che varia, all’inizio di un blocco di
voci e si applica fino alla successiva reimpostazione, per questo può aiutare
a identificare le voci dinamiche rispetto a quelle statiche impostate in fase
di creazione del file con l’installazione del fuss server, che hanno un valore
di 604800.
Quando si rimuove una voce si abbia cura di toglierlo solo quando risulta
inutilmente replicato. Se si decide di fare una pulizia completa di tutte le
voci dinamiche va tolto evitando che vada ad applicarsi alle restanti voci
statiche.  In generale cancellare tutte le voci relative ad assegnazioni
dinamiche non è un problema (verranno ricreate al rinnovo o alla richiesta
successiva) ma la risoluzione dei nomi cancellati ovviamente diventerà
indisponibile fino ad allora. Per questo si consiglia di cancellare solo le
voci che contengono i nomi che danno problemi.
Si faccia inoltre attenzione a non cancellare o modificare invece le voci
«fisse» del file, come i nomi ns, proxy, octofuss ecc. ed in
generale tutti quelli che si sono inseriti manualmente nel file per le
assegnazioni statiche.
Una volta rimosse le voci da /var/cache/bind/db.local si cancellino le
voci corrispondenti con la risoluzione inversa in
/var/cache/bind/db.192.168.XX.00, che nel caso dell’esempio precedente
saranno qualcosa del tipo:
57                      PTR     test-client.fusslab.blz.

Una volta completate le modifiche occorre aggiornare il seriale dei file di
zona (entrambi), per questo occorre cercare la riga identificata dal commento
; serial nel record SOA che è all’inizio del file, ed aumentare di uno
il valore in essa indicata; se ad esempio 811 era il valore in
/var/cache/bind/db.local precedente alle modifiche, si dovrà indicare al
suo posto 812, con qualcosa del tipo:
$ORIGIN .
$TTL 604800     ; 1 week
fusslab.blz             IN SOA  ns.fusslab.blz. root.marcela.fusslab.blz. (
                              812        ; serial
                              604800     ; refresh (1 week)
                              86400      ; retry (1 day)
                              2419200    ; expire (4 weeks)
                              604800     ; minimum (1 week)
                              )

Fatto questo si potrà «scongelare» la zona con il comando:
rndc thaw

e l’aggiornamento dinamico riprenderà a funzionare.

Mancata risoluzione di macchine con assegnazione statica
Una delle funzionalità fornite dal fuss-server è quella di consentire delle
assegnazioni statiche (reservation) degli IP in base al MAC address delle
macchine. Queste vengono mantenute nel file
/etc/dhcp/dhcp-reservations e gestite tramite octonet.
Fino alla versione 10.0.13 octofussd si limita a gestire questa
assegnazione statica, le macchine elencate nel file non venivano inserite nel
DNS. Pertanto le macchine elencate ottengono un indirizzo IP (quello
selezionato dalla funzionalità) ma il loro nome resta assente dal DNS.
A partire dalla versione 10.0.14 è stato aggiunto il supporto per
l’inserimento (in fase di creazione) e la cancellazione (in fase di rimozione)
sul DNS delle macchine indicate per l’assegnazione statica. Non è ancora
disponibile il supporto per la modifica dei dati (pertanto in caso di
necessità si cancelli e si ricrei una voce).
Il supporto disponibile a partire dalla versione 10.0.14 riguarda però
soltanto le nuove voci, per quelle già presenti il DNS non viene
aggiornato. Per gestire questo caso (o se si sta mantenendo l’uso una versione
precedente la 10.0.14) le voci devono essere inserite o eliminate a mano.
L’operazione prevede la modifica manuale dei file di zona
(/var/cache/bind/db.local e /var/cache/bind/db.192.168.XX.00) che sono
gestiti in maniera dinamica; per questo (si riveda quanto già detto al
riguardo nella sezione precedente, prima di modificarli occorre «congelare» la
situazione con il comando:
rndc freeze

a questo punto si potranno aggiungere i dati, in /var/cache/bind/db.local
va messa la risoluzione diretta, usando un TTL adeguato, con qualcosa del
tipo:
$TTL 604800     ; 1 week
static1              A       192.168.0.100

(avendo cura di usare il nome e l’indirizzo che ci sono in
/etc/dhcp/dhcp-reservations) dove la voce del TTL può essere omessa
se la riga viene inserita sotto un blocco di definizione che ha all’inizio la
stessa.
La modifica va fatta anche nella zona inversa (in
/var/cache/bind/db.192.168.XX.00) con qualcosa del tipo:
$TTL 604800     ; 1 week
100                      PTR     static1.fusslab.blz.

e vale lo stesso avviso relativamente al TTL, fatte le modifiche occorrerà di
nuovo aumentare il seriale (si rimanda a quanto detto nella sezione
precedente) e poi si potrà «scongelare» la zona con il comando:
rndc thaw

a questo punto le risoluzioni saranno disponibili.
A partire dal fuss-server 10.0.24 è disponibile lo script dnsreserv.py
(in /usr/share/fuss-server/scripts) che rilegge il contenuto di
/etc/dhcp/dhcp-reservations ed esegue un DDNS update per tutti i
nomi ivi contenuti, questo consente di evitare l’intervento manuale per
reinserirli, ma la eventuale cancellazione di nomi spuri non viene eseguita e
in tal caso si deve ricorrere alla precedente procedura manuale.

Corruzione del repository dei backup
Può accadere che, se il programma viene interrotto in maniera inopportuna, il
repository che mantiene i dati del backup risulti corrotto. In tal caso si
potranno ottenere degli errori (riportati nella mail riassuntiva inviata al
completamento di ogni backup) del tipo:
borg.helpers.IntegrityError: Segment entry checksum mismatch [...]

In questo caso è necessario eseguire una verifica manuale, ed eventualmente
riparare il repository dei dati.
Per farlo è necessario montare il disco remoto su cui si fanno i backup,
questo si può fare (utilizzando i dati contenuti nella configurazione del
fuss-backup) con i comandi:
. /etc/fuss-backup/fuss-backup.conf
mount $DISK $BASEDIR

poi si potrà verificare lo stato del repository, con:
borg check $BASEDIR/$BACKUP_DIR

e se questo riporta degli errori si potranno sistemare con:
borg check --repair $BASEDIR/$BACKUP_DIR

accettando che si possano perdere dei dati (sono dati del backup, si possono
ripristinare facendone uno subito dopo la riparazione). Completata la
riparazione ci si ricordi di smontare il disco remoto con umount $BASEDIR.

Gestione dei FUSS client

Configurazione di un FUSS Client
Per configurare una macchina come FUSS Client è disponibile il comando
fuss-client, installato col pacchetto omonimo, che cura tutta la
configurazione della macchina, e l’eventuale collegamento della stessa al
Fuss Server, installando il software necessario ed effettuando le relative
configurazioni.

Installazione ordinaria
Il comando principale per la configurazione del client è fuss-client -a
che esegue il collegamento ad un Fuss Server rilevato automaticamente nella
rete in cui è stata inserita la macchina.
Se si dispone di una chiavetta con una chiave di autenticazione per il
Fuss Server questa deve essere inserita sulla macchina, e la procedura
sarà completamente automatizzata (per i dettagli vedi Accesso con
chiave al server per fuss-client), altrimenti una volta lanciato il
comando dovrà essere immessa per tre volte la password di root del Fuss
Server per consentire l’importazione delle credenziali necessarie.
Se non vi sono cluster definiti sul Fuss Server è necessario
definirne preventivamente uno, se ne è definito soltanto uno non verrà
chiesto nient’altro e l’installazione proseguirà direttamente fino alla
fine, ottenendo sul terminale un risultato del tipo:
PLAY RECAP ****************************************************************
localhost                  : ok=129  changed=71   unreachable=0    failed=0

(dove si deve avere failed=0)
Se invece sul Fuss Server sono presenti più cluster all’inizio verrà chiesto
di scegliere in quale essere inseriti con una schermata del tipo:
This server has several workstation groups

Please choose the one desired for this machine:
0  -  aula1
1  -  aula2

Your choice? (enter the server number)
0
...

Impostazione dell’hostname
Il comando fuss-client supporta la installazione ed il collegamento
al server di una macchina con la contestuale impostazione del nome della
stessa. Questo risulta utile quando un pc viene installato utilizzando
una immagine creata con clonezilla, che ha ovviamente impostato
l’hostname del client da cui la si è creata.
Inoltre, il comando fuss-client effettua una normalizzazione dei
nomi delle macchine, infatti in alcuni casi veniva usato come hostname
della macchina l’hostname completo (FQDN) della stessa, cosa che crea
poi problemi nella risoluzione dei nomi ed inseriva gli stessi nel file
/etc/clusters del server. Questo cosa poi aveva portato ad usare
come hostname completo (impostato in /etc/hosts) un nome semplice
senza dominio (cosa che potrebbe causare problemi con eventuali servizi
installati successivamente).
Quando si esegue l’installazione ed il collegamento al server di un client, il
comando che permette l’impostazione contestuale dell’hostname della macchina
usando l’opzione -H nella forma:
fuss-server -a -H clientname

dove clientname deve essere un nome a dominio alfanumerico che non deve
contenere nessun «.», ed essere indicato solo con lettere minuscole.
In tal caso il client, ottenuto il nome del dominio dal server, effettuerà la
corretta impostazione dei file /etc/hostname, inserendovi semplicemente il
nome indicato con un contenuto come:
clientname

mentre in /etc/hosts verrà inserito il corretto valore per la risoluzione
completa con un contenuto come:
127.0.1.1     clientname.institute.lan clientname

e si otterrà correttamente che:
root@testclient:~# hostname
clientname
root@testclient:~# hostname -f
clientname.institute.lan

ed in questo modo nel file /etc/clusters del server verrà usato il nome
della macchina.

Veyon
A partire da FUSS Client 10.0.40, la configurazione di Veyon viene fatta
in maniera completamente automatica estraendo i dati sui client da
/etc/clusters sul server FUSS.
Potranno utilizzare Veyon master , da qualsiasi postazione di uno
stesso cluster, solo gli utenti appartenenti al gruppo veyon-master
(che andranno pertanto opportunamente scelti ed associati al gruppo).
Per ragioni di sicurezza sono stati implementati dei controlli che
facciano sì che non sia controllabile da qualcun altro attraverso Veyon
nessun utente membro di almeno uno dei seguenti gruppi
- docenti
- insegnanti
- veyon-master
- tecnici

Qualora si volesse inibire ulteriori gruppi, sarà necessario creare il
file di testo /var/www/html/veyon/excluded_groups con,  uno per
riga, i nomi dei gruppi.
Attenzione: questo file permette di fare l’override anche dei gruppi
pre-impostati, che andranno pertanto inseriti nel file
excluded_groups per evitare, ad esempio, il controllo sul gruppo
docenti.
Diverse funzionalità di Veyon tipo accensione e spegnimento dei PC,
condivisione dello schermo del docente o aggiornamento dei PC non sono
al momento fruibili e verranno nascoste dall’interfaccia con un prossimo
aggiornamento.

Aggiornamenti

Aggiornamenti minori di fuss-client
Nel caso ci siano aggiornamenti di minor version di fuss-client (10.0.x →
10.0.(x+1)) li si può applicare aggiornando il pacchetto:
# apt update
# apt install fuss-client

e quindi lanciando:
# fuss-client -U

per applicare le nuove configurazioni.
Le informazioni presenti in /usr/share/doc/fuss-client/changelog.gz
(dopo l’installazione del pacchetto) possono essere utili per scoprire
se le modifiche sono utili per installazioni esistenti o se riguardano
solo le nuove installazioni.

Accesso con chiave al server per fuss-client
Per collegare i client ad un fuss-server è necessario dare accesso ssh
al server a chi effettua il collegamento; è possibile limitare questo
accesso usando una chiave ssh apposita che da accesso come root al
server, limitato però ai soli comandi necessari per fuss-client.
Coi comandi fuss-server create o fuss-server upgrade viene
creata una coppia di chiavi in
/etc/fuss-server/client_keys/client-rsa(.pub) e la stessa viene
abilitata per l’accesso al server da parte di fuss-client.
Sui client già configurati con fuss-client è disponibile uno script,
/usr/local/sbin/copy_server_key, che prepara una chiavetta USB
configurata per essere riconosciuta da fuss-client, il quale
provvede a montarla, usarla per l’identificazione e poi smontarla quando
non più necessaria, in modo da poter essere spostata sugli altri client.
In alternativa, è possibile trasferire la chiave privata sui client in
altro modo a piacere ed usare l’opzione -k
</path/completo/della/chiave> per identificarsi senza password.  In
questo caso è ovviamente cura dell’utente provvedere a mount e umount di
eventuali dispositivi rimovibili.

Nota
ssh impone che il file della chiave abbia permessi tali da
impedirne la lettura ad altri utenti; se tali file sono su
filesystem ext è opportuno assegnare i permessi 0600 al file
della chiave privata.
Se si usa invece un filesystem FAT, è necessario usare opzioni di
mount opportune per evitare che i file si presentino con permessi
0755, come avviene di default.

In entrambi i casi, i file presenti sulla chiavetta vengono usati
durante la fase iniziale di fuss-client; quando non sono più in uso
viene emesso un suono diverso a seconda se la chiavetta sia stata
smontata e la si possa rimuovere tranquillamente o ci siano stati
problemi nello smontaggio e quindi la si può smontare a mano e
rimuovere.
Nel caso in cui non si senta il suono, questo avviene poco prima del
momento in cui iniziano le scritte colorate di ansible.

Gestione delle chiavi

Aggiunta di nuove chiavi sul server
È possibile abilitare nuove chiavi mettendo la coppia di chiavi
pubbliche e private in /etc/fuss-server/client_keys/ e lanciando
fuss-server upgrade perché vengano abilitate all’accesso.
/etc/fuss-server/client_keys/client-rsa(.pub) deve esistere
(altrimenti ne viene creata una nuova) ed è la chiave di default usata
ad esempio dallo script copy_server_key, altre chiavi vanno gestite
manualmente.

Disabilitazione di chiavi
Per disabilitare una chiave dal server è necessario:

rimuovere la riga corrispondente da /root/.ssh/authorized_keys
rimuovere le chiavi pubbliche e private da /etc/fuss-server/client_keys/

Creazione di una chiavetta USB con le chiavi ssh
Sui client già configurati, a partire dalla versione 9.0.16 di
fuss-client, è presente uno script, /usr/local/sbin/copy_server_key,
per creare chiavette USB contenenti le chiavi ssh da usare per
l’identificazione.
Lo script non dipende da altre componenti del fuss-client e può essere
copiato su altre macchine; in tal caso per usarlo è necessario aver
installato il pacchetto python3-pyudev (dipendenza di fuss-client).
Per usarlo, collegare una chiavetta USB vuota al computer e lanciare il
comando:
# copy_server_key /dev/sdXn

dove /dev/sdXn è il device corrispondente alla partizione della
chiavetta dove si desiderano salvare le chiavi.

Avvertimento
La partizione specificata verrà riformattata, perdendo
tutti i dati eventualmente presenti sulla chiavetta.

Di default viene copiata la chiave presente sul server raggiungibile
all’indirizzo proxy; in alternativa si può specificare l’indirizzo
del server tramite l’opzione -s <indirizzo.del.server>.

Avvertimento
Nella versione di mkfs.ext4 presente in Debian Buster, e
quindi sui vecchi fuss-client, è presente un bug nella localizzazione
italiana, #907034, che
stampa le richieste di conferma in inglese, ma si aspetta risposta in
italiano.
Se viene stampata una richiesta tipo:
mke2fs 1.43.4 (31-Jan-2017)
/dev/sdb1 contiene un file system ext4 con etichetta "portachiavi"
    last mounted on /mnt/portachiavi on Mon Aug 13 09:40:52 2018
Proceed anyway? (y,N)

è necessario premere s per continuare; y non viene
riconosciuto e viene trattato come il default, n, che quindi
causa l’uscita immediata dal programma.

Specifiche

Chiavi USB per la distribuzione delle chiavi ssh
Per poter lavorare in modo sicuro, fuss-client senza opzione -k
richiede che le chiavi ssh siano salvate su una chiavetta USB
configurata in modo ben preciso, come generata dallo script
copy_server_key.
La chiavetta USB deve contenere una partizione formattata ext con
etichetta portachiave, all’interno della quale è presente una
directory server_key contenente il file client-rsa con permessi
rispettivamente 0700 e 0600, entrambi appartenenti all’utente
root.

Risoluzione di problemi

Diagnostica degli errori di fuss-client
Per poter risolvere eventuali problemi di installazione di un client durante
l’esecuzione di fuss-client è essenziale poter disporre del log completo
delle operazioni effettuate da ansible durante l’esecuzione, riportare solo
le righe finali del risultato non è sufficiente.
Per questo nel caso si presentino problemi è opportuno rilanciare il comando
seguendo le indicazioni per registrare la sessione illustrate in
Bug reporting.

Procedure alternative

Installazione su Debian 12 (bookworm)
Fuss Client può essere installato su una Debian 12 (bookworm) standard; in
tal caso è necessario effettuare alcune configurazioni, sempre lavorando
come root.

Installare Debian 12 (bookworm) recuperando una delle seguenti ISO (a
seconda dell’occorrenza):

Architettura
ISO xfce-desktop UFFICIALE
ISO xfce-desktop NON UFFICIALE (con firmware proprietari)

amd64
debian-live-<versione>-amd64-xfce.iso
debian-live-<versione>-amd64-xfce+nonfree.iso

i386
debian-live-<versione>-i386-xfce.iso
debian-live-<versione>-i386-xfce+nonfree.iso

Abilitare i repository fuss in
/etc/apt/source.list.d/archive_fuss_bz_it.list:
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main

aggiungere la chiave di firma del repository e aggiornare apt:
# wget -qO /usr/share/keyrings/fuss-keyring.gpg  https://archive.fuss.bz.it/apt.gpg
# apt update

ed infine, lanciare il programma fuss-client:
# fuss-client -a

Installazione standalone
fuss-client supporta anche una modalità di installazione standalone
che non effettua il collegamento ad un fuss-server, ma si limita a
configurare un’installazione di debian con i programmi e le
personalizzazione del sistema fuss.
Per usarla, a partire da un’installazione pulita di Debian, è
sufficiente aggiungere i repository fuss in
/etc/apt/source.list.d/archive_fuss_bz_it.list:
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ bookworm main

aggiungere la chiave di firma del repository e aggiornare apt:
# wget -qO - https://archive.fuss.bz.it/apt.key | gpg --dearmour > /usr/share/keyrings/fuss-keyring.gpg
# apt update

ed infine, lanciare il programma fuss-client:
# fuss-client --standalone

Configurazione di chroot per la generazione di iso
Nel caso in cui si stia configurando con --standalone non una
macchina reale ma una chroot, si può aggiungere l’opzione --iso per
evitare che siano configurati grub e i locale, per evitare fallimenti.

Installazione leggera
L’opzione --light permette di fare installazioni più leggere
evitando di installare gli inter metapacchetti fuss-kids,
fuss-children e fuss-education. Ovviamente una selezione di
pacchetti educational più limitata può essere installata manualmente in
un secondo tempo.

Supporto per firmware proprietari
Per il funzionamento di determinato hardware è necessario l’uso di
firmware proprietari, disponibili nella sezione non-free-firmware
dei repository.
L’opzione --unofficial di fuss-client aggiunge l’installazione
di tali firmware; per usarla è necessario abilitare le sezioni
contrib, non-free-firmware e non-free per i repository
debian in /etc/apt/sources.list.

Avvertimento
Come dice il nome, questa opzione è da considerarsi non
ufficiale, ed in particolare l’installazione di software da
non-free diverso dai firmware necessari per il supporto hardware
non è supportata.

Cambiamento dell’hostname
Per cambiare l’hostname di un fuss-client si può lanciare il comando:
fuss-client -H <nuovo_hostname>

questo aggiorna anche la chiave kerberos con il nuovo hostname.
L’opzione è pensata per essere usata su macchine appena ripristinate da
un’immagine pulita per assegnare un hostname unico alla stessa subito
prima di configurarla con fuss-client.
L’uso di questa opzione su macchine già configurate con fuss-client è
adeguato nel caso in cui si sia fatto un errore nell’assegnazione
dell’hostname, ma è sconsigliato farne uso sistematico, e in particolare
nel caso di cambiamento del server è consigliabile effettuare un restore
da immagine pulita.
Nel caso si usi questa opzione su un client che è già stato collegato ad
un fuss-server è inoltre opportuno usare, sul server, il comando:
/usr/share/fuss-server/scripts/forget_client <vecchio_hostname>

per rimuovere le tracce della registrazione con l’hostname precedente.

Rimozione completa della configurazione dei client
Premessa
Fino a fuss 11 fuss-client permetteva di togliere parte della configurazione di un FUSS Client in modo da poterlo spostare da un server in dismissione ad un nuovo server senza reinstallarlo.
Si otteneva lanciando il comando:
# fuss-client -r -p

quindi spostando il client sulla rete del nuovo server e lanciando fuss-client regolarmente come indicato sopra.
Configurazione attuale
A partire da fuss 12, una volta che una macchina è stato configurata non è possibile rimuovere in modo affidabile la sua configurazione;
per cambiare totalmente caso d’uso di un PC (ad esempio da client a standalone) è necessario ripristinare la sua installazione da un’immagine pulita
tramite fuss-fucc (o effettuarne una nuova installazione, a seconda di cosa risulti più comodo o veloce).
Mantenendo lo stesso caso d’uso (ridenominazione di un client nella stessa rete o spostamento di un client da una rete ad un’altra), generalmente è sufficiente una riconfigurazione con l’opzione -H documentata sopra:
fuss-client -H client_name

Per rimuovere il client lato server è necessario invece lanciare sul server il comando:
/usr/share/fuss-server/scripts/forget_client client_name

Nel caso vi sia la necessità di rimuovere un certo numero di client dal server,
è vantaggioso creare ad esempio nella cartella  /root del server una lista di hostname da rimuovere
chiamandola client-forget.csv e uno script forget-clients come il seguente:
#!/bin/sh

systemctl stop octofussd
for HOSTNAME in $(cat client-forget.csv)
do
        echo $HOSTNAME
        DOMAINNAME=$(dnsdomainname)
        FQDN="$HOSTNAME.$DOMAINNAME"
        sed -r -i "s/ +$HOSTNAME( +|$)/\1/g" /etc/clusters
        kadmin.local ktremove nfs/$FQDN all
        kadmin.local delprinc nfs/$FQDN
done
systemctl start octofussd

Lanciando questo script, tutti i client elencati vengono rimossi dal join e cancellati da /etc/clusters.

L’interfaccia di gestione di OctoNet

Architettura

Servizi necessari al funzionamento
Per poter utilizzare l’interfaccia di gestione di OctoNet, occorre che
sia attiva tutta l’infrastruttura di gestione Octofuss) fornita del
Fuss Server, che prevede la presenza dei seguenti tre servizi (gestiti
con systemd e lanciati all’avvio del server):

octofussd: demone di gestione dell’infrastruttura di gestione
Octofuss (verificabile con systemctl status octofussd);
octonet: servizio che fornisce l’interfaccia web di OctoNet
(verificabile con systemctl status octonet);
octofuss-client: demone di controllo della macchina locale, da
installare anche sul server (verificabile con systemctl status
octofuss-client).

Accesso all’interfaccia web
Il Fuss Server fornisce l’interfaccia di gestione via web OctoNet, cui si
accede tramite browser.
Sul server stesso si può accedere usando l’indirizzo
http://localhost:13402; dato che l’accesso è fornito senza
cifratura non è sicuro collegarvisi direttamente da altre macchine, ma
si può usare un tunnel SSH: su un terminale da un qualunque client della
rete interna eseguire:
$ ssh sshuser@proxy -L 13402:localhost:13402

dove sshuser è un qualunque utente con accesso SSH sul server (cioè
facente parte del gruppo sshaccess).
Per abilitare l’accesso anche alla nuova piattaforma Fuss Manager
occorre collegare anche la porta 1232:
$ ssh sshuser@proxy -L 13402:localhost:13402 -L 1232:localhost:1232

Una volta collegati in console, si potrà accedere all’interfaccia web
usando un browser sul client puntandolo all’indirizzo
http://localhost:13402, dove si otterrà la seguente schermata di
accesso:

Con l’installazione del Fuss Server viene creato un accesso di default
con username root e password uguale alla master password impostata
durante l’esecuzione del comando fuss-server create (l’utenza creata
è interna al servizio octofussd e non ha nulla a che fare con
l’utenza root di sistema). Una volta effettuato l’accesso si otterrà
una pagina come la seguente:

Nella pagina è disponibile, nella colonna sulla sinistra, il menu delle
diverse funzionalità di gestione fornite da OctoNet. Si tenga presente che il
menu è dinamico e mostra le diverse funzionalità solo quando queste sono
disponibili (se ad esempio non sono state abilitate le quote disco, la
relativa voce non sarà presente).
La barra in alto riporta a destra un menù utente che consente di scollegarsi,
ed alla sua sinistra un menu di scelta della lingua (sono disponibili inglese,
italiano e tedesco). Nel seguito faremo riferimento alla versione in italiano.

L’interfaccia a riga di comando octofussctl
L’infrastruttura di Octofuss mette a disposizione un tool a riga di comando,
octofussctl, che consente di effettuare le operazioni di gestione in forma
scriptabile.
Il comando richiede le stesse credenziali di accesso utilizzate per OctoNet,
e fornisce sia una linea di comando interattiva, che la possibilità di
eseguire operazioni in batch (scrivendo i relativi comandi all’interno di un
file di testo da passare al comando con l’opzione -b).
Per l’accesso occorre indicare la URL che identifica il server, nella forma:
octofussctl http://localhost:13400/conf

si può indicare l’utente con l’opzione -u (o con la variabile di ambiente
OCTOFUSS_USER) mentre la password, se non indicata nella variabile di
ambiente OCTOFUSS_PASSWORD, viene richiesta sul terminale. Le credenziali
sono le stesse che si usano per OctoNet (e si applica quanto detto in
precedenza).
I comandi disponibili all’interno della shell di octofussctl sono elencati
dal comando help, ed il relativo funzionamento con help comando.
Con octofussctl diventa possibile automatizzare alcune operazioni che
diventerebbero molto macchinose da eseguire attraverso l’interfaccia web; ad
esempio qualora si volessero cancellare tutti gli utenti di un gruppo
(l’interfaccia web consente di rimuoverli da un gruppo, ma non di
cancellarli), si potrebbe usare il comando delete in un ciclo come:
export OCTOFUSS_PASSWORD=password
export OCTOFUSS_USER=root
for i in $(members gruppo); do
  octofussctl http://localhost:13400/conf delete /users/users/$i
done

Gestione Utenti e Gruppi
Si può accedere alla gestione utenti di OctoNet attraverso la voce Utenti e
Gruppi che abilita sulla barra superiore (sulla sinistra) un menu omonimo da
cui accedere alle altre pagine.

Visualizzazione utenti
Una volta selezionata la gestione utenti si viene portati sulla pagina di
gestione degli utenti (corrispondente alla voce Tutti gli utenti del
suddetto menu).

La pagina visualizza una tabella con tutti gli utenti creati sul server (solo
quelli gestiti in maniera centralizzata attraverso il servizio LDAP), due di
questi, admin e nobody sono utenti di servizio sempre presenti che non
devono essere modificati (sono disabilitati, e per questo contraddistinti da
una crocetta rossa).
Si può cambiare il numero di utenti visualizzati selezionando una delle
possibilità nel menu a tendina Visualizza sulla sinistra o eseguire una
ricerca sul nome utente inserendo una stringa nel campo Cerca.
Cliccando sul link con il nome utente in seconda colonna o sul pulsante
modifica sulla riga dello stesso, è possibile accedere alla pagina di gestione
dell’utente stesso:

Gestione gruppi
Si tenga conto che prima di creare un utente, se si vuole che questo sia
assegnato ad un qualche gruppo specifico, occorre che quest’ultimo esista.
L’elenco dei gruppi di ottiene dal menu Utenti e Gruppi -> Tutti i gruppi,
alcuni di questi sono automaticamente definiti (ad uso di Samba)
all’installazione del Fuss Server, e sono quelli mostrati nella pagina
seguente:

Da questa pagina si può aggiungere un nuovo gruppo con il pulsante Crea nuovo
gruppo o selezionando la stessa funzionalità dal menu Utenti e Gruppi, si
otterrà la pagina di creazione:

in cui occorre inserire il nome del gruppo (che deve essere indicato usando
solo lettere minuscole e numeri, senza spazi o altri caratteri di
interpunzione).  Una volta creato il gruppo si verrà riportati nella pagina
dello stesso, che ne elenca i membri (all’inizio nessuno):

É opportuno creare un gruppo per ogni classe che si vuole definire, ed
eventuali altri gruppo per tipologia di utenti (tecnici, segreteria, docenti,
ecc.). Ma si tenga conto che il gruppo docenti (o qualunque gruppo il cui nome
inizi per docent) ha un ruolo speciale per la gestione della scadenza
delle password secondo le normative della privacy, ed è riservato alle utenze
degli insegnanti.
Una volta che si sia creato un gruppo questo potrà essere usato nelle pagine
di gestione o creazione degli utenti, e questi vi potranno essere inseriti o
tolti. Inoltre premendo sul pulsante Modifica in alto a destra si passerà
alla pagina di gestione del gruppo:

I membri presenti sono presenti sono illustrati nella casella di testo
Membri come pulsanti, e possono essere tolti dal gruppo cliccando sulla
crocetta nel pulsante, cliccando invece nell’area vuota verrà presentato un
menu a tendina con gli utenti disponibile con cui è possibile aggiungere nuovi
membri al gruppo. Una volta completate le modifiche si dovranno salvare con il
pulsante Salva.
Ulteriori operazioni sono possibili con i pulsanti a destra, in tal caso
l’applicazione è immediata ed una volta effettuata l’operazione si viene
riportati nella pagina del gruppo; le operazioni sono:

con Aggiungi gruppo è possibile aggiungere tutti gli utenti del gruppo
corrente ad un altro gruppo, selezionato dal menu a tendina sovrastante;
è possibile rimuovere in un colpo solo tutti gli utenti dal gruppo con il
pulsante Rimuovi tutti gli utenti;
è possibile aggiungere in blocco dei Permessi a tutti gli utenti del gruppo
con il pulsante Aggiungi permesso, selezionando quale permesso dal menu a
tendina soprastante;
analogamente con il pulsante Aggiungi permesso si potrà rimuovere un
permesso, sempre da selezionare dal menu a tendina soprastante, a tutti gli
utenti del gruppo.

Creazione e gestione utente singolo
Una volta che si sono creati i gruppi necessari per creare un utente occorre
selezionare la voce Utenti e Gruppi -> Crea utente dal menu di gestione
Utenti e Gruppi che porta nella pagina di creazione illustrata di seguito:

In questo caso occorrerà specificare anzitutto un nome utente, di nuovo
occorre indicare lo stesso utilizzando solo lettere minuscole e numeri, senza
spazi o altri caratteri di interpunzione, nello scriverlo verrà avvalorato
automaticamente il campo della Directory Home con il default (che è sempre
/home/nomeutente). Se l’utente è uno studente è opportuno indicare come
Gruppo Primario quello corrispondente alla sua classe, ed indicarne il nome
completo (qui si possono usare maiuscole e spazi) nel campo omonimo.
I campi Shell predefinita, Gruppo Controllore e Directory Home si
possono lasciare al default; eventualmente si può modificare quest’ultima se
si è deciso di suddividere le home degli studenti per classe, usando un
percorso del tipo /home/studenti/nomeclasse/nomestudente.
La password deve esser immessa due volte (uguale nei campi Password e
Conferma). Eventuali ulteriori gruppi di cui si vuole l’utente faccia parte
vanno indicati nel campo Gruppi (cliccando all’interno vengono mostrati in
una tendina quelli che corrispondono al testo immesso).
Il campo Permessi serve a controllare i permessi che verranno assegnati
all’utente perché questo possa utilizzare le relative funzionalità quando si
collega su un client. Questi corrispondono ad altrettanti gruppi locali dei
client nel quale l’utente verrà automaticamente inserito (si tenga conto però
che questo non è immediato, occorre che il client sia acceso e si sincronizzi
con il server, per cui possono, nella peggiore delle ipotesi, passare anche 5
minuti perché questo avvenga).
Inoltre, perché venga abilitata la navigazione su internet è necessario
che venga rinnovata la cache di nscd: per forzare un aggiornamento
si può usare la voce Propaga i permessi di accesso alla rete nel menù
Utenti e Gruppi.

Il default propone i permessi per l’accesso alla scheda sonora, ai dispositivi
rimuovibili, allo scanner, ad internet ed al CDROM, secondo l’elenco in
tabella.

Permesso
Significato

plugdev
Può utilizzare dispositivi rimuovibili (chiavette USB, ecc.)

cdrom
Ha accesso a CD e DVD

audio
Può utilizzare i dispositivi audio (scheda sonora)

video
Può usare dispositivi di registrazione video (ex. webcam)

internet
Può navigare il web attraverso il proxy

scanner
Può utilizzare uno scanner

lpadmin
Può amministrare le stampanti

bluetooth
Può comunicare con il servizio bluetooth attraverso dbus

netdev
Può amministrare le interfacce di rete via Network Manager

Cliccando sulla crocetta essi possono essere rimossi, cliccando nel campo
viene mostrato un menu a tendina che mostra quelli disponibili, con quelli
presenti in grigio, ed è possibile aggiungerne altri. Una volta premuto il
pulsante Salva l’utente verrà creato e si verrà portati sulla relativa
pagina di gestione:

Si noti come l’utente, non essendo stato classificato come docente, riporti
nella riga Unità il valore studente. Come accennato questo parametro viene
gestito in modalità automatica sulla base del gruppo principale dell’utente, e
determina le modalità con cui viene gestita la scadenza delle password, che
non c’è per uno studente (che non tratta dati personali) mentre viene
applicata per i docenti secondo i requisiti della normativa sulla privacy.
Nel caso si voglia creare un utente per un docente occorrerà allora utilizzare
come gruppo principale (attenzione, gruppo principale, nella voce Gruppo
primario e non in uno dei gruppi ausiliari indicati nella voce Gruppi) un
gruppo il cui nome inizi con la stringa docent (è così possibile creare
più gruppi per i docenti, per differenziare eventuali diritti di accesso, ad
esempio per il Gruppo Controllore).
Un esempio è nella pagina seguente, dove oltre ad usare il gruppo docenti
si assegna all’utente anche il privilegio lpadmin che consente di
effettuare la gestione delle stampanti.

con l’utilizzo del gruppo  docenti come gruppo principale il nuovo utente
verrà classificato nella riga Unità come docente:

Una volta creato l’utente si potrà modificarne le impostazioni, disabilitarlo
o eliminarlo cliccando sul pulsante Modifica della sua pagina di gestione:

Da questa pagina, oltre a cambiare le proprietà inserite in fase di creazione
(tutte tranne il nome utente, che non può essere cambiato via OctoNet, se lo
si è sbagliato si deve cancellare e creare da capo), sono possibili alcune
ulteriori operazioni:

si possono (quando sono state configurate ed abilitate) inserire le quote
disco (nella sezione Modifica Quote) dell’utente
si può cancellare l’utente con il pulsante Elimina utente; l’utente verrà
cancellato e per non perdere eventuali suoi dati verrà creato un archivio
username.tar.gz con il contenuto della sua home directory nella
directory sotto cui questa si trovava
si può disabilitare l’utente con il pulsante Disabilita utente, nel qual
caso l’accesso dell’utente verrà disabilitato, l’utente verrà marcato come
disabilitato nella lista degli utenti e nella sua pagina, ma il suo account
resterà attivo e potrà essere riabilitato
si può riabilitare un utente precedentemente disabilitato con il pulsante
Abilita utente che compare al posto di quello Disabilita utente nella
pagina di modifica quando l’utente è disabilitato.

Avvertimento
ATTENZIONE!
Nel caso in cui il pulsante di Modifica ci porti alla pagina di errore, è possibile che non siano state configurate correttamente le quote (vedi https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#configurazione-iniziale-per-le-quote     ).
Ad ogni modo, per indagare la causa del malfunzionamento di octonet, si possono usare i comandi:
systemctl status octonet.service

oppure:
journalctl -u octonet.service

Gestione manuale di utenti e gruppi
Il modo migliore per gestire utenti è usare l’apposita interfaccia di octofuss
che automatizza l’intera procedura minimizzando il rischio di errori, inoltre
è l’unico che consente la gestione dei permessi degli utenti. Questi appunti
sono utili nel caso sia invece necessario intervenire direttamente tramite gli
smbldap-tools. Si da per assunto che siano invocati come root sul server.
È importante notare che per il corretto funzionamento della home sul
fuss-server è necessario non solo gestire un utente LDAP/Samba, ma anche il
relativo principal Kerberos, con la stessa password.
La creazione di un utente può essere realizzata con il comando:
smbldap-useradd -a -m nomeutente

a cui deve seguire l’impostazione di una password con il comando:
smbldap-passwd nomeutente

È quindi necessario impostare un principal Kerberos con la stessa password,
tramite il comando @kadmin.local@:
kadmin.local << EOF
addprinc user@DOMINIO.LAN
pwd
pwd
EOF

Si tenga presente che con questi comandi non viene impostato il valore
dell’attributo ou dell’utente che indica se questi è uno studente o un
docente. Lo si può impostare manualmente usando il comando:
ldapvi '(uid=username)'

che apre un editor con il contenuto in formato LDIF dei dati dell’utente;
aggiungendo la riga:
ou: studenti

agli attributi mostrati nell’editor si classificherà l’utente come studente.
Per cambiare la password dell’utente si può usare il comando visto sopra:
smbldap-passwd nomeutente

e successivamente aggiornare anche la password del principal Kerberos con
kadmin.local:
kadmin.local << EOF
cpw user@DOMINIO.LAN
newpw
newpw
EOF

Per la creazione di un gruppo di utenti si può utilizzare il comando:
smbldap-groupadd -a nomegruppo

per aggiungere un utente ad un gruppo si può utilizzare il comando:
smbldap-groupmod  -m nomeutente nomegruppo

mentre per toglierlo:
smbldap-groupmod  -x nomeutente nomegruppo

Per disabilitare temporaneamente un utente si può usare il comando:
smbldap-usermod -I nomeutente

e per riabilitarlo:
smbldap-usermod -J nomeutente

Il gruppo controllore
Nella creazione di un utente la sua home sarà creata con permessi 0700
(cioè accessibile soltanto a lui) assegnando all’utente la proprietà della
stessa, mentre per il gruppo proprietario verrà usato il gruppo preimpostato
Domain Users, si avrà cioè nel caso dell’esempio precedente:
root@fussserver:~# ls -ld /home/studente1
drwx------ 2 studente1 Domain Users 4096 lug 23 18:22 /home/studente1

è possibile però fornire accesso al contenuto della home agli utenti facenti
parte di un gruppo (detto per questo Gruppo controllore) da specificare nel
campo omonimo della pagina di gestione dell’utente (ad esempio il gruppo
docenti) cliccando sul quale si ottiene un menu a tendina sui gruppi
disponibile (sui quali viene effettuata automaticamente una ricerca su quanto
si scrive nel campo) da cui scegliere:

ed una volta impostato un gruppo controllore questo comparirà nella pagina
dell’utente:

ed i permessi della sua home verranno cambiati in 2770:
root@fussserver:~# ls -ld /home/studente1
drwxrws--- 2 studente1 docenti 4096 lug 23 18:22 /home/studente1

in questo modo il gruppo docenti avrà accesso in lettura e scrittura dei
contenuti, ed i nuovi file e le directory saranno assegnati al gruppo stesso
come gruppo proprietario.

Creazione utenti in massa
La funzionalità, prevalentemente fornita a scopo di test e per creare blocchi
di utenti temporanei (ad esempio per accessi da fornire a esterni in una prova
di esame) è accessibile dalla voce Creazione in massa del menu Utenti e
gruppi e richiede di immettere un prefisso ed un numero di utenti da creare:

gli utenti vengono creati ed automaticamente viene fatto scaricare un file
(mass-created-users-AAAA-MM-GG.csv) in cui viene fornito l’elenco degli
stessi e delle rispettive password che sono assegnata automaticamente.
Non esiste una funzionalità di cancellazione in massa, ma questa può essere
realizzata in maniera relativamente veloce usando octofussctl da riga di
comando con:
export OCTOFUSS_PASSWORD=password
echo ls users/users/test* \
  | octofussctl http://localhost:13400/conf -u root \
  | tail -n +2 | tr -d " />" \
  | sed -r 's|([a-z0-9]+)|delete users/users/\1|' \
  | octofussctl http://localhost:13400/conf -u root

che a differenza della cancellazione manuale con altri tool di gestione
utenti, effettua la cancellazione come se la si fosse fatta da OctoNet,
creando gli archivi con i file degli utenti.

Creazione utenti da file CSV
Una seconda funzionalità per creare in massa liste di utenti è quella
dell’importazione da file CSV, che consente di preparare una lista in un file
.csv.

Formato del file
Il formato CSV ha moltissime varianti, delle quali viene supportato un
limitato sottoinsieme, per questo alcune precauzioni nella creazione del file
CSV da usare per l’importazione, che deve avere queste caratteristiche:

Encoding: l’encoding del file deve essere ASCII o UTF-8 senza BOM. Il
BOM (Byte Order Mark)
abbiamo visto creare problemi. Si può verificare che l’encoding sia
corretto eseguendo il comando:
$ file nomedelfile.csv

e se il risultato è:
nomedelfile.csv: UTF-8 Unicode (with BOM) text, with CRLF line
terminators

bisognerà convertirlo in questo modo:
$ uconv nomedelfile.csv -t ASCII > nuovofile.csv

e si potrà poi verificare che nuovofile.csv avrà il corretto encoding:
nuovofile.csv: ASCII text, with CRLF line terminators

Campi testuali: i campi devono essere in formato alfanumerico evitando
caratteri di controllo come virgolette o apici, questo è necessario per
nomi di utenti e gruppi, ma si applica anche per i nomi e per le password,
per cui occorre limitare i caratteri di punteggiatura ed interpunzione.
Coerenza del numero di colonne:  Nel file tutte le righe dovranno avere
lo stesso numero di campi. Ad esempio qui si vede la prima riga che
contiene 4 campi, e la seconda 5:
Mario,Rossi,mariorossi,mariorossipassword
Lucia,Bianchi,luciabianchi,luciabianchipassword,campoaggiuntivo

e anche questo non andrà bene; si tenga conto anche che una riga vuota,
anche se messa in coda al file, viene considerata come con 0 campi (l’a
capo sull’ultima riga non conta, ma non ve ne devono essere altri) per cui
un file che ne contenga una non andrà bene per questo motivo).

Formato del file: Il file non dovrebbe avere la prima riga di
intestazione, ma tutte le righe dovrebbero essere relative agli utenti. Ad
esempio un file che inizia così:
Name,Surname,Username,Password
Mario,Rossi,mariorossi,mariorossipassword
Lucia,Bianchi,luciabianchi,luciabianchipassword

non va bene, e bisognerà cancellare la prima riga in modo che il file inizi
direttamente con le righe relative agli utenti. In questo caso il requisito
non è stringente, in quanto l’interfaccia di importazione consente di
escludere una eventuale riga di intestazione.

Dato che se il file da importare è molto grande esaminare la correttezza (in
particolare per il terzo requisito) non è banale, dal menu Utenti e gruppi ->
Verifica file CSV si può effettuare un controllo preventivo:

Dove viene richiesto di scegliere il file da controllare (si aprirà il
selettore di file del desktop) e la riga in cui si è inserito l’username
(verrà verificato che non vi siano doppioni), se ad esempio partiamo da un
con una riga vuota file come:
utente,tre,utente3,pippo,classe2
docente,due,docente2,pippo,docenti

docente,tre,docente3,pippo,docenti

occorrerà indicare la colonna con l’username con il numero 3, ma contenendo
questo una riga vuota otterremo:

invece avendo un file con un nome utente indicato due volte come:
utente,tre,utente3,pippo,classe2
docente,due,docente2,pippo,docenti
docente,tre,docente3,pippo,docenti
utente,quattro,utente4,pippo,classe1
studente,tre,studente3,pippo,classe1
studente,quattro,studente4,pippo,classe1
studente,cinque,studente5,pippo,classe1
studente,cinque,studente5,pippo,classe1

otterremo:

mentre se il file è corretto (mettendo studente6 nell’ultima riga)
otterremo:

venendo rediretti automaticamente nella pagina di importazione dei file CSV.
Questo controllo è importante perché l’importazione inserisce un utente alla
volta e si ferma in caso di errore, dopo di che non è immediato ricominciare
da dove ci si era fermati.

Prerequisiti
Il controllo su Utenti e gruppi -> Verifica file CSV effettua solo un
controllo di base di coerenza del contenuto del file, perché l’importazione
finale abbia successo sono necessari una serie di ulteriori requisiti:

Eventuali gruppi primari o gruppi controllore indicati nel file dovranno già
essere presenti nel sistema (bisognerà crearli prima sempre tramite
OctoNet). In caso ne mancassero, il sistema darà un messaggio di errore
senza importare nulla, per evitare import parziali. Questo non vale per i
gruppi secondari, che invece vengono creati nell’importazione.
Nessun utente elencato nel file CSV dovrà esistere sul sistema.
Nessuna directory home di quelle che si dovrebbero creare durante
l’importazione dovrà essere presente.

Si ricorda che per i professori, il gruppo primario a cui aggiungerli è
docenti, non insegnanti o professori o altro. Quindi questo dovrà
essere il gruppo primario indicato, per i professori, nel file CSV. Il nome è
fondamentale perché è sulla base del nome che il sistema capisce che si sta
trattando un docente e non uno studente.
Il file può contenere i seguenti campi (il nome campo fa riferimento al nome
usato nella interfaccia di importazione):

Nome campo
Formato

Nome
Nome (una parola)

Cognome
Cognome (una parola)

Nome completo
Nome e Cognome

Password
password (evitare virgole e caratteri CSV)

Nome utente
username (solo minuscole, eventuali numeri in coda)

Gruppo primario
nome di un gruppo (deve esistere)

Gruppo controllore
nome di un gruppo (deve esistere)

Gruppi secondari
nomi dei gruppi separati da spazi

Prefisso Home
pathname della directory dove andranno le home

Procedura di importazione
Per l’importazione degli utenti da un file CSV si deve usare la pagina Utenti
e gruppi -> Importa da CSV, che consente di selezionare un file dalla propria
macchina col pulsante Scegli file, si otterrà una visualizzazione della
tabella come la seguente:

A questo punto bisognerà selezionare le colonne che si desidera importare
semplicemente trascinando le celle di intestazione nella colonna desiderata
(dalle altre colonne o dalla lista di quelle non assegnate in fondo alla
tabella); se una colonna non si vuole o non si deve importare, si trascini la
relativa intestazione fuori dalla tabella e l’intestazione resterà
deselezionata.
L’interfaccia consente anche l’eliminazione delle prime righe del file
importato (solo a partire dall’inizio del file). Questo può risultare utile se
il CSV ha una riga di intestazione (come quello che si può ottenere dalla
conversione di un file .ldif). Per farlo occorre cliccare sulla riga
corrispondente che verrà barrata, un esempio è riportato nella seguente
immagine:

cliccando sulla riga successiva potrà essere esclusa anche quella, ricliccando
si rimuoverà l’esclusione (di nuovo funziona solo sull’ultima delle righe
escluse, la funzionalità di esclusione si applica solo all’inizio del file).
Il campo Nome completo non si può importare se viene usato in coincidenza
con Nome o Cognome, se si usano questi due campi viene creato
automaticamente unendoli.
È sempre obbligatorio selezionare la colonna Nome utente, se non lo si fa
l’importazione riporta un errore e non va avanti.
Se la colonna password non viene impostata gli utenti verranno creati senza
password (e non potranno accedere fintanto che non gli se ne imposta una). Una
volta finito si dovrà avere una situazione del tipo:

Una volta impostate le colonne si potrà premere Carica file e se tutto è
inizialmente corretto si dovrebbe vedere un popup che dice di non chiudere la
finestra e di attendere la fine del processo. Questo potrebbe durare diversi
minuti, o se si tratta di migliaia di utenti, anche ore (è un limite
intrinseco di LDAP).
Se tutto è stato importato correttamente, alla fine comparirà un bottone per
redirigere alla lista utenti, in cui si potrà verificare l’avvenuta
importazione.

Importazione da un file LDIF
Qualora si disponga dell’elenco utenti in formato LDIF (che può essere
ottenuto da un backup degli stessi, disponibile sotto /var/backups/slapd
se si è installato e configurato fuss-backup) è possibile eseguire una
conversione dello stesso usando il pulsante Converti file LDIF in alto a
destra. Si può comunque ottenere un file LDIF dall’istanza corrente con il
comando slapcat, con:
slapcat -v -l nome_del_file.ldif

In questo caso si dovrà scegliere un file .ldif con il pulsante Scegli
file e poi fargli generare il CSV premendo sul pulsante Genera file CSV,
questo verrà generato e fatto scaricare al browser, e si potrà andare sulla
pagina di importazione cliccando sul nuovo pulsante Importa il file
generato.
Si tenga presente che il file così generato conterrà delle password casuali
create da OctoNet, ed ha una riga di intestazione che deve essere rimossa
prima dell’importazione.

Gestione quote disco
La gestione delle quote disco può essere eseguita per il singolo utente dalla
sua pagina di gestione, o utilizzando direttamente l’interfaccia di gestione
che compare nel menu alla voce Quote disco sulla colonna di destra di
OctoNet. Cliccando sulla stessa si verrà portati su una pagina che elenca i
filesystem disponibili:

Si tenga conto che la funzionalità è presente soltanto se le quote disco sono
attive e configurate. Nella installazione ordinaria del Fuss Server questo
viene fatto per la directory /home solo se questa è montata su un
filesystem separato.
Le quote disco infatti sono applicabili solo a livello di filesystem e non per
le singole directory. Questo significa anche, se i dati sono distribuiti su
più filesystem, che non possono essere applicate in forma «globale» per un
totale generico ma possono essere impostate solo per ciascuno filesystem in
maniera del tutto indipendente.
La pagina prima elenca i filesystem disponibili indicando rispettivi mount
point e la relativa occupazione di spazio disco, e ripete in fondo quelli per
i quali sono abilitate le quote disco. La scelta di Fuss Server è abilitarle
solo per le home, dato che è solo li che han senso, applicandosi ai dati
degli utenti. Si tenga presente che se si è installato il  Fuss Server
usando solo il filesystem radice, esse non saranno attive.
Benché sia possibile cliccare su tutti i filesystem si otterrà una lista delle
quote solo per quelli su cui queste sono abilitate, nel caso precedente
home, per cui si otterrà:

Le quote disponibili sono di due tipi, le quote utente (che valgono per il
singolo utente) e le quote gruppo (applicate ai file di un gruppo), ed hanno
due limiti, soft ed hard. Il primo può essere superato per un periodo di
tempo limitato (il grace time, che di default vale una settimana) passato il
quale verrà applicato, il secondo viene applicato immediatamente. Le quote
utente e quelle gruppo sono indipendenti.
Inoltre le quote sono suddivise per spazio disco (Quota disco) e per numero
di file (Quota file), ed anche queste sono indipendenti l’una dall’altra, si
può cioè superare la quota sia perché si è finito lo spazio disco, o perché si
è esaurito il numero di file (per cui non si potranno creare nuovi file, ma si
potranno allargare quelli esistenti).
La pagina presenta di default le quote utente, si può passare a quelle gruppo
cliccando sulla linguetta corrispondente. Vengono visualizzati un numero fisso
di utenti o gruppi selezionabili con il menu a tendina Visualizza e si può
effettuare la ricerca di un utente/gruppo specifico con Cerca.
Per modificare uno dei valori delle quote si faccia un doppio click sulla
stessa, e comparirà una finestra di immissione, si dovrà specificare una
dimensione in kilobytes per le Quota disco ed un numero per le Quota file
e poi salvarlo; si tenga conto che occorre sempre indicare per le quote soft
un valore inferiore che per le hard.

Come accennato si possono impostare anche le quote nella pagina di gestione
del singolo utente, nella sezione finale della pagina di modifica dello
stesso:

Gestione hosts
Il Fuss Server è in grado di gestire in maniera centralizzata i client
facenti parte di una rete scolastica, utilizzando le funzionalità presenti
nella sezione Hosts del menu sulla colonna di destra.

Gestione del DHCP
Si può accedere alle pagine di gestione del DHCP dalla voce Leases DHCP che
porta automaticamente sulla pagina che elenca lo stato attuale dei leases
(vale a dire delle assegnazioni MAC Address/Indirizzo IP) presenti sul server,
e fa comparire nella barra in alto il menu Leases DHCP sulla sinistra.

alla stessa pagina si può tornare da una qualunque delle altre della sezione
usando il link Leases DHCP serviti dal menu Leases DHCP.
Si ricordi che in fase di installazione del Fuss Server una delle richieste
effettuate da fuss-server create è quella dell’indicazione dell’intervallo
di indirizzi IP da assegnare dinamicamente, che viene memorizzato nel file di
configurazione fuss-server.yaml, nella variabile dhcp_range; lo si
potrà pertanto ottenere con il comando:
grep dhcp_range /etc/fuss-server/fuss-server.yaml

La pagina illustrata è solo informativa e ci dice quali assegnazioni dinamiche
sono state effettuate; è possibile però impostare anche delle assegnazioni
statiche (le cosiddette «reservation») usando dal menù la voce Crea
assegnazione statica, che porta sulla relativa pagina di immissione:

ed in questo modo si possono controllare gli indirizzi assegnati alle singole
macchine attraverso il DHCP (la cosa può essere utile ad esempio per assegnare
IP fissi ad apparati di rete come le stampanti in modo da poterne gestire
l’accesso in maniera centralizzata). In genere non è opportuno utilizzare
questa assegnazione per i client, che vengono gestiti direttamente dal server,
ma solo per macchine ed apparati esterni.
La pagina richieda che si immetta un nome che identifichi l’apparato, il MAC
address della sua scheda di rete e l’indirizzo IP che si vuole gli venga
assegnato.  É opportuno che quest’ultimo sia fuori dall’intervallo di IP
dinamici identificato in precedenza. L’impostazione verrà salvata nel file
/etc/dhcp/dhcp-reservations.
Si tenga conto che se l’apparato è impostato per ricevere l’indirizzo in DHCP,
questo verrà assegnato dinamicamente una volta accesso, ed anche se poi si
effettua una assegnazione statica, questa non verrà effettuata fintanto che il
precedente lease non scade. Per questo per rendere effettiva l’assegnazione
statica occorre in genere riavviare l’apparato (o forzare la nuova richiesta
di un indirizzo IP, se esiste una funzionalità per farlo).
Eseguita l’assegnazione si verrà portati nella pagina che elenca le
assegnazioni effettuate, a cui si può accedere anche direttamente dal menu
Leases DHCP con la voce Assegnazione statica DHCP:

da questa pagina si potranno gestire anche le assegnazione presenti
cancellandole col pulsante Elimina (verrà chiesto conferma in una finestra di
pop-up) o modificandole con il pulsante Modifica, nel qual caso si verrà
riportati nella pagine di impostazione dell’assegnazione statica, potendo però
modificare solo i campi relativi al MAC address ed all’indirizzo IP (per la
modifica del nome è necessario fare una cancellazione ed una creazione da
capo).

Gestione cluster
Il Fuss Server consente una gestione più dettagliata di tutti i client che
vengono registrati sul server con una join, quando su di essi si esegue
fuss-client -a. In quella fase si può chiedere di inserire il client in un
cluster, che consente di raggruppare gruppi di client.
L’elenco dei computer gestiti dal Fuss Server si ottiene selezionando la
voce Computer gestiti dal menu della colonna di destra, che porta sulla
pagina degli host gestiti, e rende inoltre disponibile il menu Computer
gestiti nella barra superiore.

La pagina mostra l’elenco dei client registrati sul Fuss Server (ed è
inizialmente vuota) in una tabella dove viene mostrato un eventuale utente
collegato sulla macchina e lo stato della stessa (se accesa o spenta) e dello
schermo (se bloccato o sbloccato).
Si tenga presente che l’elenco fa riferimento a tutti i computer che sono
stati registrati, anche se questi non sono più presenti. Si potrà tornare
sulla lista selezionato dal menu Computer gestiti la voce Tutti gli host.
É anche possibile ottenere una lista di computer che sono stati osservati
sulla rete (grazie al servizio Avahi) usando la voce del menu Nuovi
computer ma si tenga conto che questa pagine contiene una lista di tutti i
computer osservati, non solo quelli presenti sulla rete interna su cui sono
posizionati i client.

Come accennato quando si esegue fuss-client -a su un client questo viene
agganciato al server, se sul server è presente un cluster, questo verrà
automaticamente selezionato, e se ne sono presenti più di uno verrà richiesta
la scelta di quale cluster utilizzare. Se non ne è presente nessuno verrà
usato come default None ed un cluster con questo nome verrà
automaticamente creato.
Pertanto è in genere opportuno creare i cluster sul server prima di eseguire
la join dei client, in modo che questo possa selezionare in quale essere
incluso all’esecuzione di fuss-client -a, per farlo si deve selezionare
dal menu Computer gestiti nella barra superiore la voce Crea nuovo cluster
che porterà nella pagina di creazione:

dove si potrà creare un cluster immettendo il nome nella casella Nome
cluster, si tenga conto che il nome non deve contenere spazi ed per
semplicità utilizzare solo lettere minuscole e numeri. Una volta creato si
verrà rediretti automaticamente nella pagina di gestione del cluster:

e lo stesso apparirà nel menu Computer gestiti nella barra superiore, e lo
si potrà selezionare per arrivare alla relativa pagina:

ottenendo:

Premendo sul pulsante Dettagli cluster si può poi passare alla pagina di
gestione delle macchine del cluster, da cui si possono effettuare diverse
operazioni sulle macchine che ne fanno parte.

Da questa con il pulsante Shutdown now si possono spegnere tutte le macchine
del cluster, con il pulsante Disable internet si blocca l’accesso ad
Internet delle stesse (viene creata una opportuna regola di firewall) e con il
pulsante Lock screen si blocca lo schermo degli utenti collegati. È inoltre
possibile inviare un messaggio agli utenti collegati (da inserire nel campo
Message to send) con il pulsante Send a message e indicare un pacchetto da
installare (da inserire nel campo Package to install) con il pulsante
Install software.
Infine si può inserire nel cluster un nuovo client usando il pulsante Create
new computer, scrivendone il nome nel campo Name of the new computer.

Gestione manuale del cluster
I dati dei cluster sono mantenuti sul Fuss Server nel file /etc/clusters
il cui formato è nella forma di una riga per cluster di macchine, con campi
separati da spaziature, in cui il primo campo, quello ad inizio riga, indica
il nome del cluster, ed i successivi i nomi dei client che ne fanno parte.
Si tenga presente che nel collegamento ordinario al server i client vengono
identificati solo per hostname (con il nome singolo, non l’FQDN completo), ma
questo avviene con le versioni più recenti del client, che hanno introdotto il
supporto per la normalizzazione dei nomi e la capacità di cambiare al volo
l’hostname di una macchina prima di effettuare il collegamento.
Se si deve intervenire manualmente su questo file occorre avere alcune
accortezze, infatti il suo contenuto viene letto da octofussd all’avvio,
ed aggiornato coerentemente fintanto che si usa OctoNet o si aggiungono i
client con fuss-client, ma se si opera manualmente su /etc/clusters
occorre forzare la rilettura con service octofussd restart.
Qualora si voglia creare manualmente il file si possono utilizzare i dati
raccolti grazie al servizio DHCP, per questo però è necessario che tutti i pc
che devono essere inseriti nel cluster siano accesi. In tal caso è possibile
visualizzare a schermo tutte le macchine accese con il comando:
host -l “nome dominio.local”

e da questa lista si può creare il file /etc/clusters eseguendo (sempre
dalla console del server) il comando:
host -l “nome dominio.local” \
| cut -d “.” -f 1 \
| head -n -1 \
| sort \
| tr '\n' ' ' >> /etc/clusters

In alternativa possiamo estrarre, piuttosto che i nomi dei client, gli IP
consegnati dal server DHCP (utile quando sulle postazioni clienti non è ancora
installato fuss-client che configura dhclient per far si che i nomi
dei clienti siano presenti sul DNS) in questo modo:
grep lease /var/lib/dhcp/dhcpd.leases  \
| head -n -8 \
| cut -d " " -f 2 \
| sort | uniq \
| tr '\n' ' ' >> /etc/clusters

Si possono utilizzare i dati di definizione del cluster direttamente dalla
console del server con il comando:
cssh nomecluster

oppure da una postazione client, mi devo però prima collegare al server con:
ssh -X root@server

oppure:
ssh -X server -l root

e avvio cssh:
cssh nomecluster

Gestione degli host
Oltre alla gestione generale dei client che fanno parte di un cluster, si
possono pianificare operazioni per le singole macchine. Si può accedere a
queste operazioni cliccando sul link di una macchina dalla pagine Tutti gli
host (o da quella di un cluster di cui la macchina fa parte), che porta sulla
pagina dell’host richiesto:

Nella pagina vengono riportate le Azioni possibili sulla parte destra;
alcune di queste (Shutdown now, Disable internet, Lock desktop, Send a
message, Install software) sono le stesse già viste per le macchine di un
cluster in Gestione cluster; a queste si aggiungono la possibilità di
inserire la macchina in un cluster (da selezionare dal menu a tendina Add to
cluster) con il pulsante Add to cluster e quella di rimuoverla da un
cluster con (da selezionare dal menu a tendina Remove from cluster) con il
pulsante Remove from cluster.
Infine è possibile aggiungere la macchina ad un aggiornamento pianificato (che
deve essere creato in precedenza, vedi Gestione aggiornamenti) selezionando
lo stesso dal dal menu a tendina Add to upgrade con il pulsante Add to
upgrade, o pianificare l’esecuzione di uno degli script di gestione inseriti
sulla piattaforma (anche questo deve essere creato in precedenza, vedi
Gestione script) di nuovo da selezionare dal tendina Add to script run
con il pulsante Add to script run.

Gestione aggiornamenti
Per la gestione degli aggiornamenti delle macchine collegate al Fuss Server
si possono impostare dei job di aggiornamento usando la voce Gestione
Aggiornamenti dal menu delle operazioni di destra.

Questo porta nella pagina che elenca i lavori impostati, da cui è possibile
impostare un nuovo aggiornamento nella sezione Crea nuovo aggiornamento,
indicandone un nome nella casella di testo e cliccando sull’adiacente pulsante
Crea, che ci porterà nella pagina di impostazione dello stesso.

Dalla pagina si potrà selezionare il tipo di aggiornamento dalla casella Tipo
aggiornamento (con le due possibilità Aggiornamento pacchetti e
Aggiornamento distribuzione che corrispondono all’esecuzione di apt-get
upgrade e apt-get dist-upgrade) e selezionare le macchine da inserire
nell’aggiornamento o singolarmente dalla casella Aggiungi host o per cluster
dalla casella Aggiungi gruppo.
Finanto che non si inserisce almeno una macchina nell’aggiornamento non
compare il pulsante verde Programma che consente di programmare
l’operazione, che invece può essere cancellata in qualunque momento con il
pulsante rosso Elimina. Una volta inserita una macchina nell’aggiornamento
questa apparirà nella lista sulla destra, affiancata da un pulsante Rimuovi
che consente di toglierla dall’aggiornamento.
Quando si è finito di inserire le macchine volute nell’aggiornamento lo si
potrà programmare con il pulsante Programma, da quel momento non sarà più
modificabile.

Gestione script
Dalla pagina principale di Octonet si clicchi in basso a destra
sulla voce Gestore Script .
Ci si trova nella pagina con la Lista degli scripts .

Si clicchi sul pulsante Programma posto a destra dello script prescelto.

Dopo aver assegnato un Nome si clicchi sul pulsante Crea una nuova
esecuzione .
Si clicchi sul nome dell’Esecuzione appena creata.

A questo punto si devono aggiungere gli hosts o i gruppi (cluster)
inserendoli negli appositi campi e cliccando volta per volta sul
pulsante Conferma .
Infine si lanci lo script cliccando sul pulsante nero Programma . Si
tenga presente che che lo script non viene lanciato istantaneamente ma
in genere passano alcuni minuti.

Terminata l’esecuzione, essa può essere eliminata cliccando sul tasto
rosso Elimina.

Gestione filtri web
Tramite la voce Rete → Filtro Web nella barra laterale si accede
alla pagina di gestione dei filtri sui contenuti per la navigazione,
abilitandone il relativo menù nella barra superiore.

Le voci di menù presenti corrispondono ai file di configurazione del
programma che gestisce le regole di navigazione, documentati in
dettaglio nell’apposita sezione e2guardian (filtro contenuti)
della guida.
Le varie pagine contengono un elenco di voci, per ciascuna delle quali è
disponibile il campo Descrizione tramite il quale fornire dei commenti
sulla voce e sul motivo per cui è stata inserita.
La prima voce del menù, allowed_sites permette di gestire l’elenco di
domini ai quali è sempre consentito accedere, indipendentemente da divieti
imposti.
Il file corrispondente è /etc/fuss-server/content-filter-allowed-sites.

banned_extensions è un elenco di estensioni di file ai quali è
proibito l’accesso.
Il file corrispondente è /etc/dansguardian/lists/bannedextensionlist.

banned_sites è un’elenco di domini ai quali l’accesso è sempre proibito.
Il file corrispondente è /etc/dansguardian/lists/bannedsitelist.

Ed infine, config permette di modificare la configurazione di
dansguardian stesso; in questo caso il campo Descrizione contiene il
valore del parametro di configurazione corrispondente.
Il file corrispondente è /etc/dansguardian/dansguardianf1.conf.

Modifiche ai filtri web

I campi delle pagine appena viste sono modificabili, oppure svuotabili
premendo il tasto x rosso corrispondente; nuove voci possono essere
aggiunte nelle cinque righe vuote presenti in fondo alla pagina.
Perché le modifiche vengano scritte sui file di configurazione è poi
necessario premere il tasto Salva, e alla fine riavviare il servizio
dalla pagina principale di questa sezione perché diventino attive.

Gestione firewall
Tramite la voce Rete → Firewall nella barra laterale si accede alla
pagina di gestione del firewall, abilitandone il relativo menù nella
barra superiore.

Le voci di menù presenti corrispondono ai file di configurazione del
programma che gestisce le regole di navigazione, documentati in
dettaglio nell’apposita sezione Firewall
della guida.
Le varie pagine contengono un elenco di voci, per ciascuna delle quali è
disponibile il campo Descrizione tramite il quale fornire dei commenti
sulla voce e sul motivo per cui è stata inserita.
Host senza accesso corrisponde al file
/etc/fuss-server/firewall-denied-lan-hosts

Host con accesso completo corrisponde al file
/etc/fuss-server/firewall-allowed-lan-hosts

Destinazioni consentite corrisponde al file
/etc/fuss-server/firewall-allowed-wan-hosts

Servizi consentiti corrisponde al file
/etc/fuss-server/firewall-allowed-wan-services

Servizi offerti all’esterno corrisponde al file
/etc/fuss-server/firewall-external-services

Host/servizi consentiti corrisponde al file
/etc/fuss-server/firewall-allowed-wan-host-services

Nota
Eventuali regole iptables custom non possono essere configurate da
OctoNet ma solo modificando sul server il file
/etc/fuss-server/firewall-custom-rules (con le dovute
attenzioni) riavviando subito dopo il firewall (si faccia
riferimento alla sezione Firewall).

Modifiche al firewall
I campi delle pagine appena viste sono modificabili, oppure svuotabili
premendo il tasto x rosso corrispondente; nuove voci possono essere
aggiunte nelle due righe vuote presenti in fondo alla pagina.
Perché le modifiche vengano scritte sui file di configurazione è poi
necessario premere il tasto Salva, e alla fine riavviare il servizio
dalla pagina principale di questa sezione perché diventino attive.

Stampanti di rete
La sezione Rete → Stampanti di rete permette di gestire le stampanti
condivise.
La pagina principale della sezione presenta l’elenco delle stampanti
disponibili (ovvero «code di stampa»), con link alla relativa pagina di
configurazione, ed un pulsante che permette di raggiungere la pagina di
configurazione di CUPS, il servizio di gestione delle stampanti.

L’accesso a CUPS è consentito a root, oppure agli utenti del gruppo
lpadmin.

Avvertimento
Se si sta accedendo ad OctoNet da un computer diverso dal server,
tramite tunnel SSH, il link Configura stampanti e code punterà
all’interfaccia CUPS della macchina da cui si sta accedendo (se
installato) e non del server.
Per accedere all’interfaccia CUPS del server si può creare un secondo
tunnel ssh col comando:
ssh sshuser@proxy -L 13631:localhost:631

e dopo aver aperto Configura stampanti e code correggere
manualmente l’indirizzo perché punti a http://localhost:13631/

Nella pagina di modifica di una coda di stampa si trova l’elenco degli
host della rete locale abilitati ad accedere, con la possibilità di
rimuovere host individuali dall’elenco, aggiungerne (Aggiungi host alla
coda) oppure aggiungere con un click solo tutti gli host facenti parte
di un cluster (Aggiungi gruppo di host alla coda).

Aggiunta di una stampante
Per aggiungere una nuova stampante è innanzitutto necessario
configurarla su CUPS: dall’interfaccia relativa selezionare CUPS for
Administrators → Adding Printers and Classes:

Quindi premere il tasto Add Printer nella sezione Printers,
autenticandosi con un utente che sia nel gruppo lpadmin sul server.

Suggerimento
Alcuni modelli di stampante richiedono passi aggiuntivi per la loro
installazione in CUPS; per questi si veda la miniguida
Gestione e installazione di stampanti e scanner.

Si otterrà una pagina con la scelta di che tipo di stampante
aggiungere; nel caso siano già state trovate stampanti locali o di rete
queste verranno presentate in Local Printers o Discovered Network
Printers rispettivamente:

Selezionando una stampante che sia stata già riconosciuta, verranno
richieste un nome (che non può contenere i caratteri /, # né
spazio), una descrizione ed una posizione fisica da visualizzare agli
utenti; inoltre viene richiesto se condividere la stampante (Share This
Printer):

Premendo su Continue si raggiunge la schermata successiva, in cui si
seleziona il driver da usare per la stampante indicando dapprima il
produttore:

e, dopo aver premuto Continue il modello:

Premendo Add Printer la stampante viene aggiunta e si viene portati ad
una pagina dove è possibile cambiare le sue impostazioni di default:

A questo punto si può ricaricare la pagina delle stampanti di rete di
octonet, dove sarà apparsa la stampante appena aggiunta:

E tramite Modifica Host si possono abilitare host ad usarla,
completando così la configurazione della nuova stampante:

Share Samba

Creazione di uno share
Per creare uno share samba:

predisporre la directory sul filesystem, ad esempio in una
sottodirectory di /home/SAMBA:
# mkdir /home/SAMBA/<nome_share>

ed assegnarle permessi opportuni perché gli utenti possano accedervi;
ad esempio per creare una share scrivibile dai docenti:
# chgrp docenti /home/SAMBA/<nome_share>
# chmod 775 /home/SAMBA/<nome_share>

via octonet, andare sulla creazione di un nuovo share:

Cartelle Condivise → Servizio Samba nel menù laterale;
Cartelle Condivise → Crea Cartella Condivisa nel menù in alto;

(si aprirà la pagina all’indirizzo /samba/create)

indicare:

nome dello share
path assoluto
eventuali parametri di accesso (guest, gruppi di utenti con accesso
in lettura, in scrittura etc)

Avvertimento
I nomi degli share samba devono essere composti solo da lettere
minuscole per evitare errori nell’uso successivo.
Le versioni più recenti di octonet impediscono l’inserimento di
caratteri diversi nel nome dello share.

Test di uno share
Usare un client samba qualsiasi per provare le shares.

Da riga di comando
Ad esempio, con smbclient da riga di comando, installato su un
fuss-client, si possono elencare le share disponibili sul server (e
visibili all’utente in uso) con:
$ smbclient -L proxy

e ci si può collegare con:
$ smbclient \\\\proxy\\<nome della share>

usare ls per vedere i file presenti, quit per uscire, help
per vedere gli altri comandi disponibili.

Con Thunar (Gestore dei File grafico)
Il Gestore dei File dei fuss-client è capace di accedere alle share
samba; si può quindi usare per testarne la configurazione.
Nella colonna laterale selezionare “Esplora la rete”, quindi aprire
“Rete Windows” e le successive cartelle fino ad arrivare alla share
desiderata.

Inserire la password di un utente opportuno per verificare la corretta
visibilità della share.

Gestione delle classi

Premessa
Per una gestione ordinata delle home si consiglia di organizzare
l’albero delle home separando secondo la gerarchia:

plesso o ordine di scuola;
docenti o alunni;
classe (solo per gli alunni).

Ad esempio le home dei  docenti di una scuola media potranno essere in:
/home/media/docenti/

Gli alunni di una classe della primaria (poniamo 2c) saranno invece ad
esempio in:
/home/primaria/alunni/classe-2c-ele

Per facilitare la gestione delle classi, come ad esempio eliminare
agevolmente le classi in uscita, si raccomanda di attribuire un gruppo
secondario corrispondente. Nel caso precedente gli alunni
apparterrebbero quindi al gruppo 2c-ele.
Naturalmente si possono scegliere denominazioni di classi e gruppi
diversi, purchè siano coerenti ed omogenee nello stesso plesso.
L’esecuzione dello script prevede che, come auspicabile, tutti gli
alunni di uno stesso plesso appartengano allo stesso gruppo
primario. Diversamente bisognerà adattarlo alla situazione specifica o
lanciarlo, ad esempio, per gruppi più piccoli.

Spostamento delle classi da un anno all’altro

Lo script
L’anno successivo chiaramente le classi ed i gruppi cambieranno (ad
esempio la classe classe-2c-ele diventerà classe-3c-ele ed il
gruppo 2c-ele diventerà 3c-ele.
La procedura di spostamento viene affidata ad uno script e richiede solo
una particolare attenzione nel predisporre i due file csv letti dallo
script stesso.
Ovviamente si raccomanda di analizzare bene lo script per capire
esattamente quello che esegue. In caso di dubbi rivolgersi a
info@fuss.bz.it:
#! /bin/bash
# Creiamo innanzitutto una copia di ldap
# LDAP save
slapcat -l ldap-dump.ldif

### LDAP restore in caso di problemi
#systemctl stop slapd
#echo "Restoring LDAP"
#rm -rf /var/lib/ldap/*
#slapadd < $BASE/ldap-dump.ldif
#chown openldap:openldap /var/lib/ldap/*
#systemctl start slapd

# Decommentare le seguenti due righe e si commenti la successiva se
# si intende procedere in modo interattivo

#echo "Qual è il gruppo primario degli utenti da spostare?"
#read GRUPPO_PRIMARIO

#Sostituire ad alunni-ele il gruppo primario degli alunni delle
# classi da spostare
GRUPPO_PRIMARIO=alunni-ele
echo "Gruppo primario: $GRUPPO_PRIMARIO"
MEMBRI=`members -p $GRUPPO_PRIMARIO`
echo "Membri: $MEMBRI"

# Nella seguente parte dello script viene letto il file csv con il
# nome vecchio e quello nuovo della classe. Le classi in uscita
# vengono spostate in classi inesistenti (ad esempio IV media, VI
# elementare o superiore)
# Viene effettuato un controllo per evitare che una classe
# sovrascriva l'altra se il csv è stato elaborato male, ma si rischia
# di spostare solo una parte delle classi.
# In questo caso è preferibile ripristinare la situazione iniziale,
# sistemare il file csv e riclanciare lo script.

while IFS=, read -r OLDHOME NEWHOME
do
    if [ ! -d "$NEWHOME" ]
    then
        echo $NEWHOME
        mv $OLDHOME $NEWHOME
    else
        echo "Controlla l'ordine delle classi nel csv!"
        exit
    fi
done < classi_mapping.csv

# Con il codice  seguente si effettua lo stesso spostamento delle
# classi nell'albero ldap; in caso di errori si esegua il restore di
# ldap commentato ad inizio script

declare -A classi; while IFS=, read -r OLDHOME NEWHOME ; do classi[$OLDHOME]=$NEWHOME ; done < classi_mapping.csv

for i in `members -p $GRUPPO_PRIMARIO`
do
    home=`smbldap-usershow $i |grep homeDirectory|awk '{print $2}'`

    echo $home

    home_tr=${home/"/"$i/}

    echo $home_tr

    home_mod=${classi[$home_tr]}

    echo $home_mod

    smbldap-usermod -d $home_mod"/"$i $i

done

# Infine, se esistono gruppi_classe, col seguente comando è possibile
# aggiornarli da un anno all'altro leggendo i dati da un csv.
# !!! Attenzione!!! Per rinominare un gruppo è necessario che il
# nuovo gruppo non esista già, per cui il file csv va eventualmente
# preparato con numeri decrescenti dall'alto in basso!

while IFS=, read -r OLDGROUP NEWGROUP ; do smbldap-groupmod -n $NEWGROUP $OLDGROUP; done < group_mapping.csv

I file csv
Ecco un esempio di csv (classi_mapping.csv) per lo spostamento delle
classi.
Come si può vedere il csv è formato da due colonne separate da una virgola:

la colonna di sinistra contiene le classi «vecchie» e quella di destra
le classi «nuove»;
si noti che le classi sono in ordine decrescente dal basso all’alto;
si presti particolare cura nella preparazione del csv:
/home/primaria/alunni/classe-5b-ele,/home/primaria/alunni/classe-6b-ele
/home/primaria/alunni/classe-5a-ele,/home/primaria/alunni/classe-6a-ele
/home/primaria/alunni/classe-4b-ele,/home/primaria/alunni/classe-5b-ele
/home/primaria/alunni/classe-4a-ele,/home/primaria/alunni/classe-5a-ele
/home/primaria/alunni/classe-3b-ele,/home/primaria/alunni/classe-4b-ele
/home/primaria/alunni/classe-3a-ele,/home/primaria/alunni/classe-4a-ele
/home/primaria/alunni/classe-2b-ele,/home/primaria/alunni/classe-3b-ele
/home/primaria/alunni/classe-2a-ele,/home/primaria/alunni/classe-3a-ele
/home/primaria/alunni/classe-1b-ele,/home/primaria/alunni/classe-2b-ele
/home/primaria/alunni/classe-1a-ele,/home/primaria/alunni/classe-2a-ele

Il seguente file (group_mapping.csv) è un esempio di csv per lo
spostamento degli alunni delle classi da un gruppo a quello successivo.
Viene letto nella stessa maniera di quello precedente. Se il gruppo
nuovo esiste già, lo spostamento non avviene, per cui si deve sempre
procedere in ordine decrescente dall’alto al basso, accertandosi che i
gruppi più alti (nel nostro caso classe-6…) non esistano, ed
eventualmente eliminarli.
5b-ele,6b-ele
5a-ele,6a-ele
4b-ele,5b-ele
4a-ele,5a-ele
3b-ele,4b-ele
3a-ele,4a-ele
2b-ele,3b-ele
2a-ele,3a-ele
1b-ele,2b-ele
1a-ele,2a-ele

Conclusioni
La procedura descritta è necessaria per mantenere in ordine la
disposizione delle classi come illustrata, ma può essere utile anche per
sanare alberi delle home poco ordinati o nomi poco chiari per alunni e
docenti, come 2019a per indicare la classe-4a. Il tutto richiede
poco tempo e solo una certa attenzione, ribadiamo, nella predisposizione
dei file csv.

Fuss Manager
Fuss-manager è la nuova interfaccia di gestione delle aule che si
affianca e progressivamente sostituirà octonet.
Questa pagina ne documenterà l’uso.

Installazioni specializzate
Si tratteranno in questa sezione una serie di casi speciali per
l’installazione del Fuss Server, non coperti dall’installazione ordinaria
vista nella sezione Installazione di FUSS server tradizionale

Installazione di Debian su RAID software

Preparazione della macchina
A volte è possibile che nell’installazione non venga riconosciuto il
controller RAID del server (o che questo sia in realtà un fake raid) e che quindi sia
necessario usare i dischi come singoli senza la configurazione RAID del
BIOS. Questo ad esempio è quanto successo con un server Fujitsu PRIMERGY TX1320
M1 con 2 hard disk da 1 Tb ciascuno in RAID1 (mirroring).
Occorre in questo caso fare in modo tramite il BIOS del controller RAID che
gli HD siano semplicemente nello stato «READY» ed eventualmente nel BIOS del
server (se possibile) disattivare il Controller_RAID.
Occorre pertanto, nel caso del Fujitsu PRIMERGY TX1320 M1, entrare nel BIOS
all’avvio con F2, dopo di che dal BIOS eseguire i seguenti passi:

Selezionare Advanced
Selezionare SATA Configuration
Selezionare SATA Mode [AHCI MODE]
Premere F4 (Save and Exit) oppure selezionare da menù «Save and Exit»

Partizionamento dei dischi
Una volta avviata la macchina con il CD/DVD/Chiavetta USB di
installazione di Debian Buster (si prenda l’ultima versione
disponibile) ed arrivati alla schermata di
«Partizionamento dei dischi» si proceda selezionando «Manuale».

Comparirà l’elenco dei dischi (in genere sda e sdb), e al di sotto di
ciascuno di essi, se sono presenti, quella delle eventuali partizioni.

Che le partizioni siano presenti o meno occorrerà comunque posizionarsi sulla
riga che elenca il disco e selezionarlo con invio, cosa che porterà alla
richiesta di creare una nuova tabella delle partizioni, cui occorre rispondere
di si (se vi sono partizioni preesistenti saranno cancellate).

A questo punto selezionando la voce «SPAZIO LIBERO» che comparirà sotto al
disco si potrà procedere al partizionamento premendo invio, e scegliendo «Crea
una nuova partizione».

Verrà poi chiesta la dimensione della stessa. La prima partizione servirà per
installarvi il RAID1 che ospiterà /boot e le sue dimensioni possono essere
fra i 512 Mb ed 1Gb, per cui inseriremo ad esempio «1 Gb», verranno poi
chiesti: il tipo della partizione e va scelto «Primaria», la posizione della
nuova partizione e va scelto «Inizio», ed infine le modalità di uso.

Qui premendo invio sul valore di default (in genere «File system ext4
con Journaling») occorre selezionare nel menu seguente «Volume fisico
per il RAID», e ottenuta la scelta posizonarsi in fondo alla schermata
su «Impostazione della partizione completata» e premere invio.

La sequenza per la prima partizione pertanto è:

Posizionarsi sul disco (es: sda )
Creare una nuova tabella delle partizioni vuota su questo dispositivo?  <Si>
Posizionarsi sullo spazio libero
Creare una nuova partizione
1 GB
Primaria;
Inizio;
Usare come:    Volume fisico per il RAID
Impostazioni della Partizione completata

L’operazione va ripetuta in maniera analoga per creare una seconda
partizione sullo spazio libero restante, lo si dovrà di nuovo
selezionare sulla riga successiva, e ripetere le stesse operazioni della
volta precedente accettando stavolta la dimensione proposta per la
partizione (e riselezionando la nuova partizione come primaria, rispetto
al default presentato di logica), si avrà pertanto la sequenza:

Posizionarsi sullo spazio libero
Creare una nuova partizione
999 GB (accettare quanto proposto)
Primaria;
Inizio;
Usare come:    Volume fisico per il RAID
Impostazioni della Partizione completata

Una volta completato il partizionamento del primo disco le operazioni
dovranno essere ripetute sul secondo disco (ad esempio sdb), avendo cura
di indicare esattamente le stesse dimensioni: è sufficiente indicare le
stesse per la prima partizione, la seconda con il default prende tutto
il resto del disco e sarà uguale in caso di dischi identici (eventuali
piccole differenze in caso di dischi diversi lasceranno inutilizzata la
parte eccedente di quello più grande).

Configurare il RAID software
Una volta completato il partizionamento, come illustrato nella figura
seguente, si potrà passare alla configurazione del RAID software
selezionando la seconda voce del menu.

Verrà richiesto di scrivere i cambiamenti sui dischi, e poi si potrà passare
alla configurazione del raid scegliendo «Creare un device multidisk», e poi il
tipo di raid, che deve essere RAID1.

Verranno poi chiesti il numero di device attivi (accettare il default di 2) e
quello dei device di riserva (spare, accettare il default di 0), dopo di che
si potranno selezionare i dispositivi che compongono il RAID scegliendo la
prima partizione di entrambi i dischi:

Si avrà pertanto la sequenza:

Alla richiesta «Scrivere i cambiamenti sui dispositivi di memorizzazione e
configurare il RAID?» selezionare «Si»
Selezionare «Creare un device multidisk (MD)»
Selezionare RAID1 dal menu seguente
Alla richiesta «Numero device attivi per l’array RAID1:» lasciare il default
di 2
Alla richiesta «Numero dei device spare per l’array RAID1:» lasciare il
default di 0
Alla richiesta Device attivi per l’array RAID1 selezionare /dev/sda1 e
/dev/sdb1

Si dovrà poi ripetere la sequenza per creare il secondo RAID1 che sarà usato
per LVM, ripetendo le scelte precedenti e selezionando alla fine le due
partizioni restanti.

La seconda sequenza sarà pertanto:

Selezionare «Creare un device multidisk (MD)»
Selezionare RAID1 dal menu seguente
Alla richiesta «Numero device attivi per l’array RAID1:» lasciare il default
di 2
Alla richiesta «Numero dei device spare per l’array RAID1:» lasciare il
default di 0
Alla richiesta Device attivi per l’array RAID1 selezionare /dev/sda2 e
/dev/sdb2

Una volta fatto questo l’impostazione del RAID1 è completa e la si potrà
terminare selezionando la relativa opzione:

Configurare LVM (Logical Volume Manager)
Una volta finita la configurazione del RAID dovrà essere configurato LVM per
usare il device md1 su cui abbiamo concentrato la gran parte dello spazio
disco, dalla schermata principale che a questo punto sarà la seguente si dovrà
scegliere «Configurare il Logical Volume Manager» e accettare di mantenere
l’attuale partizionamento:

A questo punto di avrà accesso al menu di configurazione di LVM, il primo
passo è creare un gruppo di volumi, scegliendo la relativa opzione, ed
inserire il relativo nome(ad esempio vg):

infine occorrerà scegliere il dipositivo (il volume fisico) su cui appoggiarsi
per i dati, che nel nostro caso è /dev/md1 (si deve selezionare solo
questo):

La sequenza di azione è pertanto

Scegliere dal menu «Creare nuovo gruppo di volumi»
Impostare il nome del gruppo di volumi (es. vg)
Selezionare il dispositivo /dev/md1

A questo punto si potrà passare alla creazione dei Volumi Logici, ne
serviranno 2, uno per la swap ed uno per la radice, che chiameremo
rispettivamente root e swap. Dal menu di configurazione di LVM si
dovrà pertanto scegliere «Creare volume logico»:

verrà presentata la scelta di quale Volume Group usare, bloccato sull’unico
disponibile, vg, creato in precedenza, proseguendo si potrà inserire il
nome del volume logico e la relativa dimensione. Le dimensioni consigliate
sono una dimensione pari ad un quarto della RAM (ma senza andare oltre i 4G)
per swap, ed una dimensione fra i 30 ed i 50G per root.
I passi sono pertanto i seguenti, da ripetere due volte, prima per la swap e
poi per radice:

Scegliere dal menu «Creare volume logico»
Accettare il default per il gruppo di volumi
Alla richiesta «Nome del volume logico» inserire il nome (prima swap, poi
root)
Inserire le dimensioni scelte (es. prima 4G, poi 50G)

Completate le richieste si avrà la schermata del menù analoga alla seguente
(con un volume fisico, un gruppo di volumi e due volumi logici) da cui si
potrà chiudere la configurazione scegliendo «Termina», o verificare le scelte
scegliendo «Mostra i dettagli di configurazione».

Completare il partizionamento e la formattazione del disco
Terminata la configurazione di LVM si dovrà completare la configurazione dei
dischi indicando come formattare i due volumi logici appena creati, e come
formattare il primo RAID1 (/dev/md0) che verrà usato per /boot.
Nel caso della swap si dovrà configurare la stessa selezionando il relativo
volume logico come nell’immagine seguente:

una volta scelto il volume si tornerà al menu che ci richiede come usare lo
stesso, e stavolta occorrerà scegliere «area di swap». Nel caso della swap,
che non deve essere montata, questo è tutto.
L’operazione va ripetuta per formattare il filesystem della radice, di nuovo
va scelto il relativo volume logico:

e stavolta nel «Come usare» occorrerà selezionare «File system ext4 con
journaling», a questo punto ci verrà presentata anche la scelta del «Punto di
mount» e si dovrà scegliere la radice:

La stessa operazione deve essere ripetuta selezionando il dispositivo «RAID1
dispositivo n° 0» (vedi immagine seguente) e poi scegliendo ancora di usare
come «File system ext4 con journaling» ma selezionando /boot nel «Punto di
mount».

Riepilogando i passi sono:

Selezionare il volume logico LV swap
In «Usare come:» scegliere «area di swap»
Concludere su «Impostazioni della partizione completata»
Selezionare il volume logico LV root
In «Usare come:» scegliere «File system ext4 con journaling»
In «Punto di Mount:» scegliere «/ - il file system root»
Concludere su «Impostazioni della partizione completata»
Selezionare il RAID1 dispositivo n° 0
In «Usare come:» scegliere «File system ext4 con journaling»
In «Punto di Mount:» scegliere «/boot - file del boot loader»
Concludere su «Impostazioni della partizione completata»

Una volta completati questi passi si dovrebbe avere una configurazione analoga
a quella illustrata nella immagine seguente:

e si potrà proseguire scegliendo «Terminare il partizionamento e scrivere le
modifiche sul disco» e confermando sulla successiva schermata:

A questo punto si potrà proseguire con il resto dell’installazione.

Finalizzazioni
La schermata finale richiede l’installazione di Grub, si scelga di installare
sul primo disco, come illustrato nella figura seguente:

Terminata la procedura e l’installazione del server, si deve riavviare senza
CD per verificare la ripartenza della macchina. A questo punto occorre poi
assicurarsi che Grub sia installato su tutte e due i dischi, cosa da fare con
i comandi:
grub-install /dev/sda
grub-install /dev/sdb

(è importante che Grub sia installato su entrambi i dischi, altrimenti in caso
di rottura del primo la macchina non ripartirà).
Da terminale si può controllare lo stato del RAID con il comando seguente, che
se eseguito poco dopo l’installazione mostrerà il progressivo della
sincronizzazione dei dischi:
local-utente@appiano:~$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
      976130880 blocks super 1.2 [2/2] [UU]
      [==========>..........]  resync = 53.3% (520999104/976130880) finish=140.1min speed=54122K/sec

md0 : active raid1 sda1[0] sdb1[1]
      498368 blocks super 1.2 [2/2] [UU]

una volta completata la sincronizzazione si avrà qualcosa del tipo:
local-utente@appiano:~$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
      976130880 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
     498368 blocks super 1.2 [2/2] [UU]

Installazione di Proxmox su Debian
Questa procedura si applicava alle macchine per le quali non viene
riconosciuto il controller RAID (ad esempio i server Fujitsu PRIMERGY
TX1320 M1). Dato che l’installer di Proxmox non supporta il RAID
software occorrerà usare quello di Debian, e poi passare a Proxmox una
volta installata Debian. Per gli altri casi si applica la procedura
illustrata nella sezione Installazione diretta di Proxmox.
Viene descritta nel dettaglio l’installazione della versione 6.x di
proxmox basata su Debian Buster; sulle macchine nuove non dovrebbe più
servire, ma nel caso può essere utile consultare anche
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye
per verificare eventuali aggiustamenti per la versione attuale.

Installazione di base
Si inizi con l’installazione di una Debian Buster da CD, DVD o chiavetta USB,
per la scelta dell’immagine si hanno due possibilità:

Scaricare e installare debian-live-<versione>-amd64-xfce.iso da
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
Scaricare e installare la netinstall
debian-<versione>-amd64-netinst.iso o il CD ordinario di
installazione debian-<versione>-amd64-xfce-CD-1.iso da
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

L’installazione è quella ordinaria di un sistema base Debian, ma ci sono delle
accortezze da seguire per quanto riguarda la configurazione della rete ed il
partizionamento dei dischi.
La rete deve essere configurata con IP statico (dovrà comunque essere
riconfigurata in seguito da dentro Proxmox). Se si dispone di un solo IP
pubblico e si è dietro un NAT (si presuppone che l’accesso ad internet in tal
caso sia gestito da un router) l’IP della rete interna su cui vengono
reindirizzati i pacchetti provenienti dall’esterno deve essere lasciato al
fuss-server (se si vuole la raggiungibilità dello stesso da remoto). Si usi
pertanto un altro IP nella rete interna usata dal router.
Se per esempio il router ha IP interno 192.168.112.1 ed usa la rete
192.168.112.0/24 e redirige tutto il traffico dall’esterno sull’IP
192.168.112.2, quest’ultimo dovrà essere usato sulla macchina virtuale del
Fuss Server, e non si potrà usare per l’installazione. Pertanto, assumendo che
si sia messo sullo stesso tratto di rete la prima interfaccia del server (si
assume sia eth0) nell’installazione si potrà usare un qualunque altro IP
libero della rete, ad esempio 192.168.112.102.
Per il partizionamento dei dischi occorre installare sul RAID software
usando LVM, per potersi trovare nella stessa situazione in cui ci si
troverebbe con l’installazione di Proxmox su un RAID hardware. Questa
parte della procedura è descritta in dettaglio nella sezione
Installazione di Debian su RAID software a cui si rimanda.
La procedura prevede l’installazione con una /boot separata (installata
direttamente sul primo RAID1, posto su /dev/md0) con tutto il resto su un
volume LVM (installato sul secondo RAID1, posto su /dev/md1). Le
dimensioni delle varie partizioni e volumi logici pertanto sono le seguenti,
illustrate anche nella pagina citata:

un primo disco RAID1 per /boot dell’ordine di 1Gb
un secondo disco RAID1 come volume fisico di LVM con tutto il resto dello
spazio disco
un volume logico di swap dell’ordine di un quarto della RAM (ma non superare
i 4G)
un volume logico per /root dell’ordine di 30/50G a seconda che si
preveda o meno di installare anche l’interfaccia grafica.
nessun altro volume logico in fase di installazione (verranno creati dopo)

Eventuali correzioni all’installazione iniziale
Con una installazione ordinaria si dovrebbe ottenere una configurazione già
funzionante, e potete passare direttamente alla sezione Preparazione
all’installazione di Proxmox, ma alcuni possibili interventi di correzione
post-installazione di Debian sono i seguenti:

Cambiare le password di root e dell’utente locale creato durante
l’installazione (es.local-fuss):
passwd root
passwd local-fuss

Installare i firmware aggiuntivi, solo se necessario; copiare i firmware
(*.deb) nella cartella /opt ed installarli con:
cd /opt
dpkg -i *.deb

Modificare il file di configurazione delle schede di rete, questo passo è
da eseguire solo se la configurazione della rete eseguita in fase di
installazione all’interno dell’installer di Debian non ha funzionato
correttamente, per modificarlo si apra il file /etc/network/interfaces
con un editor qualunque, ad esempio eseguendo vim
/etc/network/interfaces; un esempio del file è il seguente:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface -- WAN
auto eth0
iface eth0 inet static
    address 192.168.112.102
    netmask 255.255.255.0
    network 192.168.112.0
    broadcast 192.168.112.255
    gateway 192.168.112.1
    # dns-* options are implemented by the resolvconf package, if installed
    # dns-nameservers 208.67.222.222 208.67.220.220 8.8.8.8

verificare che il nome della scheda di rete (eth0 nell’esempio)
corrisponda alla scheda di rete rilevata sulla macchina dal comando
ip a.

se si è modificato il file di configurazione delle interfacce si esegua il
restart dei servizi di rete con:
service networking restart

Modifiche del file dei repository (/etc/apt/sources.list); questo passo
è da eseguire solo se occorre inserire dei repository aggiuntivi o fare
correzioni rispetto a quelli installati di default dall’installer di Debian,
si apra il file con vim /etc/apt/sources.list un esempio del file è:
deb http://security.debian.org/ buster/updates main
deb-src http://security.debian.org/ buster/updates main
#
deb http://deb.debian.org/debian/ buster-updates main
deb-src http://deb.debian.org/debian/ buster-updates main
#
deb http://deb.debian.org/debian buster main
deb-src http://deb.debian.org/debian buster main

Modifiche alla impostazione dei DNS; questo passo è da eseguire solo se la
configurazione della rete eseguita in fase di installazione all’interno
dell’installer di Debian non ha funzionato correttamente, si apra il file
con vim /etc/resolv.conf, un possibile esempio (usando il server
di Cloudfare) è:
# Generated by NetworkManager
nameserver 1.1.1.1

e se ne può verificare subito il funzionamento ad esempio tramite ping ad
un server noto:
$ ping www.linux.it

Preparazione all’installazione di Proxmox
Una volta completata l’installazione base di Debian come descritto nella
sezione Installazione di base. ci sono una serie di passi preliminari da
effettuare prima di passare ad installare la piattaforma di Proxmox.

Rimuovere i pacchetti non necessari e/o dannosi
I seguenti due pacchetti devono essere rimossi con i comandi:
apt-get --purge remove network-manager
apt-get --purge remove os-prober

L’uso di network-manager interferisce con la configurazione delle
interfacce, deve essere sempre rimosso, e si verifichi che non venga
eventualmente reinstallato come dipendenza nel caso si installi una
interfaccia grafica.
Il pacchetto os-prober è inutile e potenzialmente pericoloso per qualunque
server, perché cerca di controllare il contenuto di tutti i dischi per
identificare quali sono i sistemi operativi da far partire in fase di boot,
compresi eventuali dischi di macchine virtuali, magari attivi o montati, per
cui può causare anche corruzioni pesanti dei filesystem.

Configurare la risoluzione del nome locale
Prima di passare all’installazione della piattaforma occorre assicurarsi che
l’indirizzo IP assegnato alla macchina sia risolto correttamente nell’hostname
della stessa, altrimenti il servizio di pve-manager non si avvierà,
bloccando l’installazione. Per questo occorre modificare il file
/etc/hosts installato di default da Debian con:

Nella seconda riga sostituire l’IP 127.0.1.1 con l’IP assegnato al
server, nel nostro caso 192.168.112.102
Nella seconda riga aggiungere alla fine il nome aggiuntivo pvelocalhost

un esempio del file, per la macchina server102 nel dominio dom102.bzn
è il seguente:
127.0.0.1       localhost.localdomain localhost
192.168.112.102        server102.dom102.bzn    server102 pvelocalhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Una volta fatto la modifica va verificata la risoluzione del nome locale; per
la verifica della risoluzione diretta occorre eseguire il comando:
getent hosts IP.DEL.MIO.SERVER

ad esempio con la configurazione precedente si deve avere:
# getent hosts 192.168.112.102
192.168.112.102 server102.dom102.bzn server102 pvelocalhost

per la verifica della risoluzione inversa eseguire il comando:
hostname --ip-address

e con la configurazione precedente si deve avere:
# hostname --ip-address
192.168.112.102

Installare la piattaforma di Proxmox
Completate le configurazioni preliminari della sezione Preparazione
all’installazione di Proxmox si può passare all’installazione.

Aggiungere i repository di Proxmox
Il primo passo è aggiungere il repository per l’installazione eseguendo il
comando:
echo "deb http://download.proxmox.com/debian buster pve-no-subscription" \
   > /etc/apt/sources.list.d/pve-install-repo.list

occorre poi aggiungere la chiave che firma i pacchetti del repository
eseguendo il comando:
wget -O- "http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg" | apt-key add -

Installazione della piattaforma
Una volta aggiornati i dati del repository il primo passo è installare i
pacchetti aggiornati forniti da Proxmox:
apt update && apt dist-upgrade

occorre aspettare che il download e l’installazione si completino, ci possono
volere anche 15 minuti.

Installare i pacchetti di Proxmox
Una volta aggiornati i pacchetti presenti si può passare all’installazione
della piattaforma installando il necessario con il comando:
apt install proxmox-ve postfix open-iscsi

nella scelta della configurazione di postfix si può rispondere «internet site».

Operazioni di pulizia
Il kernel Debian non serve più, ma quando si fanno gli aggiornamenti scarica
anche quello, per cui si può rimuovere con (si verifichi quale versione è
effettivamente quella installata):
apt remove linux-image-amd64 linux-image-4.9.0-3-amd64

Riavvio sulla piattaforma Proxmox
Una volta fatti i passi precedenti si può riavviare, per sicurezza si può
comunque eseguire un update-grub verificando che nella lista dei kernel
compaia quello di Proxmox (che ha il suffisso pve). Nel caso si sia
installato Debian su RAID1 software, si verifichi che grub sia installato
nel su entrambi i dischi, si può verificare la cosa (ed eventualmente
correggere l’installazione) eseguendo dpkg-reconfigure grub-pc
selezionando i dispositivi dei due dischi.
Una volta riavviato il server ci si potrà collegare all’interfaccia web di
gestione con l’indirizzo:
https://IP.DEL.MIO.SERVER:8006
si otterrà una finestra di accesso come la seguente:

deve essere selezionato come «Realm», come in figura, «Linux PAM standard
authentication» e ci si potrà collegare usando le credenziali dell’utente
root (inserendo root come username e la relativa password nel campo
«Password»).
Apparirà la seguente finestra di assenza di sottoscrizione, a cui si può dare
OK senza nessun problema.

Finalizzazione della piattaforma
Il passaggio da Debian a Proxmox lascia alcune configurazioni da sistemare
rispetto alla installazione diretta di quest’ultima. Questi i passi per
effettuare gli aggiustamenti necessari.

Riconfigurare l’interfaccia di rete principale per l’uso del bridge
Ci si colleghi dall’interfaccia web e si acceda alla sezione di configurazione
della rete con le seguenti azioni:

Cliccare sul Nodo (es.»server102») nel primo pannello
Cliccare su «Network» nel secondo pannello

ottenendo la schermata seguente:

Dalla sezione di configurazione della rete dovremo eliminare la configurazione
di eth0, che verrà poi sostituita da quella di vmbr0, con le seguenti
azioni:

Doppio click su eth0
Eliminare tutti i campi contenuti e premere su «OK»

la finestra dovrà risultare come la seguente:

salvando la configurazione della rete risulterà la seguente:

A questo punto possiamo passare a creare il bridge vmbr0, si prema sul
pulsante «Create» e dal menu si selezioni «Linux Bridge», verrà proposta una
interfaccia di configurazione in cui occorrerà riempire i campi:

IP address: mettere lo stesso indirizzo che si era usato per eth0
Subnet mask: mettere la stessa che si era usata per eth0
Gateway: mettere lo stesso indirizzo che si era usato per eth0
(quello del router)
Bridge ports: mettere eth0

un esempio di configurazione è riportato nella immagine seguente:

per attivare le nuove configurazioni occorre riavviare il server, lo si può
fare direttamente dal pulsante «Restart».

Creare il Logical Volume del pool di dati per lo storage thin-lvm (local-lvm)
Il primo passo è verificare con vgdisplay quanto spazio disco libero è
presente sul volume group di LVM (vg se si sono seguite le istruzioni
precedenti):
# vgdisplay
...
  Alloc PE / Size       12782 / 49,93 GiB
  Free  PE / Size       18897844278 / 788,13 GiB
...

Verificato lo spazio disponibile si crei il volume logico data per il pool;
è prudente lasciarsi un polmone di spazio disco libero per eventuali
estensioni per cui non prenderemo tutto lo spazio disponibile. Nel caso il
comando:
lvcreate -L 715G -n data vg

creerà un volume da 715 Gb, a questo punto si potrà marcare il nuovo volume
come pool per il thin provisioning con il comando:
lvconvert --type thin-pool vg/data

Avvertimento
data è il nome del logical volume per il pool, si può usare
un nome qualunque ma questo è quello usato di default
dall’installer di Proxmox. Invece vg è del volume group
che si è usato negli esempi illustrati nella sezione
Installazione di Debian su RAID software , nel caso dell’installer di
Proxmox questo è in genere pve.

Predisposto il volume logico per il thin provisioning dall’interfaccia di
Proxmox (Datacenter->Storage->Add->LVM-Thin) si aggiunga un nuovo storage,
verranno richiesti in una finestra:

ID (usare local-lvm per coerenza con il default dell’installer di Proxmox)
Volume group: selezionare dal menù a tendina (o scrivere direttamente quello
usato, ad esempio vg
Thin pool: scrivere data o selezionarlo dal menù a tendina (comparirà
dopo aver impostato il volume group)
gli altri campi non van toccati

Aggiustamenti finali
Non è necessario per il funzionamento, ma si può installare un Ambiente
Desktop (xfce4) con un Display Manager (lightdm) e Terminali più evoluti di
quelli di serie con il comando:
apt-get install xfce4 lightdm xfce4-terminal gnome-terminal

Come browser si può installare Firefox con il comando:
apt-get install firefox-esr

Installazione diretta di Proxmox
Per i server dove viene riconosciuto il controller RAID si può
installare direttamente la piattaforma Proxmox, si può scaricare una
immagine ISO scrivibile anche su chiavetta. L’immagine è disponibile a
partire dalla pagina:
https://www.proxmox.com/en/downloads/

1. Scelta della ripartizione dello spazio disco sull’installer
In fase di installazione di Proxmox dall’immagine ISO occorre scegliere
la ripartizione dello spazio disco. Questo viene fatto nella schermata
Target Harddisk (la seconda, subito dopo aver accettato la licenza); si
selezionino come valori:

swapsize 4 (4G swap)
maxroot 30 (30G di radice, contiene solo il sistema)
maxvz - (in questo modo tutto il resto del disco sarà inserito
nel thin-pool di LVM)
minfree 50 (lasciamo un polmone di 50G)

Attenzione
con questa scelta lo storage locale (marcato local,
associato alla directory /var/lib/vz) avrà a disposizione solo lo
spazio disco della radice, che è sufficiente per tenere le immagini iso
dei CD per le installazioni, tutto lo spazio non assegnato
esplicitamente viene lasciato per l’installazione di macchine virtuali.
Se si vogliono eseguire dei dump delle macchine virtuali sul disco
locale (i dump potrebbero essere eseguiti su NAS via NFS, ovviamente con
prestazioni nettamente inferiori), occorre invece aumentare il valore
del precedente parametro minfree, per poter poi creare un ulteriore
volume logico su cui creare un filesystem da dedicare i dump (le
dimensioni dovranno corrispondere allo spazio che si prevede di usare
per le macchine virtali).

2. Configurazione della rete
La configurazione della rete che viene effettuata dall’installer di
Proxomox sulla immagine ISO è comunque statica, anche quando l’indirizzo
IP viene ottenuto da un server DHCP, in tal caso occorre sincerarsi che
l’IP che si va ad usare sia fuori dal range di un eventuale DHCP, si
verifichi per non creare possibili futuri conflitti di IP. E’
preferibile effettuare una impostazione manuale, ma la configurazione si
può comunque cambiare in un secondo momento.
Per la scelta dell’IP vale quanto detto anche al riguardo
dell’installazione di Debian; se si dispone di un solo IP pubblico e si
è dietro un NAT (si presuppone che l’accesso ad internet in tal caso sia
gestito da un router) l’IP della rete interna su cui vengono
reindirizzati i pacchetti provenienti dall’esterno deve essere lasciato
al Fuss Server (se si vuole la raggiungibilità dello stesso da remoto).
Si usi pertanto un altro IP nella rete interna.
Per un esempio si rimanda a quanto illustrato nel punto 1. di
Installazione di Proxmox su Debian

3. Aggiustamento dei repository
L’installazione diretta di Proxmox configura in
/etc/apt/sources.list.d/pve-enterprise.list il repository
“enterprise” che richiede una sottoscrizione al loro contratto di
supporto. Questa non ci serve pertanto si può cancellare questo file,
oppure commentarne il contenuto (basta apporre un # all’unica riga
che contiene).
Occorrerà poi aggiungere il repository “community” eseguendo il
comando:
echo "deb http://download.proxmox.com/debian stretch pve-no-subscription" \
   > /etc/apt/sources.list.d/pve-install-repo.list

e aggiungere poi la chiave che firma i pacchetti del repository
eseguendo il comando:
wget -O- "http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg" | apt-key add -

e, dato che l’immagine dell’installer in genere non contiene gli
aggiornamenti, eseguire i comandi:
apt-get update
apt-get dist-upgrade

ed attendere l’installazione degli aggiornamenti; se fra questi vi è
anche il kernel occorrerà riavviare la macchina.

Installazione del fuss-server su Proxmox
In questa pagina si dettagliano tutti i passi da far per installare il
Fuss Server su Proxmox, che sono indipendenti dal modo con cui è
installato quest’ultimo, che lo si sia fatto con l’installer, o che lo
si sia fatto installando prima Debian e passando poi a Proxmox.

Indicazioni generali sul collegamento all’interfaccia web
Tutte le volte che si deve fare una operazione dall’interfaccia di
gestione via web di Proxmox ci si dovrà collegare all’indirizzo:
https://IP.DEL.MIO.SERVER:8006
e si otterrà una finestra di accesso come la seguente:

deve essere selezionato come “Realm” dal menu “Linux PAM standard
authentication” e ci si potrà collegare usando le credenziali
dell’utente root, inserendo root nel campo “Username” e la
relativa password nel campo “Password”.
Una volta autenticati apparirà la seguente finestra di avviso per
l’assenza di sottoscrizione, a cui si può dare OK senza nessun problema.

Configurazioni aggiuntive preliminari
Sono configurazioni da effettuare e controllare dopo l’installazione.

Sincronizzazione di data e ora
Su Proxmox 4.4 la sincronizzazione del tempo viene eseguita da
systemd-timesyncd, la cui configurazione è mantenuta in
/etc/systemd/timesyncd.conf, che di default è vuoto per cui vengono
utilizzati i server NTP del pool Debian.
Se la macchina ha accesso ad Internet non è necessario nessun intervento
ulteriore, altrimenti occorrerà modificare il file per indicare a quale
server NTP rivolgersi (ad esempio ad un server NTP sulla rete interna,
che potrebbe essere fornito ad esempio dal router).
In tal caso occorrerà inserire nel file suddetto un contenuto del tipo:
[Time]
Servers=IP.DEL.SERVER.NTP

Alternativamente si può installare direttamente il servizio NTP sulla
macchina con:
apt-get install ntp

Di nuovo per una sincronizzazione corretta occorre impostare l’accesso
ad un server NTP di riferimento, per farlo si deve:

aprire il file di configurazione di ntp (/etc/ntp.conf) ad
esempio con vim /etc/ntp.conf
commentare le voci server esistenti e aggiungere l’indirizzo IP del
server che si può raggiungere per sincronizzare data e ora

Un esempio del contenuto che si può modificare è il seguente:
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

Se la sincronizzazione di default con systemd-timesyncd non sta
funzionando si deve intervenire manualmente. Per verificare che
l’orologio sia sincronizzato (e verificare al contempo che il server NTP
indicato sia raggiungibile) si possono eseguire i seguenti comandi:
service ntp stop
ntpdate tempo.ien.it
# sincronizza orologio al clock dell'hw
hwclock --systohc
service ntp start
date

Creazione dei bridge per le interfacce
Nell’installazione di Proxmox (o in quella di Debian) viene configurata
soltanto la prima interfaccia di rete. Il Fuss Server ne usa almeno una
seconda per la rete locale (supporremo sia eth1) ed eventualmente
una terza per il captive portal (supporremo sia eth2).
L’installazione le lascia non configurate e assumeremo questo come punto
di partenza.
Per poterle utilizzare dalle macchine virtuali occorre configurare un
corrispondente bridge (sarà rispettivamente vmbr1 e vmbr2. Per
farlo ci si colleghi all’interfaccia web, e si acceda alla sezione di
configurazione della rete con le seguenti azioni:

Cliccare sul Nodo (es.“server102”) nel primo pannello
Cliccare su “Network” nel secondo pannello

A questo punti si prema sul pulsante “Create” e dal menu si selezioni
“Linux Bridge”, verrà proposta una finestra di configurazione in cui il
solo campo che occorre impostare è “Bridge ports” in cui inserire il
nome della relativa interfaccia (ad esempio per vmbr1 si metterà
eth1 per la rete interna, per vmbr2 si metterà eth2 per il
captive portal).
Nel caso della configurazione dell’interfaccia del captive portal non è
opportuno configurare un indirizzo, ma si è rivelata necessaria una ulteriore
configurazione specifica dell’interfaccia ethernet ad esso dedicata, per
evitare rallentamenti in upload che si manifestano con alcune interfacce. Per
questo motivo occorre disabilitare nell’interfaccia di rete le funzionalità di
«generic segmentation offload» e «TCP segmentation offload». Questo si fa
manualmente con il comando:
ethtool -K eth2 gso off gro off tso off

continuando a supporre che l’interfaccia dedicata al Captive Portal sia la
eth2; si noti che la configurazione si applica all’interfaccia, non al
bridge.  Per rendere permanente la configurazione il comando può essere
impostato aggiungendo sotto /etc/network/if-up.d/ uno script cp-iface
che lo esegua, con un contenuto del tipo:
#!/bin/sh

# disable GRO, GSO and TSO from captive portal interface,
# to avoid upload slowdown

ETHTOOL=/sbin/ethtool

test -x $ETHTOOL || exit 0

[ "$IFACE" != "eth2" ] || exit 0

$ETHTOOL -K eth2 gso off gro off tso off

Per la configurazione dell’interfaccia della rete interna se si vuole
raggiungere la macchina Proxmox dalla stessa occorrerà dare un indirizzo
IP anche al bridge, avendo cura di inserirlo al di fuori del range che
poi si utilizzerà per il DHCP del Fuss Server (ed ovviamente diverso da
quello che assegneremo al Fuss Server stesso). In tal caso i campi da
riempire sono:

IP address : mettere l’indirizzo desiderato
Subnet mask : mettere la subnet mask che si userà sulla rete interna
Gateway : deve essere lasciato vuoto
Bridge ports : mettere eth1

Un esempio è riportato in figura, la configurazione si finalizza
premendo “Create”.

Per applicare la nuova configurazione della rete la macchina deve essere
riavviata (si può farlo direttamente usando il pulsante “Restart”
dell’interfaccia web).

Caricare sul server le immagini ISO per l’installazione delle macchine virtuali
Il caricamento può essere fatto attraverso un download diretto sul
server (ad esempio con wget) o con la copia diretta del file nella
directory /var/lib/vz/template/iso. I file in questa directory
devono essere immagini ISO di CD/DVD di installazione.
Nel caso del Fuss Server si deve usare la più aggiornata che si scarica
dal seguente indirizzo:
http://iso2.fuss.bz.it/fuss8/server/
(ad esempio “fuss-server-jessie-amd64-201705221525.iso”)
Qualora si abbia l’immagine sul proprio PC la si potrà caricare
direttamente dall’interfaccia web, sullo storage “local”. Per farlo si
eseguano i seguenti passi:

dal menù di sinistra, cliccare su “local (server)”
dal menù laterale selezionare “Content”
dal menù centrale, cliccare su “Upload”

si otterrà la seguente schermata:

a questo punto cliccare “Select file” e scegliere la ISO scaricata (si
può anche caricare direttamente da un device esterno) ed una volta
selezionata si otterrà:

a questo punto si potrà cliccare su “Upload”, a caricamento terminato,
si visualizzerà la ISO caricata come in figura:

Creazione della macchina virtuale per il Fuss Server

Procedura di creazione della macchina virtuale
La creazione si attiva cliccando sul tasto “Create VM” di colore azzurro
posto in alto a sinistra, cosa che farà comparire una finestra come
quella in figura:

che prevede l’esecuzione di una serie di impostazioni di valori divise
in sezioni, seguendo una successione di schermate navigabili avanti ed
indietro con i pulsanti “Next” e “Back”, ed identificate da una
etichetta in alto.

Sezione: “General”, inserire soltanto

VM ID: (si può accettare il default, 100)
Name: un nome identificativo (ad esempio fuss-server-01; si
consiglia l’uso dello stesso nome del fuss-server)

Sezione: “OS”

selezionare “Linux 4.X/3.X/2.6 Kernel”

Sezione: “CD/DVD”

espandere tendina “ISO image:”
Selezionare la ISO precedentemente caricata (ad esempio:
“fuss-server-jessie-amd64-201705221525.iso”)

Sezione: “Hard Disk”

Bus/Device = VirtIO
Storage = local-lvm
Disk size (GB)= dimensione del disco in GB, vedi istruzioni al punto
4.2
Format = Raw disk image (raw) (NON MODIFICABILE)
Cache = Default (No cache)

Sezione: “CPU”

Socket: pari al numero di processori della macchina, vedi istruzioni
al punto 4.2
Cores: 1

Sezione: “Memory”

Memory (MB) : RAM della macchina, scegliere in base alle
indicazioni del punto 4.2
Togliere il “flag” alla funzione “Ballooning”

Sezione: “Network”

Bridge = vmbr0
Model = VirtIO (paravirtualized)

Dimensionamento per RAM, CPU e disco
Per il dimensionamento della memoria gli sviluppatori di Proxmox
suggeriscono di lasciare almeno 1G della RAM totale della macchina per
il sistema, si può allocare il rimanente per le macchine virtuali, per
il fuss-server le esigenze effettive possono variare a seconda del
numero di utenti che lo useranno.
La scelta della quantità di RAM dipende anche dall’eventuale uso della
macchina fisica per ospitare altre macchine virtuali. Una buona scelta
di partenza è impiegare dalla metà ai tre quarti del totale, lasciandosi
un polmone di risorse per aumentare la RAM in un secondo tempo (basterà
modificare il valore dall’interfaccia web e riavviare la macchina).
Per il dimensionamento della CPU si verifichi il numero di processori
della macchina e si lo si indichi come numero di cores (l’uso di socket
e cores è indifferente per le prestazioni, conta il totale prodotto dei
due valori, la possibilità di variarli è a favore di chi ha licenze
software per numero di socket, che non ci interessa).

Suggerimento
Per scoprire il numero di processori della macchina si può usare il
comando top, premere 1 per visualizzare le statistiche separate
per CPU e contare le righe relative presenti.

Per il dimensionamento del disco, occorre scegliere una dimensione
totale assegnata alle macchine virtuali compatibile con la dimensione
massima disponibile sul pool di spazio disco del volume logico data.
La situazione corrente si ottiene con il comando lvs; ad esempio:
# lvs
  LV            VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve  twi-aotz-- 514,06g             11,48  5,66
  local         pve  -wi-ao---- 200,00g
  root          pve  -wi-ao----  20,00g
  swap          pve  -wi-ao----   4,00g
  vm-101-disk-1 pve  Vwi-aotz-- 100,00g data        59,04

In questo esempio la dimensione assegnata al pool (logical volume
data) è di 514,06 G, ed alla macchina virtuale 101 sono stati
assegnati 100G. Lo spazio è aumentabile a piacere (dall’interfaccia), ma
per evitare alla radice la possibilità di esaurire lo spazio su data
non si superi mai una assegnazione pari al 95% della dimensione del pool
(volume logico data).

Avvertimento
le percentuali Data% e Meta% fanno riferimento all’uso
effettivo, sicuramente inferiore a quello massimo teorico (nel caso
100/514 ~ 20%). L’uso del pool consente il cosidetto overcommit,
cioè allocare più spazio disco di quanto effettivamente disponibile,
una situazione da evitare assolutamente. Infatti allocando per le
macchine virtuali più spazio disco di quello disponibile, se poi
questo viene esaurito, si ottiene una disastrosa perdita di dati.

Pertanto quando si crea il fuss-server, posto che non si preveda di
creare nessun’altra macchina virtuale in seguito, sarà sufficiente usare
un valore inferiore ai 95% della dimensione (nel caso precedente
514,06g) disponibili su data. Si ricordi che ridurre lo spazio disco
allocato in eccesso all’inizio ad una macchina è sempre più complicato
che non estenderlo quando risulti essere poco. Se nel volume group è
ancora disponibile spazio disco (lo sarà se lo si è lasciato in fase di
installazione tenendosi un “polmone” come consigliato) è comunque
possibile allargare data con il comando:
lvextend -L +XXg /dev/pve/data

e poi eventualmente utilizzare lo spazio in più ottenuto.

Avviare la macchina virtuale
Una volta create la macchina virtuale, comparirà nel panello a destra,
per avviarla, ed avere al contempo l’accesso alla console, si possono
seguire i seguenti passi:

Selezionare la VM, ad esempio “100(fuss-server-01)”

Selezionare in alto a destra il tasto “>__Console”

Scegliere “Start”

Installazione del Fuss Server
La gran parte delle opzioni di installazione del fuss-server sono già
preimpostate nell’immagine ISO, la sola scelta significativa da fare in
fase di installazione è il partizionamento del disco (virtuale)
assegnato allo stesso.

Nella scelta predefinita dopo aver selezionato il disco viene proposto
direttamente il suo partizionamento. La scelta più sicura, per evitare
problemi di riempimento della radice, è usare filesystem separati per
/home, /var, /tmp. Questo però con il partizionamento
diretto rende meno flessibile la eventuale riallocazione dello spazio
disco.

Si tenga presente infatti che anche avendo disponibile spazio disco nel
virtualizzatore per poter allargare il disco della macchina virtuale,
l’allargamento avverrebbe sul “fondo” pertanto sarebbe facile
ridimensionare soltanto l’ultima partizione (nel caso la /home, che
pur essendo quella più probabile, non è detto sia davvero quella che ha
bisogno dello spazio disco aggiuntivo).
Per questo si suggerisce, per avere maggiore flessibilità, al costo di
una leggera perdita di prestazioni in I/O, di installare usando LVM.
Questo però significa che una volta eseguita la scelta precedente,
occorrerà “tornare indietro” riselezionando “partizionamento guidato”:

e poi selezionando “guidato, usa l’intero disco e imposta LVM”:

ed a questo punto di dovrà ripetere la scelta del disco e dell’uso dei
filesystem separati, e confermare la configurazione di LVM:

ed infine confermare prima le modifiche del disco:

e poi la formattazione finale:

A questo dopo un eventuale allargamento del disco della macchina
virtuale sarà sufficiente allargare la partizione finale (che sarà
/dev/vda5, logica) che ospita il volume fisico di LVM, estendere
quest’ultimo con pvresize, ed estendere poi il filesystem che si
preferisce con resize2fs (se si è usato il default di ext4).

Precauzioni post installazione di Proxmox.
Proxmox fornisce anche un suo sistema di gestione dei firewall per
l’host per le macchine virtuali, ma il fuss-server ha già la sua
gestione del firewall interna, pertanto il firewall di Proxmox non deve
essere abilitato, perché andrebbe ad interferire.
Per proteggere il sistema della macchina fisica è sufficiente installare
un semplice script di firewall che limiti gli accessi dalla rete interna
alle porte 22 e 8006. In ogni caso questa non deve essere visibile
direttamente da internet (l’indirizzo IP pubblico va reinoltrato, se
necessario, sul fuss-server), per cui la necessità di un firewall è meno
impellente.
Per le macchine che hanno controller RAID hardware si suggerisce di
installare alcuni tool esterni rispetto a Debian (si verifichino i
problemi di licenza) per monitorare lo stato degli stessi. Un sito che
contiene vari di questi programmi, in particolare per i controller meno
recenti e meno supportati, è http://hwraid.le-vert.net/. Occorrerà
comunque (i programmi citati comunicano via email) definire chi riceverà
le relative notifiche.
Si suggerisce inoltre di installare alcuni pacchetti ausiliari di
controllo ed utilità come:
apt-get tiger etckeeper debsums molly-guard atop iotop iftop

Clonazione di macchine con clonezilla
I passi necessari per clonare una macchina su tutto un laboratorio sono,
sulla macchina da clonare:

Avviare la prima macchina con Clonezilla
Impostare Clonezilla selezionando il server da usare per il
salvataggio dell’immagine
Clonare la macchina

e quindi su ciascuna delle altre macchine:

Avviare ciascuna delle altre macchine con Clonezilla
Impostare Clonezilla selezionando il server dal quale ottenere
l’immagine da ripristinare
Avviare la procedura di ripristino

Le immagini verranno salvate nella directory /var/clonezilla tramite
ssh, usando l’utente clonezilla con la password che si trova sul
server in /root/clonezilla_cred.txt (vedi Gestione utente/password
clonezilla)

Boot di Clonezilla via rete
Innanzitutto è necessario configurare i vari computer per fare boot da
rete (PXE): come fare dipende dai diversi BIOS presenti sui computer, ma
generalmente è sufficiente premere un tasto per ottenere il menù di boot
e selezionare una voce che nomini network, netboot o PXE.
A quel punto si otterrà il menù con le immagini disponibili sul server
FUSS: scegliere Clonezilla Live:

Configurazione di Clonezilla
Verrà innanzitutto richiesta conferma della fingerprint del server
(essendo su rete locale si può tranquillamente accettare):

quindi inserire la password dell’utente clonezilla, che si trova nel
file /root/clonezilla_cred.txt sul server:

Una schermata riassuntiva mostrerà lo spazio disponibile, premere invio
per continuare:

Si può quindi avviare Clonezilla:

Scegliere la modalità di creazione/ripristino da immagine (anziché la
copia diretta tra computer):

Dato che il server per le immagini è appena stato caricato, selezionare
skip:

E verrà chiesta ulteriore conferma, premere ancora invio per continuare:

Infine, selezionare la modalità principiante per non dover fornire
troppi dettagli:

Clone di una macchina
Selezionare l’opzione per creare l’immagine di un disco (notare che se
questa è la prima volta che si usa clonezilla verranno presentate solo
le due prime scelte, “savedisk” e “saveparts”: tutte le altre voci del
menù vengono abilitate quando sono già presenti delle immagini salvate):

Scegliere il nome da dare all’immagine (il default, oppure qualcosa di
comodo da ricordarsi)

Scegliere il disco da clonare; di solito l’unico presente:

Se la macchina è stata spenta correttamente, e se contiene partizioni
windows, scegliere di non effettuare un check del filesystem; può essere
utile invece fare tale check se la macchina contiene solo partizioni
linux ed un precedente tentativo di clone è fallito:

Selezionare di controllare che l’immagine salvata sia ripristinabile
(default):

Selezionare di non crittare l’immagine; non necessario dato che viene
salvata sul fuss-server:

Selezionare di riavviare il computer alla fine della copia:

Clonezilla mostrerà ora la riga di comando completa che verrà eseguita;
premere invio per continuare:

Viene chiesta conferma di procedere, scrivere y per continuare:

Clonezilla procederà alla creazione di un’immagine e al suo salvataggio

Fino ad annunciare di essere pronto al riavvio:

Infine, premere invio per permettere il riavvio (dato che clonezilla è
stato avviato via rete non è necessario rimuovere nessun disco):

Ripristino di una macchina
Selezionare l’opzione per ripristinare un’immagine da disco:

Selezionare il nome dell’immagine; se ne è presente più di una è
necessario ricordarsi il nome dato in fase di creazione:

Selezionare il disco su cui ripristinare l’immagine; di solito l’unico
presente:

Selezionare di verificare l’immagine prima del ripristino:

Selezionare di riavviare il computer alla fine del ripristino:

Clonezilla mostrerà ora la riga di comando completa che verrà eseguita;
premere invio per continuare:

Clonezilla inizierà a verificare l’immagine selezionata:

Quindi chiederà per due volte conferma di voler continuare, cancellando
tutto quanto presente eventualmente sul disco locale:

A questo punto verrà effettuato il ripristino:

Fino ad annunciare di essere pronto al riavvio:

Infine, premere invio per permettere il riavvio (dato che clonezilla è
stato avviato via rete non è necessario rimuovere nessun disco):

Note varie

Gestione utente/password clonezilla
L’utente clonezilla viene creato da fuss-server create che
genera una password casuale e la salva in /root/clonezilla_cred.txt
e lo aggiunge al gruppo sshaccess.
Con fuss-server upgrade viene verificata (e nel caso ripristinata)
la presenza dell’utente e la sua appartenenza al gruppo. Per la
password, se il file /root/clonezilla_cred.txt non è presente ne
viene generata ed impostata una nuova.
Se si vuole cambiare password per l’utente clonezilla si può usare
semplicemente passwd, ma è cura di chi lo fa aggiornare
/root/clonezilla_cred.txt con la nuova password.

Installazioni nelle scuole della Provincia Autonoma di Bolzano
La procedura standard di installazione nelle scuole della Provincia
Autonoma di Bolzano prevede
l”Installazione di Proxmox su Debian, seguita dalla
Installazione del fuss-server su Proxmox seguendo le accortezze
specifiche di questa sezione.

Installazione di Debian
Durante l’installazione ricordarsi di:

annotarsi il nome delle schede di rete, specialmente WAN;
dare un nome host alla macchina seguendo gli standard stabiliti (ad
esempio galilei-prox);
seguire gli standard anche per scegliere il nome di dominio (ad
esempio galilei.blz);
scegliere un nome utente locale (ad esempio local-fuss, con
password local-fuss);
inserire i server DNS 208.67.222.222 e 208.67.220.220;
eliminare eventuali partizioni pre-esistenti.

Per il partizionamento dei dischi si possono presentare due casi: se il
RAID nativo del server non viene riconosciuto (come avviene ad esempio
con Server Fujitsu TX 1320 M1 o 2 e HP Proliant Microserver Gen8) è
necessario seguire la procedura per l”Installazione di Debian su RAID software; in
caso contrario si può procedere direttamente con la guida
all”Installazione di Proxmox su Debian, usando il seguente schema di
partizionamento:

mount
dimensioni
tipo partizione
filesystem

/boot
1 GB
Partizione fisica
ext4 con journaling

/ (root)
50 GB (max)
Volume logico LVM
ext4 con journaling

swap
4 GB
Volume logico LVM
swap

/var
50+ GB
Volume logico LVM
ext4 con journaling

Configurazione aggiuntiva di Debian
Una volta completata l’installazione e la configurazione di rete è un
buon momento per installare alcuni programmi aggiuntivi utili.
Se si vuole installare il pacchetto dei microcode per i processori intel
è necessario abilitare i repository non-free-firmware in
/etc/apt/sources.list:
deb http://ftp.it.debian.org/debian/ bookworm main contrib non-free-firmware
deb-src http://ftp.it.debian.org/debian/ bookworm main contrib non-free-firmware

deb http://security.debian.org/debian-security bookworm/updates main contrib non-free-firmware
deb-src http://security.debian.org/debian-security bookworm/updates main contrib non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://ftp.it.debian.org/debian/ bookworm-updates main contrib non-free-firmware
deb-src http://ftp.it.debian.org/debian/ bookworm-updates main contrib non-free-firmware

Quindi installare i programmi desiderati:
# apt update
# apt install vim gedit net-tools dnsutils molly-guard iperf screen etherwake
# apt install intel-microcode

Nota
Il pacchetto intel-microcode è ad esempio necessario nel caso in cui
all’avvio di Proxmox comparisse l’errore TSC_DEADLINE disabled due
to Errata…
Per ulteriori informazioni si veda il thread relativo sul forum di
proxmox

Installazione Proxmox

Problemi con i server DELL PowerEdge T630
Se si presentano problemi all’avvio con il kernel proxmox installato
sopra (cosa che può succedere ad esempio con kernel 4.15.18.1) riavviare
il sistema e, nella schermata di GRUB, selezionare la modalità
Advanced / Avanzato per poi partire con un kernel più vecchio.
A questo punto si può cercare quale sia il kernel corrispondente alla
ISO proxmox più recente, su https://www.proxmox.com/en/downloads seguire
il link alle informazioni sull’iso e quindi quello alle release notes.
istruzioni da completare dopo aggiornamento allo stato attuale del
supporto per il server in questione

Problemi con i server HP
Con alcuni server HP ed alcuni controller RAID (HWRaid HP P222 P222i P420 o
P420i) si manifestano delle corruzioni dei dati quando viene attivata la
IOMMU, cosa che avviene di default per i kernel successivi alla versione
5.15-23. Si può controllare che controller sono presenti con il comando:
lspci | grep -i raid

sono indicati come possibilmente problematici quelli citati e lo Smart Array
Gen8.
Per rimediare al problema si deve disabilitare la funzionalità passando come
opzione di avvio del kernel intel_iommu=off; per questo occorre modificare
/etc/default/grub, aggiungendo la suddetta opzione alla definizione della
variabile GRUB_CMDLINE_LINUX_DEFAULT con:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=off"

ed applicare le modifiche eseguendo update-grub.

Problemi a raggiungere l’interfaccia di Proxmox
Nel caso in cui l’interfaccia web di proxmox non risponda, controllare
in /var/log/daemon.log se compare un errore come:
Apr 13 16:18:24 prox1 pveproxy[3535]: /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 1642.

Nel caso, per correggere usare i seguenti comandi:
# systemctl restart pve-cluster
# pvecm updatecerts

seguito da un reboot della macchina

Aggiornamento di Proxmox
Nel caso in cui sia necessario effettuare l’aggiornamento di Proxmox ad
una versione successiva, si possono seguire le guide del progetto,
scegliendo quella adeguata al proprio caso in
https://pve.proxmox.com/wiki/Category:Upgrade

Installazione del fuss-server
Quando si effettua l’installazione del fuss-server, l’obiettivo è la
creazione di una VM che possa essere trasportata in un altro host
Proxmox, e quindi essere compatibile con le caratteristiche hardware del
server più piccolo presente nell’intero parco macchine.

Schema di partizonamento
Lo schema di partizionamento consigliato è:

swap
max 8 GB
stessa quantità della RAM

/
50 GB

/var
min 100 GB

/srv
min 100 GB
Ospita il software e le immagini di Clonezilla
Calibrare la dimensione in base al numero e
dimensione delle immagini che si vogliono usare

/home
rimanente

Ricordando di usare LVM e che allargare le partizioni è più semplice che
non restringerle, per cui se si lascia dello spazio libero è meglio
sottostimare le dimensioni necessarie ed eventualmente allargarle in
futuro.

Configurazione delle interfacce di rete
Un esempio di /etc/network/interfaces adatto al fuss-server è il
seguente:
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface -- WAN
auto eth0
iface eth0 inet static
        address  192.168.94.3
        netmask 255.255.255.0
        network 192.168.94.0
        broadcast 192.168.94.255
        gateway 192.168.94.1

# The secondary network interface - LAN
auto eth1
iface eth1 inet static
        address 192.168.0.1
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255

In caso si voglia usare un captive portal sarà necessario configurare
una terza interfaccia di rete.

Salvataggio e ripristino di immagini
Prima di configurare il fuss-server con fuss-server create si può
creare un dump completo della VM, trasportabile su altri host Proxmox.
In questo modo per creare il FUSS server di altre scuole si può partire
da una macchina quasi ultimata sulla quale si possono sistemare le
caratteristiche specifiche per rete/utenza e completare la
configurazione.

Dump

Nota
Il device su cui si fa il dump non deve contenere dump preesistenti
di una VM con lo stesso ID di quella su cui stiamo operando.
Se così fosse, si possono raggruppare le directory relative al dump
preesistente (dump, images, private, templates) in
una nuova directory, ad esempio old_dumps.

Montare uno storage esterno
Collegare l’HD esterno al server (possibilmente ad una porta USB 3) e
assicurarsi che Proxmox monti il device (basta cliccarlo in Gestione
dei File).
Verificarne il punto di mount, che sarà tipo
/media/<nome_utente_loggato>/<etichetta_hd_esterno>.

Scollegare la ISO di fuss-server dal DVD della macchina virtuale
Cliccare sulla VM, su Hardaware, doppio click su CD/DVD Drive e
scegliere «Do not use any media»; confermare.

Aggiungere il disco esterno agli storage disponibili.

Cliccare su Datacenter, poi su Storage e poi su Add.
Scegliere Directory
Dare un nome (ID:) allo storage, ad esempio BACKUP SERVER.
Inserire nel campo Directory il punto di mount del disco esterno.

Effetuare il dump.

Assicurarsi che la macchina virtuale sia spenta.
Espandere il menù a tendina Content, cliccare su VZDump backup file
e poi sul tasto azzurro Add.
Cliccare sulla VM, su Backup e poi su Backup now.
Nel menù Storage selezionare quello appena aggiunto.
Nel menù Mode selezionare snapshot.
Lasciare selezionato il tipo di compressione LZO (fast).
Cliccare sul tasto azzurro Backup.

Il processo creerà un file denominato vzdump-quemu..........lzo
nella directory dump del disco esterno.

Scollegare il disco esterno.

Cliccare su Datacenter, Storage, sulla riga corrispondente al disco
esterno, quindi su Remove e confermare con Yes.
Smontare il disco dall’host Proxmox.

Restore
Nel caso si abbia già un dump di FUSS Server, quando si è arrivato alla
fine dell”Installazione di Proxmox su Debian lo si può ripristinare.

Avvertimento
L’host di destinazione dovrà essere configurato con uno schema di
bridge identico a quello dell’host sul quale è stato creato lo
snapshot.

Sul server di destinazione, copiare il file .lzo del dump nella
directory /var/lib/vz/dump/.
Da terminale eseguire l’operazione di restore:
# cd /var/lib/vz/dump/
# qmrestore <file_del_dump>.lzo <id_macchina>

dove <id_macchina> (ad esempio 100) è diverso da eventuali
altre macchine presenti sul server proxmox.

A questo punto è necessario adattare la macchina virtuale alla nuova
scuola.

in Options cambiare il nome della macchina virtuale.
In Hardware eliminare e ricreare le Network Interfaces.
Adattare eventualmente la quatità di RAM e il numero di CPU.

Quindi, al primo boot della macchina virtuale, cambiare i seguenti
parametri:

password di root
hostname della macchina in /etc/hosts ed /etc/hostname
indirizzi di rete in /etc/network/interfaces.

Bug reporting

Raccolta di informazioni
Quando qualcosa va storto, può essere necessario segnalare un bug
(Segnalazione) sul progetto opportuno di
https://work.fuss.bz.it/; prima di farlo è importante raccogliere
tutte le informazioni rilevanti per aiutare la diagnosi del problema.

numeri di versione
Piuttosto che indicare «aggiornato alla data X», meglio indicare i
numeri di versione precisi del pacchetto (o pacchetti) che si sospetta
possano essere coinvolti nel problema, ottenendoli ad esempio con:
dpkg -l <nomepacchetto>

fuss-server e fuss-client
Per la diagnosi è importante registrare tutti i messaggi forniti da
ansible durante l’installazione, pertanto si riporti tutto quanto
stampato dal comando fin dall’inizio.
Se si è in console (fisica o di una macchina virtuale) si può salvare
tutto l’output del comando usando preventivamente il comando script, ad
esempio:
script
<comando>
...
exit # da dare quando il comando finisce

dove <comando> sarà di volta in volta fuss-server create,
fuss-client -a o le loro varie varianti; questo salva tutto l’output
sul file typescript nella directory corrente.

Politiche
Questa sezione documenta le politiche adottate nelle scuole che adottano
FUSS, con informazioni sulle loro implementazioni.

Specifiche autenticazione
Con la versione 7.x del fuss-server sono state introdotti dei criteri di
gestione delle credenziali di autenticazione per essere conformi ai
requisiti correnti dettati dalla normativa sulla privacy, in particolare
per quanto riguarda la complessità e la scadenza delle password.
Sono soggetti a tali requisiti soltanto i docenti (in quanto gli studenti non
trattano dati altrui). Pertanto si è utilizzato un valore specifico
dell’attributo multivalore unità operativa, ou (assegnabile ad ogni
utente) per distinguere studenti e docenti. In particolare questo dovrè essere
impostato secondo la seguente tabella:

Docenti
ou=docenti

Studenti
ou=studenti

Il sistema di gestione delle password coi comandi di sistema è stato
impostato usando la seguente riga di in /etc/pam.d/common-password:
required pam_cracklib.so retry=3 minlen=8 difok=3 minclass=3

che implica lunghezza minima di otto caratteri, non ripetizione di più
di tre caratteri nel cambio password, presenza di almeno tre fra le
quattro classi di caratteri: maiuscole, minuscole, numeri,
punteggiatura.
L’applicativo web per il cambio password consente di evitare queste
restrizioni ma si applica solo agli utenti che hanno attributo
ou=studenti.
Per la scadenza delle password questa viene impostata in fase di creazione di
un utente LDAP impostando un valore in giorni nell’attributo ShadowMax
dello stesso, lo stesso valore viene applicato.  I default impostati dalla
configurazione del FUSS server non prevedono la scadenza delle password, in
quanto questa non è necessaria per la maggior parte degli utenti (che sono gli
studenti). In particolare questa non viene impostata se si usano i comandi del
pacchetto smbldap-tools.  Qualora si debba intervenire manualmente
occorre usare lo script chage.py installato come gli altri sotto
/usr/share/fuss-server/scripts/, specificando un valore in giorni con
l’opzione -M.

Octofuss
Octofuss imposta automaticamente il valore della ou= corrispondente
ad un utente, sulla base dei gruppi cui questo appartiene. Se l’utente
viene messo in un gruppo secondario chiamato “docente” o
“docenti”, ottiene la ou=docenti. Se non si trova in questi
gruppi, allora ottiene la ou=studenti.
Allo stesso tempo per i docenti viene automaticamente impostato un valore di
scadenza della password di 90 giorni, come previsto dalla normativa della
privacy. Per gli studenti invece viene usato un default di 99999 giorni, che
implica la non scadenza della stessa.

Accesso a internet
Le politiche di accesso ad internet impostate da fuss-server sono:

Gli utenti non autenticati non possono navigare, con l’eccezione dei vari
repository di software che sono autorizzati per semplicità di installazione,
elencati nella ACL repository dentro /etc/squid3/squid.conf, più
quelli eventualmente aggiunti (funzionalità disponibile dalla versione
8.0.38 del fuss server) in /etc/squid3/squid-added-repo.conf.
Gli utenti autenticati escono solo se fanno parte del gruppo internet
(locale) del fuss-server (permesso internet dentro Octonet).
Nella configurazione del proxy è possibile restringere l’accesso alla rete
Internet in orario ristretto da lunedì a venerdì dalle 7.00 alle 22.00 ed il
sabato dalle 7.00 alle 14.00, per ottenere questa restrizione occorre
modificare la configurazione di Squid, sostituendo in
/etc/squid3/squid.conf la riga:
http_access allow password internet

con la riga:
http_access allow password internet orario

Gli accessi ai siti internet vengono registrati nei file di log del sistema.
La navigazione su Internet viene svolta in modalità protetta (usando il
filtro sui contenuti di Dansguardian/E2guardian). A partire dalla versione
8.0.38 del fuss-server questa restrizione viene disabilitata di default
sulla rete locale in quanto esiste già un filtro a monte della rete delle
scuole, si può riabilitare l’uso del filtro modificando la variabile
dans_exclude_localnet in fuss-server-defaults.yaml (vedi File dei
default del Fuss Server).
L’accesso ad internet è di default bloccata per le macchine Windows, lo
si può riabilitare  modificando
la variabile proxy_win_exclude in  fuss-server-defaults.yaml
(vedi file-default-fuss-server).

Verifiche
È importante eseguire tutte le verifiche indicate per essere sicuri che
il proxy funzioni veramente.

provare a navigare con un utente autorizzato (cioè inserito nel gruppo
internet) indicando correttamente username e password;
provare a navigare con un utente autorizzato indicando correttamente
username ma sbagliando la password;
provare a navigare con un utente non autorizzato (cioè non inserito nel
gruppo internet) indicando correttamente username e password;
provare a navigare con un utente autorizzato utilizzando le sue
credenziali corrette, poi provare a toglierlo dal gruppo internet e
verificare se il proxy lo blocca.

Si tenga presente che la rimozione o l’aggiunta al gruppo internet non
hanno effetto immediato. Se questa viene effettuate tramite Octonet o
octofussctl infatti il permesso deve essere propagato da
octofuss-client che può richiedere fino a 5 minuti, inoltre gli helpers
di Squid devono vedere i nuovi permessi (finché non terminano viene visto il
valore precedente) e occorre che la cache di nscd sia rinnovata.
Pertanto se si vuole essere sicuri che il permesso sia propagato subito
occorre (a partire dalla versione 8.0.42 di fuss-server) fare
restart del servizio propagate-net-perm (disponibile anche tra i
servizi riavviabili dall’interfaccia di Octonet).
Per le versioni precedenti i comandi equivalenti sono:
octofuss-client --dryrun
nscd -i group
systemctl stop squid3
systemctl start squid3

FTP
Per abilitare il traffico FTP è necessario permettere il traffico di
questo servizio attraverso il firewall (sblocco porta 21/tcp).

Dump e restore

Aggiornamento del fuss-server via dump e restore
A partire dalla versione 8.0.48 e 10.0.28 del fuss-server sono stati
predisposti gli strumenti necessari ed una procedura che consente di
eseguire il dump di un server FUSS 8 e ripristinarlo su di un server
FUSS 10, per poter consentire il passaggio da FUSS 8 a FUSS 10
mantenendo la gran parte dei dati presenti sul server di partenza. Lo
stesso vale per il passaggio da FUSS 10 a FUSS 12.

Operazioni di dump sul server originario (FUSS 10)
La procedura prevede che si effettui un backup completo delle home degli
utenti sul server (che deve comprendere oltre a /home qualunque altra
directory in cui queste possono essere state inserite), da cui poi
ripristinare i dati. Si darà per scontato che questo sia stato fatto con il
programma fuss-backup e che il ripristino delle /home avvenga con
questo programma (il ripristino dei dati delle home può essere fatto in un
secondo tempo).
Il primo passo della procedura è eseguire lo script
/usr/share/fuss-server/scripts/fuss-dump.sh sul server di partenza (si
assume che sia un FUSS 8), questo creerà un file
fuss-server-dump-$DATA.tgz nella directory corrente con i dati necessari
al ripristino, che dovrà essere copiato a destinazione sul nuovo server (i
dati dell’archivio restano comunque salvati anche nel server originale sotto
/var/backups/fuss-dump).

Operazioni sul nuovo server (FUSS 12)
Occorrerà poi installare il sistema operativo sul nuovo server, e configurarne
la rete; è opportuno usare lo stesso hostname del server precedente; cambiarlo
potrebbe infatti dare luogo ad inconvenienti relativi a nomi rimasti in cache
sui client, quindi è meglio mantenere sempre lo stesso hostname.  Inoltre se
sul vecchio server si stanno usando le quote disco, occorrerà che queste siano
abilitate anche sul nuovo.

Avvertimento
La procedura di dump e quella di restore assume che le quote siano attive
al massimo su un solo filesystem, come normale su un fuss-server, questo
viene ricavato da /etc/fstab cercando le opzioni di montaggio
usrquota e grpquota, che devono essere attive su un solo filesystem
(non è necessario sia lo stesso fra macchina originale e nuova macchina).

Per poter utilizzare il ripristino occorre installare il nuovo server FUSS10
normalmente, con fuss-server create, mantenendo però identici il dominio,
la master password ed il workgroup. É opportuno mantenere anche la stessa rete
interna ed il range del DHCP, dato che alcuni dati (in particolare le
impostazioni del firewall e le reservation statiche) possono dipendere da
queste impostazioni.
Pertanto prima dell’esecuzione di fuss-server create è opportuno copiarsi
i dati della configurazione del server di partenza (il file
/etc/fuss-server/fuss-server.yaml, che viene comunque anche incluso
nell’archivo prodotto dallo script di dump come fuss-server.yaml.old) e
modificare soltanto le voci external_ifaces: e internal_ifaces: che
possono essere cambiate (come avviene nel passaggio da Jessie a Buster),
adattandole al nuovo server nel caso sia necessario.
Si possono comunque estrarre i dati dal dump che è un semplice tar compresso
con:
tar -xvzf fuss-server-dump-$DATA.tgz

ed il file di configurazione del fuss server precedente sarà in
fuss-dump/fuss-server.yaml.old.
Una volta completata la configurazione di base del fuss-server occorrerà
copiarvi il file con il dump dei dati, ed eseguire lo script di restore con:
/usr/share/fuss-server/scripts/fuss-restore.sh fuss-server-dump-$DATA.tgz

lo script una volta scompattato l’archivio nella sottodirectory
fuss-dump (sovrascriverà eventuali file omonimi contenuti) fermerà tutti
i servizi, reimporterà i dati, e poi li riavvierà.
Dato che i dati di NFS/Kerberos possono risentire di caching da parte del
server (che gira nel kernel) può essere opportuno riavviare il server dopo
aver eseguito il restore.
A questo punto gli utenti e le configurazioni dei servizi saranno stati
reimportati, ma resterà da ripristinare il contenuto delle home degli utenti,
operazione da fare con le istruzioni date per l’uso di fuss-backup.

Avvertimento
Il nuovo server, essendo stato reinstallato, avrà delle chiavi SSH diverse
dal vecchio, pertanto collegandosi dai client si potranno avere degli
errori di mancato riconoscimento delle fingerprint SSH del server dovuti a
questo cambiamento. Occorrerà cancellare le vecchie chiavi ed accettare le
fingerprint delle nuove chiavi (si abbia cura di segnarsele in fase di
reinstallazione).

Come ultima nota, a partire dalla versione 8.0.50 (e 10.0.34) del fuss-server
il file con i default di configurazione
(/etc/fuss-server/fuss-server-defaults.yaml) non verrà inserito nel dump,
ma semplicemente copiato a fianco di fuss-server.yaml.old (come
fuss-server-defaults.yaml.old) nella directory fuss-dump, questo
perché nello sviluppo di FUSS 10 sono stati aggiunte alcune
ulteriori variabili di configurazioni non presenti con Fuss 8, la cui mancanza
causerebbe il fallimento di fuss-server ad una esecuzione successiva al
ripristino. Per questo motivo il file viene comunque salvato in modo da poter
verificare, e riapplicare, eventuali modifiche effettuate rispetto al default
installato dal pacchetto.

Avvertimento
Si tenga presente che la rimozione di fuss-server-defaults.yaml dai
file ripristinati totalmente avviene soltanto se si esegue fuss-dump.sh
nella versione installata con un fuss-server posteriore la 8.0.50, questo
dovrebbe essere sempre vero se si sono tenute aggiornate le macchine come
buona pratica, se questo non è avvenuto, il file sarà ancora presente e
sovrascriverà quello nuovo installato con fuss-server create. Se non si
è sicuri si salvi il file prima di eseguire il restore.

Aggiornamento del server FUSS
Di seguito viene mostrata passo-passo la procedura di aggiornamento di un server FUSS dalla versione 10 alla 12.

Riferimenti sulla FUSS Tech Guide:

https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#installazione-di-fuss-server-dal-template-cloud-init-ready
https://fuss-tech-guide.readthedocs.io/it/latest/restore.html#operazioni-di-dump-sul-server-originario-fuss-10
https://fuss-tech-guide.readthedocs.io/it/latest/gestione-dei-fuss-client.html#rimozione-completa-della-configurazione

Aggiornare il server fuss e lanciare fuss-server upgrade:

apt update
apt dist-upgrade
fuss-server upgrade

Fare il dump della macchina Proxmox.
Se la scuola è dotata di rete WiFi con Captive Portal, scollegare la
scheda di rete o impostare una password al SSID dal controller. Dal
momento che dalla versione 12 l’autenticazione è gestita dagli AP,
se la rete viene lasciata aperta gli utenti possono navigare non
autenticati durante la procedura di upgrade.
Per fare il backup della configurazione di Proxmox, la comunità
Proxmox consiglia gli script che si trovano al link
https://github.com/DerDanilo/proxmox-stuff
Fare il fuss-backup del vecchio server FUSS;

il fuss-backup include anche il backup fatto da fuss-dump.sh dove ci sono anche

fuss-backup.conf con relativo cron file
/opt

Copiare il file /var/backups/fuss-server-dump-yyyy-mm-dd.tgz nella
cartella root di Proxmox:
scp /var/backups/fuss-server-dump-yyyy-mm-dd.tgz root@IP-PROXMOX-SERVER:.

Nota
Per ricavare il fingerprint RSA/ECDSA/ED25519 di un server si può usare il seguente comando:
ssh-keygen -lf <(ssh-keyscan $HOSTNAME 2>/dev/null)

Seguire la guida
https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#installazione-di-fuss-server-dal-template-cloud-init-ready
Connettersi al server Proxmox:
ssh root@IP-PROXMOX-SERVER

Copiare l’immagine cloudinit presa da http://iso.fuss.bz.it in
/var/lib/vz/dump:
cd /var/lib/vz/dump
wget http://iso.fuss.bz.it/cloud-init/vzdump-qemu-fuss-server-12-latest.vma.zst

Spegnere la vecchia VM del server FUSS.
Effettuare il restore dell’immagine cloud-init (da local) in Proxmox

Creare disco cloud-init: Hardware --> Add:

Parametri cloud-init: fare copy-paste dei parametri dalla VM del vecchio server FUSS.
Avviare la nuova VM.
Collegarsi via ssh:
ssh root@IP-FUSS-SERVER

Nota
La password di root della nuova immagine cloudinit è fuss; va cambiata subito.

Aggiornare i pacchetti:
apt update && apt dist-upgrade

Copiare da Proxmox il file fuss-server-dump-yyyy-mm-dd.tgz e
scompattarlo in /root per poter accedere ai parametri di
fuss-server.yaml da inserire dopo aver lanciato fuss-server
create:

scp root@IP-PROXMOX-SERVER:fuss-server-dump-yyyy-mm-dd.tgz .
tar xvzf fuss-server-dump-yyyy-mm-dd.tgz

apt install fuss-server

Per avere i parametri fuss-server del vecchio server sotto mano:
cat fuss-server.yaml.old

Lanciare la configurazione del fuss-server:
fuss-server create

Può darsi che /var/lib/dpkg/info/cups.postinst rallenti il task misc di ansible
(Install package cups, foomatic-db-compressed-ppds by apt). In tal caso stoppare il server cups:
systemctl stop cups

Fare il restore della configurazione del vecchio server FUSS:
/usr/share/fuss-server/scripts/fuss-restore.sh  fuss-server-dump-yyyy-mm-dd.tgz

Lanciare
fuss-server upgrade

Copiare eventualmente anche la cartella /opt

Nota
Ricordare di ingrandire il disco (se viene usata un’unica partizione per / e /home) prima di riavviare la VM andando in
Hardware –> Disk Action –> Resize:

Montare i backup FUSS sul NAS e copiare le home degli utenti:
fuss-backup mount
cd /mnt/recover
cd PATH-ULTIMO-BACKUP/home
cp -a * /home

Se invece le /home sono su di un disco separato rispetto alla
root /, potete riassegnare quel disco alla nuova VM sempre
usando Disk Actions e ricordandovi di andare a riprendere dal
backup la riga per il mount della /home dal file /etc/fstab.
Riavviare server
Se la scuola è dotata di rete WiFi, configurare la nuova
infrastruttura basata su WPA Enterprise. Ricordarsi che con la nuova
configurazione l’IP deve essere già assegnato alla scheda di rete
quando si lancia fuss-server cp. Si veda
https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#rete-wifi-wpa-enterprise

Nota
Non dimenticare di mantenere aggiornata la macchina Proxmox
assicurandosi sempre di avere il dump delle VM. Portarla almeno
alla versione 7 di Proxmox VE. Seguite le semplici istruzioni sul
wiki di Proxmox:

da 5 a 6: https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0
da 6 a 7: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0
da 7 a 8: https://pve.proxmox.com/wiki/Upgrade_from_7_to_8

Dopo aver portato anche i client a FUSS 12, ricordare di resettare
le impostazioni di Xfce4 agli utenti usando lo script
/usr/share/fuss-server/scripts/home-cleanup.  Editare lo script
aggiungendo alla variabile CLEAN_LIST il path
.config/xfce4/

Eseguire lo script una volta e rimuovere poi il path aggiunto al
file home-cleanup.

Miniguide hardware
Questa sezione comprende guide su argomenti vari di utilità nelle
scuole relativi ad installazioni per hardware particolari.

PC con requisiti particolari

PC HP ProOne 440 G6 24 All-in-One
Per il funzionamento dell’ audio delle macchine HP ProOne 440 G6 24
All-in-One è necessario installare il pacchetto firmware-sof-signed:
apt update
apt install firmware-sof-signed

A questo punto l’audio della webcam incorporata ancora non funziona e si
deve seguire la seguente procedura.

Il comando arecord -l consente di individuare card e
dispositivo del microfono (nell` esempio qui sotto 0,7):
root@aulamuse:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In /etc/xdg/autostart si crei un file alsamodule.desktop che
contenga:
[Desktop Entry]
Version=1.0
Type=Application
Name=alsamodule
Comment=Carica modulo per usare audio della webcam incorporata; il device potrebbe variare e si desume dal comando  “arecord -l”
Exec=/bin/sh -c 'sleep 1;/usr/bin/pacmd "load-module module-alsa-source device=hw:0,7"'
Terminal=false
StartupNotify=true

Dopo aver riavviato, cliccando sull’icona di Pulseaudio si troverà
una voce in più, Entrata,  che consente di selezionare il
dispositivo incorporato.

Notebook con requisiti particolari

Notebook Acer TravelMate TMP-214

Installazione immagine mediante Clonezilla
Prima di installare un’immagine di FUSS mediante Clonezilla (via PXE
boot o con chiavetta USB) è necessario accedere al menu di setup del
notebook con F2. Nella scheda Security impostare come prima cosa la
password di Supervisor premendo Enter su Set Supervisor Password.
Disabilitare poi la voce Secure Boot nella scheda Boot come mostrato
nella seguente immagine:

Dopo aver clonato l’immagine di FUSS e riavviato il notebook, si entri
nuovamente in setup con F2 riabilitando il Secure Boot.

Selezionare la voce Select an UEFI file as trusted for executing
percorrendo le cartelle del disco HDD1: <EFI> -> <debian>.

Si scelga il file shimx64.efi premendo Enter ed inserendo nel
pop-up la descrizione di questa opzione di boot, p.es. fuss10
confermando con Yes.

Al termine salvare le modifiche premendo Exit Saving Changes nella
scheda Exit o semplicemente premendo F10 confermando al termine.

Notebook HP ProBook 430 G5

Wifi
Per il funzionamento del wifi si veda:
wireless-HP ProBook

Notebook HP ProBook 450 G5

Wireless
Per il funzionamento del wifi è necessario installare il pacchetto
firmware-realtek se non già presente.
Eseguire:
apt update
apt install -t stretch-backports linux-image-amd64 firmware-realtek

Video
I portatili (HP ProBook 450 G5) presentano come unica risoluzione il
valore 1920x1080.
Il seguente codice aggiunge le risoluzioni del proiettore (o di un altro
dispositivo di output video) al portatile (interfaccia eDP-1 ) e
rende quindi possibile la specchiatura degli schermi .
for i in $(xrandr | awk '{print $1}' | grep "x")
do
if [ "$i" != "1920x1080" ]; then
xrandr --addmode eDP-1 $i
fi
done

Il codice va aggiunto allo script
/etc/fuss-client/display-setup-script/setDisplayResolution che
diventerà pertanto:
#!/bin/sh

for i in $(xrandr | awk '{print $1}' | grep "x")
do
if [ "$i" != "1920x1080" ]; then
xrandr --addmode eDP-1 $i
fi
done

HOSTNAME=$(/usr/bin/hostname)
autorandr --load $HOSTNAME || autorandr common || true

Una volta aggiunte le risoluzioni del proiettore, la seconda parte dello
script consente la specchiatura automatica dei due dispositivi già nella
finestra di login.
Gli scripts inseriti in /etc/fuss-client/display-setup-script
vengono infatti lanciati all’avvio di lightdm.

HP UEFI boot - no bootable device

Introduzione
In alcuni modelli HP recenti, bootabili solo con UEFI, dopo
l’installazione dell’immagine Fuss10 il boot non va a buon fine ed
all’avvio appare un messaggio del tipo:
NO BOOTABLE DEVICE

Il problema è dovuto al fatto che UEFI non riesce a trovare il file EFI
automaticamente. Una soluzione può essere la seguente:

Riavviare la macchina e premere il tasto per il boot manuale (in genere F9)
Scegliere Boot from file e poi:

> PciRoot … > EFI > debian > grubx64.efi      # se il Secure
Boot è disabilitato
> PciRoot … > EFI > debian > shimx64.efi      # se il Secure
Boot è abilitato

Dopo l’avvio del sistema aprire una sessione terminale e lanciare:
efibootmgr

Il comando precedente elenca le opzioni di avvio disponibili e
l’ordine di avvio, come nell’esempio seguente
BootCurrent: 0001
Timeout: 0 seconds
BootOrder:
Boot0000* Fuss10    HD(2,c8800,82000,a0d91f49-899b-46ac-8863-35f2d16774c4)File(\EFI\debian\grubx64.efi)
Boot0001* Fuss10    HD(2,c8800,82000,a0d91f49-899b-46ac-8863-35f2d16774c4)File(\EFI\debian\shimx64.efi)
Boot2001* USB Drive (UEFI)  RC
Boot2002* Internal CD/DVD ROM Drive (UEFI)  RC

4) A questo punto si deve individuare la voce del menu con la quale
siete entrati, ad es. Boot0001

Settare o cambiare il boot order col comando
efibootmgr -o 0001,0000

dove 0001 sono le 4 cifre che seguono “Boot”; non è necessario
inserire tutte le voci, è sufficiente la prima.

Nel caso si voglia visualizzare il menu all’avvio, è sufficiente
allungare il Timeout a 5 secondi o più con:
efibootmgr -t 5

Riavviare la macchina e verificare che il sistema si avvii

Notebook Lenovo IdeaPad 120s

Introduzione
Tale notebook non è dotato di presa RJ45, pertanto per la connessione
alla rete è necessario dotarsi di un adattatore USB-RJ45. Tale
adattatore non viene riconosciuto dal BIOS per permettere un network
boot e consentire l’avvio di un’immagine di Clonezilla da un server
FUSS. E” necessario dotarsi di una chiavetta USB sulla quale va copiata
preventivamente un’immagine di Clonezilla.

Modifiche al BIOS
Innanzitutto si rende necessario modificare le impostazioni del BIOS.
Dopo aver acceso il notebook, premere il tasto F2 per accedere al BIOS
(Phoenix SecureCore Technology Setup). Sotto la voce Security
accertarsi che Secure Boot sia Disabled. Sotto la voce Boot
cambiare Boot Mode in Legacy Support. Uscire salvando le modifiche
con F10. Il notebook verrà riavviato.

Avvio di Clonezilla
Dopo aver inserito una chiavetta USB avviabile con un’immagine di
Clonezilla (la versione usata per questa
guida è la 2.5.6-22), per la scelta del dispositivo di boot, premere
F12 e selezionare la voce USB HDD.
Dopo l’avvio, Clonezilla vi chiederà di selezionare la lingua
dell’interfaccia ed eventualmente di cambiare il layout della tastiera
da quello di default. Dopo questa prima impostazione verrà mostrata la
finestra Start Clonezilla nella quale va selezionata la voce omonima.
A seguire l’opzione device-image, ssh_server e dhcp. Il notebook
riceverà un indirizzo IP dal server FUSS e subito dopo si dovrà inserire
l’indirizzo IP del server (p.es. 192.168.0.1), la porta (tipicamente
22), l’account dell’utente (clonezilla), la cartella sul server
ove Clonezilla dovrà leggere l’immagine (tipicamente
/srv/clonezilla) e la password dell’utente clonezilla.
Dopo aver inserito la password, Clonezilla chiederà la modalità di
esecuzione: scegliere Beginner e poi restoredisk; verranno mostrate
le immagini disponibili sul server. Scegliere un’immagine di FUSS 9 a
64bit (di dimensione inferiore a 64 GB) che avrete preventivamente
caricato sul server FUSS nella cartella /srv/clonezilla. Confermare
il disco di destinazione sul notebook (mmcblk1) premendo Invio.
Scegliere se fare o meno un check dell’immagine prima del restore ed
infine scegliere l’azione da eseguire al termine (choose, reboot o
poweroff). Premere Invio e confermare con y due volte. Clonezilla
provvederà a copiare l’immagine indicando il tempo necessario per
concludere l’operazione.
wireless-HP ProBook

Lenovo ThinkPad P15 G2
Per la configurazione audio (output e input) si veda: PC HP ProOne 440 G6 24 All-in-One

Attivazione microfono webcam Logitech C920e
Il microfono della webcam Logitech C920e è disattivato per impostazione predefinita e può essere attivato solo utilizzando il software proprietario Logi Tune (Windows, Mac OS).
Tuttavia uno script di Python scaricabile dal seguente link :

https://github.com/MavChtz/C920e/

permette di aggirare il problema e attivare il microfono lanciando un semplice comando.

Procedura
Installare la seguente dipendenza se non già presente:
sudo apt install git python3-usb

Scaricare la cartella contenente lo script:
git clone https://github.com/MavChtz/C920e

Spostarsi nella cartella
cd C920e

Attivare il microfono col comando:
sudo ./C920e.py on

È poi sufficiente scollegare e ricollegare la webcam ed il microfono è già funzionante.

Gestione e installazione di stampanti e scanner
Le stampanti di una rete FUSS vengono gestite tramite OctoNet, come
descritto nella sezione Stampanti di rete della guida relativa.
Questa sezione descrive le procedure di installazione di alcuni modelli
di stampanti di recente produzione e per le quali la procedura di
installazione prevede passi aggiuntivi.

HP PageWide Pro 452dw
Dalla lista delle stampanti HP pubblicata su
https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index
si vede che questa stampante necessita di una versione del pacchetto
hplip (HP Linux Imaging and Printing) almeno uguale alla 3.16.3.
La versione di hplip presente sul server FUSS (Debian 8 «Jessie») è
la 3.14.16 che non prevede questo modello di stampante. Pertanto è
necessario installare hplip nella versione 3.16.11 presente nel
repository jessie-backports che va prima incluso nel file
/etc/apt/sources.list:
deb http://httpredir.debian.org/debian jessie-backports main contrib

Aggiornare i pacchetti del server ed installare hplip da jessie-backports:
apt update
apt -t jessie-backports install hplip

Dopo esserci collegati al server via ssh in modalità X11 Forwarding con
ssh -X NOMESERVER), apriamo firefox connettendoci all’URL
http://localhost:631 al quale risponde l’interfaccia web di CUPS.
Si scelga Amministrazione - Aggiungi una stampante, seguendo i passi
come mostrato nei seguenti screenshot.
Si scelga innanzitutto l’opzione AppSocket/HP JetDirect premendo poi il
bottone Continua.

Indicare nel campo connessione socket://IP_DELLA_STAMPANTE:9100 dopo
aver assegnato alla stampante un IP statico.

Inserire nella schermata successiva Nome, Descrizione e Posizione
della stampante ed aggiungendo il flag di condivisione.

Scegliere la marca della stampante (Make)

ed a seguire il modello. Si scelga HP Officejet Pro 251dw che è il
nome del modello compatibile suggerito da HPLIP.

Verificare che il Media size sia correttamente impostato sul formato A4

ed infine, selezionando la voce Opzioni installate, indicare che il
Vassoio 2 è installato e premere il bottone Imposta le opzioni
predefinite.

Ora la stampante è correttamente configurata. Resta l’ultimo passo che è
quello di abilitare i client alla stampa, operazione che va fatta in
OctoNet come descritto nella sezione dedicata.

Brother MFC-L6900DW
Scaricare sul server i due pacchetti DEB necessari
(mfcl6900dwcupswrapper-3.5.1-1.deb e mfcl6900dwlpr-3.5.1-1.deb
al seguente link:

http://fuss.bz.it/utility/printers/Brother_MFC-L6900DW

Installarli con:
dpkg -i mfcl6900dw*

Dopo esserci collegati al server via ssh in modalità X11 Forwarding con
ssh -X NOMESERVER), apriamo firefox connettendoci all’URL
http://localhost:631 al quale risponde l’interfaccia web di CUPS.
In alternativa ci colleghiamo via ssh con il server aprendo un tunnel
con ssh root@NOMESERVER -L 13631:localhost:631 e apriamo firefox
in sessione utente connettendoci all’URL http://localhost:13631 .
Si segue poi una procedura di installazione simile a quella della
stampante HP PageWide Pro 452dw
Si scelga Amministrazione - Aggiungi una stampante.
Si scelga innanzitutto l’opzione AppSocket/HP JetDirect premendo poi
il bottone Continua.
Indicare nel campo connessione socket://IP_DELLA_STAMPANTE:9100 dopo
aver assegnato alla stampante un IP statico.
Inserire nella schermata successiva Nome, Descrizione e Posizione
della stampante ed aggiungendo il flag di condivisione.
Scegliere la marca della stampante (Brother).
ed a seguire il modello: Brother MFCL6900DW for CUPS .
Quindi selezionare la voce Opzioni installate e confermare cliccando
sul bottone Imposta le opzioni predefinite.
Infine abilitare i client alla stampa, operazione che va fatta in
OctoNet come descritto nella sezione dedicata.

Scanner Epson Perfection 3490
Il seguente tutorial è stato ricavato dal link
http://www.autodidacts.io/how-to-get-epson-perfection-3490-flatbed-scanner-working-on-ubuntu-linux
segnalato e testato dal tecnico Paolo Baratta.
Innanzitutto, è necessario installare SANE (che sta per Scanner Access
Now Easy,  un popolare back-end per scanner Linux che consente di
utilizzare tutti i tipi di scanner diversi con tutti i tipi di app di
scansione. Puoi installarlo con il seguente comando:
sudo apt-get install sane

Crea una directory chiamata snapscan in /usr/share/sane
sudo mkdir  /usr/share/sane/snapscan/

Puoi scaricare il firmware  Esfw52.bin facendo clic su http://cdn.autodidacts.io/misc/Esfw52.bin
oppure trovarlo altrove su Internet cercando il nome del file.
Sposta il file in /usr/share/sane/snapscan/Esfw52.bin
sudo mv ~/Scaricati/Esfw52.bin    /usr/share/sane/snapscan/

Cambia le autorizzazioni del file del firmware:
sudo chmod 777 /usr/share/sane/snapscan/Esfw52.bin

Apri il  file di configurazione
sudo gedit /etc/sane.d/snapscan.conf

Cambia la riga in alto che dice
"firmware /usr/share/sane/snapscan/your-firmwarefile.bin"

in
"firmware /usr/share/sane/snapscan/Esfw52.bin"

Salva ed esci.
Apri /etc/default/saned (che contiene i valori predefiniti per lo script
di inizializzazione saned) in un editor di testo:
sudo gedit  /etc/default/saned

e cambia la linea che dice  RUN = no   in   RUN = yes.
Salva ed esci.

Scanner Epson Perfection V370 Photo
Installare i driver iscan-perfection-v370-bundle-2.30.4.x64 che si
trovano al seguente link:
https://download2.ebz.epson.net/iscan/plugin/perfection-v370/deb/x64/iscan-perfection-v370-bundle-2.30.4.x64.deb.tar.gz
.
Nella directory scompattata si trova uno script install.sh che
esegue l’installazione dei driver.
Seguire poi la procedura indicata per lo scanner Epson Perfection 3490
sostituendo al firmware   Esfw52.bin   il firmware PS1208MFG_FW_ver
1_29.bin scaricabile all’indirizzo:
https://kb.epson.eu/pf/12/webfiles/Article%20ZIP%20files/PS1208MFG_FW_ver%201_29.zip
.

Configurazione job accounting (contabilità processi)
Testato con Olivetti dCOPIA 5000MF E Kyocera TASKALFA 4053ci
Il seguente tutorial permette di configurare i PC affinché si possa
stampare verso le stampanti in cui è stato configurato il Job accounting
(contabilità processi).

Cosa si deve fare sulla stampante
Il Job Accounting è una funzione offerta dai due modelli di cui sopra e
si attiva manualmente, tramite la tastiera della stampante oppure dalla
LAN, oppure tramite l’interfaccia Web della stampante, dopo averla
configurata con indirizzo IP.
Una volta attivata la funzione, vanno inseriti gli account (uno per
ciascun utente/reparto), costituiti ciascuno da un nome utente e da un
ID (numerico).
Questa operazione può eventualmente essere eseguita con un import di
massa, tramite file csv (link al file contenente le istruzioni
specifiche).

Cosa si deve fare sui pc
Installate il pacchetto kyodialog_4.0-1_amd64.deb contenuto nel file
compresso (versione testata): Linux_8.7114_TA...xx53ci_x003
reperibile al seguente link:
https://www.kyoceradocumentsolutions.de/index/serviceworld/downloadcenter.html?initial=false&search=any&searchTerm=Linux&category=driver&language=EN#
Installato il pacchetto (deb), tra le applicazioni troverete “Kyocera
Print Panel”

Installate la stampante tramite il tool “Impostazioni di stampa”
(system-config-printer), assicurandovi di selezionare il protocollo IPP

Selezionate la modalità di installazione che prevede di scegliere il
PPD e impostate quello fornito al seguente link:
http://fuss.bz.it/utility/ppd/OLIVETTI-KYOCERA-(KPDL).ppd
Aprite CUPS (http://localhost:631), e nella sezione “Gestione
stampanti”, sotto “Amministrazione”, cliccate sulla coda di stampa
appena creata.
Aprite il menu a tendina “Amministrazione”, selezionate “Imposta
opzioni di default” e cliccate su “Job Accounting”.
Aprite il menu a tendina “Contabilità processi” (Job Accounting) e
selezionate 00000000
Cliccate su “Imposta opzioni di default” e chiudete CUPS
Riavviate CUPS #service cups restart

Impostazione dell’id personale
Le operazioni seguenti devono essere eseguite da ciascun utente per
poter impostare il proprio id personale

Lanciate il tool “Kyocera Print Panel e selezionate la coda di stampa
che si vuole utilizzare.
Cliccate su “Lavoro” (Job) e successivamente spuntate la casella
corrispondente a “Contabilità processi” (Job Accounting).
Nel menu a tendina selezionate “Usa ID account specifico” ed inserite
il vostro ID.
Cliccate su “OK” e chiudete il tool “Kyocera Print Panel”.

Esempio di stampa utilizzando libreoffice writer

Una volta prodotto/aperto il file, cliccate sull’icona stampante,

selezionate la coda di stampa e cliccare su “Proprietà”.

Aperta la scheda “Proprietà”, cliccare su “Dispositivo” e nel menu
“Opzione:” selezionate “Contabilità processi” (Job Accounting)
Nel menu “Valore attuale:” selezionare “Personalizzato” (Custom).
In alto, sempre sotto il menu “Valore attuale:”, si aprirà un campo
vuoto nel quale andrà inserito il proprio ID.
Cliccare due volte su “OK” e la stampa verrà inviata con il codice ID.

Import di massa account per stampanti Kyocera e Olivetti

Installare in Windows il programma Kyocera Net Viewer (pacchetto KNV
5.12.1029)
LINK: https://cl.kyoceradocumentsolutions.com/content/dam/kdc/kdag/downloads/technical/executables/utilities/kyoceradocumentsolutions/cl/en/KNV%20v5.12.1029.zip
ATTENZIONE: durante l’installazione  installate tutti i pacchetti,
soprattutto la contabilità.

Nel menù principale troverete tutte le stampanti presenti in rete,
anche di marche differenti.

Come mostrato qui sotto, cliccate col tasto destro del mouse sulla
stampante desiderata, poi su  “Impostazioni di comunicazione” e
inserite username: Admin ; password: Admin

Inserimanto account (ID, cognome e quota di stampa) tramite fie csv
(vedi in fondo al presente tutorial come si crea il file csv)
Posizionate il mouse nella sezione contabilità e attivate la stampante
desiderata con tasto destro, verificando che il bollino
corrispondente, da rosso, diventi verde.

Cliccate col tasto destro del mouse sulla stampante desiderata e
selezionate “Imposta più dispositivi account”.

Dopo aver scelto il modello di stampante, selezionate Impostazioni
account, Crea da file e infine cliccate su Sfoglia  per
indirizzare il programma sul file *.csv .

Selezione file *.csv
Nella fotocopiatrice verranno creati gli account con le restrizioni scelte

COME SI CREA IL FILE CSV
| AccountID | AccountName | AccountSubName | PrintTotalR | PrintFullColorR | PrintSingleColorR | CopyTotalR | CopyFullColorR | CopySinglecolorR | ScanTotalR | ScanOtherR | FAXTransmissionR | FAXTransmissionPortR |

(Modello tabella LibreOffice Calc)

Bisogna partire da una tabella di Libreoffice Calc, corrispondente al
modello che vedete sopra. La tabella dovrà contenere gli stessi 13
campi, con i rispettivi nomi, inseriti nella stessa posizione. Il file
*.csv deve essere prodotto scegliendo il formato DOS, con i
separatori , .  (punto e virgola).

Configurazione per poter stampare dai client con job accounting locale impostato
Per permettere di stampare da PC con il Job Accounting locale impostato su On è necessario «rimappare» l’utente sconosciuto su un utente locale.
La procedura è la seguente (per confermare le modifiche cliccare su Invia):

Si accede, anche da remoto, con l’utente amministratore, in genere Admin
Nella finestra di scorrimento a sinistra si selezione Impostazioni di gestione
Innanzitutto si crea l’utente locale da associare a quello di rete sconosciuto,ad esempio con ID 9999. Per semplicità gli possiamo attribuire lo stesso Nome utente: 9999

Si clicca su Impostazioni
Si clicca su Impostazioni autenticazione

Si spunta la voce Autorizza e poi si clicca su Impostazioni utente sconosciuto

Si clicca su Elenco account , si scorre fino a trovare l’utente 9999 e lo si spunta

A questo punto sarà possibile agli utenti stampare dai client, ma le stampe non verranno (per il momento) conteggiate, mentre verranno conteggiate le copie fatte direttamente sulla fotocopiatrice.

Lettore per la tessera sanitaria o CNS/CPS
L’attuale distribuzione FUSS incorpora già i pacchetti necessari per il
funzionamento del lettore della tessera sanitaria o CPS/CNS (Carta
Nazionale/Provinciale dei Servizi) fornito dalla Provincia Autonoma di
Bolzano. Tali pacchetti, a titolo informativo, sono:
pcscd libccid opensc pcsc-tools

Per autenticarsi nei siti Web per mezzo della tessera sanitaria bisogna
impostare (una sola volta) Firefox per l’utilizzo della libreria OpenSC
secondo la seguente procedura.

Aprire Firefox e andare in Menu -> Preferenze -> Privacy e
Sicurezza; in fondo alla pagina, sotto la voce Certificati
cliccare il bottone Dispositivi di sicurezza;
Cliccare il pulsante Carica;
Fornire nel campo Nome Modulo una descrizione, ad esempio «Carta
Nazionale dei Servizi»;
Per finire impostare il Nome file modulo cliccando su Sfoglia,
cercando e selezionando la libreria opensc-pkcs11.so nei seguenti
percorsi:

per le distribuzioni a 64 bit:
/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so;
per le distribuzioni a 32 bit:
/usr/lib/i386-linux-gnu/opensc-pkcs11.so.

Installazione di lettore Carta d’identità elettronica

Premessa
Il lettore NFC USB utilizzato per redigere la presente guida è il
modello ACR122U USB NFC Reader dell’azienda Advanced Card Systems
Ltd (https://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/)
ed è compatibile con i principali sistemi operativi (Linux, MacOS,
Windows, Android) con un costo che si aggira attorno ai 40 €.

Installazione

Usare un pc standalone con il sistema operativo uguale o superiore a Fuss 10 (buster)
aggiornato e che esca diretto dal proxy; verificare che siano installati i pacchetti pcscd e pcsc-tools .
Nel caso si operi su un pc joinato alla rete fuss utilizzare un utente locale (è sempre disponibile l’utente
local-fuss-user con password local-fuss-user)
Disattivare il modulo del kernel pn533_usb (che a cascata disabilita «nfc» e «pn533») creando il file /etc/modprobe.d/cie.conf contenente la riga:
blacklist pn533_usb

Scaricare il middleware del Ministero dell’Interno cliccando sul seguente link:

https://github.com/italia/cie-middleware-linux/releases/download/1.4.3.7/CIE-Middleware-1.4.3-7.amd64.deb/
ed installarlo con il comando:
dpkg -i CIE-Middleware-1.4.3-7.amd64.deb

oppure installarlo dai repository fuss bullseye e bookworm con:
apt install cie-middleware

Configurare il browser Firefox, come indicato nel manuale del middleware:
https://github.com/italia/cie-middleware-linux/releases/download/1.4.3.1/CIE.3.0.-.Manuale.d.uso.del.middleware.Linux.pdf/

ovvero:

Avviare Firefox e accedere alla sezione Impostazioni del browser:

Selezionare la scheda Privacy e Sicurezza

Cliccare su Dispositivi di sicurezza

Cliccare su Carica e inserire le seguenti informazioni:

Nome modulo: CIE PKI
Nome file modulo: /usr/local/lib/libcie-pkcs11.so

Nota
Per fare in modo che il lettore venga letto correttamente, è
necessario che il lettore sia collegato prima dell’avvio di Firefox
(in caso contrario non viene avviato il servizio pcscd).

Modificare il tipo di disco del FUSS Server
Questa modifica ha senso soltanto se lo storage per i dischi è di tipo
LVM-thin, qualora si stia usando uno storage di tipo LVM semplice la procedura
è inutile.
Se si è installato il FUSS server o una qualunque altra macchina virtuale
indicando come tipologia dell’hardware del disco VirtIO o VirtIO block
(dispositivo a blocchi virtuale) non sarà possibile possibile utilizzare il
comando fstrim per liberare l’occupazione di spazio disco da LVM. Questa
infatti è realizzata soltanto se disponibile il comando SCSI discard, che è
supportato solo dalla tipologia di disco VirtIO SCSI che è il default con
Proxmox 5.
Per effettuare il cambiamento occorre spegnere la macchina, se il suo
identificativo è 100 questo si fa a riga di comando con qm shutdown 100
dopo di che si dovrà modificare manualmente il relativo file di
configurazione che è /etc/pve/qemu-server/100.conf. L’operazione deve
essere effettuata a macchina spenta.
Nel caso si sia configurata la macchina inizialmente con VirtIO block il
contenuto del file avrà come configurazione per l’identificazione del disco
qualcosa del tipo:
...
bootdisk: virtio0
...
virtio0: local-lvm:vm-100-disk-0,size=32G
...

e comparirà nell’interfaccia web (selezionando la macchina e poi il menù
hardware) indicato come in figura:

Per poter riconfigurare la macchina per l’uso di VirtIO SCSI occorre
anzitutto sostituire virtio0 con scsi0 (si sta facendo l’ipotesi di un
solo disco virtuale, se sono più di uno l’operazione andrà ripetuta per tutti,
indicando con bootdisk quale deve essere usato come disco di avvio);
inoltre deve essere indicato il tipo di supporto SCSI con scsihw (se non
presente).
In sostanza il file di configurazione dovrà essere modificato per contenere
qualcosa del tipo:
...
bootdisk: scsi0
...
scsihw: virtio-scsi-pci
...
scsi0: local-lvm:vm-100-disk-0,size=32G
...

Per precauzione comunque si tenga una copia dell’originale, in questo modo si
potrà tornare indietro in qualunque momento semplicemente ricopiando indietro
la copia e ripristinando il contenuto precedente.
Una volta eseguite le modifiche nell’interfaccia web il disco verrà mostrato
nella sezione hardware della macchina virtuale come:

e selezionandolo si potrà attivare l’uso del comando discard, con:

questa ultima operazione comunque si può effettuare anche direttamente in fase
di modifica, utilizzando come specificazione del disco:
scsi0: local-lvm:vm-100-disk-0,discard=on,size=32G

invece del valore precedente. A questo punto una volta riavviato il server si
potrà utilizzare fstrim.

UPS

Premessa
Attualmente in varie scuole sono collegati ai server vari UPS di questo
tipo, senza un setup che permetta lo spegnimento automatico in caso di
una prolungata assenza di corrente elettrica.
Il setup è stato testato con collegamento USB su sistema operativo
Debian Stretch (9.4 – ProxMox 5.x).
I modelli di UPS utilizzati per il test sono i seguenti:

UPS 800 Raptor/Groups

UPS 800 Riello

UPS 1kVA Braga Moro

Configurazione

Installazione del programma nut (Network UPS Tools)
Lanciare il comando:
# apt install nut

Configurazione del file /etc/nut/ups.conf
Alla fine del file aggiungere:
[RIELLO]
   driver = riello_usb
   port = auto
   ignorelb
   override.battery.charge.low = 20
   override.battery.runtime.low = -1

Il nome RIELLO è una scelta come un’altra. Per i Raptor si puo
mettere RAPTOR o qualsiasi altro nome.

Nota
Il parametro override.battery.charge.low = 20 è quello su cui si
agisce per determinare a che stato di carica far eseguire lo
shutdown al sistema operativo.  Se non indicato come nell’esempio il
default è il 10% ( si potrebbe aumentare il valore per garantire uno
shutdown sicuro).

Nota

Per RAPTOR il driver da mettere è usbhid-ups anziché riello_usb
Per BRAGA MORO il driver (compatibile) è blazer_usb

Fatta la configurazione lanciamo il comando:
#  upsdrvctl start

e dovremmo ottenere qualcosa del tipo:
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Device simulation and repeater driver 0.13 (2.7.2)

Configurazione del file /etc/nut/upsd.conf
Qui scommentiamo la riga:
LISTEN 127.0.0.1 3493

Configurazione del file /etc/nut/nut.conf
Qui cambiamo il parametro MODE=none in MODE=standalone.
Fatto questo lanciamo il comando upsd (per avviare il demone).
Dovremmo cosí ottnere qualcosa del tipo:
Network UPS Tools upsd 2.7.2
fopen /var/run/nut/upsd.pid: No such file or directory
listening on 127.0.0.1 port 3493
Connected to UPS [RIELLO]: dummy-ups-RIELLO

Nota
Nel caso che il comando dia un errore per via del fatto che c’è giá
un’istanza attiva, basterá lanciare il comando:
# upsd -c reload

Verifica dello stato delle cose
Con il comando upsc seguito dal nome dato all’UPS (nel file
ups.conf) possiamo monitorare lo stato dell’apparecchio. Ad esempio:
# upsc RIELLO

Possiamo per esempio vedere se l’UPS è alimentato dalla rete elettrica
(ups.status: OL) oppure sta prendendo energia dalla batteria
(ups.status: OB DISCHRG).

Creazione di un utente di monitoring (file /etc/nut/upsd.users)
Aggiungere alla fine del file:
[monuser]
    password = mypass
    actions = SET
    instcmds = ALL
    upsmon master

Nota
Non si tratta di creare un utente sul sistema, ma solo nel file
appena visto.

Facciamo quindi un reload della configurazione con:
# upsd -c reload

Creazione di una direttiva di monitoring (/etc/nut/upsmon.conf)
Qui ritroviamo l’utente che abbiamo creato nel file precedente
(upsd.users).
Alla fine del file aggiungere:
MONITOR RIELLO 1 monuser mypass master

Fatto questo, lanciare il comando upsmon.
Ad un eventuale riavvio della macchina non dovrebbe essere necessario
lanciare i vari comandi (da verificare… con un ultimo test).

LIM e videoproiettori interattivi
Al termine della configurazione di ciascun modello, eseguire
all’occorrenza una calibrazione come indicato nella sezione omonima.
Riguardo all’utilizzo delle stesse, per una questione di uniformità
nelle diverse scuole, si conviene di utilizzare il software OpenBoard e
non prodotti proprietari forniti in dotazione con le stesse LIM.

Lavagne SMART BOARD

SMART Board 480
In via di elaborazione

SMART Board M600 (con proiettore Epson EB-475W)
In via di elaborazione

SMART Board SB680
Per questo modello si seguano i seguenti passi:

installare il pacchetto xserver-xorg-input-evdev:
apt install xserver-xorg-input-evdev

ridenominare il file /usr/share/X11/xorg.conf.d/10-evdev.conf
aumentando il prefisso numerico in modo tale che sia superiore a
40 (quello del file 40-libinput.conf):
mv /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/90-evdev.conf

Se il computer collegato alla LIM è un notebook, nel file
/usr/share/X11/xorg.conf.d/90-evdev.conf commentare la sezione
«touchpad» lasciandola gestire a libinput.

riavviare l’X server:
systemctl restart lightdm

Se necessario, procedere alla calibrazione della lavagna come illustrato
di seguito.

SMART Board 800 (con proiettore Epson EB-570)
Seguire gli stessi passi indicati per la LIM SMART Board SB680 .

Hitachi
https://github.com/mmuman/starboard-lsadrv  (Il makefile è da rivedere per i kernel usati da Debian «stretch»)

Hitachi Starboard FXT77
In via di elaborazione

Epson
Non richiedono software aggiuntivo per la gestione dell’input. Deve
essere configurato correttamente il proiettore dal suo Menu.
I proiettori interattivi Epson EB595 Wi ed  EB695 Wi permettono
l’interattività attraverso:

apposite penne in dotazione (pen) basate su tecnologia a infrarossi
tocco con le dita (finger touch) basato su tecnologia laser

Per attivare la funzionalità penna interattiva bisogna selezionare:

Selezionare l’impostazione Modo Funzion. Penna e premere il tasto
[Enter].
Selezionare Modalità Ubuntu e uscire.

Per attivare la funzionalità finger touch bisogna selezionare:

Selezionare Imp. unità di tocco e premere il tasto [Enter].
Selezionare Alimentazione e premere il tasto [Enter].
Selezionare On e uscire.

Effettuare una calibrazione se necessario.
Per questa e altre configurazioni che dovessero essere necessarie
consultare il manuale:

https://www.ceconet.ch/data/dokumente/00002981/Italienisch/Support/Anleitung/Instruzioni%20per%20l’uso_EB-695Wi-685Wi-680Wi-675Wi-685W-675W-680-670_IT.pdf

Monitor Samsung
Samsung DM65E-BR non richiede software aggiuntivo per gestire il touchscreen.

QOMO QWB100WS-PS
Per questo modello si seguano gli stessi passi indicati per la LIM
SMART Board SB680 .
Se necessario, procedere alla calibrazione della lavagna come illustrato
di seguito.
NOTA: NON usare più i vecchi driver che erano scaricabili da:

https://drive.google.com/file/d/0B_NIgwPdq93QRC1BdGt2QTNILUU/view?usp=sharing

oppure da

https://nc.fuss.bz.it/index.php/s/WWYoX5rHMtMLrNK

Calibrazione
Se non presente, installare il pacchetto xinput-calibrator
Lanciare come root l’applicativo:
xinput_calibrator --list

ed annotarsi l’ID (numerico) del proprio dispositivo di input (lavagna).
Importante individuare correttamente il device poiché potrebbero esserci
altri dispositivi di input (p.es. touchpad del notebook).
Lanciare poi di nuovo il comando xinput_calibrator con i seguenti parametri:
xinput_calibrator --output-filename /usr/share/X11/xorg.conf.d/99-calibration.conf --device ID-DELLA-LAVAGNA

e procedere alla calibrazione. Al termine della calibrazione verrà
scritto il file sopra indicato il quale conterrà una configurazione
analoga alla seguente:
Section "InputClass"
    Identifier    "calibration"
    MatchProduct    "EPSON EPSON EPSON 695Wi/695WT"
    Option    "Calibration"    "55 32624 -10 32331"
    Option    "SwapAxes"    "0"
EndSection

In caso di misclick detection durante la calibrazione, ridurre l’area di
proiezione sulla lavagna e rilanciare il comando di calibrazione.
Riavviare infine l’X server:
systemctl restart lightdm

Specchiatura ottimale di due device video collegati allo stesso pc

Nota
Dalla distribuzione Fuss 10 la configurazione del server grafico Xserver non è più affidata al file xorg.conf che veniva inserito nella cartella /etc/X11/.

L’ultimo fuss-client installa su tutte le macchine il pacchetto
autorandr ed uno script arandr-setup che è stato messo in
/usr/sbin.
In molti casi autorandr è in grado di individuare automaticamente la
specchiatura ottimale. Nel caso non vi riesca o si voglia ottenere una
coppia di risoluzioni personalizzata si deve procedere nel seguente
modo.
Solo sulle macchine collegate a proiettori/LIM/monitor per le quali si
desidera, oppure è necessaria, una soluzione «personalizzata»:

ci si logga come root
si lancia lo script arandr-setup
si sceglie la risoluzione migliore «specchiata» su entrambi gli schermi

Il contenuto dello script arandr-setup è il seguente:
#!/bin/bash
arandr
autorandr --save $HOSTNAME
mkdir -p /etc/xdg/autorandr/
cp -r /root/.config/autorandr/$HOSTNAME /etc/xdg/autorandr/

Lo script permette di creare una configurazione video «personalizzata»,
condivisa da tutti gli utenti. Se necessario, può essere successivamente
modificata rilanciando lo stesso script.

Riavviare il PC e verificare che la risoluzione sia quella scelta:

sia prima del login
sia dopo il login

Per evitare interferenze da parte di eventuali configurazioni fatte via
xfce4-display-settings e salvate in
~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml, lato server
è stato previsto un cron-job /etc/cron.d/home-cleanup per la
cancellazione periodica di displays.xml agli utenti.

Miniguide software
Questa sezione comprende guide su argomenti vari di utilità nelle
scuole relativi ad installazioni per hardware particolari.

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.

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:

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

Soluzione al problema 1

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

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.

Installazione del pacchetto giochi iprase

Premessa
È 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).

Avvertimento
Non è supportato l’aggiornamento di massa di un’aula da
fuss 11 a fuss 12 (bookworm), per il quale si raccomanda invece la
reinstallazione tramite fuss-fucc / clonezilla.

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 11.0.22 per Fuss 11, 12.0.7 per Fuss 12) 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 12.0.10 ma disponibile anche
per server FUSS 10.
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.
Se si vuole installare l’agent su di un server FUSS, il comando da
eseguire è:
/usr/share/fuss-server/scripts/ocs-agent-inst --connection=local -i 127.0.0.1,

Incubatore di idee
Questa sezione rappresenta una piccola vetrina di idee e proposte in
fase di incubazione che debbono essere ancora approfonditamente testate.
Hanno lo scopo di dare la possibilità

a chiunque abbia delle proposte, di vederle pubblicate dopo una prima
fase di approvazione da parte del team di progetto;
a chiunque voglia, di visionare e/o testare tali proposte aggiungendo
i propri commenti sulla mailing list fuss-devel
https://www.fuss.bz.it/cgi-bin/mailman/listinfo/fuss-devel.

Proposta 1: Installazione di FUSS Server partendo da Debian Cloud upstream
Autore: Marco Marinello
Se si vuole installare velocemente un server virtualizzato
partendo da una versione aggiornata di Debian la scelta migliore è
sicuramente partire da un disco messo a disposizione direttamente da Debian.
Recandosi su https://cloud.debian.org/images/cloud/ è possibile vedere
un elenco delle immagini cloud disponibili. Scegliere
quella relativa alla corrente distro del server (buster al momento)
quindi la penultima voce, prima di daily, ovvero l’ultima stabile.
Fra i vari file elencati, copiare il link del generic-amd64-*.qcow2,
collegarsi al server Proxmox che lo dovrà ospitare e, dopo aver creato
la macchina virtuale, eseguire
cd /opt
wget https://cloud.debian.org/images/cloud/buster/20201023-432/debian-10-generic-amd64-20201023-432.qcow2
# Importa il disco sullo storage local-lvm per la macchina con ID 100
qm importdisk 100 debian-10-generic-amd64-20201023-432.qcow2 local-lvm

A questo punto rimuovere il vecchio disco (che era stato creato automaticamente
dal wizard) dalla VM attraverso la GUI di Proxmox e «collegare»
il nuovo. Si estenda il disco (solitamente il template consta di 2GB quindi
è consigliabile incrementare almeno di 48 per arrivare a 50GB di root) e se
ne aggiunga un secondo da usare poi per le home. Aggiungere una porta seriale,
le porte di rete necessarie ed un volume Cloud-Init.
Una volta opportunamente valorizzata la tab «Cloud-Init»
sarà sufficiente avviare la VM perché Cloud-Init perfezioni la configurazione.
Una volta che la macchina è avviata attendere che unattended-upgrades installi
gli aggiornamenti quindi eseguire
fdisk /dev/sdb
# n
# p
# 1
# <enter>
# <enter>
# w
mkfs.ext4 /dev/sdb1
# Abilita controlli sul disco
tune2fs -c 50 -i 30d /dev/sda1
tune2fs -c 50 -i 30d /dev/sdb1
blkid

Si utilizzi il risultato di blkid per valorizzare il file /etc/fstab.
Sostituire anche gli ultimi due valori nel disco di root con 1 0
ed utilizzare invece 1 1 per il disco con le home.
Si esegua infine mount -a e verificare attraverso il comando
df -h che il disco sia stato montato correttamente.
Si può ora procedere alla rimozione di Cloud-Init (che creerebbe
solo disguidi d’ora in poi) ed alla configurazione vera e propria:
apt purge cloud-init
mv /etc/network/interfaces.d/50-cloud-init /etc/network/interfaces
apt install gnupg2 qemu-guest-agent nfs-common
apt install -t buster-backports ansible systemd
wget -O - https://archive.fuss.bz.it/apt.key | apt-key add -
sed -i 's/main/main contrib/g' /etc/apt/sources.list
echo 'deb http://archive.fuss.bz.it/ buster main contrib' >> /etc/apt/sources.list
apt update
apt install fuss-server fuss-backup

Proposta 2: Migrazione soft da server FUSS 8 a server FUSS 10
Autore: Marco Marinello
Al fine di semplificare la migrazione delle scuole dall’ottava versione di
FUSS Server e Client alla decima è possibile spezzare la migrazione in due.
Si può migrare distintamente server e client, non ha importanza l’ordine.
La presente guida si applica a tutti i seguenti contesti:

Server FUSS 8 e client FUSS 8
Server FUSS 8 e client FUSS 9
Server FUSS 8 e client FUSS 10

Backup del vecchio server
Come prima cosa assicurarsi di «portare via» tutti i dati essenziali alla
migrazione. Si suppone fuss-backup sia già configurato ed operativo.
Se così non dovesse essere, si segua la relativa guida. Si verifichi
nel file /etc/fuss-backup/fuss-backup.conf che la variabile
PATHS sia valorizzata correttamente e si aggiunga /root e
le altre directory che si vuole backuppare.
PATHS="/etc /home /var/backups /var/lib /var/log /var/mail /var/local /root /srv"

D’ora in poi si suppone che la rete sia scarica (non vi devono essere
operazioni in corso o utenti collegati).
Si torni quindi nella home di root e si esegua
slapcat > dump_pre_mig.ldif

che genererà un backup di LDAP nel file /root/dump_pre_mig.ldif .
Si esegua poi, per creare un backup dei gruppi
octofussctl -u root http://localhost:13400/conf > groups_backup.txt <<EOF
ls users/groups
EOF

Si ripulisca il file rimuovendo la prima riga «Welcome to the octofussd
client […]», il primo e l’ultimo />. Si esegua dunque
sed -i 's+^+create users/groups/+' groups_backup.txt

cosicché il file sia pronto per l’importazione nel nuovo server.
Spostare questo file oltre a /root/dump_pre_mig.ldif e
/etc/fuss-backup/fuss-backup.conf sulla propria macchina quindi
lanciare fuss-backup . Se root è fra i destinatari si
potrà verificare l’esito del backup col comando mail.  Ci si
annoti anche le chiavi SSH autorizzate all’accesso e gli IP della
macchina.
Il nuovo server dovrà essere identico al vecchio, nulla potrà essere
modificato fra IP, nome di dominio, hostname del server e password di
root.

Installazione del nuovo server
Si parta dall’installazione del fuss-server usando uno qualunque dei
metodi indicati su questa guida.
Qui si prosegue intendendo che fuss-server sia installato assieme
a fuss-backup ma non sia mai stato eseguito.
Si inizi montando la risorsa su cui era stato fatto il backup dal vecchio
server. Lo si può verificare dal file fuss-backup.conf copiato
poc’anzi.
mount 172.16.11.22:/myback /mnt

Si può ora procedere all’estrazione di alcuni file necessari alla
prosecuzione (si suppone si lavori come root):
cd
mkdir from_backup
cd from_backup
borg extract --progress /mnt/borgdata::$(borg list /mnt/borgdata|tail -1|cut -d ' ' -f 1) etc/fuss-server etc/fuss-backup etc/fuss-server etc/fuss-backup var/lib/krb5kdc/principal etc/krb5kdc etc/krb5.keytab root

Si copi quindi il vecchio file fuss-server.yaml in-place e si
esegua fuss-server. Se la configurazione dell’host è identica a
quella precedente non dovrebbero esserci errori e nessuna domanda
dovrebbe essere posta. Se succedesse, si verifichi la correttezza della
configurazione fatta sinora.
Se era configurato il captive portal, è possibile riconfigurarlo subito,
previo accertamento dei requisiti del file network come descritti nella
relativa guida.
cp etc/fuss-sevrer/fuss-server.yaml /etc/fuss-server
fuss-server create
# Per captive portal (se richiesto) - verificare corrispondenza interfacce
cp etc/fuss-server/fuss-captive-portal.conf /etc/fuss-server
fuss-server cp

A questo punto è consigliabile un riavvio per accertarsi che tutto funzioni.

Importazione degli utenti

Avvertimento
Ci si accerti che la versione di octonet sia >= 10.0.4-2
e octofussd >= 10.0.15-1

Creazione dei gruppi
Per non incorrere in errori, come prima cosa si ricrei i gruppi che si
aveva sul vecchio server. Il file groups_backup.txt dovrebbe essere
stato estratto dal backup in /root/from_backup/root/groups_backup.txt
octofussctl -u root http://localhost:13400/conf < /root/from_backup/root/groups_backup.txt

Conversione del file LDIF da OctoNet
Ci si colleghi dalla propria macchina ad OctoNet via browser e si esegua
l’accesso. Si vada quindi ad Utenti e Gruppi > Converti file LDIF.
Si carichi il file precedentemente esportato e si scarichi l’output in CSV.
Si modifichi quindi il file CSV con LibreOffice e si rimuova la colonna
password che contiene quelle generate automaticamente e si salvi.

Importazione del nuovo CSV
Ora che si è in possesso della lista degli utenti è possibile importare
questi nel nuovo server. Nuovamente da Utenti e Gruppi si scelga
Importa da CSV. Si carichi il file CSV appena preparato, si selezioni
la prima riga (intestazione) per renderla ignorata e si associ le
colonne.
Ci si accerti di aver associato la Hashed password altrimenti gli utenti
verranno creati senza password.
Si autorizzi l’importazione e si attenda pazientemente il termine.
La barra di progresso dovrebbe segnalare l’avanzamento dell’operazione.
Ora tutti gli utenti dovrebbero essere stati ricreati con le relative
home (vuote).

Ripristino dei file di Kerberos
Una volta creati tutti gli utenti si possono spostare in-place i vecchi
file di Kerberos con le credenziali.
systemctl stop octofussd octonet fuss-manager krb5-admin-server krb5-kdc nfs-common nfs-kernel-server
cp /etc/krb5.keytab{,-fs_old}
cp /var/lib/krb5kdc/principal{,-fs_old}
cp /root/from_backup/etc/krb5.keytab /etc/
cp /root/from_backup/var/lib/krb5kdc/principal /var/lib/krb5kdc/

Si riavvii ora il server per tornare ad una situazione pulita dal punto
di vista dei servizi. Ora è possibile accendere un client e provare
l’accesso con un utente importato. Se tutto è stato eseguito
correttamente, si dovrebbe accedere e visualizzare la propria home
(vuota).

Estrazione delle home
Ultimo step è il ripristino delle home dal backup. Dato che è un
processo lungo, è consigliabile eseguirlo in screen.
cd /
borg extract --progress /mnt/borgdata::$(borg list /mnt/borgdata|tail -1|cut -d ' ' -f 1) home

Configurazione del nuovo backup
Nel riconfigurare fuss-backup è consigliabile non usare di nuovo
la directory borgdata per non intaccare il vecchio backup.
Si preferisca piuttosto qualcosa come borgdata10.

Ripristino di altri dati o configurazioni precedenti
Il server dovrebbe essere ora pienamente operativo. È possibile tuttavia
ripristinare ulteriori dati (come le immagini di clonezilla) o
configurazioni (come quelle del firewall) dal backup.
Questi sono lasciati come esercizio al lettore.

Contribuisci
Chiunque può contribuire a migliorare questa documentazione che è scritta in reStructuredText.

Autori
Le seguenti persone hanno partecipato alla stesura di questa guida.

Paolo Baratta
Claudio Cavalli
Piergiorgio Cemin
Paolo Dongilli
Donato Florio
Elena Grandi, Truelite Srl
Marco Marinello
Davide Nobile
Andrea Padovan
Simone Piccardi, Truelite Srl
Michael Von Guggenberg
Fabian Zwischenbrugger

I dettagli e lo storico dei contributi sono disponibili sul repository
git.

Supporto
Se ti serve aiuto, scrivi una mail ad info@fuss.bz.it

Licenze

Docenti	`ou=docenti`
Studenti	`ou=studenti`