Guida all'installazione 5.1

Transcript

1 RHN Proxy Server Guida all'installazione 5.1 ISBN: Publication date:

2 RHN Proxy Server 5.1.1

3 RHN Proxy Server 5.1.1: Guida all'installazione Copyright 2008 Red Hat, Inc. Copyright 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries. All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the key is: CA B D6 9D FC 65 F6 EC C CD DB 42 A6 0E 1801 Varsity Drive Raleigh, NC USA Phone: Phone: Fax: PO Box Research

4 RHN Proxy Server 5.1.1

5 1. Introduzione Red Hat Network RHN Proxy Server Termini da comprendere Come funziona Requisiti Requisiti software Requisiti hardware Requisiti di spazio del disco Requisiti aggiuntivi Esempio di topologie Topologia di Proxy singolo Topologia orizzontale di proxy multipli Topologia verticale di Proxy multipli Proxy con RHN Satellite Server Installazione Installazione di base Processo di installazione del RHN Proxy Server RHN Package Manager Creazione di un canale privato Caricamento dei pacchetti Opzioni della linea di comando Troubleshooting Gestione del servizio Proxy File di log Domande e risposte Problemi generali Host non trovato/impossibile determinare il FQDN Errori di connessione Problematiche di Caching Proxy Debugging di Red Hat...38 A. Esempio file di configurazione di RHN Proxy Server...39 Indice...41 v

6 vi

7 Capitolo 1. Introduzione 1. Red Hat Network Red Hat Network (RHN) è l'ambiente di supporto del sistema e di gestione dei sistemi Red Hat o di una serie di reti. Red Hat Network racchiude i tool, i servizi e le repository per le informazioni necessarie per massimizzare l'affidabilità, la sicurezza e la prestazione dei sistemi stessi. Per poter usare RHN, gli amministratori possono registrare i profili software e hardware, conosciuti anche come Profili del Sistema, dei propri sistemi client con Red Hat Network. Quando un sistema client richiede gli aggiornamenti, solo i pacchetti applicabili per il client vengono ritornati (basati sul profilo software conservato sui server di RHN). I vantaggi nell'uso di Red Hat Network includono: Scalabilità con Red Hat Network, un solo amministratore di sistema è in grado di impostare e gestire più facilmente centinaia o migliaia di sistemi Red Hat, in modo più accurato e veloce rispetto ad un amministratore che gestisce un solo sistema senza Red Hat Network. Protocolli standard vengono utilizzati protocolli standard per gestire la sicurezza e aumentare la capacità. Per esempio, XML-RPC conferisce a Red Hat Network la possibilità di fare molto di più che il semplice download dei file. Sicurezza tutte le comunicazioni tra i sistemi registrati e Red Hat Network hanno luogo attraverso collegamenti internet sicuri. Visualizzazione degli Errata Alert visualizzate più facilmente gli Errata Alert per tutti i vostri sistemi client, attraverso un solo sito web. Azioni programmate utilizzate il sito web per poter programmare le azioni, incluso gli Errata Alert, le installazioni dei pacchetti e gli aggiornamenti del profilo software. Simplificazione gestione più semplice dei sistemi di Red Hat, processo automatizzato. 2. RHN Proxy Server Un RHN Proxy Server è un meccanismo di package-caching in grado di ridurre i requisiti di larghezza di banda per RHN, permettendo l'impiego di pacchetti personalizzati. Gli utenti di Proxy conservano all'interno della cache gli RPM, come ad esempio aggiornamenti errata provenienti da RPM personalizzati o di Red Hat generati dalla propria organizzazione, su di un server centrale interno. Successivamente, i sistemi client ricevono i suddetti aggiornamenti provenienti dal Proxy invece di accedere individualmente ad internet. Anche se i pacchetti vengono serviti dal Proxy, i profili del sistema client e le informazioni dell'utente vengono conservati sui server RHN centrali sicuri 1, i quali servono anche il sito web 1 In questo documento "RHN" potrebbe riferirsi ai siti Hosted di RHN ( o ad un RHN Satellite Server. 1

8 Capitolo 1. Introduzione di RHN (rhn.redhat.com). Il Proxy si comporta come da tramite per i sistemi client e Red Hat Network (o RHN Satellite Server). Ogni transazione viene autenticata ed il Red Hat Update Agent controlla la firma GPG di ogni pacchetto recuperato dal RHN Proxy Server. locale. In aggiunta alla conservazione dei pacchetti Red Hat ufficiali, il RHN Proxy Server può essere configurato in modo da consegnare pacchetti personalizzati di una organizzazione, dai canali RHN privati tramite il RHN Package Manager. Per esempio, una organizzazione potrebbe sviluppare il proprio software, compattandolo in un RPM, firmarlo con la propria firma GPG e facendo aggiornare dal RHN Proxy Server locale tutti i sistemi presenti nella rete con le ultimissime versioni di software personalizzato. I vantaggi nell'utilizzo di RHN Proxy Server includono: Scalabilità è possibile implementare RHN Proxy Server multipli locali in una organizzazione. Sicurezza viene mantenuto un collegamento sicuro end-to-end: dai sistemi client al RHN Proxy Server locale, ed ai server di Red Hat Network. Risparmio di tempo i pacchetti vengono consegnati ad una velocità maggiore attraverso una rete dell'area locale invece di internet. Risparmio di larghezza di banda i pacchetti vengono scaricati da RHN solo una volta (per meccanismo di caching del Server Proxy locale), invece di scaricare ogni pacchetto per ogni sistema client. Aggiornamenti personalizzati è possibile creare un sistema automatizzato di consegna dei pacchetti, per i pacchetti software personalizzati e per i pacchetti Red Hat ufficiali necessari per i sistemi client. I canali privati RHN personalizzati permettono ad una organizzazione di consegnare in modo automatico i pacchetti interni. Configurazione personalizzata è possibile rifiutate o garantite gli aggiornamenti ad architetture specifiche e a determinate versioni dell'os. Solo un collegamento internet necessario Poichè i client si collegano solo al RHN Proxy Server e non ad Internet, essi avranno bisogno di un solo collegamento Local Area Network per il Proxy. Solo il RHN Proxy Server ha bisogno di un collegamento Internet per contattare i server RHN, a meno che il RHN Proxy Server non stia utilizzando un RHN Satellite Server; in tal caso solo il RHN Satellite Server avrà bisogno di un collegamento Internet. 3. Termini da comprendere Prima di comprendere RHN Proxy Server, è importante conoscere i seguenti termini di Red Hat Network Canale Un canale è un elenco di pacchetti software. Sono presenti due tipi di canali: i canali di base 2

9 Come funziona ed i canali figlio. Un canale di base consiste in un elenco di pacchetti basati su di una specifica architettura e release di Red Hat. Un canale figlio è un canale associato con un canale di base che contiene pacchetti aggiuntivi. Organization Administrator Un Organization Administrator è un utente con il livello più elevato di controllo in un account Red Hat Network di una organizzazione. I membri con il suddetto ruolo possono aggiungere o rimuovere altri utenti, sistemi e gruppi di sistema. Una organizzazione di Red Hat Network deve avere almeno un Organization Administrator. Channel Administrator Un Channel Administrator possiede un accesso completo alle capacità di gestione del canale. Gli utenti con questo ruolo sono in grado di creare i canali e di assegnare i pacchetti ai canali. Questo ruolo può essere assegnato da un Organization Administrator attraverso la tabella Utenti del sito web di RHN. Red Hat Update Agent Il Red Hat Update Agent è il Red Hat Network client application (up2date o yum) il quale permette agli utenti di ripristinare ed installare pacchetti nuovi o aggiornati per il sistema client sul quale viene eseguita l'applicazione. Traceback Un traceback rappresenta una descrizione dettagliata di "quello che non ha funzionato" ed è utile per il troubleshooting del RHN Proxy Server. I messaggi di traceback vengono generati automaticamente al verificarsi di un errore critico, e vengono inviati ai membri designati all'interno del file di configurazione del RHN Proxy Server. Per maggiori informazioni su questi termini e su altri argomenti consultate la Red Hat Network Reference Guide disponibile su e 4. Come funziona Il Red Hat Update Agent sui sistemi client non contatta direttamente il server di Red Hat Network. Al contrario il client si collega a turno ad un RHN Proxy Server il quale a sua volta si collega ai server di Red Hat Network oppure ad un RHN Satellite Server. Per questo motivo i sistemi client non hanno bisogno di un accesso diretto ad Internet, ma solo di un accesso al RHN Proxy Server. Importante Per assicurare un collegamento corretto, Red Hat consiglia vivamente che i client collegati ad un RHN Proxy Server eseguano l'ultimissima versione di Red Hat Enterprise Linux. I client che accedono direttamente al RHN vengono autenticati dai server di RHN. I client che accedono al RHN Proxy Server vengono autenticati dal RHN; tuttavia in questo caso il Proxy 3

10 Capitolo 1. Introduzione fornisce sia l'autenticazione che le informazioni d'instradamento al RHN. Dopo una corretta autenticazione, il server di Red Hat Network indica al RHN Proxy Server la possibilità di eseguire un'azione specifica per il client. Il RHN Proxy Server scarica tutti i pacchetti aggiornati (se non presenti all'interno della propria cache) e li consegna al sistema client. Le richieste provenienti dal Red Hat Update Agent sui sistemi client vengono ancora autenticate dal server, ma la consegna dei pacchetti risulta essere più veloce poichè i pacchetti vengono salvati all'interno della cache nella HTTP Proxy Caching Server o RHN Proxy Server (per i pacchetti locali); Il RHN Proxy Server ed il sistema client sono collegati tramite le LAN, e sono limitati solo dalla velocità della rete locale. Il processo di autenticazione viene eseguito tramite le seguenti fasi: 1. Il client esegue un'azione di login al momento di iniziare una sessione client. Il login viene passato attraverso uno o più RHN Proxy Server fino a raggiungere un server Red Hat Network. 2. Il server di Red Hat Network cercherà di autenticare il client. Se tale processo ha successo, il server tornerà un token della sessione tramite la catena dei RHN Proxy Server. Questo token, all'interno del quale vi è una firma ed una scadenza, contiene le informazioni relative all'utente incluso le sottoscrizioni del canale, nome utente ecc. 3. Ogni RHN Proxy Server conserva questo token sul proprio file system in /var/cache/rhn/. L'azione di caching riduce l'overhead dovuto all'autenticazione con i server Red Hat Network, migliorando le prestazioni di Red Hat Network. 4. Questo token viene ritornato alla macchina del client ed utilizzato in successive azioni sul Red Hat Network. Dal punto di vista del client, non vi è alcuna differenza tra un RHN Proxy Server ed un Red Hat Network. Dal punto di vista del server Red Hat Network, un RHN Proxy Server risulta essere un tipo particolare di client RHN. I client non risultano essere influenzati dai tragitti seguiti dalle richieste per raggiungere un server Red Hat Network. Il tutto viene implementato nei server Red Hat Network e RHN Proxy Server. Facoltativamente RHN Package Manager può essere installato e configurato per servire i pacchetti personalizzati. Qualsiasi pacchetto che non risulta essere un pacchetto ufficiale di Red Hat, incluso i pacchetti personalizzati scritti in modo specifico per una organizzazione, possono essere serviti solo da un canale software privato (riferito anche come canale software personalizzato). Dopo aver creato un canale RHN privato, i pacchetti RPM personalizzati vengono associati con quel canale attraverso il caricamento delle intestazioni del pacchetto sui server di RHN. Verranno caricate solo le intestazioni e non i file del pacchetto. Le intestazioni sono necessarie poichè esse contengono informazioni RPM importanti, come ad esempio le dipendenze software che permettono a RHN di automatizzare le installazioni del pacchetto. I pacchetti RPM personalizzati vengono conservati sul RHN Proxy Server ed inviati ai sistemi client dalla rete dell'area locale dell'organizzazione. 4

