FUSS - Manuale per il tecnico

_images/fuss.png

Il presente manuale è una guida rivolta ai tecnici FUSS per la manutenzione di un’installazione FUSS GNU/Linux basata su Debian 10 «Buster».

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.

Topologia di una rete FUSS

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-10-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-10-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 rimuoverele 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 Buster, su cui è basato il FUSS server. Le immagini si possono ottenere dall’indirizzo

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

e a febbraio 2020 la versione più recente è la 10.3.0, quindi il file da utilizzare è debian-10.3.0-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:

_images/netinstall-boot.png

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

_images/netinstall-langsel.png

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

_images/netinstall-posizione.png

e si scelga Italia; la tastiera:

_images/netinstall-keyboard.png

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):

_images/netinstall-ifselect.png

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:

_images/netinstall-manualnet.png

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

_images/netinstall-configip.png
_images/netinstall-configgw.png
_images/netinstall-configdns.png

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

_images/netinstall-sethostname.png

si prosegua poi impostando il dominio:

_images/netinstall-setdomain.png

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»:

_images/fuss-server_scelta-guidato.png

quindi selezionare il disco da partizionare:

_images/fuss-server_selezione-disco.png

l’uso dei filesystem separati:

_images/fuss-server_selezione-partizioni.png

e confermare la configurazione di LVM:

_images/fuss-server_conferma-scelta.png

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

_images/fuss-server_gruppo-volumi.png

e poi la formattazione finale:

_images/fuss-server_scelta-finale.png

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

_images/netinstall-ulteriori-cd.png

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

_images/netinstall-pacchetti.png
_images/netinstall-mirror.png
_images/netinstall-proxy.png

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»:

_images/netinstall-tasksel.png

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

_images/netinstall-grubinstall.png
_images/netinstall-selectdisk.png

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/ buster-backports main
deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ buster main

infine si dovrà importare la chiave GPG del repository di FUSS con:

# apt install gnupg
# wget -qO - https://archive.fuss.bz.it/apt.key | gpg --dearmour > /usr/share/keyrings/fuss-keyring.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 10 «buster». Ad oggi (aprile 2022) l’ultima versione disponibile di «buster» è la 10.12.0 ed è possibile reperirla da https://cdimage.debian.org/mirror/cdimage/archive/latest-oldstable-live/amd64/iso-hybrid/ per architettura amd64:

E` 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-10.12.0-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.

_images/fuss-client_01.png

Scelta di lingua e tastiera.

_images/fuss-client_02.png
_images/fuss-client_03.png
_images/fuss-client_04.png

Inserire il nome del host.

_images/fuss-client_05.png

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

_images/fuss-client_06.png

Impostazione della password di root.

_images/fuss-client_07.png
_images/fuss-client_09.png

Creazione di un utente locale.

_images/fuss-client_10.png
_images/fuss-client_11.png
_images/fuss-client_12.png
_images/fuss-client_13.png

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

_images/fuss-client_14.png
_images/fuss-client_15.png
_images/fuss-client_16.png
_images/fuss-client_17.png
_images/fuss-client_18.png
_images/fuss-client_19.png
_images/fuss-client_20.png
_images/fuss-client_21.png
_images/fuss-client_22.png
_images/fuss-client_23.png
_images/fuss-client_24.png
_images/fuss-client_25.png
_images/fuss-client_26.png

Al termine scrivere le modifiche sul disco.

_images/fuss-client_27.png

Inizia l’installazione del sistema.

_images/fuss-client_28.png

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

_images/fuss-client_29.png

Scegliere un mirror di rete.

_images/fuss-client_30.png
_images/fuss-client_31.png
_images/fuss-client_32.png

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

_images/fuss-client_33.png
_images/fuss-client_34.png

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

_images/fuss-client_35.png
_images/fuss-client_36.png
_images/fuss-client_37.png
_images/fuss-client_38.png

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.

E` necessario configurare i repository FUSS. Abilitare pertanto sia i repository FUSS che buster-backports in /etc/apt/sources.list:

deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg] http://archive.fuss.bz.it/ buster main
deb http://httpredir.debian.org/debian buster-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 buster main
deb-src http://deb.debian.org/debian buster main

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

deb http://security.debian.org/debian-security/ buster/updates main
deb-src http://security.debian.org/debian-security/ buster/updates main

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

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

Se invece si ha la necessità di scaricare anche i pacchetti non-free si aggiungano a «main» anche «contrib» e «non-free»

# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free

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

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

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

deb [signed-by=/usr/share/keyrings/fuss-keyring.gpg]  http://archive.fuss.bz.it/ buster 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 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 la 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. Se si vuole agganciare il computer al dominio si deve aggiungere la parola join e, come ultimo parametro, il nome del cluster. Il file incluso nel pacchetto contiene un piccolo esempio commentato che riportiamo di seguito:

