Aggiornamento del server FUSS

Di seguito viene mostrata passo-passo la procedura di aggiornamento di un server FUSS dalla versione 12 alla 13.

Riferimenti sulla FUSS Tech Guide:
Aggiornare il server fuss e lanciare fuss-server upgrade:
apt update apt dist-upgrade fuss-server upgrade
Fare il dump della macchina Proxmox.
Per fare il backup della configurazione di Proxmox, la comunità Proxmox consiglia gli script che si trovano al link https://github.com/DerDanilo/proxmox-stuff
Fare il fuss-backup del vecchio server FUSS;
- il fuss-backup include anche il backup fatto da fuss-dump.sh dove ci sono anche
  - fuss-backup.conf con relativo cron file
  - /opt
Copiare il file /var/backups/fuss-server-dump-yyyy-mm-dd.tgz nella cartella root di Proxmox:
```
scp /var/backups/fuss-server-dump-yyyy-mm-dd.tgz root@IP-PROXMOX-SERVER:.
```
Nota

Per ricavare il fingerprint RSA/ECDSA/ED25519 di un server si può usare il seguente comando:
```
ssh-keygen -lf <(ssh-keyscan $HOSTNAME 2>/dev/null)
```
Seguire la guida https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#installazione-di-fuss-server-dal-template-cloud-init-ready
Connettersi al server Proxmox:
```
ssh root@IP-PROXMOX-SERVER
```

Copiare l’immagine cloudinit presa da http://iso.fuss.bz.it in /var/lib/vz/dump:

cd /var/lib/vz/dump
wget http://iso.fuss.bz.it/cloud-init/vzdump-qemu-fuss-server-13-latest.vma.zst

Spegnere la vecchia VM del server FUSS.
Effettuare il restore dell’immagine cloud-init (da local) in Proxmox
Creare disco cloud-init: Hardware --> Add:
Parametri cloud-init: fare copy-paste dei parametri dalla VM del vecchio server FUSS.
Avviare la nuova VM.
Collegarsi via ssh:
```
ssh root@IP-FUSS-SERVER
```
Nota

La password di root della nuova immagine cloudinit è fuss; va cambiata subito.
Aggiornare i pacchetti:
```
apt update && apt dist-upgrade
```
Copiare da Proxmox il file fuss-server-dump-yyyy-mm-dd.tgz e scompattarlo in /root per poter accedere ai parametri di fuss-server.yaml da inserire dopo aver lanciato fuss-server create:
scp root@IP-PROXMOX-SERVER:fuss-server-dump-yyyy-mm-dd.tgz . tar xvzf fuss-server-dump-yyyy-mm-dd.tgz
apt install fuss-server
Per avere i parametri fuss-server del vecchio server sotto mano:
```
cat fuss-server.yaml.old
```
Lanciare la configurazione del fuss-server:
```
fuss-server create
```
- Può darsi che /var/lib/dpkg/info/cups.postinst rallenti il task misc di ansible (Install package cups, foomatic-db-compressed-ppds by apt). In tal caso stoppare il server cups:
```
systemctl stop cups
```

Fare il restore della configurazione del vecchio server FUSS:

/usr/share/fuss-server/scripts/fuss-restore.sh  fuss-server-dump-yyyy-mm-dd.tgz

Lanciare
```
fuss-server upgrade
```
Copiare eventualmente anche la cartella /opt
Nota

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

Montare i backup FUSS sul NAS e copiare le home degli utenti:

fuss-backup mount
cd /mnt/recover
cd PATH-ULTIMO-BACKUP/home
cp -a * /home

Se invece le /home sono su di un disco separato rispetto alla root /, potete riassegnare quel disco alla nuova VM sempre usando Disk Actions e ricordandovi di andare a riprendere dal backup la riga per il mount della /home dal file /etc/fstab.
Riavviare il server
Se la scuola è dotata di rete WiFi, configurare la nuova infrastruttura basata su WPA Enterprise. Ricordarsi che con la nuova configurazione l’IP deve essere preventivamente assegnato alla scheda di rete quando si lancia fuss-server create --wifi-guest. Si veda https://fuss-tech-guide.readthedocs.io/it/latest/quick-install.html#rete-wifi-wpa-enterprise A tal proposito non dimenticare di ripristinare dal backup il file di configurazione /etc/freeradius/3.0/clients.conf.
Scaricare le due immagini Clonezilla (in formato .tar) dei client FUSS da https://iso.fuss.bz.it/fuss13/client/ scompattandole nella cartella /srv/clonezilla e verificando che abbiano i permessi dell’utente clonezilla.
Nel file /srv/clonezillacomputerList.txt ricordare di modificare il nome delle immagini Clonezilla sostituendole con quelle previste per FUSS 13.
Qualora si usi OCS Inventory, non dimenticare di consultare la guida https://fuss-tech-guide.readthedocs.io/it/fuss12/miniguide_software/ocsinventory.html e di copiare in /var/www/fuss-data-conf i file necessari come indicato.
Dopo aver portato anche i client a FUSS 13, ricordare di resettare le impostazioni di Xfce4 agli utenti usando lo script /usr/share/fuss-server/scripts/home-cleanup. Editare lo script aggiungendo alla variabile CLEAN_LIST il path
```
.config/xfce4/
```
Eseguire lo script una volta e rimuovere poi il path aggiunto al file home-cleanup.
Nota

