Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Client Configuration Guide

Red Hat Network Satellite 5.4

Red Hat Network Satellite

Edizione 1

Sommario

Benvenuti alla Red Hat Network Satellite Client Configuration Guide.

Capitolo 1. Introduzione

Questa guida è stata creata per assistere gli utenti di RHN Satellite Server e RHN Proxy Server a configurare i propri sistemi client seguendo un processo semplice.
Per default tutte le applicazioni client di Red Hat Network sono configurate in modo da comunicare con i server di Red Hat Network centrali. Dove invece i client risultano collegati al RHN Satellite Server o RHN Proxy Server, la maggior parte di queste impostazioni devono essere alterate. La modifica delle impostazioni client per un uno o due sistemi potrebbe essere un processo semplice. In un ambiente enterprise molto grande nel quale sono presenti centinaia o migliaia di sistemi, porete seguire invece le fasi di seguito riportate.
A causa della complessità di questo processo gli utenti possono utilizzare uno script popolato a priori, il quale automatizza un numero considerevole di compiti necessari per accedere al proprio server Proxy o Satellite, consultate il Capitolo 5, Come utilizzare il RHN Bootstrap per maggiori informazioni. Red Hat crede che la comprensione delle implicazioni dovute alle modifiche è importante, per questo motivo descrive le fasi necessarie per la riconfigurazione nei primi capitoli. Usate il vostro giudizio per determinare la soluzione ideale per la vostra organizzazione.
Anche se la maggior parte dei comandi forniti all'interno di questa guida possono essere applicati nel modo in cui vengono riportati, sarà impossibile prevedere tutte le configurazioni adottate degli utenti. Per questo motivo Red Hat consiglia l'utilizzo di questi comandi solo come riferimento, tenendo presente le impostazioni della vostra organizzazione.

Nota

Le informazioni sulla configurazione del client Unix sono disponibili nella RHN Satellite Server Reference Guide all'interno del capitolo Supporto Unix.

Capitolo 2. Applicazioni client

Per poter utilizzare la maggior parte dei contenuti presenti nella classe-enterprise di Red Hat Network, come ad esempio la registrazione con un Satellite RHN, è necessario una configurazione delle ultimissime applicazioni client. Ottenere queste applicazioni prima di registrare il client con Red Hat Network può essere molto difficoltoso. Tale difficoltà si presenta soprattutto per gli utenti che migrano su Red Hat Network, un numero considerevole di sistemi più vecchi. Questo capitolo riporta tutte le tecniche da usare per risolvere il suddetto problema.

Importante

Red Hat consiglia ai client collegati ad un RHN Proxy Server o RHN Satellite Server, di eseguire l'ultimissimo aggiornamento di Red Hat Enterprise Linux, in modo da ottenere un collegamento corretto.
Altresì, se i firewall del client sono configurati, le porte 80 e 443 doveno essere aperte in modo da garantire una funzionalità corretta con Red Hat Network.

2.1. Impiego degli ultimissimi RPM client di Red Hat Network

Package Updater (pup), yum, e Red Hat Network Registration Client (rhn_register) su Red Hat Enterprise Linux 5 (up2date su versioni precedenti di Red Hat Enterprise Linux) sono prerequisiti per utilizzare meglio le funzionalità enterprise di Red Hat Network. È fondamentale installarli sui sistemi client prima di utilizzare RHN Proxy Server o RHN Satellite Server nel vostro ambiente.
È possibile seguire diverse modalità per completare l'aggiornamento del software client di RHN, una delle quali consente di conservare gli RPM in una posizione accessibile da parte di tutti i sistemi client, ed impiegare i pacchetti con il comando più semplice. In quasi tutti i casi, non è necessario eseguire una implementazione manuale di yum, pup, e rhn_register (up2date in presenza di versioni precedenti di Red Hat Enterprise Linux). I tool del client non dovrebbero avere alcun problema a collegarsi al vostro ambiente Proxy o RHN Satellite. Gli argomenti di seguito riportati presumono che "le versioni" di yum, pup, e rhn_register (o up2date), non siano l'ultimissima versione e quindi non idonea al vostro ambiente.
Ricordate, solo i sistemi che eseguono Red Hat Enterprise Linux 5 devono essere registrati con RHN in firstboot dopo l'installazione o usare rhn_register. I sistemi che eseguono Red Hat Enterprise Linux 3 e 4 possono utilizzare la funzionalità di registrazione interna al Red Hat Update Agent.
Questo documento presuppone che l'utente in questione abbia installato sulla propria rete almeno un RHN Satellite Server e/o un RHN Proxy Server. L'esempio di seguito riportato mostra un approccio molto semplice per il primo impiego di yum, pup, e rhn_register (o up2date) da parte di un amministratore, presumendo che le macchine non abbiano un RHN funzionante, e che l'amministratore abbia popolato la directory /var/www/html/pub/ con una copia degli RPM yum, pup, e rhn_register (o up2date), necessari per i propri sistemi client, e che abbia impiegato semplicemente gli RPM in questione sui propri sistemi client con un comando rpm -Uvh molto semplice. Eseguito da un client, questo comando installa gli RPM su quel client, considerando validi il nome del dominio, i path, e le versioni degli RPM (nota bene che questo comando è stato suddiviso in righe multiple per la stampa e per il formato PDF ma deve essere digitato come riga unica sul prompt della shell):
rpm -Uvh
http://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/yum-3.2.8-9.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
Ricordate che l'architettura (in questo caso i386), può essere modificata a seconda dei sistemi da servire.

2.2. Configurazione delle Applicazioni client

Non tutti gli utenti devono eseguire un collegamento sicuro ad un RHN Satellite Server o RHN Proxy Server all'interno della propria organizzazione. Non tutti gli utenti hanno bisogno di creare ed impiegare una chiave GPG per i pacchetti personalizzati. (Entrambi questi argomenti vengono affrontati in dettaglio più in avanti.) Ogni utente che utilizza RHN Satellite Server o RHN Proxy Server deve riconfigurare il Red Hat Update Agent (up2date), e possibilmente il Red Hat Network Registration Client (rhn_register), in modo da ridirezionarlo da Red Hat Network sui propri RHN Satellite Server o RHN Proxy Server.

Importante

Anche se non è configurabile, la porta utilizzata da up2date è 80 per HTTP e 443 per il secure HTTP (HTTPS). Per default yum su Red Hat Enterprise Linux 5 utilizza solo SSL. Per questo motivo gli utenti dovrebbero assicurarsi che i propri firewall permettano i collegamenti attraverso la porta 443. Per baipassare SSL, modificate il protocollo per il serverURLda https a http in /etc/sysconfig/rhn/up2date. Per poter utilizzare il Monitoring di RHN, ed i probe che necessitano del Red Hat Network Monitoring Daemon, i sistemi client devono abilitare i collegamenti sulla porta 4545 (o porta 22, se si utilizza sshd).
Per default, rhn_register e up2date indicano i server Red Hat Network principali. Gli utenti devono riconfigurare i sistemi client in modo da indicare il proprio RHN Satellite Server o RHN Proxy Server.
Da notare che le ultimissime versioni di Red Hat Update Agent, possono essere configurate in modo da facilitare le funzioni di numerosi server RHN, fornendo così un failover nel caso in cui il server primario risulta inaccessibile. Consultate la Sezione 2.2.4, «Implementazione del processo di failover del server» per maggiori informazioni su come abilitare questa funzione.
The next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. To see how virtually all reconfiguration can be scripted, see Capitolo 6, Esecuzione manuale dello script per la configurazione.

2.2.1. Registrazione con le Chiavi di Attivazione

Red Hat consiglia l'utilizzo delle chiavi di attivazione per registrare e configurare i sistemi client in grado di accedere al RHN Proxy Server o RHN Satellite Server. È possibile utilizzare le suddette chiavi di attivazione per registrare, abilitare e sottoscrivere un gruppo di sistemi. Consultate la sezione "Chiavi di Attivazione" del capitolo RHN Satellite Server Reference Guide per informazioni sulle chiavi di attivazione.
La registrazione con una chiave di attivazione viene eseguita attraverso quattro fasi:
  1. Creazione di una Chiavi di Attivazione
  2. Importare le chiavi GPG personalizzate.
  3. Scaricare ed installare l'RPM del certificato SSL dalla directory /pub/ del RHN Proxy Server o RHN Satellite Server. Il comando per questa fase potrebbe somigliare a quanto segue:
    rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    
  4. Registrare il sistema con il vostro RHN Proxy Server o RHN Satellite Server. Il comando per questa fase potrebbe somigliare al seguente:
     rhnreg_ks --activationkey mykey --serverUrl https://your-satellite-FQDN/XMLRPC 
Alternativamente la maggior parte delle fasi sopra riportate possono essere combinate tra loro all'interno di uno script della shell il quale include le seguenti righe (nota bene: questo comando è stato suddiviso in righe multiple per la stampa o per il formato PDF ma deve essere inserito come una sola riga al prompt della shell).
wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://your-satellite-FQDN/XMLRPC
Lo script di bootstrap, generato al momento dell'installazione e disponibile sia per RHN Satellite Server che per RHN Proxy Server, è uno di questi script. Lo script ed il RHN Bootstrap che lo genera, vengono affrontati in dettaglio nel Capitolo 5, Come utilizzare il RHN Bootstrap.