11 Come funziona La configurazione di una rete del computer per l'utilizzo del RHN Proxy Server è un processo molto semplice. Le applicazioni di Red Hat Network presenti sui sistemi client devono essere configurate in modo da collegarsi al RHN Proxy Server e non ai server di Red Hat Network. Consultate la RHN Client Configuration Guide per informazioni. Da parte del proxy, il proxy precedente deve specificare il proxy successivo all'interno della catena (la quale eventualmente termina con un server Red Hat Network). Se usate RHN Package Manager i sistemi client devono essere sottoscritti ad un canale RHN privato. 5

12 6

13 Capitolo 2. Requisiti Prima di iniziare il processo d'installazione è necessario soddisfare i requisiti previsti. Per eseguire una installazione della versione 3.6 o una versione più recente di RHN Proxy Server usando RHN Satellite Server, è necessario che la versione del Satellite risulti essere la 3.6 oppure una versione più recente. 1. Requisiti software Per eseguire una installazione è necessario avere i seguenti componenti software: Sistema operativo di base RHN Proxy Server è supportato con Red Hat Enterprise Linux AS 3 Update 5 e con versioni più recenti, oppure con Red Hat Enterprise Linux AS 4. Il sistema operativo può essere installato tramite disco, immagine ISO locale, kickstart oppure tramite qualsiasi metodo supportato da Red Hat. Importante Se desiderate ottenere un servizio di livello Monitoring, è necessario installare il vostro RHN Proxy Server su Red Hat Enterprise Linux AS 3 Update 5 o Red Hat Enterprise Linux AS 4. Essi infatti risultano essere i soli sistemi operativi supportati per i proxy in grado di servire i sistemi aventi diritto al Monitoring. Ogni versione di Red Hat Enterprise Linux AS richiede un determinato set di pacchetti per poter supportare RHN Proxy Server. Qualsiasi altro set potrà causare degli errori durante il processo di installazione. Per questo motivo Red Hat consiglia di ottenere il set di pacchetti desiderato nei seguenti modi: Nota Bene Per eseguire kickstart su Red Hat Enterprise Linux AS 4 o Red Hat Enterprise Linux AS 3 Update 5, specificare il seguente gruppo di Base Per installare Red Hat Enterprise Linux AS 4 o Red Hat Enterprise Linux AS 3 Update 5 tramite CD o immagine ISO, selezionare il seguente gruppo: Minimal Avvertimento In Red Hat Enterprise Linux AS 4 il Security-enhanced Linux (SELinux) deve essere disabilitato prima di installare il RHN Proxy Server. Per fare questo 7

14 Capitolo 2. Requisiti eseguite uno dei metodi di seguito riportati: Durante l'installazione con l'immagine ISO o CD, selezionate Disabled alla visualizzazione delle opzioni per il supporto di SELinux. Per fare questo nelle installazioni kickstart, inserire il comando selinux --disabled Dopo aver completato l'installazione modificate il file /etc/selinux/config in modo da leggere SELINUX=disabled e riavviate il sistema. Per finire è possibile utilizzare il comando system-config-securitylevel-tui e riavviare il sistema. Un entitlement RHN Proxy Server disponibile all'interno del vostro account Red Hat Network. Un entitlement di Provisioning disponibile all'interno del vostro account Red Hat Network (il quale dovrebbe essere presente con il vostro entitlement RHN Proxy Server). Un accesso al canale Red Hat Network Tools per la versione installata di Red Hat Enterprise Linux AS. Tutti i pacchetti rhncfg* installati sul Proxy (dal canale RHN Tools). Sul Proxy è necessaria la presenza del pacchetto rhns-certs-tools (dal canale RHN Tools), oppure della password del certificato CA del secure sockets layer (SSL), utilizzato per generare il certificato del server genitore (come nel caso del RHN Satellite Server). Configurate il sistema in modo che lo stesso accetti i comandi remoti e la gestione della configurazione attraverso Red Hat Network. Per informazioni consultate la Sezione 2, «Processo di installazione del RHN Proxy Server». 2. Requisiti hardware Per un RHN Proxy Server sono necessari i seguenti requisiti: Processore Pentium III, 1.26GHz, 512K cache o equivalente 512 MB di memoria 3 GB di storage per una installazione di base di Red Hat Enterprise Linux AS 6 GB di storage per distribuzione/canale 8

