Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Client Configuration Guide

Red Hat Network Satellite 5.5

Red Hat Network Satellite

Edizione 3

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.
Per impostazione predefinita tutte le applicazioni client di Red Hat Network sono configurate in modo da comunicare con i\nserver 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. Questo documento risulterà utile in presenza di un ambiente\nenterprise molto grande nel quale sono presenti centinaia o migliaia di sistemi ai quali sarà necessario modificare le impostazioni predefinite.
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. 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 RHN Satellite, è 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 da 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 dei client Red Hat Network

Il Package Updater (pup), yum, yum RHN Plugin (yum-rhn-plugin) e Red Hat Network Registration Client (rhn_register) su Red Hat Enterprise Linux 5 e 6 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, pupe rhn_register. 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, non siano l'ultimissima versione e quindi non idonea al vostro ambiente.
Ricordate, solo i sistemi che eseguono Red Hat Enterprise Linux 5 e 6 devono essere registrati con RHN in firstboot dopo l'installazione, o usare rhn_register.\n
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:
rpm -Uvh
http://satellite.example.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://satellite.example.com/pub/yum-3.2.8-9.el5.i386.rpm
http://satellite.example.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
L'amministratore abbia precedentemente popolato la directory /var/www/html/pub/, in ambienti RHN Satellite o RHN Proxy, con una copia degli RPM yum, pup e rhn_register, necessari per i propri sistemi client ed impiegato semplicemente gli RPM in questione sui propri sistemi client con un comando rpm -Uvh molto semplice. Se eseguito da un client questo comando installa gli RPM su quel client, considerando validi il nome del dominio, i percorsi 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\nshell):
Ricordate che le versioni dell'architettura (in questo caso i386) e dei pacchetti 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 pacchetti personalizzati. 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 impostazione predefinita rhn_register e up2date indicano i server di 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 RHN Server, fornendo così un failover nel caso in cui il server primario risulta inaccessibile. Consultate la Sezione 2.2.5, «Implementazione del processo di failover del server» per maggiori informazioni su come abilitare questa funzione.
Le sezioni successive descrivono diversi metodi di configurazione dei sistemi client per poter accedere al vostro RHN Satellite Server o RHN Proxy Server. Per un processo di script di tutte le riconfigurazioni consultate il Capitolo 6, Esecuzione manuale dello script per la configurazione di RHN Bootstrap.

2.2.1. Registrazione dei client con il RHN Satellite Server

Per registrare un sistema con un RHN Satellite Server è necessario essere in possesso di un fully qualified domain name (FQDN) ed un certificato SSL. Dopo aver soddisfatto i suddetti requisiti seguire le fasi riportate:
  1. Scaricare il certificato SSL per il client:
    cd /usr/share/rhn/
    wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
    
  2. Modificare il file /etc/sysconfig/rhn/up2date:
    serverURL=https://satellite.example.com/XMLRPC
    noSSLServerURL=http://satellite.example.com/XMLRPC
    sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
    
  3. Registrare la macchina:
    rhn_register
    

2.2.2. Registrazione con 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.
Durante la registrazione con una chiave di attivazione:
  1. Generare la chiave di attivazione. (Consultare la sezione "Chiavi di attivazione" nella RHN Satellite Server Reference Guide)
  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://satellite.example.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    
  4. Registrare il sistema con il RHN Proxy Server o RHN Satellite Server:
     rhnreg_ks --activationkey mykey --serverUrl https://satellite.example.com/XMLRPC 
Alternativamente la maggior parte delle fasi sopra riportate possono essere combinate tra loro in uno script della shell, includendo quanto di seguito riportato:
wget -0 - http://satellite.example.com/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://satellite.example.com/XMLRPC
Note 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.
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.

2.2.3. 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 pagina man 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 scheda Generale, sotto Seleziona un nuovo Red Hat Network Server da usare sostituite il valore di default con il fully qualified domain name (FQDN) del RHN Satellite Server o RHN Proxy Server, come ad esempio https://satellite.example.com/XMLRPC. Mantenete però /XMLRPC alla fine. Una volta terminato fate clic su OK.
Configurazione GUI di Red Hat Update Agent