Avvertimento

I sistemi che eseguono Red Hat Enterprise Linux 2.1 e versioni di Red Hat Linux precedenti alla versione 8.0, potrebbero incontrare dei problemi durante l'utilizzo delle Chiavi di Attivazione nella migrazione delle impostazioni del certificato SSL da rhn_register a up2date. Per questo motivo le informazioni sul certificato SSL sui sistemi in questione devono essere impostate manualmente. Tutte le altre impostazioni, come ad esempio l'URL del server, verranno trasferite correttamente.

2.2.2. Opzione up2date --configure

Red Hat Update Agent in Red Hat Enterprise Linux 3 e 4 forniscono le interfacce necessarie per configurare numerose impostazioni. Per un elenco completo di queste impostazioni, consultate la man page di up2date (man up2date tramite la linea di comando).
Per riconfigurare Red Hat Update Agent, emettete il seguente comando come utente root:
 up2date --configure 
A questo punto visualizzerete una casella di dialogo che vi presenterà varie impostazioni. All'interno della tabella Generale, sotto Select a Red Hat Network Server to use sostituite il valore di default con il fully qualified domain name (FQDN) del RHN Satellite Server o RHN Proxy Server, come ad esempio https://your_proxy_or_sat.your_domain.com/XMLRPC. Mantenete però /XMLRPC alla fine. Una volta terminato fate clic su OK.
Red Hat Update Agent GUI Configuration

Figura 2.1. Red Hat Update Agent GUI Configuration

Assicuratevi di aver inserito correttamente il nome del dominio del vostro RHN Satellite Server o RHN Proxy Server. L'inserimento di un dominio non corretto, oppure lasciando il campo in questione vuoto, potrebbe impedire il lancio di up2date --configure. Tale problema potrà essere risolto modificando il valore all'interno del file di configurazione up2date. Consultate Sezione 2.2.3, «Aggiornamento manuale dei file di configurazione» per istruzioni più dettagliate.

Avvertimento

I sistemi che eseguono Red Hat Enterprise Linux 3 o 4 presentano una funzione di registrazione interna al Red Hat Update Agent, e per questo motivo non installano il Red Hat Network Registration Client. I sistemi su Red Hat Enterprise Linux 5 non utilizzano up2date e necessitano di rhn_register per registrare i propri sistemi su RHN o Satellite e yum e pup per aggiornare i propri pacchetti.

2.2.3. Aggiornamento manuale dei file di configurazione

Come alternativa all'interfaccia GUI descritta nella precedente sezione, gli utenti sono in grado di riconfigurare il Red Hat Update Agent modificando i file di configurazione delle applicazioni.
Per configurare il Red Hat Update Agent sui sistemi client, i quali a loro volta si collegano al RHN Proxy Server o al RHN Satellite Server, modificate i valori delle impostazioni di serverURL e noSSLServerURL all'interno del file di configurazione /etc/sysconfig/rhn/up2date (come utente root). Sostituite l'URL di default di Red Hat Network con il fully qualified domain name (FQDN) per il RHN Proxy Server o RHN Satellite Server. Per esempio:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC

Avvertimento

L'impostazione httpProxy in /etc/sysconfig/rhn/up2date non si riferisce al RHN Proxy Server. Essa viene utilizzata per configurare un proxy HTTP facoltativo per il client. Avendo un RHN Proxy Server, l'impostazione httpProxy deve essere vuota (cioè senza alcun valore).

2.2.4. Implementazione del processo di failover del server

Iniziando con up2date-4.2.38, Red Hat Update Agent può essere configurato in modo da ricercare gli aggiornamenti attraverso una serie di server RHN. Tale processo può essere particolarmente utile per l'esecuzione regolare di aggiornamenti se il vostro RHN Satellite Server o RHN Proxy Server primario è stato messo offline.
Per utilizzare questa funzione, assicuratevi prima di eseguire la versione richiesta di up2date. Poi manualmente aggiungete i server secondari alle impostazioni serverURL e noSSLServerURL nel file di configurazione /etc/sysconfig/rhn/up2date (come utente root). Aggiungete i fully qualified domain names (FQDN) per il Proxy o per Satellite, immediatamente dopo il server primario, separato da un punto e virgola (;). Per esempio:
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;
Verrà tentato un collegamento sui server nell'ordine di seguito riportato. Durante questo processo è possibile includere il numero desiderato di server, ed anche elencare i server RHN centrali. Per poter ottenere l'esito desiderato, i sistemi client devono essere in grado di collegarsi ad internet.

2.3. Applet del Package Updater

Red Hat Enterprise Linux 5 presenta un programma in esecuzione sul pannello del desktop grafico il quale controlla periodicamente la presenza di aggiornamenti del server di Satellite o RHN, ed allerta gli utenti quando un nuovo aggiornamento è disponibile.
Applet del Package Updater

Figura 2.2. Applet del Package Updater

L'applet del Package Updater resta nell'area di notifica nel pannello desktop e controlla periodicamente la presenza di nuovi aggiornamenti. L'applet vi permette altresì di eseguire alcuni compiti di gestione dei pacchetti selezionando l'icona di notifica e scegliendo tra le seguenti azioni:
  • Refresh — Controlla la presenza di nuovi aggiornamenti in RHN o Satellite.
  • View Updates — lancia l'applicazione Package Updater, così facendo l'utente è in grado di visualizzare gli aggiornamenti disponibili in dettaglio e configurarli in base alle proprie specifiche.
  • Apply Updates — Scarica ed installa tutti i pacchetti aggiornati.
  • Quit — chiude l'applet

2.4. Configurazione di Red Hat Network Alert Notification Tool con Satellite

Red Hat Network Alert Notification Tool, l'icona circolare presente sul pannello del vostro desktop Red Hat Enterprise Linux 3 o 4, può essere configurata sui sistemi che eseguono Red Hat Enterprise Linux 3 o versioni più recenti, in modo da poter riconoscere gli aggiornamenti disponibili sui canali personalizzati del vostro RHN Satellite Server. Assicuratevi che il RHN Satellite Server sia configurato per supportare questa funzione. (RHN Proxy Server supporta applet senza alcuna modifica del client o del server.) Di seguito vengono riportate le fasi necessarie per configurare Red Hat Network Alert Notification Tool:
  1. Assicuratevi che la versione del vostro RHN Satellite Server sia la 3.4 oppure una versione più recente, e di aver installato sul Satellite il pacchetto rhns-applet. Il pacchetto è disponibile nel canale software di Satellite RHN per versioni 3.4 o per versioni più recenti.
  2. Recuperate il pacchetto rhn-applet-actions con up2date, oppure attraverso il canale software di Red Hat Network Tool. Installate il pacchetto su tutti i sistemi Red Hat Enterprise Linux 3 o sistemi client con versioni più recenti, per essere informati sulla presenza di aggiornamenti personalizzati con il Red Hat Network Alert Notification Tool. I sistemi client devono aver diritto ai livelli di servizio Management o Provisioning.
  3. All'interno della versione Satellite del sito web di RHN, andate sulla pagina Informazioni sul sistema di ogni sistema, e fate clic sul link presente all'interno dell'area RHN Applet, per ridirezionare Red Hat Network Alert Notification Tool sul Satellite.
Al momento del riavvio di applet, verrà applicata la nuova configurazione e verrà stabilito un collegamento al RHN Satellite Server in modo da ricevere gli aggiornamenti.

Capitolo 3. Infrastruttura SSL

Per gli utenti di Red Hat Network le problematiche relative alla sicurezza ricoprono un aspetto molto importante. Una delle caretteristiche più importanti di Red Hat Network è la possibilità di processare ogni singola richiesta attraverso il Secure Sockets Layer, o SSL. Per mantenere questo livello di sicurezza, gli utenti che installano Red Hat Network all'interno della propria infrastruttura, devono generare i certificati e le chiavi SSL personalizzate.
La creazione manuale e l'impiego delle chiavi SSL e dei certificati, può essere un processo molto impegnativo. Durante il processo di installazione, sia RHN Proxy Server che RHN Satellite Server vi permettono di creare le vostre chiavi SSL ed i certificati in base al vostro Certificate Authority (CA) privato. A tale scopo è disponibile una utility separata della linea di comando, RHN SSL Maintenance Tool.Le suddette chiavi insieme ai certificati, devono essere utilizzate su tutti i sistemi presenti all'interno della vosra infrastruttura gestita. In molti casi per l'utente, l'impiego di queste chiavi SSL e dei certificati, risulta essere un processo automatizzato. Questo capitolo descrive i metodi più idonei per condurre questi compiti.
Vi preghiamo di notare che questo capitolo non affronta SSL in modo molto approfondito. RHN SSL Maintenance Tool è stato creato per diminuire la complessità presente durante l'impostazione e la gestione di questa public-key infrastructure (PKI). Per maggiori informazioni vi preghiamo di consultare alcuni dei manuali disponibili nella libreria a voi più vicina.