info-pc01 08:00:27:ab:5a:a2 cloneImage-img join clustername

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.

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 alla rete come indicato in computerList.txt.

clonezilla boot

clonezilla boot

In caso contrario, o se qualcosa non va 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.

Captive Portal

L’installazione del captive portal 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 Captive Portal è necessario disporre di una terza interfaccia di rete che deve essere lasciata non configurata. Questa interfaccia sarà quella che dovrà essere collegata fisicamente al tratto di rete (che deve essere fisicamente separata dalla rete interna del server) che verrà gestita dal Captive Portal (ad esempio vi si potrà attaccare un access point senza autenticazione). Negli esempi successivi assumeremo che si tratti di ens20.

Si tenga presente che l’interfaccia fisica (ens20) viene gestita direttamente dal software di gestione del Captive Portal (Coova Chilli) che poi fa passare i pacchetti autorizzati creando una interfaccia tunnel (di default tun0). Gli indirizzi di rete fanno riferimento a quest’ultima, ad ens20 non deve essere assegnato alcun indirizzo IP.

Per questo si abbia cura di verificare che sul Fuss Server non sia stato attivato network manager in caso di installazione dell’interfaccia grafica (il default comunque non lo prevede). Qualora risultasse presente si abbia cura di bloccare ogni possibile tentativo di autoconfigurazione dell’interfaccia dedicata al Captive Portal inserendo in /etc/network/interfaces una voce del tipo:

iface ens20 inet manual

Per installare il Fuss Captive Portal 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 del Captive Portal (ad esempio eth2)
  • indirizzo della rete del Captive Portal (ad esempio 10.1.0.0/24)

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.1.0.0/24
...

Nota

Si tenga presente che nel file /etc/fuss-server/fuss-server-defaults.yaml la variabile chilli_range_split è impostata di default a yes e pertanto quando si configura il captive portal la rete di coova-chilli viene separata in un range dinamico ed un range statico. Quello statico viene destinato tipicamente agli access-point. In relazione al numero di device che dovranno essere serviti è opportuno usare un hotspot_network adeguato. Ad esempio se si sceglie 10.1.0.0/23 il range dinamico sarà 10.1.0.2--10.1.0.254 mentre quello statico 10.1.1.1--10.1.1.254.

Il software del Captive Portal autentica gli utenti su LDAP (occorre quindi avere un utente definito per poterlo provare), e consente solo agli utenti autenticati di uscire, passando attraverso il proxy per il traffico web.

Per il funzionamento del Captive Portal viene creato dal comando di installazione anche il file fuss-captive-portal.conf che contiene le variabili necessarie allo script di firewall per gestire gli accessi relativi al Captive Portal, questo file non deve essere modificato né cancellato, altrimenti il riavvio del firewall non aprirà gli accessi necessari al funzionamento del Captive Portal.

Nota

l’installazione del captive portal aggiunge 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.

Accesso alla rete wifi tramite Captive Portal

Una volta connessi alla rete dell’access point, per navigare è necessario inserire le proprie credenziali nella finestra di login del Captive Portal, a cui si accede aprendo il browser e inserendo nella barra di navigazione l’indirizzo <http://10.1.0.1:4990> . Poiché il Captive Portal memorizza MAC address della macchina e lo conserva per qualche tempo, prima di chiudere la sessione è consigliabile inserire nella barra di navigazione l’indirizzo <http://10.1.0.1:4990/logoff>, <http://logout> o semplicemente logout. In caso contrario l’utente successivo potrebbe navigare in rete usando le nostre credenziali.

Architettura

Servizi presenti su Fuss Server

Servizi
Servizio Descrizione
apache Server web
bind DNS locale
coova-chilli Captive portal (solo se configurato esplicitamente)
e2guardian Filtro sui contenuti internet
isc-dhcp-server DHCP per la rete locale
iptables Firewall
freeradius Autenticazione sul captive portal (se configurato esplicitamente)
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, se disponibile, userà l’interfaccia grafica, altrimenti queste dovranno essere inserite con interfaccia testuale nel terminale.

Le seguenti immagini illustrano le varie finestre di immissione disponibili quando si usa il programma di impostazione nell’interfaccia grafica, i pulsanti di navigazione consentono di muoversi avanti ed indietro nelle varie impostazioni per poterle modificare, ed una completata l’immissione dei dati si potrà premere il pulsante applica nell’ultima finestra.

_images/fs-create-01-welcome.png
_images/fs-create-02-localnet.png
_images/fs-create-03-domain.png
_images/fs-create-04-workgroup.png
_images/fs-create-05-dhcp_range.png
_images/fs-create-06-pass.png
_images/fs-create-07-geoplace.png
_images/fs-create-08-external_ifaces.png
_images/fs-create-09-internal_ifaces.png
_images/fs-create-10-done.png

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.

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.