Non dimenticare di mantenere aggiornata la macchina Proxmox assicurandosi sempre di avere il dump delle VM. Portarla alla versione 9 di Proxmox VE. Seguite le semplici istruzioni sul wiki di Proxmox:
- da 7 a 8: https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
- da 8 a 9: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9

Mantenimento dei client a FUSS 12

Nel caso si decida di aggiornare i client solo in un secondo momento non occorre praticamente fare niente dopo l’aggiornamento del server. Entro al massimo un’ora su ogni client verra eseguito in modalità unattended: fuss-client -U che copierà i nuovi certificati LDAP e consentirà di loggarsi e utilizzare i client come prima.

Aggiornamento in place dei fuss-client da FUSS 12 a FUSS 13

Come alternativa all’installazione da zero dei client con F12 è possibile eseguire l’aggiornamento «in place» dei client da FUSS 12 a FUSS 13 è stato creato un programma dedicato.

Se non già installato, si installa il pacchetto con:

apt update
apt install fuss-release-upgrader

Per avviare la procedura si deve eseguire da terminale:

do_release_upgrade

Questo script ne esegue una serie di altri, divisi in passi successivi ed eseguiti dentro uno screen che permettono di effettuare le varie operazioni per l’in-place upgrade. Il risultato delle singole fasi ed anche il loro eventuale fallimento si può verificare nella cartella di log:

/var/log/fuss-release-updater

Qui si trovano, un una serie di file numerati per ciascun passo, l’output dei comandi eseguiti nello stesso, un file runs.log dove vengono segnate le date di ogni lancio o tentativo di lancio, ed i file Upgrade-Start, Upgrade-Progress, Upgrade-End dove sono registrati rispettivamente l’inizio, la progressione e la fine delle operazioni. Ad ogni esecuzione tutti i file tranne runs.log vengono salvati in una nuova directory run-$(date +%T).

Se si desidera eseguire l’aggiornamento in modalità «unattended», il pacchetto fuss-release-upgrader mette a disposizione lo script unattended_release_upgrade che esegue l’aggiornamento in una sessione di tmux. Una volta avviato si possono usare questi comandi fondamentali di tmux:

tmux ls: per elencare le sessioni attive (si cerchi la sessione update);

tmux attach [SESSION]: per agganciare la (singola) sessione attiva o quella specificate;

con CTRL-B-D si fa il detach della sessione.

Avvertimento

Se per sbaglio si utilizza, per memoria muscolare, CTRL-A-D che è il comando di detach di screen, invece si termina immediatamente il programma, cosa che interrompe la sequenza degli aggiornamenti (salvo il passo in corso, che viene eseguito dentro uno screen) e lascia presente il file di lock /var/run/fuss-release-updater che a quel punto blocca ogni eventuale riesecuzione della procedura. Si faccia attenzione.

In OctoNet si può programmare uno script da lanciare su cluster di macchine, a questo scopo il pacchetto fuss-release-upgrader installa una unit di systemd dedicata per lanciare correttamente l’operazione, che deve essere eseguita esplicitamente con systemctl start fuss-release-upgrader.

Su un fuss-client aggiornato (deve essere stata installata ed aver girato la versione 12.0.82 del fuss-client) questo è quanto basta, e lo script di Octonet può essere semplicemente:

#!/bin/bash

systemctl start fuss-release-upgrader

Se invece il client non è aggiornato, fuss-release-upgrader potrebbe non essere installato; per il funzionamento è sufficiente installarlo e si può provare ad usare uno script come il seguente:

#!/bin/bash

if apt update; then
    if apt-get --yes --fix-broken install; then
        if apt-get --yes install fuss-release-upgrader; then
            systemctl start fuss-release-upgrader
        else
            echo Failing install fuss-release-upgrader
            exit 2
        fi
    else
        echo Failing install apt-get --yes --fix-broken install
        exit 3
    fi
else
    echo Failing apt update, stop
    exit 1
fi

echo fuss-release-upgrader launched

Si tenga presente però che questa versione può fallire se sono in corso gli unattended-upgrades, non riuscendo ad eseguire nessuna delle operazioni richieste con apt. La soluzione più semplice è quella di attendere, come indicato nella nota seguente.

Nota

Sui computer che non sono stati accesi da tempo partirà unattended-upgrades, che avrà bisogno di tempo per arrivare a buon fine: in quel caso è opportuno accendere i PC con lauto anticipo, anche 30-60 minuti prima di prevedere il lancio degli aggiornamenti.

Nota

L’aggiornamento dei client da FUSS 12 a FUSS 13 comporta lo scaricamento di un enorme volume di pacchetti per cui si raccomanda di verificare prima, di avere sufficiente spazio sul disco del server per contenere la cache di apt-cacher-ng. Inoltre si consideri che il primo scaricamento dei pacchetti trixie richiede parecchio tempo, che si riduce nei successivi aggiornamenti di altri client.

Nota

Per l’aggiornamento di notebook configurati per connettersi via «WiFi LAN», consigliamo un aggiornamento via fuss-fucc (F12) in quanto meno dispendioso in termini di tempo.