Red Hat Network Satellite 5.4 Client Configuration Guide

Transcript

1 Red Hat Network Satellite 5.4 Client Configuration Guide Red Hat Network Satellite Edizione 1 Landmann

2 Red Hat Network Satellite 5.4 Client Configuration Guide Red Hat Network Satellite Edizione 1 Landmann rlandmann@redhat.co m

3 Nota Legale Copyright 2010 Red Hat, Inc. T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. T he OpenStack Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. Sommario Benvenuti alla Red Hat Network Satellite Client Configuration Guide.

4 Indice Indice. Capitolo Introduzione Capitolo Applicazioni client Impiego degli ultimissimi RPM client di Red Hat Network Configurazione delle Applicazioni client Registrazione con le Chiavi di Attivazione Opzione up2date --configure Aggiornamento manuale dei file di configurazione Implementazione del processo di failover del server Applet del Package Updater Configurazione di Red Hat Network Alert Notification T ool con Satellite 9. Capitolo Infrastruttura SSL Una breve introduzione al SSL Il RHN SSL Maintenance Tool Processo di generazione di SSL Opzioni del RHN SSL Maintenance T ool Creazione della coppia di chiavi SSL per il Certificate Authority Creazione del set di chiavi SSL del Web Server Impiego del Certificato Pubblico SSL del CA per i client Configurazione dei sistemi client 19. Capitolo Come importare le... chiavi GPG personalizzate Capitolo Come utilizzare il.. RHN.... Bootstrap Preparazione Generazione Uso dello script Opzioni di RHN Bootstrap 23. Capitolo Esecuzione manuale dello script per.... la.. configurazione Capitolo Come implementare kickstart Esempio di.. Script Bootstrap Cronologia della revisione Indice analitico Simboli 37 A 37 B 37 C 37 K 38 R 38 S 38 1

5 2 Red Hat Network Satellite 5.4 Client Configuration Guide

6 Capitolo 1. Introduzione 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 Bene Le informazioni sulla configurazione del client Unix sono disponibili nella RHN Satellite Server Reference Guide all'interno del capitolo Supporto Unix. 3

7 Red Hat Network Satellite 5.4 Client Configuration Guide 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. T ale 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 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): 4

8 Capitolo 2. Applicazioni client rpm -Uvh Ricordate che l'architettura (in questo caso i386), può essere modificata a seconda dei sistemi da servire Configurazione delle Applicazioni client Non tutti gli utenti devono eseguire un collegamento sicuro ad un RHN Satellite Server o RHN Proxy Server all'interno della propria organizzazione. Non tutti gli utenti hanno bisogno di creare ed impiegare una chiave GPG per i pacchetti personalizzati. (Entrambi questi argomenti vengono affrontati in dettaglio più in avanti.) Ogni utente che utilizza RHN Satellite Server o RHN Proxy Server deve riconfigurare il Red Hat Update Agent (up2date), e possibilmente il Red Hat Network Registration Client (rhn_register), in modo da ridirezionarlo da Red Hat Network sui propri RHN Satellite Server o RHN Proxy Server. Importante Anche se non è configurabile, la porta utilizzata da up2date è 80 per HTTP e 443 per il secure HTTP (HTTPS). Per default yum su Red Hat Enterprise Linux 5 utilizza solo SSL. Per questo motivo gli utenti dovrebbero assicurarsi che i propri firewall permettano i collegamenti attraverso la porta 443. Per baipassare SSL, modificate il protocollo per il serverurlda https a http in /etc/sysconfig/rhn/up2date. Per poter utilizzare il Monitoring di RHN, ed i probe che necessitano del Red Hat Network Monitoring Daemon, i sistemi client devono abilitare i collegamenti sulla porta 4545 (o porta 22, se si utilizza sshd). Per default, rhn_register e up2date indicano i server Red Hat Network principali. Gli utenti devono riconfigurare i sistemi client in modo da indicare il proprio RHN Satellite Server o RHN Proxy Server. Da notare che le ultimissime versioni di Red Hat Update Agent, possono essere configurate in modo da facilitare le funzioni di numerosi server RHN, fornendo così un failover nel caso in cui il server primario risulta inaccessibile. Consultate la Sezione 2.2.4, «Implementazione del processo di failover del server» per maggiori informazioni su come abilitare questa funzione. T he next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. T o see how virtually all reconfiguration can be scripted, see Capitolo 6, Esecuzione manuale dello script per la configurazione Registrazione con le Chiavi di Attivazione Red Hat consiglia l'utilizzo delle chiavi di attivazione per registrare e configurare i sistemi client in grado di accedere al RHN Proxy Server o RHN Satellite Server. È possibile utilizzare le suddette chiavi di attivazione per registrare, abilitare e sottoscrivere un gruppo di sistemi. Consultate la sezione "Chiavi di Attivazione" del capitolo RHN Satellite Server Reference Guide per informazioni sulle chiavi di attivazione. La registrazione con una chiave di attivazione viene eseguita attraverso quattro fasi: 1. Creazione di una Chiavi di Attivazione 2. Importare le chiavi GPG personalizzate. 5

