Red Hat Network Satellite 5.4 Client Configuration Guide. Red Hat Network Satellite

Transcript

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

2 Client Configuration Guide Red Hat Network Satellite 5.4 Client Configuration Guide Red Hat Network Satellite Edizione 1 Copyright 2010 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. 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. All other trademarks are the property of their respective owners Varsity Drive Raleigh, NC USA Phone: Phone: Fax: Benvenuti alla Red Hat Network Satellite Client Configuration Guide.

3 1. Introduzione 1 2. 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 Tool con Satellite Infrastruttura SSL Una breve introduzione al SSL Il RHN SSL Maintenance Tool Processo di generazione di SSL Opzioni del RHN SSL Maintenance Tool 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 Come importare le chiavi GPG personalizzate Come utilizzare il RHN Bootstrap Preparazione Generazione Uso dello script Opzioni di RHN Bootstrap Esecuzione manuale dello script per la configurazione Come implementare kickstart 29 A. Esempio di Script Bootstrap 31 B. Cronologia della revisione 35 Indice analitico 37 iii

4 iv

5 Introduzione Capitolo 1. 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. 1

6 2

7 Applicazioni client Capitolo 2. Per poter utilizzare la maggior parte dei contenuti presenti nella classe-enterprise di Red Hat Network, come ad esempio la registrazione con un Satellite RHN, è necessario una configurazione delle ultimissime applicazioni client. Ottenere queste applicazioni prima di registrare il client con Red Hat Network può essere molto difficoltoso. Tale difficoltà si presenta soprattutto per gli utenti che migrano su Red Hat Network, un numero considerevole di sistemi più vecchi. Questo capitolo riporta tutte le tecniche da usare per risolvere il suddetto problema. Importante Red Hat consiglia ai client collegati ad un RHN Proxy Server o RHN Satellite Server, di eseguire l'ultimissimo aggiornamento di Red Hat Enterprise Linux, in modo da ottenere un collegamento corretto. Altresì, se i firewall del client sono configurati, le porte 80 e 443 doveno essere aperte in modo da garantire una funzionalità corretta con Red Hat Network 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): 3

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. The next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. To see how virtually all reconfiguration can be scripted, see Capitolo 6, Esecuzione manuale dello script per la configurazione 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. 4

9 Opzione up2date --configure 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 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. Tutte 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 (man up2date tramite la linea di comando). Per riconfigurare Red Hat Update Agent, emettete il seguente comando come utente root: up2date --configure A questo punto visualizzerete una casella di dialogo che vi presenterà varie impostazioni. All'interno della tabella Generale, sotto Select a Red Hat Network Server to use sostituite il valore di default con il fully qualified domain name (FQDN) del RHN Satellite Server o RHN Proxy Server, come ad esempio Mantenete però /XMLRPC alla fine. Una volta terminato fate clic su OK. 5

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. Tale problema potrà essere risolto modificando il valore all'interno del file di configurazione up2date. Consultate Sezione 2.2.3, «Aggiornamento manuale dei file di configurazione» per istruzioni più dettagliate. 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: 6

11 Implementazione del processo di failover del server 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 HTTP 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. Tale processo può essere particolarmente utile per l'esecuzione regolare di aggiornamenti se il vostro RHN Satellite Server o RHN Proxy Server primario è stato messo offline. Per utilizzare questa funzione, assicuratevi prima di eseguire la versione richiesta di up2date. Poi manualmente aggiungete i server secondari alle impostazioni serverurl e nosslserverurl nel file di configurazione /etc/sysconfig/rhn/up2date (come utente root). Aggiungete i fully qualified domain names (FQDN) per il Proxy o per Satellite, immediatamente dopo il server primario, separato da un punto e virgola (;). Per esempio: serverurl[comment]=remote server URL serverurl= 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. 7

