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.
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.
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)).
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:
+:::::::::
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
.
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
.
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
.
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.
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 BIGGRP3
Puoi 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
.
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="-SNIS 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
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.
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>.