Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Proxy Installation Guide

Red Hat Network Satellite 5.5

Red Hat Network Satellite

Edizione 3

Red Hat Gruppo di documentazione

Sommario

Benvenuti alla RHN Proxy Installation Guide.

Capitolo 1. Introduzione

1.1. Red Hat Network

Red Hat Network (RHN) è l'ambiente di supporto del sistema e di gestione dei sistemi Red Hat e di una serie di sistemi. Red Hat Network racchiude i tool, i servizi ed i repositori 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 scaricare 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.

1.2. Terminologia usata frequentemente

Prima di poter 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 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.
Amministratore dell'organizzazione
Un Amministratore dell'organizzazione è un ruolo che detiene il livello più alto di controllo su un account Red Hat Network di una organizzazione. I membri con questo ruolo possono aggiungere e rimuovere altri utenti, sistemi, e gruppi dall'organizzazione. Una organizzazione di Red Hat Network deve avere almeno un Amministratore dell'organizzazione.
Channel Administrator
L'Amministratore del canale è un ruolo che permette di avere un accesso completo alle capacità di gestione del canale stesso. Gli utenti con questo ruolo sono in grado di creare nuovi canali e assegnare pacchetti ai canali. Questo ruolo può essere assegnato da un Amministratore dell'organizzazione attraverso la scheda Utenti del sito web di RHN.
Red Hat Update Agent
Il Red Hat Update Agent è una applicazione client di Red Hat Network (up2date or yum) la quale permette agli utenti di recuperare 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 http://www.redhat.com/docs/manuals/satellite/ e tramite la pagina Aiuto dell'interfaccia utente web di Satellite.

1.3. RHN Proxy Server

Un RHN Proxy Server è un meccanismo di package-caching in grado di ridurre i requisiti di larghezza di banda per RHN e permette l'impiego di pacchetti personalizzati. Gli utenti di Proxy archiviano 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 dei sistemi client e le informazioni dell'utente vengono archiviate sui server RHN centrali sicuri[1], i quali servono anche il sito web di RHN (rhn.redhat.com). Il Proxy si comporta come da tramite per i sistemi client e Red Hat Network (o RHN Satellite Server). Solo i file del pacchetto sono archiviati sul RHN Proxy 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 Serve può essere configurato in modo da rendere disponibili i 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 dell'uso 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 larghezza di banda — i pacchetti vengono scaricati da RHN solo una volta (per meccanismo di caching del Proxy Server 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 rendere disponibili 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 di 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.

1.4. Come funziona il Proxy