15 Requisiti di spazio del disco Il carico sull'apache Web server è direttamente associato alla frequenza con la quale i sistemi client si collegano al Proxy, quindi se si riduce l'intervallo predefinito di quattro ore (o 240 minuti) come set nel file di configurazione /etc/sysconfig/rhn/rhnsd dei sistemi client, aumenterete significativamente il carico su questo componente. 3. Requisiti di spazio del disco Il meccanismo di caching utilizzato dal RHN Proxy Server è lo Squid HTTP proxy, il quale è in grado di risparmiare una notevole quantità di larghezza di banda per i client. Altresì esso dovrebbe avere una certa quantità di spazio disponibile. I pacchetti conservati nella cache si trovano in /var/spool/squid. L'allocazione necessaria per ogni distribuzione/canale è di 6 GB. Se il RHN Proxy Server è configurato per distribuire pacchetti locali o personalizzati, assicuratevi che il mount point /var presente sul sistema che conserva i pacchetti locali, abbia uno spazio sufficiente per contenere tutti i pacchetti personalizzati, i quali a loro volta sono conservati in /var/spool/rhn-proxy. Lo spazio necessario del disco per i pacchetti locali, dipende dal numero di pacchetti personalizzati serviti. 4. Requisiti aggiuntivi I seguenti requisiti aggiuntivi devono essere soddisfatti prima di considerare conclusa l'installazione del RHN Proxy Server. Accesso completo I sistemi client necessitano di un accesso completo ai servizi RHN Proxy Server ed alle porte. Regole per il firewall RHN consiglia vivamente l'utilizzo del firewall per il RHN Proxy Server durante l'utilizzo di internet. Tuttavia è necessario aprire varie porte TCP sul Proxy, a seconda della implementazione RHN Proxy Server: Porta Direzione Motivi 80 Uscita Il Proxy utilizza questa porta per raggiungere rhn.redhat.com 1, xmlrpc.rhn.redhat.com 2 e satellite.rhn.redhat.com 3 (se non eseguito in modalità scollegata per Satellite) 80 Ingresso Le richieste del client arrivano attraverso http o https

16 Capitolo 2. Requisiti Porta Direzione Motivi 443 Ingresso Le richieste del client arrivano attraverso http o https 443 Uscita Per raggiungere e Uscita Se il vostro Proxy è collegato ad un RHN Satellite Server, il Monitoring stabilisce i collegamenti su rhnmd in esecuzione sui sistemi client tramite questa porta TCP, se Monitoring è stato abilitato ed i probe sono configurati sui sistemi registrati Ingresso L'apertura di questa porta permetterà di stabilire collegamenti client osad al demone jabberd sul Proxy durante l'utilizzo di RHN Push Uscita Se il vostro Proxy è collegato ad un RHN Satellite Server, questa porta deve essere aperta per stabilire collegamenti server-to-server tramite jabberd da parte di RHN Push. Tabella 2.1. Porte da aprire sul Proxy Orari sincronizzati del sistema È presente una certa sensibilità per quanto riguarda il tempo di connettività ad un Web server in grado di eseguire un SSL (Secure Sockets Layer); è obbligatorio che le impostazioni dell'ora sui client e sul server, siano ragionevolmente molto vicine l'un l'altra, in modo da non far scadere il certificato SSL prima o durante il suo utilizzo. A tal proposito è consigliato utilizzare il Network Time Protocol (NTP) per sincronizzare gli orologi. Fully Qualified Domain Name (FQDN) Il sistema per mezzo del quale RHN Proxy Server sarà installato, deve risolvere il proprio FQDN in modo corretto. Un account Red Hat Network Gli utenti che si collegheranno ai server Red Hat Network centrali per ricevere gli aggiornamenti incrementali, avranno bisogno di un account con Red Hat Network. Questo account dovrebbe essere impostato al momento dell'acquisto con il rappresentante in questione. Backup delle informazioni di login È fondamentale che i clienti conservino tutte le informazioni di login primarie. Per RHN 10

17 Requisiti aggiuntivi Proxy Server tale processo include i nomi utente, e le password per l'account di un Organization Administrator e per la generazione del certificato SSL. Red Hat consiglia vivamente di copiare queste informazioni su due dischetti floppy separati, stampandole su di un foglio e conservandole in un luogo sicuro. Posizioni della distribuzione Poichè proxy inoltra virtualmente tutte le richieste HTTP locali ai server RHN centrali, è necessario posizionare i file destinati alla distribuzione (come ad esempio in un albero di installazione di kickstart), in un luogo di non-forwarding sul Proxy: /var/www/html/pub/. I file presenti in questa directory possono essere scaricati direttamente dal Proxy. Tale operazione può essere molto utile per la distribuzione di chiavi GPG, o per la determinazione degli alberi di installazione per kickstart. Altresì Red Hat consiglia di non rendere pubblicamente disponibili i sistemi che eseguono il codice. Solo gli amministratori di sistema, e non gli utenti normali, devono avere accesso alla shell per queste macchine. Tutti i servizi non necessari devono essere disabilitati. Per disabilitare i suddetti servizi è possibile utilizzare ntsysv o chkconfig. Per finire, è necessario essere in possesso dei seguenti documenti tecnici per un loro utilizzo seguendo l'ordine riportato: 1. La RHN Proxy Server Installation Guide Questa guida fornisce le fasi necessarie per impostare ed eseguire correttamente un RHN Proxy Server. 2. La RHN Client Configuration Guide Questa guida spiega come configurare i sistemi serviti da un RHN Proxy Server o RHN Satellite Server. (Tale operazione richiederà anche l'utilizzo della RHN Reference Guide, la quale contiene tutte le fasi necessarie per la registrazione e l'aggiornamento dei sistemi.) 3. La RHN Channel Management Guide Questa guida identifica in modo particolare i metodi consigliati per la creazione dei pacchetti e dei canali personalizzati, ed i metodi per la gestione degli Errata privati. 4. La RHN Reference Guide Questa guida descrive come creare gli account RHN, registrare ed aggiornare i sistemi, ed utilizzare al meglio il sito web di RHN. La suddetta guida potrebbe essere utile durante l'intero processo di installazione e configurazione. 11

18 12

19 Capitolo 3. Esempio di topologie RHN Proxy Server può essere configurato in diversi modi, selezionatene uno in base ai seguenti fattori: 1. Il Numero totale di sistemi client serviti dal RHN Proxy Server 2. Numero massimo previsto di client, che si collegheranno contemporaneamente al RHN Proxy Server. 3. Numero di canali e pacchetti personalizzati serviti dal RHN Proxy Server. 4. Numero di RHN Proxy Server utilizzato nell'ambiente utente. Il resto del capitolo descrive le configurazioni possibili, spiegandone anche i benefici relativi. 1. Topologia di Proxy singolo La configurazione più semplice è quella che utilizza un RHN Proxy Server singolo per servire l'intera rete. Tale configurazione è sufficiente per servire un piccolo gruppo di client, ed una rete che potrebbe beneficiare del caching degli RPM di Red Hat, insieme alla conservazione dei pacchetti personalizzati su di un server locale. Lo svantaggio nell'utilizzo di un solo RHN Proxy Server è rappresentato dalle prestazioni, infatti esse tenderanno a peggiorare con l'aumentare del numero dei client che richiede i pacchetti. Figura 3.1. Topologia di Proxy singolo 2. Topologia orizzontale di proxy multipli 13