9 Red Hat Network Satellite 5.4 Client Configuration Guide 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 4. Registrare il sistema con il vostro RHN Proxy Server o RHN Satellite Server. Il comando per questa fase potrebbe somigliare al seguente: rhnreg_ks --activationkey mykey --serverurl 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 bash && rhnreg_ks --activation-key my_key --serverurl 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. Attenzione 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. T utte le altre impostazioni, come ad esempio l'url del server, verranno trasferite correttamente 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 (m an 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 ain.com/xmlrpc. Mantenete però /XMLRPC alla fine. Una volta terminato fate clic su OK. 6

10 Capitolo 2. Applicazioni client 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. T ale 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. Attenzione 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 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: 7

11 Red Hat Network Satellite 5.4 Client Configuration Guide serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Attenzione L'impostazione httpproxy in /etc/sysconfig/rhn/up2date non si riferisce al RHN Proxy Server. Essa viene utilizzata per configurare un proxy HT T P facoltativo per il client. Avendo un RHN Proxy Server, l'impostazione httpproxy deve essere vuota (cioè senza alcun valore) Implementazione del processo di failover del server Iniziando con up2date , Red Hat Update Agent può essere configurato in modo da ricercare gli aggiornamenti attraverso una serie di server RHN. T ale 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= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= 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 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 8

12 Capitolo 2. Applicazioni client 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 T ool, 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 T ool: 1. Assicuratevi che la versione del vostro RHN Satellite Server sia la 3.4 oppure una versione più recente, e di aver installato sul Satellite il pacchetto rhns-applet. Il pacchetto è disponibile nel canale software di Satellite RHN per versioni 3.4 o per versioni più recenti. 2. Recuperate il pacchetto rhn-applet-actions con up2date, oppure attraverso il canale software di Red Hat Network Tool. Installate il pacchetto su tutti i sistemi Red Hat Enterprise Linux 3 o sistemi client con versioni più recenti, per essere informati sulla presenza di aggiornamenti personalizzati con il Red Hat Network Alert Notification T ool. I sistemi client devono aver diritto ai livelli di servizio Management o Provisioning. 3. All'interno della versione Satellite del sito web di RHN, andate sulla pagina Inform azioni sul sistem a di ogni sistema, e fate clic sul link presente all'interno dell'area RHN Applet, per ridirezionare Red Hat Network Alert Notification T ool 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. 9

13 Red Hat Network Satellite 5.4 Client Configuration Guide 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 T ool.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 T ool è 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 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 Bene All'interno di questo documento vengono affrontati argomenti relativi ai certificati pubblici ed alle chiavi SSL private. T ecnicamente, 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 10