File dei default del Fuss Server

Sotto /etc/fuss-server/ viene installato anche secondo file, fuss-server-defaults.yaml, sempre in formato yaml, che contiene alcune variabili interne ad uso del fuss-server per i default di installazione. Non deve essere cancellato, o il comando fuss-server cesserà di funzionare, qui si possono effettuare modifiche per cambiare i default.

Le variabili definite in questo file permettono di controllare alcune caratteristiche che assume l’installazione, un elenco di quelle rilevanti è illustrato nella tabella seguente.

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. Stringa yes
dans_exclude_localnet Esclude la rete locale dal filtraggio di e2guardian. Stringa 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
e2_nofile Limite di file aperti per e2guardian Intero 8192
e2_workers Limite di httpworker per e2guardian Intero 1024
chilli_range_split Se è impostato a yes la rete di coova-chilli viene separata in un range statico ed un range dinamico; nel caso in cui lo si usi è opportuno usare un hotspot_network adeguato, ad esempio 10.1.0.0/23. Stringa 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.

E2guardian

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/dansguardian/lists/.

Server DHCP

Il file /etc/fuss-server/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/fuss-server/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

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/

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.

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

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)

I file in /etc/e2guardian/lists/ permettono di modificare la configurazione del filtro contenuti.

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"

E” 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

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.

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:

1.a) «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"

1.b) 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)
  1. Modificare i seguenti file, sostituendo la vecchia-password con la nuova-password.
vim /root/.ldapvirc
  1. 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
  1. Modificare i seguenti file, sostituendo (2 volte) la vecchia-password con la nuova-password .
vim /etc/smbldap-tools/smbldap_bind.conf

5) 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:____________
  1. Modificare il seguente file sostituendo la password:
vim /etc/octofuss/octofuss.conf
  1. Riavviare il servizio:
service octofussd restart
  1. 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.

9.a) 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:

9.b) 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

9.c) 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:

9.d) Uscire da questa modalità interattiva digitando:

exit
  1. Editare il seguente file per sostituire la MASTER-PASSWORD :
vim /etc/fuss-server/fuss-server.yaml
  1. Editare il seguente file per sostituire la MASTER-PASSWORD :
vim /etc/freeradius/modules/ldap

Riavviare il servizio

service freeradius restart
Procedure facoltative consigliate
  1. 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: ________
  1. Si potrà poi andare nella history ed eliminare le tracce dei comandi contenenti la nuova password. La procedura è la seguente:
  1. Visualizzare la lista dei comandi ed il loro numero progressivo lanciando il comando:
history
  1. Eliminare lo specifico comando (poniamo che sia il numero 764 della lista) con:
history -d 764
  1. Confermare le modifiche con:
history -w
  1. 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/fuss-server/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/fuss-server/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/fuss-server/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.

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 sul 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 10 (buster)

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

  • Installare Debian 10 (buster) 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-10.3.0-amd64-xfce.iso debian-live-10.3.0-amd64-xfce+nonfree.iso
    i386 debian-live-10.3.0-i386-xfce.iso debian-live-10.3.0-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/ buster 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 -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/ buster 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 dei repository.

L’opzione --unofficial di fuss-client aggiunge l’installazione di tali firmware; per usarla è necessario abilitare le sezioni contrib 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.

Rimozione completa della configurazione

fuss-client permette 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 ottiene lanciando il comando:

# fuss-client -r -p

quindi spostando il client sulla rete del nuovo server e lanciando fuss-client regolarmente come indicato sopra.

Attenzione che questa procedura non agisce sul server (non è quindi adatta per scollegare client da server che si vogliono mantenere in uso) e non rimuove tutta la configurazione del client; in generale il metodo consigliato è sempre il ripristino del client da un’immagine clonezilla fresca di installazione tramite fuss-fucc.

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:

_images/browser-to-octonet-login.png

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:

_images/browser-to-octonet-justlogged.png

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.

_images/browser-to-octonet-user-group-menu.png

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).

_images/browser-to-octonet-user-list.png

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:

_images/browser-to-octonet-user-admin-edit.png

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:

_images/browser-to-octonet-groups-initial.png

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:

_images/browser-to-octonet-group-create.png

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):

_images/browser-to-octonet-group-initiallist.png

É 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:

_images/browser-to-octonet-group-edit.png

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:

_images/browser-to-octonet-user-create-empty.png

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.

_images/browser-to-octonet-user-create-filled.png

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:

_images/browser-to-octonet-user-student1-created.png

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.

_images/browser-to-octonet-user-docente1-create.png

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

_images/browser-to-octonet-user-docente1-created.png

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

_images/browser-to-octonet-user-student1-edit.png

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:

  1. si possono (quando sono state configurate ed abilitate) inserire le quote disco (nella sezione Modifica Quote) dell’utente
  2. 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
  3. 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
  4. 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.