20 Capitolo 3. Esempio di topologie Per reti più grandi sarà necessario implementare un metodo più complesso, come quello di avere RHN Proxy Server multipli tutti collegati individualmente al Red Hat Network. Questa configurazione orizzontale, bilancia il carico dovuto alle richieste del client, abilitando altresì ogni Proxy alla sincronizzazione simultanea con RHN. Uno svantaggio di questa struttura è rappresentato dal fatto che i pacchetti, caricati su di un singolo Proxy, devono essere distribuiti ai propri server imparentati 'sibling'. Questa situazione può essere risolta in uno dei seguenti modi: Il programma di trasferimento del file rsync può essere utilizzato per sincronizzare i pacchetti tra i Proxy è possibile stabilire una condivisione del Network File System (NFS), tra i Proxy ed il repositorio del canale personalizzato. Entrambe le suddette soluzioni permetteranno a qualsiasi client di qualsiasi RHN Proxy Server, di ricevere tutti i pacchetti personalizzati. Figura 3.2. Topologia orizzontale di proxy multipli 3. Topologia verticale di Proxy multipli Un metodo alternativo per i RHN Proxy Server multipli, è quello di stabilire un proxy primario al quale gli altri si possono collegare per ricevere sia gli RPM da Red Hat Network, che i pacchetti personalizzati creati localmente. In assenza di tale metodo, i proxy secondari possono comportarsi come client del primario. Ciò allevierà la necessità di stabilire una sincronizzazione tra i RHN Proxy Server, poichè essi utilizzano la funzionalità up2date ereditata con il prodotto. Come con la configurazione orizzontale, il metodo verticale permette a qualsiasi client di 14

21 Proxy con RHN Satellite Server qualsiasi RHN Proxy Server, di ricevere tutti i pacchetti personalizzati a loro consegnati. Il Proxy controlla raramente il proprio repositorio cercando di trovare il pacchetto sul proprio filesystem. In caso contrario, effettuerà un altro tentativo dal livello superiore successivo. Questo tipo di configurazione verticale assicura che i proxy secondari dipendono dal primario per la ricezione sia degli aggiornamenti provenienti da RHN, che per i pacchetti personalizzati. Altresì i canali personalizzati ed i pacchetti, devono essere posizionati solo sul proxy primario per assicurare una distribuzione ai proxy figlio. Per finire, i file di configurazione dei proxy secondari, devono indicare il primario invece di indicare direttamente Red Hat Network. Figura 3.3. Topologia verticale di Proxy multipli 4. Proxy con RHN Satellite Server In aggiunta ai metodi descritti all'interno di questo capitolo, gli utenti hanno la possibilità di utilizzare RHN Proxy Server insieme con RHN Satellite Server. In questo caso il funzionamento è simile alla configurazione verticale di Proxy, con l'aggiunta di una maggiore capacità, poichè i Satellite sono in grado di servire un numero maggiore di sistemi client. Per una descrizione più completa di questa combinazione, consultate il capitolo degli esempi di topologie della RHN Satellite Server Installation Guide. Il collegamento dei certificati SSL dei due prodotti, viene riportato all'interno della RHN Client Configuration Guide. Per saperne di più sulla suddivisione dei canali e dei pacchetti, consultate la RHN Channel Management Guide. 15

22 16

23 Capitolo 4. Installazione Questo capitolo descrive l'installazione iniziale del RHN Proxy Server. Si presuppone che i requisiti presenti nel Capitolo 2, Requisiti siano stati soddisfatti. Tuttavia se state eseguendo un processo di aggiornamento ad una nuova versione di RHN Proxy Server, contattate il vostro rappresentante Red Hat per assistenza. 1. Installazione di base Il RHN Proxy Server è stato creato per essere eseguito su sistemi operativi Red Hat Enterprise Linux AS. Per questo motivo, la prima fase consiste nell'installazione del sistema operativo di base, tramite disco, immagine ISO, o kickstart. Durante e dopo il processo di installazione del sistema operativo assicuratevi di: Assegnare spazio sufficiente alla partizione che verrà utilizzata per conservare i pacchetti, come riportato dai requisiti hardware precedentemente indicati. La posizione di default per i pacchetti Red Hat conservati è /var/spool/squid, mentre i pacchetti personalizzati si trovano all'interno di /var/spool/rhn-proxy. Installate solo i pacchetti necessari per RHN Proxy Server Nota Bene Installate solo i pacchetti di base poichè altri pacchetti causeranno il fallimento dell'installazione di RHN Proxy Server. Consultate la Sezione 1, «Requisiti software» su come ottenere il gruppo di pacchetti necessario per ogni versione di Red Hat Enterprise Linux AS. Importante Se desiderate ottenere un servizio di livello Monitoring, è necessario installare il vostro RHN Proxy Server su Red Hat Enterprise Linux AS 3 Update 5 o Red Hat Enterprise Linux AS 4. Essi infatti risultano essere i soli sistemi operativi supportati per i proxy in grado di servire i sistemi aventi diritto al Monitoring. Abilitate il Network Time Protocol (NTP) sul Proxy, e selezionate il fuso orario appropriato. A questo punto tutti i sistemi client dovrebbero aver già eseguito il demone ntpd, e presentare il fuso orario corretto. Dopo il processo di installazione, disabilitate i servizi ipchains e iptables. 17

24 Capitolo 4. Installazione 2. Processo di installazione del RHN Proxy Server Le seguenti informazioni descrivono il processo di installazione del RHN Proxy Server 1. Registrate il sistema Red Hat Enterprise Linux AS appena installato con Red Hat Network (server RHN centrali o il vostro RHN Satellite Server), usando l'account organizzativo contenente l'entitlement di RHN Proxy Server, con il comando up2date --register. 2. Assegnate al sistema un entitlement di Provisioning. Visitate il RHN Website (o il fully qualified domain name del Satellite asservito al Proxy), eseguite il login come Organization Administrator, e navigate fino a giungere alla pagina Il vostro RHN # Gestione sottoscrizione. Selezionate la casella relativa al sistema sul quale è necessario installare il RHN Proxy Server, selezionate Provisioning dal menù a tendina, e fate clic sul pulsante Aggiungi Entitlement. 3. Assicuratevi che il sistema sia sottoscritto al canale Red Hat Network Tools per il proprio sistema operativo di base, selezionando il nome del sistema e navigando attraverso la pagina Sistema = > Informazioni del sistema. Sotto la sezione Canali sottoscritti, controllate i canali presenti per il canale Tools. Se non sottoscritto a questo canale, selezionate il link Modifica sottoscrizioni del canale, selezionate la casella situata accanto al canale tools, e successivamente sul pulsante Modifica sottoscrizioni, per confermare la scelta. 4. Installate il pacchetto rhncfg-actions (il quale installa anche i pacchetti rhncfg e rhncfg-client come dipendenze), navigando attraverso le sottotabelle Sistema = > Informazioni del Sistema = > Software = > Pacchetti = > Installa. Successivamente andate alla ricerca di rhncfg-actions utilizzando la casella di ricerca Filtra in base al nome del pacchetto. Nell'elenco risultante selezionate il pacchetto rhn-actions ed installatelo. 5. Se abilitate la cifratura secure sockets layer (SSL) sul Proxy ed eseguite il collegamento ai server RHN centrali, installate il pacchetto rhns-certs-tools dallo stesso canale Red Hat Network Tools, ed utilizzate il Tool di gestione SSL di RHN per generare il tar file necesario. Consultate il capitolo relativo ai Certificati SSL della RHN Client Configuration Guide per maggiori informazioni. Se desiderate abilitare sul Proxy la cifratura SSL, ed eseguire un collegamento con RHN Satellite Server oppure con un altro RHN Proxy Server con SSL, allora avrete bisogno della password del certificato CA utilizzato per il sistema genitore. 6. Eseguite un log in sul sistema come utente root attraverso un terminale, e successivamente eseguite il comando rhn_check per iniziare immediatamente l'installazione programmata del pacchetto. 7. Una volta installato i pacchetti, e confermato attraverso la scheda Informazioni del sistema = > Eventi, preparate il sistema ad accettare i comandi remoti e la gestione della configurazione 'configuration management' tramite il seguente comando: /usr/bin/rhn-actions-control --enable-all 18

