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 serverURL
da 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:
- Creazione di una Chiavi di Attivazione
- Importare le chiavi GPG personalizzate.
- 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
- 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.
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.
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:
- 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. - Recuperate il pacchetto
rhn-applet-actions
conup2date
, 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. - 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:
- 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. - 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.
- 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
- 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).
- 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.
- Registrate e conservate la password CA per un suo utilizzo futuro.
- 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.
- 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 CARHN-ORG-TRUSTED-SSL-CERT
— il certificato pubblico SSL del CArhn-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 SSLlatest.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 serverserver.csr
— richiesta del certificato SSL del Web serverserver.crt
— certificato pubblico SSL del web serverrhn-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, mentrebootstrap-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.400 | 2013-10-31 | Rüdiger Landmann | |
| |||
Revisione 1-3 | 2012-07-18 | Anthony Towns | |
| |||
Revisione 1-7 | Fri Feb 27 2009 | ||
|
Indice analitico
Simboli
- --configure
- utilizzo di, Opzione up2date --configure
A
- applicazioni client
- configurazione di, Configurazione delle Applicazioni client
- installazione di, Impiego degli ultimissimi RPM client di Red Hat Network
B
- bootstrap.sh
- file d'esempio, Esempio di Script Bootstrap
- preparazione ed utilizzo, Come utilizzare il RHN Bootstrap
C
- certificati SSL
- configurazione di, Configurazione dei sistemi client
- generazione, Il RHN SSL Maintenance Tool
- installazione di, Impiego del Certificato Pubblico SSL del CA per i client
- chiavi di attivazione
- registrazione con, Registrazione con le Chiavi di Attivazione
- cȟiavi GPG
- come importare, Come importare le chiavi GPG personalizzate
- configurazione
- failover del server, Implementazione del processo di failover del server
- manuale, Aggiornamento manuale dei file di configurazione
- script completo, Esecuzione manuale dello script per la configurazione
- configurazione del client
- Red Hat Update Agent , Opzione up2date --configure
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.