_images/browser-to-octonet-user-student1-reenable.png

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:

_images/browser-to-octonet-user-student1-controlgroupset.png

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

_images/browser-to-octonet-user-student1-controlled.png

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:

_images/browser-to-octonet-user-masscreate.png

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:

  1. 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
    
  2. 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.

  3. 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).

  4. 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:

_images/browser-to-octonet-user-csv-verify.png

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:

_images/browser-to-octonet-user-csv-verify-numcolerr.png

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:

_images/browser-to-octonet-user-csv-verify-dupuser.png

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

_images/browser-to-octonet-user-csv-verify-ok.png

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:

_images/browser-to-octonet-user-csv-import-loaded.png

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:

_images/browser-to-octonet-user-csv-import-exclude.png

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:

_images/browser-to-octonet-user-csv-import-reordered.png

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.

_images/browser-to-octonet-user-csv-import-imported.png
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
_images/browser-to-octonet-ldif-conversion-choose.png

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:

_images/browser-to-octonet-quota-list-filesystem.png

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à:

_images/browser-to-octonet-quota-home-user-quotes.png

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.

_images/browser-to-octonet-quota-setting.png

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

_images/browser-to-octonet-user-quota-setting.png

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.

_images/browser-to-octonet-dhcp-leases.png

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:

_images/browser-to-octonet-dhcp-reservation-create.png

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/fuss-server/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:

_images/browser-to-octonet-dhcp-reservation-list.png

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.

_images/browser-to-octonet-host-managed-list.png

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.

_images/browser-to-octonet-host-newhosts-list.png

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:

_images/browser-to-octonet-host-cluster-create.png

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:

_images/browser-to-octonet-host-cluster-created.png

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

_images/browser-to-octonet-host-cluster-menu.png

ottenendo:

_images/browser-to-octonet-host-cluster-hosts.png

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.

_images/browser-to-octonet-host-cluster-operations.png

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:

_images/browser-to-octonet-host-singlehost-operations.png

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.

_images/browser-to-octonet-host-upgrade-page.png

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.

_images/browser-to-octonet-host-upgrade-manage.png

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 .

_images/lista_degli_script.png

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

_images/esecuzione.png

Dopo aver assegnato un Nome si clicchi sul pulsante Crea una nuova esecuzione .

Si clicchi sul nome dell’Esecuzione appena creata.

_images/esecuzione2.png

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.

_images/confermaeprogramma.png

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

Gestione filtri web

Tramite la voce ReteFiltro Web nella barra laterale si accede alla pagina di gestione dei filtri sui contenuti per la navigazione, abilitandone il relativo menù nella barra superiore.

_images/wf01-filtro_web.png

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 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.

_images/wf02-siti_permessi.png

banned_extensions è un elenco di estensioni di file ai quali è proibito l’accesso.

Il file corrispondente è /etc/dansguardian/lists/bannedextensionlist.

_images/wf03-estensioni_proibite.png

banned_sites è un’elenco di domini ai quali l’accesso è sempre proibito.

Il file corrispondente è /etc/dansguardian/lists/bannedsitelist.

_images/wf04-siti_proibiti.png

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.

_images/wf05-config.png

Modifiche ai filtri web

_images/wf06-edit.png

I campi delle pagine appena viste sono modificabili, oppure svuotabili premendo il tasto ✘ 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.

_images/wf07-restart.png

Gestione firewall

Tramite la voce ReteFirewall nella barra laterale si accede alla pagina di gestione del firewall, abilitandone il relativo menù nella barra superiore.

_images/fw01-firewall.png

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

_images/fw07-host_senza_accesso.png

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

_images/fw04-host_accesso_completo.png

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

_images/fw02-destinazioni_consentite.png

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

_images/fw06-servizi_consentiti.png

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

_images/fw05-servizi_esterno.png

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

_images/fw03-servizi_consentiti.png

Modifiche al firewall

I campi delle pagine appena viste sono modificabili, oppure svuotabili premendo il tasto ✘ 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 ReteStampanti 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.

_images/pr01-stampanti_di_rete.png

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/

_images/pr03-interfaccia_cups.png

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).

_images/pr02-modifica_stampante.png

Aggiunta di una stampante

Per aggiungere una nuova stampante è innanzitutto necessario configurarla su CUPS: dall’interfaccia relativa selezionare CUPS for AdministratorsAdding Printers and Classes:

_images/pr04-cups_admin.png

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 stampanti.

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:

_images/pr05-cups_add_printer.png

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):

_images/pr05-cups_add_printer_settings.png

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

_images/pr05-cups_add_printer_make.png

e, dopo aver premuto Continue il modello:

_images/pr05-cups_add_printer_model.png

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

