Încerc să fac o montare utilizator NFSv4 a unui laptop (spigot, 21.10) pe un server (deuce, 20.04 LTS) cu Kerberos și din anumite motive rpc.gssd nu pot vedea memoria cache a acreditărilor mele. Rețineți că aceasta este 100% o problemă la nivelul clientului, deoarece serverul NFS funcționează deja bine cu un client Mac.
In al meu /etc/fstab pe laptop, am urmatoarele:
deuce:/home/dorian /net/dorian nfs4 sec=krb5p,soft,user,noauto 0 0
Când încerc montură ca eu:
dorian@spigot:~$ mount -t nfs4 -vvvv deuce:/home/dorian
mount.nfs4: timeout setat pentru sâmbătă, 18 decembrie 10:41:06 2021
mount.nfs4: încercarea de opțiuni bazate pe text „sec=krb5p,soft,vers=4.2,addr=172.16.0.254,clientaddr=172.16.0.19”
mount.nfs4: mount(2): Permisiune refuzată
mount.nfs4: acces refuzat de server în timpul montării deuce:/home/dorian
rpc.gssd -f -vvv deversează următoarele:
handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,3,1,2' (nfs/clnt12)
krb5_use_machine_creds: uid 0 tgtname (null)
Numele de gazdă complet pentru „deuce.office.srs.biz” este „deuce.office.srs.biz”
Numele de gazdă complet pentru „spigot” este „spigot”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „[email protected]”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „[email protected]”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „root/[email protected]”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „nfs/[email protected]”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „host/[email protected]”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „SPIGOT$@”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „root/spigot@”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit în timpul obținerii intrării keytab pentru „nfs/spigot@”
Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la obținerea intrării din tabelul de chei pentru „gazdă/spigot@”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
EROARE: Fișierul tabelului de chei „/etc/krb5.keytab” nu a fost găsit la începutul scanării keytab-ului pentru keytab „FILE:/etc/krb5.keytab”
EROARE: gssd_refresh_krb5_machine_credential: nu s-a găsit nicio intrare utilizabilă keytab în keytab /etc/krb5.keytab pentru conexiunea cu gazda deuce.office.srs.biz
EROARE: Nu s-au găsit acreditări pentru conectarea la serverul deuce.office.srs.biz
făcând apel de eroare
(În principal, aceasta este văitarea de lipsa unei tabele de taste; dacă tasta de taste ar fi prezentă, s-ar plânge în schimb că nu există directori în ea.)
Cu alte cuvinte, nici măcar nu încerca pentru a citi ccache-ul Kerberos. Intr-adevar se spune uid=0 ceea ce are sens pentru că rpc.gssd este într-adevăr rulat ca root. Dar sursa de gssd_proc.c sugerează că ar trebui trimiteți la utilizatorul apelant înainte de a încerca să căutați memoria cache a acreditărilor. Cu toate acestea, nu pare să facă asta de fapt. Mai degrabă, ar trebui să obțină uid-ul dintr-un fișier magic în acel ciudat rpc_pipefs montură, iar dacă eu strace rpc.gssd -f -vvv pot vedea că valoarea din acel fișier RPC voodoo este mech=krb5 uid=0 service=*â¦, deci orice ar trebui să seteze asta la uid-ul utilizatorului meu nu o face.
(De remarcat că pe baza sursei, că încercarea de a utiliza un principal de serviciu este declanșată de combinația dintre a serviciu= fiind prezent în acel fișier pipefs împreună cu uid=0.)
Deci întrebarea mea este: ce este responsabil pentru setarea conținutului acelui fișier (/run/rpc_pipefs/nfs/$CLIENT/krb5), și ce incantație trebuie să intonez pentru a o face să spună ceea ce trebuie?