25 Processo di installazione del RHN Proxy 8. All'interno del sito web RHN, navigate attraverso la sottotabella Informazioni del sistema = > Dettagli = > Proxy. Avvertimento Si prega di notare che l'installazione del RHN Proxy Server potrebbe sostituire i file di configurazione squid.conf e httpd.conf sul sistema per facilitare i processi di aggiornamento successivi. Se avete modificato questi file e desiderate conservarli, essi verranno ruotati e potranno essere ripristinati dopo l'installazione. Figura 4.1. Informazioni del sistema = > Proxy 9. Nella sottotabella Informazioni del sistema = > Dettagli = > Proxy, il menù a tendina dovrebbe indicare la possibilità di attivare il sistema come un RHN Proxy Server. Assicuratevi che la versione corretta sia stata selezionata, e successivamente fate clic sul pulsante Attiva Proxy. A questo punto apparirà la pagina di Benvenuto. 19

26 Capitolo 4. Installazione Figura 4.2. Benvenuto 10.Nella pagina di Benvenuto troverete le notifiche relative ai requisiti non soddisfatti dal sistema. Quando il sistema è pronto apparirà un link continua. Selezionatelo per poter andare alla pagina Termini & Condizioni. 20

27 Server Figura 4.3. Termini & Condizioni 11.All'interno della pagina Termini & Condizioni selezionate il link termini e condizioni in modo da visualizzare il licensing agreement del RHN Proxy Server. Per accettare fate clic sul link Accetto. È necessario accettare per poter continuare con il processo d'installazione. Per i Proxy che eseguono una registrazione con un Satellite sui quali è stato abilitato il Monitoring, verrà visualizzata la pagina Abilita monitoring. 21

28 Capitolo 4. Installazione Figura 4.4. Abilita Monitoring 12.Nella pagina Abilita Monitoring decidete se usare il Proxy per monitorare i sistemi da esso serviti. Per fare ciò è necessario che il RHN Proxy Server sia collegato ad un RHN Satellite Server e soddisfi i requisiti identificati nel Capitolo 2, Requisiti (o ad un altro Proxy collegato ad un Satellite). Per abilitare il monitoring sul Proxy, selezionate la casella e fate clic su continua. A questo punto apparirà la pagina Configura RHN Proxy Server. 22

29 Processo di installazione del RHN Proxy Figura 4.5. Configura RHN Proxy Server 13.Nella pagina Configura RHN Proxy Server, fornire o confermare le voci per tutti i campi richiesti. L'indirizzo di posta elettronica dell'amministratore riceverà tutte le mail generate dal Proxy, incluso anche un gran numero di messaggi relativi ad errori di traceback. Per limitare questo flusso, considerate l'adozione dei filtri di posta in grado di catturare i messaggi con soggetto "RHN TRACEBACK from hostname". Per elencare più di un amministratore, inserire un elenco di indirizzi separati da una virgola. Il RHN Proxy Hostname è il fully qualified domain name (FQDN) del RHN Proxy Server. Il server genitore di RHN è il nome del dominio del server il quale serve il Proxy i server RHN centrali, un altro RHN Proxy Server o un RHN Satellite Server. Per collegarsi ai server RHN centrali includere il valore xmlrpc.rhn.redhat.com. Per collegarsi ad un Satellite o ad un altro Proxy, inserite il FQDN del sistema genitore. Se il RHN Proxy Server si collega attraverso un proxy HTTP, configuratelo utilizzando i campi associati. Da notare che i riferimenti al protocollo come o non 23

30 Capitolo 4. Installazione devono essere inclusi nel campo HTTP Proxy Server. Inserire solo l'hostname e la porta nel formato hostname:port, come ad esempio your-gateway.example.com:3128. Suggerimento Il processo d'installazione interessa solo il file di configurazione del Proxy: /etc/rhn/rhn.conf. Il file di configurazione di Red Hat Update Agent (up2date), /etc/sysconfig/rhn/up2date, deve essere aggiornato manualmente per poter ricevere i propri aggiornamenti da un altro server, come ad esempio un RHN Satellite Server. Per finire, è necessario decidere se abilitare SSL utilizzando la casella nella parte bassa. Red Hat consiglia vivamente l'implementazione di questo livello di cifratura per tutto il traffico da e per il RHN Proxy Server. Per selezionarlo sarà necessario collegarsi ai server RHN centrali (i quali avranno SSL selezionato per default) oppure collegarsi ad un RHN Satellite Server o RHN Proxy Server con SSL abilitato. Il collegamento ai server RHN centrali richiede il caricamento del tar file del certificato precedentemente indicato. Il collegamento ad un Satellite o ad un altro Proxy attraverso un SSL, necessita di una password del certificato CA usata per l'abilitazione di SSL su di un sistema genitore. Nota Consultate il capitolo intitolato "Infrastruttura SSL" nella Red Hat Network Client Configuration Guide per maggiori informazioni su come configurare una infrastruttura RHN Proxy Server sicura usando SSL. Se decidete di non abilitare SSL durante l'installazione, non selezionate questa casella e consultate il capitolo Certificati SSL della RHN Client Configuration Guide, su come ottenere questo livello di sicurezza post installazione. Una volta terminato, selezionate continua. Se abilitate SSL e desiderate collegarvi ad un Satellite, sarete in grado di visualizzare la pagina Configura SSL. Se avete abilitato SSL e siete collegati ad un altro Proxy o ai server RHN centrali, allora sarete in grado di visualizzare la pagina Carica SSL. Se non avete abilitato SSL ma avete abilitato il Monitoring, andate alla pagina di descrizione di Configura Monitoring. Se non avete abilitato sia SSL che il Monitoring, andate sulla pagina di descrizione del Progresso installazione. 24

31 Server Figura 4.6. Configura SSL 14.Nella pagina Configura SSLapplicabile solo ad un Proxy che si collega ad un RHN Satellite Server con SSL abilitato, fornire le informazioni necessarie per generare il certificato del server. L'informazione più importante è la password del certificato SSL, la quale deve corrispondere alla password utilizzata durante l'abilitazione di SSL sul server genitore. I campi restanti devono corrispondere ai valori presenti nel server genitore e possono differire a seconda del ruolo del RHN Proxy Server, per esempio per riflettere una posizione geografica diversa. In modo simile, l'indirizzo potrebbe essere lo stesso di quello fornito precedentemente per l'amministratore del Proxy, e ridirezionato ad un particolare amministratore del certificato. La scadenza del certificato può essere modificata. Anche in questo caso assicuratevi che i valori forniti siano presenti nei backup delle informazioni presenti nel Capitolo 2, Requisiti. Una volta terminato fate clic su continua. 25

32 Capitolo 4. Installazione Figura 4.7. Configura Monitoring 15.Nella pagina Configura Monitoring, fornite oppure confermate l'hostname e l'indirizzo IP del server genitore al quale il RHN Proxy Server risulta essere collegato. Esso può essere sia un RHN Satellite Server che un altro Proxy, i quali a turno sono collegati ad un Satellite. Non è possibile eseguire il Monitoring attraverso i server RHN centrali. Una volta terminato, fate clic su continua. A questo punto visualizzerete la pagina Progressi del processo d'installazione. Figura 4.8. Progressi del processo d'installazione 16.Nella pagina Progresso installazione è possibile monitorare le fasi necessarie per 26

