Project

General

Profile

Segnalazione #392

condivise home nfs4 - mappature uid gid

Added by Michael Guggenberg almost 5 years ago. Updated almost 4 years ago.

Status:
Chiuso
Priority:
Urgente
Start date:
09/01/2017
Due date:
% Done:

100%


Description

Non vengono mappate uid e gid di utenti creati da interfaccia web octonwet se la home di un utente è condivisa attraverso filesystem nfs4.

outout uid e gid di un utene esemplare:
[prova@240300winfo-117:~]id
uid=10762(prova) gid=513(Domain Users) gruppi=513(Domain Users),24(cdrom),29(audio),46(plugdev),116(scanner),516(docenti)
[prova@240300winfo-117:~]logout

[prova@240300winfo-117:~]ls lah
totale 24K
drwx-----
2 4294967294 4294967294 4,0K lug 26 11:43 .
drwxr-xr-x 90 root root 4,0K ago 29 15:23 ..
rw------ 1 4294967294 4294967294 220 nov 5 2016 .bash_logout
rw------ 1 4294967294 4294967294 3,5K nov 5 2016 .bashrc
rw------ 1 4294967294 4294967294 1,3K lug 26 11:43 .fuss_profile
rw------ 1 4294967294 4294967294 699 lug 26 11:43 .profile

Vengono invece mappati corettamente uid e gid di utenti importati da file csv.

photo_2017-11-15_02-53-17.jpg View - file con permessi nobody/nogroup (193 KB) Paolo Dongilli, 11/15/2017 03:31 AM

History

#1 Updated by Simone Piccardi almost 5 years ago

  • Assignee changed from TRUELITE to Simone Piccardi

#2 Updated by Simone Piccardi almost 5 years ago

  • Status changed from Nuovo to In elaborazione

A quel che ho visto facendo dei test il problema non attiene alla modalità in cui viene creato l'utente, quanto al quanti ce ne sono in totale.

Il problema attiene al fatto che il kernel tiene una mappa delle risoluzioni UID-utente in cache come chiavi. Il problema è che se gli utenti sono molti la cache si riempie e questo fa si che idmapd cessi di eseguire la mappatura e risponda con l'UID di default associato a nfsnobody (4294967294).

Usando il comando nfsidmap -c la cache viene svuotata, ed idmapd riprende a funzionare regolarmente, ma questo potrà continuare solo finché la cache non si riempie di nuovo.

Il problema è la dimensione di default per il numero di chiavi della cache è 200, cosa che in tutte le prove fatte era più che sufficiente, ma che nel caso in questione (verificatosi sulla scuola Pascoli) non lo è, essendoci circa 800 utenti.

Quello che succede è che all'avvio la cache si riempie e idmapd smette di funzionare, si può verificare la situazione in /proc/key-users (contano le ultime due coppie di numeri a destra, rispettivamente il numero attuale di chiavi/massimo e dimesione attuale delle chiavi/massimo), questo il risultato dopo l'avvio:

# cat /proc/key-users 
    0:   206 205/205 199/200 7186/20000
# ls -l /home/ | grep ospite10
drwx------   2 4294967294 4294967294    4096 lug 26 11:43 ospite10
# nfsidmap -c
# cat /proc/key-users 
    0:    10 9/9 3/200 31/20000
# ls -l /home/ | grep ospite10
drwx------   2 ospite10  Domain Users    4096 lug 26 11:43 ospite10

la soluzione è impostare dei limiti più alti per il numero di chiavi (e per la loro dimensione, ma questa è meno critica). Serve però avere una stima del valore massimo di utenti che si possono avere per mettere dei valori non inutilmente esagerati.

Ho messo come valori per una prova:

kernel.keys.root_maxbytes = 100000
kernel.keys.root_maxkeys = 2000

ottenendo dopo l'avvio:

# cat /proc/key-users 
    0:   781 780/780 774/2000 27961/100000
# ls -l /home/ | grep ospite10
drwx------   2 ospite10  Domain Users    4096 lug 26 11:43 ospite10

una volta stabilito un valore adeguato per i due parametri precedenti il nuovo pacchetto del fuss client (che sto predisponendo) provvederà ad installare il dovuto.

#3 Updated by Simone Piccardi almost 5 years ago

  • Assignee changed from Simone Piccardi to Paolo Dongilli

Ops, dimenticata la riassegnazione.

#6 Updated by Simone Piccardi almost 5 years ago

  • Status changed from In elaborazione to Commenti
  • Assignee changed from Paolo Dongilli to Michael Guggenberg

Ho visto (grazie ai link di Michael) che i due default dei limiti sono stati alzati nei kernel recenti a valori che vanno ben al di là del possibile numero di utenti di un fuss-server. Pertanto ho provveduto ad aggiungere al fuss-client dei sysctl per eseguire una impostazione per i limiti analoga a quella dei kernel più recenti.

La correzione riguarda il client (non il server), ed è disponibile con il nuovo pacchetto (fuss-client 8.0.20). Riassegno a Michael per verifiche.

#7 Updated by Michael Guggenberg almost 5 years ago

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

#8 Updated by Michael Guggenberg almost 5 years ago

  • Status changed from Risolto to Chiuso

#9 Updated by Paolo Dongilli over 4 years ago

Mi è capitato in due circostanze (2 scuole) recentemente (l'ultima ieri) di vedere owner/group di 1 o più file nella /home sul server mutare a nobody/nogroup per poi tornare alla normalità dopo alcuni minuti.

In entrambi i casi fuss-client sui PC in uso era aggiornato a 8.0.22.

Come detto, dopo alcuni minuti (non calcolati) la situazione è tornata alla normalità e owner/group erano quelli attesi.

In entrambi i casi un

# cat /proc/key-users

mi restituiva nelle ultime due coppie di numeri

maxkeys=1000000 e maxbytes=25000000

quindi OK.

Mi chiedo se per qualche motivo che non mi spiego ricadiamo nel terzo caso (3. idmapd is caching old information) descritto al link https://www.novell.com/support/kb/doc.php?id=7005060

#10 Updated by Simone Piccardi over 4 years ago

  • Assignee changed from Simone Piccardi to Paolo Dongilli

Si tratta quasi certamente della casistica illustrata, i PC su cui hai rilevato il problema da quanto tempo erano stati accesi?

#11 Updated by Paolo Dongilli over 4 years ago

  • Assignee changed from Paolo Dongilli to Simone Piccardi

Simone Piccardi ha scritto:

Si tratta quasi certamente della casistica illustrata, i PC su cui hai rilevato il problema da quanto tempo erano stati accesi?

Non so dirtelo con esattezza. Uno l'ho trovato già acceso quando sono intervenuto; un altro PC è stato acceso sul momento. Nell'altra scuola potrei dirti dopo un'oretta.

#13 Updated by Michael Guggenberg about 4 years ago

  • Assignee changed from Simone Piccardi to Paolo Dongilli

#14 Updated by Paolo Dongilli almost 4 years ago

  • Status changed from Commenti to Chiuso

Dopo almeno 4 mesi e comunque dopo l'aggiornamento a FUSS 9 non abbiamo più notato questo comportamento. Chiudo la issue.

Also available in: Atom PDF