The Linux NIS(YP)/NYS/NIS+ HOWTO Thorsten Kukuk v1.0, 9 marzo 1999 Questo documento descrive la configurazione di Linux come client NIS(YP) o NIS+ e l'installazione di un server NIS. Traduzione origi­ nale di Michele Dalla Silvestra. Revisione e aggiormento di Giovanni Bortolozzo, (borto@pluto.linux.it). 1. Introduzione Sempre più macchine Linux sono installate come parte di una rete di computer. Per semplificare l'amministrazione di rete, molte reti (principalmente reti basate su macchine Sun) usano il Network Information Service (``Servizio Informativo di Rete''). Le macchine Linux possono sfruttare appieno l'esistenza di un servizio NIS o fornire esse stesse tale servizio. Le macchine Linux possono essere anche client NIS+ completi, sebbene tale supporto sia in un stadio di beta test. Questo documento prova a rispondere alle domande sull'impostazione di NIS(YP) e NIS+ sulla propria macchina Linux. Non si dimentichi di leggere la sezione ``Il Portmapper RPC''. Il NIS-HOWTO è scritto e mantenuto da: Thorsten Kukuk, kukuk@suse.de Le principali fonti di informazione per la versione iniziale del NIS- HOWTO sono state fornite da: Andrea Dell'Amico Mitchum DSouza Erwin Embsen Peter Eriksson che tutti dovremmo ringraziare per la scrittura iniziale di questo documento. 1.1. Nuove versioni di questo documento L'ultima versione di questo documento è sempre consultabile su World Wide Web attraverso l'URL http://www.suse.de/~kukuk/linux/HOWTO/NIS- HOWTO.html . Le nuove versioni di questo documento saranno inoltre archiviate nei vari siti WWW e FTP dedicati a Linux, tra cui la home page dell'LDP. I link alle traduzioni di questo documento possono essere trovati a http://www.suse.de/~kukuk/linux/nis-howto.html . 1.2. Liberatoria Sebbene questo documento sia stato creato utilizzando il meglio della mia conoscenza potrebbe, e probabilmente è così, contenere errori. Per informazioni più dettagliate ed accurate si invita a leggere tutti i file README distribuiti con i diversi software descritti in questo documento. Proverò a mantenere questo documento il più possibile esente da errori. 1.3. Commenti e correzioni Se si hanno domande o commenti su questo documento, si inviino liberamente a Thorsten Kukuk, a kukuk@suse.de. Qualsiasi suggerimento o critica saranno i benvenuti. Se si trova un errore in questo documento, mi si informi cosicché possa correggerlo nella versione successiva. Grazie. Per piacere non mi si inviino domande su problemi particolari con la propria distribuzione di Linux! Non conosco tutte le distribuzioni di Linux. Ma proverò ad aggiungere qualsiasi soluzione mi si voglia spedire. 1.4. Ringraziamenti Vogliamo ringraziare quanti hanno contribuito a questo documento (direttamente o indirettamente). In ordine alfabetico: Byron A Jeff Markus Rex Miquel van Smoorenburg Theo de Raadt è responsabile per il codice originale dei client yp. Swen Thuemmler ha portato tale codice su Linux e ha portato le routine yp in libc (ancora basandosi sul lavoro di Theo). Thorsten Kukuk ha scritto da capo le routine NIS(YP) e NIS+ per la GNU libc 2.x. 2. Glossario e informazioni generali 2.1. Glossario dei termini In questo documento sono usati molti acronimi. Di seguito una breve descrizione dei più importanti: DBM DataBase Management, una libreria di funzioni che mantiene le coppie chiave-contenuto in una base di dati. DLL Dynamically Linked Library, una libreria linkata in esecuzione a un programma eseguibile. domainname Un nome ``chiave'' usato dai client NIS per localizzare un server NIS appropriato che serve questa chiave di dominio. Si noti che questo non ha necessariamente nulla a che spartire con il ``dominio'' DNS (nome macchina) delle macchine. FTP File Transfer Protocol, un protocollo usato per trasferire file tra due computer. libnsl Name services library, una libreria di chiamate a name service (getpwnam, getservbyname, ecc...) sugli Unix SVR4. La GNU libc la usa per le funzioni di NIS(YP) e NIS+. libsocket Socket services library, una libreria di chiamta a servizi socket (socket, bind, listen, etc...) su Unix SVR4. NIS Network Information Service, un servizio che fornisce informazioni che devono essere note attraverso la rete a tutte le macchine nella rete. Il supporto per NIS è presente nella libc standard di Linux, e nel seguito verrà riferito come ``NIS tradizionale''. NIS+ Network Information Service (Plus :-), in sostanza NIS anabolizzato. NIS+ è stato progettato da Sun Microsystems Inc. come rimpiazzo di NIS con una migliore sicurezza e gestione migliore di ``grosse'' installazioni. NYS Questo è il nome di un progetto e sta per NIS+, YP e Switch ed è gestito da Peter Eriksson . Contiene tra le altre cose una completa reimplemetazione del codice di NIS (= YP) che usa le funzionalità di Name Services Switch della libreria NYS. NSS Name Service Switch. Il file /etc/nsswitch.conf determina l'ordine delle ricerche indicizzate (``lookup'') effettuate quando è richiesta una determinata informazione. RPC Remote Procedure Call. Le routine RPC permettono ai programmi 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 RPC. YP Yellow Pages(tm), un marchio registrato in Gran Bretagna dalla British Telecom plc. TCP-IP Transmission Control Protocol/Internet Protocol. È il protocollo di comunicazione dei dati maggiormente usato nelle macchine Unix. 2.2. Alcune informazioni generali Le quattro righe che seguono sono una citazione del Sun(tm) System & Network Administration Manual: ``NIS era noto in precedenza come Sun Yellow Pages (YP) ma il nome Yellow Pages(tm) è un marchio registrato in Gran Bretagna da British Telecom plc e non può essere usato senza autorizzazione.'' NIS sta per Network Information Service. Lo scopo è di fornire informazioni che devono essere note attraverso la rete a tutte le macchine nella rete. Le informazioni solitamente distribuite attraverso NIS sono: · nomi di login/password/home directory (/etc/passwd) · informazioni sui gruppi (/etc/group) Se, per esempio, la voce della propria password è registrata nel database passwd di NIS, si sarà in grado di connettersi su tutte le macchine nella rete che abbiano un programma client NIS in esecuzione. Sun è un marchio registrato da Sun Microsystems, Inc. e in licenza a SunSoft, Inc. 3. NIS, NYS o NIS+? 3.1. libc 4/5 con il NIS tradizionale o NYS? La scelta tra il ``NIS tradizionale'' o il codice NIS nella libreria NYS è la scelta tra pigrizia e maturità contro flessibilità e spirito d'avventura. Il codice del ``NIS tradizionale'' è nella libreria C standard, è in giro da parecchio e qualche volta soffre della sua età e scarsa flessibilità. Il codice NIS nella libreria NYS richiede la ricompilazione della libreria libc per includere al suo interno il codice NYS (oppure si può prendere una versione precompilata di libc da qualcuno che l'ha già fatto). Un'altra differenza è che il codice NIS tradizionale ha un po' di supporto per i Netgroup (``gruppi di rete'') NIS, che il codice NYS non ha. D'altra parte il codice NYS permette la gestione delle shadow password in modo trasparente. Il codice del ``NIS tradizionale'' non supporta le shadow password su NIS. 3.2. glibc 2 e NIS/NIS+ Si dimentichi tutto questo se si ha la nuova libreria C 2.x della GNU (detta anche libc6). Ha un reale supporto per NSS (name switch service), che la rende davvero flessibile e contiene il supporto per le seguenti mappe NIS/NIS+: aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services e shadow. La libreria C della GNU non ha problemi con le shadow password assieme al NIS. 3.3. NIS o NIS+ ? La scelta tra NIS e NIS+ è facile: usare NIS se non si deve usare NIS+ o si hanno stringenti necessità di sicurezza. NIS+ è molto più problematico da amministrare (è abbastanza facile da gestire dal lato client, ma il lato server è orribile). Un altro problema è che il supporto per NIS+ sotto Linux è ancora in sviluppo: si deve usare l'ultimissima glibc 2.1. Esiste un port del supporto NIS+ di glibc per libc5 come rimpiazzo temporaneo. 4. Come funziona 4.1. Come funziona NIS In una rete ci deve essere almeno una macchina che fa da server NIS. Si possono anche avere più server NIS, ognuno che serve un diverso ``dominio'' NIS, oppure si possono avere server NIS cooperanti, nel qual caso uno di questi è il ``master NIS server'', e tutti gli altri sono detti ``slave NIS server'' (per un certo ``dominio'' NIS, ovviamente!), oppure si può avere un mix delle due situazioni... I server slave hanno solo copie delle basi di dati NIS e ricevono queste copie dal master NIS server ogni qual volta ci sono delle modifiche nelle basi di dati del server. A seconda del numero di macchine nella propria rete e della sua solidità, si può decidere di installare uno o più slave server. Ogni qual volta un server NIS non risponde o oppure risponde troppo lentamente ad una richiesta, il client NIS connesso a quel server proverà a trovarne uno attivo o più veloce. Le basi di dati NIS sono nel cosiddetto formato DBM, derivato dalle basi di dati ASCII. Per esempio, i file /etc/passwd e /etc/group possono essere direttamente convertiti nel formato DBM usando il software di traduzione da ASCII a DBM ``makedbm", incluso con il software per il server. Il master NIS server dovrebbe averle entrambe, sia la base di dati ASCII che quella DBM. I slave server saranno avvertiti di qualsiasi modifica nelle mappe NIS (attraverso il programma ``yppush"), e automaticamente scaricheranno le necessarie modifiche per poter sincronizzare le loro basi di dati. Il client NIS non serve lo facciano in quanto parlano sempre con il server NIS per leggere le informazioni salvate nel suo database DBM. Le vecchie versioni di ypbind fanno un broadcast per trovare un server NIS funzionante. Questa cosa non è sicura, a causa del fatto che chiunque può installare un server NIS e rispondere alle interrogazioni di ypbind. Le versioni più recenti di ypbind (ypbind-3.3 or ypbind- mt) possono ottenere il nome del server da un file di configurazione e quindi non è più necessario il broadcast. 4.2. Come funziona NIS+ NIS+ è una nuova versione di NIS di Sun. La maggiore differenza tra NIS e NIS+ è che NIS+ ha il supporto per la cifratura dei dati e l'autenticazione su RPC sicure. Il modello di naming di NIS+ si basa su una struttura ad albero. Ogni nodo nell'albero corrisponde a un oggetto NIS+, del quale ne esistono sei tipi: directory, entry, group, link, table e private. La directory NIS+ che forma la radice dello spazio di nomi ("namespace") NIS+ è chiamata root directory. Esistono due speciali directory NIS+: org_dir e groups_dir. La directory org_dir consiste di tutte le tabelle di amministrazione, come passwd, hosts, e mail_aliases. La directory groups_dir consiste degli oggetti group di NIS+ usati per il controllo dell'accesso. Con dominio NIS+ si fa riferimento alla collezione di org_dir, groups_dir e delle loro directory superiori. 5. Il Portmapper RPC Per far funzionare tutti i software che verranno menzionati a breve si deve eseguire il programma /usr/sbin/portmap. Alcune distribuzioni Linux hanno già l'apposito codice nei file in /sbin/init.d/ o /etc/rc.d/ per avviarlo come demone. Tutto quel che si deve fare è di attivarlo e riavviare la propria 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 di programma RPC in numeri di porta del protocollo TCP/IP (o UDP/IP). Deve essere eseguito per poter fare della chiamate RPC (che è quanto fa il software del client NIS/NIS+) ai server RPC (come un server NIS o NIS+) su quella macchina. Quando è avviato un server RPC, questo dirà al portmap su quale numero di porta rimane in ascolto e quali numeri di programmi RPC è pronto a servire. Quando un client intende fare una chiamata RPC ad un dato numero di programma, per prima cosa contatta il portmap sulla macchina server per determinare il numero della porta alla quale inviare i pacchetti RPC. Normalmente i server RPC standard sono avviati da inetd(8), cosicché portmap deve essere in esecuzione prima di lanciare inetd. Per RPC sicure, il portmapper ha bisogno del servizio Time. Ci si assicuri che tale servizio sia abilitato in /etc/inetd.conf su tutti gli host: # # Il servizio Time è usato per le sincronizzazioni degli orologi # time stream tcp nowait root internal time dgram udp wait root internal IMPORTANTE: Non si dimentichi di riavviare inetd dopo aver modificato il suo file di configurazione! 6. Cos'è necessario fare per mettere su un NIS? 6.1. Determinare se si è server, slave o client Per rispondere a questa domanda si debbono considerare due casi: 1. La propria macchina sta per diventare parte di una rete dove esiste già un server NIS 2. Non si ha ancora nessun server NIS nella propria rete Nel primo caso, si ha bisogno solo dei programmi client (ypbind, ypwhich, ypcat, yppoll, ypmatch). Il programma più importante è ypbind. Questo programma dev'essere sempre in esecuzione, ovvero deve sempre apparire nella lista dei processi. È un cosiddetto processo demone e deve essere avviato nei file di avvio del sistema (eg. /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local). Prima si ha ypbind in esecuzione, prima la propria macchina diventa un cliente NIS. Nel secondo caso, se non si ha un server NIS, allora si avrà bisogno anche del programma NIS per il server (solitamente chiamato ypserv). La sezione ``Configurare un Server NIS'' descrive come mettere su un server NIS nella propria macchina Linux usando l'implementazione di ``ypserv'' di Peter Eriksson e Thorsten Kukuk. Si noti che a partire dalla versione 0.14 questa implementazione supporta il concetto di master-slave di cui si è parlato nella sezione 4.1. Esiste un altro server NIS libero, chiamato ``yps'', scritto da Tobias Reber in Germania che supporta il concetto di master-slave, ma ha altre limitazioni oltre a non essere più supportato da molto tempo. 6.2. Il software La libreria di sistema ``/usr/lib/libc.a'' (versione 4.4.2 e superiore) o la libreria condivisa ``/lib/libc.so.x'' contengono tutte le system call necessarie per portare a buon fine la compilazione del software NIS per client e server. Con la GNU C Library 2 (glibc 2.x) serve anche /lib/libnsl.so.1. Alcuni hanno riportato che NIS funziona solo con una versione di "/usr/lib/libc.a'' 4.5.21 o superiore, e quindi se si vuole andare sul sicuro non si usino libc più vecchie. Il software per un client NIS può essere ottenuto da: Sito Directory Nome File ftp.kernel.org /pub/linux/utils/net/NIS yp-tools-2.2.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS ypbind-mt-1.4.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 ftp.uni-paderborn.de /linux/local/yp yp-clients-2.2.tar.gz Una volta scaricato il software, si seguano le istruzioni distribuite con quest'ultimo. yp-clients 2.2 è per l'uso con libc4 e libc5 fino alla versione 5.4.20. libc 5.4.21 e glibc 2.x hanno bisogno di yp- tools 1.4.1 o successivi. I nuovi yp-tools 2.2 dovrebbero funzionare con qualsiasi libc per Linux. Poiché ci sono alcuni bug nel codice NIS, non si dovrebbe usare la libc 5.4.21-5.4.35. Si usi invece la libc 5.4.36 o successiva, o la maggior parte dei programmi YP non funzionerà. ypbind 3.3 funzionerà anche lui con tutte le librerie. Se si usa gcc 2.8.x o successivo, egcs o glibc 2.x, si deve aggiungere la patch ypbind-3.3-glibc5.diff a ypbind-3-3. Non si dovrebbe mai usare ypbind distribuito assieme a yp-clients 2.2. ypbind-mt è un nuovo demone multithread che ha bisogno di un kernel Linux 2.2 e di glibc 2.1 o successiva. 6.3. Il demone ypbind Dopo aver compilato con successo il software si è pronti per installarlo. Un posto adatto per il demone ypbind è la directory /usr/sbin. Alcuni potrebbero affermare che non è necessario ypbind su un sistema con NYS. Questo è sbagliato, in quanto ypwhich e ypcat ne hanno bisogno. Ovviamente si deve fare tutto come root. Gli altri binari (ypwhich, ypcat, yppoll, ypmatch) dovrebbero andare in una directory accessibile a tutti gli utenti, solitamente /usr/bin. I più recenti ypbind hanno un file di configurazione chiamato /etc/yp.conf. È possibile specificare al suo interno un server NIS. Per maggiori informazioni si veda la pagina di manuale di ypbind(8). Questo file è necessario anche per NYS. Un esempio: ypserver voyager ypserver defiant ypserver ds9 Se il sistema può risolvere il nome degli host senza NIS, si può usare il nome, altrimenti bisogna usare l'indirizzo IP. ypbind 3.3 ha un baco e userà solo l'ultima voce (ypserver ds9 nell'esempio). Tutte le altre voci sono ignorate. ypbind-mt gestisce correttamente questa cosa e usa il server che prima risponde. Può essere una buona idea testare ypbind prima di incorporarlo nei file d'avvio. Per testare ypbind si faccia quanto segue: · Assicurarsi si aver impostato il proprio nome di dominio YP. Se non è impostato allora si usi il comando: /bin/domainname dominio.nis dove dominio.nis dovrebbe essere una qualche stringa, solitamente NON associata con il nome di dominio DNS della propria macchina! Il motivo è che così diventa un po' più difficile per cracker esterni ottenere la base di dati delle password dal proprio server NIS. Se non si sa qual è il nome di dominio NIS della propria rete, si chieda al proprio amministratore di sistema/rete. · Avviare ``/usr/sbin/portmap'' se non è già in esecuzione. · Creare la directory ``/var/yp'' se ancora non esiste. · Avviare ``/usr/sbin/ypbind". · Usare il comando ``rpcinfo -p localhost'' per controllare se ypbind è stato in grado di registrare i suoi servizi con il portmapper. L'output dovrebbe essere qualcosa del tipo: program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100007 2 udp 637 ypbind 100007 2 tcp 639 ypbind o 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 a seconda della versione di ypbind che si sta usando. · Si può anche eseguire ``rpcinfo -u localhost ypbind". Questo comando dovrebbe produrre qualcosa di simile a program 100007 version 2 ready and waiting o program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting L'output dipende dipende dalla versione di ypbind installata. L'importante è solo il messaggio ``version 2". A questo punto si dovrebbe essere in grado di usare i programmi client NIS come ypcat, ecc... Per esempio, ``ypcat passwd.byname'' dovrebbe restituire l'intera base di dati NIS delle password. IMPORTANTE: Se si è saltata la procedura di test allora ci si assicuri di aver impostato il nome di dominio e di aver creato la directory /var/yp Questa directory DEVE esistere affinché ypbind si avvii con successo. Per controllare se il nome di dominio è impostato correttamente, si usi /bin/ypdomainname degli yp-tools 2.2. Questo usa la funzione yp_get_default_domain(), che è più restrittiva. Per esempio non permette il nome di dominio ``(none)'', che è quello predefinito sotto Linux e che crea un sacco di problemi. Se il test funziona ora si possono modificare i file di avvio in modo che ypbind sia avviato al boot del sistema e che quest'ultimo funzioni come client NIS. Ci si assicuri che il nome di dominio sia impostato prima di avviare ypbind. Bene, è tutto. Si riavvii la macchina e si controllino i messaggi di boot per vedere se ypbind è realmente avviato. 6.4. Impostare un client NIS usando il NIS tradizionale Per la ricerca degli host si deve impostare (o aggiungere) ``nis'' alla riga relativa all'ordine di ricerca nel proprio file /etc/host.conf. Si invita a leggere la pagina man di ``resolv+.8'' per ulteriori dettagli. Aggiungere le seguenti righe al proprio file /etc/passwd dei propri client NIS: +:::::: Si possono usare anche i caratteri + e - per includere/escludere o modificare utenti. Se si vuole escludere l'utente guest semplicemente si aggiunga -guest nel proprio file /etc/passwd. Si vuole usare una shell diversa (e.g. ksh) per l'utente ``linux''? Nessun problema, si aggiunga semplicemente ``+linux::::::/bin/ksh'' (senza le virgolette) al proprio /etc/passwd. I campi che non si vogliono modificare dovrebbero essere lasciati vuoti. Si possono anche usare i Netgroups (``gruppi di rete'') per il controllo degli utenti. Per esempio, per permettere l'accesso di login a miquels, dth e ed, e a 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 Si noti che in Linux si può anche ridefinire il campo password, come si è fatto in questo esempio. Si è rimossa la login ``ftp'', cosicché non sia più nota e non funzioni più l'ftp anonimo. Il netgroup potrebbe essere qualcosa del tipo sysadmins (-,software,) (-,kukuk,) IMPORTANTE: La funzionalità dei netgroup è implementata a partire da libc 4.5.26. Se si ha una versione di libc precedente, qualsiasi utente nella base di dati NIS delle password può accedere alla macchina linux se è in esecuzione ``ypbind''! 6.5. Impostare un client NIS usando NYS Tutto ciò che serve è che il file di configurazione di NIS (/etc/yp.conf) punti al/ai server corretto/i per le sue informazioni. Inoltre deve essere correttamente impostato il file di configurazione del Name Services Switch (/etc/nsswitch.conf). Si dovrebbe installare ypbind. Non è richiesto dalla libc, ma i tool NIS(YP) ne hanno bisogno. Se si vuole usare la funzionalità di inclusione/esclusione utenti (+/-guest/+@admins), si deve usare ``passwd: compat'' e ``group: compat'' in nsswitch.conf. Notare che non c'è un ``shadow: compat''! Si deve usare ``shadow: files nis'' in questo caso. I sorgenti di NYS fanno parte dei sorgenti della libc 5. Quando si lancia configure, rispondere ``NO'' la prima volta che appare la domanda ``Value correct'', e poi rispondere ``YES'' a ``Build a NYS libc from nys''. 6.6. Impostare un client NIS usando glibc 2.x La glibc usa il ``NIS tradizionale", così si deve avviare ypbind. Il file di configurazione del Name Services Switch (/etc/nsswitch.conf) deve essere correttamente impostato. Se si usa la modalità compat per passwd, shadow o group, si deve aggiungere il ``+'' alla fine di questi file, e si può usare la funzionalità di inclusione/esclusione utenti. La configurazione è esattamente identica a quella che si fa sotto Solaris 2.x. 6.7. Il File nsswitch.conf Il file del Network Services Switch /etc/nsswitch.conf determina l'ordine delle ricerche (``lookup'') effettuate quando è richiesta una data informazione, proprio come il file /etc/host.conf determina il modo con il quale sono effettuate 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 /etc/hosts locale, poi effettuare un lookup NIS e alla fine una vera richiesta al domain name service (/etc/resolv.conf e named), e a quel punto, se non viene trovata alcuna corrispondenza, viene restituito un errore. Questo file deve essere leggibile per qualsiasi utente! Si possono trovare maggiori informazioni nelle pagine man nsswitch.5 e nsswitch.conf.5. Un buon /etc/nsswitch.conf per NIS è: # # /etc/nsswitch.conf # # Un esempio di file di configurazione del Name Service Switch. # Questo file dovrebbe essere ordinato in modo che i servizi più # comuni siano all'inizio. # # La voce '[NOTFOUND=return]' indica che la ricerca di una voce # dovrebbe fermarsi se la ricerca nella voce precedente non ha # restituito niente. Si noti che se la ricerca fallisce per qualche # altra ragione (come la mancata risposta del server NIS) allora la # ricerca continua con la voce successiva. # # Le voci ammesse sono: # # nisplus Usa NIS+ (NIS versione 3) # nis Usa NIS (NIS versione 2), detto anche YP # dns Usa DNS (Domain Name Service) # files Usa file locali # db Usa la base di dati /var/db # [NOTFOUND=return] Ferma la ricerca se prima non è stato # trovato niente # 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 supportate solo da glibc 2.x. Se non ci sono regole shadow nel file /etc/nsswitch.conf, glibc userà le regole passwd per le ricerche. Ci sono alcuni altri moduli di ricerca per glibc, come hesoid. Per maggiori informazioni si legga la documentazione di glibc. 6.8. Le password shadow con NIS Le password shadow su NIS sono sempre una cattiva idea. Si perde la sicurezza che shadow dà e sono supportate solo da poche librerie C per Linux. Un buon modo per evitare le shadow password su NIS è di mettere solo gli utenti locali del sistema in /etc/shadow. Si rimuovano le voci degli utenti NIS dal database shadow e si rimettano le password in passwd. In questo modo si può usare shadow per il login di root e le password normali per gli utenti NIS. Questo ha il vantaggio che funzionerà con qualsiasi client NIS. 6.8.1. Linux La sola libc per Linux che supporta le password shadow con NIS è la GNU C Library 2.x. La libc5 per Linux non ha questo supporto. La libc5 per Linux non ha il supporto per questa cosa. La libc5 per Linux compilata con il NYS abilitato ha un po' di supporto. Ma tale supporto è gravemente bacato e in qualche caso non funziona con tutte le corrette voci shadow. 6.8.2. Solaris Solaris non supporta le password shadow con NIS. 6.8.3. PAM PAM non supporta le password shadow con NIS, in particolare pam_pwdb/libpwdb non lo fa. Questo è un grosso problema per gli utenti di RedHat 5.x. Se si ha glibc e PAM, è necessario modificare le voci in /etc/pam.d/*. Si rimpiazzino tutte le regole pam_pwdb attraverso i moduli pam_auth_unix_*. A causa di un baco nel modulo pam_unix_auth.so module questa cosa non funzionerà sempre. Un esempio di file /etc/pam.d/login è questo: #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix_auth.so auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_unix_passwd.so session required /lib/security/pam_unix_session.so Per ``auth'' è necessario usare il modulo pam_unix_auth.so, per ``account'' il modulo pam_unix_acct.so, per ``password'' il modulo pam_unix_passwd.so e per ``session'' il modulo pam_unix_session.so. 7. Cosa serve per mettere su NIS+? 7.1. Il software Il codice dei client NIS+ per Linux è stato sviluppato per la libreria C 2 della GNU. Esiste anche un port per la libc5 di Linux, in quanto la maggior parte delle applicazioni commerciali sono linkate con questa libreria e non è possibile ricompilarle per usare la glibc. Ci sono problemi con libc5 e NIS+: non è possibile fare il link di questa con i programma statici, e i programmi compilati con questa non funzioneranno con altre versioni della libc5. Ci si deve procurare e compilare GNU C Library 2.1 per piattaforme basate su Intel o GNU C Library 2.1.1 per piattaforme a 64-bit. Come sistema di partenza è necessaria una distribuzione basata su glibc come Debian 2.x, RedHat 5.x o SuSE Linux 6.x. Qualsiasi sia la distribuzione, è necessario ricompilare il compilatore gcc/g++, libstdc++ e ncurses. Per la RedHat, è necessario fare pesanti modifiche alla configurazione PAM. Per SuSE Linux 6.0, è necessario ricompilare il pacchetto shadow. Il software per i client NIS+ può essere ottenuto da: Sito Directory Nome File ftp.funet.fi /pub/gnu/funet libc-*, glibc-crypt-*, glibc-linuxthreads-* ftp.kernel.org /pub/linux/utils/net/NIS+ nis-utils-19990223.tar.gz ftp.kernel.org /pub/linux/utils/net/NIS+ pam_keylogin-1.2.tar.gz Le distribuzioni basate su glibc possono essere scaricate da: Sito Directory ftp.debian.org /pub/debian/dists/slink ftp.redhat.com /pub/redhat/redhat-5.2 ftp.suse.de /pub/SuSE-Linux/6.0 Per la compilazione della libreria C della GNU, si invita a seguire le istruzioni ricevute con il software. Qui è dove si può trovare la libc5 modificato, basata su NYS e con i sorgenti di glibc che rimpiazzano quelli della libc5 standard: Sito Directory Nome File ftp.kernel.org /pub/linux/utils/net/NIS+ libc-5.4.44-nsl-0.4.10.tar.gz Per maggiori informazioni e per gli ultimi sorgenti si dovrebbe guardare a http://www.suse.de/~kukuk/linux/nisplus.html . 7.2. Impostare un client NIS+ IMPORTANTE: Per l'impostazione di un client NIS+, si legga la documentazione del NIS+ di Solaris per sapere cosa fare dal lato server! Questo documento descrive solamente cosa fare dal lato client! Dopo aver installato la nuova libc e i nis-tools, si creino le credenziali per il nuovo client nel server NIS+. Assicurarsi che portmap sia in esecuzione. Poi controllare che il proprio PC Linux abbia la stessa ora del Server NIS+. Per le RPC sicure si ha solo una piccola finestra di circa 3 minuti nella quale credenziali sono valide. Una buona idea è di eseguire xntpd su ognuno degli host. Dopo di questo, lanciare domainname domimio.nisplus nisinit -c -H per inizializzare il file d'avvio. Si legga la pagina man di nisinit per ulteriori opzioni. Assicurarsi che il nome di dominio rimanga sempre impostato dopo un reboot. Se non si conosce il nome del dominio NIS+ della propria rete, si chieda al proprio amministratore di sistema/rete. Ora si dovrebbe modificare il proprio file /etc/nsswitch.conf. Assicurarsi che il solo servizio dopo publickey sia nisplus ("publickey: nisplus"), e niente altro! Dopo di che, avviare keyserv e assicurarsi che sia sempre avviato all'avvio del sistema. Eseguire keylogin -r per salvare la chiave segreta (``secretkey'') di root nel proprio sis­ tema (spero si sia già aggiunta la chiave pubblica (``publickey'') per il nuovo host nel server NIS+?). Ora ``niscat passwd.org_dir'' dovrebbe mostrare tutte le voci nella base di dati passwd. 7.3. NIS+, keylogin, login e PAM Quando un utente effettua il login, è necessario che imposti la sua chiave segreta in keyserv. Ciò è fatto lanciando ``keylogin''. Il programma di login del pacchetto shadow fa questa cosa al posto dell'utente, se è stato compilato con la glibc 2.1. Per un programma di login con il supporto PAM, si deve installare pam_keylogin-1.2.tar.gz e cambiare il file /etc/pam.d/login per usare pam_unix_auth, e non pwdb, che non supporta NIS+. Un esempio: #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_keylogin.so auth required /lib/security/pam_unix_auth.so auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_unix_passwd.so session required /lib/security/pam_unix_session.so 7.4. Il file nsswitch.conf Il file del Network Services Switch /etc/nsswitch.conf determina l'ordine delle ricerche ("lookup") effettuate quando è richiesta una data informazione, proprio come il file /etc/host.conf determina il modo con il quale sono effettuate le ricerche degli host. Per esempio, la riga: hosts: files nisplus dns specifica che le funzioni di ricerca degli host dovrebbero prima guardare nel file /etc/hosts locale, poi effettuare un lookup NIS e alla fine una vera richiesta al domain name service (/etc/resolv.conf e named), e a quel punto, se non viene trovata alcuna corrispondenza, viene restituito un errore. Un buon file /etc/nsswitch.conf file per NIS+ è: # # /etc/nsswitch.conf # # Un esempio di file di configurazione del Name Service Switch. # Questo file dovrebbe essere ordinato in modo che i servizi più # comuni siano all'inizio. # # La voce '[NOTFOUND=return]' indica che la ricerca di una voce # dovrebbe fermarsi se la ricerca nella voce precedente non ha # restituito niente. Si noti che se la ricerca fallisce per qualche # altra ragione (come la mancata risposta del server NIS) allora la # ricerca continua con la voce successiva. # # Le voci ammesse sono: # # nisplus Usa NIS+ (NIS versione 3) # nis Usa NIS (NIS versione 2), detto anche YP # dns Usa DNS (Domain Name Service) # files Usa file locali # db Usa la base di dati /var/db # [NOTFOUND=return] Ferma la ricerca se prima non è stato # trovato niente # passwd: compat # per libc5: passwd: files nisplus group: compat # per libc5: group: files nisplus shadow: compat # per libc5: shadow: files nisplus 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 8. Impostare un server NIS 8.1. Il programma server ypserv Questo documento descrive solamente come impostare il server NIS ``ypserv''. Il software per il server NIS lo si può trovare su: Sito Directory Nome File ftp.kernel.org /pub/linux/utils/net/NIS ypserv-1.3.6.tar.gz Per maggiori informazioni si può dare un'occhiata anche a http://www.suse.de/~kukuk/linux/nis.html . L'impostazione del server è la stessa sia per il NIS tradizionale che per NYS. Si compili il software per generare i programmi ypserv e makedbm. È possibile configurare ypserv per usare il file securenets oppure tcp_wrapper. Il tcp_wrapper è molto più flessibile, ma un sacco di gente ha diversi problemi ad usarlo. Inoltre alcuni file di configurazione di tcp_wrapper possono causare spreco di memoria. Se si hanno problemi con ypserv compilato per tcp_wrapper, lo si ricompili usando il file securenets. Il comando ypserv --version mostrerà quale versione si sta usando. Se si fa funzionare il proprio server come master, si determinino quali file si vuole siano disponibili tramite NIS e poi si aggiungano o rimuovano le voci apposite nella regola ``all'' in /var/yp/Makefile. Si dovrebbe comunque dare un'occhiata al Makefile e modificare le opzioni all'inizio del file. C'è stato un solo grosso cambiamento tra ypserv 1.1 e ypserv 1.2. Dalla versione 1.2 ypserv fa il cache dei file handle. Ciò significa che si deve sempre lanciare makedbm con l'opzione -c se si creano delle nuove mappe. Sincerarsi di usare il nuovo /var/yp/Makefile di ypserv 1.2 o successivo, o si aggiunga l'opzione -c a makedbm nel Makefile. Se non lo si fa, ypserv continuerà ad usare le vecchie mappe e non quelle aggiornate. Ora si modifichino /var/yp/securenets e /etc/ypserv.conf. Per maggiori informazioni, leggere le pagine di manuale di ypserv(8) e ypserv.conf(5). Assicurarsi che il portmapper (portmap(8)) sia in esecuzione, e si avvii il server ypserv. Il comando % rpcinfo -u localhost ypserv dovrebbe restituire qualcosa di simile a program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting La riga ``version 1'' potrebbe non esserci a seconda della versione di ypserv e della configurazione usata. È necessaria solamente se si usano vecchi client SunOS 4.x. Ora si generi la base di dati NIS (YP). Sul master, si lanci % /usr/lib/yp/ypinit -m Su uno slave, assicurarsi che ypwhich -m funzioni. Ciò significa che lo slave dev'essere per prima cosa configurato come client NIS prima di poter eseguire % /usr/lib/yp/ypinit -s masterhost per installare l'host come slave NIS. È tutto, il proprio server è attivo e in esecuzione. Se si hanno grossi problemi, si può avviare ypserv e ypbind in modalità di debug su xterm separate. L'output di debug dovrebbe mostrare cosa non va. Se si deve aggiornare una mappa, si esegua make nella directory /var/yp del NIS master. Ciò aggiornerà una mappa se il file sorgente è stato modificato e invierà i file ai server slave. Non usare ypinit per aggiornare una mappa. Non è male poi modificare il crontab di root nello slave server e aggiungere le righe seguenti 20 * * * * /usr/lib/yp/ypxfr_1perhour 40 6 * * * /usr/lib/yp/ypxfr_1perday 55 6,18 * * * /usr/lib/yp/ypxfr_2perday Ciò assicura che la maggior parte delle mappe NIS saranno mantenute aggiornate, anche se un aggiornamento è stato perso a causa di un mal­ funzionamento (down) dello slave al momento dell'aggiornamento sul master. Uno slave può essere aggiunto in qualsiasi momento. Per prima cosa, assicurarsi che il nuovo server slave abbia i permessi per contattare il master NIS. Poi eseguire % /usr/lib/yp/ypinit -s masterhost sul nuovo slave. Sul server master si aggiunga poi il nome del nuovo server slave in /var/yp/ypservers e si esegua make in /var/yp per aggiornare le mappe. Se si vuole restringere l'accesso al proprio server NIS agli utenti, si deve impostare il server NIS come un client eseguendo ypbind e aggiungere le voci-più ("+") a /etc/passwd a mezza via del file delle password. Le funzioni di libreria ignoreranno tutte le normali voci dopo la prima voce NIS, e otteranno le restanti informazioni attraverso NIS. In questo modo sono mantenute le regole di accesso NIS. 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 [ Tutti i normali utenti DOPO questa riga! ] 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 impostata a /etc/NoShell. miquels avrà l'accesso normale. In alternativa, si può modificare il file /var/yp/Makefile ed impostare NIS ad usare un altro file di password come sorgente. Su sistemi grossi, i file delle password e dei gruppi NIS sono solitamente salvati in /var/yp/ypfiles/. Se lo si fa i normali strumenti per l'amministrazione del file delle password come passwd, chfn e adduser non funzioneranno più e si avrà bisogno di speciali strumenti fatti su misura. Comunque yppasswd, ypchsh e ypchfn ovviamente funzioneranno. 8.2. Il programma server yps Per l'impostazione del server NIS ``yps'' si faccia riferimento al paragrafo precedente. L'impostazione del server ``yps'' è simile ma non esattamente la stessa, quindi si faccia attenzione se si prova ad applicare le istruzioni di ``ypserv'' a ``yps"! ``yps'' non è supportato da alcun autore e contiene alcuni problemi di sicurezza. Quindi non è affatto consigliabile usarlo! Il software per il server NIS ``yps'' può essere trovato 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 8.3. Il programma rpc.ypxfrd rpc.ypxfrd è usato per velocizzare i trasferimenti di grosse mappe NIS dal NIS master ai diversi slave. Se un server NIS slave riceve un messaggio che attesta la presenza di una nuova mappa, avvierà ypxfr per trasferire la nuova mappa. ypxfr leggerà il contenuto di una mappa dal server master usando la funzione yp_all(). Questo processo può durare diversi minuti quando esistono mappe molto grosse che devono essere salvate dalla libreria di database. Il server rpc.ypxfrd velocizza il processo di trasferimento permettendo si server NIS slave di copiare semplicemente i file di mappa del master piuttosto che si costruiscano da soli la propria copia. rpc.ypxfrd usa un protocollo di trasferimento basato su RPC, cosicché non è necessario per la costruzione di nuove mappe. rpc.ypxfrd può essere avviato da inetd. Però poiché si avvia molto lentamente, dovrebbe essere lanciato assieme a ypserv. È necessario avviare rpc.ypxfrd solo sul master. 8.4. Il programma rpc.yppasswdd Ogni qual volta gli utenti cambiano le loro password, la base di dati NIS delle password e, probabilmente, altre basi di dati NIS che dipendono da questa dovrebbero essere aggiornate. Il programma "rpc.yppasswdd'' è un server che gestisce le modifiche delle password e assicura che le informazioni NIS sia aggiornate di conseguenza. rpc.yppasswdd è ora integrato in ypserv. Non serve più il vecchio yppasswd-0.9.tar.gz o yppasswd-0.10.tar.gz, e non dovrebbero essere più usati. Il rpc.yppasswd in ypserv 1.3.2 ha il pieno supporto per le shadow. yppasswd fa ora parte di yp-tools-2.2.tar.gz, Si deve lanciare rpc.yppasswd solo nel server NIS master. Di default, gli utenti non hanno il permesso di cambiare il loro nome o la loro shell di login. È possibile permettere tali modifiche con le opzioni -e chfn o -e chsh. Se i propri file passwd e shadow sono in una directory diversa da /etc, si deve aggiungere l'opzione -D. Per esempio, se si sono messi tutti i file sorgente in /etc/yp e si vuole che gli utenti possano cambiare la propria shell, si deve avviare rpc. yppasswdd con i seguenti parametri: rpc.yppasswdd -D /etc/yp -e chsh oppure rpc.yppasswdd -s /etc/yp/shadow -p /etc/yp/passwd -e chsh Non c'è molto altro da fare. Ci si deve solamente assicurare che rpc.yppasswdd usi gli stessi file di /var/yp/Makefile. Gli errori saranno registrati usando syslog. 9. Verificare l'installazione di NIS/NYS Se tutto è a posto (come dovrebbe essere), si dovrebbe essere essere in grado di verificare l'installazione con pochi semplici comandi. Assunto, per esempio, che il proprio file passwd sia gestito da NIS, il comando % ypcat passwd dovrebbe restituire il contenuto del proprio file NIS passwd. Il comando % ypmatch userid passwd (dove userid è il nome di login di un utente arbitrario) dovrebbe restituire la voce relativa all'utente nel file NIS passwd. I programmi ``ypcat'' e ``ypmatch'' dovrebbero essere inclusi nella propria distribuzione di NIS tradizionale o NYS. Se un utente non riesce a fare il login, si esegua il programma seguente nel client: #include #include #include int main(int argc, char *argv[]) { struct passwd *pwd; if(argc != 2) { fprintf(stderr,"Uso: getwpnam nomeutente\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,"Utente \"%s\" non trovato!\n",argv[1]); exit(0); } L'esecuzione di questo programma con il nome utente come parametro, mostrerà tutte le informazioni che la funzione getpwnam restituisce per quell'utente. Ciò dovrebbe mostrare quale voce non è corretta. Il problema più comune è che il campo della password è stato sovrascritto con un ``*". La GNU C Library 2.1 (glibc 2.1) contiene uno strumento chiamato gentent. In un sistema di questo tipo si usi questo programma invece di quello qua sopra. Si può provare: getent passwd o getent passwd login 10. Problemi comuni con NIS e soluzioni Ecco qui alcuni problemi riferiti da vari utenti: 1. Le librerie 4.5.19 hanno problemi. Il NIS non funzionerà con queste. 2. Se si aggiornano le librerie dalla 4.5.19 alla 4.5.24 allora il programma su si rompe. Ci si deve procurare il comando su dalla distribuzione Slackware 1.2.0. Non a caso questo è pure un posto dove si possono prendere le librerie aggiornate. 3. Quando un server NIS va giù e poi ritorna su ancora, ypbind si avvia mostrando un messaggio tipo: yp_match: clnt_call: RPC: Unable to receive; errno = Connection refused e il login è rifiutato a quanti sono registrati nella base di dati NIS. Provare a fare il login come root, si termini ypbind e lo si avvii ancora. Un aggiornamento a ypbind 3.3 o successivo dovrebbe aiutare. 4. Dopo l'aggiornamento di libc ad una versione successiva alla 5.4.20, gli YP tools non funzionano più. Si ha bisogno degli yp- tools 1.2 o successivi per la libc >= 5.4.21 e glibc 2.x. Per libc più recenti si deve usare yp-clients 2.2. Gli yp-tools 2.0 dovrebbero funzionare con tutte le librerie. 5. In libc 5.4.21 - 5.4.35 yp_maplist è rotta, c'è bisogno di libc 5.4.36 o successiva, o alcuni programmi YP come ypwhich provocheranno un segfault. 6. La libc 5 con il NIS tradizionale non supporta le password shadow su NIS. Sono necessarie le libc5 + NYS oppure glibc 2.x. 7. ypcat shadow non mostra la mappa shadow. Questo è corretto in quanto il nome della mappa shadow è shadow.byname, non shadow. 8. Solaris non usa sempre porte privilegiate. Quindi non si usi il mangling delle password se si ha un client Solaris. 11. Filza di Assilli Quotidiani (aka Frequently Asked Questions) La maggior parte delle domande ora dovrebbero aver trovato risposta. Se ci sono ancora questioni non risposte si può postare un messaggio in comp.os.linux.networking