33 Processo di installazione del RHN Proxy l'installazione durante il loro svolgimento. Selezionate il link per ogni fase per visualizzare la rispettiva pagina Dettagli azione. Quando un'azione inizia, il suo stato va da Queued a Picked Up per poi giungere allo stato Completed. In modo simile alle installazioni precedenti del pacchetto, è possibile azionare queste fasi attraverso l'esecuzione del comando rhn_check in un terminale del sistema come utente root. Una volta terminato, la pagina Progresso installazione mostrerà il messaggio The installation is complete.. Ora sarà possibile iniziare la registrazione dei sistemi serviti dal RHN Proxy Server. Consultate la RHN Client Configuration Guide. 17.Quando tutte le informazioni sulla pagina Progresso installazione risultano complete, il Proxy sarà pronto all'uso. È ora possibile registrare i sistemi al RHN attraverso il Proxy. 27

34 28

35 Capitolo 5. RHN Package Manager RHN Package Manager è un tool della linea di comando che permette ad una organizzazione di servire i pacchetti locali associati con un canale RHN privato attraverso il RHN Proxy Server. Se desiderate che il RHN Proxy Server aggiorni solo i pacchetti Red Hat ufficiali, allora non installate il RHN Package Manager. Per usare il RHN Package Manager, installate il pacchetto rhns-proxy-package-manager e le relative dipendenze. Vengono caricate sui server RHN solo le informazioni relative all'intestazione per i pacchetti. Le intestazioni sono necessarie a RHN per risolvere le dipendenze del pacchetto per i sistemi client. I file del pacchetto (*.rpm) vengono conservati su RHN Proxy Server. RHN Package Manager utilizza le stesse impostazioni del Proxy le quali vengono definite nel file di configurazione /etc/rhn/rhn.conf. 1. Creazione di un canale privato Prima di poter fornire i pacchetti locali attraverso un RHN Proxy Server, è necesario munirsi di un canale privato in modo da poter conservare i pacchetti in questione. Per creare un canale privato eseguire le seguenti fasi: 1. Eseguite un login sull'interfaccia web di RHN in 2. Fate clic su Canali nella barra di navigazione superiore. Se non visualizzate l'opzione Gestisci canali all'interno della barra di navigazione di sinistra, assicuratevi che l'utente in questione possieda un set di permessi per la modifica del canale. Fate questo attraverso la categoria Utenti accessibile nella barra di navigazione superiore. 3. Nella barra di navigazione di sinistra, fate clic su Gestisci Canali Software, e successivamente sul pulsante crea nuovo canale nell'angolo a destra della pagina. 4. Selezionate un'archtettura del canale genitore e canale di base, inserite un nome, etichetta, sommario e descrizione per il nuovo canale privato. L'etichetta del canale deve contenere: almeno sei caratteri, iniziare con una lettera e contenere solo lettere minuscole, cifre, trattini (-) e punteggiatura (.). Inserite anche l'url della chiave GPG del canale. Anche se questo campo non risulta necessario, è consigliato aumentare il livello di sicurezza. Per informazioni su come generare le chiavi GPG, consultate la RHN Channel Management Guide. 5. Fate clic su Crea canale. 2. Caricamento dei pacchetti 29

36 Capitolo 5. RHN Package Manager Nota Bene È necessario essere un Organization Administrator per caricare i pacchetti sui canali RHN privati. Lo script vi richiederà di inserire il vostro nome utente e password di RHN. Dopo aver creato il canale privato, caricate le intestazioni del pacchetto per i vostri RPM sorgente e binari sul server RHN, e copiate i pacchetti sul RHN Proxy Broker Server. Per caricare le intestazioni del pacchetto per gli RPM binari emettete il seguente comando: rhn_package_manager -c "label_of_private_channel" pkg-list pkg-list rappresenta l'elenco dei pacchetti da caricare. Alternativamente utilizzare l'opzione -d per specificare la directory locale che contiene i pacchetti da aggiungere al canale. Assicuratevi che la directory contenga solo i pacchetti da includere e non altri file. RHN Package Manager è in grado di leggere anche l'elenco dei pacchetti da un input standard (utilizzando --stdin). Per caricare le intestazioni dei pacchetti per gli RPM sorgente: rhn_package_manager -c "label_of_private_channel" --source pkg-list Se è stato specificato più di un canale (utilizzando -c o --channel), le intestazioni caricate del pacchetto verranno collegate a tutti i canali elencati. Nota Bene Se non è stato specificato il nome i pacchetti non verranno aggiunti ad alcun canale. I pacchetti possono successivamente essere aggiunti ad un canale utilizzando l'interfaccia web di Red Hat Network. L'interfaccia può essere anche usata per modificare i canali privati esistenti. Dopo aver caricato i pacchetti, è possibile controllare immediatamente l'interfaccia web di RHN per verificare la loro presenza. Fate clic su Canali nella barra di navigazione superiore, Gestisci Canali Software nella barra di navigazione di sinistra, e successivamente sul nome del canale personalizzato. A seguire fate clic sulla sottotabella Pacchetti. Ogni RPM dovrebbe essere elencato. È possibile controllare se la directory locale risulta essere sincronizzata con l'immagine del server RHN dei canali, direttamente sulla linea di comando: rhn_package_manager -s -c "label_of_private_channel" 30

37 Opzioni della linea di comando L'opzione -s elencherà tutti i pacchetti mancanti (pacchetti caricati sul server RHN non presenti nella directory locale). È necessario essere un Organization Administrator per poter utilizzare questo comando. Lo script vi richiederà di inserire la vostra password ed il vostro nome utente di RHN. Per opzioni aggiuntive della linea di comando consultate la Tabella 5.1, «opzioni rhn_package_manager». Se state utilizzando RHN Package Manager per aggiornare i pacchetti locali, è necessario andare sul sito web di RHN per registrare il sistema sul canale privato. 3. Opzioni della linea di comando Un sommario di tutte le opzioni della linea di comando per RHN Package Manager rhn_package_manager: Opzione -v, --verbose -ddir, --dir=dir -cchannel, --channel=channel -nnumber, --count=number -l, --list -s, --sync -p, --printconf -XPATTERN, --exclude=pattern --newest --stdin --nosig --username=username --password=password Descrizione Maggiore verbosità. Processa i pacchetti dalla directory DIR. Gestisci questo canale può essere presente più volte. Processa questo numero di intestazione per chiamata il default è 32. Elenca ogni nome del pacchetto, numero della versione, numero della release, ed architettura nel canale specificato. Controlla se la directory locale è in sincronizzazione con il server. Stampa la configurazione attuale ed esci. Escludi i file che corrispondono a questa espressione globale può essere presente più volte. Passa solo i pacchetti più recenti rispetto ai pacchetti precedentemente passati al server per il canale specificato. Legge i nomi dei pacchetti definiti da stdin. Passa i pacchetti non firmati. Per default RHN Package Manager cerca di passare solo i pacchetti firmati. Specifica il vostro nome utente di RHN. Se non ne fornite uno con questa opzione, allora vi sarà richiesto di specificarne uno in questo modo. Specifica la vostra password RHN. Se non ne fornite una con questa opzione, allora vi sarà richiesto di specificarne una in questo modo. 31

38 Capitolo 5. RHN Package Manager Opzione --source --dontcopy --test --no-ssl Descrizione Carica le intestazioni del pacchetto sorgente. Nella fase di post-caricamento, non copiare i pacchetti nella loro posizione finale all'interno dell'albero dei pacchetti. Stampa solo i pacchetti che devono essere passati. Non consigliato Disabilita SSL. -?, --usage Descrivi brevemente le opzioni. --copyonly -h, --help Copia i file elencati nell'argomentazione all'interno del canale specificato. Utile quando un canale presente sul Proxy non possiede un determinato pacchetto, e quando un utente non desidera importare nuovamente tutti i pacchetti all'interno del canale. Es. rhn_package_manager-cchannel--copyonly/path/to/missing/file Visualizza la schermata d'aiuto insieme ad un elenco di opzioni. Tabella 5.1. opzioni rhn_package_manager Suggerimento Queste opzioni della linea di comando sono descritte anche nella pagina man di rhn_package_manager: man rhn_package_manager. 32