14 Capitolo 3. Infrastruttura SSL 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. T ale 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 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 T ool, 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. T uttavia è da tener presente che esso non impiega i pacchetti in questione. T ale compito è responsabilità dell'amministratore, o in molti casi, viene automatizzato dal RHN Satellite Server. Nota Bene 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. T ale 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. 11

15 Red Hat Network Satellite 5.4 Client Configuration Guide 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 Processo di generazione di SSL I benefici primari nell'utilizzo di RHN SSL Maintenance T ool 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 rhnscerts-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 T ool, completate i seguenti compiti seguendo l'ordine indicato. Consultate le sezioni restanti per le informazioni necessarie: 1. Installare il pacchetto rhns-certs-tools su di un sistema all'interno della vostra organizzazione, ma non necessariamente RHN Satellite Server o RHN Proxy Server. 2. Create una coppia di chiavi SSL del Certificate Authority per la vostra organizzazione, ed installate l'rpm risultante o il certificato pubblico, su tutti i sistemi client. 3. Create un set di chiavi SSL del web server per ogni Proxy e Satellite da impiegare, ed installate gli RPM risultanti sui server RHN, successivamente riavviate il servizio httpd: /sbin/service httpd restart 4. Archiviate il build tree SSL - che consiste in una build directory primaria e di tutte le sotto-directory e file- su di un media rimovibile, come ad esempio un floppy disk. (I requisiti sullo spazio del disco 12

16 Capitolo 3. Infrastruttura SSL sono insignificanti). 5. Verificate e successivamente conservate l'archivio in questione in una posizione sicura, come ad esempio quella descritta per i backup nelle sezioni Requisiti Aggiuntivi del Proxy o della Satellite installation guide. 6. Registrate e conservate la password CA per un suo utilizzo futuro. 7. Per motivi di sicurezza cancellate il buid tree dal build system 'sistema di compilazione', ma solo quando l'intera infrastruttura RHN risulta essere pronta e configurata. 8. Quando è necessario un set di chiavi SSL aggiuntivo del web server, ripristinate il build tree su di un sistema in grado di eseguire il RHN SSL Maintenance T ool, e successivamente ripetere la fase 3 fino alla fase 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à: m an 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: 13

17 Red Hat Network Satellite 5.4 Client Configuration Guide T abella 3.1. Opzioni SSL Certificate Authority (CA) (rhn-ssl-tool --gen-ca --help) Opzione --gen-ca -h, --help -f, --force -p=, --password=password -d=, --dir=build_directory --ca-key=filename --ca-cert=filename --cert-expiration=ca_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit --set-com m on-nam e=hostname Descrizione 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. Visualizza la schermata d'aiuto con un elenco di opzioni di base specifiche alla generazione ed alla gestione di un Certificate Authority. Forza la creazione di una chiave privata CA nuova e/o di un certificato pubblico. La password CA. Vi verrà richiesto di inserire una password se la stessa non è stata ancora fornita. Registratela in modo sicuro. Richiesto per numerosi comandi - La directory dove i certificati e gli RPM vengono creati. Il default è./ssl-build. Il filename della chiave privata CA. Il default è RHN-ORG-PRIVAT E-SSL-KEY. Il filename del certificato pubblico CA. Il default è RHN-ORG-T RUST ED-SSL-CERT. La data di scadenza del certificato CA pubblico. Il default è il numero di giorni fino ad un giorno prima della data limite (o ). La sigla di una nazione composta da due lettere. Il default è US. Lo stato o provincia del CA. Il default è ''. La città o località. Il default è ''. L'azienda o l'organizzazione, come ad esempio Red Hat. Il default è Example Corp. Inc. L'unità dell'organizzazione, come RHN. Il default è ''. Generalmente non impostato per CA. - Il nome comune. --set-em ail= Generalmente non impostato per CA. - L'indirizzo . --rpm-packager=packager --rpm-vendor=vendor -v, --verbose Il Packager degli RPM generati, come ad esempio "RHN Admin (rhnadmin@example.com)." Il rivenditore degli RPM generati, come ad esempio "IS/IT Example Corp." Visualizza il verbose messaging. Accumultivo - "v" aggiunte risutano in 14

