nlnx.network u0.2
NLNX offre diversi servizi, sia localmente, sia attraverso la rete. Alcuni di questi sono attivabili anche durante il funzionamento da unità in sola lettura. Per leggere le sezioni successive, si tengano come riferimento anche le tabelle u44.2, u44.4, u44.10 e u44.5.
I file di configurazione di BIND, per la risoluzione dei nomi, sono collocati tutti nella directory /etc/bind/ e le zone di competenza, nell'impostazione iniziale, si riferiscono all'indirizzo 127.0.0.1.
Il nome nlnx viene indicato nel file /etc/hosts, come sinonimo di localhost, per garantire il funzionamento di alcuni programmi (si veda il capitolo 33 a proposito della configurazione di un servizio DNS con Bind). Se all'elaboratore si vuole attribuire un nome differente da nlnx, è necessario correggere il file /etc/hosts, in modo che contempli anche questo come sinonimo di 127.0.0.1.
Il file /etc/resolv.conf iniziale è configurato in modo da interrogare l'elaboratore locale, ma con la presenza di altri indirizzi di serventi DNS di fornitori ben conosciuti, i quali potrebbero tornare utili in caso di emergenza, o anche solo per conoscenza. Tuttavia, in presenza di una configurazione automatica della rete, questo file viene aggiornato, perdendo le informazioni originarie.
NLNX dispone di un cliente DHCP che viene usato in modo predefinito per la configurazione della rete locale.
|
L'utilizzo di un servizio DHCP può essere molto utile quando si usa NLNX da unità in sola lettura, senza un'organizzazione particolare del lavoro. Ma quando si installa NLNX in una serie di elaboratori, è preferibile avere un'attribuzione precisa degli indirizzi, anche senza dipendere necessariamente da un servizio DHCP. |
NLNX utilizza diverse «opzioni» DHCP per la propria configurazione, secondo lo schema della tabella seguente. Si osservi comunque che le direttive utilizzate sono più numerose di quelle descritte qui.
|
Il servizio DHCP viene fornito solo per l'interfaccia di rete che risulta essere "interna"; tuttavia, dal momento che si creano delle complicazioni quando si utilizza un elaboratore con una sola interfaccia, che però opera con più indirizzi, l'avvio del servizio viene gestito direttamente dallo script /etc/init.d/nlnx.network. Per questo, lo script /etc/init.d/dhcpd3-server non è in grado di avviare o di riavviare il servizio, ma solo di fermarlo.
Si veda anche la sezione u61 per una trattazione più ampia del contesto in cui si inserisce l'utilizzo del DHCP con NLNX.
NLNX dispone di un servente TFTP per la condivisione della directory /var/lib/tftpboot/, allo scopo di consentire l'avvio dalla rete, attraverso il protocollo PXE. L'avvio attraverso il protocollo PXE si avvale di PXELINUX, costituito in pratica dal file /var/lib/tftpboot/pxelinux/pxelinux.0 e dalla sua configurazione contenuta nella directory /var/lib/tftpboot/pxelinux/pxelinux.cfg/; gli altri file contenuti nella directory /var/lib/tftpboot/pxelinux/ vengono caricati attraverso il protocollo PXE, in base alla configurazione predisposta con PXELINUX.
Si veda anche il capitolo u56 per una trattazione più ampia dell'uso di questi protocolli con NLNX.
È disponibile il servente HTTP Mathopd. Allo scopo di semplificare il lavoro, si possono eseguire i programmi CGI se il nome del file corrispondente ha un'estensione del tipo .cgi, .pl o .sh; inoltre, se è installato l'interprete PHP, i file con estensione .php, .phtml o .pht vengono trattati attraverso questo sistema.
Si veda anche la sezione u57 a questo proposito.
NLNX include un servizio proxy HTTP, costituito da OOPS, che può essere usato in modo trasparente. In generale, OOPS si avvia automaticamente solo quando NLNX è stato installato secondo una modalità normale (per cui il file system viene usato in lettura e scrittura), altrimenti dal DVD live o da altra unità in sola lettura, è possibile avviare il servizio attraverso il comando seguente:
# /etc/init.d/oops start[Invio]
La configurazione predefinita prevede l'ascolto presso la porta 3 128; inoltre si fa a meno di usare file su disco per conservare le pagine e le altre risorse già visitate. Il funzionamento di un proxy HTTP e di OOPS in particolare è descritto nella sezione 42.2.
La configurazione di OOPS viene ripristinata dallo script /etc/init.d/nlnx.config, a ogni avvio del sistema, da una copia di sicurezza. Ciò permette di non perdere inavvertitamente la configurazione standard quando si aggiorna il programma; tuttavia, se NLNX è stato installato nel disco fisso e si vuole intervenire nella configurazione di OOPS, occorre ricordarsi di fare le stesse modifiche anche nel file /etc/oops/oops.cfg.nlnx, il quale rappresenta tale copia di sicurezza.
È possibile modificare facilmente la configurazione del registro di sistema allo scopo di inviare una copia di ciò che accade presso un elaboratore unico. Invece di modificare direttamente il file /etc/syslog.conf, si può intervenire con il comando seguente:
# nlnxrc log-server config[Invio]
.--------Log server----------. | Please specify the log | | server to send system log: | | .------------------------. | | | | | | `------------------------' | |----------------------------| | < OK > <Cancel> | `----------------------------' |
Supponendo di voler inviare una copia all'elaboratore 192.168.1.254:
192.168.1.254<OK>
È possibile sincronizzare il proprio elaboratore con un altro, che offra il servizio NTP o RDATE. Per questo è sufficiente usare il comando nlnxrc date config:
# nlnxrc date config[Invio]
.-------Rdate server---------. | Please specify the date | | server you trust: | | .------------------------. | | | | | | `------------------------' | |----------------------------| | < OK > <Cancel> | `----------------------------' |
pool.ntp.org<OK>
Se la configurazione riguarda una copia installata, oppure se viene salvata in qualche modo, all'avvio successivo l'allineamento dell'orologio avviene in modo automatico.
Per la sincronizzazione viene tentato un accesso attraverso ntpdate, il quale prevede già una propria configurazione nel file /etc/default/ntpdate. In questo file conviene evitare l'indicazione di un servente NTP, perché il meccanismo usato da NLNX non lo richiede. Infatti, durante l'avvio del sistema, NLNX interroga l'indirizzo indicato nel modo mostrato sopra, attraverso il protocollo NTP, ma se questo fallisce riprova con il protocollo RDATE. Dal momento che queste operazioni richiedono un certo tempo, sono eseguite sullo sfondo, senza sospendere temporaneamente l'esecuzione dello script in cui sono contenute. Ciò ha il vantaggio di non rallentare l'avvio quando l'elaboratore non ha un accesso alla rete esterna; se invece si specifica un servente NTP nel file /etc/default/ntpdate, da un lato si esegue per due volte la stessa funzione, dall'altro si ottiene una pausa inutile all'avvio se il servente NTP non può essere raggiunto.
NLNX dispone di un servente per il protocollo SSH (Secure Shell), che però non viene avviato automaticamente con il sistema operativo, durante il funzionamento da unità in sola lettura (come i DVD), se la parola d'ordine per accedere in qualità di utente amministratore è rimasta quella predefinita. Come già descritto, anche la condivisione dei dati attraverso il protocollo NFS non è attiva in modo predefinito se si sta usando il sistema da unità in sola lettura. Per attivare questi servizi, rispettivamente, si può intervenire nel modo seguente:
# /etc/init.d/ssh start[Invio]
# /etc/init.d/nfs-kernel-server start[Invio]
Oltre ai servizi elencati, che, per motivi di sicurezza, non vengono avviati automaticamente da unità in sola lettura, anche altri non lo sono, per evitare di appesantire inutilmente il funzionamento, oppure perché il contesto richiede che non lo siano. Nella tabella successiva ne vengono riepilogati alcuni.
|
Tabella u55.4. Alcuni servizi che non vengono avviati automaticamente durante il funzionamento da unità in sola lettura.
|
NLNX prevede la presenza di SANE per la gestione dello scanner. Per gli scanner che vengono riconosciuti automaticamente non ci sono problemi di utilizzo, inoltre è prevista una configurazione predefinita di SANE, tale da concedere l'accesso attraverso la rete, purché si tratti di indirizzi privati o comunque locali.
Per accedere a uno scanner remoto, è necessario intervenire nel file di configurazione /etc/sane.d/net.conf di ogni nodo cliente; tuttavia, se si usa il DHCP, lo script che si occupa della configurazione dinamica aggiorna questo file inserendo tutti gli elaboratori che risultano fornire qualche servizio (anche se diverso), considerando che uno scanner di rete potrebbe essere collocato in uno di quelli.
|
In pratica, se si vuole usare il DHCP e si intende predisporre uno scanner di rete, conviene collocare questo presso lo stesso elaboratore che funge già da servente di stampa, oppure quello che offre il servizio NIS, oppure anche quello che si usa per accumulare il registro di sistema degli elaboratori appartenenti alla rete locale. |
«a2» 2013.11.11 --- Copyright © Daniele Giacomini -- appunti2@gmail.com http://informaticalibera.net