_images/pr09-cups_default_options.png

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

_images/pr10-stampanti_rete_nuova.png

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

_images/pr11-aggiungi_host.png

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.

_images/samba_create.png

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.

_images/thunar_01_esplora_la_rete.png
_images/thunar_02_rete_windows.png
_images/thunar_03_workgroup.png
_images/thunar_04_server.png

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

_images/thunar_05_password.png
_images/thunar_06_share.png

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».

_images/PartizionamentoManuale.png

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.

_images/SceltaDisco.png

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).

_images/CreaNuovaTabellaPartizioni.png

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».

_images/SelezioneSpazioLibero.png
_images/NuovaPartizione.png

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.

_images/SelezionaUsareCome.png
_images/SceltaVolumeFisicoRaid.png

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.

_images/ImpostazioneTerminata.png

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
_images/RipetizioneSceltaSpazio.png

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.

_images/SceltaRaidSoftware.png

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.

_images/CreaDeviceMultidisk.png
_images/SceltaRaid1.png

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:

_images/SceltaDischi.png

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.

_images/RiselezioneDischi.png

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:

_images/TerminaRaid.png

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:

_images/SceltaLVM.png
_images/ConfermaLVM.png

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):

_images/LVMCreaVG.png
_images/LVMNomeVG.png

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):

_images/LVMSelezioneDispositivo.png

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»:

_images/LVMCreareLV.png

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».

_images/LVMTermina.png

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:

_images/SceltaImpostaSwap.png

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:

_images/SceltaImpostaRoot.png
_images/SceltaImpostaRootExt4.png

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:

_images/SceltaImpostaRootMP.png
_images/SceltaImpostaRootRadice.png

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».

_images/SelezioneRAIDboot.png

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:

_images/PartizionamentoFinale.png

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

_images/ConfermaFinale.png

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:

_images/ConfigGrub.png

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 applica 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.

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à:

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:

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

    passwd root
    passwd local-fuss
    
  2. Installare i firmware aggiuntivi, solo se necessario; copiare i firmware (*.deb) nella cartella /opt ed installarli con:

    cd /opt
    dpkg -i *.deb
    
  3. 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.

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

    service networking restart
    
  5. 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
    
  6. 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:

_images/P-001.png

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.

_images/P-002.png

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:

_images/N-01.png

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:

_images/N-03.png

salvando la configurazione della rete risulterà la seguente:

_images/N-02.png

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:

_images/N-04.png

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:

_images/P-001.png

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.

_images/P-002.png

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”.

_images/N-05.png

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:

_images/P-007.png

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à:

_images/P-008.png

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

_images/P-009.png

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:

_images/P-010.png

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.

  1. 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)
_images/P-011.png
  1. Sezione: “OS”
  • selezionare “Linux 4.X/3.X/2.6 Kernel”
_images/P-012.png
  1. Sezione: “CD/DVD”
  • espandere tendina “ISO image:”
  • Selezionare la ISO precedentemente caricata (ad esempio: “fuss-server-jessie-amd64-201705221525.iso”)
_images/P-013.png
  1. 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)
_images/P-014.png
  1. Sezione: “CPU”
  • Socket: pari al numero di processori della macchina, vedi istruzioni al punto 4.2
  • Cores: 1
_images/P-015.png
  1. Sezione: “Memory”
  • Memory (MB) : RAM della macchina, scegliere in base alle indicazioni del punto 4.2
  • Togliere il “flag” alla funzione “Ballooning”
_images/P-016.png
  1. Sezione: “Network”
  • Bridge = vmbr0
  • Model = VirtIO (paravirtualized)
_images/P-017.png
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:

  1. Selezionare la VM, ad esempio “100(fuss-server-01)”
_images/P-020.png
  1. Selezionare in alto a destra il tasto “>__Console”
_images/P-021.png
  1. Scegliere “Start”
_images/P-022.png

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.

_images/SelezioneDisco.png

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.

_images/SelezionePartizioni.png

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”:

_images/ScegliPartizGuidato.png

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

_images/SceltaGuidato.png

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

_images/ConfermaScelta.png

ed infine confermare prima le modifiche del disco:

_images/SceltaConLVM.png

e poi la formattazione finale:

_images/SceltaFinale.png

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:

e quindi su ciascuna delle altre macchine:

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:

_images/000-boot_menu.png

Configurazione di Clonezilla

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

_images/a01-ssh_fingerint.png

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

_images/a02-ssh_password.png

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

_images/a03-ssh-confirm.png

Si può quindi avviare Clonezilla:

_images/006-avvia_clonezilla.png

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

_images/007-device-image.png

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

_images/skip_mount.png

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

_images/a05-mount_confirm.png

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

_images/018-modalita_beginner.png

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):

_images/101-savedisk.png

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

_images/102-nome_immagine.png

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