18 Capitolo 3. Infrastruttura SSL --ca-cert-rpm =CA_CERT_RPM --key-only --cert-only --rpm-only --no-rpm maggiori informazioni. Raramente modificato - Il nome dell'rpm che ospita il certificato CA (il filename di base, e non filename-versionrelease.noarch.rpm). Raramente utilizzato - Generalmente solo una chiave privata CA. Per maggiori informazioni consultate --gen-ca --keyonly --help. Rarramente utilizzata - Genera solo un certificato pubblico CA. Ricontrollare -- gen-ca --cert-only --help per maggiori informazioni. Rarramente utilizzata - Genera solo un RPM per il suo impiego. Ricontrollare -- gen-ca --rpm-only --help per maggiori informazioni. 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: 15

19 Red Hat Network Satellite 5.4 Client Configuration Guide T abella 3.2. Opzioni SSL Web Server (rhn-ssl-tool --gen-server --help) Opzione --gen-server -h, --help -p=, --password=password -d=, --dir=build_directory --server-key=filename --server-cert-req=filename --server-cert=filename --startdate=yymmddhhmmssz --cert-expiration=server_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit --set-hostnam e=hostname Descrizione 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. 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. La password CA. Vi verrà richiesto di inserire una password se la stessa non è stata ancora fornita. Registratela in modo sicuro. Richiesto per numerosi comandi - La directory dove i certificati e gli RPM vengono creati. Il default è./ssl-build. Il filename della chiave privata SSL del web server. Il default è server.key. Il filename della richiesta del certificato SSL del web server. Il default è server.csr. Il filename del certificato SSL del web server. Il default è server.cst. 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. 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 ). La sigla di una nazione composta da due lettere. Il default è US. Lo stato o provincia. Il default è Carolina del Nord La città o località. Il default è Raleigh. La compagnia o l'organizzazione, come ad esempio Red Hat. Il default è Example Corp. Inc. L'unità dell'organizzazione, come ad esempio RHN. Il default è l'unità. L'hostname del server RHN che deve ricevere la chiave. Il default viene dinamicamente impostato sull'hostname della build machine. 16

20 Capitolo 3. Infrastruttura SSL --set-em ail= --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --key-only --cert-req-only --cert-only --rpm-only --no-rpm --server-rpm =SERVER_RPM --server-tar=server_tar L'indirizzo del contatto del certificato. Il default è Il Packager degli RPM generati, come ad esempio "RHN Admin Il rivenditore degli RPM generati, come ad esempio "IS/IT Example Corp." Visualizza il verbose messaging. Accumultivo - "v" aggiunte risutano in maggiori informazioni. Raramente utilizzato - Genera solo una chiave privata del server. Ricontrollare -- gen-server --key-only --help per maggiori informazioni. Raramente utilizzato - Genera solo una richiesta del certificato del server. Ricontrollare --gen-server --certreq-only --help per maggiori informazioni. Raramente utilizzato - Genera solo un certificato del server. Ricontrollare --genserver --cert-only --help per maggiori informazioni. Raramente utilizzato - Genera solo un RPM per il suo utilizzo. Ricontrollare --genserver --rpm-only --help per maggiori informazioni. Raramente utilizzato - Esegue tutte le fasi relative al server ad eccezione di quella di generazione dell'rpm. Raramente modificato - Il nome dell'rpm che ospita il set di chiavi SSL del web server (il filename di base e non filenameversion-release.noarch.rpm). 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 filenameversion-release.tar) 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. T utti i componenti CA finiscono all'interno della directory di compilazione 17