Distribuzione FUSS » Server » fuss-server

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.

Ops, dimenticata la riassegnazione.

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.

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

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

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.

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