Additional pre-authentication required
Il 17/11/20 08:53, Marco Marinello ha scritto:

Buongiorno a tutti,

in accordo con Paolo scrivo questa e-mail con l'intento di avviare un
thread sulla /soft migration/ di FUSS Server.

La procedura che è attualmente documentata
su https://fuss-tech-guide.readthedocs.io/it/latest/incubatore/migrazione_soft.html
è quella che ho studiato io la settimana scorsa e testato, con esito
positivo. Una possibile controindicazione del metodo proposto è la
mancata conservazione delle samba??password che immagino dia problemi
alle reti Windows. Workaround potrebbe essere far scadere subito le
password di tutti gli utenti. Soluzione a questo problema - immagino -
sarebbe migrare l'albero con slapcat / slapadd. Riconosco renderebbe
anche la procedura più scorrevole. Se la cosa non genera problemi e non
intacca il server 10 (è cambiato lo schema? se ne installa uno più
vecchio così?) si potrebbe fare questo cambiamento.

Mi pare manchino anche la migrazione dei cluster, le quote disco e i
permessi degli utenti su octonet, oltre alle password di samba. Gli
schemi di LDAP non sono cambiati, ma per quelli come per altri dati ci
sono delle informazioni mantenute anche nel DB di octonet che è meglio
riprendere direttamente.

Inoltre per kerberos è preferibile partire dal dump/restore fornito dal
progetto piuttosto che ricopiare tutti i file.

Su git ci sono, nella directory script del fuss-server, degli script per
fare un dump e restore dei dati di un fuss server 8 su un fuss server
10, ma non sono stati ancora provati a fondo e non sono completi (manca
la parte del captive portal) e non prevedono il ripristino dei dati
delle home che va gestito a parte.

Se serve eseguire una migrazione fatecelo sapere, perché avere del
feedback su questo, come su altri aspetti del progetto, è estremamente
utile, ed inoltre aiuta a coordinarsi nello sviluppo.

Riguardo l'installazione, cerco di chiarire i motivi della scelta: ho
preferito partire dall'immagine del Cloud Team di Debian perché a lavoro
usavamo template fatti come (penso) quello di FUSS Server ovvero
installando la macchina virtuale da iso e poi installando il pacchetto
cloud-init. Questo creava però diversi problemi per cui alla fine quasi
mai la macchina era realmente fruibile: copia della chiave SSH,
scrittura del resolv.conf o configurazione delle interfacce di rete
erano complicazioni all'ordine del giorno. Questo unito al desiderio di

Sarebbe stato utile conoscere i dettagli di questi problemi, per
risolverli.

L'aggiornamento delle chiavi SSH fatto da cloud può essere evitato, e
l'impostazione di resolv.conf e della rete, quando si usa cloud-init,
deve essere fatto passando da li, è uno dei vantaggi principali
(consente di gestire IP e DNS dall'interfaccia di Proxmox). Se ci sono
problemi vanno investigati e risolti.

Lo scopo dell'immagine cloud-init di FUSS è quello di avere i pacchetti
di fuss già installati per non doverli riscaricare, avere una
configurazione standard per l'accesso a root (che l'immagine cloud-init
di debian disabilita) ed avere una swap.

Come dicevo se ci sono problemi con l'uso di quell'immagine è opportuno
affrontarli e risolverli. L'altro vantaggio dell'uso di cloud-init, che
va pesato sulle esigenze specifiche, è che automatizza l'estensione dei
dischi, posto che si usi una partizione unica, e non è necessario dover
ripartizionare ed estendere a mano. Ma questa funzionalità non è
supportata per una home separata.

partire da un'immagine il più aggiornata possibile e la consapevolezza
che fuss-server dovrebbe riuscire a tirarsi su tutto da solo mi ha
portato a questa decisione che, non nascondo, porta la speranza di una
maggiore consapevolezza da parte dei tecnici nell'uso dei dischi in
Proxmox che spesso saturano l'LVM con conseguenti problemi, senza
contare che in futuro avere già le home su un disco separato
semplificherebbe ulteriormente la migrazione.

La home separata su un secondo disco coi suoi vantaggi è ottenibile
indipendentemente dall'uso dell'immagine di cloud-init di debian, di
quella di FUSS o dell'installazione da un template di Debian, ed è una
cosa che può essere opportuno documentare in separata sede, dato che
comunque è applicabile a qualunque installazione in cui non ci sia.

Ma non è questo che risolve l'eventuale saturazione degli LVM se vengono
fatti troppo snapshot che avvengono comunque a livello di VM, la
saturazione di LVM va capita e gestita indipendentemente dall'uso di una
/home separata perché comunque riguarda anche quella.

In ultimo, riguardo systemd da backports, ecco le motivazioni:
https://github.com/ansible/ansible/issues/71528 . Sia fuss-server che
fuss-client falliscono senza il workaround di aggiornare systemd. Io mi
sono limitato a cercare la via più semplice, non so se ci siano altri
workaround meno invasivi.

Installare pacchetti da backports significa sostanzialmente rinunciare
agli aggiornamenti degli stessi.

Se però l'esecuzione di fuss-server o fuss-client fallisce sarebbe
opportuno sapere dove, perché non deve accadere e occorre diagnosticare
il problema e risolverlo. Non mi risulta però che né su fuss-server né
su fuss-client sia previsto l'uso di docker da parte dei playbook e
quindi non capisco l'incidenza del bug segnalato.

Considerato che systemd è al cuore del sistema direi che prima di
ricorrere ad un backport di systemd in maniera generica occorre
esplorare tutte le strade per le possibili alternative, a partire dalla
 valutazione dell'uso di alternative a docker.

Simone