39 Capitolo 6. Troubleshooting Questo capitolo fornisce i suggerimenti per poter determinare la causa degli errori più comuni, e la loro risoluzione, associati con RHN Proxy Server. Se avete bisogno di una maggiore assistenza, contattate il supporto Red Hat Network su Per poter visualizzare un elenco completo di opzioni, è necessario eseguire un login utilizzando il vostro account avente diritto al Satellite. 1. Gestione del servizio Proxy Poichè il RHN Proxy Server consiste in una moltitudine di singoli componenti, Red Hat fornisce un servizio master, rhn-proxy, che vi permetterà di arrestare, iniziare o riprendere gli stati dei diversi servizi nell'ordine appropriato. Questo servizio d'aiuto accetta tutti i comandi tipici: service rhn-proxy startservice rhn-proxy stopservice rhn-proxy restartservice rhn-proxy status Utilizzate il servizio rhn-proxy per terminare e riavviare l'intero RHN Proxy Server, e ripristinare contemporaneamente i messaggi sullo stato di tutti i propri servizi. 2. File di log Virtualmente ogni fase di troubleshooting dovrebbe iniziare consultando il file di log associato o i relativi file. I suddetti file forniscono informazioni molto utili sull'attività svolta nel dispositivo, oppure all'interno dell'applicazione, e possono essere utilizzate per monitorare le prestazioni ed assicurare una configurazione corretta. Consultate la Tabella 6.1, «File di log» per i path dei file di log più importanti: Componente Apache Web server Squid RHN Proxy Broker Server RHN SSL Redirect Server Red Hat Update Agent Posizione del file di log directory /var/log/httpd/ directory /var/log/squid/ /var/log/rhn/rhn_proxy_broker.log /var/log/rhn/rhn_proxy_redirect.log /var/log/up2date Tabella 6.1. File di log 3. Domande e risposte Questa sezione contiene le risposte alle domende più frequenti sul processo di installazione e di configurazione di una soluzione RHN Proxy Server. 33

40 Capitolo 6. Troubleshooting 3.1. Dopo aver configurato RHN Package Manager, come posso determinare se i pacchetti locali sono stati aggiunti al canale RHN privato? Utilizzate il comando rhn_package_manager -l -c "name_of_private_channel", per elencare i pacchetti del canale privato conosciuti ai server RHN. Oppure visitate l'interfaccia Web di RHN. Dopo aver sottoscritto un sistema registrato su di un canale privato, è possibile eseguire il comando up2date -l --showall sul sistema registrato, andando alla ricerca dei pacchetti provenienti dal canale RHN privato Come posso sapere se i client sono in grado di collegarsi al server Squid? Il file /var/log/squid/access.log registra tutti i collegamenti al server Squid Il Red Hat Update Agent sui sistemi client non si collega attraverso il RHN Proxy Server. Come posso risolvere questo problema? Assicuratevi che l'ultimissima versione del Red Hat Update Agent sia stata installata sui sistemi client. L'ultimissima versione presenta le caratteristiche necessarie per eseguire un collegamento attraverso un RHN Proxy Server. È possibile ottenere l'ultimissima versione attraverso Red Hat Network tramite il comando up2date up2date come utenti root, oppure dal 1. Altresì è bene ricordare che poichè il RHN Proxy Server si comporta come un meccanismo di caching per RHN, l'impostazione httpproxy in /etc/sysconfig/rhn/up2date sui sistemi client, risulta essere ridondante e probabilmente non necessaria. Il RHN Proxy Server è una estensione di Apache. Consultate la Tabella 6.1, «File di log» per la posizione del suo file di log La configurazione del mio RHN Proxy Server non funziona. Da dove posso iniziare il suo processo di troubleshooting? Assicuratevi che /etc/sysconfig/rhn/systemid sia posseduto da root.apache con i permessi Consultate i file di log. Un elenco è disponibile sulla Tabella 6.1, «File di log». 4. Problemi generali Per iniziare il troubleshooting di problemi generali, esaminate i file di log oppure i file relativi sul

41 Host non trovato/impossibile determinare il componente che presenta gli errori. Così facendo è possibile eseguire il comando tail, per verificare le ultime informazioni relative ai file di log, e successivamente eseguire up2date --list. Dopo aver seguito tale processo, esaminate tutte le nuove entry dei log per possibili suggerimenti. Un problema comune è rappresentato dall'assenza di spazio disponibile su disco. Una indicazione in tal senso è la presenza di righe interrotte all'interno dei file di log. Se la registrazione è stata arrestata durante il processo di scrittura, come ad esempio una parola a metà, molto probabilmente tale problema indicherà l'assenza di spazio disponibile sui dischi. Per avere una conferma eseguite il seguente comando e controllate le percentuali nella colonna Use%: df -h In aggiunta ai file di log, è possibile ottenere informazioni utili controllando lo stato dei vari componenti. Questo processo è disponibile sia per Apache Web server che per Squid. Per ottenere lo stato di Apache Web server eseguite il comando: service httpd status Per ottenere lo stato di Squid eseguite il comando: service squid status Se l'amministratore non riesce a ricevere le dal RHN Proxy Server, controllate che gli indirizzi corretti siano stati impostati per traceback_mail in /etc/rhn/rhn.conf. 5. Host non trovato/impossibile determinare il FQDN Poichè i file di configurazione di RHN si affidano esclusivamente al fully qualified domain names (FQDN), è necessario che le applicazioni più importanti siano in grado di risolvere il nome del RHN Proxy Server in un indirizzo IP. Red Hat Update Agent, Red Hat Network Registration Client, e Apache Web server sono particolarmente propensi a questo problema con le applicazioni RHN, emettendo errori di "host non trovato" con il Web server che visualizza il messaggio "Impossibile determinare il fully qualified domain name del server" durante l'avvio. Questo problema ha le sue origini nel file /etc/hosts. Per una conferma, esaminate /etc/nsswitch.conf il quale definisce i metodi e l'ordine secondo il quale vengono risolti i nomi del dominio. Generalmente il file /etc/hosts viene controllato prima, seguito poi dal Network Information Service (NIS) se utilizzato, e dal DNS. Almeno una delle entità elencate non deve riportare alcun errore, questo per permettere ad Apache Web server di avviarsi correttamente e garantire un normale funzionamento delle applicazioni client RHN. Per risolvere questo problema identificate il contenuto del file /etc/hosts. Potrebbe somigliare 35

42 Capitolo 6. Troubleshooting al seguente: this_machine.example.com this_machine localhost.localdomain \ localhost Come prima cosa in un editor di testo, rimuovere le informazioni che causano il problema come riportato nel seguente esempio: localhost.localdomain.com localhost Successivamente salvate il file e cercate di eseguire nuovamente le applicazioni client di RHN o Apache Web server. In caso di errore, identificate esplicitamente nel file l'indirizzo IP del Proxy come nel seguente caso: localhost.localdomain.com localhost this_machine.example.com this_machine Sostituite qui il valore con l'indirizzo IP del Proxy. Tale operazione dovrebbe risolvere il problema. Ricordate, se desiderate modificate l'indirizzo IP specifico della macchina, è necessario aggiornare il file in questione. 6. Errori di connessione Se credete di aver incontrato problemi relativi ai collegamenti, vi consigliamo di seguire quanto di seguito riportato: Confermate che il pacchetto corretto: rhn-org-httpd-ssl-key-pair-machine_name-ver-rel.noarch.rpm sia installato sul RHN Proxy Server e che il corrispondente rhn-org-trusted-ssl-cert-*.noarch.rpm o certificato raw CA SSL public (client) sia stato installato sui sistemi client. Verificate che i sistemi client siano stati configurati in modo da utilizzare il certificato appropriato. Se si utilizzano uno o più RHN Proxy Server, assicuratevi che ogni certificato SSL sia stato creato correttamente. Se si utilizza il RHN Proxy Server insieme con un RHN Satellite Server, il Proxy dovrebbe presentare sia la coppia di chiavi SSL del server, che il certificato CA SSL public (client), poichè esso verrà utilizzato per entrambi i casi. Consultate il capitolo Certificati SSL del RHN Client Configuration Guide per istruzioni specifiche. Se il RHN Proxy Server si collega attraverso un Proxy HTTP, assicuratevi che l'url sia valido. Per esempio, il campo HTTP Proxy URL, non deve presentare alcun riferimento a 36