Figura 2.1. Configurazione GUI di Red Hat Update Agent

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, o lasciare il campo in questione vuoto, potrebbe impedire il lancio di up2date --configure. Questo problema potrà essere risolto modificando il valore all'interno del file di configurazione up2date. Consultate Sezione 2.2.4, «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 e 6 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.4. 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 di httpProxy in /etc/sysconfig/rhn/up2date non si riferisce al RHN Proxy Server. Essa viene utilizzata per configurare un HTTP proxy facoltativo per il client. Avendo un RHN Proxy Server, l'impostazione di httpProxy deve essere vuota (cioè senza alcun valore).

2.2.5. 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 RHN Proxy Server o RHN Satellite Server primario è stato messo offline.
Per usare questa funzione:
  1. Eseguire la versione necessaria o più recente di up2date ed usare Red Hat Enterprise Linux 5 o 6.
  2. Aggiungere manualmente i server secondari alle impostazioni serverURL e noSSLServerURL nel file di configurazione /etc/sysconfig/rhn/up2date (come utente root).
  3. Aggiungere il fully qualified domain name (FQDN) per il Proxy o Satellite immediatamente dopo il server primarioseparato da due punti (;). Per esempio:
    serverURL[comment]=Remote server URL
    serverURL=https://satellite.example.com/XMLRPC; 
    https://your_secondary.your_domain.com/XMLRPC;
    
    noSSLServerURL[comment]=Remote server URL without SSL
    noSSLServerURL=http://satellite.example.com/XMLRPC; 
    http://your_secondary.your_domain.com/XMLRPC;
    
    Il collegamento ai server segue l'ordine qui riportato. Includere il numero di server necessari.

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 permette altresì agli utenti di eseguire alcuni compiti di gestione dei pacchetti selezionando l'icona di notifica e scegliendo tra le seguenti azioni:
  • Ricarica — Controlla la presenza di nuovi aggiornamenti in RHN o Satellite.
  • Visualizza gli aggiornamenti — 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.
  • Applica aggiornamenti — Scarica ed installa tutti i pacchetti aggiornati.
  • Esci — chiude l'applet

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 permettono di creare le chiavi SSL ed i certificati in base al Certificate Authority (CA) privato. A tale scopo è disponibile una utilità 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 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 eseguire questi compiti.
Questo capitolo non affronta SSL in modo molto approfondito. RHN SSL Maintenance Tool è stato creato per facilitare 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 chiave privata relativa che dalla chiave privata SSL del CA. Spesso si fà riferimento ad un set di chiavi del Web server; questo a causa della creazione di una richiesta del certificato SSL intermedia. I dettagli relativi non hanno alcuna importanza in questa dscussione. Tutti e tre verranno impiegati su di un RHN Server.
Di seguito viene riportato uno scenario: Con 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 directory SSL di compilazione generata con questo tool, e/o gli installatori su un dispositivo separato, scrivere la password CA e conservare sia il dispositivo 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 infrastruttura sicura: RHN SSL Tool, comunemente conosciuto tramite il suo comando rhn-ssl-tool. Il suddetto tool è disponibile come parte del pacchetto spacewalk-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 le ISO del RHN Satellite Server). RHN SSL Tool permette di generare la coppia di chiavi SSL del Certificate Authority insieme ai set di chiavi SSL del Web server (talvolta chiamate coppia di chiavi).
Questo tool rappresenta solo un tool di compilazione. 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 RHN Server.
Il tool è necessario:
  • Durante l'aggiornamento del certificato pubblico del Certificate Authority (CA)
  • Durante l'installazione di un RHN Proxy Server versione 3.6 o con una versione più recente, in grado di collegarsi ai RHN Server centrali come proprio servizio di livello superiore - il servizio hosted, per ragioni di sicurezza, non potrà essere un repositorio per la chiave SSL del CA e per il certificato, infatti quest'ultimo risulta essere privato alla vostra organizzazione.
  • All'esecuzione di una riconfigurazione della infrastruttura di RHN in modo da utilizzare SSL là dove non era possibile.
  • Durante l'aggiunta di RHN Satellite Server multipli alla infrastruttura RHN - a tale scopo contattate un rappresentante di Red Hat per maggiori informazioni.
Nei seguenti casi il tool non è 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 ed i certificati di RHN Proxy Server.
I processi di installazione sia di RHN Satellite Server che di RHN Proxy Server assicurano che il certificato pubblico SSL del CA venga implementato nella directory /pub di ogni server. Il suddetto certificato pubblico viene utilizzato dai sistemi client in modo da collegarsi al RHN Server. 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.

