Network Information Service (NIS), originariamente chiamato Yellow Pages (YP), è un servizio di nomi/directory (naming service) di tipo client-server, usato soprattutto in ambienti Unix e sistemi Unix-like per distribuire in rete dati amministrativi e di configurazione (per esempio utenti, gruppi, host, alias di posta e tabelle testuali simili). NIS organizza le informazioni in database chiamati mappe (maps), mantenuti in forma autorevole su un server master e replicati su uno o più server slave/replica; i client interrogano le mappe per risolvere nomi e ottenere attributi (ad esempio la riga per un determinato utente).

Dal punto di vista dei protocolli, NIS usa ONC RPC (detto anche Sun RPC) e i meccanismi di binding tramite portmapper/rpcbind per pubblicare e risolvere dinamicamente le porte dei servizi RPC associati a NIS.

NIS è spesso considerato una tecnologia legacy per via di limiti strutturali e, soprattutto, di sicurezza; molte piattaforme moderne incoraggiano la migrazione verso servizi basati su LDAP e soluzioni di identity management più recenti.

Storia Origini e diffusione Secondo documentazione tecnica di Sun BluePrints, NIS (all’epoca noto come Yellow Pages) era già disponibile nel 1985 e si è affermato come soluzione per centralizzare file amministrativi che, in precedenza, andavano replicati manualmente su ogni host.

Cambio di nome da Yellow Pages a NIS Nei manuali e nelle man page, NIS viene descritto come “precedentemente noto” con il nome Yellow Pages (YP) e il cambio di denominazione viene ricondotto a questioni di marchio nel Regno Unito, dove “Yellow Pages” risulta un marchio registrato di British Telecommunications plc.

Evoluzione: NIS+, migrazione verso LDAP e stato su Solaris Sun sviluppò NIS+ come evoluzione di NIS, introducendo (tra le altre cose) una struttura di naming più ricca e meccanismi di sicurezza/controllo accessi più articolati.

In ambiente Solaris sono stati forniti strumenti e meccanismi di migrazione verso repository LDAP (NIS→LDAP, spesso indicato come N2L).

NIS+ non è più distribuito con il sistema operativo Oracle Solaris (rimozione annunciata e documentata), mentre NIS continua a risultare presente in Oracle Solaris 11.x, anche se con avvertenze sul futuro supporto. Panoramica tecnica Architettura generale Un’installazione NIS è organizzata in uno o più domini NIS (NIS domain), concettualmente separati dai domini DNS: un dominio NIS non deve rispecchiare un dominio DNS e l’amministrazione può scegliere confini diversi.

I ruoli principali sono: server NIS (demone ypserv) che pubblica mappe per uno o più domini; client NIS che, tramite ypbind, mantiene informazioni di binding (a quale server rivolgere le richieste) e consente alle librerie/strumenti di interrogare le mappe.

Il server può gestire più domini individuandoli come sottodirectory (tipicamente sotto /var/yp).

Mappe (maps) Una mappa è un database chiave→valore derivato spesso da file testuali (per esempio passwd, group, hosts, services). La nomenclatura delle mappe include varianti come “.byname” o “.byuid” (chiave: nome oppure UID).

Gli strumenti “yp*” permettono di interrogare le mappe (es. ypcat per stampare valori, ypmatch per cercare una chiave, ypwhich per vedere il server correntemente usato o il master di una mappa).

Archiviazione locale delle mappe Le mappe sono memorizzate come database DBM (key/value) e le implementazioni possono differire sul backend: alcune documentazioni (Solaris) citano ndbm, mentre su Linux sono comuni backend gdbm o Berkeley DB (a seconda dell’implementazione).

Replicazione: master e slave La propagazione delle mappe verso server slave avviene tipicamente tramite: ypxfr (pull: lo slave trasferisce una mappa dal master); yppush (push: dal master “invita” gli slave a eseguire un trasferimento); opzionalmente ypxfrd come servizio per accelerare trasferimenti di mappe grandi.

Protocolli, RPC e rpcbind/portmapper ONC RPC definisce chiamate remote con encoding XDR e prevede che i servizi si registrino tramite un binder (rpcbind/portmapper). NIS è associato a specifici RPC program numbers assegnati storicamente (per esempio “yellow pages (NIS)” 100004 per ypserv, e “yp binder (NIS)” 100007 per ypbind).

Sicurezza Problemi strutturali Il modello di sicurezza di NIS è tradizionalmente basato su una rete “fidata”: la sola conoscenza di nome dominio NIS e hostname del server può essere sufficiente per interrogare mappe, e l’assenza di cifratura/strong authentication rende possibili attacchi di sniffing e spoofing in diversi scenari.

Un rischio specifico è l’esposizione di informazioni sensibili nelle mappe di password: diverse guide sottolineano la necessità di evitare la propagazione dell’account root e di proteggere i file sorgente usati per generare le mappe password.

Mitigazioni tipiche Implementazioni di ypserv supportano spesso un file “securenets” (ad esempio /var/yp/securenets) per limitare le reti/host autorizzati a interrogare mappe e richiedere trasferimenti.

Documentazione di sicurezza evidenzia però che questa misura non previene, da sola, attacchi basati su spoofing IP e va integrata con controlli di rete (segmentazione, firewalling, limitazione broadcast) e buone pratiche operative.

