NIS, che sta per Network Information Services, fu sviluppato da Sun Microsystems per centralizzare l'amministrazione di sistemi UNIX® (in origine SunOS™). Ora in sostanza è diventato uno standard di settore; tutti i sistemi UNIX like (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, etc) supportano NIS.
NIS in precedenza era noto come Yellow Pages, ma per una questione di marchi, Sun ha cambiato il nome. Il vecchio termine (e yp) è ancora si incontra ancora spesso.
E' un sistema client/server basato su RPC che permette ad un gruppo di macchine in un dominio NIS di condividere un insieme comune di file di configurazione. Questo permette ad un amministratore di sistema di installare sistemi client NIS con il minimo di dati di configurazione e di aggiungere, rimuovere o modificare dati di configurazione da una singola macchina.
E' simile al sistema di domini di Windows NT®; anche se le implementazioni interne dei due sistemi sono del tutto diverse, le funzionalità base possono essere paragonate.
Ci sono parecchi termini e molti importanti processi utente che incontrerai quando cercherai di implementare NIS su FreeBSD, sia che cerchi di creare un server NIS sia che cerchi di installare un client NIS:
| Termine | Descrizione |
|---|---|
| Nome dominio NIS | Un server NIS master e tutti i suoi client (inclusi i suoi server slave) hanno un nome dominio NIS. Analogamente al nome dominio di Windows NT, il nome dominio NIS non ha nulla a che fare con il DNS. |
| rpcbind | Deve essere in esecuzione al fine di abilitare RPC (Remote Procedure Call, un protocollo di rete usato da NIS). Se rpcbind non è attivo, sarà impossibile portare in esecuzione un server NIS o fungere da client NIS |
| ypbind | Esegue il “bind” di un client NIS al suo server. Prenderà il nome dominio NIS dal sistema, e, usando RPC, si connetterà al server. ypbind è il fulcro di una comunicazione client-server in ambiente NIS; se ypbind muore su un client, questo non sarà in grado di accedere il server NIS. |
| ypserv | Dovrebbe essere in esecuzione solo sui server NIS;è il processo NIS vero e proprio. Se ypserv(8) muore, il server non sarà più in grado di rispondere a richieste NIS (si spera ci sia un server slave per sostituirlo). Ci sono alcune implementazioni di NIS (ma non quello di FreeBSD) che non cerca di ricollegarsi ad un altro server se il server che stava usando muore. Spesso, l'unica cosa che aiuta in questo caso è riavviare il processo server (o anche l'intero server o il processo ypbind sul client). |
| rpc.yppasswdd | Un altro processo che dovrebbe essere in esecuzione solo sui server master NIS; è un demone che permette a client NIS di cambiare le proprie password NIS. Se questo demone non è attivo, gli utenti dovranno loggarsi al server master NIS e cambiare le proprie password da lì. |
Ci sono tre tipi di host in ambiente NIS: master server, slave server e client. I server fungono da magazzino centralizzato per le informazioni sulla configurazione degli host. I server master mantengono la copia "ufficiale" di queste informazioni, mentre i server slave effettuano il mirror di queste informazioni per ridondanza. I client si affidano al server per ottenere queste informazioni.
Le informazioni in molti file possono essere condivise in questo modo. I file master.passwd ,group e hosts sono in genere condivisi in questo modo via NIS. Qualora un processo su un client necessiti di informazioni che normalmente sarebbero trovate in questi file in locale, fa una query al server NIS a cui è legato.
Un server master NIS. Questo server, analogamente a primary domain controller Windows NT , mantiene i file usati da tutti i client NIS. Il file passwd, il file group, e vari altri file usati da client NIS vivono sul server master.
Nota: E' possibile per una macchina agire da master server NIS per più di un dominio NIS. Comunque, questo caso non sarà coperto in questa introduzione, che presuppone un ambiente NIS relativamente piccolo.
NIS slave server. Analogamente a backup domain controller Windows NT, i server slave NIS mantengono copie dei file di dati del server master NIS. I server slave NIS garantiscono la ridondanza che viene richiesta in ambienti importanti. Inoltre aiutano a bilanciare il carico del server master: i client NIS si legano sempre al NIS server che risponde per primo alla loro richiesta, compresi i server slave.
NIS client. I client NIS, come la maggior parte delle workstation Windows NT , si autenticano nei confronti del NIS server (o del domain controller Windows NT nel caso di workstation Windows NT) per effettuare il login.
Questa sezione riguarderà l'installazione di un ambiente di esempio NIS.
Supponiamo che tu sia l'amministratore di un piccolo laboratorio universitario. Questo laboratorio, che consiste di 15 macchine FreeBSD, al momento non ha un sistema centralizzato di amministrazione; ogni macchina ha il suo /etc/passwd e /etc/master.passwd. Questi file sono tenuti sincronizzati fra di loro attraverso intervento manuale; al momento, quando aggiungi un utente al laboratorio, devi eseguire adduser su tutte e 15 le macchine. Chiaramente, questa situazione è provvisoria, così hai deciso di convertire il laboratorio a NIS, usando due delle macchine come server.
Così la configurazione del laboratorio adesso sembra questa:
| Nome della macchina | Indirizzo IP | Ruolo della macchina |
|---|---|---|
| ellington | 10.0.0.2 | NIS master |
| coltrane | 10.0.0.3 | NIS slave |
| basie | 10.0.0.4 | Workstation della facoltà |
| bird | 10.0.0.5 | Macchina client |
| cli[1-11] | 10.0.0.[6-17] | Altre macchine client |
Se stai installando uno schema NIS per la prima volta, è una buona idea riflettere su come affrontarlo. Indipendemente dalla dimensione della rete, ci sono alcune decisioni che devono essere prese.
Questo può non essere il “nome dominio” a cui sei abituato. Per la precisione viene chiamato “nome dominio NIS”. Quando un client fa il broadcast della sua richiesta per informazioni, include il nome del dominio NIS di cui fa parte. In questo modo molti server su una rete possono distinguere a quale server la richiesta è riferita. Considerate il nome dominio NIS come il nome per un gruppo di host che sono collegati per qualche motivo.
Alcune organizzazioni scelgono di usare il loro nome dominio Internet come nome dominio NIS. Questo non è raccomandabile in quanto può causare confusione quando si cerchi di debuggare problemi di rete. Il nome dominio NIS dovrebbe essere unico all'interno della tua rete ed è utile che sia descrittivo del gruppo di macchine che rappresenta. Per esempio, il dipartimento di Arte della Acme Inc. può essere nel dominio “acme-art”. Per questo esempio, si presume tu abbia scelto il nome test-domain.
Comunque, alcuni sistemi operativi (principalmente SunOS) usano il loro nome dominio NIS come loro nome dominio Internet. Se una o più macchine sulla tua rete hanno questa restrizione, tu devi usare il nome dominio Internet come il tuo nome dominio NIS.
Ci sono molte cose da tener in mente quando si sceglie quale macchina usare come server NIS. Una delle caratteristiche più sfortunate di NIS è il livello di dipendenza che i client hanno verso il server. Se un client non riesce a contattare il server per il suo dominio NIS, molto spesso la macchina risulta inutilizzabile. La mancanza di informazioni utente e di gruppo fa sì che molti sistemi si blocchino. Tenendo questo in mente dovresti accertati di scegliere una macchina che non sia soggetta a reboot frequenti o una che non sia usata per sviluppo. Il server NIS dovrebbe essere in teoria una macchina stand alone il cui unico scopo di esistenza è essere un server NIS. Se hai una rete non pesantemente trafficata, è accettabile installare il server NIS su una macchina che esegue altri servizi, basta ricordarsi che se il server NIS diventa irrangiungibile, tutti i tuoi client NIS ne saranno affetti in modo negativo.
Le copie canoniche di tutte le informazioni NIS sono conservate su una singola macchina chiamata il server master NIS. I database usati per conservare le informazioni sono chiamate mappe NIS. In FreeBSD, queste mappe sono conservate in /var/yp/[nome-dominio] dove [nome-dominio] è il nome del dominio NIS che si server. Un singolo server NIS può supportare molti domini al tempo stesso, di conseguenza è possibile avere molte directory di questo tipo, una per ogni dominio supportato. Ogni dominio avrà il suo insieme indipendente di mappe.
I server NIS master e slave gestiscono tutte le richieste NIS col demone ypserv. ypserv è responsabile per la ricezione delle richieste in entrata dai client NIS, traducendo il dominio richiesto e il nome mappa ad un percorso verso il file di database e trasmettendo i dati indietro al client.
Installare un server master NIS può essere relativamente semplice, a seconda delle tue necessità . FreeBSD presenta un supporto nativo per NIS. Tutto quello che devi fare è aggiungere le seguenti linee a /etc/rc.conf, e FreeBSD farà il resto.
nisdomainname="test-domain"Questa linea imposterà il nome domino NIS a test-domain al momento della configurazione di rete (ad esempio dopo il reboot).
nis_server_enable="YES"Questa linea dirà a FreeBSD di avviare i processi NIS server la prossima volta che la rete è riavviata.
nis_yppasswdd_enable="YES"Questo avvierà il demone rpc.yppasswd che, come accennato prima, permetterà agli utenti di cambiare la loro password NIS dalle macchine client.
Nota: A seconda delle tue impostazioni NIS, potresti aver bisogno di aggiungere altre linee. Leggi la sezione sui NIS server che sono anche NIS client , di seguito, per dettagli.
Ora, tutto quello che devi fare è eseguire il comando /etc/netstart come super-utente. Questo imposterà il sistema, usando i valori che hai specificato in /etc/rc.conf.
Le mappe NIS sono file di database, che sono conservati nella directory /var/yp. Sono generati da file di configurazione nella directory /etc del NIS master, con una eccezione: il file /etc/master.passwd. C'è un buon motivo per questo, infatti normalmente non vuoi che siano propagate le password a root e ad altri account amministrativi a tutti gli altri server nel dominio NIS. Così prima di inizializzare le mappe NIS, dovresti:
# cp /etc/master.passwd /var/yp/master.passwd # cd /var/yp # vi master.passwd
Dovresti rimuovere tutte le linee che riguardano account di sistema (bin, tty, kmem, games, etc.), così come altri account che non vuoi siano propagate ai client NIS (per esempio root ed ogni altro account con UID 0 (super-utente)).
Nota: Accertati che il file /var/yp/master.passwd non sia nè leggibile dal gruppo nè dal resto del mondo (modo 600)! Usa il comando chmod, se appropriato.
Quando hai finito, è il momento di inizializzare le mappe NIS! FreeBSD include uno
script chiamato ypinit che lo fa per te (leggi la sua pagina di
manuale per dettagli). Nota che questo script è disponibile sulla maggior parte dei
sistemi operativi UNIX ma non su tutti. Su Digital
Unix/Compaq Tru64 UNIX è chiamato ypsetup. Poichè stiamo
generando mappe per un NIS master, passeremo l'opzione -m al
comando ypinit. Per generare le mappe NIS, supponendo che tu
abbia già eseguito i passi di cui sopra, esegui:
ellington# ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors.
ypinit dovrebbe aver creato /var/yp/Makefile da /var/yp/Makefile.dist. Quando creato, questo file assume che tu stia operando su un ambiente NIS a server singolo con solo macchine FreeBSD. Dal momento che test-domain ha anche un server slave, devi editare /var/yp/Makefile:
ellington# vi /var/yp/Makefile
Dovresti commentare la linea che dice
NOPUSH = "True"
(se non è già commentata).
Impostare un server NIS slave è anche più semplice che impostare il master. Loggati al
server slave ed edita il file /etc/rc.conf esattamente come hai
fatto col server master. L'unica differenza è che ora dobbiamo usare l'opzione -s quando eseguiamo ypinit. L'opzione
-s richiede che il nome del server NIS sia passato, così la
nostra linea di comando assomiglia alla seguente:
coltrane# ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington.
Ora dovresti avere una directory chiamata /var/yp/test-domain. Copie delle mappe NIS del master server dovrebbero risiedere in questa directory. Dovresti accertarti che siano aggiornate. La seguente linea di /etc/crontab sul tuo server slave dovrebbe far ciò:
20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid
Queste due linee forzano lo slave a sincronizzare le sue mappe con le mappe del server master. Anche se queste entry non sono obbligatorie, dal momento che il server master cerca di assicurarsi che tutte le modifiche alle sue mappe NIS siano comunicate ad i suoi slave e perchè le informazioni sulle password sono vitali per i sistemi che dipendono dal server, è una buona idea forzare gli aggiornamenti. Questo è ancora più importante su reti trafficate dove gli aggiornamenti delle mappe potrebbero non essere completi.
Adesso, esegui il comando /etc/netstart anche sullo slave, per avviare il server NIS.
Un client NIS stabilisce quello che è chiamato un binding ad un particolare NIS server usando il demone ypbind. ypbind controlla il dominio di default del sistema (impostato dal comando domainname), ed inizia a fare broadcast di richieste RPC sulla rete locale. Queste richieste specificano il nome del dominio per il quale ypbind sta cercando di stabilire un binding. Se un server è stato configurato a servire il dominio richiesto, risponderà a ypbind, che registrerà l'indirizzo del server. Se ci sono molti server disponibili (ad esempio un master e molti slave), ypbind userà l'indirizzo del primo che risponde. Da quel momento in poi, il sistema client dirigerà tutte le sue richieste NIS a quel server. ypbind occasionalmente farà un “ping” del server per accertarsi che sia su ed attivo. Se non riceve una risposta di uno dei suoi ping in un tempo accettabile, ypbind segnerà il dominio come non connesso e inizierà di nuovo a fare broadcasting nella speranza di localizzare un altro server.
Impostare una macchina FreeBSD perchè sia un client NIS è abbastanza semplice.
Edita il file /etc/rc.conf e aggiungi le seguenti linee per impostare il nome dominio NIS ed avviare ypbind all'avvio della rete:
nisdomainname="test-domain" nis_client_enable="YES"
Per importare tutte le possibili linee di password dal server NIS, rimuovi tutti gli account utente dal tuo /etc/master.passwd ed usa vipw per aggiungere la seguente linea alla fine del file:
+:::::::::
Nota: Questa linea permetterà a chiunque con un valido account nella mappa delle password del server NIS di loggarsi sul client. Ci sono molti modi per configurare il tuo client NIS cambiando questa linea. Leggi la sezione sui netgroups di seguito per maggiori informazioni. Per letture più dettagliate vedere il libro della O'Reilly Managing NFS and NIS.
Nota: Dovresti tenere almeno un account locale (non importato via NIS) nel tuo file /etc/master.passwd e questo account dovrebbe essere anche un membro del gruppo wheel. Se c'è qualche problema con NIS, questo account può essere usato per loggarsi da remoto, diventare root e riparare le cose.
Per impostare tutte le possibili linee dei gruppi dal server NIS, aggiungi questa linea al tuo file /etc/group:
+:*::
Dopo aver completato questi passi, dovresti essere in grado di eseguire ypcat passwd e vedere la mappa delle password del NIS server.
In generale, ogni utente remoto può eseguire una RPC a ypserv(8) ed ottenere i contenuti delle tue mappe NIS, ammesso che l'utente remoto conosca il tuo nome dominio. Per prevenire tali transazioni non autorizzate, ypserv(8) supporta una caratteristica chiamata “securenets” che può essere usata per restringere l'accesso ad un dato insieme di host. All'avvio ypserv(8) cercherà di caricare le informazioni delle securenets da un file chiamato /var/yp/securenets.
Nota: Questo percorso varia a secondo del percorso specificato con l'opzione
-p. Questo file contiene linee che consistono di una specificazione della rete e di una maschera di rete separate da spazi vuoti. Le linee che cominciano con “#” sono considerati commenti. Un esempio di file securenets può assomigliare al seguente:
# allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0
Se ypserv(8) riceve una richiesta da un indirizzo che coincide con una di queste regole, processerà la richiesta normalmente. Se l'indirizzo non coincide la richiesta sarà ignorata ed un messaggio di warning sarà loggato. Se il file /var/yp/securenets non esiste, ypserv permetterà connessioni da ogni host.
Il programma ypserv ha anche supporto per il pacchetto di Wietse Venema TCP Wrapper. Questo permette all'amministratore di usare i file di configurazione di TCP Wrapper per controlli sull'accesso al posto di /var/yp/securenets.
Nota: Pur essendo entrambi questi meccanismi di accesso di controllo abbastanza sicuri, questi, come il test di porta privilegiata, sono vulnerabili agli attacchi “IP spoofing”. Tutto il traffico relativo a NIS dovrebbe essere bloccato al firewall.
I server che usano /var/yp/securenets possono non riuscire a servire client NIS legittimi che abbiano implementazioni TCP/IP obsolete. Alcune di queste implementazioni impostano a zero tutti i bit degli host quando fanno broadcast e/o non riescono a osservare la maschera di sotto-rete quando calcolano l'indirizzo broadcast. Mentre alcuni di questi problemi possono essere corretti cambiando la configurazione del client, altri problemi possono causare il ritiro dei client in questione o l'abbandono di /var/yp/securenets.
Usando /var/yp/securenets su un server con una tale obsoleta implementazione del TCP/IP è sicuramente una cattiva idea e causerà alla perdita della funzionalità NIS per gran parte della tua rete.
L'uso del pacchetto TCP Wrapper aumenta la latenza del tuo server NIS. Il ritardo addizionale può essere lungo a sufficienza tanto da causare dei timeout in programmi client, specialmente su reti trafficate o con server NIS lenti. Se uno o più client soffre di questi sintomi, dovresti convertire il sistema dei client in questione a server NIS slave e forzarli a non fare il binding a loro stessi.
Nel nostro laboratorio c'è una macchina basie che si suppone sia una workstation solo della facoltà . Non vogliamo togliere questa macchina dal dominio NIS, tuttavia il file passwd sul server NIS master contiene account che sono sia della facoltà sia degli studenti. Cosa possiamo fare?
C'è un modo di impedire a specifici utenti di loggarsi ad una macchina, anche se sono presenti nel database NIS. Per farlo, tutto quello che devi fare è aggiungere -username alla fine del file /etc/master.passwd sulla macchina client, dove username è lo username dell'utente di cui vuoi impedire l'accesso. E' meglio fare questo con vipw dato che vipw farà un controllo di correttezza dei tuoi cambiamenti a /etc/master.passwd, e ricostruirà automaticamente il database delle password quando hai finito di editarlo. Ad esempio, se vogliamo impedire l'accesso all'utente bill verso l'host basie faremmo:
basie# vipw [aggiungi -bill alla fine del file, poi esci] vipw: rebuilding the database... vipw: done basie# cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie#
Il metodo mostrato nella sezione precedente funziona ragionevolmente bene se hai bisogno di regole speciali per un numero molto piccolo di utenti e/o macchine. Su reti più grandi, certamente ti dimenticherai di impedire l'accesso di certi utenti a macchine dal ruolo critico, oppure potresti perfino finire a modificare ogni macchina separatamente, in questo modo perdendo il beneficio centrale di NIS: l'amministrazione centralizzata.
La soluzione degli sviluppatori NIS a questo problema è chiamata netgroups. Il loro scopo e la loro semantica possono essere paragonate ai normali gruppi utenti usati dal file system UNIX. L'unica differenza è la mancanza di un ID numerico e l'abilità di definire un netgroup che includa sia gruppi utenti che altri netgroup.
I netgroup furono sviluppati per gestire grandi reti complesse con centinaia di utenti e macchine. Da un lato questa è una Buona Cosa se sei obbligato a gestire una simile situazione. Dall'altro, questa complessità rende praticamente impossibile spiegare i netgroup con esempi relativamente semplici. L'esempio usato nel resto di questa sezione dimostra questo problema.
Assumiamo che la favorevole introduzione di NIS nei tuoi laboratori catturi l'interesse dei tuoi superiori. Il tuo prossimo compito è di estendere il tuo dominio NIS per coprire alcune altre macchine del campo. Le due tabelle contengono i nomi dei nuovi utenti e delle nuove macchine, con una breve descrizione.
| User Name(s) | Description |
|---|---|
| alpha, beta | Impiegato normale del dipartimento IT |
| charlie, delta | Il nuovo apprendista del dipartimento IT |
| echo, foxtrott, golf, ... | Impiegato ordinario |
| able, baker, ... | Gli interni correnti |
| Machine Name(s) | Description |
|---|---|
| war, death, famine, pollution | Il tuoi server più importanti. Solo gli impiegati IT hanno il permesso di loggarsi in queste macchine. |
| pride, greed, envy, wrath, lust, sloth | Server meno importanti. Tutti i membri del dipartimento IT hanno il permesso di loggarsi a queste macchine. |
| one, two, three, four, ... | Workstation normali. Solo veri impiegati hanno permesso di accedere a queste macchine. |
| trashcan | Una macchina molto vecchia senza alcun dato critico. Anche gli interni hanno permesso di usare questa macchina. |
Se provi ad implementare queste restrizioni bloccando separatamente ogni utente, dovresti aggiungere una linea -user ad ogni passwd per ogni utente che non ha il permesso di loggarsi in quel sistema. Se ti dimentichi anche solo di una linea, potresti essere nei pasticci. Può essere ragionevole fare ciò correttamente durante l'installazione iniziale, comunque certamente ti dimenticherai alla fine di aggiungere le linee per i nuovi utenti durante le operazioni giornaliere. Dopo tutto, Murphy era un ottimista.
Gestire questa situazione con i netgroup offre molti vantaggi. Non c'è bisogno di gestire separatamente ogni utente; basta assegnare un utente ad uno o più netgroup e permettere o impedire il login a tutti i membri del netgroup. Se aggiungi una nuova macchina, dovrai solo definire restrizioni di login per i netgroup. Se un nuovo utente viene aggiunto, dovrai solo aggiungere l'utente ad uno o più netgroup. Questi cambiamenti sono indipendenti l'uno dall'altro: non più “per ogni combinazione di utenti e macchine fai ...”Se la tua installazione NIS è pianificata con attenzione, dovrai solo modificare esattamente un file centrale di configurazione per garantire o negare l'accesso alle macchine.
Il primo passo è l'inizializzazione della mappa NIS netgroup. ypinit(8) di FreeBSD non crea questa mappa di default, ma la sua implementazione NIS la supporterà una volta che è stata creata. Per aggiungere una linea alla mappa, semplicemente usa il comando
ellington# vi /var/yp/netgroup
e poi inizia ad aggiungere contenuti. Per i nostri esempi abbiamo bisogno di almeno quattro netgroup: impiegati IT, apprendisti IT, impiegati normali ed interni.
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)
IT_EMP, IT_APP etc. sono i nomi dei netgroup. Ogni gruppo fra parentesi tonde aggiunge uno o più account utente. I tre campi dentro il gruppo sono:
Il nome degli host dove le seguenti caratteristiche sono valide. Se non specifichi un nome host, la linea è valida per tutti gli host. Se specifichi un nome host, entrerai nel regno dell'oscurità , dell'orrore e della confusione assoluta.
Il nome dell'account che appartiene a questo netgroup.
Il dominio NIS per l'account. Puoi importare account da altri domini NIS nel tuo netgroup se sei uno di quei ragazzi sfortunati con più di un dominio NIS.
Ognuno di questi campi può contenere wildcards. Leggi netgroup(5) per dettagli.
Nota: Nomi netgroup più lunghi di 8 caratteri non dovrebbero essere usati, specialmente se hai macchine che eseguono altri sistemi operativi all'interno del tuo dominio NIS. I nomi sono case sensitive; usare le lettere maiuscole per il tuo netgroup è un modo semplice per distinguere fra utenti, macchine e nomi di netgroup.
Alcuni client NIS (non FreeBSD) non possono gestire netgroup con un numero troppo grande di linee. Ad esempio, alcune vecchie versioni di SunOS iniziano ad avere problemi se un netgroup contiene più di 15 linee. Puoi superare questo limite creando molti sotto-netgroup con 15 o meno utenti ed un vero netgroup che consiste dei sotto-netgroup:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3Puoi ripetere questo processo se hai bisogno di più di 225 utenti all'interno di un singolo netgroup.
Attivare e distribuire la tua nuova mappa NIS è facile:
ellington# cd /var/yp ellington# make
Questo genererà le tre mappe NIS netgroup, netgroup.byhost e netgroup.byuser. Usa ypcat(1) per controllare che le tue nuove mappe NIS siano disponibili:
ellington% ypcat -k netgroup ellington% ypcat -k netgroup.byhost ellington% ypcat -k netgroup.byuser
L'output del tuo primo comando dovrebbe assomigliare a /var/yp/netgroup. Il secondo comando non produrrà output se non hai specificato netgroup specifici agli host. Il terzo comando può essere usato per ottenere una lista dei netgroup di un utente.
L'installazione del client è abbastanza semplice. Per configurare il server war, devi solo eseguire vipw(8) e sostituire la linea
+:::::::::
con
+@IT_EMP:::::::::
Ora, solo i dati per l'utente definito nel netgroup IT_EMP sono importati nel database delle password di war e solo questi utenti hanno permesso di accesso.
Sfortunatamente, questa limitazione si applica anche alla funzione della shell ~ ed a tutte le routine che convertono fra nomi utenti e user ID numerici. In altre parole,cd ~user non funzionerà , ls -l mostrerà gli ID numerici invece dello username e find . -user joe -print darà l'errore “No such user”. Per riparare questo, dovrai importare tutte le linee dell'utente senza permettere a loro di loggarsi sui tuoi server.
Questo può essere ottenuto aggiungendo un'altra linea a /etc/master.passwd. Questo dovrebbe contenere:
+:::::::::/sbin/nologin, dal significato “Importa tutte le entry ma imposta la shell di login a /sbin/nologin nelle linee importate”. Puoi sostituire ogni campo nella linea passwd piazzando un valore di default nel tuo /etc/master.passwd.
Avvertimento: Accertati che la linea +:::::::::/sbin/nologin sia piazzata dopo +@IT_EMP:::::::::. Altrimenti tutti gli account utente importati da NIS avranno /sbin/nologin come loro shell di login.
Dopo questo cambiamento, dovrai solo cambiare una mappa NIS se un nuovo impiegato si unisce al dipartimento IT. Puoi usare un simile approccio per i server meno importanti sostituendo +::::::::: nella tua versione locale di /etc/master.passwd con qualcosa del tipo:
+@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin
Le linee corrispondenti per le workstation normali potrebbero essere:
+@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin
E tutto sarebbe a posto fino a che non c'è un cambiamento di policy dopo poche settimane: il dipartimento IT inizia ad assumere interni. Gli interni IT hanno permesso di usare le normali workstation ed i server meno importanti; e gli apprendisti IT hanno permesso di loggarsi ai server principali. Aggiungi un nuovo netgroup IT_INTERN, aggiungi i nuovi interni IT a questo nuovo netgroup IT_INTERN, e inizia a cambiare la configurazione su ogni nuova macchina... Come il vecchio adagio dice:“Errori nella pianificazione centralizzata porta a caos globale”.
L'abilità NIS di creare netgroup da altri netgroup può essere usata per prevenire situazioni come queste. Una possibilità è la creazione di netgroup basati sul ruolo. Per esempio, potresti creare un netgroup chiamato BIGSRV per definire le restrizioni di login per i server importanti, un altro netgroup chiamato SMALLSRV per i server meno importanti ed un terzo netgroup chiamato USERBOX per le workstation normali. Ognuna di questi netgroup contiene i netgroup che hanno permesso di accesso a queste macchine. Le nuove linee della tua mappa NIS dovrebbero assomigliare a questa:
BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS
Questo metodo di definire restrizioni di login funziona ragionevolmente bene se puoi definire gruppi di macchine con restrizioni identiche. Sfortunatamente questa è l'eccezione, non la regola. La maggior parte del tempo, avrai necessità di definire restrizioni di login macchina per macchina.
Definizioni di netgroup specifiche per ogni macchina sono l'altra possibilità per gestire il cambiamento di policy delineato sopra. In questo scenario il /etc/master.passwd di ogni macchina deve contenere due linee che iniziano con “+”. La prima di queste aggiunge un netgroup con l'account che ha il permesso di loggarsi alla macchina, il secondo aggiunge tutti gli altri account con /sbin/nologin come shell. E' buona norma usare la versione “MAIUSCOLA” del nome macchina come nome del netgroup. In altre parole, le linee dovrebbero assomigliare a questa:
+@BOXNAME::::::::: +:::::::::/sbin/nologin
Una volta che hai completato questo task per tutte le macchine, non dovrai mai più modificare la versione locale di /etc/master.passwd. Tutti gli ulteriori cambiamenti possono essere gestiti modificando la mappa NIS. Di seguito un esempio di una possibile mappa netgroup per questo scenario con altri vantaggi addizionali:
# Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow]
Se stai usando qualche tipo di database per gestire i tuoi account utente, dovresti essere in grado di creare la prima parte della mappa con i tuoi tool di report del database. In questo modo, i nuovi utenti avranno accesso automaticamente alle macchine.
Un ultima nota di avvertimento: può non essere sempre consigliabile usare netgroup basati sulle macchine. Se stai per mettere in produzione qualche dozzina o perfino qualche centinaia di macchine identiche per laboratori studente, dovresti usare netgroup basati sul ruolo invece che netgroup basati sulla macchina, per tenere la dimensione della mappa NIS al di sotto di un limite ragionevole.
Ci sono ancora un paio di cose che dovrai cambiare ora che operi in ambiente NIS.
Ogni volta che devi aggiungere un utente al laboratorio devi aggiungerlo solo al server master NIS e devi ricordarti di ricostruire le mappe NIS. Se ti dimentichi di farlo il nuovo utente non sarà in grado di loggarsi in alcuna macchina eccetto che sul server NIS master. Per esempio, se abbiamo bisogno di aggiungere un nuovo utente jsmith al laboratorio, faremmo:
# pw useradd jsmith # cd /var/yp # make test-domain
Puoi anche eseguire adduser jsmith invece di pw useradd jsmith.
Tieni gli account amministrativi fuori dalle mappe NIS. Normalmente non vuoi che gli account amministrativ e le password si propaghino a macchine che avranno utenti che non dovrebbero avere accesso a quegli account.
Tieni al sicuro il NIS master e slave, e minimizza il tempo in cui sono giù. Se qualcuno hackera o semplicemente spegne queste macchine riesce a privare molte persone della possibilità di loggarsi al laboratorio.
Questa è la principale debolezza di ogni sistema centralizzato di amministrazione. Se non proteggi il tuo server NIS, avrai un mucchio di utenti arrabbiati!
ypserv di FreeBSD supporta fino ad un certo punto client NIS v1. L'implementazione di NIS di FreeBSD usa solo il protocollo NIS v2, comunque altre implementazioni includono supporto per il protocollo v1 per compatibilità all'indietro coi vecchi sistemi. Il demone ypbind fornito con questi sistemi proverà a stabilire un binding con un server NIS v1 anche se potrebbero non averne mai bisogno (e possono continuare a fare broadcast in ricerca di uno anche dopo che hanno ricevuto risposta da un server v2). Nota che mentre il supporto per i client normali viene garantito, questa versione di ypserv non gestisce richieste di trasferimento di mappe v1; di conseguenza, non può essere usato come master o slave in congiunzione con server NIS più vecchi che supportano solo il protocollo v1. Fortunatamente, probabilmente non ci sono server del genere in uso oggi.
Bisogna prestare molta attenzione quando si esegue ypserv in un dominio multi-server dove le macchine server sono anche client NIS. E' generalmente una buona idea forzare i server ad effettuare il binding a sè stessi piuttosto che permettere loro di effettuare il broadcast delle richieste binding e potenzialmente possono fare il bind una all'altra. Possono risultare strani errori quando un server va giù e gli altri sono dipendenti da lui. Alla fine, tutti i client andranno in timeout e cercheranno di effettuare il bind ad altri server, ma il ritardo di questa operazione può essere considerevole e l'uscita di errore è ancora presente dato che i server possono fare il binding fra di loro di nuovo.
Puoi forzare un host a fare il binding ad un server in particolare usando ypbind con l'opzione -S. Se non vuoi
fare questa azione a mano ogni volta che fai il reboot del tuo server NIS, puoi
aggiungere queste linee al tuo /etc/rc.conf:
nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server"
Consulta ypbind(8) per ulteriori informazioni.
Uno dei problemi più comuni in cui la gente incappa quando tenta di implementare NIS è la compatibilità del formato delle password. Se il tuo server NIS usa password criptate con DES, supporterà solo client che usano anche loro DES. Ad esempio, se hai client NIS Solaris nella rete, dovrai quasi certamente usare password criptate con DES.
Per controllare quale formato il tuo server e client usano, dai un'occhiata a /etc/login.conf. Se l'host è configurato per usare password criptate DES, la classe default conterrà una linea simile a questa:
default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided]
Altri valori possibili per l'opzione passwd_format includono blf e md5 (per password criptate con Blowfish e con MD5, rispettivamente).
Se hai fatto modifiche a /etc/login.conf, dovrai anche ricostruire il database delle possibilità di login, il che si ottiene eseguendo il seguente comando come root:
# cap_mkdb /etc/login.conf
Nota: Il formato delle password che sono già in /etc/master.passwd non sarà aggiornato finchè un utente cambia la sua password per la prima volta dopo che il database delle possibilità di login è ricostruito.
Dopodichè per assicurarti che le password siano criptate con il formato che hai scelto, dovresti anche controllare che crypt_default in /etc/auth.conf dia precedenza al formato delle password scelto. Per farlo, inserisci il formato che hai scelto per primo nella lista. Ad esempio, quando usi password criptate DES, la linea dovrebbe essere:
crypt_default = des blf md5
Seguendo i passi sopra citati su ognuno dei FreeBSD basati su NIS server e client, puoi star sicuro che tutti siano d'accordo su quale formato delle password sia usato all'interno della rete. Se hai problemi nell'identificazione su un client NIS, questo è un buon punto di partenza per cercare possibili problemi. Ricordati: se vuoi mettere in produzione un server NIS per una rete eterogenea, dovrai probabilmente usare DES su tutti i sistemi poichè questo è il minimo standard comune.
| Indietro | Partenza | Avanti |
| Network File System (NFS) | Risali | Configurazione Automatica della Rete (DHCP) |
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Per domande su FreeBSD, leggi la documentazione prima di contattare <questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <doc@FreeBSD.org>.