3.1. Una breve introduzione al SSL

SSL, o Secure Sockets Layer, è un protocollo che abilita le applicazioni server-client, in grado di passare informazioni desiderate in modo sicuro. SSL utilizza un sistema di coppie di chiavi private e pubbliche, per cifrare le comunicazioni che intercorrono tra client e server. I certificati pubblici possono essere accessibili, mentre sarà necessario rendere sicure le chiavi pubbliche. Il rapporto matematico (una firma digitale) che intercorre tra una chiave privata ed il certificato pubblico corrispondente, rende possibile il corretto funzionamento del sistema. Attraverso il suddetto rapporto viene stabilito un collegamento fidato.

Nota

All'interno di questo documento vengono affrontati argomenti relativi ai certificati pubblici ed alle chiavi SSL private. Tecnicamente, entrambi possono essere identificati come chiavi (chiavi pubbliche e private). Ma è convenzione, quando si parla di SSL, indicare la parte pubblica di una coppia di chiavi SSL (o set di chiavi), come certificato pubblico SSL.
Una infrastruttura SSL di una organizzazione è generalmente costituita da queste chiavi SSL e dai seguenti certificati:
  • Certificate Authority (CA) SSL private key e certificato pubblico — generalmente viene generato solo un set per ogni organizzazione. Il certificato pubblico viene firmato digitalmente dalla propria chiave privata. Il suddetto certificato viene distribuito ad ogni sistema.
  • Chiave privata SSL del Web server e certificato pubblico — un set per application server. Il certificato pubblico viene firmato digitalmente sia dalla propria chiave privata che dalla chiave privata SSL del CA. Spesso si fà riferimento ad un set di chiavi del Web server; questo perchè viene generata una richiesta di certificato SSL intermediaria. I dettagli relativi non hanno alcuna importanza in questa dscussione. Tutti e tre verranno impiegati su di un Server RHN.
Di seguito viene riportato uno scenario: Se avete un solo RHN Satellite Server e cinque RHN Proxy Server, allora sarà necessario generare una coppia di chiavi SSL del CA e sei set di chiavi SSL del server. Il certificato pubblico SSL del CA viene distribuito su tutti i sistemi ed utilizzato da tutti i client, per stabilire un collegamento con i rispettivi server upstream. Ogni server possiede il proprio set di chiavi SSL, il quale viene collegato all'hostname del server in questione, e generato utilizzando in combinazione la propria chiave privata SSL e la chiave privata SSL del CA. Tale processo stabilisce un'associazione verificabile digitalmente tra il certificato pubblico SSL del Web server, la coppia di chiavi SSL del CA e la chiave privata del server. Il set di chiavi del Web server non può essere condiviso con altri web server.

Importante

La parte più importante di questo sistema è la coppia di chiavi SSL del CA. Da quel certificato pubblico e dalla chiave privata, un amministratore sarà in grado di generare qualsiasi set di chiavi SSL del Web server. Questa coppia di chiavi SSL del CA deve essere sicura. Una volta teminata l'impostazione ed intrapresa l'esecuzione dell'infrastruttura RHN dei server, è fortemente consigliato archiviare la build-directory SSL generata con questo tool, e/o gli installatori su di un media separato, scrivere la password CA, e conservare sia il media che la password in un luogo sicuro.

3.2. Il RHN SSL Maintenance Tool

Red Hat Network fornisce un tool della linea di comando utile per facilitare il processo di gestione della vostra infrastruttura sicura: RHN SSL Maintenance Tool, comunemente conosciuto tramite il suo comando rhn-ssl-tool. Il suddetto tool è disponibile come parte del pacchetto rhns-certs-tools. Questo pacchetto è disponibile all'interno dei canali software per l'ultimissima versione di RHN Proxy Server e RHN Satellite Server (ed anche per il RHN Satellite Server ISO). RHN SSL Maintenance Tool vi permette di generare la vostra coppia di chiavi SSL Certificate Authority, insieme ai set di chiavi SSL del Web server (talvolta chiamati key pairs).
Questo tool rappresenta solo un tool di creazione. Esso è in grado di generare tutte le chiavi SSL ed i certificati necessari. Altresì è anche in grado di racchiudere i file in pacchetti in formato RPM, per una distribuzione ed una installazione rapida su tutte le macchine client. Tuttavia è da tener presente che esso non impiega i pacchetti in questione. Tale compito è responsabilità dell'amministratore , o in molti casi, viene automatizzato dal RHN Satellite Server.

Nota

Soddisfando i requisiti minimi previsti, rhns-certs-tools, il quale contiene rhn-ssl-tool, può essere installato ed eseguito su tutti i sistemi Red Hat Enterprise Linux correnti. Tale funzione viene offerta agli amministratori, per facilitare il loro compito di gestione delle proprie infrastrutture SSL direttamente dalle proprie workstation, o da un altro sistema diverso dai propri Server RHN.
Di seguito viene indicato quando utilizzare il suddetto tool:
  • Durante l'aggiornamento del certificato pubblico CA - ciò è molto raro.
  • Durante l'installazione di un RHN Proxy Server versione 3.6 o con una versione più recente, in grado di collegarsi ai server RHN centrali come proprio servizio top-level - il servizio hosted, per ragioni di sicurezza, non potrà essere una repositoty per la vostra chiave SSL del CA e per il certificato, infatti quest'ultimi risultano essere privati alla vostra organizzazione.
  • Quando si esegue la riconfigurazione della vostra infrastruttura RHN in modo da utilizzare SSL là dove non era possibile.
  • Quando si aggiungono i RHN Proxy Server con una versione precedente alla 3.6, all'interno della vostra infrastruttura RHN.
  • Se desiderate aggiungere dei RHN Satellite Server multipli alla vostra infrastruttura RHN - contattate un rappresentante di Red Hat per maggiori informazioni.
Nei seguenti casi il tool non risulta necessario:
  • Durante l'installazione di un RHN Satellite Server - tutte le impostazioni SSL vengono configurate durante il processo di installazione. Le chiavi SSL ed il certificato vengono creati ed impiegati automaticamente.
  • Durante l'installazione di un RHN Proxy Server versione 3.6 o di una versione più recente, se collegato ad un RHN Satellite Server versione 3.6 o con una versione più recente come proprio servizio top-level - RHN Satellite Server contiene tutte le informazioni SSL necessarie per configurare, creare ed impiegare le chiavi SSL del RHN Proxy Server ed i certificati.
I processi di installazione sia di RHN Satellite Server che di RHN Proxy Server, assicurano che il certificato pubblico SSL del CA venga impiegato nella directory /pub di ogni server. Il suddetto certificato pubblico viene utilizzato dai sistemi client in modo da collegarsi al server RHN. Per maggiori informazioni consultate la Sezione 3.3, «Impiego del Certificato Pubblico SSL del CA per i client».
In breve, se l'infrastruttura RHN della vostra organizzazione impiega l'ultimissima versione di RHN Satellite Server come proprio servizio top-level, molto probabilmente non avrete alcuna necessità di utilizzare il tool in questione. In caso contrario, vi consigliamo di prendere dimestichezza quanto prima.

3.2.1. Processo di generazione di SSL

I benefici primari nell'utilizzo di RHN SSL Maintenance Tool sono una maggiore sicurezza, flessibilità e trasferibilità. Una maggiore sicurezza viene implementata attraverso la creazione di chiavi SSL del Web server separate e di certificati per ogni server RHN, tutti firmati da una coppia singola di chiavi SSL del Web server creata dalla vostra organizzazione. Una maggiore flessibilità viene fornita grazie all'abilità del tool, di lavorare su qualsiasi macchina sulla quale è stato installato il pacchetto rhns-certs-tools. Maggiore trasferibilità di una struttura di compilazione 'build structure' in grado di essere conservata in qualsiasi luogo sicuro, e successivamente installata là dove necessario.
Ed ancora, se il server RHN principale della vostra infrastruttura è il RHN Satellite Server più aggiornato, allora sarà necessario ripristinare il vostro albero ssl-build da un archivio, sulla directory /root ed utilizzare i tool di configurazione presenti all'interno del sito web di RHN Satellite Server.
Per sfruttare al meglio il RHN SSL Maintenance Tool, completate i seguenti compiti seguendo l'ordine indicato. Consultate le sezioni restanti per le informazioni necessarie:
  1. Installare il pacchetto rhns-certs-tools su di un sistema all'interno della vostra organizzazione, ma non necessariamente RHN Satellite Server o RHN Proxy Server.
  2. Create una coppia di chiavi SSL del Certificate Authority per la vostra organizzazione, ed installate l'RPM risultante o il certificato pubblico, su tutti i sistemi client.
  3. Create un set di chiavi SSL del web server per ogni Proxy e Satellite da impiegare, ed installate gli RPM risultanti sui server RHN, successivamente riavviate il servizio httpd:
     /sbin/service httpd restart 
  4. Archiviate il build tree SSL - che consiste in una build directory primaria e di tutte le sotto-directory e file- su di un media rimovibile, come ad esempio un floppy disk. (I requisiti sullo spazio del disco sono insignificanti).
  5. Verificate e successivamente conservate l'archivio in questione in una posizione sicura, come ad esempio quella descritta per i backup nelle sezioni Requisiti Aggiuntivi del Proxy o della Satellite installation guide.
  6. Registrate e conservate la password CA per un suo utilizzo futuro.
  7. Per motivi di sicurezza cancellate il buid tree dal build system 'sistema di compilazione', ma solo quando l'intera infrastruttura RHN risulta essere pronta e configurata.
  8. Quando è necessario un set di chiavi SSL aggiuntivo del web server, ripristinate il build tree su di un sistema in grado di eseguire il RHN SSL Maintenance Tool, e successivamente ripetere la fase 3 fino alla fase 7.

