Project

General

Profile

Segnalazione #359

Rigenerazione o meno di /etc/krb5.keytab

Added by Elena Grandi almost 5 years ago. Updated over 4 years ago.

Status:
Risolto
Priority:
Normale
Start date:
07/27/2017
Due date:
% Done:

100%


Description

Mi è stato fatto notare che dopo aver installato il fuss client, lanciando i seguenti comandi:

fuss-client -a -g
riavvio PC
fuss-client -r
rm /etc/krb5.keytab
fuss-client -a

non viene richiesta identificazione sul server per la creazione di /etc/krb5.keytab.

Questo è dovuto alla presenza di un'altra copia del keytab, /root/krb5.keytab, usata per poter richiedere l'identificazione all'inizio della run.
Il file /etc/krb5.keytab viene correttamente ripristinato da tale copia, e le home funzionano correttamente.

Se il client è collegato allo stesso server, questo è un buon comportamento perché evita che sul server rimangano troppe chiavi di client non più in uso.

Se invece si sta lanciando fuss-client -r per rimuovere il client da un server e passarlo ad un'altra rete ed altro server, bisogna effettivamente ricordarsi di rimuovere anche /root/krb5.keytab; a seconda di quanto frequente è questa operazione può essere il caso di pensare ad un automatismo per farlo.

Notare che nell'uso quotidiano, ad esempio per rilanciare fuss-client -a in seguito ad un aggiornamento del pacchetto fuss-client, non è necessaria (e anzi è lievemente dannosa) la cancellazione e rigenerazione di /etc/krb5.keytab: quel consiglio era stato dato durante la fase di test quando si stava testando la sistemazione di un bug specifico nella generazione del file in questione, ma adesso che quel bug è stato fissato il file può essere lasciato al suo posto tra un esecuzione e l'altra.


Related issues

Related to fuss-client - Segnalazione #387: Configuring Kerberos Authentication Commenti 08/31/2017

Associated revisions

Revision 99c1aae9 (diff)
Added by Elena Grandi over 4 years ago

Add an option to remove an old kerberos key. refs: #359

History

#1 Updated by Michael Guggenberg almost 5 years ago

Possibile prevedere rimozione dei file in questione durante l'operazione fuss-client -a se si passa il client a nuovo server (anche se nuovo server ha stesso nome host e dominio, puo capitare che il server e stato reinstallato con stesso nome host e dominio)?

#2 Updated by Michael Guggenberg almost 5 years ago

#3 Updated by Michael Guggenberg almost 5 years ago

  • Assignee changed from Michael Guggenberg to TRUELITE

#4 Updated by Elena Grandi almost 5 years ago

  • Assignee changed from TRUELITE to Michael Guggenberg

Vedo problematico accorgersi in modo affidabile che si sta passando il client ad un nuovo server, soprattutto se vengono mantenuti i nomi.

Piuttosto si potrebbe aggiungere un'opzione che forzi la cancellazione di quei file: potrebbe andare ugualmente bene?

#5 Updated by Michael Guggenberg over 4 years ago

  • Assignee changed from Michael Guggenberg to TRUELITE

Potrebbe essere soluzione.

#6 Updated by Elena Grandi over 4 years ago

  • Assignee changed from TRUELITE to Paolo Dongilli

implemento?

#7 Updated by Paolo Dongilli over 4 years ago

  • Assignee changed from Paolo Dongilli to Elena Grandi

Elena Grandi ha scritto:

implemento?

Sì, procedi pure.

#8 Updated by Elena Grandi over 4 years ago

  • Status changed from Nuovo to In elaborazione

#9 Updated by Paolo Dongilli over 4 years ago

Ti chiedo anche per favore di documentarlo nel wiki.

#10 Updated by Elena Grandi over 4 years ago

  • Assignee changed from Elena Grandi to Michael Guggenberg

Implementata l'opzione --purge (-p) che rimuove le chiavi kerberos, da usare in caso di cambio server.
Pubblicata la nuova versione di fuss-client (8.0.23) che la supporta; ovviamente non è necessario riapplicare fuss-client sulle macchine già configurate.

Ho scritto della documentazione su Uso di fuss-client che spiega anche (come già scritto su questo ticket) le motivazioni dell'opzione, per memoria futura.

Non riesco però a modificare https://work.fuss.bz.it/projects/fuss/wiki per aggiungerla all'elenco.

#11 Updated by Elena Grandi over 4 years ago

  • Status changed from In elaborazione to Commenti

#12 Updated by Michael Guggenberg over 4 years ago

  • Status changed from Commenti to Risolto
  • % Done changed from 0 to 100

Also available in: Atom PDF