3.2.1. Generazione dei certificati 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 RHN Server, tutti firmati da una coppia singola di chiavi SSL del Certificate Authority 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 spacewalk-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 RHN Server 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 spacewalk-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. Per maggiore informazione consultare Sezione 3.2.3, «Creazione della coppia di chiavi SSL per il Certificate Authority».
  3. Create un set di chiavi SSL del web server per ogni Proxy e Satellite da impiegare, ed installate gli RPM risultanti sui RHN Server
  4. Riavviare il servizio httpd service:
     /sbin/service httpd restart 
  5. Archiviate l'albero di compilazione SSL - che consiste in una directory di compilazione primaria e di tutte le sotto-directory e file - su di un dispositivo estraibile, come ad esempio un CD o DVD. (I requisiti sullo spazio del disco sono insignificanti).
  6. 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.
  7. Registrate e conservate la password CA per un suo utilizzo futuro.
  8. Per motivi di sicurezza cancellate l'albero di compilazione dal sistema di compilazione solo quando l'intera infrastruttura RHN risulta essere pronta e configurata.

    Nota

    Quando è necessario un set di chiavi SSL aggiuntivo del web server, ripristinate l'albero di compilazione su di un sistema in grado di eseguire RHN SSL Maintenance Tool, e successivamente ripetere la fase 3 fino alla fase 7.

3.2.2. Opzioni 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 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 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 utilizzata - Generalmente solo una chiave privata CA. Per maggiori informazioni consultate --gen-ca --key-only --help.
--cert-only Raramente utilizzata - Genera solo un certificato pubblico CA. Ricontrollare --gen-ca --cert-only --help per maggiori informazioni.
--rpm-only Raramente 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 L'azienda o l'organizzazione, come ad esempio Red Hat. Il valore predefinito è 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 RHN Server 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 di chiavi 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 permette di generare una coppia di chiavi SSL del CA se necessario, e di riutilizzarla per tutti gli impieghi successivi del RHN Server.
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. Per maggiori informazioni 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 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 processo di compilazione 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 directory di compilazione che riflettono il nome della macchina del sistema di compilazione, 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 l'organizzazione. Ciò darà luogo ai seguenti file all'interno di una sottodirectory della directory di compilazione 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 RHN Server. 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 RHN Server. 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 RHN Server, 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 implementato l'RPM, o il raw certificate, su di un sistema client, l'amministratore del sistema in questione dovrà alterare i file di configurazione del Red Hat Update Agent e del Red Hat Network Registraction Client (se necessario), in modo da poter utilizzare il file del certificato pubblico SSL del CA e 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 applicazione riduce le fasi di installazione necessarie e semplifica 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 è relativa alla creazione di 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 dei client 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 i sistemi client potranno scaricare la chiave 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
Una volta aggiunta la chiave GPG al client, il sistema dovrebbe essere in grado di convalidare gli RPM personalizzati firmati con la chiave corrispondente.

Nota

Durante l'uso di canali e RPM personalizzati creare sempre una chiave GPG personalizzata per questi pacchetti. La posizione della chiave GPG deve essere aggiunta al profilo kickstart.
La chiave GPG personalizzata devrà essere aggiunta ai sistemi client, in caso contrario l'installazione kickstart fallirà.

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 di RHN Proxy Server e quelli con 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 per 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 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 RHN Server. 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, «Configurazione delle opzioni di RHN Bootstrap». Per finire consultate Appendice A, Esempio di Script Bootstrap per uno script d'esempio.

5.1. Preparazione per una installazione RHN Bootstrap

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 di sistemi, il tutto tramite una sola azione. Da notare che è necessario avere gli entitlement di Gestione 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 RHN Server centrali per Proxy o il fully qualified domain name del Satellite). Consultate il 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 gli 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/ di RHN Server, 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 RHN Server 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 in base ai 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, «Configurazione delle opzioni di RHN Bootstrap» per un elenco completo.