_images/103-disco_da_clonare.png

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:

_images/104-check_filesystem.png

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

_images/105-controllo_immagine_salvata.png

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

_images/106-non_crittare_immagine.png

Selezionare di riavviare il computer alla fine della copia:

_images/107-reboot_alla_fine.png

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

_images/108-comando_per_ripetere.png

Viene chiesta conferma di procedere, scrivere y per continuare:

_images/109-prima_conferma.png

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

_images/109a-clone.png

Fino ad annunciare di essere pronto al riavvio:

_images/110-preparazione_al_reboot.png

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

_images/111-reboot.png

Ripristino di una macchina

Selezionare l’opzione per ripristinare un’immagine da disco:

_images/201-restoredisk.png

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

_images/202-selezione_immagine.png

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

_images/203-selezione_disco.png

Selezionare di verificare l’immagine prima del ripristino:

_images/204-controllo_immagine.png

Selezionare di riavviare il computer alla fine del ripristino:

_images/205-reboot.png

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

_images/206-comando_per_ripetere.png

Clonezilla inizierà a verificare l’immagine selezionata:

_images/206a-verifica.png

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

_images/207-prima_conferma.png
_images/208-seconda_conferma.png

A questo punto verrà effettuato il ripristino:

_images/209-ripristino.png

Fino ad annunciare di essere pronto al riavvio:

_images/209-preparazione_al_reboot.png

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

_images/210-reboot.png

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 in /etc/apt/sources.list:

# deb cdrom:[Official Debian GNU/Linux Live 9.4.0 xfce 2018-03-10T11:37]/ stretch main

deb http://ftp.it.debian.org/debian/ stretch main contrib non-free
deb-src http://ftp.it.debian.org/debian/ stretch main contrib non-free

deb http://security.debian.org/debian-security stretch/updates main contrib
deb-src http://security.debian.org/debian-security stretch/updates main contrib

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

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

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.

  1. 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>.

  2. 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.

  3. 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.
  4. 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.

  5. 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 FUSS8 e ripristinarlo su un server FUSS10, per poter consentire il passaggio da FUSS 8 a FUSS 10 mantenendo la gran parte dei dati presenti sul server di partenza.

Operazioni di dump sul server originario (FUSS8)

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 (FUSS10)

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.

Miniguide

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

Miniguide hardware

PC con requisiti particolari

PC Ultracompatto HP ProDesk 405 G6

Per l’installazione di questo PC si consiglia un kernel >= 5.11 per avere il driver ethernet RealTek r8169 aggiornato. Inoltre è necessario il pacchetto firmware-amd-graphics da buster-backports, che fornisce i driver amdgpu per la scheda grafica integrata AMD Renoir. E” stata preparata l’immagine di FUSS con kernel 5.12 fuss-10-amd64-client-k512-liquorix-20210629-img.tar che va scaricata dal repository FUSS delle immagini e copiata sul server FUSS in /srv/clonezilla/.

Anche Clonezilla, necessario per clonare FUSS sul PC, ha bisogno di un kernel >= 5.11. Ad oggi (22-07-2021) consigliamo di usare la versione alternative stable - 20210609-hirsute (o superiore), l’unica con kernel >= 5.11 copiandola su chiavetta USB in quanto attualmente la versione di clonezilla presente sui server FUSS non incorpora il driver ethernet aggiornato.

Installazione automatica con fuss-fucc

E” solo necessario aggiornare sul server FUSS i pacchetti

  • clonezilla-fuss (v. 2.6.6-15+really20210717-2)
  • fuss-fucc (v. 0.5.11)

alle versioni indicate o superiori.

Installazione manuale