Il Red Hat Update Agent o Package Updater sui sistemi client non contatta direttamente il server di Red Hat Network. Al contrario il client (o i 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 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 o Package Updater 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 archivia 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, migliorandone le prestazioni.
  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 server di 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 il 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.
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.


[1] In questo documento "RHN" potrebbe riferirsi ai siti Hosted di RHN (http://rhn.redhat.com) o ad un RHN Satellite Server.

Capitolo 2. Requisiti

Prima di iniziare il processo di installazione di RHN Proxy Server è necessario soddisfare i seguenti requisiti. Satellite deve avere una versione uguale o maggiore a quella del Proxy che desiderate installare. Per esempio, se desiderate installare RHN Proxy Server 5.4 la versione del Satellite deve essere 5.4 o più recente e non potrà essere 5.3 o minore.

2.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 5. Il sistema operativo può essere installato tramite disco, immagine ISO locale, kickstart oppure tramite qualsiasi metodo supportato da Red Hat.
    RHN Proxy Server può essere installato su Red Hat Enterprise Linux 5 e 6 in qualsiasi ambiente supportato da Red Hat, incluso Xen, KVM, e VMware.
    Da notare che per ambienti di produzione è consigliata l'implementazione di RHN Proxy Server come l'unica applicazione in esecuzione sull'hardware fisico sottostante per evitare possibili problemi. Il supporto funzionale per gli ambienti virtualizzati non eguaglia sempre le prestazioni di una esecuzione su hardware fisico e per questo motivo considerare attentamente l'ambiente virtualizzato desiderato e qualsiasi linee guida per la regolazione.

    Nota

    Ogni prodotto acquistato di RHN Proxy include una istanza supportata di Red Hat Enterprise Linux Server. RHN Proxy deve essere installato su una nuova installazione di Enterprise Linux dove RHN Proxy è l'unica applicazione e servizio fornito dal sistema operativo. L'uso del sistema operativo Red Hat Enterprise Linux incluso nel RHN Proxy per eseguire i demoni, le applicazioni o i servizi all'interno dell'ambiente non è supportato.
    Ogni versione di Red Hat Enterprise Linux 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

    Per eseguire kickstart specificare il seguente gruppo di pacchetti: @ Base
    Per installare Red Hat Enterprise Linux tramite CD o immagine ISO, selezionare il seguente gruppo: Minimal
  • Un entitlement RHN Proxy Server presente all'interno di un account RHN Satellite Server.
  • Un entitlement di provisioning presente all'interno di un account RHN Satellite Server (il quale dovrebbe essere disponibile con l'entitlement RHN Proxy Server).
  • Accesso al canale Red Hat Network Tool per la versione di Red Hat Enterprise Linux installata. Questo canale include il pacchetto spacewalk-proxy-installer che contiene il programma d'installazione configure-proxy.sh necessario per installare RHN Proxy Server.
  • Tutti i pacchetti rhncfg* installati sul Proxy (dal canale RHN Tools).
  • Sul Proxy è necessaria la presenza del pacchetto spacewalk-certs-tools (dal canale RHN Tools) per gli utenti di RHN Hosted, oppure della password del certificato CA del secure sockets layer (SSL), utilizzato per generare il certificato del server genitore per gli utenti di RHN Satellite Server.
  • Se utilizzate il metodo non supportato d'installazione della Web UI è consigliato 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 4.2, «Processo di installazione del RHN Proxy Server».

2.2. Requisiti hardware

Per un RHN Proxy Server sono necessari i seguenti requisiti:
  • Processore Pentium IV o equivalente
  • 512 MB di memoria
  • Almeno 5 GB di storage per una installazione di base di Red Hat Enterprise Linux
  • 6 GB di storage per distribuzione/canale
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.

2.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.

2.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 in base alla implementazione del RHN Proxy Server:

Tabella 2.1. Porte da aprire sul Proxy

Porta Direzione Motivi
80 Uscita Proxy utilizza questa porta per raggiungere rhn.redhat.com, xmlrpc.rhn.redhat.com e l'URL di Satellite (se RHN Proxy è in comunicazione con il RHN Hosted o un Satellite Server).
80 Ingresso Le richieste del client arrivano attraverso http o https
443 Ingresso Le richieste del client arrivano attraverso http o https
443 Uscita Proxy utilizza questa porta per raggiungere rhn.redhat.com, xmlrpc.rhn.redhat.com e l'URL di Satellite (se RHN Proxy è in comunicazione con il RHN Hosted o un Satellite Server).
4545 Uscita Se il 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.
5222 Ingresso L'apertura di questa porta permetterà di stabilire collegamenti client osad al demone jabberd sul Proxy durante l'utilizzo di RHN Push.
5269 Uscita Se il 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.
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 Proxy Server tale processo include i nomi utente, e le password per l'account di un Amministratore dell'organizzazione e per la generazione del certificato SSL. Red Hat consiglia vivamente di copiare queste informazioni su due dischetti separati (CD/DVD/Dischi fissi estraibili), 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.

Capitolo 3. Esempio di tipologie

Il 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.

3.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 all'archiviazione 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.
Topologia di Proxy singolo

Figura 3.1. Topologia di Proxy singolo

3.2. Topologia orizzontale di proxy multipli

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.
Topologia orizzontale di proxy multipli

Figura 3.2. Topologia orizzontale di proxy multipli

3.3. Topologia verticale di Proxy multipli

Un metodo alternativo per 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 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.
Topologia verticale di Proxy multipli

Figura 3.3. Topologia verticale di Proxy multipli

3.4. Proxy con il 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.

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 rappresentante Red Hat per assistenza.

4.1. Installazione di base

Il RHN Proxy Server è stato creato per l'esecuzione su sistemi operativi Red Hat Enterprise Linux. 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 archiviati è /var/spool/squid, mentre i pacchetti personalizzati si trovano all'interno di /var/spool/rhn-proxy.

    Nota

    Il programma d'installazione calcola automaticamente lo spazio disponibile sulla partizione sulla quale è stato montato /var/spool/squid, ed assegna fino al 60 per cento dello spazio libero per l'utilizzo del RHN Proxy Server.
  • Installare i pacchetti richiesti da RHN Proxy Server.

    Nota

    Installate solo i pacchetti di base poichè altri pacchetti causeranno il fallimento dell'installazione di RHN Proxy Server.
    Consultate la Sezione 2.1, «Requisiti software» su come ottenere il gruppo di pacchetti necessario per ogni versione di Red Hat Enterprise Linux.
  • 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.

4.2. Processo di installazione del RHN Proxy Server

Le seguenti informazioni descrivono il processo di installazione del RHN Proxy Server:
  1. Eseguire una registrazione come utente root sul sistema RHN Proxy Server desiderato.
  2. Registrate il sistema Red Hat Enterprise Linux appena installato con Red Hat Network (server RHN centrali o RHN Satellite Server), usando l'account organizzativo contenente l'entitlement di RHN Proxy Server, con il comando rhn_register.
  3. Sottoscrivere il client al canale RHN Tool.
  4. Installare l'installer del proxy:
    yum install spacewalk-proxy-installer
    
  5. Eseguire l'installazione:
    configure-proxy.sh
    

    Nota

    Per eseguire correttamente questa fase è necessario avere un accesso root al server di Satellite. Alternativamente aggiungere l'opzione --force-own-ca al comando.
    Il programma d'installazione della linea di comando porta gli utenti attraverso una serie di prompt relativi all'installazione del RHN Proxy Server e alle informazioni sulla configurazione iniziale, come ad esempio le opzioni d'installazione e la generazione del certificato SSL. Le seguenti informazioni descrivono il processo d'installazione:

    Nota

    Se selezionate Invio ad un prompt invece di digitare una voce, il programma d'installazione della linea di comando di RHN Proxy Server utilizza una risposta predefinita all'interno delle parentesi.
    Alternativamente se desiderate usare le risposte predefinite senza alcuna interazione utilizzare l'opzione --non-interactive la quale userà tutte le risposte predefinite.
  6. I primi prompt sono specifici al sito relativo all'installazione.
    Proxy version to activate [5.4]:
    
    Versione Proxy vi richiede di confermare la versione del RHN Proxy Server che desiderate installare:
    RHN Parent [satserver.example.com]:
    
    RHN Parent è il nome del dominio o l'indirizzo del sistema che serve il Proxy, possono essere server di RHN Hosted (xmlrpc.rhn.redhat.com), o un server di Satellite.
    Traceback email []:
    
    L'Email di Traceback è l'indirizzo email al quale vengono inviati i messaggi di tracaback relativi agli errori, generalmente risulta essere l'email dell'amministratore del Proxy. Utilizzare le virgole per separare gli indirizzi email all'interno di questo prompt.
  7. Il set di prompt successivi si riferiscono alla configurazione delle informazioni per la generazione di un certificato SSL, consigliato per rendere sicuro il traffico per e dal RHN Proxy Server.
    Use SSL [Y/n]: y
    
    Nel prompt Utilizza SSL, digitare y per configurare il RHN Proxy Server al supporto SSL.
    CA Chain [/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT]:
    
    Nel prompt Catena del CA selezionare Invio per utilizzare il percorso predefinito per la Catena del Certificate Authority (CA), il quale valore se il RHN Proxy è in comunicazione con un RHN Satellite, risulta essere /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT. Se la comunicazione avviene con un RHN Hosted il valore sarà /usr/share/rhn/RHNS-CA-CERT. I certificato SSL personalizzati devono essere posizionati nella directory /usr/share/rhn/.
    HTTP Proxy []:
    
    Se il RHN Proxy Server esegue un collegamento attraverso un HTTP proxy, inserire l'hostname del proxy ed il numero della porta, come ad esempio corporate.proxy.example.com:3128
    Inserire le informazioni necessarie per generare un certificato del server SSL corretto, incluso il nome dell'Organzzazione, l'Unità Organizzazione (come ad esempio Engineering), il Nome comune (il domain name), insieme alle infromazioni relative alla Città, Stato e Nazione. Per finire, inserire l'indirizzo email per l'amministratore o del personale tecnico responsabile per i certificati SSL.
    Senza tener in considerazione se SSL è stato abilitato al collegamento con il Proxy Parent
    Server, vi verrà richiesto di generare un certificato SSL.
    Questo certificato permetterà ai sistemi client di collegarsi a questo Spacewalk Proxy
    in modo sicuro. Per maggiori informazioni consultate la Spacewalk Proxy Installation Guide
    Organization: Example Company
    Organization Unit [proxy1.example.com]:
    Common Name: proxy1.example.com
    City: New York
    State: New York
    Country code: US
    Email [admin@example.com]:
    
  8. Come risultato dell'esecuzione del programma di installazione del RHN Proxy Server, il programma di installazione a linea di comando:
    • Richiede l'installazione del supporto per il monitoring sul RHN Proxy Server.
    • Permette all'organizzazione di creare e popolare un canale di configurazione per installazioni future del RHN Proxy Server.
    • Finallizza la configurazione del SSL.
    • Riavvia qualsiasi demone del servizio con configurazioni modificate.
    Non avete installato il monitoring. Desiderate farlo?.
    Verrà eseguito 'yum install spacewalk-proxy-monitoring'.  [Y/n]:n
    
    Confermate se desiderate installare il supporto per il Monitoring sul Proxy server.
    Generating CA key and public certificate:
    CA password: 
    CA password confirmation: 
    Copying CA public certificate to /var/www/html/pub for distribution to clients:
    Generating SSL key and public certificate:
    CA password: 
    Backup made: 'rhn-ca-openssl.cnf' --> 'rhn-ca-openssl.cnf.1'
    Rotated: rhn-ca-openssl.cnf --> rhn-ca-openssl.cnf.1
    Installing SSL certificate for Apache and Jabberd:
    Preparing packages for installation...
    rhn-org-httpd-ssl-key-pair-proxy1.example-1.0-1
    
    Il programma configure-proxy.sh esegue la configurazione del SSL e richiede la creazione di una password per il Certificate Authority, insieme alla sua conferma, prima di generare le chiavi SSL ed il certificato pubblico.
    Create and populate configuration channel rhn_proxy_config_1000010000? [Y]:
    Using server name satserver.example.com
    Red Hat Network username: admin
    Password:
    Creating config channel rhn_proxy_config_1000010000
    Config channel rhn_proxy_config_1000010000 created
    using server name satserver.example.com
    Pushing to channel rhn_proxy_config_1000010000:
    Local file /etc/httpd/conf.d/ssl.conf -> remote file /etc/httpd/conf.d/ssl.conf
    Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf
    Local file /etc/rhn/cluster.ini -> remote file /etc/rhn/cluster.ini
    Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf
    Local file /etc/httpd/conf.d/cobbler-proxy.conf -> remote file /etc/httpd/conf.d/cobbler-proxy.conf
    Local file /etc/httpd/conf.d/rhn_proxy.conf -> remote file /etc/httpd/conf.d/rhn_proxy.conf
    Local file /etc/httpd/conf.d/rhn_broker.conf -> remote file /etc/httpd/conf.d/rhn_broker.conf
    Local file /etc/httpd/conf.d/rhn_redirect.conf -> remote file /etc/httpd/conf.d/rhn_redirect.conf
    Local file /etc/jabberd/c2s.xml -> remote file /etc/jabberd/c2s.xml
    Local file /etc/jabberd/sm.xml -> remote file /etc/jabberd/sm.xml
    
    Il programma d'installazione chiederà se desiderate creare un canale di configurazione in base ai file di configurazione creati durante l'esecuzione di configure-proxy.sh. Successivamente il programma creerà un canale di configurazione RHN Satellite Server in base al nome del sistema client sul quale è stato installato RHN Proxy Server (nell'esempio sopra riportato il sysID è 1000010000), e raccoglierà i vari file server httpd, SSL, squid, e jabberd che costituiscono il canale di configurazione per il Proxy server.
  9. Per finire il programma d'installazione avvia e riavvia tutti i servizi di RHN Proxy Server uscendo una volta terminato.
    Enabling Satellite Proxy
    Shutting down rhn-proxy...
    Shutting down Jabber router:                               [  OK  ]
    Stopping httpd:                                            [  OK  ]
    Stopping squid:                                            [  OK  ]
    Done.
    Starting rhn-proxy...
    init_cache_dir /var/spool/squid... Starting squid: .       [  OK  ]
    Starting httpd:                                            [  OK  ]
    Starting Jabber services                                   [  OK  ]
    Done.
    

4.2.1. Answer File

Se desiderate automatizzare parte del processo d'installazione del RHN Proxy Server sui sistemi, il programma configure-proxy.sh permette agli amministratori di creare i file di risposta "answer files" contenenti le risposte ai prompt del programma d'installazione.
Di seguito viene riportato un esempio di answer file contenente risposte precedentemente impostate relative al numero della versione, al server di RHN Satellite Server usato come genitore, SSL, e ad altri parametri di configurazione. Per maggiori informazioni sulla creazione e utilizzo degli answer file, consultate la pagina man di configure-proxy.sh digitando man configure-proxy.sh al prompt della shell.
# example of answer file for configure-proxy.sh
# for full list of possible option see
# man configure-proxy.sh

VERSION=5.4
RHN_PARENT=rhn-satellite.example.com
TRACEBACK_EMAIL=jsmith@example.com
USE_SSL=1
SSL_ORG="Red Hat"
SSL_ORGUNIT="Spacewalk"
SSL_CITY=Raleigh
SSL_STATE=NC
SSL_COUNTRY=US
INSTALL_MONITORING=N
ENABLE_SCOUT=N
CA_CHAIN=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
POPULATE_CONFIG_CHANNEL=Y
Per utilizzare un answer file (per esempio chiamato answers.txt) con configure-proxy.sh, digitate:
configure-proxy.sh --answer-file=answers.txt

Capitolo 5. RHN Package Manager e Servizio dei pacchetti locali

Il RHN Package Manager è uno strumento della linea di comando il quale permette ad una organizzazione di servire i pacchetti locali associati con un canale RHN privato attraverso il RHN Proxy Server. Non installate RHN Package Manager se desiderate aggiornare solo i pacchetti Red Hat ufficiali.
Per usare il RHN Package Manager installate il pacchetto spacewalk-proxy-package-manager e le relative dipendenze.
Solo le informazioni relative all'intestazione per i pacchetti sono caricate sui server RHN. Le intestazioni sono necessarie a RHN per risolvere le dipendenze del pacchetto per i sistemi client. I file del pacchetto (*.rpm) sono archiviati sul RHN Proxy Server.
Il RHN Package Manager utilizza le stesse impostazioni del Proxy definite nel file di configurazione /etc/rhn/rhn.conf.
Un sommario di tutte le opzioni della linea di comando per RHN Package Manager rhn_package_manager:

Tabella 5.1. opzioni rhn_package_manager

Opzione Descrizione
-v, --verbose Maggiore verbosità.
-dDIR, --dir=DIR Processa i pacchetti dalla directory DIR.
-cCHANNEL, --channel=CHANNEL Gestisci questo canale — può essere presente più volte.
-nNUMBER, --count=NUMBER Processa questo numero di intestazione per chiamata — il default è 32.
-l, --list Elenca ogni nome del pacchetto, numero della versione, numero della release, ed architettura nel canale specificato.
-s, --sync Controlla se la directory locale è in sincronizzazione con il server.
-p, --printconf Stampa la configurazione attuale ed esci.
-XPATTERN, --exclude=PATTERN Escludi i file che corrispondono a questa espressione globale — può essere presente più volte.
--newest Passa solo i pacchetti più recenti rispetto ai pacchetti precedentemente passati al server per il canale specificato.
--stdin Legge i nomi dei pacchetti definiti da stdin.
--nosig Passa i pacchetti non firmati. Per default RHN Package Manager cerca di passare solo i pacchetti firmati.
--username=USERNAME Specifica il nome utente di RHN. Se non ne fornite uno con questa opzione, allora vi sarà richiesto di specificarne uno in questo modo.
--password=PASSWORD Specifica la password RHN. Se non ne fornite una con questa opzione, allora vi sarà richiesto di specificarne una in questo modo.
--source Carica le intestazioni del pacchetto sorgente.
--dontcopy Nella fase di post-caricamento, non copiare i pacchetti nella loro posizione finale all'interno dell'albero dei pacchetti.
--test Stampa solo i pacchetti che devono essere passati.
--no-ssl Non consigliato — Disabilita SSL.
-?, --usage Descrive brevemente le opzioni.
--copyonly 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
-h, --help Visualizza la schermata d'aiuto insieme ad un elenco di opzioni.

Nota

Queste opzioni della linea di comando sono descritte anche nella pagina man di rhn_package_manager: man rhn_package_manager.
Per far si che RHN Package Manager sia in grado di servire i pacchetti locali seguire le fasi di seguito riportate:
  1. Creazione di un canale privato.
  2. Caricare i pacchetti locali all'interno del canale.
Le fasi verranno approfondite nelle sezioni successive.

5.1. Creazione di un canale privato

Prima di rendere disponibili i pacchetti locali attraverso un RHN Proxy Server, è necesario munirsi di un canale privato in modo da poter archiviare i pacchetti in questione. Per creare un canale privato eseguire le seguenti fasi:
  1. Eseguite un login sull'interfaccia web di RHN in https://rhn.redhat.com.
  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.

5.2. Caricamento dei pacchetti

Nota

È necessario essere un Amministraore dell'organizzazione per caricare i pacchetti sui canali RHN privati. Lo script richiederà di inserire il 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
Questo comando caricherà l'intestazione del pacchetto sul nome del canale specificato, ed il pacchetto su /var/spool/rhn-proxy/rhn.
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

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.
Controllare anche 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" 
L'opzione -s elenca tutti i pacchetti mancanti (tutti i pacchetti trasferiti sul server RHN ma non presenti sulla directory locale). È necessario essere un Amministratore dell'organizzazione per poter utilizzare questo comando. L'applicazione richiederà l'inserimento della password ed il nome utente di RHN.
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.

Capitolo 6. Come aggiornare l'installazione

Questo capitolo descrive il processo attraverso il quale è possibile aggiornare una installazione di RHN Proxy Server. Per fare questo è necessario avere un RHN Proxy Server in esecuzione e gli entitlement relativi.

6.1. Prerequisiti

L'ultimissima versione di RHN Proxy Server richiede:
  • Red Hat Enterprise Linux 5 (32-bit o 64-bit) o Red Hat Enterprise Linux 6 (solo a 64-bit).
  • La rimozione del profilo del sistema vecchio del Proxy Server dal Red Hat Network Classic o Satellite Server genitore (se applicabile).

6.2. Processo di aggiornamento dell'installazione

  1. Eseguire il back up del Proxy Server. Se applicabile ripristinare le informazioni per la compilazione del SSL dal backup alla directory /root/ssl-build.
  2. Eseguire la registrazione del Proxy Server su Red Hat Network Classic o sul Satellite Server genitore (se applicabile) Assicuratevi che il Proxy Server sia stato sottoscritto con il canale di base del server di Red Hat Enterprise Linux ed il canale figlio di Red Hat Network Tool.
  3. Installare il pacchetto spacewalk-proxy-installer dal canale figlio di Red Hat Network Tool:
    # yum install spacewalk-proxy-installer
    
  4. installare l'ultimissima versione del Proxy come riportato in Sezione 4.2, «Processo di installazione del RHN Proxy Server».

    Nota

    Se il Proxy Server è stato registrato con Red Hat Network Classic e in precedenza gestiva i canali personalizzati, allora sarà necessario ripristinare il repositorio dei pacchetti personalizzati dal backup eseguito precedentemente all'aggiornamento. Sarà altresì necessario impostare correttamente i permessi e l'ownership.
    # chmod 0750 /var/spool/rhn-proxy
    # chown apache:apache /var/spool/rhn-proxy
    # mkdir -m 0750 -p /var/spool/rhn-proxy/list
    # chown apache:apache /var/spool/rhn-proxy/list
    
    Generalmente il repositorio del pacchetto personalizzato predefinito è /var/spool/rhn-proxy.
  5. Dopo l'installazione aggiornare il server agli ultimissimi aggiornamenti dell'errata.
    # yum update
    
  6. Riavviare i servizi di RHN Proxy Server ed eseguire una prova sulla loro funzionalità:
    # /usr/sbin/rhn-proxy restart
    

Capitolo 7. Troubleshooting

Questo capitolo fornisce i suggerimenti per poter determinare la causa degli errori più comuni, e la loro risoluzione, associati con un RHN Proxy Server. Se avete bisogno di una maggiore assistenza, contattate il supporto di Red Hat Network su https://rhn.redhat.com/help/contact.pxt. Per poter visualizzare un elenco completo di opzioni è necessario eseguire un login utilizzando un account Satellite con l'entitlement richiesto.

7.1. Gestione del servizio Proxy

Poichè il RHN Proxy Server consiste in una moltitudine di singoli componenti, Red Hat fornisce uno script chiamato rhn-proxy il quale vi permetterà di arrestare, iniziare o recuperare gli stati presenti sul Proxy.

Tabella 7.1. comandi rhn-proxy

Comando Funzione
/usr/sbin/rhn-proxy start Il suddetto comando avvia il RHN Proxy Server se non risulta in esecuzione.
/usr/sbin/rhn-proxy stop Il suddetto comando arresta il RHN Proxy Server se non è stato precedentemente arrestato.
/usr/sbin/rhn-proxy restart Questo comando arresterà il RHN Proxy Server in esecuzione, riavviandolo subito dopo. Se invece RHN Proxy Server è stato precedentemente arrestato, esso verrà riavviato.
/usr/sbin/rhn-proxy status Questo comando mostrerà lo stato corrente di RHN Proxy Server.

7.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 o all'interno dell'applicazione, e possono essere utilizzate per monitorare le prestazioni ed assicurare una configurazione corretta. Consultate la Tabella 7.2, «File di log» per i percorsi dei file di log più importanti:

Tabella 7.2. File di log

Componente Posizione del file di log
Apache Web server directory /var/log/httpd/
Squid directory /var/log/squid/
RHN Proxy Broker Server /var/log/rhn/rhn_proxy_broker.log
RHN SSL Redirect Server /var/log/rhn/rhn_proxy_redirect.log
Red Hat Update Agent /var/log/yum.log

7.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.
Domanda: Dopo aver configurato il RHN Package Manager, come posso determinare se i pacchetti locali sono stati aggiunti al canale RHN privato?
Domanda: Ho modificato le impostazioni del nome DNS del mio Proxy Server ed ora i miei sistemi client non eseguono l'aggiornamento. Come posso correggerlo?
Domanda: Come posso sapere se i client sono in grado di collegarsi al server Squid?
Domanda: Il Red Hat Update Agent sui sistemi client non si collega attraverso il RHN Proxy Server. Come posso risolvere questo problema?
Domanda: La configurazione del mio RHN Proxy Server non funziona. Da dove posso iniziare il suo processo di troubleshooting?
Domanda:
Dopo aver configurato il RHN Package Manager, come posso determinare se i pacchetti locali sono stati aggiunti al canale RHN privato?
Risposta:
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.
Domanda:
Ho modificato le impostazioni del nome DNS del mio Proxy Server ed ora i miei sistemi client non eseguono l'aggiornamento. Come posso correggerlo?
Risposta:
Eseguite il comando up2date -u sul sistema client per implementare il nome modificato.
Domanda:
Come posso sapere se i client sono in grado di collegarsi al server Squid?
Risposta:
Il file /var/log/squid/access.log registra tutti i collegamenti al server Squid.
Domanda:
Il Red Hat Update Agent sui sistemi client non si collega attraverso il RHN Proxy Server. Come posso risolvere questo problema?
Risposta:
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 yum update yum come utenti root, oppure dal http://www.redhat.com/support/errata/.
Il RHN Proxy Server è una estensione di Apache. Consultate la Tabella 7.2, «File di log» per la posizione del suo file di log.
Domanda:
La configurazione del mio RHN Proxy Server non funziona. Da dove posso iniziare il suo processo di troubleshooting?
Risposta:
Assicuratevi che /etc/sysconfig/rhn/systemid sia posseduto da root.apache con i permessi 0640.
Consultate i file di log. Un elenco è disponibile sulla Tabella 7.2, «File di log».

7.4. Problemi generali

Per iniziare il troubleshooting di problemi generali esaminate i file di log oppure i file relativi sul 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 email dal RHN Proxy Server, controllate che gli indirizzi email corretti siano stati impostati per traceback_mail in /etc/rhn/rhn.conf.

7.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 per primo, 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 di RHN.
Per risolvere questo problema identificate il contenuto del file /etc/hosts. Potrebbe somigliare al seguente:
127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost
In un editor di testo rimuovere dal file le informazioni relative all'host della macchina nel modo seguente:
127.0.0.1 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:
127.0.0.1 localhost.localdomain.com localhost
123.45.67.8 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.

7.6. Errori di connessione

Se credete di aver incontrato problemi relativi ai collegamenti vi consigliamo di seguire quanto di seguito riportato:
  • Confermate l'uso del 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 Servers, assicuratevi che ogni certificato SSL sia stato creato correttamente. Se si utilizza il RHN Proxy Servers 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 protocolli come ad esempio http:// o https://. È 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 2.4, «Requisiti aggiuntivi».

7.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 Squid è disponibile in /var/spool/squid/. Per azzerarla:
  1. Arrestare Apache Web server: service httpd stop
  2. Arrestare il server Squid: service squid stop
  3. Cancellare il contenuto della directory: rm -fv /var/cache/rhn/*
  4. Riavviare entrambi i servizi:
    	
    			service squid start
    			service httpd start
    
È possibile eseguire più velocemente la stessa azione rimuovendo la directory e riavviando squid, così facendo però potreste dar luogo ad un certo numero di messaggi di traceback di RHN.
Anche la cache del meccanismo interno di archiviazione in cache 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 RHN Authentication Daemon non è 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 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 RHN Authentication Daemon, 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:
auth_cache.debug = 2

7.8. Proxy Debugging di Red Hat

Se avete utilizzato tutte le fasi di troubleshooting di seguito riportate, oppure se desiderate rimandarle ai professionisti di ed Hat Network, Red Hat consiglia di sfruttare il supporto offerto con RHN Proxy Server.
Un modo attraverso il quale è possibile usufruire del supporto dei nostri esperti è attraverso il Red Hat Knowledgebase, il quale fornisce le soluzioni alle problematiche più comuni incontrate dagli utenti, tramite una interfaccia robusta 'browse and search' per la ricerca delle risposte pertinenti alle problematiche relative al Proxy. È possibile accedere al Red Hat Knowledgebase su http://kbase.redhat.com.
Red Hat fornisce altresì un tool della linea di comando chiamato SoS Report, comunemente conosciuto come sosreport. Il tool raccoglie i parametri di configurazione del vostro Proxy, i file di log e le informazioni sul database inviandole direttamente a Red Hat.
Per usare questo tool con le informazioni di RHN Satellite Server è necessario aver installato il pacchetto sos. Digitare come utente root sosreport -o rhn sul server di Satellite per creare una notifica. Per esempio:
[root@satserver ~]# sosreport -o rhn

sosreport (version 1.7)

This utility will collect some detailed  information about the
hardware and  setup of your  Red Hat Enterprise Linux  system.
The information is collected and an archive is  packaged under
/tmp, which you can send to a support representative.
Red Hat will use this information for diagnostic purposes ONLY
and it will be considered confidential information.

This process may take a while to complete.
No changes will be made to your system.

Press ENTER to continue, or CTRL-C to quit.
A questo punto sarà necessario inserire l'iniziale del nome ed il cognome insieme ad un numero per la richiesta di supporto.
Potrebbero essere necessari alcuni minuti per la generazione ed archiviazione della notifica da parte del sistema in un file compresso.Una volta terminato inviate una email del nuovo file dalla directory /tmp/ al vostro rappresentante Red Hat per una diagnosi immediata.

Appendice A. Esempio di 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

È 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 predefinito, 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 = user0@domain.com, user1@domain.com

Appendice B. Diario delle Revisioni

Diario delle Revisioni
Revisione 3-5.2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revisione 3-5.2Tue Apr 23 2013Francesco Valente
it-IT translation completed
Revisione 3-5.1Thu Mar 21 2013Francesco Valente
I file della traduzione sono sincronizzati con con le versioni 3-5 dei sorgenti XML
Revisione 3-5Wed Sept 19 2012Dan Macpherson
Creazione finale per 5.5
Revisione 3-4 Wed Jul 4 2012Athene Chan
Preparato per la release 5.5
Incorporate le modifiche per la revisione tecnica
BZ#491007 Aggiunto il capitolo in Come aggiornare l'installazione
Revisione 3-0 Wed Jul 4 2012Athene Chan
Preparato per la release 5.5
Incorporate le modifiche per la revisione tecnica
BZ#491007 Aggiunto il capitolo in Come aggiornare l'installazione
Revisione 2-5Thu Jan 5 2012Lana Brindley
BZ#682996 - Capitolo installazione - Aggiorna istruzioni
BZ#705755 - Capitolo Gestore pacchetti - Informazioni aggiuntive
BZ#722193 - Capitolo Requisiti - Errore corretto
BZ#729617 - Capitolo Installazione - Errore corretto
BZ#729663 - Capitolo Installazione - Aggiunto un avvertimento
Revisione 2-4Mon Aug 15 2011Lana Brindley
Incorporata la release z-stream in y-stream
Revisione 2-3Wed Jun 22 2011Lana Brindley
BZ#713527 - Aggiunti i riferimenti al RHEL 6
Revisione 2-2Wed Jun 15 2011Lana Brindley
Preparato per la traduzione
Revisione 2-1Fri May 27 2011Lana Brindley
Aggiornamenti dei traduttori
Revisione 2-0Fri May 6 2011Lana Brindley
Pronto per la traduzione
Revisione 1-9Wed April 27 2011Lana Brindley
BZ#653844 - Revisione QE
Revisione 1-8Mon Feb 7 2011Lana Brindley
BZ#646176 - Installazione

Indice analitico

A

Amministratore del canale, Terminologia usata frequentemente
Amministratore dell'organizzazione, Terminologia usata frequentemente
archiviazione in cache squid, Problematiche di Caching
autenticazione, Come funziona il Proxy

C

caching per l'autenticazione
riordino, Problematiche di Caching
canale, Terminologia usata frequentemente
creazione di un canale privato, Creazione di un canale privato
canale privato, Creazione di un canale privato
come funziona il Proxy, Come funziona il Proxy
configurazione del client
sottoscrizione ad un canale privato, Caricamento dei pacchetti

D

domande e risposte, Domande e risposte

E

errore host not found
impossibile determinare il FQDN, Host non trovato/Impossibile determinare il FQDN
errori di connessione, Errori di connessione

F

file di log, File di log

H

HTTP Proxy Caching Server
requisiti di spazio del disco, Requisiti di spazio del disco

P

porta
443, Requisiti aggiuntivi
5222, Requisiti aggiuntivi
80, Requisiti aggiuntivi
porta 443, Requisiti aggiuntivi
porta 4545, Requisiti aggiuntivi
porta 80, Requisiti aggiuntivi
porte in ingresso, satellite
5222, Requisiti aggiuntivi
porte in uscita
80, 443, Requisiti aggiuntivi
Porte Proxy, Requisiti aggiuntivi
problematiche per la memorizzazione in cache, Problematiche di Caching
problemi generali, Problemi generali

R

Red Hat Network
introduzione, Red Hat Network
Red Hat Update Agent, Terminologia usata frequentemente, Come funziona il Proxy
requisiti, Requisiti
aggiuntivi, Requisiti aggiuntivi
di spazio del disco, Requisiti di spazio del disco
hardware, Requisiti hardware
software, Requisiti software
requisiti aggiuntivi, Requisiti aggiuntivi
requisiti di spazio del disco, Requisiti di spazio del disco
requisiti hardware, Requisiti hardware
requisiti software, Requisiti software
RHN Authentication Daemon, disabilitazione
rhn_auth_cache, arresto, Problematiche di Caching
RHN Package Manager, Come funziona il Proxy, RHN Package Manager e Servizio dei pacchetti locali
canali, specificare, Caricamento dei pacchetti
caricamento intestazioni del pacchetto, Caricamento dei pacchetti
crea canale privato, Creazione di un canale privato
file di configurazione, RHN Package Manager e Servizio dei pacchetti locali, Creazione di un canale privato
installazione, RHN Package Manager e Servizio dei pacchetti locali
opzioni della linea di comando, RHN Package Manager e Servizio dei pacchetti locali
verifica elenco pacchetti locali, Caricamento dei pacchetti
rhn-proxy
servizio, Gestione del servizio Proxy
rhn.conf
file di esempio, Esempio di File di configurazione di RHN Proxy Server
rhn_package_manager , Caricamento dei pacchetti (vedi RHN Package Manager)

S

satellite-debug, Proxy Debugging di Red Hat

T

Terminologia usata frequentemente, Terminologia usata frequentemente
tipologie, Esempio di tipologie
proxy con RHN Satellite Server, Proxy con il RHN Satellite Server
proxy multiple orizzontali, Topologia orizzontale di proxy multipli
proxy multiple verticali, Topologia verticale di Proxy multipli
proxy singolo, Topologia di Proxy singolo
traceback, Terminologia usata frequentemente
troubleshooting, Troubleshooting

V

vantaggi, RHN Proxy Server

Nota Legale

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