Project

General

Profile

Segnalazione #253

Problema con fuss-client -a

Added by Piergiorgio Cemin over 7 years ago. Updated over 7 years ago.

Status:
Chiuso
Priority:
Urgente
Assignee:
Elena Grandi
Start date:
05/12/2017
Due date:
% Done:

0%

Estimated time:

Description

Dando il comando fuss-client -a
ottengo questo errore (su due client)
Successivamente non accedo con utente pcemin
id pcemin su client dà No such user
client client1 e client2 da berta.fussbox.blz

Errore alla fine:
TASK [homes : Remount /home] *******************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["systemctl", "start", "home.mount"], "delta": "0:00:00.141333", "end": "2017-05-12 11:15:35.057329", "failed": true, "rc": 1, "start": "2017-05-12 11:15:34.915996", "stderr": "Job for home.mount failed. See 'systemctl status home.mount' and 'journalctl -xn' for details.", "stdout": "", "stdout_lines": [], "warnings": []}
to retry, use: --limit @/usr/share/fuss-client/connect.retry

Files

typescript (15 KB) typescript Piergiorgio Cemin, 05/16/2017 09:50 AM

History

#1

Updated by Christopher R. Gabriel over 7 years ago

  • Project changed from Octofuss to fuss-client
  • Assignee changed from Christopher R. Gabriel to Simone Piccardi
#2

Updated by Piergiorgio Cemin over 7 years ago

  • Status changed from Nuovo to Commenti

Sistemato il problema ldap: era dovuto al fatto che in /etc/hosts era finito l'indirizzo pubblico
80.22.104.69 berta.fuss.bz.it berta
invece che
192.168.0.1 berta.fussbox.blz berta
(sempre che questo vada bene)
Resta ancora il problema delle /home che non vengono montate.
Ecco l'errore.
Se provo il muont manuale ottengo
mount.nfs: access denied by server while mounting 192.168.0.1:/home
e in /var/log/syslog
May 12 17:27:26 client2 rpc.gssd2765: ERROR: No credentials found for connection to server 192.168.0.1

#3

Updated by Piergiorgio Cemin over 7 years ago

Aggiungo output di systemctl status home.mount -l

root@client2:/var/home/piero# systemctl status home.mount -l
  • home.mount - "Mount /home"
    Loaded: loaded (/etc/systemd/system/home.mount; enabled)
    Active: failed (Result: exit-code) since ven 2017-05-12 17:46:01 CEST; 2min 49s ago
    Where: /home
    What: 192.168.0.1:/home
    Process: 5406 ExecMount=/bin/mount -n 192.168.0.1:/home /home -t nfs4 -o defaults,rsize=8192,wsize=8192,noatime,sec=krb5 (code=exited, status=32)

mag 12 17:46:01 client2 systemd1: Mounting "Mount /home"...
mag 12 17:46:01 client2 systemd1: home.mount: Directory /home to mount over is not empty, mounting anyway.
mag 12 17:46:01 client2 mount5406: mount.nfs4: access denied by server while mounting 192.168.0.1:/home
mag 12 17:46:01 client2 systemd1: home.mount mount process exited, code=exited status=32
mag 12 17:46:01 client2 systemd1: Failed to mount "Mount /home".
mag 12 17:46:01 client2 systemd1: Unit home.mount entered failed state.

#4

Updated by Simone Piccardi over 7 years ago

  • Assignee changed from Simone Piccardi to Piergiorgio Cemin

Per capire il problema mi servono dei dettagli maggiori.

1) quale era il problema LDAP e su quale macchina. Un fuss server (nel caso berta) interroga sempre LDAP su localhost, quindi il cambio di /etc/hosts non dovrebbe avere alcun effetto, e non mi quadra che abbia risolto qualcosa.

2) per capire gli eventuali errori nell'esecuzione del comando fuss-client serve la sessione completa con tutti i messaggi riportati, questa si ottiene in maniera analoga come si fa con il fuss server, lanciando il comando in un terminale con la procedura illustrata in questa pagina https://work.fuss.bz.it/projects/server/wiki/Bug_Reporting (lanciando però fuss-client -a)

#5

Updated by Piergiorgio Cemin over 7 years ago

Ecco il file con tutto l'output.

#6

Updated by Elena Grandi over 7 years ago

  • Assignee changed from Simone Piccardi to Elena Grandi
#7

Updated by Elena Grandi over 7 years ago

  • Assignee changed from Elena Grandi to Piergiorgio Cemin

Qui il problema è stato quasi sicuramente nella configurazione di kerberos, che non è andata a buon fine.

Purtroppo nel typescript allegato si vede quella che sembra essere una run successiva, in cui la configurazione kerberos non viene ripetuta, e quindi non si scopre quale sia stato l'errore.

Per far ripetere la configurazione di kerberos si può cancellare, sul client, il file /etc/krb5.keytab e poi rilanciare fuss-client.

(non è una buona pratica in produzione, dato che lascia un po' di rimasugli sul server, ma in fase di test non fa comunque danni.)

#8

Updated by Piergiorgio Cemin over 7 years ago

  • Status changed from Commenti to Chiuso
  • Assignee changed from Piergiorgio Cemin to Elena Grandi

Ho verificato e ora funzaiona. Chiudo il ticket
Grazie

Also available in: Atom PDF