Si seguano i passi indicati per installare manualmente il PC in una rete FUSS:

  • avviare il PC, premere F9 e scegliere il boot da USB;
  • nel menu di clonezilla scegliere l’opzione Clonezilla live (VGA 800x600 & to RAM;
  • cliccare Start_Clonezilla e device-image;
  • scegliere ssh_server e dhcp;
  • impostare l’IP del server e la porta 22;
  • come utente scegliere clonezilla o root;
  • la directory in cui sono memorizzate le immagini sul server è /srv/clonezilla;
  • inserire la password dell’utente clonezilla sul server FUSS;
  • scegliere a menu Beginnner seguito da restoredisk;
  • scegliere l’immagine con kernel fuss-10-amd64-client-k512-liquorix-20210629-img.tar;
  • scegliere il disco nvme0n1 da 250 GB sul quale verrà installata l’immagine di FUSS;
  • optare per lo spegnimento del PC al termine del cloning.

Si seguano infine i passi della sezione HP UEFI boot - no bootable device.

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.

  1. 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
    
  2. 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
    
  3. 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:

_images/acer-tmp214-01.jpg

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

_images/acer-tmp214-02.jpg

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

_images/acer-tmp214-03.jpg
_images/acer-tmp214-04.jpg
_images/acer-tmp214-05.jpg
_images/acer-tmp214-06.jpg

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.

_images/acer-tmp214-07.jpg
_images/acer-tmp214-08.jpg

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

_images/acer-tmp214-09.jpg
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

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:

  1. Riavviare la macchina e premere il tasto per il boot manuale (in genere F9)

  2. 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
  3. 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
  1. A questo punto si deve individuare la voce del menu con la quale siete entrati, ad es. Boot0001

  2. 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.
  1. Nel caso si voglia visualizzare il menu all’avvio, è sufficiente allungare il Timeout a 5 secondi o più con:

    efibootmgr -t 5
    
  2. 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:

audio

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.

_images/hp-pagewide-pro-452dw-01.png

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

_images/hp-pagewide-pro-452dw-02.png

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

_images/hp-pagewide-pro-452dw-03.png

Scegliere la marca della stampante (Make)

_images/hp-pagewide-pro-452dw-04.png

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

_images/hp-pagewide-pro-452dw-05.png

Verificare che il Media size sia correttamente impostato sul formato A4

_images/hp-pagewide-pro-452dw-06.png

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

_images/hp-pagewide-pro-452dw-07.png

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:

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”

_images/1-logo.png

Installate la stampante tramite il tool “Impostazioni di stampa” (system-config-printer), assicurandovi di selezionare il protocollo IPP

_images/2-stampante.png
  • 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
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,
_images/3-icona-stampante.png
  • selezionate la coda di stampa e cliccare su “Proprietà”.
_images/4-stampante.png
  • 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
_images/01-import.jpg
  • Come mostrato qui sotto, cliccate col tasto destro del mouse sulla stampante desiderata, poi su “Impostazioni di comunicazione” e inserite username: Admin ; password: Admin
_images/02-import.png
  • 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.
_images/03-import.png
  • Cliccate col tasto destro del mouse sulla stampante desiderata e selezionate “Imposta più dispositivi account”.
_images/04-import.png
  • 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 .
_images/05-import.png
_images/06-import.png
_images/07-import.png
  • Selezione file *.csv
  • Nella fotocopiatrice verranno creati gli account con le restrizioni scelte
_images/08-import.png

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).

Utilizzare il lettore per la tessera sanitaria o CNS/CPS (Carta Nazionale/Provinciale dei Servizi)

L’attuale distribuzione FUSS incorpora già i pacchetti necessari per il funzionamento del lettore della tessera sanitaria o CPS/CNS 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.

  1. Aprire Firefox e andare in Menu -> Preferenze -> Privacy e Sicurezza; in fondo alla pagina, sotto la voce Certificati cliccare il bottone Dispositivi di sicurezza;
  2. Cliccare il pulsante Carica;
  3. Fornire nel campo Nome Modulo una descrizione, ad esempio «Carta Nazionale dei Servizi»;
  4. 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 lettore Carta 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 €.

_images/Lettore-CIE.png
Installazione
  1. Avviare Firefox e accedere alla sezione Impostazioni del browser:
_images/Impostazioni_firefox.png
  1. Selezionare la scheda Privacy e Sicurezza
_images/PrivacyeSicurezza.png
  1. Cliccare su Dispositivi di sicurezza
_images/Carica_modulo.png
  1. 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).

  1. Per l’utilizzo del lettore si consulti la guida utente al link:

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:

_images/virtio-block-disk.png

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:

_images/virtio-scsi-disk.png

e selezionandolo si potrà attivare l’uso del comando discard, con:

_images/virtio-scsi-disk-discard.png

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
    _images/ups-raptor-groups-800.jpg
  • UPS 800 Riello
    _images/ups-riello-800.png
  • UPS 1kVA Braga Moro
    _images/ups-braga-moro-1kVA.png
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

_images/fig1.jpg

Per attivare la funzionalità penna interattiva bisogna selezionare:

_images/fig2.jpg
  • Selezionare l’impostazione Modo Funzion. Penna e premere il tasto [Enter].
  • Selezionare Modalità Ubuntu e uscire.

Per attivare la funzionalità finger touch bisogna selezionare:

_images/fig3.jpg
  • Selezionare Imp. unità di tocco e premere il tasto [Enter].
  • Selezionare Alimentazione e premere il tasto [Enter].
  • Selezionare On e uscire.
_images/fig4.jpg

Effettuare una calibrazione se necessario. Per questa e altre configurazioni che dovessero essere necessarie consultare il manuale:

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:

oppure da

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
Come ottenere una 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»:

  1. ci si logga come root
  2. si lancia lo script arandr-setup
  3. 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

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

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

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

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

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

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

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

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

e riavviare il servizio con service postfix restart.

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

Nota

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

Aggiornare Proxmox dalla versione 4 alla versione 5

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

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