43 FQDN protocolli come ad esempio o È necessario includere solo l'hostname e la porta nel formato hostname:port, come ad esempio your-gateway.example.com:8080. Assicuratevi che i sistemi client non utilizzino i firewall bloccando quindi le porte necessarie come riportato nella Sezione 4, «Requisiti aggiuntivi». 7. Problematiche di Caching Se la consegna del pacchetto fallisce o se un oggetto è corrotto e non vi è alcuna relazione con gli errori di collegamento, allora sarà necessario ripulire le cache. Il RHN Proxy Server presenta due tipi di cache: una per Squid e l'altra per l'autenticazione. La cache di Squid si trova in /var/spool/squid/. Per riordinarla, arrestate l'apache Web server e Squid, cancellate i contenuti della directory, e riavviate entrambi i servizi. Emettete questi comandi nel seguente ordine: service httpd stop service squid stop rm -fv /var/spool/squid/* service squid start service httpd start Potrete eseguire lo stesso compito più velocemente ripulendo la directory e riavviando squid, ma molto probabilmente riceverete un numero di messaggi traceback di RHN. Anche la cache del meccanismo interno di caching utilizzato per l'autenticazione dal Proxy, potrebbe aver bisogno di essere riordinata. Per fare questo, emettere il seguente comando: rm -fv /var/cache/rhn/* Anche se il Demone di autenticazione di RHN non risulta essere supportato con la release di RHN Proxy Server 3.2.2, e sostituito con il meccanismo caching di autenticazione interno, il demone potrebbe essere ancora in esecuzione sul vostro Proxy. Per disabilitarlo, emettete i seguenti comandi nell'ordine riportato: chkconfig --level 2345 rhn_auth_cache off service rhn_auth_cache stop Per riordinare la propria cache, emettere: rm /var/up2date/rhn_auth_cache Se avete bisogno di mantenere il Demone di autenticazione di RHN, ricordiamo che Red Hat non lo consiglia ne lo supporta. Informiamo altresì che le sue prestazioni potrebbero rallentare a causa di un login verboso. Per questo motivo il login interessato(per /var/log/rhn/rhn_auth_cache.log) viene disabilitato per default. Se eseguite il demone e desiderate il suddetto login, riabilitatelo aggiungendo la seguente riga al file /etc/rhn/rhn.conf di Proxy. 37

44 Capitolo 6. Troubleshooting auth_cache.debug = 2 8. Proxy Debugging di Red Hat Se avete seguito tutte le fasi di troubleshooting sopra riportate, oppure desiderate rimandarle ai professionisti di Red Hat Network, Red Hat consiglia di sfruttare i vantaggi derivati dal supporto fornito con RHN Proxy Server. Il modo migliore è di allegare i vostri parametri di configurazione di Proxy, i file di log e le informazioni sul database, ed inviare questo pacchetto direttamente a Red Hat. RHN fornisce un tool della linea di comando proprio per questo. Il RHN Proxy Diagnostic Info Gatherer, comunemente conosciuto come rhn-proxy-debug. Per usare questo tool, emettete il comando in questione come utente root. A questo punto sarete in grado di visualizzare le informazioni raccolte, ed una singola tarball creata come di seguito riportato: [root@rhel-4 root]# rhn-proxy-debug Collecting and packaging relevant diagnostic information. Warning: this may take some time... * copying configuration information * copying logs * querying RPM database (versioning of RHN Proxy, etc.) * get diskspace available * timestamping * creating tarball (may take some time): /tmp/rhn-proxy-debug.tar.bz2 * removing temporary debug tree Debug dump created, stored in /tmp/rhn-proxy-debug.tar.bz2 Deliver the generated tarball to your RHN contact or support channel. Una volta terminato, inviate una del nuovo file dalla directory /tmp/, al vostro rappresentante Red Hat per una diagnosi immediata. 38

45 Appendice A. Esempio file di configurazione di RHN Proxy Server Il file di configurazione /etc/rhn/rhn.conf per RHN Proxy Server, vi permette di stabilire le impostazioni della chiave. Attenzione però, perchè la presenza di errori all'interno di questo file possono causare il fallimento del Proxy stesso. Per questo motivo eseguite le modifche alla configurazione con molta cautela. Se state utilizzando anche un RHN Satellite Server, prestare particolare attenzione ai seguenti parametri: traceback_mail e proxy.rhn_parent. Controllate nuovamente l'esempio riportato ed i relativi commenti (che iniziano con il carattere cancelletto #), per informazioni aggiuntive. Nota Bene È possibile aggiungere use_ssl su rhn.conf solo a scopo di prova. Impostate il suo valore su 0 per disabilitare momentaneamente SSL tra il Proxy ed il server upstream. Da notare che tale operazione compromette enormemente la sicurezza. Per riabilitare SSL ritornate l'impostazione al proprio valore di default, cioè 1, oppure rimuovete semplicemente la riga dal file di configurazione. # Automatically generated RHN Management Proxy Server configuration file. # # SSL CA certificate location proxy.ca_chain = /usr/share/rhn/rhns-ca-cert # Corporate HTTP proxy, format: corp_gateway.example.com:8080 proxy.http_proxy = # Password for that corporate HTTP proxy proxy.http_proxy_password = # Username for that corporate HTTP proxy proxy.http_proxy_username = # Location of locally built, custom packages proxy.pkg_dir = /var/spool/rhn-proxy # Hostname of RHN Server or RHN Satellite proxy.rhn_parent = rhn.redhat.com # Destination of all tracebacks, etc. traceback_mail = [email protected], [email protected] 39

46 40

47 Indice A Amministratore del canale, 2 autenticazione, 4 C caching di autenticazione ripulire, 37 canale, 2 creazione di un canale privato, 29 canale privato, 29 come funziona, 3 configurazione client sottoscrizione ad un canale privato, 31 D Demone di autenticazione di RHN, disabilitazione rhn_auth_cache, arresto, 37 domande e risposte, 33 E Errore host non trovato impossibile determinare FQDN, 35 errori di connessione, 36 F file di log, 33 H HTTP Proxy Caching Server requisiti di spazio del disco, 9 I installazione del RHN Proxy Server, 18 di base, 17 O Organization Administrator, 2 P porta 443, , 9 80, 9 porta 443, 9 porta 4545, 9 porta 80, 9 porte in entrata, satellite 5222, 9 porte in uscita 80, 443, 9 Porte Proxy, 9 problematiche di Caching, 37 problemi generali, 34 R Red Hat Network introduzione, 1 Red Hat Update Agent, 2, 3 requisiti, 7 aggiuntivi, 9 hardware, 8 software, 7 spazio del disco, 9 requisiti aggiuntivi, 9 requisiti di spazio del disco, 9 requisiti hardware, 8 requisiti software, 7 RHN Package Manager, 4, 29 canali, specificazione, 30 caricamento delle intestazioni dei pacchetti, 30 configurazione, 29 creazione di un canale privato, 29 file di configurazione, 29 installazione, 29 opzioni della linea di comando, 31 verifica elenco pacchetti locali, 30 rhn-proxy servizio, 33 rhn.conf file di esempio, 39 rhn_package_manager, 30 (Vd. RHN Package Manager) S 41

48 Indice satellite-debug, 38 squid caching, 37 T ternini da comprendere, 2 topologie, 13 proxy con RHN Satellite Server, 15 proxy multipli impostati orizzontalmente, 13 proxy multipli impostati verticalmente, 14 proxy singolo, 13 traceback, 2 troubleshooting, 33 V vantaggi, 2 42