Sempre più macchine Linux sono installate come parti di una rete di computer. Al fine di semplificarne la gestione, molte reti (principalmente basate su Sun) utilizzano il Network Information Service. Le macchine Linux possono sfruttare al massimo il servizio NIS esistente o fornirlo esse stesse. Le macchine Linux possono agire anche come client NIS+ completi, ma questo supporto è in stadio beta.
Questo documento tenta di rispondere alle domande riguardanti l'impostazione di NIS(YP) e NIS+ sulla vostra macchina Linux. Non si dimentichi di leggere la Sezione 5.
Il NIS-Howto è scritto e mantenuto da
Thorsten Kukuk, <kukuk@suse.de> |
La principale fonte di informazioni per l'iniziale NIS-Howto è stata fornita da:
Andrea Dell'Amico <adellam@ZIA.ms.it> Mitchum DSouza <Mitch.DSouza@NetComm.IE> Erwin Embsen <erwin@nioz.nl> Peter Eriksson <peter@ifm.liu.se> |
che dovremmo ringraziare per aver scritto la prima versione di questo documento.
È possibile sempre vedere l'ultima versione di questo documento sul Word Wide Web tramite l'URL http://www.linux-nis.org/nis-howto/HOWTO/NIS-HOWTO.html.
Nuove versioni di questo documento potranno pure essere archiviate in vari siti Linux WWW e FTP, inclusa la home page di LDP.
I link alle traduzioni di questo documento potranno essere trovati a http://www.linux-nis.org/nis-howto/.
Sebbene questo documento possa riassumere il meglio della mia conoscenza è possibile, e probabile, che contenga errori. Per maggiori dettagli ed accurate informazioni, si leggano i file README che sono distribuiti con i vari software qui descritti. Cercherò di mantenere questo documento il più possibile libero da errori.
Se si hanno domande o commenti inerenti questo documento, si inviino liberamente a Thorsten Kukuk, presso kukuk@linux-nis.org. Accetto qualsiasi suggerimento o critica. Se si individuano errori in questo documento, fatemelo sapere così che possa correggerli nella prossima versione. Grazie.
Per cortesia non inviatemi domande inerenti problemi specifici con le vostre Distribuzioni Linux! Non conosco ogni Distribuzione Linux. Ma tenterò di aggiungere ogni soluzione inviatami.
Vogliamo ringraziare tutte le persone che hanno contribuito (direttamente o indirettamente) a questo documento. In ordine alfabetico:
Byron A Jeff <byron@cc.gatech.edu> Markus Rex <msrex@suse.de> Miquel van Smoorenburg <miquels@cistron.nl> Dan York <dyork@lodestar2.com> Christoffer Bromberg <christoffer@web.de> |
Theo de Raadt è responsabile per il codice originale dei client yp. Swen Thuemmler ha portato il codice dei client yp su Linux ed ha pure prodotto le routine yp in libc (basate ancora sul lavoro di Theo). Thorsten Kukuk ha scritto da zero le routine NIS(YP) and NIS+ per GNU libc 2.x.
In questo documento vengono usati molti acronimi. Qui ci sono i più importanti con una breve spiegazione:
DataBase Management, una libreria di funzioni che mantiene le coppie chiave-contenuto di una base di dati.
Dynamically Linked Library, una libreria collegata in fase di esecuzione ad un programma eseguibile.
Un nome "chiave" che è utilizzato dai client NIS al fine di localizzare il corretto server NIS che fornisce il servizio questo domainname chiave. Da notare che questo non ha necessariamente a che fare con il "dominio" DNS della macchina(e).
File Transfer Protocol, un protocollo utilizzato per il trasferimento di file tra due computer.
Name services library, una libreria di chiamate al name service (getpwnam, getservbyname, etc...) sugli Unix SVR4. GNU libc la utilizza per le funzioni NIS (YP) e NIS+.
Socket services library, una libreria per le chiamate a servizi socket (socket, bind, listen, etc...) sugli Unix SVR4.
Network Information Service, un servizio che fornisce informazioni che devono essere conosciute in ogni parte della rete, a tutte le macchine che vi prendono parte. Il supporto per il NIS è contenuto nella libreria standard libc di Linux, al quale, nel testo seguente, ci si riferisce come "NIS tradizionale".
Network Information Service (Plus :-), essenzialmente NIS con gli steroidi. NIS+ è stato progettato da Sun Microsystems Inc. come rimpiazzo per NIS con migliore sicurezza e migliore gestione di _grandi_ installazioni.
Questo è il nome del progetto e sta per NIS+, YP e Switch ed è gestito da Peter Eriksson <peter@ifm.liu.se>. Tra le altre cose, contiene una completa reimplementazione del codice di NIS (= YP) che utilizza la funzionalità di Name Services Switch della libreria di NYS.
Name Service Switch. Il file /etc/nsswitch.conf determina in che ordine devono essere effettuare le ricerche quando un certo tipo di informazione viene richiesto.
Remote Procedure Call. Le routine RPC permettono a programmi in C di effettuare chiamate a procedure su altre macchine attraverso la rete. Quando si parla di RPC, il più delle volte si intende la variante SUN di RPC.
Yellow Pages(tm), un marchio di fabbrica registrato nel Regno Unito dalla British Telecom plc.
Transmission Control Protocol/Internet Protocol. È il protocollo di comunicazione dati più utilizzato sulle macchine Unix.
Le quattro righe successive sono citazioni tratte dal Manuale Sun(tm) di Amministrazione del sistema e della rete:
"In passato, NIS era conosciuto come Sun Yellow Pages (YP) ma
il nome Yellow Pages(tm) è un marchio registrato nel Regno
Unito dalla British Telecom plc e non può essere utilizzato
senza permesso." |
NIS sta per Network Information Service. Il suo scopo è di fornire informazioni, che devono essere conosciute in ogni parte della rete, a tutte le macchine che vi prendono parte. Le informazioni verosimilmente fornite da NIS sono:
nomi di login/passwords/directory home (/etc/passwd)
informationi sul gruppo (/etc/group)
Se, per esempio, la propria password è registrata nel database passwd di NIS, sarà possibile accedere a tutte le macchine sulla rete che hanno in esecuzione i programmi client di NIS.
Sun è un marchio registrato da Sun Microsystems Inc. in licenza a SunSoft, Inc.
La scelta tra il "NIS tradizionale" o il codice di NIS nella libreria di NYS è una scelta tra pigrizia e maturità contro flessibilità ed amore per l'avventura.
Il codice del "NIS tradizionale" è nella libreria standard C, è in giro da molto ed alcune volte soffre a causa della sua età e lieve inflesibilità.
Il codice NIS nella libreria NYS richiede la ricompilazione della libreria libc per includere al suo interno il codice NYS (oppure si può ottenere una versione precompilata di libc da qualcuno che l'ha già fatto).
Un'altra differenza è che il codice del NIS tradizionale ha qualche supporto per i Netgroup NIS, che il codice di NYS non possiede. D'altro canto il codice NYS permette la gestione delle Shadow Password in modo trasparente. Il codice "NIS tradizionale" non supporta le Shadow su NIS.
Si dimentichi tutto questo se si utilizza la nuova libreria 2.x GNU C (anche conosciuta come libc6). Essa ha un vero supporto a NSS (name switch service), che la rende molto flessibile e lo ha anche per le seguenti mappe: aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services e shadow. La libreria GNU C non ha problemi con le shadow password su NIS.
La scelta tra NIS e NIS+ è facile - usare NIS+ solo se si ha bisogno di sicurezza rigorosa. NIS+ è molto più problematico da amministrare (è facile da gestire dal lato client, ma dal lato server è orribile). Un altro problema è che il supporto per NIS+ sotto Linux contiene un sacco di errori ed il suo sviluppo è stato interrotto.
All'interno di una rete ci deve essere almeno una macchina che funzioni come server NIS. È possibile avere più server NIS, ognuno serve differenti "domini" NIS - in alternativa è possibile avere dei server NIS che cooperano, dove uno è il server NIS master, e tutti gli altri sono chiamati server NIS slave (per un determinato "dominio" NIS, ovviamente!) - oppure è possibile avere un misto di questi...
Solo i server slave hanno copie dei database NIS e ricevono queste copie dal server NIS master ogni qual volta vengano fatte modifiche al database master. In relazione al numero di macchine presenti in rete ed alla sua qualità, è possibile decidere di installare uno o più server slave. Ogni qual volta un server NIS si disattiva o è troppo lento per rispondere alle richieste, un client NIS connesso a quel server tenterà di trovarne uno attivo o più veloce.
I database NIS sono in formato così chiamato DBM, derivato dal database ASCII. Per esempio, il file /etc/passwd e /etc/group possono essere direttamente convertiti in formato DBM utilizzando un software di traduzione da ASCII a DBM (makedbm, incluso con il software per il server ). Il server NIS master dovrebbe avere entrambe formati di database.
I server slave verranno avvisati di ogni cambiamento alle mappe NIS (tramite il programma yppush) e recupereranno automaticamente i necessari cambiamenti al fine di sincronizzare i loro database. I client NIS non hanno bisogno di questo poiché sono continuamente in contatto con il server NIS al fine di leggere le informazioni immagazzinate nel suo database DBM.
Le vecchie versioni di ypbind fanno un broadcast per trovare un server NIS in esecuzione. Questo non è un sistema sicuro, a causa del fatto che chiunque potebbe installare un server NIS e rispondere alle interrogazioni broadcast. Le versioni più recenti di ypbind (ypbind-3.3 or ypbind-mt) sono in grado di ottenere il server da un file di configurazione - in questo modo non è più necessario fare il broadcast.
NIS+ è una nuova versione del nameservice delle informazioni della rete fornito da Sun. La più grande differenza tra NIS e NIS+ è che NIS+ ha il supporto per la crittografia dei dati e l'autenticazione su RPC sicuro.
Il modello di assegnazione dei nomi di NIS+ è basato su una struttura ad albero. Ogni nodo dell'albero corrisponde ad un oggetto di NIS+, del quale si hanno sei tipi: directory, entry, group, link, table e private.
La directory NIS+ che forma la radice dello spazio dei nomi di NIS+ è chiamata directory radice. Vi sono due speciali directory NIS+: org_dir e groups_dir. La directory org_dir è composta da tutte le tabelle di amministrazione, come passwd, hosts e mail_aliases. La directory groups_dir è composta dal gruppo di oggetti di NIS+ utilizzati per il controllo degli accessi. L'insieme di org_dir, groups_dir e delle loro directory superiori fanno riferimento ad un dominio NIS+.
Per il funzionamento di qualsiasi software di seguito menzionato è necessario avere in esecuzione il programma /sbin/portmap. Alcune distribuzioni Linux hanno già inserito del codice nei file /sbin/init.d/ o /etc/rc.d/ affinché questo demone sia avviato. Tutto quello che c'è da fare è attivarlo e riavviare la macchina Linux. Si legga la documentazione della propria distribuzione Linux per sapere come fare.
Il portmapper RPC (portmap(8)) è un server che converte i numeri del programma RPC in numeri di porta del protocollo TCP/IP (o UDP/IP). Deve essere in funzione al fine di eseguire chiamate RPC (che è quello che fa il software del client NIS/NIS+) ai server RPC (come un server NIS o NIS+) su quella macchina. Quando un server RPC è in esecuzione, comunica a portmap su quale numero di porta è in ascolto e quali numeri di programmi RPC è pronto a servire. Quando un client desidera fare una chiamata RPC ad un dato numero di programma, prima contatta portmap sulla macchina server al fine di determinare il numero della porta dove i pacchetti RPC potranno essere inviati.
Affinché i server RPC possano essere avviati da inetd(8), portmap dovrà essere in esecuzione prima dell'avvio di inetd.
Per il RPC sicuro, il portmapper necessita del servizio Time. Ci si assicuri che il servizio Time sia abilitato in /etc/inetd.conf su tutti gli hosts:
# # Time service is used for clock syncronization. # time stream tcp nowait root internal time dgram udp wait root internal |
IMPORTANTE: Non si dimentichi di riavviare inetd dopo i cambiamenti al suo file di configurazione !
Per rispondere a questa domanda, bisogna considerare due casi:
La macchina farà parte di una rete ove esistono server NIS
Non si ha ancora nessun server NIS in rete
Nel primo caso, si ha la necessità dei programmi client (ypbind, ypwhich, ypcat, yppoll, ypmatch). Il programma più importante è ypbind. Questo programma deve essere sempre in esecuzione, il che significa che dovrà sempre apparire nella lista dei processi. Essendo un processo demone necessita di essere avviato dal file di avvio del sistema (es. /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local). Non appena ypbind sarà in esecuzione sul sistema, si diventerà un client NIS.
Nel secondo caso, se non si ha un server NIS, allora si avrà bisogno anche di un programma di server NIS (solitamente chiamato ypserv). la Sezione 9 descrive come impostare un server NIS sulla vostra macchina Linux utilizzando il demone ypserv.
La libreria di sistema "/usr/lib/libc.a" (versione 4.4.2 e successive) o la libreria condivisa "/lib/libc.so.x" contengono tutte le chiamate di sistema per compilare con successo i programmi client e server NIS. Per la GNU C Library 2 (glibc 2.x), si ha bisogno pure di /lib/libnsl.so.1.
Qualcuno ha riferito che NIS funzioni solo con "/usr/lib/libc.a" versione 4.5.21 e successive, così se si vuole andare sul sicuro non bisogna utilizzare le più vecchie libc. Il software per client NIS è possibile ottenerlo da:
Sito Directory Nome del file ftp.kernel.org /pub/linux/utils/net/NIS yp-tools-2.8.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS ypbind-mt-1.13.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS ypbind-3.3.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS ypbind-3.3-glibc5.diff.gz |
Una volta ottenuto il software, si prega di seguire le istruzioni fornite con lo stesso. yp-clients 2.2 sono per l'uso con libc4 e libc5 fino alla 5.4.20. libc5.4.21 e glibc 2.x necessitano di yp-tools 1.4.1 o successivi. I nuovi yp-tools 2.4 dovrebbero funzionare con ogni libreria libc di Linux. Poiché vi è un bug nel codice di NIS, non si dovrebbe utilizzare libc 5.4.21-5.4.35. Invece si usi libc 5.4.36 o successiva o la maggior parte dei programmi non funzionerà. ypbind 3.3 funzionerà pure lui con tutte le librerie. Se si usa gcc 2.8.x o successivo, egcs o glibc 2.x, si dovrebbe aggiungere a ypbind 3.3 la patch ypbind-3.3-glibc5.diff. Se possibile, si dovrà evitare l'uso di ypbind 3.3 per ragioni di sicurezza. ypbind-mt è un demone nuovo e multithread. Questi necessita del Kernel Linux 2.2 e di glibc 2.1 o successivo.
Dopo aver compilato con successo il software, si è pronti ad installarlo. Un posto adatto per il demone ypbind è la directory /usr/sbin. Qualcuno potrebbe dirvi che non è necessario ypbind su un sistema con NYS. Questo è sbagliato, ypwhich e ypcatne ne necessitano sempre.
Naturalmente si deve fare questo come root. Gli altri binari (ypwhich, ypcat, yppasswd, yppoll, ypmatch) dovrebbero essere messi in una directory accessibile a tutti gli utenti, normalmente /usr/bin.
Le nuove versioni di ypbind hanno un file di configurazione chiamato /etc/yp.conf. Al suo interno, è possibile specificare un server NIS - per maggiori informazioni si veda la pagina del manuale per ypbind(8). È possibile utilizzare questo file per NYS. Un esempio:
ypserver 10.10.0.1 ypserver 10.0.100.8 ypserver 10.3.1.1 |
Se il sistema può risolvere i nomi degli host senza NIS, potrete usare il nome, altrimenti bisogna utilizzare l'indirizzo IP. ypbind 3.3 ha un bug ed utilizzerà solamente l'ultima voce (nell'esempio ypserver 10.3.1.1). Tutte le altre voci sono ignorate. ypbind-mt gestisce correttamente questa cosa e ne utilizza uno, il primo che risponde.
Può essere una buona idea provare ypbind prima di incorporarlo nel file di avvio. Per provare ypbind si faccia quanto segue:
Assicurarsi di aver impostato un nome di dominio-YP. Se non è stato fatto, utilizzate il comando:
/bin/domainname nis.domain |
Avviare "/sbin/portmap" se non è già in esecuzione.
Creare la diretory /var/yp se non esiste.
Avviare /usr/sbin/ypbind
Utilizzare il comando rpcinfo -p localhost per verificare se ypbind sia stato in grado di registrare i propri servizi tramite portmapper. L'output dovrebbe apparire in modo simile:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 637 ypbind
100007 2 tcp 639 ypbind
|
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100007 2 udp 758 ypbind
100007 1 udp 758 ypbind
100007 2 tcp 761 ypbind
100007 1 tcp 761 ypbind
|
Si potrebbe pure eseguire rpcinfo -u localhost ypbind. Questo comando dovrebbe produrre qualcosa di simile:
program 100007 version 2 ready and waiting |
program 100007 version 1 ready and waiting
program 100007 version 2 ready and waiting
|
A questo punto si dovrebbe essere in grado di utilizzare i programmi per il client NIS come ypcat, ecc... Per esempio, ypcat passwd.byname vi restituirà l'intero database delle password NIS.
IMPORTANTE: se si salta la procedura di test poi assicurarsi di avere impostato il nome di dominio e creato la directory
/var/yp |
Questa directory DEVE esistere perché ypbind possa avviarsi con successo.
Verificare se il domainname sia impostato correttamente, si usi /bin/ypdomainname di yp-tools 2.2. Questo utilizza la funzione yp_get_default_domain() che è più restrittiva. Non si permetta, per esempio, il domainname "(none)" che è predefinito sotto Linux e crea parecchi problemi.
Se il test funziona, ora potrete cercare di sostituire i vostri file di avvio così che ypbind possa essere eseguito all'avvio ed il vostro sistema si comporti come un client NIS. Assicurarsi che il domainname sia impostato prima di avviare ypbind.
Bene, questo è tutto. Riavviate la macchina ed osservate i messaggi di boot per vedere se ypbind sia effettivamente attivo.
Per la ricerca degli host si deve impostare (o aggiungere) "nis" alla riga relativa all'ordine di ricerca nel vostro file /etc/host.conf. Per cortesia, si legga la manpage "resolv+.8" per maggiori dettagli.
Aggiungere la seguente riga a /etc/passwd sui vostri client NIS:
+:::::: |
Potrete pure utilizzare i caratteri + e - per includere/escludere o cambiare gli utenti. Se volete escludere l'utente guest, aggiungete semplicemente -guest al vostro file /etc/passwd. Volete usare una differente shell (p.e. ksh) per l'utente "linux" ? Nessun problema, semplicemente aggiungete "+linux::::::/bin/ksh" (senza gli apici) al vostro /etc/passwd. I campi che non volete sostituire lasciateli vuoti. Potete pure utilizzare Netgroups per il controllo dell'utente.
Per esempio, per permettere l'accesso-login solo a miquels, dth e ed, e tutti i membri del netgroup sysadmin, pur mantenendo disponibili i dati di account di tutti gli altri utenti:
+miquels:::::::
+ed:::::::
+dth:::::::
+@sysadmins:::::::
-ftp
+:*::::::/etc/NoShell |
Da notare che in Linux è pure possibile ridefinire il campo password, come fatto in questo esempio. Si è pure rimosso il login "ftp", così non è più noto e l'ftp anonimo non funzionerà.
Il netgroup potrebbe apparire come
sysadmins (-,software,) (-,kukuk,) |
IMPORTANTE: La caratteristica di netgroup è stata implementata dalla libc 4.5.26. Se si possiede una versione di libc precedente alla 4.5.26, ogni utente presente nel database delle password di NIS può accedere alla vostra macchina Linux se esegue "ypbind"!
Tutto ciò che è richiesto è che il file di configurazione NIS (/etc/yp.conf) punti al(ai) server(s) corretto(i) per le sue informazioni. Pure il file di configurazione del Name Services Switch (/etc/nsswitch.conf) deve essere correttamente impostato.
Si dovrebbe installare ypbind. Non è richiesto dalle libc, ma è necessario per gli strumenti di NIS(YP).
Se si vuole impiegare la caratteristica di includere/escludere per utente (+/-guest/+@admins), si deve utilizzare "passwd: compat" e "group: compat" in nsswitch.conf. Si noti che non c'è "shadow: compat"! In questo caso di deve usare "shadow: files nis".
I sorgenti di NYS sono parte dei sorgenti di libc 5. Quando si esegue configure, la prima volta rispondere "NO" alla domanda "Values correct", poi "YES" alla "Build a NYS libc from nys".
Le glibc utilizzano il "NIS tradizionale", così è necessario eseguire ypbind. Il file di configurazione del Name Services Switch (/etc/nsswitch.conf) deve essere correttamente impostato. Se si utilizza la modalità compact per passwd, shadow o group, si deve aggiungere il "+" alla fine di questo file e si può usare la caratteristica per l'utente di includere/escludere.
Il file del Network Services Switch /etc/nsswitch.conf determina l'ordine delle ricerche effettuate quando viene richiesta una certa informazione, proprio come il file /ets/host.conf che determina il modo in cui effettuare le ricerche degli host. Per esempio la riga:
hosts: files nis dns |
specifica che le funzioni di ricerca degli host dovrebbero prima guardare nel file locale /etc/hosts, di seguito fare una ricerca NIS ed infine utilizzare il servizio dei nomi di dominio (/ets/resolv.conf e named). A quel punto, se nessuna corrispondenza è stata trovata, viene riportato un errore. Questo file deve essere leggibile da ogni utente! È possibile reperire ulteriori informazioni nelle pagine di man nsswitch.5 o nsswitch.conf.5.
Un buon file /etc/nsswitch.conf per NIS è:
# # /etc/nsswitch.conf # # Un esempio del file di configurazione del Name Service Switch. Il file # dovrebbe essere ordinato con i servizi più utilizzati all'inizio. # # La voce '[NOTFOUND=return]' indica che la ricerca di una voce dovrebbe # fermarsi se la ricerca nella voce precedente non ha restituito nulla. # Si noti che se la ricerca fallisce per altre ragioni (perché nessun # server NIS risponde) allora la ricerca continua con la nuova voce. # # Le voci ammesse sono: # # nisplus Usa NIS+ (NIS versione 3) # nis Usa NIS (NIS versione 2), chiamato pure YP # dns Usa DNS (Domain Name Service) # files Usa i file locali # db Usa i database /var/db # [NOTFOUND=return] La ricerca si ferma se nulla è stato trovato finora # passwd: compat group: compat # Con libc5, si deve usare shadow: files nis shadow: compat passwd_compat: nis group_compat: nis shadow_compat: nis hosts: nis files dns services: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files netgroup: nis bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files automount: files aliases: nis [NOTFOUND=return] files |
passwd_compat, group_compat e shadow_compat sono supportati solamente da glibc 2.x. Se non vi sono regola shadow in /etc/nsswitch.conf, glibc utilizzerà la regola passwd per le ricerche. Vi sono alcuni altri moduli di ricerca per glibc come hesoid. Per maggiori informazioni, si legga la documentazione di glibc.
Le password shadow su NIS sono sempre una cattiva idea. Si perde la sicurezza che shadow fornisce ed è supportato solo da poche librerie Linux C. Un buon modo di usufruire delle password shadow su NIS è di inserire solo gli utenti locali del sistema in /etc/shadow. Si rimuovano le voci degli utenti dal database di shadow e si rimettano le password in passwd. Così è possibile utilizzare shadow per l'accesso come root e di norma passwd per l'utente NIS. Questo ha il vantaggio che sarà possibile lavorare con ogni client NIS.
La sola libc di Linux che supporta le password shadow su NIS è la GNU C Library 2.x. La libc5 di Linux non le supporta. La libc5 di Linux compilata con NYS attivato possiede un po' di codice per supportarle ma questo codice è in alcuni casi fortemente imperfetto e non lavora con tutte le voci shadow corrette.
Linux-PAM 0.75 e successivi non supportano le password shadow su NIS se utilizzate il modulo pam_unix.so o se installate il modulo extra pam_unix2.so. I vecchi sistemi che utilizzano pam_pwdb/libpwdb (per esempio Red Hat Linux 5.x) hanno bisogno di sostituire le voci di /etc/pam.d/*. Tutte le regole di pam_pwdb dovranno essere sostituite completamente da un modulo pam_unix_*.
Un esempio di file /etc/pam.d/login appare come:
#%PAM-1.0 auth requisite pam_unix2.so nullok #set_secrpc auth required pam_securetty.so auth required pam_nologin.so auth required pam_env.so auth required pam_mail.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_unix2.so none # debug or trace session required pam_limits.so |
Il codice per client NIS+ per Linux è stato sviluppato per la GNU C library 2. Vi è pure un port per libc5 di Linux, in quanto nel passato la maggior parte delle applicazioni commerciali erano linkate con questa libreria e non è possibile ricompilarle per utilizzare glibc. Ci sono problemi con libc5 e NIS+: i programmi statici non possono essere collegati con questa libreria e programmi compilati con questa non lavoreranno con altre versioni di libc5.
Come sistema base avete bisogno di una glibc basata su Distribuzioni come Debian, Red Hat Linux o Suse Linux. Se avete una distribuzione Linux che non ha glibc 2.1.1 o successive, dovete aggiornarla ad una nuova versione.
Il software per il client NIS+ può essere reperito da:
Sito Directory Nome File
ftp.gnu.org /pub/gnu/glibc glibc-2.3.2.tar.gz,
glibc-linuxthreads-2.3.2.tar.gz
ftp.kernel.org /pub/linux/utils/net/NIS+ nis-utils-1.4.1.tar.gz |
Si dovrà dare pure un'occhiata a http://www.linux-nis.org/nisplus/ per maggiori informazioni e gli ultimi sorgenti.
IMPORTANTE: per impostare un client NIS+ leggete i vostri documenti NIS+ di Solaris per sapere cosa fare dal lato server! Questo documento descrive solamente che cosa fare dal lato client.
Dopo l'installazione della nuova libc e degli strumenti NIS, create le credenziali per il nuovo client sul server NIS+. Assicurarsi che portmap sia in esecuzione. Poi verificate che il vostro PC Linux abbia la stessa ora del server NIS+. Per RPC sicure avete solo una piccola finestra di circa 3 minuti nella quale le credenziali sono valide. Una buona idea è di lanciare xntpd su ogni host. Dopo questo, eseguite
domainname nisplus.domain. nisinit -c -H <NIS+ server> |
per inizializzare il file d'avvio. Si legga la pagina man di nisinit per maggiori opzioni. Assicurarsi che domainname sia sempre impostato dopo il riavvio. Se non conoscete il nome del dominio NIS+ nella vostra rete, chiedete all'amministratore di sistema/rete.
Ora dovrete sostituire il vostro file /etc/nsswitch.conf Assicuratevi che il solo servizio dopo publickey sia nisplus ("publickey: nisplus"), e null'altro!
Poi avviate keyserv e assicuratevi che sia sempre attivo come primo demone dopo portmap all'accensione. Eseguite
keylogin -r |
niscat passwd.org_dir dovrà mostrare ora tutte le voci nel database passwd.
Quando un utente effettua il login, ha bisogno di impostare la sua chiave privata al keyserv. Questo viene fatto chiamando "keylogin". Il login del pacchetto shadow farà questo per l'utente, se è stato compilato con glibc 2.1. Per un login con PAM, si deve sostituire il file /etc/pam.d/login per utilizzare pam_unix2, non pwdb, che non supporta NIS+. Un esempio:
#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix2.so set_secrpc auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix2.so password required /lib/security/pam_unix2.so session required /lib/security/pam_unix2.so |
Il file Network Services Switch /etc/nsswitch.conf determina l'ordine di ricerca quando viene richiesto un certo tipo di informazione, proprio come il file /etc/host.conf che determina l'ordine delle ricerche degli host. Per esempio, la riga
hosts: files nisplus dns |
specifica che le funzioni di ricerca degli host dovranno prima verificare nel file locale /etc/hosts, seguendo poi un lookup di NIS+ e finalmente attraverso il servizio di nomi di dominio (/etc/resolv.conf e named), a questo punto se nessuna corrispondenza è stata trovata, viene restituito un errore.
Un buon file /etc/nsswitch.conf per NIS+ è:
# # /etc/nsswitch.conf # # Un esempio del file di configurazione del Name Service Switch. Il file # dovrebbe essere ordinato con i servizi più utilizzati all'inizio. # # La voce '[NOTFOUND=return]' indica che la ricerca di una voce dovrebbe # fermarsi se la ricerca nella voce precedente non ha restituito nulla. # Si noti che se la ricerca fallisce per altre ragioni (perché nessun # server NIS risponde) allora la ricerca continua con la nuova voce. # # Le voci ammesse sono: # # nisplus Usa NIS+ (NIS versione 3) # nis Usa NIS (NIS versione 2), chiamato pure YP # dns Usa DNS (Domain Name Service) # files Usa i file locali # db Usa il database /var/db # [NOTFOUND=return] La ricerca si ferma se nulla è stato trovato finora # passwd: compat group: compat shadow: compat passwd_compat: nisplus group_compat: nisplus shadow_compat: nisplus hosts: nisplus files dns services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files netgroup: nisplus bootparams: nisplus [NOTFOUND=return] files publickey: nisplus automount: files aliases: nisplus [NOTFOUND=return] files |
Questo documento descrive solamente come impostare il server NIS "ypserv".
Il software per il server NIS può essere reperito su:
Sito Directory Nome file ftp.kernel.org /pub/linux/utils/net/NIS ypserv-2.9.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS ypserv-2.9.tar.bz2 |
È possibile dare un'occhiata a http://www.linux-nis.org/nis/ per maggiori informazioni.
L'impostazione del server è la stessa sia per il NIS tradizionale che NYS.
Si compili il software per generare i programmi ypserv e makedbm. Solo ypserv-2.x supporta il file securnets per le restrizioni degli accessi.
Se eseguite il vostro server come master, verificate che i file richiesti siano disponibili tramite NIS e poi aggiungete o rimuovete le voci appropriate alle regole "all" in /var/yp/Makefile. Dovreste sempre osservare il Makefile ed editare le opzioni all'inizio del file.
C'è stato un grande cambiamento tra ypserv 1.1 e ypserv 1.2. Dalla versione 1.2, la gestione del file è cached. Questo significa che si deve sempre eseguire makedbm con l'opzione -c se si vogliono creare nuove mappe. Assicurarsi di utilizzare il nuovo /var/yp/Makefile di ypserv 1.2 o successivo, oppure si agginga il flag -c a makedbm in Makefile. Se non lo si fa, ypserv continuerà ad utilizzare le vecchie mappe e non quelle aggiornate.
Ora editate /var/yp/securenets e /etc/ypserv.conf. Per maggiori informazioni, leggete le pagine del manuale di ypserv(8) e ypserv.conf(5).
Assicirarsi che portmapper (portmap(8)) sia in esecuzione esi avvii il server ypserv. Il comando
% rpcinfo -u localhost ypserv |
dovrà restituirvi qualcosa come
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting |
La linea "version 1" potrebbe non esserci, dipende dalla versione di ypserv e dalla configurazione in uso. È necessaria solo se si hanno vecchi client SunOS 4.x.
Ora si generi il nuovo database NIS (YP). Sul master, eseguite
% /usr/lib/yp/ypinit -m |
Su uno slave assicurarsi che ypwhich -m lavori. Questo significa che il vostro slave deve essere configurato come client NIS prima di poter eseguire
% /usr/lib/yp/ypinit -s masterhost |
Questo è tutto, il server è impostato ed in esecuzione.
Se si hanno grossi problemi, si può avviare ypserv e ypbind in modalità debug su differenti xterms. L'output di debug dovrebbe mostrare cosa fa di sbagliato.
Se si deve aggiornare una mappa, eseguire make nella directory /var/yp sul master NIS. Questo aggiornerà una mappa se il file sorgente è più nuovo ed invierà i file ai server slave. Per cortesia, non si utilizzi ypinit per aggiornare una mappa.
Si potrebbe editare il crontab di root sul server slave ed aggiungere le seguenti righe:
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday |
Dopo, si può aggiungere uno slave in ogni momento. Prima, assicurarsi che il nuovo server slave abbia i permessi per contattare il master NIS. Poi si esegua
% /usr/lib/yp/ypinit -s masterhost |
Se si vuole ridurre l'accesso agli utenti sul server NIS, si dovrà impostare il server NIS come un client eseguendo ypbind ed aggiungendo le voci + a /etc/passwd a metà del file delle password. Le funzioni di libreria ignoreranno tutte le voci normali dopo la prima voce NIS ed otterranno il resto delle informazioni direttamente da NIS. In questo modo le regole di accesso a NIS verranno mantenute. Un esempio:
root:x:0:0:root:/root:/bin/bash
daemon:*:1:1:daemon:/usr/sbin:
bin:*:2:2:bin:/bin:
sys:*:3:3:sys:/dev:
sync:*:4:100:sync:/bin:/bin/sync
games:*:5:100:games:/usr/games:
man:*:6:100:man:/var/catman:
lp:*:7:7:lp:/var/spool/lpd:
mail:*:8:8:mail:/var/spool/mail:
news:*:9:9:news:/var/spool/news:
uucp:*:10:50:uucp:/var/spool/uucp:
nobody:*:65534:65534:noone at all,,,,:/dev/null:
+miquels::::::
+:*:::::/etc/NoShell
[ All normal users AFTER this line! ]
tester:*:299:10:Just a test account:/tmp:
miquels:1234567890123:101:10:Miquel van Smoorenburg:/home/miquels:/bin/zsh |
Quindi l'utente "tester" esisterà ma avrà la shell di /etc/NoShell. miquels avrà un normale accesso.
Alternativamente, potrete editare il file /var/yp/Makefile ed impostare NIS per utilizzare un'altro file sorgente delle password. Su grandi sistemi i file delle password e gruppi NIS sono normalmente archiviati in /etc/yp/. Se si fa questo, i normali strumenti per amministrare il file delle password come passwd, chfn, adduser non funzioneranno più e si avrà bisogno di speciali strumenti fatti su misura per queste operazioni.
In ogni caso, yppasswd, ypchsh e ypchfn lavoreranno comunque.
Per impostare il server NIS "yps" riferirsi al precedente paragrafo. L'impostazione del server "yps" è simile ma non esattamente uguale, così si faccia attenzione se si tenta di applicare le istruzioni di "ypserv" a "yps"! "yps" non è supportato da alcun autore e contiene alcune falle nella sicurezza. Veramente non sarebbe da utilizzare!
Il server NIS "yps" può essere reperito su:
Sito Directory Nome File ftp.lysator.liu.se /pub/NYS/servers yps-0.21.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS yps-0.21.tar.gz |
rpc.ypxfrd è utilizzato per velocizzare il trasferimento di mappe NIS molto grandi da un server NIS master ai server slave. Se un server NIS slave riceve un messaggio che c'è una nuova mappa, avvierà ypxfr per il trasferimento della nuova mappa. ypxfr leggerà i contenuti della mappa dal server master utilizzando la funzione yp_all(). Questo processo può impiegare diversi minuti in presenza di mappe molto grandi che devono essere salvate dalla libreria.
Il server rpc.ypxfrd velocizza il processo di trasferimento permettendo ai server NIS slave di copiare semplicemente il file della mappa del server master anziché costruire le proprie da zero. rpc.ypxfrd utilizza un protocollo di trasferimento dei file basato su RPC, così che non vi sia necessità di costruire una nuova mappa.
rpc.ypxfrd può essere avviato da inetd. Ma poiché si avvia molto lentamente, dovrebbe essere avviato da ypserv. È necessario avviare rpc.ypxfrd solo sul server NIS master.
Ogni qual volta gli utenti cambiano la loro password, il database NIS delle password e probabilmente gli altri database NIS, che dipendono da questo, dovrebbero essere aggiornati. Il programma "rpc.yppasswdd" è un server che gestisce le password cambiate e si assicura che che l'informazione NIS sia aggiornata di conseguenza. Ora rpc.yppasswdd è integrato in ypserv. Non avrete bisogno del vecchio, distinto yppasswd-0.9.tar.gz o yppasswd-0.10.tar.gz, e non dovrebbero essere utilizzati ancora a lungo.
Si deve eseguire rpc.yppasswdd solo su server NIS master. Per valore predefinito, gli utenti non sono autorizzati a cambiare il loro nome completo o la shell di login. È possibile permetterlo con l'opzione -e chfn o -e chsh.
Se i file passwd e shadow non sono nella directory /etc, si deve aggiungere l'opzione -D. Per esempio, se si mettono tutti i file sorgenti in /etc/yp e si vuole che gli utenti cambino la loro shell, si deve avviare rpc.yppasswdd con i seguenti parametri:
rpc.yppasswdd -D /etc/yp -e chsh |
o
rpc.yppasswdd -s /etc/yp/shadow -p /etc/yp/passwd -e chsh |
Non c'è molto altro da fare. Ci si deve solo assicurare che rpc.yppasswdd utilizzi gli stessi file di /var/yp/Makefile. Gli errori verranno riportati mediante syslog.
Se ogni cosa è a posto (come dovrebbe essere), c'è la possibilità di > verificare l'installazione con pochi e semplici comandi. Si assuma, per esempio, che il file passwd sia gestito da NIS, il comando
% ypcat passwd |
dovrebbe restituire i contenuti del file passwd di NIS. Il comando
% ypmatch userid passwd |
(dove userid è il nome di login di un utente arbitrario) dovrebbe restituire la voce dell'utente nel file passwd di NIS. I programmi "ypcat" e "ypmatch" dovrebbero essere inclusi con la distribuzione del NIS tradizionale o del NYS.
Se un utente non riesce a fare il login, eseguire il seguente programma da un client:
#include <stdio.h>
#include <pwd.h>
#include <sys/types.h>
int
main(int argc, char *argv[])
{
struct passwd *pwd;
if(argc != 2)
{
fprintf(stderr,"Usage: getwpnam username\n");
exit(1);
}
pwd=getpwnam(argv[1]);
if(pwd != NULL)
{
printf("name.....: [%s]\n",pwd->pw_name);
printf("password.: [%s]\n",pwd->pw_passwd);
printf("user id..: [%d]\n", pwd->pw_uid);
printf("group id.: [%d]\n",pwd->pw_gid);
printf("gecos....: [%s]\n",pwd->pw_gecos);
printf("directory: [%s]\n",pwd->pw_dir);
printf("shell....: [%s]\n",pwd->pw_shell);
}
else
fprintf(stderr,"User \"%s\" not found!\n",argv[1]);
exit(0);
} |
Eseguendo il programma con il nome dell'utente (username) come parametro, stamperà tutte le informazioni che la funzione getpwnam restituisce per questo utente. Questo dovrebbe mostrare quale voce non è corretta. Il problema più comune è che il campo della password è stato sovrascritto con un "*".
GNU C Library 2.1 (glibc 2.1) contiene uno strumento chiamato getent. Si usi questo programma invece di quello sopra in un sistema di questo tipo. Si può provare:
getent passwd |
getent passwd login |
Le mappe NIS iniziali verranno create eseguendo
% /usr/lib/yp/ypinit -m |
Questo viene fatto quando si imposta il server NIS master per la prima volta. Per maggiori informazioni inerenti questa operazione, leggere la Sezione 9. Se si desidera aggiungere nuove mappe al server o rimuoverne alcune, è necessario editare /var/yp/Makefile e cambiare la regola all:. Aggiungere o rimuovere la regola che genera la mappa.
Se si cancella una mappa, si devono rimuovere anche i file corrispondenti.
Dopo questo cambiamento, si deve eseguire
% make -C /var/yp |
e le mappe dovrebbero essere create.
Se si modificano i sorgenti per le mappe NIS (per esempio se si crea un nuovo utente aggiungendo l'account al file passwd), è necessario rigenerare le mappe NIS. Questo viene fatto con un semplice
% make -C /var/yp |
Questo comando verificherà quali sorgenti sono stati cambiati, crea le nuove mappe ed avvisa ypserv che le mappe sono state sostituite.
La lunghezza di una voce è limitata a 1024 caratteri dal protocollo NIS. Non è possibile incrementare semplicemente questo valore e ricompilare il sistema. Ogni sistema che usa NIS v2 attende chiavi e dati non più lunghi in dimensione di 1024 byte; se improvvisamente si aumenta il valore di YPMAXRECORD sul client e sul server, si interromperà l'interoperatività con altri sistemi che utilizzano NIS sulla rete. Per lavorare correttamente, si dovrebbe andare da ogni venditore che supporta NIS ed ottenere da loro di fare tutti i cambiamenti allo stesso tempo. Possibilità che non si può avere.
Con glibc 2.1 e successivi questo limite è stato rimosso dall'implementazione di glibc NIS. In questo modo è possibile, sotto Linux, utilizzare voci più lunghe ma solo se non ci sono altri client o server NIS nella rete.
Per permettere la creazione di mappe NIS con una voce più lunga, si deve aggiungere l'opzione --no-limit-check alla chiamata a makedbm in /var/yp/Makefile.
Il risultato dovrebbe apparire come:
DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname` --no-limit-check |
ATTENZIONE: questo interrompe il protocollo NIS e anche se Linux lo supporta, non tutte le applicazioni eseguibili sotto Linux lavorano con questa variazione!
C'è un'altro modo per risolvere questo problema per le voci di /etc/group. L'idea è di Ken Cameron:
1. Interrompere la voce in più di una linea e dare un nome ad ogni gruppo lievemente differente. 2. assegnare lo stesso GID per tutte. 3. avere la prima voce con il giusto nome di gruppo e GID. Non inserire nessun nome utente in questa. Succede che partendo dal nome dell'utente, si recupererà il GID quando il codice lo legge. Poi partendo in altro modo, si ferma dopo la prima corrispondenza di GID e ne ottiene il nome. È brutto ma funziona! |
Una volta che si è configurato correttamente NIS sul server e sui client, bisogna essere sicuri che la configurazione sopravviverà al riavvio.
Vi sono due questioni separate da verificare: l'esistenza di uno script di init e la corretta archiviazione del nome di dominio NIS.
Nella vostra versione di Linux, è necessario controllare la directory degli script di init, solitamente /etc/init.d, /etc/rc.d/init.d o /sbin/init.d per essere sicuri che ci sia uno script di startup per NIS. Solitamente questo file è chiamato ypbind o ypclient.
Probabilmente il più grande problema che alcune persone hanno con NIS è assicurare che il nome di dominio NIS sia disponibile dopo un riavvio. Secondo Solaris 2.x, il nome di dominio NIS potrebbe essere inserito come una linea singola in:
/etc/defaultdomain |
Comunque, la maggior parte delle distribuzioni Linux sembra non utilizzino questo file.
A questo punto, l'informazione seguente è sapere come le varie distribuzioni Linux gestiscono l'archiviazione del nome di dominio NIS.
Caldera utilizza il file /etc/nis.conf che ha lo stesso formato del normale /etc/yp.conf.
Si crei o modifichi la variabile NISDOMAIN nel file /etc/sysconfig/network.
Si modifichi la variabile YP_DOMAINNAME in /etc/rc.config e poi si esegua il comando SuSEconfig.
Dalla versione 8.0 anche SuSE Linux segue l'uso di Sun di /etc/defaultdomain.
Il modo standard per cambiare una password NIS è invocare yppasswd, su alcuni sistemi questo è solo un alias per passwd. Questo comando usa il protocollo yppasswd e necessita dell'esecuzione di un processo rpc.yppasswdd sul server NIS master. Il protocollo ha lo svantaggio che la vecchia password verrà trasmessa in chiaro attraverso la rete. Questo non è problematico, se la sostituzione della password avviene con successo. In questo caso, la vecchia password viene sostituita con una nuova. Ma se il cambiamento della password fallisce, un attaccante può utilizzare la password in chiaro per effettuare il login come questo utente. Ancora più pericoloso: se l'amministratore di sistema sostituisce la password NIS di un altro utente, la password di root del server NIS master è trasferita in chiaro sulla rete. E questo non verrà cambiato.
Una soluzione è non utilizzare yppasswd per sostituire la password. Invece, una buona alternativa è il comando rpasswd dal pacchetto pwdutils.
Sito Directory Nome File ftp.kernel.org /pub/linux/utils/net/NIS pwdutils-2.3.tar.gz ftp.suse.com /pub/people/kukuk/pam/pam_pwcheck pam_pwcheck-2.2.tar.bz2 ftp.suse.com /pub/people/kukuk/pam/pam_unix2 pam_unix2-1.16.tar.bz2 |
rpasswdcambia le password per gli account degli utenti su un server remoto tramite una connessione sicura SSL. Un utente normale può cambiare solo la password del proprio account, se l'utente conosce la password per l'account dell'amministratore (al momento questa è la password di root sul server), egli può sostituire la password per ogni account se invoca rpasswd con l'opzione -a.
Per il server si necessita innanzitutto del certificato, il nome del file predefinito per questo è /etc/rpasswdd.pem. Il file può essere creato con il seguente comando:
openssl req -new -x509 -nodes -days 730 -out /etc/rpasswdd.pem -keyout /etc/rpasswdd.pem |
È necessario anche un file di configurazione di PAM per rpasswdd . Se gli account NIS sono archiviati in /etc/passwd, la seguente è un buon punto di partenza per un configurazione di lavoro:
#%PAM-1.0 auth required pam_unix2.so account required pam_unix2.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok password required pam_make.so /var/yp session required pam_unix2.so |
Se i sorgenti per le mappe delle password di NIS sono archiviati in un'altra posizione (per esempio in /etc/yp), l'opzione nisdir di pam_unix2 può essere usata per trovare i file sorgenti in altri luoghi:
#%PAM-1.0 auth required pam_unix2.so account required pam_unix2.so password required pam_pwcheck.so nisdir=/etc/yp password required pam_unix2.so nisdir=/etc/yp use_first_pass use_authtok password required pam_make.so /var/yp session required pam_unix2.so |
Ora si avvii il demone rpasswdd sul server master NIS.
Poiché il cambio della password viene fatto con moduli PAM, rpasswdd è pure in grado di permettere i cambiamenti delle password per NIS+, LDAP o altri servizi supportati da un modulo di PAM.
Su ogni client è necessario solo il file di configurazione /etc/rpasswd.conf che contiene il nome del server. Se il server non parte sulla porta predefinita, la porta corrente può pure essere menzionata qui:
# rpasswdd eseguito su master.example.com server master.example.com # La porta 774 è la porta predefinita port 774 |
Ci sono alcuni problemi comuni riportati da vari utenti:
Le librerie per 4.5.19 sono danneggiate. NIS non funziona con queste.
Se si aggiornano le librerie dalla 4.5.19 alla 4.5.24 poi il comando su smette di funzionare. È necessario ottenerlo dalla distribuzione slackware 1.2.0. A proposito, è dove si può ottenere le librerie aggiornate.
Quando un server NIS si disattiva e viene riattivato, ypbind parte lamentandosi con un messaggio simile:
yp_match: clnt_call:
RPC: Unable to receive; errno = Connection refused |
Dopo l'aggiornamento di libc ad una versione successiva alla 5.4.20, gli strumenti di YP non funzioneranno molto a lungo. Si ha bisogno di yp-tools 1.2 o successivi per libc >= 5.4.21 e glibc 2.x. Per la versione precedente di libc si ha bisogno di yp-clients 2.2. yp-tools 2.x dovrebbe funzionare con tutte le librerie.
In libc 5.4.21 - 5.4.35 yp_maplist si blocca, si ha bisogno della 5.4.36 o successiva, o alcuni programmi YP come ypwhich andranno in segfault.
libc5 con NIS tradizionale non supporta le password shadow su NIS. Si ha bisogno di libc5 + NYS o glibc 2.x.
ypcat shadow non mostra la mappa shadow. Questo è corretto, il nome della mappa shadow è shadow.byname, non shadow.
Solaris non sempre usa porte privilegiate. Così non si utilizzi la password rovinata se si possiede un client Solaris.
Molte delle vostre domande dovrebbero avere avuto una risposta ora. Se vi sono altre domande che non ne hanno trovata una, potete cercare di inviare un messaggio a
comp.os.linux.networking |