5.2. Generazione di script RHN Bootstrap

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 emettere il comando rhn-bootstrap seguito dal valore e dalle opzioni desiderate. Se le opzioni non vengono incluse sarà 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 che gli script usati siano in grado di soddisfare i requisiti delle chiavi di attivazione, delle chiavi GPG e delle opzioni di configurazione avanzate:
  • Utilizzate l'opzione --activation-keys per poter includere le chiavi tenendo presente i requisiti dell'entitlement identificati in Sezione 5.1, «Preparazione per una installazione RHN Bootstrap».
  • Utilizzate l'opzione --gpg-key per identificare il percorso della chiave ed il filename durante la generazione dello script. In caso 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 una gestione remota della configurazione 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 la gestione della configurazione questa funzione è molto utile durante la riconfigurazione di sistemi multipli.
Una volta terminato, il 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
Includere i nomi della chiave. Per un elenco completo delle opzioni consultare la Sezione 5.4, «Configurazione delle opzioni di RHN Bootstrap».

5.3. Come usare lo script di RHN Bootstrap

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 RHN Server.

5.4. Configurazione delle 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 RHN Server, 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 percorso per il certificato SSL pubblico della vostra organizzazione sia per un pacchetto che per un certificato raw. Esso verrà copiato su --pub-tree. Un valore di "" forzerà una ricerca di --pub-tree.
--gpg-key=GPG_KEY Il percorso per la 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 Booleano; 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 Booleano; 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 - Booleano; Includendo questa opzione, SSL verrà disabilitato sul sistema client.
--no-gpg Non consigliato - Booleano; Includendo questa opzione, verrà disabilitato il controllo GPG sul sistema client.
--no-up2date Non consigliato - Booleano; 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 - Booleano; includendo questa opzione forzerete la generazione dello script di bootstrap, dopo aver ricevuto i messaggi di avvertimento.
-v, --verbose Visualizza una messaggistica verbosa. Accumulativo; -vvv causa la generazione di messaggi verbosi molto elevati.

Capitolo 6. Esecuzione manuale dello script per la configurazione di RHN Bootstrap

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 bootstrap.
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.
Usando tutti i comandi riportati nel capitolo precedente seguendo un certo ordine, saremo in grado di creare il seguente script:
# 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

Nota

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 di 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 inserite all'interno degli spazi corrispondenti elencati nello script. Altresì, a seconda dell'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 essere 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 configurazione 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.
L'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 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. Diario delle Revisioni

Diario delle Revisioni
Revisione 3-5.3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revisione 3-5.3Wed Mar 20 2013Francesco Valente
Traduzione completata
Revisione 3-5.2Tue Mar 12 2013Francesco Valente
Traduzione completata
Revisione 3-5.1Fri Jan 4 2013Terry Chuang
Traduzione file sincronizzata con i sorgenti XML 3-5
Revisione 3-5Wed Sept 19 2012Dan Macpherson
Packaging finale per 5.5
Revisione 3-4Fri Aug 10 2012Athene Chan
Staging per la revisione
Revisione 3-0Tue Jun 28 2012Athene Chan
Preparato per la pubblicazione di RHN Satellite 5.5
Modifiche per la revisione tecnica
BZ#837703 Aggiunta nota per la chiave GPG personalizzata
Revisione 2-2Mon Aug 15 2011Lana Brindley
Incorporata la release z-stream in y-stream
Revisione 2-1Wed Jun 15 2011Lana Brindley
Preparato per la traduzione
Revisione 2-0Fri May 7 2011Lana Brindley
Pronto per la traduzione
Revisione 1-8Mon Feb 7 2011Lana Brindley
BZ#662876 - Certificati
Revisione 1-7Tue Feb 1 2011Lana Brindley
BZ#636703 - Ultimissimi Client

Indice analitico

Simboli

--configure
utilizzo di, Opzione up2date --configure

B

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

K

kickstart
utilizzo, Come implementare kickstart

R

Red Hat Update Agent
configurazione per l'uso di RHN Proxy Server o RHN Satellite Server, Aggiornamento manuale dei file di configurazione
registrazione , Registrazione dei client con il RHN Satellite Server
RHN Bootstrap
generazione di script, Generazione di script RHN Bootstrap
opzioni della linea di comando, Configurazione delle opzioni di RHN Bootstrap
preparazione, Preparazione per una installazione RHN Bootstrap
utilizzo, Come utilizzare il RHN Bootstrap
utilizzo dello script, Come usare lo script di RHN Bootstrap
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 RHN SSL Maintenance Tool
processo di generazione, Generazione dei certificati 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 RHN SSL Maintenance Tool
processo di generazione, Generazione dei certificati 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.