Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Getting Started Guide

Red Hat Network Satellite 5.5

Provisioning ed implementazione con il Red Hat Network Satellite

Edizione 2

Red Hat Engineering Content Services

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.

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. Tecnicamente 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. Tale 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).
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».

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. Tuttavia queste posizioni differiscono in base alle architetture. La seguente tabella riporta le varie posizioni:

Tabella 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
Tutte 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. Tale 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 Tools 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 Tools corrispondente rhn-tools-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 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 /mnt/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

    È 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 Tool del canale di base esistente di Red Hat Enterprise Linux. Per questa operazione:
    1. Sull'interfaccia web di Satellite selezionare Canali → Gestisci canali software → Clona canale
    2. Selezionare il canale figlio da clonare dalla casella Clona da: e selezionare lo stato per la clonazione.
    3. Selezionare Crea canale.
    4. Inserire le informazioni necessarie e selezionare il canale genitore da utilizzare per il canale figlio clonato.
    5. Selezionare Crea canale.
Creazione di una distribuzione kickstart

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 Tipo di virtualizzazione desiderato. Consultare Tipi 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 HTTP che FTP 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.
  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 Tipo di virtualizzazione desiderato. Consultare Tipi 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 my_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.
Kickstart raw

Figura 2.2. Kickstart raw

Tipi di virtualizzazione

Tutti i profili kickstart hanno un tipo di virtualizzazione a loro associati. Questa tabella riporta le diverse opzioni:

Tabella 2.2. Tipi di virtualizzazione

Tipo 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 completamente virtualizzato Xen Guest Xen Usare questo tipo di provisioning per guest Xen

Nota

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 Usare questo tipo di 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 qemu nella sezione %packages.
I sistemi completamente virtualizzati possono aver bisogno di un supporto di virtualizzazione abilitato nel menu del BIOS del computer.

Nota

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 mod_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

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_name'). 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.
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_management_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

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.
Snippet kickstart

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
    Tutti 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 Template disponibile durante la modifica di uno script %post o %pre.
  • Includere #errorCatcher Echo nella prima riga dello snippet.

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. Tale 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: 
    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.

  1. Importante

    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:
    1. Abilitazione avvio di rete con il protocollo bootp.
    2. 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.
    3. Il server DHCP direziona il sistema sul server Cobbler con indirizzo IP 192.168.2.1
    4. 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 TFTP, il server FTP usato per il trasferimento dell'immagine d'avvio su di un client PXE.
    Abilitazione Xinetd tramite il comando chkconfig: 
    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 TFTP 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. Tale 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

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 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 Sistemi, 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

      virbr0 non permetterà un networking esterno. Se desiderate un networking esterno configurate l'host per la creazione di un bridge. Tuttavia 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/mydisk, VolGroup00, o /var/lib/xen/images/myDisk.
  4. Selezionare Programma Kickstart e termina.

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 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

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 ORG-SSL del server master. Tale certificato può essere scaricato attraverso HTTP dalla directory /pub/ di qualsiasi Satellite. Il file viene chiamato RHN-ORG-TRUSTED-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 --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels
    Sostituire master.satellite.example.com con l'hostname del server master.

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      = master.satellite.example.com
iss_ca_chain    = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
  2. Iniziare la sincronizzazione eseguendo il comando satellite-sync: 
    satellite-sync -c your-channel

    Nota

    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. Tale 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

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

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.

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:

Tabella 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_preservations.
kickstart.keys Elenca, crea, e rimuove le chiavi crittografiche (GPG/SSL) che possono essere associate ad un profilo kickstart.

Nota

Una volta creata la chiave crittografica la stessa può essere associata ad un profilo kickstart utilizzando il metodo API kickstart.profile.system.add_keys.
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 post-script 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
Per maggiori informazioni sulle chiamate API consultare la documentazione relativa disponibile su https://satellite.example.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:

Tabella 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 --name=profile-name or cobbler system report --name=system-name Mostra un output più dettagliato relativo ad un oggetto specifico
cobbler profile edit --name=profile-name --virt-ram=1024 Modifica vari parametri. Questo esempio assegnerà ad ogni installazione virtualizzata di un dato profilo 1GB di RAM.
cobbler system edit --name=system-name --netboot-enabled=1 Forza la reinstallazione di un sistema durante il successivo riavvio
cobbler system edit --name=system-name --profile=new-profile-name --netboot-enabled=1 Assegna un sistema ad un nuovo profilo per la reinstallazione
cobbler system find --profile=profile-name Elenca tutti i sistemi assegnati ad un profilo
cobbler system find --profile="abc" | xargs -n1 --replace cobbler system edit \ --name={} --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 --name=profilename --kopts="variablename=3" --in-place Imposta una variabile aggiuntiva per il templating su di un profilo senza modificare altre variabili
cobbler system edit --name=systemname --kopts="selinux=disabled asdf=jkl" Assegna alcune variabili ai dati del sistema trascurando quelle precedentemente impostate
cobbler profile find --name="*webserver*" | xargs -n1 --replace cobbler profile edit --name={} --profile="RHEL5-i386" Imposta le nuove installazioni di ogni profilo contenente webserver come stringa per l'utilizzo di un profilo chiamato RHEL5-i386
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/modules.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 HTTPD usando il seguente comando: 
    setsebool -P httpd_can_network_connect true
    -P è essenziale poichè abilita un collegamento persistente HTTPD durante il riavvio di tutti i sistemi.
  2. Impostare le regole del contesto del file di SELinux per TFTP 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 IPTables 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 TFTP: 
    /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 HTTPD: 
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    Per Cobbler: 
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j ACCEPT
    Per Koan: 
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j 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

    Avvertimento

    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 sistema 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.
  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. Tuttavia, 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_name:$org_id:$org_name (se creato manualmente)
