Red Hat Network Satellite 5.5 Getting Started Guide

Transcript

Red Hat Network Satellite 5.5
Getting Started Guide
Provisioning ed implementazione con il Red Hat Network Satellite
Edizione 2
Red Hat Gruppo di documentazione
Provisioning ed implementazione con il Red Hat Network Satellite
Edizione 2
Red Hat Gruppo di do cumentazio ne
Nota Legale
Copyright © 2011 Red Hat, Inc.
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus T orvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Sommario
Questo documento contiene le informazioni per l'uso della funzionalità di provisioning di kickstart con
Red Hat Network Satellite. Per maggiori informazioni di base sul Satellite consultare la Satellite User
Guide.
Indice
Indice
. . . . . . . . . .1.
Capitolo
. . Introduzione
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .
.Capitolo
. . . . . . . . .2.
. . Kickstart
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . .
2.1. Pacchetti necessari
5
2.2. Alberi kickstart
5
2.3. Profili kickstart
7
2.4. T emplating
11
2.5. Kickstart di una macchina
14
2.5.1. Kickstart da Bare Metal
14
2.5.2. Reprovisioning
16
2.5.3. Provisioning del guest virtualizzato
17
2.5.4. Provisioning per mezzo di un RHN Proxy
17
.Capitolo
. . . . . . . . .3.. .Satellite
. . . . . . . . . multipli
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
............
3.1. Inter-Satellite Synchronization
19
3.2. Sincronizzazione per organizzazione
20
3.3. Esempi di utilizzo ISS
21
.Capitolo
. . . . . . . . .4. .. Comandi
. . . . . . . . . .e. .metodi
. . . . . . . API
. . . . avanzati
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
...........
4.1. API XML-RPC
23
4.2. Cobbler
25
4.3. Koan
29
.Capitolo
. . . . . . . . .5.
. . T. .roubleshooting
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
...........
5.1. Interfaccia web
30
5.2. Anaconda
30
5.3. Messaggi di T raceback
31
5.4. Registrazione
32
5.5. Kickstart e Snippet
33
. . . . . . . . . .History
Revision
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
...........
1
2
Capitolo 1. Introduzione
Capitolo 1. Introduzione
Il Provisioning è un processo per mezzo del quale è possibile configurare una macchina virtuale o fisica
con uno stato predefinito conosciuto. Red Hat Network (RHN) Satellite esegue il provisioning dei sistemi
che utilizzano un processo kickstart. Per poter utilizzare la funzione di provisioning è necessario essere
in possesso di una o più macchine target. Esse possono essere macchine fisiche, sistemi bare metal o
macchine virtuali. Per poter usare la funzionalità di provisioning della macchina virtuale di RHN Satellite,
creare le macchine virtuali usando Xen o KVM.
Definizioni
Alcuni termini usati in questo libro:
Kickstart
Un processo di installazione automatizzato di un sistema basato su Red Hat il quale richiede
un intervento minimo, o in alcuni casi nessun intervento, da parte dell'utente. T ecnicamente
kickstart si riferisce ad un meccanismo presente nel programma di installazione di Anaconda
che permette di forniere una breve descrizione dei contenuti e della configurazione di una
macchina al programma di installazione. T ale definizione è conosciuta come Profilo kickstart.
Profilo kickstart
Il file kickstart è un file di testo che specifica tutte le opzioni necessarie per il processo kickstart
di una macchina, incluse le informazioni di partizionamento, la configurazione della rete, ed i
pacchetti da installare. Un profilo kickstart di RHN Satellite è un superset di una definizione
kickstart tradizionale di Anconda poichè l'implementazione di Satellite esegue una compilazione
tramite questo metodo. Un profilo kickstart ha bisogno di un albero kickstart.
Albero kickstart
Il software ed i file di supporto necessari per eseguire il kickstart di una macchina. Ciò viene
identificato anche come "albero di installazione". Esso rappresenta generalmente la struttura
della directory ed i file ottenuti dal dispositivo di installazione presente con una release
particolare. Usando una terminologia Cobbler, un albero kickstart è parte di una distribuzione.
PXE (Preboot eXecution Environment)
Un protocollo di livello basso che rende possibile il kickstart di macchine bare-metal
(generalmente macchine fisiche, o reali) durante l'accensione senza alcuna preconfigurazione
della macchina target. PXE si affida ad un server DHCP per informare i client sui server
bootstrap (per lo scopo di questo documento, installazioni Satellite 5.5 o più recenti). Per poter
essere usato PXE deve essere supportato nel firmware della macchina target. Sarà possibile
utilizzare la virtualizzazione e installare nuovamente le utilità di Satellite senza usare PXE,
detto questo PXE è molto utile per l'avvio di nuove macchine fisiche o per la reinstallazione di
macchine non registrate con Satellite.
Scenari di provisioning
I tipi di scenari di provisioning supportati da RHN Satellite:
Nuove installazioni
Sarà possibile eseguire il provisioning dei sistemi che in precedenza erano sprovvisti di
sistema operativo (conosciute anche come installazioni bare metal).
3
Installazioni virtuali
Satellite supporta i guest completamente virtualizzati Xen, KVM e guest paravirtualizzati Xen.
Reprovisioning
È possibile eseguire il re-provisioning di sistemi guest e fisici previa registrazione degli stessi
con la stessa istanza di Satellite. Consultare Sezione 2.5.2, «Reprovisioning».
4
Capitolo 2. Kickstart
2.1. Pacchetti necessari
Se state utilizzando una distribuzione personalizzata sarà necessario utilizzare i seguenti pacchetti
disponibili tramite qualsiasi canale rhn-tools di Red Hat Network (RHN):
koan
spacewalk-koan
Clonare un canale rhn-tools esistente per poter accedere ai suddetti pacchetti dal vostro canale
personalizzato.
Per RHN Satellite è necessario posizionare i file kernel e initrd in posizioni specifiche all'interno
dell'albero di kickstart. T uttavia queste posizioni differiscono in base alle architetture. La seguente
tabella riporta le varie posizioni:
T abella 2.1. File distribuzione necessari per architettura
Architettura
kernel
Immagine RAM disk iniziale
IBM System z
TREE_PATH/images/kernel.img
TREE_PATH/images/initrd.img
PowerPC
TREE_PATH/ppc/ppc64/vmlinuz
TREE_PATH/images/pxeboot/vmlinux
T utte le altre
architetture
TREE_PATH/images/pxeboot/vmlinuz
TREE_PATH/images/pxeboot/initrd.img
2.2. Alberi kickstart
È necessario aver installato almeno un albero kickstart sul Satellite per poter usare il provisioning di
kickstart. Satellite supporta l'installazione dell'albero kickstart sia manuale che automatica.
Procedura 2.1. Installazione automatica degli alberi kickstart
Per tutte le distribuzioni con un canale di base in RHN, gli alberi di kickstart possono essere installati
automaticamente. T ale procedura è parte di una sincronizzazione normale del canale tramite
satellite-sync.
1. Selezionare la distribuzione sulla quale basare kickstart ed indicare il canale di base insieme al
canale RHN T ools corrispondente.
Per esempio, se desiderate utilizzare Red Hat Enterprise Linux 5 con una architettura x86 sarà
necessario il canale rhel-i386-server-5 ed il canale RHN T ools corrispondente rhntools-rhel-i386-server-5.
2. Se utilizzate un Satellite collegato sincronizzatelo direttamente con i server di Red Hat usando
satellite-sync. Se Satellite è scollegato sarà necessario acquisire i dump dei canali scollegati
dai server di Red Hat ed eseguire una sincronizzazione.
3. La sincronizzazione del canale creerà automaticamente un albero kickstart corrispondente per
quella distribuzione.
Procedura 2.2. Installazione manuale degli alberi kickstart
Se desiderate eseguire il kickstart di una distribuzione personalizzata, una distribuzione non supportata
da Red Hat, o una versione beta di Red Hat Enterprise Linux, sarà necessario creare manualmente un
5
albero kickstart corrispondente. Per la distribuzione interessata sarà necessario una ISO di
installazione.
1. Copiare l'ISO di installazione sul server di Satellite e montarlo in /m nt/iso
2. Copiare i contenuti delle ISO in una posizione personalizzata. È consigliato creare una directory
all'interno di /var/satellite per tutte le vostre distribuzioni personalizzate. Per esempio
potreste copiare i contenuti della distribuzione beta di RHEL in /var/satellite/custom distro/rhel-i386-server-5.3-beta/
3. Usare l'interfaccia web di RHN Satellite per creare un canale software personalizzato. Navigate
attraverso Canali → Gestisci canali software → Crea nuovo canale e creare un canale
genitore con un nome ed una etichetta appropriata. Per l'esempio sopra riportato usare l'etichetta
rhel-5.3-beta.
4. Inviate i pacchetti software dalla posizione dell'albero sul nuovo canale software appena creato
usando il comando rhnpush:
rhnpush --server=http://localhost/APP -c 'rhel-5.3-beta' \ -d
/var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/
Le sottodirectory all'interno dell'albero potranno essere diverse a seconda della distribuzione.
5. Una volta inoltrati i pacchetti software essi potranno essere rimossi dal percorso dell'albero
tramite il comando rm . I pacchetti saranno archiviati sul server di Satellite all'interno del canale e
non risulteranno più necessari all'interno dell'albero.
rm /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/*.rpm
Nota Bene
È possibile lasciare i pacchetti software all'interno dell'albero di kickstart. Così facendo essi
potranno essere installati con il comando yum in qualsiasi momento.
6. Usare l'interfaccia web di RHN Satellite per creare una distribuzione. Andate su Sistemi →
Kickstart → Distribuzioni → crea nuova distribuzione per creare una distribuzione usando
una etichetta appropriata ed il percorso completo dell'albero (nel nostro caso
/var/satellite/custom -distro/rhel-i386-server-5.3-beta/). Selezionate il canale
di base precedentemente creato e successivamente correggere l'Installer Generation (ad
esempio Red Hat Enterprise Linux 5). Per finire selezionare Crea distribuzione
kickstart.
7. Per poter mantenere la stessa tipologia software su ambienti multipli e sui sistemi clonare, come
canale figlio del canale di base appena creato, il canale RHN T ool del canale di base esistente di
Red Hat Enterprise Linux. Per questa operazione:
a. Sull'interfaccia web di Satellite selezionare Canali → Gestisci canali software → Clona
canale
b. Selezionare il canale figlio da clonare dalla casella Clona da: e selezionare lo stato per la
clonazione.
c. Selezionare Crea canale.
d. Inserire le informazioni necessarie e selezionare il canale genitore da utilizzare per il
canale figlio clonato.
e. Selezionare Crea canale.
6
Figura 2.1. Creazione di una distribuzione kickstart
2.3. Profili kickstart
I profili kickstart specificano le opzioni di configurazione da usare per l'installazione.
È possibile creare profili kickstart usando una interfaccia wizard la quale genererà un profilo in base alle
risposte date ad una serie di domande. Essi potranno essere creati anche usando il metodo raw il quale
conferisce un controllo completo sui contenuti del profilo.
Procedura 2.3. Creazione di un profilo kickstart con un wizard
1. Selezionare Sistemi → Kickstart → Crea un nuovo profilo kickstart
2. Fornire una etichetta appropriata e selezionare il canale di base e l'albero avviabile
con kickstart desiderati
3. Selezionare il T ipo di virtualizzazione desiderato. Consultare T ipi di virtualizzazione per
maggiori informazioni sui diversi tipi di virtualizzazione. Fare clic su successivo per continuare.
4. Selezionare la posizione per scaricare il profilo kickstart. Se utilizzate una distribuzione
personalizzata inserire la posizione del proprio albero come URL (sia HT T P che FT P sono
supportati), in caso contrario usare l'opzione predefinita. Selezionare successivo per
continuare.
5. Inserire la password root e selezionare fine per completare la creazione del profilo.
7
6. Il profilo kickstart completo sarà creato. Visualizzare il profilo selezionando File di
Kickstart.
Procedura 2.4 . Creazione di un profilo kickstart con un metodo Raw
1. Selezionare Sistemi → Kickstart → Carica un nuovo file kickstart
2. Fornire una etichetta appropriata e selezionare la distribuzione desiderata
3. Selezionare il T ipo di virtualizzazione desiderato. Consultare T ipi di virtualizzazione per
maggiori informazioni sui diversi tipi di virtualizzazione.
4. Se siete in possesso di un profilo kickstart esistente caricatelo, in caso contrario inserite il profilo
kickstart nella casella Contenuti del File.
Di seguito viene riportato un esempio di kickstart raw da utilizzare come punto di partenza:
install
text
network --bootproto dhcp
url --url http://$http_server/ks/dist/org/1/ks-rhel-i386-server-5
lang en_US
keyboard us
zerombr
clearpart --all
part / --fstype=ext3 --size=200 --grow
part /boot --fstype=ext3 --size=200
part swap --size=1000
--maxsize=2000
bootloader --location mbr
timezone America/New_York
auth --enablemd5 --enableshadow
rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0
selinux --permissive
reboot
firewall --disabled
skipx
key --skip
%packages
@ Base
%post
$SNIPPET('redhat_register')
5. Il server di RHN Satellite non è in grado di gestire l'utilizzo della distribuzione specificata come
url in kickstart. Per questo motivo includere l'opzione url --url. Esso dovrebbe somigliare al
seguente:
url --url http://satellite.example.com/ks/dist/org/1/my_distro
Sostituire m y_distro con l'etichetta della distribuzione e 1 con l'id dell'organizzazione.
6. I profili kickstart raw utilizzano $http_server al posto del nome host di Satellite. Questo
parametro verrà inserito automaticamente durante la processazione del template di kickstart.
7. Lo snippet redhat_register viene usato per gestire la registrazione.
8
Figura 2.2. Kickstart raw
T ipi di virtualizzazione
T utti i profili kickstart hanno un tipo di virtualizzazione a loro associati. Questa tabella riporta le diverse
opzioni:
9
T abella 2.2. T ipi di virtualizzazione
T ipo
Descrizione
Uso
none
Nessuna virtualizzazione
Idoneo per un provisioning
normale, installazioni bare metal
e virtualizzate non Xen o KVM
(come ad esempio VMware, o
Virtage)
Guest virtualizzato KVM
Guest KVM
Usare questo tipo di
provisioning per guest KVM
Guest com pletam ente
virtualizzato Xen
Guest Xen
provisioning per guest Xen
Nota Bene
Questa opzione richiede
un supporto hardware
sull'host ma non
necessita di alcun
sistema operativo
modificato nel guest.
Guest paravirtualizzato
Xen
Guest Xen
Usare questo tipo per il
provisioning di un guest virtuale
con una modalità di
paravirtualizzazione Xen.
Questa modalità è quella più
veloce e non ha bisogno di
alcun supporto hardware a
parte un flag PAE sulla CPU del
sistema, ma necessita di un
sistema operativo modificato.
Red Hat Enterprise Linux 5
supporta i guest in modalità
paravirtualizzazione.
Host di virtualizzazione
Xen
Host Xen
provisioning per un host virtuale
con paravirtualizzazione Xen.
Gli host ed i guest
paravirtualizzati Xen sono
supportati se l'hardware è
compatibile.
I profili Kickstart creati per l'uso come host Xen devono includere il pacchetto kernel-xen nella
sezione %packages.
I profili Kickstart creati per l'uso come host KVM devono includere il pacchetto qem u nella sezione
%packages.
I sistemi completamente virtualizzati possono aver bisogno di un supporto di virtualizzazione abilitato
nel menu del BIOS del computer.
10
Nota Bene
Per maggiori informazioni su kickstart consultate il Capitolo Installazioni Kickstart nella Red Hat
Enterprise Linux Installation Guide.
2.4. Templating
Con il templating di kickstart sarà possibile includere le variabili, gli snippet, e le istruzioni di controllo del
flusso come per esempio i loop for e if nei file kickstart. Per questo processo usare il tool cheetah.
È possibile utilizzare il templating per svariati motivi ad esempio:
Per il riutilizzo di una sezione particolare di kickstart come la sezione relativa al partizionamento del
disco tra le partizioni multiple.
Se desiderate eseguire determinate azioni in %post attraverso kickstart multipli.
Definizione di uno snippet su alcuni tipi di ruoli ricoperti dal server come ad esempio il server DNS, il
server proxy ed il web server. Per esempio il web server potrà avere il seguente snippet:
httpd
mod_ssl
mod_python
Per creare un profilo del web server includere lo snippet nella sezione %package del file di kickstart.
Se desiderate che un profilo possa essere sia un web server che un server proxy includere entrambi
gli snippet nella sezione del pacchetto. Successivamente se desiderate aggiungere un altro
pacchetto allo snippet del web server, per esempio m od_perl, aggiornate gli snippet. Così facendo
tutti i profili che utilizzano lo snippet in questione verranno aggiornati dinamicamente.
Variabili
Il templating permette ad un utente di definire una variabile da usare su di un file di kickstart. Le variabili
possono essere impostate su di un livello e sovrascritte su livelli inferiori. Se si definisce una variabile
sul livello del sistema ciò sovrascriverà la variabile stessa definita sui livelli del profilo o kickstart.
Similmente, se si definisce una variabile sul livello del Profilo ciò sovrascriverà la stessa variabile se
definita sul livello dell'albero kickstart (distro).
Nota Bene
Da notare che le variabili dell'albero kickstart non possono essere definite per gli alberi kickstart
generati automaticamente come ad esempio quelli ottenuti al momento della sincronizzazione di
satellite.
Snippet
Gli snippet riutilizzano sezioni di codice tra template multipli di kickstart. Essi possono includere
numerose righe e variabili, possono essere inclusi in un profilo kickstart utilizzando il testo
$SNIPPET ('snippet_nam e'). Sarà possibile creare uno snippet per un determinato elenco di
pacchetti, uno per uno script %post particolare, o per qualsiasi testo da includere in un file kickstart.
Per gestire gli snippet andate su Sistemi → Kickstart → Snippet di Kickstart.
11
La pagina Snippet di Kickstart mostra numerosi snippet che non possono essere modificati ma
che sono disponibili a qualsiasi organizzazione. Gli snippet predefiniti possono essere usati con
kickstart scritti o caricati sul server di RHN Satellite. Gli snippet predefiniti sono archiviati sul file system
del server di RHN Satellite in /var/lib/cobbler/snippets/. È disponibile un template di kickstart
basato sul wizard in /var/lib/rhn/kickstarts/wizard/ in grado di spiegare i diversi tipi di
snippet predefiniti ed il loro impiego.
Lo snippet redhat_register è quello predefinito e può essere usato per la registrazione delle
macchine su di un server di RHN Satellite come parte di kickstart. Utilizza una variabile speciale
chiamata redhat_m anagem ent_key per la registrazione della macchina. Impostate la suddetta
variabile sul sistema o sul livello della distribuzione ed aggiungere $SNIPPET ('redhat_register')
ad una sezione %post del kickstart. Qualsiasi kickstart basato sul wizard generato dal server di RHN
Satellite includerà lo snippet nella propria sezione %post.
La scheda Snippet personalizzati permette di visualizzare e modificare gli snippet creati per la
vostra organizzazione. I nuovi snippet possono essere creati selezionando crea nuovo snippet. Gli
snippet personalizzati sono archiviati nella directory /var/lib/rhn/kickstarts/snippets/. RHN
Satellite archivia gli snippet per diverse organizzazioni in directory differenti così facendo gli snipper
personalizzati possono essere archiviati usando un nome del file simile al seguente, dove 1 è l'ID
dell'organizzazione:
$SNIPPET('spacewalk/1/snippet_name')
Per determinare il testo da usare per inserire lo snipet nel kickstart andate alla ricerca della colonna
Snippet Macro nell'elenco degli snippet oppure sulla pagina Dettagli snippet.
Nota Bene
Gli snippet sono presenti a livello globale e non condividono la stessa struttura di successione
delle variabili. È possibile utilizzare variabili all'interno degli snippet per modificarne il
comportamento a seconda del sistema che richiede il processo kickstart.
12
Figura 2.3. Snippet kickstart
Escape dei caratteri speciali
I caratteri $ e # vengono usati durante il templating per specificare le variabili e controllare il flusso. Per
utilizzare i suddetti caratteri per qualsiasi altro scopo in uno script, sarà necessario eseguire l'escape
degli stessi in modo da non essere riconosciuti come variabili. Per fare questo seguire i metodi riportati:
Posiziore un carattere di backslash (\) prima di ogni istanza di $ o # da ignorare durante il template.
Racchiudere l'intero script in #raw ... #end raw
T utti gli script %pre e %post creati usando i kickstart basati sul Wizard sono racchiusi per
impostazione predefinita in #raw...#end raw. Ciò può essere selezionato o deselezionato usando
la casella relativa al T em plate disponibile durante la modifica di uno script %post o %pre.
Includere #errorCatcher Echo nella prima riga dello snippet.
13
Esempio 2.1. Escape dei caratteri speciali nei template
Questo esempio descrive come eseguire l'escape dei caratteri speciali nei tempate di kickstart.
Inserire il seguente script bash in una sezione %post:
%post
echo $foo > /tmp/foo.txt
Se non eseguite l'escape di $ il motore per il templating cercherà di trovare una variabile chiamata
$foo fallendo poichè essa non esiste come variabile.
Il modo più semplice di eseguire l'escape del parametro $ è quello di utilizzare un carattere backslash
(\):
%post
echo \$foo > /tmp/foo.txt
Così facendo \$foo verrà interpretato come $foo.
Un secondo metodo è quello di racchiudere l'intero script bash in #raw ... #end raw:
%post
#raw
echo $foo > /tmp/foo.txt
#end raw
Il metodo finale è quello di includere #errorCatcher Echo nella prima riga di kickstart. T ale
impostazione indica al motore di templating di ignorare qualsiasi variabile non esistente e di stampare
il testo. Questa opzione viene inclusa nei kickstart basati sul wizard e può essere inclusa nei
kickstart raw creati.
2.5. Kickstart di una macchina
2.5.1. Kickstart da Bare Metal
Quando una macchina non ha alcun sistema operativo o presenta un sistema operativo incorretto essa
viene indicata come macchina bare metal. A tal proposito sono disponibili tre metodi per il provisioning di
una macchina bare metal:
Dispositivo di installazione del sistema operativo standard
Avvio con PXE
Procedura 2.5. Avvio da un dispositivo di installazione
1. Inserire il dispositivo di installazione nella macchina. Il dispositivo deve corrispondere al kickstart
che desiderate usare. Per esempio se il vostro kickstart è stato configurato in modo da usare
l'albero kickstart ks-rhel-i386-server-5-u2 usare il dispositivo di installazione i386 di Red
Hat Enterprise Linux 5.2.
2. Ad un prompt d'avvio attivare kickstart tramite il seguente comando:
14
linux ks=http://satellite.example.com/path/to/kickstart
3. Il sistema eseguirà l'avvio, scaricherà il kickstart ed eseguirà una installazione automatica.
Procedura 2.6. Avvio con PXE
Per eseguire un avvio PXE ogni sistema deve supportare l'avvio tramite PXE sul BIOS. Quasi tutti gli
hardware più rencenti dovrebbero essere in grado di supportare questa modalità d'avvio. In aggiunta, è
necessario avere un server DHCP anche se i vostri sistemi saranno configurati staticamente dopo
l'installazione.
Importante
1.
Se siete in possesso di un altro server DHCP su un altro sistema della rete allora avrete
bisogno di un accesso amministrativo al server DHCP per poter modificare il file di
configurazione DHCP.
Se le macchine risiedono su reti multiple assicuratevi che le stesse siano in grado di collegarsi al
server DHCP. A tal proposito includere il multi-homing per il server DHCP (real o trunked VLAN) e
configurare i router o gli interruttori per passare DHCP attraverso i limiti della rete.
Configurare il server DHCP in modo da indicare il server PXE impostando l'indirizzo next-server
per i sistemi da gestire con RHN Satellite.
Per utilizzare gli hostname durante l'installazione, configurare il server DHCP in modo da indicare
gli indirizzi IP e il dominio includendo le seguenti righe:
option domain-name DOMAIN_NAME;
option domain-name-servers IP_ADDRESS1, IP_ADDRESS2;
2. Come utente root sul server DHCP modificate il file /etc/dhcpd.conf inserendo una nuova
classe con le opzioni necessarie per l'esecuzione di una installazione con un avvio PXE. Per
esempio:
allow booting;
allow bootp;
class "PXE" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 192.168.2.1;
filename "pxelinux.0";
}
Questa classe eseguirà le seguenti azioni:
a. Abilitazione avvio di rete con il protocollo bootp.
b. Creazione di una classe chiamata PXE la quale se è un sistema configurato per avere PXE
con priorità più alta nel processo d'avvio, identifica se stesso come PXEClient.
c. Il server DHCP direziona il sistema sul server Cobbler con indirizzo IP 192.168.2.1
d. Il server DHCP indica il file immagine d'avvio su /var/lib/tftpboot/pxelinux.0.
3. Configurazione di Xinetd. Xinetd è un demone che gestisce una suite di servizi incluso T FT P, il
server FT P usato per il trasferimento dell'immagine d'avvio su di un client PXE.
Abilitazione Xinetd tramite il comando chkconfig:
15
chkconfig xinetd on
Alternativamente come utenti root aprire il file /etc/xinetd.d/tftp. Individuare la riga disable
= yes e modificarla in disable = no.
4. Avviare il servizio Xinetd in modo che T FT P possa servire l'immagine d'avvio pxelinux.0:
chkconfig --level 345 xinetd on
/sbin/service xinetd start
Il comando chkconfig abilita il servizio xinetd per tutti i runlevel dell'utente, mentre il comando
/sbin/service abilita immediatamente xinetd.
2.5.2. Reprovisioning
Il reprovisioning è l'atto di reinstallazione di un sistema esistente. Se eseguite un reprovisioning
attraverso una interfaccia web di RHN Satellite il sistema userà lo stesso profilo usato prima del
processo di reprovisioning. T ale operazione conserverà gran parte delle informazioni e delle
impostazioni del sistema.
Il reprovisioning può essere programmato dalla scheda Provisioning durante la visualizzazione del
sistema. Per configurare le opzioni aggiuntive andate su Configurazioni avanzate, esse
permetteranno di configurare le informazioni relative alle opzioni del kernel, sul networking e sulla
sincronizzazione dei profili dei pacchetti. La sezione Opzioni del Kernel fornisce un accesso alle
opzioni del kernel usate durante il kickstart, mentre le Opzioni Post Kernel rappresentano le
opzioni del kernel usate dopo aver completato il processo di kickstart durante il primo avvio del sistema.
Esempio 2.2. Configurazione delle opzioni del kernel e Post Kernel
Questo esempio descrive la differenza tra le opzioni del kernel e le opzioni post kernel nel processo
di configurazione per il reprovisioning.
Per stabilire un collegamento VNC per il controllo remoto di kickstart includere vnc
vncpassword=PASSWORD sulla riga Opzioni del Kernel
Se desiderate che il kernel del sistema risultante esegua l'avvio con una opzione noapic
aggiungere noapic sulla riga Opzioni Post Kernel.
Procedura 2.7. File Preservation
La funzione File Preservation può essere utilizzata per salvare i file, quindi non perderli, durante il
processo di reprovisioning. Questa funzione archivia i file momentaneamente durante il kickstart,
ripristinandoli dopo il completamento del reprovisioning.
Nota Bene
Gli elenchi per il File preservation sono solo disponibili su kickstart basati sul wizard e possono
essere usati durante il reprovisioning.
1. Andate su Sistemi → Kickstart → File Preservation → crea nuovo elenco per il file
preservation e creare un elenco di file da conservare.
2. Andate su Sistemi → Kickstart → Profili ed associate l'elenco del file preservation con un
16
kickstart selezionando il profilo desiderato.
3. Andate su Informazioni del sistema → File Preservation e selezionate l'elenco del file
preservation.
2.5.3. Provisioning del guest virtualizzato
Con RHN Satellite 5.5 il provisioning del guest virtualizzato è supportato usando le seguenti tecnologie
di virtualizzazione:
Guest virtualizzato KVM
Guest completamente virtualizzato Xen
Guest paravirtualizzato Xen
Procedura 2.8. Provisioning di un guest virtualizzato
1. Assicuratevi che il sistema host sia in possesso di un entitlement di Virutalizzazione o
Virtualization Platform .
2. Sulla pagina Sistem i, selezionare l'host virtuale corretto e successivamente Virtualizzazione
→ Provisioning. Selezionare il profilo kickstart appropriato ed inserire il nome del guest.
3. Per configurare i parametri aggiuntivi come ad esempio l'uso della cpu o la memoria del guest
selezionate il pulsante Configurazione avanzata. Sarà possibile configurare quanto di
seguito riportato:
Rete: statica o DHCP
Opzioni del kernel
Sincronizzazione profilo del pacchetto: una volta terminato il processo il sistema sincronizzerà
il proprio profilo del pacchetto con quello di un altro sistema o profilo archiviato
Assegnazione memoria: RAM (Predefinita di 512MB)
Dimensione disco virtuale
CPU virtuali (Predefinita di 1)
Bridge virtuale: Il bridge per il networking usato per l'installazione. L'impostazione predefinita è
xenbr0 per il provisioning Xen, e virbr0 per KVM.
Nota Bene
virbr0 non permetterà un networking esterno. Se desiderate un networking esterno
configurate l'host per la creazione di un bridge. T uttavia xenbr0 è un vero e proprio
bridge ed è consigliato il suo utilizzo quando possibile.
Percorso storage virtuale: Percorso per un file, volume logico LVM, directory o dispositivo a
blocchi con il quale archiviare le informazioni del disco del guest come ad esempio /dev/sdb,
/dev/LogVol00/m ydisk, VolGroup00, o /var/lib/xen/im ages/m yDisk.
4. Selezionare Program m a Kickstart e term ina.
2.5.4. Provisioning per mezzo di un RHN Proxy
È possibile altresì eseguire un provisioning usando un RHN Proxy installato e registrato con RHN
Satellite.
1. Durante il provisioning di un guest virtuale o un reprovisioning di un sistema selezionate il proxy
desiderato dal menu a tendina Seleziona Proxy Satellite
2. Per una installazione Bare Metal sostituire il fully qualified domain name (FQDN) di RHN Satellite
17
con quello del Proxy. Per esempio se l'URL per il file kickstart è:
http://satellite.example.com/ks/cfg/org/1/label/myprofile
Per eseguire kickstart con il proxy usare:
http://proxy.example.com/ks/cfg/org/1/label/myprofile
18
Capitolo 3. Satellite multipli
Inter-satellite synchronization (ISS) permette di coordinare il contenuto tra i Satellite. È possibile usare
questa funzione in modi diversi a seconda dei requisiti dell'organizzazione. Questo capitolo contiene
una sezione sui diversi tipi di utilizzo e sul metodo migliore di impostazione dell'ISS per la vostra
organizzazione.
Requisiti ISS
Di seguito sono riportati i requisiti per poter utilizzare ISS:
Due o numero maggiore di server RHN Satellite
Un minimo di un RHN Satellite popolato con almeno un canale
Per collegamenti sicuri ogni RHN Satellite slave avrà bisogno di un certificato SSL del RHN Satellite
master
3.1. Inter-Satellite Synchronization
Procedura 3.1. Configurazione del server master
Il server master viene utilizzato per determinare i file da sincronizzare per gli altri satellite.
1. Abilitare la funzione inter-satellite synchronization (ISS). Aprire il file /etc/rhn/rhn.conf ed
aggiungere o modificare la riga nel modo seguente:
disable_iss=0
2. Nel file /etc/rhn/rhn.conf individuare la riga allowed_iss_slaves=. Per impostazione
definita nessun Satellite slave viene specificato per il processo di sincronizzazione. Inserire
l'hostname di ogni server Satellite slave separato da virgole. Per esempio:
allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org
3. Salvare il file di configurazione e riavviare il servizio httpd:
service httpd restart
Procedura 3.2. Configurazione dei server slave
I server satellite slave sono macchine con un contenuto sincronizzato con il server master.
1. Per trasferire in modo sicuro il contenuto ai server slave sarà necessario avere il certificato ORGSSL del server master. T ale certificato può essere scaricato attraverso HT T P dalla directory
/pub/ di qualsiasi Satellite. Il file viene chiamato RHN-ORG-T RUST ED-SSL-CERT ma può essere
rinominato e posizionato in qualsiasi posizione sul filesystem locale dello slave, come ad esempio
sulla directory /usr/share/rhn/.
2. Visualizzare l'elenco dei canali disponibili per la sincronizzazione del server master con il
seguente comando. Così facendo verranno visualizzati i canali ufficiali di Red Hat insieme a
qualsiasi canale personalizzato disponibile:
satellite-sync --iss-parent=master.satellite.example.com --cacert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels
Sostituire master.satellite.example.com con l'hostname del server master.
19
Procedura 3.3. Esecuzione di Inter-Satellite Synchronization
Una volta configurati i server slave e master sarà possibile eseguire una sincronizzazione.
1. Sui server slave aprire il file /etc/rhn/rhn.conf con l'editor di testo preferito ed aggiungere
l'hostname del server master insieme alle informazioni sul percorso del file per il certificato SSL:
iss_parent
iss_ca_chain
= master.satellite.example.com
= /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
2. Iniziare la sincronizzazione eseguendo il comando satellite-sync:
satellite-sync -c your-channel
Nota Bene
Qualsiasi opzione della linea di comando per il comando satellite-sync sovrascriverà
qualsiasi impostazione predefinita o personalizzata nel file /etc/rhn/rhn.conf.
3.2. Sincronizzazione per organizzazione
ISS può essere usato anche per importare il contenuto su qualsiasi organizzazione specifica. Questo
processo può essere eseguito localmente o usando una sincronizzazione remota. Questa funzione è
utile per un satellite di tipo scollegato con organizzazioni multiple, dove il contenuto è ripristinato
attraverso i dump del canale o tramite una esportazione dai satellite collegati e successivamente
importandolo sui satellite scollegati. È possibile usare una sincronizzazione delle organizzazioni per
esportare i canali personalizzati da satellite collegati. La stessa sincronizzazione può essere usata per
spostare il contenuto tra organizzazione multiple.
La sincronizzazione per organizzazione presenta alcune regole per mantenere l'integrità
dell'organizzazione sorgente:
Se il contenuto sorgente appartiene all'organizzazione NULL (qualsiasi contenuto Red Hat) verrà
eseguito il default sull'organizzazione NULL anche se si specifica una organizzazione di
destinazione. T ale approccio assicura che il contenuto specificato sia sempre nella organizzazione
NULL privilegiata.
Se si specifica una organizzazione sulla linea di comando il contenuto verrà importato da quella
organizzazione.
Se non è stata specificata alcuna organizzazione il default sarà org 1.
Di seguito sono disponibili tre scenari d'esempio dove vengono usati gli ID delle organizzazioni (orgid)
per la sincronizzazione tra Satellite:
Esempio 3.1. Come importare il contenuto da un satellite master ad uno slave
In questo esempio il contenuto viene importato da un satellite master ad uno slave:
satellite-sync --parent-sat=master.satellite.example.com -c channel-name -orgid=2
20
Esempio 3.2. Come importare il contenuto da un dump esportato di una organizzazione
In questo esempio il contenuto viene importato da un dump esportato di una organizzazione
specifica:
$ satellite-sync -m /dump -c channel-name --orgid=2
Esempio 3.3. Come importare il contenuto da un Red Hat Network Hosted
In questo esempio il contenuto viene importato da un Red Hat Network Hosted (assumendo che il
sistema sia stato registrato ed attivato):
$ satellite-sync -c channel-name
3.3. Esempi di utilizzo ISS
È possibile utilizzare ISS in diversi modi in base ai requisiti della vostra organizzazione. Questa sezione
fornisce gli esempi su come utilizzare ISS insieme ai metodi per l'impostazione ed il funzionamento
relativo.
Esempio 3.4 . Staging di Satellite
Nel seguente esempio viene usato il satellite di staging per preparare il contenuto ed eseguire il
quality assurance (QA) sui pacchetti per assicurare l'idoneità dei pacchetti stessi ad un uso di
produzione. Dopo l'approvazione del contenuto il Production Satellite sincronizzerà il contenuto
proveniente dal Satellite di staging.
1. Eseguire il comando satellite-sync per sincronizzare i dati con rhn_parent
(generalmente Red Hat Network Hosted):
satellite-sync -c your-channel
2. Eseguire il seguente comando per sincronizzare i dati dal server di stage:
satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel
21
Esempio 3.5. Slave sincronizzati
In questo esempio Satellite master fornisce i dati direttamente agli slave e le modifiche regolarmente
sincronizzate.
Esempio 3.6. Contenuto personalizzato degli slave
In questo esempio il Satellite master è il canale di sviluppo dal quale viene distribuito il contenuto su
tutti i Satellite slave di produzione. Alcuni slave presentano un contenuto aggiuntivo il quale non è
presente nei canali Satellite master. I suddetti pacchetti vengono preservati ma tutti i cambiamenti del
Satellite master sono sincronizzati con il Satellite slave.
Esempio 3.7. Sincronizzazione bidirezionale
In questo ambiente due server RHN Satellite si comportano come master l'uno dell'altro e possono
sincronizzare i rispettivi contenuti.
1. Assicuratevi che entrambi i satellite siano in grado di condividere i certificati SSL.
2. Sul primo satellite aprire il file /etc/rhn/rhn.conf ed impostare l'opzione iss_parent in
modo da indicare l'hostname del secondo satellite.
3. Sul secondo satellite aprire /etc/rhn/rhn.conf ed impostare l'opzione iss_parent per
indicare l'hostname del primo satellite.
22
Capitolo 4. Comandi e metodi API avanzati
4.1. API XML-RPC
RHN Satellite 5.5 supporta il provisioning con le API XML-RPC.
Usare i seguenti metodi API per il profilo kickstart e l'amministrazione dell'albero:
23
T abella 4 .1. Metodi XML-RPC
XML-RPC Namespace
Uso
kickstart
Crea, importa e cancella i profili kickstart. Usato
anche per elencare i profili e gli alberi kickstart
disponibili.
kickstart.tree
Crea, rinomina, aggiorna e cancella gli alberi
kickstart.
kickstart.filepreservation
Elenca, crea e cancella gli elenchi per il file
preservation che possono essere associati ad un
profilo kickstart. Nota Bene: una volta creato un
elenco per il file preservation sarà possibile
associarlo ad un profilo kickstart usando il
metodo API
kickstart.profile.system .add_file_pr
eservations.
kickstart.keys
Elenca, crea, e rimuove le chiavi crittografiche
(GPG/SSL) che possono essere associate ad un
profilo kickstart.
Nota Bene
Una volta creata la chiave crittografica la
stessa può essere associata ad un profilo
kickstart utilizzando il metodo API
kickstart.profile.system .add_ke
ys.
kickstart.profile
Manipola la gamma IP, modifica l'albero kickstart
ed i canali figlio, scarica i file kickstart associati
con un profilo, manipola le opzioni avanzate e
quelle personalizzate, ed aggiunge i pre- e postscript ad un profilo kickstart.
kickstart.profile.keys
Elenca, aggiunge (associa), e rimuove le chiavi di
attivazione associate ad un profilo kickstart.
kickstart.profile.software
Manipola l'elenco dei pacchetti associati ad un
profilo kickstart.
kickstart.profile.system
Gestisce il file preservation, le chiavi
crittografiche, abilita/disabilita la gestione della
configurazione ed i comandi remoti,
l'impostazione degli schemi di partizionamento ed
imposta le informazioni del locale associate ad un
dato profilo kickstart.
Le seguenti chiamate dei metodi API sono usate per il reprovisioning di un host e la programmazione
delle installazioni del guest:
system .provision_system
system .provision_virtual_guest
24
Per maggiori informazioni sulle chiamate API consultare la documentazione relativa disponibile su
https://satellite.exam ple.com /rpc/api.
4.2. Cobbler
RHN Satellite utilizza Cobbler per il provisioning. Durante l'aggiornamento dei sistemi, degli alberi
(distribuzioni) e dei profili kickstart per il provisioning in RHN Satellite, essi verranno sincronizzati con
l'istanza di Cobbler sull'host RHN Satellite. Così facendo sarà possibile utilizzare direttamente Cobbler
per gestire il provisioning.
La seguente tabella descrive i comandi di Cobbler:
T abella 4 .2. Comandi di Cobbler
Comando
Uso
cobbler profile list
Eseguire questo comando sull'host RHN Satellite
per mostrare un elenco di profili
cobbler distro list
Mostra un elenco di alberi kickstart, kernel, RAM
disk ed altre opzioni
cobbler system list
Mostra un elenco di dati del sistema creato al
momento della programmazione di un kickstart
cobbler profile report -nam e=profile-nam e or cobbler system
report --nam e=system -nam e
Mostra un output più dettagliato relativo ad un
oggetto specifico
cobbler profile edit -nam e=profile-nam e --virt-ram =1024
Modifica vari parametri. Questo esempio
assegnerà ad ogni installazione virtualizzata di
un dato profilo 1GB di RAM.
cobbler system edit --nam e=system nam e --netboot-enabled=1
Forza la reinstallazione di un sistema durante il
successivo riavvio
cobbler system edit --nam e=system nam e --profile=new-profile-nam e -netboot-enabled=1
Assegna un sistema ad un nuovo profilo per la
reinstallazione
cobbler system find -profile=profile-nam e
Elenca tutti i sistemi assegnati ad un profilo
cobbler system find --profile="abc"
| xargs -n1 --replace cobbler system
edit \ --nam e={} --profile="def" -netboot-enabled=1
Assegna tutti i sistemi attualmente impostati sul
profilo abc sul profilo def reinstallandoli al
successivo processo di riavvio.
cobbler profile edit -nam e=profilenam e -kopts="variablenam e=3" --in-place
Imposta una variabile aggiuntiva per il templating
su di un profilo senza modificare altre variabili
cobbler system edit -nam e=system nam e -kopts="selinux=disabled asdf=jkl"
Assegna alcune variabili ai dati del sistema
trascurando quelle precedentemente impostate
cobbler profile find -nam e="* webserver* " | xargs -n1 -replace cobbler profile edit -nam e={} --profile="RHEL5-i386"
Imposta le nuove installazioni di ogni profilo
contenente webserver come stringa per l'utilizzo
di un profilo chiamato RHEL5-i386
25
Altre impostazioni di Cobbler
Modificare solo alcune impostazioni per il Cobbler in /etc/cobbler/settings. L'opzione
pxe_just_once è una di queste (descritta in Procedura 4.3, «Configurazione di Cobbler per l'uso di
PXE»). L'opzione server può essere modificata in modo da riflettere l'indirizzo o l'hostname del server
di RHN Satellite.
Dopo aver modificato /etc/cobbler/settings eseguire il seguente comando per confermare le
modifiche:
/sbin/service cobblerd restart
cobbler sync
Importante
Non modificate altre impostazioni su /etc/cobbler/settings. RHN Satellite necessita di una
configurazione particolare di questo file determinata dall'installer di RHN Satellite. In modo simile il
file /etc/cobbler/m odules.conf, il quale controlla i sorgenti di autenticazione, deve essere
inalterato ed avere la stessa impostazione creata dall'installer di RHN Satellite. In particolare il
modulo di autenticazione deve essere authn_spacewalk e non modificabile.
Procedura 4 .1. Configurazione di SELinux per il suo uso con Cobbler
Con Red Hat Enterprise Linux è installato per impostazione predefinita il supporto SELinux ed un firewall
sicuro. Per configurare correttamente un server Red Hat Enterprise Linux ed usare Cobbler, configurare
prima SELinux per abilitare i collegamenti da e per il server Cobbler.
1. Per abilitare SELinux al supporto di Cobbler impostare il valore booleano di SELinux in modo da
abilitare i componenti del servizio web HT T PD usando il seguente comando:
setsebool -P httpd_can_network_connect true
-P è essenziale poichè abilita un collegamento persistente HT T PD durante il riavvio di tutti i
sistemi.
2. Impostare le regole del contesto del file di SELinux per T FT P per servire il file immagine d'avvio
usando il seguente comando sul server di Cobbler:
semanage fcontext -a -t public_content_t "var/lib/tftpboot/.*"
3. Sarà necessario configurare IPT ables per abilitare il traffico di rete in entrata ed in uscita sul
server Cobbler.
Se siete in possesso di un insieme di regole firewall che utilizzano iptables, aggiungere le
seguenti regole per aprire le porte relative al Cobbler nel modo seguente:
Per T FT P:
/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j
ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j
ACCEPT
Per HT T PD:
26
ACCEPT
ACCEPT
Per Cobbler:
/sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j
ACCEPT
Per Koan:
ACCEPT
4. Salvare la configurazione del firewall:
/sbin/iptables-save
5. Assicuratevi che i file di configurazione siano tutti sincronizzati eseguendo il comando:
cobbler sync
6. Avviare il server di satellite:
/usr/sbin/rhn-satellite start
Avvertenza
Non avviare o arrestare il servizio cobblerd indipendentemente dal servizio di Satellite
poichè così facendo potreste causare errori o problemi di altro tipo.
Usare sempre /usr/sbin/rhn-satellite per avviare o arrestare RHN Satellite.
Procedura 4 .2. Configurazione dati del sistema Cobbler
I dati del sistema cobbler sono oggetti presenti all'interno di cobbler che controllano le attività di un
sistema e del profilo kickstart associato. Per eseguire un kickstart PXE assicurarsi prima che un profilo
kickstart di Satellite sia associato ai dati del sistema cobbler corrispondente alle macchine desiderate
per l'esecuzione di un kickstart.
1. Andate su Informazioni del sistema → Provisioning per ogni sistema e selezionate il profilo
kickstart da associare.
2. Fate clic sul pulsante Crea dati del sistem a Cobbler per eseguire l'associazione.
3. Una volta eseguita la suddetta associazione la stessa resterà attiva a meno che non abbiate
impostato pxe_just_once su vero (true) per ogni macchina. In tal caso l'associazione sarà
interrotta dopo un kickstart corretto. Consultare Procedura 4.3, «Configurazione di Cobbler per
l'uso di PXE» per maggiori informazioni.
Procedura 4 .3. Configurazione di Cobbler per l'uso di PXE
Per default Cobler viene impostato per generare configurazioni PXE; per ottenere il meglio di PXE nel
BIOS, modificare l'opzione di configurazione pxe_just_once.
27
1. Spesso l'ordine del BIOS è impostato in modo da avere PXE come priorità più alta. Ciò significa
che il sistema non eseguirà l'avvio dal disco locale se non indicato dal server PXE in modo
remoto. Questo tipo di impostazione può creare un boot loop dove il sistema eseguirà
continuamente un processo d'avvio.
Per evitare questo tipo di comportamento aprire il file /etc/cobbler/settings ed aggiungere
la seguente riga:
pxe_just_once: 1
Questa impostazione aggiunge una macro $kickstart_done nel template di kickstar la quale
indicherà al sistema di eseguire un avvio locale dopo aver completato l'installazione, e non un
avvio di rete.
2. Se utilizzate pxe_just_once: 1 e desiderate reinstallare il sistema più avanti sarà necessario
impostare il flag netboot-enabled sul sistema. Per fare questo utilizzare l'interfaccia web di RHN
Satellite o direttamente usando Cobbler. Al successivo riavvio del sistema verrà eseguita una
installazione PXE, ritornando ad un avvio tramite il disco locale fino a quando non si imposta
nuovamente il flag.
Se il BIOS è stato impostato per eseguire un avvio utilizzando prima gli hard drive locali allora non
sarà necessario abilitare pxe_just_once. T uttavia, per eseguire nuovamente il provisioning del
sistema utilizzando PXE sarà necessario azzerare l'MBR (master boot record).
Convenzione dei nomi
Per mantenere i dati sincronizzati tra RHN Satellite e Cobbler, RHN Satellite utilizza una convenzione dei
nomi per le distribuzioni e i profili. Queste convenzioni sono importanti se interagite con Cobbler usando
l'interfaccia della linea di comando.
Distribuzioni
$tree_nam e:$org_id:$org_nam e (se creato manualmente)
$tree_nam e (se sincronizzato da RHN Satellite )
Profili
$profile_nam e:$org_id:$org_nam e
Importante
Non alterate i nomi generati automaticamente da RHN Satellite. Se modificate i nomi, RHN Satellite
non sarà più in grado di gestire questi elementi.
Nota Bene
Per processi di troubleshooting Cobbler registra i dati nei log di RHN Satellite e nel file
/var/log/cobbler/
28
4.3. Koan
L'utilità koan (kickstart over a network) permette di accedere al RHN Satellite in modo remoto da host
sui quali è stato eseguito il provisioning. Koan permette all'utente di eseguire il provisioning di kickstart,
creare guest virtuali (su host virtuali) ed è in grado di elencare i kickstart disponibili dall'host di RHN
Satellite. Disponibile nel pacchetto koan.
T abella 4 .3. Comandi di Koan
Comando
Uso
m an koan
Consulta la pagina del manuale di koan
koan --replace-self -server=satellite.exam ple.org -profile=profile-nam e o koan -replace-self -server=satellite.exam ple.org -system =system -nam e
Reprovisioning di un sistema esistente. Esegue
un riavvio dopo l'esecuzione di questo comando
per installare un nuovo sistema operativo.
Utilizzabile anche per aggiornare kickstart (per
esempio per aggiornare un numero molto grande
di macchine da una versione all'altra di Red Hat
Enterprise Linux).
koan --virt -server=satellite.exam ple.org -profile=profile-nam e o koan --virt -server=satellite.exam ple.org -system =system -nam e
Provisioning di un guest virtuale
koan --list=profiles -server=satellite.exam ple.org o koan -list=system s -server=satellite.exam ple.org
Interroga Cobbler per visualizzare un elenco di
profili o sistemi disponibili per una installazione
remota
Nota Bene
Nei processi di troubleshooting Koan registra i dati in /var/log/koan
29
Capitolo 5. Troubleshooting
5.1. Interfaccia web
Domanda:Ho problemi con l'interfaccia utente di RHN Satellite. Quali file di log devo
controllare?
Risposta:In presenza di errori durante la visualizzazione, programmazione o lavorando con kickstart
utilizzando l'interfaccia utente di RHN Satellite controllare il file di log
/var/log/tom cat5/catalina.out.
Per tutti gli altri errori con l'interfaccia utente controllare /var/log/httpd/error_log.
5.2. Anaconda
Domanda:Visualizzo il seguente errore Error downloading kickstart file. Qual è il
problema e come posso correggerlo?
Risposta:Questo problema è generalmente il risultato di un errore di rete. Per individuare il problema
eseguire il comando cobbler check e consultare l'output il quale dovrebbe essere simile al
seguente:
# cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade
yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpmlist parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed
machines (default_password_crypted in /etc/cobbler/settings) is still set to
'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power
management features. install cman to use them
Se cobbler check non fornisce alcuna risposta controllare quanto di seguito riportato:
Verificare che httpd sia in esecuzione: service httpd status
Verificare che cobblerd sia in esecuzione: service cobblerd status
Verificate se siete in grado di recuperare il file di kickstart usando wget da un host diverso:
wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386u3:1:Example-Org
Domanda:Ho un errore di installazione del pacchetto il quale indica T he file chkconfig1.3.30.1-2.i386.rpm cannot be opened.. Qual è il problema e come posso
correggerlo?
Risposta:I client eseguiranno il recupero del contenuto dal RHN Satellite in base al parametro --url
presente nel kickstart. Per esempio:
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Se ricevete un errore da Anaconda il quale indica che non è possibile trovare le immagini o i
30
pacchetti, controllate che l'URL di kickstar sia in grado di generare una risposta 200 OK. Per fare
questo eseguite wget nei confronti del file posizionato sull'URL in questione:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
--2011-08-19 15:06:55-- http://satellite.example.com/ks/dist/ks-rhel-i386server-5-u3
Resolving satellite.example.com... 10.10.77.131
Connecting to satellite.example.com|10.10.77.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `ks-rhel-i386-server-5-u3.1'
2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
Se ricevete una risposta diversa da 200 OK, controllate i log d'errore per individuare il problema.
Sarà possibile altresì controllare il file che Anaconda ha cercato di scaricare controllando il file
access_log:
# grep chkconfig /var/log/httpd/access_log
10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET
/rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server5-u3/Server /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-"
"urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386server-5-u3/Server/chkconfig1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386server-5-u3/Server/chkconfig1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET
/rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-"
"urlgrabber/3.1.0 yum/3.2.19"
Se le richieste non vengono visualizzate nel file access_log il sistema potrebbe avere problemi
con l'impostazione del networking. Se invece le richieste possono essere visualizzate e le stesse
generano un errore, allora controllate i log d'errore.
È possibile scaricare manualmente i file in modo da controllare se il pacchetto è disponibile:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5u3/Server/chkconfig-1.3.30.1-2.i386.rpm
5.3. Messaggi di T raceback
Domanda:Ricevo delle email con oggetto "WEB T RACEBACK". Come mi devo comportare?
Risposta:Una email di traceback tipica potrebbe somigliare alla seguente:
31
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From: RHN Satellite <[email protected]>
To: [email protected]
java.lang.RuntimeException: XmlRpcException calling cobbler.
at
com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(Cobb
lerXMLRPCHelper.java:72)
at
com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
at
com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreaded
TestableTask.java:54)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
at
com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(Cobb
lerXMLRPCHelper.java:69)
... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for
URL: http://someserver.example.com:80/cobbler_api
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.jav
a:1236)
at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
... 7 more
Ciò indica la presenza di un errore di comunicazione tra Cobbler ed il servizio taskom atic.
Provate a controllare quanto segue:
Verificare che httpd sia in esecuzione: service httpd status
Verificare che cobblerd sia in esecuzione: service cobblerd status
Verificate che non ci siano regole per il firewall in grado di impedire i collegamenti localhost.
5.4 . Registrazione
Domanda:Il comando rhnreg_ks fallisce quando eseguito ed indica il seguente messaggio,
ERROR: unable to read system id. Qual è il problema?
Risposta:Alla fine del file di kickstart è presente una sezione %post la quale registra la macchina con
RHN Satellite:
32
# begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O
/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC -sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1c8d01e2f23c6bbaedd0f6507e9ac079d
# end Red Hat management server registration
Seguendo l'ordine con il quale è stato aggiunto, ciò comporterà una:
Creazione della directory in modo da contenere il certificato SSL personalizzato usato dal RHN
Satellite.
Ripristino del certificato SSL da usare durante la registrazione.
Verrà eseguita una ricerca e sostituzione delle stringhe del certificato SSL dai file di
configurazione rhn-register e successivamente verrà eseguita una registrazione con RHN
Satellite usando il certificato SSL ed una chiave di attivazione. Ogni profilo kickstart include una
chiave di attivazione per l'assegnazione al sistema dei canali figlio e di base corretti, ottenendo
altresì gli entitlement corretti. Se si esegue il reprovisioning di un sistema esistente la chiave di
attivazione assicurerà una associazione con il profilo del sistema precedente.
Se il comando rhnreg_ks fallisce sarà possibile visualizzare errori simili al seguente all'interno
del file di log ks-post.log:
ERROR: unable to read system id.
Questi errori si verificano anche se l'utente cercherà di eseguire rhn_check ed il sistema non è
registrato con RHN Satellite.
Il modo migliore per risolvere il problema è quello di controllare il file di kickstart ed eseguire un
copia ed incolla delle quattro fasi direttamente al prompt del comando dopo aver completato
kickstart. Così facendo verranno generati i messaggi d'errore più dettagliati per assistervi
all'individuazione del problema.
5.5. Kickstart e Snippet
Domanda:Qual è la struttura della directory per kickstart?
Risposta:Il percorso di base dove sono archiviati i file di kickstart è /var/lib/rhn/kickstarts/.
All'interno di questa directory i kickstart raw si trovano nella sottodirectory upload, ed i kickstart
basati sul wizard si troveranno nella sottodirectory wizard:
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
Domanda:Qual è la struttura della directory per gli snippet di Cobbler?
Risposta:Gli snippet di Cobbler sono archiviati in /var/lib/rhn/kickstarts/snippets. Cobbler è
in grado di accedere gli snippet usando il link simbolico
/var/lib/cobbler/snippets/spacewalk.
33
Snippets:
/var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name
Importante
Non modificate la posizione delle directory snippet e del kickstart di Cobbler poichè gli RPM
di RHN Satelliteaccettano solo la loro posizione predefinita.
34
Revision History
Revision History
Revisione 4 -2.1.4 02
Rebuild with Publican 4.0.0
Fri Oct 25 2013
Rüdiger Landmann
Revisione 4 -2.1
T hu Feb 21 2013
T raduzione file sincronizzata con sorgenti 4-2 XML
Francesco Valente
Revisione 4 -2
Packaging finale per 5.5
Wed Sept 19 2012
Dan Macpherson
Revisione 4 -1
Staging per la release
T hu Aug 9 2012
Athene Chan
Revisione 4 -0
Mon June 25 2012
Capitoli 1 e 2 per RHN Satellite 5.5 aggiornati
Capitolo 3 - 5 per RHN Satellite 5.5 modificati
BZ #787348 Riga non corretta di iptables per Cobbler
BZ #702529 Implementate informazioni aggiuntive per il Kickstart
BZ #797688 ISO per l'avvio di Cobbler non supportato
Athene Chan
Revisione 3-0
T hu May 31 2012
Athene Chan
BZ #826803 - Correzione punteggiatura nella Sezione "Kickstart di una macchina"
Piccole correzioni grammaticali nella sezione kickstart.
Revisione 2-0
T hu May 24 2012
Athene Chan
BZ #783339 - Modificata la struttura della frase presente in sezione "Provisioning processo di
troubleshooting di T askomatic"
BZ #783340 - Aggiornato "s390x" in "IBM System z"
Revisione 1-3
Mon Aug 15 2011
Incorporata la release z-stream in y-stream
Lana Brindley
Revisione 1-2
Wed Jun 15 2011
Praparato per il processo di traduzione
Lana Brindley
Revisione 1-1
Aggiornamenti dai traduttori
Lana Brindley
Fri May 27 2011
Revisione 1-0
Fri May 6, 2011
Modifiche finali per la Revisione QE
Pronto per la traduzione
Lana Brindley
Revisione 0-8
BZ #701822 - Revisione QE
T hu May 5, 2011
Lana Brindley
Revisione 0-7
Commenti revisione tecnica
T hu April 14 , 2011
Lana Brindley
35
Revisione 0-6
Wed March 23, 2011
Preparazione per la revisione tecnica
Lana Brindley
Revisione 0-5
BZ #666435
BZ #666846
BZ #678080
BZ #682364
T ue March 22, 2011
Lana Brindley
Revisione 0-4
T roubleshooting
T ue March 22, 2011
Lana Brindley
Revisione 0-3
Satellite multipli
Mon March 21, 2011
Lana Brindley
Revisione 0-2
Introduzione
Kickstart
Comandi avanzati
Varie correzioni dei capitoli
T hu March 17, 2011
Lana Brindley
Revisione 0-1
Wed Jan 5, 2011
Nuova struttura del capitolo completata
Lana Brindley
Revisione 0-0
T ue Dec 21, 2010
Lana Brindley
Nuova documentazione creata dalla RHN Satellite Deployment Guide originale
36

Red Hat Network Satellite 5.5 Getting Started Guide

Transcript

Documenti analoghi

scarica pdf - Dipartimento di Ingegneria

CENNI STORICI 1957 Ott. Sputnik 1 Primo satellite artificiale Nov

comunicato del Dipartimento Nazionale della Protezione Civile ore

Il satellite THETA della societ GoogleMoon è munito di una

Procedura aggiornamento XSATHP da 558.87 KByte

Sistema di controllo satellitare a terra - SUPSI

Modulatore QPSK

supporto protezione toshiba protezione antivirus notebook toshiba

Red Hat Network Satellite 5.5 Note di rilascio