12 Capitolo 2. Applicazioni client Figura 2.2. Applet del Package Updater L'applet del Package Updater resta nell'area di notifica nel pannello desktop e controlla periodicamente la presenza di nuovi aggiornamenti. L'applet vi permette altresì di eseguire alcuni compiti di gestione dei pacchetti selezionando l'icona di notifica e scegliendo tra le seguenti azioni: Refresh Controlla la presenza di nuovi aggiornamenti in RHN o Satellite. View Updates lancia l'applicazione Package Updater, così facendo l'utente è in grado di visualizzare gli aggiornamenti disponibili in dettaglio e configurarli in base alle proprie specifiche. Apply Updates Scarica ed installa tutti i pacchetti aggiornati. Quit chiude l'applet 2.4. Configurazione di Red Hat Network Alert Notification Tool con Satellite Red Hat Network Alert Notification Tool, l'icona circolare presente sul pannello del vostro desktop Red Hat Enterprise Linux 3 o 4, può essere configurata sui sistemi che eseguono Red Hat Enterprise Linux 3 o versioni più recenti, in modo da poter riconoscere gli aggiornamenti disponibili sui canali personalizzati del vostro RHN Satellite Server. Assicuratevi che il RHN Satellite Server sia configurato per supportare questa funzione. (RHN Proxy Server supporta applet senza alcuna modifica del client o del server.) Di seguito vengono riportate le fasi necessarie per configurare Red Hat Network Alert Notification Tool: 1. Assicuratevi che la versione del vostro RHN Satellite Server sia la 3.4 oppure una versione più recente, e di aver installato sul Satellite il pacchetto rhns-applet. Il pacchetto è disponibile nel canale software di Satellite RHN per versioni 3.4 o per versioni più recenti. 2. Recuperate il pacchetto rhn-applet-actions con up2date, oppure attraverso il canale software di Red Hat Network Tool. Installate il pacchetto su tutti i sistemi Red Hat Enterprise Linux 3 o sistemi client con versioni più recenti, per essere informati sulla presenza di aggiornamenti personalizzati con il Red Hat Network Alert Notification Tool. I sistemi client devono aver diritto ai livelli di servizio Management o Provisioning. 3. All'interno della versione Satellite del sito web di RHN, andate sulla pagina Informazioni sul sistema di ogni sistema, e fate clic sul link presente all'interno dell'area RHN Applet, per ridirezionare Red Hat Network Alert Notification Tool sul Satellite. Al momento del riavvio di applet, verrà applicata la nuova configurazione e verrà stabilito un collegamento al RHN Satellite Server in modo da ricevere gli aggiornamenti. 8

13 Infrastruttura SSL Capitolo 3. Per gli utenti di Red Hat Network le problematiche relative alla sicurezza ricoprono un aspetto molto importante. Una delle caretteristiche più importanti di Red Hat Network è la possibilità di processare ogni singola richiesta attraverso il Secure Sockets Layer, o SSL. Per mantenere questo livello di sicurezza, gli utenti che installano Red Hat Network all'interno della propria infrastruttura, devono generare i certificati e le chiavi SSL personalizzate. La creazione manuale e l'impiego delle chiavi SSL e dei certificati, può essere un processo molto impegnativo. Durante il processo di installazione, sia RHN Proxy Server che RHN Satellite Server vi permettono di creare le vostre chiavi SSL ed i certificati in base al vostro Certificate Authority (CA) privato. A tale scopo è disponibile una utility separata della linea di comando, RHN SSL Maintenance Tool.Le suddette chiavi insieme ai certificati, devono essere utilizzate su tutti i sistemi presenti all'interno della vosra infrastruttura gestita. In molti casi per l'utente, l'impiego di queste chiavi SSL e dei certificati, risulta essere un processo automatizzato. Questo capitolo descrive i metodi più idonei per condurre questi compiti. Vi preghiamo di notare che questo capitolo non affronta SSL in modo molto approfondito. RHN SSL Maintenance Tool è stato creato per diminuire la complessità presente durante l'impostazione e la gestione di questa public-key infrastructure (PKI). Per maggiori informazioni vi preghiamo di consultare alcuni dei manuali disponibili nella libreria a voi più vicina 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. Tecnicamente, entrambi possono essere identificati come chiavi (chiavi pubbliche e private). Ma è convenzione, quando si parla di SSL, indicare la parte pubblica di una coppia di chiavi SSL (o set di chiavi), come certificato pubblico SSL. Una infrastruttura SSL di una organizzazione è generalmente costituita da queste chiavi SSL e dai seguenti certificati: Certificate Authority (CA) SSL private key e certificato pubblico generalmente viene generato solo un set per ogni organizzazione. Il certificato pubblico viene firmato digitalmente dalla propria chiave privata. Il suddetto certificato viene distribuito ad ogni sistema. Chiave privata SSL del Web server e certificato pubblico un set per application server. Il certificato pubblico viene firmato digitalmente sia dalla propria chiave privata che dalla chiave privata SSL del CA. Spesso si fà riferimento ad un set di chiavi del Web server; questo perchè viene generata una richiesta di certificato SSL intermediaria. I dettagli relativi non hanno alcuna importanza in questa dscussione. Tutti e tre verranno impiegati su di un Server RHN. 9