$tree_name (se sincronizzato da RHN Satellite )
Profili
$profile_name:$org_id:$org_name

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

Per processi di troubleshooting Cobbler registra i dati nei log di RHN Satellite e nel file /var/log/cobbler/

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.

Tabella 4.3. Comandi di Koan

Comando Uso
man koan Consulta la pagina del manuale di koan
koan --replace-self --server=satellite.example.org --profile=profile-name o koan --replace-self --server=satellite.example.org --system=system-name 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.example.org --profile=profile-name o koan --virt --server=satellite.example.org --system=system-name Provisioning di un guest virtuale
koan --list=profiles --server=satellite.example.org o koan --list=systems --server=satellite.example.org Interroga Cobbler per visualizzare un elenco di profili o sistemi disponibili per una installazione remota

Nota

Nei processi di troubleshooting Koan registra i dati in /var/log/koan

Capitolo 5. Troubleshooting

5.1. Interfaccia web
Domanda: Ho problemi con l'interfaccia utente di RHN Satellite. Quali file di log devo controllare?
5.2. Anaconda
Domanda: Visualizzo il seguente errore Error downloading kickstart file. Qual è il problema e come posso correggerlo?
Domanda: Ho un errore di installazione del pacchetto il quale indica The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened.. Qual è il problema e come posso correggerlo?
5.3. Messaggi di Traceback
Domanda: Ricevo delle email con oggetto "WEB TRACEBACK". Come mi devo comportare?
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?
5.5. Kickstart e Snippet
Domanda: Qual è la struttura della directory per kickstart?
Domanda: Qual è la struttura della directory per gli snippet di Cobbler?

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/tomcat5/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 --rpm-list 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-i386-u3:1:Example-Org
Domanda:
Ho un errore di installazione del pacchetto il quale indica The file chkconfig-1.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 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-i386-server-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-server-
5-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-i386-server-5-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:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-  
1.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-server- 
5-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-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm

5.3. Messaggi di Traceback

Domanda:
Ricevo delle email con oggetto "WEB TRACEBACK". Come mi devo comportare?
Risposta:
Una email di traceback tipica potrebbe somigliare alla seguente: 
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From: RHN Satellite <dev-null@redhat.com>
To: admin@example.com

java.lang.RuntimeException: XmlRpcException calling cobbler.
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
	at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
	at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.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(CobblerXMLRPCHelper.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.java: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 taskomatic. 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: 
# 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=1-c8d01e2f23c6bbaedd0f6507e9ac079d
# 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. 
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.

Appendice A. Revision History

Diario delle Revisioni
Revisione 4-2.1.402Fri Oct 25 2013Rüdiger Landmann
Rebuild with Publican 4.0.0
Revisione 4-2.1Thu Feb 21 2013Francesco Valente
Traduzione file sincronizzata con sorgenti 4-2 XML
Revisione 4-2Wed Sept 19 2012Dan Macpherson
Packaging finale per 5.5
Revisione 4-1Thu Aug 9 2012Athene Chan
Staging per la release
Revisione 4-0Mon June 25 2012Athene Chan
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
Revisione 3-0Thu May 31 2012Athene Chan
BZ#826803 - Correzione punteggiatura nella Sezione "Kickstart di una macchina"
Piccole correzioni grammaticali nella sezione kickstart.
Revisione 2-0Thu May 24 2012Athene Chan
BZ#783339 - Modificata la struttura della frase presente in sezione "Provisioning processo di troubleshooting di Taskomatic"
BZ#783340 - Aggiornato "s390x" in "IBM System z"
Revisione 1-3Mon Aug 15 2011Lana Brindley
Incorporata la release z-stream in y-stream
Revisione 1-2Wed Jun 15 2011Lana Brindley
Praparato per il processo di traduzione
Revisione 1-1Fri May 27 2011Lana Brindley
Aggiornamenti dai traduttori
Revisione 1-0Fri May 6, 2011Lana Brindley
Modifiche finali per la Revisione QE
Pronto per la traduzione
Revisione 0-8Thu May 5, 2011Lana Brindley
BZ#701822 - Revisione QE
Revisione 0-7Thu April 14, 2011Lana Brindley
Commenti revisione tecnica
Revisione 0-6Wed March 23, 2011Lana Brindley
Preparazione per la revisione tecnica
Revisione 0-5Tue March 22, 2011Lana Brindley
BZ#666435
BZ#666846
BZ#678080
BZ#682364
Revisione 0-4Tue March 22, 2011Lana Brindley
Troubleshooting
Revisione 0-3Mon March 21, 2011Lana Brindley
Satellite multipli
Revisione 0-2Thu March 17, 2011Lana Brindley
Introduzione
Kickstart
Comandi avanzati
Varie correzioni dei capitoli
Revisione 0-1Wed Jan 5, 2011Lana Brindley
Nuova struttura del capitolo completata
Revisione 0-0Tue Dec 21, 2010Lana Brindley
Nuova documentazione creata dalla RHN Satellite Deployment Guide originale

Nota Legale

Copyright © 2011 Red Hat, Inc.
This 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, OpenShift, 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 Torvalds 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.
The 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.