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

Il 17/11/20 14:21, Simone Piccardi ha scritto:

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.

Incredibile! E chi lo sapeva? NON c'è scritto nella guida che ho pushato su RTD. Parto da questo spunto per alcune mie considerazioni personali.

Sono 5+ anni che contribuisco al progetto FUSS e da allora Truelite mi ha sempre trattato come se fossi una scimmia appena scesa da un albero perché teme che le si """rubi""" il lavoro. Vi devo dare subito una notizia: questo NON è open source. Starsene a Firenze a scrivere "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" invece che recepire le pull requests di chi sul territorio si fa il mazzo, NON è open. Mettere me a sistemare la compliance di PEP8 (purtroppo non mi invento nulla https://work.fuss.bz.it/issues/58) su codice che avete scritto voi, NON è open.

Simone, se hai qualcosa in contrario alla procedura che ho proposto oltre al fatto che sono io l'autore, si apprezzano ovviamente i commenti al riguardo ma si apprezza ancora di più che tu la corregga, la testi e poi la pubblichi.

Se questi 5 anni non vi fossero bastati, ve lo metto nero su bianco: trattarmi con sufficienza ed indisponenza non mi ha fatto desistere in passato, non mi fa desistere ora e non lo farà in futuro. Io credo in FUSS e per questo motivo contribuisco fattivamente al suo avanzamento. Sono rammaricato di non vedere lo stesso da parte vostra*. Se poi la chiusura del progetto arriverà veramente, non si potrà negare che questo abbia sicuramente inciso.

-Marco

* ad onor del vero, devo scusarmi con Elena per quanto scrivo, che si è sempre comportata in maniera più che corretta nei miei confronti. Cosa molto apprezzata.

Buongiorno a tutti,

oggi ho tentato la migrazione di FUSS Server 8 a 10 con la guida https://fuss-tech-guide.readthedocs.io/it/latest/restore.html .

Sfortunatamente, non è andata a buon fine. Terminato il restore con lo script e l'estrazione delle home da borg, i [vecchi] client, falliscono la unit home.mount. I log del server riportano

Additional pre-authentication required

Il problema sembra dunque legato a Kerberos. Non ho trovato soluzione se non reinstallare da zero, fuss-server create, rm /var/lib/ldap, slapadd, chown, estrazione dei file dal tar (compresi firewall*, dhcp, db di octonet ecc) [sostanzialmente il percorso seguito dallo script], /var/lib/krb5kdc e /etc/krb5* . A questo punto i client non manifestano alcuna rimostranza nel funzionare in maniera normale.

Un caro saluto,

Marco

Il 17/11/20 14:21, Simone Piccardi ha scritto:

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