14 Capitolo 3. Infrastruttura SSL Di seguito viene riportato uno scenario: Se avete un solo RHN Satellite Server e cinque RHN Proxy Server, allora sarà necessario generare una coppia di chiavi SSL del CA e sei set di chiavi SSL del server. Il certificato pubblico SSL del CA viene distribuito su tutti i sistemi ed utilizzato da tutti i client, per stabilire un collegamento con i rispettivi server upstream. Ogni server possiede il proprio set di chiavi SSL, il quale viene collegato all'hostname del server in questione, e generato utilizzando in combinazione la propria chiave privata SSL e la chiave privata SSL del CA. Tale processo stabilisce un'associazione verificabile digitalmente tra il certificato pubblico SSL del Web server, la coppia di chiavi SSL del CA e la chiave privata del server. Il set di chiavi del Web server non può essere condiviso con altri web server. Importante La parte più importante di questo sistema è la coppia di chiavi SSL del CA. Da quel certificato pubblico e dalla chiave privata, un amministratore sarà in grado di generare qualsiasi set di chiavi SSL del Web server. Questa coppia di chiavi SSL del CA deve essere sicura. Una volta teminata l'impostazione ed intrapresa l'esecuzione dell'infrastruttura RHN dei server, è fortemente consigliato archiviare la build-directory SSL generata con questo tool, e/o gli installatori su di un media separato, scrivere la password CA, e conservare sia il media che la password in un luogo sicuro Il RHN SSL Maintenance Tool Red Hat Network fornisce un tool della linea di comando utile per facilitare il processo di gestione della vostra infrastruttura sicura: RHN SSL Maintenance Tool, comunemente conosciuto tramite il suo comando rhn-ssl-tool. Il suddetto tool è disponibile come parte del pacchetto rhns-certstools. Questo pacchetto è disponibile all'interno dei canali software per l'ultimissima versione di RHN Proxy Server e RHN Satellite Server (ed anche per il RHN Satellite Server ISO). RHN SSL Maintenance Tool vi permette di generare la vostra coppia di chiavi SSL Certificate Authority, insieme ai set di chiavi SSL del Web server (talvolta chiamati key pairs). Questo tool rappresenta solo un tool di creazione. Esso è in grado di generare tutte le chiavi SSL ed i certificati necessari. Altresì è anche in grado di racchiudere i file in pacchetti in formato RPM, per una distribuzione ed una installazione rapida su tutte le macchine client. Tuttavia è da tener presente che esso non impiega i pacchetti in questione. Tale compito è responsabilità dell'amministratore, o in molti casi, viene automatizzato dal RHN Satellite Server. Nota Bene Soddisfando i requisiti minimi previsti, rhns-certs-tools, il quale contiene rhn-ssltool, può essere installato ed eseguito su tutti i sistemi Red Hat Enterprise Linux correnti. Tale funzione viene offerta agli amministratori, per facilitare il loro compito di gestione delle proprie infrastrutture SSL direttamente dalle proprie workstation, o da un altro sistema diverso dai propri Server RHN. Di seguito viene indicato quando utilizzare il suddetto tool: Durante l'aggiornamento del certificato pubblico CA - ciò è molto raro. Durante l'installazione di un RHN Proxy Server versione 3.6 o con una versione più recente, in grado di collegarsi ai server RHN centrali come proprio servizio top-level - il servizio hosted, per ragioni di sicurezza, non potrà essere una repositoty per la vostra chiave SSL del CA e per il certificato, infatti quest'ultimi risultano essere privati alla vostra organizzazione. 10