3.2.2. Opzioni del RHN SSL Maintenance Tool

Il RHN SSL Maintenance Tool offre un certo numero di opzioni della linea di comando per generare una coppia di chiavi SSL del Certificate Authority, e per la gestione di chiavi e certificati SSL del server. Il suddetto tool è in grado di offrire le seguenti opzioni di aiuto della linea di comando: rhn-ssl-tool --help (generale), rhn-ssl-tool --gen-ca --help (Certificate Authority), e rhn-ssl-tool --gen-server --help (Web server). La pagina del manuale di rhn-ssl-tool risulta essere molto dettagliata ed è disponibile in caso di necessità: man rhn-ssl-tool.
Le due tabelle suddividono le opzioni in base ai loro compiti, sia CA che per la generazione del set di chiavi SSL del web server.
Questo set di opzioni deve essere preceduto dall'argomento --gen-ca:

Tabella 3.1. Opzioni SSL Certificate Authority (CA) (rhn-ssl-tool --gen-ca --help)

Opzione Descrizione
--gen-ca Genera una coppia di chiavi Certificate Authority (CA) ed un RPM pubblico. Essi devono essere generati insieme a qualsiasi opzione presente all'interno della tabella.
-h, --help Visualizza la schermata d'aiuto con un elenco di opzioni di base specifiche alla generazione ed alla gestione di un Certificate Authority.
-f, --force Forza la creazione di una chiave privata CA nuova e/o di un certificato pubblico.
-p=, --password=PASSWORD La password CA. Vi verrà richiesto di inserire una password se la stessa non è stata ancora fornita. Registratela in modo sicuro.
-d=, --dir=BUILD_DIRECTORY Richiesto per numerosi comandi - La directory dove i certificati e gli RPM vengono creati. Il default è ./ssl-build.
--ca-key=FILENAME Il filename della chiave privata CA. Il default è RHN-ORG-PRIVATE-SSL-KEY.
--ca-cert=FILENAME Il filename del certificato pubblico CA. Il default è RHN-ORG-TRUSTED-SSL-CERT.
--cert-expiration=CA_CERT_EXPIRE La data di scadenza del certificato CA pubblico. Il default è il numero di giorni fino ad un giorno prima della data limite (o 01-18-2038).
--set-country=COUNTRY_CODE La sigla di una nazione composta da due lettere. Il default è US.
--set-state=STATE_OR_PROVINCE Lo stato o provincia del CA. Il default è ''.
--set-city=CITY_OR_LOCALITY La città o località. Il default è ''.
--set-org=ORGANIZATION L'azienda o l'organizzazione, come ad esempio Red Hat. Il default è Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT L'unità dell'organizzazione, come RHN. Il default è ''.
--set-common-name=HOSTNAME Generalmente non impostato per CA. - Il nome comune.
--set-email=EMAIL Generalmente non impostato per CA. - L'indirizzo email.
--rpm-packager=PACKAGER Il Packager degli RPM generati, come ad esempio "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=VENDOR Il rivenditore degli RPM generati, come ad esempio "IS/IT Example Corp."
-v, --verbose Visualizza il verbose messaging. Accumultivo - "v" aggiunte risutano in maggiori informazioni.
--ca-cert-rpm=CA_CERT_RPM Raramente modificato - Il nome dell'RPM che ospita il certificato CA (il filename di base, e non filename-version-release.noarch.rpm).
--key-only Raramente utilizzato - Generalmente solo una chiave privata CA. Per maggiori informazioni consultate --gen-ca --key-only --help.
--cert-only Rarramente utilizzata - Genera solo un certificato pubblico CA. Ricontrollare --gen-ca --cert-only --help per maggiori informazioni.
--rpm-only Rarramente utilizzata - Genera solo un RPM per il suo impiego. Ricontrollare --gen-ca --rpm-only --help per maggiori informazioni.
--no-rpm Raramente utilizzata - Esegue tutte le fasi relative al CA ad eccezione della fase di generazione dell'RPM.
Il seguente set di opzioni deve essere preceduto dall'argomento --gen-server:

Tabella 3.2. Opzioni SSL Web Server (rhn-ssl-tool --gen-server --help)

Opzione Descrizione
--gen-server Genera il set di chiavi SSL del web server, l'RPM ed il tar archive. Tale opzione deve essere emessa insieme a qualsiasi altra opzione restante presente su questa tabella.
-h, --help Visualizza la schermata d'aiuto insieme ad un elenco delle opzioni di base specifiche per la generazione e la gestione di una coppia di chiavi del server.
-p=, --password=PASSWORD La password CA. Vi verrà richiesto di inserire una password se la stessa non è stata ancora fornita. Registratela in modo sicuro.
-d=, --dir=BUILD_DIRECTORY Richiesto per numerosi comandi - La directory dove i certificati e gli RPM vengono creati. Il default è ./ssl-build.
--server-key=FILENAME Il filename della chiave privata SSL del web server. Il default è server.key.
--server-cert-req=FILENAME Il filename della richiesta del certificato SSL del web server. Il default è server.csr.
--server-cert=FILENAME Il filename del certificato SSL del web server. Il default è server.cst.
--startdate=YYMMDDHHMMSSZ La data di inizio della validità del certificato del server nel formato indicato: anno, mese, data, ora, minuto, secondi (due caratteri per valore). Z stà per Zulu ed è necessaria. Il valore di default è una settimana prima della generazione.
--cert-expiration=SERVER_CERT_EXPIRE La data di scadenza del certificato del server. Il default è il numero di giorni fino a raggiungere il giorno precedente alla data di azzeramento (o 01-18-2938).
--set-country=COUNTRY_CODE La sigla di una nazione composta da due lettere. Il default è US.
--set-state=STATE_OR_PROVINCE Lo stato o provincia. Il default è Carolina del Nord
--set-city=CITY_OR_LOCALITY La città o località. Il default è Raleigh.
--set-org=ORGANIZATION La compagnia o l'organizzazione, come ad esempio Red Hat. Il default è Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT L'unità dell'organizzazione, come ad esempio RHN. Il default è l'unità.
--set-hostname=HOSTNAME L'hostname del server RHN che deve ricevere la chiave. Il default viene dinamicamente impostato sull'hostname della build machine.
--set-email=EMAIL L'indirizzo email del contatto del certificato. Il default è admin@example.corp.
--rpm-packager=PACKAGER Il Packager degli RPM generati, come ad esempio "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=VENDOR Il rivenditore degli RPM generati, come ad esempio "IS/IT Example Corp."
-v, --verbose Visualizza il verbose messaging. Accumultivo - "v" aggiunte risutano in maggiori informazioni.
--key-only Raramente utilizzato - Genera solo una chiave privata del server. Ricontrollare --gen-server --key-only --help per maggiori informazioni.
--cert-req-only Raramente utilizzato - Genera solo una richiesta del certificato del server. Ricontrollare --gen-server --cert-req-only --help per maggiori informazioni.
--cert-only Raramente utilizzato - Genera solo un certificato del server. Ricontrollare --gen-server --cert-only --help per maggiori informazioni.
--rpm-only Raramente utilizzato - Genera solo un RPM per il suo utilizzo. Ricontrollare --gen-server --rpm-only --help per maggiori informazioni.
--no-rpm Raramente utilizzato - Esegue tutte le fasi relative al server ad eccezione di quella di generazione dell'RPM.
--server-rpm=SERVER_RPM Raramente modificato - Il nome dell'RPM che ospita il set di chiavi SSL del web server (il filename di base e non filename-version-release.noarch.rpm).
--server-tar=SERVER_TAR Raramente modificato - Il nome dell'archivio .tar del set della chiave SSL del web server e del certificato pubblico, utilizzati solo per i processi di installazione del RHN Proxy Server (il filename di base e non filename-version-release.tar).

3.2.3. Creazione della coppia di chiavi SSL per il Certificate Authority