Implementazioni e varianti Implementazioni NIS (YP) su Unix-like In ambito Linux è comune l’uso di ypserv (server) e strumenti client come yp-tools, spesso mantenuti come “Linux NIS Project”.

Il repository di progetto specifica che ypserv implementa il protocollo YP/NIS v2 (non NIS+).

Sistemi *BSD includono storicamente supporto a YP/NIS con demoni e man page dedicati (ypserv/ypbind).

NIS+ NIS+ è stato progettato come sostituto di NIS, con funzionalità aggiuntive (naming più strutturato e meccanismi di autenticazione/controllo accessi).

In Solaris, NIS+ è integrato con meccanismi come Secure RPC per l’autenticazione; la documentazione descrive l’uso di credenziali DES e la gestione di access rights su oggetti NIS+.

Oracle documenta la rimozione di NIS+ da Oracle Solaris, mantenendo strumenti di migrazione verso LDAP.

NIS→LDAP e “compatibilità YP” su LDAP In Solaris esiste un servizio di transizione NIS→LDAP (N2L) che consente a client NIS di consumare dati mantenuti in un directory server LDAP, tramite mapping tra mappe NIS e strutture LDAP e gestione cache/TTL.

In OpenBSD esiste una soluzione (ypldap) che espone mappe YP usando LDAP come backend, descritta da man page e file di configurazione dedicati.

Esempi d’uso e configurazione Impostazione del dominio NIS La variabile di “dominio” usata da NIS è consultabile/impostabile con comandi come domainname e rappresenta il dominio NIS (non necessariamente il dominio DNS).

# Mostra il dominio NIS domainname

# Imposta il dominio NIS per la sessione corrente domainname example-nis

Configurazione del binding client (ypbind) Molte implementazioni supportano /etc/yp.conf come file di configurazione del binding per ypbind, con modalità “server list” o “broadcast”.

Esempio (server espliciti): domain example-nis server nis-master.example.org domain example-nis server nis-slave1.example.org

Esempio (binding via broadcast locale): domain example-nis broadcast

Integrazione con Name Service Switch (nsswitch.conf) Nei sistemi che usano NSS (Name Service Switch), l’ordine delle fonti per database come passwd/group/hosts è definito in /etc/nsswitch.conf.

Esempio minimale: passwd: files nis group: files nis hosts: files dns nis

Query delle mappe # Visualizza tutte le coppie (chiave/valore) di una mappa ypcat passwd.byname

# Cerca una chiave in una mappa ypmatch alice passwd.byname

# Identifica il server NIS attualmente usato dal client ypwhich

Aggiornamento e propagazione mappe Un modello tipico è rigenerare le mappe sul master e propagare verso gli slave (yppush/ypxfr).

# Sul master: ricostruzione mappe (meccanismo e path variano) cd /var/yp make

# Sul master: richiede agli slave di aggiornarsi yppush passwd.byname

Confronto tra NIS, NIS+ e LDAP + Confronto sintetico Caratteristica NIS (YP) NIS+ LDAP Modello dati Mappe key/value (tabelle “piatte” derivate da file) Namespace e oggetti/tabelle con semantica più ricca Directory tree (DIT), schema estensibile Trasporto/protocollo ONC RPC + binder (rpcbind/portmapper) ONC RPC (con estensioni e sicurezza NIS+) TCP (tipicamente) con meccanismi di autenticazione/estensioni (LDAPv3) Sicurezza (in-transit/auth) Limitata; modello “rete fidata”, mitigazioni perimetrali (securenets, filtri) Più articolata; uso di Secure RPC e access rights su oggetti Variabile: può supportare TLS/StartTLS e controlli di accesso granulari (dipende dall’implementazione) Scalabilità/uso tipico Piccole/medie reti, ambienti storici, compatibilità legacy Principalmente legacy; su alcune piattaforme rimosso/abbandonato Enterprise/ambienti moderni (directory service), spesso integrato con SSO/IdM Stato attuale (2020s) Tendente a deprecazione/rimozione in più distribuzioni; ancora usato in contesti legacy Rimosso da Solaris 11; strumenti di migrazione disponibili Standard de facto per molte directory moderne Alternative moderne e rilevanza attuale Per sistemi nuovi, molti vendor raccomandano di migrare verso soluzioni basate su LDAP/SSSD/IdM o equivalenti: per esempio RHEL 9 documenta la rimozione dei componenti NIS e suggerisce Identity Management e SSSD.

Fedora ha proposto e implementato il ritiro dei programmi user-space NIS(+) (ypbind/ypserv/yp-tools) nelle release recenti, motivando la scelta con deprecazione e scarsa sicurezza del modello NIS(+) e con la disponibilità di alternative come LDAP/FreeIPA.

Oracle Solaris segnala che i componenti NIS potrebbero non essere disponibili in aggiornamenti futuri e indica LDAP naming services come alternativa.

Voci correlate ONC RPC LDAP DNS Name Service Switch Solaris

Note

Collegamenti esterni

Categoria:Protocolli di rete Categoria:Servizi di rete Categoria:Unix Categoria:Amministrazione di sistema