15 Processo di generazione di SSL 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 Tool sono una maggiore sicurezza, flessibilità e trasferibilità. Una maggiore sicurezza viene implementata attraverso la creazione di chiavi SSL del Web server separate e di certificati per ogni server RHN, tutti firmati da una coppia singola di chiavi SSL del Web server creata dalla vostra organizzazione. Una maggiore flessibilità viene fornita grazie all'abilità del tool, di lavorare su qualsiasi macchina sulla quale è stato installato il pacchetto 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 Tool, completate i seguenti compiti seguendo l'ordine indicato. Consultate le sezioni restanti per le informazioni necessarie: 1. Installare il pacchetto rhns-certs-tools su di un sistema all'interno della vostra organizzazione, ma non necessariamente RHN Satellite Server o RHN Proxy Server. 2. Create una coppia di chiavi SSL del Certificate Authority per la vostra organizzazione, ed installate l'rpm risultante o il certificato pubblico, su tutti i sistemi client. 3. Create un set di chiavi SSL del web server per ogni Proxy e Satellite da impiegare, ed installate gli RPM risultanti sui server RHN, successivamente riavviate il servizio httpd: 11

16 Capitolo 3. Infrastruttura SSL /sbin/service httpd restart 4. Archiviate il build tree SSL - che consiste in una build directory primaria e di tutte le sotto-directory e file- su di un media rimovibile, come ad esempio un floppy disk. (I requisiti sullo spazio del disco sono insignificanti). 5. Verificate e successivamente conservate l'archivio in questione in una posizione sicura, come ad esempio quella descritta per i backup nelle sezioni Requisiti Aggiuntivi del Proxy o della Satellite installation guide. 6. Registrate e conservate la password CA per un suo utilizzo futuro. 7. Per motivi di sicurezza cancellate il buid tree dal build system 'sistema di compilazione', ma solo quando l'intera infrastruttura RHN risulta essere pronta e configurata. 8. Quando è necessario un set di chiavi SSL aggiuntivo del web server, ripristinate il build tree su di un sistema in grado di eseguire il RHN SSL Maintenance Tool, e successivamente ripetere la fase 3 fino alla fase 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: rhnssl-tool --help (generale), rhn-ssl-tool --gen-ca --help (Certificate Authority), e rhnssl-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 --gen-ca -h, --help -f, --force -p=, --password=password -d=, --dir=build_directory 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. 12

17 Opzioni del RHN SSL Maintenance Tool Opzione --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-common-name=hostname Descrizione Il filename della chiave privata CA. Il default è RHN-ORG-PRIVATE-SSL-KEY. Il filename del certificato pubblico CA. Il default è RHN-ORG-TRUSTED-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- = Generalmente non impostato per CA. - L'indirizzo . --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --ca-cert-rpm=ca_cert_rpm --key-only --cert-only --rpm-only 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 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 -- key-only --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. 13

18 Capitolo 3. Infrastruttura SSL Opzione --no-rpm Descrizione 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 --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 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. 14

19 Opzioni del RHN SSL Maintenance Tool Opzione --set-org=organization --set-org-unit=set_org_unit --set-hostname=hostname --set- = --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 Descrizione 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. L'indirizzo del contatto del certificato. Il default è admin@example.corp. 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 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 -- cert-req-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 -- gen-server --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 15