Prima di creare il set di chiavi SSL necessario per il Web server,è necessario generare una coppia di chiavi SSL del Certificate Authority (CA). Un certificato pubblico SSL del CA sarà distribuito sui sistemi client del Satellite o Proxy. RHN SSL Maintenance Tool vi permette di generare una coppia di chiavi SSL del CA se necessario, e di riutilizzarla per tutti gli impieghi successivi del server RHN.
Il processo di compilazione genera automaticamente la coppia di chiavi e l'RPM pubblico per la distribuzione ai client. Tutti i componenti CA finiscono all'interno della directory di compilazione specificata sulla linea di comando, generalmente /root/ssl-build (o /etc/sysconfig/rhn/ssl per vecchi Satellite e Proxy). Per generare una coppia di chiavi SSL del CA, emettere un comando simile al seguente:
rhn-ssl-tool --gen-ca --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="SSL CA Unit"
Sostituire i valori dell'esempio con i valori appropriati per la vostra organizzazione. Ciò darà luogo ai seguenti file all'interno della directory di compilazione specificata:
  • RHN-ORG-PRIVATE-SSL-KEY — la chiave privata SSL del CA
  • RHN-ORG-TRUSTED-SSL-CERT — il certificato pubblico SSL del CA
  • rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm — l'RPM creato per la distribuzione sui sistemi client. Contiene il certificato pubblico SSL del CA (sopra riportato), ed è in grado di installarlo in: /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
  • rhn-ca-openssl.cnf — il file di configurazione del CA di SSL
  • latest.txt — elenca sempre le ultimissime versioni dei file rilevanti.
Una volta terminato sarete pronti a distribuire l'RPM sui sistemi client. Consultate la Sezione 3.3, «Impiego del Certificato Pubblico SSL del CA per i client».

3.2.4. Creazione del set di chiavi SSL del Web Server

Anche se è necessario aver generarato a priori una coppia di chiavi SSL del CA, molto probabilmente sarete in grado di generare con più frequenza dei set di chiavi SSL del Web server, in modo particolare se sono stati impiegati più di un Proxy o Satellite. Da notare che il valore di --set-hostname risulta essere diverso per ogni server. In altre parole, un set diverso di chiavi SSL e di certificati, deve essere generato ed installato per ogni hostname del server RHN.
Il build process per il certificato del server funziona in modo simile alla generazione della coppia di chiavi SSL del CA con una sola eccezione: Tutti i componenti server terminano nella sottodirectory della build directory che riflettono il nome della macchina del build system, come ad esempio /root/ssl-build/MACHINE_NAME. Per generare i certificati del server, emettere un comando simile:
rhn-ssl-tool --gen-server --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example	Inc." \
--set-org-unit="IS/IT" --set-email="admin@example.com" \
--set-hostname="rhnbox1.example.com
Sostituite i valori dell'esempio con i valori appropriati per la vostra organizzazione. Ciò darà luogo ai seguenti file all'interno di una sottodirectory della build directory di una macchina specifica:
  • server.key — la chiave server privata SSL del web server
  • server.csr — richiesta del certificato SSL del Web server
  • server.crt — certificato pubblico SSL del web server
  • rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm — l'RPM creato per la distribuzione sui server RHN. Viene altresì generato il file associato src.rpm. Il suddetto RPM contiene i tre file sopra riportati. Esso eseguirà la loro installazione nelle seguenti posizioni:
    • /etc/httpd/conf/ssl.key/server.key
    • /etc/httpd/conf/ssl.csr/server.csr
    • /etc/httpd/conf/ssl.crt/server.crt
  • rhn-server-openssl.cnf — il file di configurazione SSL del Web server
  • latest.txt — elenca sempre le ultimissime versioni dei file rilevanti.
Una volta terminato, potrete distribuire ed installare l'RPM sui rispettivi server RHN. Da notare che il servizio httpd deve essere riavviato subito dopo l'installazione:
 /sbin/service httpd restart 

3.3. Impiego del Certificato Pubblico SSL del CA per i client

Grazie alla generazione dell'RPM e del certificato pubblico SSL del CA, sia il processo di installazione del RHN Proxy Server che quello di RHN Satellite Server rendono l'impiego del client un processo molto semplice. Posizionando una loro copia all'interno della directory /var/www/html/pub/ del server RHN, questi processi di installazione rendono sia il certificato che l'RPM disponibili al pubblico.
È possibile controllare la directory pubblica, navigando attraverso qualsiasi web browser: http://proxy-or-sat.example.com/pub/.
Il certificato pubblico SSL del CA in quella directory, può essere scaricato su di un sistema client utilizzando wget o curl. Per esempio:
curl -O	http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Alternativamente, se l'RPM del certificato pubblico SSL del CA risiede nella directory /pub, esso può essere installato direttamente su di un sistema client:
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
Confermare il nome attuale del certificato o dell'RPM, prima di eseguire questi comandi.

3.4. Configurazione dei sistemi client

Una volta che l'RPM, o il raw certificate, è stato impiegato su di un sistema client, l'amministratore del sistema in questione deve alterare i file di configurazione del Red Hat Update Agent e del Red Hat Network Registration Client (se necessario), in modo da poter utilizzare il file del certificato pubblico SSL del CA e di collegarsi ad un RHN Proxy Server o RHN Satellite Server appropriato. La posizione generalmente accettata per il certificato pubblico SSL del CA si trova all'interno della directory /usr/share/rhn.
RHN Bootstrap è installato per default sia su RHN Proxy Server che su RHN Satellite Server, tale caratteristica riduce le fasi di installazione necessarie e semplificano il processo di registrazione e configurazione dei sistemi client. Per maggiori informazioni consultate il Capitolo 5, Come utilizzare il RHN Bootstrap.

Capitolo 4. Come importare le chiavi GPG personalizzate

Per gli utenti che desiderano creare e distribuire in modo sicuro i propri RPM, è fortemente consigliato firmare tutti gli RPM personalizzati con la GNU Privacy Guard (GPG). La generazione delle chiavi GPG e la creazione di pacchetti firmati con GPG vengono affrontati all'interno della Red Hat Network Channel Management Guide.
Una volta firmati i pacchetti la chiave pubblica deve essere implementata su tutti i sistemi che importano gli RPM interessati. Questo processo presenta due fasi: la prima è quella di creare una posizione centrale per la chiave pubblica in modo che gli utenti siano in grado di recuperarla, e la seconda è l'aggiunta della chiave al keyring GPG locale per ogni sistema.
La prima fase del processo è comune e può essere gestita utilizzando il sito web consigliato per l'implementazione delle applicazioni client di RHN. (Consultate la Sezione 2.1, «Impiego degli ultimissimi RPM client di Red Hat Network».) Per fare questo create una directory pubblica sul Web server e posizionate la firma pubblica GPG al suo interno:
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
Successivamente sarà possibile scaricare la chiave da parte dei sistemi client utilizzando Wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
L'opzione -O- invia i risultati agli output standard, mentre l'opzione -q imposta Wget in modo da essere eseguito in modalità quiet. Ricordate di sostituire la variabile YOUR-RPM-GPG-KEY con il nome del file della vostra chiave.
Una volta disponibile la chiave sul file system del client importatela all'interno del keyring GPG locale. Diversi sistemi operativi richiedono metodi diversi.
Per Red Hat Enterprise Linux 3 o versioni più recenti utilizzate il seguente comando:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Per Red Hat Enterprise Linux 2.1, utilizzate il seguente comando:
gpg $(up2date --gpg-flags) --import /path/to/YOUR-RPM-GPG-KEY
Una volta aggiunta la chiave GPG al client, il sistema dovrebbe essere in grado di convalidare gli RPM personalizzati firmati con la chiave corrispondente.

Capitolo 5. Come utilizzare il RHN Bootstrap

Red Hat Network fornisce un tool in grado di automatizzare gran parte dei processi di riconfigurazione del manuale descritti nei precedenti capitoli: RHN Bootstrap. Il suddetto tool ricopre un ruolo importante all'interno del RHN Satellite Server Installation Program, e permette la generazione dello script di bootstrap durante l'installazione.
Gli utenti RHN Proxy Server e quelli in possesso di impostazioni Satellite aggiornate, necessitano di un tool bootstrap in grado di essere usato in modo indipendente. RHN Bootstrap, invocato con il comando /usr/bin/rhn-bootstrap, è in grado di far fronte a tale esigenza ed è presente per default sia su RHN Satellite Server che sul RHN Proxy Server.
Se utilizzato correttamente, lo script generato da questo tool può essere eseguito da qualsiasi sistema client, in modo da svolgere i seguenti compiti:
  • Per ridirezionare le applicazioni client sul RHN Proxy o Satellite
  • Per importare le chiavi GPG personalizzate
  • Per installare i certificati SSL
  • Per registrare il sistema su RHN, sui gruppi di sistemi particolari e sui canali con l'aiuto delle chiavi di attivazione
  • Per l'esecuzione di attività varie post-installazione, incluso l'aggiornamento dei pacchetti, l'esecuzione dei processi di riavvio, e la modifica della configurazione di RHN