Predisposizione

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

apt-get update
apt-get dist-upgrade

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

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

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

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

Aggiornamento

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

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

e quelle di Proxmox con:

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

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

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

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

apt-get dist-upgrade

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

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

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

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

Troubleshooting

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

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

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

apt remove linux-image-amd64

procedendo poi con gli aggiornamenti.

Problemi con CD e DVD

Montaggio dei CD-ROM
Problema nel montaggio

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

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

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

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

Soluzione del problema

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

Lo script seguente risolve il problema:

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

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

DVD Zanichelli

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

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

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

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

sh /media/<nome-utente>/<nome-cd>/BooktabZ-StartCD_lnx.sh
Installazione dei DVD-ROM Oxford su FUSS 9
Premessa

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

Problema nel montaggio

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

/dev/sr0       /media/cdrom0   udf,iso9660 user,noauto     0       0
Soluzione del problema

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

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

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

Avvio del programma

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

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

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

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

Installazione adobe-flashplugin

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

apt remove flashplayer-mozilla

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

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

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

Eventuale lanciatore da scrivania

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

1) Cliccare col tasto destro

2) Selezionare ``Crea avviatore``

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

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

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

Impostazioni chromium

Premessa
La seguente miniguida è nata dall’esigenza di risolvere due problemi:
  1. All’avvio del browser chromium viene richiesto insistentemente di inserire la password di sblocco del portachiavi
  2. Diversi utenti vorrebbero che le credenziali di accesso al proxy venissero memorizzate senza dover essere digitate ogni volta.
Soluzione al problema 1

1a) Da root

Modificare il lanciatore di chromium:

vim /usr/share/applications/chromium.desktop

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

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

1b) Da utente normale

  • Creare un lanciatore trascinando l’icona del browser chromium dal menù al pannello e confermando.
  • Cliccare col tasto destro sul lanciatore e selezionare Proprietà. Si apre la finestra:
_images/finestra-avviatore.png
  • 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»).
_images/modifica-avviatore.png
Soluzione al problema 2
  • L’offerta di salvataggio delle credenziali proxy si presenta in modo imprevedibile e difficilmente replicabile; a volte si verifica cancellando la cartella ./config/chromium e deselezionando Accesso automatico in Impostazioni > Persone > Password.
  • Il modo più semplice e certo di ottenere il risultato è quello di utilizzare un’estensione scaricabile da Web store che memorizza le credenziali proxy, che non verranno più richieste. Ovviamente l’utente deve ricordarsi di aggiornarle quando la password dell’account viene cambiata.

Guida Veyon su Fuss 10

Avvertimento

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

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

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

Sulla postazione principale installare veyon-master

apt install  veyon-master

Su tutte le macchine controllate installare veyon-service

apt install  veyon-service

Ciascuno dei due pacchetti porta con sè alcune dipendenze.

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

systemctl enable veyon-service
Sulla postazione principale, nel Menu delle applicazioni (sottomenù Internet) troviamo::
  • Veyon Master
  • Veyon configurator
Creazione gruppo veyon-client

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

In ogni postazione controllata, per semplicita client :

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

#!/bin/bash

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

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

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

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

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

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

Ricordarsi di renderli eseguibili con:

chmod +x Nome-file
Sulla postazione principale :
Premessa:

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

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

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

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

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

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

veyon-configurator.

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

Configurazione generale
_images/generale.png
Servizio
_images/servizio.png
Principale

Non è necessario fare modifiche.

Controllo accessi
_images/controllo-accessi.png
Chiavi di autenticazione

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

Stanze & computer

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

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

_images/stanze-computer.png

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

RENDERE VEYON-MASTER ACCESSIBILE SOLO AI DOCENTI

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

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

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

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

Installazione del pacchetto giochi iprase

Premessa

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

Aggiunta dell’architettura i386

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

dpkg --add-architecture i386

Per aggiornare la cache coi pacchetti i386 si lancia:

apt update

Infine si installa l’applicazione con:

apt install iprase
Installazione in locale con pacchetto .deb

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

dpkg -i iprase_1.1.deb

Share Samba con struttura di sottocartelle

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

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

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

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

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

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

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

(permessi 2770 e gruppo assegnato alla classe).

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

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

Aggiornamento dei fuss-client tramite fuss-cru

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

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

Nota

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

Configurazione per l’uso dell’agent di OCS inventory

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

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

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

acl repositories url_regex ocs.inventory.server

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

Il passo successivo prevede di:

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

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

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

Un esempio di questo file è il seguente:

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

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

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

Nota

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

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

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

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

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

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

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

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

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

In questo test si è utilizzata serverdaupstream ma qualsiasi metodo di installazione di FUSS Server dovrebbe essere equipollente. 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

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

Code GPLv3 Documentation CC BY-SA