20 Capitolo 3. Infrastruttura SSL Opzione Descrizione del RHN Proxy Server (il filename di base e non filename-version-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. Tutti i componenti CA finiscono all'interno della directory di compilazione specificata sulla linea di comando, generalmente /root/ssl-build (o /etc/sysconfig/ rhn/ssl per vecchi Satellite e Proxy). Per generare una coppia di chiavi SSL del CA, emettere un comando simile al seguente: rhn-ssl-tool --gen-ca --password=my_ca_password --dir="/root/ssl-build" \ --set-state="north Carolina" --set-city="raleigh" --set-org="example Inc." \ --set-org-unit="ssl CA Unit" Sostituire i valori dell'esempio con i valori appropriati per la vostra organizzazione. Ciò darà luogo ai seguenti file all'interno della directory di compilazione specificata: RHN-ORG-PRIVATE-SSL-KEY la chiave privata SSL del CA RHN-ORG-TRUSTED-SSL-CERT il certificato pubblico SSL del CA rhn-org-trusted-ssl-cert-ver-rel.noarch.rpm l'rpm creato per la distribuzione sui sistemi client. Contiene il certificato pubblico SSL del CA (sopra riportato), ed è in grado di installarlo in: /usr/share/rhn/rhn-org-trusted-ssl-cert rhn-ca-openssl.cnf il file di configurazione del CA di SSL latest.txt elenca sempre le ultimissime versioni dei file rilevanti. Una volta terminato sarete pronti a distribuire l'rpm sui sistemi client. Consultate la Sezione 3.3, «Impiego del Certificato Pubblico SSL del CA per i client» Creazione del set di chiavi SSL del Web Server Anche se è necessario aver generarato a priori una coppia di chiavi SSL del CA, molto probabilmente sarete in grado di generare con più frequenza dei set di chiavi SSL del Web server, in modo particolare se sono stati impiegati più di un Proxy o Satellite. Da notare che il valore di --sethostname risulta essere diverso per ogni server. In altre parole, un set diverso di chiavi SSL e di certificati, deve essere generato ed installato per ogni hostname del server RHN. Il build process per il certificato del server funziona in modo simile alla generazione della coppia di chiavi SSL del CA con una sola eccezione: Tutti i componenti server terminano nella sottodirectory della build directory che riflettono il nome della macchina del build system, come ad esempio /root/ ssl-build/machine_name. Per generare i certificati del server, emettere un comando simile: 16

21 Impiego del Certificato Pubblico SSL del CA per i client 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- ="admin@example.com" \ --set-hostname="rhnbox1.example.com Sostituite i valori dell'esempio con i valori appropriati per la vostra organizzazione. Ciò darà luogo ai seguenti file all'interno di una sottodirectory della build directory di una macchina specifica: server.key la chiave server privata SSL del web server server.csr richiesta del certificato SSL del Web server server.crt certificato pubblico SSL del web server rhn-org-httpd-ssl-key-pair-machine_name-ver-rel.noarch.rpm l'rpm creato per la distribuzione sui server RHN. Viene altresì generato il file associato src.rpm. Il suddetto RPM contiene i tre file sopra riportati. Esso eseguirà la loro installazione nelle seguenti posizioni: /etc/httpd/conf/ssl.key/server.key /etc/httpd/conf/ssl.csr/server.csr /etc/httpd/conf/ssl.crt/server.crt rhn-server-openssl.cnf il file di configurazione SSL del Web server latest.txt elenca sempre le ultimissime versioni dei file rilevanti. Una volta terminato, potrete distribuire ed installare l'rpm sui rispettivi server RHN. Da notare che il servizio httpd deve essere riavviato subito dopo l'installazione: /sbin/service httpd restart 3.3. Impiego del Certificato Pubblico SSL del CA per i client Grazie alla generazione dell'rpm e del certificato pubblico SSL del CA, sia il processo di installazione del RHN Proxy Server che quello di RHN Satellite Server rendono l'impiego del client un processo molto semplice. Posizionando una loro copia all'interno della directory /var/www/html/pub/ del server RHN, questi processi di installazione rendono sia il certificato che l'rpm disponibili al pubblico. È possibile controllare la directory pubblica, navigando attraverso qualsiasi web browser: 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 wget 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 \ 17

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

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

24 20

25 Capitolo 5. Come utilizzare il RHN Bootstrap Red Hat Network fornisce un tool in grado di automatizzare gran parte dei processi di riconfigurazione del manuale descritti nei precedenti capitoli: RHN Bootstrap. Il suddetto tool ricopre un ruolo importante all'interno del RHN Satellite Server Installation Program, e permette la generazione dello script di bootstrap durante l'installazione. Gli utenti RHN Proxy Server e quelli in possesso di impostazioni Satellite aggiornate, necessitano di un tool bootstrap in grado di essere usato in modo indipendente. RHN Bootstrap, invocato con il comando /usr/bin/rhn-bootstrap, è in grado di far fronte a tale esigenza ed è presente per default sia su RHN Satellite Server che sul RHN Proxy Server. Se utilizzato correttamente, lo script generato da questo tool può essere eseguito da qualsiasi sistema client, in modo da svolgere i seguenti compiti: Per ridirezionare le applicazioni client sul RHN Proxy o Satellite Per importare le chiavi GPG personalizzate Per installare i certificati SSL Per registrare il sistema su RHN, sui gruppi di sistemi particolari e sui canali con l'aiuto delle chiavi di attivazione Per l'esecuzione di attività varie post-installazione, incluso l'aggiornamento dei pacchetti, l'esecuzione dei processi di riavvio, e la modifica della configurazione di RHN Gli utenti dovrebbero tener presente i rischi derivati dall'utilizzo di uno script per condurre il processo di configurazione. I tool di sicurezza, come ad esempio i certificati SSL, vengono installati dallo stesso script; per questo motivo essi non esistono ancora sui sistemi, e non possono essere utilizzati per processare le transazioni. Ciò permette di impersonificare un Satellite e quindi di trasmettere dati corrotti. Tale rischio viene alleviato dal fatto che quasi tutti i Satellite ed i sistemi client, operano dietro dei firewall limitando così il traffico esterno. Il processo di registrazione viene eseguito tramite SSL e quindi risulta essere protetto. Lo script di bootstrap bootstrap.sh viene automaticamente posizionato nella directory /var/www/ html/pub/bootstrap/ del server RHN. Da li può essere scaricato ed eseguito su tutti i sistemi client. Da notare che sarà necessario eseguire alcune modifiche post-generazione, come riportato nelle seguenti sezioni. Per un elenco completo di opzioni dei tool consultate Sezione 5.4, «Opzioni di RHN Bootstrap». Per finire, consultate Appendice A, Esempio di Script Bootstrap per uno script d'esempio Preparazione Poichè RHN Bootstrap (rhn-bootstrap) dipende da altri componenti dell'infrastruttura di Red Hat Network, per un processo corretto di configurazione dei sistemi client i suddetti componenti devono essere pronti prima della generazione dello script. Il seguente elenco identifica le misure iniziali consigliate. Generare le chiavi di attivazione invocate dallo script. Le suddette chiavi possono essere usate per regisrare i sistemi Red Hat Enterprise Linux, abilitarli ad un livello di servizio RHN, e sottoscriverli su canali specifici e gruppi del sistema, il tutto tramite una sola azione. Da notare che è necessario avere gli entitlement di Management per poter utilizzare una chiave di attivazione, mentre per l'integrazione contemporanea di chiavi di attivazione multiple sono necessari gli entitlement di Provisioning. Generate le chiavi di attivazione attraverso la pagina Chiavi di attivazione all'interno della categoria Sistemi del sito web di RHN (sia i server RHN centrali per Proxy, o il fully qualified 21