Gli utenti dovrebbero tener presente i rischi derivati dall'utilizzo di uno script per condurre il processo di configurazione. I tool di sicurezza, come ad esempio i certificati SSL, vengono installati dallo stesso script; per questo motivo essi non esistono ancora sui sistemi, e non possono essere utilizzati per processare le transazioni. Ciò permette di impersonificare un Satellite e quindi di trasmettere dati corrotti. Tale rischio viene alleviato dal fatto che quasi tutti i Satellite ed i sistemi client, operano dietro dei firewall limitando così il traffico esterno. Il processo di registrazione viene eseguito tramite SSL e quindi risulta essere protetto.
Lo script di bootstrap bootstrap.sh viene automaticamente posizionato nella directory /var/www/html/pub/bootstrap/ del server RHN. Da li può essere scaricato ed eseguito su tutti i sistemi client. Da notare che sarà necessario eseguire alcune modifiche post-generazione, come riportato nelle seguenti sezioni. Per un elenco completo di opzioni dei tool consultate Sezione 5.4, «Opzioni di RHN Bootstrap». Per finire, consultate Appendice A, Esempio di Script Bootstrap per uno script d'esempio.

5.1. Preparazione

Poichè RHN Bootstrap (rhn-bootstrap) dipende da altri componenti dell'infrastruttura di Red Hat Network, per un processo corretto di configurazione dei sistemi client i suddetti componenti devono essere pronti prima della generazione dello script. Il seguente elenco identifica le misure iniziali consigliate.
  • Generare le chiavi di attivazione invocate dallo script. Le suddette chiavi possono essere usate per regisrare i sistemi Red Hat Enterprise Linux, abilitarli ad un livello di servizio RHN, e sottoscriverli su canali specifici e gruppi del sistema, il tutto tramite una sola azione. Da notare che è necessario avere gli entitlement di Management per poter utilizzare una chiave di attivazione, mentre per l'integrazione contemporanea di chiavi di attivazione multiple sono necessari gli entitlement di Provisioning. Generate le chiavi di attivazione attraverso la pagina Chiavi di attivazione all'interno della categoria Sistemi del sito web di RHN (sia i server RHN centrali per Proxy, o il fully qualified domain name del Satellite). Consultate Red Hat Update Agent ed i capitoli del Sito web di RHN della RHN Reference Guide per informazioni sulla creazione e sull'utilizzo.
  • Red Hat consiglia di firmare i vostri RPM con una chiave GNU Privacy Guard (GPG) personalizzata. Rendete la chiave disponibile in modo da poterla prendere come riferimento dallo script. Generate la chiave come descritto nella RHN Channel Management Guide, e posizionatela nella directory /var/www/html/pub/ del server di RHN, come riportato nel Capitolo 4, Come importare le chiavi GPG personalizzate.
  • Se desiderate utilizzare lo script per implementare il vostro certificato pubblico SSL del CA, allora avrete bisogno del certificato o del pacchetto (RPM) contenente il certificato sul server RHN in questione, includendolo durante la generazione dello script con l'opzione --ssl-cert. Per informazioni consultate il Capitolo 3, Infrastruttura SSL.
  • Tenete pronti i valori per poter sviluppare uno o più script di bootstrap, a seconda della varietà dei sistemi da riconfigurare. Poichè RHN Bootstrap fornisce un set completo di opzioni utili per la riconfigurazione, usatelo per generare script di bootstrap differenti, in modo da poter soddisfare ogni tipo di sistema. Per esempio, bootstrap-web-servers.sh potrebbe essere utilizzato per riconfigurare i vostri Web server, mentre bootstrap-app-servers.sh può gestire gli application server. Consultate la Sezione 5.4, «Opzioni di RHN Bootstrap» per un elenco completo.

5.2. Generazione

Ora che tutti i componenti necessari sono pronti, potrete utilizzare RHN Bootstrap per generare gli script necessari. Eseguite un login sul vostro RHN Satellite Server o RHN Proxy Server come utente root, ed emettete il comando rhn-bootstrap seguito dal valore e dalle opzioni desiderate. Se non vengono incluse delle opzioni, verrà creato il file bootstrap.sh nella sottodirectory bootstrap/ contenente i valori essenziali derivati dal server, incluso l'hostname, il certificato SSL, e se già esistente, le impostazioni SSL e GPG, ed una chiamata per il file client-config-overrides.txt.
Red Hat consiglia vivamente che i vostri script siano in grado di soddisfare i requisiti delle chiavi di attivazione, delle chiavi GPG e delle opzioni di configurazioni avanzate nel seguente modo:
  • Utilizzate l'opzione --activation-keys per poter includere le chiavi, tenendo presente i requisiti dell'entitlement identificati in Sezione 5.1, «Preparazione».
  • Utilizzate l'opzione --gpg-key per identificare il path della chiave ed il filename durante la generazione dello script. Al contrario, utilizzate l'opzione --no-gpg per disabilitare il processo di verifica sui sistemi client. Red Hat consiglia di conservare queste misure di sicurezza.
  • Includere il flag --allow-config-actions per abilitare il configuration management remoto su tutti i sistemi client interessati dallo script. Questa funzione risulta essere utile durante la riconfigurazione simultanea di sistemi multipli.
  • Includere il flag --allow-remote-commands per abilitare gli script remoti su tutti i sistemi client. Come il configuration management, questa funzione è molto utile durante la riconfigurazione di sistemi multipli.
Una volta terminato, il vostro comando somiglierà al seguente:
	rhn-bootstrap --activation-keys KEY1,KEY2 \
		--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
		--allow-config-actions \
		--allow-remote-commands
Includete ovviamente i nomi della chiave. Per un elenco completo delle opzioni, consultare la Sezione 5.4, «Opzioni di RHN Bootstrap»

5.3. Uso dello script

Per finire, una volta teminata la preparazione dello script, sarete pronti per poterlo eseguire. Eseguite un login all'interno del RHN Satellite Server o RHN Proxy Server, e navigate fino a raggiungere la directory /var/www/html/pub/bootstrap/, eseguite il seguente comando, alterando l'hostname ed il nome dello script in modo da soddisfare il tipo di sistema:
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Un'alterativa meno sicura è quella di utilizzare wget o curl, per riprendere ed eseguire uno script da ogni sistema client. Eseguite il login all'interno di ogni macchina client ed emettete il seguente comando, alterando lo script e l'hostname in modo richiesto:
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Oppure con curl:
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Una volta eseguito lo script su ogni sistema client è necessario eseguire una configurazione idonea ad utilizzare il server RHN.

5.4. Opzioni di RHN Bootstrap

RHN Bootstrap offre numerose opzioni della linea di comando per la creazione degli script di bootstarp del client. Anche se le descrizioni possono essere disponibili all'interno delle seguenti tabelle, assicuratevi che esse siano disponibili nella versione del tool installato sul vostro server RHN, per fare questo emettete il comando rhn-bootstrap --help, oppure ricontrollate la pagina man corrispondente.

Tabella 5.1. Opzioni di RHN Bootstrap

Opzione Descrizione
-h, --help Visualizza la schermata di aiuto con un elenco delle opzioni specifiche per la generazione dello script di bootstrap.
--activation-keys=ACTIVATION_KEYS chiave di attivazione, come definito nel sito web di RHN, con entry multiple separate da una virgola senza alcuno spazio.
--overrides=OVERRIDES Configurazione del filename overrides. Il default è client-config-overrides.txt.
--script=SCRIPT Il filename dello script di bootstrap. Il default è bootstrap.sh.
--hostname=HOSTNAME Il fully qualified domain name (FQDN) del server al quale i sistemi client si collegheranno.
--ssl-cert=SSL_CERT Il path per il certificato SSL pubblico della vostra organizzazione, sia per un pacchetto che per un certificato raw. Verrà copiato sull'opzione --pub-tree. Un valore di "" forzerà una ricerca di --pub-tree.
--gpg-key=GPG_KEY Il path per la vostra chiave GPG pubblica dell'organizzazione, se utilizzato. Verrà copiato nella posizione specificata dall'opzione --pub-tree.
--http-proxy=HTTP_PROXY L'impostazione del proxy HTTP per i sistemi client nella forma di hostname:port. Un valore pari a "" disabilita questa impostazione.
--http-proxy-username=HTTP_PROXY_USERNAME Se si utilizza un proxy HTTP di autenticazione, specificare un nome utente. Un valore "" disabilita questa impostazione.
--http-proxy-password=HTTP_PROXY_PASSWORD Se si utilizza un proxy HTTP di autenticazione, specificare una password.
--allow-config-actions Boolean; includendo questa opzione imposterete il sistema in modo da poter abilitare tutte le azioni di configurazione tramite RHN. Ciò richiederà l'installazione di determinati pacchetti rhncfg-*, possibilmente attraverso una chiave di attivazione.
--allow-remote-commands Boolean; includendo questa opzione imposterete il sistema in modo da poter abilitare i comandi arbitrari remoti tramite RHN. Ciò richiederà l'installazione di determinati pacchetti rhncfg-*, possibilmente attraverso una chiave di attivazione.
--no-ssl Non consigliato - Boolean; Includendo questa opzione, SSL verrà disabilitato sul sistema client.
--no-gpg Non consigliato - Boolean; Includendo questa opzione, verrà disabilitato il controllo GPG sul sistema client.
--no-up2date Non consigliato - Boolean; includendo questa opzione, eviterete l'esecuzione di up2date dopo aver eseguito bootstrap sul sistema.
--pub-tree=PUB_TREE Modifica non consigliata - L'albero pubblico della directory dove risiederanno sia il pacchetto che il certificato SSL del CA; la directory di bootstrap e gli script. Il default è /var/www/html/pub/.
--force Non consigliato - Boolean; includendo questa opzione forzerete la generazione dello script di bootstrap, dopo aver ricevuto i messaggi di avvertimento.
-v, --verbose Visualizza il verbose messaging. Accumulativo; -vvv causa la generazione di messaggi verbosi molto elevati.

