Tutoriel Linux

Getent su Linux: trovare un account anche se non proviene da /etc/passwd

Débutant3 min de lecture

Avviate id alice su un server, l’account esiste nell’annuario dell’azienda, ma grep alice /etc/passwd non restituisce nulla. Prima di concludere che un account è assente, guardate la vista che Linux utilizza realmente.

getent interroga le basi dichiarate in NSS, il meccanismo che può combinare file locali, SSSD, LDAP o un altro servizio di identità. Potete così sapere se il sistema risolve l’account, il gruppo e il suo identificativo numerico, senza modificare la configurazione.

Tux collega un account Linux ai file locali e a un annuario di rete
Getent consulta le fonti di identità configurate da NSS.

Perché /etc/passwd non dà sempre la risposta

Su una macchina locale, /etc/passwd contiene spesso tutti gli account previsti. Su un server connesso a LDAP o Active Directory tramite SSSD, questo file conserva gli account locali, mentre gli account remoti arrivano tramite NSS.

Il comando getent passwd passa attraverso NSS per risolvere la base passwd con le fonti e l’ordine definiti in /etc/nsswitch.conf.

grep '^passwd:' /etc/nsswitch.conf
grep '^group:' /etc/nsswitch.conf

Una riga come passwd: files systemd sss indica che Linux consulta prima i file locali, poi il servizio di sistema e infine SSSD. Non copiate questo ordine nella vostra configurazione: dipende dalla distribuzione e dall’integrazione già in atto.

Cercare un account con getent

Utilizzate il nome di accesso esatto, senza visualizzare l’intero database. Su un annuario voluminoso, getent passwd da solo può produrre un output lungo e inutile.

getent passwd alice
getent passwd 10542

Se l’account è risolto, l’output segue il formato abituale: nome, marcatore di password, UID, GID, campo descrittivo, directory personale e shell. Un account LDAP o SSSD può quindi apparire qui mentre è assente da /etc/passwd.

Nessun output significa solo che NSS non trova questa voce con la sua configurazione attuale. Questo risultato non corregge né un guasto LDAP, né una cache SSSD, né un errore nel nome richiesto.

Controllare il gruppo e l’identità effettiva

Un account visibile non garantisce che i suoi gruppi siano corretti. Controllate la base group, poi lasciate id visualizzare i gruppi calcolati per questo utente.

getent group progetto-admin
id alice

id alice deve mostrare l’UID, il GID principale e i gruppi aggiuntivi previsti. Se l’account appare con getent passwd alice ma non con id alice, conservate entrambe le uscite e controllate i registri di SSSD o del servizio di identità coinvolto.

Questa lettura aiuta gli strumenti che chiedono a NSS di risolvere un’identità, come id o un servizio configurato con un annuario.

La guida per elencare gli utenti su Linux rimane utile per inventariare gli account locali. Qui, la questione è diversa: il sistema riconosce l’identità nel momento in cui un servizio deve utilizzarla?

Cercare prima, riparare dopo

Terrò getent come primo controllo prima di riavviare SSSD, svuotare una cache o modificare nsswitch.conf. Il comando è in sola lettura e offre lo stesso punto di vista di molti programmi Linux.

  • Confronta l’account richiesto con la riga passwd: di /etc/nsswitch.conf.
  • Avvia getent passwd utente e getent group gruppo.
  • Controlla i gruppi calcolati con id utente.
  • Se manca un’entrata, prendi nota del registro del servizio di identità prima di cambiare la sua configurazione.

Su una stazione locale, getent confermerà spesso il contenuto di /etc/passwd. Su un server collegato a un annuario, questa differenza evita di eliminare o ricreare un account che esiste già sul lato NSS.

La pagina getent(1) di man7 dettaglia le basi disponibili e la ricerca per chiave. Se l’account deve essere creato localmente, utilizzate invece la procedura Useradd su Linux dopo aver escluso un’identità remota.

sudo apt update && sudo apt upgrade