Red Hat Network Satellite 5.5 Getting Started Guide

Transcript

1 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

2 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

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

4 Indice Indice. Capitolo Introduzione Capitolo Kickstart Pacchetti necessari Alberi kickstart Profili kickstart T emplating Kickstart di una macchina Kickstart da Bare Metal Reprovisioning Provisioning del guest virtualizzato Provisioning per mezzo di un RHN Proxy 17. Capitolo Satellite multipli Inter-Satellite Synchronization Sincronizzazione per organizzazione Esempi di utilizzo ISS 21. Capitolo Comandi e.. metodi API.... avanzati API XML-RPC Cobbler Koan 29. Capitolo T.. roubleshooting Interfaccia web Anaconda Messaggi di T raceback Registrazione Kickstart e Snippet 33. Revision History

5 2 Red Hat Network Satellite 5.5 Getting Started Guide

6 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

7 Red Hat Network Satellite 5.5 Getting Started Guide 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

8 Capitolo 2. Kickstart 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 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 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 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

9 Red Hat Network Satellite 5.5 Getting Started Guide 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/customdistro/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= -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 Tool 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

10 Capitolo 2. 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 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 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. 7

11 Red Hat Network Satellite 5.5 Getting Started Guide 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 lang en_us keyboard us zerombr clearpart --all part / --fstype=ext3 --size=200 --grow part /boot --fstype=ext3 --size=200 part swap --size= 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 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 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

12 Capitolo 2. Kickstart 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

13 Red Hat Network Satellite 5.5 Getting Started Guide 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 Usare questo tipo di 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 Host di virtualizzazione Xen Guest Xen Host 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. 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. 10

14 Capitolo 2. Kickstart Nota Bene Per maggiori informazioni su kickstart consultate il Capitolo Installazioni Kickstart nella Red Hat Enterprise Linux Installation Guide 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

15 Red Hat Network Satellite 5.5 Getting Started Guide 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

16 Capitolo 2. 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 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

17 Red Hat Network Satellite 5.5 Getting Started Guide 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 Kickstart di una macchina 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 Ad un prompt d'avvio attivare kickstart tramite il seguente comando: 14

18 Capitolo 2. Kickstart linux ks= 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 ; 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 d. Il server DHCP indica il file immagine d'avvio su /var/lib/tftpboot/pxelinux Configurazione di Xinetd. Xinetd è un demone che gestisce una suite di servizi incluso TFTP, il server FT P usato per il trasferimento dell'immagine d'avvio su di un client PXE. Abilitazione Xinetd tramite il comando chkconfig: 15

19 Red Hat Network Satellite 5.5 Getting Started Guide 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 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

20 Capitolo 2. Kickstart kickstart selezionando il profilo desiderato. 3. Andate su Informazioni del sistema File Preservation e selezionate l'elenco del file preservation 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. 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/m ydisk, VolGroup00, o /var/lib/xen/im ages/m ydisk. 4. Selezionare Program m a Kickstart e term ina 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

21 Red Hat Network Satellite 5.5 Getting Started Guide con quello del Proxy. Per esempio se l'url per il file kickstart è: Per eseguire kickstart con il proxy usare: 18

22 Capitolo 3. Satellite multipli 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-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

23 Red Hat Network Satellite 5.5 Getting Started Guide 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 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 20

24 Capitolo 3. Satellite multipli 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

25 Red Hat Network Satellite 5.5 Getting Started Guide 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