Capitolo 6. Esecuzione manuale dello script per la configurazione

Da notare che questo capitolo fornisce un'alternativa all'utilizzo di RHN Bootstrap per la generazione dello script di bootstrap. Con queste informazioni sarete in grado di creare il vostro script di botstrap.
Tutte le tecniche iniziali avevano un comune denominatore: lo sviluppo dei file necessari in una posizione centralizzata da recuperare ed installare eseguendo comandi semplici 'scriptable' su ogni client. In questo capitolo verrà affrontato il metodo attraverso il quale è possibile creare uno script singolo, che potrà essere invocato da qualsiasi sistema presente nella vostra organizzazione.
Se combiniamo tutti i comandi presenti nel capitolo precedente seguendo un ordine preciso, otterremo il seguente script. Ricordate, rhn_register non è presente all'interno di Red Hat Enterprise Linux 3 o 4.
# First, install the latest client RPMs to the system.
rpm -Uvh \
	http://proxy-or-sat.example.com.com/pub/rhn_register-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/rhn_register-gnome-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-3.0.7-1.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-gnome-3.0.7-1.i386.rpm

# Second, reconfigure the clients to talk to the correct server.

perl -p -i -e 's/s/www\.rhns\.redhat\.com/proxy-or-sat\.example\.com/g' \
	/etc/sysconfig/rhn/rhn_register \
	/etc/sysconfig/rhn/up2date


# Third, install the SSL client certificate for your company's 
# RHN Satellite Server or RHN Proxy Server.
rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-*.noarch.rpm

# Fourth, reconfigure the clients to use the new SSL certificate.
perl -p -i -e 's/^sslCA/#sslCA/g;' \
	/etc/sysconfig/rhn/up2date /etc/sysconfig/rhn/rhn_register
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/up2date
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/rhn_register


# Fifth, download the GPG key needed to validate custom packages.
wget -O - -q http://proxy-or-sat.example.com.com/pub/YOUR-RPM-GPG-KEY


# Sixth, import that GPG key to your GPG keyring.
rpm --import /path/to/YOUR-RPM-GPG-KEY
Ricordate, la sesta fase viene documentata in questa sezione poichè appartiene ai sistemi che eseguono Red Hat Enterprise Linux 3 o versioni più recenti.
Questo script consiste in un processo pulito e ripetibile in grado di configurare completamente qualsiasi potenziale client Red Hat Network, in preparazione per la registrazione su di un RHN Proxy Server o RHN Satellite Server. Ricordate che i valori delle chiavi, come ad esempio l'URL del vostro RHN Server, la sua directory pubblica, e la vostra chiave GPG devono essere inseriti all'interno degli spazi corrispondenti elencati nello script. Altresì, a seconda del vostro ambiente, potranno essere necessarie alcune modifiche aggiuntive. Questo script dovrebbe essere usato solo come guida.
Come i propri componenti, questo script potrebbe avere una posizione centrale. Posizionando il suddetto script nella directory /pub/ del server, ed eseguendo wget -O- e successivamente inviando in pipe l'output su di una sessione della shell, sarà possibile eseguire l'intero processo di bootstrap con un comando singolo da ogni client:
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash

Avvertimento

L'esecuzione di uno script della shell direttamente da un input inviato in pipe attraverso un collegamento web, presenta ovviamente alcuni rischi. Per questo motivo, ed in questo esempio, è importante controllare la sicurezza del server sorgente.
Successivamente è possibile invocare questo comando attraverso tutti i sistemi presenti su di una rete. Se l'amministratore possiede un accesso SSH a tutti i sistemi in questione, diverrebbe un compito semplice ripeterlo su di un elenco di sistemi, ed eseguire il comando in modo remoto su di essi. Questo script rappresenta una perfetta aggiunta alla sezione %post di uno script di kickstart esistente.

Capitolo 7. Come implementare kickstart

Il momento migliore per apportare modifiche alla configurazione di un sistema è quando il sistema in questione è stato appena creato. Per gli utenti che già utilizzano in modo efficiente kickstart, lo script di bootstrap rappresenta un'aggiunta ideale al processo.
Una volta risolte tutte le problematiche relative alla sicurezza, sarà possibile registrare il sistema con i server Red Hat Network locali utilizzando l'utilità rhnreg_ks, presente con gli RPM up2date e rhn_register. Questo capitolo affronta l'utilizzo corretto di rhnreg_ks per la registrazione dei sistemi.
La utilità rhnreg_ks utilizza le chiavi di attivazione per registrare, per conferire gli entitlement, e sottoscrivere i sistemi ai canali specifici tramite un'unica procedura. Per saperne di più sulle chiavi di attivazione consultate i capitoli Red Hat Update Agent ed il Sito web di RHN della Red Hat Network Management Reference Guide.
Il seguente file di kickstart rappresenta un esempio ideale di come poter configurare un sistema dall'inizio alla fine utilizzando Red Hat Network.
# Generic 7.2 kickstart for laptops in the Widget Corporation (widgetco)

# Standard kickstart options for a network-based install. For an
# explanation of these options, consult the Red Hat Linux Customization 
# Guide.

lang en_US
langsupport --default en_US en_US
keyboard defkeymap
network --bootproto dhcp
install
url --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386
zerombr yes
clearpart --all
part /boot	 --size 128 --fstype ext3 --ondisk hda
part /			 --size 2048 --grow --fstype ext3 --ondisk hda
part /backup --size 1024 --fstype ext3 --ondisk hda
part swap		--size 512 --ondisk hda
bootloader --location mbr
timezone America/New_York
rootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.
auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \
	--krb5adminserver auth.widgetco.com
mouse --emulthree genericps/2
xconfig --card "S3 Savage/MX" --videoram 8192	--resolution 1024x768 \
	--depth 16 --defaultdesktop=GNOME --startxonboot --noprobe \
	 --hsync 31.5-48.5 --vsync 40-70

reboot

# Define a standard set of packages.	Note: Red Hat Network client 
# packages are found in Base.	This is quite a minimal set of packages;
# your mileage may vary.

%packages
@ Base
@ Utilities
@ GNOME
@ Laptop Support
@ Dialup Support
@ Software Development
@ Graphics and Image Manipulation
@ Games and Entertainment
@ Sound and Multimedia Support


# Now for the interesting part.

