Gestione di sistemi e gruppi di lavoro

Commenti

Transcript

Gestione di sistemi e gruppi di lavoro
Gestione di sistemi e gruppi di lavoro
Guida per gli amministratori di sistema HP-UX
Edizione 9
Server e workstation HP
Codice prodotto: B2355-90958
E0306
Marzo 2006
© Copyright 1997-2006 Hewlett-Packard Development Company, L.P.
Avvisi legali
Software per computer proprietario. Licenza valida da HP richiesta per il
possesso, l’uso o la copia. In base a quanto previsto da FAR 12.211 e
12.212, il software per computer proprietario, la documentazione del
software per computer ed i dati tecnici per gli articoli commerciali sono
dati in licenza al Governo degli Stati Uniti secondo la licenza commerciale
standard del rivenditore.
Garanzia
Le informazioni qui contenute possono essere modificate senza preavviso.
Le uniche garanzie per i prodotti ed i servizi HP sono stabilite nel
certificato di garanzia che accompagna questi prodotti e servizi. Nulla di
quanto segue potrà essere interpretato come elemento costituente di
garanzia aggiuntiva. HP non sarà da considerare responsabile di errori
tecnici o redazionali o omissioni qui contenuti.
È possibile ottenere una copia dei termini di garanzia specifici applicabili
al proprio prodotto e parti di ricambio Hewlett-Packard dal proprio Ufficio
vendite ed assistenza locale.
Avvisi sui marchi di fabbrica
DiskAccess® è un marchio di fabbrica registrato di Intergraph.
Intel® e Itanium® sono marchi di fabbrica registrati di Intel Corporation
o di sue società controllate negli Stati Uniti e negli altri paesi.
MS-DOS®, Windows NT® e Microsoft® sono marchi registrati di
Microsoft Corporation.
OSF/Motif™ è un marchio registrato di Open Software Foundation, Inc.
negli Stati Uniti e negli altri paesi.
UNIX® è un marchio di fabbrica registrato negli Stati Uniti e negli altri
paesi, brevettato esclusivamente attraverso The Open Group.
X Window System™ è un marchio di fabbrica del Massachusetts Institute
of Technology.
2
Cronologia della pubblicazione
La data della pubblicazione del manuale ed il codice prodotto indicano la
sua edizione corrente. La data di pubblicazione cambierà all’emissione di
una nuova edizione.
Per assicurarsi di ricevere le nuove edizioni, occorre abbonarsi al relativo
servizio di supporto prodotto. Per i dettagli, consultare il proprio
rappresentante delle vendite HP.
Prima edizione
Ottobre 1997, B2355-90157 (in inglese),
da HP-UX 9.0 fino a 11.0
a stampa, in CD-ROM (Instant Information) ed in rete
(http://www.docs.hp.com)
Seconda edizione Maggio 1998, B2355-90664 (in inglese),
da HP-UX 9.0 fino a 11.0,
in CD-ROM ed in rete (La versione a stampa è
disponibile da http://www.fatbrain.com/)
Terza edizione
Febbraio 2000, B2355-90676 (in inglese),
da HP-UX 9.0 fino a 11.0
In CD-ROM ed in rete
Quarta edizione Ottobre 2000, B2355-90701 (in inglese),
da HP-UX 10.0 fino a 11i v1 (B.11.11),
a stampa, in CD-ROM (Instant Information) ed in rete
(http://www.docs.hp.com/)
Quinta edizione Giugno 2001, B2355-90742 (in inglese),
da HP-UX 10.0 fino a 11i v1 (B.11.11),
a stampa, in CD-ROM (Instant Information) ed in rete
(http://www.docs.hp.com/)
Sesta edizione
Agosto 2003, 5187-2213 (in italiano),
da HP-UX 10.0 fino a 11i v2 (B.11.23),
a stampa ed in rete (http://www.docs.hp.com/)
Settima edizione Settembre 2004, 5990-8175 (in italiano),
da HP-UX 10.0 fino a 11i v2 (B.11.23),
a stampa ed in rete (http://www.docs.hp.com/)
3
Ottava edizione Settembre 2005, B2355-90920 (in italiano),
da HP-UX 10.0 fino a 11i v2 (B.11.23)
In rete (http://www.docs.hp.com/)
Scopo di questa edizione è di inserire le due seguenti
procedure rettificate e tre nuove sezioni:
Nona edizione
•
“Esecuzione del mirroring dei volumi logici di root,
di avvio e di scambio primario per i sistemi HP 9000
(PA-RISC)” a pagina 640
•
“Eseguire il mirroring di un disco di avvio con LVM
con HP-UX 11i per server HP Integrity” a
pagina 643
•
“Disconnessione temporanea di un collegamento ad
un volume fisico” a pagina 597
•
“Ripristino di un collegamento ad un volume fisico”
a pagina 598
•
“Sostituzione di un disco in mirroring in un volume
logico” a pagina 888
Marzo 2006, B2355-90958 (in italiano),
da HP-UX 10.0 fino a 11i v2 (B.11.23)
A stampa ed in rete (http://www.docs.hp.com/)
Scopo di questa edizione è comprendere le informazioni
su Distributed Systems Administration Utilities
(DSAU). Vedere “Utilizzo di Distributed Systems
Administration Utilities” a pagina 142.
4
Convenzioni
Sono utilizzate le seguenti convenzioni tipografiche.
audit (5)
Manpage di HP-UX. audit è il nome e 5 è la sezione nella
HP-UX Reference. In rete e nel CD Instant Information,
potrebbe essere presente un collegamento alla manpage
stessa. Per visualizzare la manpage, nella riga dei
comandi HP-UX, è possibile digitare “man audit”
oppure “man 5 audit”. Consultare man (1).
Titolo del manuale Titolo di un manuale. In rete e nel CD Instant
Information, potrebbe essere presente un collegamento
al manuale stesso.
KeyCap
Nome di un tasto della tastiera. Notare che Invio ed
Enter si riferiscono entrambi allo stesso tasto.
Enfasi
Testo enfatizzato.
Enfasi
Testo fortemente enfatizzato.
Termine
Uso definito di una parola o un’espressione importante.
ComputerOut
Testo visualizzato dal computer.
Input utente
Comandi ed altro testo digitato dall’utente.
Comando
Nome di un comando o espressione di comando
qualificata.
Variabile
Nome di una variabile che è possibile sostituire in un
comando o funzione, oppure informazioni in una
schermata che rappresentano vari valori possibili.
[ ]
Il contenuto è facoltativo nei formati e nelle descrizioni
del comando.
{ }
Il contenuto è necessario nei formati e nelle descrizioni
del comando. Nel caso il contenuto sia un elenco di voci
separate dal carattere |, occorrerà sceglierne una.
...
L’elemento che precede può essere ripetuto un numero
arbitrario di volte.
|
Separa le voci in un elenco di scelte.
5
6
Indice
1. Sistemi e gruppi di lavoro
Punto centrale dei gruppi di lavoro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modalità di utilizzo dei termini Sistema e Gruppo di lavoro. . . . . . . . . . . . . . . . . . . . .
Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gruppi di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipi di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utente unico o multiutente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server o client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistemi partizionati (il partizionamento in continuo) . . . . . . . . . . . . . . . . . . . . . . . .
Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistemi operativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipi di gruppi di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NFS Diskless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiutente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
41
41
41
42
42
42
43
46
46
47
47
48
48
2. Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modello multiutente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modello NFS Diskless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modello client-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distribuzione delle applicazioni e dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modello di condivisione dei file HP-UX (V.4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questo come aiuta a condividere i file? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cosa distribuire, cosa tenere a livello locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pratica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distribuzione delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server a scopi specifici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Un gruppo di lavoro/rete campione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La rete MSW (Generalità) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La rete MSW (sistema per sistema). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistemi server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personal Computer (PC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
50
52
53
56
56
56
57
57
57
58
59
60
60
62
62
64
64
66
68
7
Indice
Thin client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Stampanti di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Impostazione della strategia di gestione dei dischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Distribuzione dei dischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Pianificazione delle capacità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
File server e server delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Strumenti di gestione del disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
VERITAS Volume Manager (VxVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Disco intero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Occorre usare un Logical Volume Manager o il Disco intero? . . . . . . . . . . . . . . . . 76
Mirroring del disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Striping del disco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Pianificazione della gestione dei file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Introduzione alla Gestione dei file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Determinazione di quale tipo di file system usare . . . . . . . . . . . . . . . . . . . . . . . . . 80
Journaled File System, il default del file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
FAQ sul Journaled File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
JFS ed altri file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
JFS e le operazioni interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
JFS ed il comando mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Funzionalità di HP OnLineJFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Gestione degli utenti su sistemi multipli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Linee guida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Occorre condividere la home directory e la directory della posta degli utenti?. . . . 101
Pianificazione della configurazione della stampante . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Panoramica dello spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
File modello della stampante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Tipi di stampanti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Nome della stampante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Classe di stampanti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Destinazione della stampa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Priorità di stampanti e richieste di stampa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Registrazione della stampante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Scalabilità e lo spooler LP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8
Indice
HP Distributed Print Service (HPDPS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cos’è HPDPS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perchè usare HPDPS?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pianificazione per implementare HPDPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Per ulteriori informazioni sulle procedure correlate alla stampante. . . . . . . . . . . .
Distribuzione dei backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di HP OpenView OmniBack II per l’esecuzione del backup . . . . . . . . . . . . . . .
Servizi per scambio dati con Personal Computer. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strumenti di trasferimento file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kermit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Emulatori del terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Versioni di sistemi operativi simili a UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Versioni del sistema X Window per PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Versioni dei sistemi PC Windows per sistemi HP-UX . . . . . . . . . . . . . . . . . . . . . . .
Montaggi NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistemi operativi di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Possibili problemi nello scambio di dati tra HP-UX e PC . . . . . . . . . . . . . . . . . . . . . .
Problemi di fine riga ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il problema della differenza Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cos’è Endian? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocolli Internet ed IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informazioni su IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
112
113
114
121
122
122
124
124
124
125
125
126
126
127
128
128
129
129
130
130
131
131
133
133
3. Configurazione di un sistema
Avvio di un sistema precaricato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso del desktop CDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di System Administration Manager (SAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso dei comandi di SAM rispetto a quelli di HP-UX . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di SAM con un sistema X Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di SAM con un terminale di testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di SAM per l’amministrazione di sistemi remoti . . . . . . . . . . . . . . . . . . . . . . .
Concessione agli utenti dell’accesso limitato a SAM . . . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione delle informazioni sul dispositivo in SAM . . . . . . . . . . . . . . . . . . .
136
137
138
139
139
140
140
140
140
141
9
Indice
Utilizzo di Distributed Systems Administration Utilities . . . . . . . . . . . . . . . . . . . . . .
Introduzione a Configuration Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica di cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelli di attuazione del server master di cfengine . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di Configuration Synchronization Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione manuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Note sulla sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disattivazione dell’uso di cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opzioni di registrazione eventi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risoluzione dei problemi di cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduzione a syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formato dei messaggi di syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filtro dei messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica della consolidazione dei registri eventi . . . . . . . . . . . . . . . . . . . . . . . . .
Consolidazione dei registri eventi migliorata . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Coesistenza con syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione della consolidazione dei registri eventi . . . . . . . . . . . . . . . . . . . . . .
Uso di Log Consolidation Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione manuale della consolidazione dei registri eventi . . . . . . . . . . . .
Configurazione manuale dei client per l’inoltro dei registri eventi . . . . . . . . . . .
Disattivazione della consolidazione dei registri eventi. . . . . . . . . . . . . . . . . . . . . . .
Disattivazione di un sistema indipendente di consolidazione dei registri eventi
Disattivazione di un sistema di consolidazione dei registri eventi in un cluster
Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disattivazione di un client indipendente per l’inoltro dei registri eventi . . . . . .
Disattivazione di un client per l’inoltro dei registri eventi in un cluster
Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protezione dei registri eventi consolidati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protezione del file di log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port forwarding ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di Bastille per rafforzare il sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione dei registri eventi consolidati . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di System Management Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduzione a Command Fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parallel Distributed Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wrapper dell’utility pdsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
142
142
143
147
148
148
159
175
178
178
179
181
181
183
183
184
185
189
189
204
219
228
228
229
230
231
232
232
233
235
236
236
237
237
239
Indice
Configurazione di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risoluzione dei problemi della distribuzione dei comandi . . . . . . . . . . . . . . . . . .
Controllo dell’accesso ad un sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di utente ad un sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatizzare il processo di aggiunta di un utente . . . . . . . . . . . . . . . . . . . . . . .
Controllo dell’accesso del file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definizione di appartenenza al gruppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione dei permessi di accesso al file . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione del possesso per i file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione delle Liste di controllo dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo dell’uso e dei processi con i livelli di esecuzione . . . . . . . . . . . . . . . . . . .
Aggiunta di periferiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di terminali non HP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problemi di ricerca guasti con i terminali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminali che non rispondono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altri problemi del terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione delle manpage in linea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Realizzazione delle regolazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione dell’orologio del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problemi potenziali quando si modifica l’orologio del sistema . . . . . . . . . . . . . . .
Impostazione del fuso orario (Time Zone - TZ) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione dell’ora e della data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione manuale delle informazioni iniziali . . . . . . . . . . . . . . . . . . . . . . . . . .
Personalizzazione degli ambienti del sistema e del login utente . . . . . . . . . . . . . .
Configurazione dei servizi di posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Componenti di un sistema di posta elettronica. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agenti dell’utente di posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agenti di consegna della posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File alias di posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La coda della posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Topografie di networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta di una topografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applicazioni MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di un sistema per l’invio di posta elettronica . . . . . . . . . . . . . . . . .
Uso del mascheramento del sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di un sistema per la ricezione di posta elettronica . . . . . . . . . . . . .
Topografia dell’hub di posta centrale (che riceve posta elettronica). . . . . . . . . . .
240
242
244
244
247
249
249
250
250
250
251
254
255
257
257
263
265
267
267
267
268
268
269
271
272
272
272
273
274
274
274
277
277
278
278
279
280
11
Indice
Topografia dell’hub di posta gateway (che riceve posta elettronica) . . . . . . . . . .
Topografia (di sistema indipendente) a distribuzione totale . . . . . . . . . . . . . . . .
Riconfigurazione della kernel
(Prima di HP-UX 11i versione 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedura per riconfigurare la kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Se la nuova kernel non si avvia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei moduli della kernel a caricamento dinamico . . . . . . . . . . . . . . . . . . . .
Concetti DLKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strumenti DLKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedure DLKM per i moduli caricabili a configurazione dinamica . . . . . . . . .
Procedure DLKM per i moduli caricabili a configurazione statica. . . . . . . . . . . .
Glossario DLKM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Riconfigurazione della kernel (HP-UX 11i versione 2) . . . . . . . . . . . . . . . . . . . . . . . .
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funzionalità di configurazione della kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cos’è una configurazione della kernel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica dei comandi di configurazione della kernel. . . . . . . . . . . . . . . . . . . .
Panoramica dello strumento kcweb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altre operazioni di configurazione della kernel. . . . . . . . . . . . . . . . . . . . . . . . . . .
Comportamento comune per i comandi di configurazione della kernel. . . . . . . . . .
Opzioni della riga di comando comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Formati di output comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Codici di stato di uscita comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vincoli di sicurezza comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Permanenza delle modifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei moduli della kernel con kcmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sui moduli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sul modulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica degli stati del modulo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei moduli della kernel con kcweb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sui moduli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sul modulo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica degli stati del modulo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei parametri settabili della kernel con kctune. . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sui settaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sul settaggio. . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica dei valori dei settaggi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
281
282
284
287
288
289
290
301
305
315
317
319
319
319
320
321
322
324
325
325
326
327
328
328
329
329
331
333
334
335
336
337
339
340
342
343
Indice
Gestione dei parametri settabili della kernel con kcweb . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sui settaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sul settaggio. . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica dei valori dei settaggi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoraggio dell’uso delle risorse della kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sugli allarmi con kcweb . . . . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sugli allarmi con kcweb. . . . . . . . . . . . . . . . .
Modifica dei valori degli allarmi con kcweb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comandi dell’uso delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione della configurazione in esecuzione usando kconfig . . . . . . . . . . . . . . . . . .
Gestione delle configurazioni salvate con kconfig. . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sulle configurazioni salvate . . . . . . . . . . . . . . . .
Interpretazione delle informazioni sulla configurazione salvate . . . . . . . . . . . . .
Uso e modifica delle configurazioni salvate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione delle configurazioni con i file di sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
Realizzazione delle modifiche di configurazioni con i file di sistema . . . . . . . . . .
Usi per i file di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione delle specificazioni del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivo di scambio primario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivi di copiatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifiche del driver del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il file di log di configurazione della kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analisi sintattica dell’output dei comandi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recupero dagli errori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La configurazione di backup automatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di una configurazione salvata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio in modo esente da guasti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per il recupero dagli errori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di configurazione della kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabelle di riferimento rapido di configurazione della kernel . . . . . . . . . . . . . . . . . .
Transizione dalle release precedenti di HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . .
345
346
346
348
351
351
353
354
356
357
358
358
359
360
361
362
364
366
366
367
368
369
370
371
371
373
373
374
375
382
387
4. Configurazione di un gruppo di lavoro
Installazione di nuovi sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurare nuovi sistemi in rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione delle informazioni sulla rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
392
392
393
393
13
Indice
Concessione dell’accesso a sistemi remoti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurare nuovi sistemi in un gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di utenti ad un gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accesso a sistemi multipli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Condivisione di directory di lavoro remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Home directory locali ed home directory remote. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di un utente a vari sistemi: un caso di studio . . . . . . . . . . . . . . . . . . . . . .
Esportazione di una home directory locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementazione della strategia di gestione dei dischi . . . . . . . . . . . . . . . . . . . . . . . .
Condivisione di file ed applicazioni attraverso NFS e ftp . . . . . . . . . . . . . . . . . . . . . .
Esportazione di un file system (da HP-UX ad HP-UX) . . . . . . . . . . . . . . . . . . . . . .
Importazione di un file system (da HP-UX ad HP-UX) . . . . . . . . . . . . . . . . . . . . . .
Importazione di directory HP-UX ad NT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CIFS/9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prodotti di terzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ricerca guasti di NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voci richieste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recupero dei servizi di rete dopo un guasto dell’alimentazione. . . . . . . . . . . . . . . .
Sintomi e parole chiave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cosa fare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spostamento o riutilizzo di una directory esportata. . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dell’ftp anonimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ricerca guasti del login ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di sistemi PC/NT al gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connessioni hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei sistemi HP-UX per l’emulazione del terminale . . . . . . . . . . . .
telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altri emulatori del terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei sistemi HP-UX per il trasferimento file . . . . . . . . . . . . . . . . . .
ftp (File Transfer Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montaggio dei file system tra HP-UX e PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di stampanti per un gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di stampanti per usare lo spooler LP. . . . . . . . . . . . . . . . . . . . . . . .
Inizializzazione dello spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di una stampante locale allo spooler LP. . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di una stampante remota allo spooler LP . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di una stampante su base di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
394
395
396
396
397
397
397
400
401
402
403
404
408
408
409
411
414
414
414
415
416
416
419
420
420
421
421
424
424
425
439
440
440
440
441
443
446
Indice
Creazione di una classe di stampanti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rimozione di una stampante dallo spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rimozione di una stampante da una classe di stampanti. . . . . . . . . . . . . . . . . . .
Rimozione di una classe di stampanti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione delle stampanti per usare HPDPS. . . . . . . . . . . . . . . . . . . . . . . . . .
Implementazione di HPDPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio automatico di HPDPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica degli ambienti degli utenti per usare HPDPS . . . . . . . . . . . . . . . . . . . .
Compatibilità tra HP-UX Release 10.x ed 11.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità da HP-UX 10.x ad 11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità binaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità della sorgente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità di upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità binaria riallocabile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità tra 32 bit e 64 bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esecuzione di applicazioni 10.x su HP-UX 11.0 . . . . . . . . . . . . . . . . . . . . . . . . . .
Decisione sul trasferimento o meno del software . . . . . . . . . . . . . . . . . . . . . . . . .
Quando non trasferire il software da piattaforma su HP-UX 11.0. . . . . . . . . . . .
Quando trasferire il software su HP-UX 11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione per la transizione del software ad HP-UX 11.0. . . . . . . . . . . . .
Quali strumenti di transizione STK sono disponibili? . . . . . . . . . . . . . . . . . . . . .
Scambio di dati tra applicazioni a 32 bit ed a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . .
Uso di ‘pipe’ tra applicazioni a 32 bit ed a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilità di file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Per configurare il supporto di file di grandi dimensioni con NFS . . . . . . . . . . . . . .
Supporto di file di grandi dimensioni e compatibilità del protocollo NFS. . . . . . . .
446
447
449
450
451
452
454
454
455
455
455
455
456
456
456
457
457
458
458
459
460
461
461
462
462
465
465
5. Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La sequenza di avvio: Avvio di un sistema HP-UX . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di HP-UX nei server HP Integrity: dettagli e varianti . . . . . . . . . . . . . . . . . .
Avvio standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio automatico ed avvio manuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio da un’origine alternativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modica dei percorsi di avvio PRI, HAA e ALT . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica del contenuto del file AUTO in un dispositivo di avvio . . . . . . . . . . . . .
470
470
471
472
473
477
479
482
15
Indice
Avvio in modalità utente singolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio in modalità di manutenzione LVM (o VxVM) . . . . . . . . . . . . . . . . . . . . . . .
Avvio di HP-UX nei sistemi HP 9000 (PA-RISC): dettagli e varianti . . . . . . . . . . .
Avvio standard (sistemi PA-RISC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio automatico ed avvio manuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifica dei percorsi di avvio PRI, HAA e ALT . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di sistemi PA-RISC da un’origine alternativa di avvio . . . . . . . . . . . . . . . .
Modifica del contenuto del file autoexecute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio in modalità utente singolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio in modalità manutenzione LVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Velocizzazione dell’avvio: SpeedyBoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test di avvio del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione delle impostazioni SpeedyBoot del sistema . . . . . . . . . . . . . . . .
Configurazione dei test di sistema d’avvio con il menu di BCH (solo per
sistemi HP 9000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei test di sistema d’avvio con la shell EFI (solo per s
erver HP Integrity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei test d’avvio da un sistema in esecuzione . . . . . . . . . . . . . . . .
Uso di setboot per la configurazione delle impostazioni di SpeedyBoot. . . . . . . .
Impostazione delle informazioni iniziali sul sistema . . . . . . . . . . . . . . . . . . . . . . . . . .
Personalizzazione dell’avvio e dello spegnimento . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spegnimento dei sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica dei processi di spegnimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pronti . . . Attenti . . . Via!. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipi di spegnimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spegnimento normale (pianificato) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guasto dell’alimentazione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spegnimenti non puliti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crash di sistema / Attacchi di panico di HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . .
Modalità utente singolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Considerazioni speciali per lo spegnimento di alcuni sistemi . . . . . . . . . . . . . . . . .
Server della posta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server di nomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gateway di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File server NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server cluster NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
489
491
492
492
494
497
499
502
503
505
506
508
509
511
512
513
515
517
519
524
524
525
526
526
530
531
532
532
532
533
533
533
534
534
535
Indice
Client cluster NFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evitare uno spegnimento quando possibile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta e sostituzione in linea di schede PCI (OLA/R). . . . . . . . . . . . . . . . . . . .
Spegnimenti anomali del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica del ciclo copiatura / salvataggio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparazione ad un crash di sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistemi che eseguono release di HP-UX precedenti alla 11.0. . . . . . . . . . . . . . . .
Decisioni sulla configurazione di copiatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definizione dei dispositivi di copiatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Che cosa succede quando il sistema subisce un crash . . . . . . . . . . . . . . . . . . . . . . .
Sistemi che eseguono release di HP-UX precedenti alla 11.0. . . . . . . . . . . . . . . .
Opzioni di override dell’operatore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La copiatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il riavvio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Che cosa fare quando il sistema si è riavviato . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di crashutil per completare il salvataggio di una copiatura . . . . . . . . . . . . .
Opzioni savecrash per copiature compresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conversione del formato delle copiature non compresse . . . . . . . . . . . . . . . . . . .
Conversione del formato delle copiature compresse . . . . . . . . . . . . . . . . . . . . . . .
Analisi delle copiature del crash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
535
535
535
536
537
538
539
539
548
555
555
555
557
557
558
559
560
560
561
561
6. Amministrazione di un sistema: Gestione di dischi e file
Gestione dei dischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fatti attuali sulla gestione di dischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fatti utili su LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Come funziona LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pianificazione per l’uso di volumi logici. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei volumi logici per file system . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurare volumi logici per lo scambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei volumi logici per la memorizzazione di dati grezzi . . . . . . . .
Uso di interfacce di disco I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Riubicazione dei blocchi difettosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aumento della disponibilità con collegamenti alternativi . . . . . . . . . . . . . . . . . .
Convenzioni di nomenclatura di LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Denominazione dei volumi fisici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Denominazione dei gruppi di volumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
564
565
566
566
567
570
571
573
574
575
575
576
576
576
577
17
Indice
Denominazione dei volumi logici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Denominazione dei gruppi di volumi fisici. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei volumi logici mediante SAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei volumi logici mediante i comandi di HP-UX . . . . . . . . . . . . . . . . . . . .
Esempio: Creazione di un volume logico mediante i comandi di HP-UX . . . . . . .
Procedure che si possono eseguire solo con i comandi di HP-UX . . . . . . . . . . . . . . .
Estensione di un volume logico su un disco specifico . . . . . . . . . . . . . . . . . . . . . .
Creazione di un gruppo di volumi di root e di volumi logici di root e di avvio. . .
Esecuzione del backup e ripristino della configurazione del gruppo di volumi .
Spostamento e riconfigurazione dei dischi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spostamento dei dati su un diverso volume fisico . . . . . . . . . . . . . . . . . . . . . . . .
Riduzione delle dimensioni di un volume logico:. . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di collegamenti alternativi ad un volume fisico . . . . . . . . . . . . .
Disconnessione temporanea di un collegamento ad un volume fisico . . . . . . . . .
Ripristino di un collegamento ad un volume fisico . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dello striping del disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedure LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ricerca guasti LVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Se non si riesce ad avviare da un volume logico . . . . . . . . . . . . . . . . . . . . . . . . . .
Problemi dopo la riduzione delle dimensioni di un volume logico . . . . . . . . . . . .
Gestione degli errori I/O all’interno di LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nessuna risposta o output di programma da un disco . . . . . . . . . . . . . . . . . . . . .
Gestione dei file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creazione di un file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montaggio di file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montaggio dei file system usando i comandi di HP-UX. . . . . . . . . . . . . . . . . . . .
Montaggio automatico dei file system all’avvio . . . . . . . . . . . . . . . . . . . . . . . . . .
Risoluzione dei problemi relativi al montaggio . . . . . . . . . . . . . . . . . . . . . . . . . . .
Smontaggio di file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Smontaggio di file system NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Smontaggio automatico dei file system allo spegnimento . . . . . . . . . . . . . . . . . .
Risoluzione dei problemi relativi allo smontaggio . . . . . . . . . . . . . . . . . . . . . . . .
Estensione delle dimensioni di un file system all'interno di un volume logico . . . .
Procedura di esempio per aumentare le dimensioni di un volume logico . . . . . .
Copiatura di un file system fra dispositivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione della corruzione del file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
578
579
579
580
583
584
585
586
589
591
594
594
596
597
598
598
602
602
602
606
607
610
611
612
614
615
616
616
617
618
618
619
619
620
621
622
622
Indice
Diagnosi di un file system corrotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ubicazione e correzione della corruzione usando fsck. . . . . . . . . . . . . . . . . . . . . .
Sostituzione di un file system esistente con uno più piccolo . . . . . . . . . . . . . . . . . .
Se si usa JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Se non si stanno usando i volumi logici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Se si stanno usando i volumi logici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dell’uso dello spazio su disco con quote . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione ed attivazione delle quote di disco.. . . . . . . . . . . . . . . . . . . . . . . .
Disattivazione delle quote di disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Che cosa fare quando si supera un limite flessibile. . . . . . . . . . . . . . . . . . . . . . . .
Che cosa fare quando si supera un limite rigido. . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dei file system con mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creazione e modifica dei volumi logici con mirroring . . . . . . . . . . . . . . . . . . . . .
Effettuazione di un backup in linea attraverso la suddivisione di un
volume logico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento della separazione dei canali I/O.. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esecuzione del mirroring dei volumi logici di root, di avvio e di scambio
primario per i sistemi HP 9000 (PA-RISC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eseguire il mirroring di un disco di avvio con LVM con HP-UX 11i per
server HP Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedure di mirroring che devono essere eseguite usando i comandi di HP-UX
Deframmentazione di un file system JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conversione di file system esistenti in JFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metodo 1: Copia di HFS su JFS su un volume logico nuovo . . . . . . . . . . . . . . . . .
Metodo 2: Sostituzione di HFS con JFS sul volume logico esistente . . . . . . . . . .
Metodo 3: Conversione da HFS a JFS usando vxfsconvert. . . . . . . . . . . . . . . . . .
Ridimensionamento di un file system JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Per ridimensionare un file system JFS usando fsadm . . . . . . . . . . . . . . . . . . . . .
Per ridimensionare un file system JFS di base . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi e procedure di riferimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione di file di grandi dimensioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creazione di un file system per file di grandi dimensioni . . . . . . . . . . . . . . . . . .
Esempi di creazione di un file system per file di grandi dimensioni . . . . . . . . . .
Esempi di creazione di un file system per file non di grandi dimensioni. . . . . . .
Modifica da un file system per file di grandi dimensioni . . . . . . . . . . . . . . . . . . .
Supporto dei comandi per file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . .
Riparazione di un file system per file di grandi dimensioni con fsck . . . . . . . . . .
Il comando mount e i file system per file di grandi dimensioni . . . . . . . . . . . . . .
623
623
628
628
628
629
629
630
634
634
635
637
637
639
640
640
643
646
652
653
655
657
659
661
661
663
663
664
664
664
665
665
666
666
666
19
Indice
Per maggiori informazioni sui file di grandi dimensioni. . . . . . . . . . . . . . . . . . . .
Gestione dell’FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abilitazione/disabilitazione del file di configurazione/etc/ftpd/ftpaccess . . . . . . .
Controllo dei nomi di percorso dei file di configurazione FTP . . . . . . . . . . . . . . .
Ottenimento di informazioni sugli utenti FTP . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creazione di un messaggio di spegnimento dell'FTP . . . . . . . . . . . . . . . . . . . . . .
Registrazione delle informazioni sulla sessione FTP . . . . . . . . . . . . . . . . . . . . . .
Registrazione dei trasferimenti di file FTP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione del supporto FTP virtuale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dello scambio e della copiatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipi di spazio di scambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scambio del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scambio del file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pseudoscambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scambio primario e secondario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Progettazione dell'allocazione dello spazio di scambio . . . . . . . . . . . . . . . . . . . . . . .
Verifica della quantità di spazio di scambio di cui si dispone attualmente . . . . .
Stima delle esigenze di spazio di scambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Regolazione dei parametri di sistema dello spazio di scambio . . . . . . . . . . . . . . .
Linee guida per la configurazione delle aree di scambio del dispositivo . . . . . . .
Linee guida per la configurazione delle aree di scambio del file system . . . . . . .
Linee guida per l’assegnazione della priorità di scambio . . . . . . . . . . . . . . . . . . .
Aggiunta, modifica ed eliminazione dello scambio del file system . . . . . . . . . . . . .
Configurazione dello scambio primario e secondario . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione della copiatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quanto spazio su disco occorre usare per la copiatura? . . . . . . . . . . . . . . . . . . . .
Configurazione delle aree di copiatura usando i comandi di HP-UX . . . . . . . . . .
Effettuazione del backup dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta del tipo di dispositivo di memorizzazione. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta di una utility di backup/recupero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta di HP Omniback per il backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta di SAM per il backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta di una utility di backup/recupero di HP-UX. . . . . . . . . . . . . . . . . . . . . . . .
Determinazione dei dati di cui effettuare il backup . . . . . . . . . . . . . . . . . . . . . . . . .
Definizione dei file e delle directory di cui effettuare il backup . . . . . . . . . . . . . .
Determinazione della frequenza del backup dei dati . . . . . . . . . . . . . . . . . . . . . . . .
Backup completi o backup incrementali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
667
667
667
668
668
669
669
669
670
671
671
671
672
672
673
673
673
674
676
676
677
678
678
680
681
682
682
684
685
686
686
687
687
692
692
693
693
Indice
Livelli di backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempio di impostazione dei livelli di backup . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup dei dati usando il comando fbackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedura generale per l’uso del comando fbackup. . . . . . . . . . . . . . . . . . . . . . . .
Creazione del file dell'indice analitico sul dispositivo locale . . . . . . . . . . . . . . . .
Backup di file con montaggio NFS con fbackup . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi di comandi fbackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup di file su un sistema remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup remoto usando fbackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup remoto usando cpio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup remoto usando tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di un programma di backup automatico . . . . . . . . . . . . . . . . . . . . .
Creazione di un programma di backup automatico . . . . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione di un programma di backup automatico. . . . . . . . . . . . . . . . . . . . .
Attivazione di un programma di backup automatico . . . . . . . . . . . . . . . . . . . . . . . .
Backup se si sta usando LVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup dei file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utility di backup che supportano file di grandi dimensioni . . . . . . . . . . . . . . . . .
Utility di backup che non supportano file di grandi dimensioni . . . . . . . . . . . . .
Ripristino dei file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup di un’istantanea JFS del file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Come creare ed effettuare il backup di un’istantanea JFS del file system . . . . .
Ripristino dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determinazione dei dati da ripristinare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prima del ripristino dei dati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ripristino dei dati usando SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ripristino dei dati usando i comandi di HP-UX.. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ripristino dei file di cui si sia effettuato il montaggio NFS.. . . . . . . . . . . . . . . . .
Ripristino dei file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi di ripristino dei dati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi di ripristino remoto dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recupero da un crash di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
693
695
696
696
697
698
698
700
700
700
700
701
701
703
703
704
704
704
705
705
705
705
708
708
709
709
709
710
710
710
711
711
21
Indice
7. Amministrazione di un sistema: Gestione di stampanti, software e
prestazioni
Gestione delle stampanti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione dello spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interruzione e riavvio dello spooler LP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo del flusso di richieste di stampa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abilitazione o disabilitazione di una stampante . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione della priorità della barriera di una stampante . . . . . . . . . . . . . . .
Modifica della priorità di richiesta di default di una stampante . . . . . . . . . . . . .
Sommario delle procedure aggiuntive delle stampanti . . . . . . . . . . . . . . . . . . . .
Risoluzione dei comuni problemi relativi alle stampanti . . . . . . . . . . . . . . . . . . .
Tipici comandi di LP per utenti e amministratori di LP. . . . . . . . . . . . . . . . . . . .
Amministrazione di HP Distributed Print Service (HPDPS). . . . . . . . . . . . . . . . . .
Riepilogo dei comandi di HPDPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migrazione delle stampanti di spooler LP su HPDPS. . . . . . . . . . . . . . . . . . . . . .
Gestione del software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Distributor (SD-UX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Struttura del Software SD-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ubicazione del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedure di SD-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ruoli di SD-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Package Builder (SPB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informazioni sui patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Patch consigliati - Extension Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installazione di Extension Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rimozione dei patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione delle prestazioni di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Colli di bottiglia delle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processi avidi di risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Misurazione delle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifica del carico del disco con sar ed iostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifica delle dimensioni del blocco server /client NFS. . . . . . . . . . . . . . . . . . . . .
Verifica delle scritture asincrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifica del sovraccarico del server con nfsstat -rc . . . . . . . . . . . . . . . . . . . . . . . .
Misurazione dell’utilizzo della memoria con vmstat . . . . . . . . . . . . . . . . . . . . . . .
Verifica della presenza di overflow del socket con netstat -s . . . . . . . . . . . . . . . .
22
714
714
715
716
717
717
718
718
720
721
723
723
725
726
726
727
728
729
734
735
737
737
737
738
739
739
740
742
743
743
744
745
745
746
746
Indice
Verifica della presenza di sovraccarichi di rete con netstat -i . . . . . . . . . . . . . . .
Effettuazione di modifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aumento del numero di daemon nfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deframmentazione di un file system HFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parametri della kernel configurabili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ulteriori strumenti di gestione delle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . .
SAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il comando top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prodotti OpenView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Resource Monitor (KRM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
746
747
747
747
749
749
750
750
751
752
8. Amministrazione di un sistema: Gestione della sicurezza del sistema
Sicurezza standard del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pianificazione della sicurezza del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pratiche di sicurezza comuni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mantenimento della sicurezza del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida fondamentali. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelte di sicurezza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Come ottenere gli HP-UX Security Bulletin ed i patch . . . . . . . . . . . . . . . . . . . . . .
Gestione delle password standard e dell’accesso al sistema . . . . . . . . . . . . . . . . . . . .
Criteri per creare una buona password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File di password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il file /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eliminazione degli pseudoaccount e protezione dei sottosistemi chiave . . . . . . . . .
Accesso del sistema tramite modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protezione dei programmi dall’esecuzione illegale . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione dell’accesso a file e directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso delle liste di controllo dell’accesso (ACL) HFS. . . . . . . . . . . . . . . . . . . . . . . . . .
ACL HFS e comandi e chiamate HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso delle liste di controllo dell’accesso (ACL) JFS . . . . . . . . . . . . . . . . . . . . . . . . . .
Definizione di una ACL JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ACL JFS minima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voci aggiuntive di utente e di gruppo ACL JFS . . . . . . . . . . . . . . . . . . . . . . . . . .
Voci di classe ACL JFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste di controllo dell’accesso JFS di default . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modalità di generazione di ACL JFS da parte del sistema . . . . . . . . . . . . . . . . .
Esame di una ACL JFS con getacl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
754
755
756
756
757
758
758
760
760
761
762
762
764
765
765
766
768
770
770
770
771
772
775
777
777
23
Indice
Modifica delle liste di controllo dell’accesso JFS di un file con setacl . . . . . . . . .
Confronto fra ACL JFS e HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differenze funzionali tra ACL JFS e HFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappatura dei comandi e delle funzioni di JFS e HFS . . . . . . . . . . . . . . . . . . . .
Le ACL in un ambiente di rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione dei permessi di default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protezione delle directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protezione degli account utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Considerazioni sulla sicurezza per i file del dispositivo . . . . . . . . . . . . . . . . . . . . . .
Protezione delle partizioni del disco e dei volumi logici . . . . . . . . . . . . . . . . . . . . . .
Linee guida per eseguire un sistema sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per gestire i programmi setuid e setgid . . . . . . . . . . . . . . . . . . . . . . . .
Possibili motivi di rischio per i programmi setuid e setgid. . . . . . . . . . . . . . . . . .
Modalità di impostazione degli ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per limitare la forza di setuid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per l'inizializzazione del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per backup e ripristino sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per il montaggio e lo smontaggio del file system . . . . . . . . . . . . . . . . .
Linee guida per la gestione delle violazioni della sicurezza . . . . . . . . . . . . . . . . . . .
Ricerca della root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo della sicurezza in una rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo di un dominio amministrativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifica delle impostazioni di permesso nei file di controllo della rete . . . . . . . . . .
Comprensione sulla funzionalità dei servizi di rete . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di inetd.sec per limitare l’accesso esterno . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Negazione dell'accesso con /etc/ftpd/ftpusers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File montati in ambiente NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vulnerabilità del server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vulnerabilità del client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Salvaguardia di file montati su NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accesso a livello collegamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicurezza del sistema sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Impostazione del proprio sistema sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revisione di un sistema sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semplificazione dei dati di log di revisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmi di autorevisione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File di log di revisione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
779
782
782
783
783
784
784
785
785
787
788
788
789
789
790
791
792
793
795
797
798
798
799
800
800
801
801
802
802
803
803
804
805
807
812
813
813
Indice
Visualizzazione dei log di revisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linee guida per gestire il proprio sistema di revisione. . . . . . . . . . . . . . . . . . . . . . .
Considerazioni sulle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso della revisione in un ambiente NFS Diskless . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione delle password e dell’accesso nei sistemi sicuri . . . . . . . . . . . . . . . . . . . . . .
Criteri per creare una buona password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File di password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il file /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il database /tcb/files/auth/. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scelta e creazione della password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Invecchiamento della password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Storico della password e riutilizzo della password . . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo dell’accesso basato sul tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controllo dell’accesso basato sul dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manipolazione dei database di sistema sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dei cluster NFS Diskless per i sistemi sicuri . . . . . . . . . . . . . . . . . . .
Scelta n.1: cluster con database delle password privato. . . . . . . . . . . . . . . . . . . . . .
Conversione di un cluster non sicuro in uno sicuro. . . . . . . . . . . . . . . . . . . . . . . .
Conversione di un sistema standalone sicuro in un cluster sicuro . . . . . . . . . . .
Scelta n.2: cluster con database delle password condiviso . . . . . . . . . . . . . . . . . . . .
Conversione di un cluster non sicuro in uno sicuro. . . . . . . . . . . . . . . . . . . . . . . .
Conversione di un sistema standalone sicuro in un cluster sicuro . . . . . . . . . . .
HP-UX Bastille. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installazione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software aggiuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Considerazioni sulla sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File di configurazione predefiniti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione interattiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applicazione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Riesecuzione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inversione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disinstallazione di Bastille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interazioni con altro software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
814
815
816
816
817
818
819
820
821
822
823
823
824
824
825
826
826
826
827
827
828
829
831
831
831
832
832
832
833
837
839
844
847
847
847
848
849
25
Indice
Esecuzione dei comandi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File di configurazione e di log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altri pacchetti di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sistema di rilevamento delle intrusioni host di HP-UX (HP UX HIDS). . . . . . . . . . .
Password oscurate di HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funzionalità e vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmazione delle API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Altro supporto software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Information Service Plus (NIS+) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di SAM con NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione di NIS+ con il modo sicuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabella sicura NIS+ ed il daemon ttsyncd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pluggable Authentication Modules (PAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uso di SAM con PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione a livello dell’intero sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione a livello utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il file di configurazione pam.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il file di configurazione pam_user.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Come funziona PAM: esempio di login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secure Internet Services (SIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funzionamento con sistemi sicuri e non sicuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Patch Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lavoro con un firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
849
850
852
853
854
854
855
855
855
856
856
857
858
859
860
861
861
862
862
866
867
869
870
870
871
871
871
872
872
9. Amministrazione di un gruppo di lavoro
Gestione dei dischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di un disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di un volume logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di un volume logico con mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estensione di un volume logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
875
876
877
878
879
881
Indice
Estensione di un volume logico quando non è possibile utilizzare SAM . . . . . . .
Riduzione di un volume logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rimozione di un volume logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di una copia speculare ad un volume logico esistente. . . . . . . . . . . . . .
Rimozione di una copia speculare da un volume logico . . . . . . . . . . . . . . . . . . . .
Sostituzione di un disco in mirroring in un volume logico . . . . . . . . . . . . . . . . . .
Spostamento di una directory su un volume logico di un altro sistema. . . . . . . .
Come: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determinazione della versione del sistema operativo HP-UX in esecuzione . . . . .
Esecuzione del backup e ripristino delle directory: Riferimento rapido per tar . . .
Uscita rapida dalla schermata di avvio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifica del livello di esecuzione del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestione di sistemi distribuiti o di cluster Serviceguard . . . . . . . . . . . . . . . . . . . . .
Creazione del diagramma dell’utilizzo del disco di sistema . . . . . . . . . . . . . . . . . . .
Reperimento di file di grandi dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Esame delle caratteristiche del file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spostamento di una directory (all'interno di un file system) . . . . . . . . . . . . . . . . . .
Spostamento di un sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Salto dello stack della directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pianificazione di un lavoro cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Continuazione del lavoro durante un fermo programmato . . . . . . . . . . . . . . . . . . .
Risoluzione dei problemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suggerimenti per l'interpretazione dei messaggi d’errore di HP-UX . . . . . . . . . . .
Abilitazione di servizi Internet governati da inetd. . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di software ad un gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installazione e gestione del software per un Enterprise . . . . . . . . . . . . . . . . . . . . .
Impostazione di un host di rete (costruzione di un depot) . . . . . . . . . . . . . . . . . . . .
Copia di software da un depot con l'interfaccia utente di SD . . . . . . . . . . . . . . . .
Copia di software da CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copia di software da un nastro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ulteriori esempi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ulteriori strumenti di gestione del gruppo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . .
882
884
886
886
887
888
890
894
895
896
897
897
898
898
901
901
902
903
904
904
905
906
907
907
909
909
909
910
910
910
911
912
27
Indice
10. Configurazione ed amministrazione di un cluster NFS diskless HP-UX
Che cosa è un cluster NFS Diskless? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Motivi per creare un cluster NFS diskless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pianificazione delle politiche di cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Politiche per l'ubicazione dei dati utente e di gruppo . . . . . . . . . . . . . . . . . . . . . . .
Politiche per l’ubicazione delle home directory . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Politiche per la posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione dell'hardware del cluster NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Periferiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unità disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispositivi di backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stampanti e plotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Area Network (LAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memorizzazione su disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento delle informazioni sul server e sul client . . . . . . . . . . . . . . . . . . . . . . . .
Ottenimento dell'indirizzo hardware (della stazione) . . . . . . . . . . . . . . . . . . . . . . .
Installazione del software diskless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installazione di un client Serie 700 su un server cluster Serie 800 . . . . . . . . . . . . . .
Configurazione di un agente relè . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione del server cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anteprima di ciò che occorrerà fare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informazioni sulla Guida dei cluster NFS diskless . . . . . . . . . . . . . . . . . . . . . . . . .
Definire le politiche per un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiunta di client ad un cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avvio di nuovi client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cosa fare successivamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiungere un disco locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione del cluster NFS diskless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domande e risposte su NFS diskless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurazione del cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prestazioni. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione a punto singolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Politiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedure comuni a tutto il cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utenti e gruppi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
915
916
917
918
919
919
920
921
921
921
921
922
922
922
924
925
927
929
931
934
934
934
935
935
940
942
943
944
948
948
954
956
956
958
960
960
Indice
A. Uso di strategie ad alta disponibilità
Uso del mirroring del software come strategia di protezione del disco. . . . . . . . . . . . 965
Uso dei disk array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Disk array che usano le strategie di protezione dei dati RAID . . . . . . . . . . . . . . . . . . 967
Mirroring (RAID Livello 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Pro e contro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Usi consigliati e considerazioni sulle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . 967
Striping del disco (RAID Livello 0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Pro e contro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Usi consigliati e considerazioni sulle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . 968
RAID 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Pro e contro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Usi consigliati e considerazioni sulle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . 969
RAID 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Pro e contro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Usi consigliati e considerazioni sulle prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . 970
Cos’è AutoRAID? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Pro e contro di AutoRAID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Usi consigliati di AutoRAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
HP SureStore E Disk Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Uso di dischi di ricambio hot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Uso dei sistemi di memorizzazione ad alta disponibilità (High Available Storage
Systems - HASS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Pro e contro dei sistemi HASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Usi consigliati dei sistemi HASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Uso di Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Pro e contro di Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Funzionalità di Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Automatic Rotating Standby (Standby a rotazione automatica) di Serviceguard 976
Upgrade a rotazione di Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Advanced Tape Services – ATS (Servizi a nastro avanzati) di Serviceguard . . . 977
Altri prodotti e funzionalità ad alta disponibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Monitor ad alta disponibilità (Monitor HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Kit degli strumenti Enterprise Cluster Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
MetroCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
ContinentalClusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
HP ServiceControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
29
Indice
Indice analitico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
30
Prefazione
Nomi ed identificatori delle release di HP-UX
11i
Con HP-UX 11i v1, HP fornisce un sistema operativo ad alta disponibilità,
sicuro e gestibile che soddisfa le esigenze dell’elaborazione end-to-end
critica per Internet. HP-UX 11i supporta gli ambienti Enterprise,
Mission-critical e Technical computing. HP-UX 11i è disponibile sia per
sistemi PA-RISC sia per sistemi su base Intel® Itanium®.
Ogni release HP-UX 11i v1 ha associato un nome ed un identificatore di
release. Il comando uname con l’opzione -r fornisce l’identificatore della
release. La Tabella 1 mostra le release disponibili per HP-UX 11i.
Tabella 1
Release di HP-UX 11i
Identificatore
della release
Nome della release
Architettura del
processore supportata
B.11.11
HP-UX 11i versione 1
PA-RISC
B.11.23
HP-UX 11i versione 2
Su base Itanium
B.11.23
HP-UX 11i versione 2,
settembre 2004
PA-RISC e su base
Itanium
Per informazioni sui sistemi e sulle architetture di processori supportati
nelle varie versioni di HP-UX, far riferimento alle informazioni sulla
release relative alla propria versione di HP-UX (ad esempio, le HP-UX
11.0 Release Notes oppure le Informazioni sulla release di HP-UX 11i
versione 2).
31
Modifiche agli strumenti di gestione del
sistema in HP-UX 11i versione 2
Interfaccia SAM su base X Window
Per HP-UX 11i versione 2, alcune parti dell’interfaccia System
Administration Manager (SAM) su base X Window sono state sostituite
dalle equivalenti interfacce SCM (Servicecontrol Manager) su base web.
Le sezioni di questo documento che mostrano i dettagli dell’interfaccia
SAM non sono ancora state completamente aggiornate per rispecchiare
questa variazione. Tuttavia, per supporto sull’uso dello strumento SCM è
possibile selezionare la guida in linea integrata.
Le seguenti aree funzionali di SAM lanceranno uno strumento su base
web:
•
•
•
configurazione kernel (lancia kcweb)
dispositivi periferici (lancia pdweb)
partition manager (lancia la versione su base web di parmgr)
Gli strumenti precedentemente indicati possono anche essere lanciati in
modo indipendente dalla riga di comando di HP-UX, oltre che da SAM o
SCM.
Per informazioni su kcweb, il nuovo strumento di configurazione kernel,
consultare la relativa guida in linea “Riconfigurazione della kernel
(HP-UX 11i versione 2)” a pagina 319.
Per informazioni su pdweb, il nuovo strumento per i dispositivi periferici,
consultare la relativa guida in linea, oltre al Manuale del supporto delle
schede d'interfaccia OL* (notare che per 11i v2, le informazioni su PCI
OL* sono state spostate dal manuale Configuring HP-UX for Peripherals
alla Manuale del supporto delle schede d'interfaccia OL*).
Notare anche che Partition Manager (parmgr) compare in SAM sia sotto i
sistemi nPartizionabili, sia sotto quelli non-nPartizionabili. Si tratta di un
fatto normale per le installazioni HP-UX.
Per informazioni su Partition Manager, consultare la relativa guida in
linea ed anche Guida alle partizioni di sistema HP.
32
Interfaccia SCM basata sul Web
SCM è uno strumento di gestione di sistema in grado di gestire uno o più
sistemi contemporaneamente. Gli amministratori con sistemi
HP multipli che eseguono HP-UX o Linux traggono maggiori vantaggi
dall’uso di SCM.
Inoltre, SCM usa il protocollo WBEM (Web-Based Enterprise
Management), una sostituzione di SNMP (Simple Network Management
Protocol). Come dice il nome stesso, SNMP non può gestire dati complessi
ed ha problemi di sicurezza specifici; WBEM risolve questi problemi. SCM
offre anche un’interfaccia a riga di comando.
Per informazioni dettagliate su SCM, compreso il protocollo WBEM,
consultare la guida in linea integrata e la HP Servicecontrol Manager
User’s Guide, disponibile alla pagina http://docs.hp.com.
Alcune aree funzionali possono essere lanciate sia da SAM, sia da SCM:
•
•
•
•
•
•
•
•
Accounts for Users and Groups
Auditing and Security
Disks and File Systems
Kernel Configuration (kcweb)
Peripheral Devices (pdweb)
Printers and Plotters
Resource Management (EMS)
Software Management (SD)
Le seguenti aree funzionali possono essere lanciate solo da SAM:
•
•
•
•
•
Networking and Communications
Performance Monitors
Routine Tasks
SAM on remote systems
Time (ntp)
SCR e DMI sostituiti in 11i v2 dal nuovo strumento SIM
Per HP-UX 11i versione 2, Configuration Repository (SCR) e Desktop
Management Interface (DMI) sono stati sostituiti dal nuovo strumento
Systems Inventory Manager (SIM). È possibile scaricare SIM e le relative
informazioni da http://software.hp.com.
33
Distributed Systems Administration Utilities
HP Distributed Systems Administration Utilities – DSAU – migliora la
gestione di sistemi multipli e di cluster Serviceguard. Le utility offrono:
•
Configuration synchronization
•
Log consolidation
•
Command fanout
Queste utility semplificano la gestione di gruppi di sistemi e di cluster
Serviceguard.
Configuration Synchronization offre la gestione della configurazione
basata su criteri per gruppi di sistemi e per cluster Serviceguard.
Con la sincronizzazione delle configurazione, si specifica un server come
proprio master di configurazione; tutti gli altri sistemi sono definiti come
client. Il master di configurazione conserva le copie di tutti i file che si
desidera sincronizzare nei vari client. Ad esempio, le azioni di
sincronizzazione possono comprendere:
•
Aggiornamento di un file locale con una copia dal master di
configurazione
•
Controllo delle autorizzazioni e del possesso dei file
•
Modifica dei file
•
Esecuzione di comandi della shell
•
Disattivazione dell’uso di un file
•
Controllo di alcuni processi
•
Avvio dei processi
•
Mantenimento dei collegamenti simbolici
•
Manutenzione delle directory
Consolidated logging fornisce la registrazione eventi centralizzata e
funzioni avanzate per il filtraggio dei registri. In ambienti Serviceguard,
l’amministratore è in grado di creare un server di consolidazione dei
registri ad alta disponibilità.
Con la consolidazione dei registri eventi, i registri di tutti i sistemi gestiti,
che si trovino in un cluster o no, inviano i loro file di log – di sistema, di
pacchetto o del cluster – in un’unica ubicazione dove possono essere
34
controllati facilmente. Per utilizzare la registrazione eventi consolidata,
tutti i sistemi devono trovarsi in un cluster oppure devono essere connessi
in rete.
Command fanout fornisce degli strumenti ad alte prestazioni per
l’esecuzione dei comandi della shell e per la distribuzione di file attraverso
gruppi di sistemi e cluster Serviceguard.
Con la distribuzione dei comandi, è possibile inviare con un’unica azione
in modo efficace il medesimo comando a tutti i sistemi della propria
configurazione.
35
Reperimento di informazioni su HP-UX
La seguente tabella indica dove trovare le informazioni di base sulla
gestione di sistema per HP-UX. Questa tabella non include informazioni
per prodotti specifici.
Se si desidera … . .
Andare a… . .
scoprire cosa è
cambiato nelle
release HP-UX, nel
contenuto degli
ambienti operativi,
nei requisiti firmware
e nei sistemi
supportati
le informazioni sulla release
del sistema HP-UX
specifiche per la propria
versione di HP-UX; ad
esempio, alle HP-UX 11.0
Release Notes, oppure alle
Informazioni sulla release di
HP-UX 11i versione 2.
•
CD-ROM Instant Information di
HP (in inglese)
•
http://docs.hp.com
•
directory /usr/share/doc/
installare o
aggiornare HP-UX
•
•
•
Leggere prima di
installare o aggiornare
ad HP-UX
Che si trova in… . .
La directory /usr/share/doc contiene
solo le informazioni sulla release originali della propria versione di HP-UX.
Per le informazioni sulla release aggiornate, consultare il CD Instant Information e http://docs.hp.com.
•
Guida di installazione ed
aggiornamento di
•
HP-UX 11i
Kit del supporto (fornito con
l’ambiente operativo)
CD-ROM Instant Information di
HP (in inglese)
http://docs.hp.com
(Nota: fare riferimento ai
manuali specifici per la
propria versione di HP-UX).
gestione di un
sistema HP-UX
•
•
•
36
•
Gestione di sistemi e
gruppi di lavoro: Guida
per gli amministratori di
•
sistema HP-UX
•
Guida alle partizioni di
sistema HP:
Amministrazione delle
nPartition
“Planning Superdome
Configurations” (libro
bianco)
CD-ROM Instant Information di
HP (in inglese)
http://docs.hp.com
“Planning Superdome
Configurations” è disponibile
all’indirizzo
http://docs.hp.com/hpux/
onlinedocs/os/11i/
superdome.pdf
Contenuto di questo documento
Questo documento:
•
Supporta HP-UX 11i ed 11.x, compresa la funzionalità a 64 bit, come
pure HP-UX 10.x.
•
Si occupa dell'amministrazione di gruppi di lavoro interdipendenti,
come pure di sistemi singoli.
Sono qui trattati i seguenti argomenti principali:
•
Capitolo 1, “Sistemi e gruppi di lavoro” a pagina 39
Definizione di termini e categorie.
•
Capitolo 2, “Pianificazione di un gruppo di lavoro” a pagina 49
Scelta tra modelli alternativi per la distribuzione delle applicazioni,
dei dati e di altre risorse di elaborazione.
•
Capitolo 3, “Configurazione di un sistema” a pagina 135
Impostazione di una workstation singola o di un solo server.
•
Capitolo 4, “Configurazione di un gruppo di lavoro” a pagina 391
Connessione di sistemi al gruppo di lavoro e alla rete; distribuzione di
risorse.
•
Capitolo 5, “Amministrazione di un sistema: Avvio e spegnimento” a
pagina 469
Informazioni su avvio e spegnimento di una workstation singola o di
un solo server.
•
Capitolo 6, “Amministrazione di un sistema: Gestione di dischi e file”
a pagina 563
Informazioni su dischi e file per una workstation singola o un solo
unico.
•
Capitolo 7, “Amministrazione di un sistema: Gestione di stampanti,
software e prestazioni” a pagina 713
Informazioni su stampanti e software per una workstation singola o
un solo server.
37
•
Capitolo 8, “Amministrazione di un sistema: Gestione della sicurezza
del sistema” a pagina 753
Informazioni sulla gestione della sicurezza per una workstation
singola o un solo server.
•
Capitolo 9, “Amministrazione di un gruppo di lavoro” a pagina 873
Operazioni di manutenzione che coinvolgono più sistemi;
collegamenti a tutte le procedure utili contenute nel documento.
Consultare:
— “Come:” a pagina 894
— “Risoluzione dei problemi” a pagina 906
•
Capitolo 10, “Configurazione ed amministrazione di un cluster NFS
diskless HP-UX” a pagina 913
Informazioni su NFS Diskless (solo HP-UX 10.20).
•
Appendice A, “Uso di strategie ad alta disponibilità” a pagina 963
Informazioni su alcuni dei vari metodi di implementazione dell'alta
disponibilità.
38
Sistemi e gruppi di lavoro
1
Sistemi e gruppi di lavoro
Questo documento è destinato agli amministratori dei sistemi e dei gruppi
di lavoro HP-UX. Gli argomenti introduttivi a seguire dovrebbero essere
di aiuto nel comprendere i termini e le categorie che si utilizzeranno.
•
“Punto centrale dei gruppi di lavoro” a pagina 40
•
“Modalità di utilizzo dei termini Sistema e Gruppo di lavoro” a
pagina 41
— “Sistema” a pagina 41
— “Gruppi di lavoro” a pagina 41
Capitolo 1
•
“Tipi di sistema” a pagina 42
•
“Tipi di gruppi di lavoro” a pagina 47
39
Sistemi e gruppi di lavoro
Punto centrale dei gruppi di lavoro
Punto centrale dei gruppi di lavoro
La maggior parte dei manuali di amministrazione dei sistemi, incluso il
manuale HP-UX System Administration Tasks delle release precedenti,
incentrano il loro interesse sulle procedure dei sistemi individuali,
dicendo come configurare e realizzare la manutenzione dei singoli sistemi.
Si tratta di informazioni essenziali, ma non sono sufficienti. Oggigiorno,
la maggior parte dei sistemi non si usa isolatamente, piuttosto, le risorse
di elaborazione a computer sono condivise tra vari sistemi: applicazioni,
file, database, servizi tipo il World Wide Web e la posta e periferiche come
le stampanti sono di solito disponibili agli utenti di più di un sistema ed in
alcuni casi sono condivisi tra centinaia o migliaia di sistemi.
La pratica di condividere risorse è così comune che il vecchio modo di
pensare ad un sistema come ad una “scatola” individuale spesso non è più
utile; il “sistema” che un amministratore di sistema deve gestire di solito
contiene almeno un server che distribuisce le risorse su una LAN o
almeno cinque o sei client, alcuni dei quali a turno possono condividere
reciprocamente le risorse. In questo documento, si farà riferimento a tali
sistemi interdipendenti come a gruppi di lavoro, riservando il termine
sistema per riferirsi ad una “scatola” singola.
Quando si condividono così tante risorse importanti, le procedure di
routine come portare in linea un nuovo sistema, realizzare i backup,
aggiornare il software, aggiungere utenti e chiudere i sistemi, sono un po’
più complesse di quanto non sarebbero se il sistema esistesse
isolatamente.
Ad esempio, chiudere un sistema standalone è una procedura
relativamente semplice, ma chiudere un file server senza interrompere il
lavoro degli utenti che da esso dipendono richiede una certa pianificazione
e potrebbe richiedere del lavoro, come copiare i file system condivisi su un
server alternativo e copiarli nuovamente indietro prima di riportare il
server originale in linea.
Inoltre, la nuova funzionalità del sistema operativo HP-UX denominata
OLA/R consente l’aggiunta e la sostituzione in linea di schede I/O PCI, che
consente all’amministratore di aggiungere una nuova scheda e/o
sostituirne una esistente senza coinvolgere altri componenti di quel
sistema, altri sistemi collegati a quella workstation o richiedere un
riavvio.
40
Capitolo 1
Sistemi e gruppi di lavoro
Modalità di utilizzo dei termini Sistema e Gruppo di lavoro
I concetti e le procedure di OLA/R sono presentati nei dettagli nel
manuale Configuring HP-UX for Peripherals.
Questo documento fornisce le linee guida semplici ed affidabili e le
istruzioni per la gestione di procedure di tutti i giorni, ed al contempo si
occupa dei fondamentali dell’amministrazione dei sistemi individuali.
Modalità di utilizzo dei termini Sistema e
Gruppo di lavoro
Sistema
In questo documento, si usa il termine sistema per riferirsi ad un sistema
HP-UX individuale, una “scatola” singola. Un sistema così definito ha
sempre la sua CPU (ad esempio, spesso non ci si riferisce agli XTerminal
come sistemi) ma potrebbe o non potrebbe avere il proprio file system di
root.
Per ulteriori informazioni, consultare “Tipi di sistema” a pagina 42.
Gruppi di lavoro
Un gruppo di lavoro è un gruppo di sistemi che dipendono da uno o più
server comuni, o uno dall’altro, per servizi importanti come i file system
con montaggio NFS ed i cui utenti, nella maggior parte dei casi, lavorano
su progetti comuni, o sono nello stesso team o dipartimento.
Un gruppo di lavoro potrebbe anche essere composto da un sistema
multiutente individuale al quale gli utenti si collegano da terminali o
emulatori di terminali, sebbene tali sistemi non siano al centro
dell’interesse primario del presente documento.
In questa prima versione del documento, gruppi di lavoro significa un
raggruppamento di sistemi prevalentemente HP-UX, ma si troveranno
alcune informazioni sull’integrazione dei sistemi Windows NT in un
gruppo di lavoro simile.
Per ulteriori informazioni, consultare “Tipi di gruppi di lavoro” a
pagina 47.
Capitolo 1
41
Sistemi e gruppi di lavoro
Tipi di sistema
Tipi di sistema
Utente unico o multiutente
Ai fini del presente documento, si opererà una distinzione tra due modi di
utilizzo di un dato sistema da parte delle persone:
•
come workstation di utente unico, di solito sulla scrivania di
qualcuno ed usata principalmente o esclusivamente da tale persona;
•
come sistema multiutente, spesso tenuto in una stanza di computer,
con cui i singoli utenti comunicano mediante un terminale, o un
emulatore di terminale su un sistema desktop collegato attraverso
una LAN o un modem.
La potenza dei sistemi standalone di gestire sempre più utenti (così
come molte altre funzioni di rete) è aumentata in modo notevole.
Per tale motivo, se si pianifica di configurare una macchina standalone
come sistema multiutente, consultare le informazioni che riguardano
l’aggiunta e la sostituzione in linea nel manuale Configuring HP-UX
for Peripherals. Questo materiale può essere di aiuto nel pianificare la
configurazione del sistema in modo che in caso di guasto hardware, sia
possibile sostituire l’hardware con il minimo impatto sugli utenti.
Server o client
In linea di massima, un server fornisce un certo genere di risorsa di
elaborazione (applicazioni, file, cicli di computo, stampa ed esecuzione
dello spooling...) ed un client usa tale risorsa.
In questo documento, si useranno i termini server e client più
comunemente, sebbene non in modo esclusivo, nel contesto dei servizi
NFS (Networked File System) e si chiarirà tale contesto ogniqualvolta sia
necessario usando i termini server NFS e client NFS.
Sotto NFS ed nella maggior parte degli altri contesti, lo stesso sistema può
funzionare sia da server sia da client. Ad esempio, un sistema potrebbe
importare un file system (realizzando il montaggio NFS da dischi di un
altro sistema) mentre ne esporta un altro (consentendo ad altri sistemi di
montare il file system dai propri dischi). Come importatore di uno o più file
system, il sistema agisce da client NFS, mentre come esportatore agisce da
server NFS.
42
Capitolo 1
Sistemi e gruppi di lavoro
Tipi di sistema
Sistemi partizionati (il partizionamento in continuo)
HP-UX 11i fornisce molti modi per isolare o combinare le risorse del
sistema (ad esempio, le CPU, la memoria e le schede I/O). HP fa
riferimento alla raccolta di soluzioni di amministrazione del sistema che
fornisce tali funzionalità come al Partizionamento in continuo.
Oltre al modo di funzionamento tradizionale di un sistema operativo
HP-UX per computer, casi multipli di HP-UX possono eseguire su un unico
computer (usando il partizionamento) e computer multipli possono essere
combinati per ospitare un caso singolo di HP-UX (usando il clustering).
A seconda delle versioni di HP-UX che si stanno usando e dell’hardware
che si sta eseguendo su di esse, è possibile usare una qualsiasi delle
seguenti tecnologie (o combinazioni di esse) per aumentare al massimo
l’efficienza e la flessibilità dell’apparecchiatura su base HP-UX:
NOTA
iCOD
Instant Capacity on Demand consente di avere nel
proprio sistema dei processori (CPU) non ancora
acquistati. Tali processori restano a riposo fino a che
non li si attivi usando gli speciali comandi iCOD.
Per ulteriori informazioni su iCOD, consultare la
sezione “On Demand Solutions (ODS)” di
http://docs.hp.com/hpux/netsys.
nPartizioni
Alcuni sistemi server PA-RISC ed Enterprise su base
Itanium (ad esempio, i Superdome) hanno le connessioni
dei processori, della memoria e dell’interfaccia I/O
montate su schede di cella. Di solito, questi sistemi
contengono schede di cella multiple.
Schede I/O collegate nello chassis I/O. Gli chassis sono
collegati (associati) alle schede di cella mediante cavi o
altre connessioni interne.
Le schede di cella possono essere raggruppate in modi
specifici in modo tale che le risorse di ciascun gruppo
siano elettricamente isolate da quelle di altri gruppi del
sistema. Tali gruppi, denominati partizioni (a volte
vengono definiti partizioni hard, o partizioni fisiche),
separano le risorse del computer in unità a
contenimento autonomo, protette l’una dall’altra in
modo tale che i crash hardware o software in una
partizione non siano in grado di avere effetti sui
funzionamenti delle partizioni vicine. Ogni partizione è
Capitolo 1
43
Sistemi e gruppi di lavoro
Tipi di sistema
in grado di supportare il proprio sistema operativo1.
Il termine nPartizioni deriva dall’algebra, dove la “n”
indica un numero variabile, il che segnala che è
possibile raggruppare (e raggruppare nuovamente) le
schede di cella del sistema in modi diversi per creare
numeri e dimensioni variabili di partizioni (nel modo
più confacente alle proprie necessità).
L’unità più piccola della costruzione di una nPartizione
è una scheda di cella (cioè, non è possibile usare il
partizionamento hardware per suddividere le risorse di
una scheda di cella, assegnandole a più di una
partizione). Per fare ciò, usare le Partizioni virtuali
(consultare vPars di seguito).
nPartizioni può essere configurato e gestito usando lo
strumento ParMgr (consultare parmgr (1M), o mediante
vari strumenti della riga di comando. Le seguenti
manpage descrivono i comandi di nPartizioni (da usare
dalla riga di comando):
Tabella 1-1
Manpage di nPartizioni:
parstatus (1)
partition (1)
parcreate (1M)
parmgr (1M)
parmodify (1M)
parremove (1M)
parunlock (1M)
Informazioni esaustive sull’uso e la configurazione di
nPartizioni sono reperibili nella Guida alle partizioni di
sistema HP.
PPU
Strettamente correlato ad ICOD, la tecnologia Pay-PerUse consente di pagare per l’apparecchiatura su base
HP-UX che si sta usando attualmente piuttosto che
acquistare direttamente l’hardware. È possibile reperire
informazioni dettagliate su ICOD e PPU in Instant
Capacity on Demand (iCOD) User’s Guide for Version
B.05.00 (consultare la sezione “On Demand Solutions
(ODS)” di http://docs.hp.com/hpux/netsys).
1. Casi multipli di HP-UX possono perfino essere eseguiti in una
nPartizione usando partizioni virtuali in modo da suddividere
ulteriormente le risorse della nPartizione.
44
Capitolo 1
Sistemi e gruppi di lavoro
Tipi di sistema
PRM
Process Resource Manager è uno strumento di gestione
delle risorse usato per controllare la quantità di risorse
che i processi usano durante il carico di picco del
sistema (al 100% di utilizzo della CPU, al 100% della
memoria o al 100% dell’ampiezza di banda del disco).
PRM può garantire un’allocazione minima delle risorse
del sistema disponibili per un gruppo di processi
attraverso l’uso di gruppi PRM. È possibile reperire
informazioni dettagliate su PRM in HP Process
Resource Manager User’s Guide e HP-UX Workload
Manager User’s Guide
PSETS
Processor Sets consente di partizionare un sistema
multiprocessore in due o più gruppi di processori (CPU)
all’interno di un dato caso di HP-UX, in modo tale che
sia possibile isolare le risorse della CPU per le
applicazioni o gli utenti selezionati da quelli di altre
applicazioni o utenti.
vPars
Nel caso in cui si disponga di un sistema
multiprocessore (che supporti o meno
l’nPartizionamento), o se si desidera suddividere
ulteriormente le risorse di una nPartizione di una
macchina che supporta l’nPartizionamento (Vedere
“Sistemi partizionati (il partizionamento in continuo)” a
pagina 43), è possibile usare le partizioni virtuali.
Le partizioni virtuali forniscono più flessibilità delle
nPartizioni e le stesse protezioni contro i crash
software/del sistema operativo di quelle fornite dalle
nPartizioni; tuttavia, un crash dovuto ad un guasto
hardware renderà inattivi tutti i sistemi operativi in
tutte le partizioni virtuali all’interno della macchina o le
nPartizioni in cui si è verificato il guasto.
vPARS può essere configurato e gestito dal Virtual
Partition Manager, o usando la riga di comando.
Informazioni esaustive sull’installazione e la
configurazione di vPARS sono reperibili in Installing
and Managing HP-UX Virtual Partitions (vPars).
Le seguenti manpage descrivono i comandi di vPARS
(da usare dalla riga di comando):
Capitolo 1
45
Sistemi e gruppi di lavoro
Tipi di sistema
Tabella 1-2
Manpage di vPars:
vparboot (1M)
vparcreate (1M)
vparmodify (1M)
vparremove (1M)
vparreset (1M)
vparstatus (1M)
vparutil (1M)
vparresources (5)
vpartition (5)
Non tutte le macchine su base HP-UX supportano le
partizioni virtuali. Per informazioni dettagliate su quali
macchine e release di HP-UX supportino vPars,
consultare Installing and Managing HP-UX Virtual
Partitions (vPars).
WLM
WLM espande le funzionalità di PRM fornendo un modo
più dinamico di allocare le risorse. WLM configura
automaticamente PRM in base ai criteri definiti
dall’utente (noto come Service Level Objectives -- SLO)
e monitorando con regolarità la disponibilità delle
risorse. Specificando il livello di servizio che ci si aspetta
dal proprio computer e dalle applicazioni, si offre a
WLM i suoi obiettivi. WLM lavora con PRM e con gli
scheduler di HP-UX di ottenere e conservare questi
obiettivi di livello di servizio. È possibile reperire
informazioni dettagliate su WLM in HP-UX Workload
Manager User’s Guide
Hardware
I sistemi dei quali si parla in questo documento sono principalmente:
•
Server HP 9000 Enterprise
•
Workstation HP 9000
•
Personal Computer (PC)
Sistemi operativi
Questo documento è destinato agli amministratori dei sistemi HP-UX ed
i gruppi di lavoro descritti sono prevalentemente costituiti da tali sistemi,
con qualche PC che esegue i sistemi operativi Microsoft Windows o Linux.
46
Capitolo 1
Sistemi e gruppi di lavoro
Tipi di gruppi di lavoro
Tipi di gruppi di lavoro
Ai fini del presente documento, un gruppo di lavoro è un gruppo di sistemi
prevalentemente HP-UX interdipendenti, ma potrebbe anche includere
dei sistemi Windows NT.
I sistemi HP-UX potrebbero o meno avere i propri file system di root.
Consultare “NFS Diskless” a pagina 47, “Multiutente” a pagina 48 e
“Client-Server” a pagina 48.
NFS Diskless
Si riferisce a gruppi di lavoro, parti di gruppi di lavoro, che ottengono la
root del proprio file system HP-UX da un server remoto.
NOTA
NFS Diskless è supportato su HP-UX 10.20. Non è supportato su
HP-UX 10.30 o successivi.
Anche se non ignora tali disposizioni, questa release di Gestione di sistemi
e gruppi di lavoro: Guida per gli amministratori di sistema HP-UX presta
maggiore attenzione ai sistemi in grado di avviarsi dai propri dischi locali
(consultare “Client-Server” a pagina 48).
Per ulteriori informazioni, consultare:
Capitolo 1
•
“Modello NFS Diskless” a pagina 52
•
“Configurazione ed amministrazione di un cluster NFS diskless
HP-UX” a pagina 913
47
Sistemi e gruppi di lavoro
Tipi di gruppi di lavoro
Multiutente
Grande sistema (ad es., HP-UX Classe V) al quale gli utenti si collegano
attraverso terminali o emulatori di terminale. Oggigiorno, tali sistemi
spesso fanno parte di un gruppo di lavoro “Client-Server” a pagina 48 in
cui almeno alcuni utenti dispongono dei propri computer desktop.
Per ulteriori informazioni, consultare:
•
“Modello multiutente” a pagina 50
•
“Configurazione di un sistema” a pagina 135
•
“Amministrazione di un sistema: Gestione di dischi e file” a
pagina 563
•
“Amministrazione di un sistema: Gestione di stampanti, software e
prestazioni” a pagina 713
Client-Server
Per ulteriori informazioni, consultare:
48
•
“Modello client-server” a pagina 53
•
“Configurazione di un gruppo di lavoro” a pagina 391
•
“Amministrazione di un gruppo di lavoro” a pagina 873
Capitolo 1
Pianificazione di un gruppo di lavoro
2
Pianificazione di un gruppo di
lavoro
Gli argomenti a seguire hanno lo scopo primario di aiutare chiunque si
appresti a configurare un gruppo di lavoro da zero, ma è anche possibile
trovarli utili in caso di configurazione od espansione del gruppo di lavoro.
Nel caso in cui occorra sapere cosa si intenda per gruppo di lavoro,
consultare “Modalità di utilizzo dei termini Sistema e Gruppo di lavoro” a
pagina 41.
Per ulteriori informazioni, consultare i seguenti argomenti:
Capitolo 2
•
“Scelta di un modello di condivisione dei file” a pagina 50
•
“Distribuzione delle applicazioni e dei dati” a pagina 56
•
“Un gruppo di lavoro/rete campione” a pagina 62
•
“Impostazione della strategia di gestione dei dischi” a pagina 71
•
“Pianificazione della gestione dei file system” a pagina 78
•
“Gestione degli utenti su sistemi multipli” a pagina 99
•
“Pianificazione della configurazione della stampante” a pagina 102
•
“Distribuzione dei backup” a pagina 122
•
“Servizi per scambio dati con Personal Computer” a pagina 124
•
“Possibili problemi nello scambio di dati tra HP-UX e PC” a
pagina 130
49
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
Scelta di un modello di condivisione dei file
Se ci si appresta a configurare un nuovo gruppo di lavoro, o ad effettuare
notevoli modifiche ad uno esistente, occorre prima decidere le modalità di
distribuzione delle risorse di elaborazione tra gli utenti. Le decisioni più
importanti fra queste ultime riguardano le modalità di condivisione dei
file e delle applicazioni da parte degli utenti. Essi:
•
Si collegheranno al/i sistemi sui quali risiedono i file e le applicazioni?
(“Modello multiutente” a pagina 50)
•
Avvieranno da un sistema remoto e memorizzeranno i dati condivisi
da remoto? (“Modello NFS Diskless” a pagina 52)
•
Avvieranno dal proprio disco locale, ma memorizzeranno i file e le
applicazioni condivisi da remoto? (“Modello client-server” a
pagina 53)
Probabilmente, la risposta è una combinazione di quanto espresso sopra e
magari potrebbe anche essere tutto quanto sopra citato. Le sezioni a
seguire hanno lo scopo di aiutare l’utente ad esplorare ogni modello e
sceglierne uno prevalente.
Modello multiutente
Un sistema multiutente è un sistema al quale si collega un certo numero
di utenti per eseguire il proprio lavoro, usando un terminale direttamente
collegato al sistema, o un emulatore di terminale su un sistema remoto
collegato da un modem o una LAN.
Vantaggi
•
“Vantaggi” a pagina 50
•
“Svantaggi” a pagina 51
•
“Riepilogo” a pagina 51
•
Potrebbe essere il miglior uso delle risorse di elaborazione di un
sistema di grandi dimensioni.
Consultare “Distribuzione delle applicazioni” a pagina 58
•
Modello più semplice:
— Soltanto un sistema da configurare, su cui eseguire il backup e la
manutenzione.
50
Capitolo 2
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
— Nessun problema di coesistenza del sistema operativo.
— Tabella hardware/OS/applicazioni più semplice possibile.
•
Potrebbe ridurre il traffico LAN.
•
Sicurezza:
— Facile da proteggere dal punto di vista fisico (ad es., in una stanza
da computer chiusa a chiave).
— Consente di tenere i dati sensibili (o tutti i dati) fuori dal desktop.
Svantaggi
•
Occorre un sistema di grandi dimensioni, possibilmente con
processori multipli:
— Requisiti di alimentazione e clima particolari.
•
Fragile:
— Se il sistema subisce un crash, o è inattivo per motivi di
manutenzione, non lavora nessuno.
— Il guasto di un componente qualsiasi probabilmente avrà i suoi
effetti su tutti.
•
Non flessibile:
— Non è in grado di ridistribuire facilmente il carico in risposta
all’uso ed alle prestazioni mutati (o calcolati male).
Riepilogo
Questo modello potrebbe essere quello giusto se si dispone (o si è in grado
di poter acquistare) di un sistema ad alta potenza ed i propri utenti usano
tutti le stesse applicazioni per manipolare i dati che è possibile
memorizzare a livello centrale, non parcellizzati su dischi locali. Se è
questo il caso in questione, i propri utenti non dovranno dimenticare i
vantaggi della creazione di finestre: gli Xterminal forniscono le stesse
capacità di visualizzazione dei monitor delle workstation.
Anche nel caso in cui questo modello non fosse quello adatto nella sua
forma pura, si potrebbe volerlo usare in combinazione con un approccio
più distribuito; ad esempio, si potrebbe desiderare che almeno alcuni dei
propri utenti dispongano delle proprie workstation sulle loro scrivanie,
ma tuttavia consentire loro (o richiedere loro) di collegarsi ad un “server
delle applicazioni” ad alta potenza per eseguire le applicazioni cui occorra
la memoria, i MIPS, lo spazio su disco o altre risorse di un grande sistema;
oppure si potrebbero sfruttare le applicazioni tra due o tre workstation ad
alte prestazioni e far collegare gli utenti a queste ultime per eseguirle.
Capitolo 2
51
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
Modello NFS Diskless
Il termine NFS Diskless descrive i sistemi che usano funzionalità
speciali di NFS per condividere il file system di root. (Diskless significa
che i client non richiedono un disco; in pratica, molte workstation “senza
disco” hanno almeno un disco). In questo documento, si usa il termine per
fare riferimento nello specifico all’implementazione HP di NFS Diskless.
ATTENZIONE
Vantaggi
NFS diskless rappresenta una buona scelta per i gruppi di lavoro, o parti
di gruppi di lavoro, che eseguono da 10.0 a 10.20, ma non è supportato
sulle release successive.
•
“Vantaggi” a pagina 52
•
“Svantaggi” a pagina 52
•
“Riepilogo” a pagina 53
•
Consultare anche: Capitolo 10, “Configurazione ed amministrazione
di un cluster NFS diskless HP-UX” a pagina 913
•
Condivisione delle risorse semplice ed efficace:
— Periferiche
— Spazio su disco
•
•
Amministrazione a punto singolo (attraverso SAM).
Sicurezza fisica:
— Facile per mantenere periferiche di valore e dischi contenenti dati
sensibili, in un luogo centrale e metterli sotto chiave.
Svantaggi
•
Non supportato dopo HP-UX 10.20.
•
Fragile:
— Se il server subisce un crash, o è inattivo per motivi di
manutenzione, non lavora nessuno.
•
Dipende in modo notevole dalle prestazioni della LAN e della
sottorete.
— Per ottenere le prestazioni ottimali, si consiglia lo scambio sul
disco locale.
52
Capitolo 2
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
Riepilogo
Se si sarà i responsabili unici o principali dell’amministrazione del gruppo
di lavoro e non occorre eseguire HP-UX 11.0, si dovrebbe prendere in
considerazione NFS Diskless.
Questo modello è diventato meno diffuso con il declino del prezzo dello
spazio su disco, ma rappresenta ancora il modo più semplice per
amministrare un gruppo di workstation. SAM, il System
Administration Manager guidato da menu, è stato fatto su misura a
partire da HP-UX 10.01 in modo da facilitare l’amministrazione di un
cluster NFS Diskless da un’unica console. Per ulteriori informazioni,
consultare il Capitolo 10, “Configurazione ed amministrazione di un
cluster NFS diskless HP-UX” a pagina 913.
Modello client-server
Client-server è un termine inclusivo usato per riferirsi ai gruppi di
lavoro che condividono risorse diverse da quelle del file system di root;
cioè, le workstation eseguono HP-UX dai propri dischi locali, ma
dipendono dal server NFS per i file e le applicazioni non di “sistema” e
possono anche avere disposizioni comuni per la stampa, i backup e
l’accesso utente.
Vantaggi
•
“Vantaggi” a pagina 53
•
“Svantaggi” a pagina 54
•
“Riepilogo” a pagina 54
•
Flessibilità:
— Può ridistribuire facilmente le risorse in risposta alle necessità ed
alle condizioni mutevoli ed ai risultati del metodo per
approssimazioni successive.
•
Robustezza:
— Un eventuale guasto di un sistema o di un componente non
comporterà necessariamente degli effetti su tutti gli altri.
— I dati e le altre risorse possono spesso essere commutati
rapidamente da un sistema guasto ad uno funzionante,
minimizzando il tempo di fermo.
Capitolo 2
53
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
•
Prestazioni:
— Assegnando ruoli come file server, server delle applicazioni e
client, si dovrebbe essere in grado di sfruttare le proprie risorse
hardware e software per ottenere le migliori prestazioni possibili.
•
Responsabilità condivisa:
— A seconda dei propri utenti, si potrebbe essere in grado di girare
loro la maggior parte del lavoro di amministrazione delle loro
workstation, riducendo il proprio carico di lavoro a lungo termine.
Svantaggi
•
Complessità:
— La tabelle delle versioni del sistema operativo, le versioni delle
applicazioni e le periferiche potrebbero essere pesanti.
— Più i dati sono distribuiti ampiamente, più sarà difficile eseguire
il backup.
— I montaggi NFS possono creare dipendenze incrociate complesse
tra i sistemi, e può diventare difficile tener traccia di questi
ultimi, che potrebbero presentare dei problemi durante l’avvio e lo
spegnimento.
•
Prestazioni:
— Dipende in modo notevole dalle prestazioni della LAN e della
sottorete:
— L’esecuzione delle applicazioni a livello locale potrebbe alleggerire
i colli di bottiglia della LAN, ma a scapito della potenza di
elaborazione di un server di grandi dimensioni.
•
Disorganizzazione:
— Se gli utenti sono anche solo parzialmente liberi di amministrare
i propri sistemi, la complessità ed i problemi imprevisti
potrebbero aumentare oltre la propria capacità di gestirli.
Riepilogo
54
Grazie alla sua flessibilità, e forse anche perché sembra a molte persone
un modo naturale per sistemare le cose, questo modello sta diventando
sempre più diffuso e questo documento gli dedica molto spazio.
Capitolo 2
Pianificazione di un gruppo di lavoro
Scelta di un modello di condivisione dei file
In teoria, questo modello consente di avere il migliore dei mondi possibili;
chiunque nel gruppo di lavoro può usare la miglior combinazione delle
risorse del gruppo (potenza di elaborazione, memorizzazione di massa,
capacità di visualizzazione) senza dover essere a tal punto dipendenti da
dover smettere di lavorare tutti in caso di guasto di un server.
In pratica, esistono compensazioni difficili. Se si desidera che ognuno invii
e riceva la propria posta a livello locale, ad esempio (invece che dipendere
da un hub della posta), occorrerà configurare e conservare i file alias di
posta su ogni workstation, un lavoro notevole in un’organizzazione di
grandi dimensioni. Se si desidera ridurre il traffico LAN facendo in modo
che le persone eseguano le loro applicazioni e memorizzino i dati a livello
locale, non solo occorrerà organizzare il backup di quei dati, ma si
potrebbero anche acquistare dischi e memoria per ottenere prestazioni
locali accettabili.
D’altro canto, consolidando le risorse sui server si dovrebbero risparmiare
tempo e denaro, ma si tornerà anche indietro ad una dipendenza del tipo
mainframe su pochi sistemi, con una dipendenza aggiuntiva sulle
prestazioni e l’affidabilità della LAN.
Se si adotta questo modello, occorre prevedere di dedicare del tempo (e, se
possibile, un po’ del proprio budget) per l’esecuzione del metodo per
approssimazioni fornisce offre alcune linee guida e consigli.
Capitolo 2
55
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
Distribuzione delle applicazioni e dei dati
Gli argomenti che seguono hanno lo scopo di aiutare a pianificare la
configurazione complessiva del gruppo di lavoro, in termini di quali parti
del flusso di lavoro risiedono ed eseguono su quali sistemi. Questa sezione
avrà più senso se si è già letto “Scelta di un modello di condivisione dei
file” a pagina 50; si noterà che la discussione tende verso il “Modello
client-server” a pagina 53.
Per ulteriori informazioni, consultare uno dei seguenti argomenti:
•
“Modello di condivisione dei file HP-UX (V.4)” a pagina 56
•
“Cosa distribuire, cosa tenere a livello locale” a pagina 57
•
“Server a scopi specifici” a pagina 59
Modello di condivisione dei file HP-UX (V.4)
HP-UX ha introdotto un nuovo layout di file system con 10.0. Il nuovo
layout si basa sui file system AT&T SVR4 ed OSF/1 ed ha lo scopo di
fornire vantaggi quali:
•
la separazione del software del sistema operativo dal software
applicativo
•
una base per i modelli di condivisione dei file come “Modello NFS
Diskless” a pagina 52 e “Modello client-server” a pagina 53
•
coerenza con altri rivenditori UNIX
Per ulteriori informazioni, consultare la HP-UX 10.0 File System Layout
White Paper alla pagina http://docs.hp.com.
Questo come aiuta a condividere i file?
Il nuovo layout è più lineare e più logico del 9.x, è essenziale per NFS
Diskless (consultare “Modello NFS Diskless” a pagina 52) e dovrebbe
rendere più semplice l’interoperatività con altri rivenditori di sistemi
UNIX.
Non modifica la meccanica della configurazione dei montaggi NFS, ma
facilita la loro gestione sotto un aspetto importante: la segregazione di
applicazioni non di “sistema” sotto /opt e le modifiche che applicazioni
come Netscape hanno fatto rispettare, significano che il server ora può
56
Capitolo 2
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
esportare una data applicazione da un’unica sottodirectory sotto /opt,
invece che dover esportare varie sottodirectory per ogni applicazione, o
perfino l’intera /usr/local.
Cosa distribuire, cosa tenere a livello locale
Teoria
Il paradigma di condivisione dei file V.4 divide le directory di HP-UX in
due categorie: private e condivise (a volte denominate anche
dinamiche e statiche).
Le directory contenenti le informazioni sulla configurazione di un sistema
si designano come private e non devono essere condivise attraverso NFS.
Esse sono:
•
•
•
•
•
/ (root)
/etc
/dev
/var
/stand
Il modello definisce anche /home (per le home directory degli utenti), /tmp
e /mnt (per i montaggi locali) come private, sebbene in pratica esista un
argomento per la condivisione di /home e /var/mail (consultare “Occorre
condividere la home directory e la directory della posta degli utenti?” a
pagina 101). Inoltre, /opt stesso non deve essere condiviso, sebbene le sue
sottodirectory siano le prime candidate per la condivisione.
Le directory definite come condivisibili sono:
•
•
•
/usr
/sbin
sottodirectory di /opt
Pratica
In pratica, tranne che sotto NFS diskless (consultare “Modello NFS
Diskless” a pagina 52) non è una buona idea condividere /sbin o directory
sotto /usr diverse da /usr/local perchè crea troppa dipendenza (il
client NFS non può funzionare a meno che il server NFS sia attivo) e
perchè ciò provocherà dei problemi quando si tenterà di aggiornare i
sistemi ad una nuova release di HP-UX. HP consiglia di implementare
queste configurazioni così strettamente accoppiate soltanto sotto NFS
Diskless (attualmente limitato ai sistemi 10.x).
Capitolo 2
57
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
Le directory da prendere in considerazione per la condivisione sono:
•
directory di applicazione sotto /opt
•
directory che conservano dati sui quali funzionano le applicazioni
condivise
•
directory che conservano progetti ai quali collabora un certo numero
di utenti
•
directory che conservano dati importanti e volatili dei quali occorre
eseguire il backup nottetempo
Ad esempio, gli autori del presente documento conservano il testo
sorgente su un file server, un sistema Serie 800 che esegue HP-UX 10.20,
del quale si esegue il backup nottetempo. I nostri strumenti per gli autori
e web browser risiedono su un server delle applicazioni, un server
Classe K che esegue 10.20, su cui si realizza la manutenzione di tutto il
software. Non si esegue il backup dei nostri dischi locali, i quali non
contengono applicazioni e strumenti che richiedano supporto esterno.
Distribuzione delle applicazioni
I criteri principali sono qui le prestazioni e la facilità di gestione.
Le possibilità pratiche sono:
•
memorizzarle su un server e distribuirle alle workstation attraverso
NFS
•
memorizzarle su un server al quale si collegano gli utenti per
eseguirle
L’unica configurazione che probabilmente occorre non prendere in
considerazione fin dall’inizio è di installare ciascuna applicazione
singolarmente sui dischi locali di ogni workstation; ciò potrebbe avere
senso per il singolo utente occasionale con necessità particolari, ma le
considerazioni di gestione del software lo rendono pressoché impensabile
come approccio generale.
Dato per assodato che si memorizzeranno le applicazioni su uno o più
server, è meglio eseguirle sulle workstation (attraverso NFS) o sul server?
Vi sono delle opinioni discordi ed in pratica si potrebbero benissimo
combinare i due approcci. Ma occorre tener presente che le applicazioni
moderne sono ad intensità di scambio e di memoria e spesso è meglio
concentrare queste risorse su un server piuttosto che parcellizzarle su
singole workstation.
58
Capitolo 2
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
Per la massima facilità di gestione (backup e manutenzione del software)
occorre:
•
conservare i dati in un luogo centrale in cui sia facilmente eseguibile
il backup
•
conservare soltanto una versione ed una copia di ogni applicazione
•
se possibile, concentrare le applicazioni su un unico server potente
Mirare alla configurazione più semplice in linea con prestazioni
accettabili.
Server a scopi specifici
La parte utile di qualsiasi sistema di computer è composta da applicazioni
e dai dati che esse manipolano. Il proprio compito è di decidere le modalità
di sfruttamento delle applicazioni e dei dati del gruppo di lavoro in modo
che possano essere tranquillamente accessibili, disponibili e sicuri.
Questa sezione sottintende che:
•
si abbia intenzione di collocare le workstation (invece che i soli
terminali display) sulle scrivanie di almeno qualche utente.
•
gli utenti del gruppo di lavoro condivideranno almeno alcune delle
stesse applicazioni.
Occorre pianificare di tenere le applicazioni condivise in una ubicazione
centrale dove le si installa, configura, si esegue il backup e la manutenzione. Allo stesso modo, occorre pianificare di conservare tutti i dati condivisi dagli utenti, e quanti più dati volatili possibili (cioè, dati che cambiano di frequente, a prescindere o meno dalla loro condivisione da parte
di più di un utente) in una ubicazione centrale dove sia possibile eseguire
il backup facilmente, e da cui siano distribuiti alle workstation attraverso
NFS. Un sistema i cui dischi contengano dati condivisi di solito si chiama
file server (anche se i dati effettivamente risiedono in database piuttosto
che in file ordinari). Un sistema sul quale le applicazioni condivise vengono conservate potrebbe chiamarsi server delle applicazioni o compute server; noi utilizzeremo server delle applicazioni.
In molti gruppi di lavoro, il file server ed il server delle applicazioni sono
la stessa macchina, che è semplicemente un magazzino per tutto ciò che è
condiviso e tutto ciò che richieda un backup regolare. Ciò potrebbe essere
comodo e può rappresentare la miglior cosa da fare con l’hardware
disponibile, ma non è l’ideale perché le funzioni di un file server sono
Capitolo 2
59
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
diverse da quelle di un server delle applicazioni e possono interferire con
loro. Ad esempio, una CPU che è occupata a gestire le richieste NFS avrà
meno cicli per eseguire le applicazioni.
File Server
Di solito, gli utenti non si collegano ad un file server; ottengono i dati che
a loro servono da esso mediante montaggio NFS.
I requisiti principali per un file server sono:
•
molto spazio su disco
Lo striping del disco, che consente all’I/O di moltiplicare gli spindle in
modo simultaneo, potrebbe migliorare la velocità effettiva.
•
molta RAM
•
interfacce I/O veloci come Fast-Wide SCSI.
•
vicinanza alle workstation servite
Gli hub intermedi, i router, gli switch ed i segmenti LAN occupati
rallenteranno le cose.
Questa lista non intende certo dire che la potenza della CPU non sia
importante in un file server, ma soltanto che non è così importante come
in un server delle applicazioni.
Server delle applicazioni
Se si dispone, o ci si può permettere di acquistare, le risorse hardware,
occorre installare le applicazioni su un sistema al quale gli utenti possono
collegarsi ed eseguirle. Che lo facciano o meno dipenderà in parte dalla
quantità di potenza e capacità di cui dispongono sui propri desktop, in
parte dalle prestazioni della LAN, in parte dalla compatibilità
dell’OS/applicazione, ma è probabile che almeno alcuni utenti del gruppo
non saranno in grado di eseguire tutte le applicazioni di cui necessitano a
livello locale e che altri preferiranno non farlo perché, per una ragione o
per l’altra, le prestazioni a livello locale sono scadenti. E naturalmente
alcune applicazioni, tipo le applicazioni database di grandi dimensioni,
per loro natura necessitano di capacità che non è probabile si trovino su
un desktop qualsiasi.
60
Capitolo 2
Pianificazione di un gruppo di lavoro
Distribuzione delle applicazioni e dei dati
Un server delle applicazioni, allora richiede:
•
Tutte le caratteristiche di un file server, perché in alcuni casi esso si
comporta da file server, distribuendo le applicazioni attraverso NFS ai
client che le eseguono a livello locale.
Per ragioni di prestazioni, non si tratta di una sistemazione ideale (è
probabile che le applicazioni eseguano più velocemente se la CPU del
server non è occupata a gestire le richieste NFS), ma è una di quelle
comuni ed in pratica potrebbe funzionare bene.
•
Inoltre, un processore potente e magari processori multipli, in modo
da poter eseguire applicazioni di grandi dimensioni e molte
applicazioni simultaneamente.
Per ragioni di compatibilità delle applicazioni, un server delle
applicazioni potrebbe anche necessitare di più frequenti aggiornamenti
del sistema operativo rispetto ad un file server.
Capitolo 2
61
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
Un gruppo di lavoro/rete campione
Per fornire coerenza tra gli studi dei casi e gli esempi nel corso di Gestione
di sistemi e gruppi di lavoro: Guida per gli amministratori di sistema
HP-UX (MSW), abbiamo sviluppato un gruppo di lavoro/rete campione
per dimostrare una varietà di situazioni e procedure.
Dal momento che è impossibile render conto di ogni possibile
combinazione di apparecchiatura e topografia di rete, abbiamo tentato di
render conto di molte delle configurazioni comuni.
La rete MSW (Generalità)
La rete MSW ha due “sottoreti”, congiunte presso un computer gateway
dotato al suo interno di due schede di interfaccia di networking. Le
sottoreti, note come “net1” e “net2,” usano indirizzi Internet Protocol (IP)
nei seguenti intervalli:
net1 15.nn.yy da .0 a 15.nn.yy.256
net2 15.nn.xx da .0 a 15.nn.xx.256
NOTA
Gli indirizzi IP usati nella rete di esempio e nel corso di MSW sono
designati usando componenti di indirizzo non specifici “nn”, “xx” e “yy” per
evitare conflitti con indirizzi IP del mondo reale. Gli indirizzi IP di solito
non contengono lettere.
Nel corso di questo manuale, le sottoreti net1 e net2 fanno parte di un
dominio generico denominato “corporate”.
La Figura 2-1 a pagina 63 illustra una panoramica della rete di esempio
per Gestione di sistemi e gruppi di lavoro. La sezione “La rete MSW
(sistema per sistema)” a pagina 64 offre informazioni dettagliate sui
sistemi della rete di esempio.
62
Capitolo 2
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
Figura 2-1
Schema della rete di esempio di Gestione di sistemi e gruppi di
lavoro
15.nn.yy
15.nn.xx
Enterprise Server
Superdome a 32 vie
(appserver)
Enterprise Server modello rp8400
(flserver)
Workstation
modello J6700
(wsj6700)
Workstation modello b2600
(wsb2600)
Network Hub
HP Pavilion
modello 735n PC
(pc735n)
Workstation modello zx2000
(wszx2)
Stampante di rete
(netlp2)
Compaq Presario
modello s3300nx PC
(pcs3300nx)
Stampante
di rete (netlp1)
Legenda
Workstation modello zx6000
(wszx6)
Server
Workstation
PC
Thin Client modello T20
(thin20)
Thin Client modello T30
(thin30)
Thin Client
Stampante di rete
Tabella 2-1
Sistemi server
Rete di esempio di Gestione di sistemi e gruppi di lavoro
Workstation
Personal
Computer
(PC)
Thin client
Stampanti di
rete
flserver
wszx2
pc735n
thin20
netlp1
appserver
wsj6700
pcs3300nx
thin30
netlp2
wszx6
wsb2600
Capitolo 2
63
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
La rete MSW (sistema per sistema)
La rete MSW include una varietà di tipi di sistemi: sistemi server,
workstation, personal computer e thin client. Vi sono anche diverse
stampanti su base di rete. Per i dettagli sui sistemi specifici elencati nella
tabella precedente, esaminare le seguenti descrizioni fino a trovare il
sistema che interessa.
Sistemi server
La rete di esempio di MSW include due sistemi server:
64
appserver
Questo sistema, un Superdome a 32 vie configurato con
una partizione unica, è un server delle applicazioni
nella rete di esempio. Esegue HP-UX 11i versione 1.
flserver
Questo sistema, un HP9000 rp8400, è uno dei computer
chiave della rete. Il suo nome ne riflette l’uso primario,
un file server. È il luogo in cui questo gruppo di lavoro
memorizza la maggior parte dei propri dati.
Capitolo 2
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
Oltre al suo uso come file server, fa anche da computer
gateway tra le due sottoreti net1 e net2. Ha due schede
di rete, una che connette a net1 attraverso il cavo
coassiale lan sottile ed una che connette a net2
attraverso un hub di rete 10-BaseT.
flserver ha anche una stampante connessa
direttamente ad esso.
appserver
flserver
Nome del sistema:
appserver.net2.corporate
Tipo di sistema:
HP 9000 Enterprise Server
Superdome a 32 vie (partizione unica)
Indirizzo (IP) di rete:
15.nn.xx.200
Sistema operativo:
HP-UX Release 11i versione 1
Memoria fisica:
128 GB
Spazio su disco:
512 GB
Funzionalità:
Server delle applicazioni per gruppo
di lavoro
Nome del sistema:
flserver.net1.corporate
flserver.net2.corporate
Tipo di sistema:
HP 9000 rp8400 (partizione unica)
Indirizzi (IP) di rete:
15.nn.yy.100 (sulla sottorete “net1”)
15.nn.xx.100 (sulla sottorete “net2”)
Sistema operativo:
HP-UX 11i versione 1
Memoria fisica:
64 GB
Spazio su disco:
288 GB
Funzionalità:
File server per gruppo di lavoro.
Si tratta del computer che memorizza
la maggior parte dei file dati per il
gruppo di lavoro rappresentato in
MSW. È una configurazione LVM di
grandi dimensioni con funzionalità ad
alta disponibilità installate.
Capitolo 2
65
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
Questo computer è il sistema gateway
tra le sottoreti net1 e net2. In ragione
di ciò, ha due nomi di rete
(flserver.net1 e flserver.net2) e
due indirizzi IP (uno per ciascuna
scheda di interfaccia di rete).
Workstation
Vi sono quattro workstation nella rete di esempio di MSW, una sulla
sottorete net1, l’altra sulla net2. Ciascuna è un modello diverso ed
eseguono varie versioni di HP-UX per rispecchiare molte installazioni del
mondo reale dove non tutti i computer eseguono la stessa release di
HP-UX.
66
wsj6700
Questa è la workstation connessa alla sottorete net1. Esegue
una versione più vecchia di HP-UX nella rete, HP-UX Release
11.00.
wszx6
Un HP Integrity Modello zx6000 che esegue HP-UX 11i
versione 2.
wsb2600
Un HP 9000 Modello b2600 che esegue HP-UX Release 10.01.
wszx2
Un HP Integrity Modello zx2000 che esegue HP-UX 11i
versione 2.
Capitolo 2
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
wsj6700
wszx6
wsb2600
wszx2
Capitolo 2
Nome del sistema:.
wsj6700.net1.corporate
Tipo di sistema:.
HP 9000 Modello J6700
Indirizzo (IP) di rete:.
15.nn.yy.101
Sistema operativo:.
HP-UX Release 11.00
Memoria fisica:.
64 MB
Spazio su disco:.
144 GB
Funzionalità:.
Computer nel gruppo di lavoro che
eseguono una versione più vecchia del
sistema operativo HP-UX.
Nome del sistema:
wszx6.net2.corporate
Tipo di sistema:
HP Integrity Modello zx6000
Indirizzo (IP) di rete:
15.nn.xx.103
Sistema operativo:
HP-UX 11i versione 2
Memoria fisica:
6 GB
Spazio su disco:
128 GB
Funzionalità:
Workstation di sviluppo software
Nome del sistema:
wsb2600.net2.corporate
Tipo di sistema:
HP 9000 Modello b2600
Indirizzo (IP) di rete:
15.nn.xx.101
Sistema operativo:
HP-UX 11i versione 1
Memoria fisica:
2 GB
Spazio su disco:
36 GB
Nome del sistema:
wszx2.net2.corporate
Tipo di sistema:
HP Integrity Modello zx2000
Indirizzo (IP) di rete:
15.nn.xx.102
Sistema operativo:
HP-UX 11i versione 2
Memoria fisica:
4 GB
Spazio su disco:
36 GB
67
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
Personal Computer (PC)
hp
Hewlett
Packard
La rete di esempio di MSW include due PC, ciascuno che esegue i sistemi
operativi “Microsoft Windows”.
pc735n
68
pc735n
Questo desktop PC HP Pavilion 735n si trova sulla
sottorete net1.
pcs3300nx
Questo desktop PC Compaq Presario s3300nx si trova
sulla sottorete net2.
Nome del sistema:
pc735n.net1.corporate
Tipo di sistema:
Desktop PC HP Pavilion 735n
Indirizzo (IP) di rete:
15.nn.yy.3
Sistema operativo:
Microsoft Windows XP
Memoria fisica:
512 MB
Spazio su disco:
80 GB
Capitolo 2
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
pcs3300nx
Nome del sistema:
pcs3300nx.net2.corporate
Tipo di sistema:
Compaq Presario s3300nx
Indirizzo (IP) di rete:
15.nn.xx0.2
Sistema operativo:
Microsoft Windows XP
Memoria fisica:
1 GB
Spazio su disco:
120 GB
Thin client
La rete di esempio di MSW include anche due computer thin client. Questi
dispositivi non hanno dischi propri e dipendono in gran parte da altri
computer della rete.
thin20
Un thin client Compaq EVO T20
thin30
Un thin client Compaq EVO T30
Thin client Compaq EVO T20
Capitolo 2
69
Pianificazione di un gruppo di lavoro
Un gruppo di lavoro/rete campione
thin20
thin30
Nome del sistema:
thin20.net2.corporate
Tipo di sistema:
Thin client Compaq EVO T20
Indirizzo (IP) di rete:
15.nn.xx.150
Sistema operativo:
Microsoft Windows NT Embedded
Memoria fisica:
8 MB
Spazio su disco:
<nessuno>
Nome del sistema:
thin30.net2.corporate
Tipo di sistema:
Thin client Compaq EVO T30
Indirizzo (IP) di rete:
15.nn.xx.151
Sistema operativo:
Microsoft Windows XP Embedded
Memoria fisica:
16 MB
Spazio su disco:
<nessuno>
Stampanti di rete
La rete di MSW contiene anche varie stampanti di rete, una su ogni
sottorete.
netlp1
netlp2
70
Nome della stampante:
netlp1.net1.corporate
Tipo di stampante:
HP Color LaserJet 5
Indirizzo (IP) di rete:
15.nn.yy.11
Funzionalità:
Dotata di una scheda rete
HP JetDirect per le connessioni di rete
dirette.
Nome della stampante:
netlp2.net2.corporate
Tipo di stampante:
HP LaserJet 5si MX
Indirizzo (IP) di rete:
15.nn.xx.10
Funzionalità:
Dotata di una scheda rete
HP JetDirect per le connessioni di
rete dirette.
Capitolo 2
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Impostazione della strategia di gestione dei
dischi
Questa sezione si occupa di:
•
“Distribuzione dei dischi” a pagina 71
A quali sistemi occorre collegare i dischi del gruppo di lavoro?
•
“Pianificazione delle capacità” a pagina 72
Quanto spazio su disco occorre?
•
“Strumenti di gestione del disco” a pagina 74
LVM, mirroring, striping: di cosa si tratta ed a cosa servono?
Distribuzione dei dischi
Leggere queste linee guida insieme con “Distribuzione delle applicazioni e
dei dati” a pagina 56.
•
Concentrare la capacità del file system sui file server ed i server delle
applicazioni.
Un gruppo di lavoro in cui ogni sistema è autosufficiente è l’incubo
degli amministratori. Il desktop non è il luogo migliore in cui
memorizzare:
— Applicazioni (a meno che l’utente non si assuma la responsabilità
esplicita della loro manutenzione).
— Dati (tranne i dati dei quali non occorra eseguire il backup).
•
Assicurarsi che ogni workstation disponga di un disco locale.
Perfino un client “diskless” ha bisogno di spazio su disco sufficiente
per lo scambio a livello locale. NFS Diskless (disponibile su alcuni
sistemi 10.x) consente ai client di scambiare sui dischi di un server,
ma le prestazioni probabilmente non saranno accettabili.
•
Capitolo 2
Teoricamente, collocare i dati e le applicazioni su server separati, in
modo che la CPU del file server sia occupata principalmente
nell’elaborazione delle richieste NFS, mentre il server delle
applicazioni esegue le applicazioni.
71
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Pianificazione delle capacità
Come per la memoria, la semplice risposta alla domanda, “Quanta
capacità disco occorre acquistare?” è “Tanta quanta sia possibile
permettersene.” È quasi possibile esser sicuri che, per quanta capacità sia
possibile acquistare ora, i propri utenti e le loro applicazioni troveranno
un modo per esaurirla entro un anno.
Comunque, occorre pianificare. Anche se si sta equipaggiando il proprio
gruppo di lavoro partendo da zero ed il gruppo di utenti deve essere
formato anch’esso dal nulla, è probabile che il lavoro che il gruppo svolgerà
non sia stato appena inventato; in qualche posto nella propria società si sta
svolgendo lo stesso lavoro simile ed è da lì che occorre partire.
File server e server delle applicazioni
File system e database
•
Quali applicazioni usano attualmente i propri utenti, o, se si tratta di
un progetto di avvio, quali applicazioni occorre usare per procedure
comparative da parte di circa lo stesso numero di utenti?
•
Quanto spazio su disco devono usare le applicazioni stesse?
•
Quanto spazio su disco devono usare le directory di dati lette e scritte
dalle applicazioni?
•
Quanto spazio consumano attualmente i propri utenti (o utenti
comparabili) nelle loro home directory e directory della posta?
Le risposte a queste domande forniranno un punto di partenza per
stabilire quanto spazio su disco consentire nei volumi non di “sistema” dei
propri file server e server delle applicazioni, cioè, nelle directory delle
applicazioni (/opt), di lavoro, della posta ed home directory e nei volumi
database.
Non sarà dannoso consentire il 100% di crescita nel primo anno in tali
directory (o più di ciò se non si pianifica di controllare la crescita delle
directory degli utenti con le quote disco; consultare “Gestione dell’uso
dello spazio su disco con quote” a pagina 629). Nel corso dell’anno è
possibile monitorare la crescita reale e pianificare gli acquisti extra di
conseguenza.
72
Capitolo 2
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Scambio Non esiste un modo standard per stimare lo scambio, tranne
che lo scambio deve essere almeno uguale alla memoria del sistema locale.
Ciò potrebbe essere sufficiente per i client; quasi sicuramente non lo sarà
per i server.
“Gestione dello scambio e della copiatura” a pagina 671 fornisce alcune
linee guida per stimare le necessità di scambio, ma spesso non esiste un
sostituto per eseguire le applicazioni e vedere cosa accade.
Ecco ciò che abbiamo fatto per riuscire a capire quanto scambio
utilizzerebbero gli strumenti per sviluppare questo documento.
Esempio
Abbiamo avviato una workstation (un HP9000 715 che esegue
HP-UX 10.01 con 96MB di RAM), avviato VUE, aperto una finestra, poi
avviato tutte le applicazioni una dopo l’altra, usando swapinfo (1M) per
verificare ogni volta l’utilizzo dello scambio.
I numeri che seguono rappresentano ciò che è accaduto su un dato sistema
in un dato giorno; li registriamo soltanto per illustrare il metodo. Essi non
definiscono in alcun modo le prestazioni del prodotto o di HP-UX.
ATTENZIONE
Eseguire HP-UX al livello di esecuzione 3 occupa 19-20 MB di scambio
riservato. Effettuare la transizione al livello di esecuzione 4 ed aprire una
finestra VUE ha portato a 39-40 MB di spazio riservato; ciò è illustrato
nella prima fila della tabella; le file successive illustrano ciò che è
accaduto all’avvio delle applicazioni. I totali nella colonna a destra sono
cumulativi.
Tabella 2-2
Eseguire…
Campionatura dell’utilizzo dello scambio
Riservati/usati al momento
della creazione (MB)
MB riservati/usati
aggiuntivi
Attività
Totale
HP-UX/VUE
39-40
0
Aprire 1
finestra
FrameMaker
10
0
Aprire
documento
emacs
2
0
Browser
DynaText
4
0
Aprire manuale 1
0
60
Netscape
6
0
Caricare
grafico
0
67
Capitolo 2
39-40
1
2
53
55
1
73
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Abbiamo ripetuto l’esperimento su un altro sistema più piccolo (32 MB di
RAM) ed abbiamo ottenuto risultati simili, giungendo alla conclusione che
ad una workstation che esegue queste applicazioni a livello locale
occorrono circa 30 MB di scambio disponibili, per un minimo di scambio
configurato di 70 MB.
Nella nostra situazione particolare, dato che all’epoca non disponevamo di
un server delle applicazioni potente e che avevamo varie workstation di
moderata potenza, abbiamo deciso che per noi aveva senso importare
queste applicazioni sulle workstation (attraverso montaggio NFS dal
nostro file server) e, di conseguenza, abbiamo aggiunto scambio di file
system a quei sistemi che sembravano averne bisogno.
Se si dovesse effettuare un simile esperimento su un server delle
applicazioni multiutente, occorrerebbe eseguire tante copie di ogni
applicazione per quante se ne dovessero eseguire in realtà nelle ore di
picco ed occorrerebbe ragionare in modo di gran lunga più semplice di
quanto non si farebbe dal punto di vista delle funzioni delle applicazioni
realizzare e della frequenza e complessità dei campioni.
Workstation
Una workstation necessita di spazio sul disco locale sufficiente a
conservare il sistema operativo, più scambio sufficiente per il gestore dello
spazio di lavoro e qualsiasi applicazione che sarà eseguita a livello locale.
Pianificare di fornire ad ogni workstation un disco di almeno 1 GB.
Entrambe le workstation HP-UX ed NT potrebbero essere in grado di
farcela con 500 MB, ma a stento, in particolare se alcune applicazioni di
dimensioni notevoli stanno eseguendo a livello locale (attraverso NFS o
dal disco locale); consultare “Scambio” a pagina 73.
Strumenti di gestione del disco
Questa sezione fornisce un breve riassunto degli strumenti di gestione del
disco che HP-UX fornisce; per i dettagli, consultare “Amministrazione di
un sistema: Gestione di dischi e file” a pagina 563.
74
Capitolo 2
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Logical Volume Manager (LVM)
LVM è il metodo di gestione del disco più comune per le versioni attuali di
HP-UX su tutte le piattaforme. A partire dalla release 10.20, è il default
sui sistemi Serie 800 (tranne quelli installati con un disco di root inferiori
ad 1 GB), ed è richiesto sui sistemi Serie 700 il cui disco di root è superiore
a 2 GB.
LVM divide il disco allo stesso modo delle “partizioni hard” implementate
con le versioni precedenti di HP-UX per i sistemi, ma i volumi logici sono
di gran lunga più semplici da configurare delle partizioni e possono essere
distribuiti su due o più dischi. Questi due attributi fanno di LVM uno
strumento molto più potente e flessibile che le partizioni hard.
VERITAS Volume Manager (VxVM)
Il VERITAS Volume Manager fornisce gestione del disco in linea
alternativa sui prodotti HP Logical Volume Manager ed
HP MirrorDisk/UX. Il VERITAS Volume Manager è incluso sul CD delle
applicazioni di HP-UX 11i e, a partire dalla release di Settembre 2002 di
HP-UX 11i versione 1, VxVM è incluso negli ambienti operativi e consente
la gestione del volume di root VxVM. Con la gestione del volume di root
VxVM, è possibile scegliere di configurare il volume di root durante
l’installazione con Ignite-UX, o usare gli strumenti di conversione
installati con VxVM per configurare il volume di root in una fase
successiva. Per ulteriori informazioni e dettagli, leggere Guida di
installazione ed aggiornamento di HP-UX 11i ed i documenti di VERITAS
Volume Manager 3.5:
•
•
•
•
•
•
•
VERITAS Volume Manager 3.5 Installation Guide
VERITAS Volume Manager 3.5 Migration Guide
VERITAS Volume Manager 3.5 Release Notes
VERITAS Volume Manager 3.5 Administrator’s Guide
VERITAS Volume Manager 3.5 Hardware Notes
VERITAS Volume Manager 3.5 Troubleshooting Guide
VERITAS Volume Manager 3.5 User’s Guide - VERITAS Enterprise
Administrator
Per informazioni aggiuntive sulle altre versioni di VERITAS Volume
Manager, consultare “VERITAS Volume Manager and File System”
presso il sito web della documentazione HP-UX di HP:
http://docs.hp.com/hpux/os/11i/index.html#VERITAS%20Volume%2
0Manager%20and%20File%20System
Capitolo 2
75
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
IMPORTANTE
Prima di prendere in considerazione di impostare il volume di root su
VxVM, assicurarsi di leggere le VERITAS Volume Manager 3.5 Release
Notes e la VERITAS Volume Manager 3.5 Migration Guide alla pagina
http://docs.hp.com per avere maggiori informazioni e dettagli su
VxVM e la gestione del volume di root.
Disco intero
L’alternativa ad LVM è la gestione a “disco intero”, che, così come si
deduce dal nome, tratta il disco come un’unica unità.
Occorre usare un Logical Volume Manager o il Disco intero?
Vantaggi di un Logical Volume Manager:
•
I volumi logici possono spaziare su dischi multipli:
— I file system (ed i singoli file) possono essere più grandi di un unico
disco fisico.
— Un volume logico può essere piccolo o grande a seconda della
necessità del file system montato su di esso.
— Non occorre sprecare spazio: piccole porzioni di spazio inutilizzato
provenienti da vari dischi possono essere combinate per creare un
volume utilizzabile.
•
È possibile estendere un file system senza doverlo ricostruire.
— Ridurre un file system è più complesso, ma è anche relativamente
indolore.
•
LVM supporta “Mirroring del disco” a pagina 77 e “Striping del disco”
a pagina 77.
Svantaggi di LVM:
•
Complessità.
LVM è uno strumento sofisticato; come tale, occorre del tempo per
apprenderlo, richiede manutenzione (occorre eseguire il backup delle
informazioni sulla configurazione) e le cose possono andar male (se le
informazioni sulla configurazione vanno perdute o si corrompono,
potrebbe non esservi alcun modo per accedere ai dati reali sul disco,
anche se i dati in sé stessi sono intatti).
76
Capitolo 2
Pianificazione di un gruppo di lavoro
Impostazione della strategia di gestione dei dischi
Ma, la propria configurazione di LVM viene automaticamente salvata
in backup ogni volta che la si modifica (in /etc/lvmconf) e “Mirroring
del disco” a pagina 77 fornisce un’assicurazione contro la perdita dei
dati che non è possibile con il metodo a “disco intero”.
Di certo, occorre usare LVM sui file server e sui server delle applicazioni;
sulle workstation dotate di un unico disco, usato soltanto per
memorizzare il sistema operativo e per lo scambio, LVM non è necessario,
sebbene si possa scegliere di implementarlo comunque a scopo di
uniformità, o perché si prevede di aggiungere altri dischi ad alcune
workstation nel corso del tempo.
Mirroring del disco
Il mirroring del disco è disponibile soltanto con LVM. Consultare “Logical
Volume Manager (LVM)” a pagina 75.
Il mirroring del disco consente di mantenere una copia dal vivo di
qualsiasi volume logico; i dati contenuti in tale volume subiscono in effetti
un backup continuo. Il mirroring rigoroso si assicura che la copia
speculare sia su un disco a parte (nello stesso gruppo di volumi).
Il mirroring del disco presenta il vantaggio ovvio di aumentare la
protezione dei dati e la disponibilità del sistema e l’altrettanto ovvio
svantaggio di consumare il doppio dello spazio su disco (o tante volte per
quante sono le copie speculari). Usare il mirroring del disco per i dati
volatili e mission-critical; non occorre eseguire la copia speculare dei
volumi contenenti il software statico tipo il sistema operativo.
Striping del disco
Lo striping del disco è disponibile soltanto con LVM. Consultare “Logical
Volume Manager (LVM)” a pagina 75.
Lo striping del disco distribuisce in modo logico blocchi di dati contigui
(ad esempio, porzioni dello stesso file) su dischi multipli. Ciò accelera la
velocità effettiva I/O per i file di grandi dimensioni quando vengono letti
e scritti in sequenza (ma non necessariamente quando l’accesso è
casuale).
Lo svantaggio dello striping del disco è che la perdita di un solo disco può
avere come conseguenza il danneggiamento di molti file, dato che i file
sono di proposito “spalmati” pezzo per pezzo su due o più dischi.
Considerare di usare lo striping del disco sui file system in cui sono
memorizzati file di grandi dimensioni, se tali file di solito vengono letti e
scritti in sequenza e le prestazioni I/O sono importanti.
Capitolo 2
77
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Pianificazione della gestione dei file system
Questa sezione fornisce le risposte alle domande che potrebbero insorgere
durante la pianificazione dell’amministrazione dei file system. Si discute
dei seguenti argomenti:
•
“Introduzione alla Gestione dei file system” a pagina 78
•
“Determinazione di quale tipo di file system usare” a pagina 80
•
“Wrapper del file system” a pagina 81
•
“Journaled File System, il default del file system” a pagina 82
•
“FAQ sul Journaled File System” a pagina 83
Per le procedure usate per amministrare i file system, andare a “Gestione
dei file system” a pagina 611.
Introduzione alla Gestione dei file system
I file di sistema, i file delle applicazioni ed i file degli utenti devono
risiedere in un file system per essere disponibili al sistema operativo ed
alle applicazioni.
Il file system complessivo di HP-UX è composto da un albero delle
directory o gerarchia, a partire dalla root. Sebbene il file system possa
apparire come un sistema unitario, in realtà potrebbe essere composto da
varie “parti” diverse, ciascuna memorizzata su dispositivi diversi o su
volumi logici diversi. Per consentire agli utenti di accedere ai file di un file
system, tranne che per il file system di root, occorre “montare” il file
system. È possibile fare ciò sia manualmente sia automaticamente
all’avvio, allegandolo ad una directory contenuta nell’albero delle
directory esistente. La directory in cui si allega il file system aggiunto si
chiama il punto di montaggio.
•
Per le informazioni procedurali, andare a “Montaggio di file system” a
pagina 614.
•
Per informazioni utili sulla scelta delle opzioni di montaggio JFS,
andare a “JFS ed il comando mount” a pagina 90.
È anche possibile smontare un file system e se lo si sceglie, allegarlo
nuovamente ad un punto di montaggio diverso.
78
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Per le informazioni procedurali, andare a “Smontaggio di file system” a
pagina 618.
Esistono molti motivi per cui si potrebbe creare una nuova parte del file
system globale, incluso:
•
È stato appena aggiunto un nuovo disco o volume logico non LVM.
•
Ci si preoccupa della possibilità di esaurire lo spazio su disco per i file
dei propri utenti (o si è davvero esaurito lo spazio su disco).
•
Si desidera separare fisicamente parti di un file system, per limitare
la crescita dei file entro una parte del file system oppure per
aumentare la velocità di accesso in modo da avere prestazioni
migliori. Ad esempio, si potrebbe voler mantenere il file system di root
quanto più piccolo possibile per motivi di prestazioni e di sicurezza.
Oppure, si potrebbe volersi preoccupare di un gruppo distinto di
utenti e delle loro necessità, o separare determinati dati con
caratteristiche distinte.
•
Si desidera sostituire un file system di dimensioni maggiori entro un
disco o volume logico non LVM con uno di dimensioni inferiori. Ciò
potrebbe richiedere la creazione di un nuovo file system entro un disco
o volume logico non LVM.
Per le informazioni procedurali, andare a “Creazione di un file
system” a pagina 612.
Tabella 2-3
Limiti del file system delle release HP-UX
10.20
11.00
11i
versione 1
11i
versione 2
128 GB
1 TB
2 TBa
4 TBb
128 GB locale,
2 GB rete
1 TB
2 TBa
2 TBb
RAM fisica
3.75 GB
4 TB
256 GBc
448 GBd
1 TBe
Memoria condivisa
2.75 GB
8 TB
8 TB
261 x 3 Byte
Spazio dati di elaborazione
1.9 GB
4 TB
4 TB
262 Byte
60 K
60 K
60K
400 K
Dimensioni del file system
Dimensioni del file
Numero di descrittori dei file
Capitolo 2
79
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Tabella 2-3
Limiti del file system delle release HP-UX (segue)
Numero di ID utente
a.
b.
c.
d.
e.
10.20
11.00
~2.000 K
~2.000 K
11i
versione 1
11i
versione 2
~2.000 K
~2.000 K
Usando JFS (la versione di default è 3.3)
Usando JFS (la versione di default è 3.5), la limitazione di LVM è 2 TB
Su un Superdome che usa DIMMS da 512 MB
Su un Superdome che usa DIMMS da 1 GB
HP-UX supporta 1 TB – le capacità di memoria variano a seconda del tipo di
macchina
Determinazione di quale tipo di file system usare
A partire da HP-UX 11.0, il Journaled File System (JFS) è installato di
default per la root ed altri file system HP-UX. Tuttavia, sono disponibili
altri quattro tipi di file-system da usare su HP-UX. Le informazioni su
ciascuno di essi sono presentate nella seguente tabella:
Tabella 2-4
Tipo di file
system
Tipi di file system di HP-UX
Quando occorre usarlo?
Informazioni aggiuntive
JFS (Journaled
File System)
Installato di default per
HP-UX 11.0. Consigliato per
scopi generali.
Implementazione HP-UX di un journaled
file system (JFS). Fornisce un recupero
del file system rapido e la capacità di
realizzare una varietà di procedure
amministrative in linea.
HFS (High
Performance File
System)
Quando occorra la
compatibilità con release
precedenti di HP-UX.
Rappresenta l’implementazione HP-UX
standard dello UNIX File System (UFS).
NFS (Network
File System)
Usare NFS per montare le
directory da sistemi remoti.
NFS consente a molti sistemi di
condividere gli stessi file usando un
approccio client/server. Dato che le
tecniche di accesso sono trasparenti,
l’accesso dei file remoti appare simile
all’accesso dei file locali.
80
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Tabella 2-4
Tipo di file
system
Tipi di file system di HP-UX (segue)
Quando occorre usarlo?
Informazioni aggiuntive
CDFS (CD-ROM
File System)
Usare CDFS per montare un
CD-ROM contenente un file
system.
CDFS è un file system di sola lettura; non
è possibile scrivere su un CDFS.
LOFS (Loopback
File System)
Usare LOFS per montare
una directory esistente su
un’altra directory.
Consente alla stessa gerarchia di file di
comparire in posti multipli, il che è utile
per la creazione di copie di ambienti di
costruzione e sviluppo.
È consentito avere un misto di JFS ed altri file system su un unico sistema
di computer.
NOTA
Le liste di controllo dell’accesso sono supportate in JFS ad iniziare da JFS
3.3, che è incluso con HP-UX 11i. È possibile ottenere JFS per
HP-UX 11.00 dal Software Depot HP, http://software.hp.com.
Per vedere se JFS è installato su un sistema HP-UX 11.00, eseguire
swlist -l fileset JFS
Se JFS è installato, l’output includerà una lista dei set di file di JFS. Nel
caso in cui si ottenga un messaggio di errore, significa che JFS non è
installato.
Wrapper del file system Molti comandi di amministrazione del file
system ora forniscono un’opzione -F tipo_FS che consente di specificare
il tipo di file system. Usare le seguenti parole chiave per indicare il tipo di
file system idoneo:
•
•
•
•
•
vxfs per JFS (VxFS)
hfs per HFS
nfs per NFS
cdfs per CDFS
lofs per LOFS
HP-UX può stabilire il tipo di file system per i comandi che funzionano su
un file system preesistente, anche se non si specifica -F tipo_FS sulla
riga dei comandi.
Per ulteriori informazioni sui wrapper del file system, consultare
fs_wrapper (5).
Capitolo 2
81
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Per informazioni procedurali sulla conversione del file system, consultare
“Conversione di file system esistenti in JFS” a pagina 653.
Journaled File System, il default del file system
JFS è l’implementazione HP-UX del VERITAS journaled file system
(VxFS), che presenta una superba affidabilità ed un rapido recupero.
A partire dalla release 10.30, JFS è il file system di default di HP-UX.
Gli ambienti operativi HP-UX 11i includono VxFS.
La funzionalità JFS di base è inclusa con il software del sistema operativo
HP-UX. Con l’installazione di un prodotto che è possibile ordinare a parte
denominato HP OnLineJFS, JFS fornisce anche le operazioni
amministrative in linea, incluso il backup, il ridimensionamento e la
deframmentazione.
Vale davvero la pena dedicare un po’ di tempo all’apprendimento dell’uso
di JFS, considerando i vantaggi che esso offre.
Per le informazioni procedurali concernenti i file system JFS, andare a:
•
•
•
•
•
NOTA
“Conversione di file system esistenti in JFS” a pagina 653
“Ridimensionamento di un file system JFS” a pagina 661
“Deframmentazione di un file system JFS” a pagina 652
“Gestione della corruzione del file system” a pagina 622
“Backup di un’istantanea JFS del file system” a pagina 705
Per informazioni aggiuntive sulle funzionalità di JFS, consultare Disk
and File Management Tasks on HP-UX, pubblicato da Prentice Hall.
Consultare anche la documentazione HP JFS, la HP OnLineJFS e
VERITAS File System disponibile alla pagina http://docs.hp.com.
http://docs.hp.com/hpux/os/11i/index.html#VERITAS%20Volume%2
0Manager%20and%20File%20System
82
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
FAQ sul Journaled File System
Cos’è JFS?
JFS è l’implementazione HP-UX del VERITAS journaled file system
(VxFS) introdotta in HP-UX 10.01. Essa offre affidabilità, recupero rapido
ed operazioni amministrative in linea, incluso il backup, il
ridimensionamento e la deframmentazione.
Per quanto tempo è stato disponibile JFS in HP-UX?
HP ha programmato l’implementazione di JFS nel corso di varie release:
Capitolo 2
•
HP-UX 10.01 ha introdotto una parte iniziale di JFS, basata su
VERITAS Versione 2 VxFS, per file system che era possibile montare
(ma non di root). Fino ad allora, HFS (high-performance file system)
era il solo file system di lettura/scrittura montato a livello locale.
•
A partire da 10.20, HP-UX ha concesso JFS come file system di root
locale nell’ambito di un volume logico, sebbene non su un disco intero
non partizionato. L’implementazione 10.20 di JFS è VERITAS
Versione 3, che supporta dimensioni file superiori a 2 GB così come
numero di identificazione utente (UID) di grandi dimensioni. Per
informazioni per convertire un file system Versione 2 alla Versione 3,
consultare vxupgrade (1M). Non si è limitati ad usare soltanto
un’unica versione sul proprio sistema; tuttavia, non è possibile
montare la Versione 3 su un sistema 10.01.
•
A partire da 10.30, JFS è diventato il file system di default per i server
ad accensione immediata ed installazione a freddo.
•
Tra le altre caratteristiche, HP-UX 11i versione 1 include JFS 3.3 o
3.5, che supporta le Liste di controllo dell’accesso (Access Control
Lists - ACL) ed il layout disco Versione 4. HP-UX 11.00 include
JFS 3.1, ma JFS 3.3 è disponibile per HP-UX 11.00 dal Software
Depot HP, http://software.hp.com.
83
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
JFS ed altri file system
Come si confronta il journaled file system (JFS) a HFS?
JFS migliora l’High-Performance file system (HFS) nei seguenti modi:
•
tempo di recupero più rapido rispetto ad HFS fsck, usando un log di
intenti
•
più robusto di HFS, perché JFS contiene più codici di annullamento
panico
•
migliori prestazioni in molte circostanze, dovute all’uso di estensioni
•
amministrazione in linea, incluso il backup, il ridimensionamento e la
deframmentazione, usando il pacchetto opzionale HP OnLineJFS
Se confrontato con HFS, JFS si ripristina molto più rapidamente dal
guasto del sistema, grazie al suo meccanismo per la registrazione delle
modifiche nella struttura del file system. Quando il sistema si avvia dopo
un crash, il file system si sincronizza usando il suo log per accelerare il
ripristino, con un’operazione simile, ma più veloce, a quella realizzata da
fsck. Il tempo di recupero rapido è particolarmente utile in ambienti che
richiedono alte prestazioni o che trattano grandi volumi di dati.
JFS consente una maggiore velocità effettiva dei dati (I/O più veloce) di
HFS. Ciò è dovuto all’organizzazione di JFS della memorizzazione dei file
in estensioni, che possono essere composte da blocchi di dati multipli.
Il prodotto opzionale HP OnLineJFS facilita la manutenzione del sistema
consentendo di realizzare procedure come il backup del file system e
l’aumento o la riduzione di un file system senza doverlo smontare. Queste
funzionalità non sono disponibili con HFS.
•
“Conversione di file system esistenti in JFS” a pagina 653
Quali sono gli svantaggi di configurare un file system usando JFS?
Si potrebbe non voler configurare JFS su un sistema con memoria
limitata perché i suoi requisiti di memoria superano quelli di HFS.
L’uso di JFS è limitato in qualche modo da LVM (consultare “Il Logical
Volume Manager (LVM)” a pagina 566)?
È possibile usare JFS su qualsiasi file system, a prescindere dal fatto che
sia gestito o meno da LVM.
84
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Come si amministra JFS?
JFS può essere amministrato usando SAM o i comandi di HP-UX. SAM ha
delle utility per creare (aggiungere), eseguire il backup e ridimensionare
i file system JFS.
Se si dispone del pacchetto opzionale HP OnLineJFS (a cui si fa
riferimento in alcune manpage come Advanced VxFS), è possibile usare la
scelta di menu VxFS Maintenance di SAM per visualizzare l’estensione e
la frammentazione delle directory, riorganizzare le estensioni e le
directory, ridimensionare i file system JFS quando si è in linea e
realizzare un backup in linea usando un’istantanea di un file system JFS.
Dalla riga di comando è possibile usare:
•
Il comando mkfs -F vxfs per creare un file system JFS (consultare
mkfs_vxfs (1M)).
•
Qualsiasi utility di backup per realizzare un backup di un file system
JFS tranne fbackup (perché non supporta i file system a sola lettura)
o dump.
•
fsadm per visualizzare la frammentazione, riorganizzare e
ridimensionare i file system JFS. (fsadm (1M) è disponibile con
HP OnLineJFS (anche noto come Advanced VxFS).
JFS e le operazioni interne
Come funziona JFS?
JFS alloca lo spazio sui file sotto forma di estensioni, blocchi di dischi
adiacenti trattati come un’unità. Le dimensioni delle estensioni possono
variare da un unico blocco a molti megabyte. Organizzare i dati dei file in
questo modo consente a JFS di emettere richieste I/O di grandi
dimensioni, il che è più efficace che leggere o scrivere un unico blocco per
volta.
JFS raggruppa le modifiche strutturali in transazioni e le registra in un
log degli intenti su un disco prima di realizzare effettivamente qualsiasi
modifica. Se il sistema subisce un crash, fsck dovrà soltanto scansionare
il log degli intenti e completare le transazioni che erano in corso.
Ciò fornisce una maggiore integrità del file system e riduce di molto il
tempo di recupero in confronto ad un file system tradizionale che deve
essere scansionato dall’inizio alla fine alla ricerca di eventuali incoerenze.
Capitolo 2
85
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
JFS offre opzioni di montaggio per ritardare o disabilitare la
registrazione delle transazioni. Ciò consente all’amministratore di
sistema di realizzare bilanciamenti tra integrità e prestazioni del file
system, assicurando l’integrità dei file system critici ed al contempo
ottimizzando le prestazioni dei file system non critici o temporanei.
Quando si dispone del prodotto opzionale HP OnLineJFS, è possibile
realizzare molte operazioni amministrative su un file system JFS attivo,
incluso ridimensionarlo, riorganizzare i suoi file per renderli contigui e
riorganizzare le directory per recuperare lo spazio non utilizzato. Inoltre,
è possibile realizzare un’istantanea di un file system montato per il
backup. L’istantanea fornisce una visualizzazione coerente e di sola
lettura del file system in un determinato momento, anche se il file system
del quale è un’istantanea continua a modificarsi. L’amministrazione in
linea, insieme con il recupero rapido reso possibile dal log degli intenti,
aumenta in modo significativo la disponibilità del file system.
Quali sono i contenuti di una transazione JFS?
Una transazione è composta da tutte le singole operazioni del sistema
correlate ad una modifica. Ad esempio, scrivere su un file potrebbe
comportare l’aumento delle sue proporzioni, il che implicherebbe
l’allocazione di spazio aggiuntivo, l’aggiornamento della mappa delle sue
estensioni, l’aumento delle sue dimensioni e l’aggiornamento del suo
tempo dell’ultima modifica. Queste modifiche sono trattate come un’unica
transazione, che viene registrata prima della realizzazione effettiva di
eventuali modifiche. Quando tutte le modifiche sono effettuate, anche
questo fatto è registrato nel log degli intenti.
Le transazioni di JFS sono garantite come atomiche, cioè tutte le singole
operazioni che comprendono una transazione vanno a buon fine o nessuna
di esse lo fa. Il file system non resta in uno stato intermedio, con alcune
operazioni completate ed altre no, anche dopo un crash del sistema. In
genere, una transazione è impegnata (cioè, assicurata per il
completamento) quando la chiamata del sistema che l’ha iniziata torna
all’applicazione; tuttavia, si trovano delle eccezioni nelle opzioni di
montaggio JFS che ritardano la registrazione della transazione. Tuttavia,
anche se la registrazione della transazione è ritardata, le transazioni
restano atomiche ed il file system non sarà tuttavia lasciato in uno stato
intermedio.
86
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
I dati utente fanno parte di una transazione?
Di solito, i dati utente non sono trattati come parte di una transazione.
Invece, sono collocati nella cache buffer senza garanzia di scriverli sul
disco a meno che non si esegua esplicitamente sync (1M). Tuttavia, se
un’applicazione usa una scrittura sincrona (ad esempio, aprendo un file
con l’indicatore O_SYNC), i dati utente sono trattati come parte della
transazione, con la stessa atomicità applicabile ai metadati (inodi, mappe
delle estensioni, ecc.) del file system.
Cosa sono le estensioni di JFS e come le usa il sistema operativo?
JFS alloca lo spazio sui file sotto forma di estensioni, blocchi di dischi
adiacenti (contigui) trattati come un’unità. Le dimensioni delle estensioni
possono variare da un unico blocco a molti megabyte. Organizzare i dati
dei file in questo modo consente a JFS di emettere richieste I/O di grandi
dimensioni (cioè, gestire I/O in blocchi multipli), il che è più efficace che
leggere o scrivere un unico blocco per volta.
Se si legge un file in sequenza, JFS può trasportare più dell’estensione
attuale di quanta ne occorra per soddisfare un’unica chiamata di sistema
di lettura, rendendo in tal modo disponibili i dati nella cache buffer per le
letture successive. Questa forma di lettura anticipata non comporta
un’operazione I/O extra, dato che i dati sono contigui sul disco. Al
contrario, con un’unica richiesta I/O vengono portati nella cache buffer
più dati di quanti ne occorrano nell’immediato.
I dati per una chiamata di sistema di scrittura vengono collocati nella
cache buffer e riversati sul disco in un momento successivo. Questa è
definite scrittura ritardata. Casomai, quando i dati vengono svuotati sul
disco, JFS cerca altri dati in attesa di essere stati svuotati sui blocchi
adiacenti e tenta di raggruppare tutti i dati in un’unica grande richiesta
I/O.
Le estensioni di JFS sono rappresentate da un numero di blocco di
partenza ed un conteggio di blocco. Quando un file cresce, JFS prima tenta
di aumentare le dimensioni dell’ultima estensione del file.
Capitolo 2
•
Se riesce nell’operazione, il suo numero di blocco di partenza resta lo
stesso, ma il suo conteggio di blocco viene aumentato.
•
Se invece fallisce, una nuova estensione viene allocata con un numero
di blocco diverso ed aggiunta al file.
87
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
NOTA
Le estensioni di JFS non sono correlate alle estensioni fisiche o logiche di
LVM. Le estensioni fisiche di LVM sono anche blocchi contigui del volume
fisico (disco), 4 MB di dimensioni di default, ma le cui dimensioni sono
fisse. Per informazioni sulle estensioni di LVM, consultare “Come
funziona LVM” a pagina 567.
Come fa JFS ad allocare le estensioni per gestire la crescita dei file?
Quando un file cresce, è possibile aggiungere una nuova estensione, o
aumentare le dimensioni dell’ultima estensione (presumendo che vi sia
sufficiente spazio libero immediatamente dopo di essa). Nel caso in cui
non vi sia sufficiente spazio libero immediatamente dopo l’ultima
estensione, JFS alloca un’estensione non contigua a parte.
Il prodotto opzionale HP OnLineJFS consente di deframmentare le
estensioni non contigue. Questa riorganizzazione comporta il
mescolamento dei blocchi di dati in un file system per fondere le
estensioni e rendere i file più contigui. Per i dettagli, consultare la guida
in linea di SAM o fsadm_vxfs (1M).
Cos’è il log degli intenti di JSF e come si usa?
JFS raggruppa le modifiche strutturali in transazioni e le registra in un
log degli intenti su un disco prima di dare loro inizio. Ad esempio, scrivere
su un file potrebbe comportare l’aumento delle sue proporzioni, il che
implicherebbe l’allocazione di spazio aggiuntivo su di esso,
l’aggiornamento della mappa delle sue estensioni, l’aumento delle sue
dimensioni e l’aggiornamento dell’ora dell’ultima modifica. Tali modifiche
sarebbero trattare come un’unica transazione che sarebbe registrata
prima della realizzazione effettiva di qualsiasi modifica. Una volta
effettuate tutte le modifiche, anche questo fatto sarebbe registrato nel log
degli intenti.
Se il sistema subisce un crash, fsck dovrà soltanto scansionare il log degli
intenti e completare le transazioni che erano in corso. Questo si chiama
riesecuzione del log. Essa fornisce una maggiore integrità del file system
e riduce di molto il tempo di recupero in confronto ad un file system
tradizionale che deve essere scansionato dall’inizio alla fine alla ricerca di
eventuali incoerenze. Poichè il log degli intenti è disponibile su fsck, le
dimensioni del file system non rappresentano un fattore importante,
soltanto il numero di transazioni incomplete al momento del crash. Anche
per un file system che era molto attivo, la riesecuzione del log impiegherà
di solito meno di dieci secondi.
88
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Per ulteriori informazioni, consultare “Gestione della corruzione del file
system” a pagina 622.
Ogni file system JFS ha il proprio log degli intenti. Al momento della
creazione del file system, si riserva dello spazio per il log degli intenti, e le
sue dimensioni non possono essere in seguito modificate. Il log degli
intenti non è un file visibile dall’utente, sebbene sia possibile usare lo
strumento fsdb per copiarlo.
Di solito, i dati utente non sono trattati come parte di una transazione. Al
contrario, vengono collocati nella cache buffer con la solita semantica di
scrittura ritardata UNIX (cioè, senza garanzie di essere stati scritti su
disco, a meno che non si esegua esplicitamente sync). Tuttavia, se
l’applicazione indica una scrittura sincrona (ad esempio, aprendo un file
con l’indicatore O_SYNC), i dati utente sono trattati come parte della
transazione, con la stessa garanzia di ‘tutto o niente’ applicabile ai
metadati del file system (tipo directory, inodi, mappe libere delle
estensioni).
In quali casi il log degli intenti contiene i dati dei file?
Di solito, il log degli intenti contiene soltanto le informazioni sui metadati
del file system, tipo superblocco, inodi e directory.
Tuttavia, i dati dei file scritti sincronicamente (cioè, il file viene aperto con
l’opzione O_SYNC o O_DSYNC) vengono registrati nel log degli intenti, se le
dimensioni del blocco di scrittura sono di 8KB o inferiori. Tale comportamento è vero sia per Basic JFS sia per HP OnLineJFS (anche noto come
pacchetto Advanced VxFS), ma può essere modificato usando l’opzione
nodatainlog del comando di montaggio (consultare mount_vxfs (1M)).
NOTA
Un server NFS scrive sincronicamente, pertanto potrebbe avere un senso
aumentare le dimensioni del log degli intenti (opzione newfs) su un file
system esportato su NFS.
Quali sono le dimensioni consigliate del log degli intenti?
Le dimensioni del log degli intenti sono impostate per default, in base alle
dimensioni del file system. Di solito, le dimensioni del log degli intenti
sono di 1 MB.
Se il file system è:
Capitolo 2
•
superiore o uguale ad 8 MB, il default è di 1024 blocchi
•
superiore o uguale a 2 MB, il default è di 128 blocchi
•
inferiore a 2 MB, il default è di 32 blocchi
89
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Potrebbe esservi un motivo per aumentare le dimensioni del log degli
intenti? Cosa accade se si riempie? Si verificheranno degli errori o ne
risulteranno pregiudicate le prestazioni?
No. Se il log degli intenti si riempie, non vi sarà alcun impatto percettibile
sugli utenti. Potrebbe verificarsi un blocco su I/O, ma ciò si verifica in
molte situazioni che non sono correlate al log degli intenti e non avrà un
impatto percettibile. Se il log degli intenti si riempie, non si
verificheranno errori.
Come è possibile conoscere le dimensioni del log degli intenti?
È possibile usare fsdb per visualizzare le dimensioni del log degli intenti.
Tuttavia, questo debugger del file system deve essere usato
esclusivamente da utenti avanzati, dato che, se non è usato correttamente,
può distruggere il file system. Per le relative informazioni e per
informazioni sul formato superblocco JFS, consultare fsdb_vxfs (1M).
Come è possibile modificare le dimensioni del log degli intenti?
Usare il comando mkfs -F vxfs con la seguente opzione -o:
-o logsize=n, dove n è il numero di blocchi da allocare per il log degli
intenti. n deve essere compreso nell’intervallo da 32 a 2048.
Per la sintassi, consultare mkfs_vxfs (1M).
JFS ed il comando mount
Quali sono le opzioni di montaggio JFS e dove sono vantaggiose da usare?
JFS offre opzioni di mount per ritardare o disabilitare la registrazione
delle transazioni e per controllare se i dati utente sono scritti sincronicamente o ritardati. Queste impostazioni consentono all’amministratore di
sistema di realizzare bilanciamenti tra integrità e prestazioni del file
system, assicurando l’integrità dei file system critici ed al contempo ottimizzando le prestazioni dei file system non critici o temporanei.
Per la sintassi, consultare mount_vxfs (1M).
Quali sono le opzioni di registrazione disponibili usando JFS?
JFS fornisce una varietà di opzioni per controllare come le transazioni
vengono registrate sul disco, come elencato di seguito. Il default, log,
fornisce la massima integrità di sistema in caso di guasto del sistema. In
altri casi, incluso il montaggio di un file system JFS con SAM e della
realizzazione di un’installazione a freddo, il modo di registrazione
consigliato è delaylog.
90
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
log
Registrazione completa (default). Le modifiche
strutturali del file system sono registrate sul disco
prima che la chiamata del sistema torni all’applicazione.
Se il sistema subisce un crash, fsck porterà a termine le
operazioni registrate non ancora completate.
delaylog
Registrazione ritardata. Alcune chiamate del sistema
tornano prima che il log degli intenti sia scritto. Ciò
aumenta le prestazioni del sistema, ma alcune
modifiche non sono assicurate fino a poco tempo dopo
l’avvenuta scrittura del log degli intenti. Questo modo si
avvicina alle garanzie UNIX tradizionali per la
correttezza in caso di guasto del sistema.
tmplog
Registrazione temporanea. Il log degli intenti è quasi
sempre ritardato. Ciò migliora le prestazioni, ma le
modifiche recenti potrebbero scomparire in caso di
crash del sistema. Questo modo è consigliato soltanto
per i file system temporanei.
nolog
Nessuna registrazione. Il log degli intenti è disabilitato.
Gli altri tre modi di registrazione forniscono il recupero
rapido del file system; nolog non fornisce il recupero
rapido del file system. Con il modo nolog, occorre
realizzare una verifica strutturale completa dopo un
crash; ciò potrebbe provocare una perdita di parti
sostanziali del file system, a seconda dell’attività che si
stava realizzando al momento del crash. Di solito, dopo
un crash occorre ricostruire un file system nolog con
mkfs. Il modo nolog deve essere usato esclusivamente
per file system residenti in memoria o molto temporanei
(consultare mkfs_vxfs (1M)).
Quali sono le opzioni di scrittura disponibili usando JFS?
JFS fornisce varie opzioni per controllare le modalità di scrittura dei dati
utenti sul disco.
sync
Capitolo 2
Scritture sincrone. Scrive il blocco fino a che i dati
specificati nella richiesta di scrittura e tutti gli attributi
del file richiesti per recuperare i dati non siano scritti
sul disco.
91
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
dsync
Scritture sincrone dei dati. Un’operazione di scrittura
torna al chiamante dopo che i dati sono stati trasferiti al
supporto esterno. Tuttavia, se nell’inodo deve essere
aggiornato soltanto il tempo, l’inodo non viene
aggiornato sincronicamente.
closesync
Scritture alla chiusura sync. Il modo I/O alla chiusura
sync provoca il ritardo delle scritture invece del loro
effetto immediato e provoca l’esecuzione
dell’equivalente di un fsync (2) alla chiusura di un file.
delay
Scritture ritardate. Provoca il ritardo delle scritture
invece che il loro effetto immediate. Alla chiusura di un
file non si effettua alcuna azione particolare.
Inoltre, l’amministratore di sistema può controllare il modo in cui le
scritture sono gestite, con e senza O_SYNC.
•
l’opzione di mount mincache stabilisce le modalità di trattamento
delle scritture ordinarie.
•
l’opzione di mount convosync stabilisce le modalità di trattamento
delle scritture sincrone
Date tutte le molteplici opzioni di JFS, quali sono alcune delle
combinazioni utili di registrazione e memorizzazione nella cache?
mount -o log,mincache=dsync
•
fornisce integrità completa per i metadati ed i dati utente
•
registra immediatamente tutte le transazioni
•
tratta tutte le scritture come sincrone
mount -o log
•
fornisce integrità completa per i metadati
•
registra immediatamente tutte le transazioni
•
per le scritture vale la normale semantica UNIX
— Svuotate periodicamente dal daemon syncer (1M).
— È possible svuotarle in modo esplicito mediante sync (1M)
92
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
mount -o delaylog
•
fornisce integrità completa per i metadati critici
•
registra immediatamente le modifiche dei metadati critici
•
ritarda la registrazione delle modifiche dei metadati non critici
— Operazione più comune: aggiornamento dell’ora dell’accesso o di
modifica del file
•
per le scritture vale la normale semantica UNIX
mount -o nolog,convosync=delay
•
fornisce le prestazioni massime, ma la protezione minima
•
non registra alcuna transazione
•
tratta tutte le scritture come ritardate (anche se l’applicazione ha
richiesto esplicitamente I/O sincrono)
•
riesecuzione della registrazione impossibile
— dopo un crash, potrebbe essere necessario dover ricostruire il file
system
mount -o nolog,convosync=delay è utile soltanto per file system
temporanei. L’opzione convosync=delay fa in modo che JFS modifichi
tutte le scritture O_SYNC in scritture ritardate, annullando tutte le
garanzie di integrità dei dati di solito fornite aprendo un file con O_SYNC.
Funzionalità di HP OnLineJFS
Quali operazioni in linea è possibile realizzare con OnLineJFS?
Le operazioni amministrative che è possibile realizzare sul file system
JFS attivo quando si dispone del prodotto opzionale HP OnLineJFS
includono:
Capitolo 2
•
ridimensionamento
•
riorganizzazione dei suoi file per renderli contigui
•
riorganizzazione delle directory per recuperare spazio inutilizzato
•
realizzazione di un’istantanea di un file system montato a scopo di
backup
93
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Cos’è un’istantanea di JFS e perché è utile?
Un’istantanea (disponibile con HP OnLineJFS) è una visualizzazione
coerente e stabile di un file system attivo, usata per realizzare un backup
di un file system attivo. Consente all’amministratore di sistema di
catturare lo stato del file system in un determinato momento nel tempo
(senza doverlo collocare fuori linea e copiare), montare l’immagine di quel
file system in qualche altro posto ed eseguirne il backup.
Ad esempio, è possibile montare un’istantanea di /home su /tmp/home.
All’inizio, compariranno directory e file identici sotto /home e sotto
/tmp/home, ma gli utenti saranno ancora in grado di accedere e modificare
il file system primario (/home). Tali modifiche non compariranno
nell’istantanea. Invece, /tmp/home continuerà a rispecchiare lo stato di
/home al momento della realizzazione dell’istantanea.
Per l’utente, l’istantanea ha l’aspetto di un file system ordinario, che è
stato montato read-only (in sola lettura). Le istantanee sono sempre
montate in sola lettura; cioè, nessuna delle sue directory o file può essere
modificato.
Tuttavia, internamente succede qualcosa di molto diverso.
•
Il dispositivo contenente un’istantanea contiene soltanto i blocchi che
sono cambiati sul file system primario dal momento in cui l’istantanea
è stata creata.
•
I restanti blocchi, che non sono cambiati, possono essere reperiti sul
dispositivo contenente il file system primario. Pertanto, non occorre
realizzare una copia.
Tutto ciò viene realizzato in modo trasparente nell’ambito della kernel.
Come si lavora con le istantanee?
Un’istantanea JFS può essere usata per realizzare un backup in linea di
un file system. Per la procedura, andare a “Come creare ed effettuare il
backup di un’istantanea JFS del file system” a pagina 705.
L’istantanea del file system deve risiedere su un disco a parte o su un
volume logico a parte, separato dal file system originale. Tutti i dati
presenti sul dispositivo prima della realizzazione dell’istantanea saranno
sovrascritti al momento della realizzazione dell’istantanea stessa.
Non occorre modificare i comandi e le applicazioni per lavorare con le
istantanee, dal momento che la kernel è responsabile dell’ubicazione dei
dati dell’istantanea (sul dispositivo dell’istantanea o sul dispositivo
primario) e della copiatura dei singoli blocchi dal file system primario al
94
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
dispositivo dell’istantanea immediatamente prima del loro
aggiornamento. In ragione di tale schema di scrittura su copia, è possibile
creare un’istantanea in modo immediato ed occorre soltanto lo spazio
sufficiente a contenere i blocchi che potrebbero cambiare durante
l’esecuzione del montaggio dell’istantanea.
Il volume dell’istantanea deve essere pari a circa il 10-20% delle
dimensioni del file system originale. Non occorre strutturare il volume
dell’istantanea in alcun modo; non è necessario eseguire newfs per il file
system di un’istantanea prima della realizzazione del suo montaggio.
Durante il montaggio di un’istantanea, le modifiche apportate al file
system originale non compariranno in tale istantanea. L’istantanea è
un’immagine “congelata” del file system originale.
Una volta smontata l’istantanea, i suoi contenuti vanno perduti.
Quali limitazioni presentano le istantanee?
È possibile esaurire lo spazio su un dispositivo di istantanea. Ciò potrebbe
accadere perché il dispositivo è troppo piccolo, perché il file system
primario è troppo volatile o perché l’istantanea resta montata troppo a
lungo. Quando il dispositivo di un’istantanea si riempie, la kernel non ha
altro luogo in cui copiare i blocchi dal file system primario. In una
situazione simile, la kernel non può conservare una visualizzazione
stabile del file system, pertanto rende inaccessibile l’istantanea. Di solito,
l’amministratore di sistema creerà una nuova istantanea dopo aver
eliminato il problema (ad esempio, usando un dispositivo di istantanea di
maggiori dimensioni, o scegliendo un’ora in cui il file system primario sia
meno volatile).
In che modo un backup di OnLineJFS è diverso da un backup standard?
Un backup di OnLineJFS implica l’uso di un’istantanea del file system,
invece che il file system stesso.
È possibile reperire informazioni esplicite sulle modalità di realizzazione
di un backup in linea in “Backup di un’istantanea JFS del file system” a
pagina 705.
Ai fini dei backup in linea, quali sono i vantaggi e quali gli svantaggi delle
istantanee in confronto all’uso della utility lvsplit di LVM?
Questa domanda presume che si sia installato sia HP MirrorDisk/UX sia
HP OnLineJFS.
Capitolo 2
95
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Vantaggi dell’uso di lvsplit:
•
È possibile realizzare il backup usando un gruppo di volumi di sola
lettura.
•
È possibile usare fbackup, che non è supportato per i file system
dell’istantanea di JFS.
•
lvsplit funziona in modo atomico su vari volumi logici
contemporaneamente; al contrario, non è possibile realizzare
un’istantanea di più di un file system per volta.
•
In caso di guasto di un disco, il mirroring fornisce maggior protezione
(tuttavia, è possibile realizzare un’istantanea di un volume del quale
sia stata eseguita una copia speculare; non occorre realizzare la copia
speculare dell’istantanea stessa).
•
lvsplit potrebbe fornire prestazioni migliori, dal momento che i
blocchi in scrittura sono copiati sul volume dell’istantanea,
aumentando quindi l’I/O del disco. Tuttavia, lvmerge aumenterà
anche l’I/O del disco ed occorrerà anche un fsck.
Vantaggi dell’istantanea JFS:
•
Le istantanee richiedono meno spazio su disco di quanto non ne
richiedano le immagini copiate specularmente del file system.
•
Le istantanee non richiedono un fsck, che è necessario dopo avere
eseguito un lvsplit.
•
Le istantanee sono una procedura sicura a prova d’errore: eseguendo
lvmerge con una sequenza di argomenti errata è possibile distruggere
i blocchi del disco creati dopo lvsplit.
JFS ha un’interfaccia con un file system di istantanea?
La utility fscat fornisce un’interfaccia con un file system di istantanea di
JFS, simile quella fornita dalla utility dd richiamata sul file speciale di
altri file system JFS. Sulla maggior parte dei file system JFS, il blocco o
file speciale di caratteri per il file system fornisce l’accesso ad
un’immagine grezza del file system per scopi tipo l’esecuzione del backup
del file system su nastro. La utility fscat illustra l’istantanea come flusso
di byte che è possibile elaborare in un pipeline o scrivere su nastro.
Per ulteriori informazioni, consultare fscat_vxfs (1M).
96
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Di quali considerazioni sulle dimensioni deve essere al corrente un
amministratore quando configura un file system JFS?
Dimensioni del
blocco
Spazio su disco
Dimensioni del
volume logico
Inodi
Le dimensioni del blocco consigliate per i file system
JFS sono di 1K. Dal momento che JFS usa le estensioni,
non occorre aumentarle. Tuttavia, nel caso in cui si
decida di modificare le dimensioni del blocco, occorre
ricreare il file system. Usare mkfs -F vxfs
-o bsize=n, dove n sono le dimensioni del blocco
espresse in byte e rappresenta la quantità di spazio su
disco più piccola che sarà allocata su un file. n deve
essere una potenza di 2 scelta in un intervallo compreso
da 1024 a 8192; il default è 1024 byte.
Il solo spazio su disco aggiuntivo usato da JFS oltre a
quello usato da HFS è quello destinato al log degli
intenti. La sua media è di 1 MB e non può essere
maggiore di 2048 blocchi.
Le dimensioni massime consentite per un volume logico
in JFS sono di 4 GB.
JFS alloca gli inodi dinamicamente, senza limitazione
interna sul numero possibile, in quanto l’unica
limitazione è rappresentata dallo spazio su disco. Un
inodo di JFS occupa fino a 256 byte (la creazione degli
inodi di JFS è diversa da HFS, che ha mkfs che alloca un
numero fisso di inodi in anticipo).
Inoltre, JFS ed HFS hanno gli stessi limiti per le dimensioni dei file e del
file system:
Capitolo 2
•
Le dimensioni del file massime sono di 2 GB per le release di HP-UX
precedenti alla 10.20, di 128 GB per HP-UX 10.20, o di 1TB per
HP-UX 11.x e successive.
•
Le dimensioni del file massime sono di 4 GB per le release di HP-UX
precedenti alla 10.20, di 128 GB per HP-UX 10.20, o di 1TB per
HP-UX 11.x e successive.
97
Pianificazione di un gruppo di lavoro
Pianificazione della gestione dei file system
Cosa fornisce JFS per garantire buone prestazioni?
In generale, un file system JFS ha prestazioni migliori di un file system
HFS, in ragione del suo uso di grandi estensioni, uso dello spazio del file
system ottimizzato, grande lettura in anticipo e file contigui. Tuttavia, il
risultato naturale del file system è la frammentazione dei suoi blocchi.
HP OnLineJFS ha un efficiente mezzo di deframmentare lo spazio del file
system, per ripristinare le prestazioni del file system. È possibile
deframmentare un file system JFS usando SAM o direttamente dalla riga
di comando usando il comando fsadm.
È possibile realizzare due generi di directory di deframmentazione e
frammentazione di estensione.
Con quale frequenza occorre deframmentare (riorganizzare) un file system
JFS?
Per le prestazioni ottimali, l’allocatore delle estensioni della kernel deve
essere in grado di trovare grandi estensioni ogniqualvolta sia necessario.
Per conservere i livelli di prestazioni del file system, occorre eseguire la
utility fsadm periodicamente su tutti i file system J01FS, per ridurre la
frammentazione. La frequenza dipende dall’uso del file system, dagli
schemi di attività e dall’importanza delle prestazioni, per cui potrebbe
voler dire quotidianamente o mensilmente.
Tuttavia, per conservare le prestazioni ottimali su file system occupati,
occorre deframmentarli nottetempo.
Come si deframmenta un file system JFS?
•
Su un file system JFS Basic, occorre realizzare le stesse procedure
usate per il file system HFS. eseguire il backup del file system, quindi
ripristinarlo.
Per le procedure e la logistica di backup, consultare “Effettuazione del
backup dei dati” a pagina 684.
•
Se si ha il prodotto opzionale HP OnLineJFS, è possibile
deframmentare (riorganizzare) un file system JFS usando SAM o la
utility fsadm.
Per la procedura, consultare “Deframmentazione di un file system
JFS” a pagina 652.
98
Capitolo 2
Pianificazione di un gruppo di lavoro
Gestione degli utenti su sistemi multipli
Gestione degli utenti su sistemi multipli
Se i propri utenti si collegano regolarmente a più di un sistema, occorre
pensare sia alla sicurezza sia alla logistica. Potrebbero essere utili le
seguenti linee guida.
Linee guida
•
Conservare ID utente “globali” ed esclusivi sui sistemi.
Occorre essere sicuri che ogni nome di login abbia un numero di ID
utente esclusivo (uid) su tutti i sistemi ai quali l’utente si collega;
altrimenti, un utente potrebbe essere in grado di leggere i file privati
di un altro utente. Questo è un problema potenziale grave a
prescindere o meno dal fatto che la home directory sia montata su
NFS.
SAM (il System Administration Manager azionato da menu)
visualizzerà un avvertimento se si sceglie un uid non esclusivo sul
sistema locale, ma potrebbe non essere sufficiente. Ad esempio, se
l’utente jack ha un uid di 215 e gid (id di gruppo) di 20 sul proprio
sistema e lo si imposta con lo stesso uid e gid su un sistema remoto
(ad esempio usando taglia e incolla con la sua voce /etc/passwd dal
sistema locale a quello remoto) e l’utente jill sul sistema remoto ha
già uid 215 e gid 20, allora jack sarà in grado di leggere i file privati
di jill.
Di contro, si supponga di usare SAM per assicurarsi che jack abbia
un ID esclusivo su ogni sistema. SAM controlla che uid 215 sia
esclusivo sul sistema locale di jack e che 301 sia esclusivo sul sistema
di jill. Entrambi i sistemi hanno una directory denominata
/common_stuff montata NFS da un file server. Quando jack si
collega al sistema di jill, potrebbe scoprire di non poter leggere
alcuni dei propri file che si trovano in /common_stuff; in effetti, non
sarà in grado di leggere alcun file che ha salvato sul proprio sistema
con permessi utente di lettura e scrittura o di sola lettura.
Ciò accade perché HP-UX guarda essenzialmente i campi uid e gid
quando verifica chi abbia il permesso di fare quello che fa su un file; il
nome utente è irrilevante.
Capitolo 2
99
Pianificazione di un gruppo di lavoro
Gestione degli utenti su sistemi multipli
Alcuni siti hanno un servizio automatizzato che assegna uid esclusivi
in tutto il sito. Se il proprio sito offre un tale servizio, usarlo;
altrimenti, occorrerà inventarsi un metodo proprio per verificare che
l’uid che si assegna ad ogni nuovo login sia esclusivo su tutti i sistemi
ai quali avrà accesso l’utente.
•
La distribuzione delle directory della posta da un punto centrale
consente di impostare un hub della posta per il gruppo, semplificando
la manutenzione della posta.
Spesso, si tratta di una buona idea. Gli utenti avranno bisogno di
account, con i loro uid “globali”, sul server della posta, a prescindere
dal fatto che vi si colleghino o meno. Per ulteriori informazioni,
consultare “Topografie di networking” a pagina 274.
•
La distribuzione delle home directory dal file server semplifica il
backup e consente ad ogni utente di collegarsi a qualsiasi workstation
del gruppo di lavoro (consultare “Occorre condividere la home
directory e la directory della posta degli utenti?” a pagina 101).
Questa cosa potrebbe o meno essere desiderabile, a seconda di fattori
tipo il proprio budget hardware, il budget di manutenzione (se i
servizi di backup sono a pagamento), gli schemi d’uso e le politiche
sulla sicurezza del sito o del dipartimento.
Se si pianifica di centralizzare le home directory degli utenti in questo
modo, occorre assicurarsi che ogni utente abbia almeno un ambiente
personale minimo sul proprio disco locale, in modo che possano
collegarsi e svolgere almeno del lavoro anche se il file server è
inattivo.
Un modo per fare ciò è di creare prima la home directory dell’utente
sul disco locale, poi importare la home directory “reale” dal server.
Quando il server è attivo, sarà visibile soltanto la directory “reale”
(importata); quando il server è inattivo, la directory sul disco locale
diventerà visibile ancora una volta e l’utente sarà ancora in grado di
collegarsi.
100
Capitolo 2
Pianificazione di un gruppo di lavoro
Gestione degli utenti su sistemi multipli
Occorre condividere la home directory e la directory
della posta degli utenti?
Sebbene il paradigma V.4 li definisca come privati, esistono degli
argomenti per la condividere /home e /var/mail:
•
backup
Anche se si danno istruzioni ai propri utenti affinché non lascino dati
importanti nelle proprie home directory, o nelle proprie caselle della
posta, probabilmente lo faranno ugualmente, pertanto occorrerà
eseguire il backup di tali directory ogni giorno. È più semplice
eseguire il loro backup da una ubicazione centrale piuttosto che
singolarmente da ogni workstation.
•
configurazione e manutenzione della posta
Spesso è sensato configurare un sistema del gruppo di lavoro come
l’hub della posta del gruppo ed in tal caso alcuni utenti potrebbero
desiderare importare /var/mail in modo da poter eseguire il loro
programma di posta sui propri sistemi locali invece che collegarsi al
server della posta.
Se si usa un hub della posta, occorre assicurarsi che ogni utente
disponga di un account sull’hub della posta (a prescindere dal fatto
che si siano mai collegati ad esso o meno) e che il loro id utente (uid)
ed id di gruppo (gid) siano gli stessi sull’hub e sulla loro workstation
locale. Altrimenti, la posta non sarà instradata in modo corretto.
Per ulteriori dettagli, consultare “Topografie di networking” a
pagina 274.
•
condivisione di workstation
Se si esportano la directory della posta e la home directory degli utenti
su altre workstation del gruppo e si conservano le stesse voci per ogni
utente in ogni file /etc/passwd, allora tutti gli utenti saranno in
grado di collegarsi a tutte le workstation, il che è utile se gli utenti
arrivano ad ore diverse o in turni diversi e non si dispone di hardware
sufficiente per tutti loro, o se alcune workstation del gruppo hanno
hardware o software che si desidera far usare alle persone mediante
collegamento alla workstation in questione.
Lo svantaggio di centralizzare sia la directory della posta sia la home
directory è la dipendenza: se l’hub della posta si disattiva, nessuno sarà in
grado di leggere la propria posta; se il file server si disattiva, gli utenti non
saranno in grado di raggiungere le proprie home directory, il che significa
che non saranno in grado di collegarsi. Per ulteriori dettagli, consultare
“Gestione degli utenti su sistemi multipli” a pagina 99.
Capitolo 2
101
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Pianificazione della configurazione della
stampante
Questa sezione contiene informazioni concettuali su due approcci per la
gestione delle stampanti.
•
Spooler LP, il veicolo UNIX tradizionale per la gestione della stampa
(consultare “Spooler LP” a pagina 102).
•
HP Distributed Print Service (HPDPS), funzionalità che consente
l’amministrazione centralizzata delle risorse di stampa disperse
(consultare “HP Distributed Print Service (HPDPS)” a pagina 111)
(notare che HPDPS non è supportato sulle release successive ad
HP-UX 11i versione 1).
Per le procedure per configurare ed amministrare la configurazione della
stampante, consultare:
•
“Configurazione di stampanti per usare lo spooler LP” a pagina 440
•
“Configurazione delle stampanti per usare HPDPS” a pagina 451
•
“Amministrazione dello spooler LP” a pagina 714
•
“Amministrazione di HP Distributed Print Service (HPDPS)” a
pagina 723
Spooler LP
I seguenti sono link ai concetti di gestione della stampa sullo spooler LP:
102
•
“Panoramica dello spooler LP” a pagina 103
•
“Spooling remoto” a pagina 105
•
“File modello della stampante” a pagina 106
•
“Tipi di stampanti” a pagina 107
•
“Nome della stampante” a pagina 108
•
“Classe di stampanti” a pagina 108
•
“Destinazione della stampa” a pagina 109
•
“Priorità di stampanti e richieste di stampa” a pagina 109
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Panoramica dello spooler LP
Il Sistema di spooling della stampante in linea (spooler LP ) è un
set di programmi, script della shell e directory che controlla le stampanti
ed il flusso dei dati loro inviati.
NOTA
Usare lo spooler LP se il sistema ha più di un utente in ogni dato
momento. Altrimenti, gli elenchi inviati alla stampante mentre un altro
elenco è in stampa si mescoleranno ed in tal modo entrambi gli elenchi si
confonderanno.
Anche se si ha un sistema ad utente unico, si potrebbe desiderare voler
aggiungere la/e stampanti allo spooler LP in modo da poter accodare le
richieste di stampa. In tal modo, non occorrerà attendere il
completamento di una richiesta prima di inviarne un’altra.
Per comprendere lo spooler LP, occorre pensarlo come un impianto
idraulico, come illustrato nella Figura 2-2 a pagina 104. I dati da stampare
entrano nell’impianto come “acqua”. Le directory di richiesta (code di
stampa) servono da serbatoi di deposito temporanei per le richieste di
stampa fino a che non sono inviate ad una stampante per essere stampate.
La directory di richiesta e la stampante controllano il flusso delle richieste
di stampa.
•
i termini accettazione e rifiuto fanno riferimento al controllo del
flusso delle richieste di stampa alle directory di richiesta
•
i termini abilitazione e disabilitazione fanno riferimento al
controllo del flusso delle richieste di stampa alle stampanti
L’accettazione, il rifiuto, l’abilitazione e la disabilitazione delle richieste di
stampa controllano i dati attraverso lo spooler LP così come farebbero le
valvole con il flusso dell’acqua in un vero impianto idraulico.
Gli script di interfaccia (scritti come script della shell) vicino alla fine
del flusso dei dati servono da pompa che “pompa” un flusso di dati
ordinato alle stampanti.
Lo scheduler della stampante in linea (denominato lpsched) controlla
l’instradamento delle richieste di stampa alle stampanti. Funziona come
un controller di flusso automatizzato nell’impianto “idraulico”
instradando le richieste di stampa alle stampanti fisiche secondo il
principio del ‘first in, first out’ o della priorità. lpsched consente la stampa
dei file su una stampante specifica o una classe di stampanti. Evita il
mescolamento degli elenchi (cioè, il mescolamento delle pagine stampate
provenienti da diverse richieste di stampa). lpsched monitora anche le
Capitolo 2
103
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
priorità della stampante/lavori di stampa, regola lo stato della stampante
e registra le attività dello spooler LP.
Se lo “scarico di una stampante si ottura”, è possibile reindirizzare una
richiesta di stampa da quella stampante ad un’altra usando il comando
lpmove. I dati indesiderati possono essere “eliminati” dall’impianto di
esecuzione dello spooling con il comando cancel.
Figura 2-2
104
Schema dell’impianto idraulico dello spooler della stampante in
linea
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Spooling remoto È anche possibile inviare richieste di stampa ad una
stampante configurata su un sistema remoto, usando lo spooling
remoto. Quando si usa lo spooling remoto, uno script della shell
(“pompa”) invia i dati ad un sistema remoto attraverso il comando rlp.
Un programma di spooling remoto denominato rlpdaemon, in esecuzione
sul sistema remoto, riceve i dati e li dirige nello spooler LP del sistema
remoto. Il programma rlpdaemon esegue anche sul proprio sistema locale
per ricevere richieste dai sistemi remoti. Lo spooling remoto si realizza
mediante la comunicazione tra lo spooler locale e lo spooler remoto.
Se alcuni dei sistemi hanno stampanti configurate ed altre no, ma tutti i
sistemi sono collegati in rete da una LAN, è possibile far condividere ai
sistemi l’uso delle stampanti disponibili. Per fare ciò, configurare gli
spooler LP dei sistemi privi di stampanti per l’invio automatico dei lavori
di stampa attraverso la LAN allo spooler LP del sistema dotato di
stampante. Il programma rlpdaemon esegue nel background del sistema
della stampante, monitorando il traffico LAN entrante per tutte le
richieste di stampa provenienti da altri sistemi. Quando tali richieste
arrivano, il programma rlpdaemon le sottopone al suo spooler LP locale
per conto dell’utente remoto.
Oltre a gestire richieste di stampa remote, rlpdaemon gestisce richieste di
annullamento e di stato provenienti da sistemi remoti, usando script di
interfaccia speciali molto simili a script di interfaccia della stampante.
Quando si configura una stampante di spooling remoto,
•
Il file modello di annullamento (/usr/spool/lp/cmodel/rcmodel)
ed il file modello di stato (/usr/spool/lp/smodel/rsmodel) sono
copiati in directory di interfaccia (/usr/spool/lp/cinterface e
/usr/spool/lp/sinterface, rispettivamente)
•
E rinominati con il nome della stampante.
La configurazione di una stampante remota nel proprio spooler LP
richiede che si forniscano le seguenti informazioni aggiuntive oltre a ciò
che si fornisce per configurare una stampante locale.
Capitolo 2
•
nome del sistema che sta con la stampante
•
script di interfaccia da usare quando si emette una richiesta di
annullamento remota
•
script di interfaccia da usare quando si emette una richiesta di stato
remota
•
nome della stampante, così come definito nello spooler LP del sistema
remoto
105
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Per configurare l’esecuzione dello spool remoto, consultare “Aggiunta di
una stampante remota allo spooler LP” a pagina 443.
File modello della stampante
I file modello della stampante sono necessari nelle seguenti procedure:
•
“Aggiunta di una stampante locale allo spooler LP.” a pagina 441
•
“Aggiunta di una stampante remota allo spooler LP” a pagina 443
Quando si configura la stampante nello spooler LP, occorre identificare lo
scrip di interfaccia della stampante da usare. La directory
/usr/lib/lp/model elenca gli script di interfaccia della stampante dai
quali scegliere. Questa directory contiene i file corrispondenti ai modelli ed
ai nomi di tutte le stampanti e plotter HP (più alcuni file modello generici).
La Tabella 2-5, “File modello e stampanti e plotter corrispondenti” a
pagina 106 elenca i nomi dei file modello di base, i modelli aggiuntivi ai
quali essi sono collegati ed i codici prodotto HP che supportano.
Se si sta configurando una stampante non HP in HP-UX, leggere i file
modello ASCII per individuare le caratteristiche essenziali della
stampante, ad esempio se la propria stampante usa il Printer Command
Language (PCL) o PostScript. Per ulteriori informazioni sui livelli del
linguaggio PCL, consultare anche il manuale allegato alla stampante. Per
le stampanti di terzi che non sono stampanti PostScript, usare il modello
dumb; per i plotter non PostScript, usare dumbplot.
Il comando /usr/sbin/lpadmin copia lo script del modello individuato in
/etc/lp/interface/printername. Consultare lpadmin (1M) per avere
informazioni sulle opzioni del comando.
Tabella 2-5
File model
File modello e stampanti e plotter corrispondenti
Scopo previsto
HPGL1
Interfaccia LP per plotter HP7440A HP7475A; file identici: colorpro,
hp7440a, hp7475a
HPGL2
Interfaccia LP per plotter HP7550A, HP7596A, HP7570A; file identici:
hp7550a, hp7570a, hp7595a, hp7596a, draftpro
HPGL2.cent
Interfaccia LP per plotter HP7550Plus, HP7550B e plotter 7600 Serie
Electrostatic quando sono collegati mediante interfaccia parallella
PCL1
Interfaccia modello di livello 1 PCL, file identici: hp2225a, hp2225d,
hp2227a, hp2228a, hp2631g, hp3630a, paintjet, quietjet, thinkjet
106
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Tabella 2-5
File modello e stampanti e plotter corrispondenti (segue)
File model
Scopo previsto
PCL2
Interfaccia modello di livello 2 PCL, file identici: hp2300-1100L,
hp2300-840L, hp2560, hp2563a, hp2564b, hp2565a, hp2566b, hp2567b
PCL3
Interfaccia modello di livello 3 PCL, file identici: deskjet, deskjet500,
deskjet500C, deskjet550C, deskjet850C, deskjet855C, hp2235a,
hp2276a, hp2932a, hp2934a, ruggedwriter
PCL4
Interfaccia modello di livello 4 PCL, file identici: hp33447a, laserjet,
hp5000f100
hp33440a
File modello basato su PCL livello 4; file identici: hp2684a, hp2686a
PCL5
Interfaccia modello di livello 5 PCL, file identici: hp5000c30,
laserjetIIISi, laserjet4Si, laserjet4, laserjet4v, laserjet5Si,
colorlaserjet.
deskjet1200C
Interfaccia LP basata su PCL5; incluso supporto per commutazione lingua;
file identico: deskjet1200C (è lo stesso nome file del file modello),
paintjetXL300
hpC1208a
Interfaccia LP per HP C1208A, basato su PCL5
dumb
Interfaccia LP per stampante in linea dumb
dumbplot
Interfaccia LP per plotter dumb
hp256x.cent
Interfaccia LP per la famiglia di stampanti in linea HP 256x
postscript
Interfaccia LP per stampante PostScript, da usare su HP LaserJet IID, III,
stampanti con cartuccia HP 33439P LaserJet PostScript, così come
stampanti PostScript generiche. Supporta soltanto RS-232-C, interfacce
parallele.
rmodel
Interfaccia LP per stampanti remote.
Tipi di stampanti
Una stampante locale è fisicamente collegata al sistema. Per
configurare una stampante locale, consultare “Aggiunta di una stampante
locale allo spooler LP.” a pagina 441.
Una stampante remota potrebbe essere fisicamente collegata o
semplicemente configurata su un computer e si potrebbe accedere ad essa
in una rete attraverso rlp (1M). Per accedere alla stampante remota, il
Capitolo 2
107
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
sistema invia richieste attraverso la rete di area locale (LAN) all’altro
sistema. Per configurare una stampante remota nello spooler LP locale,
occore essere in grado di accedere al sistema remoto attraverso la LAN.
Per configurare una stampante remota, consultare “Aggiunta di una
stampante remota allo spooler LP” a pagina 443.
Una stampante su base di rete differisce da una stampante remota in
quanto essa è collegata direttamente alla LAN; non è collegata fisicamente
ad un sistema specifico. Le stampanti di rete non usano file speciali del
dispositivo, ma hanno il proprio indirizzo IP ed identificazione LANIC.
Consultare “Aggiunta di una stampante su base di rete” a pagina 446.
Nome della stampante
Quando si configura una stampante nello spooler LP, le si assegna un
nome della stampante, al quale si dirigono le richieste di stampa. Un
nome della stampante può contenere fino a 14 caratteri alfanumerici e
può includere degli underscore. I seguenti sono nomi della stampante
validi campione. laser1, letterhead, invoices, check_printer. I nomi
della stampante che si assegnano sono elencati nella directory
/usr/spool/lp/interface. Ogni file presente in quella directory è una
copia del file modello (script di interfaccia della stampante) che consente
di stampare sulla stampante denominata.
Classe di stampanti
È possibile fare un uso efficace di stampanti multiple raggruppandole
come se fossero logicamente un’unica stampante. Per fare ciò, si crea una
classe di stampanti. Una classe di stampanti è un nome collettivo per
un gruppo di stampanti. La classe di stampanti è conservata nella
directory /usr/spool/lp/class. Ad esempio, alle nostre stampanti
campione denominate laser1 e laser2 si potrebbe assegnare una classe di
stampanti denominata VIP, mentre alle stampanti denominate invoices e
check_printer si potrebbe assegnare una classe di stampanti denominata
Accounts. Una stampante può appartenere a più di una classe, tuttavia le
stampanti remote non possono appartenere ad una classe di stampanti.
Per usare una classe di stampanti, si dirigono le richieste di stampa ad
essa invece che ad una stampante specifica. Si esegue lo spooling della
richiesta di stampa su una coda di stampa singola e viene stampata dalla
prima stampante disponibile presente nella classe. Così, è possibile
bilanciare l’uso della stampante e ridurre al minimo l’affidamento su una
stampante particolare.
108
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Per creare una classe di stampanti, consultare “Creazione di una classe di
stampanti” a pagina 446. Consultare anche “Rimozione di una stampante
da una classe di stampanti” a pagina 449 e “Rimozione di una classe di
stampanti” a pagina 450.
Destinazione della stampa
La destinazione della stampa è la stampante o la classe di stampanti
in cui sarà accodato un file. Vari comandi per lo spooler LP richiedono che
si specifichi una destinazione della stampa. È possibile definire una
destinazione della stampa nello spooler LP sulla stampante di default
del sistema. In alternativa, è possibile assegnare ad ogni utente una
stampante di default impostando un ambiente di shell dell’utente
denominato LPDEST.
Priorità di stampanti e richieste di stampa
Ogni stampante ha due attributi di priorità:
•
priorità della richiesta
•
priorità della barriera
Di solito, le richieste di stampa sono gestite da una stampante nell’ordine
in cui vengono ricevute. Per default, le richieste di stampa hanno la
priorità della richiesta di default della stampante e sono FIFO
(first-in-first-out). Tuttavia, ai lavori di stampa è possibile assegnare
valori di priorità per aumentare o diminuire la loro priorità, usando
l’opzione -p del comando lp. I valori della priorità sono compresi
nell’intervallo da 0 a 7, dove il 7 rappresenta la priorità più alta. Per i
dettagli, consultare lp (1).
È possibile modificare una priorità della richiesta di stampa usando il
comando lpalt. È possibile impostare la priorità della richiesta di default
di una stampante usando il comando lpadmin (SAM consente di
impostare una priorità della richiesta di default diversa da zero quando si
aggiunge una stampante, ma non può modificare una priorità della
richiesta di default della stampante). Per i dettagli, consultare lpadmin
(1M) e lpalt (1).
Se vi sono richieste di stampa multiple in attesa di essere stampate su
una stampante specifica e tutte hanno priorità sufficientemente alte per
la stampa, la stampante stamperà la richiesta di stampa successiva con la
priorità più alta. Se più di una richiesta di stampa ha la stessa priorità, le
richieste di stampa con quella priorità saranno stampate nell’ordine in cui
sono state ricevute dallo spooler LP.
Capitolo 2
109
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Allo stesso modo, è possibile assegnare un valore della barriera di priorità
a ciascuna stampante per impostare una priorità minima che la richiesta
di stampa deve possedere per stampare su tale stampante. La priorità
della barriera di una stampante si usa per stabilire quali richieste di
stampa far stampare; vanno in stampa soltanto le richieste con priorità
uguali o maggiori alla priorità della barriera della stampante. Per i
dettagli, consultare lpadmin (1M) e lpfence (1M).
Registrazione della stampante
Ogni richiesta del sistema dello spooler LP viene registrata in un file di
log che si trova in /usr/spool/lp/log. Il file contiene un record di ogni
richiesta del sistema dello spooler LP, incluso l’ID della richiesta, il nome
utente, il nome della stampante, l’ora, i messaggi di errore e le ristampe
causate dai guasti.
Scalabilità e lo spooler LP
Il sistema dello spooler LP serve in modo abbastanza idoneo la gestione
della stampa di routine. Tuttavia, considerato l’aumento delle necessità
tecnologiche, il problema della scalabilità si è rivelato essere un ostacolo
per lo spooler LP.
Se si amministra un ambiente di stampa su larga scala, l’HP Distributed
Print Service (HPDPS) potrebbe essere un set di strumenti preferibile
(consultare “HP Distributed Print Service (HPDPS)” a pagina 111).
HPDPS (anche noto come DPS) consente agli utenti di usare i soliti
comandi dello spooler LP, ed al contempo offre una maggiore flessibilità
gestendo un ambiente di stampa complesso. Di contro, i comandi HPDPS
consentono una specificità delle richieste di stampa di gran lunga
maggiore.
110
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
HP Distributed Print Service (HPDPS)
HP Distributed Print Service (HPDPS, anche noto come DPS) può essere
usato con grandi benefici in ambienti di grandi dimensioni e distribuiti
organizzati secondo un modello client/server e che usano DCE. HPDPS
può essere configurato in un ambiente di base o esteso.
IMPORTANTE
HPDPS non è supportato sulle release successive ad HP-UX 11i
versione 1.
Quella che segue è una lista di link in questo modulo ai concetti di
gestione della stampa usando HPDPS:
•
“Cos’è HPDPS?” a pagina 112
•
“Perchè usare HPDPS?” a pagina 113
•
“Pianificazione per implementare HPDPS” a pagina 114
•
“Acquisire dimestichezza con gli oggetti HPDPS” a pagina 115
•
“Ambiente di base HPDPS campione” a pagina 116
•
“Ambiente esteso HPDPS campione” a pagina 117
•
“Determinazione dei set di file da installare e loro ubicazione di
installazione” a pagina 118
•
“Pianificare le configurazioni logiche e fisiche HPDPS” a pagina 115
•
“Progettare la configurazione fisica” a pagina 116
•
“Acquisire dimestichezza con le variabili di ambiente HPDPS” a
pagina 119
•
“Ambiente esteso DCE ed HPDPS” a pagina 120
•
“Pianificazione dei gruppi di personale” a pagina 120
Per le procedure per configurare ed amministrare HPDPS, consultare:
Capitolo 2
•
“Configurazione delle stampanti per usare HPDPS” a pagina 451
•
“Amministrazione di HP Distributed Print Service (HPDPS)” a
pagina 723
111
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Cos’è HPDPS?
L’HP Distributed Print Service (HPDPS) è un prodotto di
amministrazione e gestione della stampa che rappresenta un
avanzamento oltre il sistema dello spooler LP. HPDPS gestisce ambienti di
stampa su larga scala e distribuiti ad un livello impensabile usando il solo
spooler LP.
Sia lo spooler LP sia HPDPS possono coesistere nello stesso ambiente; la
compatibilità di codice consente di realizzare una migrazione graduale ad
HPDPS. Sebbene HPDPS sia gestito in modo diverso dallo spooler LP, gli
utenti finali possono continuare ad usare i comandi dello spooler LP con
qui hanno dimestichezza in un ambiente HPDPS.
HPDPS fornisce un set completo di
•
funzioni di stampa per l’utente finale per presentare e controllare i
lavori di stampa
•
funzioni di amministratore di sistema per controllare gli ambienti di
stampa distribuiti
Per usare le funzionalità complete di HPDPS, occorre usare HP9000
Distributed Computing Environment (DCE), un prodotto da acquistare a
parte. Se il proprio sistema host è configurato come cella DCE, è possibile
implementare l’ambiente esteso HPDPS, che presenta un’infrastruttura
client/server multipiattaforma, amministrazione a punto singolo,
autenticazione del client ed autorizzazione dell’oggetto.
HPDPS può essere anche configurato senza DCE. Usando l’HPDPS Basic
Environment, HPDPS fornisce ancora più funzionalità e scalabilità dello
spooler LP, ma alcune configurazioni devono essere gestite a livello locale,
invece che da un singolo punto di amministrazione.
In poche parole, HPDPS è composto da tre tipi di oggetti di gestione della
stampante:
client
Funzionalità, composta da daemon e comandi, che
consentono agli utenti di emettere richieste di stampa
ed agli amministratori di gestire l’ambiente di stampa.
spooler
Processo che controlla le stampanti logiche e le code.
supervisore
Processo che gestisce e controlla le stampanti fisiche.
A seconda dell’implementazione, questi oggetti possono essere configurati
su un unico sistema o distribuiti su vari sistemi di computer.
112
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
HPDPS usa anche una stampante gateway, una stampante logica simile
ad una “stampante remota” fornita dallo spooler LP. Una stampante
gateway consente di dirigere una richiesta di stampa tra l’ambiente di
base e l’ambiente esteso DCE e tra gli host compresi nell’ambiente di base.
Perchè usare HPDPS?
Usando HPDPS, l’amministratore può gestire i seguenti generi di
impostazioni da un’unica ubicazione:
•
Ambienti di stampa distribuiti, in cui le stampanti sono ubicate in
ubicazioni diverse in senso fisico su una LAN.
•
Ambienti su larga scala, in cui vi è un grande volume di stampa e
molte stampanti da gestire.
HPDPS fornisce le seguenti funzionalità:
•
Gestire l’intero sistema di stampa da qualsiasi client HPDPS della
rete. Se si usa HPDPS da un ambiente DCE, è possibile configurare e
monitorare il sistema di stampa della rete da qualsiasi client HPDPS
HP-UX della cella DCE. È possibile configurare e monitorare
stampanti, server e code. È possibile impostare i default per i lavori
che gli utenti inviano alle stampanti gestite da HPDPS.
•
Configurare le proprie risorse di stampa per bilanciare i carichi di
lavoro in modo efficace.
— Fornire accesso agli utenti con requisiti di lavori comuni alle
stampanti che supportano i loro lavori.
— Distribuire i carichi di lavoro della stampante instradando i lavori
ad una qualsiasi delle stampanti in grado di stampare i lavori.
— Usare diversi default di lavoro o documento per stampanti o
utenti specifici.
•
Coesistere con lo spooler LP.
— Gli utenti finali possono usare HPDPS senza dover apprendere un
nuovo set di comandi. È possibile usare il comando lp per
presentare i lavori alle stampanti gestite da HPDPS, senza alcuna
procedura di configurazione LP aggiuntiva.
— È possibile iniziare ad usare HPDPS dopo la configurazione
minima, poi espandere l’implementazione a seconda delle
necessità.
Capitolo 2
113
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
•
Ricevere notifiche in tempo reale dello stato del sistema di stampa.
È possibile configurare “profili di notifica” in modo che HPDPS
notifichi agli utenti dove viene stampato un lavoro, così come altri
eventi.
•
È possibile implementare molta della configurazione di HPDPS
usando SAM.
Pianificazione per implementare HPDPS
Se si decide di implementare HPDPS, dedicare un po’ di tempo alla lettura
dei primi cinque capitoli della HP Distributed Print Service
Administration Guide prima di procedere oltre. Questo offrirà una
comprensione totale del design, delle funzionalità e delle strategie usate
durante l’installazione, l’implementazione e l’amministrazione di
HPDPS.
Per le procedure, consultare “Implementazione di HPDPS” a pagina 452 o
la guida in linea in SAM.
Valutare le capacità del sistema Prima di configurare HPDPS,
valutare le capacità di spazio del sistema, tenendo presente quanto segue:
•
•
•
Tabella 2-6
spazio su disco
spazio di scambio
spazio di paginazione
Requisiti del disco per l’installazione di HPDPS
Componenti
114
Spazio su disco
richiesto
Tutto (client, supervisore e spooler)
17 MB
Solo client
9 MB
Client e spooler
13 MB
Client e supervisore
13 MB
Server (spooler e supervisore)
13 MB
Solo spooler
12 MB
Solo supervisore
12 MB
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Nel Capitolo 2 si forniscono ulteriori tabelle e formule per calcolare i
requisiti di memoria e spazio su disco, “Installing HPDPS,” della
HP Distributed Print Service Administration Guide.
Compatibilità delle release di sistema HP-UX 10.20 deve essere
installato su ogni sistema HP-UX che contenga un client o server HPDPS
(spooler o supervisore).
Pianificare le configurazioni logiche e fisiche HPDPS
Acquisire
Prima di poter progettare il proprio ambiente di stampa gestito da
dimestichezza con HPDPS, acquisire dimestichezza con i componenti intercorrelati di
gli oggetti HPDPS HPDPS. Leggere le seguenti sezioni nel Capitolo 1, “Introducing
HP Distributed Print Service” della HP Distributed Print Service
Administration Guide:
•
“HPDPS Architecture” definisce la terminologia di base HPDPS ed
illustra gli oggetti nelle loro relazioni reciproche.
•
“How HPDPS Processes Jobs” spiega come i componenti HPDPS
lavorano insieme.
Inoltre, “Planning your Logical Configuration” nel Capitolo 3 enumera
considerazioni concernenti gli oggetti di base HPDPS.
Prendere in
considerazione i
propri utenti
Capitolo 2
Per farsi un’idea di come si desidera che il sistema HPDPS gestisca le
stampanti, chiedersi quali siano le necessità dei propri utenti.
•
Quali modelli si osservano tra gli utenti nel modo in cui essi accedono
alle stampanti? Stampano di continuo durante la giornata o a più
riprese? Stampano da moduli o su carta da lettera? Si passa tanto
tempo in attesa delle stampe in determinate ore del giorno o da
determinate stampanti ma non da altre?
•
È possibile raggruppare i propri utenti a seconda delle loro necessità?
•
Di che tipo di default necessita ogni gruppo di utenti?
•
Come deve essere distribuito il flusso delle richieste di stampa alle
stampanti?
115
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Per formulare un piano di come applicare gli oggetti HPDPS alle necessità
degli utenti, esaminare le seguenti sezioni della HP Distributed Print
Service Administration Guide:
•
The Minimum HPDPS Configuration, nel Capitolo Uno.
•
Configuring HPDPS to Meet the Needs of Your Users, nel Capitolo
Uno. Questa sezione presenta una varietà di disposizioni degli oggetti
HPDPS.
•
Selecting Logical Configuration Models, nel Capitolo Tre. Questa
sezione valuta i vantaggi e gli svantaggi di varie configurazioni degli
oggetti HPDPS.
Progettare la
configurazione
fisica
Stabilire quanti client, spooler e supervisori installare.
Figura 2-3
Ambiente di base HPDPS campione
Ad esempio, è possibile configurare un ambiente di base, che avrà tutti gli
oggetti installati su un sistema host unico. Occorrerà configurare un
client, uno spooler ed un supervisore.
Nella Figura 2-3 a pagina 116, fancy è un sistema host unico, sul quale
sono installati il client, lo spooler ed il supervisore HPDPS. Collegata a
fancy, vi è una stampante configurata a livello locale. Tuttavia, potrebbe
essere possibile configurare qualsiasi altra stampante accessibile
attraverso la LAN perché sia usata e gestita da HPDPS. Inoltre, è
possibile rendere disponibili a livello locale attraverso le stampanti
gateway qualsiasi stampante gestita da DPS su un altro sistema di base
o esteso.
116
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Una configurazione HPDS campione con un ambiente esteso potrebbe
avere uno o più client, uno o più spooler ed uno o più supervisori,
distribuiti tra vari sistemi host.
Figura 2-4
Ambiente esteso HPDPS campione
Nella Figura 2-4 a pagina 117, fancy, tango e kenya sono sistemi
computer host, sui quali sono configurati oggetti HPDPS distribuiti in un
ambiente esteso. Si potrebbe gestire l’intero ambiente (usando SAM) da
qualsiasi sistema su cui sia configurato un client. In tal modo, fancy e
tango potrebbero essere usati per gestire tutti gli oggetti HPDPS, incluso
quelli configurati su kenya. Connessa a kenya vi è una stampante
configurata a livello locale, che necessita di un supervisore HPDPS ivi
residente. Gli utenti di fancy e kenya potrebbero inviare richieste di
stampa HPDPS a qualsiasi stampante HPDPS, perché i client sono
configurati sui loro sistemi. L’utente collegato a tango potrebbe non poter
presentare richieste di stampa HPDPS, anche se lo spooler HPPDS è
configurato lì. Tuttavia, usando lo spooler lp, l’utente di tango potrebbe
inviare richieste di stampa a qualsiasi stampante configurata di HPDPS.
Lo spooler lp è in grado di gestire le richieste di stampa ed inoltrarle alle
stampanti HPDPS.
Per ulteriori informazioni, leggere la sezione, “Planning your Physical
Configuration, nel Capitolo Tre della HP Distributed Print Service
Administration Guide.
Capitolo 2
117
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Determinazione dei set di file da installare e loro ubicazione di
installazione Il software HPDPS è in bundle con il CDE Run-Time
Environment (o con Instant Ignition sotto il Run-Time Environment) nel
prodotto DistributedPrint.
È possibile installare l’intero prodotto o set di file selezionati, a seconda
del ruolo svolto dal sistema nell’ambiente di stampa distribuito.
Questi sono i set di file:
PD-CLIENT
Obbligatorio. Selezionare questo set di file
per usare i comandi HPDPS. Occorre
anche avere questo set di file se si
pianifica la gestione dell’ambiente di
stampa con SAM.
PD-SPOOLER
Selezionare questo set di file per eseguire
uno spooler HPDPS sul sistema.
PD-SUPERVISOR
Selezionare questo set di file per eseguire
un supervisore HPDPS sul sistema.
PD-COMMON
Set di file della dipendenza backend usato
da tutti i componenti.
PD-SERVCOMMON
Set di file della dipendenza backend usato
dal codice spooler e supervisore.
Quando si usa swinstall per selezionare i set di file HPDPS per client,
spooler e/o supervisore, saranno fatti entrare automaticamente il/i set di
file della dipendenza backend idonea.
Si useranno queste informazioni in “Implementazione di HPDPS” a
pagina 452.
118
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Acquisire
dimestichezza con
le variabili di
ambiente HPDPS
La Tabella 2-7 a pagina 119 illustra i valori impostati in
/etc/rc.config.d/pd. Una volta che la configurazione di HPDPS sia
stabile, si potrebbe voler modificare questo file per impostare i valori, in
modo che all’avvio di HP-UX, esso attivi automaticamente la
configurazione.
Tabella 2-7
Valori memorizzati nel file /etc/rc.config.d/pd
Valore
NOTA
Capitolo 2
Definizione
PD_ENV
Definisce l’ambiente HPDPS. Impostato su base per
default; impostato su esteso per eseguire come ambiente
esteso HPDPS.
PDPRNPATH
Definisce i percorsi in cui HPDPS trova i file modello
della stampante (per informazioni sui contenuti di una
directory di file modello, consultare la HP Distributed
Print Service Administration Guide).
PD_CLIENT
Specifica se il sistema host avvia un daemon client.
Impostato per default su PD_CLIENT=0, il che significa
che l’host non avvia un client (impostare PD_CLIENT=1
per avviare un daemon client automaticamente durante
il riavvio).
PD_SPOOLERS
Definisce i nomi dello spooler per avviare ed eseguire su
questo host. Nessuno spooler si avvia per default; per
avviare gli spooler, seguire le istruzioni fornite nel file.
PD_SUPERVISORS
Definisce i nomi del supervisore per avviare ed eseguire
su questo host. Nessun supervisore si avvia per default;
per avviare i supervisori, seguire le istruzioni fornite nel
file
PD_MEMLIMIT
Definisce la quantità massima di memoria (in kilobyte)
che lo spooler o il supervisore possono usare sul sistema
host.
Per ulteriori informazioni su questi valori, consultare la sezione,
“Automatically Starting HPDPS,” nel Capitolo 4, “Getting Started with
HPDPS”. Per acquisire dimestichezza con i valori da impostare, è
possibile leggere /etc/rc.config.d/pd.
119
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Ambiente esteso
DCE ed HPDPS
Se si intende trarre un vantaggio più completo dalla funzionalità di
HPDPS e configurare un ambiente esteso HPDPS, occorre anche
installare i set di file DCE. Da notare che i set di file DCE necessari ad
eseguire un ambiente esteso HPDPS non sono quelli forniti in bundle con
i set di file di nucleo di HP-UX. Fanno parte di un prodotto HP opzionale.
•
Per implementare l’ambiente di base HPDPS, caricare i servizi di
nucleo DCE di default 10.x forniti in bundle con HP-UX per la
funzionalità di ambiente di elaborazione distribuita.
•
Per implementare l’ambiente esteso HPDPS, caricare i server DCE,
un prodotto da acquistare a parte.
Le istruzioni dettagliate per l’installazione dei componenti HPDPS che
usano swinstall si trovano nel Capitolo 2, “Installing HP Distributed
Print Service,” della HP Distributed Print Service Administration Guide.
I puntatori sulla documentazione DCE si trovano nello stesso capitolo.
Pianificazione dei gruppi di personale (disponibile soltanto per
l’ambiente esteso HPDPS DCE).
Se si installa l’ambiente esteso HPDPS, è possibile organizzare o delegare
la gestione per gruppi, il che potrebbe includere:
•
•
•
•
Gruppi utente
Gruppo operatori stampante
Gruppo operatori sistema
Gruppo amministratori
È anche possibile rendere più rigida la sicurezza e configurare protocolli
di notifica.
Tutti questi argomenti sono trattati nel Capitolo Tre, “Planning Your
HPDPS Configuration,” della HP Distributed Print Service
Administration Guide.
120
Capitolo 2
Pianificazione di un gruppo di lavoro
Pianificazione della configurazione della stampante
Per ulteriori informazioni sulle procedure correlate
alla stampante
Per informazioni aggiuntive, consultare i seguenti manuali:
Capitolo 2
•
Configuring HP-UX for Peripherals — per la configurazione di HP-UX
prima di installare i dispositivi periferici.
•
HP JetDirect Network Interface Configuration Guide — per
configurare le stampanti di rete sull’interfaccia di rete HP JetDirect.
•
SharedPrint/UX User and Administrator’s Guide for HP-UX 10.0 —
per usare l’interfaccia utente grafica SharedPrint.
•
HP Distributed Print Service User’s Guide e HP Distributed Print
Service Administration Guide — per usare ed amministrare
l’HP Distributed Print Service (HPDPS).
121
Pianificazione di un gruppo di lavoro
Distribuzione dei backup
Distribuzione dei backup
In una configurazione di gruppo di lavoro, dove sono coinvolti grandi
numeri di sistemi, è spesso più efficace centralizzare l’amministrazione
del backup. In tal modo, è possibile controllare il processo di backup ed
assicurarsi che i dati importanti per la propria organizzazione siano
sempre salvati in backup.
Uso di HP OpenView OmniBack II per l’esecuzione
del backup
Se si sta eseguendo il backup di grandi numeri di sistemi, il prodotto
software HP OmniBack può risultare particolarmente utile.
HP OmniBack è più veloce di altri metodi per eseguire il backup. Inoltre,
è in grado di fare quanto segue:
•
centralizzare l’amministrazione del backup
•
consentire l’esecuzione del backup di grandi numeri di sistemi senza
la necessità di dover sorvegliare l’operazione
•
creare un database delle informazioni sul backup
•
consentire la personalizzazione di parti diverse dell’organizzazione
Usare HP OmniBack II implica la configurazione di un server database e
l’esecuzione del software HP OmniBack II che dirige e registra il processo
di backup per i client.
La seguente illustrazione mostra un server che esegue il software
OmniBack II che amministra il processo di backup. Il server invia in rete
istruzioni di backup su personalizzate singolarmente ai client specificati.
I client quindi inviano i dati dei quali occorre eseguire il backup ad un
supporto di memorizzazione, tipo unità nastro DDS o DLT, che può essere
collegato direttamente al server o ad uno o più di uno fra i client. I client
poi restituiscono una registrazione del backup al server in modo che il
processo di backup possa essere esaminato e monitorato. Per una
descrizione dettagliata, consultare la HP OpenView OmniBack II
Administrator’s Guide.
Per ulteriori informazioni sui vari metodi diversi di esecuzione del
backup, consultare “Effettuazione del backup dei dati” a pagina 684.
122
Capitolo 2
Pianificazione di un gruppo di lavoro
Distribuzione dei backup
Figura 2-5
Capitolo 2
Distribuzione dei backup con HP OmniBack II
123
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Servizi per scambio dati con Personal
Computer
La tecnologia attuale offre molti modi per condividere i dati tra sistemi
HP-UX e personal computer (PC). Fra di essi, vi sono:
•
“Strumenti di trasferimento file” a pagina 124
•
“Emulatori del terminale” a pagina 125
•
“Versioni di sistemi operativi simili a UNIX” a pagina 126
•
“Versioni del sistema X Window per PC” a pagina 127
•
“Versioni dei sistemi PC Windows per sistemi HP-UX” a pagina 128
•
“Montaggi NFS” a pagina 128
•
“Sistemi operativi di rete” a pagina 129 che consente ai PC di accedere
alle risorse HP-UX
•
“Posta elettronica” a pagina 129
Strumenti di trasferimento file
Esistono molti protocolli di scambio dati diversi, la maggior parte
sviluppati per l’ambiente del personal computer. Due che sono supportati
da HP-UX sono:
•
ftp
•
Kermit
Nel modo dei personal computer, ftp di solito si trova come utility
indipendente. Kermit fa di solito parte di un pacchetto di emulazione
terminale, ma esistono versioni indipendenti di kermit per i personal
computer.
ftp
In origine era una utility UNIX, ftp si trova ora in versioni di workstation
Windows NT di Microsoft e sistemi operativi di server Windows NT.
È anche possibile reperire versioni di terzi, pubblico dominio e shareware
del software ftp.
124
Capitolo 2
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Poiché ftp è supportato da HP-UX ed è disponibile su molti sistemi
operativi basati su PC, è uno strumento ideale da usare per il
trasferimento dati tra sistemi HP-UX ed i personal computer.
Sui sistemi HP-UX, è possibile trovare la utility ftp nel file eseguibile:
/usr/bin/ftp.
ATTENZIONE
Quando si usa ftp, ogni carattere digitato, incluso quelli che
rappresentano le password per gli account sui sistemi remoti, viaggia in
rete decodificato. Si tratta di un problema di sicurezza importante, dal
momento che è possibile che qualcuno “ascolti” il traffico della rete e si
appropri delle password. Per tale motivo, è meglio usare il login
“anonimo” quando ci si collega ai sistemi remoti attraverso ftp.
Per i dettagli sulle modalità di trasferimento dei file usando ftp,
consultare “Configurazione dei sistemi HP-UX per il trasferimento file” a
pagina 424.
Kermit
Kermit è una famiglia di programmi software di trasferimento file,
gestione e comunicazione proveniente dalla Columbia University
disponibile per la maggior parte dei computer e dei sistemi operativi.
Come ftp, è possibile usare kermit per trasferire file (sia ASCII sia binari)
tra sistemi HP-UX e personal computer.
HP-UX include una versione indipendente di kermit: /usr/bin/kermit.
Emulatori del terminale
Gli emulatori del terminale consentono di collegarsi ad un computer da un
altro. Esiste un’ampia varietà di emulatori del terminale che eseguono su
personal computer. È possibile usarli per collegarsi ai sistemi HP-UX sia
attraverso un modem sia, in alcuni casi, attraverso le connessioni di rete.
HP-UX include l’emulatore del terminale noto come telnet che può
essere usato per collegare personal computer basati in rete, a patto che i
PC stiano eseguendo un’applicazione del server telnet.
Molti emulatori del terminale offrono funzionalità di trasferimento file
incorporate o plugin; molti offrono registrazione della sessione al disco
locale che è un altro modo per condividere i dati tra i PC ed i sistemi
HP-UX.
Capitolo 2
125
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Fra gli esempi di emulatori del terminale, vi sono:
•
telnet - può essere usato per collegarsi ai PC (occorre che il PC
esegua un’applicazione del server telnet) e può essere usato sui PC (in
modo client) per collegarsi ai sistemi HP-UX.
•
Hyperterminal (si trova in diverse versioni dei sistemi operativi
Microsoft) – può essere usato sui PC per collegarsi ai sistemi HP-UX
attraverso un modem.
telnet
telnet, in origine era una utility UNIX, ora si trova in versioni di
workstation Windows NT di Microsoft e sistemi operativi di server
Windows NT.
Può essere usato per collegarsi ad un sistema HP-UX da un personal
computer. Può essere usato per collegarsi ad un personal computer da un
sistema HP-UX. Sia in un caso sia nell’altro, il computer che inizia la
connessione deve eseguire un’applicazione client telnet ed il computer
che riceve la connessione deve eseguire un’applicazione server telnet.
Sui sistemi HP-UX l’applicazione server telnet è nota come il daemon
telnetd.
Per i dettagli sulle modalità di trasferimento dei file usando telnet,
consultare “Configurazione dei sistemi HP-UX per l’emulazione del
terminale” a pagina 421.
Versioni di sistemi operativi simili a UNIX
Sebbene non sia difficile scambiare dati tra HP-UX ed i personal
computer che eseguono un sistema operativo Microsoft o un sistema
operativo Apple Macintosh, il fatto stesso che i computer eseguono sistemi
operativi diversi tende a limitare il numero di modi in cui scambiare dati
tra di essi. Quei sistemi operativi non sono stati progettati per essere
molto simili a UNIX, e pertanto la loro compatibilità con i sistemi
operativi su base UNIX tipo HP-UX è minima.
Tuttavia, esistono dei sistemi operativi disponibili per i personal
computer progettati specificamente per essere molto simili a UNIX: in
particolare, un sistema operativo denominato LINUX. Tali sistemi
operativi, per design, hanno molto in comune con UNIX e le opzioni per la
condivisione dei dati tra questi sistemi operativi simili a UNIX ed HP-UX
sono probabilmente molto numerose.
126
Capitolo 2
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Versioni del sistema X Window per PC
Eseguire applicazioni su un computer remoto e visualizzare i risultati
sullo schermo del proprio computer è facile tanto quanto usare un
emulatore del terminale (consultare “Emulatori del terminale” a
pagina 125) se si lavora soltanto con del testo. Ma, cosa accade se occorre
eseguire un programma che usa un’interfaccia grafica (GUI)?
Tra le workstation UNIX che supportano il sistema X Window, la
soluzione può essere così facile da richiedere la semplice impostazione
della variabile di ambiente DISPLAY (sul computer remoto) ed
assicurarsi che il computer remoto disponga del permesso di visualizzare
le cose sullo schermo. E, se il personal computer esegue un sistema
operativo che supporta il sistema X Window (ad esempio, LINUX), la
soluzione è la stessa.
I sistemi operativi Windows NT non includono la versione nativa di un
server X Window, ma molti rivenditori commercializzano server X Window
per PC. Con un server X Window che esegue sul proprio personal computer,
è possibile eseguire applicazioni con GUI sui sistemi HP-UX ed avere il
risultato visualizzato sullo schermo del proprio personal computer.
Sebbene questa non sia una lista completa1, le seguenti società / prodotti
supportano display X Window sui personal computer che eseguono
sistemi operativi Windows NT:
Tabella 2-8
Prodotti che supportano la visualizzazione X Window nei PC
Nome del prodotto
Società
Digital PATHWORKS 32
Digital Equipment Corporation
eXeed
Hummingbird Communications, Inc.
PC_Xware
Network Computing Devices
Chameleon
Net Manage
eXodus
White Pine Software
Reflection/X
WRQ
1. Questa lista fornisce soltanto un punto di partenza per la ricerca di
prodotti che realizzano queste funzioni. Hewlett-Packard Company
non consiglia ma neanche scoraggia l’uso di tale lista.
Capitolo 2
127
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Versioni dei sistemi PC Windows per sistemi HP-UX
Eseguire applicazioni su un computer remoto e visualizzare i risultati
sullo schermo del proprio computer è facile tanto quanto usare un
emulatore del terminale (consultare “Emulatori del terminale” a
pagina 125) se si lavora soltanto con del testo. Ma, cosa accade se occorre
eseguire un programma su base PC che usa un’interfaccia grafica utente
(GUI) e si desidera visualizzare l’interfaccia di tale programma sul
display X Window?
Sebbene questa non sia una lista completa1, le seguenti società / prodotti
supportano display PC Windows sui sistemi operativi HP-UX che
eseguono server X Window:
Tabella 2-9
Prodotti che supportano la visualizzazione nei PC Windows in
HP-UX
Nome del prodotto
Società
NTRIGUE
Insignia Solutions
WinCenter
Network Computing Devices
WinDD
Tektronix, Inc.
Montaggi NFS
I montaggi NFS sono possibili tra personal computer e sistemi HP-UX. Di
solito, un file system su base HP-UX è montato come lettera di un’unità in
un sistema operativo basato su PC Windows.
Perché il sistema HP-UX possa servire le richieste provenienti dai
personal computer, occorre che il daemon NFS del PC esegua su tale
sistema
Per ulteriori dettagli su NFS ed il suo uso sui sistemi HP-UX, consultare
“Condivisione di file ed applicazioni attraverso NFS e ftp” a pagina 402 e
“CIFS/9000” a pagina 408.
1. Questa lista fornisce soltanto un punto di partenza per la ricerca di
prodotti che realizzano queste funzioni. Hewlett-Packard Company
non consiglia ma neanche scoraggia l’uso di tale lista.
128
Capitolo 2
Pianificazione di un gruppo di lavoro
Servizi per scambio dati con Personal Computer
Sistemi operativi di rete
I sistemi operativi di rete come NetWare di Novell, AppleShare di Apple
Computer, Inc., o LAN Manager di Microsoft rappresentano un altro modo
ancora di condividere dati tra sistemi HP-UX e personal computer.
Con un sistema operativo di rete (NOS), una parte dell’albero delle
directory HP-UX viene allocato per essere usato dai client PC. I client PC
di un sistema operativo di rete non possono accedere ai file HP-UX fuori
dalla parte di albero delle directory HP-UX allocata sul NOS.
Sebbene ciascuno possa fare in modo diverso, ogni NOS è responsabile
della gestione delle differenze tra i permessi di accesso del sistema
operativo HP-UX per ogni file o directory ed i permessi di accesso del
personal computer per gli stessi file e directory.
Posta elettronica
È anche possibile scambiare dati tra un personal computer ed un sistema
HP-UX mediante posta elettronica. La maggior parte dei programmi di
posta elettronica sono ora in grado di gestire dati binari tipo grafici,
animazioni e file sonori attraverso un sistema noto come MIME (che sta
per Multimedia Internet Mail Exchange); pertanto, è possibile includerli
in un messaggio di posta elettronica quando si invia il messaggio tra
HP-UX ed un personal computer.
Capitolo 2
129
Pianificazione di un gruppo di lavoro
Possibili problemi nello scambio di dati tra HP-UX e PC
Possibili problemi nello scambio di dati tra
HP-UX e PC
A prescindere dalla modalità di condivisione dei dati tra sistemi HP-UX e
PC, vi sono varie cose importanti da prendere in considerazione correlate
all’architettura del sistema operativo e del computer:
•
Differenze della modalità di gestione dei PC, dei computer Apple
Macintosh e dei sistemi HP-UX della condizione di fine riga nei file di
testo ASCII.
•
Architettura di computer “Big Endian” o “Little Endian”.
Problemi di fine riga ASCII
Ogni volta che si scambiano dati tra sistemi operativi Microsoft, sistemi
operativi Apple Macintosh e sistemi HP-UX, si potrebbe incorrere in
problemi correlati ai vari modi in cui ognuno di tali sistemi stabilisce la
condizione di fine riga (EOL) nei file di testo ASCII.
La seguente tabella illustra quali caratteri usa ogni sistema operativo per
stabilire la fine delle righe in un file di testo ASCII.
Tabella 2-10
Caratteri di fine riga del sistema operativo
Sistema operativo
Stabilisce la fine riga con:
HP-UX
carattere avanzamento di una
interlinea (LF)
OS Macintosh
carattere ritorno carrello (CR)
Sistemi operativi su base
Microsoft (DOS,
WINDOWS 95, NT, eccetera)
carattere ritorno carrello seguito
immediatamente da un carattere di
avanzamento di una interlinea (CR)
(LF)
Molte utility di trasferimento file traducono automaticamente il carattere
di fine riga, ma è possibile che si incorra in uno o più dei seguenti
problemi:
130
Capitolo 2
Pianificazione di un gruppo di lavoro
Possibili problemi nello scambio di dati tra HP-UX e PC
•
Righe con caratteri (^M) attaccati quando si modifica un file in
HP-UX originato su un sistema operativo su base Microsoft.
•
Avanzamento di una interlinea senza ritorni di carrello (il testo
continua sul lato destro dello schermo).
•
Ritorni di carrello senza avanzamento di una interlinea (ogni riga del
testo sovrascrive la riga precedente). Tutte le righe del file sono
stampate sulla stessa riga dello schermo.
Se si vede uno dei sintomi sopra descritti, la soluzione è di modificare il
file corrotto usando un editor o un elaboratore di testo e cambiare i
caratteri di fine riga nel file ASCII in ciò che si aspetta il proprio sistema
operativo (consultare la Tabella 2-1, “Rete di esempio di Gestione di
sistemi e gruppi di lavoro” a pagina 63).
Il problema della differenza Endian
Sebbene sia meno probabile imbattersi in questo problema piuttosto che
in quello del carattere di fine riga, e sebbene molte utility e programmi
siano scritti per rendere conto automaticamente delle differenze nei tipi
endian delle varie macchine, si potrebbero incontrare dei file che
sembrano essere corrotti su un’architettura e che tuttavia hanno un
aspetto regolare su un’altra. Questa cosa si verificherà con più probabilità
quando si condivide un file system tra computer di architetture endian
diverse (come quando di usano montaggi NFS o sistemi operativi di rete
come il NetWare
di Novell).
Cos’è Endian?
Il termine “endian” si riferisce all’ordine in cui sono numerati i byte di una
parola del computer. Quando determinate applicazioni scrivono i dati su
un file, registrano i byte della parola in ordine numerico. Sebbene quasi
tutti i computer visualizzino una parola di memoria come se avesse il bit
più significativo nella posizione all’estrema sinistra ed il bit meno
significativo nella posizione all’estrema destra, le architetture dei
computer variano nel numerare i byte di una parola da sinistra a destra,
o da destra a sinistra.
Capitolo 2
131
Pianificazione di un gruppo di lavoro
Possibili problemi nello scambio di dati tra HP-UX e PC
Archietetture Big
Endian
Le architetture che numerano i byte di una parola da sinistra a destra
(con il byte 0 che rappresenta gli otto bit dell’estrema sinistra della
parola) si chiamano architetture “big endian”. I computer Apple
Macintosh e molti computer PA-RISC di Hewlett-Packard sono degli
esempi di macchine big endian.
NOTA
I computer PA-RISC più recenti possono essere sia macchine big endian
sia little endian, tuttavia il sistema operativo HP-UX è un sistema
operativo big endian.
Figura 2-6
Esempio a 32 bit di architettura Big Endian
Architetture Little
Endian
Le architetture che numerano i byte di una parola da destra a sinistra
(con il byte 0 che rappresenta gli otto bit dell’estrema destra della parola)
si chiamano architetture “little endian”. I computer su base Intel x86 e
Pentium sono esempi di macchine little endian.
Figura 2-7
Esempio a 32 bit di architettura Little Endian
132
Capitolo 2
Pianificazione di un gruppo di lavoro
Protocolli Internet ed IPv6
Protocolli Internet ed IPv6
Internet Protocol versione 6 (IPv6) è una nuova generazione del Protocollo
Internet che sta iniziando ad essere adottata dalla comunità di Internet.
IPv6 viene anche definito "IPng" (IP di prossima generazione). Esso
fornisce l’infrastruttura per la successiva ondata di dispositivi Internet,
come i PDA, i telefoni cellulari e gli elettrodomestici. Fornisce anche
connettività aumentata per i dispositivi esistenti cone i computer laptop.
La differenza più evidente tra la versione normalmente usata oggi di IP
(IP versione 4) ed IPv6 è il maggior spazio di indirizzo supportato da IPv6.
IPv6 supporta indirizzi Internet a 128 bit, in confronto all’indirizzo
Internet a 32 bit supportato da IP versione 4. Inoltre, IPv6 offre una
maggior semplicità di configurazione e gestibilità così come una maggiore
sicurezza.
Ad iniziare con HP-UX 11i versione 2, il software IPv6 è installato sul
server. Una volta che la/e interfacce IPv4 ed IPv6 siano state configurate,
il server viene considerato un’implementazione “dual stack” IPv6/IPv4.
Ciò comporta che IPv4 e IPv6 eseguono entrambi in modo parallelo ed
indipendente. Il server può comunicare sia con il nodo IPv4 sia con il nodo
IPv6 e può identificare i pacchetti provenienti da altri server e client come
IPv4 o IPv6.
Informazioni su IPv6
Per ulteriori informazioni, consultare i seguenti documenti, disponibili
alla pagina http://docs.hp.com.
•
•
Capitolo 2
HP-UX 11i IPv6 Transport Administrator’s Guide
HP-UX IPv6 Porting Guide
133
Pianificazione di un gruppo di lavoro
Protocolli Internet ed IPv6
134
Capitolo 2
Configurazione di un sistema
3
Configurazione di un sistema
Questa sezione descrive come configurare un sistema ad utente unico o un
sistema multiutente. Si discute dei seguenti argomenti:
•
“Avvio di un sistema precaricato” a pagina 136
•
“Uso del desktop CDE” a pagina 137
•
“Uso di System Administration Manager (SAM)” a pagina 138
•
“Utilizzo di Distributed Systems Administration Utilities” a
pagina 142
•
“Controllo dell’accesso ad un sistema” a pagina 244
•
“Aggiunta di periferiche” a pagina 254
•
“Configurazione delle manpage in linea” a pagina 265
•
“Realizzazione delle regolazioni” a pagina 267
•
“Configurazione dei servizi di posta” a pagina 272
•
“Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)” a
pagina 284
•
“Riconfigurazione della kernel (HP-UX 11i versione 2)” a pagina 319
Consultare anche:
•
Capitolo 3
Capitolo 8, “Amministrazione di un sistema: Gestione della sicurezza
del sistema” a pagina 753
135
Configurazione di un sistema
Avvio di un sistema precaricato
Avvio di un sistema precaricato
Gli amministratori di sistema possono usare queste istruzioni come
riferimento rapido oppure stamparle per gli utenti che si apprestano ad
avviare i propri sistemi.
IMPORTANTE
Punto
La sicurezza del sistema è una parte importante della configurazione di
quest’ultimo. HP-UX fornisce un’ampia varietà di funzionalità di
sicurezza, incluso controllo di base del file e dell’accesso, configurazione
dei Sistemi sicuri, rilevamento antiintrusione con HP-UX HIDS e blocco
del sistema con Bastille. Usare il Capitolo 8, “Amministrazione di un
sistema: Gestione della sicurezza del sistema” a pagina 753 per sviluppare
un piano di sicurezza che soddisfi le proprie necessità. Tale piano può
essere installato e configurato come parte della seguente procedura.
1. Accendere il monitor ed il sistema computer.
Il sistema eseguirà una serie di verifiche automatiche. Per informazioni
su tali verifiche automatiche, consultare la propria Guida utente.
Dopo un paio di minuti, compare una serie di messaggi di pari passo con
l’attivazione dei vari sottosistemi hardware e software. A meno di
problemi, non sarà richiesto di rispondere a tali messaggi.
Punto
2. Inserire le informazioni, se richieste.
Occorrerà conoscere il proprio nome host ed indirizzo IP.
L’amministratore di rete può fornire il nome host e l’indirizzo IP.
Premere Invio per usare i valori di default. Per fornire le informazioni
mancanti in un secondo momento, collegarsi ad un terminale come
superutente ed eseguire il comando:
/sbin/set_parms
Comparirà una lista di opzioni. Inserire nuovamente il comando con
un’opzione idonea.
/sbin/set_parms opzione
Punto
3. Specificare una password di root.
Il nome utente del superutente è root.
136
Capitolo 3
Configurazione di un sistema
Uso del desktop CDE
La workstation porta a termine la sua sequenza di avvio e visualizza la
schermata di login del desktop.
Punto
4. Eseguire il login al desktop come root per la prima sessione. Consultare
“Uso del desktop CDE” a pagina 137.
Punto
5. Impostare e configurare sicurezza aggiuntiva, come suggerito nella nota
precedente “Importante”. Consultare il Capitolo 8, “Amministrazione di
un sistema: Gestione della sicurezza del sistema” a pagina 753.
Punto
6. Aggiungere utenti a seconda delle necessità. Consultare “Aggiunta di
utente ad un sistema” a pagina 244.
Punto
7. Configurare NFS se lo si desidera. Consultare “Condivisione di file ed
applicazioni attraverso NFS e ftp” a pagina 402.
Riferimenti HP
Per informazioni dettagliate sull’installazione e l’aggiornamento,
consultare
•
Guida di installazione ed aggiornamento di HP-UX 11i versione 2
•
HP-UX 11i versione 1.6 - Guida di installazione e configurazione
•
HP-UX 11i Version 1.5 Installation and Configuration Guide
•
Guida di installazione ed aggiornamento di HP-UX 11i versione 1
•
HP-UX 11.0 Installation and Update Guide
•
Installing HP-UX 11.0 and Updating HP-UX 10.x to 11.0
•
Installing and Updating HP-UX 10.x
Uso del desktop CDE
Dopo aver installato HP-UX, il Login Manager del desktop visualizza una
schermata di login. La schermata di login CDE è etichettata CDE.
Quando si esegue un desktop particolare, è il desktop eseguito da tutti gli
utenti del sistema. Consultare la HP CDE 2.1 Guida introduttiva.
Se compare un prompt di login della console, allora CDE non è in
esecuzione sul sistema.
Capitolo 3
137
Configurazione di un sistema
Uso di System Administration Manager (SAM)
Uso di System Administration Manager (SAM)
NOTA
In HP-UX 11i versione 2, è stata modificata l’implementazione di un certo
numero di funzioni di System Administration Manager (SAM), sebbene
SAM continui a fornire un’interfaccia. Per i dettagli, consultare
“Interfaccia SAM su base X Window” a pagina 32.
Il System Administration Manager (SAM) è uno strumento HP-UX che
fornisce un’interfaccia utente di facile utilizzo per la realizzazione della
configurazione e di altre procedure essenziali. SAM fornisce un aiuto
nell’amministrazione di:
•
Revisione e sicurezza
•
Backup e ripristino
•
Configurazione del cluster
•
Dischi e file system
•
Configurazione della kernel
•
Networking e comunicazioni
•
Dispositivi periferici
•
Stampanti e plotter
•
Gestione dei processi
•
Procedure di routine
•
SAM sui sistemi remoti
•
Gestione del software SD-UX (procedure selezionate attraverso il
menu “Software Management”)
•
Ora
•
Account utente e di gruppo
•
Aggiunta e sostituzione in linea di schede PCI (OLA/R)
•
Partition Manager
Usare SAM per ulteriori informazioni o chiarimenti su una data
procedura.
138
Capitolo 3
Configurazione di un sistema
Uso di System Administration Manager (SAM)
Uso dei comandi di SAM rispetto a quelli di HP-UX
L’uso di SAM riduce la complessità di molte procedure di amministrazione.
SAM riduce al minimo o elimina la necessità di avere una conoscenza
dettagliata di molti comandi di amministrazione, risparmiando in tal
modo tempo prezioso. Usare SAM ogni volta che sia possibile,
specialmente quando si apprende ad usare una procedura per la prima
volta. Alcune procedure descritte in questo manuale non possono essere
realizzate da SAM, in tal caso occorrerà usare i comandi di HP-UX.
Tuttavia, SAM è lo strumento preferito per la maggior parte del lavoro di
amministrazione.
Ciò è particolarmente importante quando si realizzano eventuali
procedure di aggiunta e sostituzione in linea (OLA/R). Quando si
realizzano queste procedure dall’interfaccia della riga di comando usando
il comando /usr/bin/rad, viene fornita la protezione minima contro la
disabilitazione dei driver del dispositivo e lo spegnimento degli slot della
scheda. D’altro canto, SAM offre un’Analisi delle risorse critica che
fornisce feedback ed avvertimenti continui nel corso del processo.
NOTA
In HP-UX 11i v2, il controllo e la funzionalità di OLA/R è stata
implementata con il comando /usr/bin/olrad, che realizza le stesse
verifiche di quelle realizzate da SAM nelle release precedenti.
Avvio di SAM
Assicurarsi che SAM sia installato sul sistema. Per eseguire SAM, occorre
essere in possesso del permesso di superutente. Consultare anche
“Concessione agli utenti dell’accesso limitato a SAM” a pagina 140. Nel
caso in cui SAM non sia stato installato in origine ed ora si desideri usarlo,
consultare il Manuale di amministrazione di Software Distributor per
aggiungere SAM alla configurazione. Prima di avviare SAM, assicurarsi
che la variabile di ambiente LANG sia impostata su C. Per i dettagli,
consultare sam (1M).
Per avviare SAM, inserire
/usr/sbin/sam
Per un supporto sull’uso di SAM, selezionare il pulsante Help.
Capitolo 3
139
Configurazione di un sistema
Uso di System Administration Manager (SAM)
Uso di SAM con un sistema X Window
Per usare SAM con un sistema X Window, occorre che il set di file X11-RUN
sia installato e che la variabile di ambiente DISPLAY sia impostata in
modo da rispecchiare il display sul quale si desidera che SAM compaia (la
variabile DISPLAY di solito sarà impostata, a meno che non sia stato usato
rlogin per collegarsi ad un sistema remoto). Per visualizzare le
impostazioni attuali delle variabili di ambiente, inserire
env | more
La variabile di ambiente DISPLAY di solito si imposta nel file.profile per
le shell Korn e POSIX e nel file .login per la shell C come segue:
export DISPLAY=nome_host:0.0 (shell Korn e POSIX)
setenv DISPLAY nome_host:0 (Shell C)
dove nome_host è il nome restituito dal comando /usr/bin/hostname.
Uso di SAM con un terminale di testo
Un terminale di testo è una combinazione di display video/tastiera per la
quale SAM ha un’interfaccia speciale. Invece di usare un mouse per
navigare nelle schermate di SAM, usare la tastiera per controllare le
azioni di SAM.
Per usare SAM con un terminale di testo, occorre che non sia impostata la
variabile di ambiente DISPLAY.
Uso di SAM per l’amministrazione di sistemi remoti
Usare SAM per amministrare sistemi remoti multipli da un’unica
ubicazione. Per aggiungere o rimuovere sistemi remoti, selezionare la
voce di menu “Run SAM on Remote Systems”.
Concessione agli utenti dell’accesso limitato a SAM
Come amministratore di sistema, è possibile dare accesso di superutente
limitato ai non superutenti inserendo:
sam -r
Ciò attiva il Restricted SAM Builder, che consente di abilitare o
disabilitare aree scelte di SAM per gli utenti.
140
Capitolo 3
Configurazione di un sistema
Uso di System Administration Manager (SAM)
Per ogni accesso limitato dato all’utente, SAM crea un file
/etc/sam/custom/nome_login.cf che definisce i privilegi di SAM
dell’utente. SAM usa questo file per dare accesso agli utenti alle aree
indicate.
Quando gli utenti eseguono SAM, avranno stato di superutente nelle aree
definite e vedranno soltanto quelle aree di SAM nel menu. Le aree che non
richiedono stato di superutente (come SD) compariranno anche ed
eseguiranno usando l’ID utente. Tutte le altre aree di SAM saranno
nascoste dall’utente. Quando i non superutenti privi di accesso speciale a
SAM tenteranno di eseguire SAM, riceveranno un messaggio che li
informa che occorre essere superutenti per eseguire SAM.
Quando si eseguono versioni limitate di SAM, non vi sono tasti di uscita
della shell sui terminali ed il menu della lista è disabilitato. Ciò impedisce
agli utenti di ottenere accesso di superutente alle aree limitate di SAM.
È anche possibile aggiungere proprie applicazioni a SAM e configurarle
per l’accesso limitato.
Visualizzazione delle informazioni sul dispositivo in
SAM
Per visualizzare le informazioni sul dispositivo, SAM richiama ioscan in
background. Tuttavia, se un comando ioscan è già in esecuzione quando
SAM richiama ioscan, può sembrare che SAM si blocchi perché è in
attesa del primo comando ioscan per finire la scrittura delle sue
informazioni. SAM non è bloccato; con i sistemi dotati di molti dispositivi,
ioscan può impiegare molto tempo a completare le sue operazioni.
Inoltre, se si avvia un altro comando ioscan dopo che SAM richiama
ioscan, SAM potrebbe non mostrare tutte le informazioni sul dispositivo.
Per risolvere questo problema, aggiornare semplicemente i dati di SAM
(sotto il menu Options) dopo che tutti i processi di ioscan sono stati
completati. Per verificare i processi di ioscan, usare il seguente comando
ps:
ps -ef | grep ioscan
Capitolo 3
141
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Utilizzo di Distributed Systems
Administration Utilities
È possibile utilizzare gli strumenti Distributed Systems Administration
Utilities – DSAU – per inviare file e comandi verso sistemi designati del
proprio cluster o della rete. Gli strumenti DSAU offrono:
•
Configuration synchronization
•
Consolidated logging
•
Command fanout
Con la sincronizzazione della configurazione, si può avere la sicurezza che
i sistemi del proprio cluster o della rete siano conformi allo standard
scelto. Come saranno effettuate delle modifiche al master di
configurazione, queste saranno trasmesse in tutti i sistemi client.
Con la registrazione eventi consolidata, è possibile esaminare un singolo
file di log contenente le voci di tutti i sistemi nella propria configurazione,
ordinate secondo data ed ora, in modo da reperire facilmente una data
voce.
Con la distribuzione dei comandi, da un sistema designato è possibile
inviare il medesimo comando verso tutti gli altri sistemi nella propria
configurazione. In questo modo sarà eliminata l’esigenza di esaminare
tutti i sistemi nella configurazione e di molte operazioni manuali.
Introduzione a Configuration Synchronization
Per gli amministratori di sistema, gestire la configurazione di un gruppo
di sistemi distribuiti e le sue variazioni è una sfida costante. Sono
disponibili molti strumenti di ausilio per la gestione dei vari aspetti delle
configurazioni multisistema. Ad esempio, per la gestione degli account, le
soluzioni standard comprendono Network Information System (NIS) e
Lightweight Directory Access Protocol (LDAP). Per la sincronizzazione a
livello di file, sono disponibili strumenti come rdist ( vedere la manpage
rdist (1)) e rsync. System Insight Manager di HP serve a rilevare,
controllare e gestire gruppi di sistemi.
Novità di questo gruppo di strumenti è Configuration Engine (cfengine).
cfengine è un diffuso strumento open source per la sincronizzazione
della configurazione. Consente la gestione della configurazione basata su
142
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
criteri o su obiettivi, che permettono all’amministratore di definire le
azioni d’amministrazione da applicare a gruppi di sistemi, in modo che
essi raggiungano la condizione desiderata.
Lo strumento cfengine è su base client/server. Un sistema centrale
master di configurazione, o server dei criteri, ospita il file dei criteri di
configurazione, che definisce le operazioni di gestione da eseguire in ogni
client amministrato. Il master di configurazione ospita inoltre i file delle
“immagini golden”, le copie di riferimento dei file da distribuire nei client.
L’amministratore può utilizzare cfengine per eseguire operazioni come:
•
Accertarsi che i sistemi client stiano utilizzando un insieme corretto
di file di configurazione, tramite la copia dei file o delle directory di
riferimento.
•
Disattivare nel client i file configurati in modo inadeguato.
•
Controllare le autorizzazioni dei file, della proprietà, e verificare le
variazioni del valore checksum.
•
Modificare i file.
•
Eseguire in ogni client i comandi della shell specificati.
•
Controllare i processi ed i loro segnali.
•
Controllare il montaggio di determinati filesystem.
Per aiutare l’amministratore a configurare rapidamente cfengine per la
gestione di un gruppo di sistemi distribuiti, oppure per configurarlo come
servizio ad alta disponibilità di un cluster Serviceguard, è disponibile una
procedura guidata di sincronizzazione della configurazione
(csync_wizard).
Panoramica di cfengine
L’amministratore per prima cosa definisce un sistema centrale, oppure un
cluster Serviceguard, in modo che agisca da server master di
configurazione o da server dei criteri. Configuration Synchronization
Wizard (csync_wizard) è un front-end di uso intuitivo per la procedura
iniziale di configurazione. Questo sistema centrale ospiterà il file
principale dei criteri – ad esempio cfagent.conf – che definisce i criteri
di configurazione desiderati, ed anche le copie di riferimento, o copie
principali, dei file che dovranno essere distribuiti nei client amministrati.
Capitolo 3
143
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Ogni client amministrato copia i file principali dei criteri dal server
centrale di configurazione e valuta la propria condizione corrente rispetto
a quella definita nel file dei criteri. Qualsiasi differenza provocherà
l’applicazione delle regole di configurazione, in modo da sincronizzare il
client.
L’amministratore può avviare le operazioni di sincronizzazione nei client
amministrati in due modi, con un’operazione attiva oppure con una
passiva.
•
Utilizzando il comando cfrun (per ulteriori informazioni vedere la
manpage cfrun (1)) dal server master di configurazione,
l’amministratore potrà forzare – “spingere” – le modifiche. cfrun
legge il file cfrun.hosts per stabilire un elenco di client
amministrati. Quindi esegue il comando cfagent in ogni client
amministrato per eseguire la sincronizzazione. Le operazioni attive
sono in realtà una richiesta ai client amministrati di eseguire
immediatamente un’operazione passiva.
•
Le operazioni passive – di “traino” – sono eseguite utilizzando cron
oppure l’analogo daemon cfexecd di cfengine. Entrambe le tecniche
eseguono ad intervalli prefissati il comando cfagent, in modo da
eseguire la sincronizzazione della configurazione avviata dal client.
L’amministratore definisce quale intervallo è idoneo per ogni gruppo
di client amministrati. Ad esempio, ogni cinque minuti, ogni ora,
oppure una volta al giorno. L’amministratore può inoltre eseguire
direttamente cfagent per eseguire una sincronizzazione a richiesta.
Comandi e daemon di cfengine Per eseguire le operazioni di
sincronizzazione della configurazione, cfengine utilizza vari daemon e
comandi. L’elenco seguente descrive i componenti principali di cfengine.
•
cfagent – il comando cfagent è l’agente principale di cfengine. È
eseguito in ogni client amministrato, e si avvia da sé utilizzando il file
update.conf, che descrive il gruppo di file da trasferire dal server
master al client amministrato locale. I file trasferiti comprendono
quello principale dei criteri, cfagent.conf, e qualsiasi file dei criteri
correlato. Nell’implementazione DSAU, cfagent.conf importa il file
cf.main, che contiene esempi di molte funzionalità di cfengine.
Dopo il trasferimento dei file di configurazione, cfagent valuta le
istruzioni di configurazione in essi contenute. Nel caso che la
configurazione corrente del sistema client si discosti da quella
desiderata, cfagent eseguirà le azioni definite per riportare il client
nella condizione idonea.
144
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
cfservd – il daemon cfservd ha due ruoli:
— cfservd è eseguito nel server master di configurazione ed è il
punto di smistamento per le richieste di trasferimento file
provenienti dai client amministrati. Nei client, cfagent contatta
cfservd nel server master e richiede le copie dei file principali dei
criteri e le copie di qualsiasi file di riferimento che sia necessario
per le operazioni di sincronizzazione della configurazione. Il
comando cfservd principale è responsabile dell’autenticazione
dei client remoti, tramite un meccanismo di scambio di chiavi
pubblica/privata, e dell’eventuale crittografia dei file trasferiti
verso i client amministrati.
— cfservd è facoltativamente in grado di essere eseguito in ogni
client amministrato, per elaborare le richieste di cfrun. Il comando cfrun consente all’amministratore di imporre le modifiche
ai client amministrati, invece che attendere che essi si sincronizzino nell’intervallo di tempo definito nel client. Il comando cfrun
deve essere eseguito dal server master di configurazione. Esso
contatta ogni client amministrato elencato nel file cfrun.hosts e
si connette a cfservd del client amministrato, richiedendo a
cfagent di eseguire l’operazione di sincronizzazione.
cfservd è configurato con cfservd.conf ed avviato con
/sbin/init.d/cfservd.
•
cfexecd – cfexecd è uno strumento di pianificazione e di
segnalazione. Nel caso l’amministratore utilizzi cron per eseguire la
sincronizzazione ad intervalli prefissati, cfexecd è il comando situato
nel file crontab per il wrapping dell’esecuzione di cfagent.
Memorizza l’output dell’esecuzione di cfagent nella relativa
directory – per i dettagli, vedere cfagent.conf – ed invia
facoltativamente dei messaggi email.
cfexecd ha delle proprie funzionalità analoghe a quelle di cron,
basate sulle classi temporali di cfengine. L’amministratore può
scegliere di eseguire cfexecd in modalità daemon e di utilizzarlo per
eseguire cfagent ad intervalli prefissati al posto di cron.
L’impostazione predefinita è di eseguire cfagent ogni ora. Dopo avere
iniziato ad usare cfengine, risulterà più facile che utilizzare cron.
•
Capitolo 3
cfrun – il comando cfrun contatta i client amministrati richiedendo
loro di eseguire immediatamente la sincronizzazione. In particolare,
si connette al comando opzionale cfservd in ogni client
amministrato, che a sua volta esegue cfagent.
145
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
La Figura 3-1, “Panoramica di cfengine” mostra le relazioni tra i comandi
ed i daemon di cfengine, con un esempio dell’uso di cfrun da parte
dell’amministratore. Le linee tratteggiate nel diagramma indicano le
sequenze di chiamata (ad esempio, A chiama B). Le linee continue
indicano la lettura dei dati dai file di configurazione.
Figura 3-1
Panoramica di cfengine
1. L’amministratore ha eseguito l’accesso nel server master di
sincronizzazione della configurazione ed effettua una modifica da
distribuire ai client amministrati, utilizzando il comando cfrun.
2. cfrun controlla il file cfrun.hosts per l’elenco dei client
amministrati. Il server master può essere client di se stesso. In questo
diagramma, ci sono due client, il server master ed un client remoto.
3. cfrun contatta cfservd in ogni client amministrato, che a sua volta
esegue cfagent.
4. cfagent per prima cosa controlla il server master per una copia
aggiornata del file update.conf e, se necessario, lo trasferisce nel
client.
146
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Nel caso che il server master sia un sistema indipendente, per impostazione predefinita la copia principale di update.conf si troverà in
/var/opt/dsau/cfengine_master/inputs/. Le copie principali
degli altri file di configurazione, come cfagent.conf, cfservd.conf
e cfrun.hosts, si troveranno anch’esse qui. Nel caso che il server
master sia un cluster Serviceguard, i file di configurazione principali
si troveranno nel punto di montaggio associato al pacchetto. Ad esempio, se il nome di questo punto di montaggio è csync, il percorso sarà
/csync/dsau/cfengine_master/inputs.
5. Durante la copia dei file di configurazione nel sistema locale, cfagent
li collocherà in /var/opt/dsau/cfengine/inputs sia per i sistemi
indipendenti sia per i cluster. Per prima cosa, cfagent esaminerà il
contenuto di update.conf, per aggiornare – se necessario – il file
binario di cfengine eventualmente modificato, ed ottiene la più
recente versione de file dei criteri – cfagent.conf – e dei file relativi.
cfagent esaminerà quindi cfagent.conf per accertare se il client si
trova nella condizione desiderata. In caso di differenze, cfagent
eseguirà le azioni definite per correggere la configurazione del client.
Modelli di attuazione del server master di cfengine
Il server master di cfengine può essere un sistema HP-UX indipendente
che serve dei gruppi di client distribuiti. I client stessi possono essere dei
sistemi indipendenti, oppure membri di un cluster Serviceguard. Nel caso
si stia già utilizzando un server di amministrazione centrale Systems
Insight Manager, si ha a disposizione un sistema ideale da utilizzare come
server master di cfengine. I server principali possono anche agire da
client, e le operazioni di sincronizzazione possono essere eseguite in questi
sistemi così come nei client remoti.
Nel caso si gestisca dei cluster Serviceguard, sarà possibile utilizzare
cfengine esclusivamente per la sincronizzazione dei membri all’interno di
un singolo cluster. In questa configurazione, cfservd è configurato come
pacchetto per l’alta disponibilità, ma gli unici client di cfengine sono i
membri stessi del cluster. Il nome DNS o indirizzo IP del pacchetto è
quello del server master di cfengine.
Oltre a fornire la sincronizzazione della configurazione come servizio
interno al cluster, un’altra configurazione di Serviceguard è quella in cui
il cluster fornisce la sincronizzazione della configurazione ad alta
disponibilità per gruppi di sistemi client remoti. Questi client possono
Capitolo 3
147
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
essere sistemi indipendenti oppure cluster Serviceguard. Il cluster che
fornisce il servizio cfengine può essere un client di se stesso e sfruttare le
funzionalità di sincronizzazione della configurazione di cfengine.
Una configurazione possibile anche se inconsueta è di avere un membro
fisso di un cluster Serviceguard che agisca come server master ma senza
che sia configurato alcun pacchetto, in modo che cfservd non sia ad alta
disponibilità. Questa configurazione è valida ma non è consigliata.
Configurazione di cfengine
Le sezioni seguenti forniscono le istruzioni dettagliate per impostare un
server master di sincronizzazione della configurazione e dei suoi client. Il
modo più rapido per iniziare è utilizzare la procedura Configuration
Synchronization Wizard (csync_wizard), descritta oltre. È anche
descritta la configurazione completamente manuale.
Uso di Configuration Synchronization Wizard
La procedura csync_wizard (vedere csync_wizard (1)) automatizza le
operazioni di impostazione di un server master di sincronizzazione della
configurazione e dei suoi client amministrati. Supporta l’impostazione di
un sistema indipendente oppure di un cluster Serviceguard come server
master. La procedura guidata configura tutti i client amministrati in
modo da eseguire cfservd, per consentire l’utilizzo di cfrun (vedere cfrun
(8)) nel server master.
Per i dettagli, vedere oltre le relative sezioni.
Uso della procedura guidata per la configurazione di un server di
sincronizzazione indipendente Per configurare un server di
sincronizzazione per un sistema indipendente, eseguire csync_wizard(1)
nel sistema indipendente che si desidera configurare come server master
di sincronizzazione:
# /opt/dsau/sbin/csync_wizard
La procedura guidata mostrerà la seguente schermata introduttiva:
Querying the system <nome host locale> for current status, one moment...
This Configuration Synchronization Wizard helps you set up the Configuration Engine
(cfengine) environment. Cfengine is a powerful tool for performing policy-based
management for groups of systems and cluster environments.
It is a client/server based utility. A standalone system or Serviceguard cluster can be
148
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
configured as the cfengine ‘master’. The master contains the configuration description
and configuration files that will be used by all the clients. Clients copy the
configuration description from the master and apply it to themselves. The configuration
description supports a rich set of management actions such as copying configuration
files from the master to the client, performing edits to files, checking file ownerships,
permissions, and checksums, executing shell commands, checking for processes, etc.
For a detailed description of the cfengine management actions, please refer to cfengine
man page.
This wizard will help you set up this system as a cfengine master or to add or remove
a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue...
Premere INVIO per proseguire e scegliere la voce 1 nel menu in basso per
configurare un server master:
Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(9) Exit
Enter choice: 1
The cfengine master server is being configured on:
<nome host locale>
La procedura guidata chiederà quindi se si desidera anche configurare i
client amministrati subito dopo avere configurato il server. In questo
esempio, la risposta è no. I client amministrati saranno aggiunti in
seguito.
You can optionally specify additional remote clients to manage at this time. If you are
running in an HA environment, you do not need to specify the cluster members.
Would you like to manage clients? [N]: n
La procedura guidata procederà nella configurazione del sistema come
server master:
******* WARNING!!!! ******** To protect against possible corruption of sensitive
configuration files, control-c has been disabled for the remainder of this
configuration.
Configuration of the cfengine master server is starting.
Verifying the master has an entry in the /etc/hosts file on each client...
Capitolo 3
149
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines. This may take a few
minutes....
Terminata la configurazione, la procedura guidata presenterà la seguente
schermata di riepilogo, che indirizzerà l’amministratore al file principale
dei criteri, /var/opt/dsau/cfengine_master/inputs/cf.main, ed al
file delle risposte registrate per questa esecuzione della procedura
guidata.
The Configuration Synchronization Wizard has completed the configuration of cfengine:
- The master configuration description template is here:
</var/opt/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration synchronization actions
performed in cfengine. For example, synchronizing critical files such as /etc/hosts,
package scripts, etc.
All the actions in the template are disabled by default (commented out). Uncomment the
lines corresponding to the desired synchronization actions for this configuration. See
the cfengine reference documentation for a description of additional cfengine features:
/opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host: <nome host locale>
and members:
Quando si configura un server master ma non si aggiungono dei client
amministrati durante l’operazione, i membri – l’elenco dei client
amministrati – non saranno presenti, come mostrato nell’esempio in alto.
A file recording the answers for this run of the Configuration Synchronization Wizard
is stored here...
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
150
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Uso della procedura guidata per la configurazione di un cluster
Serviceguard come server di sincronizzazione Per configurare un
server di sincronizzazione in un cluster Serviceguard, sono possibili due
scelte:
•
Creare un pacchetto Serviceguard per il servizio di configurazione in
modo da garantire l’alta disponibilità.
•
Configurazione di un singolo membro del cluster come se fosse un
sistema indipendente. Il servizio di sincronizzazione della
configurazione non sarà ad alta disponibilità, ed inoltre questa
configurazione non funzionerà correttamente con le funzionalità
d’automazione di Serviceguard trattate nella sezione “Funzionalità
d’automazione di Serviceguard” e non è quindi consigliata.
Questa sezione tratta l’uso della procedura guidata per impostare un
servizio di sincronizzazione della configurazione ad alta disponibilità.
NOTA
Accertarsi che il valore di MAX_CONFIGURED_PACKAGES del cluster
sia in grado di accogliere il pacchetto aggiuntivo. Per ulteriori
informazioni su questa impostazione, consultare il manuale Managing
Serviceguard, che fa parte della documentazione di Serviceguard. Inoltre,
prima di eseguire la procedura guidata, tutti i membri correnti del cluster
devono essere operativi.
Iniziare eseguendo Configuration Synchronization Wizard,
csync_wizard(1):
# /opt/dsau/sbin/csync_wizard
Querying the system <nome host locale> for current status, one moment...
This Configuration Synchronization Wizard helps you set up the Configuration Engine
(cfengine) environment. Cfengine is a powerful tool for performing policy-based
management for groups of systems and cluster environments.
It is a client/server based utility. A standalone system or Serviceguard cluster can be
configured as the cfengine ‘master’. The master contains the configuration description
and configuration files that will be used by all the clients. Clients copy the
configuration description from the master and apply it to themselves. The
configuration description supports a rich set of management actions such as copying
configuration files from the master to the client, performing edits to files, checking
file ownerships, permissions, and checksums, executing shell commands, checking for
processes, etc.
For a detailed description of the cfengine management actions, please refer to cfengine
man page.
Capitolo 3
151
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
This wizard will help you set up this system as a cfengine master or to add or remove
a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue...
Premere INVIO per proseguire e scegliere la voce 1 nel menu in basso per
configurare un server master:
Configuration Synchronization Wizard Menu
=========================================
(1)
(2)
(3)
(4)
(9)
Set up a cfengine master server
Add a client
Remove a client
Key management for cfengine users
Exit
Enter choice: 1
Dopo avere scelto 1 ed avere premuto INVIO, la procedura guidata
mostrerà il testo seguente:
This system is a member of a Serviceguard cluster. The cfengine configuration will be
defined as a package for high availability unless you answer no to the below question.
If you answer no, for the purposes of cfengine control, this machine will be treated as
a single machine without failover capability for cfengine.
If you accept the default answer of ‘HA’ to the below question, cfengine will be
configured as a highly available Serviceguard package. This will ensure that your
cfengine master server is available as long as one of the cluster members that can run
the package is also available.
You will need a free IP address for this package and you need to configure storage for
the package before proceeding. For details on creating highly available file systems,
please refer to ‘Creating a Storage Infrastructure’ chapters of the Managing
Serviceguard documentation.
Will this master server be Highly Available (HA) [Y]:
La procedura guidata proporrà “csync” come nome del pacchetto per la
sincronizzazione della configurazione. Questo specifico nome del
pacchetto è obbligatorio. Prima di proseguire o iniziare la procedura
guidata, deve essere impostata la configurazione d’archiviazione LVM e
della rete per il pacchetto. Tutti i membri del cluster devono essere in
funzione e disponibili. Per i dettagli, consultare il volume Managing
Serviceguard, in “Building an HA Cluster Configuration”, “Creating a
Storage Infrastructure with LVM.”
152
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
NOTA
La procedura guidata supporta solamente la creazione di pacchetti basati
sui gruppi di volumi LVM. Utilizzando CFS o VxVM, sarà necessaria la
configurazione manuale. Per i dettagli sulla configurazione manuale del
pacchetto csync, vedere la sezione sulla configurazione manuale di un
cluster Serviceguard.
La procedura guidata farà le seguenti richieste, le quali dovrebbero essere
tutte già configurate:
•
Nome del gruppo di volumi LVM (ad esempio, vgcsync)
•
Volume logico nel gruppo di volumi (ad esempio,
/dev/vgcsync/lvol1)
•
Il punto di montaggio del filesystem (ad esempio, /csync)
•
Le opzioni di montaggio del filesystem (ad esempio, -o
rw,largefiles). Le opzioni di montaggio sono utilizzate alla lettera
nel campo FS_MOUNT_OPT[0] dello script di controllo del pacchetto
Service. Le opzioni di montaggio devono essere coerenti con il
filesystem creato nel volume logico. Ad esempio, se il filesystem è
stato creato con il supporto per i file di grande dimensione, per il
punto di montaggio deve essere specificata l’opzione “largefiles”.
•
Il tipo di filesystem (ad esempio, VxFS)
•
L’indirizzo IP del pacchetto. Questo dovrebbe anche essere un nome
DNS registrato, in modo che la sincronizzazione della configurazione
sia di facile impostazione nei sistemi client.
•
La sottorete del pacchetto. Per accertare la sottorete, utilizzare
netstat -i.
Configurata l’infrastruttura d’archiviazione ed ottenuto l’indirizzo IP,
premere INVIO per accedere alla risposta predefinita “yes” e procedere
con la creazione del pacchetto. La procedura guidata richiederà le
informazioni del pacchetto:
Configuring the csync Serviceguard package for a highly available cfengine master.
The cfengine master server is being configured as a HA Serviceguard Package on this
cluster.
Please provide the following information for the package:
Enter the Volume group? []: vgcsync
You need to enter a fully qualified Logical Volume, for example: /dev/vgname/lvol1 Enter
the fully qualified Logical Volume? []: /dev/vgcsync/lvol1
Capitolo 3
153
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Enter
Enter
Enter
Enter
Enter
the
the
the
the
the
Filesystem (Mount Point)? []: /csync
Mount Options? [-o rw,largefiles]:<INVIO>
Filesystem Type? [vxfs]: <INVIO>
IP address? []: 12.345.6.78
Subnet? []: 12.345.7.8
La procedura guidata chiederà ora se si desidera gestire anche dei client
amministrati remoti, sistemi cioè che si trovano all’esterno del cluster. La
procedura guidata configurerà automaticamente i membri correnti del
cluster. Per questo motivo tutti i membri devono essere in funzione ed
accessibili quando si esegue la procedura guidata. Nell’esempio mostrato
in basso, l’amministratore ha scelto “no”, per cui inizialmente saranno
configurati solo i membri del cluster.
I client remoti potranno essere facilmente aggiunti in seguito con la
procedura guidata. Non è necessario utilizzare la procedura guidata per
l’aggiunta i nuovi client quando si aggiungono altri membri al cluster. Per
i dettagli, consultare la sezione sulle funzionalità d’automazione di
Serviceguard.
You can optionally specify additional remote clients to manage at this time. If you are
running in an HA environment, you do not need to specify the cluster members.
Would you like to manage clients? [N]: <INVIO>
La procedura guidata ora dispone di tutti i dati necessari per configurare
il cluster e procede a farlo:
******* WARNING!!!! ******** To protect against possible corruption of sensitive
configuration files, control-c has been disabled for the remainder of this
configuration.
Configuring the ‘csync’ Serviceguard package.
Applying the ‘csync’ Serviceguard package configuration file, this will take a moment.
Starting the ‘csync’ Serviceguard package, this will take a few moments...
The ‘csync’ Serviceguard package has been started on <nome host locale>.
Configuration of the cfengine master server is starting.
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines.
This may take a few minutes....
Terminata la configurazione, la procedura guidata presenterà la seguente
schermata di riepilogo, che indirizzerà l’amministratore al file principale
dei criteri, punto_montaggio/cfengine_master/inputs/cf.main, ed al
file delle risposte registrate per questa esecuzione della procedura
154
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
guidata. Il file dei criteri si trova nel filesystem appena configurato
associato con il pacchetto. In questo esempio, l’amministratore ha scelto di
montare il filesystem per il pacchetto come /csync.
Nel caso che l’amministratore in precedenza abbia configurato cfengine,
prima di sovrascrivere dei file di configurazione esistenti, la procedura
guidata creerà dei backup nella directory:
/var/opt/dsau/cfengine/backups
I file nel livello superiore di questa directory sono i backup più recenti.
Qualsiasi configurazione anteriore sarà salvata in sottodirectory di nome
v_data_ora.
The Configuration Synchronization Wizard has completed the configuration of cfengine:
- The master configuration description template is here:
</csync/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration synchronization actions
performed in a cluster. For example, synchronizing critical files such as /etc/hosts,
package scripts, etc.
All the actions in the template are disabled by default (commented out). Uncomment the
lines corresponding to the desired synchronization actions for this cluster. See the
cfengine reference documentation for a description of additional cfengine features:
/opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host: <nome host pacchetto>
and members: <membro 1 del cluster>, <membro 2 del cluster>, ...
A file recording the answers for this run of the Configuration Synchronization Wizard
is stored here...
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
Note sulla configurazione del cluster Questa sezione descrive in
dettaglio la configurazione ad alta disponibilità di cfengine in un cluster
Serviceguard. Per ulteriori informazioni sui ruoli dei vari comandi e
daemon di cfengine, consultare “Comandi e daemon di cfengine” a
pagina 144. Il pacchetto Serviceguard garantisce che il daemon cfservd
di cfengine rimanga ad alta disponibilità. I file di configurazione di
Capitolo 3
155
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
cfengine, update.conf e cfagent.conf, definiscono il server master di
sincronizzazione della configurazione in modo che sia il nome DNS
registrato per l’indirizzo IP riallocabile del pacchetto. Quando i client
amministrati eseguono cfagent (vedere cfagent (8)), cfagent si connette
a cfservd nel nodo adottivo del pacchetto. I membri del cluster stessi sono
perciò sono tutti client amministrati. Il membro che ospita il pacchetto
agisce inoltre come server master per i file dei criteri.
All’avvio del cluster, ogni membro avvierà un daemon cfservd client. Si
tratta del daemon cfservd che risponde alle richieste di cfrun. Quando è
avviato il pacchetto in un membro, quel daemon cfservd avrà l’accesso al
filesystem del pacchetto e diventerà il daemon cfservd principale, che
servirà i file dei criteri a tutti i client amministrati. Questo daemon
cfservd è controllato dal pacchetto. In caso di errore di cfservd, il
pacchetto tenterà riavviarlo in un altro membro. Il daemon cfservd di
quel membro diventerà il daemon cfservd principale.
Arrestando il pacchetto non si provocherà l’arresto del daemon cfservd
nel membro adottivo, dato che ci si attende che esso sia presente per
rispondere a future richieste di cfrun. Inoltre, diversamente da altri
servizi ad alta disponibilità, se il pacchetto csync non è in esecuzione o
non è disponibile, non ci saranno conseguenze negative per i client remoti.
I client continueranno a funzionare con la propria configurazione
correntemente definita. Per distribuire le nuove istruzioni di
configurazione ai client amministrati, l’amministratore dovrebbe
accertarsi che il pacchetto sia in esecuzione ed operativo.
La procedura guidata automatizza la distribuzione delle chiavi di
cfengine in tutti i membri del cluster. Per la descrizione dettagliata della
procedura di distribuzione delle chiavi, consultare “Note sulla sicurezza”
a pagina 175.
Funzionalità d’automazione di Serviceguard Distributed Systems
Administration Utilities richiede Serviceguard 11.17 o successiva. Con
Serviceguard 11.17 o successiva, gli strumenti di sincronizzazione della
configurazione eseguiranno automaticamente le opportune azioni di
configurazione quando si aggiungono o rimuovono membri dal cluster. In
particolare:
•
156
Quando si aggiunge un membro al cluster, il nuovo membro sarà
configurato automaticamente per partecipare alla sincronizzazione
della configurazione. Nel nuovo membro avverranno
automaticamente le azioni di configurazione seguenti:
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
1. Sarà modificato etc/rc.config.d/cfservd per impostare ad 1 il
valore di CSYNC_CONFIGURED.
2. Saranno create le chiavi pubblica e privata di cfengine per il
nuovo membro e queste saranno collocate nella directory
/var/opt/dsau/cfengine/ppkeys del membro. Le nuove chiavi
di questo membro saranno inoltre distribuite nella directory
/var/opt/dsau/cfengine/ppkeys degli altri membri del cluster.
3. Sarà riempita la directory /var/opt/dsau/cfengine/inputs del
nuovo membro.
4. Nel nuovo membro sarà eseguito cfservd.
5. I file del pacchetto saranno copiati nella directory
/etc/cmcluster/csync/ del nuovo membro.
6. Sarà eseguita una sincronizzazione di cfagent nel sistema
principale per riempire la sua directory
/var/opt/dsau/cfengine/inputs.
7. Sarà eseguita la sincronizzazione con cfagent nel client remoto.
•
Eliminando un membro dal cluster, la chiave pubblica del membro
eliminato sarà rimossa dalla directory
/var/opt/dsau/cfengine/ppkeys in tutto il cluster.
L’amministratore è in grado di definire gruppi o classi di cfengine che
enumerano tutti i membri di un dato cluster Serviceguard. Queste
definizioni di classi non saranno aggiornate automaticamente e, per le
modifiche dell’appartenenza al cluster, l’amministratore dovrà aggiornare
manualmente il file cfagent.conf e quelli correlati.
Configurazione di un client di sincronizzazione È possibile
utilizzare Configuration Synchronization Wizard per aggiungere dei
client amministrati alla configurazione esistente di cfengine. Eseguire la
procedura guidata nel server master, non nel sistema client. Quando un
cluster Serviceguard è il server master, eseguire la procedura guidata nel
nodo adottivo del pacchetto csync. L’aggiunta alla configurazione ad alta
disponibilità di un nuovo membro del cluster sarà eseguita
automaticamente. Per ulteriori informazioni, consultare “Funzionalità
d’automazione di Serviceguard” a pagina 156.
Capitolo 3
157
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Inoltre, per distribuire in sicurezza le chiavi di cfengine, il client deve
essere configurato per l’accesso ssh non interattivo da parte dell’account
di root del server master. Lo strumento csshsetup (vedere csshsetup (1))
facilita la configurazione dell’accesso ssh ad un sistema remoto. Questo
strumento è utilizzato negli esempi in basso.
Quando i client si trovano nel medesimo dominio DNS del server master,
la procedura guidata al momento è in grado di gestire solamente dei
client. Per le istruzioni su come aggiungere manualmente dei client nelle
configurazioni a domini multipli, consultare “Configurazione manuale” a
pagina 159.
In caso di aggiunta di un cluster Serviceguard come client amministrato,
ogni membro del cluster dovrà essere aggiunto individualmente.
Cominciare eseguendo l’accesso come root al server master e configurare
l’accesso ssh al sistema remoto:
# csshsetup <nome host del client amministrato>
Per prima cosa, csshsetup prova l’accesso ssh al sistema remoto. Nel
caso non sia configurato, ssh richiederà la password del client
amministrato.
Eseguire Configuration Synchronization Wizard e scegliere l’opzione 2
per aggiungere un nuovo client:
Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(9) Exit
Enter choice: 2
Alla richiesta, digitare il nome del client da aggiungere:
This option will configure additional clients to the cfengine domain.
Enter the name of the client to add: <nuovo client>
158
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
La procedura guidata proseguirà quindi a configurare il client e segnalerà
il procedere dell’operazione:
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
The client <nuovo client> has been added to the cfengine domain
La procedura guidata configura ogni nuovo client in modo da eseguire
cfservd, affinché sia in grado di rispondere alle richieste di cfrun ed
aggiunge i client al file cfrun.hosts del server master.
Configurazione manuale
La sezione seguente descrive le operazioni necessarie per configurare
manualmente cfengine nei server principali di sincronizzazione della
configurazione o nei client amministrati. È in genere più semplice
cominciare usando csync_wizard (vedere csync_wizard (1m)) e
modificare quindi la configurazione risultante, invece che partire da zero.
Questo vale particolarmente per i cluster Serviceguard, in cui procedura
guidata è utile per configurare il pacchetto e si fa carico di distribuire i file
di configurazione corretti in tutti i membri del cluster.
Eseguendo la configurazione manuale, è possibile creare configurazioni
che non potranno essere gestite successivamente da csync_wizard. Ad
esempio, la procedura guidata supporta solamente configurazioni a
singolo dominio DNS. Eseguendo manualmente una configurazione a
domini multipli, non sarà possibile utilizzare la procedura guidata per
aggiungere e rimuovere client.
NOTA
Capitolo 3
È possibile utilizzare csshsetup per configurare una relazione di fiducia
tra il server master ed i client amministrati. Questo consentirà di
utilizzare i comandi per la distribuzione dei comandi come cexec e ccp
(vedere cexec (1) e ccp (1)). L’uso di questi comandi può semplificare le
operazioni di configurazione descritte oltre, quando sarà necessario
distribuire i file nei client amministrati.
159
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Configurazione manuale di un server di sincronizzazione
indipendente Per configurare un sistema indipendente come server
master per cfengine, eseguire una sola volta le seguenti operazioni:
1. Cominciare creando le copie principali dei file di configurazione di
cfengine. Questi file si trovano in una directory nota, e sono
distribuiti in ogni client amministrato. La directory predefinita è
/var/opt/dsau/cfengine_master/inputs, riportata nei modelli
predefiniti. Cominciare creando la directory:
# mkdir -p /var/opt/dsau/cfengine_master/inputs
2. Copiare i file dei modelli predefiniti nelle directory seguenti:
#
#
#
#
#
#
cd
cp
cp
cp
cp
cp
/var/opt/dsau/cfengine_master/inputs
/opt/dsau/share/cfengine/templates/cf.main.template cf.main
/opt/dsau/share/cfengine/templates/update.conf.template update.conf
/opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf
/opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts
/opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
3. Quindi, modificare update.conf. Questo file è in un formato simile al
principale file di configurazione di cfengine, cfagent.conf. È
utilizzato per trasferire ed aggiornare nei client amministrati i file
binari di cfengine e qualsiasi file di definizione della configurazione,
ad esempio, cfagent.conf. È molto importante evitare errori e
semplificare al massimo questo file. Gli eventuali errori in questo file
richiederanno di copiare manualmente una nuova versione in ogni
client amministrato.
Il file contiene dei token, nella forma <%nome_token%>, che saranno
sostituiti da csync_wizard con le risposte date dall’amministratore
alle domande. Sostituire i token nel modo seguente:
a. Sostituire <%HOST_NAMER%> con il nome host non qualificato del
server master.
b. Sostituire <%DOMAIN_NAMER%> con il nome di dominio del server
master. Ad esempio:
host_name = ( “nome_server_principale” )
domain_name = ( “abc.xyz.com” )
Questo modello update.conf presume che il server master ed i
suoi client si trovino tutti in un singolo dominio DNS. Nel caso il
proprio server master dovesse avere dei client amministrati in
domini DNS multipli, modificare update.conf nel modo
seguente:
160
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
c.
Sostituire <%HOST_NAMER%> con il nome host qualificato completo
del server master.
d. Eliminare la variabile <domain_name>.
e.
Sostituire la riga “domain = ( “${nome_dominio}” )” con:
domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) )
Questo imposta in modo adeguato la variabile domain nel lato
client. Questa tecnica presume che in ogni client amministrato
/etc/resolv.conf sia stato correttamente configurato.
Questa medesima modifica alla variabile domain dovrà anche
essere eseguita in cf.main ed in cfservd.conf. Vedere le
operazioni successive. Utilizzare il flag cfagent -p (oppure
--parse-only) per controllare la sintassi di update.conf.
4. Distribuire la copia principale di update.conf in ogni client
amministrato. Questa operazione è descritta in “Configurazione di un
client amministrato di sincronizzazione” a pagina 172.
5. Creare le chiavi di protezione del server master. Per autenticare i
client remoti, cfengine utilizza lo scambio delle chiavi pubblica e
privata. Nel server master, ed in tutti i client amministrati, sarà
creata una coppia di chiavi pubblica e privata. La chiave pubblica di
ogni client amministrato sarà copiata nel server master e da questo
nei client amministrati. È importante scambiare le chiavi in modo
sicuro, utilizzando uno strumento come secure copy (vedere scp (1)),
oppure utilizzando un nastro o un CD-ROM. Iniziare creando le chiavi
per il server master:
# /opt/dsau/sbin/cfkey
# cd /var/opt/cfengine/ppkeys
Ciò creerà i file localhost.pub e localhost.priv.
Copiare la chiave pubblica in
root-indirizzo_IP_server_principale.pub. Ad esempio, se
l’indirizzo IP del sistema è 10.0.0.5, utilizzare questo comando:
# cp localhost.pub root-10.0.0.5.pub
Per i dettagli su come copiare le chiavi dei client in questo server
master, vedere “Configurazione di un client amministrato di
sincronizzazione” a pagina 172.
Capitolo 3
161
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
6. Nel server master, configurare il daemon cfservd per l’avvio assieme
al sistema. Modificare /etc/rc.config.d/cfservd e cambiare la
riga CSYNC_CONFIGURED=0 in CSYNC_CONFIGURED=1.
Facoltativamente, nel caso si desideri “spingere” le modifiche nei
client amministrati utilizzando cfrun, ripetere questa modifica in
tutti i client amministrati.
7. cfrun richiede che i client amministrati siano elencati nel file
cfrun.hosts. Nella configurazione predefinita, questo file si trova in
/var/opt/dsau/cfengine_master/inputs. Modificarlo ed
aggiungere il nome host di ogni client amministrato, uno per riga.
Conviene fare in modo che tutti i i nomi host siano completamente
qualificati. Utilizzando i nomi host completamente qualificati,
“domain = riga” non è necessaria e può essere eliminata. Nel caso si
usino nomi host non qualificati, cercare la riga “domain =
<%DOMAIN_NAMER%>” e sostituire il token con il dominio DNS dei
sistemi client. In questo modo, i client saranno solamente i membri di
tale singolo dominio.
8. Il file /var/opt/dsau/cfengine_master/inputs/cfagent.conf è
quello principale dei criteri. Il file predefinito cfagent.conf
comprende il modello predefinito cf.main, che è un file modello con
commenti contenente esempi di azioni comuni di sincronizzazione, sia
per sistemi indipendenti sia per cluster Serviceguard. Il file cf.main
contiene i medesimi token <%HOST_NAMER%> e <%DOMAIN_NAMER%> di
update.conf. Eseguire le medesime modifiche descritte prima al
punto 3.
Questo file predefinito cf.main non esegue azioni di
amministrazione. Tutte le righe relative alle azioni sono dei
commenti. Si tratta di un punto di partenza per la creazione di un
gruppo personalizzato di criteri per cfengine e di azioni per i propri
client amministrati. Il manuale di cfengine, che documenta la
sintassi e tutte le azioni di amministrazione definite in questo file, si
trova in /opt/dsau/doc/cfengine. Altri esempi di file di
configurazione per cfengine, che sono presenti nella distribuzione
open source di cfengine, si trovano in
/opt/dsau/share/cfengine/examples.
9. Il file /var/opt/dsau/cfengine_master/inputs/cfservd.conf
controlla quali client amministrati avranno accesso ai file gestiti da
cfservd nel server master. Eseguire le seguenti modifiche a
cfservd.conf.
162
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Eliminare interamente la riga seguente:
domain_name
•
= ( “<%DOMAIN_NAMER%>” )
Modificare la riga
domain
= ( “${domain_name}” )
nel modo seguente:
domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf)
•
)
La definizione “admit:” controlla quali client remoti avranno
accesso ai file nel server. Modificare ogni occorrenza di
“*.${domain_name}” con l’elenco di domini DNS dei client
amministrati, separati da un spazio. Ad esempio:
/var/opt/dsau/cfengine_master/master_files
*.abc.xyz.com *.cde.xyz.com
Questo esempio consente a tutti gli host nei domini elencati di
accedere ai file nel server master. È inoltre possibile specificare
elenchi di determinati host, intervalli di indirizzi IP, ecc. Per
ulteriori informazioni, consultare il manuale di cfengine.
10. Nel server master, eseguire cfservd:
# /sbin/init.d/cfservd start
Ciò dovrà essere ripetuto per ogni client amministrato.
11. Provare la configurazione eseguendo le operazioni seguenti:
a. In un client amministrato, utilizzare il comando:
# cfagent --no-lock --verbose --no-splay
L’output dettagliato mostrerà il client mentre controlla la
presenza di copie aggiornate dei file principali dei criteri, mentre
li copia in /var/opt/cfengine/inputs, se necessario, e mentre
esegue il contenuto di cfagent.conf/cf.main.
b. Nel server master, provare il comando cfrun:
# cfrun -- --inform
La sintassi --inform indica a cfagent eseguito remotamente di
utilizzare il flag --inform, che darà origine a dei messaggi per
tutte le modifiche eseguite da cfengine nel sistema. Per ulteriori
informazioni, può essere utile --verbose:
# cfrun -v -- --verbose
Capitolo 3
163
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
L’opzione -v indica a cfrun stesso di essere più dettagliato e
l’opzione --verbose sarà passata a cfagent eseguito
remotamente.
Per ulteriori informazioni sulla risoluzione dei problemi, consultare
“Risoluzione dei problemi di cfengine” a pagina 179.
Configurazione manuale di un cluster Serviceguard come server
di sincronizzazione La configurazione di cfengine per l’alta disponibilità in un cluster Serviceguard è analoga a quella di una macchina indipendente, descritta nella sezione “Uso della procedura guidata per la configurazione di un server di sincronizzazione indipendente” a pagina 148.
Le differenze principali sono la creazione del pacchetto di Serviceguard ed
il meccanismo utilizzato per la distribuzione delle chiavi di protezione di
cfengine. Seguire tutte le operazioni descritte oltre.
•
Preparazione iniziale del pacchetto di Serviceguard
1. Iniziare ottenendo un indirizzo IP per il pacchetto. Questo
indirizzo è in genere registrato in un DNS, per semplificare la
gestione di client remoti. Utilizzando cfengine solamente
all’interno di un cluster, sarà sufficiente assicurarsi che l’indirizzo
sia aggiunto al file /etc/hosts di ogni membro.
2. Quindi, creare l’infrastruttura d’archiviazione necessaria per il
nuovo pacchetto. Le istruzioni per fare ciò sono documentate nel
volume Managing Serviceguard, in “Building an HA Cluster
Configuration”, “Creating a Storage Infrastructure.” Ad esempio,
utilizzando l’infrastruttura d’archiviazione LVM, saranno
necessarie le operazioni seguenti:
a. Creare il gruppo di volumi (VG) LVM ed i volumi logici (LV),
ad esempio, /dev/vgcsync/lvol1.
b. Esportazione ed importazione dei gruppi di volumi in tutto il
cluster.
c.
Configurazione dei filesystem nei volumi logici.
d. Creare il punto di montaggio del filesystem, ad esempio,
/csync, in tutto il cluster.
I modelli predefiniti presumono che si utilizzi un’archiviazione
LVM. Per utilizzare VxVM o altre archiviazioni o filesystem in
tutto il cluster, eseguire le opportune modifiche ai modelli del
pacchetto descritte oltre.
164
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
3. Assicurarsi che nel membro corrente il filesystem per il pacchetto
sia montato. Ad esempio, utilizzando LVM eseguire:
# vgchange -a e /dev/vgcsync
# mount -o rw,largefiles /dev/vgcsync/lvol1 /csync
•
Personalizzazione iniziale del file dei criteri
1. Creare una sottodirectory per il file principale dei criteri e per i
file di riferimento. Ad esempio:
# mkdir -p /csync/dsau/cfengine_master/master_files
Queste directory di esempio sono quelle utilizzate da
csync_wizard.
2. Copiare i file dei modelli predefiniti nella directory principale per
gli input:
#
#
#
#
#
#
cd /csync/dsau/cfengine_master/inputs
cp /opt/dsau/share/cfengine/templates/cf.main.template cf.main
cp /opt/dsau/share/cfengine/templates/update.conf.template update.conf
cp /opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf
cp /opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts
cp /opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
3. Modificare update.conf. Questo file è in un formato simile al
principale file di configurazione di cfengine, cfagent.conf. È
utilizzato per trasferire ed aggiornare nei client amministrati i
file binari di cfengine e qualsiasi file di definizione della
configurazione, ad esempio, cfagent.conf. È molto importante
evitare errori e semplificare al massimo questo file. Gli eventuali
errori in questo file richiederanno di copiare manualmente una
nuova versione in ogni client amministrato.
Il file contiene dei token, nella forma <%nome_token%>, che
saranno sostituiti da csync_wizard con le risposte date
dall’amministratore alle domande. Sostituire i token nel modo
seguente:
— Sostituire <%HOST_NAMER%> con il nome host non
qualificato del pacchetto Serviceguard.
— Sostituire <%DOMAIN_NAMER%> con il nome di dominio
DNS del pacchetto. Ad esempio:
host_name = ( “nome-host-pacchetto”)
domain_name = ( “abc.xyz.com”)
Capitolo 3
165
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Questo update.conf modello presume che il server master ed i
suoi client si trovino tutti in un singolo dominio DNS. Nel caso il
proprio server master dovesse avere dei client amministrati in
domini DNS multipli, modificare update.conf nel modo
seguente:
— Sostituire <%HOST_NAMER%> con il nome host qualificato
completamente del pacchetto Serviceguard.
— Eliminare la variabile “domain_name”.
— Sostituire la riga domain = ( “${nome_dominio}” ) con:
domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) )
Questo imposta in modo adeguato la variabile domain nel lato
client.
Questa medesima modifica alla variabile domain dovrà anche
essere eseguita in cf.main ed in cfservd.conf. Vedere oltre.
Utilizzare il flag -p (--parse-only) di cfagent per controllare la
sintassi di update.conf.
•
Elenco dei client amministrati in cfrun.hosts
cfrun richiede che tutti i client amministrati siano elencati nel file
cfrun.hosts. Dato che ogni membro del cluster è considerato un
client, assicurarsi che ognuno di essi sia elencato in
/csync/dsau/cfengine_master/inputs/cfrun.hosts.
Modificarlo ed aggiungere il nome host di ogni membro, uno per riga.
Conviene fare in modo che tutti i i nomi host siano completamente
qualificati. Utilizzando i nomi host completamente qualificati, la riga
“domain =” non è necessaria e può essere eliminata. Nel caso si usino
nomi host non qualificati, cercare la riga ““domain =
<%DOMAIN_NAMER%>”” e sostituire il token con il dominio DNS dei
membri del cluster. In questo modo, i client saranno solamente i
membri di tale singolo dominio.
•
Modifica del file principale dei criteri
Il file /var/opt/dsau/cfengine_master/inputs/cfagent.conf è
quello principale dei criteri. Il file predefinito cfagent.conf
comprende il modello predefinito cf.main, un file modello con
caratteri di commento, contenente esempi di azioni comuni di
sincronizzazione, sia per sistemi indipendenti sia per cluster
Serviceguard. Modificare cf.main per sostituire i token seguenti:
cf.main contiene gli stessi token <%HOST_NAMER%> e
166
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
<%DOMAIN_NAMER%> di update.conf. Eseguire le medesime modifiche
descritte al punto 3 del precedente elenco puntato, “Personalizzazione
iniziale del file dei criteri”.
Questo modello predefinito non esegue azioni di amministrazione.
Tutte le righe relative alle azioni sono dei commenti. Contiene molti
esempi specifici per la sincronizzazione dei file un cluster
Serviceguard. Si tratta di un punto di partenza per la creazione di un
gruppo personalizzato di criteri per cfengine e di azioni per il proprio
cluster ed altri client amministrati.
Il manuale di cfengine, che documenta la sintassi e tutte le azioni di
amministrazione definite in questo file, si trova in
/opt/dsau/doc/cfengine.
Altri esempi di file di configurazione per cfengine, che sono presenti
nella sua distribuzione open source, si trovano in
/opt/dsau/share/cfengine/examples.
•
Modificare il file cfservd.conf
Il file /var/opt/dsau/cfengine_master/inputs/cfservd.conf
controlla quali client amministrati avranno accesso ai file gestiti da
cfservd nel server master. Eseguire le seguenti modifiche a
cfservd.conf.
— Eliminare interamente la riga seguente:
domain_name
= ( “<%DOMAIN_NAMER%>” )
— Modificare la riga
domain
= ( “${domain_name}” )
nel modo seguente:
domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf)
)
— La definizione “admit:” controlla quali client remoti avranno
accesso ai file nel server. Modificare ogni occorrenza di
“*.${domain_name}” con l’elenco di domini DNS dei client
amministrati, separati da un spazio. Ad esempio:
/var/opt/dsau/cfengine_master/master_files
*.abc.xyz.com *.cde.xyz.com
Questo esempio consente a tutti gli host nei domini elencati di
accedere ai file nel server master. È inoltre possibile specificare
elenchi di determinati host, intervalli di indirizzi IP, ecc. Per
ulteriori informazioni, consultare il manuale di cfengine.
Capitolo 3
167
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Distribuire il file principale update.conf in ogni membro del
cluster
Usare i comandi seguenti:
# cd /var/opt/dsau/cfengine/master_files/inputs
# ccp update.conf /var/opt/dsau/cfengine/inputs/
cfengine stesso si occuperà di distribuire in tutto il cluster ed a tutti
i client amministrati i file rimanenti.
•
Distribuire le chiavi di protezione di cfengine
Dato che cfengine utilizza un modello di scambio di chiavi pubblica e
privata per la convalida dell’autenticità dei client amministrati, deve
essere configurata una chiave che sia associata all’indirizzo IP
riallocabile del pacchetto. Tale indirizzo sarà quello che i client remoti
vedranno come server master. Poiché ogni membro del cluster può
diventare il nodo adottivo, questa chiave deve essere identica per tutti
i membri del cluster. Il comando cfkey per cfengine crea una coppia
di chiavi pubblica e privata per il sistema corrente. cfkey crea i file
localhost.priv e localhost.pub.
cfengine prevede che i nomi delle chiavi utilizzino la convenzione
seguente:
nome_utente-indirizzo_IP.pub
Ad esempio:
root-10.0.0.3.pub
L’amministratore copierà la chiave localhost.pub con il mone corretto
in base all’indirizzo IP del sistema. Nel caso di un cluster, per la
creazione delle chiavi per tutto il cluster saranno utilizzate quelle del
membro corrente, con le operazioni seguenti:
1. Usare cfkey per creare la coppia di chiavi pubblica e privata per
questo membro del cluster:
# mkdir -p /var/opt/dsau/cfengine/ppkeys
# cd /var/opt/dsau/cfengine/ppkeys
# /opt/dsau/sbin/cfkey
Ciò creerà le chiavi di nome localhost.priv e localhost.pub.
168
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
2. La chiave pubblica, localhost.pub sarà quindi copiata in
root-indirizzo_IP_pacchetto.pub. Ad esempio,
# cp localhost.pub root-10.116.9.74.pub
dove 10.116.9.74 è l’indirizzo IP riallocabile del pacchetto csync.
3. Il file localhost.pub di questo membro è sovente utilizzato per la
creazione di chiavi specifiche per ogni membro:
# cp
# cp
# cp
...
# cp
localhost.pub root-<indirizzo_IP_membro>.pub
localhost.pub root-<indirizzo_IP_membro2>.pub
localhost.pub root-<indirizzo_IP_membro3>.pub
localhost.pub root-<indirizzo_IP_membroN>.pub
4. Infine, tutte le chiavi saranno copiate in ogni membro.
# ccp * /var/opt/dsau/cfengine/ppkeys
Nota: ccp, un comando distribuito, esegue la copia nel cluster,
copiando un comando in tutti i membri del cluster.
•
Configurazione ed avvio di cfservd
1. Configurare il daemon cfservd per l’avvio assieme al sistema.
Modificare /etc/rc.config.d/cfservd e cambiare la riga
CSYNC_CONFIGURED=0 in CSYNC_CONFIGURED=1.
2. Distribuire questa modifica nel cluster:
# ccp /etc/rc.config.d/cfservd /etc/rc.config.d/cfservd
3. Nel server master, eseguire cfservd:
# /sbin/init.d/cfservd start
4. Ripetere l’operazione per i membri rimanenti del cluster. Nel caso
che il cluster sia stato configurato per l’utilizzo degli strumenti
per la distribuzione dei comandi di DSAU, utilizzare il seguente
comando per avviare il daemon in tutto il cluster:
# cexec /sbin/init.d/cfservd start
•
Creazione del pacchetto csync
Per creare il pacchetto di sincronizzazione della configurazione,
modificare i file modello predefiniti del pacchetto secondo il caso per il
proprio ambiente Serviceguard. È obbligatorio che il nome del
pacchetto sia csync. In caso contrario, non saranno possibili le
Capitolo 3
169
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
operazioni automatiche di Serviceguard. Per maggiori informazioni,
consultare la sezione “Funzionalità d’automazione di Serviceguard” a
pagina 156
Cominciare eseguendo le modifiche descritte oltre.
1. Creare nel cluster la directory per il pacchetto:
# cexec mkdir /etc/cmcluster/csync
2. Copiare il file ASCII modello e lo script di controllo del pacchetto
nella directory /etc/cmcluster/cysnc del membro corrente:
#
#
#
#
cd /etc/cmcluster/csync
cp /opt/dsau/share/serviceguard/templates/csync.conf.template csync.conf
cp /dsau/share/serviceguard/templates/csync.script.template csync
chmod +x csync
3. Modificare il file ASCII di configurazione del pacchetto,
csync.conf, per sostituire i token segnaposto con i valori opportuni.
I token sono nella forma <%nome_token%>. Cercare la riga
“SUBNET <%SG_PKG_SUBNET%>” e sostituire il token con il valore di
sottorete del pacchetto csync. Per identificare la sottorete,
utilizzare netstat -i.
4. Modificare lo script di controllo del pacchetto e sostituire i token
segnaposto con i valori opportuni.
Nota: il modello predefinito dello script presume che si utilizzi
una configurazione d’archiviazione LVM. Nel caso che si usi
VxVM e/o CFS, consultare la documentazione Managing
Serviceguard per ulteriori informazioni sulla configurazione dei
pacchetti utilizzando queste tecnologie. Sarà necessario
rimuovere i commenti dalle sezioni LVM del modello descritte
oltre, e sostituire le opportune definizioni per VxVM o per CFS.
a. Cercare la riga “VG[0]=“<%SG_PKG_VOL_GRP%>”” e sostituire
il token con il nome del gruppo di volumi LVM del pacchetto.
Ad esempio, VG[0]“vgcsync”.
b. Cercare la riga “LV[0]=“<%SG_PKG_LOG_VOL%>”” e sostituire
il token con il nome completo del volume logico. Ad esempio,
LV[0]=“/dev/vgcsync/lvol1”.
170
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
c.
Cercare la riga “FS[0]=“<%SG_PKG_FS%>”” e sostituire il
token con il nome del punto di montaggio del filesystem creato
per questo pacchetto. Ad esempio, FS[0]=“/csync”.
Questo punto di montaggio deve essere stato creato in ogni
membro del cluster come parte della configurazione
d’archiviazione descritta prima.
d. Cercare la riga “FS_MOUNT_OPT[0]=“<%SG_PKG_MNT_OPT%>””
e sostituire il token con le opzioni di montaggio del filesystem.
Ad esempio, FS_MOUNT_OPT[0]=“-o rw,largefiles”.
e.
Cercare la riga “FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>”” e
sostituire il token con il tipo di filesystem. Ad esempio,
FS_TYPE[0]=“vxfs”.
f.
Cercare la riga
“FS_UMOUNT_OPT[0]=“<%SG_PKG_FS_UMOUNT_OPT%>”” e
sostituire il token con le opzioni di umount per il filesystem.
Questo token può essere rimosso e questa opzione lasciata in
bianco nel caso non vi siano particolari opzioni per umount.
Ad esempio, FS_UMOUNT_OPT[0]=“”.
g.
Cercare la riga
“FS_FSCK_OPT[0]=“<%SG_PKG_FS_FSCK_OPT%>”” e sostituire
il token con le opzioni di fsck specifiche per il filesystem.
come prima, è possibile eliminare il token e lasciare questa
opzione in bianco. Ad esempio, FS_FSCK_OPT[0]=“”.
h. Cercare la riga “IP[0]=“<%SG_PKG_IP%>””e sostituire il
token con l’indirizzo IP del pacchetto csync. Ad esempio,
IP[0]= 123.456.789.3.
i.
Cercare la riga “SUBNET[0]=“<%SG_PKG_SUBNET%>”” e
sostituire il token con la sottorete dell’indirizzo IP del
pacchetto. Per identificare la sottorete, utilizzare netstat -i.
Ad esempio, SUBNET[0]= 123.456.789.0.
5. Distribuire nel cluster lo script di controllo ed i file ASCII di
configurazione del pacchetto:
# ccp csync csync.conf /etc/cmcluster/csync/
6. Applicare il pacchetto ed avviarlo:
# cmapplyconf -P csync.conf
# cmmodpkg -e csync
Capitolo 3
171
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Provare la configurazione del pacchetto csync
Provare la configurazione eseguendo le operazioni seguenti:
1. In un client amministrato, utilizzare il comando:
# cfagent --no-lock --verbose --no-splay
L’output dettagliato mostrerà il client mentre controlla la
presenza di copie aggiornate dei file principali dei criteri, mentre
li copia in /var/opt/cfengine/inputs, se necessario, e mentre
esegue il contenuto di cfagent.conf/cf.main.
2. Nel server master, provare il comando cfrun:
# cfrun -- --inform
La sintassi --inform indica a cfagent eseguito remotamente di
utilizzare il flag --inform, che darà origine a dei messaggi per
tutte le modifiche eseguite da cfengine nel sistema. Per ulteriori
informazioni, può essere utile --verbose:
# cfrun -v -- --verbose
L’opzione -v indica a cfrun stesso di essere più dettagliato e
l’opzione --verbose sarà passata a cfagent eseguito
remotamente.
Per ulteriori informazioni sulla risoluzione dei problemi,
consultare “Risoluzione dei problemi di cfengine” a pagina 179.
Configurazione di un client amministrato di sincronizzazione
Quando si configurano manualmente i client amministrati, le operazioni
base sono:
•
Scambio delle chiavi di protezione. Questo istituirà una relazione di
fiducia tra il client amministrato ed il server master.
•
Copia di update.conf dal server master al client amministrato.
•
Impostazione di una pianificazione grazie alla quale cfagent
eseguirà le operazioni di sincronizzazione.
Per configurare un cluster Serviceguard come client di un server master
cfengine, ogni membro del cluster è trattato come se fosse un sistema
indipendente e configurato individualmente. Aggiungendo nuovi membri
al cluster, ognuno di essi dovrà essere configurato adeguatamente.
172
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Nel caso dell’aggiunta di un nuovo membro ad un cluster Serviceguard
che esegue il pacchetto csync, i membri del cluster saranno configurati
automaticamente come client amministrati da cfengine. In questo
scenario, il pacchetto csync agisce da server master. I nuovi membri
saranno configurati automaticamente come client amministrati e
saranno inoltre in grado di gestire il controllo degli errori per il pacchetto.
L’infrastruttura d’archiviazione ed il filesystem del pacchetto dovrebbero
essere configurati prima dell’aggiunta del nuovo membro al cluster.
Per aggiungere un nuovo client amministrato, iniziare configurando la
relazione di fiducia tra il client ed il server master. I due sistemi si
scambiano le chiavi di protezione per autenticarsi l’uno con l’altro. La
chiave pubblica del server master deve essere copiata nel client e quella
del client nel server master:
1. Come root, creare le chiavi di protezione del client usando cfkey:
# mkdir -p /var/opt/cfengine/ppkeys
# cd /var/opt/cfengine/ppkeys
# /opt/dsau/sbin/cfkey
Ciò creerà i file localhost.pub e localhost.priv di questo client.
2. Copiare la chiave del client nel server master. Per il nome delle chiavi
dei client, il server master utilizza la seguente convenzione:
<nome_utente>-<indirizzo_IP_client>.pub.
3. Inviare la chiave pubblica del client nella directory ppkeys del server
master, osservando la convenzione seguente:
# scp localhost.pub server_principale:\
/var/opt/cfengine/ppkeys/root-indirizzo_IP_client.pub
Quando si trasferisce la chiave, per proteggerne l’integrità è
importante utilizzare un’utility come secure copy (vedere scp (1)).
4. Infine, copiare in questo client amministrato la chiave del server
master:
# scp server_principale:/var/opt/cfengine_master/ppkeys/localhost.pub \
root-indirizzo_IP_server_principale.pub
5. Quindi, copiare il file update.conf dal server master al client
amministrato.
#
#
#
#
mkdir -p /var/opt/dsau/cfengine/inputs
cd /var/opt/dsau/cfengine/master_files/inputs
cd /var/opt/dsau/cfengine/inputs
scp server_principale:/var/opt/dsau/cfengine/inputs/update.conf ./update.conf
Capitolo 3
173
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Per consentire a questo client di accettare le richieste di cfrun, compiere
le operazioni seguenti:
1. Modificare /etc/rc.config.d/cfservd ed impostare la variabile
CSYNC_CONFIGURED al valore “1” – questo avvierà cfservd assieme al
sistema.
2. Avviare cfservd:
# /sbin/init.d/cfservd start
3. Provare la configurazione con cfagent (vedere cfagent (8)):
# cfagent --no-lock --verbose --no-splay
L’output dettagliato mostrerà il client mentre controlla la presenza di
copie aggiornate dei file principali dei criteri, mentre li copia in
/var/opt/cfengine/inputs, se necessario, e quindi mentre esegue il
contenuto di cfagent.conf/cf.main.
Per ulteriori informazioni sulla risoluzione dei problemi, consultare la
sezione “Risoluzione dei problemi di cfengine” a pagina 179.
Scelta del metodo di richiesta della sincronizzazione Come
amministratori, è possibile “spingere” le modifiche nei client
amministrati utilizzando il comando cfrun (vedere cfrun (8)). cfrun
contatta il daemon cfservd in ogni client amministrato e cfservd esegue
cfagent affinché questo compia l’effettiva operazione di sincronizzazione.
È inoltre possibile scegliere che cfagent sia eseguito ad intervalli regolari
nel client. Esistono due approcci:
•
Eseguire cfagent con una pianificazione di cron.
Quando si esegue cfagent da cron, farlo utilizzando cfexecd -F.
Come esempio, in basso è mostrata la voce per crontab:
0 * * * * /var/opt/dsau/cfengine/bin/cfexecd -F
Questa voce di crontab farà sì che cfagent sia eseguito ogni ora.
In questo esempio, cfexecd (vedere cfexecd (8)) agisce come wrapper
per cfagent e raccoglie gli output e li colloca in
/var/opt/dsau/cfengine/outputs. cfexecd è anche in grado di
inviare all’amministratore dei messaggi email, se specificato nel file
cfagent.conf. Per i dettagli, consultare il manuale di cfengine, in
/opt/dsau/doc/cfengine.
174
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Il file cf.main predefinito contiene un esempio su come aggiungere
automaticamente la riga mostrata sopra al file di crontab di ogni
client amministrato.
•
Eseguire cfexecd in modalità daemon.
cfexecd ha funzionalità analoghe a quelle di cron, basate sulle classi
temporali di cfengine, e può essere utilizzato al posto di cron per
eseguire cfagent. L’impostazione predefinita di cfexecd è di eseguire
cfengine ogni ora. Quando si comincia ad utilizzare cfengine, è
probabilmente più semplice usare cron per pianificare la
sincronizzazione nel lato client. Per i dettagli sull’uso di cfexecd in
modalità daemon, consultare il tutorial cfengine presente in
/opt/dsau/doc/cfengine/.
Note sulla sicurezza
cfengine dispone di molte funzionalità di protezione, che vanno dai
parametri per controllare gli attacchi negazione del servizio – DoS – fino
alle liste di controllo dell’accesso, che impediscono ai client amministrati
di accedere alle directory dei file di riferimento nel server. Per i dettagli
sulle funzionalità di sicurezza di cfengine, consultare il suo manuale,
situato in /opt/dsau/doc/cfengine/.
I temi relativi alla sicurezza qui trattati comprendono:
Scambio delle
chiavi
•
Scambio delle chiavi
•
Uso delle porte di rete
•
Crittografia
•
Allarmi di tipo checksum
Tutti gli esempi di scambio di chiavi mostrati finora hanno utilizzato scp
per il trasferimento protetto della chiave pubblica del server master nel
client amministrato e di quella del client amministrato nel server master.
Uno schema come questo offre il maggiore livello di protezione, ma in
alcune situazioni può essere problematico. Altre possibilità di
distribuzione delle chiavi comprendono:
•
Capitolo 3
Alla connessione con un nuovo client, cfrun dispone di una modalità
interattiva simile a ssh, nella quale all’amministratore sarà chiesto di
accettare la chiave del sistema remoto. Ad esempio:
175
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
cfrun(0): .......... [ Hailing remote-host.abc.xyz.com ] ..........
WARNING - You do not have a public key from host remote-host.abc.xyz.com =
12.345.678.90
Do you want to accept one on trust? (yes/no)
-> yes
cfrun:<nome server master>: Trusting server identity and willing to accept key from
remote-host.abc.xyz.com=12.345.678.90
•
Questa modalità interattiva può rivelarsi inefficiente con un gran
numero di client. cfrun supporta l’opzione -T, che indica a cfengine
di dare fiducia a tutte le nuove chiavi degli host elencati in
cfrun.hosts.
•
cfservd.conf supporta la clausola di controllo TrustKeysFrom. Ad
esempio:
control:
TrustKeysFrom = ( 128.39.89.76 ) # Host fidato
TrustKeysFrom = ( 128.39.89.76/24 ) # Sottorete fidata
Gli host o gli indirizzi di sottorete elencati saranno implicitamente
fidati e le loro chiavi saranno accettate automaticamente.
Tutte queste alternative di scambio delle chiavi devono essere utilizzate
con estrema attenzione e solamente in ambienti sicuri, in cui la LAN è
fidata, così come lo sono gli host remoti. Una volta che è stata accettata, la
chiave pubblica non sarà aggiornata, a meno che sia eliminata
manualmente dalla directory /var/opt/dsau/cfengine/ppkeys del
server master, oppure sostituita manualmente da una nuova chiave.
Uso delle porte di
rete
cfservd utilizza per impostazione predefinita la porta TCP 5308. È
possibile impostare cfagent in modo che si connetta a cfservd
utilizzando un’altra porta, specificandola nel file cfrun.hosts. Ad
esempio:
host1.abc.xyz.com # Usa la porta standard
host2.abc.xyz.com # Usa la porta standard
host3.abc.xyz.com:4444 # Usa la porta 4444
Inoltre, cfengine utilizzerà una porta TCP per cfengine che sia stata
definita in /etc/services.
176
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Crittografia
In generale, il traffico di trasferimento file tra il server master ed un client
amministrato non è crittografato. Questo è accettabile per molti file di
configurazione correlati all’amministrazione di sistema. Per alcuni file, è
desiderabile il loro trasferimento crittografato. L’azione di copia in
cfagent.conf contiene l’opzione “encrypt = true”, per crittografare il file
specificato. Per le ulteriori opzioni crittografiche, consultare il manuale di
cfengine, in /opt/dsau/doc/cfengine.
Allarmi di tipo
checksum
cfengine ha una funzionalità di allarme per il checksum simile a
Tripwire. Per controllare le variazioni al checksum di un file, compiere le
operazioni seguenti:
•
Aggiungere la seguente definizione a
/var/opt/dsau/cfengine_master/inputs/cfagent.conf:
ChecksumUpdates = ( “on” )
•
Nella sequenza di azioni “files” di cfagent.conf, aggiungere
l’opzione checksum = md5, oppure quella checksum = sha, per i file
da controllare. Ad esempio:
files:
class::
/etc/example
mode = 644
checksum = md5
Questa opzione per checksum è diversa da quella checksum = true
utilizzata nella sequenza di azioni per la copia. Quella opzione indica
a cfengine di utilizzare il valore checksum al posto di quello di data
ed ora per decidere se è necessario copiare il file.
Se non dovesse esistere già, cfagent creerà nel client il database dei
valori checksum. Quando ChecksumUpdates è impostata come “on”
oppure “true”, il valore checksum corrente dei file controllati sarà
aggiunto al database o aggiornato. Dopo l’esecuzione iniziale per
compilare il database dei valori checksum, cambiare ChecksumUpdates a
“off.” A questo punto, qualsiasi variazione del valore checksum di un file
controllato provocherà un avviso di protezione. Ad esempio:
host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
host1: SECURITY ALERT: Checksum for /etc/example changed!
host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Capitolo 3
177
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Disattivazione dell’uso di cfengine
Il programma csync_wizard non ha un’opzione di deconfigurazione per
far cessare un sistema dall’operare come server master. Per disattivare un
server master, arrestare semplicemente cfservd:
# /sbin/init.d/cfservd stop
Per impedire l’avvio di cfservd assieme al sistema, modificare
/etc/rc.config.d/cfservd e cambiare CSCYN_CONFIGURED a “0”.
Nel caso che sia stata utilizzata la procedura csync_wizard per creare la
configurazione di cfengine ed aggiungere i client amministrati, potrà
essere usata per rimuoverli. Eseguire la procedura guidata nel server
master e scegliere l’opzione “Remove a client”. La procedura guidata
richiede che sia stato configurato l’accesso ssh non interattivo al client
amministrato, come descritto nella sezione “Configurazione di un client di
sincronizzazione” a pagina 157. Il client specificato sarà rimosso da
cfrun.hosts, la sua chiave pubblica sarà eliminata dalla directory
ppkeys del server master e la chiave del server master sarà eliminata
dalla directory ppkeys del client.
Opzioni di registrazione eventi
Con cfengine non sono volutamente fornite informazioni riguardanti la
maggior parte delle modifiche alla configurazione, ma esistono varie
opzioni di configurazione per aumentare il livello di dettagli dell’output di
cfengine, come le seguenti:
178
•
La maggior parte delle azioni di cfagent.conf, come “copy”,
“editfiles” e “processes”, supportano l’opzione syslog = true, in modo
da provocare la registrazione dell’azione in syslog.
•
Analogamente, la maggior parte delle azioni supportano l’opzione
“inform = true”, per fare in modo che cfagent segnali le modifiche.
•
La sezione di controllo di cfagent.conf supporta le opzioni globali
“inform = (true)” e “syslog = true”.
•
cfagent (vedere cfagent (8)) supporta l’opzione --inform nella riga
dei comandi. Per ulteriori informazioni, consultare il manuale di
cfengine, in /opt/dsau/doc/cfengine.
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Risoluzione dei problemi di cfengine
Seguono alcuni suggerimenti per la risoluzione dei problemi nell’uso di
cfengine.
1. Eseguire cfservd nel server master utilizzando le opzioni --no-fork
(-F) e --verbose (-v). Ciò fornirà delle informazioni utili per
l’eventuale risoluzione dei problemi
2. Potrebbero essere visibili errori di autenticazione. Quando si esegue
l’operazione “cfagent -K”, saranno visualizzati i messaggi seguenti:
cfengine:: BAD: key could not be accepted on trustcfengine:: Authentication dialogue
with <server master>.abc.xyz.com failed
cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:194: Warning:
actionsequence is empty
cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:194: Warning: perhaps
cfagent.conf/update.conf have not yet been set up?
Questo problema è molto probabilmente dovuto alla configurazione di
sicurezza di cfengine. Per risolvere il problema, sarà necessario
scambiare le chiavi pubbliche per cfengine tra il client amministrato
ed il server master. La procedura csync_wizard (vedere csync_wizard
(8)) automatizza questa operazione al momento dell’aggiunta del
client. Per le istruzioni su come distribuire manualmente le chiavi nei
client amministrati, vedere la sezione “Configurazione di un client
amministrato di sincronizzazione” a pagina 172.
3. Errori “Warning: actionsequence is empty”
Utilizzare l’opzione cfagent -v per ottenere maggiori informazioni.
Una causa possibile di questo messaggio è che update.conf non è
stato aggiunto alla directory /var/opt/dsau/cfengine/inputs del
client.
4. Errori di sintassi dovuti a spazi mancanti
# cfagent -K
cfengine::/var/opt/dsau/cfengine/inputs/update.conf:39: syntax error
cfengine::/var/opt/dsau/cfengine/inputs/update.conf:Execution terminated
after parsing due to errors in program
Controllare gli spazi nei file di configurazione. Come regola generale,
l’uso degli spazi può migliorare la leggibilità. Un errore comune è
l’omissione di spazi all’interno delle parentesi. Ad esempio, le funzioni
Capitolo 3
179
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
non dovrebbero contenere spazi tra il nome della funzione e la
parentesi aperta, ma la funzione stessa richiede uno spazio iniziale ed
uno finale all’interno delle parentesi. L’esempio seguente mostra
l’utilizzo degli spazi iniziale e finale necessari.
control:
nome_variabile = ( ExecResult(/bin/ls -l) )
Nell’esempio precedente, il parser segnala un errore nella riga 39 di
update.conf; molto probabilmente si tratta di un errore della
dichiarazione o riga precedente, la 38.
5. Connessione impossibile a cfengine client o principale.
# cfruncfrun(0): .......... [ Hailing host1 ] ..........
cfrun(0): .......... [ Hailing host2 ] ..........
cfrun:host2: Couldn’t open a socket
cfrun:host2: socket: Connection refused
Controllare che il daemon cfservd nell’host2 sia configurato ed in
esecuzione. Nel caso che non sia in esecuzione, utilizzare
/sbin/init.d/cfservd start per avviare cfservd.
6. Messaggi “Can’t stat”
Quando si esegue cfrun oppure cfagent è possibile ottenere degli
errori “can’t stat”. Ad esempio:
host1: Can’t stat
/var/opt/dsau/cfengine_master/master_files/etc/test in copy
Controllare l’archivio dei file del server master ed accertarsi che il file
in questione sia disponibile ed abbia le autorizzazioni adeguate.
7. Errori “Couldn’t open a socket ” oppure “unable to establish
connection:”
cfagent e cfrun possono visualizzare errori come:
cfengine:: Couldn’t open a socket
cfengine:: Unable to establish connection with host1 (failover)
host2: Couldn’t open a socket
Nel caso che cfservd sia in esecuzione nel server master, questo
errore può segnalare un problema con il firewall oppure una porta,
che fa sì che il client non riesca a raggiungere la porta TCP 5308 nel
server master. Quando si utilizza cfrun, anche il server master deve
essere in grado di raggiungere la porta TCP 5308 nel client remoto.
Controllare che le regole del firewall consentano l’accesso a tali porte.
180
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
8. Gli argomenti nella riga dei comandi per cfengine distinguono le
maiuscole dalle minuscole. Ad esempio, cfagent supporta le opzioni
-k e -K, che hanno differente significato:
•
-k indica a cfagent di ignorare la sequenza di azioni per la copia
•
-K indica a cfagent di ignorare i blocchi durante la sua
esecuzione
9. Come ottenere maggiori dettagli da cfengine
La maggior parte degli strumenti e daemon di cfengine accettano
l’opzione per l’output dettagliato e varie opzioni di debug. Ad esempio:
cfagent -d, -d1, -d2, -d3, or -d4 # per l’output di debug
cfservd -v
cfrun -v
Introduzione a syslog
syslogd (vedere syslogd (1M)) è un componente dei sistemi UNIX molto
diffuso, che esegue l’attività di registrazione degli eventi di sistema.
syslogd legge un gruppo di file di log di origine, come /dev/log e
/dev/klog, e ne elabora i messaggi secondo le istruzioni di
/etc/syslog.conf. Le applicazioni registrano i messaggi in syslog
utilizzando la chiamata syslog() (vedere syslog (3C)).
Formato dei messaggi di syslog
Un messaggio di syslog è in formato standard, che comprende un livello
di priorità facoltativo ed un servizio. Il livello di priorità indica l’urgenza
del messaggio. Il servizio segnala il sottosistema che ha generato il
messaggio. La Tabella 3-1 elenca i livelli di priorità ed i servizi definiti in
/usr/include/syslog.h.
Capitolo 3
181
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Tabella 3-1
Livelli di priorità di syslog
Messaggio
Descrizione
LOG_EMERG
Condizione di panico, normalmente trasmessa a tutti gli
utenti.
LOG_ALERT
Condizione da correggere immediatamente, come quella
di un database di sistema danneggiato.
LOG_CRIT
Condizione critica, come un errore hardware.
LOG_ERR
Errori generici.
LOG_WARNING
Messaggi di avvertimento
LOG_NOTICE
Condizioni non di errore, ma che richiedono partizione
attenzione.
LOG_INFO
Messaggi informativi.
LOG_DEBUG
Messaggi che contengono informazioni normalmente
utilizzate solo per il debug di un programma.
La Tabella 3-2 descrive i messaggi di servizio per syslog.
Tabella 3-2
Messaggi di servizio per syslog
Messaggio
Descrizione
LOG_KERN
Messaggi generati dalla kernel. Non possono essere
generati da processi dell’utente.
LOG_USER
Messaggi generati casualmente dai processi dell’utente.
Si tratta dell’identificatore predefinito del servizio
quando non ne è specificato nessuno.
LOG_MAIL
Messaggi del sistema di posta elettronica.
LOG_DAEMON
Messaggi dai daemon di sistema, come inetd, ftpd
(vedere inetd (1M), ftpd (1M)).
LOG_AUTH
Messaggi dal sistema di autenticazione, tra cui login,
su, getty (vedere login (1), su (1), getty (1M)).
LOG_SYSLOG
Messaggi generati internamente dal daemon syslogd.
182
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Tabella 3-2
Messaggi di servizio per syslog (segue)
Messaggio
Descrizione
LOG_LPR
Messaggi dal sistema di spooling di stampa, come lp,
lpsched (vedere lp (1), lpsched (1M)).
LOG_NEWS
Messaggi del sistema di news.
LOG_UUCP
Messaggi del sistema UUCP.
LOG_CRON
Messaggi del daemon CRON.
LOG_LOCAL0 - LOC_LOCAL7
Riservati per l’uso locale.
Filtro dei messaggi
Utilizzando /etc/syslog.conf, sarà possibile filtrare i messaggi in base
al loro livello di priorità ed al servizio. I messaggi possono essere
indirizzati verso:
•
Specifici file di log
•
La console
•
Un dato utente. Se l’utente ha eseguito l’accesso, il messaggio sarà
inviato al suo terminale.
•
Tutti gli utenti che hanno eseguito l’accesso
•
Inoltrato verso sistemi remoti. Per ulteriori informazioni, consultare
“Panoramica della consolidazione dei registri eventi” a pagina 183.
Per ulteriori informazioni sulla configurazione dei filtri dei messaggi,
vedere la manpage di syslogd (1M).
Panoramica della consolidazione dei registri eventi
L’inoltro dei registri eventi è una funzionalità del daemon standard UNIX
syslogd. Oltre a registrare i messaggi nei file di log dell’host locale,
syslogd è in grado di inoltrarli verso uno o più sistemi remoti. Questi
sistemi sono detti collettori o server di consolidazione dei registri eventi.
Capitolo 3
183
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
La consolidazione dei registri eventi offre vantaggi come i seguenti:
•
Analisi più semplice dei registri – Il registro centralizzato fornisce
all’amministratore una singola ubicazione per eseguire l’analisi dei
file di log. Fornisce un’unica visualizzazione degli eventi che
interessano più sistemi
•
Maggiore sicurezza – Una violazione della sicurezza può
compromettere i registri locali ma non la copia centralizzata. Il
sistema di consolidazione dei registri eventi può essere rafforzato con
modalità che probabilmente sarebbero inadatte per i client di inoltro
dei registri.
•
Archiviazione semplificata dei registri – In alcuni casi è più semplice
archiviare un gruppo di registri centralizzati piuttosto che sistema
per sistema.
Vi sono alcuni svantaggi nell’utilizzo del daemon syslogd standard in un
server di consolidazione dei registri eventi:
•
syslogd supporta l’inoltro utilizzando solamente UDP. Universal
Datagram Protocol – UDP – è un protocollo “senza connessione” e non
offre il controllo di flusso né garantisce la consegna dei messaggi. È
perciò possibile che i messaggi dei registri così inoltrati vadano
perduti.
•
Le funzionalità di filtraggio di syslogd sono piuttosto semplici: è
possibile filtrare solamente in base alla priorità ed al servizio del
messaggio.
•
Un sistema di consolidazione dei registri eventi presente un unico
punto debole. Nel caso che il sistema non sia disponibile, i messaggi
inoltrati dai client andranno perduti. I messaggi continueranno ad
esistere nei singoli sistemi client. Sono perduti solamente per il
registro consolidato.
Consolidazione dei registri eventi migliorata
Distributed Systems Administration Utilities (DSAU) utilizza
syslog-ng, o syslog “Next Generation”, per ovviare alle debolezze di
syslogd prima citate.
184
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
syslog-ng è un sostitutivo open source di syslogd. Esegue tutte le
funzionalità di syslogd, oltre ad offrire quelle seguenti:
•
Migliori funzionalità di filtraggio. Oltre ai livelli di filtraggio per
priorità e servizio di syslog, syslog-ng è in grado di eseguire
filtraggi secondo espressioni regolari in base al nome del programma,
il nome host, il testo del messaggio stesso, l’indirizzo IP del mittente,
e così via.
•
Trasporto TCP – Oltre al trasporto UDP di syslogd, syslog-ng
supporta quello TCP, che offre migliori garanzie di consegna.
È importante osservare come il supporto di syslog-ng per il trasporto
TCP non comporti una salvaguardia contro la perdita dei messaggi.
Ad esempio, nel caso che il server per la consolidazione dei registri
eventi sia inattivo, una volta superata la capacità dei loro buffer, nei i
client remoti inoltranti si verificherà una perdita di pacchetti (la
dimensione del buffer nel lato client è configurabile con syslog-ng).
Tuttavia, TCP è generalmente in grado di offrire una maggiori
affidabilità, oltre a miglior sicurezza. Ad esempio, è possibile
crittografare il traffico TCP dei registri utilizzando ssh.
NOTA
•
Rotazione dei registri in base ai nomi di file di output – La
registrazione con nomi di file di output può essere basata su modelli di
nomi che supportano espansioni con macro. Ad esempio, se il modello
dei nomi di file di output contiene una macro per il mese, ogni mese
sarà creato un nuovo nome di file.
•
Esecuzione di programmi – Un messaggio può attivare l’avvio di un
programma, inviando il messaggio verso il suo input standard
•
Inoltro dei registri per file di log di testo arbitrari – Assieme a allo
strumento clog_tail di DSAU, syslog-ng può essere utilizzato per
l’inoltro e la consolidazione dei file di log arbitrari di applicazioni
basate su testo, come quelli dei pacchetti di Serviceguard.
Coesistenza con syslog
Distributed Systems Administration Utilities configura syslog-ng per
coesistere ed operare a fianco del daemon syslogd standard. syslogd
continua a gestire la registrazione eventi locale del sistema. syslog-ng è
utilizzato per l’inoltro dei messaggi ad un sistema di consolidazione dei
registri eventi ed è utilizzato nel sistema di consolidazione per la ricezione
ed il filtraggio dei messaggi.
Capitolo 3
185
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
I diagrammi seguenti mostrano la relazione tra syslogd e syslog-ng. La
Figura 3-2 a pagina 186 illustra la configurazione di syslog-ng in un
sistema client che inoltra i registri eventi verso un server remoto di
consolidazione.
Figura 3-2
Configurazione per l’inoltro dei registri eventi con syslog-ng
1. L’area grigia rappresenta le operazioni standard di syslogd.
Applicazioni come il daemon cmcld di Serviceguard, chiamano
syslog (vedere syslog (3C)) per inviare i messaggi a syslogd. syslog
salva i messaggi in /var/adm/syslog/syslog.log e nei file correlati
del sistema locale. Le applicazioni frequentemente hanno dei propri
file di log. In questo esempio, Serviceguard mantiene un registro
eventi delle operazioni dei pacchetti in
/etc/cmcluster/<nome_pacchetto>/<nome_pacchetto>.log.
186
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
2. Il daemon clog_tail di DSAU, etichettato nel diagramma come
“Lettore file di log”, controlla i registri eventi testuali ed invia le
nuove righe a syslog-ng per l’elaborazione. In un cluster
Serviceguard, clog_tail controlla per impostazione predefinita tutti
i file di log dei pacchetti.
3. Il lettore_file_di_log invia tutti i nuovi messaggi dei registri in
una named pipe (fifo_registro_consolidato), che è una delle
origini dei registri per syslog-ng.
4. Il daemon syslog-ng legge i nuovi dati dalla named pipe e li inoltra
al server di consolidazione dei registri eventi.
5. Il daemon locale syslogd, oltre a salvare i messaggi dei registri eventi
nel file locale /var/adm/syslog/syslog.log, è anche configurato per
inoltrare tutti i messaggi all’istanza locale di syslog-ng. A sua volta,
syslog-ng inoltra questi messaggi al sistema di consolidazione dei
registri eventi. Per l’inoltro dei messaggi, l’amministratore può
scegliere di utilizzare UDP, TCP oppure TCP con ssh.
La Figura 3-3 mostra la configurazione nel server di consolidazione dei
registri eventi.
Capitolo 3
187
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Figura 3-3
Configurazione del sistema di consolidazione dei registri eventi
con syslog-ng
1. Il server di syslog-ng legge i dati dei registri in arrivo dai client
connessi con UDP o con TCP. Nota: le frecce grigie indicano
un’operazione di lettura, quelle nere, di scrittura.
2. L’area grigia è identica alla configurazione del client della Figura 3-2,
“Configurazione per l’inoltro dei registri eventi con syslog-ng”. In
termini di sistema locale, syslog-ng agisce come client ed elabora i
messaggi di syslog e quelli di clog_tail inoltrati localmente.
3. Il server di syslog-ng elabora tutti i messaggi e li filtra nei
corrispondenti file di log consolidati. In questo esempio specifico,
l’amministratore ha creato un filesystem di nome “/clog” per
contenere i registri consolidati. /clog/syslog/ conterrebbe il file
correlato con syslog. /clog/packages conterrebbe i registri
consolidati dei pacchetti del cluster Serviceguard.
188
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Configurazione della consolidazione dei registri
eventi
Le sezioni seguenti descrivono come configurare i server di consolidazione
dei registri eventi ed i client di inoltro dei registri. La configurazione di un
server di consolidazione è una procedura con varie fasi. Lo strumento
clog_wizard semplifica ampiamente la procedura di configurazione. Nel
caso si scegliesse di non utilizzare la procedura guidata, le operazioni
della configurazione manuale sono descritte oltre.
Uso di Log Consolidation Wizard
Log Consolidation Wizard è installato come
/opt/dsau/sbin/clog_wizard.
La procedura guidata supporta la creazione delle configurazioni seguenti:
•
server di consolidazione dei registri eventi indipendente
•
server di consolidazione dei registri eventi ad alta disponibilità da
utilizzarsi in un singolo cluster Serviceguard (solo all’interno del
cluster)
•
server di consolidazione dei registri eventi ad alta disponibilità da
utilizzabile da un cluster Serviceguard locale e da sistemi remoti,
compresi i client del cluster Serviceguard
•
sistema indipendente per l’inoltro dei registri verso un server di
consolidazione dei registri remoto
•
cluster Serviceguard per l’inoltro dei registri verso un server di
consolidazione dei registri remoto
Scegliere l’opzione di configurazione adatta.
La procedura guidata rileverà se si tratta di un sistema indipendente
oppure di un cluster Serviceguard, come descritto nella sezione
successiva.
Configurazione con clog_wizard di un server di consolidazione
dei registri eventi indipendente
Per un sistema indipendente, per prima cosa la procedura guidata
presenterà del testo introduttivo che illustra la consolidazione dei registri
eventi, quindi chiederà:
Do you want to configure log consolidation? (y/n) [y]:
Capitolo 3
189
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Rispondere sì (yes) oppure premere semplicemente Invio. La domanda
successiva sarà:
You can configure this system hostname as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure hostname as a Consolidation Server?
(y/n) [y]:
Rispondere “yes”.
La procedura guidata chiederà quindi:
Enter the fully qualified directory where the consolidated logs should be stored? []:
Per la consolidazione dei registri eventi, in genere è preferibile scegliere
un filesystem dedicato. Dato che i registri consolidati come syslog
possono rapidamente crescere, HP consiglia che il filesystem sia
configurato per “largefiles.” In questo esempio, si presume sia utilizzato il
filesystem “/clog”.
La procedura guidata richiederà quindi il tipo di trasporto del client:
You can choose to have the clients forward logs to this consolidation server via the UDP
protocol or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]:
La scelta di TCP non preclude necessariamente l’utilizzo di UDP per
l’inoltro dei messaggi dei registri da parte dei client. L’utilizzo esclusivo di
TCP per i messaggi dei registri da parte del sistema di consolidazione
dipende dal fatto che esso sta consolidando il proprio file di syslog locale.
Per i dettagli, vedere oltre.
You need to choose a free port on this system for log receiving.
Note: When configuring log consolidation on the clients, this port will need to be
specified.
Enter the TCP port to be used for log receiving? []:
Non esiste una porta riservata per il trasporto TCP di syslog-ng. Sarà
possibile scegliere qualsiasi porta che non sia in uso. HP consiglia agli
amministratori di scegliere una porta nell’intervallo riservato, cioè sotto a
quella 1024. Solamente i processi con privilegi di un sistema remoto sono
in grado di connettersi alle porte privilegiate. Ciò offre solamente una
debole garanzia di protezione, dato che implica che l’amministratore
consideri fidato il sistema remoto. Per istituire delle più forti garanzie di
protezione, vedere la sezione ssh dove si tratta dei client di inoltro dei
registri.
190
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Il file /etc/services documenta le porte riservate ben note. Scegliendo
una porta riservata, la procedura guidata controllerà /etc/services ed
utilizzerà “netstat -an” per verificare che la porta non sia in uso.
Tenere presente che syslogd utilizza la porta UDP 514. L’uso della porta
TCP 514 è riservato a remsh. remsh non è un protocollo sicuro ed è
disabilitato in molti siti. Nel caso che remsh si stato disattivato nel
sistema di consolidazione, sarà possibile utilizzare la porta TCP 514.
Questo comporta il vantaggio che si tratta di una porta privilegiata e che
ha il medesimo numero della porta UDP, essendo così più facile da
ricordare e da gestire. Tuttavia, nel caso che l’amministratore modifichi il
sistema per riattivare l’uso di remsh, syslog-ng dovrà essere
riconfigurato per utilizzare una nuova porta e tutti i sistemi client che
inoltrano a questo sistema dovranno essere aggiornati.
Diversamente da UDP, TCP è un protocollo orientato alla connessione.
Ogni client che inoltra i registri utilizzando TCP disporrà di una
connessione al server di consolidazione dei registri eventi. Per evitare
attacchi di negazione del servizio, il numero predefinito delle connessioni
TCP accettate da syslog-ng è limitato a 10. Per un maggior numero di
client, modificare il file /etc/syslog-ng.conf.server del server di
consolidazione. Cercare la riga TCP source nel file:
source s_syslog_tcp { tcp(port(<TCP port>)
keep-alive(yes));};
ed aggiungere l’attributo max-connections() nel modo seguente:
source s_syslog_tcp { tcp(port(<TCP port>) keep-alive(yes)
max-connections(N)); };
dove N è il numero previsto di client.
La procedura guidata chiederà quindi quali registri eventi devono essere
consolidati:
I file di log che si trovano in questo sistema potranno essere consolidati.
Would you like to consolidate this system's syslogs? (y/n) [y]:
Rispondendo di sì, i dati locali di syslog di questo sistema di
consolidazione dei registri eventi saranno collocati nel registro
consolidato, assieme ai dati di syslog del sistema client. Per conservare la
priorità ed il servizio delle voci di syslog, sarà utilizzato il loopback UDP
locale, e inoltre syslog sarà configurato per inoltrare le voci verso la sua
porta UDP 514. syslog-ng sarà configurato per leggere da questa porta.
Perciò, consolidando i syslog di questo sistema si consentirà ai client di
connettersi anche a questo server di consolidazione dei registri eventi
Capitolo 3
191
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
tramite la porta UDP 514, anche se in precedenza è stato specificato il
trasporto TCP. Scegliendo di non consolidare i syslog di questo sistema,
la precedente selezione del trasporto TCP richiederà che tutti i client di
inoltro dei registri siano configurati per l’utilizzo del trasporto TCP.
La procedura guidata visualizzerà il riepilogo di tutte le scelte di
configurazione eseguite dall’amministratore:
Summary of Log Consolidation Configuration:
You have chosen to configure nome_host as a Log
Consolidation Server.
Logs will be forwarded from the remote consolidation
clients to local port 1776 using the TCP protocol.
The consolidated logs will be stored under directory:
/clog
The following logs from the local system will be
consolidated:
Syslog
Se queste scelte sono corrette, proseguire:
Do you want to continue? (y/n) [y]: y
La procedura guidata visualizzerà il progredire dell’operazione
descrivendo quali file sono modificati. Per la descrizione completa dei file
modificati, consultare “Configurazione manuale della consolidazione dei
registri eventi” a pagina 204.
Copying files that will be modified by the wizard to /var/opt/dsau/root_tmp/clog. These
files will be used to restore the system to its current log consolidation configuration,
in the event of a failure.
Configuring nome_host as a log consolidation server.
Creating the /etc/syslog-ng.conf.server configuration file.
Creating a symbolic link from /etc/syslog-ng.conf to the /etc/syslog-ng.conf.server
configuration file.
Creating /etc/rc.config.d/syslog-ng, the log consolidation configuration file.
Updating the syslog configuration:
Updating the /etc/rc.config.d/syslogd file to add
-N SYSLOGD_OPTS. This stops syslogd from
listening to UDP port 514.
192
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Updating the /etc/syslog.conf file for UDP local
loopback.
Starting syslogd for the configuration changes to
take effect.
Registering the log consolidation ports in the /etc/services file.
Starting syslog-ng.
Successfully configured nome_host as a log consolidation server.
Configurazione con clog_wizard di un cluster Serviceguard come
server di consolidazione dei registri eventi
Quando si esegue clog_wizard (vedere clog_wizard (1M)) in un cluster,
per prima cosa accertarsi che tutti i suoi membri siano in funzione e
disponibili. La procedura guidata deve eseguire le operazioni di
configurazione in ogni membro. È necessario eseguirla una sola volta, in
un qualsiasi membro del cluster.
La procedura guidata imposterà e creerà un pacchetto di Serviceguard
per il servizio di registrazione eventi consolidato. Accertarsi che il valore
di MAX_CONFIGURED_PACKAGES del cluster sia in grado di
accogliere il pacchetto aggiuntivo. Per ulteriori informazioni su questa
impostazione, consultare il manuale Managing Serviceguard, che fa parte
della documentazione di Serviceguard.
Per prima cosa, la procedura guidata visualizzerà un testo introduttivo
che illustra la consolidazione dei registri eventi:
Log file consolidation allows you combine the log entries from multiple remote systems
into a single file. The standard use of this feature is to consolidate syslog data from
several systems. Each remote system continues to write entries to its local syslog.log
and additionally forwards the entries to the consolidating host. The system's
forwarding log entries are consolidation clients. The system they are sending the
entries to is the consolidation server. In addition to syslog data, arbitrary textual
log files can also be consolidated.
In a Serviceguard cluster, this tool can help you automate package log file
consolidation. Log consolidation is especially useful in a Serviceguard cluster, since
it allows you to look at a single consolidated file instead of the per-member logs. This
tool needs to be run only once in the cluster and not on each cluster member. All cluster
members should be up when running this wizard.
clog_wizard will prompt you for information to configure log file consolidation. Some
of these questions have a default answer contained within square brackets. If you press
Return, the default answer is assumed.
Capitolo 3
193
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Do you want to configure log consolidation? (y/n) [y]:
Rispondere sì (yes) oppure premere semplicemente Invio. La domanda
successiva sarà
You can configure this cluster nome_cluster as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure nome_cluster as a Consolidation Server?
(y/n) [y]:
Rispondere “yes”.
In un cluster, la procedura guidata configurerà syslog-ng per l’alta
disponibilità, utilizzando un pacchetto di Serviceguard. Il nome del
pacchetto per la registrazione eventi consolidata è “clog”. Prima di
proseguire o iniziare la procedura guidata, per il pacchetto deve essere
impostata la configurazione d’archiviazione LVM e quella della rete. Per
ulteriori dettagli, consultare il volume Managing Serviceguard, capitolo
5, “Building an HA Cluster Configuration”, sezione “Creating a Storage
Infrastructure with LVM.”
NOTA
La procedura guidata supporta solamente la creazione di pacchetti basati
sui gruppi di volumi LVM. Utilizzando CFS o VxVM, sarà necessaria la
configurazione manuale. Per maggiori dettagli, vedere la sezione
“Configurazione manuale della consolidazione dei registri eventi” a
pagina 204.
La procedura guidata farà le seguenti richieste, le quali dovrebbero essere
tutte già configurate:
1. Nome del gruppo di volumi LVM (ad esempio, vgclog)
2. Volume logico nel gruppo di volumi (ad esempio, /dev/vgclog/lvol1)
3. Il punto di montaggio del filesystem (ad esempio, /clog)
4. Le opzioni di montaggio del filesystem (ad esempio, -o
rw,largefiles). Le opzioni di montaggio sono utilizzate alla lettera
nel campo FS_MOUNT_OPT[0] dello script di controllo del pacchetto
Service. Le opzioni di montaggio devono essere coerenti con il
filesystem creato nel volume logico. Ad esempio, se il filesystem è
stato creato con il supporto per i file di grande dimensione, deve essere
specificata l’opzione “largefiles” per il punto di montaggio. Dato che i
registri eventi consolidati tendono ad essere di grande dimensione, si
consiglia di configurare i filesystem VxFS con l’opzione “largefiles”.
194
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
5. Il tipo di filesystem (ad esempio, VxFS)
6. L’indirizzo IP del pacchetto. Questo dovrebbe anche essere un nome
DNS registrato, in modo che l’inoltro dei registri eventi sia di facile
impostazione nei sistemi client.
7. La sottorete del pacchetto. Per accertare la sottorete, utilizzare
netstat -i.
La procedura guidata richiederà quindi il tipo di trasporto del client.
You can choose to have the clients forward logs to this consolidation server via the UDP
protocol or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]:
La scelta di TCP non preclude necessariamente l’utilizzo di UDP per
l’inoltro dei messaggi dei registri da parte dei client. L’utilizzo esclusivo di
TCP per i messaggi dei registri da parte del sistema di consolidazione
dipende dal fatto che esso sta consolidando il proprio file di syslog locale.
Per i dettagli, vedere oltre.
Scegliendo di usare TCP, sarà necessario selezionare una porta TCP
libera. Questa porta deve essere libera in tutti i membri del cluster. Per i
dettagli sulla scelta di una porta TCP utilizzando clog_wizard, vedere la
sezione “Configurazione con clog_wizard di un client d’inoltro dei registri
eventi” a pagina 200.
La procedura guidata chiederà quindi quali registri eventi devono essere
consolidati:
Log files that reside on this cluster can be consolidated.
Would you like to consolidate this cluster's syslogs? (y/n) [y]:
Would you like to consolidate this cluster's package logs? (y/n) [y]:
In un cluster Serviceguard, è possibile consolidare tutti i file di syslog
specifici di un membro in un singolo registro syslog consolidato,
contenente syslog.log, mail.log e syslog-ng.log. È inoltre possibile
consolidare i registri del pacchetto specifici dei singoli membri.
Scegliendo di consolidare i registri syslog del cluster, i client remoti
potranno anche inoltrare al cluster via UDP i messaggi syslog,
indipendentemente dalla risposta data alla domanda “Do you want to use
the TCP protocol”. Scegliendo di non consolidare i syslog di questo cluster,
la precedente selezione del trasporto TCP richiederà che tutti i client di
inoltro dei registri siano configurati per l’utilizzo del trasporto TCP.
Capitolo 3
195
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
I registri eventi consolidati saranno collocati nel filesystem associato a
questo pacchetto. Secondo l’esempio precedente, il file syslog.log
dovrebbe trovarsi qui:
/clog/syslog/syslog.log,mail.log,syslog-ng.log
I registri eventi consolidati dei pacchetti dovrebbero trovarsi qui:
/clog/package/pacchetto_1.log, pacchetto_2.log, ..., pacchetto_N.log
La procedura guidata ora dispone di tutti i dati necessari per configurare
il pacchetto per la registrazione eventi consolidata: mostrerà una
schermata di riepilogo e conferma, quindi eseguirà la configurazione:
Summary of Log Consolidation Configuration:
You have chosen to configure nome_cluster as a Log Consolidation
Server.
Logs will be forwarded from the remote consolidation clients to local
port port-number using the TCP protocol.
For high availability the Serviceguard package "clog" will be
configured with the following attributes:
Volume Group:
vgclog
Logical Volume:
/dev/vgclog/lvol1
Filesystem:
/clog
Mount Options:
-o rw,largefiles
Filesystem Type: vxfs
IP Address:
123.456.789.10
Subnet:
123.456.788.0
The following logs on this cluster will be consolidated:
Syslog
Serviceguard package logs Do you want to continue? (y/n) [y]:
Do you want to continue? (y/n) [y]:
Copying files that will be modified by the wizard to /var/opt/dsau/root_tmp/clog
on each cluster node. These files will be used to restore the cluster to its
current log consolidation configuration, in the event of a failure.
Configuring nome_cluster as a log consolidation server.
The configuration will be done on all cluster nodes.
It will take a few minutes....
Creating the /etc/syslog-ng.conf.server configuration file.
Creating the /etc/syslog-ng.conf.client configuration file.
196
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Creating a symbolic link from /etc/syslog-ng.conf to the
/etc/syslog-ng.conf.client configuration file.
Halting the "clog" Serviceguard package if it is up.
Creating /etc/rc.config.d/syslog-ng, the log consolidation configuration file.
Updating the syslog configuration:
Updating the /etc/rc.config.d/syslogd file to add -N to SYSLOGD_OPTS.
This stops syslogd from listening to UDP port 514.
Updating the /etc/syslog.conf file for UDP local loopback.
Starting syslogd for the configuration changes to take effect.
Registering the log consolidation ports in the /etc/services file.
Starting syslog-ng.
Setting up the log consolidation server to be highly available.
Configuring the "clog" Serviceguard package.
Applying the "clog" Serviceguard package configuration file, this will take a
moment.
Starting the "clog" Serviceguard package, this will take a few moments...
The "clog" Serviceguard package has been started on cluster-member.
Successfully created the "clog" Serviceguard package.
Successfully configured nome_cluster as a log consolidation server.
Note sulla configurazione del cluster
In un cluster Serviceguard, il nodo adottivo del pacchetto clog esegue le
funzioni di consolidazione dei registri eventi. Tutti gli altri membri del
cluster partecipano come client d’inoltro dei registri ed inviano i relativi
messaggi all’indirizzo IP riallocabile del pacchetto clog.
DSAU mantiene due file di configurazione, che determinano se l’istanza di
syslog-ng in un dato membro del cluster opera come server di
consolidazione o come client d’inoltro dei registri:
/etc/syslog-ng.conf.server e /etc/syslog-ng.conf.client. Il
Capitolo 3
197
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
collegamento simbolico /etc/syslog-ng.conf punta ad uno dei file di
configurazione. Quando si esegue l’avvio del cluster, tutti i suoi membri si
avviano come client d’inoltro dei registri eventi, con syslog-ng in
esecuzione in ogni membro. Lo script d’avvio /sbin/init.d/syslog-ng
imposta il collegamento simbolico /etc/syslog-ng.conf in modo che
punti a /etc/syslog-ng.conf.client.
All’avvio del pacchetto clog, il nodo adottivo riavvia l’istanza di
syslog-ng come server di consolidazione dei registri eventi. Lo script del
pacchetto reimposta il collegamento simbolico /etc/syslog-ng.conf in
modo che punti a /etc/syslog-ng.conf.server.
In caso di arresto del pacchetto clog, il collegamento simbolico sarà
modificato in modo da puntare a /etc/syslog-ng.conf.client e
l’istanza di syslog-ng di tale membro sarà riavviata. Quando un cluster
è un server di consolidazione dei registri eventi ed il pacchetto è inattivo,
la consolidazione dei registri eventi non avverrà ed i messaggi dei registri
eventi inoltrati andranno perduti.
I membri del cluster possono inoltrare i messaggi dei registri eventi al
sistema di consolidazione utilizzando UDP oppure TCP. All’interno di un
cluster Serviceguard, non è utilizzato il port forwarding ssh. È possibile
utilizzare il port forwarding ssh per proteggere il traffico dei registri
eventi inoltrati dai client remoti all’esterno del cluster. Per ulteriori
informazioni, consultare “Port forwarding ssh” a pagina 233
Funzionalità d’automazione di Serviceguard
Distributed Systems Administration Utilities richiede Serviceguard
11.17 o successiva. Con Serviceguard 11.17 o successiva, quando si
aggiungono o rimuovono membri dal cluster o si aggiungono o rimuovono
dei pacchetti, gli strumenti di registrazione eventi consolidata di DSAU
eseguiranno automaticamente le opportune azioni di configurazione. In
particolare:
•
Quando si aggiunge un membro al cluster, il nuovo membro sarà
configurato automaticamente per partecipare alla consolidazione dei
registri eventi, secondo la configurazione del cluster. I file seguenti
saranno automaticamente configurati nel nuovo membro:
— /etc/rc.config.d/syslog-ng
— /etc/rc.config.d/syslogd
— /etc/syslog.conf
198
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
— /etc/syslog-ng.conf.client, /etc/syslog-ng.conf.server
ed il collegamento simbolico /etc/syslog-ng.conf
— /etc/services
•
Quando si elimina un membro dal cluster:
— Il membro rimarrà configurato come client per l’inoltro dei
registri eventi e continuerà ad inoltrare i messaggi di syslog al
cluster, se è stata scelta questa opzione nell’esecuzione iniziale di
clog_wizard. Nel caso che il sistema non sia più in grado di
inoltrare i messaggi dei registri al cluster, eseguire nuovamente la
procedura guidata per configurare il sistema per l’inoltro ad un
altro sistema di consolidazione, oppure per disattivare
completamente la consolidazione dei registri eventi. Per ulteriori
informazioni, consultare “Disattivazione della consolidazione dei
registri eventi” a pagina 228.
— I registri eventi del pacchetto del membro così eliminato saranno
ancora controllati fino al riavvio successivo. Poiché questo
membro non fa più parte del cluster, i registri eventi dei pacchetti
non saranno più attivi.
•
Quando si aggiunge o si elimina un pacchetto, saranno eseguite
automaticamente le operazioni seguenti:
— Il pacchetto sarà rimosso da oppure aggiunto a
/etc/syslog-ng.conf.server in tutto il cluster. In questo file
esiste una sezione riservata all’utilizzo da parte degli strumenti di
DSAU. Le definizioni di configurazione aggiunte a questa sezione
indicano a syslog-ng di filtrare i messaggi dei registri dei
pacchetti nell’appropriato registro eventi consolidato.
— Il controllore dei registri eventi clog_tail aggiunge oppure
elimina il file di log del pacchetto dal suo elenco di file da
controllare.
Minimizzare la perdita di messaggi durante il recupero da errori
Quando si verifica un guasto nel nodo adottivo, prima che il pacchetto clog
si recuperato dall’errore in un altro membro del cluster, trascorre un certo
lasso di tempo. Maggiore è questo tempo di recupero dall’errore, maggiore
sarà la possibilità di perdere dei messaggi del registro eventi consolidato.
Per minimizzare la perdita di messaggi durante il recupero degli errori,
utilizzare le seguenti linee guida.
Capitolo 3
199
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Configurare i client per l’uso del trasporto TCP al posto di quello UDP.
Quando il pacchetto è inattivo, i messaggi inviati con UDP andranno
inevitabilmente perduti. Il protocollo TCP contiene dei meccanismi
per ripetere l’invio, il controllo per la congestione, ed altro, elementi
utili per minimizzare la perdita di messaggi.
•
syslog-ng è in grado di offrire un buffer per i messaggi TCP nel lato
client. Il numero dei messaggi memorizzati nel buffer è controllato
dall’impostazione di syslog-ng log_fifo_size(). Questa imposta il
limite massimo del numero di messaggi che possono essere
memorizzati nel buffer. Il file /etc/syslog-ng.conf() predefinito
imposta log_fifo_size come 10000.
•
Per configurare il tempo di attesa prima di ristabilire una connessione
interrotta, syslog-ng dispone dell’opzione time_reopen(). Nel file
/etc/syslog-ng.conf, time_reopen() è impostata a 10 secondi.
•
Serviceguard offre varie opzioni di configurazione per migliorare i
tempi di recupero dagli errori, come HEARTBEAT_INTERVAL e
NODE_TIMEOUT. È anche disponibile Serviceguard Extension for
Faster Failover (SGeFF), per ottimizzare i tempi di recupero dagli
errori nei cluster a due nodi. Poiché syslog-ng stesso si avvia
rapidamente, SGeFF è un candidato ideale per migliorare i tempi di
recupero e minimizzare la perdita di messaggi.
Configurazione con clog_wizard di un client d’inoltro dei registri
eventi
Esistono due modi per configurare un client per l’inoltro dei registri
eventi: come macchina indipendente oppure come cluster Serviceguard.
Quando si configura un cluster come client per l’inoltro dei registri eventi,
tutti i membri del cluster dovranno essere configurati come client in modo
identico. La procedura guidata rivolgerà le medesime domande ed
eseguirà le medesime azioni di configurazione per i sistemi singoli e per i
cluster. Gli esempi in basso mostrano l’uso di clog_wizard in un cluster
Serviceguard.
Dopo avere eseguito clog_wizard, rispondere “yes” alle domande
seguenti:
Do you want to configure log consolidation? (y/n) [y]:
oppure premere semplicemente Invio. La domanda successiva sarà:
200
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
You can configure this cluster nome_cluster as either:
- Consolidation server
- Client that forwards logs to a remote consolidation server
Do you want to configure nome_cluster as a Consolidation
Server? (y/n) [y]: n
Qui, rispondere “No”. A questo punto si sta configurando un client per
l’inoltro dei registri eventi. La procedura guidata mostrerà:
You now need to specify what system will be the consolidator. If the consolidator is a
Serviceguard cluster, you should specify the IP address of the "clog" Serviceguard
package for this question. The "clog" package is used to make log consolidation highly
available on the consolidator.
The consolidation server must already be configured.
Enter the hostname or IP address of the consolidator? []: clog.usa.xyz.com
Dopo avere immesso il nome host o l’indirizzo IP del server di
consolidazione dei registri eventi, la procedura guidata chiederà se si
desidera utilizzare il trasporto TCP per l’inoltro dei messaggi dei registri
eventi:
You can choose to forward logs to the consolidator via
the UDP protocol or the TCP protocol (recommended).
Do you want to use the TCP protocol? (y/n) [y]:
Il daemon syslogd standard inoltra i messaggi utilizzando il protocollo
UDP. UDP è un protocollo ad alto rendimento, orientato alla trasmissione,
senza controllo di flusso né verifica della ricezione dei messaggi.
syslog-ng supporta il protocollo UDP come syslogd e quello TCP. Il
trasporto TCP offre sia il controllo di flusso sia il controllo della ricezione
dei messaggi. Tuttavia, dato che TCP è un protocollo orientato alla
connessione, richiede risorse aggiuntive nel server di consolidazione dei
registri eventi. L’attributo max-connections() del server di
consolidazione dovrà essere impostato secondo il numero massimo di
client previsti. Per una discussione dell’impostazione di
max-connections(), consultare la sezione “Configurazione con
clog_wizard di un server di consolidazione dei registri eventi
indipendente” a pagina 189.
Rispondendo “yes” per l’uso di TCP, la domanda successiva chiederà verso
quale porta TCP inoltrare i messaggi:
Capitolo 3
201
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
You need to find out from the administrator of the consolidation server the TCP port that
was configured for log receiving.
Enter the TCP port configured on the CONSOLIDATOR for log receiving? []: 1776
È necessario utilizzare la porta TCP selezionata dall’amministratore di
sistema nel server di consolidazione dei registri eventi. Se per la
configurazione del server è stato utilizzato clog_wizard, il numero della
porta è stato salvato in /etc/rc.config.d/syslog-ng, come variabile
CLOG_TCP_PORT. In questo esempio, è utilizzata la porta TCP 1776.
Rispondendo “yes” alla domanda su TCP, sarà visualizzata quella
seguente:
The TCP protocol can be used in conjunction with Secure Shell port forwarding to enhance
security. Each member of this cluster must already have non interactive Secure Shell
Authentication set up with the consolidator. You can use the tool
/opt/dsau/bin/csshsetup to configure non interactive Secure Shell Authentication.
Do you want to configure Secure Shell port forwarding? (y/n) [y]:
Scegliere “yes” per utilizzare il port forwarding ssh. In questo modo tutto
il traffico generato da questo client locale d’inoltro dei registri eventi verso
il sistema di consolidazione sarà crittografato.
NOTA
Quando un cluster Serviceguard è il server di consolidazione dei registri
eventi, in esso è necessaria una speciale configurazione di protezione ssh.
Per i dettagli, vedere “Port forwarding ssh” a pagina 233.
Il port forwarding di ssh richiede una porta TCP libera addizionale nel
sistema client locale:
Per il port forwarding di ssh è necessario scegliere una porta libera in
questo cluster. La porta selezionata deve essere libera in tutti i nodi del
cluster.
Enter the ssh port to be used for port forwarding? []: 1175
Per questa porta si applica il medesimo criterio per la scelta della porta
TCP libera per syslog-ng. Per i dettagli, vedere “Configurazione con
clog_wizard di un server di consolidazione dei registri eventi
indipendente” a pagina 189. In questo esempio, è utilizzata la porta locale
1775.
202
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Per un cluster Serviceguard client d’inoltro dei registri eventi, i syslog ed
i registri eventi dei pacchetti del cluster dovranno essere inoltrati al
server di consolidazione dei registri eventi. Per un sistema indipendente,
la procedura guidata chiederà solamente se inoltrare i messaggi di
syslog:
Log files that reside on this cluster can be forwarded to the consolidator.
Would you like to forward this cluster's syslogs? (y/n) [y]:
Would you like to forward this cluster's package logs? (y/n) [y]:
Quando si esegue l’inoltro dei registri eventi dei pacchetti di un cluster,
per aggiungere le righe per il filtraggio di syslog-ng, in modo che questi
registri dei pacchetti siano consolidati nei propri file, sarà necessaria la
configurazione manuale. Per i dettagli, vedere “Configurazione manuale
dei client per l’inoltro dei registri eventi” a pagina 219.
Dopo avere risposto a tutte le domande, clog_wizard mostrerà la
seguente schermata di riepilogo:
Summary of Log Consolidation Configuration:
You have chosen to configure nome_cluster as a Log Consolidation Client.
Logs will be forwarded to the remote consolidation server
clog.usa.xyz.com on port 1776 using the TCP protocol.
The TCP protocol will be used in conjunction with Secure Shell
Port Forwarding using port 1775, for added security.
The following logs will be forwarded for consolidation:
Syslog
Serviceguard package logs
Do you want to continue? (y/n) [y]:
Confermare le risposte scegliendo “yes” e la procedura guidata
riepilogherà le operazioni di configurazione eseguite:
Copying files that will be modified
/var/opt/dsau/root_tmp/clog on each
These files will be used to restore
log consolidation configuration, in
by the wizard to
cluster node.
the cluster to itscurrent
the eventof a failure.
Configuring nome_cluster as a log consolidation client.
The configuration will be done on all cluster nodes.
Capitolo 3
203
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
It will take a few minutes....
Creating the /etc/syslog-ng.conf.client configuration file.
Creating a symbolic link from /etc/syslog-ng.conf to the
/etc/syslog-ng.conf.client configuration file.
Creating /etc/rc.config.d/syslog-ng, the log consolidation configuration file.
Updating the syslog configuration:
Updating the /etc/rc.config.d/syslogd file to add -N to SYSLOGD_OPTS.
This stops syslogd from listening to UDP port 514.
Updating the /etc/syslog.conf file for UDP local loopback.
Starting syslogd for the configuration changes to take effect.
Registering the log consolidation ports in the /etc/services file.
Starting syslog-ng.
Successfully configured nome_cluster as a log consolidation client.
Per ulteriori informazioni sulle operazioni di configurazione eseguite da
clog_wizard, consultare “Configurazione manuale di un cluster
Serviceguard come server di consolidazione dei registri eventi” a
pagina 209.
Configurazione manuale della consolidazione dei registri eventi
Scegliendo di non utilizzare Consolidated Logging Wizard, utilizzare le
seguenti sezioni per le operazioni manuali necessarie alla configurazione
di un server per la consolidazione dei registri eventi e dei client d’inoltro
dei registri. Dato che le operazioni necessarie per impostare client e
server sono numerose, HP consiglia l’utilizzo di clog_wizard.
Nei casi seguenti è necessaria la configurazione manuale:
204
•
Quando un cluster è un client inoltrante registri eventi e registri dei
pacchetti, nel server di consolidazione – indipendente o cluster che sia
– per filtrare in modo adeguato i registri dei pacchetti è necessaria la
configurazione manuale.
•
Quando si configura un cluster Serviceguard come server per la
consolidazione dei registri eventi, è necessario:
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
— Una personalizzazione speciale del pacchetto clog
— Utilizzare VxVM al posto di LVM
— Utilizzare Cluster File System (CFS)
Sovente, è più semplice eseguire la procedura guidata e lasciarle
completare la configurazione di base per poi personalizzarla, partendo da
quel punto.
Configurazione manuale di un server di consolidazione dei
registri eventi
Le sezioni seguenti descrivono in dettaglio le operazioni necessarie per la
configurazione manuale di un sistema indipendente o di un cluster
Serviceguard cluster come server di consolidazione dei registri eventi.
Configurazione
manuale di un
client
indipendente per
l’inoltro dei registri
eventi
Cominciare configurando il daemon syslogd standard per coesistere con
il daemon di consolidazione syslog-ng. Per impostazione predefinita,
syslogd è in ascolto per i messaggi dei registri in arrivo nella porta UDP
514. Nel caso si desideri accettare i messaggi syslog UDP da client remoti
oppure consolidare i syslog locali di questo server, syslog-ng deve essere
in ascolto nella porta UDP 514. Modificare /etc/rc.config.d/syslogd e
cambiare SYSLOGD_OPTS aggiungendo l’opzione -N, che impedisce a
syslogd l’ascolto nella porta 514. Ad esempio:
SYSLOGD_OPTS=“-D -N”
Se si desidera che i messaggi syslog locali provenienti dal server di
consolidazione dei registri eventi stesso facciano parte della
consolidazione di syslog, modificare il file /etc/syslog.conf per
inoltrare i messaggi verso la porta 514 nell’host locale, dove saranno letti
da syslog-ng. Utilizzando come esempio il file /etc/syslog.conf
predefinito di HP-UX, aggiungere le righe seguenti:
mail.debug
*.info;mail.none
@<server_consolidazione>
@<server_consolidazione>
dove <server_consolidazione> è il nome di dominio completamente
qualificato del server di consolidazione. Il nome deve essere
completamente qualificato, oppure syslogd non inoltrerà correttamente i
messaggi. Prima di ogni carattere @ deve essere presente quello <tab>.
Se syslog.conf è stato personalizzato, accertarsi di aggiungere anche le
righe per l’inoltro nella propria personalizzazione.
Capitolo 3
205
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Affinché le modifiche abbiano effetto, è necessario fermare e riavviare
syslogd, utilizzando i seguenti comandi:
# /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start
Con syslogd opportunamente configurato, configurare syslog-ng.
Cominciare con il medesimo modello syslog-ng.conf utilizzato da
clog_wizard.
Copiare
/opt/dsau/share/clog/templates/syslog-ng.conf.server.template
in /etc/syslog-ng.conf.server. Questo file contiene dei token, nella
forma <%nome_token%> che sono sostituiti dalla procedura guidata in
base alle risposte dell’amministratore alle sue domande.
Sostituire i token nel modo seguente:
•
Quando si utilizza il protocollo TCP e si configura il server per la
consolidazione dei propri syslog, sostituire il token
<%UDP_LOOPBACK_SOURCE%> con:
source s_syslog_udp { udp(port(514)); };
Sostituire il token <%UDP_LOOPBACK_LOG%> con:
log { source(s_syslog_udp); destination(d_syslog_tcp); };
Ciò farà sì che il daemon di consolidazione syslog-ng legga i
messaggi UDP locali di syslogd e li invii a syslog-ng nella porta
TCP locale. Facoltativamente, è possibile impostare la destinazione
direttamente al file di consolidazione locale,
(destination(d_syslog) in questo modello predefinito), ma questo
configura i componenti client del server di consolidazione nello stesso
modo di un client remoto. In altre parole, quando il sistema di
consolidazione è client di se stesso, è configurato identicamente ai
client remoti.
Utilizzando il protocollo UDP oppure non consolidando i syslog locali
di questo server, eliminare i token <%UDP_LOOPBACK_SOURCE%> e
<%UDP_LOOPBACK_LOG%>.
•
206
Sostituire i token <%TYPE%> con udp oppure con tcp, secondo il tipo
desiderato di trasporto dei registri. Quando si utilizzano dei client
TCP, se è configurata la consolidazione dei syslog locali del server,
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
saranno supportati anche quelli UDP. Sono presenti più righe che
contengono il token <%TYPE%>, e tutte devono essere modificate on
modo adeguato.
•
Nella riga “source s_syslog_<%TYPE%> ”, sostituire i token
<%PORT%> e <%KEEP_ALIVE%> con i valori adeguati, come mostrato di
seguito:
source s_syslog_<%TYPE%> { <%TYPE%>(port(<%PORT%>) <%KEEP_ALIVE%>); };
Per TCP, la porta deve essere una porta TCP disponibile. Per una
discussione sulla selezione di una porta disponibile, vedere la sezione
“Configurazione con clog_wizard di un server di consolidazione dei
registri eventi indipendente” a pagina 189. Per UDP, usare la porta
514.
<%KEEP_ALIVE%> si applica solamente scegliendo TCP per il trasporto
dei registri eventi. Sostituire questo token con “keep-alive(yes)”,
che indica a syslog-ng di tenere aperta la connessione quando
ripeterà la lettura del suo file di configurazione. Utilizzando UDP,
eliminare questo token.
•
Nella riga “destination d_syslog_<%TYPE%>”, sostituire i token
<%IP%> e <%PORT%>:
destination d_syslog_<%TYPE%> { <%TYPE%>(“<%IP%>” port(<%PORT%>)); };
Ad esempio, per TCP:
destination d_syslog_tcp { tcp(“nome_host_locale” port(1776)); };
dove <%IP%> è sostituito dall’indirizzo IP del server o dal nome host
locale e <%PORT%> dal numero della porta TCP selezionata.
Per UDP:
destination d_syslog_udp { udp(“nome_host_locale” port(514)); }
dove <%IP%> è sostituito dall’indirizzo IP del server o dal nome host
locale ed il token <%PORT%> è sostituito da 514, la porta UDP standard
di syslog.
•
Sostituire il token <%FS%> con il filesystem oppure la directory dove
si troveranno i registri eventi consolidati. Ad esempio,
destination d_syslog { file(“<%FS%>/syslog/syslog.log”); };
diventa:
destination d_syslog { file(“/clog/syslog/syslog.log”); };
Capitolo 3
207
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Accertarsi che questa directory esista o che il filesystem sia montato.
Dato che i registri eventi consolidati possono diventare facilmente di
dimensioni notevoli, HP consiglia di utilizzare l’opzione “largefiles”
per tale filesystem e di lasciare spazio libero disponibile.
•
Quando si utilizza TCP, scrivere nel file /etc/services il numero
della porta selezionata prima.
Ad esempio, aggiungere la riga:
clog_tcp
1776/tcp
•
# Registrazione eventi consolidata con syslog-ng
Creare il collegamento simbolico seguente:
ln -sf /etc/syslog-ng.conf.server /etc/syslog-ng.conf
•
La procedura di avvio di syslog-ng, /sbin/init.d/syslog-ng, usa
varie variabili di configurazione. Modificare
/etc/rc.config.d/syslog-ng nel modo seguente:
— Modificare la riga CLOG_CONFIGURED in:
CLOG_CONFIGURED=1
— Aggiungere le righe seguenti:
CLOG_CONSOLIDATOR=1
CLOG_FS=<directory dove saranno archiviati i registri
consolidati>
Se si utilizza il protocollo TCP, aggiungere:
CLOG_TCP=1
CLOG_TCP_PORT=<porta tcp scelta per la consolidazione dei registri>
altrimenti, se si utilizza il protocollo UDP, aggiungere:
CLOG_TCP=0
Se si consolidano i syslog locali, aggiungere:
CLOG_SYSLOG=1
altrimenti aggiungere:
CLOG_SYSLOG=0
Per un sistema indipendente di consolidazione, aggiungere:
CLOG_SYSTEM_LOG_CONSOLIDATION_DIR=<directory_registri_consolidati/syslog>
CLOG_SERVICEGUARD_PACKAGE_LOG_CONSOLIDATION_DIR=<directory_registri_consolidati/
packages>
208
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
— Aggiungere i due seguenti valori, che sono utilizzati da System
Log Viewer:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
•
Provare la configurazione eseguendo le operazioni seguenti:
1. Eseguire /opt/dsau/sbin/syslog-ng con l’opzione -s oppure
quella --syntax-only, per controllare la sintassi del file
/etc/syslog-ng.conf. Questo dovrebbe essere un collegamento
simbolico a /etc/syslog-ng.conf.server, come descritto
prima.
2. Avviare syslog-ng utilizzando /sbin/init.d/syslog-ng
start.
3. Se si consolidano i syslog locali, utilizzare logger
<messaggio_di_prova> ed accertarsi che questo messaggio si
trovi nel syslog.log consolidato. Se non si stanno consolidando i
registri eventi locali, utilizzare il comando logger da un client di
inoltro dei registri. I messaggi del comando logger sono prima
inviati al syslog locale, il quale li inoltra a syslog-ng. Per
impostazione predefinita, syslogd elimina i messaggi duplicati. Se
si creano più messaggi di prova per logger, assicurarsi che siano
unici.
Configurazione
manuale di un
cluster
Serviceguard
come server di
consolidazione dei
registri eventi
La configurazione di un cluster Serviceguard come server di
consolidazione è simile a quella di un sistema singolo. Tutti i membri del
cluster devono essere operativi quando si esegue questa procedura
guidata.
Creare in ogni membro del cluster i file di configurazione descritti oltre.
L’approccio più semplice è di configurare completamente un membro e
quindi copiare ogni file di configurazione in tutto il cluster. Gli strumenti
cexec e ccp sono in grado di semplificare la replicazione nel cluster delle
modifiche.
Per una configurazione cluster, syslog-ng è impostato come pacchetto, in
modo che il servizio di consolidazione dei registri eventi sia ad alta
disponibilità. Il nome del pacchetto deve essere clog ed i suoi file di
configurazione richiedono le informazioni seguenti:
Capitolo 3
•
L’indirizzo IP registrato ed il nome DNS del pacchetto clog
•
La sottorete associata a tale indirizzo IP
209
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
La configurazione d’archiviazione nel cluster usando LVM o VxVM
•
Il filesystem configurato per l’archiviazione nel cluster, che può essere
VxFS o CFS. Dato che i registri eventi consolidati possono
rapidamente diventare di dimensioni notevoli, HP consiglia di
utilizzare l’opzione “largefiles” per il filesystem e di lasciare spazio
libero disponibile.
Prima di continuare, completare la registrazione di indirizzo IP e della
configurazione di archiviazione e filesystem. Per ulteriori informazioni
sulla creazione della configurazione di archiviazione e filesystem di
Serviceguard per un pacchetto, consultare il manuale Managing
Serviceguard.
Per una panoramica su come configurare in un cluster la registrazione
eventi consolidata, consultare la sezione “Note sulla configurazione del
cluster” a pagina 197.
Punto
1. Se si desidera che i messaggi di syslog per il cluster stesso facciano parte
del syslog consolidato, eseguire le operazioni seguenti:
a. Cominciare configurando il daemon syslogd standard per coesistere
con il daemon di consolidazione syslog-ng. Per impostazione
predefinita, syslogd è in ascolto per i messaggi dei registri in arrivo
nella porta UDP 514. Per utilizzare il protocollo UDP oppure per
consolidare i syslog locali di questo server, syslog-ng deve essere in
ascolto nella porta UDP 514. Modificare /etc/rc.config.d/syslogd
e cambiare SYSLOGD_OPTS aggiungendo l’opzione -N, per impedire a
syslogd l’ascolto nella porta 514. Ad esempio:
SYSLOGD_OPTS=“-D -N”
b. Modificare il file /etc/syslog.conf per inoltrare i messaggi dei
registri eventi alla porta UDP 514 nell’host locale, dove saranno letti
da syslog-ng. Utilizzando come esempio il file /etc/syslog.conf
predefinito di HP-UX, aggiungere le righe seguenti:
mail.debug
*.info;mail.none
@<server_consolidazione>
@<server_consolidazione>
dove <server_consolidazione> è il nome di dominio completamente
qualificato del membro del cluster locale. Il nome deve essere
completamente qualificato, oppure syslogd non inoltrerà
correttamente i messaggi.
Se syslog.conf è stato personalizzato, accertarsi di aggiungere anche
le righe per l’inoltro nella propria personalizzazione.
210
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
c. Dato che /etc/rc.config.d/syslogd è generico, può essere
distribuito in tutto il cluster utilizzando ccp, nel modo seguente:
# cpp /etc/rc.config.d/syslogd /etc/rc.config.d/
d. Il file /etc/syslog.conf è specifico per ogni membro e le modifiche
descritte prima dovranno essere eseguite in ogni membro del cluster.
e. Eseguendo le modifiche di cui sopra in ogni membro del cluster, sarà
necessario riavviare syslogd perché queste abbiano effetto. Utilizzare
cexec per fare ciò in tutti i membri del cluster:
# cexec “/sbin/init.d/syslogd stop;/sbin/init.d/syslogd start”
Punto
2. Per configurare syslog-ng, cominciare con il medesimo modello di
syslog-ng.conf utilizzato da clog_wizard. In un membro del cluster, copiare /opt/dsau/share/clog/templates/syslog-ng.conf.server.template
in /etc/syslog-ng.conf.server. Quindi copiare
/opt/dsau/share/clog/templates/syslog-ng.conf.client.template in
/etc/syslog-ng.conf.client. Entrambi questi file contengono dei
token, nella forma <%nome_token%> che sono sostituiti dalla procedura
guidata in base alle risposte dell’amministratore alle sue domande.
Sostituire manualmente i token in /etc/syslog-ng.conf.server nel
modo seguente:
a. Quando si utilizza il protocollo TCP e si configura il server per la
consolidazione dei propri syslog, sostituire il token
<%UDP_LOOPBACK_SOURCE%> con:
source s_syslog_udp { udp(port(514)); };
Sostituire il token <%UDP_LOOPBACK_LOG%> con:
log { source(s_syslog_udp); destination(d_syslog_tcp); };
Ciò farà sì che il daemon di consolidazione syslog-ng legga i messaggi
UDP locali di syslogd e li invii a syslog-ng nella porta TCP locale.
Facoltativamente, è possibile impostare la destinazione direttamente
al file di consolidazione locale, (destination(d_syslog) in questo
modello predefinito), ma la configurazione di cui sopra imposta i
componenti client del server di consolidazione nello stesso modo di un
client remoto. In altre parole, quando il sistema di consolidazione è
client di se stesso, è configurato identicamente ai client remoti.
Utilizzando il protocollo UDP oppure non consolidando i syslog locali
di questo cluster, eliminare i token <%UDP_LOOPBACK_SOURCE%> e
<%UDP_LOOPBACK_LOG%>.
Capitolo 3
211
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
b. Sostituire i token <%TYPE%> con udp o tcp, secondo il tipo desiderato di
trasporto dei registri. Quando si utilizzano dei client TCP, se è
configurata la consolidazione dei syslog locali del cluster saranno
supportati anche quelli UDP. Sono presenti più righe che contengono il
token <%TYPE%>, e tutte devono essere modificate on modo adeguato.
c. Nella riga “source s_syslog_<%TYPE%>”, sostituire i token
<%PORT%> e <%KEEP_ALIVE%> con i valori adeguati:
source s_syslog_<%TYPE%>
{<%TYPE%>(port(<%PORT%>)<%KEEP_ALIVE%>); };
Per TCP, la porta deve essere una porta TCP disponibile in tutti i
membri del cluster. Per una discussione sulla selezione di una porta
disponibile, vedere la sezione “Configurazione con clog_wizard di un
server di consolidazione dei registri eventi indipendente” a
pagina 189. Per UDP, usare la porta 514.
<%KEEP_ALIVE%> si applica solamente scegliendo TCP per il trasporto
dei registri eventi. Sostituire questo token con “keep-alive(yes)”,
che indica a syslog-ng di tenere aperta la connessione quando
ripeterà la lettura del suo file di configurazione. Utilizzando UDP,
eliminare questo token.
d. Nella riga destination d_syslog_<%TYPE%>, sostituire i token
<%IP%> e <%PORT%>:
destination d_syslog_<%TYPE%> { <%TYPE%>(“<%IP%>” port(<%PORT%>)); };
Ad esempio, per TCP:
destination d_syslog_tcp { tcp(“IP_pacchetto” port(1776)); };
dove <%IP%> è sostituito dall’indirizzo IP o dal nome host di clog e
<%PORT%> è sostituito dal numero della porta TCP selezionata.
Per UDP:
destination d_syslog_udp { udp(“IP_pacchetto” port(514)); };
dove <%IP%> è sostituito dall’indirizzo IP del pacchetto clog oppure dal
nome host ed il token <%PORT%> è sostituito da 514, la porta UDP
standard di syslog.
e. Sostituire il token <%FS%> con il filesystem oppure la directory dove si
troveranno i registri eventi consolidati. Questo filesystem, o directory,
è quello gestito dal pacchetto di Serviceguard. Ad esempio:
destination d_syslog { file(“<%FS%>/syslog/syslog.log”); };
212
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
diventa:
destination d_syslog { file(“/clog/syslog/syslog.log”); };
Accertarsi che il punto di montaggio di questo filesystem esista in tutto
il cluster e che il recupero dagli errori per l’archiviazione operi nel
cluster in modo corretto. Dato che i registri eventi consolidati possono
diventare facilmente di dimensioni notevoli, HP consiglia di utilizzare
l’opzione “largefiles” per tale filesystem e di lasciare spazio libero
disponibile.
Per ulteriori informazioni sulla creazione della configurazione di
archiviazione e filesystem di Serviceguard per un pacchetto,
consultare il manuale Managing Serviceguard.
Punto
3. Sostituire manualmente i token in /etc/syslog-ng.conf.client nel
modo seguente:
a. Configurando il cluster per la consolidazione dei propri syslog,
sostituire il token <%UDP_LOOPBACK_SOURCE%> con:
source s_syslog_udp { udp(port(514)); };
Sostituire il token <%UDP_LOOPBACK_LOG%> con:
log { source(s_syslog_udp); destination(d_syslog_<tipo>); };
dove <tipo> è tcp oppure udp, secondo il tipo di trasporto desiderato
per i registri eventi.
Ciò farà sì che syslog-ng legga i messaggi locali UDP di syslogd e li
invii al server di consolidazione dei registri eventi.
Se non si desidera la consolidazione dei syslog locali di questo cluster,
eliminare i token <%UDP_LOOPBACK_SOURCE%> e
<%UDP_LOOPBACK_LOG%>.
b. Sostituire tutti i token <%TYPE%> con tcp o con udp, secondo il tipo
desiderato di trasporto dei registri eventi.
c. Cercare la riga: “destination d_syslog_<%TYPE%>{
<%TYPE%>(“<%IP%>”port(<%PORT>%>)); };.”
Sostituire <%IP%> con l’indirizzo IP del pacchetto clog. Per TCP,
sostituire <%PORT%> con la porta TCP selezionata per l’inoltro dei
registri eventi (selezionata prima). Per UDP, sostituire <%PORT%> con
514, la porta UDP standard.
Capitolo 3
213
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
4. La procedura di avvio di syslog-ng, /sbin/init.d/syslog-ng, usa
varie variabili di configurazione. Modificare
/etc/rc.config.d/syslog-ng nel modo seguente:
a. Modificare la riga CLOG_CONFIGURED in:
CLOG_CONFIGURED=1
b. Aggiungere le righe seguenti:
CLOG_CONSOLIDATOR=1
Se si utilizza il protocollo TCP, aggiungere:
CLOG_TCP=1
CLOG_TCP_PORT=<porta tcp scelta per la consolidazione dei registri>
altrimenti, se si utilizza il protocollo UDP, aggiungere:
CLOG_TCP=0
Se si consolidano i syslog locali, aggiungere:
CLOG_SYSLOG=1
altrimenti aggiungere:
CLOG_SYSLOG=0
Se si consolidano i registri eventi dei pacchetti di questo cluster,
aggiungere:
CLOG_PACKAGE=1
altrimenti
CLOG_PACKAGE=0
c. Aggiungere i due seguenti valori, che sono utilizzati da the System Log
Viewer:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
Punto
5. Tutti i file fin qui modificati devono essere distribuiti nel cluster:
# ccp /etc/syslog-ng.conf.server /etc/
# ccp /etc/syslog-ng.conf.client /etc/
# ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/
214
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
clog_tcp
6. Quando si utilizza TCP, scrivere nel file /etc/services il numero della
porta selezionata prima. Ad esempio, aggiungere la riga:
1776/tcp
# Registrazione eventi consolidata con syslog-ng
Aggiungere questa riga al file /etc/services in ogni membro del cluster.
Creazione del
pacchetto clog
#
#
#
#
#
Per creare la registrazione eventi consolidata oppure il pacchetto clog,
iniziare copiando i modelli del pacchetto:
mkdir /etc/cmcluster/clog
cd /etc/cmcluster/clog
cp /opt/dsau/share/serviceguard/templates/clog.conf.template clog.conf
cp /opt/dsau/share/serviceguard/templates/clog.script.template clog
chmod +x clog
Sia il file di configurazione del pacchetto clog.conf sia lo script di
controllo del pacchetto clog devono essere modificati, sostituendo i token
con i valori correnti.
In clog.conf c’è un solo token da sostituire, <%SG_PKG_SUBNET%>. Questo
identifica la sottorete del pacchetto. È il medesimo valore di sottorete
dello script di controllo del pacchetto. Per identificare la sottorete corretta
per l’indirizzo IP del pacchetto, utilizzare netstat -i.
Nello script di controllo del pacchetto, clog, eseguire le modifiche
descritte oltre.
Il modello predefinito dello script presume che si utilizzi una
configurazione d’archiviazione LVM. Sostituire i token per gruppo di
volumi e filesystem con i valori adatti per la configurazione
d’archiviazione del pacchetto, nel modo seguente:
Punto
1. Cercare la riga “VG[0]=“<%SG_PKG_VOL_GRP%>”” e sostituire il token con
il nome del gruppo di volumi LVM del pacchetto. Ad esempio:
VG[0]=“vgclog”
Se si usa VxVM, rimuovere il carattere di commento della riga per il
gruppo di volumi LVM VG[0]=”<%SG_PKG_VOL_GRP%>”. Rimuovere il
commento dalla riga “VXVM_DG[0]=” ed immettere il gruppo di dischi
VxVM.
Punto
2. Cercare la riga “LV[0]=“<%SG_PKG_LOG_VOL%>”” e sostituire il token con
il nome completo del volume logico. Ad esempio:
LV[0]=“/dev/vgclog/lvol1”
Capitolo 3
215
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
3. Cercare la riga “FS[0]=“<%SG_PKG_FS%>”” e sostituire il token con il
nome del filesystem creato per questo pacchetto. Ad esempio:
FS[0]=“/clog”
Tutti i registri eventi consolidati si troveranno in questo filesystem. La
posizione specifica dei registri eventi consolidati dei pacchetti e dei syslog
consolidati è specificata nel file /etc/syslog-ng.conf.server.
Utilizzando /clog come esempio, le posizioni predefinite in base al file
/etc/syslog-ng.conf.server modello sono:
/clog/syslog/syslog.log
/clog/packages/<nome_pacchetto>.log
Punto
4. Cercare la riga “FS_MOUNT_OPT[0]=“<%SG_PKG_MNT_OPT%>”: ” e
sostituire il token con le opzioni di montaggio del filesystem. Ad esempio:
FS_MOUNT_OPT[0]=-o rw,largefiles
Punto
5. Cercare la riga “FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>”” e sostituire il
token con il tipo di filesystem. Ad esempio:
FS_TYPE[0]=vxfs
Punto
6. Cercare la riga “FS_UMOUNT_OPT[0]=“<%SG_PKG_FS_UMOUNT_OPT%>”” e
sostituire il token con le opzioni di umount per il filesystem. Il token può
essere rimosso e questa opzione lasciata in bianco nel caso non vi siano
particolari opzioni per umount. Ad esempio:
FS_UMOUNT_OPT[0]=“”
Punto
7. Cercare la riga “FS_FSCK_OPT[0]=“<%SG_PKG_FS_FSCK_OPT%>”” e
sostituire il token con le opzioni di fsck specifiche per il filesystem. È
possibile eliminare il token e lasciare questa opzione in bianco. Ad
esempio:
FS_FSCK_OPT[0]=
Punto
8. Cercare la riga “IP[0]=“<%SG_PKG_IP%>””e sostituire il token con
l’indirizzo IP del pacchetto clog. Ad esempio:
IP[0]= 192.119.152.3
Punto
9. Cercare la riga “SUBNET[0]=“<%SG_PKG_SUBNET%>”” e sostituire il token
con la sottorete dell’indirizzo IP del pacchetto. Per identificare la
sottorete, utilizzare netstat -i. Ad esempio:
SUBNET[0]= 192.119.152.0
216
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Ora sarà necessario distribuire i file del pacchetto nel cluster. Per fare ciò,
eseguire le operazioni seguenti:
Punto
1. Distribuire i file del pacchetto nel cluster. Per prima cosa, creare la
directory per il pacchetto in tutti gli altri membri:
# cexec mkdir /etc/cmcluster/clog
Punto
2. Copiare lo script di controllo ed i file ASCII di configurazione del
pacchetto:
# ccp clog clog.conf /etc/cmcluster/clog/
Punto
3. Aggiornare il file /etc/rc.config.d/syslog-ng, aggiungendo le righe
seguenti:
CLOG_PKG_VOL_GRP=<gruppo volumi LVM>
CLOG_PKG_LOG_VOL=<volume logico (percorso completo)>
CLOG_PKG_FS=<punto di montaggio del filesystem dove archiviare i file di log
consolidati>
CLOG_PKG_MNT_OPT=<opzioni di montaggio del filesystem, come -o rw,largefiles>
CLOG_PKG_FS_TYPE=<tipo di filesystem>
CLOG_PKG_IP=<indirizzo IP del pacchetto clog>
CLOG_PKG_SUBNET=<sottorete dell’indirizzo IP del pacchetto clog>
CLOG_SYSTEM_LOG_CONSOLIDATION_DIR=<punto di montaggio del filesystem/syslog>
CLOG_SERVICEGUARD_PACKAGE_LOG_CONSOLIDATION_DIR=<punto di montaggio di
filesystem/packages>
CLOG_PKG_RETRY_TIMES=1
CLOG_PKG_MONITOR_INTERVAL=5
Punto
4. Distribuirlo nel cluster:
# ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/
Prova ed avvio del Prima di avviare il pacchetto, provare la configurazione:
pacchetto clog
Punto
1. Eseguire /opt/dsau/sbin/syslog-ng con l’opzione -s oppure quella
--syntax-only, per controllare la sintassi dei file
/etc/syslog-ng.conf.server e /etc/syslog-ng.conf.client. Nel
nodo adottivo del pacchetto, sarà creato un collegamento simbolico di
nome /etc/syslog-ng.conf ed esso punterà al file .server. Nei membri
rimanenti del cluster, il collegamento simbolico punterà al file .client.
Dato che il pacchetto non è ancora in esecuzione, utilizzare syslog-ng per
controllare in modo esplicito ogni file, nel modo seguente:
# /opt/dsau/sbin/syslog-ng --syntax-only --cfgfile /etc/syslog-ng.conf.server
# /opt/dsau/sbin/syslog-ng --syntax-only --cfgfile /etc/syslog-ng.conf.client
Capitolo 3
217
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Se tutte le modifiche sono state applicate correttamente, non saranno
visualizzati errori.
Punto
2. Avviare syslog-ng in ogni membro del cluster. Ogni syslog-ng sarà
avviato come client d’inoltro dei registri eventi:
# cexec /sbin/init.d/syslog-ng start
Utilizzare il comando ps per il cluster, cps, per convalidare il corretto
avvio di tutti i daemon:
# cps -ef | grep syslog-ng
Dovrebbe essere visibile un daemon syslog-ng in esecuzione in ogni
membro del cluster.
Punto
3. Creare il pacchetto clog:
# cd /etc/cmcluster/clog/
# cmapplyconf -P clog.conf
Serviceguard convaliderà la configurazione del pacchetto e segnalerà
eventuali errori. Correggere gli errori e riprovare.
Punto
4. Avviare il pacchetto clog:
# cmmodpkg -e clog
Utilizzare quindi cmviewcl per accertarsi che sia in esecuzione:
# cmviewcl -p clog
In caso di problemi eseguendo il pacchetto, per un aiuto nel risolverli,
controllare i file /etc/cmcluster/clog/clog.log in ogni membro.
Punto
5. Controllare che l’inoltro dei registri eventi funzioni correttamente. Se si
consolidano i syslog locali del cluster, utilizzare “logger
<messaggio_di_prova>” ed accertarsi che questo messaggio si trovi nel
syslog.log consolidato. Se non si stanno consolidando i registri eventi
locali, utilizzare il comando logger da un client di inoltro dei registri.
I messaggi del comando logger sono prima inviati al syslogd locale, il
quale li inoltra a syslog-ng. Per impostazione predefinita, syslogd
elimina i messaggi duplicati. Se si creano più messaggi di prova per
logger, assicurarsi che siano unici. Il messaggio di logger dovrebbe
essere presente nel file syslog.log consolidato locale, nella directory
specificata nel file /etc/syslog-ng.conf.server. Negli esempi
precedenti, questa directory dovrebbe essere /clog/syslog/syslog.log.
218
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Se si consolidano i registri eventi dei pacchetti di questo cluster, qualsiasi
azione del pacchetto che generi informazioni per i registri eventi, come un
suo recupero da un errore, dovrebbe fare sì che l’evento sia registrato in
/clog/packages.
Il modello predefinito dello script del pacchetto clog presume che si utilizzi
l’archiviazione LVM. Per utilizzare invece l’archiviazione VxVM, è
necessario modificare lo script del pacchetto clog, in
/etc/cmcluster/clog/clog. Inserire il carattere di commento per la
riga del gruppo di volumi LVM “VG[0]=“xxx””, rimuoverlo dalla riga
“VXVM_DG[0]=”, ed immettere il gruppo di dischi VxVM.
Uso di VxVM al
posto di LVM
Configurazione manuale dei client per l’inoltro dei registri eventi
Nella configurazione di un client per l’inoltro dei registri eventi, è
possibile farlo come sistema indipendente o come cluster Serviceguard. In
ogni caso saranno impostati sia syslogd, sia syslog-ng.
Configurazione
manuale di un
client indipendente per l’inoltro
dei registri eventi
Punto
1. Cominciare configurando il daemon syslogd standard per coesistere con
il daemon di inoltro syslog-ng.
a. Per impostazione predefinita, syslogd è in ascolto per i messaggi dei
registri in arrivo nella porta UDP 514. Se si desidera inoltrare i syslog
di questo sistema, syslog-ng deve essere in ascolto nella porta UDP
514. Modificare /etc/rc.config.d/syslogd e cambiare
SYSLOGD_OPTS aggiungendo l’opzione -N, che impedisce a syslogd
l’ascolto nella porta 514. Ad esempio:
SYSLOGD_OPTS=“-D -N”
b. Modificare il file /etc/syslog.conf per inoltrare i messaggi dei
registri eventi alla porta 514 nell’host locale, dove saranno letti da
syslog-ng. Utilizzando come esempio il file /etc/syslog.conf
predefinito di HP-UX, aggiungere le righe seguenti:
mail.debug
*.info;mail.none
Capitolo 3
@<nome host completamente qualificato>
@<nome host completamente qualificato>
219
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo sistema. Il nome deve essere
completamente qualificato, oppure syslogd non inoltrerà
correttamente i messaggi.
Se syslog.conf è stato personalizzato, accertarsi di aggiungere anche
le righe per l’inoltro nella propria personalizzazione.
c. Affinché queste modifiche abbiano effetto, fermare e riavviare
syslogd:
# /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start
Punto
2. Per configurare syslog-ng, cominciare con il medesimo modello di
syslog-ng.conf utilizzato da clog_wizard.
Copiare /opt/dsau/share/clog/templates/syslog-ng.conf.client
.template in /etc/syslog-ng.conf.client. Questo file contiene dei
token, nella forma <%nome_token%>, che sono sostituiti dalla procedura
guidata in base alle risposte dell’amministratore alle sue domande.
Sostituire manualmente i token in /etc/syslog-ng.conf.client nel
modo seguente:
a. Configurando il sistema per l’inoltro dei propri syslog al server di
consolidazione, sostituire il token <%UDP_LOOPBACK_SOURCE%> con:
source s_syslog_udp { udp(port(514)); };
Sostituire il token <%UDP_LOOPBACK_LOG%> con:
log { source(s_syslog_udp); destination(d_syslog_<tipo>); };
dove <tipo> è tcp oppure udp secondo il tipo di trasporto desiderato.
Ciò farà sì che syslog-ng legga i messaggi locali UDP di syslogd e li
invii al server di consolidazione dei registri eventi. Se non si desidera
la consolidazione dei syslog locali di questo sistema, eliminare i token
<%UDP_LOOPBACK_SOURCE%> e <%UDP_LOOPBACK_LOG%>.
b. Sostituire tutti i token <%TYPE%> con tcp o con udp, secondo il tipo
desiderato di trasporto dei registri eventi.
c. Cercare la riga
“destination d_syslog_<%TYPE%>{<%TYPE%>(“<%IP%>” port(<%PORT%>)); };”
220
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Se si utilizza il protocollo UDP, sostituire <%IP%> con l’indirizzo IP del
server di consolidazione dei registri eventi e <%PORT%> con 514, la
porta UDP standard.
Se si utilizza il protocollo TCP con il port forwarding ssh, sostituire
<%IP%> con 127.0.0.1 e <%PORT%> con la porta scelta per il port
forwarding ssh. Per questa porta si applica il medesimo criterio per la
scelta della porta TCP libera per syslog-ng. Per i dettagli, consultare
la sezione “Configurazione con clog_wizard di un server di
consolidazione dei registri eventi indipendente” a pagina 189. È
necessario che tra questo sistema e quello di consolidazione dei registri
eventi sia stata imposta l’autenticazione non interattiva di secure
shell (per la sua configurazione, è possibile utilizzare lo strumento
/opt/dsau/bin/csshsetup). Per i dettagli, vedere “Port forwarding
ssh” a pagina 233.
Se si utilizza il protocollo TCP senza il port forwarding di ssh,
sostituire <%IP%> con l’indirizzo IP del server di consolidazione dei
registri eventi e <%PORT%> con la porta TCP scelta nel sistema di
consolidazione per questa operazione.
d. Creare il collegamento simbolico seguente:
ln -sf /etc/syslog-ng.conf.client /etc/syslog-ng.conf
Punto
3. La procedura di avvio di syslog-ng, /sbin/init.d/syslog-ng, usa
varie variabili di configurazione. Modificare
/etc/rc.config.d/syslog-ng nel modo seguente:
a. Modificare la riga CLOG_CONFIGURED in:
CLOG_CONFIGURED=1
b. Aggiungere le righe seguenti:
CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=<indirizzo IP del sistema di consolidazione>
c. Se si utilizza il protocollo TCP, aggiungere le righe seguenti:
CLOG_TCP=1
CLOG_TCP_PORT=<porta tcp del server di consolidazione dei
registri eventi>
Se si utilizza il port forwarding di ssh, aggiungere:
CLOG_SSH=1
CLOG_SSH_PORT=<porta ssh scelta>
Capitolo 3
221
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
altrimenti, utilizzare:
CLOG_SSH=0
altrimenti, se si utilizza il protocollo UDP, utilizzare:
CLOG_TCP=0
Se si consolidano i syslog locali, utilizzare:
CLOG_SYSLOG=1
altrimenti, utilizzare:
CLOG_SYSLOG=0
Punto
4. Quando si utilizza TCP con il port forwarding di ssh, scrivere nel file
/etc/services il numero della porta ssh che è stata scelta prima. Ad
esempio, aggiungere la riga:
clog_ssh 1776/tcp
# Registrazione eventi consolidata con
port forwarding di ssh
Aggiungere questa riga al file /etc/services di questo sistema.
Punto
5. Provare la configurazione eseguendo le operazioni seguenti:
a. Eseguire /opt/dsau/sbin/syslog-ng con l’opzione -s oppure quella
--syntax-only, per controllare la sintassi del file
/etc/syslog-ng.conf. Questo dovrebbe essere un collegamento
simbolico a /etc/syslog-ng.conf.client, come descritto prima.
b. Avviare syslog-ng utilizzando il comando seguente:
# /sbin/init.d/syslog-ng start
c. Se si consolidano i syslog locali, utilizzare “logger
<messaggio_di_prova>” ed accertarsi che questo messaggio si trovi
nel syslog.log consolidato nel server di consolidazione dei registri
eventi. I messaggi del comando logger sono prima inviati al syslog
locale, il quale li inoltra a syslog-ng. Per impostazione predefinita,
syslogd elimina i messaggi duplicati. Se si creano più messaggi di
prova per logger, assicurarsi che siano unici.
222
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Configurazione
manuale di un
cluster Serviceguard come client
per l’inoltro dei
registri eventi
Punto
La configurazione di un cluster Serviceguard come client d’inoltro dei
registri eventi è simile a quella di un sistema singolo. Tutti i membri del
cluster devono essere operativi quando si esegue questa procedura
guidata. Per prima cosa sarà configurato syslogd, quindi syslog-ng.
Creare in ogni membro del cluster i file di configurazione descritti oltre.
L’approccio più semplice è di configurare completamente un membro e
quindi copiare ogni file di configurazione in tutto il cluster. Gli strumenti
cexec e ccp sono in grado di semplificare la replicazione nel cluster delle
modifiche.
1. Se si desidera che i messaggi di syslog per il cluster siano inoltrati al
sistema di consolidazione dei registri eventi, eseguire:
a. Cominciare configurando il daemon syslogd standard per coesistere
con il daemon di inoltro syslog-ng. Per impostazione predefinita,
syslogd è in ascolto per i messaggi dei registri in arrivo nella porta
UDP 514. Per inoltrare i syslog di questo cluster, syslog-ng deve
essere in ascolto nella porta UDP 514. Modificare
/etc/rc.config.d/syslogd e cambiare SYSLOGD_OPTS aggiungendo
l’opzione -N; ciò impedirà a syslogd l’ascolto nella porta 514. Ad
esempio,
SYSLOGD_OPTS=“-D -N”
b. Modificare il file /etc/syslog.conf in modo da inoltrare i messaggi dei
registri eventi alla porta 514 nell’host locale, dove saranno letti da
syslog-ng. Utilizzando come esempio il file /etc/syslog.conf predefinito
di HP-UX, aggiungere le righe seguenti:
mail.debug
qualificato>
*.info;mail.none
qualificato>
@<nome host completamente
@<nome host completamente
dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo membro del cluster. Questo nome
deve essere completamente qualificato, oppure syslogd non inoltrerà
correttamente i messaggi.
Se syslog.conf è stato personalizzato, accertarsi di aggiungere anche
le righe per l’inoltro nella propria personalizzazione.
Capitolo 3
223
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
c. Affinché queste modifiche abbiano effetto, sarà necessario fermare e
riavviare syslogd:
# /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start
d. Dato che /etc/rc.config.d/syslogd è generico, può essere
distribuito in tutto il cluster utilizzando ccp:
# cpp /etc/rc.config.d/syslogd /etc/rc.config.d/
e. Il file /etc/syslog.conf è specifico per ogni membro e le modifiche
descritte prima dovranno essere eseguite in ogni membro del cluster.
f. Eseguendo le modifiche di cui sopra in ogni membro del cluster, sarà
necessario riavviare syslogd perché queste abbiano effetto. Per fare
ciò, utilizzare cexec in tutti i membri del cluster:
# cexec “/sbin/init.d/syslogd stop;/sbin/init.d/syslogd start”
Punto
2. Per configurare syslog-ng, cominciare con il medesimo modello di
syslog-ng.conf utilizzato da clog_wizard.
In un membro del cluster, copiare
/opt/dsau/share/clog/templates/syslog-ng.conf.client.template
in /etc/syslog-ng.conf.client. Questo file contiene dei token, nella
forma <%nome_token%>, che sono sostituiti dalla procedura guidata in
base alle risposte dell’amministratore alle sue domande.
Sostituire manualmente i token in /etc/syslog-ng.conf.client nel
modo seguente:
a. Configurando il cluster per l’inoltro dei propri syslog al server di
consolidazione, sostituire il token <%UDP_LOOPBACK_SOURCE%> con:
source s_syslog_udp { udp(port(514)); };
Sostituire il token <%UDP_LOOPBACK_LOG%> con:
log { source(s_syslog_udp); destination(d_syslog_<tipo>); };
dove <tipo> è tcp oppure udp secondo il tipo di trasporto desiderato
per i registri eventi. Ciò farà sì che syslog-ng legga i messaggi locali
UDP di syslogd e li invii al server di consolidazione dei registri eventi.
Se non si desidera la consolidazione dei syslog locali di questo cluster,
eliminare i token <%UDP_LOOPBACK_SOURCE%> e
<%UDP_LOOPBACK_LOG%>.
b. Sostituire tutti i token <%TYPE%> con tcp o con udp, secondo il tipo
desiderato di trasporto dei registri eventi.
224
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
c. Cercare la riga
“destination d_syslog_<%TYPE%>{<%TYPE%>(“<%IP%>”
port(<%PORT%>)); };”
Se si utilizza il protocollo UDP, sostituire <%IP%> con l’indirizzo IP del
server di consolidazione dei registri eventi e <%PORT%> con 514, la
porta UDP standard. Se si utilizza il protocollo TCP con il port
forwarding ssh, sostituire <%IP%> con 127.0.0.1 e <%PORT%> con la
porta scelta per il port forwarding ssh. Per questa porta si applica il
medesimo criterio per la scelta della porta TCP libera per syslog-ng.
Per i dettagli, vedere “Configurazione con clog_wizard di un server di
consolidazione dei registri eventi indipendente” a pagina 189. (La
porta selezionata ssh deve essere libera in tutti i membri del cluster.)
È necessario che tra ogni membro di questo cluster ed il sistema di
consolidazione dei registri eventi sia stata imposta l’autenticazione
non interattiva di secure shell (per la sua configurazione, è possibile
utilizzare lo strumento /opt/dsau/bin/csshsetup). Per i dettagli,
vedere “Port forwarding ssh” a pagina 233.
Se si utilizza il protocollo TCP senza il port forwarding di ssh,
sostituire <%IP%> con l’indirizzo IP del server di consolidazione dei
registri eventi e <%PORT%> con la porta TCP scelta nel sistema di
consolidazione per questa operazione.
Punto
3. La procedura di avvio di syslog-ng, /sbin/init.d/syslog-ng, usa
varie variabili di configurazione. Modificare
/etc/rc.config.d/syslog-ng nel modo seguente:
a. Modificare la riga CLOG_CONFIGURED in:
CLOG_CONFIGURED=1
b. Aggiungere le righe seguenti:
CLOG_CONSOLIDATOR=0
CLOG_CONS_IP=<indirizzo IP del sistema di consolidazione>
c. Se si utilizza il protocollo TCP, aggiungere le righe seguenti:
CLOG_TCP=1
CLOG_TCP_PORT=<porta tcp del server di consolidazione dei registri eventi>
Se si utilizza il port forwarding di ssh, aggiungere:
CLOG_SSH=1
CLOG_SSH_PORT=<porta ssh scelta>
Capitolo 3
225
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
altrimenti aggiungere:
CLOG_SSH=0
altrimenti, se si utilizza il protocollo UDP, aggiungere:
CLOG_TCP=0
Se si consolidano i syslog locali, aggiungere:
CLOG_SYSLOG=1
altrimenti aggiungere:
CLOG_SYSLOG=0
Se si consolidano i registri eventi dei pacchetti di questo cluster,
aggiungere:
CLOG_PACKAGE=1
altrimenti aggiungere:
CLOG_PACKAGE=0
Punto
4. Tutti i file fin qui modificati devono essere distribuiti nel cluster:
# ccp /etc/syslog-ng.conf.client /etc/
# ccp /etc/rc.config.d/syslog-ng /etc/rc.config.d/
Creare il seguente collegamento simbolico in ogni membro del cluster:
# ln -sf /etc/syslog-ng.conf.client /etc/syslog-ng.conf
Punto
5. Quando si utilizza TCP con il port forwarding di ssh, scrivere nel file
/etc/services il numero della porta ssh che è stata scelta prima. Ad
esempio, aggiungere la riga:
clog_ssh 1776/tcp
forwarding di ssh
# Registrazione eventi consolidata con port
Aggiungere questa riga al file /etc/services in ogni membro del cluster.
Punto
226
6. Per consolidare i registri eventi dei pacchetti del cluster, sono necessarie
delle ulteriori operazioni manuali del server di consolidazione dei registri
eventi. Sarà necessario eseguire queste operazioni ogni volta che in
questo cluster sarà eliminato o aggiunto un pacchetto. Consultare
“Consolidazione dei registri eventi dei pacchetti nel server di
consolidazione” a pagina 227.
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
7. Provare la configurazione eseguendo le operazioni seguenti:
a. Eseguire /opt/dsau/sbin/syslog-ng con l’opzione -s oppure quella
--syntax-only, per controllare la sintassi del file
/etc/syslog-ng.conf. Questo dovrebbe essere un collegamento
simbolico a /etc/syslog-ng.conf.client, come descritto prima.
b. Avviare syslog-ng in tutti i membri del cluster utilizzando
# cexec “/sbin/init.d/syslog-ng start”
c. Se si consolidano i syslog locali, utilizzare “logger
<messaggio_di_prova>” ed accertarsi che questo messaggio si trovi
nel syslog.log consolidato nel server di consolidazione dei registri
eventi. I messaggi del comando logger sono prima inviati al syslog
locale, il quale li inoltra a syslog-ng. Per impostazione predefinita,
syslogd elimina i messaggi duplicati. Se si creano più messaggi di
prova per logger, assicurarsi che siano unici.
Consolidazione
dei registri eventi
dei pacchetti nel
server di
consolidazione
Punto
Per consolidare i registri eventi dei pacchetti inoltrati dai client del
cluster al server di consolidazione dei registri eventi, nel server sarà
necessario eseguire le operazioni seguenti:
1. Per ogni pacchetto che sarà inoltrato dal client cluster, aggiungere al file
syslog-ng.conf.server le seguenti righe per destinazione, filtri e
registri eventi, dopo la sezione
HP_AUTOMATED_LOG_FILE_CONSOLIDATION.
destination d_<cluster_1>_<pacchetto_1> {
file(“<fs>/packages/<cluster_1>_<pacchetto_1>.log”); };
filter f_<cluster_1>_<pacchetto_1> { program(<cluster_1>_<pacchetto_1>.log); };
log { source(s_syslog_<tipo>);
filter(f_<cluster_1>_<pacchetto_1>);destination(d_<cluster_1>_<pacchetto_1>);
flags(final);};
dove <pacchetto_1> è il nome del pacchetto, <cluster_1> è l’alias del
cluster che sta inoltrando i registri eventi del pacchetto, e <fs> è il
filesystem del sistema di consolidazione dove sono archiviati i registri
eventi consolidati.
Punto
2. Se il sistema di consolidazione è un cluster Serviceguard, assicurarsi di
copiare il file /etc/syslog-ng.conf.server così modificato nel cluster,
nel modo seguente:
# ccp /etc/syslog-ng.conf.server /etc/
Capitolo 3
227
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
3. Eseguire sighup syslog-ng nel sistema di consolidazione, in modo che
rilegga il suo file di configurazione. (sighup è un metodo UNIX per
riavviare un processo.) Nel cluster Serviceguard di consolidazione,
eseguire sighup syslog-ng solamente nel nodo adottivo del pacchetto
clog.
Punto
4. Per ogni pacchetto che è stato eliminato dal client cluster che esegue
l’inoltro dei registri eventi dei pacchetti, eliminare le righe per
destinazione, filtro e registro eventi corrispondenti dal file
/etc/syslog-ng.conf.server del sistema di consolidazione. Sarà
necessario eseguire sighup per syslog-ng nel sistema di consolidazione,
in modo da ricaricare il file di configurazione. Nel sistema di
consolidazione di Serviceguard, il file aggiornato
/etc/syslog-ng.conf.server dovrà essere distribuito nel cluster.
Tuttavia, l’esecuzione di sighup per syslog-ng dovrà avvenire solamente
nel nodo adottivo del pacchetto clog.
Disattivazione della consolidazione dei registri eventi
clog_wizard consente la configurazione della consolidazione dei registri
eventi ma non dispone di un’opzione per la deconfigurazione. Sarà quindi
necessario disattivare manualmente un sistema perché non partecipi alla
consolidazione dei registrazione eventi, seguendo queste istruzioni.
Disattivazione di un sistema indipendente di consolidazione dei
registri eventi
Per deconfigurare la consolidazione dei registri eventi, eseguire le
operazioni seguenti:
Punto
1. Nel caso che siano consolidati i syslog locali, oppure che sia utilizzato il
protocollo UDP, modificare /etc/rc.config.d/syslogd e cambiare
SYSLOGD_OPTS rimuovendo l’opzione -N. Ad esempio, eseguire la modifica
seguente:
SYSLOGD_OPTS=“-D”
Punto
2. Nel caso che i syslog locali fossero consolidati, modificare anche il file
/etc/syslog.conf del sistema, rimuovendo le righe seguenti:
mail.debug
*.info;mail.none
@<nome host completamente qualificato>
@<nome host completamente qualificato>
dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo sistema.
228
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
3. Riavviare syslogd, utilizzando il comando seguente:
#/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start
Punto
4. Fermare syslog-ng:
# /sbin/init.d/syslog-ng stop
Punto
5. Modificare il file /etc/rc.config.d/syslog-ng nel modo seguente:
a. Cambiare la riga CLOG_CONFIGURED in CLOG_CONFIGURED=0.
b. Rimuovere tutte le altre righe CLOG, tranne:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
Punto
clog_tcp
6. Nel caso che sia utilizzato il protocollo TCP, rimuovere da /etc/services
le righe seguenti:
<porta>/tcp # Registrazione eventi consolidata con syslog-ng
Disattivazione di un sistema di consolidazione dei registri eventi
in un cluster Serviceguard
Per deconfigurare la consolidazione dei registri eventi in un cluster
Serviceguard, eseguire le operazioni seguenti: Queste operazioni
dovranno essere eseguite in ogni membro del cluster:
Punto
1. Nel caso che siano consolidati i syslog locali, oppure che sia utilizzato il
protocollo UDP, modificare /etc/rc.config.d/syslogd e cambiare
SYSLOGD_OPTS rimuovendo l’opzione -N. Per esempio:
SYSLOG_OPTS="-D"
Punto
2. Riavviare syslogd con il comando seguente:
#/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start
Punto
3. Nel caso che i syslog locali fossero consolidati, modificare il file
/etc/syslog.conf del sistema, rimuovendo le righe seguenti:
mail.debug
*.info;mail.none
@<nome host completamente qualificato>
@<nome host completamente qualificato>
Dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo sistema. Il carattere @ è preceduto
da quello <tab>.
Capitolo 3
229
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
4. Fermare il pacchetto clog con il comando:
#/usr/sbin/cmhaltpkg clog
Punto
5. Fermare syslog-ng con il comando seguente:
# /sbin/init.d/syslog-ng stop
(Questo arresterà il daemon syslog-ng e la consolidazione dei registri
eventi dei pacchetti, se configurata.)
Punto
6. Modificare il file /etc/rc.config.d/syslog-ng e cambiare la riga
CLOG_CONFIGURED nel modo seguente:
CLOG_CONFIGURED=0
Rimuovere tutte le altre righe CLOG, tranne:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
Punto
7. Eliminare il pacchetto clog con il comando seguente:
# cmdeleteconf -p clog
Disattivazione di un client indipendente per l’inoltro dei registri
eventi
Per deconfigurare l’inoltro dei registri eventi in un client indipendente,
eseguire le operazioni seguenti:
Punto
1. Nel caso che i messaggi syslog fossero inoltrati al sistema di
consolidazione, modificare /etc/rc.config.d/syslogd e cambiare
SYSLOGD_OPTS rimuovendo l’opzione -N. Ad esempio,
SYSLOGD_OPTS=“-D”
Punto
2. Modificare il file /etc/syslog.conf del sistema, rimuovendo le righe
seguenti:
mail.debug
*.info;mail.none
@<nome host completamente qualificato>
@<nome host completamente qualificato>
dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo sistema. Prima di ogni carattere @ è
presente quello <tab>.
230
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
3. Riavviare syslogd con il comando seguente:
#/sbin/init.d/syslogd stop
#/sbin/init.d/syslogd start
Punto
4. Fermare syslog-ng con il comando seguente:
# /sbin/init.d/syslog-ng stop
(Questo arresterà il daemon syslog-ng ed anche il port forwarding ssh,
se configurato.)
Punto
5. Modificare il file /etc/rc.config.d/syslog-ng e cambiare la riga
CLOG_CONFIGURED nel modo seguente:
CLOG_CONFIGURED=0
Rimuovere tutte le altre righe CLOG, tranne:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
Punto
6. Nel caso che sia stato configurato il port forwarding ssh, rimuovere da
/etc/services la riga seguente:
clog_ssh <porta>/tcp
# Registrazione eventi consolidata con
port forwarding di ssh
Disattivazione di un client per l’inoltro dei registri eventi in un
cluster Serviceguard
Per deconfigurare l’inoltro dei registri eventi, eseguire le operazioni
seguenti: Queste operazioni dovranno essere eseguite in ogni membro del
cluster:
Punto
1. Nel caso che i messaggi syslog fossero inoltrati al sistema di
consolidazione, modificare /etc/rc.config.d/syslogd e cambiare
SYSLOGD_OPTS rimuovendo l’opzione -N. Ad esempio,
SYSLOGD_OPTS=“-D”.
Punto
2. Modificare il file /etc/syslog.conf del sistema, rimuovendo le righe
seguenti:
mail.debug
*.info;mail.none
@<nome host completamente qualificato>
@<nome host completamente qualificato>
dove <nome host completamente qualificato> è il nome host
completamente qualificato di questo sistema.
Capitolo 3
231
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Punto
3. Fermare e riavviare syslogd con i comandi seguenti:
# /sbin/init.d/syslogd stop
# /sbin/init.d/syslogd start
Punto
4. Fermare syslog-ng:
# /sbin/init.d/syslog-ng stop
(Questo arresterà il daemon syslog-ng ed il port forwarding ssh e
l’inoltro dei registri eventi dei pacchetti, se configurati.)
Punto
5. Modificare il file /etc/rc.config.d/syslog-ng e cambiare la riga
CLOG_CONFIGURED in CLOG_CONFIGURED=0. Rimuovere tutte le altre righe
CLOG, tranne:
CLOG_LAYOUTS_DIR=/var/opt/dsau/layouts
CLOG_ADDITIONAL_LOG_DIRS[0]=/var/adm/syslog
Punto
clog_ssh
ssh
6. Nel caso che sia stato configurato il port forwarding ssh, rimuovere da
/etc/services la riga seguente:
<porta>/tcp
# Registrazione eventi consolidata con port forwarding di
Protezione dei registri eventi consolidati
In un sistema HP-UX standard, tutti gli utenti sono in grado di
visualizzare il file locale di sistema /var/adm/syslog/syslog.log.
L’accesso ai registri eventi consolidati è in genere soggetto a limitazioni. Il
server di consolidazione dei registri eventi stesso è un sistema ad accesso
limitato, con criteri di protezione rigorosi.
Protezione del file di log
Un livello di protezione sono le autorizzazioni dei file di log consolidati
stessi. Questo è controllato tramite il file syslog-ng.conf.server. È
possibile specificare le autorizzazioni per ogni “file” syslog-ng di
destinazione. Se la directory dei registri eventi di un file consolidato non
dovesse esistere, è possibile indicare a syslog-ng di crearla,
(create_dirs(yes)) e di impostare anche i permessi e la proprietà della
directory. Ad esempio,
destination d_file { file(“/clog/test/esempio.log” );
dir_owner(root);
dir_group(sys);
232
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
dir_perm(0600);
owner(root);
group(sys);
perm(0600);
};
Port forwarding ssh
Il port forwarding ssh imposta un canale crittografato per il trasferimento dei registri eventi tra il daemon syslog-ng del client d’inoltro ed il
daemon syslog-ng del server di consolidazione. Questo canale basato su
ssh è disponibile solamente quando si utilizza il trasporto TCP, non con
UDP. Inoltre, il port forwarding ssh non è utilizzato per inoltrare il trasferimento dei registrazione eventi all’interno di un cluster Serviceguard
(da membro a membro). Per il traffico all’interno del cluster, sono utilizzati i protocolli TCP o UDP standard.
Il port forwarding ssh è trasparente per syslog-ng. Il file
/etc/syslog-ng.conf.client è configurato in modo tale che syslog-ng
inoltri il trasferimento dei registri eventi alla porta locale gestita da ssh.
L’istanza locale di ssh si connette a quella remota di sshd, nel server di
consolidazione dei registri eventi, quindi sshd apre la porta TCP standard
di syslog-ng. Il sistema remoto di consolidazione dei registrazione eventi
crede che si tratti di un client standard di inoltro dei registri eventi e non
si rende conto del canale di comunicazione aperto.
Un problema di questo canale di ssh è l’eventuale guasto del server di
consolidazione dei registri eventi. In caso di arresto normale oppure
anomalo del server di syslog-ng, il canale ssh remoto sarà interrotto. Il
canale ssh del client ritenterà la connessione ad intervalli di un minuto.
Il periodo di riconnessione è configurabile.
Ogni tentativo di riconnessione andato a vuoto è registrato nel
syslog.log locale del client. Durante questo tempo, il file di log client di
syslog-ng (/var/adm/syslog/syslog-ng.log) mostrerà i tentativi di
riconnessione del canale. Il periodo di riconnessione predefinito è di 10
secondi. Ciò è configurabile tramite l’impostazione globale di syslog-ng
“time_reopen(<secondi>)”. Per i dettagli, vedere il manuale open
source di syslog-ng (/opt/dsau/doc/syslog-ng).
Capitolo 3
233
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Port forwarding
ssh verso un
server di
consolidazione in
un cluster
Serviceguard
Quando si utilizza il port forwarding ssh con un cluster Serviceguard
come server di consolidazione dei registri eventi, è necessaria una speciale
configurazione per ssh.
In generale, l’uso del port forwarding ssh richiede che il server di
consolidazione dei registri eventi esegua lo scambio di chiavi con il client
inoltrante i registri eventi. In particolare, la chiave pubblica di ssh del
client remoto che esegue l’inoltro deve essere aggiunta al file delle chiavi
autorizzate del server di consolidazione. Inoltre, l’impronta digitale del
server di consolidazione è aggiunta al file /.ssh/known_hosts del client
di inoltro. Dopo questo scambio di chiavi, il client inoltrante i registri
eventi sarà un sistema fidato, a questo punto il server di consolidazione
server non dovrà richiedere la password per ssh.
Dato che il server di consolidazione è un pacchetto, potenzialmente
potrebbe essere eseguito in ogni membro del cluster. Questo scambio di
chiavi tra il client remoto inoltrante i registri eventi ed un membro del
cluster dovrà essere replicato per ogni membro. Ciascun membro del
cluster dovrà stabilire la medesima relazione di fiducia con i client di
inoltro dei registri eventi.
Potrebbe sorgere un problema con l’impronta digitale di del file
known_host del client d’inoltro dei registri eventi. Quando si utilizza
l’indirizzo IP riallocabile del pacchetto per lo scambio iniziale di chiavi per
ssh, l’impronta digitale del nodo adottivo sarà aggiunta al file
/.ssh/known_hosts locale del client. Quando il pacchetto esegue il recupero degli errori ed è ristabilita la connessione ssh, il nuovo nodo adottivo
avrà un’impronta digitale differente e ssh interpreterà questo come un
attacco del tipo “man-in-the-middle” e rifiuterà di ristabilire il canale ssh.
Per impedire questa situazione, dal punto di vista dei client di inoltro dei
registri eventi, ogni membro del cluster dovrà apparire come se fosse il
medesimo sistema. Questo potrà essere ottenuto facendo sì che ciascun
membro del cluster usi un’identica chiave host. Le chiavi host per ssh si
trovano in /opt/ssh/etc e sono contenute nei file seguenti:
•
•
•
•
•
•
234
ssh_host_key
ssh_host_key.pub
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Scegliere uno dei membri del cluster e copiare questi file nella medesima
directory degli altri membri. Utilizzare lo strumento “cluster copy” oppure
quello cpp è un modo rapido per farlo, con i comandi seguenti:
# cd /opt/ssh/etc/
# ccp ssh_host_* /opt/ssh/etc/
Eseguire quindi in ogni client di consolidazione dei registri eventi lo
scambio standard di ssh con l’indirizzo IP riallocabile del pacchetto clog.
Un modo di fare ciò è utilizzare lo strumento csshsetup (vedere csshsetup
(1)), nel modo seguente:
# csshsetup <nome DNS del pacchetto clog>
Per eseguire lo scambio iniziale di chiavi, csshsetup chiederà la password
del cluster.
Uso di Bastille per rafforzare il sistema
Bastille è uno strumento di rafforzamento della protezione, che è possibile
usare per migliorare la sicurezza del sistema operativo HP-UX. Fornisce
il bloccaggio personalizzato sistema per sistema, consentendo
all’amministratore di scegliere da elenchi di controllo per rafforzamento e
bloccaggio quali funzionalità di protezione attivare o disattivare.
È possibile utilizzare Bastille per rafforzare un server di consolidazione
dei registri eventi. Abilitando i filtri IP, sarà necessario lasciare aperte le
seguenti porte per syslog e per syslog-ng:
Capitolo 3
•
UDP 514 – questa porta è utilizzata dai client syslogd per l’inoltro dei
messaggi dei registri eventi
•
Porta TCP <numero_porta> – l’amministratore sceglie quale porta
TCP il sistema di consolidazione dei registri eventi syslog-ng utilizza
per la ricezione dei messaggi.
•
Porta TCP 22 – quando si utilizza il port forwarding ssh per creare dei
canali crittografati, i client remoti comunicano con il daemon sshd del
server di consolidazione dei registri eventi. In una configurazione
predefinita, questo daemon è in ascolto nella porta TCP 22.
235
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Visualizzazione dei registri eventi consolidati
Per visualizzare e filtrare i file di log syslog locali del sistema, utilizzare
System Log Viewer di System Management Homepage. In un sistema che
sia anche di consolidazione dei registri eventi, System Log Viewer è in
grado di visualizzare e filtrare i registri eventi consolidati.
Avvio di System Management Homepage
Per eseguire l’accesso a System Management Homepage, andare a:
http://nome_host:2301
Immettere nome utente e password. Per impostazione predefinita, è
abilitato l’accesso di root. Per ulteriori informazioni su avvio ed accesso a
System Management Homepage, consultare HP Systems Management
Homepage User Guide.
Dopo avere eseguito l’accesso a System Management Homepage, scegliere
la scheda Logs, quindi “System Log Viewer.”
Uso di System Log System Log Viewer mostrerà i registri eventi correlati a syslog del
Viewer
sistema. Per impostazione predefinita, sono compresi i registri eventi
locali del sistema in /var/adm/syslog. Se questo sistema consolida i
registri eventi, saranno anch’essi elencati.
NOTA
In un cluster Serviceguard configurato come server di consolidazione dei
registri eventi, questi si troveranno nel filesystem associato al pacchetto
“clog”. Per ulteriori informazioni, vedere “Note sulla configurazione del
cluster”. Quando si utilizzano configurazioni d’archiviazione LVM e
VxVM di recupero dagli errori, i registri eventi consolidati saranno
accessibili per un solo membro del cluster alla volta. Per stabilire in quale
membro del cluster è al momento in esecuzione il pacchetto clog, utilizzare
cmvviewcl ed avviare System Management Homepage in quel sistema e
visualizzare i registri eventi consolidati.
Scegliere il registro eventi da visualizzare dalla scheda principale Select.
Per la ricerca di voci specifiche, utilizzare la scheda Filter per specificare
le espressioni di filtraggio, quindi scegliere la scheda Display per
visualizzare il contenuto del registro eventi. Per ulteriori informazioni
sull’uso di System Log Viewer, utilizzare la guida in linea, disponibile
nell’applicazione.
236
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Introduzione a Command Fanout
Le utility Command fanout consentono all’amministratore di sistema di
replicare in più sistemi i comandi della shell. Usualmente, per fornire le
funzioni di distribuzione dei comandi, gli amministratori avevano creato
dei wrapper per strumenti come la shell remota (vedere remsh (1)) e la
shell protetta (vedere ssh (1)).
Parallel Distributed Shell
Distributed Systems Administration Utilities (DSAU) contiene lo
strumento open souce Parallel Distributed Shell (pdsh). pdsh formalizza
l’utilizzo di remsh e di ssh per la distribuzione dei comandi in gruppi di
sistemi. Diversamente dai wrapper remsh/ssh, pdsh offre i vantaggi
seguenti:
•
Alte prestazioni
I comandi sono eseguiti in parallelo in gruppi di sistemi di
destinazione. Per controllare il numero di comandi simultanei, pdsh
supporta una finestra scorrevole o impostazione di distribuzione.
•
Impostazioni per il timeout dei comandi
pdsh supporta il timeout per l’esecuzione dei comandi, il quale
controlla per quanto tempo un comando sarà eseguito remotamente
prima di essere disconnesso (per impedire il blocco dei programmi a
causa di problemi). Supporta inoltre un timeout di connessione che
impedisce il blocco quando i sistemi remoti sono irraggiungibili.
•
Elaborazione dell’output e restituzione dello stato
pdsh gestisce correttamente l’elaborazione di stdout e stderr e
supporta la restituzione della condizione “peggiore di”, in modo che il
chiamante sia in grado di rilevare gli errori nei sistemi remoti.
•
Specificazione flessibile dei sistemi di destinazione
pdsh supporta vari meccanismi per specificare gli hosts di
destinazione in cui operare. Possono essere specificati nella riga dei
comandi, in stdin, in un file noto (/etc/machines) oppure in un file
specificato nella variabile ambientale WCOLL. Nella riga dei comandi è
anche possibile escludere determinati sistemi.
Capitolo 3
237
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Espressioni per elenchi host
Per gruppi di sistemi che utilizzano una convenzione di nomenclatura
del tipo prefisso_NNN (ad esempio, h1, h2, ..., hN), pdsh consente di
specificare i nodi di destinazione utilizzando espressioni come
“h[1-10]”, che distribuiscono il comando negli host di nome da h1 fino
a h10.
•
Filtro intelligente dell’output
pdsh antepone ad ogni riga di output il nome host del sistema di
origine. dshbak (vedere dshbak (8)) è un filtro in grado di formattare
l’output standard di pdsh in vari modi. Il flag dshbak -c cerca
l’output dei vari host che è identico e lo consolida invece di duplicarlo.
L’intestazione indicherà gli host per i quali si applica l’output
consolidato.
•
Scelta del trasporto del comando
pdsh è in grado di utilizzare come trasporto dei comandi la shell
remota rcmd (vedere rcmd (3)) oppure ssh. Il trasporto di ssh offre
una protezione molto migliorata. Per i dettagli, vedere
“Configurazione di sicurezza” a pagina 240.
•
Comando di copia parallela
Il comando pdcp offre la copia parallela per copiare un file d’origine
locale in più destinazioni.
La Figura 3-4, “Architettura di pdsh” mostra i componenti di pdsh e la sua
architettura.
238
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Figura 3-4
Architettura di pdsh
Per ulteriori informazioni su pdsh e su dshbak, consultare le relative
manpage.
Wrapper dell’utility pdsh
Per quei comandi che sono di uso frequente in sistemi multipli e cluster
Serviceguard, gli amministratori possono realizzare dei comandi wrapper
per pdsh. Molti di questi comandi wrapper sono forniti con DSAU. Questi
wrapper sono previsti per i cluster Serviceguard e la loro impostazione
predefinita è di distribuire i comandi in tutto il cluster quando sono
utilizzati in ambiente Serviceguard. Questi wrapper supportano la
maggior parte delle opzioni standard di pdsh nella riga dei comandi e
supportano anche la sintassi estesa delle opzioni (--opzione) .
cexec
Capitolo 3
cexec è un wrapper per pdsh di uso generico. Oltre alle
funzionalità standard di pdsh, cexec ne comprende una
per la creazione di rapporti. Per ottenere la
visualizzazione con cexec dell’ubicazione del rapporto
di un comando, utilizzare l’opzione --report_loc. Il
239
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
rapporto del comando registra i comandi eseguiti, oltre
ai nodi in cui il la sua esecuzione è stata positiva, errata,
oppure i nodi irraggiungibili. Il rapporto può essere
utilizzato con l’opzione --retry, per ripetere il comando
nei nodi in cui la sua esecuzione è fallita, è riuscita, in
quelli irraggiungibili, oppure in tutti i nodi.
ccp
ccp è un wrapper per pdcp e copia i file in tutto il
cluster, oppure nel gruppo di sistemi specificato.
cps
cps distribuisce il comando ps in un gruppo di sistemi o
in un cluster.
ckill
ckill consente agli amministratori di segnalare un
processo tramite il suo nome, dato che il pid di un dato
processo varierà in un gruppo di sistemi o tra i membri
di un cluster.
cuptime
cuptime visualizza le statistiche del tempo di attività di
un gruppo di sistemi o di un cluster.
Tutti i wrapper, quando non sono eseguiti in un cluster Serviceguard,
supportano la variabile ambientale CFANOUT_HOSTS. La variabile
ambientale specifica un file che contiene l’elenco degli host di
destinazione, un nome host per riga. Sarà utilizzato quando nella riga dei
comandi non è presente nessuna altra specificazione degli host. Quando
nella riga dei comandi non è utilizzata un’opzione per l’elenco dei nodi di
destinazione e CFANOUT_HOSTS non è stata definita, il comando sarà
eseguito nell’host locale.
Per ulteriori informazioni su questi comandi, consultare le relative
manpage.
Configurazione di sicurezza
Gli strumenti per la distribuzione dei comandi supportano i trasporti sia
della shell remota (rsh oppure rcmd) sia di ssh. Per autorizzare l’utente
che avvia l’operazione di distribuzione dei comandi ed eseguirne uno nel
sistema remoto di destinazione, ognuna richiede delle specifiche
operazioni di configurazione. Gli strumenti di distribuzione dei comandi
richiedono che il sistema remoto non chieda la password. Per consentire
questo accesso non interattivo, sia il trasporto di rsh, sia di ssh dovranno
essere preconfigurati in ogni sistema remoto. Le sezioni seguenti
descrivono le operazioni di configurazione necessarie per abilitare le
operazioni di distribuzione dei comandi per ogni tipo di trasporto.
240
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Impostazione della Quando si utilizza il trasporto dei comandi con la shell remota, il file
protezione per la
$HOME/.rhosts dell’utente locale deve essere configurato in ogni sistema
shell remota
remoto di destinazione. Per i dettagli sulla configurazione del file
$HOME/.rhosts, consultare la manpage rhosts (4).
Impostazione della ssh utilizza le chiavi pubbliche dell’host per l’autenticazione degli host
protezione per ssh remoti e supporta l’autenticazione della chiave pubblica per autenticare
gli utenti . Quando le chiavi pubbliche degli utenti sono configurate
correttamente in un gruppo di sistemi remoti, questi saranno in grado di
accedervi senza che sia richiesta una password. La configurazione
manuale di ssh per l’accesso non interattivo è una procedura in più fasi,
in cui i file di configurazione di ssh saranno modificati in ogni sistema. Lo
strumento csshsetup semplifica moltissimo la configurazione della
relazione di fiducia per ssh.
Ad esempio, quando si utilizzano gli strumenti per la distribuzione dei
comandi in un cluster Serviceguard, in genere si desidera di poter
eseguire i comandi da un qualsiasi membro e di poterli indirizzare verso
qualsiasi altro membro. Questo richiede la distribuzione di n^2 chiavi
pubbliche per ssh. Cominciare creando un file di testo che elenchi i
membri del cluster, uno per riga. Eseguire csshsetup utilizzando questo
file. Questo comando deve essere eseguito solo una volta, dato che
configura ogni membro del cluster:
# csshsetup -r -f members_list.txt
L’opzione -r indica a csshsetup di distribuire le chiavi in modo condiviso
oppure in modo n^2. All’utente sarà chiesta la password in ogni host
remoto. Quindi csshsetup automatizzerà tutta la procedura di
distribuzione delle chiavi pubbliche.
L’uso di csshsetup non è specifico dei cluster Serviceguard; può essere
utilizzato per un qualsiasi gruppo di sistemi. Inoltre, non è necessario che
la relazione sia bidirezionale. Omettere l’opzione -r quando si imposta
una relazione di fiducia unidirezionale tra l’host corrente ed un gruppo di
host remoti di destinazione. Per ulteriori dettagli, consultare la manpage
csshsetup (1).
Note sulla
sicurezza
Il protocollo della shell remota è intrinsecamente insicuro. Si tratta del
protocollo utilizzato dai “comandi r” di Berkeley, rlogin, rcp, remsh,
eccetera. Per ragioni di pricipio, molti amministratori di sistema
disattivano l’uso dei comandi “r”. Ad esempio, lo strumento di
rafforzamento della protezione Bastille offre l’opzione predefinita per
disattivare questi servizi non sicuri. Se disattivati, l’opzione pdsh -R rsh
per utilizzare il trasporto della shell remota non funzionerà.
Capitolo 3
241
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
Se i servizi “r” non sono stati disattivati, l’uso dell’opzione pdsh -R rsh da
parte di utenti non privilegiati sarà comunque disattivato per
impostazione predefinita, a causa dell’intrinseco rischio per la sicurezza.
Per impostazione predefinita, solamente gli utenti con autorizzazioni di
root saranno in grado di utilizzare l’opzione pdsh -R rsh. Questo perché le
chiamate alla libreria rcmd della shell remota richiedono l’uso di una
porta privilegiata. Anche se gli utenti privilegiati possono utilizzare -R
rsh, il trasporto ssh è comunque preferibile.
Se nel proprio ambiente gli host e gli utenti sono fidati, sarà possibile
abilitare l’uso dell’opzione pdsh -R rsh per gli utenti non privilegiati con
i comandi seguenti:
# cd /opt/dsau/bin/pdsh
# chown root:bin pdsh
# chmod u+s pdsh
Risoluzione dei problemi della distribuzione dei comandi
Questa sezione contiene suggerimenti per la risoluzione dei problemi per
i più comuni messaggi d’errore prodotti a pdsh e dai comandi wrapper.
Quando si utilizza il trasporto dei comandi ssh, potrebbero essere
visualizzati i seguenti messaggi d’errore:
•
Messaggi del trasporto dei comandi ssh:
— [email protected]<nome_host_locale>: <nome_host_destinazione>: ssh
exited with exit code 1
Motivo: il sistema di destinazione è irraggiungibile.
— [email protected]<nome_host_locale>: <nome_host_destinazione>: ssh
exited with exit code 255
Motivo: questo messaggio è emesso quando il nome host di
destinazione è sconosciuto, oppure l’indirizzo IP dell’host di
destinazione in /etc/hosts è errato. Il codice di uscita 255 è
quello utilizzato da ssh stesso quando incontra un errore.
242
Capitolo 3
Configurazione di un sistema
Utilizzo di Distributed Systems Administration Utilities
•
Messaggi del trasporto dei comandi rsh:
— [email protected]<nome_host_locale>:
gethostbyname(“<nome_host_destinazione>”) failed
Motivo: il nome host è sconosciuto.
— [email protected]<nome_host_locale>: <nome_host_destinazione>:
connect: Connection refused
Motivo: il sistema di destinazione è irraggiungibile. In questo
sistema i servizi “r” potrebbero essere stati disattivati.
— [email protected]<nome_host_locale>: <nome_host_destinazione>:
connect: timed out
Motivo: il nome host esiste (la ricerca dell’indirizzo IP è riuscita)
ma il sistema non è in funzione o non è raggiungibile.
— rresvport: bind: Permission denied
[email protected]<nome_host_locale>: <nome_host_locale>: rcmd:
socket: Permission denied
Motivo: un utente non privilegiato sta tentando di utilizzare il
trasporto della shell remota. Per i dettagli su come consentire agli
utenti non privilegiati l’uso di pdsh con il trasporto della shell
remota, vedere la sezione “Note sulla sicurezza”.
— <nome_host_destinazione>: remshd: Login incorrect.
remote
Motivo: il file $HOME/.rhosts dell’utente nel sistema remoto non
consente l’accesso.
•
Messaggi d’errore del nodo di destinazione:
— <nome_host_destinazione>: sh: <nome_comando>: not
found
Motivo: Il comando non esiste nel nodo di destinazione. La shell
remota eseguita da pdsh dispone solamente di un percorso
minimale. Gli script d’accesso dell’utente non sono eseguiti nei
nodi remoti. Specificare i comandi utilizzando il percorso
completo.
Capitolo 3
243
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Controllo dell’accesso ad un sistema
È possibile controllare chi abbia accesso al proprio sistema, ai suoi file ed
ai suoi processi.
Gli utenti autorizzati accedono al sistema fornendo un nome utente (nome
di login) ed una password validi. Ogni utente è definito da una voce nel
file/etc/passwd. È possibile usare SAM per aggiungere, rimuovere,
disattivare, riattivare o modificare un account utente.
Per informazioni aggiuntive sulle password, consultare passwd (4) e
passwd (1). Per modificare manualmente le voci dell’account utente, usare
il comando /usr/sbin/vipw per modificare /etc/passwd; per i dettagli,
consultare vipw (1M).
Consultare anche “Amministrazione di un sistema: Gestione della
sicurezza del sistema” a pagina 753.
Aggiunta di utente ad un sistema
È possibile aggiungere un utente in molti modi.
•
“Uso di SAM per aggiungere un utente” a pagina 245.
•
“Aggiunta manuale di un utente” a pagina 246.
•
“Automatizzare il processo di aggiunta di un utente” a pagina 247.
Per aggiungere un utente, si realizzano le seguenti procedure:
❏
Assicurarsi che l’utente disponga di un UID esclusivo.
❏
Inserire una riga per l’utente nel file /etc/passwd.
❏
Creare una home directory per l’utente.
❏
Creare un ambiente per l’utente.
Prendere in considerazione la realizzazione delle seguenti procedure per
il nuovo utente.
244
•
Aggiunta di utente ad un gruppo. Consultare “Definizione di
appartenenza al gruppo” a pagina 249.
•
Aggiungere un utente alle liste di distribuzione della posta.
•
Aggiungere un utente ai sistemi di quota del disco.
Capitolo 3
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Uso di SAM per
aggiungere un
utente
Punto
•
Consentire all’utente di collegarsi ad altri sistemi senza una
password. Consultare “File $HOME/.rhosts” a pagina 394.
•
Importare directory remote usando NFS. Consultare “Condivisione di
file ed applicazioni attraverso NFS e ftp” a pagina 402.
•
Fornire accesso remoto ad un utente. Consultare “Concessione
dell’accesso a sistemi remoti” a pagina 394.
•
Configurare l’ambiente di login dell’utente. Consultare
“Personalizzazione degli ambienti del sistema e del login utente” a
pagina 271.
•
Provare il nuovo account.
Se si sta aggiungendo un utente su una macchina remota, prima di usare
SAM, digitare i seguenti comandi sulla macchina locale:
/usr/bin/X11/xhost +macchina_remota
export DISPLAY=propria_macchina_locale:0.0
1. Avviare SAM
Per avviare SAM, è possibile
•
digitare /usr/sbin/sam
oppure
•
Punto
usare CDE ed accedere ad Application Manager, fare doppio clic su
System_Admin e fare doppio clic su SAM.
2. Scegliere:
1. Accounts for Users and Groups
2. Users
3. Add... dal menu Actions
Punto
3. Completare i campi di testo. Usare un’identificativo utente esclusivo
(UID). Il proprio servizio potrebbe avere un programma per stabilire UID
esclusivi.
Punto
4. Fare clic su Primary Group Name... ed aggiungere l’utente al gruppo
primario ed agli altri gruppi.
Capitolo 3
245
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Punto
5. Fare clic su OK. Questa operazione apre la finestra della password.
Digitare una password e fare clic su OK. Inserire la password quando viene
richiesta e fare clic su OK.
Punto
6. Fare clic su OK nella finestra di dialogo Note .
Per vedere i passi che SAM esegue, scegliere Options/View SAM Log...
Quando si usa SAM per aggiungere un utente, SAM compie le seguenti
operazioni:
•
crea una voce nel file /etc/passwd per l’utente
•
crea una home directory per l’utente
•
copia i file di avvio (.cshrc, .exrc, .login, .profile) nella home
directory dell’utente
Aggiunta manuale Usare i seguenti passi per aggiungere un utente dalla riga di comando.
di un utente
Punto
1. Aggiungere l’utente al file /etc/passwd.
Come root, usare il comando /usr/sbin/vipw per modificare
/etc/passwd. Consultare vipw (1M), passwd (4) e passwd (1)
Ad esempio, si potrebbe voler aggiungere questa riga per l’utente tom:
tom:,..:102:20:,,,:/home/tom:/usr/bin/sh
Il default per la shell è un campo vuoto, il che fa in modo che il sistema usi
/sbin/sh come login. La “,..” nel campo della password richiederà che
tom imposti la sua password in occasione del suo primo collegamento.
IMPORTANTE
Punto
Notare che la shell per root non deve essere modificata da /sbin/sh.
2. Creare una home directory Ad esempio:
/usr/bin/mkdir /home/tom
Cambiare il possesso della directory nel nome dell’utente. Ad esempio:
/usr/bin/chown tom:users /home/tom
246
Capitolo 3
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Punto
Tabella 3-3
3. Assicurarsi che l’utente abbia i file di avvio della shell idonei da eseguire
al momento del collegamento. Le tre shell più diffuse dell’ambiente
HP-UX sono: shell POSIX, shell Korn e shell C. Ogni shell usa file di avvio
specifici.
File di avvio
Nome della
shell
Ubicazione
File di avvio
shell POSIX
/usr/bin/sh,
/sbin/sh
shell Korn
/usr/bin/ksh
.profile e gli eventuali file
specificati nella variabile di
ambiente ENV (per convenzione
.kshrc)
shell C
/usr/bin/csh
.login e .cshrc
È possibile creare file di avvio standard (modelli) che possono essere
copiati nelle directory degli utenti. La directory più di frequente usata a
tale scopo è /etc/skel.
Ad esempio:
cp /etc/skel/.profile /users/tom/.profile
Punto
4. Cambiare il possesso del file di avvio nell’account del nuovo utente. Ad
esempio:
/usr/bin/chown tom .profile
Punto
5. Aggiungere l’utente ad un gruppo di lavoro primario. Ad esempio:
/usr/bin/chgrp users tom
Automatizzare il processo di aggiunta di un utente
Quando si devono aggiungere vari utenti ad un sistema, è possibile
risparmiare tempo come segue:
Capitolo 3
•
Uso del modello SAM
•
Uso del comando useradd
247
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Uso del modello
SAM
Creare un modello contenente informazioni uniformi sugli account
iniziando SAM e poi scegliendo Users and Groups, facendo scendere il
menu Actions ed infine scegliendo User Templates e Create. Per i
dettagli, leggere la guida in linea di SAM.
Uso del comando
useradd
È possibile usare il comando useradd per aggiungere utenti, così come
usermod e userdel per modificarli e cancellarli. useradd ha la forma:
/usr/sbin/useradd [opzione] ... nome_utente
nome_utente è il nuovo nome di login per l’utente. Le opzioni sono
descritte nella Tabella 3-4. Consultare anche useradd (1M).
Tabella 3-4
Opzione
Opzioni useradd
Significato
-u uid
UID (per default, va sul numero maggiore successivo).
-g gruppo
Nome del gruppo primario o ID di gruppo. Il gruppo deve esistere.
Il default è 20.
-G gruppi
Lista separata da virgola dei gruppi secondari. I gruppi devono esistere.
-b dir_b
Directory di base di default per la home directory dell’utente. Il default
è /home.
-d dir
Nome del percorso della home directory. Il default è
dir_b/nome_utente.
-m
Creare la home directory /home oltre a definire l’utente.
-s shell
Shell. Il default è un campo vuoto, che per default va su /sbin/sh.
-c "commenti"
Nome completo o altri commenti. Spesso questo è una stringa separata
da virgola nella forma.
nome_completo,ubicazione,telefono_lavoro,telefono_casa
-k dir
Directory scheletro contenente i file di inizializzazione. Il default è
/etc/skel.
-e data
Data di scadenza dell’account. Non vi è alcun default. Richiede
sicurezza avanzata.
-f n
Numero di giorni in cui l’account può essere inattivo prima di essere
disabilitato. Richiede sicurezza avanzata.
248
Capitolo 3
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Il seguente comando crea un nuovo account utente, aggiunge Patrick al
gruppo di lavoro primario (denominato users), crea una home directory e
configura una shell Korn di default.
useradd -g users -m -k /etc/skel -s /usr/bin/ksh patrick
La voce risultante nel file /etc/passwd è:
patrick:*:104:20::/home/patrick:/usr/bin/ksh
È possibile creare uno script con tante istanze del comando useradd
quante ne siano necessarie. È possibile impostare default diversi con il
comando useradd -D.
Controllo dell’accesso del file
I gruppi di lavoro, i permessi del file ed il possesso del file determinano
tutti chi possa accedere ad un dato file. Consultare anche
“Amministrazione di un sistema: Gestione della sicurezza del sistema” a
pagina 753.
Definizione di appartenenza al gruppo
Gli utenti del sistema possono essere divisi in gruppi di lavoro in modo che
i file posseduti dai membri di un dato gruppo possano essere condivisi e
tuttavia restare protetti dall’accesso da parte di utenti che non sono membri del gruppo. Nel file /etc/passwd è incluso un numero di appartenenza
del gruppo primario sotto forma di una voce. Le informazioni sul gruppo
sono definite in /etc/group e /etc/logingroup.
Gli utenti che sono membri di più di un gruppo, come specificato in
/etc/group, possono modificare il loro gruppo attuale con il comando
/usr/bin/newgrp. Non occorre usare il comando newgrp se i gruppi di
utenti sono definiti in /etc/logingroup. Se non si dividono gli utenti del
sistema in gruppi di lavoro separati, è norma comune configurare un
gruppo (di solito denominato users) ed assegnare tutti gli utenti del
sistema a quel gruppo.
È possibile usare SAM per aggiungere, rimuovere o modificare
l’appartenenza al gruppo.
Per modificare manualmente l’appartenza al gruppo, modificare
/etc/group ed a scelta /etc/logingroup con un editor di testo, come vi.
Sebbene sia possibile inserire una password a livello di gruppo in
/etc/group, non si consiglia tale operazione. Per evitare di mantenere
file multipli, è possibile collegare /etc/logingroup a /etc/group. Per i
Capitolo 3
249
Configurazione di un sistema
Controllo dell’accesso ad un sistema
dettagli sui file /etc/group e /etc/logingroup, consultare la manpage
group (4). Per informazioni sul collegamento dei file, consultare la
manpage link (1M).
È possibile assegnare privilegi speciali ad un gruppo di utenti usando il
comando /usr/sbin/setprivgrp. Per informazioni, consultare
setprivgrp (1M), setprivgrp (2), getprivgrp (2), rtprio (2), plock (2), shmctl
(2), chown (1), chown (2), getprivgrp (1), plock (2), shmctl (2),lockf (2),
setuid (2), setgid (2) e setgid (2).
Impostazione dei permessi di accesso al file
Il comando /usr/bin/chmod modifica il tipo di accesso (privilegi di
lettura, scrittura ed esecuzione) per il possessore del file, i membri del
gruppo e tutti gli altri. Soltanto il possessore di un file (o il superutente)
può modificarne i privilegi di lettura, scrittura ed esecuzione. Per i
dettagli, consultare chmod (1).
Per default, i nuovi file hanno permesso di lettura/scrittura per chiunque
(-rw-rw-rw-) e le nuove directory hanno permesso di
lettura/scrittura/esecuzione per chiunque (drwxrwxrwx). I permessi di
default del file possono essere modificati usando il comando
/usr/bin/umask. Per i dettagli, consultare umask (1). Il default per i
sistemi sicuri è diverso, consultare “Impostazione del proprio sistema
sicuro” a pagina 805.
Impostazione del possesso per i file
Il comando /usr/bin/chown modifica il possesso del file. Per modificare il
possessore, occorre possedere il file o avere privilegi di superutente.
Il comando /usr/bin/chgrp modifica il possesso del gruppo di file. Per
modificare il gruppo, occorre possedere il file o avere privilegi di
superutente.
Per ulteriori informazioni, consultare chown (1) e chgrp (1).
Impostazione delle Liste di controllo dell’accesso
Le liste di controllo dell’accesso (ACL) offrono un grado superiore di
protezione del file rispetto ai permessi di accesso al file tradizionali. È
possibile usare le ACL per consentire o limitare l’accesso al file a singoli
utenti a prescindere dal gruppo di appartenenza degli utenti. Soltanto il
possessore di un file (o il superutente) può creare le ACL.
250
Capitolo 3
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Le ACL sono supportate sui file system JFS ed HFS, ma i comandi e parte
della semantica sono diversi. Su un file system JFS, usare setacl(1) per
impostare le ACL ed usare getacl(1) per visualizzarle. Su un file system
HFS, usare chacl(1) per impostare le ACL ed usare lsacl(1) per
visualizzarle. Per una discussione sulle ACL di JFS ed HFS, consultare
“Gestione dell’accesso a file e directory” a pagina 765. Per informazioni
aggiuntive sulle ACL di JFS, consultare setacl (1), getacl (1) e aclv (5). Per
informazioni aggiuntive sulle ACL di HFS, consultare lsacl (1), chacl (1) e
acl (5).
NOTA
Le liste di controllo dell’accesso sono supportate in JFS ad iniziare da
JFS 3.3, che è incluso con HP-UX 11i. È possibile ottenere JFS 3.3 per
HP-UX 11.00 dal Software Depot HP, http://software.hp.com.
Per vedere se JFS 3.3 è installato su un sistema HP-UX 11.00, eseguire
swlist -l fileset JFS
Se JFS 3.3 è installato, l’output includerà una lista dei set di file di JFS.
Nel caso in cui si ottenga un messaggio di errore, significa che JFS 3.3 non
è installato.
Controllo dell’uso e dei processi con i livelli di
esecuzione
Un livello di esecuzione è uno stato di funzionamento HP-UX in cui si
consente l’esecuzione ad un set specifico di processi. Questi processi e
livelli di esecuzione di default sono definiti nel file /etc/inittab.
I livelli di esecuzione sono:
Livello di esecuzione s
Modo operativo usato dagli amministratori di sistema
(spesso denominato “stato ad utente unico”). Questo
modo assicura che nessun altro si trovi sul sistema mentre si stanno realizzando le procedure di manutenzione
del sistema. In questo livello di esecuzione, l’unico
accesso al sistema avviene attraverso la console di
sistema da parte dell’utente di root. I soli processi in
esecuzione sul sistema possono essere la shell sulla console del sistema, i processi del daemon in background
avviati da /sbin/rc ed i processi richiamati dall’utente.
I comandi che richiedono un sistema inattivo (come
/sbin/fsck) devono essere eseguiti in livello di esecuzione s.
Capitolo 3
251
Configurazione di un sistema
Controllo dell’accesso ad un sistema
Livello di esecuzione 1
Avvia un sottoset di processi del sistema essenziali; è
possibile usarlo anche per realizzare procedure di
amministrazione del sistema.
Livello di esecuzione 2
Il modo operativo di solito denominato “stato
multiutente”. Questo modo consente a tutti gli utenti di
accedere al sistema.
Livello di esecuzione 3
Per server NFS. In questo modo, i file system NFS
possono essere esportati, secondo le necessità dei server
NFS.
Livello di esecuzione 4
Per utenti CDE. In questo modo, CDE è attivo. CDE è il
desktop di default su HP-UX 10.30 e successivi.
Il livello di esecuzione di default di solito è il livello di esecuzione 3 o 4, a
seconda del sistema. Il livello di esecuzione di default per CDE è 4.
Per stabilire il livello di esecuzione attuale del processo init, digitare:
who -r
È possibile aggiungere e modificare la sequenza dei processi che HP-UX
avvia a ciascun livello di esecuzione. Consultare “Personalizzazione
dell’avvio e dello spegnimento” a pagina 519. Consultare anche la
manpage inittab (4).
È possibile usare SAM per spegnere un sistema e modificare il livello di
esecuzione attuale nello stato ad utente unico. Usare i menu “Routine
Tasks” e “System Shutdown”.
Il superutente collegato alla console di sistema può anche modificare il
livello di esecuzione attuale con il comando /sbin/init, come segue:
1. Avvisare tutti gli utenti attualmente collegati. Ogniqualvolta si
modifica il livello di esecuzione del sistema, gli eventuali processi che
non hanno una voce di livello di esecuzione che coincida con il nuovo
livello di esecuzione saranno soppressi. Dopo l’invio di un segnale di
avvertimento automatico, vi è un periodo di proroga di 20 secondi.
252
Capitolo 3
Configurazione di un sistema
Controllo dell’accesso ad un sistema
2. Per modificare sul livello di esecuzione s, usare il comando
shutdown.
Per modificare su un livello di esecuzione diverso dal livello di
esecuzione s, usare il comando init .
Consultare shutdown (1M) ed init (1M).
ATTENZIONE
Usare soltanto il comando shutdown per modificare al livello di
esecuzione s (cioè, non specificare /sbin/init s). Il comando
shutdownporta il sistema in sicurezza al livello di esecuzione s senza
lasciare le risorse del sistema in uno stato di inutilizzo. Il comando
shutdown consente anche di specificare un periodo di proroga per fare in
modo che gli utenti possano terminare il loro lavoro prima della
disattivazione del sistema. Ad esempio, per entrare nel livello di
esecuzione s dopo aver concesso 30 secondi, inserire:
shutdown 30
Per spegnere immediatamente, inserire una delle seguenti voci:
shutdown now
shutdown 0
Non usare il livello di esecuzione 0; si tratta di un livello di esecuzione
speciale riservato all’installazione del sistema.
Per una maggior sicurezza, assicurarsi che i permessi (ed il possesso) per
i file /sbin/init ed /etc/inittab siano impostati come segue:
-r-xr-xr-x
-r--r--r--
Capitolo 3
bin
bin
bin
bin
/sbin/init
/etc/inittab
253
Configurazione di un sistema
Aggiunta di periferiche
Aggiunta di periferiche
Per aggiungere delle periferiche al sistema, consultare la seguente
documentazione:
•
Il manuale di installazione hardware fornito con la periferica.
•
Per le informazioni su PCI OL*, consultare il manuale Manuale del
supporto delle schede d'interfaccia OL* sui sistemi in grado di
supportare nPartizioni, consultare il manuale Guida alle partizioni di
sistema HP: Amministrazione delle nPartition.
PCI OL*, in precedenza noto come OLAR, è la funzionalità che
consente di aggiungere o rimuovere una scheda PCI senza dover
spegnere completamente l’intero sistema. L’hardware del sistema
combinato al supporto del sistema operativo consente il controllo
dell’alimentazione per slot. Invece di spegnere l’intero sistema, è
possibile spegnere l’alimentazione ad uno slot PCI specifico.
I dispositivi di chiusura ed i campanelli della PCI si riferiscono ai
dispositivi di chiusura ed ai pulsanti fisici che si trovano sul sistema
stesso che consente di abilitare o disabilitare l’alimentazione ad uno
slot PCI.
Le procedure per PCI OL* possono essere realizzate attraverso una
GUI, come pdweb o il Partition Manager, o attraverso i comandi di
HP-UX, come rad (olrad a partire da 11i v2). Sono tutte documentate
nei manuali precedenti.
Prima di tentare tali procedure, leggere i manuali sopra menzionati.
Spegnere l’alimentazione a certi slot PCI può avere effetti disastrosi;
ad esempio, se lo slot PCI si connette ad una root sulla quale non è
stato eseguito il mirroring o un disco di scambio, il sistema subirà un
crash. Inoltre, occorre verificare che la scheda I/O stessa disponga
della compatibilità funzionale OL* così come della compatibilità allo
slot PCI specifico; ad esempio, non è possibile inserire una scheda a
33 MHz su uno slot che esegue un bus a 66 MHz.
ATTENZIONE
•
254
Per le periferiche generali, consultare il manuale Configuring HP-UX
for Peripherals.
Capitolo 3
Configurazione di un sistema
Aggiunta di periferiche
•
Le HP-UX 11i Release Notes per i titoli dei documenti che potrebbero
essere importanti per installare le periferiche. Tali documenti
potrebbero contenere informazioni specifiche sul driver software ed il
file speciale del dispositivo per la comunicazione con periferiche
particolari.
Il modo più semplice per aggiungere delle periferiche è di eseguire SAM o
il Partition Manager per i sistemi in grado di supportare nPartizioni.
Tuttavia, è anche possibile aggiungere delle periferiche usando i comandi
di HP-UX.
Perché HP-UX comunichi con un nuovo dispositivo periferico, potrebbe
dover essere necessario riconfigurare la kernel del sistema per aggiungere
un nuovo driver. Se si usano i comandi di HP-UX, usare il comando
/usr/sbin/mk_kernel (che SAM usa). Per i dettagli, consultare
mk_kernel (1M), la guida in linea di SAM e “Riconfigurazione della kernel
(Prima di HP-UX 11i versione 2)” a pagina 284.
Configurazione di terminali non HP
Per informazioni dettagliate sulla configurazione di terminali non HP,
consultare Configuring HP-UX for Peripherals.
Per configurare un utente con un terminale non HP, procedere come
segue:
Punto
1. Assicurarsi che il set di file NONHPTERM si trovi sul sistema attraverso uno
dei seguenti metodi:
•
swlist -l fileset NonHP-Terminfo
Se il set di file esiste, sarà visualizzata la voce per
NonHP-Terminfo.NONHPTERM.
•
ll /var/adm/sw/products/NonHP-Terminfo
Se il set di file esiste, esisterà la directory
/var/adm/sw/products/NonHP-Terminfo/NONHPTERM.
Se il set di file non si trova sul sistema, occorrerà caricarlo dal supporto
HP-UX più recente. Per i dettagli, consultare “Gestione del software” a
pagina 726 o il Manuale di amministrazione di Software Distributor.
Capitolo 3
255
Configurazione di un sistema
Aggiunta di periferiche
Punto
2. Guardare nella directory /usr/share/lib/terminfo alla ricerca di un
file che corrisponda al terminale che si desidera configurare. Ad esempio,
supponiamo che si desideri configurare un utente con un terminale
Wyse™ 100. Tutti i terminali supportati i cui nomi iniziano con w sono
contenuti nella directory /usr/share/lib/terminfo/w. Poiché tale
directory contiene una voce wy100, probabilmente è stato trovato il file
corretto. Per esserne sicuri, esaminare i contenuti del file con more.
Comparirà una schermata di caratteri speciali, ma vicino all’inizio si
vedrà wy100|100|wyse 100. Questo controlla il file corretto e mostra che
è possibile fare riferimento al Wyse 100 mediante uno qualsiasi dei nomi
wy100, 100, o wyse 100.
Se esiste un file terminfo per il terminale che si desidera aggiungere,
ignorare il passo successivo e passare al Punto 4.
Se non esiste alcun file terminfo per il terminale che si desidera
aggiungere, occorrerà crearne uno. Per i dettagli, consultare il punto
successivo.
Punto
3. Per creare un file terminfo, seguire le istruzioni contenute in terminfo
(4).
Per adattare un file esistente, procedere come segue:
1. Collegarsi come superutente.
2. Creare una copia ASCII di un file terminfo esistente. Ad esempio,
creare una copia del file /usr/share/lib/terminfo/w/wy100
inserendo:
untic /usr/share/lib/terminfo/w/wy100 > nuovo_file
3. Modificare il nuovo file in modo che rispecchi le capacità del nuovo
terminale. Assicurarsi di modificare il/i nomi del terminale nella
prima riga.
4. Compilare il nuovo file terminfo:
tic nuovo_file
Per ulteriori informazioni, consultare tic (1M) ed untic (1M)
256
Capitolo 3
Configurazione di un sistema
Aggiunta di periferiche
Punto
4. Impostare la variabile dell’utente TERM nello script di login idoneo
(.profile per gli utenti della shell Korn e POSIX oppure .login per gli
utenti della shell C nelle loro home directory) su uno qualsiasi dei nomi
non trattati al Punto 2. Ad esempio:
export TERM=wy100 (shell Korn o POSIX)
setenv TERM wy100 (shell C)
Le versioni di default di questi script invitano l’utente a fornire il tipo di
terminale al momento del collegamento, quindi invece di modificare lo
script, è possibile dire semplicemente all’utente di rispondere con il nome
del terminale. Ad esempio:
TERM = (hp) wy100
È anche possibile impostare la variabile TERM con il comando
/sbin/ttytype.
Problemi di ricerca guasti con i terminali
Possono verificarsi un certo numero di problemi correlati ai terminali.
Molti di essi fanno sì che sembri che un terminale non comunichi con il
computer. Altri problemi provocano la comparsa di “rifiuti” sullo schermo
(al posto dei dati previsti o frammisti ai dati stessi).
Questa sezione si occupa principalmente dei problemi con i terminali a
display alfanumerico; tuttavia, molti dei passi discussi qui possono valere
anche per i problemi con gli emulatori di terminali tipo HP AdvanceLink
(in esecuzione su un PC Vectra) o i processi di terminali X Window (come
hpterm ed xterm). Consultare anche “Altri problemi del terminale” a
pagina 263.
Terminali che non rispondono
Sono molte le cause che possono provocare la mancata risposta da parte di
un terminale (nessun carattere visualizzato a parte, forse, quelli
visualizzati dall’impostazione del ritorno del terminale). Ecco una
procedura da usare per trovare molte di queste cause.
Punto
1. Verificare lo stato del sistema.
Il sistema è ancora attivo? Se non lo è, probabilmente è stato trovato il
problema. Occorrerà riavviare il sistema.
Capitolo 3
257
Configurazione di un sistema
Aggiunta di periferiche
Il sistema è in stato utente unico? In caso affermativo, il solo
terminale attivo sarà la console di sistema. Gli altri terminali non
risponderanno. Occorrerà passare ad uno stato multiutente. Consultare
la manpage init (1M) per ulteriori informazioni sulla modifica degli stati
di esecuzione.
Per verificare in quale stato di esecuzione si trovi il sistema (da un
terminale di lavoro), digitare:
NOTA
who -r
L’output avrà un aspetto simile al seguente:
.
system boot
Feb 10 07:10
2
0
S
Lo stato attuale della macchina è nel campo immediatamente a destra
dell’ora (terzo campo da destra). Per le informazioni complete su ciascuno
di questi campi, consultare la manpage who (1).
Punto
2. Verificare per vedere se sul terminale vi sia un editor in esecuzione.
Tale operazione si realizza al meglio da un altro terminale. Emettere il
comando:
ps -ef
Guardare nella colonna contrassegnata TTY per tutti i processi associati
al terminale con cui si stanno verificando dei problemi. Per ogni voce,
verificare nella colonna contrassegnata COMMAND per vedere se il
processo rappresentato da quella voce è un editor.
Nel caso in cui si scopra che un editor sta eseguendo sul terminale, è
probabilmente in un modo di inserimento testo. Occorrerà salvare il
lavoro ed uscire dall’editor. Per le istruzioni su come realizzare tale
operazione, consultare la manpage per l’editor del caso.
ATTENZIONE
258
Nel caso in cui non si fosse sicuri dello stato del lavoro in modifica, NON
salvare il file ed uscire semplicemente. I contenuti precedenti del file
saranno sovrascritti da testo sconosciuto. Salvare il lavoro in corso in un
file temporaneo in modo che sia la versione originale sia quella modificata
siano accessibili.
Capitolo 3
Configurazione di un sistema
Aggiunta di periferiche
Punto
3. Inserire ctrl-q sulla tastiera del terminale.
I terminali spesso usano il protocollo XON/XOFF per avviare ed arrestare
l’output inviato loro. Se l’output al terminale è stato arrestato perchè un
segnale XOFF (ctrl-s) è stato inviato dal terminale al computer, può essere
riavviato inviando al computer un segnale XON (digitare ctrl-q dalla
tastiera del terminale che presenta il problema). L’invio del segnale XON
non pregiudica alcunché, anche se in precedenza era stato inviato il
segnale XOFF.
Se il problema è un programma applicativo che è entrato in loop o non
funziona correttamente, tentare di premere il tasto break e poi tentare
ctrl-C per vedere se sia possibile ottenere di rimando un prompt della shell
(ctrl-C è il carattere di interrupt di default; si potrebbe usarne uno diverso).
Se occorre scoprire quale sia il carattere di interrupt per il terminale
interessato, andare al terminale di lavoro ed inserire il comando:
stty < /dev/nome_file_dispositivo_per_il_terminale_interessato
ATTENZIONE
Punto
Il comando stty precedente deve essere usato esclusivamente con i nomi
del dispositivo per i file del dispositivo del terminale attualmente attivo
(usare il comando who per vedere quali file del dispositivo siano attivi).
Nel caso in cui si tenti di eseguire stty con un file del dispositivo non
attivo, si provocherà il blocco del terminale in cui sono stati inseriti i
comandi.
4. Resettare il terminale.
Il terminale stesso si può bloccare in uno stato di inutilizzo. Tentare di
resettarlo. Per le informazioni sulle modalità di esecuzione di tale
operazione, consultare il proprio manuale utente. Il terminale si resetterà
anche spegnendolo, attendendo qualche secondo e riaccendendolo.
Punto
5. Verificare la configurazione del terminale.
Il terminale potrebbe non essere configurato correttamente. Occorre
verificare quanto segue:
•
•
•
•
Capitolo 3
Il terminale è in modo Remote *? Deve esserlo.
Il modo Block * è acceso (ON)? Non deve esserlo.
Il modo Line * è acceso (ON)? Non deve esserlo.
Il modo Modify * è acceso (ON)? Non deve esserlo.
259
Configurazione di un sistema
Aggiunta di periferiche
Punto
6. Verificare la connessione fisica.
Verificare per assicurasi che:
•
•
•
•
Punto
ATTENZIONE
tutti i cavi siano saldamente fissati e nelle corrette ubicazioni.
tutte le schede di interfaccia siano saldamente collocate nei rispettivi
slot.
il cavo di alimentazione al terminale sia saldamente connesso.
l’interruttore di alimentazione sia acceso.
7. Sopprimere i processi associati al terminale che presenta problemi.
Usare estrema cautela nel sopprimere i processi. I processi saranno
terminati immediatamente ed incondizionatamente. Alcuni processi
validi potrebbero impiegare un tempo notevole a completarsi. Assicurarsi
di digitare con attenzione quando si inseriscono i numeri PID per il
comando kill per evitare di sopprimere i processi errati.
Nel caso in cui vi sia un altro terminale ancora al lavoro, andare a tale
terminale e collegarsi (occorrerà essere supervisore). Eseguire il comando:
ps -ef
L’output avrà un aspetto simile al seguente:
UID
root
root
root
root
root
root
stevem
PID
95
94
22095
22977
14517
107
20133
PPID
1
0
1
1
1
1
1
C
0
0
0
0
0
0
0
STIME
Jul 20
Jul 20
13:29:17
14:42:28
Jul 21
Jul 20
11:20:24
TTY
?
tty0p5
?
?
ttyd1p4
?
ttyd2p5
TIME
0:00
0:00
0:00
0:00
0:01
0:00
0:00
COMMAND
/usr/sbin/getty
/usr/sbin/getty
/usr/sbin/getty
/usr/sbin/getty
-csh [csh]
/usr/sbin/getty
-csh [csh]
-h
-h
-h
-h
ttyd1p0
tty0p5
ttyd2p1
ttyd2p0
9600
9600
9600
9600
-h ttyd3p0 9600
Guardare nella colonna contrassegnata TTY per trovare i processi
associati al terminale con cui si stanno verificando dei problemi.
Guardare nella colonna contrassegnata PID per trovare le voci (sono gli ID
di processo per i processi associati a quel terminale). Eseguire il seguente
comando, che elenca ogni ID di processo associato al terminale che
presenta problemi:
kill -9 id_processo [id_processo]...
Se, nell’esempio precedente, si desiderava sopprimere i processi associati
al terminale ttyd2p5, occorreva eseguire il comando:
kill -9 20133
260
Capitolo 3
Configurazione di un sistema
Aggiunta di periferiche
Questo deve sopprimere tutti i processi associati a quel terminale. Il
processo init rigenererà poi un processo getty per quel terminale (se è
stato configurato per fare ciò, nel file /etc/inittab) e si dovrebbe essere
nuovamente in grado di collegarsi.
Punto
8. Tentare di collegarsi nuovamente al terminale in precedenza bloccato.
Se si riesce nell’operazione, significa che il problema è stato risolto. In
caso contrario, continuare con il passo successivo.
Punto
9. Usare cat per inviare un file ASCII al file del dispositivo del terminale
bloccato.
HP-UX comunica con le periferiche attraverso file del dispositivo. Questi
file speciali di solito si trovano nella directory /dev e sono usati da HP-UX
per stabilire quale driver occorra usare per comunicare con il dispositivo
(facendo riferimento al numero maggiore) e per stabilire l’indirizzo e
determinate caratteristiche del dispositivo con cui HP-UX sta
comunicando (facendo riferimento al numero minore).
Tentare di usare il comando cat per inviare un file ASCII (come
/etc/motd o /etc/issue) al file del dispositivo associato al terminale che
presenta problemi. Ad esempio, se il terminale che presenta problemi è
associato al file del dispositivo ttyd1p4:
cat /etc/motd > /dev/ttyd1p4
ci si deve aspettare di vedere i contenuti del file /etc/motd visualizzati
sul terminale associato al file del dispositivo /dev/ttyd1p4. In caso
contrario, continuare con il passo successivo.
Punto 10. Verificare i parametri del file del dispositivo per il terminale che presenta
problemi.
I file del dispositivo hanno permessi di accesso loro associati, proprio come
gli altri file. I permessi di accesso del file devono essere impostati in modo
da poter accedere al file. Se si imposta il modo dei permessi di accesso dei
file su 622 (crw--w--w-), si sarà al sicuro.
Se i permessi del file sono impostati in modo da consentire l’accesso di
scrittura ed il file non viene visualizzato sul terminale, verificare i numeri
maggiore e minore del file del dispositivo. È possibile elencarli con il
comando ll. È possibile usare il comando lssf per interpretare i numeri
maggiore e minore e visualizzare i risultati.
Capitolo 3
261
Configurazione di un sistema
Aggiunta di periferiche
Punto 11. Altre cose da verificare.
•
Assicurarsi che le voci inittab siano attive
Nel caso in cui si stia semplicemente aggiungendo questo terminale e
si sia creata una nuova voce nel file /etc/inittab modificandolo,
ricordarsi che l’operazione non rende automaticamente attiva la
nuova voce. Per fare ciò, occorre inserire il comando:
init -q
Questo dice al processo init di sottoporre a scansione il file
/etc/inittab per aggiornare le informazioni nelle sue tabelle
interne.
•
Verificare il funzionamento dell’hardware.
Ora, è il momento di verificare l’hardware. Per fare ciò, verificare le
seguenti parti:
— Se il terminale è dotato di una funzionalità di autodiagnosi,
attivarla. In caso contrario, spegnere il terminale, attendere
qualche secondo e riaccenderlo. Tale operazione eseguirà un
collaudo (almeno fino ad un certo punto) dell’hardware del
terminale.
— Un metodo alternativo per collaudare l’hardware del terminale è
di scambiare il terminale sospetto con uno del cui funzionamento
si sia certi. Tale operazione aiuterà ad identificare i problemi
all’interno del terminale che non sono stati rilevati
dall’autodiagnosi del terminale.
NOTA
Assicurarsi di scambiare soltanto il terminale (insieme con la sua
tastiera ed il mouse). Si desidera il terminale del cui
funzionamento si è certi nella parte terminale dello STESSO cavo
al quale era collegato il terminale sospetto. Inoltre, collegare il
terminale sospetto (con la sua tastiera ed il suo mouse) allo stesso
cavo a cui era collegato il terminale del cui buon funzionamento si
è certi e vedere se lì funziona.
— Se il terminale del cui buon funzionamento si è certi non funziona
con il cavo del terminale sospetto, ed il terminale sospetto
funziona bene nella sua nuova ubicazione, si può essere sicuri che
il terminale in sé stesso funziona correttamente e che il problema
risiede altrove.
262
Capitolo 3
Configurazione di un sistema
Aggiunta di periferiche
— La cosa successiva da verificare è il cavo che collega il terminale al
computer. Scambiare il cavo sospetto con uno del cui buon
funzionamento si è certi.
Dal momento che si sa che il terminale all’estremità di ogni cavo
funziona, occorrerà soltanto scambiare le estremità dei cavi dove
si collegano al computer. Se il problema persiste con il terminale a
cui era associato prima dello scambio del cavo, probabilmente il
cavo è rotto o allacciato in modo errato. Se il problema si
trasferisce agli altri terminali (e la combinazione terminale/cavo
che prima non funzionava ora funziona nella sua nuova
ubicazione), allora il problema molto probabilmente risiede nella
MUX, porta, o nella scheda di interfaccia.
NOTA
Altri problemi del terminale
L’altro tipo di problema in cui è probabile si incorra con i terminali è quello
dei ‘rifiuti’ sullo schermo. I ‘rifiuti’ sullo schermo si presentano come di
due tipi: ‘rifiuti’ frammisti a caratteri di dati validi e soltanto ‘rifiuti’.
Cosa verificare in caso di ‘rifiuti’ frammisti a dati validi Quella
che segue è una lista dei motivi possibili alla base della comparsa dei
‘rifiuti’ frammisti ai dati validi:
•
Rumorosità sulla linea dati:
— Cavo RS-232 troppo lungo (la lunghezza massima consigliata è di
15 m.)
— Cavo dati vicino ad apparecchiature elettricamente rumorose
(motori, ecc.)
— Fili parzialmente in corto o rotti all’interno del cavo
— Connessione rumorosa (se si usano linee telefoniche)
Capitolo 3
•
Problema hardware con un modem, una scheda di interfaccia o il
terminale stesso
•
Il programma che realizza l’I/O potrebbe stare inviando i ‘rifiuti’
•
La funzionalità Functns* del display del terminale è abilitata (che
visualizza i caratteri che normalmente non vanno in stampa)
263
Configurazione di un sistema
Aggiunta di periferiche
Cosa verificare quando tutto ciò che viene stampato è
rappresentato da ‘rifiuti’ Uno dei motivi più comuni per uno schermo
completamente pieno di ‘rifiuti’ (e certamente la prima cosa che occorre
verificare) è un accoppiamento difettoso della velocità di trasmissione.
Se l’impostazione della velocità del terminale è diversa da quella della
linea (così come è impostata con il comando stty), si otterranno i ‘rifiuti’
sullo schermo (se non addirittura niente).
Ecco una lista di altri motivi possibili per lo schermo completamente
pieno di ‘rifiuti’.
Se non ci si è ancora collegati, tentare di premere il tasto break. Questa
operazione dice a getty di provare la voce successiva del file
/etc/gettydefs. Il file gettydefs può essere impostato in modo che,
man mano che getty prova varie voci, proverà anche varie impostazioni
di velocità (questo è di solito come è configurato). getty proverà poi varie
velocità (ad ogni pressione del tasto break). Quando viene accoppiata la
velocità corretta, si otterrà un prompt di login che è leggibile.
264
•
La variabile di ambiente della shell denominata TERM non è impostata
su un valore idoneo al terminale. Se si ha un terminale HP, tentare di
impostare il valore di TERM su hp (minuscolo) usando il comando set
della shell.
•
Un processo in esecuzione sta producendo un output di ‘rifiuti’
•
Un cavo collegato in modo difettoso
•
Rumorosità eccessiva sulla linea dati
•
Un guasto hardware (scheda di interfaccia, modem, MUX guasti, ecc.)
Capitolo 3
Configurazione di un sistema
Configurazione delle manpage in linea
Configurazione delle manpage in linea
Esistono tre modi per configurare le manpage in linea, da ciascuna delle
quali consegue una quantità di uso del disco diversa ed un tempo di
risposta diverso:
1. La risposta più rapida al comando man (ma l’uso del disco più
pesante):
Creare una versione formattata di tutte le manpage. Questo è un
buon metodo se si dispone di spazio su disco sufficiente a mantenere le
pagine originali e formattate nroff per il tempo occorrente al
completamento della formattazione. Per avviare il processo di
formattazione, inserire:
catman
La formattazione di tutte le manpage può richiedere del tempo,
pertanto si potrebbe voler eseguire il processo ad una priorità
inferiore.
2. La risposta media al comando man (con l’uso del disco medio):
Formattare soltanto le sezioni molto usate delle manpage. Per
formattare le sezioni scelte, inserire:
catman sezioni
dove sezioni rappresenta una o più sezioni logiche dall’HP-UX
Reference, come 1, 2, 3.
3. La risposta più lenta al comando man (ma l’uso del disco più leggero):
Non formattare alcuna manpage. HP-UX formatterà ogni manpage la
prima volta che un utente specifichi il comando man per richiamare
una pagina. La versione formattata si usa negli accessi successivi
(soltanto se è più recente del file sorgente non formattato).
Per migliorare il tempo di risposta, è possibile creare delle directory
per contenere le manpage formattate. Per stabilire i nomi delle
directory necessarie, verificare la variabile MANPATH. Ad esempio, per
creare directory per la directory di default /usr/share/man, eseguire
il seguente script:
Capitolo 3
265
Configurazione di un sistema
Configurazione delle manpage in linea
cd /usr/share/man
mkdir cat1.Z cat1m.Z cat2.Z cat3.Z cat4.Z cat5.Z \
cat6.Z cat7.Z cat8.Z cat9.Z
Occorre creare soltanto la directory cat8.Z se
/usr/share/man/man8.Z esiste. Per risparmiare spazio su disco,
assicurarsi di usare le directory cat*.Z (non cat*) perchè se sia
cat*.Z sia cat* esistono, entrambe le directory vengono aggiornate
da man.
Per risparmiare spazio su disco, è possibile eseguire il montaggio NFS
delle manpage su un sistema remoto.
A prescindere dalla modalità di configurazione delle manpage, è possibile
recuperare spazio su disco rimuovendo i file sorgente nroff (Attenzione:
prima di rimuovere qualsiasi file, assicurarsi di eseguire un backup delle
directory man create nel caso in cui occorresse ripristinare qualche file).
Ad esempio, per rimuovere i file per la sezione 1 in /usr/share/man,
inserire:
rm man1/*
rm man1.Z/*
Questo concetto per il recupero di spazio su disco vale anche per le
manpage localizzate. Per ulteriori dettagli, consultare man (1) e catman
(1M).
266
Capitolo 3
Configurazione di un sistema
Realizzazione delle regolazioni
Realizzazione delle regolazioni
•
Impostazione dell’orologio del sistema
•
Impostazione manuale delle informazioni iniziali
•
Personalizzazione degli ambienti del sistema e del login utente
Impostazione dell’orologio del sistema
Soltanto il superutente (root) può modificare l’orologio del sistema.
L’orologio del sistema pianifica il tempo dei processi e traccia l’accesso ai
file.
Problemi potenziali quando si modifica l’orologio del sistema
Modificando l’orologio del sistema è possibile provocare i seguenti
problemi potenziali:
•
Il programma make è sensibile alle informazioni sull’ora e la data di
un file ed al valore attuale dell’orologio del sistema. Se si imposta
l’orologio in avanti non si produce alcun effetto, ma se lo si imposta
indietro anche di poco si potrebbe provocare un comportamento
imprevisto di make.
•
I backup incrementali dipendono in modo notevole dalla data corretta,
perché i backup si basano su un file datato. Se la data non è corretta,
è possibile che si esegua il backup di una versione errata di un file.
•
La modifica dell’orologio del sistema può provocare risultati
imprevisti per lavori programmati da /usr/sbin/cron:
— Nel caso in cui si sia impostata l’ora indietro, cron non eseguirà
alcun lavoro fino a che l’orologio non raggiungerà il punto da cui è
stato impostato indietro. Ad esempio, se si imposta l’orologio
indietro dalle 8:00 alle 7:30, cron non eseguirà alcun lavoro fino a
che l’orologio non raggiunga nuovamente le 8:00.
— Nel caso in cui si imposti l’orologio avanti, cron tenterà di
raggiungere l’ora avviando immediatamente tutti i lavori
programmati perché siano eseguiti tra l’ora vecchia e quella
nuova. Ad esempio, se si imposta l’orologio avanti dalle 9:00 alle
10:00, cron avvia immediatamente tutti i lavori programmati per
essere eseguiti tra le 9:00 e le 10:00.
Capitolo 3
267
Configurazione di un sistema
Realizzazione delle regolazioni
Impostazione del fuso orario (Time Zone - TZ)
/sbin/set_parms imposta il fuso orario all’avvio. Se occorre azzerare il
fuso orario, è possibile usare /sbin/set_parms. Consultare
“Impostazione manuale delle informazioni iniziali” a pagina 269.
Impostazione dell’ora e della data
/sbin/set_parms imposta l’ora e la data all’avvio. Consultare
“Impostazione manuale delle informazioni iniziali” a pagina 269.
Se occorre azzerare l’ora e la data, è possibile usare SAM o i comandi di
HP-UX.
NOTA
Hewlett-Packard consiglia vivamente di usare il modo utente unico
quando si modifica l’orologio del sistema. Pertanto, avvertire gli utenti di
uno spegnimento del sistema pianificato. Per i dettagli sullo spegnimento
del sistema, consultare “Spegnimento dei sistemi” a pagina 524.
ATTENZIONE
La modifica della data mentre il sistema è in esecuzione in modo
multiutente potrebbe interrompere programmi e processi programmati
dall’utente e correlati all’ora. La modifica della data potrebbe provocare il
comportamento imprevisto di make (1), cron (1M) e dei Source Control
subsystems SCCS, sccs (1) e di RCS, rcs (1). Inoltre, dopo il cambiamento
della data gli eventuali programmi di Hewlett-Packard o di terzi che
accedono all’ora del sistema, o le registrazioni orarie dei file memorizzate
nel file system, potrebbero presentare comportamenti imprevisti. Non si
consiglia di impostare la data indietro. Nel caso in cui siano state
apportate modifiche ai file in formato file SCCS mentre l’orologio non era
impostato correttamente, verificare i file modificati con il comando val.
Per i dettagli, consultare val (1). Per ulteriori informazioni, consultare
“Problemi potenziali quando si modifica l’orologio del sistema” a
pagina 267.
Per usare i comandi di HP-UX, procedere come segue:
1. Collegarsi come superutente.
2. Spegnere il sistema in modo utente unico. Ad esempio:
/etc/shutdown
3. Trovare l’ID di processo (PID) per cron (se esiste):
ps -ef | grep cron
268
Capitolo 3
Configurazione di un sistema
Realizzazione delle regolazioni
4. Terminare cron inserendo:
kill pid
dove pid è il PID stabilito dal passo precedente.
5. Impostare l’ora e la data. Ad esempio:
date 030214042003
Questo indica il mese di marzo, il secondo giorno del mese, le ore
14:00, 4 minuti dopo l’ora e l’anno 2003. Da notare che occorre
includere gli zero iniziali (03, non 3), l’ora si basa su un orologio di
ventiquattro ore e l’anno è opzionale.
Quando va in esecuzione /sbin/date, esso mostra l’ora e la data su
output standard.
6. Riavviare cron inserendo:
cron
7. Spegnere e riavviare immediatamente il sistema inserendo:
/etc/shutdown -r 0
Impostazione manuale delle informazioni iniziali
Usare questa sezione soltanto se occorre aggiungere o modificare le
informazioni sui parametri del sistema. Occorre realizzare le eventuali
modifiche al più presto possibile dopo l’installazione iniziale.
/sbin/set_parms esegue automaticamente al primo avvio del sistema.
Per entrare nella finestra di dialogo set_parms idonea per aggiungere o
modificare le informazioni dopo l’avvio, collegarsi come superutente e
specificare
set_parms opzione
opzione è una della parole chiave della Tabella 3-5. Comparirà l’invito ad
inserire i dati del caso.
Capitolo 3
269
Configurazione di un sistema
Realizzazione delle regolazioni
Tabella 3-5
Opzioni set_parms
opzione
Descrizione
hostname
Nome del sistema esclusivo. Questo nome host deve
avere una lunghezza di otto caratteri o inferiore,
contenere soltanto caratteri alfabetici, numeri,
underscore, o trattini e deve iniziare con un
carattere alfabetico.
ip_address
Indirizzo del protocollo Internet. Se è installata una
rete, questo è un indirizzo con quattro componenti
numerici, ciascuno dei quali è separato da un punto
con ciascun numero tra 0 e 255. Un esempio di un
indirizzo IP è: 255.32.3.10. Nel caso in cui non vi
fosse una rete installata, non sarà richiesto di
inserire l’indirizzo IP.
timezone
Il fuso orario dell’ubicazione in cui si trova il
sistema.
addl_netwrk
Parametri di rete aggiuntivi. Questi consentono di
configurare parametri di rete aggiuntivi, come la
maschera di sottorete, il gateway di rete, l’indirizzo
IP del gateway di rete, il nome del dominio locale, il
nome host del server Domain Name System (DNS),
l’indirizzo IP del server DNS e il nome del dominio
del Network Information Service.
font_c-s
Servizio dei tipi di carattere di rete. Questo consente
di configurare la workstation perchè sia un client o
un server di tipi di carattere. In qualità di client di
tipi di carattere, la workstation usa i file dei tipi di
carattere su un server di rete invece di usare i tipi di
carattere sul proprio hard disk, risparmiando spazio.
L’uso della RAM del sistema è ridotto per i client dei
tipi di carattere, ma aumenta per i server di tipi di
carattere.
Le modifiche realizzate usando set_parms saranno effettive dopo aver
riavviato il sistema. Consultare “Avvio dei sistemi” a pagina 470.
270
Capitolo 3
Configurazione di un sistema
Realizzazione delle regolazioni
Personalizzazione degli ambienti del sistema e del
login utente
I default per le variabili di sistema, come l’impostazione del fuso orario, il
tipo di terminale, il percorso di ricerca e la notifica della posta e delle
notizie, possono essere impostati in /etc/profile per gli utenti della
shell Korn e POSIX ed in /etc/csh.login per gli utenti della shell C.
Gli script di login utente possono essere usati per ignorare i default del
sistema. Quando SAM aggiunge degli utenti, gli script di login utente di
default vengono copiati nella home directory dell’utente. Per gli utenti
della shell Korn e POSIX /etc/skel/.profile viene copiato in $HOME
come .profile. Per gli utenti della shell C, /etc/skel/.login e
/etc/skel/.cshrc vengono copiati in $HOME come .login e .cshrc.
Consultare Shells: User’s Guide e Technical Addendum to the Shells:
User’s Guide per le informazioni sulla personalizzazione degli script di
login utente.
NOTA
Capitolo 3
Realizzare un backup completo una volta configurato e personalizzato
inizialmente il sistema. Questo consente di ricostruire il sistema (kernel,
file di sistema, struttura del file system, strutture utente e file
personalizzati) in caso di necessità. Usare SAM o i comandi di HP-UX per
realizzare il backup, come descritto in “Effettuazione del backup dei dati”
a pagina 684.
271
Configurazione di un sistema
Configurazione dei servizi di posta
Configurazione dei servizi di posta
Sia che si amministri un unico sistema, sia un gruppo di lavoro con molti
sistemi, probabilmente si desidererà che gli utenti siano in grado di
comunicare tra di loro usando la posta elettronica (email). Quest’area
sull’argomento aiuterà a comprendere cosa comporta configurare i servizi
di posta elettronica per il proprio gruppo di lavoro.
Componenti di un sistema di posta elettronica.
Per configurare correttamente un sistema di posta elettronica, occorre
conoscere i seguenti componenti:
•
“Agenti dell’utente di posta” a pagina 272
•
“Agenti di consegna della posta” a pagina 273
•
“File alias di posta” a pagina 274
•
“La coda della posta” a pagina 274
•
“Topografie di networking” a pagina 274
•
“Applicazioni MIME” a pagina 277
Agenti dell’utente di posta
Gli agenti dell’utente di posta sono i programmi che gli utenti eseguono
per inviare e leggere la posta elettronica. Gli agenti dell’utente di posta
forniti con HP-UX includono mail, mailx ed elm. Esistono anche agenti
dell’utente di posta disponibili in commercio.
Sebbene sembra che gli agenti dell’utente di posta compiano tutto il lavoro
di trasmettere e ricevere la posta elettronica, essi sono semplicemente la
parte visibile dell’intero sistema di posta elettronica. In realtà, gli agenti
dell’utente di posta non consegnano la posta elettronica. La consegna della
posta elettronica è gestita dagli agenti di consegna della posta.
Agenti dell’utente di posta:
•
272
Formattano i messaggi in uscita con le corrette informazioni
sull’intestazione e, se necessario, codificano i messaggi in uscita che
gli agenti di consegna della posta usano nell’instradamento dei
messaggi.
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
•
Consentono agli utenti di leggere, salvare e cancellare i messaggi di
posta elettronica entranti.
•
Programmano le applicazioni MIME (se necessario) per consentire
all’utente di trarre vantaggio dalle informazioni non testuali allegate
alla posta elettronica entrante, ad esempio la visualizzazione di file
grafici o di video o di clip, o l’ascolto di dati audio.
Agenti di consegna della posta
Gli agenti di consegna della posta costituiscono il nucleo del sistema di
posta elettronica. Questi programmi, che di solito eseguono in
background, hanno la responsabilità di instradare e consegnare la posta
elettronica. Su HP-UX ed altri sistemi UNIX, l’agente di consegna della
posta primario è sendmail.
Sebbene sendmail possa essere eseguito direttamente da un comando
della shell per inviare un messaggio, di solito non lo si usa in questo modo.
Di solito, gli agenti dell’utente di posta si usano come frontend a sendmail
per l’invio della posta.
Agenti di consegna della posta:
•
Consegnano la posta agli utenti locali (utenti che ricevono la posta
elettronica sul computer sul quale è in esecuzione l’agente di consegna
della posta) programmando il programma /bin/mail o inoltrando la
posta agli utenti sulle macchine client locali.
•
Inoltrano la posta elettronica attraverso il meccanismo di trasporto
idoneo non destinato agli utenti locali ad altri computer/reti per la
consegna. Ad esempio, la posta UUCP viene inviata sul suo percorso
mediante la programmazione del programma uux ed il passaggio del
messaggio a quest’ultimo.
•
Modificano il formato e le informazioni dell’indirizzo nelle intestazioni
del messaggio in modo da adeguarle alle necessità del computer/rete
successivi in un percorso di consegna del messaggio ed adeguarle al
metodo di consegna in uso per instradare il messaggio. Ad esempio:
gli indirizzi UUCP hanno la forma:
[email protected]!nome_utente
mentre gli indirizzi TCP/IP possono avere varie forme, ad esempio:
utente
[email protected]
[email protected]
Capitolo 3
273
Configurazione di un sistema
Configurazione dei servizi di posta
File alias di posta
I file alias di posta si usano per:
•
Mappare i nomi del “mondo reale” in nomi di login utente
•
Descrivere le liste di distribuzione (mailing list), dove un unico nome
(ad es., deptXYZ) è mappato in vari o molti nomi di login utente
Per un accesso più veloce, è possibile elaborare i file alias in un database
numerato usando il comando: newalias (una forma di sendmail). Per
default, il file alias (versione ASCII) si trova nel file /etc/mail/aliases.
La coda della posta
A causa di computer spenti, connessioni di rete guaste, traffico in rete ed
altri motivi, non è sempre possibile inviare subito i messaggi in uscita. Il
proprio agente di consegna della posta deve tenere in sospeso tali
messaggi fino a che non sia possibile inviarli verso la loro destinazione. Il
luogo in cui viene collocata è la coda della posta.
Se si usa sendmail (fornito con HP-UX) come agente di consegna della
posta, la coda della posta è, per default, la directory /var/spool/mqueue.
Topografie di networking
Sebbene esistano molti modi per configurare la posta elettronica per un
gruppo di computer sotto il proprio controllo, si usano spesso le seguenti
configurazioni:
❏
Hub di posta centrale
❏
Hub di posta gateway
❏
A distribuzione totale
Hub di posta centrale Un hub di posta centrale (un server della posta)
riceve la posta elettronica per i suoi utenti e gli utenti sui computer client
che esso serve. Gli utenti eseguono il montaggio NFS dei file della posta
entrante sui computer locali (i client) oppure eseguono il login all’hub per
leggere la propria posta. La posta elettronica può essere inviata
direttamente dai computer client.
274
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
Vantaggi:
✓
Soltanto un computer deve essere connesso al
mondo esterno, che protegge (nasconde) i client
locali dalla rete all’esterno, dando l’impressione che
tutta la posta che arriva dal gruppo di lavoro
provenga da un computer centrale.
✓
Soltanto un computer deve eseguire il daemon
sendmail (su “listen” per la posta elettronica
entrante).
✓
I dati sono centralizzati (più facile eseguirne il
backup ed il controllo)
✓
Gli utenti delle macchine client devono eseguire il
montaggio NFS dei loro file della posta entrante
dall’hub (o eseguire il login all’hub) per poter
leggere la propria posta.
✓
Tutta la posta elettronica, anche tra le macchine
client di un gruppo di lavoro locale, devono passare
dal computer hub. Ciò significa che il traffico di
posta locale potrebbe risultare rallentato se la
macchina hub si sovraccarica e che il traffico di
posta potrebbe arrestarsi completamente se l’hub si
spegne o si scollega dalla rete.
Svantaggi:
Hub di posta gateway Un hub di posta gateway riceve posta
elettronica per i propri utenti e gli utenti dei computer client che serve.
L’hub inoltra la posta destinata agli utenti dei computer client a quei
client. Gli utenti non eseguono il montaggio NFS dei loro file della posta
entrante sui computer (client) locali; essi inviano e ricevono la posta
direttamente dalle proprie macchine.
Vantaggi:
✓
Capitolo 3
Soltanto un computer deve essere connesso al
mondo esterno, che protegge (nasconde) i client
locali dalla rete all’esterno, dando l’impressione che
tutta la posta che arriva dal gruppo di lavoro
provenga da un computer centrale.
275
Configurazione di un sistema
Configurazione dei servizi di posta
✓
Il traffico tra le macchine locali (nell’ambito del
gruppo di lavoro) non deve viaggiare attraverso il
computer hub, perché ogni client può inviare e
ricevere la propria posta elettronica. Pertanto, se
l’hub si spegne o si sovraccarica, il traffico di posta
locale non ne è interessato (è interessata soltanto la
posta diretta e proveniente a computer esterni al
gruppo di lavoro).
✓
Maggior privacy per gli utenti della posta
elettronica sulle macchine client. I dati non sono
memorizzati in un deposito centrale.
✓
Ogni computer deve eseguire la propria copia del
daemon sendmail su “listen” per la posta entrante.
✓
La posta elettronica diretta e proveniente dal
mondo esterno deve viaggiare attraverso l’hub, il
che potrebbe rivelarsi un collo di bottiglia in caso di
traffico di posta pesante.
Svantaggi:
Se l’hub è spento, i client non possono inviare e
ricevere posta diretta e proveniente da computer
esterni al gruppo di lavoro.
A distribuzione totale Ogni computer del gruppo di lavoro invia e
riceve indipendentemente la propria posta elettronica.
Vantaggi:
276
✓
Non vi è alcun computer hub di cui preoccuparsi in
questa installazione. Ogni computer, a prescindere
dal fatto che sia locale al gruppo di lavoro o meno,
può inviare e ricevere posta elettronica direttamente
con ogni altro computer della rete che supporti
anch’esso la posta elettronica.
✓
Maggior privacy per gli utenti della posta
elettronica sulle macchine singole. I dati non sono
memorizzati in un deposito centrale.
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
Svantaggi:
✓
Poiché ogni computer (da un punto di vista della
posta elettronica) è connesso direttamente al mondo
esterno, esiste un rischio maggiore per la sicurezza
dei dati.
✓
Ogni computer deve eseguire la propria copia del
daemon sendmail su “listen” per la posta entrante.
Scelta di una topografia
La topografia usata dipende dalle proprie necessità. Ecco alcune cose da
prendere in considerazione quando si sceglie la propria topografia di rete
della posta elettronica.
Sicurezza
Usando una topografia con un computer hub è possibile
proteggere meglio il lavoro che si realizza sulle
macchine inserite nel proprio gruppo di lavoro o
organizzazione. Il punto di entrata unico alla propria
rete (un computer gateway) è molto più facile da
difendere contro un accesso non autorizzato.
Centralizzazione dei dati
Avendo i file di posta su un’unica macchina o struttura
di directory, è più facile eseguire il backup dei dati.
Aspetto societario e pianificazione futura
Usando una delle topografie che utilizzano un computer
hub, una piccola azienda può sembrare molto più simile
ad una grande società. Man mano che l’azienda cresce,
l’elaborazione della posta centralizzata può essere
facilmente spostata sotto la giurisdizione di un gruppo
di comunicazioni societarie.
Livelli di traffico Se si prevede di avere degli alti livelli del traffico di
posta elettronica, si potrebbe non voler utilizzare un
unico hub per l’elaborazione di tutta la posta
elettronica.
Applicazioni MIME
Sono passati i tempi in cui i messaggi di posta elettronica contenevano
soltanto testo ASCII. Oggi, la gente vuole inviare altri tipi di dati:
audioclip, grafici fissi (in una varietà di formati), videoclip, ecc.
Capitolo 3
277
Configurazione di un sistema
Configurazione dei servizi di posta
Poiché gli agenti di consegna della posta sono stati sviluppati per gestire
i dati ASCII a 7 bit in messaggi di solo testo e non i dati binari ad 8 bit
contenuti negli audio, grafici e video, occorre un metodo per codificare i
dati binari che gli agenti di trasporto di solo testo devono trasportare. Il
sistema sviluppato per la codifica dei dati binari è noto come MIME (che
sta per Multipurpose Internet Mail Extensions).
La maggior parte degli agenti dell’utente della posta moderni (incluso il
client della posta di CDE, dtmail) può elaborare messaggi di posta a
codifica MIME. Per i dettagli completi sulle modalità di lavoro di MIME,
consultare RFC 1521. Consultare anche: elm (1).
Configurazione di un sistema per l’invio di posta
elettronica
La configurazione di un sistema HP-UX per inviare posta elettronica è
relativamente semplice. Occorre fare due cose:
1. Assicurarsi che il file eseguibile per il programma sendmail,
/usr/sbin/sendmail, si trovi sul sistema.
2. Se si usa una topografia hub di posta gateway, occorre abilitare il
mascheramento del sito per ciascuno dei computer client del
gruppo di lavoro.
La seguente procedura abilita il mascheramento del sito, il che
significa che la posta elettronica proveniente dagli utenti che si
trovano sui computer client del gruppo di lavoro sembrerà, agli occhi
del mondo esterno, come se provenisse dal computer hub. Le risposte
a tale posta saranno inviate al computer hub (a meno di
un’intestazione “Reply-To:” nella posta elettronica non dia istruzioni
in tal senso).
Uso del mascheramento del sito
Punto
1. Su ogni computer client del gruppo di lavoro (servito da un hub di posta
centrale) modificare il file /etc/rc.config.d/mailservs:
a. Impostare la variabile di ambiente SENDMAIL_SERVER su 0 ad indicare
che questo computer non è l’hub e che non è un sistema di posta
elettronica indipendente. Il daemon sendmail non sarà eseguito su
questo computer:
SENDMAIL_SERVER=0
278
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
b. Impostare la variabile di ambiente SENDMAIL_SERVER_NAME sul nome
canonico (nome host ufficiale) del computer che sarà il computer hub
che invia e riceve la posta elettronica per conto di questo computer
client. Ad esempio, se il computer hub per un client ha un nome host
ufficiale, corpmail.corp.com, si imposterà la variabile come segue:
SENDMAIL_SERVER_NAME="corpmail.corp.com"
c. La variabile di ambiente SENDMAIL_FREEZE non vale per i client (che
bloccano sempre il file di configurazione sendmail), ma probabilmente
è buona regola impostare questa variabile su 1 per segnalare ai
visualizzatori del file /etc/rc.config.d/mailservs che il file di
configurazione sendmail è bloccato per questo computer client:
SENDMAIL_FREEZE=1
Punto
2. Riavviare il computer client per abilitare il mascheramento del sito e
bloccare il file di configurazione sendmail.
Configurazione di un sistema per la ricezione di posta
elettronica
La configurazione del sistema del gruppo di lavoro per ricevere posta
elettronica è un po’ più complicato che configurarlo per inviarla. Prima,
occorre stabilire due cose:
1. Quale tipo di topografia di networking si intende usare (consultare
Topografie di networking)
2. Dove si trova il sistema rispetto alla topografia: l’hub di posta
elettronica, un client di un gruppo di lavoro servito da un hub o un
sistema indipendente.
Usando tali informazioni, iniziare a scegliere la topografia di networking
idonea indicata di seguito:
Capitolo 3
❏
Topografia dell’hub di posta centrale (che riceve posta elettronica)
❏
Topografia dell’hub di posta gateway (che riceve posta elettronica)
❏
Topografia (di sistema indipendente) a distribuzione totale
279
Configurazione di un sistema
Configurazione dei servizi di posta
Topografia dell’hub di posta centrale (che riceve posta
elettronica)
Con questo tipo di sistema di posta elettronica, un unico computer serve
come luogo in cui tutti gli utenti di un gruppo di lavoro inviano e ricevono
posta elettronica. Per fare ciò, gli utenti si collegano al computer hub, o
eseguono il montaggio NFS delle proprie caselle di posta elettronica sulle
workstation (client) locali. Tutta la posta elettronica in uscita dall’intero
gruppo di lavoro, anche la posta inviata da una workstation che ha una
casella della posta elettronica con il montaggio NFS, sembra avere origine
dal computer hub.
Configurazione dell’hub Con la topografia dell’hub di posta centrale,
l’hub di posta elettronica è il computer che riceve la posta elettronica da
qualsiasi computer fuori dal gruppo di lavoro per conto dei propri utenti e
di quelli dei computer client che serve.
Punto
1. Solo sul computer hub, modificare il file /etc/rc.config.d/mailservs:
a. Impostare la variabile di ambiente SENDMAIL_SERVER su 1 ad indicare
che questo computer è il computer hub:
SENDMAIL_SERVER=1
b. Non impostare la variabile di ambiente SENDMAIL_SERVER_NAME che
indicherebbe che un altro computer serve questo:
SENDMAIL_SERVER_NAME=
c. (Opzionale) Impostare la variabile di ambiente SENDMAIL_FREEZE su 1
per indicare che il file di configurazione sendmail deve essere bloccato.
Con i computer più vecchi, ed in alcuni altri casi, un file di
configurazione bloccato può velocizzare le prestazioni di sendmail
riducendo il tempo necessario all’analisi sintattica del suo file di
configurazione.
SENDMAIL_FREEZE=1
Punto
2. Riavviare il computer hub per avviare e configurare correttamente il
daemon sendmail.
Configurazione dei client Con la topografia dell’“hub di posta
centrale”, i computer client non ricevono direttamente la posta
elettronica. Gli utenti si collegano al computer hub per elaborare la posta
elettronica, o eseguono il montaggio NFS dei file della loro casella di posta
entrante, si solito ubicati nella directory /var/mount ed eseguono un
280
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
agente dell’utente di posta sulla workstation client per elaborare la posta.
Per la posta in uscita (consultare “Configurazione di un sistema per l’invio
di posta elettronica” a pagina 278), l’agente dell’utente di posta
programmerà automaticamente il programma sendmail.
Topografia dell’hub di posta gateway (che riceve posta
elettronica)
Questo tipo di sistema di posta elettronica è simile alla topografia
dell’“hub di posta centrale” in quanto un unico computer invia e riceve la
posta elettronica per conto di tutti gli utenti del gruppo di lavoro diretta e
proveniente da computer fuori dal gruppo di lavoro. La differenza è che la
posta elettronica nell’ambito della posta elettronica del gruppo di lavoro
non deve passare dal computer hub, perché ogni macchina client esegue la
propria copia del daemon sendmail consentendole di ricevere la posta
elettronica direttamente dagli altri computer del gruppo di lavoro.
Configurazione dell’hub La procedura per la configurazione del
computer hub in una topografia dell’“hub di posta gateway” è:
Punto
1. Sul computer hub, modificare il file /etc/rc.config.d/mailservs:
a. Impostare la variabile di ambiente SENDMAIL_SERVER su 1 ad indicare
che questo computer è il computer hub:
SENDMAIL_SERVER=1
b. Non impostare la variabile di ambiente SENDMAIL_SERVER_NAME che
indicherebbe che un altro computer serve questo:
SENDMAIL_SERVER_NAME=
c. (In via opzionale) Impostare la variabile di ambiente
SENDMAIL_FREEZE su 1 per indicare che il file di configurazione
sendmail deve essere bloccato. Con i computer più vecchi, ed in alcuni
altri casi, un file di configurazione bloccato può velocizzare le
prestazioni di sendmail riducendo il tempo necessario all’analisi
sintattica del suo file di configurazione.
SENDMAIL_FREEZE=1
Punto
Capitolo 3
2. Riavviare il computer per avviare e configurare correttamente il daemon
sendmail.
281
Configurazione di un sistema
Configurazione dei servizi di posta
Configurazione dei client Usando la topografia dell’“hub di posta
gateway” ognuno dei client di un gruppo di lavoro locale può inviare posta
elettronica agli altri senza dover passare dall’hub. Perché ciò riesca, ogni
client deve eseguire il proprio daemon sendmail.
Su ogni computer:
Punto
1. Modificare il file /etc/rc.config.d/mailservs:
a. Impostare la variabile di ambiente SENDMAIL_SERVER su 1. Sebbene si
stia configurando un computer client del gruppo di lavoro, impostando
questa variabile di ambiente su 1, si avvierà il daemon sendmail ogni
volta che si avvia il computer client in modo tale che possa ricevere la
posta elettronica proveniente da altri sistemi del gruppo di lavoro.
SENDMAIL_SERVER=1
b. Impostare la variabile di ambiente SENDMAIL_SERVER_NAME sul nome
del computer che farà da gateway verso il mondo esterno. Ad esempio,
se il computer gateway era denominato gateway.corp.com:
SENDMAIL_SERVER_NAME="gateway.corp.com"
c. La variabile di ambiente SENDMAIL_FREEZE non vale per i client (che
bloccano sempre il file di configurazione sendmail), ma probabilmente
è buona regola impostare questa variabile su 1 per segnalare ai
visualizzatori del file /etc/rc.config.d/mailservs che il file di
configurazione sendmail è bloccato per questo computer client:
SENDMAIL_FREEZE=1
Topografia (di sistema indipendente) a distribuzione totale
Quando si usa una topografia di posta elettronica a distribuzione totale,
ogni computer è una macchina indipendente (per ciò che concerne la posta
elettronica). Ogni macchina è in effetti il proprio gruppo di lavoro ed è
configurata proprio come il computer hub di una rete di posta elettronica
di topografia dell’“hub di posta centrale”.
282
Capitolo 3
Configurazione di un sistema
Configurazione dei servizi di posta
Configurazione di ogni sistema La procedura per la configurazione
di ogni sistema in una topografia “a distribuzione totale” è:
Punto
1. Modificare il file / etc/rc.config.d/mailservs:
a. Impostare la variabile di ambiente SENDMAIL_SERVER su 1 ad indicare
che questo computer è il computer che eseguirà il daemon sendmail
per ricevere la posta:
SENDMAIL_SERVER=1
b. Non impostare la variabile di ambiente SENDMAIL_SERVER_NAME che
indicherebbe che un altro computer serve questo:
SENDMAIL_SERVER_NAME=
c. (In via opzionale) Impostare la variabile di ambiente
SENDMAIL_FREEZE su 1 per indicare che il file di configurazione
sendmail deve essere bloccato. Con i computer più vecchi, ed in alcuni
altri casi, un file di configurazione bloccato può velocizzare le
prestazioni di sendmail riducendo il tempo necessario all’analisi
sintattica del suo file di configurazione.
SENDMAIL_FREEZE=1
Punto
Capitolo 3
2. Riavviare il computer per avviare e configurare correttamente il daemon
sendmail.
283
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Riconfigurazione della kernel
(Prima di HP-UX 11i versione 2)
NOTA
Questa sezione vale per le release di HP-UX precedenti ad 11i versione 2.
Per le procedure per 11i versione 2 e successive, consultare
“Riconfigurazione della kernel (HP-UX 11i versione 2)” a pagina 319.
Per la maggior parte dei sistemi, la configurazione di default della kernel
inclusa in HP-UX sarà sufficiente alle proprie necessità. Tuttavia, occorre
riconfigurare la kernel in ciascuno dei seguenti casi:
•
Aggiunta o rimozione dei driver del dispositivo
Per le istruzioni complete sull’aggiunta di periferiche, consultare
Configuring HP-UX for Peripherals.
Se il sistema non usa più alcuna delle periferiche di quel tipo, si
potrebbe anche voler rimuovere un driver dalla kernel. La cosa non è
necessaria, ma può essere preferibile se occorre una kernel più piccola
ed efficiente. Tuttavia, prima di rimuovere il driver, assicurarsi che
altri driver non dipendano da esso verificando i file della directory
/usr/conf/master.d/ alla ricerca di una tabella di dipendenze dei
driver nella sezione DRIVER_DEPENDENCY. Il file core-hpux avrà la
maggior parte delle definizioni, ma altri file della directory possono
contenere anch’essi delle definizioni.
Se la periferica è controllata da un driver del dispositivo caricabile,
consultare “Gestione dei moduli della kernel a caricamento dinamico”
a pagina 289 per informazioni sull’aggiunta o la rimozione della
periferica.
Modifica dei parametri del sistema
Potrebbe essere necessario dover modificare uno o più parametri del
sistema settabili, in modo da sistemare un’applicazione specializzata
o un numero di utenti eccezionalmente vasto.
Storicamente, tutti i settaggi hanno quello statico, ma a partire da
HP-UX 11i, un settaggio potrebbe essere sia statico, sia dinamico o
automatico.
284
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
❏
Un settaggio statico è un settaggio il cui valore non può essere
modificato senza dover riavviare il sistema. Di solito, occorre
anche una ricostruzione della kernel.
❏
Un settaggio dinamico è un settaggio il cui valore può essere
modificato senza la necessità di un riavvio.
❏
Un settaggio automatico è un settaggio costantemente impostato
dalla kernel stessa in risposta alle mutevoli condizioni del
sistema.
La lista di settaggi dinamici ed automatici è in crescita continua. Per
stabilire quali settaggi siano dinamici sul proprio sistema HP-UX 11i,
usare il comando kmtune (consultare la manpage kmtune (1M)), o
consultare la parte di SAM Kernel Configuration. Nella schermata
Configurable Parameters di SAM, gli amministratori sono in grado di
dire al primo sguardo se il valore di un dato settaggio possa essere
modificato o meno senza un riavvio.
I parametri del sistema settabili si modificano usando SAM o il
comando kmtune. Ogniqualvolta si modifichi un settaggio usando
SAM, questo informerà l’amministratore se la modifica di quel
settaggio richieda o meno un riavvio. Nel caso in cui non fosse
richiesto, SAM procederà ad apportare immediatamente la modifica
al settaggio.
Per ulteriori informazioni sui settaggi dinamici, consultare la white
paper Dynamically Tunable Kernel Parameters in HP-UX 11i al
seguente sito web:
http://docs.hp.com
•
Aggiunta di determinato software Hewlett-Packard
Nel caso in sui si aggiunga determinato software Hewlett-Packard,
come LAN (rete di area locale) o NS (servizi di rete), potrebbe dover
essere necessario riconfigurare la kernel. Per le istruzioni di
installazione, consultare il manuale fornito con il software.
•
Creazione di un file system di un tipo diverso da JFS
A seconda del tipo di configurazione della kernel, potrebbe dover
essere necessario riconfigurare se è stato creato un file system di un
tipo diverso da quello di default (JFS). Per le informazioni sui tipi di
file system, consultare “Pianificazione della gestione dei file system” a
pagina 78.
Capitolo 3
285
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
•
Aggiunta, rimozione o modifica di dispositivi di scambio,
copiatura e console o del file system di root
Occorrerà riconfigurare la kernel per l’aggiunta o la rimozione di
dispositivi di copiatura e la modifica dell’ubicazione dello scambio
primario o della console di sistema. Per le informazioni sullo spazio di
scambio, consultare “Gestione dello scambio e della copiatura” a
pagina 671.
Per aggiungere, rimuovere o modificare il file system di root, non si
potrà usare SAM. Invece, reinstallare il sistema o consultare
“Creazione di un gruppo di volumi di root e di volumi logici di root e di
avvio.” a pagina 586 se si usano volumi logici.
NOTA
Se si è installato a freddo un HP 9000 Modello T500 e si sta configurando
un numero di file system notevole (circa 100 o di più), le dimensioni di alcune tabelle di default della kernel potrebbero essere troppo piccole perché
il sistema riesca ad avviarsi. Per avviare il sistema, riconfigurare la kernel
di installazione prima del primo avvio. Per realizzare ciò, consultare “Procedura per riconfigurare la kernel” a pagina 287, tenendo presente che
SAM non è disponibile a questo punto. Le seguenti impostazioni, sebbene
non siano il massimo per il sistema, consentiranno di avviare la kernel:
Tabella 3-6
Parametri della kernel
Parametri della kernel
Default
Impostazione consigliata
ninode
476
2048
nproc
276
1024
nfile
790
2048
In alternativa, è possibile fare quanto segue:
•
Riconfigurare la kernel e modificare il valore di maxusers su un
valore maggiore, come 200.
•
Selezionare un bundle idoneo di parametri impostati su SAM
procedendo come segue:
—
—
—
—
Aprire la voce di menu “SAM Kernel Configuration”
Selezionare “Configurable Parameters”
Far scendere il menu “Actions”
Selezionare “Apply Tuned Parameter Set”
Per ulteriori dettagli, consultare Installing HP-UX 11.0 and Updating
HP-UX 10.x to 11.0.
286
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Procedura per riconfigurare la kernel
Per riconfigurare la kernel, è possibile usare SAM o i comandi di HP-UX.
Per usare SAM per riconfigurare la kernel, collegarsi come superutente,
assicurarsi di essere collegati alla macchina per la quale si sta rigenerando
la kernel ed avviare SAM. Selezionare la voce di menu “Kernel
Configuration”; se necessario, usare la guida in linea di SAM. In genere,
SAM è più semplice e veloce da usare dei comandi di HP-UX equivalenti.
Per usare i comandi di HP-UX per riconfigurare la kernel:
1. Collegarsi come superutente alla macchina per cui si sta generando
una nuova kernel. È possibile collegarsi a distanza da un’altra
ubicazione usando il comando /usr/bin/rlogin.
2. Modificare la directory nell’ambiente di costruzione (/stand/build).
Lì, eseguire lo script di preparazione del sistema, system_prep.
system_prep scrive un file di sistema in base alla kernel attuale nella
directory attuale (cioè, crea /stand/build/system). La -v fornisce la
spiegazione verbosa mentre lo script esegue.
cd /stand/build
/usr/lbin/sysadm/system_prep -v -s system
3. Usare il comando kmsystem per visualizzare i moduli della kernel già
selezionati per la costruzione della kernel successiva:
/usr/sbin/kmsystem -S /stand/build/system
Aggiungere i moduli della kernel mancanti (come i driver del
dispositivo) usando il comando kmsystem. L’opzione -c Y specifica il
nome del modulo da configurare nel sistema:
/usr/sbin/kmsystem -S /stand/build/system \
-c Y nome_driver
NOTA
Capitolo 3
Le modifiche dirette ai file di descrizione del sistema HP-UX non
funzionano più come nelle release precedenti. Le modifiche dirette
non hanno supportato l’interfaccia di configurazione della kernel ed è
probabile che introducano degli errori di configurazione. Invece, usare
i comandi kmsystem e kmtune. Questi comandi sono nuovi per la
Release 11.0; consultare kmsystem (1M) e kmtune (1M) nella HP-UX
Reference.
287
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
4. Costruire la nuova kernel richiamando il comando mk_kernel:
/usr/sbin/mk_kernel -s /stand/build/system
Questo costruisce una nuova kernel pronta per il collaudo:
/stand/build/vmunix_test ed i componenti della kernel associati.
5. Preparare per il riavvio richiamando il comando kmupdate. Questo
imposta un indicatore che dice al sistema di usare la nuova kernel
quando si riavvia.
/usr/sbin/kmupdate
6. Notificare agli utenti che si spegnerà il sistema. È possibile usare il
comando
/usr/sbin/wall e/o le funzionalità interattive del comando
/usr/sbin/shutdown per distribuire un messaggio agli utenti prima
di spegnere il sistema. Per i dettagli, consultare wall (1M), shutdown
(1M) e “Spegnimento dei sistemi” a pagina 524.
NOTA
Occorre realizzare la seguente procedura soltanto se si sta cambiando
l’hardware, come l’aggiunta di nuove periferiche. Se si sta
semplicemente modificando un parametro della kernel, riavviare il
sistema per attivare la nuova kernel con shutdown -r.
7. Portare il sistema all’arresto usando il comando shutdown.
8. Togliere l’alimentazione a tutti i dispositivi periferici e poi alla SPU.
9. Installare l’hardware o rimuovere le schede di interfaccia o i
dispositivi periferici. Per istruzioni specifiche, consultare i documenti
consegnati con i prodotti da installare e Configuring HP-UX for
Peripherals.
10. Ricollegare l’alimentazione a tutti i dispositivi periferici. Attendere
che siano “pronti”, poi ricollegare l’alimentazione alla SPU. Il sistema
tenterà di avviare la nuova kernel.
Se la nuova kernel non si avvia
Se la nuova kernel non si avvia, avviare il sistema dalla kernel di backup
(/stand/vmunix.prev) e ripetere il processo di creazione di una nuova
kernel. Per informazioni sul riavvio da una kernel di backup, consultare
“Avvio da una kernel alternativa” a pagina 501.
288
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Gestione dei moduli della kernel a caricamento
dinamico
Questa sezione presenta i concetti e le procedure necessari a
comprendere, configurare e gestire i moduli della kernel a caricamento
dinamico (Dynamically Loadable Kernel Modules - DLKM).
Questa sezione si divide nelle seguenti tre parti di attualità:
Tabella 3-7
Sezioni di attualità DLKM
Argomento
Descrizione
Concetti DLKM
Questa sezione fornisce un’introduzione a
DLKM, termini DLKM importanti e concetti
DLKM tecnicamente dettagliati.
Strumenti DLKM
Questa sezione fornisce un riepilogo degli
strumenti nel complesso noti come il Set di
strumenti di configurazione della kernel che si
usano quando si installano, configurano e
gestiscono moduli DLKM.
Procedure DLKM
Questa sezione presenta le procedure chiave
DLKM usate nelle tre fasi di gestione dei moduli
DLKM: preparazione, caricamento e
manutenzione.
Questa sezione si incentra sulla configurazione e la gestione dei driver del
dispositivo caricabili, dal momento che essi costituiscono la maggioranza
dei tipi di moduli supportati per HP-UX release 11.0 e successive.
NOTA
L’infrastruttura della kernel di HP-UX fornisce la funzionalità di
caricamento e scaricamento dinamico dei driver DLKM. Mentre il set di
driver di base consegnati con HP-UX release 11.11 non è abilitato per
DLKM, molti rivenditori di software indipendenti (Independent Software
Vendors - ISV) programmano i driver abilitati per DLKM per l’hardware
da essi fornito. HP fornisce i DLKM per supporto di grafica Fire-GL su
11.0 e 11.11. I DLKM sono usati anche come l’unico mezzo di supporto di
grafica dei sistemi su base Itanium.
Verificare la documentazione allegata ai driver di terzi per stabilire se
sono abilitati per DLKM.
Capitolo 3
289
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Concetti DLKM
Questa sezione fornisce una panoramica concettuale delle caratteristiche
e funzionalità DLKM mediante:
•
definizione dei DLKM ad un alto livello
•
spiegazione dei termini e dei concetti essenziali alla comprensione dei
DLKM
•
descrizione delle modalità di packaging dei moduli DLKM in HP-UX
•
identificazione dei tipi di moduli della kernel attualmente supportati
dai DLKM
•
descrizione dei vantaggi della scrittura dei moduli della kernel in
formato DLKM
•
esame delle funzioni e dei parametri di configurazione dei moduli
DLKM
Cos’è DLKM? L’infrastruttura dei moduli della kernel a caricamento
dinamico (Dynamically Loadable Kernel Modules) è una funzionalità del
sistema operativo HP-UX che consente ai moduli della kernel “abilitati
per DLKM” di essere caricati sulla/o scaricati dalla kernel di HP-UX in
modo dinamico senza dover collegare nuovamente l’intera kernel o
riavviare il sistema.
In precedenza, per installare un nuovo driver, occorreva modificare il file
system, eseguire i comandi config o mk_kernel per creare una nuova
kernel, spegnere il sistema e poi riavviarlo prima di poter usare il nuovo
driver.
La funzionalità DLKM non soltanto fornisce l’infrastruttura per caricare
i moduli della kernel in un sistema in esecuzione, ma consente anche al
modulo della kernel di essere collegato in modo statico al momento della
ricostruzione della kernel. Impostando un indicatore in uno dei file di
configurazione del modulo DLKM stabilisce se il modulo debba essere
configurato come a caricamento dinamico o collegato in modo statico.
Termini e concetti importanti L’infrastruttura DLKM consente ai
moduli della kernel di essere configurati in un numero di modi diversi. La
seguente tabella prende in considerazione i vari modi in cui è possibile
configurare e caricare un modulo della kernel e lo definisce in modo chiaro
sotto forma di termine. Inoltre, chiarisce il rapporto esistente tra ciascun
termine così come viene visto dalla kernel di HP-UX.
290
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-8
Termini e concetti importanti
Termine/Concetto
Definizione
Modulo della kernel
Un modulo della kernel è una sezione del codice della kernel
responsabile di supportare una capacità o funzionalità specifica. Ad
esempio, i tipi di file system ed i driver del dispositivo sono moduli
della kernel.
Nel contesto di configurazione della kernel, un modulo della kernel
potrebbe essere visualizzato come un oggetto che può essere
installato, rimosso, configurato o costruito su un sistema, sia in modo
statico sia dinamico.
Esistono due categorie di moduli della kernel:
Modulo tradizionale
•
Modulo tradizionale
•
Modulo in package modulare
Un modulo tradizionale è un modulo della kernel i cui dati di
configurazione non sono stati modularizzati e che possono essere
collegati alla kernel soltanto in modo statico.
Nel contesto della configurazione della kernel, le informazioni sulla
configurazione sui moduli tradizionali è conservata nei file master e
system condivisi ed è possibile accedere ad esse al momento
dell’avvio di una kernel in cui esse siano state configurate in modo
statico.
Capitolo 3
291
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-8
Termini e concetti importanti (segue)
Termine/Concetto
Modulo in package
modulare
Definizione
Un modulo in package modulare è un modulo della kernel i cui dati
di configurazione sono stati modularizzati (non condivisi con altri
moduli della kernel), il che è un prerequisito per l’abilitazione DLKM
del modulo della kernel.
Nel contesto della configurazione della kernel, questo significa che il
modulo usa i propri file master e system (invece dei file condivisi
master e system in cui sono configurati i moduli tradizionali).
Perché il modulo sia classificato come modulo in package modulare,
esso deve contenere i propri file master e system, così come un file
dell’oggetto singolo, mod.o, che implementa il modulo.
Un modulo in package modulare può essere caricato in modo
dinamico nella kernel di HP-UX soltanto se tale modulo include il
codice wrapper del modulo e le strutture dati aggiuntivi.
Per questo motivo, collochiamo i moduli in package modulare in due
categorie:
•
Moduli in package modulare statici
•
Moduli caricabili (o moduli DLKM)
Il termine modulo caricabile e modulo DLKM sono intercambiabili.
Moduli in package
modulare statici
Un modulo in package modulare statico è un modulo in package
modulare che può essere collegato alla kernel soltanto in modo
statico.
Nel contesto di configurazione della kernel, ciò significa che il
modulo usa i propri file master e system ma non contiene il codice
wrapper del modulo ed i dati strutturali aggiuntivi che forniscono la
funzionalità di caricamento e scaricamento dinamico.
292
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-8
Termini e concetti importanti (segue)
Termine/Concetto
Modulo caricabile
(Modulo DLKM)
Definizione
Un modulo caricabile (o modulo DLKM) è un modulo in package
modulare con la funzionalità di essere caricato in modo dinamico in
una kernel in esecuzione.
Nel contesto di configurazione della kernel, ciò significa che il
modulo DLKM usa i propri file masteresystem e contiene il codice
wrapper del modulo ed i dati strutturali aggiuntivi che forniscono la
funzionalità di caricamento e scaricamento dinamico.
Tuttavia, quando si scrive un modulo DLKM con il codice wrapper
autocontenuto si esegue il packaging con i file specifici del modulo
master e system, esso può ancora essere configurato staticamente
nella kernel.
Per questo motivo, collochiamo i moduli caricabili in due categorie:
Modulo caricabile
configurato in modo
statico
•
Modulo caricabile configurato in modo statico
•
Modulo caricabile configurato in modo dinamico
Un modulo caricabile configurato in modo statico è un modulo DLKM
dotato della funzionalità di essere caricato in modo dinamico, ma che
invece è configurato per essere costruito in modo statico nella kernel.
Nel contesto di configurazione della kernel, ciò significa che il file
specifico del modulo system è stato aggiornato per segnalare la
configurazione statica.
Poiché ora è costruito in modo statico nella kernel, esso non può
essere scaricato o ricaricato nella kernel in modo dinamico.
Capitolo 3
293
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-8
Termini e concetti importanti (segue)
Termine/Concetto
Definizione
Modulo caricabile
configurato in modo
dinamico
Un modulo caricabile configurato in modo dinamico è un modulo
caricabile che è stato completamente configurato per essere caricato
o scaricato in modo dinamico dalla kernel senza dover ricollegare
l’intera kernel o riavviare il sistema.
Per riepilogare la terminologia presentata in questa tabella, un
modulo della kernel configurato in modo dinamico è tutto ciò che
segue:
Wrapper del modulo
•
un modulo in package modulare
(che è un modulo della kernel che usa file master e system
specifici del modulo).
•
un modulo caricabile (o modulo DLKM)
(che è un modulo in package modulare che contiene il codice
wrapper e le strutture dati aggiuntive ed usa i file specifici del
modulo master e system, ma che potrebbe ancora essere
configurato come collegato in modo dinamico o statico).
•
un modulo caricabile configurato in modo dinamico
(che è un modulo DLKM che è stato configurato per essere
totalmente in grado di supportare il caricamento dinamico e lo
scaricamento dalla kernel in esecuzione).
Il codice e le strutture dati aggiuntivi aggiunti ad un modulo della
kernel che abilitano il meccanismo DLKM a collegare e scollegare in
modo logico un modulo caricabile su/dalla kernel in esecuzione.
Packaging dei moduli DLKM L’infrastruttura DLKM specifica che:
•
un modulo della kernel deve essere in package modulare con almeno:
— i propri file master e system
— il proprio file dell’oggetto mod.o che implementa soltanto quel
modulo
•
294
il file dell’oggetto mod.o deve contenere il codice wrapper del modulo
(sebbene l’ottimizzazione completa sia opzionale).
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
NOTA
Consultare la manpage master (4) per le descrizioni dei due generi di file
master e la manpage config (1M) per una descrizione dei file system
tradizionali e modulari.
I moduli della kernel scritti come moduli tradizionali sono ancora
completamente supportati in HP-UX. Gli sviluppatori dei driver sono
invitati ad eseguire nuovamente il packaging dei propri moduli statici
secondo l’architettura di packaging del modulo introdotta con i moduli
DLKM.
Tipi di moduli DLKM La funzionalità DLKM attualmente supporta i
seguenti tipi di moduli della kernel:
•
driver di classe WSIO
•
driver di interfaccia WSIO
•
driver STREAMS
•
moduli STREAMS
•
Moduli vari: ad esempio, moduli contenenti funzioni di supporto non
richieste nella kernel a configurazione statica, ma condivise tra
moduli caricabili multipli.
Vantaggi dei moduli DLKM I moduli DLKM forniscono molti
vantaggi relativi ai moduli statici, incluso:
Capitolo 3
•
riduzione del tempo dedicato allo sviluppo dei driver del dispositivo
ottimizzando il processo di installazione dei driver
•
facilitazione per gli amministratori dell’installazione dei driver del
dispositivo provenienti da rivenditori terzi
•
miglioramento della disponibilità del sistema consentendo ai driver
del dispositivo e ad altri moduli di essere configurati nella kernel
mentre il sistema è in esecuzione
•
conservazione delle risorse del sistema scaricando i moduli di uso
meno frequente quando non sono in uso
•
possibilità fornita agli amministratori di richiedere il caricamento e lo
scaricamento dei moduli
•
possibilità fornita alla kernel di caricare automaticamente i moduli
295
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Il caricamento automatico si verifica quando la kernel rileva la necessità
di un modulo caricabile specifico per la realizzazione di qualche procedura
particolare, ma il modulo non è al momento caricato. La kernel carica
automaticamente il modulo.
Concetti di caricamento dei driver DLKM Quando un modulo viene
caricato in modo dinamico, il suo file object viene letto dal disco e caricato
in una memoria della kernel appena allocata. Una volta in memoria, i
simboli del modulo sono scaricati e gli eventuali riferimenti esterni risolti.
Quindi, viene eseguito il codice speciale del modulo per realizzare
l’eventuale configurazione specifica del modulo. Poi, il codice specifico del
tipo di modulo, se esiste, viene eseguito, rendendo accessibile il modulo
appena caricato al resto della kernel.
È possibile caricare un modulo nei seguenti modi:
•
Richiesta di caricamento
Una richiesta di caricamento è una richiesta a livello di utente per il
caricamento di un modulo specifico. Il caricamento viene realizzato
attraverso il comando kmadmin.
•
Evento di caricamento automatico
Un caricamento automatico si verifica quando la kernel rileva la
necessità di un modulo specifico per fornire la funzionalità necessaria
alla realizzazione di una procedura. Il caricamento è innescato
dall’iniziazione della procedura. Una volta caricato il modulo
richiesto, la procedura continua.
La funzione _load() di un modulo caricabile realizza le eventuali
procedure di inizializzazione richieste dal modulo prima che quest’ultimo
sia connesso alla kernel in modo logico. Fra le procedure di
inizializzazione tipiche, vi sono l’acquisizione di memoria privata per il
modulo ed i dispositivi di inizializzazione e le strutture dati.
•
Se il modulo non è in grado di inizializzarsi, la funzione _load() deve
liberare l’eventuale memoria allocata ed annullare le eventuali altre
azioni intraprese prima del guasto, incluso l’annullamento di tutte le
chiamate in attesa di timeout.
Concetti di scaricamento dei driver DLKM Quando la funzionalità
fornita da un modulo non è più necessaria, il modulo può essere scaricato,
liberando in tal modo le sue risorse per un uso successivo.
296
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
•
Quando si scarica un modulo, viene eseguito il codice specifico al tipo
di modulo, se esiste, per scollegare il modulo dalla kernel. Quindi,
viene eseguito il codice speciale del modulo per realizzare l’eventuale
pulizia specifica del modulo. Infine, viene liberata la memoria allocata
al modulo.
•
È possibile scaricare un modulo soltanto mediante richiesta a livello
utente specificando il modulo da scaricare. Lo scaricamento viene
realizzato attraverso il comando kmadmin. Questa richiesta può non
andare a buon fine per una varietà di motivi, fra i quali il più comune
è che il modulo è al momento occupato. Un esempio di ciò sarebbe di
tentare di scaricare un dispositivo mentre vi sono dei sospesi aperti
sul dispositivo.
La funzione _unload() del modulo caricabile viene richiamata dal
meccanismo DLKM ogniqualvolta il modulo è prossimo ad essere rimosso
dalla memoria attiva. È possibile assegnare alla funzione qualsiasi nome
(di solito nome_modulo_unload); si ottiene un puntatore alla funzione
_unload() dal wrapper del modulo.
Capitolo 3
•
La funzione _unload() del modulo pulisce le eventuali risorse che
erano allocate al modulo e deve rimuovere tutti i riferimenti al
modulo. Fra le procedure di pulizia tipiche, vi è il rilascio della
memoria privata acquisita dal modulo, la rimozione degli interrupt
del dispositivo, la disabilitazione degli interrupt dal dispositivo e
l’annullamento delle eventuali richieste di timeout in sospeso fatte
dal modulo.
•
La funzione _unload() del modulo restituisce 0 in caso di riuscita ed
un valore di errno in caso di non riuscita. In caso di guasto, la
funzione lascia il modulo integro, dato che il modulo resterà caricato
dopo il ritorno.
•
Il sistema non tenterà mai di scaricare un modulo che ritiene
occupato. Tuttavia, il sistema non può stabilire in tutti i casi quando
il modulo sia in uso. Attualmente, un modulo è considerato occupato
quando si carica un altro modulo che dipende da esso. Inoltre, i driver
di classe WSIO ed i driver STREAMS tracciano le chiamate open() e
close(); questi tipi di moduli sono occupati ogni volta che ve ne sia
almeno una aperta sul dispositivo che usa il driver. Nella maggior
parte delle altre circostanze, il modulo stabilisce da solo se sia il caso
di essere scaricato. Quando un modulo è ancora in uso, la sua funzione
_unload() restituisce un valore diverso da zero per annullare lo
scaricamento.
297
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
•
L’argomento passato alla funzione _unload() è lo stesso valore
specifico del tipo che era stato passato alla funzione _load() del
modulo. L’uso di questo argomento è descritto in “Driver STREAMS”
a pagina 300.
Concetti di configurazione dei driver DLKM Dal momento che i
moduli della kernel scritti nel formato DLKM possono essere configurati
sia come caricabili in modo dinamico sia come configurati in modo statico,
i driver del dispositivo compatibile con DLKM devono adeguarsi all’una
ed all’altra configurazione.
Attraverso l’uso di attributi del modulo configurabili, gli amministratori
di sistema possono controllare le varie funzioni di un driver DLKM,
incluso se sia caricato in modo dinamico o configurato in modo statico.
Questa sezione fornisce gli attributi e le parole chiave per:
•
i componenti necessari per un driver DLKM
•
i componenti opzionali per un driver DLKM
Presenta inoltre una breve descrizione dei driver STREAMS e Vari. Per le
istruzioni dettagliate sulle modalità di modifica degli attributi dei moduli
configurabili presentati qui, consultare la sezione “Strumenti DLKM” a
pagina 301.
NOTA
Prima che un modulo caricabile sia disponibile, occorre che il sistema sia
in stato di esecuzione. Pertanto, i moduli della kernel necessari durante
l’avvio del sistema devono essere configurati come statici.
Definizione del file Ogni modulo DLKM ha il proprio file master. Il formato del file master
master
include le seguenti parole chiave di sezione:
298
•
$VERSION—indica il numero di versione per il formato del file. La
versione viene definita un numero intero e parte da uno. Si inserisce
un’unica riga contenente l’unica versione supportata (version 1).
•
$LOADABLE—indica che il modulo supporta il caricamento dinamico.
Se questa parola chiave di sezione non esiste, il modulo può essere
soltanto configurato in modo statico nella kernel.
•
$INTERFACE—identifica i nomi e le versioni dell’interfaccia sui quali è
costruito il modulo. Per HP-UX, versioni 11.0 e superiori, si inserisce
una sola riga contenente la parola base.
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
•
$TYPE—indica il tipo di modulo e le informazioni specifiche sul tipo.
Sono tipi validi wsio_class, wsio_intfc, streams_mod,
streams_drv e misc.
•
Altre sezioni (se necessarie)—$DRIVER_DEPENDENCY, $TUNABLE e
$DRIVER_INSTALL.
La sezione $DRIVER_DEPENDENCY definisce i nomi di tutti gli altri
moduli dai quali questo modulo dipende.
La sezione $TUNABLE definisce i nomi ed i valori di default dei
parametri settabili (variabili) per il modulo. I valori di default (ed in
via opzionale quello minimo) per i parametri settabili si inseriscono
qui.
La sezione $DRIVER_INSTALL definisce il nome del modulo ed il/i
numeri del dispositivo superiore e/o del blocco associato.
Definizione del file Ogni modulo DLKM richiede un file system. Il file system include le
system
seguenti tre parole chiave di sezione obbligatorie ed una opzionale:
•
Il numero di versione per il file master ed il file system deve essere lo
stesso.
NOTA
Capitolo 3
$VERSION—indica il numero di versione per il formato del file.
Versione 1 è il solo formato di file supportato.
•
$CONFIGURE—indica se il modulo deve essere configurato nel sistema.
$CONFIGURE è Y o y, il modulo sarà configurato in occasione della
costruzione successiva; se $CONFIGURE è N o n, il modulo non sarà
configurato in occasione della costruzione successiva. kmsystem (1M)
fornisce l’interfaccia per modificare l’indicatore.
•
$LOADABLE—indica come sarà configurato il modulo. Se $LOADABLE è
Y o y, il modulo sarà configurato come modulo caricabile configurato in
modo dinamico; se $LOADABLE è N o n, il modulo sarà configurato in
modo statico nella kernel, e sarà necessario un riavvio. kmsystem
fornisce l’interfaccia per modificare l’indicatore.
•
Se $CONFIGURE è N o n, $LOADABLE viene ignorato.
•
$TUNABLE (vuoto)—segnaposto se gli eventuali parametri settabili
specificati nel file master associato per cui si desidera specificare un
valore diverso da quello di default. Qui non si inserisce nulla.
299
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
kmtune (1M) è l’interfaccia per modificare i parametri settabili nel file
di descrizione di sistema del modulo e nel file di sistema HP-UX
(/stand/system di default).
Definizione del file Un componente opzionale, il file Modstub.o è configurato in modo statico
Modstub.o
nella kernel come “segnaposto” per funzioni implementate in un modulo
caricabile che sarà caricato in un momento successivo. Il suo scopo è di
abilitare la kernel a risolvere i riferimenti alle funzioni del modulo
assente. La configurazione di un modulo che usa stub richiede una
costruzione della kernel completa in modo che gli stub possano essere
collegati alla kernel in modo statico.
Modstub.o contiene stub per punti della voce definiti nel modulo
caricabile associato a cui altri moduli della kernel configurati in modo
statico attualmente configurati nel sistema possono far riferimento.
L’accesso ad uno stub genera il caricamento automatico da parte della
kernel del modulo caricabile associato.
Definizione del file Un componente opzionale, il file space.h contiene allocazioni di
space.h
memorizzazione ed inizializzazione di strutture dati associati ad un
modulo DLKM quando le dimensioni o il valore iniziale delle strutture
dati dipendono da valori configurabili come i parametri settabili. Al fine
di comunicare tali valori al resto del modulo DLKM, i valori sono
memorizzati in variabili globali ed il modulo accede ad essi attraverso
dichiarazioni esterne nel file mod.o del modulo.
NOTA
Tutti i parametri settabili specificati nel file master sono definiti come
variabili globali nel file space.h.
Driver STREAMS
L’inizializzazione dei driver STREAMS è molto simile sia nel caso dei
moduli caricabili sia di quelli a configurazione statica. L’unica differenza
è che i driver caricabili devono usare la struttura drv_info_t che viene
passata come argomento alla funzione _load().
I driver STREAMS, come i driver di classe WSIO, tracciano
automaticamente le chiamate del sistema open() e close() per il
dispositivo STREAMS. Il sistema evita lo scaricamento di un driver
STREAMS ogni volta che il dispositivo ha una o più gestioni di file aperti.
Naturalmente, il driver può ancora impedire uno scaricamento se questa
verifica è insufficiente alle sue necessità.
300
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Moduli vari
I moduli vari possono implementare qualsiasi funzionalità nell’ambito
della kernel. Come tale, la funzione _load() di un modulo vario deve
indirizzare tutte le necessità specifiche del modulo. In modo simile, la
funzione _unload() del modulo deve stabilire da solo se lo scaricamento
sia sicuro. Il sistema non consentirà lo scaricamento di un modulo se altri
moduli caricati dipendono da tale modulo. Oltre a tale verifica, il sistema
non realizza alcun’altra verifica quando l’amministratore tenta di
rimuovere un modulo vario dalla kernel.
L’argomento sulla funzione _load() non è significativo e deve essere
ignorato.
Strumenti DLKM
Esiste un certo numero di comandi di HP-UX noti nell’insieme come il set
di strumenti di configurazione della kernel per l’installazione, la
configurazione e la gestione dei moduli DLKM. Questi comandi sono
presentati con descrizioni ed opzioni della riga di comando applicabili in
questa sezione.
Perchè occorre usare gli strumenti di configurazione della
kernel Sebbene l’ambiente della kernel statica HP-UX non sia cambiato,
esso è interessato della configurazione dei moduli della kernel nell’ambito
dell’infrastruttura DLKM. Nello specifico, DLKM richiede che un modulo
della kernel abbia i propri file master e system e che contenga un wrapper
del modulo.
Per l’ambiente di configurazione della kernel HP-UX complessivo ciò
significa:
1. Le informazioni sul modulo configurabile sono distribuite tra vari file:
•
•
i moduli tradizionali usano il file /stand/system
i moduli in package modulare usano il proprio file di sistema
specifico del modulo
2. La struttura della kernel si estende:
•
•
file eseguibile della kernel statica /stand/vmunix
componente della kernel DLKM associato sotto/stand/dlkm:
— tabella dei simboli della kernel
— moduli caricabili dinamici
Capitolo 3
301
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
A causa degli effetti che l’infrastruttura DLKM ha sull’ambiente di
configurazione della kernel globale, è preferibile configurare tutti i tipi di
moduli della kernel usando gli strumenti descritti in questa sezione.
Evitare di modificare il file system, o di sostituire il file della kernel
manualmente, dato che una tale operazione aumenta le possibilità di
introdurre errori di configurazione.
Per informazioni più dettagliate sui file master e system, consultare la
manpage master (4) e le manpage config (1M).
Descrizione degli strumenti di configurazione della kernel
L’amministratore di sistema usa gli strumenti di configurazione della
kernel per installare, configurare, caricare, scaricare, aggiornare o
rimuovere i moduli della kernel dal sistema e per costruire nuove kernel.
È possibile usare i comandi descritti in questo set di strumenti per
configurare moduli della kernel di qualsiasi tipo (statico o caricabile).
L’azione realizzata da uno strumento di configurazione della kernel
dipende dalle opzioni che si specificano durante il richiamo dello
strumento. Queste informazioni sono descritte in “Comandi ed opzioni del
set di strumenti di configurazione della kernel” a pagina 303.
La seguente lista descrive la funzione di base di ogni comando che
compone il set di strumenti di configurazione della kernel.
Strumenti da usare •
quando si
costruiscono
kernel statiche o
dinamiche
•
kmsystem (1M)
Fornisce l’interfaccia per impostare gli attributi configurabili di un
modulo, per segnalare se occorra configurare un modulo e se occorra
costruirlo come statico o caricabile.
kmtune (1M)
Fornisce l’interfaccia per impostare i parametri settabili
•
kmupdate (1M)
Aggiorna il sistema con la kernel appena costruita e/o i file DLKM
associati
Strumenti che
forniscono
un’interfaccia a
DLKM
302
•
kminstall (1M)
Installare, rimuovere o aggiornare i file dei componenti di un modulo
su un sistema
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
•
kmadmin (1M)
Fornisce l’interfaccia amministrativa generale per DLKM. Consente
agli amministratori di caricare, scaricare e richiedere i moduli
caricabili.
Comandi ed opzioni del set di strumenti di configurazione della
kernel Questa sezione descrive le opzioni della riga di comando con le
descrizioni per ogni strumento di configurazione della kernel.
NOTA
Nel caso in cui occorrano ulteriori informazioni sulla funzionalità. L’uso o
le opzioni della riga di comando di uno qualsiasi degli strumenti di
configurazione della kernel, consultare le relative manpage.
Tabella 3-9
Set di strumenti di configurazione della kernel
Strumento/
Comando
config
kmadmin
Capitolo 3
Azione
•
Prima forma-genera sia la kernel statica sia i moduli caricabili a
configurazione dinamica associati; occorre un riavvio del sistema.
•
Seconda forma, opzione -M —genera il modulo caricabile specificato da
usare con la kernel attualmente in esecuzione. Il servizio appena
configurato è disponibile immediatamente, senza dover riavviare il
sistema.
•
opzione -k —stampa una lista di moduli a configurazione statica nella
kernel in esecuzione.
•
opzione -L —carica il modulo caricabile specificato nella kernel in
esecuzione.
•
opzione -Q, -q —stampa lo stato del modulo caricabile specificato.
•
opzione -S, -s —stampa lo stato di tutti i moduli caricabili attualmente
caricati o registrati.
•
opzione -U, -u —scarica il modulo caricabile specificato dalla kernel in
esecuzione.
303
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-9
Set di strumenti di configurazione della kernel (segue)
Strumento/
Comando
kminstall
kmsystem
kmtune
304
Azione
•
opzione -a —aggiunge i file dei componenti di un modulo a determinate
sottodirectory di /usr/conf e
/stand.
•
opzione -d —cancella i file dei componenti di un modulo dalle
sottodirectory di /usr/conf e
/stand.
•
opzione -u —copia i file dei componenti aggiornati di un modulo nelle
sottodirectory di /usr/conf e
/stand.
•
opzione -c —assegna un valore (Y o N) all’indicatore ($CONFIGURE) di
configurazione del modulo specificato in preparazione per la successiva
configurazione del sistema.
•
opzione -l —assegna un valore (Y o N) all’indicatore ($LOADABLE)
caricabile del modulo specificato in preparazione della successiva
configurazione del sistema.
•
opzione -q —stampa i valori della configurazione e gli indicatori
caricabili del modulo specificato. Stampa un “-” (significa “non
applicare”) per l’indicatore caricabile di un modulo statico.
•
nessuna opzione o soltanto opzione -S —stampa i valori della
configurazione e gli indicatori caricabili di tutti i moduli. Stampa un “-”
per gli indicatori caricabili dei moduli statici.
•
opzione -l —stampa i valori di tutti i parametri di sistema.
•
opzione -q —richiede il valore del parametro di sistema specificato.
•
opzione -r — azzera il valore del parametro specificato sul suo valore di
default in preparazione della successiva configurazione del sistema.
•
opzione -s —assegna un valore al parametro di sistema specificato in
preparazione della successiva configurazione del sistema.
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-9
Set di strumenti di configurazione della kernel (segue)
Strumento/
Comando
kmupdate
Azione
•
Prima forma—prepara il sistema a spostare la kernel statica specifica
ed i file associati rispettivamente al file /stand/vmunix ed alla
directory /stand/dlkm nel corso del successivo spegnimento ed avvio
del sistema.
•
Seconda forma, opzione -M —sposta l’immagine configurata del modulo
caricabile specificato all’ubicazione in cui il caricatore DLKM può
trovarla e registra il modulo con la kernel (1) immediatamente o (2)
successivamente allo spegnimento del sistema.
Procedure DLKM per i moduli caricabili a configurazione
dinamica
Questa sezione fornisce le procedure dettagliate per la configurazione, il
caricamento e lo scaricamento dei moduli della kernel abilitati per
DLKM. Le informazioni procedurali sono illustrate in tre modi diversi. I
primi due sono formati riassuntivi ed il terzo fornisce i passi procedurali
dettagliati.
1. Diagramma di flusso procedurale DLKM
Usare questo grafico (Figura 3-5 a pagina 307) come riferimento per
visualizzare tutte le procedure e stabilire la sequenza corretta della
loro realizzazione.
2. Tabelle delle procedure di configurazione e gestione dei moduli
caricabili
Queste tabelle raggruppano le procedure in tre fasi: Procedure di
preparazione, caricamento e manutenzione. Vi è una tabella per ogni
tipo di modulo caricabile:
Capitolo 3
•
Tabella 3-10, “Procedure dei moduli caricabili a configurazione
dinamica” a pagina 308
•
Tabella 3-11, “Procedure dei moduli caricabili a configurazione
statica” a pagina 309
305
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
3. Procedure DLKM
Questa sezione presenta le istruzioni passo passo per la preparazione,
configurazione, caricamento e scaricamento (o attivazione) dei moduli
caricabili.
Le fasi dettagliate della procedura sono presentate in due sezioni:
306
•
“Procedure DLKM per i moduli caricabili a configurazione
dinamica” a pagina 305
•
“Procedure DLKM per i moduli caricabili a configurazione
statica” a pagina 315
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Figura 3-5
Diagramma di flusso procedurale DLKM
Avvio
Modulo caricabile a
configurazione dinamica
configurazione
dinamica o
statica?
Preparare il modulo come modulo caricabile a
configurazione dinamica usando il comando:
kmsystem -c Y -l Y
Modulo caricabile a
configurazione statica
Preparare il modulo come modulo caricabile a
configurazione statica usando il comando:
kmsystem -c Y -l N
OPZIONALE: Impostare il/i parametri di sistema forniti dal modulo o dalla kernel
statica usando il comando: kmtune -s
Configurare il modulo caricabile nel sistema usando
il comando: config -M
Spostare l’immagine del modulo caricabile al suo
posto e registrare il modulo usando il comando:
kmupdate -M
Configurare il modulo a collegamento statico nel
sistema costruendo la nuova kernel usando il
comando: config /stand/system
Preparare il sistema a migrare la nuova kernel al suo
posto durante il successivo spegnimento ed avvio del
sistema usando il comando:
kmupdate /stand/build/vmunix_test
Se necessario, creare uno o più file speciali del
dispositivo per il modulo caricabile usando il
comando: mknod
Caricare il modulo caricabile usando il comando:
kmadmin -L
Attivare il modulo a collegamento statico avviando la
nuova kernel usando il comando:
shutdown -r
OPZIONALE: Richiedere il modulo caricabile usando il comando kmadmin -q
OPZIONALE: Scaricare il modulo caricabile usando
il comando: kmadmin -U
OPZIONALE: Richiedere il modulo a collegamento
statico usando il comando: kmadmin -k
Se necessario, creare uno o più file speciali del
dispositivo per il modulo a collegamento statico
usando il comando: mknod
OPZIONALE: Rimuovere i componenti del
modulo dal sistema usando il comando:
kminstall -d
Fatto
Capitolo 3
307
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-10
Fase
Preparazione
Procedure dei moduli caricabili a configurazione dinamica
Opzione di
configurazione
Preparare il modulo
caricabile come modulo
caricabile a configurazione
dinamica
Procedura
Preparare un modulo caricabile per il
caricamento dinamico nella kernel HP-UX
Opzionale: Richiedere e/o impostare i
parametri del sistema forniti da un modulo
caricabile
Configurare un modulo caricabile per il
caricamento dinamico
Registrare un modulo caricabile a
configurazione dinamica con la kernel
Caricamento
Richiesta di caricamento
Caricare un modulo caricabile a
configurazione dinamica nella kernel
Manutenzione
Scaricamento
Scaricare un modulo caricabile a
configurazione dinamica
Impostazione
Impostare un modulo caricabile a
configurazione dinamica
Aggiornamento di un
modulo
Aggiornare l’immagine di un modulo
caricabile a configurazione dinamica
Richiesta di un modulo
Stabilire quali moduli caricabili a
configurazione dinamica siano attualmente
caricati
Ottenere informazioni sui moduli caricabili
a configurazione dinamica
308
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Tabella 3-11
Fase
Preparazione
Procedure dei moduli caricabili a configurazione statica
Opzione di
configurazione
Preparare il modulo
caricabile come modulo
caricabile a configurazione
statica
Procedura
Preparare un modulo caricabile per il
collegamento statico alla kernel HP-UX
Opzionale: interrogare e/o impostare i
parametri del sistema per un modulo
caricabile a configurazione statica presente
nella kernel statica
Configurare la kernel per includere il
modulo caricabile a configurazione statica
Caricamento
Attivazione di un modulo
caricabile a configurazione
statica
Attivazione di un modulo caricabile a
configurazione statica mediante riavvio
Manutenzione
Impostazione di un modulo
Impostare un modulo caricabile
Richiesta di un modulo
Stabilire quali moduli caricabili a
configurazione statica siano attualmente
caricati
Ottenere informazioni su un modulo
caricabile a configurazione statica
attualmente caricato
Tutti i moduli DLKM necessari ad avviare la kernel devono essere
configurati come moduli a configurazione statica.
Se il modulo che si sta configurando è necessario all’avvio della kernel,
consultare la procedura di configurazione in “Procedure DLKM per i
moduli caricabili a configurazione statica” a pagina 315.
Come preparare
un modulo
caricabile per il
caricamento
dinamico nella
kernel HP-UX
Capitolo 3
Usare il comando kmsystem per assegnare i valori (Y o N) agli indicatori di
configurazione ($CONFIGURE) e caricabili ($LOADABLE) nel file di
descrizione del sistema del modulo. Se l’indicatore caricabile non è
presente nel file di descrizione del sistema e si tenta di assegnargli un
valore, kmsystem esce comunicando un errore.
È possibile usare il comando kmsystem per preparare un modulo DLKM
per la configurazione come (1) dinamica o (2) statica.
309
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Per preparare un modulo caricabile perché sia caricato in modo dinamico
nella kernel, procedere come segue:
Come preparare
un modulo
caricabile per il
collegamento
dinamico
Punto
1. Eseguire questo comando kmsystem:
/usr/sbin/kmsystem -c Y -l Y nome_modulo
Come richiedere
ed impostare i
parametri del
sistema forniti da
un modulo
caricabile
Punto
Usare il comando kmtune per richiedere, impostare, o azzerare i
parametri (settaggi) del sistema usati dal modulo DLKM o la kernel
statica. kmtune legge i file di configurazione master, i file di descrizione
del sistema ed il file di sistema HP-UX.
Per un modulo in package modulare, kmtune scrive l’eventuale parametro
del sistema modificato dall’utente nel file di descrizione di sistema del
modulo. Per un modulo in package tradizionale che usa il packaging
precedente ad 11.0, kmtune scrive gli eventuali parametri del sistema
modificati dall’utente nel file di sistema HP-UX.
1. Per richiedere il valore di un parametro di sistema specifico, eseguire
questo comando kmtune:
/usr/sbin/kmtune -q nome_parametro_sistema
Punto
2. Per impostare il valore di un parametro di sistema specifico, eseguire
questo comando kmtune:
/usr/sbin/kmtune -s nome=valore_parametro_sistema
Punto
3. Per azzerare il valore di un parametro di sistema sul suo valore di default,
eseguire questo comando kmtune:
/usr/sbin/kmtune -r nome_parametro_sistema
A questo punto, sono stati impostati i valori dei parametri di sistema del
modulo per la successiva configurazione del modulo. I valori dei parametri
di sistema forniti dal modulo diverranno effettivi con la kernel in
esecuzione dopo che il modulo caricabile sarà configurato e registrato
(consultare le procedure alla pagina che segue).
310
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Come configurare
un modulo
caricabile per il
caricamento
dinamico
Punto
Una volta portata a termine la procedura di configurazione qui illustrata,
il modulo caricabile a configurazione dinamica sarà pronto al caricamento
immediato, il che significa che non occorre attendere un riavvio per
poterlo caricare.
1. Per configurare un modulo caricabile per il caricamento dinamico,
eseguire questo comando config:
/usr/sbin/config -M nome_modulo -u
Da ciò consegue la creazione di un’immagine caricabile. L’opzione -u forza
config a richiamare il comando kmupdate, che fa in modo che il sistema
sposti l’immagine appena creata in posizione e la registri con la kernel in
esecuzione.
Come registrare
un modulo a
configurazione
dinamica con la
kernel HP-UX
Per un modulo DLKM configurato come a caricamento dinamico, si usa il
comando kmupdate per aggiornare la sua immagine e registrarla con la
kernel. L’aggiornamento dell’immagine di un modulo caricabile a
configurazione dinamica significa spostare la sua immagine in posizione e
registrarla con la kernel (1) immediatamente o (2) successivamente allo
spegnimento del sistema.
Richiamare kmupdate dopo aver prima richiamato config. Se si include
l’opzione -u nel richiamo config, non occorre richiamare kmupdate. Il
comando config -M -u richiama automaticamente kmupdate.
Punto
1. Per aggiornare l’immagine di un modulo caricabile a configurazione
dinamica immediatamente, eseguire questo comando kmupdate:
/usr/sbin/kmupdate -M nome_modulo -i
Dopo aver aggiornato il modulo specificato e presumendo che il modulo
fosse caricato in origine, kmupdate ricaricherà il modulo prima di uscire.
Punto
2. Per aggiornare l’immagine di un modulo caricabile a configurazione
dinamica allo spegnimento del sistema, eseguire il seguente comando
kmupdate:
/usr/sbin/kmupdate -M nome_modulo -a
Se non si specifica l’opzione -i o -a, kmupdate tenterà di aggiornare il
modulo caricabile specificato immediatamente. Se non è possibile
aggiornare il modulo immediatamente (ad esempio, il modulo attuale è in
uso e non è possibile caricarlo), il modulo sarà aggiornato allo
spegnimento del sistema.
Capitolo 3
311
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Come caricare un
modulo a
configurazione
dinamica nella
kernel HP-UX
Per caricare un modulo caricabile a configurazione dinamica, si usa
l’opzione -L del comando kmadmin. L’operazione di caricamento iniziata
dal comando kmadmin -L realizza tutte le procedure associate al
collegamento modificando il modulo sulla kernel in esecuzione e rendendo
il modulo accessibile al sistema.
Nello specifico, l’operazione di caricamento realizza le seguenti procedure:
Punto
•
verifica da quali altri moduli dipenda il modulo caricabile e carica
automaticamente questi eventuali moduli non attualmente caricati
•
alloca spazio nella memoria attiva per il modulo caricabile specificato
•
carica il modulo caricabile specificato dal disco e lo collega-modifica
nella kernel in esecuzione
•
ubica nuovamente i simboli del modulo caricabile e risolve gli
eventuali riferimenti che il modulo fa a simboli esterni
•
richiama il punto della voce _load() del modulo a realizzare
l’eventuale inizializzazione e configurazione specifica del modulo
•
connette in modo logico il modulo al resto della kernel, il che spesso si
realizza con l’aiuto di funzioni di installazione specifiche del tipo di
modulo alle quali si accede attraverso il codice wrapper del modulo
1. Per caricare un modulo caricabile a configurazione dinamica nella kernel
in esecuzione, eseguire il seguente comando kmadmin:
/usr/sbin/kmadmin -L nome_modulo
Una volta portato a termine il caricamento, sull’output standard viene
stampato un numero identificatore (ID) per identificare il modulo
caricato.
Se si desidera che il sistema carichi in modo automatico determinati
moduli caricabili a configurazione dinamica immediatamente dopo ogni
riavvio del sistema, aggiungere i nomi dei moduli al file /etc/loadmods.
Al momento dell’avvio, lo script /sbin/init.d/kminit eseguirà il
comando kmadmin e caricherà i moduli elencati in /etc/loadmods.
Come scaricare un Usare l’opzione -U o -u del comando kmadmin per scaricare un modulo
modulo caricabile DLKM configurato come a configurazione dinamica. È possibile scegliere
se scaricare il modulo attraverso il suo nome o il suo numero ID.
a configurazione
dinamica
312
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
L’operazione di scaricamento scollega in modo logico il modulo dalla
kernel in esecuzione e richiama il punto della voce _unload() del modulo
per realizzare l’eventuale pulizia specifica del modulo incluso:
1. annullamento delle chiamate in attesa su timeout()
2. disabilitazione degli interrupt del dispositivo
3. liberamento di tutta la memoria attiva allocata al modulo caricabile
specificato
Punto
1. Per scaricare un modulo caricabile a configurazione dinamica mediante il
nome, eseguire questo comando kmadmin:
/usr/sbin/kmadmin -U nome_modulo
Punto
2. Per scaricare un modulo caricabile a configurazione dinamica mediante il
numero ID, eseguire questo comando kmadmin:
/usr/sbin/kmadmin -u id_modulo
Come stabilire
quali siano i
moduli attualmente caricati
Usare l’opzione -S o -s del comando kmadmin per visualizzare le
informazioni dettagliate su tutti i moduli DLKM attualmente registrati.
Punto
1. Per stampare lo stato completo di tutti i moduli caricabili a configurazione
dinamica attualmente registrati, eseguire questo comando kmadmin:
/usr/sbin/kmadmin -S
Punto
2. Per stampare uno stato riassuntivo di tutti i moduli caricabili a
configurazione dinamica attualmente caricati, eseguire questo comando
kmadmin:
/usr/sbin/kmadmin -s
Punto
3. Per stampare una lista di tutti i moduli a configurazione statica, eseguire
il seguente comando kmadmin:
/usr/sbin/kmadmin -k
Usare l’opzione -Q o -q del comando kmadmin per visualizzare le
Come ottenere
informazioni su un informazioni dettagliate sul modulo DLKM. Per un modulo DLKM
modulo caricato
configurato come a caricamento dinamico, si dispone della scelta di
visualizzare le informazioni per il modulo attraverso il suo nome o il suo
numero ID.
Capitolo 3
313
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Punto
1. Per visualizzare lo stato di un modulo caricabile a configurazione
dinamica mediante il nome, eseguire questo comando kmadmin:
/usr/sbin/kmadmin -Q nome_modulo
Punto
2. Per visualizzare lo stato di un modulo caricabile a configurazione
dinamica mediante ID, eseguire il seguente comando kmadmin:
/usr/sbin/kmadmin -q id_modulo
A seconda del tipo di modulo, possono essere stampate anche le
informazioni sul numero principale di blocco del modulo, il numero
principale di carattere e gli indicatori.
Tra le informazioni restituite dalle opzioni -Q e -q è incluso:
314
•
il nome del modulo
•
l’ID del modulo
•
il nome di percorso del modulo sul suo file dell’oggetto su disco
•
lo stato del modulo (LOADED o UNLOADED)
•
le dimensioni del modulo
•
l’indirizzo di carico virtuale del modulo
•
le dimensioni della memoria di Block Started by Symbol (BSS) (le
dimensioni della memoria dello spazio non inizializzato del segmento
dati del file dell’oggetto del modulo)
•
l’indirizzo base di BSS
•
il conteggio di riferimento o attesa del modulo (il numero di processi
che stanno attualmente usando il modulo)
•
il conteggio dipendente del modulo (il numero di moduli che
attualmente dipendono da questo modulo in caricamento; dipende sui
moduli specificati nella sezione $DRIVER_DEPENDENCY del file master
del modulo)
•
il valore di ritardo scarico del modulo (attualmente non in
uso—sempre 0 secondi)
•
il nome descrittivo del modulo
•
il tipo di modulo (WSIO, STREAMS, o Misc)
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Procedure DLKM per i moduli caricabili a configurazione statica
È possibile usare il comando kmsystem per preparare un modulo DLKM
per la configurazione come (1) a caricamento dinamico o (2) a
configurazione statica.
Come preparare
un modulo
caricabile per il
collegamento
statico
Punto
Usare il comando kmsystem per assegnare i valori (Y o N) agli indicatori di
configurazione ($CONFIGURE) e caricabili ($LOADABLE) nel file di
descrizione del sistema del modulo. Se l’indicatore caricabile non è
presente nel file di descrizione del sistema e si tenta di assegnargli un
valore, kmsystem esce comunicando un errore.
1. Per preparare un modulo DLKM per il collegamento statico alla kernel
HP-UX, eseguire questo comando kmsystem:
/usr/sbin/kmsystem -c Y -l N nome_modulo
Come interrogare
ed impostare i
parametri del
sistema per un
modulo caricabile
a configurazione
statica presente
nella kernel statica
Usare il comando kmtune per richiedere, impostare, o azzerare i
parametri (settaggi) del sistema usati dal modulo DLKM o la kernel
statica. kmtune legge i file di configurazione master, i file di descrizione
del sistema ed il file di sistema HP-UX.
Per un modulo in package modulare o un modulo in package tradizionale
che usa packaging di modulo 11.0, kmtune scrive gli eventuali parametri
del sistema modificati dall’utente nel file di descrizione del sistema del
modulo. Per un modulo in package tradizionale che usa il packaging
precedente ad 11.0, kmtune scrive gli eventuali parametri del sistema
modificati dall’utente nel file di sistema HP-UX.
Per richiedere il valore di un parametro di sistema specifico, eseguire
quanto segue:
Punto
1. Eseguire questo comando kmtune:
/usr/sbin/kmtune -q nome_parametro_sistema
Punto
2. Per impostare il valore di un parametro di sistema specifico, eseguire
questo comando kmtune:
/usr/sbin/kmtune -s nome=valore_parametro_sistema
Punto
3. Per azzerare il valore di un parametro di sistema sul suo valore di default,
eseguire questo comando kmtune:
/usr/sbin/kmtune -r nome_parametro_sistema
Capitolo 3
315
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
A questo punto, sono stati impostati i valori dei parametri di sistema che
produrranno il loro effetto dopo la successiva totale configurazione della
kernel HP-UX, aggiornamento e riavvio del sistema (consultare le
procedure a seguire).
Come configurare
la kernel HP-UX
per includere un
modulo caricabile
a configurazione
statica
Punto
È possibile usare il comando config per configurare un modulo DLKM
nel sistema come a caricamento dinamico o a configurazione statica.
Usare questa procedura per collegare staticamente il modulo DLKM ad
una nuova kernel.
Per configurare la kernel HP-UX per includere un modulo caricabile a
configurazione statica, procedere come segue:
1. Eseguire questo comando config:
/usr/sbin/config -u /stand/system
config costruisce una nuova kernel. L’opzione -u forza config a
richiamare il comando kmupdate, che fa in modo che il sistema realizzi le
seguenti azioni quando si spegne e si riavvia il sistema:
a. salvare il file della kernel esistente e la sua directory di set di funzioni
della kernel come/stand/vmunix.prev e
/stand/dlkm.vmunix.prev, rispettivamente
b. spostare il file della kernel appena creato e la directory del suo set di
funzioni kernel nelle loro ubicazioni di default, /stand/vmunix e
/stand/dlkm, rispettivamente
Dopo il riavvio del sistema, il modulo DLKM sarà disponibile come a
configurazione statica nella nuova kernel in esecuzione.
316
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Glossario DLKM
Caricamento
automatico
CDIO
Context-Dependent Input/Output (Input/output
dipendente dal contesto). Funzionalità del sottosistema
I/O di HP-UX che fornisce un’interfaccia coerente per i
bus I/O ed i driver del dispositivo.
DLKM
Dynamically Loadable Kernel Module (Modulo della
kernel a caricamento dinamico). Funzionalità
disponibile in HP-UX 11i che supporta il caricamento e
lo scaricamento dinamico dei moduli della kernel, per
evitare di sprecare memoria mantenendo i moduli nel
nucleo quando non si utilizzano.
DMA
Direct Memory Access (Accesso diretto alla memoria).
Trasferimento ad alta velocità di grandi quantità di dati
tra la memoria del computer ed un dispositivo periferico
senza coinvolgere l’unità di elaborazione centrale del
computer. L’unità di elaborazione centrale viene
arrestata durante il trasferimento dei dati e riprende il
funzionamento una volta trasmesse tutte le
informazioni.
Modulo della
kernel
Capitolo 3
Capacità resa possibile attraverso la funzionalità
DLKM. Il caricamento automatico si verifica quando la
kernel rileva la necessità di un modulo caricabile
specifico per la realizzazione di qualche procedura
particolare, ma il modulo non è al momento caricato. La
kernel carica automaticamente il modulo. Durante un
caricamento automatico, la kernel carica anche gli
eventuali moduli dai quali dipende il modulo in
caricamento, proprio come fa durante un caricamento a
richiesta.
Sezione di codice responsabile di supportare una
capacità o funzionalità specifica. Di solito, tale codice si
conserva in file e/o archivi dell’oggetto singoli,
consentendo l’inclusione o l’esclusione condizionale dei
moduli nella/dalla kernel, a seconda che si desiderino o
meno le funzionalità da essi supportate.
317
Configurazione di un sistema
Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)
Modwrapper
Codice aggiuntivo e strutture dati aggiunti ad un
modulo DLKM al fine di renderlo dinamico.
PCI
Peripheral Component Interconnect (Interconnessione
del componente periferico). Bus su standard industriale
usato sui sistemi HP-UX per fornire I/O di espansione.
Stream
Connessione supportata dai servizi STREAMS tra un
processo dell’utente ed un driver del dispositivo. Si
tratta di una struttura costituita da moduli collegati,
ciascuno dei quali elabora le informazioni trasmesse e le
passa al modulo successivo. È possibile usare
STREAMS per connettere una varietà di configurazioni
hardware e software, usando blocchi di costruzione, o
moduli, che possono essere sovrapposti insieme. I driver
ed i moduli STREAMS sono simili in quanto entrambi
devono dichiarare le stesse strutture e fornire la stessa
interfaccia. Soltanto i driver STREAMS gestiscono
l’hardware fisico e devono pertanto essere responsabili
degli interrupt di gestione se è il caso.
Tipo di modulo Un tipo di modulo si distingue attraverso il meccanismo
usato per conservare i moduli di quel tipo nell’ambito
della kernel. I moduli DLKM si classificano secondo un
numero fisso di tipi di moduli supportati.
WSIO
318
WSIO Workstation Input/Output (Input/output della
workstation). Ambiente ben definito fornito per
l’implementazione driver su workstation e server
HP-UX.
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Riconfigurazione della kernel
(HP-UX 11i versione 2)
NOTA
Questa sezione vale per le release di HP-UX a partire da 11i versione 2.
Per le procedure precedenti alla 11i versione 2, consultare
“Riconfigurazione della kernel (Prima di HP-UX 11i versione 2)” a
pagina 284.
Introduzione
Con ciascuna release successiva di HP-UX, gli amministratori di sistema
dispongono di una maggiore capacità di apportare modifiche alla
configurazione della kernel HP-UX senza dover subire costosi e spiacevoli
tempi di fermo. Innovazioni tipo i settaggi dinamici della kernel ed i
moduli a caricamento dinamico consentono la realizzazione delle
procedure manutenzione critica senza dover sacrificare la disponibilità
delle applicazioni.
Con queste innovazioni insorge la necessità di un meccanismo più
semplice e più esauriente per gestire le configurazioni della kernel.
HP-UX 11i versione 2 introduce una nuova suite di comandi di gestione di
configurazione della kernel ed una nuova interfaccia grafica su base web
che fornisce gestione di configurazione della kernel unificata. Questa
sezione descrive l’uso di questi nuovi strumenti. È stata pensata per
essere usata dagli amministratori di sistema HP-UX.
Funzionalità di configurazione della kernel
La nuova suite di strumenti di configurazione della kernel fornisce varie
funzionalità per gli amministratori di sistema:
Capitolo 3
•
È possibile realizzare tutte le procedure di configurazione della kernel
in un’unica interfaccia grafica.
•
Inoltre, è possibile realizzare tutte le procedure di configurazione
della kernel con un set coesivo di comandi con la stessa interfaccia
utente e lo stesso comportamento.
•
È possibile salvare e riprendere le configurazioni della kernel e
spostarle tra sistemi.
319
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
•
Gli amministratori possono salvare qualsiasi numero di
configurazioni della kernel e possono passare tra loro quando
desiderano, spesso senza dover riavviare.
•
Prima di ogni modifica di configurazione, viene realizzato un backup
automatico della configurazione della kernel in esecuzione (se lo si
desidera).
•
Il sistema conserva automaticamente un file di log dettagliato di tutte
le modifiche di configurazione della kernel.
•
I moduli della kernel ed i parametri settabili della kernel ora hanno
delle descrizioni associate loro. I parametri settabili della kernel
hanno documentazioni in linea e descrizioni dei rapporti tra di essi.
•
Tutti i comandi di configurazione della kernel possono produrre un
output sia in formato accessibile all’utente sia in formato accessibile
allo script. HP supporta compatibilità da release a release per i
formati accessibili allo script.
Cos’è una configurazione della kernel?
Dal punto di vista logico, una configurazione della kernel è una raccolta di
tutte le scelte e delle impostazioni dell’amministratore necessari a
stabilire il comportamento e le capacità della kernel HP-UX. In questa
implementazione, la raccolta include:
•
•
•
•
•
•
un set di assegnazioni di valori ai parametri settabili della kernel
un set di moduli della kernel, ciascuno con uno stato desiderato
una specifica del dispositivo di scambio primario
un set di specifiche del dispositivo di copiatura
un set di specificazioni dei dispositivi sui driver dei dispositivi
un nome ed una descrizione opzionali della configurazione della
kernel
Dal punto di vista fisico, una configurazione della kernel è una directory
sotto /stand contenente i file necessari a realizzare il comportamento
specificato. La directory include:
•
•
•
•
•
320
un eseguibile della kernel HP-UX
un set di file dei moduli della kernel HP-UX
un database del registro della kernel, contenente tutte le impostazioni
di cui sopra
un file del sistema, che descrive le impostazioni sopra menzionate in
forma leggibile dall’uomo
vari altri file specifici dell’implementazione
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Oltre alla configurazione della kernel in esecuzione, i sistemi HP-UX
possono disporre di un certo numero di configurazioni della kernel
salvate, limitato solo dallo spazio su disco disponibile in /stand.
Panoramica dei comandi di configurazione della kernel
Vi sono tre comandi primari usati per gestire le configurazioni della
kernel: kconfig, kcmodule e kctune.
kconfig si usa per gestire le configurazioni della kernel complessive. Esso
consente di salvare, caricare, copiare, rinominare, cancellare, esportare,
importare ecc. le configurazioni. Inoltre, può elencare le configurazioni
salvate esistenti e fornire i dettagli su di esse. Per ulteriori informazioni,
consultare “Gestione delle configurazioni salvate con kconfig” a
pagina 358 o la manpage kconfig (1M).
kcmodule si usa per gestire i moduli della kernel. Possono essere moduli
della kernel i driver del dispositivo, i sottosistemi della kernel o altre
entità del codice della kernel. Ciascun modulo può essere inutilizzato, a
collegamento statico all’eseguibile della kernel principale o a caricamento
dinamico. kcmodule visualizzerà o modificherà lo stato di qualsiasi
modulo nella configurazione in esecuzione attualmente o di qualsiasi
configurazione salvata. Per ulteriori informazioni, consultare “Gestione
dei moduli della kernel con kcmodule” a pagina 329 o la manpage
kcmodule (1M).
kctune si usa per gestire i parametri settabili della kernel. Si tratta di
variabili che controllano il comportamento della kernel. Essi hanno molti
usi; fra i più comuni, vi sono il controllo dell’allocazione delle risorse del
sistema e gli aspetti di settaggio delle prestazioni della kernel. kctune
visualizzerà o modificherà il valore di qualsiasi parametro settabile della
configurazione in esecuzione attualmente o di qualsiasi configurazione
salvata. Per ulteriori informazioni, consultare “Gestione dei parametri
settabili della kernel con kctune” a pagina 339 o la manpage kctune (1M).
Oltre a questi tre comandi primari, vi sono altri due comandi di
configurazione della kernel. Il comando kcpath stampa le informazioni
sull’ubicazione della kernel attualmente in esecuzione; è pensato per
essere usato dagli script e dalle applicazioni cui occorrano tali
informazioni; per i dettagli, consultare la manpage kcpath (1M)). Il
comando kclog ricerca il file di log di configurazione della kernel; per i
dettagli, consultare “Il file di log di configurazione della kernel” a
pagina 369 o la manpage kclog (1M).
Capitolo 3
321
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Infine, gli utenti dei comandi mk_kernel, kmpath e kmtune presenti nelle
release precedenti di HP-UX devono sapere che è ancora possibile usare
tali comandi. Essi sono stati reimplementati come piccoli script della shell
che richiamano i comandi elencati in precedenza. Questi comandi più
vecchi sono in obsolescenza e saranno rimossi in una release futura.
Consultare mk_kernel (1M), kmpath (1M) e kmtune (1M).
Panoramica dello strumento kcweb
È possibile configurare e gestire la kernel senza dover ricordare la
sintassi dei comandi di configurazione della kernel o i nomi esatti dei
moduli e dei parametri settabili usando kcweb, lo strumento di
configurazione della kernerl HP-UX su base web ed accessibile dall’utente
per configurare e gestire la kernel del sistema. kcweb ha le seguenti
caratteristiche:
322
•
interfaccia grafica utente accessibile dall’utente e su base web (GUI)
•
gestione dei parametri settabili della kernel: monitor e modifica
•
gestione allarmi: aggiunta, modifica e rimozione
•
gestione dello stato dei moduli della kernel: modifica
•
accesso alle manpage per i parametri settabili
•
anteprima del comando – Quando si modifica un parametro settabile,
un modulo o un allarme, è possibile usare la funzionalità di anteprima
del comando scegliendo il pulsante ?. Ciò mostrerà il richiamo del
comando di configurazione della kernel che realizzerà la procedura
richiesta.
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-6
Videata campione di kcweb
È possibile accedere a kcweb in uno qualsiasi dei seguenti modi:
•
dalla riga di comando con il comando kcweb
•
dall’HP Service Control Manager (SCM)
•
dall’area di configurazione della kernel (kcweb) di SAM
•
da un web browser, usando l’URL di un server kcweb che è già stato
avviato
Per default, kcweb richiama il web browser Mozilla. Se si desidera
invocare kcweb con qualsiasi altro browser, impostare la variabile di
ambiente BROWSER sul nome del percorso del browser che si desidera
usare. Per ulteriori dettagli, consultare la manpage kcweb (1M).
Capitolo 3
323
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Altre operazioni di configurazione della kernel
Le altre sezioni a continuazione descrivono alcune operazioni di
configurazione della kernel speciali ed usi speciali dei comandi di
configurazione della kernel.
L’uso di alcune risorse della kernel può essere monitorato con allarmi
emessi quando l’uso oltrepassa una soglia impostata. Tali allarmi
possono essere configurati ed esaminati usando il comando kcalarm o lo
strumento kcweb. L’uso delle risorse può essere esaminato usando il
comando kcusage o lo strumento kcweb. Per ulteriori informazioni,
consultare “Monitoraggio dell’uso delle risorse della kernel” a pagina 351.
Gli amministratori di versioni più vecchie di HP-UX potrebbero essere abituati ad usare i file di testo (“file di sistema” o “dfile”) per specificare le configurazioni della kernel ed apportare loro modifiche. Il formato di tali file
è stato migliorato1 perché si adatti alle innovazioni della nuova configurazione della kernel, conservando tuttavia l’utilità di un file di testo per le
operazioni di configurazione (sono particolarmente utili quando si usa la
stessa configurazione su sistemi multipli, dato che è possibile spostarli con
facilità tra i sistemi). L’uso di file di sistema è descritto in “Gestione delle
configurazioni con i file di sistema” a pagina 361.
Alcune impostazioni di configurazione non comuni possono essere controllate soltanto attraverso l’uso dei file di sistema. Fra queste, vi sono l’impostazione del dispositivo di scambio primario, l’impostazione dei dispositivi
di copiatura iniziale e la specificazione esplicita di dispositivi specifici su
moduli del driver del dispositivo specifico. Per ulteriori informazioni, consultare “Gestione delle specificazioni del dispositivo” a pagina 366.
Tutte le modifiche di configurazione della kernel realizzare usando i
comandi di configurazione della kernel sono registrate nel file
/var/adm/kc.log. È possibile reperire i dettagli su questo file di log in “Il
file di log di configurazione della kernel” a pagina 369 e nella manpage
kconfig (5) e kclog (1M).
I comandi di configurazione della kernel primari supportano un formato
di output specializzato progettato per essere usato dagli script e dalle
applicazioni che devono analizzare sintatticamente l’output dei comandi.
Tali script ed applicazioni devono usare questo formato di output
specializzato dato che HP non assicura la compatibilità da release a
1. I formati dei file di sistema da release precedenti di HP-UX sono
ancora accettati.
324
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
release per qualsiasi altro formato di output di questi comandi. Ulteriori
dettagli disponibili in “Analisi sintattica dell’output dei comandi” a
pagina 370e nella manpage kconfig (5).
È possibile avere una configurazione della kernel indesiderata o perfino
non avviabile a causa di modifiche della configurazione errate, guasti
hardware o difetti software. Esistono dei meccanismi sia per evitare tali
problemi sia per aiutare a risolverli. Per ulteriori dettagli, consultare
“Recupero dagli errori” a pagina 371.
Comportamento comune per i comandi di
configurazione della kernel
Poichè i comandi di configurazione della kernel fanno parte di una suite
unica, essi condividono, ogniqualvolta sia possibile, lo stesso
comportamento. Fra i comportamenti condivisi vi sono le opzioni della
riga di comando, i formati di output, i codici di stato di uscita, i vincoli di
sicurezza e la persistenza delle modifiche.
Opzioni della riga di comando comuni
La Tabella 3-12 elenca le opzioni condivise dai comandi di configurazione
della kernel.
Tabella 3-12
Opzione
Opzioni condivise dai comandi di configurazione della kernel
Descrizione
k
c
o
n
f
i
g
k
c
m
o
d
u
l
e
k
c
t
u
n
e
-a
(all) Include informazioni nell’output che di solito si omettono
per brevità.
o
o
o
-B
(Backup) Esegue il backup della configurazione attualmente in
esecuzione prima di modificarla.
o
o
o
-c
(configuration) Specifica la configurazione salvata da gestire. Se
omesso, gestisce la configurazione attualmente in esecuzione.
o
o
Capitolo 3
k
c
l
o
g
o
325
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-12
Opzione
-C
Opzioni condivise dai comandi di configurazione della kernel
Descrizione
(Comment) Include un commento nella voce del file di log di
configurazione della kernel associata al richiamo di questo
comando.
k
c
o
n
f
i
g
k
c
m
o
d
u
l
e
k
c
t
u
n
e
k
c
l
o
g
o
o
o
o
o
o
-d
(description) Visualizza le descrizioni per ogni voce.
-D
(Difference) Visualizza solo gli elementi per i quali vi sia una
modifica da tenere in sospeso per l’avvio successivo.
o
o
o
-h
(hold) Mantiene le modifiche richieste per l’avvio successivo.
o
o
o
-K
(Keep) Non esegue il backup della configurazione attualmente
in esecuzione. Mantiene il backup esistente immutato.
o
o
o
-P
(Parse) Usa lo speciale formato di output “analizzabile
sintatticamente”.
o
o
o
-S
(Set) Visualizza solo gli elementi che sono stati impostati su
qualcosa di diverso dal valore di default.
o
o
o
-v
(verbose) Visualizza le voci usando il formato di output verboso.
o
o
o
Formati di output comuni
Quando si recuperano delle informazioni, i comandi di configurazione
della kernel primari producono output in tre formati di output di base:
tabella, verboso ed analizzabile sintatticamente.
Per default, i comandi producono un formato tabella breve. Si tratta di un
formato che produce una riga per ciascuna voce descritta. Sono incluse
solo le informazioni usate più comunemente, al fine di consentire
all’output di adattarsi su una riga sulla maggior parte dei terminali.
326
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Con un’opzione -v (verbose), i comandi producono un formato di output
verboso. Questo formato produce tutte le informazioni disponibili per
ciascuna voce descritta, occupando a tal fine righe multiple. Una riga
vuota separa le voci dell’output.
Con un’opzione -P (Parse), i comandi producono un format di output destinato ad essere analizzato sintatticamente da script o applicazioni. Questo
formato è descritto in “Analisi sintattica dell’output dei comandi” a
pagina 370. Gli script e le applicazioni devono analizzare sintatticamente
questo formato di output, perchè HP supporta la compatibilità da release
a release del formato di output solo quando si usa l’opzione -P.
I comandi di configurazione della kernel usano tutti un formato comune
per i messaggi di errore, avvertimento, nota ed avanzamento. Si tratta
dello stesso formato usato dal pacchetto Software Distributor e pertanto
già noto alla maggior parte degli amministratori.
ERROR:
Si tratta di un messaggio di errore. Esso spiega il motivo
del mancato completamento dell’operazione richiesta.
WARNING:
Si tratta di un messaggio di avvertimento. L’operazione
richiesta è stata portata a termine, ma non senza
problemi. Potrebbe esservi una situazione da
correggere.
NOTE:
Si tratta di una nota. Essa fornisce informazioni sulle
modalità con cui l’operazione è stata portata a termine,
o altre informazioni di potenziale interesse per
l’amministratore.
*
Si tratta di un messaggio di avanzamento. Esso
visualizza le fasi portate a termine nel corso
dell’operazione.
Codici di stato di uscita comuni
Tutti i comandi di configurazione della kernel escono con uno dei codici di
stato presenti nella Tabella 3-13.
Tabella 3-13
Capitolo 3
Codici di stato di uscita
0
Operazione riuscita.
1
Non è stato possibile applicare le modifiche richieste al sistema attualmente
in esecuzione. Sono tenute in sospeso e saranno applicate al prossimo riavvio.
2
Non è stato possibile portare a termine con successo l’operazione.
327
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Vincoli di sicurezza comuni
Qualsiasi utente può eseguire i comandi di configurazione della kernel per
richiedere le informazioni sulla configurazione. Tuttavia, l’accesso alle
informazioni sulla configurazione è soggetto ai permessi del file system
Unix standard sui relativi file.
Al fine di poter realizzare qualsiasi modifica di configurazione, occorrono
privilegi di superutente.
Permanenza delle modifiche
Per default, gli strumenti di configurazione della kernel applicheranno le
modifiche di configurazione al sistema attualmente in corso,
provocandone un immediato cambiamento di comportamento. Gli
amministratori di sistema possono ignorare tale default specificando
l’opzione -h (hold) su qualsiasi comando. Tale opzione tiene in sospeso le
modifiche fino al riavvio del sistema. HP consiglia di usare questa opzione
soltanto quando si prevede che il riavvio successivo avvenga in tempi
brevi. Se il riavvio non si verifica per mesi dopo la modifica, quest’ultima
potrebbe giungere come una sorpresa poco gradita ad un amministratore
che ne avesse ormai dimenticato la richiesta.
Alcune modifiche di configurazione non possono essere applicate senza un
riavvio. Tali modifiche saranno tenute in sospeso fino al riavvio del
sistema anche se non si specifica l’opzione –h. In questi casi, sarà
stampato un messaggio di avvertimento.
Se si richiedono modifiche di configurazione multiple in un unico richiamo
di uno dei comandi di configurazione della kernel, ed una di tali modifiche
richiede un riavvio, tutte le modifiche richieste saranno tenute in sospeso
fino al riavvio del sistema. In particolare, se si carica la configurazione di
una kernel salvata usando kconfig –l (load), e non è possibile usare tale
configurazione senza un riavvio, lo stato del sistema in esecuzione non
cambia ed invece al riavvio successivo sarà usata la configurazione della
kernel specificata.
Le modifiche tenute in sospeso per il riavvio successivo possono essere
elencate usando l’opzione -D (Differences) sui comandi kcmodule, kctune,
o kconfig. Per ulteriori dettagli su ciascuno di tali comandi, consultare la
sezione seguente.
328
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Le modifiche tenute in sospeso per il riavvio successivo non sono tenute in
considerazione quando si sostituisce la configurazione in esecuzione
attualmente usando kconfig –i (import), kconfig –l (load), o
kconfig –n (next boot); quando sono esplicitamente scartate usando
kconfig –H (unHold); o quando si realizzano modifiche successive che le
superano. Ad esempio, se si esegue:
# kctune –h nproc=5000 impostare su 5000, tenere in
sospeso per il riavvio successivo
# kctune nproc=6000
impostare su 6000, ora
il valore di nproc al riavvio successivo sarà di 6000. la modifica su 5000
viene scartata. In casi simili, sarà stampato un messaggio di
avvertimento.
Le modifiche realizzare al sistema attualmente in esecuzione sono
trattenute quando si riavvia il sistema. Esse restano in vigore fino a che
non si modifichino.
Gestione dei moduli della kernel con kcmodule
Il comando kcmodule si usa per interrogare e modificare gli stati dei
moduli della kernel, nella configurazione attualmente in esecuzione o in
una configurazione salvata. La kernel di HP-UX si costruisce da un certo
numero di moduli, ciascuno dei quali è un driver del dispositivo, un
sottosistema della kernel, o qualche altro corpo del codice della kernel.
Una kernel tipica contiene 200-300 moduli.
Ottenimento delle informazioni sui moduli
Quando si esegue kcmodule senza alcuna opzione, esso mostra i moduli
del sistema, il loro stato attuale e lo stato in cui saranno al riavvio
successivo. Su un sistema tipico, si vedranno molti moduli in stato static;
alcuni moduli che sono inutilizzati, che sono spesso driver del dispositivo
per dell’hardware di cui il sistema non dispone e un certo numero di
moduli in stato caricato (gli stati sono descritti di seguito).
Quando si usa l’opzione -c (configuration), kcmodule visualizza le
informazioni sul modulo provenienti da una configurazione salvata invece
che dal sistema in esecuzione attualmente.
L’output di kcmodule può essere variato con diverse opzioni. Per verificare
quali moduli siano elencati, usare le opzioni -a (all), -D (Differences) e/o
-S (Set). L’opzione -a aggiunge moduli necessari all’output (di solito, essi
sono omessi). L’opzione -D limita l’output soltanto a quei moduli il cui
Capitolo 3
329
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
stato al riavvio successivo sia diverso dal loro stato attuale. L’opzione -S
limita l’output ai moduli il cui stato sia stato impostato esplicitamente
(cioè, omette i moduli necessari, i moduli non utilizzati e quelli aggiunti
per soddisfare una dipendenza). L’output può anche essere limitato
elencando i nomi dei moduli sulla riga di comando.
Per verificare il formato dell’output, usare le opzioni -d (description), -v
(verbose), o -P (Parse). In assenza di tali opzioni, l’output ha il seguente
aspetto:
Module
fcms
krs
State
static
static
Cause
depend
required
L’opzione -d aggiunge la descrizione di ogni modulo.
Module
fcms
krs
State
static
static
Cause
depend
required
Description
Fibre Channel Mass Storage Driver
Kernel Registry Service
L’opzione -v fornisce informazioni verbose, multiriga su ogni modulo:
Name
Description
State
Capable
Depends On
fcms [3E4741A9]
Fibre Channel Mass Storage Driver
static (to resolve dependencies)
unused static
module libfcms
interface HPUX_11_23 1.0.0
Name
Description
State
Capable
Depends On
krs [3E47419F]
Kernel Registry Service
static (required)
static
module libkrs
module libkrs_pdk
interface HPUX_11_23 1.0.0
L’opzione -P, che è destinata ad essere usata da script o programmi, offre
il controllo completo su quali informazioni siano stampate:
# kcmodule -P name,desc fcms krs
name
fcms
desc
Fibre Channel Mass Storage Driver
name
krs
desc
Kernel Registry Service
330
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Per ulteriori informazioni sull’opzione -P (Parse) ed il suo uso da parte di
script o programmi, consultare “Analisi sintattica dell’output dei
comandi” a pagina 370 o la manpage kconfig (5).
Interpretazione delle informazioni sul modulo
Guardando all’output di esempio precedente, è possibile vedere come ogni
modulo abbia una descrizione di nome e di testo. Ogni modulo ha anche
una versione, che di solito ha l’aspetto di [3E36E5FA] o 0.1.0, a seconda
dell’età del modulo. I moduli più vecchi usano la prima forma e quelli più
recenti la seconda.
La configurazione di una kernel può usare soltanto una versione di un
dato modulo. Tuttavia, potrebbero essere elencate versioni multiple se, ad
esempio, il sistema attualmente in esecuzione sta usando una versione
diversa di un modulo proveniente da quello che si userà al riavvio
successivo. Di solito, i numeri di versione sono omessi da un elenco breve,
ma saranno inclusi se di un modulo esiste più di una versione.
Ogni modulo della kernel della configurazione attualmente in esecuzione
ha uno stato, che descrive come si usa il modulo. Gli stati possibili sono:
Capitolo 3
unused
Il modulo è installato sul sistema, ma non è in uso.
static
Il modulo è collegato in modo statico nell’eseguibile della
kernel. Si tratta dello stato più comune. Per spostare un
modulo dentro o fuori da questo stato, occorre ricollegare
l’eseguibile della kernel e riavviare.
loaded
Il modulo è caricato in modo dinamico nella kernel. I
moduli più recenti supportano questo stato. Tali moduli
possono essere aggiunti all configurazione della kernel o
rimossi da essa senza riavviare.
auto
Il modulo sarà caricato in modo dinamico nella kernel
quando servirà per la prima volta, ma non si è ancora reso
necessario.
331
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Quando kcmodule offre delle informazioni sul sistema attualmente in
esecuzione e vi sono delle modifiche di configurazione in sospeso per il
riavvio successivo, kcmodule elencherà sia lo stato attuale sia quello al
riavvio successivo. Per il riavvio successivo, si usano gli stessi stati, con
significati complementari:
unused
Il modulo non sarà usato.
static
Il modulo sarà collegato in modo statico nell’eseguibile della kernel.
loaded
Il modulo sarà caricato in modo dinamico nella kernel durante il processo di
avvio.
auto
Il modulo sarà caricato in modo dinamico nella kernel quando si renderà
necessario dopo ciascun avvio.
Quando kcmodule offre informazioni su una configurazione salvata, si
usano gli stessi stati.
A fianco dello stato di ciascun modulo vi è una “causa”, che informa del
motivo per cui il modulo è (o sarà) in quello stato. Le cause sono:
explicit
L’amministratore di sistema ha scelto esplicitamente lo stato.
best
L’amministratore di sistema ha scelto di usare il modulo, ma non ha scelto uno
stato specifico, pertanto il modulo si trova nel suo stato “migliore” così come
determinato dallo sviluppatore del modulo.
auto
Il modulo era in stato auto ed è stato automaticamente caricato quando
qualcosa ha tentato di usarlo.
required
Il modulo era contrassegnato come richiesto (required) dal suo sviluppatore.
depend
Il modulo è in uso, perchè qualche altro modulo della configurazione dipende da
esso.
Moduli diversi possono supportare stati diversi. Quasi tutti i moduli
possono essere in stato statico, ma soltanto pochi supportano gli stati
loaded o auto. Molti moduli possono essere in stato unused, ma non
possono esserlo i moduli required. La riga “Capable” nell’output mostra
quali stati supporti un modulo (suggerimento: per vedere se un modulo è
richiesto (required), guardare per vedere se sulla riga “Capable” compare
unused. In caso affermativo, il modulo non è richiesto).
332
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Spesso i moduli hanno delle dipendenze tra loro. Ad esempio, i driver del
dispositivo di solito non possono essere configurati nella kernel a meno
che siano configurati anche i moduli di supporto del driver. Dipendenze
come questa sono illustrate sulle righe “Depends On” nell’output. Un
modulo può essere dipendente da un altro modulo particolare, specificato
per nome e versione. Un modulo può anche essere dipendente da
un’interfaccia che deve essere fornita da qualche altro modulo, senza dire
specificamente quali moduli forniscano l’interfaccia. I moduli che
forniscono tali interfacce hanno una riga “Exports” nell’output, che elenca
le interfacce che essi esportano.
Modifica degli stati del modulo
Per modificare lo stato di un modulo, mettere le assegnazioni di stato del
modulo sulla riga di comando di kcmodule (consultare anche “Gestione
delle configurazioni con i file di sistema” a pagina 361). Ad esempio, per
caricare il modulo CD File System, denominato cdfs:
# kcmodule cdfs=loaded
In effetti, loaded è il best stato scelto dallo sviluppatore per cdfs,
pertanto è lo stesso di:
# kcmodule cdfs=best
Per scaricarlo:
# kcmodule cdfs=unused
Per i dettagli, consultare la manpage kcmodule (1M).
Quando si modifica lo stato di un modulo usando un comando come negli
esempi precedenti, la modifica sarà effettuata immediatamente sul
sistema in esecuzione, se possibile. A volte, non è possibile realizzare la
modifica immediatamente; ad esempio, potrebbe esservi un CD file
system montato, nel qual caso cdfs non può essere scaricato. In quei casi,
kcmodule terrà la modifica in sospeso e la applicherà al riavvio successivo.
Una modifica che sposta un modulo dentro o fuori dallo stato static non
può mai essere applicata immediatamente e sarà sempre tenuta in
sospeso per il riavvio successivo. Nel caso in cui occorra tenere in sospeso
per il riavvio successivo una qualsiasi modifica sulla riga di comando di
kcmodule, allora lo saranno tutte.
Quando si spostano i moduli dentro o fuori dallo stato static, il comando
kcmodule eseguirà per un po’ di tempo. Ciò si verifica perchè tali modifiche
richiedono che l’eseguibile della kernel sia ricollegato. Nel caso in cui vi
fossero modifiche multiple di tal genere da realizzare, è preferibile
Capitolo 3
333
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
elencarle tutte sulla stessa riga di comando kcmodule, o realizzare le
modifiche in un file di sistema ed importarlo (consultare “Gestione delle
configurazioni con i file di sistema” a pagina 361). Una o l’altra di queste
tecniche garantirà che l’eseguibile della kernel sia ricollegato soltanto una
volta.
A volte, si potrebbe voler forzare una modifica perché sia tenuta in
sospeso per il riavvio successivo, invece di applicarla immediatamente. In
questi casi, è possibile usare l’opzione -h (hold) con kcmodule per forzare
tale comportamento. HP consiglia di usare questa opzione soltanto
quando si prevede che l’avvio successivo avvenga in tempi brevi. Se, ad
esempio, l’avvio successivo non avviene per mesi dopo aver realizzato tale
modifica, l’amministratore di sistema potrebbe avere la sgradita sorpresa
di assistere all’effetto di una modifica in sospeso che era stata
dimenticata.
Le modifiche alle configurazioni della kernel salvate possono essere
realizzate usando l’opzione -c (configuration). Tali modifiche si realizzano
alla configurazione salvata immediatamente, ma non avranno effetto sul
sistema in esecuzione fino a che si carica o si avvia la configurazione
salvata. Per ulteriori informazioni, consultare “Gestione delle
configurazioni salvate con kconfig” a pagina 358.
Quando si modificano gli stati del modulo, kcmodule supporta le opzioni
-B e -K per specificare il comportamento di backup e l’opzione -C per
specificare il commento del file di log. Per i dettagli, consultare “Recupero
dagli errori” a pagina 371 e “Il file di log di configurazione della kernel” a
pagina 369.
Gestione dei moduli della kernel con kcweb
kcweb può essere usato per interrogare e modificare lo stato dei moduli
della kernel nella configurazione attualmente in esecuzione. Usando
kcweb, è possibile
•
•
•
stabilire quali moduli siano attualmente in esecuzione nella kernel
visualizzare i dettagli su un modulo
modificare lo stato di un modulo
È possibile visualizzare la finestra dei moduli scegliendo la voce di menu
dei moduli dalla colonna di navigazione in kcweb.
334
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-7
Moduli kcweb
Ottenimento delle informazioni sui moduli
Per ottenere informazioni più dettagliate su un modulo particolare,
eseguire i seguenti due passi:
Capitolo 3
•
Selezionare la voce di menu dei moduli nella colonna di navigazione.
Comparirà la finestra dei moduli, che elenca tutti i moduli
attualmente configurati sul sistema.
•
Selezionare un modulo per visualizzare i dettagli su un modulo
particolare nella finestra dei dettagli.
335
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Interpretazione delle informazioni sul modulo
Se si sceglie un modulo, sarà visualizzata la schermata dei dettagli del
modulo.
Figura 3-8
Dettagli del modulo kcweb
La finestra dei dettagli del modulo contiene le seguenti informazioni:
Tabella 3-14
Campi dei dettagli del modulo
Nome del campo
Descrizione
modulo
indica il nome del modulo
descrizione
indica una breve descrizione del modulo
versione
indica la versione del modulo
stato
indica lo stato del modulo nella kernel attualmente in esecuzione
(unused, static, loaded, auto)
336
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-14
Campi dei dettagli del modulo (segue)
Nome del campo
Descrizione
causa
indica il motivo per cui il modulo si trova nello stato attuale (explicit,
auto, depend, required, default)
prossimo riavvio
indica lo stato del modulo dopo il riavvio del sistema
causa prossimo
riavvio
indica il motivo per cui il modulo si trova nel suo stato di avvio
successivo
caratteristiche
indica tutti gli stati che il modulo è in grado di supportare
dinamico
indica che si tratta di un modulo della kernel a caricamento dinamico
richiesto
indica se la kernel richiede o meno il modulo
dipendenze
indica i moduli richiesti da questo modulo
esportazioni
elenca tutte le interfacce esportate da questo modulo
Modifica degli stati del modulo
Per modificare lo stato di un modulo, eseguire i seguenti passi:
•
Selezionare la voce di menu dei moduli nella colonna di navigazione.
Comparirà la finestra dei moduli, che elenca tutti i moduli
attualmente configurati sul sistema.
•
Selezionare un modulo che si desidera modificare scegliendo l’icona
o il pulsante Modifica stato dei moduli.
Comparirà la pagina Modifica stato dei moduli.
NOTA
Capitolo 3
Se la causa è dipendente o richiesta, il pulsante Modifica stato dei moduli
non comparirà, dato che kcweb non consente modifiche allo stato di un
modulo richiesto o un modulo da cui dipendono altri moduli.
337
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-9
Modifica stato dei moduli di kcweb
La pagina Modify module state contiene i seguenti campi:
Tabella 3-15
Campi di Modifica stato dei moduli di kcweb
Nome del campo
Descrizione
modulo
nome del modulo che sarà modificato
descrizione
descrizione del modulo
versione
numero di versione del modulo
stato
valore attuale del modulo
causa
motivo per cui il modulo è venuto a trovarsi nel suo stato attuale
prossimo riavvio
stato in cui il modulo sarà modificato se si fa clic sul pulsante
caratteristiche
tutti gli stati che il modulo può supportare
dinamico
indica se il modulo è un modulo della kernel a caricamento dinamico
dipendenze
tutti i moduli dai quali questo modulo dipende
338
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-15
Nome del campo
Campi di Modifica stato dei moduli di kcweb (segue)
Descrizione
modo della
modifica
contiene un set di pulsanti di scelta per applicare le modifiche di
configurazione della kernel immediatamente o per tenere in sospeso
le modifiche di configurazione della kernel fino al riavvio successivo.
Questo campo è visualizzato soltanto per i moduli dinamici. Per
default, si seleziona la modifica al pulsante di scelta successivo. Se
non si seleziona alcun pulsante di scelta, le modifica di configurazione
della kernel saranno tenute in sospeso fino al riavvio successivo.
motivo della
modifica
campo di testo modificabile per inserire commenti per la modifica
nello stato del modulo
esegue il backup
della
configurazione
corrente prima di
applicare le
modifiche
prima di applicare la modifica, eseguire il backup della configurazione
attuale. Per default, questa casella di verifica è selezionata.
Gestione dei parametri settabili della kernel con
kctune
Il comando kctune si usa per interrogare e modificare i valori dei
parametri settabili della kernel (“settaggi”), nella configurazione
attualmente in esecuzione o in una configurazione salvata. I settagli sono
variabili che controllano il comportamento della kernel HP-UX. I settaggi
si usano per una varietà di procedure diverse: alcuni controllano le
allocazioni delle risorse; altri controllano le politiche sulla sicurezza; altri
abilitano il comportamento opzionale della kernel; ecc. In una kernel
tipica, vi sono 150-200 settaggi. Consultare la manpage kctune (1M).
Gli amministratori di sistema possono creare, se lo desiderano, i propri
settaggi “definiti dall’utente”. Questi non avranno ripercussioni dirette
sul funzionamento del sistema, ma è possibile usarli nel calcolo dei valori
di altri settaggi. Ad esempio, un amministratore ha potuto scegliere di
creare un settaggio num_databases e poi impostare vari settaggi della
kernel in base al suo valore. Una modifica successiva del valore di
num_databases provocherebbe la modifica conseguente dei valori di tutti
i settaggi della kernel correlati.
Capitolo 3
339
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Ottenimento delle informazioni sui settaggi
Quando si esegue kctune senza alcuna opzione, esso mostra i settaggi
associati ai moduli della kernel sul sistema (così come gli eventuali
settaggi definiti dall’utente), i loro valori attuali e le espressioni usate per
calcolare quei valori. Se vi sono delle modifiche a quei valori tenuti in
sospeso per il riavvio successivo, saranno mostrate anch’esse. Su un
sistema tipico, l’espressione per la maggior parte dei settaggi è “Default”,
il che significa che l’amministratore consente al sistema di scegliere il
valore del settaggio.
Quando si usa l’opzione -c (configuration), kctune visualizza le
informazioni sul settaggio provenienti da una configurazione salvata
invece che dal sistema in esecuzione attualmente.
L’output di kctune può essere variato con diverse opzioni. Per verificare
quali settaggi siano elencati, usare le opzioni -D (Differences) o -S (Set).
L’opzione -D limita l’output soltanto a quei settaggi il cui valore all’avvio
successivo sia diverso dal loro valore attuale. L’opzione -S limita l’output
soltanto a quei settaggi che sono impostati su un valore non di default.
L’output può anche essere limitato elencando i nomi dei settaggi sulla riga
di comando.
Per verificare il formato dell’output, usare le opzioni -d (description), -g
(group), -v (verbose) o -P (Parse). In assenza di tali opzioni, l’output ha il
seguente aspetto:
Tunable
acctresume
maxuprc
nproc
Current
4
256
4200
Expression
Default
Default
Default
Changes
Immed
Immed
L’opzione -d aggiunge la descrizione di ogni settaggio.
Tunable
Current Expression Changes
Description
acctresume
4 Default
Percentage of disk space that must be free to resume accounting
maxuprc
256 Default
Immed
Maximum number of processes for each non-root user
nproc
4200 Default
Immed
Maximum number of processes on the system
L’opzione -g aggiunge il nome del modulo che definisce il settaggio ed
ordina l’output per nome di modulo. Ciò produce l’effetto di raggruppare i
settaggi correlati nell’output.
340
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Module
acct
pm
pm
Tunable
acctresume
maxuprc
nproc
Value
4
256
4200
Expression
Default
Default
Default
Changes
Immed
Immed
L’opzione -v fornisce informazioni verbose, multiriga su ogni settaggio:
Tunable
acctresume
Description
Percentage of disk space that must be free to resume accounting
Module
pm
Current Value
4 [Default]
Value at Next Boot 4 [Default]
Value at Last Boot 4
Default Value
4
Constraints
acctresume >= -100
acctresume <= 101
acctresume > acctsuspend
Can Change
At Next Boot Only
Tunable
nproc
Description
Maximum number of processes on the system
Module
pm
Current Value
4200 [Default]
Value at Next Boot 4200 [Default]
Value at Last Boot 4200
Default Value
4200
Constraints
nproc >= 100
nproc <= 30000
nproc >= maxuprc + 5
nproc <= nkthread – 100
nproc >= semmnu + 4
Can Change
Immediately or at Next Boot
L’opzione -P, che è destinata ad essere usata da script o programmi, offre
il controllo completo su quali informazioni siano stampate:
# kctune -P name,current acctresume nproc
name
acctresume
current 4
name
nproc
current 4200
Per ulteriori informazioni sull’opzione -P ed il suo uso da parte di script o
programmi, consultare “Analisi sintattica dell’output dei comandi” a
pagina 370 o la manpage kconfig (5).
Capitolo 3
341
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Interpretazione delle informazioni sul settaggio
Guardando all’output di esempio precedente, è possibile vedere come ogni
settaggio abbia una descrizione di nome e di testo. Ogni settaggio è
associato ad un modulo della kernel il cui nome è elencato nell’output
verboso (o nell’output della tabella se si specifica -g). È possibile vedere e
modificare i settaggi soltanto se sono associati ad un modulo installato sul
sistema (o se sono definiti dall’utente). Il modulo non deve essere in uso.
Quando si visualizzano le informazioni sul settaggio per il sistema
attualmente in esecuzione, kctune include il valore del settaggio attuale
e l’espressione usata per calcolarlo. Se vi sono delle modifiche in sospeso al
valore del settaggio per l’avvio successivo, saranno mostrati anche il
valore e l’espressione dell’avvio successivo. Gli elenchi verbosi mostrano
anche il valore che aveva il settaggio al momento dell’ultimo avvio del
sistema. Quando visualizza le informazioni sul settaggio per una
configurazione salvata, kctune visualizza soltanto un valore attuale.
I valori dei settaggi si calcolano in espressioni di interi, che possono fare
riferimento a valori di altri settaggi (non sono consentiti riferimenti
circolari). Il valore di un settaggio potrebbe essere 4200, o 0x400, o
12*1024, o 4*nproc+20. I valori e le espressioni usano la sintassi del
linguaggio di programmazione C. Pertanto, i numeri possono essere scritti
in decimale (256), ottale (01000), o esadecimale (0x100). Le espressioni
possono usare i seguenti operatori e simboli:
( ) ~ ! - + * / % << >> < <= > >= & ^ | == != && || ?:
Lo spazio bianco non è consentito nell’espressione di alcun settaggio.
Per la retrocompatibilità, i nomi dei settaggi usati in espressioni possono
comparire tutti in maiuscole, ma non si incoraggia questo uso, anche
perché il supporto per quest’ultimo sarà eliminato in una release futura.
Tutti i settaggi della kernel hanno un valore di default, che viene scelto
dallo sviluppatore ed è mostrato nell’output verboso. Per alcuni settaggi,
il valore di default è fisso e non cambia mai. Per altri settaggi, il sistema
sceglie un nuovo valore di default al momento dell’avvio. Tuttavia, altri
possono essere impostati automaticamente, il che significa che il valore di
default può cambiare periodicamente mentre il sistema è in esecuzione, in
risposta alle risorse e necessità in mutamento del sistema. Quando si usa
un settaggio sul default, la sua espressione è riportata come Default,
come si vede nell’esempio precedente. In questi casi, il sistema è libero di
scegliere il valore che ritiene ottimale e di modificarlo a seconda della
necessità. HP consiglia di lasciare i settaggi impostati sul default a meno
che si sappia che quest’ultimo non è soddisfacente.
342
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Nota: impostare un settaggio su Default non è la stessa cosa che
impostarlo esplicitamente sul valore di default riportato da kctune.
Usando l’esempio precedente, se si imposta nproc su 4200, il suo valore
resterà 4200 fino a che non lo si cambi. Tuttavia, se si imposta nproc su
Default, il suo valore sarà mantenuto aggiornato con le eventuali
migliorie realizzate da HP al valore di default per nproc.
Alcuni settaggi hanno dei vincoli ai loro valori, che sono mostrati
nell’output verboso. A volte, si tratta di valori minimi e/o massimi, come
illustrato per nproc in precedenza. Altre volte, si tratta di rapporti fissi
tra settaggi (ad esempio, acctresume deve essere maggior di
acctsuspend) o di vincoli ai valori consentiti (ad esempio,
dnlc_hash_locks deve avere una potenza di due). Tali vincoli vengono
imposti ogniqualvolta si modificano i valori dei settaggi. Esistono altri
vincoli, non illustrati da kctune, che si basano sullo stato attuale del
sistema e possono cambiare nel corso del tempo (ad esempio, nproc non
può essere impostato su un valore inferiore al numero di processi
attualmente in esecuzione). Questi vincoli vengono imposti soltanto
quando si modifica il sistema attualmente in esecuzione e non quando si
realizzano delle modifiche tenute in sospeso per l’avvio successivo o
modifiche ad una configurazione salvata.
Alcuni settaggi hanno vincoli su quando sia possibile modificare i loro
valori. Tali vincoli sono annotati nell’output di kctune. I settaggi i cui
valori possono essere modificati immediatamente sono contrassegnati con
Immed. I settaggi i cui valori possono essere impostati automaticamente
dal sistema sono contrassegnati con Auto. I settaggi privi dell’uno o
dell’altro contrassegno possono essere modificati soltanto con un riavvio.
Tutti i settaggi HP-UX hanno manpage. Per ottenere informazioni sul
comportamento, i valori consentiti e gli effetti collaterali di un settaggio,
consultare la manpage per quel settaggio, reperibile nella Sezione 5 del
manuale in linea. Una panoramica di tutti i settaggi della kernel è
reperibile nel documento Tunable Kernel Parameters, disponibile alla
pagina http://docs.hp.com.
Modifica dei valori dei settaggi
Per modificare il valore di un settaggio, mettere le assegnazioni del valore
del settaggio sulla riga di comando di kctune (o consultare “Gestione delle
configurazioni con i file di sistema” a pagina 361). Ad esempio, per
impostare nproc su 4300:
# kctune nproc=4300
Capitolo 3
343
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Per impostare un settaggio su Default, funzionerà l’una o l’altra di
queste assegnazioni (l’impostazione di un settaggio definito dall’utente su
Default ne provoca la rimozione).
# kctune nproc=
# kctune nproc=default
Le assegnazioni possono essere espressioni, come notato in precedenza.
Notare che l’assegnazione potrebbe dover essere virgolettata, onde evitare
l‘interpretazione da parte della shell.
# kctune 'nkthread=nproc*2+100'
Per creare un settaggio definito dall’utente, usare l’opzione -u
(user-defined) quando si assegna un valore al settaggio. L’opzione -u non
è necessaria per modificare il valore di un settaggio definito dall’utente
esistente.
Usando il simbolo +=, è possibile aumentare il valore di un settaggio (di
100, in questo esempio):
# kctune nproc+=100
Usando il simbolo >=, è possibile garantire un valore minimo di un
settaggio. Il comando:
# kctune 'nproc>=5000'
imposterà nproc su 5000 se il suo valore attuale è inferiore a 5000. Se il
suo valore attuale è già 5000 o superiore, resterà invariato. Notare che
l’assegnazione è stata virgolettata per evitare l’interpretazione da parte
della shell.
Per i dettagli, consultare la manpage kctune (1M).
Quando si modifica il valore di un settaggio usando un comando come
negli esempi precedenti, la modifica sarà effettuata immediatamente sul
sistema in esecuzione, se possibile. A volte, non è possibile realizzare la
modifica immediatamente; ad esempio, si potrebbe star tentando di
ridurre il valore massimo di alcune risorse al di sotto dell’uso attuale.
Inoltre, esistono dei settaggi che non è possibile modificare senza un
riavvio. In quei casi, kctune terrà la modifica in sospeso e la applicherà
all’avvio successivo. Nel caso in cui occorra tenere in sospeso per l’avvio
successivo una qualsiasi modifica sulla riga di comando di kctune, allora
lo saranno tutte.
344
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
A volte, si potrebbe voler forzare una modifica perché sia tenuta in
sospeso per il riavvio successivo, invece di applicarla immediatamente. In
questi casi, è possibile usare l’opzione -h (hold) su kctune per forzare tale
comportamento. HP consiglia di usare questa opzione soltanto quando si
prevede che l’avvio successivo avvenga in tempi brevi. Se, ad esempio,
l’avvio successivo non avviene per mesi dopo aver realizzato tale modifica,
l’amministratore di sistema potrebbe avere la sgradita sorpresa di
assistere all’effetto di una modifica in sospeso che era stata dimenticata.
Le modifiche alle configurazione della kernel salvate possono essere
realizzate usando l’opzione -c (configuration). Tali modifiche si realizzano
alla configurazione salvata immediatamente, ma non avranno effetto sul
sistema in esecuzione fino a che si carica o si avvia la configurazione
salvata. Per ulteriori informazioni, consultare “Gestione delle
configurazioni salvate con kconfig” a pagina 358.
Quando si modificano i valori dei settaggi, kctune supporta le opzioni -B
e -K per specificare il comportamento di backup e l’opzione -C per
specificare il commento del file di log. Per i dettagli, consultare “Recupero
dagli errori” a pagina 371 e “Il file di log di configurazione della kernel” a
pagina 369.
Gestione dei parametri settabili della kernel con
kcweb
kcweb può essere usato per interrogare e modificare i valori dei parametri
settabili della kernel (“settaggi”) nella configurazione attualmente in
esecuzione. Usando kcweb, è possibile
•
•
•
•
•
modificare il valore di un settaggio
visualizzare i dettagli su un settaggio
ricercare un settaggio
verificare il valore attuale e dell’avvio successivo per un settaggio
stampare i dettagli su un settaggio o stampare una lista di tutti i
settaggi
È possibile visualizzare la finestra dei settaggi scegliendo la voce di menu
dei settaggi dalla colonna di navigazione in kcweb.
Capitolo 3
345
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-10
Settaggi di kcweb
Ottenimento delle informazioni sui settaggi
Per ottenere informazioni più dettagliate su un settaggio particolare,
eseguire i seguenti due passi:
1. Selezionare la voce di menu dei settaggi nella colonna di navigazione.
Comparirà la finestra dei settaggi, che elenca tutti i settaggi
attualmente configurati sul sistema.
2. Selezionare un settaggio per visualizzare i dettagli su un settaggio
particolare nella finestra dei dettagli.
Interpretazione delle informazioni sul settaggio
Se si sceglie un settaggio, sarà visualizzata la schermata dei dettagli
(Figura 3-11) del settaggio.
346
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-11
Dettagli dei settaggi di kcweb
La finestra dei dettagli dei settaggi contiene le seguenti informazioni:
Tabella 3-16
Dettagli dei settaggi di kcweb
Nome del campo
Descrizione
parametro
sintonizzabile
indica il nome del settaggio
descrizione
indica una breve descrizione del settaggio
modulo
indica il nome del modulo (se ve ne sono) al quale è associato il
settaggio
corrente
indica il valore massimo attuale per la risorsa
Capitolo 3
347
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-16
Nome del campo
Dettagli dei settaggi di kcweb (segue)
Descrizione
prossimo riavvio
(espressione)
indica una formula che descrive il valore dell’avvio successivo (Nota:
può essere anche un numero intero)
prossimo riavvio
(intero)
indica il valore previsto, con tutte le formule calcolate
ultimo valore di
avvio
indica il valore del settaggio al momento dell’ultimo avvio del sistema
default
indica il valore di default per il settaggio
range legale
indica il range dei valori che sono legali per il settaggio
uso attuale
indica la quantità di risorse consumata al momento della
visualizzazione della finestra, sotto forma di valore intero seguito
dall’uso percentuale della risorsa tra parentesi
dinamico
indica che è possibile modificare un settaggio della kernel dinamico
senza riavviare il sistema
stato di sintonia
automatica
indica se il settaggio viene impostato automaticamente
restrizioni
elenca le dipendenze che un settaggio potrebbe avere da altri settaggi
così come i valori consigliati per un settaggio
Modifica dei valori dei settaggi
Per modificare il valore di un settaggio, eseguire i seguenti passi:
1. Selezionare la voce di menu dei settaggi nella colonna di navigazione.
Comparirà la finestra dei settaggi, che elenca tutti i settaggi
attualmente configurati sul sistema.
2. Selezionare un settaggio che si desidera modificare scegliendo l’icona
o il pulsante Modifica nome_settaggio.
Viene visualizzata la pagina “modifica parametro sintonizzabile”
(Figura 3-12):
348
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-12
Modifica parametro sintonizzabile di kcweb
La pagina Modifica parametro sintonizzabile contiene i seguenti campi:
Tabella 3-17
Campi dei dettagli dei settaggi di kcweb
Nome del campo
Descrizione
parametro
sintonizzabile
indica il nome del settaggio che sarà modificato
descrizione
indica una descrizione del settaggio.
modulo
indica il modulo della kernel al quale è associato il settaggio
corrente
indica il valore attuale del settaggio.
prossimo riavvio
(espressione)
formula che descrive il valore dell’avvio successivo (può essere un
numero intero)
Capitolo 3
349
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-17
Campi dei dettagli dei settaggi di kcweb (segue)
Nome del campo
Descrizione
prossimo riavvio
(intero)
indica il valore calcolato del campo di input utente “prossimo
riavvio”; potrebbe dover essere aggiornato facendo clic sul pulsante
‘ricalcola’
ultimo valore di avvio
indica il valore del settaggio al momento dell’ultimo avvio del
sistema
default
si tratta del valore di default del settaggio; premendo il pulsante
‘default’, si copierà il valore di default nel campo ‘planned’
range legale
indica il range dei valori accettabili per il settaggio, i numeri
negativi sono indicati da un segno meno (-), i valori positivi hanno
un segno più implicito (+)
“NA” significa Not Available (Non disponibile) ed indica che il
comando sottostante, kctune, non restituisce nè un valore minimo
né un valore massimo
dinamico
indica se il valore del settaggio può essere modificato senza
riavviare il sistema
stato di sintonia
automatica
indica se il settaggio viene impostato automaticamente
restrizioni
elenca le dipendenze che un settaggio potrebbe avere da altri
settaggi così come i valori consigliati per un settaggio
modalità di modifica
contiene un set di pulsanti di scelta per applicare le modifiche di
configurazione della kernel immediatamente o per tenere in sospeso
le modifiche di configurazione della kernel fino al riavvio successivo.
Questo campo comparirà soltanto per i settaggi dinamici. Per
default, le modifiche di configurazione della kernel saranno tenute
in sospeso fino all’avvio successivo.
esegue il backup
della configurazione
corrente prima di
applicare le
modifiche
implica il backup della configurazione attuale prima di applicare la
modifica. Per default, questa casella di verifica è selezionata.
motivo della modifica
inserire un commento
350
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Monitoraggio dell’uso delle risorse della kernel
Alcuni parametri settabili rappresentano quelle risorse della kernel il cui
uso è possibile monitorare. Per tali settaggi, è possibile impostare allarmi
per ricevere notifica quando l’uso della risorsa della kernel corrispondente
oltrepassa una soglia specificata dall’utente.
Ottenimento delle informazioni sugli allarmi con kcweb
Per ottenere informazioni più dettagliate su un allarme particolare
usando kcweb, eseguire i seguenti due passi:
1. Selezionare la voce di menu degli allarmi nella colonna di
navigazione. Comparirà la finestra degli allarmi, che elenca tutti gli
allarmi attualmente configurati sul sistema.
2. Selezionare un allarme per visualizzare i dettagli su un allarme
particolare nella finestra dei dettagli.
La pagina degli allarmi consente di:
Capitolo 3
•
creare e rimuovere allarmi
•
attivare e disattivare allarmi
•
trovare allarmi che sono stati innescati
•
visualizzare i dettagli sugli allarmi
351
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-13
352
Allarmi di kcweb
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Interpretazione delle informazioni sugli allarmi con kcweb
Se si sceglie un allarme, sarà visualizzata la schermata dei dettagli
dell’allarme.
Figura 3-14
Dettaglio degli allarmi di kcweb
La finestra dei dettagli degli allarmi contiene le seguenti informazioni:
Tabella 3-18
Campi degli allarmi di kcweb
Nome del campo
Descrizione
parametro
sintonizzabile
indica il nome del settaggio
stato
indica lo stato dell’allarme se è attivo o se la risorsa sta attualmente
superando la soglia
soglia
indica la percentuale a cui l’allarme deve attivarsi
Capitolo 3
353
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-18
Campi degli allarmi di kcweb (segue)
Nome del campo
Descrizione
uso attuale
indica la percentuale di risorsa consumata al polling precedente
event type (tipo di
evento)
indica la notifica dell’evento da usare
intervallo di polling
indica l’intervallo di tempo tra i polling
notifica
indica il metodo usato per notificare l’innesco dell’allarme
dati della notifica
indica informazioni supplementari usate dal metodo di notifica (non
presente se non richiesto dal metodo di notifica)
(porta della notifica
indica la porta su cui comunicare la notifica (non presente se non
richiesto dal metodo di notifica)
commento
indica il campo del commento, alcuni dati di commento vengono
aggiunti automaticamente quando gli allarmi sono disattivati
Modifica dei valori degli allarmi con kcweb
Per modificare il valore di un allarme, eseguire i seguenti passi:
1. Selezionare la voce di menu degli allarmi nella colonna di
navigazione. Comparirà la finestra degli allarmi, che elenca tutti gli
allarmi attualmente configurati sul sistema.
2. Selezionare un allarme che si desidera modificare scegliendo l’icona
o il pulsante ‘modifica…’.
Viene visualizzata la pagina ‘modifica allarme’
354
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-15
Modifica allarme di kcweb
La pagina Modifica allarme contiene i seguenti campi:
Tabella 3-19
Nome del
campo
Campi di Modifica allarme di kcweb
Descrizione
parametro
sintonizzabile
indica il nome del settaggio per il quale si modificherà l’allarme
soglia
indica la percentuale a cui l’allarme deve innescarsi
Capitolo 3
355
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-19
Campi di Modifica allarme di kcweb (segue)
Nome del
campo
tipo di evento
Descrizione
visualizza le caselle di verifica che determinano quando occorra inviare le
notifiche:
initial
Primo polling a cui l’uso della risorsa supera la soglia;
quando un allarme viene aggiunto, attivato, disattivato
per la prima volta o il sistema si riavvia.
repeat
Ogni polling a cui l’uso della risorsa supera la soglia (può
portare ad un gran numero di messaggi se l’intervallo di
polling è piccolo).
return
Primo polling a cui l’uso della risorsa scende sotto la
soglia.
Se non si seleziona alcuna delle caselle di verifica, si userà il tipo di evento
di default, così come impostato da kcalarm.
Nota: È possibile selezionare più di una casella di verifica; selezionando sia
initial sia return si genererà una notifica ogniqualvolta l’uso supera o
scende sotto il valore della soglia.
intervallo di
polling
visualizza l’intervallo, espresso in minuti, tra il polling dell’uso della
risorsa
notifica
visualizza il metodo di notifica (console, opcmsg, syslog, textlog, email,
snmp, tcp, udp)
commento
indica il campo del commento
Comandi dell’uso delle risorse
Il comando kcalarm si usa per aggiungere, cancellare o elencare gli
allarmi del settaggio della kernel selezionato, così come per accendere e
spegnere il monitoraggio dei settaggi della kernel.
kcalarm si usa per gestire gli allarmi ed i monitor del settaggio della
kernel selezionato; gli allarmi ed i monitor sono implementati nel daemon
kcmond. Gli utenti possono creare, modificare, cancellare ed elencare gli
allarmi del settaggio della kernel selezionato. Gli allarmi inviano una
notifica attraverso vari target di notifica quando un settaggio della kernel
supera una soglia percentuale specificata della sua impostazione attuale.
356
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Il monitoraggio è il processo di raccolta dei dati dello storico dei settaggi.
Quando questa funzionalità è attivata, vengono raccolti i dati dello storico
sull’uso dei settaggi supportati. Questi dati sono usati dal comando
kcusage per generare tabelle di uso (incluso i consumatori maggiori) per
i settaggi della kernel supportati. Questi dati abilitano anche i grafici di
uso nello strumento kcweb. Il monitoraggio è acceso per default quando lo
strumento kcweb è installato.
Per ulteriori informazioni, consultare le manpage kcalarm (1M), kcmond
(1M) e kcusage (1M).
Gestione della configurazione in esecuzione usando
kconfig
Il comando kconfig ha due opzioni che sono utili per trattare le modifiche
alla configurazione della kernel attualmente in esecuzione tenute in
sospeso per l’avvio successivo. Le modifiche di configurazione sono tenute
in sospeso per l’avvio successivo quando vengono richieste (usando
l’opzione -h (hold) di kcmodule o kctune, o l’opzione -n (next boot) di
kconfig). Le modifiche di configurazione sono tenute in sospeso per
l’avvio successivo anche quando non è possibile applicarle al sistema
attualmente in esecuzione.
Per ottenere una lista delle modifiche tenute in sospeso per l’avvio
successivo, eseguire kconfig -D (Differences). Si tratta in realtà di un
tasto di scelta rapida per eseguire kcmodule -D e kctune -D. Allo stesso
modo, per ottenere una lista di impostazioni di configurazione che sono
impostate sui valori non di default, eseguire kconfig -S (Set). Si tratta in
realtà di un tasto di scelta rapida per eseguire kcmodule -S e kctune -S.1
Se si decide che, dopotutto, non si desidera applicare tali modifiche
all’avvio successivo, eseguire kconfig -H (unHold). Tutte le modifiche
tenute in sospeso per l’avvio successivo non saranno prese in
considerazione.
Per ulteriori informazioni sulle modifiche tenute in sospeso per l’avvio
successivo, consultare “Permanenza delle modifiche” a pagina 328.
1. Le modifiche delle specificazioni del dispositivo non sono incluse in
questi output. Consultare “Gestione delle specificazioni del
dispositivo” a pagina 366.
Capitolo 3
357
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Gestione delle configurazioni salvate con kconfig
Quando si ha una configurazione della kernel HP-UX che soddisfa le
proprie necessità, si potrebbe volerne salvare una copia per proteggersi da
modifiche di configurazione involontarie. Oppure, si potrebbe voler
disporre di configurazioni della kernel multiple, in modo da poter passare
dall’una all’altra con facilità. HP-UX consente di salvare quante
configurazioni della kernel si desideri (tenendo conto dello spazio su disco
disponibile in /stand), e di modificarle ed usarle a piacimento.
Ottenimento delle informazioni sulle configurazioni salvate
Quando si esegue kconfig senza alcuna opzione, esso mostrerà le
configurazioni salvate sul sistema. Vi sarà sempre una configurazione
salvata denominata backup, che viene conservata automaticamente dal
sistema; inoltre, saranno elencate tutte le altre configurazioni salvate sul
sistema (per ulteriori informazioni sulla configurazione di backup,
consultare “Recupero dagli errori” a pagina 371).
L’output di kcconfig può essere variato con diverse opzioni. L’output può
essere limitato a configurazioni specifiche elencandole sulla riga di
comando.
Per verificare il formato dell’output, usare le opzioni -a (all), -v (verbose)
o -P (Parse). In assenza di tali opzioni, l’output ha il seguente aspetto:
Configuration
backup
day
night
Title
Automatic Backup
Configuration for daytime multiuser processing
Configuration for nighttime batch processing
L’opzione -v fornisce informazioni verbose, multiriga su ogni
configurazione salvata:
Configuration
Title
Save Time
Modify Time
backup
Automatic Backup
Sun Jan 12 07:46:40 2003
Sun Jan 12 07:46:40 2003
Configuration
Title
Save Time
Modify Time
day
Configuration for daytime multiuser processing
Sun Jan 12 07:49:00 2003
Sun Jan 12 07:49:00 2003
Configuration night
358
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Title
Save Time
Modify Time
Configuration for nighttime batch processing
Sun Jan 12 07:52:12 2003
Sun Jan 12 07:52:12 2003
L’opzione -a genera lo stesso output dell’opzione -v, tranne che dopo ogni
configurazione salvata, vengono visualizzati gli interi output di
“kcmodule -a -v” e “kctune -v” per quella configurazione. Questo offre
una registrazione di tutte le impostazioni della configurazione (tranne che
le specificazioni del dispositivo).
L’opzione -P, che è destinata ad essere usata da script o programmi, offre
il controllo completo su quali informazioni siano stampate:
# kconfig –P name,title
name
backup
title
Automatic Backup
name
title
day
Configuration for daytime multiuser processing
name
title
night
Configuration for nighttime batch processing
Per ulteriori informazioni sull’opzione -P ed il suo uso da parte di script o
programmi, consultare “Analisi sintattica dell’output dei comandi” a
pagina 370 o la manpage kconfig (5).
Interpretazione delle informazioni sulla configurazione salvate
Facendo riferimento agli esempi precedenti, ogni configurazione salvata
ha un nome. I nomi devono iniziare con una lettera; contenere soltanto
lettere, cifre e trattini di underscore; ed avere una lunghezza massima di
32 caratteri. Tranne che per la configurazione di backup, il nome per ogni
configurazione salvata si sceglie al momento della sua creazione ed è
possibile rinominarla a piacimento.
Ogni configurazione salvata può avere anche un titolo. Il titolo può essere
usato per fornire una descrizione più lunga dello scopo o delle
impostazioni della configurazione. Esso è facoltativo.
Ogni configurazione salvata ha anche un paio di registrazioni orarie. Il
“Save Time” (Ora del salvataggio) indica quando sia stata salvata per
l’ultima volta la configurazione (kconfig –s). Il “Modify Time” (Ora della
modifica) indica quando sia stata modificata per l’ultima volta la
configurazione.
Capitolo 3
359
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Associato ad ogni configurazione salvata, si trova un set completo di
impostazioni di stato, impostazioni dei valori dei settaggi e specificazioni
del dispositivo. È possibile visualizzarli usando
# kcmodule –c configname
e
# kctune –c configname
oppure usando
# kconfig –a configname
(Le specificazioni del dispositivo sono visibili soltanto guardando il file di
sistema per la configurazione salvata, che si trova in
/stand/configname/system.)
Uso e modifica delle configurazioni salvate
Creazione di configurazioni salvate È possibile creare le
configurazioni salvate della kernel in tre modi: salvando la configurazione
attualmente in esecuzione, copiando una configurazione salvata
esistente, o leggendo un file di sistema.
Per salvare la configurazione attualmente in esecuzione, usare
kconfig -s (save). La configurazione salvata risultante includerà le
eventuali modifiche apportate alla configurazione attualmente in
esecuzione tenute in sospeso per l’avvio successivo.
È possibile copiare una configurazione salvata esistente usando
kconfig -c (copy).
Per informazioni su come lavorare con i file di sistema, consultare
“Gestione delle configurazioni con i file di sistema” a pagina 361.
Uso di configurazioni salvate È possibile caricare una configurazione
salvata usando kconfig -l (load). Questa operazione modifica la
configurazione della kernel attualmente in esecuzione in modo che
coincida con quella salvata. Se è possibile modificare la configurazione
senza dover riavviare, le modifiche avranno effetto immediato. In caso
contrario, tutte le modifiche saranno tenute in sospeso per l’avvio
successivo.
360
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
A volte, si potrebbe voler forzare la modifica della configurazione perchè
sia tenuta in sospeso per il riavvio successivo, invece di applicarla
immediatamente. In questi casi, è possibile contrassegnare la
configurazione salvata perchè sia usata all’avvio successivo usando
kconfig -n (next boot). HP consiglia di usare questa opzione soltanto
quando si prevede che l’avvio successivo avvenga in tempi brevi. Se, ad
esempio, l’avvio successivo non avviene per mesi dopo aver realizzato tale
modifica, l’amministratore di sistema potrebbe avere la sgradita sorpresa
di assistere all’effetto di una modifica in sospeso che era stata dimenticata.
Per scoprire quale sia la configurazione salvata contrassegnata perchè sia
usata all’avvio successivo, usare kconfig -w (which). Questo comando
identifica anche la configurazione salvata caricata o avviata più
recentemente, o il file di sistema importato più recentemente.
Modifica di configurazioni salvate Per modificare le impostazioni di
stato del modulo e le impostazioni dei valori dei settaggi in una
configurazione salvata, usare l’opzione -c (configuration) dei comandi
kcmodule e kctune, rispettivamente. È anche possibile modificare le
configurazioni salvate modificando il file di sistema e poi importandolo;
consultare “Gestione delle configurazioni con i file di sistema” a
pagina 361.
Varie opzioni di kconfig consentono altre modifiche alle configurazioni
salvate. L’opzione -r (rename) rinominerà una configurazione salvata
(non è possibile rinominare la configurazione di backup). L’opzione -t
modificherà il titolo su una configurazione salvata. L’opzione -d (delete)
cancellerà una configurazione salvata.
Se una configurazione è stata contrassegnata per essere usata al’avvio
successivo e si decide invece di voler continuare ad usare la
configurazione attualmente in esecuzione, usare kconfig -H (unHold)
perché tutte le modifiche tenute in sospeso per l’avvio successivo non
siano prese in considerazione.
Gestione delle configurazioni con i file di sistema
Ogni configurazione della kernel ha un file di sistema corrispondente. Un
file di sistema è un file di testo semplice che descrive tutte le impostazioni
di configurazione in un formato compatto, leggibile dalla macchina e
portatile. Il formato di un file di sistema è descritto in dettaglio nella
manpage system (4). Si tratta di un avanzamento del formato usato nelle
release precedenti di HP-UX; i formati precedenti sono ancora accettati.
Capitolo 3
361
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Realizzazione delle modifiche di configurazioni con i file di
sistema
I file di sistema forniscono un meccanismo alternativo per la
configurazione della kernel, perchè le modifiche di configurazione possono
essere realizzate modificando un file di sistema e poi ordinando agli
strumenti di configurazione della kernel si applicare le modifiche. Si
tratta del metodo di configurazione della kernel più familiare agli utenti
delle versioni più vecchie di HP-UX.
Per realizzare le modifiche di configurazione usando un file di sistema,
partire con il file di sistema corrispondente alla configurazione che si
desidera modificare.1 Il sistema conserva i file di sistema per ciascuna
configurazione in modo automatico. Il file di sistema per la configurazione
attualmente in esecuzione si trova in /stand/system. Il file di sistema
per tutte le configurazioni salvate si trova in
/stand/configname/system. Se si desidera creare un nuovo file di
sistema per una configurazione, usare il comando kconfig -e (export).
Questo comando assume due forme:
kconfig –e nome_file
esportare la configurazione in esecuzione
kconfig –e nome_config nome_file
NOTA
esportare una configurazione salvata
/stand/system e gli eventuali file di sistema creati esportando la
configurazione in esecuzione, rispecchiano sempre tutte le modifiche
tenute in sospeso per l’avvio successivo.
Una volta che si disponga di un file si sistema, è possibile modificarlo
usando qualsiasi editor di testo, realizzando le modifiche che si desidera.
Dopo averlo modificato, è possibile applicare le modifiche con il comando
kconfig -i (import). Questo comando assume tre forme:
kconfig –i nome_file
importare nella configurazione in esecuzione, ora
kconfig –h –i nome_file
importare e tenere in sospeso per l’avvio successivo
kconfig –i configname nome_file
importare nella configurazione salvata
1. Se il file di sistema proviene da una configurazione diversa da
quella che si sta modificando, o se non è aggiornato rispetto alla
configurazione che si sta modificando, sarà chiesto di confermare le
modifiche.
362
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Nella prima forma, se non è possibile applicare le modifiche al sistema in
esecuzione, esse saranno tenute in sospeso per l’avvio successivo.
Per la retrocompatibilità, il comando mk_kernel è ancora disponibile per
applicare le modifiche realizzate in un file di sistema. Notare, tuttavia,
che il suo nome non è più preciso, dato che, se gli sarà possibile, applicherà
le modifiche di configurazione senza fare una kernel. Questo comando
assume la forma:
mk_kernel [-o destinazione]
[-s nome_file]
nome_file è il nome del file di sistema da leggere; se non specificato, si
usa /stand/system. Per importare una configurazione salvata,
destinazione deve essere il nome della configurazione. Per importare sul
sistema attualmente in esecuzione, con effetto immediato, se possibile,
destinazione deve essere /stand/vmunix (nel caso in cui non sia
possibile applicarle immediatamente, le modifiche saranno tenute in
sospeso fino all’avvio successivo). Se si omette destinazione, le
modifiche saranno realizzate su una configurazione salvata denominata
hpux_test. Non è possibile importare sul sistema attualmente in
esecuzione, forzando le modifiche affinchè siano tenute in sospeso per
l’avvio successivo, usando mk_kernel. A tal fine, usare kconfig -h -i.
È importante notare che il file di sistema in /stand/system e
/stand/nome_config/system sono ricreati automaticamente dopo ogni
modifica di configurazione. In tale processo, i commenti nel file di sistema
vanno perduti. Inoltre, l’ordine delle righe del file va anch’esso perduto.
Pertanto, HP consiglia di non mettere dei commenti nei file di sistema.
Invece, usare l’opzione -C (Comment) quando si importa la
configurazione, per aggiungere i propri commenti direttamente al file di
log di configurazione della kernel (consultare “Il file di log di
configurazione della kernel” a pagina 369).
La maggior parte delle modifiche realizzate nei file di sistema possono
essere effettuate usando i comandi di configurazione della kernel e
viceversa. Ecco gli equivalenti:
Capitolo 3
363
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Comando di configurazione della
kernel
Riga del file di sistema
nome_modulo
kcmodule nome_modulo=best
module nome_modulo best
kcmodule nome_modulo=best
module nome_modulo stato [versione]
a
kcmodule nome_modulo=stato
(nessuna voce per nome_modulo)
kcmodule modulename=unused
nome_settaggio valore_settaggio
kctune
nome_settaggio=valore_settaggio
tunable nome_settaggio
valore_settaggio
kctune
nome_settaggio=valore_settaggio
(nessuna voce per nome_settaggio)
kctune nome_settaggio=default
swap dispositivo_scambio
(nessun equivalente)
dump dispositivo_copiatura
(nessun equivalente)
driver nome_dispositivo nome_driver
(nessun equivalente)
a. I file di sistema creati dagli strumenti di configurazione della kernel elencano
sempre il numero di versione per ogni modulo. Tuttavia, non è richiesto. Gli
amministratori che aggiungono righe di moduli ad un file di sistema non devono per
forza fornire i numeri di versione.
Usi per i file di sistema
I file di sistema si usano principalmente in quattro situazioni. Primo, sono
utili per gli amministratori di sistema che abbiano dimestichezza con loro
dalle release precedenti di HP-UX. Se si ha l’abitudine di modificare
/stand/system ed eseguire mk_kernel per realizzare le modifiche di
configurazione, funzionerà ancora.
Secondo, i file di sistema sono l’unico meccanismo attraverso il quale sia
possibile vedere o modificare le specificazioni del dispositivo. Per ulteriori
dettagli, consultare “Gestione delle specificazioni del dispositivo” a
pagina 366.
364
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Terzo, i file di sistema sono utili se si desidera applicare modifiche di
configurazione multiple contemporaneamente. È possibile modificare un
/stand/system e modificare i valori di tre settaggi e gli stati di due
moduli e fare in modo che tutte queste modifiche abbiano effetto insieme
al momento dell’importazione del file di sistema con kconfig -i o
mk_kernel. Per contrasto, ogni richiamo di uno dei comandi di
configurazione della kernel applica le modifiche separatamente (sebbene
modifiche multiple elencate sulla riga di comando della stessa
configurazione siano applicate insieme).
Applicare modifiche multiple insieme acquista particolare valore quando
si spostano i moduli dentro o fuori dallo stato static, perché ogni
comando che compie ciò eseguirà per un certo tempo. Ciò si verifica perchè
tali modifiche richiedono che l’eseguibile della kernel sia ricollegato. Nel
caso in cui vi fossero modifiche multiple di tal genere da realizzare, è
preferibile elencarle tutte sulla stessa riga di comando kcmodule, o
realizzare le modifiche in un file di sistema ed importarlo Una o l’altra di
queste tecniche garantirà che l’eseguibile della kernel sia ricollegato
soltanto una volta.
L’altro uso primario per i file di sistema è la copia di configurazioni da un
sistema ad un altro. Non è sicuro copiare una directory di configurazione
della kernel da una macchina all’altra ed HP non supporta tale
operazione. Tuttavia, è del tutto sicuro esportare un file di sistema da una
configurazione ad un sistema, spostare tale sistema su un sistema diverso
ed importarlo lì. Esiste un modo idoneo ed efficace per garantire che due
macchine eseguano configurazioni compatibili (compatibile significa che
hanno lo stesso set di moduli della kernel, ma potrebbero avere versioni
diverse di tali moduli a causa delle installazioni dei patch).
In alcuni casi, eseguire configurazioni compatibili non è sufficiente;
occorre essere sicuri che due macchine eseguano esattamente la stessa
configurazione. In tal caso, usare l’opzione -V (Version match) mentre si
importa il file di sistema sul sistema di destinazione. Questa opzione
attiva la verifica rigorosa della versione e l’importazione non andrà a
buon fine se le due macchine hanno versioni diverse dei moduli della
kernel installati.
Capitolo 3
365
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Gestione delle specificazioni del dispositivo
Le specificazioni del dispositivo sono di rado usate come impostazioni di
configurazione che è possibile configurare soltanto usando i file di sistema
(consultare “Gestione delle configurazioni con i file di sistema” a
pagina 361). Le specificazioni del dispositivo sono notazioni sulle
modalità di uso o di controllo di dispositivi hardware particolari. Esistono
tre tipi di specificazioni del dispositivo di base supportati da HP-UX:
specificazioni del dispositivo di scambio primario, specificazioni del
dispositivo di copiatura e specificazioni del driver del dispositivo. La
maggior parte delle configurazioni della kernel non ha alcuna
specificazione del dispositivo.
Dispositivo di scambio primario
Ogni configurazione della kernel ha la possibilità di avere una
specificazione del dispositivo di scambio primario. In mancanza di ciò,
questa specifica quale volume del disco il sistema debba usare per la
paginazione. Al momento, si specifica soltanto il dispositivo di scambio
primario usando i meccanismi di configurazione della kernel; altri
dispositivi di scambio, se li si desidera, si configurano dopo l’avvio usando
il comando swapon o la chiamata di sistema, o attraverso le voci in
/etc/fstab (per i dettagli, consultare swapon (1M), swapon (2) e fstab
(4)).
Il dispositivo di scambio primario viene specificato in un file di sistema
sotto forma di riga con una delle seguenti forme:
swap
swap
swap
swap
ID_dispositivo1
lvol
none
default
È consentita soltanto una riga del genere. Nel caso in cui non si specifichi
alcuna riga del genere, si sottintende che sia swap default.
1. Le versioni precedenti di HP-UX consentivano la specificazione di
un offset di partenza e le dimensioni dell’area di paginazione sul
dispositivo specificato. Queste specificazioni sono ancora accettate,
per la retrocompatibilità; per i dettagli, consultare system (4).
Le nuove installazioni non devono usare queste funzionalità
obsolescenti.
366
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
La prima forma identifica in modo esplicito il dispositivo del disco da
usare per la paginazione. Il dispositivo del disco non deve contenere un
file system e non deve essere un volume fisico LVM o VxVM. I dischi
vengono attualmente identificati usando percorsi hardware (per i
dettagli, consultare ioscan (1M)), ma questa cosa potrebbe cambiare nelle
release future di HP-UX.
La seconda forma (swap lvol) specifica che il dispositivo di scambio
primario è uno dei volumi logici nel gruppo di volumi LVM di root e che è
stato usato il comando lvlnboot per identificare il volume logico.
Consultare lvlnboot (1M).
La terza forma (swap none) specifica che non deve esservi alcun
dispositivo di scambio primario. Il sistema non sarà in grado di realizzare
le attività di paginazione.
La quarta forma (swap default) specifica il comportamento di default. È
equivalente a lvol se il sistema si avvia da un gruppo di volumi LVM.
Altrimenti, la paginazione viene diretta al disco contenente il file system
di root, nell’area tra la fine del file system e la fine del disco.
Dispositivi di copiatura
Ad ogni configurazione della kernel è consentito disporre di un numero
qualsiasi di dispositivi di copiatura. Si tratta di dispositivi sui quali
occorre scrivere una copia del crash di sistema, nel caso in cui se ne
verifichi uno. I dispositivi di copiatura specificati nella configurazione
della kernel di solito si usano soltanto durante il processo di avvio; una
volta portato a termine il processo di avvio, il sistema usa invece i
dispositivi di copiatura specificati in /etc/fstab. Per ulteriori dettagli,
consultare crashconf (1M).
I dispositivi di copiatura sono specificati in un file di sistema sotto forma
di righe con le seguenti forme:
dump
dump
dump
dump
ID_dispositivo
lvol
none
default
È possibile specificare un numero qualsiasi di righe di questo tipo. Nel
caso in cui non si specifichi alcuna riga del genere, si sottintende che sia
dump default.
Capitolo 3
367
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
La prima forma identifica in modo esplicito il dispositivo del disco da
usare per le copiature del crash. Il dispositivo del disco potrebbe non
contenere un file system e non deve essere un volume fisico LVM o VxVM.
I dischi vengono attualmente identificati usando percorsi hardware (per i
dettagli, consultare ioscan (1M)), ma questa cosa potrebbe cambiare nelle
release future di HP-UX.
La seconda forma (dump lvol) specifica che i dispositivi di copiatura del
crash sono volumi logici nel gruppo di volumi LVM di root e che è stato
usato il comando lvlnboot per identificare il/i volumi logici. Consultare
lvlnboot (1M).
La terza forma (dump none) specifica che non deve esservi alcun
dispositivo di copiatura del crash. Il sistema non sarà in grado di salvare
le informazioni sulla copiatura del crash nel caso in cui si verifichi un
crash del sistema.
La quarta forma (dump default) specifica il comportamento di default. Le
copiature sul crash saranno scritte sul dispositivo di scambio primario.
Usare lo stesso dispositivo per lo scambio primario e per le copiature del
crash è pratica comune ed accettata.
Specifiche del driver del dispositivo
Per la maggior parte del tempo, il sistema può scegliere in modo corretto
il modulo del driver del dispositivo che deve controllare ogni dispositivo
hardware del sistema. In alcune circostanze, potrebbe essere necessario
dover forzare un particolare dispositivo hardware perchè sia controllato
da un modulo del driver del dispositivo particolare. In tal caso, è possibile
specificare un allegato esplicito del dispositivo al driver in questione. Alla
maggior parte delle installazioni non occorre affatto specificare le
specifiche del driver del dispositivo esplicito.
Le specificazioni del driver del dispositivo esplicito sono specificate in un
file di sistema sotto forma di righe con le seguenti forme:
driver ID_dispositivo nome_driver
L’ID_dispositivo è l’identificativo del dispositivo hardware in questione.
I dispositivi vengono attualmente identificati usando percorsi hardware
(per i dettagli, consultare ioscan (1M)), ma questa cosa potrebbe cambiare
nelle release future di HP-UX. Il nome_driver è il nome del modulo della
kernel che si trova nel driver desiderato per il dispositivo.
368
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Il file di log di configurazione della kernel
Spesso, è utile sapere quali modifiche della configurazione siano state
realizzate su un sistema. A tal fine, gli strumenti di configurazione della
kernel conservano automaticamente un file di log in /var/adm/kc.log.
Questo file elenca ogni modifica realizzata usando I comandi di
configurazione della kernel (alcune modifiche di configurazione possono
essere realizzate chiamando direttamente le chiamate di sistema della
kernel. Tali modifiche non sono registrate. Le modifiche realizzare
attraverso kcweb, l’interfaccia su base web per la configurazione della
kernel, sono registrate dato che kcweb usa i comandi di configurazione
della kernel per realizzare le modifiche).
Il file di log è un file di testo semplice che è possibile visualizzare
direttamente. Il comando kclog viene fornito per quando si desidera
compiere una ricerca intelligente del file di log, ma il suo uso è facoltativo
(è possibile reperire ulteriori informazioni sul comando kclog nella
manpage kclog (1M)).
Tutti i comandi di configurazione della kernel accettano un’opzione -C
(Comment) quando si usano per realizzare modifiche di configurazione.
L’opzione -C consente di specificare un commento che sarà incluso nella
voce di log per la modifica. Questo può aiutare i lettori del log a
comprendere i motivi delle modifiche.
Per aggiungere un commento al log senza realizzare una modifica della
configurazione, usare kclog -C.
Nello strumento kcweb, è possibile selezionare la voce di menu del
visualizzatore del log delle modifiche da una colonna di navigazione per
vedere il file di log della configurazione della kernel (nell’ordine inverso).
Capitolo 3
369
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Figura 3-16
Visualizzatore del log delle modifiche di kcweb
Analisi sintattica dell’output dei comandi
Le migliorie ad HP-UX spesso richiedono modifiche nei formati di output
dei comandi come quelli descritti qui. Ciò può risultare problematico
quando sono stati scritti applicazioni o script che analizzano
sintatticamente gli output di quei comandi. Per tale motivo, ognuno dei
comandi di configurazione della kernel primari (kcmodule, kctune e
kconfig) ha un formato di output speciale, selezionato con l’opzione -P
(Parse), ideata per analizzare sintatticamente le applicazioni. Oltre a
fornire compatibilità da release a release, è anche più facile da analizzare
sintatticamente rispetto all’output leggibile dall’uomo.
ATTENZIONE
HP si riserva il diritto di modificare gli altri formati di output di questi
comandi in qualsiasi momento. HP non supporterà applicazioni e script
che analizzano sintatticamente l’output di questi comandi a meno che essi
usino l’opzione -P.
L’opzione -P di ognuno di questi comandi prende una lista di nomi di
campo, identificando i campi che l’applicazione desidera far comparire
nell’output. I nomi dei campi disponibili sono diversi per ciascun comando
e sono documentati nelle manpage relative a questi ultimi. La lista è
separata da virgole e non può contenere spazi. Gli esempi sono illustrati
nella sezione precedente.
370
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Il formato dell’output è composto da una riga per campo, contenente il
nome del campo, un carattere di un’unica tabulazione (ASCII 9), il valore
del campo e una nuova riga (ASCII 12). I campi sono stampati nell’ordine
richiesto per ogni voce, con righe vuote tra le voci.
Alcuni campi hanno valori multipli. In questi casi, vi sarà una riga per
ogni valore del campo, ognuna che inizia con il nome del campo nel modo
descritto.
In alcuni casi, alcuni campi non hanno valori. Ad esempio, il campo del
settaggio “value at last boot” non ha significato per i settaggi di una
configurazione salvata. In questi casi, per quel campo non sarà stampata
alcuna riga.
Il nome di campo speciale ALL può essere usato per recuperare tutti i dati
disponibili. Quando si usa questo nome di campo, l’output potrebbe
includere campi che non sono elencati nella manpage. L’ordine dei campi
nell’output è indefinito.
Recupero dagli errori
A volte, si realizzano modifiche di configurazione della kernel non gradite.
Inoltre, i guasti hardware e le modifiche possono rovinare una
configurazione della kernel che prima era accettabile. HP-UX ha vari
meccanismi disponibili per gli amministratori di sistema cui occorra
recuperare errori di tal genere. Essi includono il file di log di
configurazione della kernel (descritto in precedenza); le configurazioni
salvate, incluso la configurazione di backup conservata automaticamente
ed il modo di avvio esente da guasti.
La configurazione di backup automatica
Il sistema conserva automaticamente una configurazione salvata
denominata di backup. In genere, ogni volta che si usano gli strumenti di
configurazione della kernel per realizzare una modifica alla
configurazione attualmente in esecuzione, la configurazione precedente
(prima della modifica) viene salvata sul backup. Pertanto, la
configurazione di backup è qualcosa di simile al comando “annulla” in un
elaboratore di testo. In questi casi, se si carica la configurazione di backup
usando kconfig -l backup, esso invertirà l’ultima modifica realizzata
alla configurazione attualmente in esecuzione usando i comandi di
configurazione della kernel.
Capitolo 3
371
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Alcune modifiche possono essere realizzate alla configurazione
attualmente in esecuzione chiamando direttamente le chiamate di
sistema della kernel. La configurazione di backup non viene aggiornata
quando si realizzano quelle modifiche.
Esistono casi in cui si potrebbe non desiderare questo comportamento di
backup automatico. Ad esempio, se sono state realizzare modifiche non
desiderate e si sta tentando di eliminare il problema, non si desidera che
i comandi di configurazione della kernel sostituiscano una configurazione
di backup buona con una contenente le modifiche non desiderate.
L’opzione -K (Keep the existing backup) può essere attribuita a qualsiasi
comando di configurazione della kernel per disabilitare l’aggiornamento
automatico della configurazione di backup. Quando si realizzano
modifiche usando kcweb, è possibile disattivare la casella di verifica
“esegue il backup della configurazione corrente prima di applicare le
modifiche” per disabilitare il comportamento di backup automatico.
Quando il sistema si avvia per la prima volta, la configurazione di backup
rispecchia quella in uso prima del riavvio. Si potrebbe non desiderare che
questa sia sostituita dalla prima modifica di configurazione della kernel
che si realizza, specialmente dato che la prima modifica di configurazione
della kernel potrebbe essere realizzata da uno script di avvio ancor prima
di ricevere un prompt di login.
Per tale motivo, le prime modifiche di configurazione dopo un avvio sono
gestite in modo speciale. Invece della sostituzione automatica della
configurazione di backup, i comandi di configurazione della kernel
chiederanno se farlo o meno.1 Essi continueranno a porre tale domanda,
ogni volta che si realizza una modifica, fino alla prima volta in cui si
risponde “sì”. Da quel punto in poi, fino all’avvio successivo, essi
sostituiranno automaticamente la configurazione di backup con ogni
modifica come descritto in precedenza.
Se si desidera disabilitare la sostituzione automatica della configurazione
di backup per una modifica particolare, specificare -K. Se si desidera
forzare una sostituzione automatica della configurazione di backup,
specificare -B (Backup). Queste opzioni funzionano con qualsiasi comando
di configurazione della kernel che realizzi modifiche di configurazione.
1. Se il comando viene eseguito in modo non interattivo, come da uno
script di avvio, si sottintende che la risposta sia “No” per kcmodule,
kctune e kcdevice e “Sì” per kconfig.
372
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Avvio di una configurazione salvata
In casi estremi, una modifica di configurazione errata può provocare il
mancato avvio di una configurazione della kernel. In tali casi, si dispone
di due opzioni: avviare una configurazione diversa, come la configurazione
di backup automatica e/o avviare in modo esente da guasti (descritto più
avanti).
Per avviare una configurazione salvata su un sistema su base Itanium,
interrompere il processo di avvio automatico quando raggiunge il punto in
cui ha avviato il caricatore di avvio HP-UX (sulla maggior parte dei
sistemi, ciò avviene durante il secondo conto alla rovescia di 10 secondi).
Al prompt di HPUX>, digitare
HPUX> boot configname
Per avviare una configurazione salvata su un sistema PA-RISC, interrompere il processo di avvio automatico quando si arriva al gestore della console di avvio. Ordinargli di avviare dal dispositivo desiderato (di solito, con
un comando boot pri). Quando il gestore chiede se si desidera interagire
con l’ISL o l’IPL, rispondere Sì (il meccanismo esatto per arrivare a questo
punto varia; per i dettagli, consultare il manuale dell’hardware del
sistema o la manpage hpux (1M)). Al prompt di ISL>, digitare
ISL> hpux configname/vmunix
Nell’uno come nell’altro caso, ciò avvierà la configurazione salvata
denominata configname. Una volta portato a termine l’avvio, sarà la
configurazione attualmente in esecuzione; la configurazione precedente è
perduta (a meno che non sia stata salvata automaticamente come
backup).
Avvio in modo esente da guasti
L’altra alternativa per recuperare da una configurazione non avviabile è di
avviare in modo esente da guasti. Quando si avvia il sistema in modo
esente da guasti, le impostazioni della propria configurazione vengono
ignorate. A tutti i settaggi della kernel sono assegnati valori esenti da guasti, si usano le specificazioni del dispositivo di default e non si carica alcun
modulo della kernel in modo dinamico durante l’avvio. Questo metodo è
particolarmente utile quando una modifica o un guasto hardware hanno
provocato l’impossibilità di avviare l’intera configurazione salvata.
Per avviare un sistema su base Itanium in modo esente da guasti, andare
al prompt HPUX> come descritto in precedenza e digitare
HPUX> boot –tm
Capitolo 3
373
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Per avviare un sistema PA-RISC in modo esente da guasti, andare al
prompt ISL> come descritto in precedenza e digitare
ISL> hpux –f0x40000
(I due metodi possono essere combinati, se si desidera avviare una
configurazione salvata in modo esente da guasti. Questa usa l’eseguibile
della kernel costruito per la configurazione salvata, incluso tutti i suoi
moduli statici, ma nessuno dei suoi moduli a caricamento dinamico).
Quando si avvia il sistema in modo esente da guasti, la configurazione
della kernel precedente sarà salvata automaticamente, con un nome di
configurazione simile a saved_3DE78FA0. Il nome esatto sarà stampato
nei messaggi di avvio sulla console.
Quando si avvia il sistema in modo esente da guasti, l’avvio si arresterà
quando si raggiunge il modo utente unico. A questo punto, occorre
intraprendere tutti i passi necessari alla riparazione del sistema o della
configurazione e poi riavviare su una configurazione valida. HP non
consiglia di continuare ad avviare in modo multiutente dopo un avvio
esente da guasti.
Linee guida per il recupero dagli errori
Se si ha una configurazione della kernel indesiderata o non avviabile,
HP consiglia il seguente approccio per risolvere il problema.
✓
Se il sistema è spento:
❏
Se si sa quale modifica di configurazione abbia provocato il
problema:
— Se la configurazione di backup non è stata aggiornata
dall’ultima modifica errata:
•
Caricare la configurazione di backup con kconfig –l
backup.
— Altrimenti (la configurazione di backup presenta anch’essa il
problema al suo interno):
•
374
Tentare di invertire la modifica usando kcmodule o
kctune.
Specificare sempre l’opzione –K per conservare la
configurazione di backup.
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
❏
Altrimenti (non si sa quale modifica abbia provocato il problema,
o quanto descritto in precedenza non ha sortito effetto):
•
✓
Caricare una configurazione della cui correttezza si è certi
usando kconfig –l.
Tentare prima la configurazione di backup.
Altrimenti (il sistema è spento):
❏
Se si è verificato un guasto hardware ed ora il sistema non si avvia
o se occorre conservare la configurazione errata:
•
•
❏
Tentare di avviare in modo esente da guasti (consultare
sopra).
Riparare la configurazione o l’hardware, poi riavviare.
Altrimenti (nessun guasto hardware, nessuna necessità di
conservare la configurazione errata):
•
Tentare di avviare una configurazione della cui correttezza si
è certi,come backup.
Naturalmente, a seconda del livello del proprio contratto di supporto con
HP, è possibile contattare il personale dell’assistenza tecnica HP per
realizzare queste procedure, se necessario.
Se si arriva ad un punto in cui non si riesce ad avviare alcuna delle
configurazioni salvate, anche in modo esente da guasti, come ultima ratio
è possibile avviare dal supporto di installazione di HP-UX. Se tale
operazione riesce, non occorre necessariamente reinstallare HP-UX; è
possibile aprire una shell e tentare di riparare il sistema.
Esempio di configurazione della kernel
In questo esempio, l’amministratore di sistema, Susan, sta configurando
un nuovo sistema HP-UX per eseguire un database server denominato
“Prophet”. Ha appena terminato di avviare dopo l’installazione iniziale.
demo [HP Release B.11.23]
Console Login: root
Password:
Please wait...checking for disk quotas
...
WARNING: YOU ARE SUPERUSER !!
Capitolo 3
375
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
La prima cosa che Susan fa è di salvare una copia della configurazione
della kernel iniziale, nel caso in cui le occorresse in seguito. Mette dei
commenti su tutte le sue modifiche (con -C). Mette anche un titolo sulla
configurazione salvata (con -t) per ricordarsi del suo contenuto.
# kconfig -C "Salvare config installazione iniziale" \
-s installed
* The current configuration has been saved to 'installed'.
# kconfig -t installed "Installazione iniziale"
* The title of the configuration 'installed' has been set to
"Installazione iniziale".
Il manuale per “Prophet” dice a Susan di impostare il settaggio maxdsiz
su almeno 0,5 TB, di impostare il settaggio semmni su 3000 e di
aggiungere 50 a qualsiasi valore stia usando per shmmni. Come
amministratore di sistema preoccupato della sicurezza, sa che desidera
anche attivare l’Intrusion Detection System (Sistema antiintrusione)
impostando il settaggio enable_idds. Susan inizia guardando i valori
attuali di questi settaggi e le descrizioni di quelli con i quali non ha
dimestichezza.
# kctune enable_idds maxdsiz
Tunable
Value Expression
enable_idds
0 Default
maxdsiz
0x40000000 Default
Changes
Immed
# kctune -d semmni shmmni
Tunable Value Expression Changes
Description
semmni
2048 Default
Maximum number of semaphore sets on the system
shmmni
400 Default
Immed
Maximum number of shared memory segments on the system
Dopo aver fatto ciò, imposta i valori secondo le istruzioni. Li imposta tutti
sulla stessa riga di comando, in modo che abbiano effetto tutti
contemporaneamente. Dato che non è possibile realizzare due delle
modifiche immediatamente, tutte le modifiche restano in sospeso per
l’avvio successivo.
# kctune -C "Tunable settings for Prophet" "enable_idds=1" \
>
"maxdsiz>=512000000" "semmni=3000" "shmmni+=50"
WARNING: The requested changes cannot be made to the running system.
They will be held until next boot.
* The automatic 'backup' configuration has been updated.
NOTE:
No change to 'maxdsiz' was needed.
* The requested changes have been saved, and will take effect at
next boot.
376
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tunable
enable_idds
maxdsiz
semmni
shmmni
(now)
(next boot)
(now)
(next boot)
(now)
(next boot)
Value
0
1
0x40000000
2048
3000
400
450
Expression
Default
1
Default
Default
3000
400
450
Changes
Immed
Immed
Per usare l’Intrusion Detection System, Susan sa di dovere avere il
modulo idds nella sua configurazione della kernel. Controlla e vede che
esso è attualmente unused, pertanto lo aggiunge alla sua configurazione.
# kcmodule -d idds
Module State
Cause
Description
idds
unused
Intrusion Detection Data Source
# kcmodule -C "Add Intrusion Detection to the kernel." idds=best
WARNING: The requested changes cannot be made to the running system.
They will be held until next boot.
* The automatic 'backup' configuration has been updated.
* Building a new kernel for configuration 'nextboot'...
* Adding version information to new kernel...
* The requested changes have been saved, and will take effect at
next boot.
Module State
Cause
idds
static best
idds deve essere costruito nell’eseguibile della kernel stesso, pertanto si
costruisce una nuova kernel e viene contrassegnata per l’uso all’avvio
successivo.
Susan verifica un riepilogo di tutte le sue modifiche che avranno effetto al
riavvio.
# kconfig -D
Module
State
idds
(now)
unused
(next boot) static
Tunable
enable_idds
(now)
(next boot)
semmni
(now)
(next boot)
shmmni
(now)
(next boot)
Cause
best
Value
0
1
2048
3000
400
450
Expression
Default
1
Default
3000
Default
450
Changes
Immed
Soddisfatta, riavvia. Il sistema conferma che le sue modifiche saranno
applicate.
Capitolo 3
377
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
# shutdown -r
...
* The kernel registry database has been saved to disk.
* The configuration changes that were being held for next boot
have been applied.
...
The system is ready.
demo [HP Release B.11.23]
Console Login: root
Password:
Please wait...checking for disk quotas
...
WARNING: YOU ARE SUPERUSER !!
Dopo il riavvio, Susan salva la nuova configurazione della kernel con il
nome good, in modo che, se sarà necessario, potrà ritornarvi. Gli
attribuisce un titolo in modo da facilitarne il riconoscimento in seguito.
# kconfig -C "Good configuration for Prophet" -s good
* The current configuration has been saved to 'good'.
# kconfig -t good "Good configuration for Prophet"
* The title of the configuration 'good' has been set to "Good
configuration for Prophet".
Dopo un certo periodo di tempo, uno dei suoi utenti le chiede di aumentare
le dimensioni della cache del buffer, sperando di velocizzare
l’applicazione. Lei acconsente; dopotutto, non occorre riavviare, pertanto
può farlo senza disturbare nessuno. Dato che si tratta della prima
modifica dopo un avvio, il sistema chiede se realizzare dei backup
automatici.
# kctune -C "Bigger buffer cache for better performance" dbc_max_pct=20
WARNING: The automatic 'backup' configuration currently contains the
configuration that was in use before the last reboot of this
system.
==> Do you wish to update it to contain the current configuration
before making the requested change? yes
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running system.
Tunable
Value Expression Changes
dbc_max_pct (before)
10 Default
Immed
(now)
20 20
Dato che si tratta di una cosa positiva, risponde “sì”. La cache del buffer
più grande in effetti rallentava le cose, ma tutto ciò che lei deve fare è
ripristinare il backup automatico.
378
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
# kconfig -C "Putting buffer cache back; performance was worse." -l backup
* The configuration 'backup' has been loaded.
# kctune dbc_max_pct
Tunable
Value Expression
dbc_max_pct
10 Default
Changes
Immed
Mentre Susan è in vacanza, il suo collega, Fred, decide di usare la
macchina per il software di fatturazione durante la notte. Questo software
deve eseguire un codice sullo stack (un rischio per la sicurezza), pertanto
egli abilita tale comportamento (che è vietato per default). Per fare ciò,
non occorre alcun riavvio.
# kctune -d executable_stack
Tunable
Value Expression Changes
Description
executable_stack
0 Default
Immed
Enables execution of code on a stack (0 = no, 1 = yes, 2 = yes but warn)
# kctune -C "Nightly billing s/w needs execute-on-stack" executable_stack=1
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running system.
Tunable
Value Expression Changes
executable_stack (before)
0 Default
Immed
(now)
1 1
Il software di fatturazione usa anche il modulo Generatore di numeri
casuale della kernel. Fred verifica e vede che non è attualmente utilizzato,
ma dato che è caricabile non occorre un riavvio per poterlo usare.
# kcmodule -d rng
Module State
Cause Notes
Description
rng
unused
loadable, unloadable
Strong Random Number Generator
Egli prosegue e carica il modulo.
# kcmodule -C "Random Number Generator needed for nightly billing jobs" rng=best
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running system.
Module
State
Cause Notes
rng
(before) unused
loadable, unloadable
(now)
loaded
best
Fred salva queste nuove impostazioni della configurazione con il nome
night (con un titolo descrittivo).
Capitolo 3
379
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
# kconfig -C "Settings for nightly billing jobs" -s night
* The current configuration has been saved to 'night'.
# kconfig -t night "Nightly billing jobs"
* The title of the configuration 'night' has been set to "Nightly
billing jobs".
Dato che good non è più un nome molto utile per la configurazione di
Susan, Fred la rinomina come day. Egli verifica la lista delle
configurazioni per assicurarsi che tutto sia regolare.
# kconfig -r good day
* The configuration 'good' has been renamed to 'day'.
# kconfig
Configuration
backup
day
installed
night
Title
Automatic Backup
Good configuration for Prophet
Initial installation
Nightly billing jobs
Infine, tenta di caricare prima la configurazione day e poi la
configurazione night, per assicurarsi di potersi spostare avanti e indietro
a piacimento.
# kconfig -l day
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running system.
# kconfig -l night
* The automatic 'backup' configuration has been updated.
* The requested changes have been applied to the currently
running system.
Quando Susan torna dalla sua vacanza, la prima cosa che fa è controllare
il file di log conservato automaticamente per vedere ciò che Fred ha fatto.
# kclog 5
======================================================================
Change to configuration 'current'
at 21:49:08 PST on 02 February 2003 by root:
Module 'rng' set to loaded state.
Random Number Generator needed for nightly billing jobs
======================================================================
Change to configuration 'current'
at 21:53:03 PST on 02 February 2003 by root:
Configuration saved from currently running configuration.
380
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Settings for nightly billing jobs
======================================================================
Change to configuration 'day'
at 21:53:26 PST on 02 February 2003 by root:
Configuration created by renaming 'good'.
======================================================================
Change to configuration 'current'
at 21:55:49 PST on 02 February 2003 by root:
Configuration loaded from 'day'.
======================================================================
Change to configuration 'current'
at 21:56:09 PST on 02 February 2003 by root:
Configuration loaded from 'night'.
Vede che Fred ha messo una nuova applicazione sul suo server e, cosa
ancor peggiore, uno di quelli non sicuri. Almeno, ha testato e documentato
le sue modifiche.
Susan non vuole lasciare il suo sistema nel modo in cui è stato modificato
da Fred, pertanto sposta il lavoro di fatturazione notturna su un altro
sistema. Innanzitutto, esporta la sua configurazione night in un file di
testo.
# kconfig -e night /tmp/system.night
* The configuration 'night' has been exported to /tmp/system.night.
Spostando il file su un’altra macchina, importa la configurazione lì,
usando l’opzione -V per assicurarsi che sia in uso esattamente lo stesso
software della kernel. Poi, carica la configurazione. Qualcosa sulla
configurazione non può essere modificato immediatamente, forse
l’impostazione di un settaggio, pertanto deve riavviare la macchina. Come
predisposto, la macchina usa la configurazione night di Fred quando si
esegue il backup.
# kconfig -C "Move nightly billing jobs" -iV night /tmp/system.night
* /tmp/system.night has been imported to 'night'.
# kconfig -l night
* The automatic 'backup' configuration has been updated.
NOTE:
The configuration being loaded contains changes that cannot be
applied immediately. The changes will be held for next boot.
# shutdown -r
...
* The kernel registry database has been saved to disk.
* The configuration 'night' will be used at next boot, as
requested.
Capitolo 3
381
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabelle di riferimento rapido di configurazione della
kernel
Tabella 3-20
Lavoro con le configurazioni della kernel
Procedura
Comando
Scegliere la configurazione da avviare...
...prima del riavvioa
kconfig [-f]
...al prompt del caricatore di avvio (su base
Itanium)
boot nome_config
...al prompt del caricatore di avvio
(PA-RISC)
hpux nome_config/vmunix
Elencare tutte le configurazioni della kernel
kconfig [-v]
Salvare la configurazione attualmente in
esecuzione
kconfig [-f]
Copiare una configurazione salvata
kconfig -c src dest
Rinominare una configurazione salvata
kconfig -r vecchia nuova
Cancellare una configurazione salvata
kconfig [-f]
-d nome_config
Caricare una configurazione salvata
kconfig [-f]
-l nome_config
Impostare il titolo di una configurazione
kconfig -t nome_config "titolo"
-n nome_config
-s nuovo_nome
a. Se si usa questa opzione, non occorre interrompere il processo di avvio per
selezionare la nuova configurazione della kernel.
382
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-21
Lavoro con i file di sistema
Procedura
Comando
Creare un file di sistema…
…per una configurazione salvata
kconfig -e nome_config nome_file
…per la configurazione attualmente in
esecuzionea
kconfig -e nome_file
Creare/aggiornare una configurazione da un file di sistemab...
... creare/aggiornare una configurazione
salvata
kconfig -i nome_config nome_file
…aggiornare la configurazione attualmente
in esecuzione
kconfig [-fhV]
-i nome_file
a. Include le eventuali modifiche tenute in sospeso per l’avvio successivo.
b. mk_kernel può anche essere usato a questo scopo.
Tabella 3-22
Lavoro con le modifiche tenute in sospeso per l’avvio successivo
Nota: kconfig -i, kcmodule e kctune tengono in sosspeso le loro modifiche fino all’avvio
successivo se non è possibile applicarle immediatamente, oppure se si specifica -h.
Elencare tutte le modifiche tenute in sospeso
per l’avvio successivo.
kconfig -D
Scartare tutte le modifiche tenute in sospeso
per l’avvio successivo.
kconfig -H
Capitolo 3
383
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-23
Lavoro con i settaggi
Elencare i settaggi ed i relativi valori...
kctune [tunable] ...
...output verboso
-v
...solo settaggi con modifiche tenute in sospeso per
l’avvio successivo
-D
...includere settaggi derivati impostati su valori di
default
-a
...raggruppare per nome di modulo
-g
…in una configurazione salvata
-c nome_config
Impostare il valore di un settaggio
kctune settaggio="espressione"
Impostare un settaggio sul default
kctune settaggio=default
Incrementare il valore di un settaggio
kctune settaggio+=valore
Assicurarsi che il valore del settaggio sia almeno n
kctune "settaggio>=n"
...tenere in sospeso la modifica fino all’avvio
successivo
-h
...applicare la modifica alla configurazione salvata
-c nome_config
...creare settaggio definito dall’utente
-u
384
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-24
Lavoro con i moduli della kernel
Elencare i moduli ed i relativi stati...
kcmodule [modulo] ...
...output verboso
-v
...solo moduli con modifiche tenute in sospeso per
l’avvio successivo
-D
...includere moduli richiesti
-a
…in una configurazione salvata
-c nome_config
Aggiungere un modulo alla configurazione...
...in stato di default
kcmodule modulo=best
...a connessione statica nell’eseguibile della kernel
kcmodule modulo=static
...a caricamento dinamico, ora e ad ogni avvio
kcmodule modulo=loaded
...caricato automaticamente in occasione del primo
utilizzo
kcmodule modulo=auto
Rimuovere un modulo dalla configurazione...
kcmodule modulo=unused
...Tenere in sospeso la modifica fino all’avvio
successivo
-h
...Applicare la modifica alla configurazione salvata
-c nome_config
Capitolo 3
385
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-25
Lavoro con il file di log di configurazione della kernel
Nota: Il file di log si trova in /var/adm/kc.log. I comandi kc* aggiungono una voce di log
per ogni modifica.
Aggiungere un commento al file di log...
...mentre si realizza una modifica con un
comando kc*
aggiungere -C "commento" al comando di
modifica
...senza realizzare una modifica della
configurazione
kclog -C "commento"
Visualizzare le ultime n voci nel log (il
default è 1)...
kclog n
...contando soltanto le modifiche ad una
configurazione
-c nome_config
...contando soltanto le modifiche di un certo
tipo
-t module|tunable|device
...contando soltanto le modifiche ad una
certa voce
-n
nome_modulo|nome_settaggio|percorso_
hw
...contando soltanto le voci di log contenenti
una stringa
-f "stringa"
Tabella 3-26
Ubicazioni del file di configurazione della kernel
Le configurazioni salvate sono memorizzate
in...
/stand/nome_config
L’eseguibile della kernel di trova in...
/stand/nome_config/vmunix
Il file di sistema si trova in...
/stand/nome_config/system
La configurazione attualmente in esecuzione
si trova in...
/stand/current
L’eseguibile della kernel di trova in...
/stand/current/vmunix
Il file di sistema si trova in...
/stand/current/system
Nota: Non manipolare mai direttamente alcuno dei file presenti in una directory di
configurazione della kernel, tranne che il file di sistema. Usare sempre i comandi kc*.
386
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Transizione dalle release precedenti di HP-UX
Gli amministratori esperti delle release precedenti di HP-UX troveranno
alcuni aspetti dei meccanismi di configurazione della kernel della release
11i v2 poco familiari. Tuttavia, molti dei concetti di base sono rimasti
invariati. Le tabelle di questa sezione forniscono le informazioni per
aiutare gli amministratori a migrare dai meccanismi di configurazione
della vecchia kernel ad 11i v2.
Tabella 3-27
Metodologia
Tecnica più vecchia di HP-UX
HP-UX 11i versione 2
Usare SAM per configurare la kernel.
Usare kcweb per configurare la kernel. a
Guardare in /stand/system per vedere la
configurazione attuale.
Invariato. b
Eseguire un comando non supportato per
assicurarsi che /stand/system sia
aggiornato.
Non necessario. /stand/system è tenuto
aggiornato in modo automatico. b
Realizzare le modifiche di configurazione
modificando /stand/system ed eseguendo
mk_kernel.
Invariato. Le modifiche saranno applicate al
sistema in esecuzione (nessun riavvio), se
possibile. b
Realizzare le modifiche di configurazione
eseguendo kmtune o kmsystem, poi
eseguendo mk_kernel.
Realizzare le modifiche con kctune o
kcmodule (nessun mk_kernel), o modificare
manualmente /stand/system e poi eseguire
mk_kernel. b c d
Realizzare le modifiche di configurazione
modificando /stand/system ed eseguendo
config.
Usare invece mk_kernel. b
Gestire i DLKM con i comandi kminstall,
kmsystem, kmmodreg, kmadmin, kmupdate e
config.
Gestire i DLKM usando kcmodule. c
Visualizzare o modificare i settaggi usando
kmtune. e
Usare invece kctune. d
a.
b.
c.
d.
e.
“Introduzione” a pagina 319
“Gestione delle configurazioni con i file di sistema” a pagina 361
“Gestione dei moduli della kernel con kcmodule” a pagina 329
“Gestione dei parametri settabili della kernel con kctune” a pagina 339
HP-UX 11i v2 contiene stub di compatibilità per kmpath e kmtune, ma saranno
rimossi in una release futura di HP-UX.
Capitolo 3
387
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-28
Comandi ed opzioni
Comando/opzione più vecchio di HP-UX
HP-UX 11i versione 2
config (senza -M)
mk_kernel a
config -M
Non più necessario
kmadmin -b
Non più necessario
kmadmin -k
kcmodule b
kmadmin -L nome_modulo
kcmodule nome_modulo=loaded b
kmadmin -U nome_modulo
kcmodule nome_modulo=unused b
kmadmin -u id_modulo
kcmodule nome_modulo=unused b
kmadmin -q id_modulo
kcmodule -v nome_modulo b
kmadmin -Q nome_modulo
kcmodule -v nome_modulo b
kmadmin -s
kcmodule b
kmadmin -S
kcmodule -v b
kminstall
Non più necessario
kmmodreg
Non più necessario
kmpath (nessuna opzione) c
kcpath -x
kmpath -k
kcpath -b
kmpath -c
kcpath -d
kmpath -i
Non più necessario
kmsystem (nessuna opzione)
kcmodule b
kmsystem -b
Non più necessario
kmsystem -c y -l y nome_modulo
kcmodule nome_modulo=loaded b
kmsystem -c y -l n nome_modulo
kcmodule nome_modulo=static b
388
Capitolo 3
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-28
Comandi ed opzioni (segue)
Comando/opzione più vecchio di HP-UX
HP-UX 11i versione 2
kmsystem -c n nome_modulo
kcmodule nome_modulo=unused b
kmsystem -q nome_modulo
kcmodule -v nome_modulo b
kmtune (nessuna opzione) c
kctune d
kmtune -l
kctune -v d
kmtune -q settaggio
kctune settaggio d
kmtune -r settaggio
kctune settaggio=Default d
kmtune -u -s settaggio=valore
kctune settaggio=valore d
kmtune -u -s settaggio+valore
kctune settaggio+=valore d
kmtune -s settaggio=valore
kctune -h settaggio=valore d
kmupdate (nessuna opzione)
kconfig -n hpux_test e
kmupdate kernel
kconfig -n configurazione e
kmupdate -M modulo
Non più necessario
kmupdate -d kernel
kconfig -d configurazione f
mk_kernel (senza-M)
mk_kernel a
mk_kernel -M
Non più necessario
a. “Gestione delle configurazioni con i file di sistema” a pagina 361
b. “Gestione dei moduli della kernel con kcmodule” a pagina 329
c. HP-UX 11i v2 contiene stub di compatibilità per kmpath e kmtune, ma saranno
rimossi in una release futura di HP-UX.
d. “Gestione dei parametri settabili della kernel con kctune” a pagina 339
e. “Uso di configurazioni salvate” a pagina 360
f. “Modifica di configurazioni salvate” a pagina 361
Capitolo 3
389
Configurazione di un sistema
Riconfigurazione della kernel (HP-UX 11i versione 2)
Tabella 3-29
File e directory
File/directory più vecchia di HP-UX
HP-UX 11i versione 2
Kernel attualmente in esecuzione:
/stand/vmunix
/stand/vmunix
Kernel di backup: /stand/vmunix.prev
Configurazione di backup: backup a
Kernel di prova:
/stand/build/vmunix_test (output di
default di mk_kernel)
Configurazione di prova: hpux_test b
File di sistema primario: /stand/system
/stand/system b
File di sistema del modulo:
/stand/system.d/*
Non più in uso. I dati si trovano ora nel file di
sistema primario, /stand/system. b
File master: /usr/conf/master.d/*
Non più in uso. I dati sono incorporati nel
codice della kernel e sono disponibili
attraverso i comandi kcmodule e kctune. c d
a.
b.
c.
d.
390
“La configurazione di backup automatica” a pagina 371
“Gestione delle configurazioni con i file di sistema” a pagina 361
“Gestione dei moduli della kernel con kcmodule” a pagina 329
“Gestione dei parametri settabili della kernel con kctune” a pagina 339
Capitolo 3
Configurazione di un gruppo di lavoro
4
Configurazione di un gruppo di
lavoro
Questa sezione si occupa delle procedure necessarie a configurare un
nuovo sistema in rete e nel gruppo di lavoro e configurare l’accesso
condiviso a risorse tipo file e stampanti e servizi come posta e backup:
•
“Installazione di nuovi sistemi” a pagina 392
•
“Aggiunta di utenti ad un gruppo di lavoro” a pagina 396
•
“Implementazione della strategia di gestione dei dischi” a pagina 401
•
“Condivisione di file ed applicazioni attraverso NFS e ftp” a
pagina 402
•
“Aggiunta di sistemi PC/NT al gruppo di lavoro” a pagina 420
•
“Configurazione di stampanti per un gruppo di lavoro” a pagina 440
•
“Compatibilità tra HP-UX Release 10.x ed 11.x” a pagina 455
Consultare anche:
Capitolo 4
•
“Configurazione di un sistema” a pagina 135
•
“Effettuazione del backup dei dati” a pagina 684
•
“Configurazione dei servizi di posta” a pagina 272
•
“Configurazione ed amministrazione di un cluster NFS diskless
HP-UX” a pagina 913
391
Configurazione di un gruppo di lavoro
Installazione di nuovi sistemi
Installazione di nuovi sistemi
La maggior parte dei sistemi HP viene consegnata con il sistema operativo
già installato sul disco di root; questa cosa viene definita accensione
immediata. Consultare “Avvio di un sistema precaricato” a pagina 136.
Se il sistema è stato ordinato senza l’accensione immediata, occorrerà
installare HP-UX da un CD-ROM o da un nastro DDS. Leggere la guida di
installazione di HP-UX per la propria versione di HP-UX come guida nel
corso del processo di installazione.
Una volta che il sistema sia stato attivato ed in esecuzione, occorrerà
realizzare le procedure descritte nel Capitolo 3, “Configurazione di un
sistema” a pagina 135. Occorrerà anche configurare il sistema nella rete
locale e nel gruppo di lavoro. Le seguenti sottosezioni forniscono la guida
a tali procedure.
•
“Configurare nuovi sistemi in rete” a pagina 392
•
“Configurare nuovi sistemi in un gruppo di lavoro” a pagina 395
Configurare nuovi sistemi in rete
•
Modificare il file /etc/hosts in modo che contenga le informazioni
corrette. Consultare “Configurazione di /etc/hosts” a pagina 393.
•
Impostare le informazioni sulla rete. Consultare “Impostazione delle
informazioni sulla rete” a pagina 393.
•
Abilitare i servizi di rete. Consultare “Concessione dell’accesso a
sistemi remoti” a pagina 394.
•
Abilitare l’accesso al server X. Consultare “Abilitazione dell’accesso
del server X” a pagina 395
•
Configurare le stampanti. Consultare “Gestione delle stampanti” a
pagina 714.
•
Aggiungere software a seconda delle necessità. Consultare:
— “Copia di software da un depot con l'interfaccia utente di SD” a
pagina 910
— “Copia di software da CD-ROM” a pagina 910
— “Copia di software da un nastro” a pagina 910
392
Capitolo 4
Configurazione di un gruppo di lavoro
Installazione di nuovi sistemi
Configurazione di /etc/hosts
Per modificare il file /etc/hosts è possibile usare un editor di testo
qualsiasi. Se si sta eseguendo BIND o NIS, è possibile usare SAM.
Punto
1. Se sul sistema non esiste alcun file /etc/hosts, copiare
/usr/newconfig/etc/hosts in /etc/hosts, o usare ftp per copiare sul
proprio sistema il file/etc/hosts di un altro sistema. Per maggiori
informazioni, consultare la manpage ftp (1).
Punto
2. Assicurarsi che il file /etc/hosts contenga la seguente riga:
127.0.0.1
Punto
localhost loopback
3. Aggiungere l’indirizzo IP, il nome e gli alias del proprio host al file
/etc/hosts, come nel seguente esempio:
15.nn.xx.103 wszx6 patrick
Il primo campo è l’indirizzo IP, il secondo è il nome host ufficiale (così come
viene restituito dal comando hostname) e tutti gli eventuali campi
restanti sono alias. Consultare la manpage hosts (4).
Punto
4. Se il sistema dispone di più di una scheda di rete, aggiungere una riga a
/etc/hosts per ogni indirizzo IP. Le voci per le schede aggiuntive devono
avere lo stesso nome host ufficiale, ma alias diversi ed indirizzi IP diversi.
Punto
5. Aggiungere i nomi di eventuali altri host che occorra raggiungere. Se si
userà un server BIND o NIS su un host diverso, aggiungere il nome di tale
host.
Se il proprio sito usa DNS (Domain Name Service – Servizio del nome del
dominio) o NIS (Network Information Service – Servizio delle
informazioni sulla rete), /etc/hosts agisce da risorsa di backup in caso di
disattivazione del server; pertanto, è una buona idea aggiungere i nomi
dei sistemi al sistema locale che occorra raggiungere spesso.
Impostazione delle informazioni sulla rete
Se si installa HP-UX sul sistema da soli, o non si forniscono le
informazioni sul networking durante l’installazione, è possibile
aggiungere queste informazioni in seguito eseguendo /sbin/set_parms
initial. Il programma invita ad inserire le seguenti informazioni:
Capitolo 4
•
nome host ed indirizzo (IP) del protocollo Internet.
•
fuso orario
393
Configurazione di un gruppo di lavoro
Installazione di nuovi sistemi
•
password di root
•
parametri opzionali:
— maschera di sottorete
— Indirizzo IP di un Domain Name Server
— Nome del dominio Network Information Service (NIS)
•
se rendere il sistema un font client o un font server
È possibile azzerare i parametri di networking in qualsiasi momento
eseguendo nuovamente /sbin/set_parms e riavviando il sistema.
Consultare “Impostazione manuale delle informazioni iniziali” a
pagina 269 per avere una lista e la descrizione delle opzioni di set_parms.
Se un sistema ha dei problemi nel comunicare con altri sistemi, verificare
che i file /etc/rc.config.d/netconf, /var/adm/inetd.sec e
/etc/hosts contengano tutti il nome host ufficiale corretto.
Concessione dell’accesso a sistemi remoti
Per consentire l’accesso utente ad un sistema remoto usando rcp o remsh
o rlogin senza dover fornire una password, configurare un file
/etc/hosts.equiv o $HOME/.rhosts sul sistema remoto. Per maggiori
informazioni, consultare la manpage hosts.equiv (4).
Il file /etc/hosts.equiv può contenere i gruppi di rete NFS. Per
maggiori informazioni, consultare Installing and Administering NFS
Services.
File $HOME/.rhosts Agli utenti elencati in $HOME/.rhosts è
consentito l’accesso al sistema locale, dai sistemi remoti e dagli account
denominati nel file, senza fornire una password. Il file deve essere di
proprietà dell’utente locale.
Nel seguente esempio, /users/spence/.rhosts risiede sul sistema
wsj6700. Gli utenti tom e patrick possono collegarsi all’account di
spence su wsj6700, rispettivamente da ws732 e wsb2600 senza fornire
una password.
ws732 tom
wsb2600 patrick
394
Capitolo 4
Configurazione di un gruppo di lavoro
Installazione di nuovi sistemi
Abilitazione dell’accesso del server X Per consentire ad un client X
di inviare l’output ad un server X usando l’opzione display, usare il
comando xhost .
Ad esempio, per consentire al sistema ws732 di inviare una finestra al
sistema wszx6, inserire:
xhosts +ws732
sul sistema wszx6.
Configurare nuovi sistemi in un gruppo di lavoro
Per configurare un nuovo sistema in un gruppo di lavoro, realizzare le
seguenti procedure:
•
Configurare i montaggi NFS in modo da consentire agli utenti del
sistema di condividere le directory di lavoro. Consultare “Aggiunta di
un utente a vari sistemi: un caso di studio” a pagina 397 o
“Condivisione di directory di lavoro remote” a pagina 397.
Se si sta usando NIS, è possibile usare il file /etc/netgroup per
definire gruppi per tutta la rete usati per la verifica dei permessi in
occasione dei montaggi remoti, dei login remoti e delle shell remote.
Consultare la manpage netgroup (4).
Capitolo 4
•
Aggiungere utenti e gruppi locali. Consultare “Controllo dell’accesso
ad un sistema” a pagina 244.
•
Aggiungere stampanti remote. Consultare “Aggiunta di una
stampante remota allo spooler LP” a pagina 443.
395
Configurazione di un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
Questa sezione include i sµeguenti argomenti:
•
•
•
•
•
“Accesso a sistemi multipli” a pagina 396
“Condivisione di directory di lavoro remote” a pagina 397
“Home directory locali ed home directory remote” a pagina 397
“Aggiunta di un utente a vari sistemi: un caso di studio” a pagina 397
“Esportazione di una home directory locale” a pagina 400
Accesso a sistemi multipli
Se un utente ha un account con lo stesso login su più di un sistema, (ad
esempio, se è stato eseguito il montaggio NFS della directory $HOME
dell’utente da un file server) il numero uid deve essere lo stesso su tutti
questi sistemi.
Ad esempio, supponiamo che l’utente tom abbia un uid di 200 sul sistema
ws732 ed importi dei file su wsj6700 dove ha un uid di 330. Se i file creati
su ws732 hanno permessi di -rw-------, allora non saranno accessibili a
tale utente da wsj6700. HP-UX stabilisce il possesso del file mediante
l’uid, non il nome utente.
In qualità di amministratore di sistema, occorre assicurarsi che il nome di
login di ogni nuovo utente disponga di un uid corrispondente che sia
esclusivo nell’ambito del gruppo di lavoro, o della rete che l’utente deve
raggiungere.
Consultare “Occorre condividere la home directory e la directory della
posta degli utenti?” a pagina 101.
Per consentire l’accesso ad un utente ad un sistema remoto usando rcp o
remsh o per usare rlogin senza dover fornire una password, configurare
il file $HOME/.rhosts sul sistema remoto. Consultare “File
$HOME/.rhosts” a pagina 394.
396
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
Condivisione di directory di lavoro remote
Dopo aver creato un nuovo account utente, occorre decidere a quali
directory nell’ambito del gruppo di lavoro l’utente debba accedere. NFS
consente agli utenti di usare i propri sistemi locali per lavorare su file che
risiedono su file server o altre workstation del gruppo di lavoro. Il server
o sistema remoto esporta al sistema locale ed il sistema locale importa
dal sistema remoto.
L’argomento “Aggiunta di un utente a vari sistemi: un caso di studio” a
pagina 397 illustra come si potrebbero configurare i propri utenti.
Home directory locali ed home directory remote
Gli utenti possono avere la loro home directory sul proprio sistema locale
o su un file server remoto. Il vantaggio di mantenere le home directory di
tutti gli utenti su un file server è rappresentato dal fatto che è possibile
eseguire il backup di tutti gli account in contemporanea.
Se la home directory di un utente si trova su un server remoto, si potrebbe
voler creare una home directory minima sul sistema locale in modo che un
utente possa ancora collegarsi al sistema locale se il server non è attivo.
Consultare “Occorre condividere la home directory e la directory della
posta degli utenti?” a pagina 101.
Per avere la procedura per la creazione di una home directory su un
sistema remoto, consultare “Aggiunta di un utente a vari sistemi: un caso
di studio” a pagina 397.
Aggiunta di un utente a vari sistemi: un caso di studio
Il seguente esempio illustra come importare la home directory di Tom e
lavorare la directory dal file server, flserver ed importare Emacs e
Netscape dal server delle applicazioni, appserver.
Capitolo 4
397
Configurazione di un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
Figura 4-1
Aggiunta di un utente a vari sistemi
Prima di iniziare, assicurarsi che il nome di login di Tom abbia un uid
esclusivo sui sistemi che si appresta ad usare (il proprio amministratore
di rete potrebbe avere un programma per garantire l’esclusività dei
numeri uid).
Poi, creare un account per Tom sul file server, flserver. Consultare
“Aggiunta di utente ad un sistema” a pagina 244.
Poi, procedere come segue:
1. Sul file server, esportare la directory home di Tom e la directory
projects in cui egli lavora:
•
Aggiungere una voce al file /etc/exports per esportare la
directory home di Tom:
/home/tom -async,anon=65534,access=appservr:ws732:wsj6700
Se la directory è già esportata, aggiungere semplicemente il
sistema dell’utente alla lista di accesso.
398
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
•
Aggiungere una voce al file /etc/exports per esportare la
directory /projects:
/work -async,anon=65534,access=wsb2600:wsj6700
Questo contiene i file e le directory che Tom condividerà con gli
altri componenti del suo gruppo di progetto.
•
Forzare il server a leggere nuovamente /etc/exports ed attivare
le nuove esportazioni per /work e /home:
exportfs -a
2. Sul server delle applicazioni, esportare le directory (emacs e
netscape) che servono a Tom:
•
Aggiungere le voci al file /etc/exports:
/usr/local/share/emacs -async,anon=65534,access=wsb2600:wsj6700
/opt/hp/gnu/bin700/emacs -async,anon=65534,access=wsb2600:wsj6700
/opt/netscape -asynd,anon=65534,access=wsb2600:wsj6700
•
Esportare le directory per emacs e netscape:
exportfs -a
3. Sulla workstation di Tom, wsb2600, procedere come segue:
•
Creare l’account di Tom. Consultare “Aggiunta di utente ad un
sistema” a pagina 244. Se il login di Tom è stato già configurato su
un altro sistema (ad esempio, su flserver), si potrebbe voler
tagliare la riga dal file /etc/passwd di flserver ed incollarla al
file /etc/passwd su wsb2600 per assicurarsi che l’account di Tom
abbia lo stesso numero uid su entrambi i sistemi.
•
Creare directory vuote per importare i file system.
mkdir
mkdir
mkdir
mkdir
mkdir
•
/home/tom
/work
/usr/local/share/emacs
/opt/hp/gnu/bin700/emacs
/opt/netscape
Aggiungere voci a /etc/fstab.
flsserver:/home/tom /home/tom nfs rw,suid 0 0
flserver:/work /work nfs rw,suid 0 0
appserver:/opt/netscape opt/netscape nfs rw,suid 0 0
appserver:/usr/share/emacs/ /usr/share/emacs nfs rw,suid 0 0
appserver:/opt/hp/gnu/bin700/emacs nfs rw,suid 0 0
Capitolo 4
399
Configurazione di un gruppo di lavoro
Aggiunta di utenti ad un gruppo di lavoro
•
Montare tutte le directory:
mount -a
Per ulteriori informazioni, consultare “Esportazione di un file system (da
HP-UX ad HP-UX)” a pagina 403.
Esportazione di una home directory locale
Supponiamo che si stia configurando un account sul sistema denominato
wsj6700 per l’utente lisa. In questo esempio, la home directory di lisa
risiederà sul suo disco locale e sarà esportata sugli altri sistemi nel
momento in cui si collega ad essi.
Sul sistema locale, procedere come segue:
•
Creare l’account dell’utente. Consultare “Aggiunta di utente ad un
sistema” a pagina 244.
•
Esportare la home directory dell’utente su altri sistemi ai quali
l’utente debba collegarsi:
— Aggiungere una voce, come flserver, a /etc/exports:
/home/lisa -async,anon=65534,access=mailserver:appserver:flserver
— Esportare la home directory/home/lisa:
exportfs -a
Sul sistema remoto, procedere come segue:
•
Creare una directory:
mkdir /home/lisa
•
Aggiungere la voce a /etc/fstab :
mailserver:wsj6700:/home/lisa /home/lisa nfs rw,suid 0 0
•
Montare tutte le directory:
mount -a
Per ulteriori informazioni, consultare “Esportazione di un file system (da
HP-UX ad HP-UX)” a pagina 403.
400
Capitolo 4
Configurazione di un gruppo di lavoro
Implementazione della strategia di gestione dei dischi
Implementazione della strategia di gestione
dei dischi
Quando si aggiunge capacità disco al gruppo di lavoro, potrebbero essere
utili uno o più dei seguenti argomenti, sia che si stia aggiungendo uno o
più nuovi dischi, un nuovo sistema server, o una nuova workstation con
uno o più dischi locali).
•
Riferimento rapido per “Aggiunta di un disco” a pagina 877.
•
“Distribuzione delle applicazioni e dei dati” a pagina 56
Suggerimenti su come distribuire memorizzazione disco nel proprio
gruppo di lavoro.
•
“Impostazione della strategia di gestione dei dischi” a pagina 71
Riepilogo degli strumenti e delle strategie per la gestione del disco di
HP-UX.
•
Configurazione dei volumi logici; consultare:
— “Il Logical Volume Manager (LVM)” a pagina 566
Introduzione a LVM
— “Esempi” a pagina 876
Riferimento rapido per l’aggiunta, la rimozione, l’espansione e la
riduzione dei volumi logici.
•
Capitolo 4
Configurazione dei montaggi NFS; consultare “Condivisione di file ed
applicazioni attraverso NFS e ftp” a pagina 402
401
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Condivisione di file ed applicazioni attraverso
NFS e ftp
Questa sezione fornisce le procedure e le informazioni sulla ricerca guasti
per Network File System (NFS) e File Transfer Protocol (ftp).
❏
NFS consente ad un computer di accedere ad un file system che
risiede sui dischi di un altro computer, come se il file system fosse
montato a livello locale.
Il server NFS è il computer su cui il disco è fisicamente fissato; i
computer che usano il file system da remoto si chiamano client NFS.
Prima di poter eseguire il montaggio dei client NFS (importare) un
file system che risiede sui dischi del server NFS, il server NFS deve
esportarlo.
Prima di poter importare ed esportare file system, occorre installare e
configurare il software NFS sia sul sistema server sia sul sistema
client. Nella maggior parte dei casi, ciò sarà stato fatto al momento
dell’installazione dei sistemi. Se occorre installare NFS, usare il
manuale Installing and Administering NFS Services.
Per informazioni e linee guida sulla pianificazione della
configurazione di condivisione file del gruppo di lavoro, consultare
“Distribuzione delle applicazioni e dei dati” a pagina 56.
❏
ftp è un meccanismo per la copiatura dei file da un sistema all’altro.
Questa sezione contiene le informazioni su quanto segue:
•
•
•
•
•
•
•
•
“Esportazione di un file system (da HP-UX ad HP-UX)” a pagina 403
“Importazione di un file system (da HP-UX ad HP-UX)” a pagina 404
“Prodotti di terzi” a pagina 409
“Ricerca guasti di NFS” a pagina 411
“Recupero dei servizi di rete dopo un guasto dell’alimentazione” a
pagina 414
“Spostamento o riutilizzo di una directory esportata” a pagina 416
“Configurazione dell’ftp anonimo” a pagina 416
“Ricerca guasti del login ftp” a pagina 419
Consultare anche:
•
402
“Aggiunta di un utente a vari sistemi: un caso di studio” a pagina 397
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Esportazione di un file system (da HP-UX ad HP-UX)
Usare una delle seguenti procedure per configurare le esportazioni NFS
sul server.
•
“Uso di SAM per esportare un file system” a pagina 403
•
“Uso della riga di comando per esportare un file system” a pagina 403
Uso di SAM per
esportare un file
system
Punto
1. Collegarsi al server come root.
Punto
2. Eseguire SAM: inserire
sam
sulla riga di comando.
Punto
3. Abilitare, se necessario, NFS:
Scegliere Networking and Communications/Network Services/NFS
Server. Far scendere il menu Actions e scegliere Enable.
Punto
4. Scegliere Networking and Communications/Networked File
Systems/Exported Local File Systems. Far scendere il menu Actions
e scegliere Add Exported File System
Punto
5. Compilare i campi identificando i file system da esportare ed i sistemi che
possono importarli. Se necessario, usare la guida in linea di SAM.
Il file system esportato deve ora essere elencato nel file /etc/exports.
Uso della riga di
comando per
esportare un file
system
Punto
1. Collegarsi al server come root.
Punto
2. Se il file system non è già configurato come server NFS:
1. Modificare /etc/rc.config.d/nfsconf, cambiando i valori per
NFS_SERVER e START_MOUNTD su 1.
Capitolo 4
403
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
2. Eseguire lo script nfs.server:
/sbin/init.d/nfs.server start
Punto
3. Modificare /etc/exports, aggiungendo una voce per ogni directory da
esportare. La voce identifica la directory e (in via opzionale) i sistemi che
possono importarla. La voce deve avere, più o meno, il seguente aspetto:
/opt/netscape async,anon=65534,access=wsb2600:appserver:wsb2600:wszx6
Se non si specifica alcun sistema per un file system particolare, allora
tutti i sistemi hanno il permesso di importare il file system; se qualche
sistema è elencato, allora soltanto quei sistemi possono importare il file
system.
NOTA
Per ulteriori informazioni, consultare exports (4).
Punto
4. Forzare il daemon NFS (nfsd) a rileggere /etc/exports.
/usr/sbin/exportfs -a
Importazione di un file system (da HP-UX ad HP-UX)
Prima di iniziare, occorre:
•
Verificare che la directory che si sta importando a:
— non esista già sul sistema (client) locale; o
— sia vuota; o
— contenga dati che non saranno necessari fino a che non si monti la
directory remota.
In tal caso, assicurarsi che nessuno abbia dei file aperti nella
directory locale e che non sia la directory di lavoro attuale di
nessuno. Ad esempio, se si intende importare ad una directory
denominata /mydir, sul client, inserire:
fuser -cu /mydir
NOTA
404
Quando si importa la directory remota, i file nella directory locale
saranno sovrapposti, ma non sovrascritti. I file locali saranno
nuovamente accessibili una volta smontata la directory remota.
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
•
Assicurarsi che il client disponga del permesso di importare il file
system dal server.
Questo richiede una voce in /etc/exports sul server; consultare il
Punto 3 sotto “Uso della riga di comando per esportare un file system”
a pagina 403.
•
Decidere se si desidera che questo montaggio sia:
— un montaggio NFS ordinario
— un file system NFS con montaggio automatico
— montato usando Automounter
— montato usando AutoFS
Usare una qualsiasi delle seguenti procedure per importare un file system.
•
“Uso di SAM per importare un file system” a pagina 406
•
“Uso della riga di comando per importare un file system” a pagina 407
NOTA
Allo stato attuale, SAM non supporta AutoFS. Per importare usando
AutoFS, consultare il Capitolo 2 del manuale Installing and
Administering NFS Services.
Decidere quale
tipo di montaggio
NFS usare
•
Montaggio NFS ordinario —
Usare un montaggio NFS ordinario quando si desidera che il file
system montato resti sempre montato. Questo è utile quando si farà
frequentemente accesso al file system montato.
•
File system NFS con montaggio automatico —
Usare un file system NFS con montaggio automatico quando si
desidera che il file system sia montato soltanto quando si usa in modo
attivo. Questo è utile quando non si accede frequentemente al file
system montato.
AutoFS o Automounter?
A partire dalla release 11.0 Extension Pack di agosto 1998, HP-UX ha
offerto una nuova utility di montaggio automatico, AutoFS, in
aggiunta all’Automounter già esistente. A partire da HP-UX 11i v2,
Automounter è diventato obsoleto; continuerà ad essere supportato
sulle release precedenti. È possibile configurare HP-UX 11.0
attraverso sistemi 11i v1.6 per usare Automounter o AutoFS.
Capitolo 4
405
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Se il sistema sta attualmente eseguendo Automounter, è possibile
migrare ad AutoFS, che presenta diversi vantaggi rispetto ad
Automounter:
❏
AutoFS può essere usato per eseguire montaggio di file system di
qualsiasi tipo, incluso NFS Protocol Versione 3 (Automounter può
essere usato soltanto per NFS Protocol Versione 2).
❏
Con AutoFS, i punti di montaggio configurati sono quelli effettivi
(Automounter monta le directory sotto /tmp_mnt e crea
collegamenti simbolici dai punti di montaggio configurati a quelli
effettivi sotto /tmp_mnt).
❏
Per modificare le mappe del montaggio automatico, non occorre
arrestare AutoFS. Il daemon di AutoFS, automountd, esegue in
continuo. Quando si effettua una modifica ad una mappa di
montaggio automatico, si esegue il comando automount, che legge
le mappe, poi si esce (ogni volta che si effettua una modifica ad
una mappa di montaggio automatico, occorre sopprimere e
riavviare Automounter).
Per ulteriori informazioni sulle modalità di uso dei file system con
montaggio automatico,incluso AutoFS e la migrazione ad AutoFS,
consultare il Capitolo 2 del manuale Installing and Administering NFS
Services.
Uso di SAM per
importare un file
system
Punto
1. Collegarsi al client come root.
Punto
2. Eseguire SAM. Inserire:
sam
sulla riga di comando.
Punto
3. Se necessario, abilitare i servizi del client NFS:
Scegliere “Networking and Communications/Network Services/NFS
Client”, poi far scendere il menu “Actions” e scegliere “Enable”.
Punto
406
4. Scegliere “Networking and Communications/Networked File
Systems/Mounted Remote File Systems”, poi far scendere il menu
“Actions” e scegliere “Add Remote File Systems.”
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Punto
5. Compilare i campi che identificano le directory da importare.
È possibile usare NFS ordinario o NFS Automounter.
•
Se si usa l’Automounter, il file system sarà montato sul client soltanto
quando un utente o delle richieste di processo accedono ad esso e sarà
smontato dopo che saranno trascorsi cinque minuti senza che sia
stata realizzata alcuna attività su di esso.
•
Se si usa la Mappa -hosts di Automounter, SAM creerà una directory
(/net per default) sotto la quale tutti i file system (su qualsiasi host
sulla rete) che a questo client è consentito importare, si rendono
disponibili a richiesta.
Per ulteriori informazioni, scegliere “Explain Automounter” sotto “Add
Remote File System ”in SAM, o consultare la manpage automount (1M).
Compilare i campi di SAM che identificano le directory da importare. Se
necessario, usare la guida in linea di SAM.
NOTA
Non occorre denominare la directory sul client con lo stesso nome che ha
sul server, ma renderà le cose più semplici (più trasparenti) per gli utenti
farlo. Se si stanno eseguendo applicazioni configurate per usare nomi di
percorso specifici, occorre assicurarsi che quei nomi di percorso siano gli
stessi su tutti i sistemi sui quali eseguono le applicazioni.
Uso della riga di
comando per
importare un file
system
Prima di iniziare: assicurarsi che il client sia configurato per importare
file system attraverso NFS. Il metodo più semplice è di usare SAM;
consultare il Punto 3 sotto “Uso di SAM per importare un file system” a
pagina 406.
Punto
1. Collegarsi al client come root.
Punto
2. Creare la directory locale sul client, se non esiste, ad esempio:
mkdir /opt/adobe
Se la directory esiste, i suoi contenuti saranno nascosti quando si monta la
directory remota e non saranno utilizzabili fino a che non la si smonti.
NOTA
Punto
3. Aggiungere una voce a /etc/fstab in modo che il file system sia montato
automaticamente all’avvio.
nfs_server:/nfs_server_dir /client_dir
Capitolo 4
nfs defaults 0 0
407
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Ad esempio:
fancy:/opt/adobe /opt/adobe nfs defaults 0 0
Punto
4. Montare il file system remoto.
Il seguente comando forza il sistema a rileggere /etc/fstab e montare
tutti i file system:
/usr/sbin/mount -a
Importazione di directory HP-UX ad NT
È possibile usare il prodotto HP CIFS/9000 o altri prodotti di terzi per
avere accesso ai file system del PC.
CIFS/9000
CIFS/9000 fornisce ad HP-UX un file system distribuito basato sul
protocollo CIFS (Common Internet File System) di Microsoft, anche noto
come il protocollo SMB (Server Message Block). Il protocollo SMB è il
protocollo di condivisione dei file nativo in Microsoft Windows e nei
sistemi operativi OS/2 e rappresenta il modo standard per milioni di
utenti di PC per condividere file in intranet aziendali.
CIFS/9000 implementa sia i componenti server sia client del protocollo
CIFS su HP-UX. Ciò significa che è possibile montare i file system di
HP-UX sui sistemi Window ed i file system Window possono essere
montati sui sistemi HP-UX.
Il CIFS/9000 Server si basa su Samba e fornisce servizi di file e di stampa
ai CIFS client incluso Windows NT, XP, 2000 ed altre macchine HP-UX
che eseguono il software CIFS/9000 Client.
Il CIFS/9000 Client consente agli utenti HP-UX di montare come file
system UNIX le condivisioni PC dai file server CIFS, incluso i server
Window e le macchine HP-UX che eseguono il software CIFS/9000 Server.
Il CIFS/9000 client offre anche un Pluggable Authentication Module
(PAM) opzionale che implementa i protocolli di autenticazione Windows
NTLM. Quando si installa e si configura all’interno del servizio PAM di
HP-UX, questo consente agli utenti HP-UX di essere autenticati rispetto
ad un server di autenticazione Windows.
408
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Per informazioni su CIFS/9000, incluso l’uso dettagliato su HP-UX,
consultare i manuali Installing and Administering the CIFS/9000 Server
e Installing and Administering the CIFS/9000 Client, entrambi
disponibili alla pagina http://docs.hp.com.
Prodotti di terzi
Microsoft Windows NT non include una funzione NFS nativa, ma vari
prodotti di terzi di buona qualità facilitano l’esportazione di file system
HP-UX ad una workstation NT.
Il riferimento rapido fornito di seguito usa il prodotto DiskAccess,
Microsoft Windows/NT Workstation 4.0 ed HP-UX 10.x o successivo.
Presume che si stia usando Domain Name Service (DNS) per
l’instradamento di rete.
A partire dal 2 maggio 1997, con le workstation HP Vectra XW Graphics
viene fornito un pacchetto di valutazione DiskAccess. Per altri sistemi, è
disponibile un pacchetto di valutazione gratuito della durata di un mese
alla pagina web http://www.ssc-corp.com/nfs.
NOTA
Installazione Installare DiskAccess da CD sulla workstation NT e
seguire i prompt. Al prompt, riavviare la workstation.
Esportazione di un file system da un server HP-UX Procedere
come segue sul server HP-UX.
Punto
1. Configurare il sistema HP-UX come server NFS; consultare
“Esportazione di un file system (da HP-UX ad HP-UX)” a pagina 403.
Punto
2. Assicurarsi che il daemon pcnfsd sia configurato per avviarsi all’avvio in
/etc/rc.config.d/nfsconf (PCNFS_SERVER deve essere impostato su
1).
Se necessario, modificare /etc/rc.config.d/nfsconf modificando la
riga
PCNFS_SERVER=0
in
PCNFS_SERVER=1
Punto
3. Assicurarsi che pcnfsd sia in esecuzione:
ps -ef | grep pcnfsd
Capitolo 4
409
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Se pcnfsd non è in esecuzione, avviarlo:
/usr/sbin/rpc.pcnfsd
Per ulteriori informazioni, consultare pcnfsd (1M)
Punto
4. Assicurarsi che le directory da esportare siano elencate in /etc/exports e:
•
sia
Il nome host del client NT è elencato tra i sistemi che hanno accesso
ad ogni directory
•
oppure
Nessun sistema è elencato per le directory.
ATTENZIONE
Se si effettua il dial-in al server usando un indirizzo IP variabile per il
client NT ed il server elenca il nome host del client in modo esplicito in
/etc/exports, la consultazione non andrà a buon fine perché l’indirizzo
IP non coinciderà. Occorre esportare la directory senza limitazioni
(nessun nome host in /etc/exports).
Se si è modificato /etc/exports, forzare il sistema a rileggerlo:
/usr/sbin/exportfs -a
Ora, realizzare quanto segue sul client NT.
Punto
1. Scegliere “Control Panel--DiskAccess--Authentication”.
1. Inserire un nome utente ed una password valida sul server HP-UX.
2. Selezionare la casella per “PCNFSD Server” ed inserire il nome host
del server HP-UX.
3. Fare clic su “Filenames” nel “DiskAccess Control Panel” e selezionare
“Preserve Case”.
Punto
2. Scegliere “Start--Programs--NT Explorer--Tools--Map Network Drive”
1. Inserire il nome dell’unità NT o accettare il default.
2. Inserire il nome_host:/nome_percorso del server HP-UX, (o inserire
nome_host soltanto per vedere una lista dei file system che il server
esporta).
3. Fare clic su OK.
410
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Ricerca guasti di NFS
Tabella 4-1
Decidere quale tipo di montaggio NFS usare
Problema
Il singolo client non
può importare da uno o
più server
Cosa fare
Verificare quanto segue sul client:
•
Controllare che la directory locale esista sul client. Se non
esiste, crearla usando mkdir. Ad esempio:
mkdir /opt/adobe
•
Cavo LAN intatto e connesso e tutte le connessioni attive.
•
/etc/hosts esiste ed ha “Voci richieste” a pagina 414.
•
/etc/fstab esiste ed ha “Voci richieste” a pagina 414 e le voci
puntano ancora a directory valide sul server.
•
/etc/resolv.conf esiste ed ha “Voci richieste” a pagina 414
(soltanto DNS)
•
/etc/rc.config.d/nfsconf ha NFS_CLIENT=1
Verificare il file direttamente, o verificare in SAM che
NFS_CLIENT sia abilitato (consultare “Uso di SAM per
importare un file system” a pagina 406).
Verificare sui server che le directory che il client sta tentando di
importare esistano e siano elencate in /etc/exports e che il
client disponga del permesso di importarle. Consultare il Punto 3
in “Uso della riga di comando per esportare un file system” a
pagina 403.
Capitolo 4
411
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Tabella 4-1
Decidere quale tipo di montaggio NFS usare (segue)
Problema
Tutti i client non
possono importare da
un determinato server
Cosa fare
Procedere come segue sul server:
•
Verificare che il server sia attivo ed in esecuzione e che la
connessione LAN tra il server ed i client sia attiva (è possibile
“eseguire il ping” dei client dal server e viceversa?)
Verificare che rpc.mountd sia in esecuzione:
ps -ef | grep rpc.mountd
Se rpc.mountd non è in esecuzione (sintomo RPC-PROG NOT
REGISTERED), eseguirlo:
/usr/sbin/rpc.mountd
•
Verificare che nfsd sia in esecuzione:
ps -ef | grep nfsd
Se nfsd non è in esecuzione, eseguirlo:
/usr/sbin/nfsd
412
•
Verificare che /etc/rc.config.d/nfsconf abbia
NFS_SERVER=1 e START_MOUNTD=1, o verificare in SAM che
“NFS Server” sia abilitato (consultare “Uso di SAM per
esportare un file system” a pagina 403).
•
Verificare che i file system che i client stanno tentando di
montare siano elencati in /etc/exports. Verificare
/etc/exports direttamente o verificare in SAM (consultare
“Uso di SAM per esportare un file system” a pagina 403).
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Tabella 4-1
Decidere quale tipo di montaggio NFS usare (segue)
Problema
Tutti i client non
possono importare da
un determinato server
(segue)
Gestione dei file
NFS fuori sincrono
(frequenti sui client
NFS dopo un crash del
server, o un riavvio
prima che i client
abbiano smontato i file
system NFS, o dopo che
/etc/exports è stato
modificato sul server).
Cosa fare
Sul server (segue):
•
exportfs -a
(per forzare il server a rileggere /etc/exports ed esportarvi
i file system specificati).
•
Eseguire SAM e portarsi nel menu “Services Enable/Disable”
sotto “Networking/Communications”, fare clic su “NFS
Server” e scegliere “Restart” dal menu a discesa.
•
Nel caso in cui questi rimedi non riescano e la configurazione
sembri in ordine (tutte le verifiche precedenti), allora il server
potrebbe non essersi avviato correttamente; tentare un
riavvio del server.
Sul/i client:
•
Verificare che non vi siano dei file aperti nei file system
interessati, poi tentare di eseguire il loro smontaggio e di
nuovo il montaggio.
Se /etc/exports è stato modificato sul server (direttamente
o attraverso SAM), tentare prima questa operazione.
Sul server:
•
exportfs -a
Se il server è stato appena riavviato, tentare prima questa
operazione.
Su un server NFS,
umount non va a buon
fine.
•
Verificare che tutti i file siano chiusi nel file system da
smontare e che non sia la directory di lavoro di nessuno, sul
sistema (host) da cui deve essere smontato. Da notare che
sebbene sia possibile usare fuser (1M) per verificare la
presenza di file aperti, esso non è in grado di rilevare i file in
una directory diversa aperta all’interno di un editor.
•
Se si esporta la directory, tentare questa operazione:
exportfs -u dir
Capitolo 4
413
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Voci richieste
Le seguenti voci sono richieste in /etc/hosts, /etc/fstab e
/etc/resolv.conf:
•
/etc/hosts:
— Nome host del sistema ed indirizzo IP, ad esempio:
12.0.14.123 fredsys fredsys.mysite.myco.com
— Una voce simile alla seguente:
127.0.0.1
•
localhost
loopback #[no SMTP]
/etc/fstab :
— (A meno che non si stia usando l’Automounter) una voce per
ciascun file system importato (consultare “Uso della riga di
comando per importare un file system” a pagina 407).
•
/etc/resolv.conf (necessario soltanto per Domain Name Service
[DNS]):
— Il nome del dominio in cui il sistema risiede, ad esempio:
domain mysite.myco.com
— Almeno un nome server, ad esempio:
nameserver 12.0.14.165
Recupero dei servizi di rete dopo un guasto
dell’alimentazione
Questa sezione descrive come eseguire la ricerca guasti dei problemi in cui
è probabile che l’utente e gli utenti delle workstation si imbattano quando
si riavvia dopo un guasto o un blocco dell’alimentazione generale.
L’esempio presume che si stia usando DNS (Domain Name Service).
Sintomi e parole chiave
RPC_PROG_NOT_REGISTERED
nome_server
rcmd: nome_host: Unknown host
rcmd:nome_host: Not in database
rcmd:nome_host: Access denied
414
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Cosa fare
A. Quando il Domain Name Server si disattiva
Se un sistema si attiva prima del Domain Name Server, non troverà il
nome server e si avrà il messaggio:
rcmd: nome_host: Unknown host
quando l’utente tenta di raggiungere un altro sistema.
La soluzione più semplice è di riavviare il sistema dopo aver riavviato il
nome server.
B. Quando un client non può importare directory da un server
Realizzare le verifiche di ricerca guasti descritte in “Ricerca guasti di
NFS” a pagina 411. Nel caso in cui queste non diano risultati ed il client
ottenga messaggi del tipo:
rcmd: nome_host: Not in database
rcmd: nome_host: Access denied
poi, procedere come segue sul server.
Punto
1. Collegarsi come superutente.
Punto
2. Avviare SAM.
Punto
3. Scegliere “Networking and Communications/Network Services/NFS
Server”.
Far scendere il menu “Actions” e scegliere “Restart” o “Enable”.
Punto
4. Selezionare “NFS Client”.
Punto
5. Far scendere il menu “Actions” e scegliere “Restart” o “Enable”.
Punto
6. Uscire da SAM.
Punto
7. Eseguire /usr/sbin/exportfs -a.
Ora, realizzare quanto segue sul client.
Punto
1. Eseguire SAM.
Punto
2. Scegliere “Networking and Communications--Network Services--NFS
Client”.
Far scendere il menu “Actions” e scegliere “Restart” o “Enable”.
Capitolo 4
415
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Spostamento o riutilizzo di una directory esportata
Se si rinomina una directory con montaggio NFS, occorre che i client NFS
smontino e rimontino la directory importata prima di poter vedere i nuovi
contenuti.
Ad esempio, se un server sta esportando /opt/myapp e si sposta
/opt/myapp a /opt/myapp.old allora ricostruire e ricompilare
/opt/myapp, tutti i client NFS devono smontare e rimontare la directory,
ad esempio (come superutente su ogni client):
umount /opt/myapp
mount -a
Tutti i client sui quali non si realizzi ciò, continueranno a vedere i
contenuti precedenti di /opt/myapp, cioè /opt/myapp.old.
È possibile imbattersi nello stesso problema in un modo leggermente
diverso quando si usa nuovamente un volume LVM.
Ad esempio, supponiamo che si smonti un file system obsoleto denominato
/projects da un file server denominato fp_server e di conseguenza di
usi nuovamente il volume logico, montandovi sopra un file system
/newprojects.
L’eventuale client che non smonti /projects vedrà i contenuti di
fp_server:/newprojects, etichettati /projects.
Configurazione dell’ftp anonimo
L’ftp anonimo consente agli utenti che non hanno un account su un dato
sistema di inviare file a quel sistema e di recuperarli da esso.
Punto
1. Aggiungere l’utente ftp a /etc/passwd, ad esempio:
ftp:*:500:1:anonymous ftp:/home/ftp:/usr/bin/false
Il campo della password deve essere *, l’appartenenza al gruppo deve
essere guest, o, come in questo esempio, other e la shell di login deve
essere /usr/bin/false.
In questo esempio, l’ID dell’utente ftp è 500 e la directory dell’ftp
anonimo è /home/ftp.
416
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Punto
2. Creare la directory ftp anonima:
1. Creare la home directory ftp a cui si fa riferimento nel file
/etc/passwd, ad esempio:
mkdir /home/ftp
2. Creare la sottodirectory /usr/bin sotto la home directory ftp, ad
esempio:
cd /home/ftp
mkdir usr
cd usr
mkdir bin
Punto
3. Copiare i comandi ls e pwd da /sbin e /usr/bin (rispettivamente) in
~ftp/usr/bin ed impostare i permessi sui comandi su solo eseguibile
(modo 0111):
cp /sbin/ls /home/ftp/usr/bin
cp /usr/bin/pwd /home/ftp/usr/bin
chmod u=x,g=x,o=x /home/ftp/usr/bin/ls
chmod u=x,g=x,o=x /home/ftp/usr/bin/pwd
Punto
4. Impostare il possessore delle directory ~ftp/usr/bin e ~ftp/usr su root
ed impostare i permessi su non scrivibile (modo 0555):
chown
chmod
chown
chmod
Punto
root /home/ftp/usr/bin
u=rx,g=rx,o=rx /home/ftp/usr/bin
root /home/ftp/usr
u=rx,g=rx,o=rx /home/ftp/usr
5. Creare la sottodirectory etc sotto la directory ftp, ad esempio:
cd /home/ftp
mkdir etc
Punto
6. Copiare /etc/passwd e /etc/group in ~ftp/etc.
Questi file sono richiesti dal comando ls, per visualizzare i possessori di
file e directory in ~ftp.
cp /etc/passwd /home/ftp/etc
cp /etc/group /home/ftp/etc
Capitolo 4
417
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Punto
7. Tutte le voci di /home/ftp/etc/passwd, sostituiscono il campo della
password con un asterisco (*) e cancellano il campo della shell, ad
esempio:
ftp:*:500:1:anonymous ftp:/home/ftp:
tom:*:8996:20::/home/tom:
Punto
8. Tutte le voci di /home/ftp/etc/group, sostituiscono il campo della
password con un asterisco (*):
users:*:20:acb
guest:*:21:ftp
Punto
9. Cambiare il possessore dei file in ~ftp/etc con root ed impostare i
permessi su sola lettura (modo 0444):
chown root /home/ftp/etc
chmod u=r,g=r,o=r /home/ftp/etc
Punto 10. Creare una directory pub sotto ~ftp e modificare il suo possessore con
l’utente ftp ed i suoi permessi su scrivibile da tutti (modo 0777).
Gli utenti ftp anonimi possono collocare i file in questa directory per
renderli disponibili ad altri utenti ftp anonimi.
mkdir /home/ftp/pub
chown ftp /home/ftp/pub
chmod u=rwx,g=rwx,o=rwx /home/ftp/pub
Punto 11. Creare una directory dist sotto ~ftp. Cambiare il suo possessore con
root ed i suoi permessi su scrivibile soltanto da root (modo 0755).
mkdir /home/ftp/dist
chown root /home/ftp/dist
chmod u=rwx,g=rx,o=rx /home/ftp/dist
Punto 12. Cambiare il possessore della home directory di ftp dell’utente con root ed
i permessi su non scrivibile (modo 0555):
chown root /home/ftp
chmod u=rx,g=rx,o=rx /home/ftp
418
Capitolo 4
Configurazione di un gruppo di lavoro
Condivisione di file ed applicazioni attraverso NFS e ftp
Ricerca guasti del login ftp
Sintomo: Alcuni o tutti gli utenti non possono eseguire l’ftp ad un
sistema HP-UX.
NOTA
Se nessun utente può eseguire l’ftp ad un dato sistema, verificare prima
di tutto che inetd sia in esecuzione su quel sistema:
ps -ef | grep inetd
Se inetd non è in esecuzione, avviarlo:
/usr/sbin/inetd
È anche possibile che il servizio ftp sia disabilitato. Verificare
/etc/inetd.conf per la seguente riga:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l
Se questa riga non esiste, o è annotata (preceduta da un segno del
cancelletto, (#) aggiungerla (o togliere il segno del cancelletto) e riavviare
inetd:
/usr/sbin/inetd -c
È anche possibile usare SAM per verificare lo stato di ftp e, se necessario,
abilitarlo: andare a Networking and Communications/Network
Services.
Problema: ftp richiama getusershell che per default verifica le
informazioni sulla password (cioè, la voce in /etc/passwd per l’utente che
sta tentando di collegarsi) confrontandole con una lista fissa. Se la shell
non è nella lista, ftp non consentirà all’utente di collegarsi, quindi se si
usa una shell insolita si potrebbe non essere in grado di eseguire l’ftp
perfino sul proprio sistema.
getusershell può essere informato dell’esistenza di altre shell
attraverso /etc/shells; consultare “Correzione 2” a pagina 419.
Correzione 1
Convertire tutto /bin/shell in /usr/bin/shell in /etc/passwd.
Correzione 2
Creare /etc/shells sul sistema che rifiuta i login ftp ed elencare tutte
le shell che compaiono in /etc/passwd.
Per ulteriori informazioni, consultare: getusershell (3C), shells (4).
Capitolo 4
419
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
•
“Connessioni hardware” a pagina 420
•
“Configurazione dei sistemi HP-UX per l’emulazione del terminale” a
pagina 421
•
❏
“telnet” a pagina 421
❏
“Altri emulatori del terminale” a pagina 424
“Configurazione dei sistemi HP-UX per il trasferimento file” a
pagina 424
❏
•
“ftp (File Transfer Protocol)” a pagina 425
“Montaggio dei file system tra HP-UX e PC” a pagina 439
Connessioni hardware
L’aggiunta di un personal computer (PC) ad un gruppo di lavoro è
un’operazione di carattere molto più logico che fisico. L’unico requisito da
un punto di vista hardware è di fornire al personal computer accesso fisico
agli altri computer del gruppo di lavoro. Di solito, ma non sempre, si tratta
di una connessione di rete. Tuttavia, potrebbe essere una connessione
modem (dial-in): una connessione UUCP su base telefonica, o una
connessione Serial Line Internet Protocol (SLIP) ad esempio.
I requisiti per questa connessione dipendono dalla modalità con cui si
pensa di interagire con il PC (consultare “Servizi per scambio dati con
Personal Computer” a pagina 124). Ad esempio, è improbabile che il
trasferimento occasionale di piccoli file ASCII o lo scambio di email su
base di testo tra utenti del PC e gli utenti dei computer HP-UX
rappresentino un problema per una linea seriale, perché la quantità di
dati trasferiti tra computer è fondamentalmente poca. Tuttavia, se si
pensa di condividere costantemente X Windows tra i sistemi HP-UX ed il
PC, si farebbe meglio ad avere una connessione ad alta velocità come una
connessione di rete tra i due tipi di computer, o le prestazioni delle
applicazioni risulteranno lente in modo inaccettabile, ammesso che esse
funzionino.
Quando si collega il PC agli altri computer, occorre prendere in
considerazione:
420
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
•
La quantità di dati da scambiare tra il PC e gli altri computer del
gruppo di lavoro
•
La frequenza con cui si pensa di accedere ai dati sul PC
(occasionalmente? Frequentemente? Costantemente?)
•
Il tipo di dati che si desidera scambiare (testo ASCII? Grafici? Suono?
Video?)
•
Le modalità con cui i dati saranno scambiati (trasferimento file?
Ambiente con creazione di finestre condiviso? Posta elettronica?)
Configurazione dei sistemi HP-UX per l’emulazione
del terminale
Il motivo principale della presenza di un computer in un gruppo di lavoro
(a prescindere dal tipo di computer) è che in tal modo gli utenti possono
accedere alle risorse degli altri computer del gruppo di lavoro.
Un modo comune di accedere alle risorse di un altro computer è di
collegarsi al computer remoto usando un programma di emulazione del
terminale come una utility del tipo di telnet.
telnet
La utility telnet è una parte standard del sistema operativo HP-UX e un
client telnet è incluso in versioni dei sistemi operativi Windows NT 4.0 di
Microsoft. Si usa per collegarsi ad un sistema remoto da un personal
computer (PC) o da un sistema HP-UX.
Il sistema remoto può essere un sistema su base UNIX (come un sistema
HP-UX), o un PC che esegue software server telnet. All’inizio, Windows
NT 4.0 include un programma client telnet, che è possibile usare per
collegarsi ai computer remoti, ma non include un’applicazione server
telnet, che consentirebbe ad altri computer di eseguire il “telnet in” al
sistema Windows NT. Sui sistemi HP-UX il software server telnet è nota
come il daemon telnetd.
Capitolo 4
421
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Uso di Telnet per collegarsi ad un PC da un sistema HP-UX
Per usare telnet per collegarsi ad un personal computer dal proprio
sistema HP-UX, occorrerà fare quanto segue:
Punto
1. Assicurarsi che il PC sia in esecuzione e raggiungibile via rete.
a. Accendere il PC ed avviare il sistema operativo Windows NT.
b. Assicurarsi che il PC abbia i servizi di networking configurati ed un
indirizzo di rete (indirizzo IP).
Punto
2. Assicurarsi che il PC esegua il software server telnet.
a. Installare una versione del software server telnet.
I sistemi operativi Windows NT 4.0 di Microsoft inizialmente non
includono il software server telnet. Versioni commerciali e shareware
del software server telnet sono disponibili da molte sorgenti.
NOTA
b. Configurare ed avviare il software server telnet seguendo le istruzioni
ad esso allegate.
Punto
3. Sul sistema HP-UX, avviare la utility telnet ed aprire una connessione
al PC al quale si sta tentando di accedere. Ad esempio:
/usr/bin/telnet
telnet> open vectrapc1.net2.corporate
Trying...
Connected to vectrapc1.net2.corporate.
Escape character is `^]'.
Local flow control off
Un piacevole messaggio di identificazione del server
telnet/OS
login:
SUGGERIMENTO
È possibile sveltire il processo di connessione usando telnet in modo non
interattivo. Per fare ciò, specificare il nome del PC al quale si sta tentando
di connettersi come argomento sulla riga di comando quando si avvia
telnet. Ad esempio:
/usr/bin/telnet vectrapc1.net2.corporate
422
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Punto
4. Collegarsi usando lo stesso nome utente e password come se si fosse seduti
alla tastiera del PC. Le modalità di specificazione delle informazioni sul
dominio NT varieranno a seconda del software del server telnet che si sta
usando. Seguire le istruzioni allegate al software del server telnet o i
prompt forniti dal software del server durante il processo di login.
Uso di Telnet per collegarsi da un sistema HP-UX da un PC
Punto
1. Assicurarsi che il PC sia in esecuzione e raggiungibile via rete.
a. Accendere il PC ed avviare il sistema operativo Windows NT.
b. Assicurarsi che il PC abbia i servizi di networking configurati ed un
indirizzo di rete (indirizzo IP).
Punto
2. Assicurarsi che il daemon telnetd sia in esecuzione sul sistema HP-UX.
Di solito, il daemon telnetd non si esegue direttamente. Copie di
telnetd sono avviate dal daemon inetd quando arrivano le richieste
sulla rete per i servizi telnet. Pertanto:
a. Controllare che esista una voce per telnetd nel file di configurazione
/etc/inetd.conf; la voce dovrebbe avere il seguente aspetto:
telnet
stream tcp nowait root /usr/lbin/telnetd
telnetd
b. Controllare che il file /etc/services abbia una voce con il seguente
aspetto:
telnet
23/tcp
# Virtual Terminal Protocol
c. Controllare che il daemon inetd sia in esecuzione. Su un sistema
collegato in rete che esegue ad un livello di esecuzione di o superiore a
2, inetd viene avviato automaticamente dallo script
/sbin/rc.2.d/S500inetd durante la sequenza di avvio. È possibile
controllare che sia in esecuzione emettendo il seguente comando:
/usr/bin/ps -ef|grep inetd
Punto
3. Sul PC, avviare il software del client telnet.
Se si sta usando il client telnet fornito con il sistema operativo Windows
NT 4.0, è possibile avviare il client nel seguente modo:
a. Facendo clic sulla barra “Avvio” nell’angolo inferiore sinistro dello
schermo del PC
b. Facendo clic su “Programmi” nel menu a comparsa che viene
visualizzato di conseguenza
Capitolo 4
423
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
c. Facendo clic su “Accessori” nel menu a comparsa che viene visualizzato
di conseguenza
d. Facendo clic su “Telnet” nel menu a comparsa finale
Punto
4. Usare il client telnet per connettersi al sistema HP-UX.
Se si sta usando il client telnet fornito con il sistema operativo Windows
NT 4.0, è possibile avviare il client nel seguente modo:
a. Facendo clic sulla voce di menu “Connect” nell’angolo superiore
sinistro della finestra telnet.
b. Facendo clic sulla voce di menu “Remote System ...” dal menu Connect.
c. Inserendo il nome del sistema HP-UX nel campo “Host Name” della
finestra di dialogo che compare di conseguenza (lasciare il campo
“Port” impostato su “telnet”).
d. Facendo clic sul pulsante “Connect” nell’angolo inferiore sinistro della
finestra di dialogo.
Altri emulatori del terminale
telnet è soltanto uno dei molti emulatori del terminale — a volte noti
come terminali virtuali — che è possibile usare per collegarsi a sistemi
remoti, ma nel mondo UNIX è uno di uso comune.
Un altro che è spesso supportato dai pacchetti software sul PC per
interagire con i sistemi UNIX è il daemon di rlogin. rlogin sui sistemi
HP-UX è rlogind. La configurazione e l’uso di rlogin tra sistemi HP-UX
e PC sono abbastanza simili a quelli per telnet, specialmente sulla
terminazione HP-UX. Il software (client o server) rlogin non è incluso
nella fornitura originale dei sistemi operativi Windows NT 4.0; tuttavia, è
possibile reperire versioni commerciali e shareware di rlogin per i PC su
base Windows NT.
Configurazione dei sistemi HP-UX per il trasferimento
file
Il trasferimento dei file tra computer rappresenta un’attività comune del
gruppo di lavoro. Quando si mescolano sistemi HP-UX e PC in un gruppo
di lavoro, di solito i trasferimenti di rete sono i più efficienti ed a volte
rappresentano il solo modo di trasferire file da un tipo di sistema ad un
424
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
altro. Molti sistemi HP-UX non sono dotati di unità floppy disk e molti PC
non sono dotati di unità DDS o altre periferiche di memorizzazione file
esterne che spesso si trovano sui sistemi HP-UX.
ftp (File Transfer Protocol)
Una delle utility/protocolli comuni sia ai sistemi Windows NT sia HP-UX
è ftp (file transfer protocol). ftp è un protocollo client/server. Il client ftp
è il programma che si esegue sul sistema locale per comunicare con il
server ftp sul sistema remoto.
Software del client Sui sistemi HP-UX, il client ftp è il programma /usr/bin/ftp. Sui
ftp
sistemi Windows NT 4.0 si avvia il client ftp emettendo il comando ftp
dal prompt di comando.
Software del
server ftp
Inclusi come parte dei sistemi operativi Windows NT 4.0 per PC (ma non
necessariamente installati in origine) vi sono un gruppo di utility
collettivamente note come i “Servizi di rete per Microsoft”. Uno dei servizi
di questa raccolta è un “servizio di pubblicazione ftp” che consente di
eseguire l’ftp dei file verso e dal PC mentre ci si trova davanti ad uno dei
sistemi HP-UX. Questo servizio è il server ftp in esecuzione sul PC. Sui
sistemi HP-UX, il server ftp è il daemon ftpd, avviato come richiesto dal
daemon inetd quando le richieste ftp giungono dai client su altri sistemi.
Come suggerisce il nome stesso, il protocollo di trasferimento file si usa
per trasferire file da un sistema ad un altro. Il trasferimento di file da un
computer ad un altro è un processo in due fasi. Occorre prima stabilire
una connessione e collegarsi al computer remoto; poi, occorre ubicare e
trasferire i file che si desidera spostare da o verso il computer remoto.
Stabilimento di una connessione ftp da HP-UX ad un PC
Si desidera procedere in senso inverso? Consultare “Stabilimento di una
connessione ftp da un PC ad HP-UX” a pagina 432.
NOTA
Prima di avviare la seguente procedura, assicurarsi che ftp sia impostato
per il genere di accesso richiesto. Il default è di consentire soltanto
l’accesso anonimo. Se si desidera consentire l’accesso utente singolo,
occorre usare l’Internet Service Manager.
Punto
1. Sul sistema HP-UX, avviare la utility ftp inserendo il comando:
/usr/bin/ftp
Capitolo 4
425
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Punto
2. Aprire una connessione al PC usando il comando open di ftp:
ftp> open vectrapc1.net2.corporate
Se la connessione va a buon fine, ftp informerà che si è connessi e
visualizzerà le informazioni sul server ftp del PC:
Connected to vectrapc1.net2.corporate.
220 vectrapc1 Microsoft FTP Service (Version 2.0).
Se la connessione è andata a buon fine, passare al Punto 3.
INFORMAZIONI SULLA RICERCA GUASTI
Se la connessione non è andata a buon fine ftp informerà della
mancata connessione. Il messaggio di errore visualizzato varierà a
seconda della causa della mancata connessione.
❏
ftp: connect: Connection refused
La causa più probabile di questo messaggio è:
✓
Problema: Il servizio di pubblicazione ftp sul PC su base
Windows NT non è in esecuzione (non è stato avviato).
Soluzione: Avviare il server ftp sul PC.
❏
ftp: connect: Connection timed out
Fra le cause possibili di questo messaggio di errore vi sono:
✓
Problema: Il PC non è attualmente in esecuzione.
Soluzione: Assicurarsi che il PC sia acceso ed in esecuzione
(che il sistema operativo Windows NT sia stato avviato).
✓
Problema: Il PC non è attualmente raggiungibile nella rete.
Soluzione: Assicurarsi che il PC sia fisicamente connesso
alla rete e che non vi siano impedimenti o interruzioni di rete
tra il PC ed il sistema HP-UX.
426
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
INFORMAZIONI SULLA RICERCA GUASTI
❏
ftp: vectrapc1: Unknown host
Fra le cause possibili di questo messaggio di errore vi sono:
✓
Problema: Il nome del PC è stato digitato in modo errato.
Soluzione: Controllare di aver inserito correttamente il
nome del PC nel comando open. A seconda del punto della
struttura di rete in cui è ubicato il PC rispetto al sistema
HP-UX, potrebbe essere necessario qualificare in modo
completo il nome del PC. Ad esempio:
ftp> open vectrapc1
è probabilmente sufficiente se il PC si trova sul segmento di
rete locale, ma un nome più completamente qualificato, ad
esempio:
ftp> open vectrapc1.net2
oppure
ftp> open vectrapc1.net2.corporate
sarà probabilmente necessario per accedere al PC se questo
si trova in qualsiasi altro punto della rete (su un router o un
gateway). Se quanto descritto sopra non dovesse sortire
effetto alcuno, tentare di usare l’indirizzo IP del PC al posto
del nome. Ad esempio:
ftp> open 15.nn.xx.2
✓
Problema: Il PC non è formalmente noto alla rete
Soluzione: Assicurarsi che i servizi di networking, in
particolare i servizi TCP/IP siano stati correttamente
configurati sul sistema operativo Windows NT. Occorre che il
computer abbia il suo indirizzo IP valido ed è necessario
assegnare un nome host ed un dominio DNS. Questi si
assegnano attraverso il servizio “Rete” nel “Pannello di
controllo” di Windows NT.
Punto
3. Inserire le informazioni di login
Una volta eseguita con successo la connessione al PC, un altro messaggio
seguirà il messaggio “Connected to...”:
Capitolo 4
427
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Name (vectrapc1.net2.corporate:userx):
Questo messaggio è in realtà un prompt di login ed esistono vari modi per
rispondere ad esso:
❏
Premere Invio per accettare la risposta di default
Nell’esempio precedente, vi sono tre parti nel prompt visualizzato:
1. La parola “Name”
2. Il nome di rete del PC (“vectrapc1.net2.corporate”)
3. Il nome utente di default (“userx”); di solito, si tratta del nome
dell’account HP-UX usato al momento dell’emissione del comando
ftp al Punto 1.
Se si preme Invio, ftp tenterà di collegare al PC usando lo stesso nome
usato per il collegamento ad HP-UX. Quindi, si sarà invitati ad
inserire la password. Se, dopo aver preso nota del seguente messaggio
di avvertenza, non si hanno problemi nel realizzare tale operazione,
inserire la password.
È importante notare qui che tutti i caratteri digitati sulla tastiera,
incluso il nome utente e la password saranno trasmessi in rete al PC
non codificati.
ATTENZIONE
Sebbene sia improbabile, specialmente se si tratta di una rete
rigorosamente interna, è possibile che qualcuno possa intercettare
elettronicamente le linee della rete e procurarsi le informazioni di
login. Se ciò rappresenta una preoccupazione, si consiglia vivamente
di usare l’opzione di login anonimo descritta a continuazione.
❏
Inserire un nome di account ed una password validi per il PC
Se l’account PC al quale si desidera collegarsi è diverso dal nome
utente usato per collegarsi ad HP-UX, inserire il nome utente per
l’account PC al prompt. Quindi, si sarà invitati ad inserire la
password per l’account. Se, dopo aver preso nota del messaggio di
avvertenza precedente, non si hanno problemi nel realizzare tale
operazione, inserire la password dell’account.
428
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
❏
Usare la funzionalità di login anonimo di ftp
Poichè i nomi di account e le password inseriti dalla tastiera durante
il processo di login ftp sono inviati al computer remoto non codificati
(rendendole in tal modo informazioni sensibili vulnerabili per chi
intenda intercettarle in rete), ftp fornisce un modo per accedere ad
un computer remoto usando quello che è noto come “login anonimo”.
Per usare questa funzionalità, inserire la parola “anonymous” al
prompt:
Name (vectrapc1.net2.corporate:userx): anonymous
Poi, sarà richiesto di inserire una password in un modo speciale:
331 Anonymous access allowed, send identity (e-mail name) as password.
Invece di inserire la password reale per un account, inserire il proprio
indirizzo email come mezzo di identificazione sul server ftp:
Password: [email protected]
Dopo aver inserito con successo le informazioni sull’account PC, si sarà
collegati al PC e collocati nella directory designata come directory di root
di ftp nella configurazione Windows NT.
Usando il comando cd del client ftp, gli utenti remoti del PC possono
accedere:
•
alla directory di root di ftp
•
a qualsiasi sottodirectory della directory di root di ftp
•
altre directory selezionate sul PC che siano state rese disponibili
appositamente dall’amministratore del PC
Per informazioni su come rendere disponibili queste altre directory,
consultare la documentazione in linea associata al “Microsoft Internet
Service Manager.”
Sul sistema HP-UX – Recupero di un file dal PC Una volta
realizzata una connessione e collegatisi al PC dal sistema HP-UX
(consultare “Stabilimento di una connessione ftp da HP-UX ad un PC” a
pagina 425) si è pronti a recuperare un file dal PC.
Capitolo 4
429
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Punto
1. Ubicare il file che si desidera recuperare dal PC. È possibile usare i
comandi cd ed ls di ftp più o meno allo stesso modo che in una shell
HP-UX (sh, ksh, csh, ecc.). Se non si trova nella directory di root di ftp,
usare il comando di spostamento di directory di ftp (“cd”) per spostarsi
alla directory sul PC in cui si trova il file.
Punto
2. Stabilire se il file che si sta tentando di trasferire sia un file ASCII o un
file (non ASCII) binario ed impostare il modo di trasferimento di
conseguenza.
a. Per i file ASCII (solo testo), impostare il modo di trasferimento usando
il comando ascii di ftp:
ftp> ascii
Ciò abilita il verificarsi delle conversioni dei caratteri tipo lo stripping
del ritorno del carrello di fine riga (consultare “Problemi di fine riga
ASCII” a pagina 130).
b. Per i file binari (file grafici, file di suono, file di database, ecc.),
impostare il modo di trasferimento usando il comando binary di ftp
ftp> binary
Ciò consente ad ftp di usare un trasferimento ad otto bit (byte) invece
di uno a sette bit (caratteri). Ciò è molto importante, dato che la
maggior parte dei formati non ASCII dipende da quell’ottavo bit di
ciascun byte. I file binari si corromperanno se li si trasferisce usando il
modo ascii.
SUGGERIMENTO
Punto
Nel caso in cui si abbiano dei dubbi sul formato del file che si sta
trasferendo (ASCII o binario), impostare il tipo di file su “binary”. I
file ASCII non si corromperanno se trasferiti in modo binario; tuttavia,
non si verificherà lo stripping del carattere di fine riga (consultare
“Problemi di fine riga ASCII” a pagina 130).
3. Trasferire il file usando il comando get di ftp.
Esempio 1: per recuperare il file ASCII “phone.dat” (ubicato nella
sottodirectory denominata “data”, sotto la directory di root di ftp) dal
PC:
ftp> cd data
ftp> ascii
ftp> get phone.dat
430
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Esempio 2: per poi recuperare il file grafico “net2.jpg” dalla
sottodirectory denominata “pics” (ubicata sotto la directory di root di
ftp):
ftp> cd ../pics
ftp> binary
ftp> get net2.jpg
Sul sistema HP-UX – Invio di un file al PC
Una volta realizzata una connessione e collegatisi al PC dal sistema
HP-UX (consultare “Stabilimento di una connessione ftp da HP-UX ad un
PC” a pagina 425) si è pronti a trasferire un file al PC.
Punto
1. Localizzare il file che si desidera inviare. È possibile usare i comandi lcd
e ! di ftp (eseguire un comando della shell) per ubicare il file sul sistema
locale se non si trova nella directory che era la directory di lavoro attuale
al momento dell’avvio di ftp. Inoltre, se il file non si trova nella directory
attuale, è possibile specificare un nome del percorso completo (assoluto)
per il file che si desidera inviare al PC.
Punto
2. Stabilire se il file che si sta tentando di trasferire al PC sia un file ASCII
o un file (non ASCII) binario ed impostare il modo di trasferimento di
conseguenza.
a. Per i file ASCII (solo testo), impostare il modo di trasferimento usando
il comando ascii di ftp:
ftp> ascii
Ciò abilita le conversioni di caratteri come quelle che gestiscono le
differenze tra come sono gestiti i fine riga tra diversi tipi di sistemi
operativi (consultare “Problemi di fine riga ASCII” a pagina 130).
b. Per i file binari (file grafici, file di suono, file di database, ecc.),
impostare il modo di trasferimento usando il comando binary di ftp
ftp> binary
Ciò consente ad ftp di usare un trasferimento byte ad otto bit invece di
un trasferimento di caratteri a sette bit. Ciò è molto importante, dato
che la maggior parte dei formati non ASCII dipende da quell’ottavo bit
di ciascun byte. I file binari si corromperanno se li si trasferisce usando
il modo ascii.
Capitolo 4
431
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
SUGGERIMENTO
Punto
Esempio 1:
Nel caso in cui si abbiano dei dubbi sul formato del file che si sta
trasferendo (ASCII o binario), impostare il tipo di file su “binary”.
I file ASCII non si corromperanno se trasferiti in modo binario;
tuttavia, non si verificherà la gestione del carattere di fine riga
(consultare “Problemi di fine riga ASCII” a pagina 130).
3. Trasferire il file usando il comando send di ftp.
Per inviare il file ASCII “phone.dat” (ubicato nella directory “/var/tmp”
sul sistema HP-UX) al PC:
ftp> lcd /var/tmp
ftp> ascii
ftp> send phone.dat
— OPPURE —
ftp> ascii
ftp> send /var/tmp/phone.dat
Esempio 2:
Per inviare il file di grafica “roadmap.jpg” dalla directory di lavoro attuale:
ftp> binary
ftp> send roadmap.jpg
Stabilimento di una connessione ftp da un PC ad HP-UX
Si desidera procedere in senso inverso? Consultare “Stabilimento di una
connessione ftp da HP-UX ad un PC” a pagina 425.
NOTA
Punto
1. Sul PC, avviare la utility ftp:
a. Facendo clic sulla barra “Avvio” nell’angolo inferiore sinistro dello
schermo del PC.
b. Facendo clic su “Programmi” nel menu a comparsa che viene
visualizzato di conseguenza.
c. Facendo clic su “Prompt di comando” nel menu a comparsa finale.
d. Digitando “ftp” al prompt nella finestra.
Punto
2. Aprire una connessione al sistema HP-UX usando il comando “open” di
ftp:
ftp> open flserver.net2.corporate
432
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Se la connessione va a buon fine, ftp informerà che si è connessi e
visualizzerà le informazioni sul server ftp sul sistema HP-UX:
Connected to flserver.net2.corporate.
220 flserver FTP Server (Version 1.7.111.1) ready.
Se la connessione è andata a buon fine, passare al Punto 3.
Se la connessione non è andata a buon fine, ftp informerà della mancata
connessione. Il messaggio di errore visualizzato varierà a seconda della
causa della mancata connessione.
❏ftp: connect: Connection refused
Fra le cause possibili di questo messaggio di errore vi sono:
✓
Problema: Il daemon Internet (inetd) non è in esecuzione sul
sistema HP-UX.
Soluzione: Il vero problema è che il daemon ftpd non è in
esecuzione, ma di solito è inetd che avvia ftpd a seconda delle
necessità del momento. Di solito, inetd si avvia all’avvio del
computer. Se il sistema HP-UX è in modo ad utente unico,
occorrerà commutarlo al livello di esecuzione 2 o superiore.
✓
Problema: Il daemon ftp (ftpd) non è in esecuzione.
Soluzione: Controllare che nel file /etc/inetd.conf vi sia una
voce valida per il daemon ftpd. La voce deve avere il seguente
aspetto:
ftp
stream tcp nowait root /usr/lbin/ftpd ftp
-lconf
Assicurarsi che la voce non sia annotata (nessun “#” nella prima
colonna).
Realizzare gli opportuni interventi di riparazione ed usare il
comando
/usr/sbin/inetd -c
per fare in modo che inetd legga nuovamente il suo file di
configurazione.
Capitolo 4
433
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
❏ftp: connect: Connection timed out
Fra le cause possibili di questo messaggio di errore vi sono:
✓
Problema: Il sistema HP-UX non è attualmente in esecuzione.
Soluzione: Assicurarsi che il sistema HP-UX sia acceso ed in
esecuzione (che il sistema sia stato avviato).
✓
Problema: Il sistema HP-UX non è attualmente raggiungibile
nella rete.
Soluzione: Assicurarsi che il sistema HP-UX sia fisicamente
connesso alla rete e che non vi siano impedimenti o interruzioni di
rete tra il PC ed il sistema HP-UX.
❏ftp: flserver: Unknown host
Fra le cause possibili di questo messaggio di errore vi sono:
✓
Problema: Il nome del sistema HP-UX è stato digitato in modo
errato.
Soluzione: Controllare di aver inserito correttamente il nome del
sistema HP-UX nel comando open. A seconda del punto della
struttura di rete in cui è ubicato il sistema rispetto al PC, potrebbe
essere necessario qualificare in modo completo il nome del
sistema HP-UX. Ad esempio:
ftp> open flserver
è probabilmente sufficiente se il PC si trova sul segmento di rete
locale, ma un nome più completamente qualificato, ad esempio:
ftp> open flserver.net2
oppure
ftp> open flserver.net2.corporate
sarà probabilmente necessario per accedere al sistema HP-UX se
questo si trova in qualsiasi altro punto della rete (su un router o
un gateway). Se quanto descritto sopra non dovesse sortire effetto
alcuno, tentare di usare l’indirizzo IP del sistema HP-UX al posto
del nome. Ad esempio:
ftp> open 15.nn.xx.100
434
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
✓
Problema: Il sistema HP-UX non è formalmente noto alla rete
Soluzione: Assicurarsi che i servizi di networking, in particolare i
servizi TCP/IP siano stati correttamente configurati sul sistema
HP-UX. Occorre che il computer abbia il suo indirizzo IP valido ed
è necessario assegnare un nome host.
Punto
3. Inserire le informazioni di login
Una volta eseguita con successo la connessione al sistema HP-UX, un
altro messaggio seguirà il messaggio “Connected to...”:
Name (flserver.net2.corporate:(none)):
Questo messaggio è in realtà un prompt di login ed esistono vari modi per
rispondere ad esso:
❏
Inserire un nome di account ed una password validi per il PC
Quindi, si sarà invitati ad inserire la password per l’account. Se, dopo
aver preso nota del messaggio di avvertenza che segue, non si hanno
problemi nel realizzare tale operazione, inserire la password
dell’account.
È importante notare qui che tutti i caratteri digitati sulla tastiera,
incluso il nome utente e la password saranno trasmessi in rete in rete
al PC non codificati!
ATTENZIONE
Sebbene sia improbabile, specialmente se si tratta di una rete
rigorosamente interna, è possibile che qualcuno possa intercettare
elettronicamente le linee della rete e procurarsi le informazioni di
login. Se ciò rappresenta una preoccupazione, si consiglia vivamente
di usare l’opzione di login anonimo descritta a continuazione.
❏
Usare la funzionalità di login anonimo di ftp
Poiché i nomi di account e le password inseriti dalla tastiera durante
il processo di login ftp sono inviati al computer remoto non codificati
(rendendole in tal modo informazioni sensibili vulnerabili per chi
intenda intercettarle in rete), ftp fornisce un modo per accedere ad un
computer remoto usando quello che è noto come “login anonimo”. Per
usare questa funzionalità, inserire la parola “anonymous” al prompt:
Name (flserver.net2.corporate:userx):anonymous
Capitolo 4
435
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Poi, sarà richiesto di inserire una password in un modo speciale:
331 Anonymous access allowed, send identity (e-mail name)
as password.
Invece di inserire la password reale per un account, inserire il proprio
indirizzo email come mezzo di identificazione sul server ftp:
Password: [email protected]
Dopo aver inserito con successo le informazioni sull’account HP-UX, si
sarà collegati al al sistema HP-UX e collocati nella directory designata
come directory di root di ftp.
Usando il comando cd del client, gli utenti remoti (collegati in modo
anonimo) possono accedere:
•
alla directory di root di ftp
•
a qualsiasi sottodirectory della directory di root di ftp
Sul PC – Recupero di un file dal sistema HP-UX Una volta
realizzata una connessione e collegatisi al sistema HP-UX dal PC
(consultare “Stabilimento di una connessione ftp da un PC ad HP-UX” a
pagina 432) si è pronti a recuperare un file dal sistema HP-UX.
Punto
1. Localizzare il file che si desidera recuperare dal sistema HP-UX. È
possibile usare i comandi cd ed ls di ftp più o meno allo stesso modo che
in una shell HP-UX (sh, ksh, csh, ecc.). Se non si trova nella directory per
l’account HP-UX al quale ci si è collegati, usare il comando di spostamento
di directory di ftp (“cd”) per spostarsi alla directory sul sistema HP-UX in
cui si trova il file.
Punto
2. Stabilire se il file che si sta tentando di trasferire sia un file ASCII o un
file (non ASCII) binario ed impostare il modo di trasferimento di
conseguenza.
a. Per i file ASCII (solo testo), impostare il modo di trasferimento usando
il comando ascii di ftp:
ftp> ascii
Ciò abilita il verificarsi delle conversioni dei caratteri tipo lo stripping
del ritorno del carrello di fine riga (consultare “Problemi di fine riga
ASCII” a pagina 130).
436
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
b. Per i file binari (file grafici, file di suono, file di database, ecc.),
impostare il modo di trasferimento usando il comando binary di ftp.
ftp> binary
Ciò consente ad ftp di usare un trasferimento ad otto bit (byte) invece
di uno a sette bit (caratteri). Ciò è molto importante, dato che la
maggior parte dei formati non ASCII dipende da quell’ottavo bit di
ciascun byte! I file binari si corromperanno se li si trasferisce usando il
modo ascii.
SUGGERIMENTO
Punto
Nel caso in cui si abbiano dei dubbi sul formato del file che si sta
trasferendo (ASCII o binario), impostare il tipo di file su “binary”. I
file ASCII non si corromperanno se trasferiti in modo binario, tuttavia,
non si verificherà lo stripping del carattere di fine riga (consultare
“Problemi di fine riga ASCII” a pagina 130).
3. Trasferire il file usando il comando get di ftp.
Esempio 1: per recuperare il file ASCII “phone.dat” (ubicato nella
sottodirectory denominata “data”, sotto la directory home per il proprio
account) dal sistema HP-UX:
ftp> cd data
ftp> ascii
ftp> get phone.dat
Esempio 2: per poi recuperare il file grafico “net2.jpg” dalla
sottodirectory denominata “pics” (ubicata sotto la directory home):
ftp> cd ../pics
ftp> binary
ftp> get net2.jpg
Sul PC – Invio di un file al sistema HP-UX Una volta realizzata una
connessione e collegatisi al sistema HP-UX (consultare “Stabilimento di
una connessione ftp da un PC ad HP-UX” a pagina 432) si è pronti a
trasferire un file al sistema HP-UX.
Capitolo 4
437
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Punto
1. Sul PC, localizzare il file che si desidera inviare. È possibile usare i
comandi lcd e ! di ftp per localizzare il file sul sistema locale se non si
trova nella directory che era la directory di lavoro attuale al momento
dell’avvio di ftp. Se il file non si trova nella directory attuale, è possibile
specificare un nome del percorso completo (assoluto) per il file che si
desidera inviare al sistema HP-UX, o usare il comando lcd di ftp per
spostare la directory contenente il file.
Punto
2. Stabilire se il file che si sta tentando di trasferire al sistema HP-UX sia un
file ASCII o un file (non ASCII) binario ed impostare il modo di
trasferimento di conseguenza.
a. Per i file ASCII (solo testo), impostare il modo di trasferimento usando
il comando ascii di ftp:
ftp> ascii
Ciò abilita le conversioni di caratteri come quelle che gestiscono le
differenze tra come sono gestiti i fine riga tra diversi tipi di sistemi
operativi (consultare “Problemi di fine riga ASCII” a pagina 130).
b. Per i file binari (file grafici, file di suono, file di database, ecc.),
impostare il modo di trasferimento usando il comando binary di ftp.
ftp> binary
Ciò consente ad ftp di usare un trasferimento ad otto bit (byte) invece
di uno a sette bit (caratteri). Ciò è molto importante, dato che la
maggior parte dei formati non ASCII dipende da quell’ottavo bit di
ciascun byte! I file binari si corromperanno se li si trasferisce usando il
modo ascii.
SUGGERIMENTO
438
Nel caso in cui si abbiano dei dubbi sul formato del file che si sta
trasferendo (ASCII o binario), impostare il tipo di file su binary. I file
ASCII non si corromperanno se trasferiti in modo binario, tuttavia,
non si verificherà la gestione del carattere di fine riga (consultare
“Problemi di fine riga ASCII” a pagina 130).
Capitolo 4
Configurazione di un gruppo di lavoro
Aggiunta di sistemi PC/NT al gruppo di lavoro
Punto
3. Trasferire il file usando il comando send di ftp.
Esempio 1: Per inviare il file ASCII phone.dat (ubicato nella directory
C:\office_stuff sul PC) al sistema HP-UX:
ftp> lcd C:\office_stuff
ftp> ascii
ftp> send phone.dat
— OPPURE —
ftp> ascii
ftp> send C:\office_stuff\phone.dat
Esempio 2: Per inviare il file di grafica roadmap.jpg dalla directory di
lavoro attuale:
ftp> binary
ftp> send roadmap.jpg
Montaggio dei file system tra HP-UX e PC
Tuttavia, un altro modo per condividere dati tra sistema HP-UX e PC è di
condividere un file system HP-UX tra loro usando PCNFS. Per un
esempio di come fare ciò, consultare “Prodotti di terzi” a pagina 409.
Capitolo 4
439
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Configurazione di stampanti per un gruppo di
lavoro
Questa sezione tratta la configurazione delle stampanti secondo due
metodi: lo spooler LP UNIX tradizionale ed il server di stampa distribuita
HP (HPDPS).
•
“Configurazione di stampanti per usare lo spooler LP” a pagina 440
•
“Configurazione delle stampanti per usare HPDPS” a pagina 451
Per informazioni concettuali sugli argomenti di gestione della stampa,
consultare “Pianificazione della configurazione della stampante” a
pagina 102.
Per le procedure sulla manutenzione dell’ambiente di stampa, consultare
“Gestione delle stampanti” a pagina 714.
Configurazione di stampanti per usare lo spooler LP
Questa sezione fornisce le informazioni sulla realizzazione delle seguenti
procedure:
•
“Inizializzazione dello spooler LP” a pagina 440
•
“Aggiunta di una stampante locale allo spooler LP.” a pagina 441
•
“Aggiunta di una stampante remota allo spooler LP” a pagina 443
•
“Aggiunta di una stampante su base di rete” a pagina 446
•
“Creazione di una classe di stampanti” a pagina 446
•
“Rimozione di una stampante dallo spooler LP” a pagina 447
•
“Rimozione di una stampante da una classe di stampanti” a
pagina 449
•
“Rimozione di una classe di stampanti” a pagina 450
Inizializzazione dello spooler LP
Prima di poter usare lo spooler LP, occorre inizializzarlo.
Uso di SAM
440
Se si usa SAM per aggiungere una stampante, SAM chiederà di
inizializzare lo spooler LP.
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Uso dei comandi di Per inizializzare lo spooler LP è possibile usare i comandi di HP-UX
HP-UX
secondo la procedura indicata di seguito:
Punto
1. Aggiungere almeno una stampante allo spooler LP.
Consultare “Aggiunta di una stampante locale allo spooler LP.” a
pagina 441.
Punto
2. Comunicare allo spooler LP di accettare le richieste di stampa
per questa stampante.
Usando l’analogia dell’impianto idraulico della Figura 2-2 a pagina 104,
ciò equivale ad aprire le valvole di entrata/uscita sopra i serbatoi di
contenimento. Consultare anche “Controllo del flusso di richieste di
stampa” a pagina 716.
Punto
3. Comunicare allo spooler LP di abilitare la stampante alla stampa.
Nell’analogia dell’impianto idraulico, ciò equivale ad aprire le valvole di
abilitazione/disabilitazione sotto i serbatoi di contenimento. Consultare
“Abilitazione o disabilitazione di una stampante” a pagina 717.
Punto
4. Attivare lo spooler LP.
Consultare “Interruzione e riavvio dello spooler LP” a pagina 715.
Aggiunta di una stampante locale allo spooler LP.
NOTA
Non confondere l’aggiunta di una stampante allo spooler LP con
l’aggiunta di una stampante al sistema: aggiungere una stampante allo
spooler LP comporta la configurazione dello spooler LP, mentre
aggiungere una stampante al sistema comporta la connessione della
stampante al computer e la configurazione dei driver necessari nella
kernel. Per informazioni su quest’ultimo punto, consultare Configuring
HP-UX for Peripherals.
Uso di SAM
Il modo più semplice di aggiungere una stampante locale allo spooler LP
è di eseguire SAM. SAM realizzerà anche una parte della configurazione
del CDE (se si userà il CDE) e una parte della configurazione di
SharedPrint (se si sta usando il modello di stampante SharedPrint).
Capitolo 4
441
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Uso dei comandi di
HP-UX
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
Punto
3. Aggiungere la stampante allo spooler LP. Ad esempio:
/usr/sbin/lpadmin -pstampante_locale -v/dev/lp -mmodello_HP -g7
Per i dettagli sulle opzioni, consultare lpadmin (1M). Consultare “File
modello della stampante” a pagina 106 per le scelte per l’opzione -m.
Punto
4. Se la stampante da aggiungere sarà la stampante di default, eseguire
quanto segue:
/usr/sbin/lpadmin -dstampante_locale
Consentire l’accettazione delle richieste di stampa per la stampante
appena aggiunta. Ad esempio:
/usr/sbin/accept stampante_locale
Consultare “Controllo del flusso di richieste di stampa” a pagina 716 per
informazioni su accept.
Punto
5. Abilitare la stampante appena aggiunta ad elaborare le richieste di
stampa. Ad esempio:
/usr/bin/enable stampante_locale
Per i dettagli, consultare “Abilitazione o disabilitazione di una stampante”
a pagina 717.
Punto
6. Riavviare lo spooler LP:
/usr/sbin/lpsched
Punto
7. Provare la stampante usando lo spooler LP, poi verificare lo stato dello
spooler LP. Ad esempio:
lp -dstampante_locale /etc/passwd
lpstat -t
442
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Aggiunta di una stampante remota allo spooler LP
Per acquisire dimestichezza con i concetti di spooling remoto, consultare
“Spooling remoto” a pagina 105.
Il modo più semplice di aggiungere una stampante remota è di eseguire
SAM. Se si sceglie di usare i comandi di HP-UX, esaminare la procedura
di SAM, Punto 4, dato che quando si realizza la procedura manualmente
occorreranno anche queste informazioni.
Uso di SAM
SAM non controlla l’esistenza di una stampante reale su un sistema
remoto. Assicurarsi che la stampante sia installata e configurata e, se
necessario, usare SAM per configurarla sul sistema remoto prima di
aggiungerla come stampante remota.
NOTA
Punto
1. Richiamare SAM come superutente.
Punto
2. Selezionare Printers and Plotters.
Punto
3. Dal menu a tendina Action, scegliere Add Remote Printer/Plotter.
Punto
4. Fornire le informazioni per i seguenti capi di dati.
Punto
Capitolo 4
•
Printer Name
•
Remote System Name
•
Remote Printer Name
•
Se Remote Printer si trovi su un sistema BDS
•
Remote Cancel Name
•
Remote Status Name
•
Default Request Priority
•
Se Allow Anyone to Cancel a Request
•
Se Make this Printer the Default Destination
5. Una volta completati tutti i campi, selezionareOK. In caso di configurazione
non andata a buon fine, SAM fornisce le informazioni sulla ricerca guasti.
I problemi più probabili saranno correlati alla configurazione del sistema
remoto. Verificare come segue:
443
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
a. Modificare /etc/services (sul sistema remoto) e, se necessario,
togliere la nota della riga che inizia con printer togliendo il #.
b. Assicurarsi che nessun sistema abbia la limitazione dell’accesso da
parte di /var/adm/inetd.sec.
c. Assicurarsi che rlpdaemon sia in esecuzione.
Uso dei comandi di
HP-UX
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
Punto
3. Aggiungere la stampante remota.
•
Se la stampante remota si trova su un sistema HP-UX, inserire:
lpadmin -pstampante_remota -v /dev/null -mrmodel \
-ormmacchina_remota -orpdest_remota -ocmrcmodel \
-osmrsmodel
•
Se la stampante remota non si trova su un sistema HP-UX, inserire:
lpadmin -pstampante_remota -v /dev/null -mrmodel \
-ormmacchina_remota -orpdest_remota -ocmrcmodel \
-osmrsmodel -ob3
Per i dettagli sulle opzioni, consultare lpadmin (1M). Consultare anche
“File modello della stampante” a pagina 106 per informazioni da fornire
all’opzione -m.
Punto
4. Consentire l’accettazione delle richieste di stampa per la stampante
remota appena aggiunta. Ad esempio:
/usr/sbin/accept stampante_locale
Punto
5. Se la stampante da aggiungere sarà la stampante di default, eseguire
quanto segue:
/usr/sbin/lpadmin -dstampante_locale
444
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Punto
6. Abilitare la stampante appena aggiunta ad elaborare le richieste di
stampa. Ad esempio:
/usr/bin/enable stampante_locale
Punto
7. Riavviare lo spooler LP per elaborare le richieste di stampa.
/usr/sbin/lpsched
Punto
Punto
8. Inviare un lavoro di stampa campione alla stampante.
•
Se stampa, il daemon di stampa remota (rlpdaemon) è attivo sul
sistema e la procedura è completa.
•
Se il lavoro di stampa non viene stampato, il daemon di stampa
remota (rlpdaemon) non è ancora attivo sulla macchina remota.
Attivare il rlpdaemon sul sistema host in cui risiede la stampante
remota, così come descritto di seguito.
9. Esaminare il file /etc/inetd.conf e cercare la seguente riga:
# printer stream tcp nowait root /usr/sbin/rlpdaemon rlpdaemon -i
Se compare un segno di # all’inizio della riga, significa che la riga
rlpdaemon è annotata, il che impedisce alla stampante di stampare a
distanza.
Modificare il file /etc/inetd.conf per togliere il segno di #. Salvare il
file.
Punto 10. Verificare /etc/services e cercare:
# printer 515/tcp spooler #remote print spooling
Se compare un segno di # all’inizio della riga, il servizio è annotato, il che
impedisce allo spooler di stampa di servire la stampante.
Modificare il file per togliere il segno di # nella prima colonna. Salvare il
file.
Punto 11. Riconfigurare il daemon Internet inetd, forzandolo a leggere nuovamente
il file /etc/inetd.conf. Richiamare il seguente comando:
/usr/sbin/inetd -c
Inoltre, verificare le voci in /var/adm/inetd.sec che limitano un certo
tipo di sistemi dall’invio di richieste di stampa remote.
Capitolo 4
445
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Punto 12. Provare la stampante usando lo spooler LP, poi verificare lo stato dello
spooler LP.
Ad esempio:
lp -dstampante_locale /etc/passwd
lpstat -t
Aggiunta di una stampante su base di rete
Uso di SAM
È possibile usare SAM per aggiungere una stampante su base di rete che
usa l’interfaccia di rete HP JetDirect. Occorre installare il software
HP JetDirect sul sistema ed essere pronti a fornire a SAM quanto segue:
•
il nome di nodo della stampante (il nome associato ad un indirizzo
Internet)
•
il nome locale usato dallo spooler LP per fare riferimento alla
stampante.
Con HP JetDirect, le stampanti possono connettersi direttamente in rete.
La stampante usa una connessione LAN ed il software HP JetDirect
trasmette le richieste di stampa. Per ulteriori informazioni, consultare la
HP JetDirect Network Interface Configuration Guide.
Uso dei comandi di Se non si usa SAM, seguire le istruzioni fornite con la stampante o la
HP-UX
scheda di interfaccia di rete per la stampante.
Creazione di una classe di stampanti
Per informazioni concettuali, leggere “Classe di stampanti” a pagina 108.
È possibile usare SAM per aggiungere una stampante ad una classe di
stampanti quando la stampante viene aggiunta allo spooler, altrimenti
occorre usare i comandi di HP-UX. Per usare i comandi di HP-UX, seguire
questa procedura dopo aver aggiunto varie stampanti allo spooler LP:
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
446
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Punto
3. Creare la classe di stampanti, specificando la stampante che si desidera
aggiungere alla classe di stampanti.
Ad esempio, per aggiungere una stampante denominata laser1 alla
classe di stampanti denominata laser, inserire:
/usr/sbin/lpadmin -plaser1 -claser
È possibile aggiungere soltanto una stampante per volta ad una classe.
Nel caso in cui si dovesse aggiungere più di una stampante, ripetere
questo comando.
Punto
4. Consentire l’accettazione delle richieste di stampa per la classe di
stampanti appena aggiunta.
Ad esempio:
/usr/sbin/accept laser
Punto
5. Riavviare lo spooler LP:
/usr/sbin/lpsched
Rimozione di una stampante dallo spooler LP
Uso di SAM
Punto
1. Richiamare SAM come superutente.
Punto
2. Selezionare Printers and Plotters.
Punto
3. Evidenziare la stampante o il plotter che si sta rimuovendo.
Punto
4. Dal menu a tendina Actions, scegliere Remove ...
NOTA
Capitolo 4
Prima di rimuovere la stampante dallo spooler LP, SAM chiede la
conferma. Se i lavori di stampa restano nella coda della stampante o se la
stampante è la destinazione di default del sistema, SAM informa di ciò. Se
si sceglie di rimuovere una stampante con dei lavori in coda, SAM li
annulla.
447
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Usando i comandi
di HP-UX
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. (Opzionale): Informare gli utenti che si sta rimuovendo la stampante dal
sistema.
Punto
3. Rimuovere la stampante dal file di configurazione dell’eventuale
applicazione software attraverso cui si accede al dispositivo (per le
informazioni, consultare la documentazione allegata all’applicazione
software).
Punto
4. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
Punto
5. (Opzionale): Negare eventuali ulteriori richieste di stampa per la
stampante. Ad esempio:
/usr/sbin/reject -r"Use alternate printer." laser1
Realizzando questo passo, è possibile essere sicuri che non comparirà
alcun lavoro nuovo prima di rimuovere la stampante.
Gli utenti vedranno il messaggio “Use alternate printer” quando
indirizzano le richieste ad una destinazione rifiutata se la stampante non
è stata rimossa. Una volta che la stampante sia stata rimossa e gli utenti
tentino di inviare una richiesta, essi vedranno il messaggio “Destination
nome_stampante non-existent”. Consultare “Controllo del flusso di
richieste di stampa” a pagina 716.
Punto
6. (Opzionale): Stabilire se nella coda della stampante vi siano dei lavori. Ad
esempio:
/usr/bin/lpstat -o laser1
Punto
7. (Opzionale): Disabilitare la stampante da rimuovere. Ad esempio:
/usr/bin/disable -r"Printer laser1 is disabled." laser1
448
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Se nella coda della stampante vi sono dei lavori e non si desidera
attendere che siano stampati prima di rimuovere la stampante, si
emetterà il comando disable precedente. Emettendo il comando disable
si spegne la stampante in modo normale.
Per ulteriori informazioni, consultare “Abilitazione o disabilitazione di
una stampante” a pagina 717. Notare che è anche possibile specificare
l’opzione -c del comando disable per annullare le richieste di stampa per
la stampante.
Punto
8. (Opzionale): Nel caso in cui non vi fossero lavori nella coda della
stampante, passare al Punto 9. Nel caso in cui ve ne fossero, decidere se
spostare tutte le richieste di stampa in attesa nella directory delle
richieste su un’altra directory delle richieste della stampante o se
annullare le eventuali richieste. Ad esempio, per spostare le richieste di
stampa:
/usr/sbin/lpmove laser1 laser2
Per annullare le eventuali richieste:
/usr/bin/cancel laser1
Punto
9. Rimuovere la stampante dallo spooler LP. Ad esempio:
/usr/sbin/lpadmin -xlaser1
Punto 10. Riavviare lo spooler LP:
/usr/sbin/lpsched
Per i dettagli sulle opzioni del comando, consultare lpshut (1M), lpadmin
(1M) e lpsched (1M).
Rimozione di una stampante da una classe di stampanti
Leggere “Classe di stampanti” a pagina 108 per acquisire dimestichezza
con questo concetto.
NOTA
Capitolo 4
Non è possibile usare SAM per rimuovere una stampante da una classe.
449
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Usando i comandi
di HP-UX
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
Punto
3. Rimuovere la stampante dalla classe. Ad esempio:
/usr/sbin/lpadmin -plaser1 -rclass
Punto
4. Riavviare lo spooler LP:
/usr/sbin/lpsched
Per i dettagli sulle opzioni del comando, consultare lpshut (1M), lpadmin
(1M) e lpsched (1M).
Rimozione di una classe di stampanti
Consultare “Classe di stampanti” a pagina 108 per acquisire
dimestichezza con questo concetto.
Non è possibile usare SAM per rimuovere una classe di stampanti.
NOTA
Usando i comandi
di HP-UX
Punto
1. Assicurarsi di disporre di capacità di superutente.
Punto
2. Arrestare lo spooler LP:
/usr/sbin/lpshut
Per ulteriori informazioni, consultare “Interruzione e riavvio dello spooler
LP” a pagina 715.
Punto
3. (Opzionale): Negare eventuali ulteriori richieste di stampa per la
stampante. Ad esempio:
/usr/sbin/reject -r"Use alternate printer." laser1
450
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Punto
4. (Opzionale): Stabilire se nella coda della stampante vi siano dei lavori. Ad
esempio:
/usr/bin/lpstat -o laser1
Punto
5. (Opzionale): Spostare tutte le richieste di stampa in attesa nella directory
delle richieste per la classe di stampanti su un’altra stampante o classe di
stampanti. Ad esempio:
/usr/sbin/lpmove laser1 laser2
Punto
6. Rimuovere la classe di stampanti. Ad esempio:
/usr/sbin/lpadmin -xlaser
Punto
7. Riavviare lo spooler LP:
/usr/sbin/lpsched
Per i dettagli sulle opzioni del comando, consultare lpshut (1M), reject
(1M), lpmove (1M), lpadmin (1M) e lpsched (1M).
NOTA
Quando si rimuovere una classe di stampanti, le stampanti della classe
non vengono rimosse, è ancora possibile usarle come stampanti singole.
Se si rimuovono tutte le stampanti da una classe, quella classe di
stampanti viene rimossa automaticamente.
Configurazione delle stampanti per usare HPDPS
IMPORTANTE
HPDPS non è supportato sulle versioni di HP-UX successive ad 11i
versione 1.
Questa sezione fornisce le seguenti procedure per la configurazione e
l’attivazione del Servizio di stampa distribuita HP:
•
“Implementazione di HPDPS” a pagina 452
•
“Avvio automatico di HPDPS” a pagina 454
•
“Modifica degli ambienti degli utenti per usare HPDPS” a pagina 454
Per informazioni concettuali su HPDPS, leggere “HP Distributed Print
Service (HPDPS)” a pagina 111.
Capitolo 4
451
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Implementazione di HPDPS
Punto
1. Installare i set di file richiesti, usando swinstall. Per ulteriori
informazioni, consultare “Determinazione dei set di file da installare e
loro ubicazione di installazione” a pagina 118.
Se si pensa di usare SAM per implementare ed amministrare HPDPS,
assicurarsi di installare un client HPDPS sul sistema da cui si eseguirà
SAM.
NOTA
Punto
2. Il modo più semplice per implementare HPDPS è di usare SAM per creare
gli oggetti HPDPS. Ecco come farlo per un ambiente di base HPDPS su un
sistema per cui lo spooler LP sia già configurato:
a. Come superutente, eseguire sam.
b. Selezionare Printers and Plotters. Compariranno due scelte
HP Distributed Print Services ed LP Spooler.
Prima di entrare nell’area HP Distributed Print Services,
selezionare LP Spooler. Registrare le informazioni sulla
configurazione esistente che occorrerà fornire ad HPDPS.
•
Nomi delle stampanti
•
Tipi di connessione (locale, di rete o remota) e le eventuali
informazioni aggiuntive del caso, tipo l’indirizzo IP.
•
Sistema host su cui la stampante è configurata
c. Passare al livello precedente di SAM e poi selezionare
HP Distributed Print Services per creare oggetti HPDPS.
È possible aggiungere oggetti HPDPS secondo qualsiasi ordine. SAM
fornirà i prompt successivi fino a che non siano stati aggiunti tutti i
componenti necessari ad un ambiente di base (questa procedura
documenta un ordine, ma non l’unico esistente).
d. Per creare oggetti HPDPS, selezionare l’icona Physical Printers.
Una volta che la schermata passi all’area Physical Printers, far
scendere il menu Actions per scegliere il tipo di stampante fisica (ad
esempio, una stampante HP-UX LP) da aggiungere. SAM risponde con
una finestra di dialogo per aggiungere l’accesso ad una stampante
dello spooler LP di HP-UX chiedendo le seguenti informazioni:
•
452
Ubicazione della stampante HPDPS, supervisore ed host del
supervisore
Capitolo 4
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
•
Destinazione LP, host dello spooler LP ed indirizzo IP per
registrare dove la stampante fisica HPDPS invierà i suoi lavori di
stampa.
Se sul sistema non esiste ancora un supervisore HPDPS, SAM
inviterà a crearne uno attraverso una finestra di dialogo. Se sul
sistema ne esiste uno, SAM ne visualizzerà le informazioni.
Quando si inserisce OK, SAM visualizza un’altra finestra di dialogo al
fine di inserire ulteriori informazioni sulla stampante fisica stessa:
•
Printer name
•
Printer model
•
Print queue
Se esiste una coda di stampa, SAM visualizza le informazioni sulla
coda di stampa; altrimenti, SAM invita ad inserire il nome della
coda di stampa, lo spooler e l’host dello spooler. È anche possibile
impostare i metodi di programmazione dei lavori (su priorityfifo o fifo) scegliendo le opzioni di coda di stampa.
Quando si inserisce OK, se sul sistema non esiste alcun oggetto
Stampante logica, SAM invita a crearlo con un’altra finestra di
dialogo. In alternativa, è possibile selezionare Logical Printers dal
menu a tendina List. Poi, dal menu a tendina Actions, scegliere Add
a Logical Printer. SAM invita ad inserire il nome della Stampante
logica, la coda di stampa e visualizza le informazioni sulla coda di
stampa, incluso l’host dello spooler e la/e stampanti fisiche.
Mentre si creano gli oggetti HPDPS (stampante fisica, stampante
logica, coda di stampa, spooler e supervisore), SAM riporta i risultati
ed invita a continuare a creare gli oggetti fino a che non ne sia stato
creato un set minimo.
Uscire da SAM.
e. Per usare HPDPS, occorre attivare lo spooler ed i daemon del
supervisore. Il modo più semplice per farlo è di eseguire i seguenti
comandi di HP-UX:
/opt/pd/bin/pdstartspl
/opt/pd/bin/pdstartsuv
Capitolo 4
453
Configurazione di un gruppo di lavoro
Configurazione di stampanti per un gruppo di lavoro
Punto
3. Controllare la configurazione HPDPS inviando un file ad una stampante
logica configurata per HPDPS. Ad esempio,
pdpr -p Logical1 /etc/passwd
Avvio automatico di HPDPS
Una volta implementato HPDPS sul/i sistemi, si vorrà modificare il file di
configurazione di avvio, /etc/rc.config.d/pd, per avviare i daemon di
HPDPS all’avvio del sistema.
Per informazioni dettagliate su ciò, consultare “Automatically Starting
HPDPS,” nel Capitolo 4 della HP Distributed Print Service
Administration Guide.
Modifica degli ambienti degli utenti per usare HPDPS
Abilitazione degli utenti ad accedere alle stampanti HPDPS
Durante il processo di installazione, HPDPS aggiunge /opt/pd/bin alla
variabile di ambiente PATH di HP-UX. Perché gli utenti accedano ai
comandi di HPPDS, occorre che abbiano lo stesso percorso impostato nel
loro ambiente.
È possibile aggiungere il percorso agli eseguibili di HPDPS nel loro file
/etc/PATH emettendo quanto segue al prompt:
PATH=$PATH:/opt/pd/bin
Definizione di una stampante logica di default Per semplicità
d’uso degli utenti, impostare la variabile di ambiente PDPRINTER per
designare una stampante logica di default.
Ad esempio, per impostare il valore di PDPRINTER su laserjet1,
modificare il file /etc/profile comune a tutto il sistema ed aggiungere
la riga:
export PRPRINTER=laserjet1
Gli utenti possono anche aggiungere la stessa riga ai loro file .profile
per impostare una stampante logica di default.
454
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Compatibilità tra HP-UX Release 10.x ed 11.x
Gli argomenti trattati in questa sede concernono i problemi di
compatibilità che potrebbero insorgere in configurazioni del gruppo di
lavoro in cui i sistemi eseguano diverse versioni delle release HP-UX ed
anche risorse condivise come file system ed applicazioni. Ad esempio, un
gruppo di lavoro ipotetico in un ambiente misto potrebbe contenere un
server HP-UX 11.0 e tre client HP-UX 10.20.
Compatibilità da HP-UX 10.x ad 11.0
HP-UX 11.0 può essere compilato per eseguire come sistema operativo a
32 bit oppure a 64 bit. In generale, HP-UX 11.0 è progettato per essere
completamente compatibile con HP-UX 10.x.
NOTA
Notare che non occorre trasferire la maggior parte del software per
eseguirlo su HP-UX 11.0: la gran parte del software eseguirà in modo
accettabile su 11.0 senza modifiche o ricompilazioni della sorgente.
HP-UX supporta i seguenti tipi di compatibilità in HP-UX 11.0.
NOTA
Per informazioni dettagliate sulle eccezioni alla compatibilità, consultare
Release Notes for HP-UX 11.0.
Compatibilità binaria
Un’applicazione che eseguiva su una release HP-UX 10.x generalmente
continuerà ad eseguire con lo stesso comportamento sia su HP-UX 11.0 a
32 bit sia a 64 bit, a condizione che siano presenti anche le eventuali
librerie condivise dipendenti. Un eseguibile è un file binario elaborato
dall’editor di collegamento HP con ld o indirettamente con il compilatore
e può essere eseguito dal caricatore di HP-UX (exec).
Compatibilità della sorgente
Il software a 32 bit compilato su una release HP-UX 10.x può essere
ricompilato senza modifica su HP-UX 11.0. Il termine “sorgente” include
la sorgente di input su compilatori, script e file makefile.
Capitolo 4
455
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Compatibilità dei dati
Un’applicazione a 32 bit può continuare ad accedere ai file di dati
preesistenti, come i file di sistema, i formati di backup/recupero ed i
formati di dati documentati di HP attraverso le API supportate allo stesso
modo in cui lo faceva nella release precedente. Un’applicazione a 64 bit
può accedere agli stessi dati allo stesso modo in cui lo fa un’applicazione a
32 bit. Ad esempio, se si accede alle informazioni sul file della password
attraverso getpwent() invece che direttamente leggendo il file,
l’applicazione conserverà la compatibilità dei dati.
Compatibilità di upgrade
Le configurazioni ed i dati personalizzati provenienti da HP-UX 10x
vengono conservati all’upgrade ad HP-UX 11.0a 32 bit o 64 bit.
Compatibilità binaria riallocabile
Un oggetto riallocabile può essere un file .o, una libreria condivisa .sl, o
una libreria di archivio .a.
•
Compatibilità binaria dell’oggetto riallocabile da release a release.
La compatibilità binaria dell’oggetto riallocabile da release a release
non è supportata. In altre parole, se si collega un’applicazione con
oggetti riallocabili a compatibilità superiore provenienti da release
diverse o si usa shl_load() o dlopen() per caricare in modo
dinamico librerie condivise costruite su una release diversa da quella
dell’applicazione, l’eseguibile che ne consegue non è supportato.
È possibile che ciò si verifichi, ad esempio, quando si ricompilano i
componenti su HP-UX 11.0, ma li si collega alle librerie ISV create per
HP-UX 10.x. Ne risulta che, se un oggetto viene ricompilato su 11.0,
tutti gli oggetti che comprendono l’eseguibile devono essere
ricompilati su 11.0; non è possibile collegare sia le librerie pre-11.0 sia
le librerie 11.0 in un oggetto/eseguibile riallocabile. Da notare che non
comparirà alcun messaggio di avvertimento se si compie tale
operazione, ma l’eseguibile potrebbe mostrare un comportamento non
corretto.
•
Compatibilità degli oggetti riallocabili di archivio e condivisi.
Non si consiglia un eseguibile creato mediante collegamento con un
misto di librerie condivise e di archivio.
456
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
•
Compatibilità degli oggetti riallocabili del modello dati.
La creazione di un eseguibile mediante collegamento con un misto di
oggetti a 32 bit ed a 64 bit non è supportata e non sarà consentita dal
caricatore.
Compatibilità tra 32 bit e 64 bit
Esistono varie aree in cui potrebbero insorgere dei problemi di
compatibilità tra versioni a 32 bit ed a 64 bit di HP-UX 11.0. Nelle sezioni
a seguire si trovano le spiegazioni a tali problemi:
•
“Esecuzione di applicazioni 10.x su HP-UX 11.0” a pagina 457
•
“Scambio di dati tra applicazioni a 32 bit ed a 64 bit” a pagina 461
La Tabella 4-2 illustra come i sistemi supportati interagiscono con le
versioni a32 bit ed a 64 bit di HP-UX 11.0.
Tabella 4-2
Compatibilità tra 32 bit e 64 bit
Solo 32 bit
Sistemi supportati
32 bit e 64 bit
Sistemi supportati
Solo 64 bit
Sistemi supportati
- Può aggiornare o installare
soltanto alla versione a 32
bit di HP-UX 11.0.
- Può aggiornare o installare
soltanto alla versione a 32
bit o a 64 bit di HP-UX 11.0.
- Può aggiornare o installare
soltanto alla versione a 64
bit di HP-UX 11.0.
- Possono eseguire soltanto
le applicazioni a 32 bit.
- Possono eseguire sia le
applicazioni a 32 bit sia
quelle a 64 bit.
- Possono eseguire sia le
applicazioni a 32 bit sia
quelle a 64 bit.
- Possono compilare e
collegare sia i binari a 32 bit
sia i binari a 64 bit.
- Possono compilare e
collegare sia i binari a 32 bit
sia i binari a 64 bit.
- Possono compilare e
collegare sia i binari a 32 bit
sia i binari a 64 bit.
Esecuzione di applicazioni 10.x su HP-UX 11.0
Il termine compatibile binario significa che un’applicazione che
eseguiva su una release precedente di norma continuerà ad eseguire con
lo stesso comportamento sulla release attuale. Nella gran parte dei casi, il
software di legacy è compatibile binario con HP-UX 11.0 (cioè,
l’esecuzione andrà a buon fine). Se si sta eseguendo la versione a 32 bit di
11.0, non si incorrerà in alcun problema. Tuttavia, nel caso della versione
a 64 bit di HP-UX 11.0, potrebbero esservi dei problemi di compatibilità
per il software di legacy.
Capitolo 4
457
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Per stabilire se un’applicazione a 32 bit specifica sia compatibile binaria
su un sistema operativo a 64 bit, procedere come segue:
•
Nel caso in cui si sia acquistata un’applicazione di terzi, verificare con
il rivenditore dell’applicazione per assicurarsi che sia supportata su
HP-UX 11.0. Nel caso in cui si eseguirà la versione a 64 bit di 11.0,
chiedere al rivenditore una dichiarazione concernente
l’interoperabilità dell’applicazione a 64 bit con applicazioni a 32 bit.
•
Nel caso in cui si sia scritto il software a livello locale, in particolare se
quel software condividerà dei dati con applicazioni a 64 bit, potrebbe
essere necessario effettuare delle modifiche al codice sorgente. Come
supporto in tal senso, il kit di transizione software (STK) di HP-UX è
disponibile sul CD-ROM HP-UX 11.0 Application Release, o
attraverso il World-Wide Web al seguente indirizzo
http://www.software.hp.com/STK.
Decisione sul trasferimento o meno del software
Il termine trasferimento da piattaforma descrive il processo di
creazione di un nuovo binario HP-UX 11.0.
Nel caso in cui si decida che l’applicazione deve eseguire in modo a 64 bit,
occorrerà trasferirla.
Quando non trasferire il software da piattaforma su HP-UX 11.0
Eseguire il software senza trasferirlo da piattaforma comporta la minima
quantità di sforzo dato che non occorre realizzare modifiche importanti
della sorgente o ricompilare il software sulla piattaforma 11.0.
Se non si desidera trasferire il software da piattaforma, si hanno due
scelte:
458
•
Nella maggior parte dei casi, è possibile eseguire semplicemente
l’eseguibile sulla piattaforma di destinazione (che può eseguire la
versione a 32 bit o a 64 bit di HP-UX 11.0) senza realizzare alcuna
modifica al codice sorgente o ricompilazione.
•
È possibile eseguire sulla piattaforma di destinazione (che può
eseguire sia la versione a 32 bit sia quella a 64 bit di HP-UX 11.0)
realizzando modifiche minori della sorgente e ricompilando sulla
piattaforma sorgente (che esegue HP-UX 10.x).
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Conviene eseguire il software senza trasferirlo su 11.0 quando:
•
Si desidera semplificare il processo di transizione.
•
Si desidera usare un unico eseguibile sia per HP-UX 10.x sia per
HP-UX 11.0.
•
Il software non è una libreria (di solito, le versioni native delle librerie
sono necessarie per le prestazioni ottimali).
•
Non occorre ricompilare il software con il nuovo compilatore
ANSI C++.
•
Il software non usa sigcontext, che dipende dalla macchina e
pertanto non è portatile.
Quando trasferire il software su HP-UX 11.0
Il trasferimento del software e la ricompilazione comporta dello sforzo,
dato che si realizzano modifiche della sorgente e si ricompila su
HP-UX 11.0.
Spostare la sorgente del software alla release 11.0 di HP-UX è utile per
molti motivi: per trarre vantaggio dalle nuove funzionalità tipo la
capacità a 64 bit, per conformarsi agli standard industriali e ridurre i costi
di manutenzione. Il kit di transizione software (STK) è stato progettato
per aiutare gli sviluppatori di applicazioni o librerie cui occorra eseguire
la transizione del software da HP-UX 10.x ad HP-UX 11.0. I documenti e
gli strumenti contenuti nel STK semplificheranno il processo di
transizione. Per ulteriori informazioni, consultare “Quali strumenti di
transizione STK sono disponibili?” a pagina 461.
Nel caso in cui si verifichi una qualsiasi delle seguenti condizioni, occorre
trasferire il software:
Capitolo 4
•
Occorre un binario a 64 bit.
•
La prima preoccupazione è di eseguire il software su HP-UX 11.0 con
prestazioni ottimali.
•
Non occorre un unico binario sia per HP-UX 10.x sia per 11.0.
•
Il software è una libreria Dato che le applicazioni di HP-UX 11.0
possono collegarsi soltanto alle librerie di HP-UX 11.0 della stessa
dimensione della denominazione, occorre fornire sia la versione della
libreria a 32 bit sia quella a 64 bit di HP-UX 11.0.
•
Occorre ricompilare il software con il nuovo compilatore ANSI C++.
459
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
•
Il software usa sigcontext, che dipende dalla macchina e non è
portatile.
Documentazione per la transizione del software ad HP-UX 11.0
Hewlett-Packard ha fornito varie risorse come aiuto alla transizione del
software ad HP-UX 11.0.
•
HP-UX 64-bit Porting and Transition Guide
Questa guida fornisce una discussione dettagliata sui problemi di
programmazione impliciti nel trasferimento del software ad
HP-UX 11.0. Essa descrive le modifiche necessarie per realizzare la
compilazione, il collegamento e l’esecuzione dei programmi su un
sistema operativo a 64 bit. Consultare
/opt/ansic/newconfig/RelNotes/64bitTrans.bk.ps,
/opt/aCC/newconfig/TechDocs/64bitTrans.bk.ps o il CD-ROM
Instant Information.
•
HP-UX 11.x Software Developer’s Guide
Questa white paper, disponibile da http://docs.hp.com, indirizza a
varie funzionalità e vantaggi dalla migrazione delle applicazioni ad
HP-UX 11.0.
•
Kit di transizione software (KTS)
L’STK fornisce le informazioni sull’impatto dell’elaborazione a 64 bit,
sulla transizione e lo sviluppo in un ambiente a 64 bit, su quali
strumenti di transizione siano disponibili per realizzare una
transizione senza problemi e le informazioni sulla compatibilità.
L’STK è disponibile sul CD-ROM HP-UX 11.0 Application Release, o
attraverso il WorldWide Web all’indirizzo
http://www.software.hp.com/STK.
•
Scanner dello script HP-UX
È disponibile un nuovo strumento, /usr/sbin/scanscript, per
aiutare a localizzare e risolvere eventuali funzionalità modificate od
obsolete degli script di installazione o della shell. scanscript può
essere di aiuto nello stabilire se gli script contengano eventuali
comandi, percorsi, librerie che occorre modificare. Per ulteriori
informazioni, consultare la manpage scanscript (1M).
460
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Quali strumenti di transizione STK sono disponibili?
Nel Kit di transizione software (STK) sono forniti due strumenti per
aiutare ad identificare il codice nei file sorgente che potrebbero provocare
problemi di compatibilità.
•
Strumento scansummary
Questo strumento fornisce un quadro complessivo del numero e dei
tipi di problemi API di transizione dei file sorgente. L’output aiuta a
stabilire, in generale, la quantità di lavoro necessaria a trasferire i file
sorgente alla release più recente di HP-UX ed è utile quando si
pianifica una transizione.
•
Strumento scandetail
Questo strumento offre un quadro dettagliato dei problemi di
transizione API, indicando esattamente quali impatti API si
verificano su ogni riga dei file sorgente.
Per ogni problema rilevato da questi strumenti, è disponibile una pagina
degli impatti dettagliata che descrive il problema e le eventuali modifiche
dei file sorgente.
Per una descrizione esaustiva su come usare questi strumenti, consultare
il Kit di transizione software (STK) disponibile sul CD-ROM HP-UX 11.0
Application Release, o attraverso il World-Wide Web all’indirizzo
http://www.software.hp.com/STK.
Scambio di dati tra applicazioni a 32 bit ed a 64 bit
Esistono dei possibili problemi di interoperabilità tra applicazioni a 32 bit
ed a 64 bit in conseguenza di diverse definizioni dei dati tra i due tipi di
applicazioni. La stessa definizione di una struttura dati differisce nelle
dimensioni per un’applicazione a 32 bit ed a 64 bit ed i campi dati si
trovano su un offset diverso. Se si pensa di far scambiare dei dati tra
applicazioni a 32 bit ed a 64 bit, allora occorrerà modificare il codice
sorgente dell’applicazione a 32 bit. Per una discussione completa,
consultare il Kit di transizione software e la HP-UX 64-bit Porting and
Transition Guide.
Capitolo 4
461
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Uso di ‘pipe’ tra applicazioni a 32 bit ed a 64 bit
È possibile scambiare dati tra applicazioni a 32 bit ed a 64 bit attraverso
i ‘pipe’. Non esiste limitazione alcuna nell’uso di ‘pipe’ come mezzo di
comunicazione tra applicazioni a 32 bit ed a 64 bit. Tuttavia, quando si
usano i ‘pipe’ come mezzo di comunicazione tra due tipi di processi, occorre
prendere in considerazione le dimensioni dei dati.
Se l’applicazione a 64 bit sta scambiando dati con un’applicazione a 32 bit
attraverso ‘pipe’, occorre tener presente le dimensioni e l’allineamento dei
dati scambiati. Quale esempio semplice, prendere in considerazione
un’applicazione a 64 bit da stdin ed un’applicazione a 32 bit che scrive su
stdout. Quando l’output di un’applicazione a 32 bit è collegato attraverso
‘pipe’ all’applicazione a 64 bit, occorre assicurarsi che i tipi di dati scritti
e letti rispettivamente dalle due applicazioni hanno le stesse dimensioni
ed allineamento.
Compatibilità di file di grandi dimensioni
I file di grandi dimensioni (superiori a 2 GB) sono supportati sulle release
10.20 e superiore di HP-UX. Per supportare file di grandi dimensioni sul
sistema, occorre abilitare in modo esplicito un file system di grandi
dimensioni (per ulteriori informazioni, consultare “Gestione di file di
grandi dimensioni” a pagina 664).
Quando si lavora con file di grandi dimensioni, tener presenti i seguenti
problemi:
•
Non è possibile realizzare editing interattivo su file di grandi
dimensioni. Ad esempio, se si tenta di eseguire vi su un file di grandi
dimensioni, comparirà il seguente messaggio di errore:
#vi large_file
"large_file" Value too large to be stored in data type
•
Non è possibile inviare un file di grandi dimensioni per posta
elettronica.
•
Non è possibile stampare un file di grandi dimensioni.
Le seguenti figure illustrano come le applicazioni interagiscono con i file
di grandi dimensioni sui sistemi operativi a 32 bit ed a 64 bit.
462
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Figura 4-2
Sistema operativo a 32 bit e file di grandi dimensioni
HP-UX 10.30 ed HP-UX 10.20
hp
Hewlett
Packard
Sistema operativo a 32 bit
Applicazioni a 32 bit
File < 2GB
Applicazioni a 32 bit
NON abilitate per
file di grandi
dimensioni
Applicazioni a 32 bit
abilitate per file
di grandi dimensioni
File < 2GB
File > 2GB
nessun file system
di grandi dimensioni
file system di
grandi dimensioni
Nota: se un'applicazione a 32 bit non abilitata per file
di grandi dimensioni si imbatte in un file di grandi dimensioni,
restituirà un errore sulle chiamate stat e call.
Capitolo 4
463
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Figura 4-3
Sistema operativo a 64 bit e file di grandi dimensioni
HP-UX 11.00 (OS versione a 64 bit)
hp
Hewlett
Packard
Sistema operativo a 64 bit
Applicazioni a 32 bit
NON abilitate per
file di grandi dimensioni
Applicazioni a 32 bit
abilitate per file
di grandi dimensioni
Applicazioni a 64 bit che
gestiscono automaticamente
file di grandi dimensioni
File < 2GB
File > 2GB
file system di grandi dimensioni
Nota: se un'applicazione a 32 bit non abilitata per file
di grandi dimensioni si imbatte in un file di grandi dimensioni,
restituirà un errore sulle chiamate stat e call.
464
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Per configurare il supporto di file di grandi
dimensioni con NFS
Per configurare il supporto di file di grandi dimensioni su NFS, sia il client
NSF sia il server NFS devono supportare NFS PV3.
Sul server NFS, inserire comandi simili ai seguenti.
•
Per creare un nuovo file system con file di grandi dimensioni abilitato,
inserire un comando come:
/usr/sbin/newfs -F hfs -o largefiles /dev/vg02/rlvol
oppure:
/usr/sbin/newfs -F vxfs -o largefiles /dev/vg02/rlvol1
•
Per montare il file system con file di grandi dimensioni abilitato,
inserire:
mount -o largefiles /dev/vg02/rlvol /mnt
•
Per esportare un file system, che è stato abilitato per file di grandi
dimensioni, inserire:
exportfs -i /mnt
Sul client NFS, inserire:
mount [-o vers=3]
nome_host-remoto:/mnt /mnt
Supporto di file di grandi dimensioni e compatibilità
del protocollo NFS
Le vecchie versioni di HP-UX eseguivano la vecchia versione del protocollo
NFS. Il protocollo NFS versione 3 (PV3) supporta file di grandi dimensioni
(superiori a 2 GB), ma il protocollo versione 2 (PV2) non supporta file di
grandi dimensioni su file system montati. Pertanto, potrebbero insorgere
dei problemi di compatibilità con riguardo al supporto dei file di grandi
dimensioni in un ambiente misto, ove sistemi diversi eseguano versioni
diverse di HP-UX. Se si ha un ambiente che mescola sistemi che eseguono
sia NFS PV2 sia PV3, consultare la seguente tabella, che illustra i
problemi di compatibilità che potrebbero insorgere.
Capitolo 4
465
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Tabella 4-3
Compatibilità del protocollo NFS e supporto di file di grandi
dimensioni
Tipo di sistema
(opzione mount)
Client
PV2
Client
PV2/PV3
default
Client PV2/PV3
opzione
mount
-o vers=2
Client PV2/PV3
opzione
mount
-o vers=3
Client
non HP
PV2/PV3
Server HP -PV2
(HP-UX 10.20 o
precedente)
PV2
PV2a
PV2a
PV2a
PV2
Server HP - PV2/PV3
(HP-UX 10.20 o
successivo)
PV2a
PV3a b
supporto di
file di
grandi
dimensioni
PV2c d
PV3e b
supporto di file
di grandi
dimensioni
PV3e
supporto di
file di grandi
dimensioni
PV2
PV3e b
PV2a
PV3e b
PV3e
PV2
PV3b
supporto di
file di
grandi
dimensioni
PV2a
PV3b supporto
di file di grandi
dimensioni
PV3
supporto
di file di
grandi
dimensioni
opzione mount
-o largefiles
Server HP - PV2/PV3
(HP-UX 10.20 o
successivo)
opzione mount
-o nolargefiles
Server non HP - PV2/PV3
a. Il client PV2 HP-UX restituisce un errore [EFBIG] se il file richiesto è > 2 GB-1.
b. Il client PV3 HP-UX restituisce un errore [EFBIG] se il file richiesto è di dimensioni
maggiori di quelle massime consentite del file system remoto.
c. Il server PV2 HP-UX restituisce un errore [NFSERR_FBIG] se si incontra un file di
grandi dimensioni (su chiamate getattr(), setattr(), lookup(), read(), write()
e create()).
d. Il client PV2 HP-UX PV2 mappa [NFSERR_FBIG] su [EOVERFLOW] nei casi in cui si
incontri un file di grandi dimensioni remoto.
e. Il server PV3 HP-UX restituisce [NFS3ERR_FBIG] se la richiesta (read(), write(),
o create()) supera le dimensioni massime supportate del file system HFS/JFS
sottostante.
466
Capitolo 4
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
Per stabilire quali versioni di protocollo siano in esecuzione sugli NFS
client e server:
Sul client, usare il comando nfsstat -m. Ciò visualizza la versione NFS
per ogni punto di montaggio sul client. Ad esempio, l’output
/winona
Flags: vers=2
indica NFS PV2. Sul server, usare il comando rpcinfo -p | grep -iE
“service|NFS”. Ciò visualizza le versioni NFS disponibili sul server.
Ad esempio, l’output
program vers proto
100003
2
udp
100003
3
udp
150001
1
udp
150001
2
udp
150001
1
tcp
150001
2
tcp
port
2049
2049
719
719
720
720
service
nfs
nfs
pcnfsd
pcnfsd
pcnfsd
pcnfsd
indica che il server può servire sia NFS PV2 sia NFS PV3.
Capitolo 4
467
Configurazione di un gruppo di lavoro
Compatibilità tra HP-UX Release 10.x ed 11.x
468
Capitolo 4
Amministrazione di un sistema: Avvio e spegnimento
5
Amministrazione di un sistema:
Avvio e spegnimento
Questa sezione contiene le informazioni su quanto segue:
•
❏
“La sequenza di avvio: Avvio di un sistema HP-UX” a pagina 470
❏
“Avvio di HP-UX nei server HP Integrity: dettagli e varianti” a
pagina 471
❏
“Avvio di HP-UX nei sistemi HP 9000 (PA-RISC): dettagli e
varianti” a pagina 492
❏
“Velocizzazione dell’avvio: SpeedyBoot” a pagina 506
•
“Impostazione delle informazioni iniziali sul sistema” a pagina 517
•
“Personalizzazione dell’avvio e dello spegnimento” a pagina 519
•
“Spegnimento dei sistemi” a pagina 524
•
Capitolo 5
“Avvio dei sistemi” a pagina 470
❏
“Panoramica dei processi di spegnimento” a pagina 524
❏
“Tipi di spegnimento” a pagina 526
❏
“Considerazioni speciali per lo spegnimento di alcuni sistemi” a
pagina 532
❏
“Evitare uno spegnimento quando possibile” a pagina 535
“Spegnimenti anomali del sistema” a pagina 536
❏
“Panoramica del ciclo copiatura / salvataggio” a pagina 537
❏
“Preparazione ad un crash di sistema” a pagina 538
❏
“Che cosa succede quando il sistema subisce un crash” a
pagina 555
❏
“Che cosa fare quando il sistema si è riavviato” a pagina 558
469
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Avvio dei sistemi
Quando si accende (o si riavvia) il computer, occorre inizializzare
l’hardware, il firmware ed il software secondo una sequenza attentamente
orchestrata di eventi, detta sequenza di avvio.
La sequenza di avvio: Avvio di un sistema HP-UX
I sistemi su base HP-UX, quando li si accende o li si riavvia, effettuano la
seguente sequenza:
1. Le routine hardware e firmware della scheda, processori e schede I/O
eseguono i test e inizializzano quegli oggetti oltre ad inizializzare
memoria RAM sufficiente a proseguire la fase di avvio. Inoltre,
rilevano ed inizializzano le comunicazioni con la tastiera e per la
visualizzazione della console ed un dispositivo di avvio.
2. Le routine firmware/software di pre-avvio caricano ed eseguono il
caricatore di avvio HP-UX.
3. Il caricatore di avvio HP-UX:
•
Individua, apre e legge il file della kernel e copia in memoria la
kernel
•
Inizializzazione della kernel HP-UX
4. HP-UX porta a termine il suo processo di inizializzazione e inizia il
suo normale funzionamento.
NOTA
Il sistema operativo HP-UX è attualmente in grado di funzionare in due
piattaforme hardware:
Sistemi HP 9000:
utilizza la famiglia di processori PA-RISC
Server HP Integrity:
utilizza la famiglia di processori Itanium
Un server HP Integrity utilizza Extensible Firmware Interface (EFI).
Se il proprio sistema,al termine dei test firmware iniziali, visualizza il
boot manager EFI, si ha a che fare con un server HP Integrity.
Se si sta avviando un server HP Integrity, vedere “Avvio di HP-UX nei
server HP Integrity: dettagli e varianti” a pagina 471.
Se si sta avviando un sistema PA-RISC, vedere “Avvio di HP-UX nei
sistemi HP 9000 (PA-RISC): dettagli e varianti” a pagina 492.
470
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Avvio di HP-UX nei server HP Integrity: dettagli e
varianti
“La sequenza di avvio: Avvio di un sistema HP-UX” a pagina 470 descrive
la normale sequenza di eventi che solitamente ha luogo quando si accende
o si riavvia un HP Integrity. Questa sezione tratta più approfonditamente
il processo di avvio, in quanto ci sono situazioni in cui sarà necessario
controllare manualmente il processo di avvio; ad esempio:
•
Quando occorre avviare il sistema da un dispositivo diverso da quello
da cui si avvia normalmente.
•
Quando occorre avviare il sistema da un file della kernel diverso da
quello da cui si avvia normalmente.
•
Quando occorre avviare il sistema in modalità utente singolo, per
assicurarsi che le procedure speciali che si stanno eseguendo non
siano influenzate da altri utenti del sistema.
•
Quando occorre avviare il sistema in modalità Manutenzione LVM
per correggere un problema relativo ai volumi logici del computer o ai
gruppi di volume.
•
Quando si sta installando, o eseguendo l’aggiornamento ad una nuova
release di HP-UX.
Segue l’esame dettagliato del processo di avvio e di alcune sue varianti.
ATTENZIONE
La configurazione ACPI per HP-UX deve essere quella predefinita nei
server HP Integrity nPartizionabili
HP-UX non si avvierà nei sistemi compatibili con nPartition se il valore
della configurazione ACPI non è impostato come “DEFAULT”.
Per controllare la configurazione ACPI corrente, nell’interfaccia della
shell EFI digitare acpiconfig senza argomenti. Se il valore di
acpiconfig non è impostato come default, HP-UX non potrà avviarsi;
in tal caso sarà necessario riconfigurare acpiconfig, altrimenti la
procedura di avvio sarà interrotta da un panico all’avvio della kernel
HP-UX.
Per impostare la configurazione ACPI per HP-UX: nell’interfaccia della
shell EFI digitare il comando acpiconfig default, quindi digitare il
comando reset per riavviare la nPartition con la configurazione corretta
(default) per HP-UX.
Capitolo 5
471
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Avvio standard
Di seguito si trovano maggiori dettagli su ciò che avviene durante la
normale sequenza di avvio di HP-UX in un server HP Integrity.
Punto
1. Alimentazione dei dispositivi esterni: Se necessario, avviare tutte le
periferiche ed i dispositivi esterni collegati al computer (ad esempio, unità
disco, unità a nastro, stampanti, terminali, convertitori di bus).
Una volta terminati i test automatici dei dispositivi, procedere al
passaggio successivo.
Punto
2. Accensione del sistema (o nPartition): Accensione o riavvio del
computer o nPartition.
L’hardware di sistema (oppure quello associato alla nPartition) effettuerà
una serie di test automatici per verificare che i processori, la memoria e
altre componenti del sistema siano in funzione.
Punto
3. Scelta del di dispositivo di avvio: Il sistema (o la nPartition che si sta
avviando) deve individuare il file della kernel da cui eseguire l’avvio.
Esistono due fasi della ricerca:
Fase 1
stabilire il percorso hardware del dispositivo di avvio
Fase 2
stabilire quale file della kernel avviare dal percorso
hardware (vedere fase 4)
Le variabili del percorso archiviate nella memoria non volatile impostano
fino a tre percorsi possibili dai quali tentare l’avvio:
PRI
Il percorso di avvio PRImario è il primo da tentare.
Impostare il valore di questo percorso in modo da
puntare al dispositivo da cui si esegue l’avvio più
frequentemente.
HAA
Il percorso di avvio High-Availability Alternate è il
percorso alternativo da utilizzare nel caso che il sistema
non riesca ad avviarsi usando quello primario.
ALT
Il percorso di avvio ALTernativo è il percorso hardware
ad un’unità di avvio alternativa (ad esempio, un’unità a
nastro, un’origine di rete o un’unità a dischi ottici).
Nei server HP Integrity, il percorso di avvio PRI è quello utilizzato
durante l’avvio automatico. È possibile ignorare l’avvio automatico
interrompendo la fase di avvio prima della scadenza di AUTOBOOT DELAY.
472
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Se l’avvio automatico dal percorso primario (la prima voce nell’elenco
delle opzioni di avvio) non fosse possibile, sarà necessario scegliere
manualmente un percorso nel menu di EFI Boot Manager.
I dischi di avvio dei server HP contengono una speciale partizione
chiamata partizione EFI. La partizione EFI, derivata dal filesystem FAT
comunemente utilizzato nei PC, contiene delle applicazioni EFI che
possono essere eseguite prima dell’inizializzazione di HP-UX. Una di
queste applicazioni, EFI boot manager, sarà eseguita automaticamente,
che a sua volta eseguirà il caricatore di avvio di HP-UX, hpux.efi
(un’altra applicazione EFI).
Un diagramma ed una descrizione sintetica della struttura dei dischi
contenenti delle partizioni EFI è disponibile in “Eseguire il mirroring di
un disco di avvio con LVM con HP-UX 11i per server HP Integrity” a
pagina 643
NOTA
Punto
4. Selezione del file della kernel: Selezionato il dispositivo di avvio, sarà
inizializzato il caricatore di avvio specifico di HP-UX, hpux.efi.
hpux.efi utilizza il contenuto del file AUTO che si trova nel dispositivo di
avvio selezionato per individuare il file della kernel per l’avvio.
In genere, il file AUTO contiene:
boot vmunix
che indica a hpux.efi di caricare la kernel dal file di nome vmunix dal
filesystem predefinito (/stand) -- il file /stand/vmunix.
Punto
5. Caricamento ed inizializzazione del sistema operativo HP-UX:
hpux.efi quindi apre e carica in memoria la kernel HP-UX e la
inizializza.
Punto
6. HP-UX porta a termine il suo processo di inizializzazione e inizia
il suo normale funzionamento.
Avvio automatico ed avvio manuale
Che il proprio sistema avvii automaticamente (con l’opzione di avvio
senza alcun intervento in caso di guasto o di altre situazioni inattese
all’avvio) o che richieda l’intervento manuale, dipende da vari fattori, i più
importanti dei quali sono:
Capitolo 5
473
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
•
l’impostazione del flag autoboot in memoria non volatile
•
la presenza del file AUTO nella partizione EFI del dispositivo di avvio
selezionato
•
se si è scelto di avviare dal dispositivo di avvio primario del sistema
•
la disponibilità del dispositivo di avvio (o di quello alternativo ad alta
disponibilità)
Di solito, il percorso di avvio primario punta al dispositivo che si utilizza
più di frequente, e questo è disponibile. Se è stato abilitato il flag
autoboot, il sistema si avvierà automaticamente dal dispositivo di avvio
selezionato (dopo un periodo di timeout preimpostato).
autoboot on
Se il flag autoboot è impostato come on, hpux.efi
cercherà di eseguire l’avvio utilizzando le voci
dell’elenco delle opzioni di avvio, nell’ordine specificato.
Leggerà il file \EFI\HPUX\AUTO nel filesystem EFI nel
primo dispositivo disponibile contenente un file AUTO.
hpux.efi utilizza il contenuto di AUTO per individuare il
file della kernel da caricare e stabilire quali opzioni di
avvio (se presenti) utilizzare. Quindi carica ed
inizializza la kernel.
Nel caso che non sia individuato alcun file AUTO, la
procedura di avvio si arresterà al caricamento di
hpux.efi (sarà visibile il prompt HPUX>) e sarà possibile
avviare manualmente HP-UX oppure eseguire altre
operazioni.
autoboot off
Se il flag di autoboot è impostato come off la procedura
di avvio si arresterà al EFI Boot Manager dal quale sarà
possibile avviare manualmente HP-UX oppure eseguire
altre operazioni.
Evitare l’avvio automatico Se è stato abilitato il flag autoboot nella
memoria non volatile del proprio sistema o nPartition, questo cercherà,
dopo un dato tempo, di avviarsi automaticamente. Per impostazione
predefinita, il periodo di attesa di avvio è di 10 secondi; è comunque
possibile modificare questo valore.
Per evitare l’avvio automatico, premere un tasto qualsiasi (ad esempio la
barra spaziatrice) prima che scada il tempo impostato. Invece di
proseguire con l’avvio automatico, il sistema o nPartition consentirà di
interagire con EFI Boot Manager.
474
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
È possibile evitare l’avvio automatico e interagire manualmente con EFI
Boot Manager per:
•
Specificare un dispositivo di avvio (diverso da quello usato
automaticamente)
•
Specificare un file della kernel di avvio (diverso da quello usato
automaticamente)
•
Visualizzare o regolare le impostazioni di avvio del sistema
A questo punto, è possibile scegliere il dispositivo di avvio utilizzando le
opzioni fornite dal menu principale di EFI Boot Manager, oppure
interagire con la shell di EFI per avviare il sistema.
Uso della shell EFI per avviare manualmente il sistema Per usare
shell EFI per avviare manualmente il sistema:
Avvio dalla shell EFI
Punto
1. Accedere alla shell EFI
Dalla console di sistema, per accedere alla shell, dal menu di EFI Boot
Manager utilizzare i tasti direzione su/giù per selezionare la voce
“EFI Shell”.
Punto
2. Accedere alla partizione di sistema EFI del dispositivo di avvio
HP-UX.
Utilizzare il comando map della shell EFI per elencare i filesystem (fs0,
fs1 e così via) che sono noti e stati assegnati.
Per scegliere il filesystem da usare, specificare il nome assegnato seguito
da due punti (:). Ad esempio, per operare con il dispositivo di avvio
assegnato come fs0, digitare fs0: al prompt della shell EFI. Premendo
INVIO per completare il comando, il prompt della shell sarà modificato per
riflettere la selezione del dispositivo: (fs0:\>)
Punto
3. Digitare HPUX al prompt della shell EFI per eseguire il loader
HPUX.EFI.
Se necessario, è possibile specificare il percorso completo del loader
digitando \EFI\HPUX\HPUX al prompt dei comandi della shell EFI.
Punto
Capitolo 5
4. Consentire al loader HPUX.EFI di procedere con il comando boot
specificato nel file AUTO, oppure specificare manualmente il
comando boot.
475
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Per impostazione predefinita, il loader HPUX.EFI esegue l’avvio
utilizzando i comandi che si trovano nel file \EFI\HPUX\AUTO nella
partizione di sistema EFI del dispositivo di avvio selezionato. Il file AUTO
in genere contiene il comando boot vmunix.
Per interagire con il loader HPUX.EFI, interrompere la procedura di avvio
(ad esempio, premendo spazio) entro il periodo di tempo fornito dal loader.
Per uscire dal loader, usare il comando exit.
Impostazione del periodo di attesa dell’avvio automatico Per
impostazione predefinita, l’attesa dell’avvio automatico è di 10 secondi. È
possibile modificare questo valore:
Esempio 5-1
Impostazione del periodo di attesa dell’avvio automatico con le
opzioni di avvio di EFI Boot Manager:
1. Nel menu principale del gestore di avvio, scegliere “Boot Option
Maintenance Menu”
2. Nel menu boot option maintenance, scegliere “Auto Boot TimeOut”
3. Selezionare “Set TimeOut Value”
4. Specificare il numero di secondi desiderati per il periodo di attesa di
avvio (ad esempio, 30).
Esempio 5-2
Impostazione del periodo di attesa dell'avvio automatico con il
comando autoboot della shell EFI:
Per impostare a 30 secondi il periodo di attesa di autoboot, utilizzare il
comando della shell EFI:
autoboot 30
Abilitazione/Disabilitazione dell’avvio automatico Il valore del
flag autoboot può essere impostato o modificato in vari modi:
Esempio 5-3
Attivazione dell'avvio automatico (utilizzando il comando
autoboot della shell EFI)
Shell> autoboot on
Esempio 5-4
Disattivazione dell’avvio automatico (utilizzando il comando
autoboot della shell EFI)
Shell> autoboot off
476
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Esempio 5-5
Attivazione dell’avvio automatico (utilizzando setboot da un
sistema HP-UX in esecuzione)
/usr/sbin/setboot -b on
Esempio 5-6
Disattivazione dell’avvio automatico (utilizzando setboot da un
sistema HP-UX in esecuzione)
/usr/sbin/setboot -b off
Avvio da un’origine alternativa
Esistono casi in cui sarà necessario avviare da un dispositivo diverso da
quello da cui si avvia normalmente. Ad esempio, se il disco di avvio
primario non funziona, sarà necessario avviare il sistema da un disco
diverso o da un nastro di recupero.
Avvio da un dispositivo alternativo È possibile eseguire l’avvio da
un dispositivo alternativo nei modi seguenti. Se il proprio sistema è
impostato per avviarsi automaticamente, sarà necessario interrompere la
sequenza di avvio automatico premendo un tasto qualsiasi della tastiera
durante il periodo di attesa (time-out).
❏
Se il dispositivo di avvio alternativo che si desidera utilizzare è
elencato nel menu delle opzioni di avvio (il menu principale di EFI
Boot Manager), utilizzare i tasti direzione per evidenziare il
dispositivo alternativo, quindi, per avviare da quel dispositivo,
premere INVIO
❏
Se il dispositivo di avvio alternativo che si desidera utilizzare non è
elencato nel menu delle opzioni di avvio:
Punto
1. Scegliere “EFI Shell [Built-in]” nel menu delle opzioni di avvio per
eseguire la shell EFI.
Punto
2. Digitare map al prompt della shell EFI per elencare i dispositivi di avvio
del proprio sistema.
I dispositivi saranno così elencati. Cercare le voci che iniziano con fs#:
(dove # è un numero come 0, 1, 2, 3, ecc.).
Punto
3. Stabilire quale voce è assegnata al dispositivo da cui si desidera eseguire
l’avvio e digitarne il nome fs#: al prompt della shell.
Ad esempio, se la voce del dispositivo desiderato è etichettata come
“fs0:”, digitare fs0: al prompt della shell:
Capitolo 5
477
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Shell> fs0:
Il dispositivo associato alla voce fs0: è ora il dispositivo di avvio
selezionato. Il prompt della shell EFI sarà modificato di conseguenza.
Punto
4. Digitare hpux per avviare il caricatore di avvio. Il caricatore di avvio
(hpux.efi) sarà ora eseguito ed utilizzerà il file AUTO del dispositivo
selezionato per stabilire quale file della kernel usare.
Avvio da un file della kernel alternativo Il nome del file della
kernel predefinito (e quello solitamente utilizzato) è vmunix. Il file AUTO
nella partizione EFI di un dispositivo di avvio contiene in genere la voce:
“boot vmunix” che punta al file vmunix nel filesystem /stand nel
dispositivo di avvio selezionato.
Eseguendo normalmente l’avvio dal file della kernel /stand/vmunix ma,
ad esempio, dovendo temporaneamente eseguire l’avvio da un file della
kernel alternativo, seguire questa procedura sostituendo il nome del
proprio file della kernel al posto di testvmunix:
Punto
1. Se il proprio sistema si avvia automaticamente, interrompere la sequenza
di avvio automatico premendo un tasto qualsiasi della tastiera durante il
periodo di attesa (time-out).
Punto
2. Scegliere EFI Shell [Built-in] nel menu delle opzioni di avvio per
eseguire la shell EFI.
Punto
3. Assicurarsi che il dispositivo di avvio selezionato sia quello che contiene il
file della kernel che si desidera utilizzare. In caso di dubbi:
a. Digitare map al prompt della shell EFI per elencare i dispositivi di
avvio del proprio sistema.
I dispositivi saranno elencati in voci che iniziano con fs#: (dove # è un
numero come 0, 1, 2, 3, ecc.). Ad esempio:
fs0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88F40A3A-B992-11E1-8002-D6217B60E588)
fs1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part3,Sig88F40A9E-B992-11E1-8004-D6217B60E588)
blk0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
blk1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A3A-B992-11E1-8002-D6217B60E588)
blk2 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A6C-B992-11E1-8003-D6217B60E588)
blk4 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Secondary,Master)
478
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
b. Stabilire quale voce è assegnata al dispositivo contenente il file della
kernel con cui si desidera eseguire l’avvio e digitarne il nome fs#: al
prompt della shell.
Ad esempio, se la voce del dispositivo desiderato è etichettata come
“fs7:”, digitare fs7: al prompt della shell:
Shell> fs7:
Il dispositivo associato alla voce fs7: è ora il dispositivo di avvio
selezionato.
Punto
4. Al prompt della shell, digitare il comando hpux e prepararsi ad
interrompere la sequenza di avvio automatico (sempre premendo un tasto
qualsiasi della tastiera) nel caso sia visualizzato un timer che indica
quanto manca all’inizio dell’avvio automatico.
Se il file AUTO nel dispositivo di avvio ora selezionato avvierà il sistema dal
file della kernel alternativo desiderato, non sarà necessario interrompere
questa seconda procedura di avvio automatico. Altrimenti, interrompere
l’avvio automatico.
NOTA
Punto
5. Se nella fase precedente si è interrotto l’avvio automatico, ci si troverà ora
nel caricatore di avvio di HP-UX; il prompt dovrebbe essere “HPUX>”.
Al prompt del caricatore di avvio, digitare il comando boot nome_file dove
nome_file è il nome del file della kernel da cui eseguire l’avvio.
Esempio 5-7
Eseguire l’avvio dal file della kernel alternativo di nome
testvmunix
HPUX> boot testvmunix
Modica dei percorsi di avvio PRI, HAA e ALT
Nei server HP Integrity, i percorsi di avvio primario, alternativo ad alta
disponibilità ed alternativo sono basati rispettivamente sulla prima,
seconda e terza voce dell’elenco delle opzioni di avvio del server.
È possibile gestire i percorsi di avvio quando HP-UX è in esecuzione,
utilizzando il comando setboot, oppure in EFI Boot Manager utilizzando
“Boot Option Maintenance Menu”.
Capitolo 5
479
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Impostazione dei percorsi di avvio PRI, HAA e ALT con il
comando setboot di HP-UX: Quando si utilizza setboot per
configurare la prima (PRI), la seconda (HAA) o la terza (ALT) voce
dell’elenco delle opzioni di avvio, il nuovo percorso del dispositivo
specificato sostituisce l’opzione di avvio originale, oppure è inserita al suo
posto (e la voce originale spostata verso il fondo dell’elenco delle opzioni di
avvio):
❏
Nel caso che l’opzione di avvio non sia attualmente impostata ad un
dispositivo HP-UX, il nuovo percorso di avvio sarà inserito come
nuova voce nell’elenco delle opzioni di avvio.
In tal caso, la voce originale dell’elenco, se presente, sarà spostata
verso il fondo dell’elenco delle opzioni di avvio ed il nuovo dispositivo
di avvio diventerà la prima (PRI), la seconda (HAA) o la terza (ALT) voce
dell’elenco, così come specificato da setboot.
❏
Nel caso l’opzione di avvio sia correntemente impostata ad un
dispositivo HP-UX e la voce dell’elenco ha la descrizione standard (ad
esempio, “HP-UX Primary Boot for PRI” oppure “HP-UX Alternate
Boot for ALT”) il nuovo percorso del dispositivo di avvio sostituirà la
voce originale nell’elenco delle opzioni di avvio.
❏
Se l’opzione di avvio è correntemente impostata ad un dispositivo
HP-UX e la descrizione della voce è quella standard in base alla sua
posizione nell’elenco, la nuova impostazione sarà inserita nell’elenco
come nuova voce.
In tal caso la voce originale dell’elenco sarà spostata verso il fondo
dell’elenco delle opzioni di avvio.
NOTA
Il percorso del dispositivo di avvio specificato con il comando setboot
(percorso negli esempi seguenti) deve essere un percorso hardware di un
dispositivo di avvio HP-UX valido.
•
Per impostare il percorso di avvio primario, utilizzare il comando
setboot -p percorso, ad esempio:
/usr/sbin/setboot -p 0/0/2/0/0.6
•
Per impostare il percorso di avvio alternativo ad alta disponibilità,
utilizzare il comando setboot -h percorso, ad esempio:
/usr/sbin/setboot -h 0/0/0/3/1.6
•
Per impostare il percorso di avvio alternativo, utilizzare il comando
setboot -a percorso, ad esempio:
/usr/sbin/setboot -a 0/0/0/3/0.6
480
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Impostazione dei percorsi di avvio PRI, HAA e ALT con il menu
Boot Option Maintenance di EFI Boot Manager: È possibile
utilizzare il menu Boot Option Maintenance di EFI Boot Manager per
gestire i percorsi di avvio PRI, HAA e ALT: Occorre solamente ricordare
che:
PRI
Il percorso di avvio primario (PRI) corrisponde alla
prima opzione di avvio dell’elenco
HAA
Il percorso di avvio alternativo ad alta disponibilità
(HAA) corrisponde alla seconda opzione di avvio
dell’elenco
ALT
Il percorso di avvio alternativo (ALT) corrisponde alla
terza opzione di avvio dell’elenco
Nell’elenco delle opzioni di avvio è possibile avere più di tre voci. Le prime
tre corrispondono ai percorsi di avvio elencati prima. Le voci aggiuntive
potranno essere scelte manualmente dall’elenco durante un avvio
manuale.
NOTA
Punto
1. Nel menu principale di EFI Boot Manager, scegliere “Boot Option
Maintenance Menu”
Punto
2. Utilizzare le tre voci seguenti del menu Boot Option Maintenance per
modificare l’elenco delle opzioni di avvio in modo che rispecchino i
dispositivi del proprio sistema che si desidera utilizzare per i percorsi di
avvio PRI, HAA e ALT (oltre ai percorsi che si volesse aggiungere all’elenco):
Punto
Capitolo 5
Add a Boot Option
Visualizza l’elenco dei dispositivi di
avvio disponibili e consente di selezionarne uno da aggiungere all’elenco
Delete Boot Option(s)
Consente di eliminare in modo
interattivo una o più voci dall’elenco
delle opzioni di avvio
Change Boot Order
Consente di modificare l’ordine
dell’elenco delle opzioni di avvio
3. Quando l’elenco delle opzioni di avvio del proprio sistema è quello
desiderato, scegliere “Exit” per tornare al menu principale di EFI Boot
Manager (che dovrebbe riflettere le modifiche eseguite nell’elenco delle
opzioni di avvio).
481
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Modifica del contenuto del file AUTO in un dispositivo di avvio
Nei server HP Integrity, durante l’avvio automatico (ed in qualche avvio
manuale), per individuare il file della kernel da caricare, è adoperato il file
\EFI\HPUX\AUTO presente nel dispositivo di avvio utilizzato.
In genere, il file AUTO contiene “boot vmunix”. È possibile ignorare temporaneamente il contenuto del file AUTO, ad esempio, per avviare da un file
della kernel alternativo (Vedere “Avvio da un file della kernel alternativo”
a pagina 478), ma se si desidera eseguire l’avvio come impostazione predefinita dall’altro file della kernel, oppure si desidera utilizzare regolarmente alcune opzioni di avvio, sarà necessario modificare il contenuto del
file AUTO affinché rifletta le impostazioni desiderate.
Il file AUTO può specificare solamente il comando boot. Per eseguire altri
comandi del loader hpux.efi, sarà necessario interagire direttamente
con esso.
NOTA
Fondamentalmente, ci sono tre modi per modificare il contenuto del file
AUTO presente in un dispositivo. Due di questi possono essere portati a
termine solamente utilizzando l’ambiente di pre-avvio EFI. Il terzo può
essere realizzato mentre HP-UX è in esecuzione.
•
Modifica del file AUTO dalla shell EFI (pre-avvio)
•
Modifica di AUTO con il caricatore di avvio di HPUX.EFI (pre-avvio)
•
Modifica di AUTO da un ambiente HP-UX in esecuzione
Modifica del file AUTO dalla shell EFI (pre-avvio)
Questa operazione non può essere eseguita in un sistema con HP-UX in
esecuzione. Si presume che il sistema non sia stato ancora avviato. Se
fosse necessario modificare il contenuto del file AUTO di un dato dispositivo
mentre HP-UX è in esecuzione, vedere “Modifica di AUTO da un ambiente
HP-UX in esecuzione” a pagina 487.
Per elencare e configurare il file AUTO di un dispositivo di avvio HP-UX
dalla shell EFI, utilizzare i comandi della shell stessa (come cd, ls e
edit) per visualizzare e modificare il file EFI\HPUX\AUTO del dispositivo
selezionato.
Punto
482
1. Accedere all’ambiente della shell EFI utilizzando la console di
sistema del server (o della nPartition). Accedere alla console di sistema
tramite il management processor (MP) del server oppure tramite un
terminale della console collegato via hardware.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Se necessario, interrompere la procedura di avvio automatico premendo
un tasto durante il periodo di attesa. Il Boot Manager EFI visualizzerà il
menu delle opzioni di avvio (il menu principale EFI).
Dal menu delle opzioni di avvio, selezionare EFI Shell.
Punto
IMPORTANTE
2. Scegliere il dispositivo contenente il file AUTO che si desidera modificare.
Non saltare questa fase, in special modo quando si dispone di più dispositivi di avvio. Nei server HP Integrity ogni dispositivo di avvio ha un proprio file AUTO. Se non si seleziona il dispositivo contenente il file AUTO che
si desidera modificare, si modificherà un file AUTO in un altro dispositivo.
Per elencare tutti i filesystem attualmente assegnati, digitare map al
prompt della shell EFI:
Shell> map
Il comando map visualizza tutti i filesystem noti ed assegnati. Ad esempio:
fs0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88F40A3A-B992-11E1-8002-D6217B60E588)
fs1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part3,Sig88F40A9E-B992-11E1-8004-D6217B60E588)
blk0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
blk1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A3A-B992-11E1-8002-D6217B60E588)
blk2 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A6C-B992-11E1-8003-D6217B60E588)
blk4 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Secondary,Master)
Nell’elenco visualizzato, individuare la voce corrispondente al dispositivo
contenente il file AUTO che si desidera modificare. Esaminare le voci
dell’elenco che iniziano con la stringa fs#, dove # sarà un numero (ad
esempiofs0, fs1, fs2 ... e così via). Al prompt della shell EFI, digitare il
valore fs# del dispositivo desiderato seguito da due punti:
Shell> fs0:
Il dispositivo è ora selezionato ed il prompt della shell EFI cambierà di
conseguenza:
fs0:\>
Capitolo 5
483
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Andare nella directory dove si trova il file AUTO. Nel filesystem EFI
di ogni dispositivo di avvio HP-UX, il file AUTO si trova nella directory
\EFI\HPUX:
fs0:\> cd \EFI\HPUX
Il prompt cambierà nuovamente per indicare la nuova posizione:
fs0:\EFI\HPUX>
a. È possibile visualizzare il contenuto della directory con il comando ls:
fs0:\EFI\HPUX> ls
Directory of: fs0:\EFI\HPUX
06/03/04 03:31p <DIR>
512
06/03/04 03:31p <DIR>
512
06/03/04 03:35p
421,590
06/03/04 03:35p
24,576
06/03/04 03:35p
12
3 File(s)
446,196 bytes
2 Dir(s)
.
..
HPUX.EFI
NBP.EFI
AUTO
fs0:\EFI\HPUX>
b. È possibile visualizzare il contenuto corrente file AUTO con il comando
cat:
fs0:\EFI\HPUX> cat AUTO
FILE: fs0:\EFI\HPUX\AUTO, Size 12
boot vmunix
fs0:\EFI\HPUX>
Punto
3. Per modificare il contenuto del file AUTO è possibile utilizzare il
comando edit sfruttando l’editor a tutto schermo EFI, oppure utilizzare il
comando echo e reindirizzare il suo output al file AUTO:
•
Per utilizzare il comando edit, digitare edit AUTO, quindi configurare il
file AUTO utilizzando l’editor a tutto schermo.
Per salvare le modifiche fatte al file, secondo il sistema che si ha e
secondo che si stia utilizzando una console collegata direttamente
oppure un accesso di rete, premere il tasto “F2” oppure digitare Esc 2
(premere “Esc” quindi premere “2”). Per stabilire quale sequenza di
tasti utilizzare, usare i prompt su schermo dell’editor.
484
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Per uscire dall’editor EFI, premere il tasto “F3” (oppure premere Esc 3
secondo il proprio sistema come descritto nel paragrafo precedente).
•
Per configurare il file AUTO senza usare l’editor a tutto schermo,
utilizzare il comando echo:
fs0:\EFI\HPUX> echo boot testvmunix > auto
Il comando descritto prima sostituisce il contenuto precedente (se
esistente) del file AUTO con la stringa “boot testvmunix”. Sostituire il
nome del proprio file della kernel al posto di testvmunix dell’esempio.
Poiché la shell EFI (filesystem EFI) non è sensibile alle
maiuscole/minuscole, nell’esempio precedente “auto” e “AUTO” sono
considerati equivalenti.
NOTA
Come nelle shell HP-UX, nell’esempio precedente il carattere “>” fa sì che
l’output del comando echo sia reindirizzato verso il file “auto”. Se auto
esiste, il suo contenuto sarà sovrascritto. Se auto non esiste, esso sarà
creato e conterrà l’output del comando echo.
Punto
4. Controllo del nuovo contenuto del file AUTO. Per controllare che il
contenuto del file AUTO sia quello desiderato, utilizzare il comando
cat AUTO.
Modifica di AUTO con il caricatore di avvio di HPUX.EFI (pre-avvio)
Per elencare e configurare il file AUTO di un dispositivo di avvio HP-UX dal
loader HPUX.EFI utilizzare i comandi del loader showauto e setauto.
Punto
1. Accedere al loader HPUX.EFI del dispositivo di avvio che
contiene il file AUTO che si desidera configurare.
È possibile fare ciò eseguendo il loader dall’interfaccia della shell EFI,
oppure selezionando il dispositivo da EFI Boot Manager ed
interrompendo la procedura di avvio HP-UX per accedere al prompt
HPUX> del loader.
NOTA
Capitolo 5
Se si utilizza l’interfaccia della shell EFI, assicurarsi di selezionare il
dispositivo di avvio corretto prima di avviare il caricatore di avvio
HPUX.EFI, altrimenti si potrebbe modificare il file AUTO errato. Per i
dettagli su come selezionare il dispositivo corretto, vedere “Modifica del
file AUTO dalla shell EFI (pre-avvio)” a pagina 482.
485
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Punto
2. Al prompt HPUX> del caricatore di avvio HP-UX, eseguire il comando
showauto per visualizzare il contenuto corrente del file AUTO:
HPUX> showauto
\EFI\HPUX\AUTO => boot vmunix
HPUX>
Punto
3. Eseguire il comando setauto per eliminare o modificare il file AUTO.
•
setauto -d elimina il file AUTO dal dispositivo di avvio corrente.
Questo nel caso si desideri disattivare l’avvio automatico.
•
setauto stringa imposta il file AUTO in modo che contenga la stringa
specificata.
La stringa specificata deve essere nella forma del comando del loader
boot. Nel file AUTO non è permesso nessun’altro comando di HPUX.EFI.
boot
Specifica di avviare la kernel HP-UX
/stand/vmunix senza opzioni di avvio. Ad esempio:
setauto boot crea un file AUTO contenente
solamente il comando boot.
boot kernel
Specifica di avviare con una data kernel. Ad esempio: setauto boot testvmunix crea un file AUTO che
contiene solamente il comandoboot testvmunix.
boot opzione kernel
Specifica di avviare con un dato file della kernel
utilizzando una data opzione del loader. Ad esempio:
Il comando setauto boot -is vmunix crea un file
AUTO contenente boot -is vmunix (che indica di
eseguire l’avvio in modalità utente singolo, come
specificato dall’opzione -is).
Per maggiori dettagli sulle opzioni del loader, vedere
la manpage hpux (1M), che comprende la modalità
di manutenzione LVM (-lm), la modalità di
manutenzione VxVM (-vm), la modalità di
manutenzione dei parametri sintonizzabili (-tm) ed
altro.
Punto
486
4. Eseguire nuovamente il comando showauto per controllare la nuova
configurazione del file AUTO.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Modifica di AUTO da un ambiente HP-UX in esecuzione
La modifica del file AUTO di un dato dispositivo di avvio HP-UX da un
sistema operativo HP-UX in esecuzione è una procedura in tre fasi:
1. Copia del file AUTO dalla partizione EFI del dispositivo di avvio in un
file del filesystem HP-UX.
2. Modifica del contenuto del file AUTO per riflette le nuove impostazioni.
3. Copia del file AUTO modificato nella partizione EFI del dispositivo di
avvio.
Punto
1. Copiare il file AUTO dalla partizione EFI del dispositivo di avvio in un file
del filesystem HP-UX. Per fare ciò, utilizzare il comando efi_cp. Per i
dettagli, vedere efi_cp (1M). Ad esempio, se il filesystem EFI
rappresentato dal file del dispositivo /dev/rdsk/c1t4d0s1 contiene il file
AUTO che si desidera modificare, per copiare nella directory corrente il file
AUTO utilizzare il comando seguente:
efi_cp -d /dev/rdsk/c1t4d0s1 -u /EFI/HPUX/AUTO AUTO
IMPORTANTE
L’opzione -u del comando descritto sopra indica a efi_cp di copiare il file
AUTO dal filesystem EFI a quello di HP-UX. È come copiare il file in alto
dal livello inferiore dell’ambiente di pre-avvio EFI. Nella fase 3 di questa
procedura, il comando efi_cp, utilizzato senza l’opzione -u, copierà il file
AUTO modificato di nuovo nel filesystem EFI.
La parte più difficile di questa fase è stabilire quale file del dispositivo
utilizzare per far riferimento al filesystem EFI corretto. Se il file AUTO che
si desidera modificare è quello associato al dispositivo da cui si esegue
attualmente l’avvio, c’è un solo modo per stabilire qual file del dispositivo
usare:
Esempio 5-8
Stabilire la partizione del disco EFI del dispositivo di avvio
corrente
1. Utilizzare il comando bdf per visualizzare il file del dispositivo del
volume logico che contiene la directory di avvio (/stand):
bdf
/dev/vg00/lvol1
311296
66368
243064
21% /stand
In questo caso, e probabilmente nella maggior parte dei casi, il file del
dispositivo del volume logico /stand è /dev/vg00/lvol1.
Capitolo 5
487
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
2. Successivamente, utilizzare il comando lvdisplay per stabilire il
nome di file del dispositivo dei dispositivi fisici associati con il volume
logico nella fase precedente di questo esempio (utilizzare grep e tail
per filtrare le righe desiderate):
lvdisplay -vk /dev/vg00/lvol1|grep /dev|tail +3
/dev/dsk/c0t0d0s2
38
38
In questo esempio, il filesystem HP-UX del dispositivo fisico uno
associato alla directory /stand (la directory contenente il file della
kernel utilizzato per l’avvio) è /dev/dsk/c0t0d0s2. La stringa “s2” al
termine del nome del file fa riferimento alla partizione numero 2 del
dispositivo fisico. Questa è solitamente la partizione del disco che
contiene i filesystem HP-UX. La partizione EFI è sempre contenuta
nella partizione 1, perciò, modificando nel nome del file “s2” in “s1” si
dovrebbe ottenere il file del dispositivo da utilizzare con il comando
efi_cp (/dev/dsk/c0t0d0s1).
3. Se il volume logico contenente il filesystem /stand contiene più di un
dispositivo fisico, sarà necessaria un’operazione aggiuntiva. Sarà
necessario stabilire da quale è stato eseguito l’avvio, o meglio, quale di
essi sarà utilizzato per l’avvio dopo la modifica del suo file AUTO.
Anche se non sempre, si tratta solitamente del dispositivo associato al
percorso di avvio PRI (primario).
Per stabilire a quale dispositivo punta il percorso di avvio primario,
utilizzare il comando setboot senza opzioni, quindi utilizzare il
comando lssf con ogni file del dispositivo associato al volume logico
contenente /stand. Cercare il file del dispositivo che ha un indirizzo
hardware che coincide con quello del percorso di avvio primario.
Cambiare “s2” in “s1” come descritto nella sottofase precedente e si
avrà il nome da utilizzare con efi_cp.
Nel caso che si disponga di più dispositivi da cui eseguire l’avvio, è
possibile utilizzare questa procedura con dispositivi diversi da quello di
avvio corrente. L’esempio 5-8 descrive un caso comune.
NOTA
Punto
488
2. Utilizzare il metodo o l’editor preferito per modificare il contenuto del
file AUTO nella directory corrente. Ad esempio, si potrebbe voler
modificare il contenuto del file AUTO in modo da eseguire
automaticamente l’avvio da un file della kernel alternativo:
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Prima della modifica, AUTO contiene:
boot vmunix
Dopo la modifica, AUTO contiene:
boot testvmunix
Copiare il file AUTO modificato nel filesystem EFI con efi_cp (senza
l’opzione -u):
efi_cp -d /dev/rdsk/c1t4d0s1 AUTO /EFI/HPUX/AUTO
Avvio in modalità utente singolo
È possibile eseguire l’avvio di HP-UX nella modalità utente singolo
utilizzando la seguente procedura:
Avvio di HP-UX in modalità utente singolo nei server HP Integrity
Nell’ambiente della shell EFI, eseguire l’avvio in modalità utente singolo
arrestando la procedura di avvio nell’interfaccia HPUX.EFI (il prompt di
HP-UX Boot Loader, HPUX>) e digitare il comando boot -is vmunix.
Punto
1. Accedere all’ambiente della shell EFI della nPartition dalla quale si
desidera avviare HP-UX in modalità utente singolo.
Fare accesso al processore di servizio (MP o GSP) e digitare CO per
accedere all’elenco della console. Scegliere la console della nPartition.
Facendo accesso alla console, confermare che ci si trova nel menu di EFI
Boot Manager (il menu principale EFI). In un altro menu EFI, nel
sottomenu scegliere l’opzione Exit finchè non ci si troverà nella schermata
con l’intestazione EFI Boot Manager.
Nel menu di EFI Boot Manager, per accedere all’ambiente della shell EFI
scegliere EFI Shell.
Punto
2. Assicurarsi che il dispositivo di avvio selezionato sia quello che contiene il
file della kernel che si desidera utilizzare. In caso di dubbi:
1. Digitare map al prompt della shell EFI per elencare i dispositivi di
avvio del proprio sistema.
I dispositivi saranno elencati in voci che iniziano con fs#: (dove # è un
numero come 0, 1, 2, 3, ecc.). Ad esempio:
Capitolo 5
489
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
fs0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88F40A3A-B992-11E1-8002-D6217B60E588)
fs1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part3,Sig88F40A9E-B992-11E1-8004-D6217B60E588)
blk0 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
blk1 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A3A-B992-11E1-8002-D6217B60E588)
blk2 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Primary,Master)
/HD(Part1,Sig88f40A6C-B992-11E1-8003-D6217B60E588)
blk4 : Acpi(HWP0002,500)/Pci(2|0)/Ata(Secondary,Master)
2. Stabilire quale voce è assegnata al dispositivo contenente il file della
kernel cui si desidera eseguire l’avvio e digitarne il nome fs#: al
prompt della shell.
Ad esempio, se la voce del dispositivo desiderato (da un elenco più
esteso dell'esempio precedente) è etichettata come “fs7:”, digitare
fs7: al prompt della shell:
Shell> fs7:
Il dispositivo associato alla voce fs7: è ora il dispositivo di avvio
selezionato.
Punto
3. Quando si accede alla partizione di sistema EFI del dispositivo di avvio
desiderato, eseguire il comando HPUX per avviare il loader
\EFI\HPUX\HPUX.EFI del dispositivo selezionato.
Punto
4. Accedere al prompt di HP-UX Boot Loader (HPUX>) premendo un tasto
qualsiasi entro i dieci secondi di attesa concessi per interrompere la
procedura di avvio HP-UX. Nella fase successiva, sarà utilizzato il loader
HPUX.EFI per avviare HP-UX in modalità utente singolo.
Dopo aver premuto un tasto, sarà disponibile l’interfaccia HPUX.EFI
(il prompt di HP-UX Boot Loader, HPUX>). Per la guida sull’utilizzo del
loader HPUX.EFI, digitare il comando help. Per tornare alla shell EFI,
digitare exit.
fs7:\> hpux
(c) Copyright 1990-2002, Hewlett Packard Company.
All rights reserved
HP-UX Boot Loader for IA64
Revision 1.723
Press Any Key to interrupt Autoboot
\efi\hpux\AUTO ==> boot vmunix
Seconds left till autoboot 9
490
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
[L’utente preme un tasto per fermare la procedura d’avvio di HP-UX ed accedere al
caricatore HPUX.EFI ]
Type ’help’ for help
HPUX>
Punto
5. Nell’interfaccia HPUX.EFI (il prompt di HP-UX Boot Loader, HPUX>)
eseguire il comando boot -is vmunix per avviare HP-UX (la kernel
/stand/vmunix) in modalità utente singolo (-is). Nel caso si esegua
l’avvio in modalità utente singolo da un altro file della kernel, sostituire a
vmunix il nome dell’altro file. L’opzione -is è quella che specifica la
modalità utente singolo.
HPUX> boot -is vmunix
> System Memory = 4063 MB
loading section 0
................................................... (complete)
loading section 1
........ (complete)
loading symbol table
loading System Directory(boot.sys) to MFS
....
loading MFSFILES Directory(bootfs) to MFS
......
Launching /stand/vmunix
SIZE: Text:25953K + Data:3715K + BSS:3637K = Total:33306K
Console is on a Serial Device
Booting kernel...
Punto
6. Se si sta accedendo alla console di sistema tramite il processore di
amministrazione e non si desidera più utilizzarlo, uscire dalla console e
dalle interfacce del processore di servizi.
Per uscire dall’ambiente EFI, digitare ^B (Control-B); in questo modo si
uscirà dalla console di nPartition e si tornerà al menu principale del
processore di servizio. Per uscire dal processore di servizio, nel menu
principale digitare X.
Avvio in modalità di manutenzione LVM (o VxVM)
La procedura per avviare HP-UX nella modalità di manutenzione LVM è
uguale a quella per avviare in modalità utente singolo (Per i dettagli,
Vedere “Avvio di HP-UX in modalità utente singolo nei server
HP Integrity” a pagina 489), ad eccezione dell’opzione di avvio -lm al
posto di quella -is:
HPUX> boot -lm vmunix
Capitolo 5
491
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Per la modalità di manutenzione VxVM usare:
HPUX> boot -vm vmunix
Avvio di HP-UX nei sistemi HP 9000 (PA-RISC):
dettagli e varianti
Avvio standard (sistemi PA-RISC)
Di seguito si trovano maggiori dettagli su ciò che avviene durante la
normale sequenza di avvio di HP-UX in un sistema HP 9000. Se si sta
avviando un server HP Integrity, vedere “Avvio di HP-UX nei server
HP Integrity: dettagli e varianti” a pagina 471.
****************************************************
Punto
1. Alimentazione dei dispositivi esterni: Se necessario, avviare tutte le
periferiche ed i dispositivi esterni collegati al computer (ad esempio, unità
disco, unità a nastro, stampanti, terminali, convertitori di bus).
Una volta terminati i test automatici dei dispositivi, procedere al
passaggio successivo.
Punto
2. Accensione del sistema (o nPartition): Accensione o riavvio del
computer o nPartition.
L’hardware di sistema, oppure quello associato alla nPartition, che si sta
avviando effettuerà una serie di test automatici per verificare che i
processori, la memoria e altre componenti del sistema siano in funzione.
Punto
3. Scelta del di dispositivo di avvio: Il sistema (o la nPartition che si sta
avviando) deve individuare il file della kernel da cui eseguire l’avvio.
Esistono due fasi della ricerca:
Fase 1
stabilire il percorso hardware del dispositivo di avvio
Fase 2
stabilire quale file della kernel avviare dal percorso
hardware (vedere fase 4)
Le variabili del percorso archiviate nella memoria non volatile impostano
fino a tre percorsi possibili dai quali tentare l’avvio:
PRI
492
Il percorso di avvio PRImario è il primo da tentare.
Impostare il valore di questo percorso in modo da
puntare al dispositivo da cui si esegue l’avvio più
frequentemente.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
HAA
Il percorso di avvio High-Availability Alternate, nei
sistemi che lo supportano, è il percorso alternativo da
utilizzare nel caso che il sistema non riesca ad avviarsi
usando quello primario.
ALT
Il percorso di avvio ALTernativo è il percorso hardware
ad un’unità di avvio alternativa (ad esempio, un’unità a
nastro, un’origine di rete o un’unità a dischi ottici).
In alcuni sistemi sarà tentato solamente il percorso di avvio primario. In
questi sistemi, per poter eseguire l’avvio da un percorso alternativo sarà
necessario interrompere l’attesa di 10 secondi dell’avvio automatico.
In altri sistemi, è possibile configurare il firmware per associare varie
azioni ad ogni percorso di avvio. Questa azioni di avvio consentono di
indicare al sistema:
•
se tentare o ignorare un percorso di avvio
•
se l’avvio da un dato percorso non ha avuto successo, se tentare o no il
percorso successivo della sequenza PRI -> HAA -> ALT
•
se usare o no l’interfaccia Boot Console Handler (BCH)
Per maggiori informazioni sui percorsi hardware disponibili nel proprio
sistema, consultare l’output di ioscan (per i dettagli su come eseguire
ioscan, vedere ioscan (1M)). Inoltre, alcune informazioni sul percorso
sono materialmente stampate sul proprio sistema.
Di solito, il percorso di avvio primario punta al dispositivo che si utilizza
più di frequente, e questo è disponibile.
Dopo che il dispositivo di avvio è stato inizializzato, PDC (le routine
firmware) fa accesso ad un’area del dispositivo di avvio formattata in
modo particolare, chiamata volume LIF volume. PDC carica in memoria
Initial System Loader (ISL) e trasferisce ad esso il controllo.
Punto
4. Selezione del file della kernel: Se ininterrotto (e se il flag autoboot è
attivato -- Vedere “Avvio automatico ed avvio manuale” a pagina 494) ISL
caricherà ed inizializzerà hpux, lo specifico caricatore di avvio di HP-UX.
Punto
5. Caricamento ed inizializzazione del sistema operativo HP-UX:
hpux utilizza il contenuto del file AUTO che si trova nell’area LIF del
dispositivo di avvio per:
Capitolo 5
493
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
1. individuare il file della kernel per l’avvio
2. caricare in memoria la kernel HP-UX
3. inizializzare la kernel HP-UX
In genere, il file AUTO contiene:
hpux vmunix
che indica a hpux di caricare la kernel dal file di nome vmunix dal
filesystem predefinito (/stand -- il file /stand/vmunix).
Punto
6. HP-UX porta a termine il suo processo di inizializzazione e inizia
il suo normale funzionamento.
Avvio automatico ed avvio manuale
PDC configura l’avvio ed i dispositivi della console utilizzando Boot
Console Handler (BCH). Quali azioni BCH intraprende dopo che la
console ed i dispositivi di avvio sono stati inizializzati dipende se
l’operatore ha interrotto manualmente o no l’avvio automatico, e dallo
stato di due flag nella memoria non volatile: autoboot e autosearch.
Evitare l’avvio automatico Per evitare l’avvio automatico, premere un
tasto qualsiasi della tastiera della console prima che scada il tempo
impostato, di solito 10 secondi. Boot Console Handler visualizzerà il suo
menu principale e consentirà di interagire.
Abilitazione/Disabilitazione dell’avvio automatico I sistemi
HP 9000 che eseguono HP-UX normalmente sono configurati in modo da
avviarsi automaticamente all’accensione. Questa è una caratteristica
importante nel caso di sistemi installati in luoghi non sempre sorvegliati
da un operatore o da un amministratore di sistema. In caso di
interruzione nell'erogazione della corrente elettrica, il sistema si può
(solitamente) riavviare senza necessità di intervento dell'operatore.
La funzionalità di avvio automatico è anche una comodità.
A volte, non si desidera che i sistemi si avviino automaticamente, ad
esempio quando si desidera avviare da un altro dispositivo o file della
kernel. Consultare “Avvio da un dispositivo alternativo” a pagina 499 o
“Avvio da una kernel alternativa” a pagina 501.
494
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
La seguente tabella descrive come le impostazioni dei flag autoboot e
autosearch influenzano la sequenza di avvio:
Tabella 5-1
Flag autoboot e autosearch
autoboot
autosearch
Tipo di avvio
Conseguenze
OFF
OFF
Avvio
manuale
BCH interagisce con l’utente per
ottenere il percorso del dispositivo di
avvio
OFF
ON
Ricerca
dispositivo
BCH cerca tutti i dispositivi
avviabili, quindi interagisce con
l’utente per sceglierne uno
ON
OFF
Avvio
automatico
BCH tenta con percorso di avvio
primario della memoria non volatile;
se non è avviabile, BCH interagirà
con l’utente per ottenere il percorso
di un dispositivo di avvio
ON
ON
Ricerca
automatica
BCH tenta con percorso di avvio
primario ; se non è avviabile, BCH
cercherà di trovare il primo
dispositivo avviabile e lo utilizzerà.
Perché il computer si riavvii all'accensione o al riavvio, occorre che
l'indicatore autoboot sia abilitato.
Per richiedere l’intervento di un operatore all’avvio del computer, occorre
che l’indicatore autoboot sia disabilitato.
Impostazione del valore dell'indicatore autoboot. I valori dei flag autoboot
ed autosearch possono essere impostati o modificati in vari modi:
•
Nell’ambiente di pre-avvio, è possibile impostarli nel menu di configurazione
di Boot Console Handlers
•
In un sistema HP-UX in esecuzione, è possibile utilizzare il comando setboot
Impostazione dei flag autoboot ed autosearch con Boot Console Handler
Punto
1. Dopo avere acceso o riavviato il computer (o nPartition) prendere il controllo della
procedura di avvio premendo un tasto qualsiasi della tastiera della console in
modo che autoboot/autosearch non avviino automaticamente il sistema (nel caso
fossero attivati). Boot Console Handler visualizzerà il suo menu principale.
Capitolo 5
495
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Boot Console Handler (BCH) visualizzerà il suo menu principale in attesa di un
comando.
Main Menu: Enter command>
Punto
2. Digitare uno dei seguenti comandi BCH (secondo le proprie necessità):
Esempio 5-9
Attivazione del flag autoboot con BCH
Main Menu: Enter Command > co au bo on
SUGGERIMENTO
Il comando descritto sopra è un’abbreviazione per specificare un comando che
attualmente risiede nel menu di configurazione di BCH (la parte co del comando
indica che la parte successiva proviene dal menu di configurazione).
La parte au del comando descritto sopra è un’abbreviazione del comando “auto”
del menu di configurazione.
La parte bo del comando è un’abbreviazione per l’argomento “boot” del comando
auto del menu di configurazione che indica il flag autoboot. Infine, la parte on del
comando di cui sopra indica che si vuole che il flag sia attivato.
Quindi, il comando abbreviato sostituisce i due comandi seguenti:
Main Menu: Enter Command > co
Configuration Menu: Enter Command > auto boot on
Esempio 5-10
Disattivazione del flag autoboot con BCH
Main Menu: Enter Command > co au bo off
Esempio 5-11
Disattivazione del flag autosearch con BCH
Main Menu: Enter Command > co au sea on
Esempio 5-12
Disattivazione del flag autosearch con BCH
Main Menu: Enter Command > co au sea off
Impostazione dei flag autoboot e autosearch con il comando setboot di HP-UX
È possibile impostare i valori dei flag autoboot ed autosearch da un sistema
HP-UX in esecuzione. Per fare ciò, utilizzare il comando setboot (per maggiori
dettagli, vedere setboot (1M)).
Esempio 5-13
Attivazione del flag autoboot con setboot
/usr/sbin/setboot -b on
496
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Esempio 5-14
Disattivazione del flag autoboot con setboot
/usr/sbin/setboot -b off
Esempio 5-15
Attivazione del flag autoboot con setboot
/usr/sbin/setboot -s on
Esempio 5-16
Disattivazione del flag autosearch con setboot
/usr/sbin/setboot -s off
Modifica dei percorsi di avvio PRI, HAA e ALT
I sistemi HP 9000 consentono di definire un percorso di avvio primario ed
uno alternativo, e, nella maggior parte dei casi, un percorso di avvio
alternativo ad alta disponibilità.
Il percorso di avvio primario consente ad autoboot di operare in modo
corretto, e tutte e tre le definizioni consentono di fare facilmente
riferimento in caso di necessità ad altrettanti percorsi hardware (ad
esempio, con Boot Console Handler è possibile utilizzare il comando “boot
alt” per eseguire l’avvio dal dispositivo hardware associato al percorso di
avvio ALT).
È possibile gestire i percorsi di avvio quando HP-UX è in esecuzione,
utilizzando il comando setboot, oppure nell’ambiente di pre-avvio con
Boot Console Handler.
Impostazione dei percorsi di avvio PRI, HAA e ALT con il comando
setboot di HP-UX:
Quando si utilizza setboot per configurare i percorsi di avvio primario
(PRI), alternativo ad alta disponibilità (HAA) o alternativo (ALT), il nuovo
percorso del dispositivo che è stato specificato sostituisce l’opzione di avvio
originale.
NOTA
Il percorso del dispositivo di avvio specificato con il comando setboot
(percorso negli esempi seguenti) deve essere un percorso hardware di un
dispositivo di avvio HP-UX valido.
•
Per impostare il percorso di avvio primario, utilizzare il comando
setboot -p percorso, ad esempio:
/usr/sbin/setboot -p 0/0/2/0/0.6
Capitolo 5
497
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
•
Per impostare il percorso di avvio alternativo ad alta disponibilità,
utilizzare il comando setboot -h percorso, ad esempio:
/usr/sbin/setboot -h 0/0/0/3/1.6
•
Per impostare il percorso di avvio alternativo, utilizzare il comando
setboot -a percorso, ad esempio:
/usr/sbin/setboot -a 0/0/0/3/0.6
Impostazione dei percorsi di avvio PRI, HAA e ALT con Boot Console
Handler
Punto
1. Dopo avere acceso o riavviato il computer (o nPartition) prendere il
controllo della procedura di avvio premendo un tasto qualsiasi della
tastiera della console in modo che autoboot/autosearch non avviino
automaticamente il sistema (nel caso fossero attivati). Boot Console
Handler visualizzerà il suo menu principale.
Boot Console Handler (BCH) visualizzerà il suo menu principale in attesa
di un comando.
Main Menu: Enter command>
Punto
2. Digitare uno dei seguenti comandi BCH (secondo le proprie necessità):
Esempio 5-17
Impostazione del percorso di avvio primario (PRI) con BCH
Esempio: Imposta l’indirizzo del percorso di avvio primario come
0/0/0/2/0.5
Main Menu: Enter Command > pa pri 0/0/0/2/0.5
SUGGERIMENTO
Nel comando descritto sopra, pa è l’abbreviazione del comando path.
Nell’interfaccia di Boot Console Handler, è spesso possibile abbreviare
comandi ed opzioni (pri per “primary”). Per le abbreviazioni ammesse,
vedere la guida dell’interfaccia di BCH.
Esempio 5-18
Impostazione del percorso di avvio alternativo ad alta
disponibilità (HAA) con BCH
Esempio: Imposta l’indirizzo del percorso di avvio alternativo ad alta
disponibilità come 0/0/0/3/1.6
Main Menu: Enter Command > pa haa 0/0/0/3/1.6
498
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Esempio 5-19
Impostazione del percorso di avvio alternativo (ALT) con BCH
Esempio: Imposta l’indirizzo del percorso di avvio alternativo come
0/0/0/3/0.6
Main Menu: Enter Command > pa alt 0/0/0/3/0.6
Avvio di sistemi PA-RISC da un’origine alternativa di avvio
Un’origine di avvio è costituita da due elementi:
1. Un dispositivo di avvio contenente un filesystem in cui sono
archiviati i file della kernel
2. Un file della kernel contenente la kernel da eseguire
L’origine di avvio primaria è il file della kernel che si trova nel dispositivo
di avvio primario. Questa è l’unità da cui il sistema si avvierà durante
l’avvio automatico (se il sistema è configurato per l’avvio automatico).
È possibile impedire l’avvio con questa impostazione, interrompendo
l’avvio automatico e specificando un altro dispositivo di avvio oppure un
altro file della kernel nel dispositivo di avvio primario.
Avvio da un dispositivo alternativo Esistono casi in cui sarà
necessario avviare da un dispositivo diverso da quello da cui si avvia
normalmente. Ad esempio, se il disco di avvio primario non funziona,
potrebbe essere necessario avviare il sistema da un disco diverso o da un
nastro di recupero.
NOTA
Capitolo 5
Nel caso si disponga di un vecchio sistema HP 9000 con firmware che non
utilizza Boot Console Handler, seguire le istruzioni a schermo del
firmware. La procedura è la medesima; cambiano solamente i comandi
specifici:
•
Interrompere la procedura di avvio automatico
•
Utilizzare il comando boot per specificare da dove eseguire l’avvio
499
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Uso di Boot Console Handler per eseguire l’avvio da un dispositivo di
avvio alternativo
Punto
1. Dopo avere acceso o riavviato il computer (o nPartition) prendere il
controllo della procedura di avvio premendo un tasto qualsiasi della
tastiera della console in modo che autoboot/autosearch non avviino
automaticamente il sistema (nel caso fossero attivati). Boot Console
Handler visualizzerà il suo menu principale.
Boot Console Handler (BCH) visualizzerà il suo menu principale in attesa
di un comando.
Main Menu: Enter command>
Punto
2. Utilizzare il comando boot di BCH per specificare da dove eseguire l’avvio
del sistema
È possibile eseguire il comando BOOT nei modi seguenti:
•
BOOT
Lanciando il comando BOOT senza argomenti l’avvio sarà eseguito dal
percorso di avvio primario (PRI).
•
BOOT variabile_avvio
Questo comando esegue l’avvio dal dispositivo specificato nel
percorso, dove variabile_avvio è il percorso di avvio PRI, HAA o
ALT.
Ad esempio, BOOT HAA esegue l’avvio dal percorso di avvio alternativo
ad alta disponibilità.
•
BOOT LAN INSTALL o BOOT LAN.indirizzo-ip INSTALL
Il comando BOOT... INSTALL avvierà HP-UX dal server di
installazione HP-UX predefinito oppure dal server specificato con
indirizzo-ip.
•
BOOT percorso
Questo comando esegue l’avvio dal percorso specificato. È possibile
specificare il percorso nella notazione dei percorsi hardware HP-UX
(ad esempio, 0/0/2/0/0.13) oppure nel formato “etichetta del
percorso” (ad esempio, P0 o P1).
500
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Se si è specificato il percorso nel formato “etichetta del percorso”,
allora percorso farà riferimento al percorso del dispositivo riportato
dall’ultima ricerca fatta con il comando BCH SEARCH.
NOTA
Esempio 5-20
Avvio dal dispositivo specificato nel percorso di avvio ALT
Main Menu: Enter command or menu > boot alt
Esempio 5-21
Avvio dal dispositivo specificato all’indirizzo hardware
0/0/2/0/0.14:
Main Menu: Enter command or menu > boot 0/0/2/0/0.14
Esempio 5-22
Avvio dal dispositivo specificato con etichetta del percorso P2:
Main Menu: Enter command or menu > search
PATH#
----P0
P1
P2
Device Path (dec)
------------------0/0/2/0/0.13
0/0/2/0/0.14
0/0/2/0/0.0
Device Type
-----------Random access media
Random access media
Random access media
Main Menu: Enter command or menu > boot P2
Esempio 5-23
Avvio dal server di installazione HP-UX predefinito
Main Menu: Enter command or menu > boot lan
Esempio 5-24
Avvio dal server di installazione HP-UX all’indirizzo
192.nnn.xxx.yyy
Main Menu: Enter command or menu > boot lan.192.nnn.xxx.yyy
INSTALL
Avvio da una kernel alternativa Se si è compilata una nuova kernel o
si ha un file di kernel alternativo da cui si intende avviare:
Punto
1. Avvio dal dispositivo contenente il file della kernel alternativo utilizzando
il comando BOOT dall’interfaccia di BCH.
Dopo aver lanciato il comando BOOT, l’interfaccia di BCH chiederà di
specificare se si desidera un arresto al prompt ISL.
Capitolo 5
501
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Per avviare dal file del HP-UX indicato dal file AUTO nel dispositivo di
avvio senza fermarsi al prompt ISL e procedere oltre ISL ed eseguire il
contenuto del file AUTO del dispositivo selezionato, digitare n. Per
impostazione predefinita, il file AUTO è configurato per caricare
/stand/vmunix, anche se è possibile modificarlo (Vedere “Modifica del
contenuto del file autoexecute” a pagina 502).
Main Menu: Enter command or menu > BOOT PRI
Primary Boot Path:
0/0/1/0/0.15
Do you wish to stop at the ISL prompt prior to booting? (y/n)
>> n
ISL booting
hpux
Boot
: disk(0/0/1/0/0.15.0.0.0.0.0;0)/stand/vmunix
Per avviare una kernel HP-UX diversa da quella a cui punta il file AUTO,
oppure per avviare HP-UX in modalità utente singolo o di manutenzione
LVM, arrestarsi al prompt ISL e specificare gli argomenti appropriati per
il loader hpux.
Specificare il nome del percorso HP-UX del file di kernel alternativo che si
intende avviare come parte dell’argomento file_dispositivo del
comando hpux boot. Ad esempio:
ISL> hpux boot disk(2/4.0.0;0)/stand/nome_file_kernel_alt
Modifica del contenuto del file autoexecute
Nei sistemi HP 90001, una parte importante di ciò che rende possibile un
avvio automatico è il file noto come file autoexecute che contiene il
comando normalmente usato per avviare il sistema operativo HP-UX
(il comando hpux che da digitare al prompt ISL>). Il contenuto di questo
file è utilizzato durante la procedura di avvio quando alcuni o tutti gli
elementi del comando hpux sono stati omessi dal comando dato a ISL,
come nel caso dell’avvio automatico.
1. Nei sistemi di classe V, la funzione del file autoexecute è svolta da
una varietà di valori di sistema definiti, impostati attraverso vari
comandi del modo di avvio.
502
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Il file autoexecute non si trova in nessun filesystem HP-UX, perché il
suo contenuto è necessario prima che HP-UX sia in esecuzione (prima che
HP-UX possa accedere ai propri filesystem). Invece, il file autoexecute,
denominato AUTO, è ubicato nell’area LIF (denominata talvolta area di
avvio) di uno dei dischi avviabili. Questa è l’area in cui risiede ISL.
Raramente occorre modificare i contenuti del file AUTO. Ad esempio, vi
sono dei casi in cui lo si potrebbe desiderare, come quando si crea un
nuovo file della kernel (con un nome diverso da quello predefinito,
/stand/vmunix) da cui si vuole avviare regolarmente, o per avviare da un
dispositivo su un disco diverso da quello in cui risiede ISL.
Per creare un nuovo contenuto del file AUTO, utilizzare il comando
/usr/sbin/mkboot:
mkboot -a "contenuti di autofile" nome_file_dispositivo
Esempio:
mkboot -a "hpux disc(8.0.1;0)/stand/vmunix.new"
/dev/rdsk/c0t0d0
Per i dettagli, consultare mkboot (1M).
Per vedere il file AUTO quando HP-UX è in esecuzione, digitare:
/usr/bin/lifcp /dev/rdsk/c0t0d0:AUTO -
Si può anche mostrare la stringa del comando d’avvio nel file AUTO al
prompt ISL>:
ISL> lsautofl
Avvio in modalità utente singolo
Se è necessario avviare un sistema in modalità utente singolo, ad esempio
per assicurarsi che nessun altro si colleghi al sistema mentre si sta
effettuando la manutenzione:
Punto
1. Dopo avere acceso o riavviato il computer (o nPartition) prendere il
controllo della procedura di avvio premendo un tasto qualsiasi della
tastiera della console in modo che autoboot/autosearch non avviino
automaticamente il sistema (nel caso fossero attivati). Boot Console
Handler visualizzerà il suo menu principale.
Boot Console Handler (BCH) visualizzerà il suo menu principale in attesa
di un comando.
Main Menu: Enter command>
Capitolo 5
503
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Punto
2. Avviare dal dispositivo desiderato utilizzando il comando BOOT
nell’interfaccia BCH, e specificare che la procedura di avvio si arresti al
prompt ISL (rispondere y alla domanda “stop at the ISL prompt”).
Main Menu: Enter command or menu > BOOT ALT
Alternate Boot Path: 0/0/0/3/0.6
Do you wish to stop at the ISL prompt prior to booting? (y/n) >>
y
Initializing boot Device.
....
ISL Revision A.00.43 Apr 12, 2000
ISL>
Punto
Esempio 5-25
3. Al prompt ISL, eseguire il comando Secondary System Loader (hpux) per
avviare la kernel HP-UX in modalità utente singolo:
Avvio di HP-UX in modalità utente singolo nei sistemi HP 9000:
ISL> hpux -is boot /stand/vmunix
Per uscire dal prompt ISL e tornare all’interfaccia BCH, eseguire il
comando EXIT invece di specificare il comando del loader hpux.
Per l’elenco dettagliato delle altre opzioni del loader hpux, vedere la
manpage hpux (1M).
Esempio 5-26
Esempio di avvio di HP-UX in modalità utente singolo
ISL Revision A.00.42
JUN 19, 1999
ISL> hpux -is /stand/vmunix
Boot
: disk(0/0/2/0/0.13.0.0.0.0.0;0)/stand/vmunix
8241152 + 1736704 + 1402336 start 0x21a0e8
....
INIT: Overriding default level with level ’s’
INIT: SINGLE USER MODE
504
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
INIT: Running /sbin/sh
#
Il sistema si avvierà in modalità utene singolo; prestare attenzione ai
messaggi di conferma:
INIT: Overriding default level with level `s'
INIT: SINGLE USER MODE
Punto
4. Se si è fatto accesso alle interfacce della console di sistema e del
processore dei servizi (processore di amministrazione) tramite la rete,
uscirne una volta terminato il loro utilizzo.
Per uscire dall’ambiente BCH, digitare ^B (Control-B); in questo modo si
uscirà dalla console di sistema o di nPartition e si tornerà al menu
principale del processore di servizio. Per uscire dal processore di servizio,
nel menu principale digitare X.
Avvio in modalità manutenzione LVM
Per avviare HP-UX nella modalità di manutenzione LVM seguire la
procedura per avviare HP-UX nella modalità utente singolo (Vedere
“Avvio in modalità utente singolo” a pagina 503):
ISL> hpux -lm boot
I volumi logici di avvio/root sono i soli volumi logici che si trovano in un
posizione nota qualora i dati della configurazione LMV siano andati
perduti. La modalità di manutenzione è utile in tali sistemi quando un
avvio standard non sia andato a buon fine a causa di problemi della
configurazione LMV. Occorre prima risolvere i problemi della
configurazione LMV e quindi riavviare.
ATTENZIONE
Quando si avvia il sistema nella modalità di manutenzione, non attivare il
gruppo del volume di root e non andare in modalità multiutente
(ad esempio, specificando /sbin/init 2). Nel caso in cui lo si facesse,
si potrebbe corrompere il file system di root.
Una volta riparate o ripristinate le informazioni della configurazione
LMV, riavviare il sistema usando il comando reboot con l’opzione -n. Ciò
evita che le riparazioni basate sul disco siano sovrascritte dalle vecchie
informazioni ancora memorizzate nei buffer di memoria.
/usr/sbin/reboot -n
Capitolo 5
505
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
È possibile reperire ulteriori informazioni su LVM in Capitolo 6,
Amministrazione di un sistema: Gestione di dischi e file.
Velocizzazione dell’avvio: SpeedyBoot
In molti server HP Integrity e sistemi HP 9000, una funzione firmware
chiamata SpeedyBoot consente di evitare alcuni dei test di sistema al
momento dell’avvio in modo da avviare più velocemente il sistema.
NOTA
HP consiglia di eseguire tutti i test, anche se riconosce l’esigenza di avere
disponibile il sistema il più velocemente possibile.
Se si è sicuri del buon funzionamento dell’hardware del proprio sistema, è
possibile scegliere di saltare alcuni test del sistema per ottenere un avvio
più rapido.
La funzione SpeedyBoot consente di specificare quali test eseguire, o
saltare, e se farlo solamente per il prossimo avvio oppure anche per tutti
quelli successivi. Ci sono vari modi per definire quali test devono essere
eseguiti. Quale scegliere dipende da:
•
Se il sistema è in funzione o no al momento della configurazione delle
impostazioni di SpeedyBoot
•
Se si tratta di un server HP Integrity o un sistema HP 90001
•
Se si desidera configurare le impostazioni di SpeedyBoot solamente
per l’avvio successivo o per tutti quelli futuri
•
Quale release di HP-UX si sta utilizzando (se si utilizza il comando
setboot per la configurazione)
SpeedyBoot opera riducendo il numero dei test del firmware effettuati
all'avvio. L’utente specifica quali test eseguire. I test comprendono:
✓
test CPU preliminari
✓
test CPU finali
✓
inizializzazione della memoria (solo per i server HP Integrity)
1. Nei sistemi HP 9000 SpeedyBoot è supportato solamente nelle
macchine con firmware che supporta Boot Console Handler (BCH).
Alcune piattaforme meno recenti possono essere aggiornate ad un
nuovo firmware che supporta SpeedyBoot.
506
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
✓
test completi della memoria
✓
test dipendenti dalla piattaforma (solo server HP Integrity)
✓
test hardware I/O (solo server HP Integrity)
✓
test hardware dei processori (solo sistemi HP 9000)
✓
test complesso elettronico centrale (solo sistemi HP 9000)
✓
test dei chipset (solo server HP Integrity)
È possibile specificare in modo indipendente quali test saranno eseguiti:
•
solo per il prossimo riavvio
•
per tutti gli avvii successivi
I test sono descritti in “Test di avvio del sistema” a pagina 508.
NOTA
Capitolo 5
Disattivando alcuni o tutti i test di avvio, si può diminuirne, anche
notevolmente, il tempo necessario. Tuttavia, in caso di panico di sistema
o di avvio non riuscito, all’avvio successivo saranno eseguiti tutti i test.
507
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Test di avvio del sistema
Quando il sistema si avvia, esegue i test descritti nella Tabella 5-2. Si
tratta delle parole chiave per i test dell'hardware eseguiti dal processordependent code (PDC) o dal firmware al momento del avvio o del riavvio
del sistema.
Tabella 5-2
Nome del test
Test di SpeedyBoot
Valori
Descrizione
all
on
off
partial
Tutti i test elencati.
SELFTESTS
on
off
partial
comprende i test early_cpu e late_cpu. E’ equivalente
all’opzione SELFTESTS nel menu di servizio del boot console
handler (BCH). La differenza sta nel fatto che setboot può
controllare i sottotest separatamente, mentre BCH non può
farlo.
early_cpu
on
off
Quando è on, esegue i test per firmware, cache e CPU. Eseguiti
dal firmware. Quando è off, salta l’esecuzione dei test.
late_cpu
on
off
Quando è on, esegue i test per firmware, cache e CPU.
Effettuati dalla memoria e perciò più veloci dei test
early_cpu. Quando è off, salta l’esecuzione dei test.
FASTBOOT
on
off
partial
Comprende i test full_memory e PDH per i sistemi HP 9000
(PA-RISC). Comprende i test Platform e Full_memory per i
server HP Integrity. E’ equivalente all’opzione FASTBOOT nel
menu di servizio del boot console handler (BCH). La differenza
sta nel fatto che setboot può controllare i sottotest
separatamente, mentre BCH non può farlo. Nota: Quando
FASTBOOT è on, i test sono effettuati e viceversa..
full_memory
on
off
Quando è on, esegue i test di scrittura, lettura-scrittura e
lettura in tutti gli indirizzi di memoria. Quando è off,
inizializza soltanto la memoria. Supportato solamente nei
sistemi HP 9000 (PA-RISC):
Platform
on
off
Quando è on, abilita i test hardware generici per la
piattaforma. Quando è off, non esegue i test hardware
generici per la piattaforma. Supportato solamente nei server
HP Integrity
Full_memory
on
off
Quando è on, abilita i test distruttivi della memoria completi.
Quando è off, non esegue i test distruttivi della memoria
completi. Supportato solamente nei server HP Integrity
(Osservare la “f”
minuscola)
(Osservare la “F”
maiuscola)
508
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Tabella 5-2
Nome del test
Test di SpeedyBoot (segue)
Valori
Descrizione
PDH
on
off
Hardware dipendente dal processore. Quando è on, esegue un
test di checksum della memoria di sola lettura (ROM). Quando
è off, non li esegue.
CEC
on
off
Complesso elettronico centrale. Quando è on, esegue i test dei
convertitori di bus di basso livello e dei chip di I/O. Quando è
off, non li esegue.
CEC non è disponibile su tutti i sistemi.
Memory_init
on
off
Quando è on, abilita i test distruttivi della memoria completi.
Quando è off, non esegue i test distruttivi della memoria
completi. Supportato solamente nei server HP Integrity
IO_HW
on
off
Test dell’hardware IO. Quando è on, consente al firmware di
sistema (o ai driver EFI) di eseguire tutti i test dell’hardware
IO (solo per i dispositivi di avvio). Quando è off, non esegue
questi test. Supportato solamente nei server HP Integrity
Chipset
on
off
Quando è on, abilita i test dei chipset. Quando è off, non esegue
i test per i chipset. Supportato solamente nei server
HP Integrity
Visualizzazione delle impostazioni SpeedyBoot del sistema
Se il sistema è al momento avviato, è possibile visualizzare le
impostazioni di SpeedyBoot utilizzando l’opzione -v del comando setboot:
Esempio 5-27
Visualizzazione delle impostazioni correnti di SpeedyBoot del
sistema (esempio di output per HP 9000)
setboot -v
TEST
---all
SELFTESTS
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
Capitolo 5
CURRENT
------partial
partial
off
on
partial
off
on
off
SUPPORTED
--------partial
yes
yes
yes
yes
yes
yes
no
DEFAULT
------partial
on
on
on
on
on
on
off
NEXT BOOT
--------partial
partial
off
on
partial
off
on
off
509
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Esempio 5-28
Visualizzazione delle impostazioni correnti di SpeedyBoot del
sistema (esempio di output per server HP Integrity)
setboot -v
Primary bootpath : <none>
HA Alternate bootpath : 0/0/0/1/0
Alternate bootpath : <none>
Autoboot is ON (enabled)
TEST
CURRENT
DEFAULT
---------------all
partial
partial
SELFTESTS
on
on
early_cpu
on
on
late_cpu
on
on
FASTBOOT
on
on
Platform
on
on
Full_memory on
on
Memory_init
on
on
IO_HW
off
off
Chipset
on
on
Tabella 5-3
Titoli della tabella di stato di SpeedyBoot
Colonna
510
Descrizione
Test
I nomi di parola chiave dei test che possono essere
controllati da SpeedyBoot. Consultare la Tabella 5-2 a
pagina 508.
Current
L’impostazione attuale di ogni test. on significa che il
test è normalmente seguito a ogni avvio. off significa
che il test è normalmente omesso a ogni avvio.
partial significa che alcuni sottotest sono
normalmente eseguiti a ogni avvio.
Supported
Se il test è supportato o meno dal firmware di sistema.
yes significa che il test è supportato. no significa che il
test non è supportato partial significa che alcuni
sottotest sono supportati..
Default
I valori predefiniti di ogni test. on, off, e partial sono
gli stessi di Current.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Tabella 5-3
Titoli della tabella di stato di SpeedyBoot (segue)
Colonna
Next Boot
Descrizione
I valori per ogni test saranno usati al prossimo avvio.
Se sono diversi rispetto a Current, i valori Current
saranno reinseriti dopo il prossimo avvio. on, off e
partial sono gli stessi di Current.
Configurazione dei test di sistema d’avvio con il menu di BCH
(solo per sistemi HP 9000)
Nel menu di configurazione di BCH, utilizzare il comando FASTBOOT per
configurare le impostazioni SpeedyBoot per il sistema (o nPartition).
Punto
1. Accedere alla console di sistema o nPartition e riazzerare la partizione per
tornare al menu principale di BCH.
Dopo avere acceso o riavviato il computer (o nPartition) prendere il
controllo della procedura di avvio premendo un tasto qualsiasi della
tastiera della console in modo che autoboot/autosearch non avviino
automaticamente il sistema (nel caso fossero attivati). Boot Console
Handler visualizzerà il suo menu principale.
Punto
2. Nel menu principale di BCH, digitare il comando co per entrare nel menu
di configurazione di BCH.
Punto
3. Nel menu di configurazione di BCH, utilizzare il comando FASTBOOT per
elencare o configurare le impostazioni di SpeedyBoot.
Digitare FASTBOOT senza argomenti per visualizzare le impostazioni
correnti di SpeedyBoot del proprio sistema o nPartition.
NOTA
HP consiglia di eseguire tutti i test, anche se riconosce l’esigenza di avere
disponibile il sistema il più velocemente possibile.
Per attivare tutti i test, utilizzare il comando FASTBOOT RUN del menu di
configurazione di BCH.
Per disattivare un singolo test, digitare: FASTBOOT test SKIP, dove test
è il nome del test (“PDH”, “EARLY” o “LATE”).
Per attivare un singolo test, digitare: FASTBOOT test RUN.
Capitolo 5
511
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Per maggiori dettagli sulle impostazioni dei test, digitare: HELP FASTBOOT
nel menu di configurazione di BCH
Punto
4. Ripetere il passo 3 finché le impostazioni non sono quelle desiderate,
quindi riavviare il sistema.
Configurazione dei test di sistema d’avvio con la shell EFI
(solo per server HP Integrity)
Nell’ambiente della shell EFI, utilizzare il comando boottest per gestire
le impostazioni di SpeedyBoot per il sistema (o nPartition).
Punto
1. Accedere all’ambiente della shell EFI del sistema o nPartition che si
desidera configurare.
Per accedere alla shell EFI, riavviare il sistema o nPartition. Se
necessario, interrompere la procedura di avvio automatico ed utilizzare i
tasti direzione su/giù per evidenziare la voce di menu “EFI Shell”, quindi
premere INVIO per selezionarla.
Punto
2. Nell’ambiente della shell EFI, utilizzare il comando boottest per
elencare, attivare o disattivare i test d’avvio del sistema (o nPartition).
Per visualizzare l’elenco dei test d’avvio di sistema supportati, eseguire il
comando boottest -h al prompt della shell EFI:
Shell> boottest -h
Usage: BOOTTEST [on|off] | [[test] [on|off]]
test : early_cpu, late_cpu, platform, chipset,
io_hw, mem_init, mem_test
Shell>
È possibile attivare o disattivare qualsiasi test d’avvio specificandone il
nome come argomento di boottest.
Nel seguente riepilogo del comando boottest, nome_test è uno dei
seguenti test di sistema:
512
•
early_cpu
•
late_cpu
•
platform
•
chipset
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
Punto
•
io_hw
•
mem_init
•
mem_test
boottest
Visualizza la configurazione corrente
dei test d’avvio.
boottest nome_test
Visualizza l’impostazione corrente del
test specificato (nome_test). Ad
esempio: boottest mem_test
visualizza le impostazioni del test
della memoria.
boottest on
Attiva tutti i test d’avvio. Questa è
l’impostazione consigliata da HP,
anche se si riconosce che le esigenze
dell’utente potrebbero richiedere la
disattivazione di alcuni test d’avvio.
boottest off
Disattiva tutti i test d’avvio. Non è
consigliabile disattivare tutti i test.
boottest nome_test on
Attiva il test specificato (nome_test).
Ad esempio: boottest io_hw on
attiva il test d’avvio dell’hardware
I/O.
boottest nome_test off
Disattiva il test specificato
(nome_test). Ad esempio: boottest
Chipset on disattiva il test d’avvio
dei chipset.
3. Ripetere il passo 2 finché le impostazioni non sono quelle desiderate,
quindi riavviare il sistema.
Configurazione dei test d’avvio da un sistema in esecuzione
I test di SpeedyBoot sono configurabili con tre opzioni di setboot:
-v
Capitolo 5
Visualizza la tabella dello stato delle impostazioni dei
test di SpeedyBoot.
513
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
-t nome_test=valore
Modifica il valore nella memoria non volatile del test
nome_test in valore per tutti gli avvii successivi. Le
modifiche sono riportate nelle colonne Current e Next
Boot della tabella SpeedyBoot.
nome_test
Una delle seguenti parole chiave,
come descritta nella Tabella 5-2 a
pagina 508:
•
•
•
•
•
•
•
•
valore
Uno tra:
•
•
•
NOTA
all
SELFTESTS
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
on
Abilita il test.
off
Disabilita il test.
default
Reimposta il test ai valori
predefiniti di sistema, mostrati
nella colonna Defaults della
tabella di SpeedyBoot.
L’opzione -t option (t minuscola) è supportata
solamente nei sistemi HP 9000. Per modificare le
impostazioni di SpeedyBoot per tutti gli avvii successivi
di un server HP Integrity, utilizzare l’ambiente di preavvio, la shell EFI. Per i dettagli, Vedere
“Configurazione dei test di sistema d’avvio con la shell
EFI (solo per server HP Integrity)” a pagina 512.
-t nome_test=valore
Modifica il valore per il test nome_test solo per l’avvio
di sistema successivo. Le modifiche sono riportate nella
colonna Next Boot della tabella SpeedyBoot. I
cambiamenti non modificano la memoria non volatile,
514
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
perciò i valori permanenti, mostrati nella colonna
Current, saranno reimpostati dopo l'avvio. nome_test
e valore sono gli stessi dell’opzione -t.
Uso di setboot per la configurazione delle impostazioni di
SpeedyBoot
Il seguente esempio esteso mostra i risultati di varie modifiche alla
tabella di stato di SpeedyBoot. E’ una buona idea includere l’opzione -v in
ogni comando in modo da visualizzare la tabella dopo l'effettuazione delle
modifiche.
Cominciamo nello stato predefinito, off (CEC non è supportato in questo
sistema di esempio, così il suo valore predefinito è off e non può essere
modificato).
# setboot -t all=default -v
Primary bootpath : 10/0.0.0
Alternate bootpath : 10/12/5.0.0
Autoboot is ON (enabled)
Autosearch is OFF (disabled)
TEST
---all
SELFTESTS
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
CURRENT
------partial
on
on
on
on
on
on
off
SUPPORTED
--------partial
yes
yes
yes
yes
yes
yes
no
DEFAULT
------partial
on
on
on
on
on
on
off
NEXT BOOT
--------partial
on
on
on
on
on
on
off
Se è necessario avviare il sistema un certo numero di volte per qualche
tipo di installazione o aggiornamento, è possibile velocizzare questa fase
se si disabilitano tutti i test.
# setboot -t all=off -v
Primary bootpath : 10/0.0.0
Alternate bootpath : 10/12/5.0.0
Autoboot is ON (enabled)
Autosearch is OFF (disabled)
TEST
---all
SELFTESTS
Capitolo 5
CURRENT
------off
off
SUPPORTED
--------partial
yes
DEFAULT
------partial
on
NEXT BOOT
--------off
off
515
Amministrazione di un sistema: Avvio e spegnimento
Avvio dei sistemi
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
off
off
off
off
off
off
yes
yes
yes
yes
yes
no
on
on
on
on
on
off
off
off
off
off
off
off
I valori precedenti saranno ora modificati per impostare l'avvio normale
in modo che esegua solo i test late_cpu e full_memory, omettendo i test
più lenti early_cpu e quello PDH:
# setboot -t late_cpu=on -t full_memory=on -v
Primary bootpath : 10/0.0.0
Alternate bootpath : 10/12/5.0.0
Autoboot is ON (enabled)
Autosearch is OFF (disabled)
TEST
---all
SELFTESTS
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
CURRENT
------partial
partial
off
on
partial
on
off
off
SUPPORTED
--------partial
yes
yes
yes
yes
yes
yes
no
DEFAULT
------partial
on
on
on
on
on
on
off
NEXT BOOT
--------partial
partial
off
on
partial
on
off
off
Sarà infine configurato l’avvio successivo in modo che esegua tutti i test,
e quindi esegua solo il test late_cpu durante i successivi avvii.
# setboot -t full_memory=off -T all=on -v
Primary bootpath : 10/0.0.0
Alternate bootpath : 10/12/5.0.0
Autoboot is ON (enabled)
Autosearch is OFF (disabled)
TEST
---all
SELFTESTS
early_cpu
late_cpu
FASTBOOT
full_memory
PDH
CEC
516
CURRENT
------partial
partial
off
on
partial
on
off
off
SUPPORTED
--------partial
yes
yes
yes
yes
yes
yes
no
DEFAULT
------partial
on
on
on
on
on
on
off
NEXT BOOT
--------partial
on
on
on
on
on
on
off
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Impostazione delle informazioni iniziali sul sistema
Impostazione delle informazioni iniziali sul
sistema
Al primo avvio del sistema dopo l’installazione di HP-UX, sarà eseguito
uno speciale script di configurazione (chiamato /sbin/set_parms) per
richiedere i valori di certi parametri che il sistema ha bisogno di conoscere
per definire la propria posizione nel mondo. La maggior parte di questi
valori si riferisce alle reti. Ad esempio:
•
L’host name del sistema
•
L’Internet Protocol (IP) Address del sistema
•
La subnet mask del computer
I valori di sistema necessari non di rete comprendono:
•
Il valore di timezone per il sistema
•
Informazioni sul tipo di carattere
•
Se il sistema dispone o meno di una console grafica
I valori di sistema impostati mediante set_parms rappresentano dati che
cambiano raramente (o mai). Quindi, dopo avere eseguito set_parms
automaticamente la prima volta, non sarà più eseguito una seconda volta.
Se si dovesse spostare il sistema, o fare qualcosa che richiede la modifica
dei valori dei parametri di sistema:
Punto
Capitolo 5
1. Eseguire il login al sistema come superutente.
517
Amministrazione di un sistema: Avvio e spegnimento
Impostazione delle informazioni iniziali sul sistema
Punto
2. Eseguire lo script:
/sbin/set_parms opzione
dove opzione è una delle seguenti voci:
Tabella 5-4
Parametri di sistema
opzione
518
Descrizione
hostname
Nome unico del sistema. Questo nome host deve avere
una lunghezza di otto caratteri o inferiore, contenere
soltanto caratteri alfabetici, numeri, underscore, o
trattini e deve iniziare con un carattere alfabetico.
ip_address
Indirizzo del protocollo Internet. Se è installata una
rete, questo è un indirizzo con quattro componenti
numerici, ciascuno dei quali è separato da un punto
con ciascun numero compreso tra 0 e 256. Un esempio
di indirizzo IP è: 255.32.3.10. Nel caso in cui non vi
fosse una rete installata, non sarà richiesto di inserire
l’indirizzo IP.
timezone
Fuso orario dell’ubicazione in cui si trova il sistema.
addl_netwrk
Parametri di rete aggiuntivi. Questo consente di
configurare i parametri di rete aggiuntivi, come la
maschera di sottorete, il gateway di rete, l’indirizzo IP
del gateway di rete, il nome del dominio locale, il nome
host del server Domain Name System (DNS),
l’indirizzo IP del server DNS e il nome del dominio del
Network Information Service.
font_c-s
Servizio dei tipi di carattere di rete. Questo consente
di configurare la workstation perchè sia un client o un
server di tipi di carattere. In qualità di client di tipi di
carattere, la workstation usa i file dei tipi di carattere
di un server di rete invece di usare i tipi di carattere
del proprio disco rigido, risparmiando così spazio.
L’uso della RAM del sistema è ridotto per i client dei
tipi di carattere, ma aumenta per i server di tipi di
carattere.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Personalizzazione dell’avvio e dello spegnimento
Personalizzazione dell’avvio e dello
spegnimento
Questa sezione spiega come far sì che applicazioni e servizi si avviino
automaticamente all’avvio e si arrestino automaticamente allo
spegnimento.
Per automatizzare l’avvio e l’arresto di un sottosistema, è necessario fare
tutto quanto segue:
1. Decidere a quale livello di esecuzione si desidera che il sottosistema si
avvii o si arresti.
Normalmente, i sottosistemi sono arrestati al livello di esecuzione più
basso rispetto a quello a cui sono stati avviati, per cui un sottosistema
avviato al livello d’esecuzione 3, sarà arrestato al livello d’esecuzione
2. Probabilmente si desidererà avviare il sottosistema al livello 1, 2 o
3.
In genere, i livelli di esecuzione eseguono le seguenti funzioni:
Livello di esecuzione 1: configurazione minima di sistema
Livello di esecuzione 2: servizi multiutente, eccetto server NFS
Livello di esecuzione 3: server NFS (per esportare file system locali)
Per i dettagli, vedere HP-UX 10.0 File System Layout White Paper
all’indirizzo http://docs.hp.com.
Per vedere esattamente che cosa si sta avviando sul sistema a ogni
livello di esecuzione, guardare /sbin/rcn.d/S*, dove n è il livello di
esecuzione.
A meno che il sistema dipenda da servizi di esportazione di NFS, quali
rpc.mountd e nfsd, il livello di esecuzione 2 è un buon livello a cui
avviarlo.
Il livello d’esecuzione 2 è una scelta sicura e, al contempo,
normalmente logica, in quanto ha un segnaposto che HP garantisce
non sarà sovrascritto da future versioni di HP o software di terze
parti; agli altri livelli di esecuzioni questo tipo di segnaposto, e la
relativa garanzia, non esistono.
Capitolo 5
519
Amministrazione di un sistema: Avvio e spegnimento
Personalizzazione dell’avvio e dello spegnimento
2. Scrivere uno script per avviare ed arrestare i sottosistemi ed uno
script di configurazione di accompagnamento per dire al processo di
avvio se questo script deve essere eseguito o meno.
Usare il modello /sbin/init.d/template; consultare l’esempio di
seguito.
3. Creare collegamenti simbolici che facciano in modo che lo script sia
eseguito al punto giusto nelle sequenze di avvio e spegnimento.
Consultare l’esempio di seguito.
4. Riavviare il sistema per accertarsi che tutto funzioni.
In un sistema carico di lavoro, ciò può rivelarsi scomodo, ma occorre
diffidare di test effettuati in un sistema diverso da quello in cui il
sottosistema effettivamente sarà in esecuzione; qualsiasi differenza
nella configurazione di avvio/spegnimento fra il sistema di test ed il
sistema di produzione potrebbe invalidare il test.
Esempio:
Punto
questo esempio mostra un modo per automatizzare l'avvio di un daemon
server, daemon_nomeprodotto_web:
1. Decidere il livello di esecuzione:
a. Vedere che cosa si avvia al livello d’esecuzione 2:
ls /sbin/rc2.d/S*
/sbin/rc2.d/S008net.sd
/sbin/rc2.d/S560SnmpMaster
/sbin/rc2.d/S100swagentd
/sbin/rc2.d/S565SnmpHpunix...
b. Vedere che cosa si avvia al livello d’esecuzione 3:
ls /sbin/rc3.d/S*
/sbin/rc3.d/S100nfs.server
/sbin/rc3.d/S100nfs.server è un collegamento a
/sbin/init.d/nfs.server, che avvia portmap, rpc.mountd, nfsd e le
funzioni relative. Dal momento che il daemon nomeprodotto_web non
ha bisogno di nessuno di essi, è sicuro avviarlo al livello 2, usando il
segnaposto numero 900 (vedere oltre).
Allo stesso modo, si arresti lo script al livello di esecuzione 1 usando il
segnaposto numero 100.
520
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Personalizzazione dell’avvio e dello spegnimento
Punto
2. Scrivere gli script di avvio/spegnimento e di configurazione.
Si può usare /sbin/init.d/template come base e creare il seguente
script di avvio/spegnimento, salvandolo come
/sbin/init.d/nomeprodotto_web:
#!/sbin/sh
PATH=/usr/sbin:/usr/bin:/sbin
export PATH
daemon_nomeprodotto_web="nomeprodotto_web"
rval=0
killproc()
{
pid=`ps -e | awk '$NF~/'"$1"'/ {print $1}'`
if [ "X$pid" != "X" ]
then
if kill "$pid"
then
echo "$1 stopped"
else
rval=1
echo "Unable to stop $1"
fi
fi
}
case $1 in
'start_msg')
# message that appears in the startup checklist
echo "Starting the nomeprodotto_web daemon"
;;
'stop_msg')
# message that appears in the shutdown checklist
echo "Stopping the nomeprodotto_web daemon"
;;
'start')
# source the configuration file
if [ -f /etc/rc.config.d/nomeprodotto_web]
then
. /etc/rc.config.d/nomeprodotto_web
else
echo "ERROR: /etc/rc.config.d/nomeprodotto_web MISSING"
fi
# Check to see if the nomeprodotto_web daemon exists,
Capitolo 5
521
Amministrazione di un sistema: Avvio e spegnimento
Personalizzazione dell’avvio e dello spegnimento
# is executable and should be started
if [ "$NOMEPRODOTTO_WEB" -eq 1 -a -x
"$NOMEPRODOTTO_WEBHOME/$daemon_nomeprodotto_web" ]
then
cd $NOMEPRODOTTO_WEBHOME
./$daemon_nomeprodotto_web
print "$daemon_nomeprodotto_web started"
else
print "failed to start $daemon_nomeprodotto_web"
rval=2
fi
;;
'stop')
killproc $daemon_nomeprodotto_web
;;
*)
echo "usage: $0 {start|stop|start_msg|stop_msg}"
rval=1
;;
esac
exit $rval
Quindi, creare un file di configurazione,
/etc/rc.config.d/nomeprodotto_web, per indicare allo script
summenzionato dove trovare il daemon nomeprodotto_web e se avviarlo
o meno (1=sì; 0=no):
#!/sbin/sh#
# v1.0 nomeprodotto_web startup/kill config
# NOMEPRODOTTO_WEB:
Set to 1 to start
#
daemon_nomeprodotto_web
# NOMEPRODOTTO_WEBHOME: home dir for nomeprodotto_web
NOMEPRODOTTO_WEB=1
NOMEPRODOTTO_WEBHOME=/msw/nomeprodotto_web/binhp
NOTA
522
Impostare la variabile di avvio (NOMEPRODOTTO_WEB in questo caso) su 0,
piuttosto che cancellare lo script, è la maniera per rimuovere un
sottosistema dalla sequenza di avvio. Ciò è particolarmente importante
nel caso di script HP o di terze parti; non modificarli, cancellarli o
spostarli; se non si vuole eseguire il corrispondente script di avvio,
semplicemente impostare a 0 la variabile dello script corrispondente in
/etc/rc.config.d/.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Personalizzazione dell’avvio e dello spegnimento
Punto
3. Creare collegamenti simbolici che facciano in modo che lo script sia
eseguito al punto giusto nelle sequenze di avvio e spegnimento.
Dato che HP garantisce che gli script che usano il numero 900 nel livello
di esecuzione 2 non saranno sovrascritti quando si aggiorna il sistema o si
aggiunge software di terze parti, e che il livello di esecuzione 2 è un buon
punto per avviare il daemon nomeprodotto_web, abbiamo assegnato al
nostro script il numero 900 e lo abbiamo collegato dentro la directory
/sbin/rc2.d :
ln -s /sbin/init.d/nomeprodotto_web
/sbin/rc2.d/S900nomeprodotto_web
La S indica “start” e 900 stabilisce l’ordine di avvio nel
livello di esecuzione, in modo che lo script sia eseguito tardi (ultimo, al
momento) nel livello di esecuzione 2.
Allo stesso modo, HP garantisce che gli script che usano il numero 100 nel
livello di esecuzione 1 non saranno sovrascritti, al nostro script è stato
asseganto il numero 100 e lo abbiamo collegato alla directory
/sbin/rc1.d, questa volta con una lettera di codice K (per “kill”):
ln -s /sbin/init.d/nomeprodotto_web
/sbin/rc1.d/K100nomeprodotto_web
Ciò significa che allo spegnimento del sistema il daemon
nomeprodotto_web si arresta dopo la maggior parte delle altre funzioni
nel livello d’esecuzione 1.
Punto
4. Sottoporre a test lo script stesso e verificare che funzioni correttamente
nei processi di avvio e spegnimento.
Eseguire /sbin/init.d/nomeprodotto_web più volte “manualmente”
per metterlo a punto, quindi installarlo (come descritto nel passaggio 3
qui sopra) in un sistema di prova che sia stato riavviato, per verificare che
il daemon si avvii e si arresti correttamente, quindi da ultimo installarlo
nel sistema di produzione e riavviarlo.
Capitolo 5
523
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Spegnimento dei sistemi
•
“Panoramica dei processi di spegnimento” a pagina 524
•
“Tipi di spegnimento” a pagina 526
—
—
—
—
•
“Spegnimento normale (pianificato)” a pagina 526
“Guasto dell’alimentazione” a pagina 530
“Spegnimenti non puliti” a pagina 531
“Crash di sistema / Attacchi di panico di HP-UX” a pagina 532
“Considerazioni speciali per lo spegnimento di alcuni sistemi” a
pagina 532
—
—
—
—
—
—
—
“Server della posta” a pagina 533
“Server di nomi” a pagina 533
“Gateway di rete” a pagina 533
“File server NFS” a pagina 534
“Client NFS” a pagina 534
“Server cluster NFS” a pagina 535
“Client cluster NFS” a pagina 535
•
“Evitare uno spegnimento quando possibile” a pagina 535
•
“Avvio dei sistemi” a pagina 470
Panoramica dei processi di spegnimento
ATTENZIONE
524
NON togliere corrente a un sistema HP-UX senza averlo prima spento
correttamente! Anche se la maggior parte dei moderni sistemi si spengono
correttamente premendo il pulsante di alimentazione, per sicurezza non
presumere che il proprio lo faccia. Utilizzare invece il comando
/usr/sbin/shutdown.
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Ci sono molte ragioni importanti per questo avvertimento:
❏
Mentre HP-UX è in esecuzione, le informazioni riguardanti le
modifiche recenti al file system sono memorizzate nella cache.
Periodicamente i buffer di memoria nella cache sono scritti nel disco
dal programma chiamato sync. Se le informazioni sulle modifiche del
file system sono in memoria e non sono ancora state scritte nel disco
quando il sistema si spegne, il file system nel disco è incoerente con
l'“immagine generale” di come il file system deve comparire (puntatori
che puntano ai luoghi sbagliati, inodi non correttamente aggiornati,
ecc…).
❏
Al sistema potrebbero essere collegati degli utenti da ubicazioni
remote. Questi utenti potrebbero essere nel mezzo di un lavoro
importante quando si spegne il sistema. Di conseguenza, il loro lavoro
potrebbe essere interrotto e dai dati importanti andare persi.
❏
Se il sistema è in rete, potrebbe svolgere delle importanti funzioni di
rete, come essere un gateway di rete, un server di file, o un server di
nomi di rete. Spegnere un sistema può avere conseguenze che
travalicano il fine di quel sistema.
Esempio
Nella rete d’esempio MSW (consultare “La rete MSW (Generalità)” a
pagina 62), il computer denominato flserver è un membro sia della
sottorete 15.nn.xx che della sottorete 15.nn.yy (sottoreti). Esso funge
da computer gateway di rete. Se non fosse in esecuzione, i sistemi
nella sottorete 15.nn.xx non potrebbero comunicare con i sistemi nella
sottorete 15.nn.yy.
Pronti . . . Attenti . . . Via!
Come nella famosa espressione che dà il via a molte gare di corsa, esiste
un ordine preciso da seguire per spegnere e avviare il sistema, o si
potrebbero verificare dei problemi.
Allo spegnimento di un sistema HP-UX:
1. Per prima cosa, notificarlo a tutti quelli che possono essere interessati
dallo spegnimento, dando loro la possibilità di completare il lavoro in
corso e, se necessario, smontare i file system di cui si era eseguito il
montaggio NFS dal sistema.
Capitolo 5
525
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
2. Quindi, chiudere tutti i programmi che possono essere in esecuzione
(salvare i file, chiudere le finestre dei modificatori, chiudere i
programmi di modellazione grafica, ecc…).
3. Infine, usare il programma shutdown per spegnere il sistema. Il
programma shutdown per prima cosa sincronizza i file system
(scrive nel disco tutti i buffer di memoria e aggiorna il superblocco di
ogni file system interessato) così i file system saranno correttamente
intatti quando il sistema si riavvierà.
Tipi di spegnimento
Esistono vari tipi di spegnimento, sia pianificato sia non pianificato.
Questa sezione si occupa di molte situazioni comuni:
•
Uno “Spegnimento normale (pianificato)” a pagina 526
•
“Guasto dell’alimentazione” a pagina 530
•
“Crash di sistema / Attacchi di panico di HP-UX” a pagina 532
•
“Spegnimenti non puliti” a pagina 531
Spegnimento normale (pianificato)
Si spera che la maggior parte degli spegnimenti del sistema sarà di questo
tipo. Con uno spegnimento normale, si avrà tempo di preparare il sistema
e i suoi utenti così da poterlo riavviare e poter continuare il lavoro senza
perdita di dati e con il minor disturbo possibile.
Come menzionato nella panoramica di questa sezione, è importante non
spegnere semplicemente il computer (come si può fare con un personal
computer).
Al fine di aumentare al massimo le prestazioni del sistema, i dati usati di
recente dai file su disco sono tenuti e aggiornati nella memoria.
Periodicamente (ogni 30 secondi per impostazione predefinita), sarà
eseguito il programma chiamato sync, per assicurarsi che i file system nel
disco siano mantenuti aggiornati in caso di uno spegnimento non
pianificato (i file system nel disco sono sincronizzati con le modifiche
basate sulla memoria). Ma, se sono trascorsi 29 secondi dall’ultima
esecuzione di sync, ci sono probabilmente delle modifiche basate sulla
memoria che non sono ancora state rispecchiate su disco. Se il sistema
subisse un crash adesso, ciò potrebbe causare incoerenze nelle strutture
del file system nel disco (che, sebbene non sia di solito così, potrebbero
causare file danneggiati o perdita di dati).
526
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Inoltre, saranno interessati gli utenti del sistema e di altri sistemi nella
rete che dipendono dal sistema per qualche risorsa. E’ sempre meglio
notificare loro in anticipo qualsiasi spegnimento pianificato, cosicché
possano pianificare lo spegnimento e ridurre al minimo l'impatto sul loro
lavoro.
La procedura di base per uno spegnimento pianificato del sistema è:
Punto
1. Notificarlo a chiunque possa essere interessato dallo spegnimento del
sistema. Questo si può fare mediante:
•
e-mail
•
il comando wall (vedere wall (1M)) — avvisa solo gli utenti del proprio
sistema, non gli utenti di altri sistemi che possono essere interessati
dallo spegnimento del sistema
•
telefonata, o comunicazione di persona
In qualsiasi maniera lo si faccia, il punto di importanza vitale è notificarli
quanto più possibile in anticipo dello spegnimento pianificato. Se li si
notifica quanto più possibile in anticipo dello spegnimento pianificato, è
una buona idea fornire loro un richiamo all'avvicinarsi del momento dello
spegnimento.
Punto
2. Una volta che tutti siano stati informati e abbiano avuto la possibilità di
prepararsi per lo spegnimento, eseguire il comando shutdown per dare
inizio a uno spegnimento ordinato del sistema.
Esistono fondamentalmente tre tipi di spegnimento di sistema:
1. Spegnimento con riavvio immediato (usare l’opzione -r del comando
shutdown)
2. Spegnimento con arresto del sistema (usare l’opzione di -h del
comando shutdown)
3. Mettere il sistema in modalità utente singolo per manutenzione del
sistema (non usare né l’opzione -r, né l’opzione -h)
Capitolo 5
527
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Varianti comuni del comando shutdown
Si forniscono alcuni esempi di comandi shutdown per mostrare ogni tipo
di spegnimento del sistema. Per impostazione predefinita, shutdown è un
programma interattivo. Oltre ad indicare a shutdown se si desidera o
meno arrestare o riavviare il sistema, le informazioni omesse dalla riga di
comando saranno richieste al prompt. Se non si indica a shutdown che si
intende arrestare o riavviare il computer, esso presumerà che si intenda
portare il sistema in modalità singolo utente.
Esempio 5-29
Spegnimento e riavvio
Per spegnere immediatamente il sistema e riavviarlo:
/sbin/shutdown -r 0
Esempio 5-30
Spegnimento e riavvio con attesa
Per spegnere il sistema e riavviarlo immediatamente dopo aver concesso
agli utenti del sistema 3 minuti (180 secondi) per ordinare il proprio
lavoro ed eseguire il logout:
/sbin/shutdown -r 180
Esempio 5-31
Spegnimento ed arresto
Per spegnere immediatamente il sistema ed arrestarlo cosicché si possa
togliergli corrente in tutta sicurezza.
/sbin/shutdown -h 0
Esempio 5-32
Spegnimento in modalità utente singolo
Per spegnere il sistema in modalità utente singolo, non usare le opzioni -h
o -r del comando shutdown. E' concesso un intervallo: in questo esempio
7 minuti (420 secondi):
/sbin/shutdown 420
Esempio 5-33
Riavvio di server cluster NFS
Per riavviare un sistema server cluster NFS senza spegnere anche i suoi
client:
/sbin/shutdown -o -r
528
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
NOTA
E’ necessario avere l’autorizzazione per spegnere un sistema HP-UX!
Ovviamente, questo comando può avere delle serie conseguenze e deve
perciò essere usato con cautela. Non è un comando che chiunque dovrebbe
essere in grado di usare.
L'autorizzazione a spegnere il sistema è di norma riservata solo ai
superutenti. Tuttavia, esiste un meccanismo che è possibile usare per
dare l'autorizzazione ad altri utenti perché possano, in caso di necessità,
spegnere il sistema quando un superutente non è disponibile. Il file
/etc/shutdown.allow consente ai superutenti di specificare chi
disponga dell’autorizzazione a spegnere il sistema in loro assenza. Per i
dettagli, consultare la manpage shutdown (1M).
Se eseguito, shutdown assicura uno spegnimento ordinato del sistema,
facendo le seguenti cose:
•
Reimposta la variabile di ambiente PATH al valore:
/usr/bin:/usr/sbin:/sbin
•
Reimposta la variabile di ambiente IFS al valore:
spazio tabulazione nuova_riga
Capitolo 5
•
Verifica che l’utente che sta cercando di spegnere il sistema sia
autorizzato a farlo (controlla il file /etc/shutdown.allow).
•
Rende la directory di root (/) la directory attualmente operativa.
•
Esegue il comando sync per assicurarsi che le modifiche del file
system ancora in memoria siano aggiornate nei superblocchi e nelle
strutture di file system su disco. Si tratta di una delle funzioni più
importanti dello spegnimento!
•
Imposta l’ID dell’utente reale come quello del superutente (per
informazioni sugli ID dell’utente, consultare setuid (2)).
•
Invia un messaggio di diffusione a tutti gli utenti al momento collegati
al sistema, comunicando loro che il sistema sta per essere spento. Per
questo esiste un messaggio predefinito, ma è possibile specificarne
uno personalizzato.
•
È eseguito /sbin/rc per spegnere i sottosistemi, smontare i file
system, ed eseguire altre procedure per portare il sistema al livello di
esecuzione 0, al quale si può togliere la corrente in piena sicurezza se
non si intende riavviare immediatamente.
529
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
•
✓
Se il sistema è un server cluster NFS, prima che si esegua
/sbin/rc, si usa l’argomento opzionale -o per determinare se
riavviare o meno anche i client cluster NFS serviti dal sistema.
Per impostazione predefinita, (quando -o non è specificato),
saranno a loro volta riavviati tutti i client serviti dal server.
Quando -o è specificato, sarà riavviato solo il server. Una volta
presa la decisione se riavviare i client o meno, si esegue /sbin/rc.
✓
Se il sistema è un client cluster NFS, /sbin/rc porta il sistema
al livello di esecuzione 2 (lo stato singolo utente non è permesso su
un client cluster NFS).
Infine, se il sistema non è un client cluster NFS e non si sta spegnendo
il sistema in modalità utente singolo, (consultare “Modalità utente
singolo” a pagina 532), si esegue il programma /sbin/reboot per
arrestare il sistema o riavviarlo se erano specificate le opzioni -h o -r,
rispettivamente.
Guasto dell’alimentazione
Non tutti gli spegnimenti possono essere programmati. Un guasto inaspettato dell’alimentazione è un esempio di spegnimento non programmato.
Molti sistemi HP-UX possono essere dotati di gruppi di continuità (UPS)
per consentire di mantenere l'alimentazione ai sistemi per un breve
periodo dopo un guasto alla fonte primaria di alimentazione del computer.
Se il guasto all'alimentazione è di breve durata, i sistemi dotati di UPS
non risentiranno in alcun modo del guasto stesso. Se si ha l’impressione
che il guasto all’alimentazione possa durare a lungo, si può usare
l'intervallo fornito dal gruppo di continuità per eseguire uno spegnimento
normale. Consultare il “Spegnimento normale (pianificato)” a pagina 526.
I computer dotati di gruppi di continuità HP PowerTrust possono essere
anche monitorati da uno speciale daemon chiamato upsmond, che, quando
in esecuzione, risiede sempre in memoria (non è passibile di scambio).
upsmond comunica con i gruppi di continuità e, quando l’alimentazione è
mancata più a lungo di un periodo preconfigurato, upsmond eseguirà
automaticamente uno spegnimento pulito del sistema.
Non tutti i sistemi HP-UX sono dotati di gruppi di continuità. Se non lo
sono, uno spegnimento non pulito sarà la conseguenza probabile di un
guasto all’alimentazione. Non sarà eseguita nessuna copiatura di
memoria ed è possibile che i buffer di modifiche di disco recenti risiedano
ancora in memoria e non siano state scritti sul disco dal programma sync.
Per i dettagli, consultare “Spegnimenti non puliti” a pagina 531.
530
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Quando si verifica un guasto dell'alimentazione, è buona prassi spegnere
gli interruttori dell'alimentazione del computer e delle sue periferiche.
Questo ridurrà il rischio che una sovratensione dell'alimentazione
danneggi le apparecchiature al ritorno della corrente. Dopo il ripristino
dell’alimentazione, seguire le normali procedure di avvio. Consultare il
“Avvio standard” a pagina 472.
Spegnimenti non puliti
Quando si spegne un sistema in maniera corretta, tutti le modifiche del
file system basate sulla memoria sono scritte nel disco e i file system nel
disco sono contrassegnati come puliti. Se tuttavia si verifica uno
spegnimento non corretto (ad esempio, un guasto dell’alimentazione), le
informazioni basate sulla memoria potrebbero non essere scritte su disco
e perciò alcuni file system non avranno il loro indicatore “pulito”
impostato (in quanto, in realtà, potrebbero avere problemi strutturali
come risultato del fatto che le informazioni basate sulla memoria non sono
state scritte su disco).
Quando ciò accade, ha luogo una speciale attività durante il processo di
avvio. Il file system consistency checker (fsck), al momento del controllo
degli indicatori puliti su tutti i file system rappresentati nel file
/etc/fstab, individuerà che esistono file system per cui non è impostato
l’indicatore pulito. Per questi file system, fsck effettuerà un’operazione di
controllo/riparazione per ubicare e risolvere qualsiasi problema risultasse
dallo spegnimento non corretto. In quasi tutti i casi, fsck è in grado di
trovare e risolvere tutti i problemi strutturali e i file system possono
essere contrassegnati come puliti.
In rare occasioni il danno al filesystem supera quanto fsck può correggere
automaticamente. In questi casi fsck terminerà con un messaggio di
errore che indica che sarà necessario usarlo in modalità interattiva per
risolvere i problemi più gravi. In questi casi è probabile una perdita di
dati. Prima di usare fsck in modo interattivo, provare a effettuare il
backup di tutti i file critici spostandoli su un altro file system o effettuandone il backup su nastro, se una copia di backup ancora non esiste.
Per un esame più dettagliato dell’utilizzo di fsck per il ripristino dei
filesystem, consultare le seguenti manpage:
Capitolo 5
•
fsck (1M)
•
fsck_cachefs (1M)
•
fsck_hfs (1M)
•
fsck_vxfs (1M)
531
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Crash di sistema / Attacchi di panico di HP-UX
Sebbene accada raramente, i sistemi possono talvolta spegnersi
inaspettatamente da soli, in un evento chiamato crash di sistema o panico
di sistema. Per una descrizione dettagliata di cosa fare se ciò accade e per
una spiegazione di che cosa avviene a seguito di un crash di sistema,
consultare “Spegnimenti anomali del sistema” a pagina 536.
Modalità utente singolo
Nei sistemi HP-UX è disponibile una particolare modalità operativa,
chiamata modalità utente singolo. Quando il sistema è in modalità utente
singolo, è attiva solo la console mentre molti sottosistemi per HP-UX non
sono in esecuzione. Questa modalità si usa normalmente per la
manutenzione del sistema. Esistono due modi per mettere il sistema in
modalità utente singolo.
1. Avviare il sistema in modalità utente singolo (per maggiori
informazioni sull’avvio dei server Itanium nella modalità utente
singolo, vedere “Avvio in modalità utente singolo” a pagina 489,
oppure per informazioni sull’avvio dei server PA-RISC in modalità
utente singolo, vedere “Avvio in modalità utente singolo” a
pagina 503).
2. Spegnere il sistema in modalità utente singolo da una modalità di
esecuzione più alta (consultare “Spegnimento normale (pianificato)” a
pagina 526).
Considerazioni speciali per lo spegnimento di alcuni
sistemi
Nel mondo odierno dei computer in rete, persone che non sono utenti
diretti del sistema possono nondimeno essere interessati dalla sua
assenza dalla rete (qualora sia stato spento). Se il sistema svolge una delle
seguenti funzioni, è necessario, quando si programma uno spegnimento,
almeno tenere in considerazione l’impatto sugli utenti di altri sistemi.
Se possibile, occorre provare a comunicare loro in anticipo che ne saranno
interessati, cosicché si possano preparare all'evento.
532
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Server della posta
Se il sistema è un server della posta, riceve posta elettronica per conto
degli utenti e spesso è anche il computer che ne gestisce la posta in uscita.
Quando il sistema è spento, la posta entrante è solitamente trattenuta da
altri computer nella rete, in attesa di poterla consegnare quando il
sistema sarà nuovamente in linea. Se il computer rimane spento per un
lungo periodo di tempo, è possibile che i mittenti della posta elettronica
destinata ad utenti del computer si vedano rispedire indietro la propria
posta come non consegnabile.
E naturalmente gli utenti che ricevono posta elettronica attraverso il
sistema non saranno in grado di farlo mentre questo è spento.
Server di nomi
Se il computer è un server di nomi (ad esempio, un server di nomi DNS),
è responsabile della traduzione di nomi di alias di computer in indirizzi di
protocollo internet per i propri utenti e per coloro che hanno configurato i
propri sistemi per usare il computer come proprio server di nomi.
Solitamente i sistemi sono configurati in modo tale da usare fonti multiple
per le informazioni di scambio di nomi, così, se il sistema è spento,
possono usare un server di nomi alternativo, un file hosts locale, o usare
direttamente indirizzi di protocollo internet per accedere a macchine
remote finché il sistema non sarà nuovamente in linea.
Si può configurare quali sistemi (o altre fonti) un computer userà per
assegnare nomi di computer ad indirizzi IP usando l'area “Networking
and Communications/DNS (BIND)/DNS Resolver” di SAM, o modificando
il file /etc/resolv.conf. Usare SAM è il metodo preferibile.
Gateway di rete
Se il computer funge da computer gateway di rete: cioè contiene più
schede di rete ed è membro di più reti (sottoreti), l’assenza del computer
dalla rete può avere un impatto enorme sulle operazioni di rete. Un
esempio è costituito dal computer denominato flserver nella rete MSW
di esempio (consultare “La rete MSW (Generalità)” a pagina 62). Quando
tale computer è spento, i computer di una sottorete non sono in grado di
comunicare con quelli di altre sottoreti, a meno che esistano altri
computer gateway che possano gestire il traffico.
Programmare con grande cura tali spegnimenti ed accertarsi che gli
utenti della rete siano avvertiti con il maggior anticipo possibile che non
potranno comunicare con i computer in altre sottoreti.
Capitolo 5
533
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
SUGGERIMENTO
Se ci sono più sottoreti nella rete, provare quando possibile a costruire
ridondanza all'interno della rete, in modo tale che si possa liberamente
mettere un computer fuori linea senza impedire il flusso di traffico di rete.
File server NFS
Se il computer è un file server NFS, altri computer della rete hanno montato uno o più dei file system del computer perché facciano parte del loro
albero di directory. Quando il sistema si spegne, i tentativi di accesso a file
o directory del sistema da parte di utenti di altri sistemi risulteranno
sospesi a tempo indefinito. Una volta che il sistema è di nuovo in linea,
sarà probabilmente necessario riavviare gli altri sistemi, prima che questi
siano nuovamente in grado di accedere ai file system del computer.
La cosa migliore da fare consiste nell’avvisare gli amministratori dei
sistemi che hanno eseguito il montaggio NFS di file system dal computer
di eseguirne lo smontaggio prima dello spegnimento del computer!
Facendolo, essi dovranno semplicemente rimontare i file system NFS dal
computer quando sarà nuovamente in linea. Non sarà necessario il
riavvio degli altri sistemi.
NOTA
Questo può produrre un effetto domino. Ad esempio, se il computer A ha
eseguito il montaggio NFS di un file system dal computer B e il computer
B deve essere riavviato perché ha eseguito il montaggio NFS di un diverso
file system dal computer C che è stato spento senza preavviso.
E’ importante che l’amministratore del computer B avverta
l'amministratore del computer A affinché smonti qualsiasi file system di
cui si sia eseguito il montaggio NFS dal computer B, oppure anche il
computer Adovrà essere riavviato come conseguenza indiretta dello
spegnimento del computer C.
Client NFS
A condizione che i client NFS non fungano anche da server NFS per altri
computer (il computer B nella nota precedente opera sia come client che
come server NFS), sarà possibile spegnere senza che ne sia interessato il
server NFS. Occorrerà semplicemente rimontare il file system dal server
NFS quando il client NFS sarà stato riavviato. Ciò avviene probabilmente
in modo automatico durante il processo di avvio.
534
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimento dei sistemi
Server cluster NFS
Se il computer è un server cluster NFS, occorre prestare attenzione al
fatto che tutti i suoi client cluster NFS saranno a loro volta riavviati
quando si spegne il server, a meno che si usi l’opzione -o del comando
shutdown.
Client cluster NFS
E’ relativamente sicuro spegnere un client cluster NFS senza che ne siano
interessati altri client del cluster, a condizione che esso non stia anche
fungendo da risorsa di rete di qualche altro tipo.
Evitare uno spegnimento quando possibile
Come descritto in precedenza, a volte è necessario uno spegnimento
normale e programmato. Ma, mano a mano che i tempi di scollegamento
del server diventano meno desiderati e accettati , la funzionalità di
aggiunta e di sostituzione in linea in molti casi può aiutare ad evitare lo
spegnimento di un server.
Aggiunta e sostituzione in linea di schede PCI (OLA/R)
Le caratteristiche di aggiunta e sostituzione in linea di schede PCI
(OLA/R) di HP-UX consentono di sostituire una scheda di interfaccia
difettosa o di aggiungere una nuova scheda d’interfaccia a un sistema in
esecuzione, senza alcun impatto sugli utenti del sistema.
Per concetti e procedure dettagliati su OLA/R, consultare il volume
Configuring HP-UX for Peripherals.
Capitolo 5
535
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
Spegnimenti anomali del sistema
•
“Panoramica del ciclo copiatura / salvataggio” a pagina 537
•
“Preparazione ad un crash di sistema” a pagina 538
— “Sistemi che eseguono release di HP-UX precedenti alla 11.0” a
pagina 539
— “Decisioni sulla configurazione di copiatura” a pagina 539
— “Definizione dei dispositivi di copiatura” a pagina 548
•
“Che cosa succede quando il sistema subisce un crash” a pagina 555
— “Sistemi che eseguono release di HP-UX precedenti alla 11.0” a
pagina 555
— “Opzioni di override dell’operatore” a pagina 555
— “La copiatura” a pagina 557
— “Il riavvio” a pagina 557
•
“Che cosa fare quando il sistema si è riavviato” a pagina 558
— “Uso di crashutil per completare il salvataggio di una copiatura” a
pagina 559
— “Opzioni savecrash per copiature compresse” a pagina 560
— “Conversione del formato delle copiature non compresse” a
pagina 560
— “Conversione del formato delle copiature compresse” a pagina 561
— “Analisi delle copiature del crash” a pagina 561
Quando il sistema subisce un crash, è importante conoscerne il motivo,
così da poter intraprendere le contromisure atte ad evitare che la cosa si
verifichi nuovamente. A volte, è facile determinare il motivo: ad esempio,
se qualcuno inciampa sul cavo che collega il computer al disco che
contiene il file system di root (scollegando il disco).
Altre volte, la causa del crash può non essere così ovvia. In casi estremi, si
potrebbe desiderare o potrebbe dover essere necessario analizzare
un'istantanea della memoria del computer al momento del blocco, o fare in
modo che lo faccia Hewlett-Packard, al fine di determinare la causa del
blocco.
536
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
Panoramica del ciclo copiatura / salvataggio
Funzionamento normale
EL
HD
AS MA
R
C STE
SI
Ripresa del
funzionamento normale
Riavvio del sistemat
ria
mo
Me
a
fisic
Elaborazione del
crash
Dischi del file
system HP-UX
riavvio dell'elaborazione
Dispositivi di copiatura
Quando il sistema subisce un crash, HP-UX prova a salvare l’immagine
della memoria fisica, o alcune parti della stessa, su ubicazioni predefinite
chiamate dispositivi di copiatura. Quindi, all’avvio successivo del sistema,
una utility speciale copia l'immagine della memoria dal dispositivo di
copiatura all'area di file system di HP-UX. Quando l’immagine della
memoria è nel file system di HP-UX, è possibile analizzarla con debugger
o salvarla su nastro per l’invio a qualcun’altro che la analizzi.
Prima della versione 11.0 di HP-UX, i dispositivi da usare come
dispositivi di copiatura dovevano essere definiti nella configurazione della
kernel e, a partire dalla versione 11.0, possono ancora esserlo. Tuttavia, a
partire dalla versione 11.0, è disponibile un nuovo e più flessibile metodo
di definizione dei dispositivi di copiatura.
Sono ora disponibili più modi per configurare i dispositivi di copiatura.
Per definire i dispositivi di copiatura ci sono tre modi usati comunemente:
Capitolo 5
•
Nella kernel (come nelle release precedenti alla 11.0)
•
Durante l'inizializzazione del sistema quando lo script di
inizializzazione per crashconf è in esecuzione (e legge le voci nel file
/etc/fstab)
537
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
•
Durante la fase di esecuzione, da un operatore o da un
amministratore che esegua manualmente il comando
/sbin/crashconf.
Preparazione ad un crash di sistema
Funzionamento normale
L
DE
SH A
A
CR STEM
SI
Il processo di copiatura esiste solo così da avere un modo per catturare ciò
che il sistema stava facendo al momento del crash. Ciò non avviene a
scopo di recupero, i processi non possono riprendere da dove si sono
interrotti, a seguito di un crash di sistema. Piuttosto, avviene a scopo di
analisi, per aiutare a stabilire i motivi del crash del sistema, così da
evitare che accada di nuovo.
Se si desidera essere in grado di catturare l’immagine della memoria del
sistema quando si verifica il crash (per analizzarla in seguito), è
necessario definire in anticipo la/e ubicazioni in cui HP-UX colloca tale
immagine al momento del crash. Questa ubicazione può essere su
dispositivi di disco locali o su volumi logici.
Ovunque si decida che HP-UX debba collocare la copiatura, è importante
disporre di spazio sufficiente in quel punto (consultare “Quanto spazio di
copiatura è necessario?” a pagina 549). In caso contrario, non tutte le
pagine saranno salvate e si potrebbe non acquisire la parte di memoria
che contiene le istruzioni o i dati che hanno causato il blocco. Se
necessario, è possibile definire più di un dispositivo di copiatura, così, se il
primo si riempie, si usa il successivo per continuare il processo di
copiatura fino a quando la copiatura non è completa o non è più
disponibile spazio definito. Per essere sicuri di avere abbastanza spazio di
copiatura, definire un’area di copiatura grande almeno quanto la
memoria fisica del computer, più un megabyte. Se si sta procedendo ad
una copiatura selettiva (che è il modo di copiatura di default nella
maggior parte dei casi), sarà necessaria una quantità di spazio molto
minore. La copiatura completa richiede uno spazio uguale alla
dimensione della memoria del computer più un piccolo extra per le
informazioni di intestazione.
538
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
Nella release HP-UX 11i versione 1.0 e release successive, è abilitata per
impostazione predefinita la copiatura compressa. Tuttavia, la
compressione della copiatura si verifica solo se le condizioni nell’ambiente
del crash sono favorevoli. Non pianificare lo spazio di memorizzazione
della copiatura in base alla compressione potenziale, piuttosto lasciare
abbastanza spazio per una copiatura completa o selettiva non compressa.
Consultare il “Copiatura compressa” a pagina 541.
Sistemi che eseguono release di HP-UX precedenti alla 11.0
In release di HP-UX precedenti alla 11.0, si ha un controllo limitato del
processo di copiatura. Si può controllare:
NOTA
•
Se una copiatura avvenga o meno (si può definire che i dispositivi di
copiatura nel file della kernel siano dump none per evitare che la
copiatura avvenga)
•
Quali dispositivi si useranno come dispositivi di copiatura
•
Se il comando savecore si esegue o meno al riavvio per copiare
l’immagine di memoria copiata nell'area di file system di HP-UX
Occorre definire i dispositivi di copiatura per il sistema quando si
costruisce la kernel. Per i dettagli su come farlo, consultare “Definizioni di
dispositivo di copiatura della kernel” a pagina 550. E, se si desidera
cambiare i dispositivi di copiatura, occorre costruire un nuovo file della
kernel ed avviarlo perché le modifiche producano effetto.
Decisioni sulla configurazione di copiatura
Mano a mano che i computer continuano ad aumentare in velocità e
potenza di elaborazione, tendono anche a crescere in dimensione della
memoria fisica. Mentre una volta un sistema con 16 MB di memoria era
considerato un sistema enorme, oggi esso è appena sufficiente per la
maggior parte delle procedure. Alcuni sistemi HP-UX odierni possono
avere terabyte di memoria. E' importante farne menzione qui perché
maggiore è la dimensione della memoria fisica del computer, maggiore
sarà il tempo necessario per copiare il suo contenuto nel disco a seguito di
un blocco del sistema (e tanto più spazio disco occuperà).
Solitamente, quando un sistema subisce un crash, è importante
riattivarlo e rimetterlo in esecuzione il più presto possibile. Se il computer
dispone di una quantità elevata di memoria, il tempo necessario alla
copiatura della memoria sul disco può essere inaccettabilmente lungo
Capitolo 5
539
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
quando si stia tentando di riattivare il sistema rapidamente. E, se capita
di conoscere già il motivo del blocco del computer (ad esempio, se qualcuno
ha accidentalmente scollegato il cavo sbagliato), la necessità di una
copiatura è scarsa o nulla.
Nelle release di HP-UX precedenti alla 11.0, si ha un controllo limitato del
processo. Occorre decidere in anticipo se si desidera o meno che avvenga
una copiatura quando il sistema subisce un crash ed occorre costruire tale
decisione nella kernel stessa. Tuttavia, a partire dalla release 11.0 di
HP-UX, è disponibile un nuovo sottosistema di copiatura in fase di
esecuzione, che darà un controllo molto maggiore sul processo di
copiatura. Un operatore alla console di sistema può persino ignorare la
configurazione al momento dell’esecuzione mentre il sistema sta subendo
un crash.
Oltre alle eventuali opzioni di cui si disponeva, ora si ha il controllo sulle
seguenti funzionalità di copiatura del crash:
•
Quanta memoria sarà copiata.
•
Configurazione della copiatura del crash al momento dell’esecuzione.
Non occorre più costruire la configurazione di copiatura nel file della
kernel o riavviare il sistema per modificare la configurazione della
copiatura del crash.
•
Se la copiatura è compressa o meno.
Queste nuove funzionalità forniscono una flessibilità molto maggiore, ma
è necessario prendere delle decisioni importanti su come si
configureranno le copiature di sistema. Occorre tenere in considerazione
tre criteri principali. Decidere quali di questi è il più importante e leggere
la sezione corrispondente. I criteri sono:
•
“Tempo di recupero del sistema” a pagina 540
•
“Integrità delle informazioni sul crash” a pagina 545
•
“Necessità di spazio su disco” a pagina 547
Tempo di recupero del sistema Usare questa sezione se il criterio più
importante è riattivare e rimettere in esecuzione il sistema il più presto
possibile. I fattori da prendere in considerazione in questo caso sono:
540
•
“Livello di copiatura: Completa, selettiva o nessuna” a pagina 541
•
“Copiatura compressa” a pagina 541
•
“Salvataggi compressi e salvataggi non compressi” a pagina 544
Capitolo 5
Amministrazione di un sistema: Avvio e spegnimento
Spegnimenti anomali del sistema
•
“Uso di un dispositivo sia per la paginazione sia per la copiatura” a
pagina 544
Livello di copiatura: Completa, selettiva o nessuna Oltre alla possibilità di
scegliere di “copiare tutto” o “non copiare nulla,” a partire dalla versione 11.0 di
HP-UX è possibile stabilire quali classi di pagine di memoria vengono copiate.
Si sta leggendo questa sezione perché il tempo di recupero è un elemento di
importanza vitale. Ovviamente, quanto minore è il numero di pagine che il
sistema deve copiare sul disco (e al riavvio, copiare nell’area del file system di
HP-UX), tanto più velocemente il sistema potrà essere rimesso in esecuzione.
Perciò, se possibile, è da evitare l'opzione di copiatura completa.