%post
( # Note that we run the entire %post section as a subshell for logging.

# Remember that nifty one-line command for the bootstrap script that we
# went through? This is an ideal place for it. And assuming that the
# script has been properly configured, it should prepare the system
# fully for usage of local Red Hat Network Servers.

wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash

# The following is an example of the usage of rhnreg_ks, the kickstart
# utility for rhn_register. This demonstrates the usage of the 
# --activationkey flag, which describes an activation key. For example,
# this activation key could be set up in the Web interface to join this 
# system to the "Laptops" group and the local Widgetco "Laptop Software" 
# channel. Note that this section applies only to Proxy users, as this 
# step is handled by the Satellite bootstrap script. 
#
# For more information about activation keys, consult the Red Hat Network
# Management Reference Guide.

/usr/sbin/rhnreg_ks --activationkey=6c933ea74b9b002f3ac7eb99619d3374

# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1

Appendice A. Esempio di Script Bootstrap

Lo script /var/www/html/pub/bootstrap/bootstrap.sh generato dal programma d'installazione di RHN Satellite Server, fornisce la possibilità di riconfigurare i sistemi client in modo da accedere più facilmente al vostro RHN Server. È disponibile sia per gli utenti di RHN Satellite Server che per quelli di RHN Proxy Server attraverso il tool RHN Bootstrap. Dopo aver modificato lo script, esso può essere eseguito su ogni macchina client.
Ricontrollate l'esempio ed i rispettivi commenti che iniziano con il carattere asterisco (#) per informazioni aggiuntive. Seguite le fasi presenti nel Capitolo 5, Come utilizzare il RHN Bootstrap per predisporre lo script al suo utilizzo.

#!/bin/bash
echo "RHN Server Client bootstrap script v3.6"

# This file was autogenerated. Minor manual editing of this script (and
# possibly the client-config-overrides.txt file) may be necessary to complete
# the bootstrap setup. Once customized, the bootstrap script can be triggered
# in one of two ways (the first is preferred):
#
#	 (1) centrally, from the RHN Server via ssh (i.e., from the
#			 RHN Server):
#				cd /var/www/html/pub/bootstrap/
#				cat bootstrap-<edited_name>.sh | ssh root@<client-hostname> /bin/bash
#
#	 ...or...
#
#	 (2) in a decentralized manner, executed on each client, via wget or curl:
#				wget -qO-
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash
#				 ...or...
#				curl -Sks
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash

# SECURITY NOTE:
#	 Use of these scripts via the two methods discussed is the most expedient
#	 way to register machines to your RHN Server. Since "wget" is used
#	 throughout the script to download various files, a "Man-in-the-middle"
#	 attack is theoretically possible.
#
#	 The actual registration process is performed securely via SSL, so the risk
#	 is minimized in a sense. This message merely serves as a warning.
#	 Administrators need to appropriately weigh their concern against the
#	 relative security of their internal network.

# PROVISIONING/KICKSTART NOTE:
#	 If provisioning a client, ensure the proper CA SSL public certificate is
#	 configured properly in the post section of your kickstart profiles (the
#	 RHN Satellite or hosted web user interface).

# UP2DATE/RHN_REGISTER VERSIONING NOTE:
#	 This script will not work with very old versions of up2date and
#	 rhn_register.


echo
echo
echo "MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"
echo
echo "If this bootstrap script was created during the initial installation"
echo "of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
echo "probably *not* be set (see below). If this is the case, please do the"
echo "following:"
echo "	- copy this file to a name specific to its use."
echo "		(e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
echo "	- on the website create an activation key or keys for the system(s) to"
echo "		be registered."
echo "	- edit the values of the VARIABLES below (in this script) as"
echo "		appropriate:"
echo "		- ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
echo "			from the website. XKEY or XKEY,YKEY"
echo "		- ORG_GPG_KEY needs to be set to the name of the corporate public"
echo "			GPG key filename (residing in /var/www/html/pub) if appropriate."
echo
echo "Verify that the script variable settings are correct:"
echo "		- CLIENT_OVERRIDES should be only set differently if a customized"
echo "			client-config-overrides-VER.txt file was created with a different"
echo "			name."
echo "		- ensure the value of HOSTNAME is correct."
echo "		- ensure the value of ORG_CA_CERT is correct."
echo
echo "Enable this script: comment (with #'s) this block (or, at least just"
echo "the exit below)"
echo
exit 1

# can be edited, but probably correct (unless created during initial install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=insert_activation_key_here
ORG_GPG_KEY=insert_org_gpg_pub_key_here

# can be edited, but probably correct:
CLIENT_OVERRIDES=client-config-overrides.txt
HOSTNAME=your_rhn_server_host.example.com

ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT
ORG_CA_CERT_IS_RPM_YN=0

USING_SSL=1
USING_GPG=1

REGISTER_THIS_BOX=1

ALLOW_CONFIG_ACTIONS=0
ALLOW_REMOTE_COMMANDS=0

FULLY_UPDATE_THIS_BOX=1

#
# -----------------------------------------------------------------------------
# DO NOT EDIT BEYOND THIS POINT -----------------------------------------------
# -----------------------------------------------------------------------------
#

# an idea from Erich Morisse (of Red Hat).
# use either wget *or* curl
# Also check to see if the version on the 
# machine supports the insecure mode and format
# command accordingly.
if [ -x /usr/bin/wget ] ; then
		output=`/usr/bin/wget --no-check-certificate 2>&1`
		error=`echo $output | grep "unrecognized option"`
		if [ -z "$error" ] ; then
				FETCH="/usr/bin/wget -q -r -nd --no-check-certificate"
		else
				FETCH="/usr/bin/wget -q -r -nd"
		fi
		
else
		if [ -x /usr/bin/curl ] ; then
				output=`/usr/bin/curl -k 2>&1`
				error=`echo $output | grep "is unknown"`
				if [ -z "$error" ] ; then
						FETCH="/usr/bin/curl -SksO"
				else
						FETCH="/usr/bin/curl -SsO"
				fi
		fi
fi

HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pub
HTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pub
if [ $USING_SSL -eq 0 ] ; then
		HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}
fi
echo
echo "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"
echo "-------------------------------------------------"
echo "* downloading necessary files"
echo "	client_config_update.py..."
rm -f client_config_update.py
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.py
echo "	${CLIENT_OVERRIDES}..."
rm -f ${CLIENT_OVERRIDES}
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/${CLIENT_OVERRIDES}

if [ ! -f "client_config_update.py" ] ; then
		echo "ERROR: client_config_update.py was not downloaded"
		exit 1
fi
if [ ! -f "${CLIENT_OVERRIDES}" ] ; then
		echo "ERROR: ${CLIENT_OVERRIDES} was not downloaded"
		exit 1
fi

echo "* running the update scripts"
if [ -f "/etc/sysconfig/rhn/rhn_register" ] ; then
		echo "	. rhn_register config file"
		/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/rhn_register \
		 ${CLIENT_OVERRIDES}
fi
echo "	. up2date config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/up2date \
 ${CLIENT_OVERRIDES}

if [ ! -z "$ORG_GPG_KEY" ] ; then 
		echo
		echo "* importing organizational GPG key"
		rm -f ${ORG_GPG_KEY}
		$FETCH ${HTTPS_PUB_DIRECTORY}/${ORG_GPG_KEY}
		# get the major version of up2date
		res=$(rpm -q --queryformat '%{version}' up2date | sed -e 's/\..*//g')
		if [ $res -eq 2 ] ; then
				gpg $(up2date --gpg-flags) --import $ORG_GPG_KEY
		else
				rpm --import $ORG_GPG_KEY
		fi
fi

echo
echo "* attempting to install corporate public CA cert"
if [ $USING_SSL -eq 1 ] ; then
		if [ $ORG_CA_CERT_IS_RPM_YN -eq 1 ] ; then
				rpm -Uvh ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
		else
				rm -f ${ORG_CA_CERT}
				$FETCH ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
				mv ${ORG_CA_CERT} /usr/share/rhn/
		fi
fi

echo
echo "REGISTRATION"
echo "------------"
# Should have created an activation key or keys on the RHN Server's
# website and edited the value of ACTIVATION_KEYS above.
#
# If you require use of several different activation keys, copy this file and
# change the string as needed.
#
if [ -z "$ACTIVATION_KEYS" ] ; then
		echo "*** ERROR: in order to bootstrap RHN clients, an activation key or keys"
		echo "			must be created in the RHN web user interface, and the"
		echo "			corresponding key or keys string (XKEY,YKEY,...) must be mapped to"
		echo "			the ACTIVATION_KEYS variable of this script."
		exit 1
fi

if [ $REGISTER_THIS_BOX -eq 1 ] ; then
		echo "* registering"
		/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
		echo
		echo "*** this system should now be registered, please verify ***"
		echo
else
		echo "* explicitely not registering"
fi

echo
echo "OTHER ACTIONS"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "up2date up2date; up2date -p; up2date -uf (conditional)"
else
		echo "up2date up2date; up2date -p"
fi
echo "but any post configuration action can be added here.	"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "* completely updating the box"
else
		echo "* ensuring up2date itself is updated"
fi
/usr/sbin/up2date up2date
/usr/sbin/up2date -p
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		/usr/sbin/up2date -uf
fi
echo "-bootstrap complete-"

Appendice B. Cronologia della revisione

Diario delle Revisioni
Revisione 1-3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revisione 1-32012-07-18Anthony Towns
Rebuild for Publican 3.0
Revisione 1-7Fri Feb 27 2009

Indice analitico

Simboli

--configure
utilizzo di, Opzione up2date --configure

B

bootstrap.sh
file d'esempio, Esempio di Script Bootstrap
preparazione ed utilizzo, Come utilizzare il RHN Bootstrap

K

kickstart
utilizzo, Come implementare kickstart

R

Red Hat Network Alert Notification Tool
configurazione per Satellite, Configurazione di Red Hat Network Alert Notification Tool con Satellite
Red Hat Update Agent
cconfigurazione per l'uso di RHN Proxy Server o RHN Satellite Server, Aggiornamento manuale dei file di configurazione
RHN Bootstrap
generazione dello script, Generazione
opzioni della linea di comando, Opzioni di RHN Bootstrap
preparazione, Preparazione
utilizzo, Come utilizzare il RHN Bootstrap
utilizzo dello script, Uso dello script
RHN SSL Maintenance Tool
come generare il CA, Creazione della coppia di chiavi SSL per il Certificate Authority
come generare il certificato del server, Creazione del set di chiavi SSL del Web Server
opzioni, Opzioni del RHN SSL Maintenance Tool
processo di generazione, Processo di generazione di SSL
rhn-ssl-tool , Il RHN SSL Maintenance Tool
rhn-ssl-tool
come generare il CA, Creazione della coppia di chiavi SSL per il Certificate Authority
come generare il certificato del server, Creazione del set di chiavi SSL del Web Server
opzioni, Opzioni del RHN SSL Maintenance Tool
processo di generazione, Processo di generazione di SSL
RHN SSL Maintenance Tool , Il RHN SSL Maintenance Tool

S

SSL (Secure Sockets Layer)
introduzione, Una breve introduzione al SSL

Nota Legale

Copyright © 2010 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.