Red Hat Training
A Red Hat training course is available for Red Hat Satellite
Reference Guide
Red Hat Satellite 5.6
Guida alle funzioni avanzate di Red Hat Satellite
Edizione 1
Sommario
Benvenuti alla Red Hat Satellite 5.6 Reference Guide. La Red Hat Satellite Reference Guide vi guiderà attraverso le funzioni avanzate del server di Satellite.
Prefazione
1. A chi è rivolto
Questa guida è rivolta agli amministratori di sistema i quali dovranno gestire gli aggiornamenti per i sistemi presenti su una rete interna.
Capitolo 1. Informazioni specifiche al Red Hat Satellite
Questa sezione riporta vari argomenti relativi alla configurazione avanzata di Red Hat Satellite.
1.1. Strumento della linea di comando per la gestione della Configurazione
In aggiunta alle opzioni fornite nel sito web di Red Hat Satellite sono disponibili due tool della linea di comando per la gestione dei file di configurazione del sistema: Red Hat Network Configuration Client e Red Hat Network Configuration Manager. È disponibile un tool complementare, Red Hat Network Actions Control, utilizzato per abilitare e disabilitare la gestione della configurazione sui sistemi client. Se non avete ancora installato i suddetti tool essi sono disponibili all'interno del canale figlio Tool di Red Hat Network per il sistema operativo.
Nota
Ricordate, ogni qualvolta viene impiegato un file di configurazione tramite il sito web verrà creato all'interno della directory
/var/lib/rhncfg/backups/ sul sistema in questione, un backup del file insieme al suo percorso completo. Il suddetto backup manterrà il proprio filename, ma presenterà una estensione .rhn-cfg-backup.
1.1.1. Red Hat Network Actions Control
L'applicazione Red Hat Network Actions Control (
rhn-actions-control) viene utilizzata per abilitare e disabilitare il configuration management di un sistema. I sistemi client, per default, non possono essere gestiti in tal modo. Con questo tool gli Amministratori di sistema possono abilitare o disabilitare modalità specifiche relative ad azioni consentite, come ad esempio l'impiego di un file di configurazione su di un sistema, il caricamento di un file dal sistema, o l'utilizzo di diff per identificare ciò che è attualmente gestito sul sistema da quello disponibile, oppure l'esecuzione di comandi remoti arbitrari. Queste modalità vengono abilitate/disabilitate posizionando/rimuovendo i file e le directory all'interno della directory /etc/sysconfig/rhn/allowed-actions/. A causa dei permessi di default sulla directory /etc/sysconfig/rhn/, il Red Hat Network Actions Control molto probabilmente dovrà essere eseguito da un utente con accesso root.
1.1.1.1. Opzioni generali della linea di comando
È disponibile una pagina
man per la maggior parte dei tool della linea di comando. Scegliere le azioni programmate di Red Hat Network per gli amministratori di sistema. Le seguenti opzioni abilitano le diverse modalità di azioni programmate:
Tabella 1.1. Opzioni rhn-actions-control
| Opzione | Descrizione |
|---|---|
| --enable-deploy | Permette a rhncfg-client di utilizzare i file. |
| --enable-diff | Permette a rhncfg-client ad eseguire il diff dei file. |
| --enable-upload | Permette a rhncfg-client di caricare i file. |
| --enable-mtime-upload | Permette a rhncfg-client di caricare mtime. |
| --enable-all | Permette a rhncfg-client di eseguire tutto. |
| --enable-run | bilita script.run |
| --disable-deploy | Disabilita l'impiego. |
| --disable-diff | Disabilita diff |
| --disable-upload | Disabilita il caricamento |
| --disable-mtime-upload | Disabilita il caricamento mtime |
| --disable-all | Disabilita tutte le opzioni |
| --disable-run | Disabilita script.run |
| --report | Riporta se le modalità sono state abilitate o disabilitate |
| -f, --force | Forza il funzionamento senza prima chiedere |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
Una volta impostata la modalità il sistema sarà pronto alla gestione della configurazione per mezzo del Red Hat Satellite.
rhn-actions-control --enable-all è una opzione molto comune.
1.1.2. Red Hat Network Configuration Client
Come indicato dal nome, Red Hat Network Configuration Client (
rhncfg-client) deve essere installato ed eseguito da un sistema client individuale. Da lì è possibile il suo utilizzo per sapere come Red Hat Network impiega i file di configurazione per un particolare client.
Red Hat Network Configuration Client offre le seguenti modalità primarie: list, get, channels, diff, e verify.
1.1.2.1. Elenco dei file di configurazione
Per elencare i file di configurazione per la macchina, e le etichette dei canali di configurazione che li contengono, digitare il comando:
rhncfg-client list
L'output sarà simile al seguente elenco:
Config Channel File config-channel-17 /etc/example-config.txt config-channel-17 /var/spool/aalib.rpm config-channel-14 /etc/rhn/rhn.conf
Questi sono i file di configurazione applicati al vostro sistema. Tuttavia potranno esserci dei file duplicati all'interno di altri canali. Per esempio immaginate di digitare il seguente comando:
rhncfg-manager list config-channel-14
e osservate il seguente output:
File nel canale di configurazione 'config-channel-14' /etc/example-config.txt /etc/rhn/rhn.conf
Potreste domandarvi dove sia finito la seconda versione di
/etc/example-config.txt. L'importanza del file /etc/example-config.txt all'interno di config-channel-17, risulta essere più elevata di quello presente all'interno di config-channel-14. Come risultato, la versione del file di configurazione in config-channel-14 non verrà utilizzata in questo sistema, anche se il file risiede all'interno del canale. Il comando rhncfg-client non elenca il file poichè esso non verrà utilizzato sul sistema in questione.
1.1.2.2. Come ottenere un file di configurazione
Per scaricare il file di configurazione più importante per la macchina digitare il comando:
rhncfg-client get /etc/example-config.txt
Dovreste visualizzare un output simile al seguente:
Deploying /etc/example-config.txt
È possibile visualizzare i contenuti del file utilizzando
less oppure un altro pager. Notate che il file viene selezionato come il più importante in base al rango del canale di configurazione che lo contiene. È possibile ottenere quanto sopra, tramite la tabella Configurazione della pagina Informazioni sul Sistema.
1.1.2.3. Visualizzazione dei canali di configurazione
Per poter visualizzare le etichette ed i nomi dei canali di configurazione validi per il sistema, digitare il comando:
rhncfg-client channels
Dovreste visualizzare un output simile al seguente:
Canali di configurazione: Label Name ----- ---- config-channel-17 config chan 2 config-channel-14 config chan 1
La seguente tabella elenca le opzioni disponibili per
rhncfg-client get:
Tabella 1.2. opzioni rhncfg-client get
| Opzione | Descrizione |
|---|---|
| --topdir=TOPDIR | Esegui tutte le operazioni dei file in relazione a questa stringa. |
| --exclude=EXCLUDE | Impedisce l'implementazione di un file con 'get'/ può essere usato numerose volte. |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.2.4. Differenze tra i file di configurazione
Per visualizzare le differenze esistenti tra i file di configurazione impiegati sul sistema e quelli archiviati da Red Hat Network, digitare il comando:
rhncfg-client diff
Dovreste visualizzare un output simile al seguente:
[root@testsatellite root]# rhncfg-client diff --- /etc/test +++ /etc/test 2013-08-28 00:14:49.405152824 +1000 @@ -1 +1,2 @@ This is the first line +This is the second line added
In aggiunta, potreste includere l'opzione
--topdir per confrontare i file di configurazione in Red Hat Network con quelli posizionati in un luogo arbitrario (e non utilizzato) sul sistema client:
[root@ root]# rhncfg-client diff --topdir /home/test/blah/ /usr/bin/diff: /home/test/blah/etc/example-config.txt: No such file or directory /usr/bin/diff: /home/test/blah/var/spool/aalib.rpm: No such file or directory
1.1.2.5. Verifica dei file di configurazione
Per verificare velocemente se i file di configurazione del client sono diversi da quelli associati tramite Red Hat Network digitare il comando:
rhncfg-client verify
Dovreste visualizzare un output simile al seguente:
/etc/example-config.txt /var/spool/aalib.rpm modificato
Il file
example-config.txt viene modificato localmente, mentre aalib.rpm no lo è.
La seguente tabella elenca le opzioni disponibili per
rhncfg-client verify:
Tabella 1.3. opzioni rhncfg-client verify
| Opzione | Descrizione |
|---|---|
| -v, --verbose | Aumenta la quantità di informazioni dell'output. Visualizza le differenze presenti all'interno della modalità, ed i permessi del gruppo per il file di configurazione specificato. |
| -o, --only | Mostra solo i file diversi. |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3. Red Hat Network Configuration Manager
Diversamente da Red Hat Network Configuration Client, Red Hat Network Configuration Manager (
rhncfg-manager) è stato creato in modo da poter mantenere la repository centrale di RHN, dei canali e dei file di configurazione e non di quelli che si trovano sui sistemi client. Questo tool offre una linea di comando alternativa alle caratteristiche di gestione della configurazione, all'interno del sito web di Red Hat Network, insieme all'abilità di eseguire script relativi a compiti di gestione.
Viene utilizzato dagli amministratori della configurazione, e per questo motivo richiede l'uso di un nome utente e di una password di Red Hat Network, insieme ai permessi appropriati. Il nome utente può essere specificato in
/etc/sysconfig/rhn/rhncfg-manager.conf, oppure nella sezione [rhncfg-manager] di ~/.rhncfgrc.
Quando si esegue Red Hat Network Configuration Manager come utente root, esso cercherà di ottenere i valori di configurazione necessari da Red Hat Update Agent. Quando viene eseguito invece come utente diverso da root, potrebbe essere necessario eseguire alcune modifiche alla configurazione, all'interno del file
~/.rhncfgrc. Il file di sessione viene conservato in ~/.rhncfg-manager-session in modo da prevenire il loggin di ogni comando.
La scadenza predefinita per Red Hat Network Configuration Manager è di 30 minuti. Per alterare questo parametro, aggiungere l'opzione
server.session_lifetime, ed il nuovo valore al file /etc/rhn/rhn.conf sul server che esegue il manager come di seguito riportato:
server.session_lifetime = 120
Red Hat Network Configuration Manager offre le seguenti modalità primarie: add, create-channel, diff, diff-revisions, download-channel, get, list, list-channels, remove, remove-channel, revisions, update, e upload-channel.
Ogni modalità offre un proprio set di opzioni, le quali possono essere visualizzate emettendo il comando:
rhncfg-manager mode --help
Sostituire mode con il nome della modalità da ispezionare:
rhncfg-manager diff-revisions --help
È possibile visualizzare un elenco di opzioni per la modalità aggiungi nella Tabella 1.4, «Opzioni
rhncfg-manager add».
1.1.3.1. Creazione di un canale di configurazione
Per creare un canale di configurazione per la vostra organizzazione digitare il comando:
rhncfg-manager create-channel channel-label
Fornite, se richiesto, la password e nome utente di Red Hat Satellite. Dovreste visualizzare un output del tipo:
Red Hat Network username: rhn-user Password: Creating config channel channel-label Config channel channel-label created
Una volta creato un canale di configurazione, utilizzate le modalità rimanenti sopra riportate,per popolare e gestire quel canale.
1.1.3.2. Come aggiungere un file ad un canale di configurazione
Per aggiungere un file ad un canale di configurazione, è necessario specificare l'etichetta del canale insieme al file locale da caricare, come ad esempio:
rhncfg-manager add --channel=channel-label /path/to/file
Oltre all'etichetta del canale ed al percorso per il file, durante la sua aggiunta è possibile utilizzare le opzioni disponibili per modificare il file stesso. Per esempio, potete alterare il filename ed il percorso includendo l'opzione
--dest-file all'interno del comando:
rhncfg-manager add --channel=channel-label --dest-file=/new/path/to/file.txt/path/to/file
Dovreste visualizzare un output simile al seguente:
Pushing to channel example-channel Local file >/path/to/file -> remote file /new/path/to/file.txt
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager add:
Tabella 1.4. Opzioni rhncfg-manager add
| Opzione | Descrizione |
|---|---|
| -c CHANNEL --channel=CHANNEL | Carica i file in questo canale di configurazione |
| -d DEST_FILE --dest-file=DEST_FILE | Carica il file come questo path |
| --delim-start=DELIM_START | Inizia il delimitatore per l'interpolazione variabile |
| --delim-end=DELIM_END | Termina il delimitatore per l'interpolazione variabile |
| -i, --ignore-missing | Ignora i file locali mancanti |
| --selinux-context=SELINUX_CONTEXT | Sovrascrive il contesto di SELinux |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
Nota
Per default la dimensione massima del file per i file di configurazione è 128KB. Se desiderate modificare il suddetto valore cercate o create la seguente riga nel file
/etc/rhn/rhn.conf:
web.maximum_config_file_size=128
Altresì trovate o create la seguente riga nel file
/etc/rhn/rhn.conf:
maximum_config_file_size=128
Modificate il valore da 128 al limite desiderato espresso in byte.
1.1.3.3. Differenze tra gli ultimissimi file di configurazione
Per ottenere una differenza tra i file di configurazione presenti sul disco e le ultimissime revisioni presenti in un canale digitare il comando:
rhncfg-manager diff --channel=channel-label --dest-file=/path/to/file.txt \ /local/path/to/file
Dovreste visualizzare un output simile al seguente:
--- /tmp/dest_path/example-config.txt config_channel: example-channel revision: 1 +++ /home/test/blah/hello_world.txt 2003-12-14 19:08:59.000000000 -0500 @@ -1 +1 @@ -foo +hello, world
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager diff:
Tabella 1.5. Opzioni rhncfg-manager diff
| Opzione | Descrizione |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Ottenere un file da questo canale di configurazione |
| -r REVISION, --revision=REVISION | Utilizzare questa revisione |
| -d DEST_FILE, --dest-file=DEST_FILE | Carica il file come questo path |
| -t TOPDIR, --topdir=TOPDIR | Create tutti i file in relazione a questa stringa |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.4. Differenze tra diverse versioni
Per confrontare versioni diverse di un file attraverso i canali e le revisioni, utilizzare
-r per indicare quale revisione dovrebbe essere utilizzata per il confronto, e -n per identificare i due canali da controllare. Consultate la Sezione 1.1.3.11, «Come determinare il numero delle revisioni del file» per le istruzioni relative. Da notare che è necessario specificare solo un filename poichè il file stesso verrà confrontato con un'altra versione:
rhncfg-manager diff-revisions -n=channel-label1 -r=1 -n=channel-label2 -r=1 /path/to/file.txt
Dovreste visualizzare un output simile al seguente:
--- /tmp/dest_path/example-config.txt 2004-01-13 14:36:41 \ config channel: example-channel2 revision: 1 --- /tmp/dest_path/example-config.txt 2004-01-13 14:42:42 \ config channel: example-channel3 revision: 1 @@ -1 +1,20 @@ -foo +blah +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iD8DBQA9ZY6vse4XmfJPGwgRAsHcAJ9ud9dabUcdscdcqB8AZP7e0Fua0NmKsdhQCeOWHX +VsDTfen2NWdwwPaTM+S+Cow= +=Ltp2 +-----END PGP SIGNATURE-----
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager diff-revisions:
Tabella 1.6. Opzioni rhncfg-manager diff-revisions
| Opzione | Descrizione |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Utilizza questo canale di configurazione |
| -r REVISION, --revision=REVISION | Utilizzare questa revisione |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.5. Come scaricare tutti i file all'interno di un canale
Per scaricare tutti i file presenti in un canale su di un disco, create una directory ed emettete il comando:
rhncfg-manager download-channel channel-label --topdir .
Dovreste visualizzare un output simile al seguente:
Copiatura /tmp/dest_path/example-config.txt -> \ blah2/tmp/dest_path/example-config.txt in corso
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager download-channel:
Tabella 1.7. Opzioni rhncfg-manager download-channel
| Opzione | Descrizione |
|---|---|
| -t TOPDIR, --topdir=TOPDIR | Directory relativa ai path del file. Questa opzione deve essere impostata. |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.6. Come ottenere i contenuti di un file
Per direzionare i contenuti di un file particolare su stdout digitare il seguente comando:
rhncfg-manager get --channel=channel-label \ /tmp/dest_path/example-config.txt
Dovreste visualizzare un output dei contenuti del file.
1.1.3.7. Come elencare tutti i file in un canale
Per poter elencare tutti i file in un canale digitare il seguente comando:
rhncfg-manager list channel-label
Dovreste visualizzare un output simile al seguente:
File nel canale di configurazione `example-channel3': /tmp/dest_path/example-config.txt
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager get:
Tabella 1.8. Opzioni rhncfg-manager get
| Opzione | Descrizione |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Ottenere un file da questo canale di configurazione |
| -t TOPDIR, --topdir=TOPDIR | Create tutti i file in relazione a questa stringa |
| -r REVISION, --revision=REVISION | Ottieni questa revisione del file |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.8. Come elencare tutti i canali di configurazione
Per poter elencare tutti i canali di configurazione dell'organizzazione digitare il seguente comando:
rhncfg-manager list-channels
Dovreste visualizzare un output simile al seguente:
Canali di configurazione disponibili: example-channel example-channel2 example-channel3 config-channel-14 config-channel-17
Da notare che il suddetto comando non elenca i canali
local_override o server_import.
1.1.3.9. Come rimuovere un file da un canale
Per rimuovere un file da un canale digitare il comando:
rhncfg-manager remove --channel=channel-label /tmp/dest_path/example-config.txt
Fornite, se richiesto, la password e nome utente di Red Hat Network. Dovreste visualizzare un output del tipo:
Nome utente di Red Hat Network: rhn-user Password: Removing from config channel example-channel3 /tmp/dest_path/example-config.txt removed
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager remove:
Tabella 1.9. Opzioni rhncfg-manager remove
| Opzione | Descrizione |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Rimuovi file da questo canale di configurazione |
| -t TOPDIR, --topdir=TOPDIR | Create tutti i file in relazione a questa stringa |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.10. Come cancellare un canale di configurazione
Per cancellare un canale di configurazione presente all'interno della vostra organizzazione digitare il seguente comando:
rhncfg-manager remove-channel channel-label
Dovreste visualizzare un output simile al seguente:
Rimozione canale di configurazione example-channel Config channel example-channel removed
1.1.3.11. Come determinare il numero delle revisioni del file
Per ottenere il numero di revisioni (esse vanno da 1 a N numero intero maggiore di 0) di un file/percorso presenti in un canale digitare il suddetto comando:
rhncfg-manager revisions channel-label /tmp/dest_path/example-config.txt
Dovreste visualizzare un output simile al seguente:
Analisi file nel canale di configurazione example-channel \ /tmp/dest_path/example-config.txt: 1
1.1.3.12. Come aggiornare un file presente all'interno di un canale
Per creare una nuova revisione di un file all'interno di un canale (oppure aggiungere la prima revisione ad un determinato canale, se non esistente, per un dato percorso) digitare il seguente comando:
rhncfg-manager update \ --channel=channel-label --dest-file=/path/to/file.txt /local/path/to/file
Dovreste visualizzare un output simile al seguente:
Pushing nel canale example-channel: Local file example-channel/tmp/dest_path/example-config.txt -> \ remote file /tmp/dest_path/example-config.txt
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager update:
Tabella 1.10. Opzioni rhncfg-manager update
| Opzione | Descrizione |
|---|---|
| -c CHANNEL, --channel=CHANNEL | Carica i file in questo canale di configurazione |
| -d DEST_FILE, --dest-file=DEST_FILE | Carica il file come questo path |
| -t TOPDIR, --topdir=TOPDIR | Create tutti i file in relazione a questa stringa |
| --delim-start=DELIM_START | Inizia il delimitatore per l'interpolazione variabile |
| --delim-end=DELIM_END | Termina il delimitatore per l'interpolazione variabile |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.1.3.13. Come caricare file multipli simultaneamente
Per poter caricare simultaneamente file multipli su di un canale di configurazione digitare il comando:
rhncfg-manager upload-channel --topdir=topdir channel-label
Dovreste visualizzare un output simile al seguente:
Utilizzo canale di configurazione example-channel4 Uploading /tmp/ola_world.txt from blah4/tmp/ola_world.txt
La seguente tabella elenca le opzioni disponibili per
rhncfg-manager upload-channel:
Tabella 1.11. Opzioni rhncfg-manager upload-channel
| Opzione | Descrizione |
|---|---|
| -t TOPDIR, --topdir=TOPDIR | Directory relativa ai path del file |
| -c CHANNEL, --channel=CHANNEL | Elenco dei canali sui quali verranno caricate le informazioni sulla configurazione. I canali delimitati da ','. Esempio: --channel=foo,bar,baz |
| -h, --help | Mostra il messaggio d'aiuto ed esce |
1.2. Monitoring
L'entitlement Monitoring di Red Hat Network permette di eseguire un insieme di azioni ideate per mantenere i sistemi in corretta esecuzione ed efficienti. Con questo tipo di entitlement sarete in grado di controllare le risorse del sistema, i servizi di rete, i database ed entrambe le applicazioni standard e personalizzate.
Il Monitoring è in grado di fornire sia informazioni in tempo reale che quelle riguardanti la cronologia sulle modifiche dello stato, insieme ai dati metrici specifici. Esso fornisce le notifiche sulla presenza di errori e sul degrado delle prestazioni prima di raggiungere il livello critico. Inoltre sarete informati sulla necessità di condurre una pianificazione sulla capacità e degli eventi ad essa correlati. Per esempio, i risultati di un probe sulla registrazione dell'utilizzo della CPU attraverso i sistemi, risulterà avere un enorme valore per il bilanciamento dei carichi sui sistemi in questione.
Per il sistema di monitoraggio sono disponibili due componenti: il sistema di monitoraggio stesso ed il monitoring scout. Il sistema di monitoraggio viene installato sul Satellite ed esegue funzioni backend, come ad esempio l'archiviazione dei dati per il monitoring e l'esecuzione. Il monitoring scout esegue tutti i probe e raccoglie i dati relativi al monitoring. Il monitoring scout può essere abilitato per la sua esecuzione su di un Satellite o su sistemi Red Hat Satellite Proxy. L'uso del monitoring scout sul Proxy permette di scaricare il lavoro dal server di Satellite, fornendo così una scalabilità ai probe.
Il Monitoring rende possibile la creazione di metodi di notifica, l'installazione dei probes sui sistemi, un controllo regolare dello stato di tutti i probe, e la generazione dei riporti in grado di visualizzare i dati sulla cronologia per un sistema o per un servizio. Qquesta sezione cerca di identificare i compiti comuni associati con l'entitlement di Monitoring. Ricordate, virtualmente tutte le modifiche che interessano la vostra infrastruttura di Monitoring, devono essere finalizzate aggiornando la vostra configurazione attraverso la pagina Scout Config Push.
1.2.1. Prerequisiti
Prima di implementare il Monitoring di Red Hat Network con l'infrastruttura, assicuratevi di avere tutti i tool necessari. Come minimo avrete bisogno di:
- Entitlement di Monitoring - Questi entitlement sono necessari per tutti i sistemi da controllare. Il Monitoring è supportato solo sui sistemi Red Hat Enterprise Linux.
- Red Hat Satellite con Monitoring - I sistemi con il Monitoring devono essere collegati ad un Satellite con un sistema operativo di base Red Hat Enterprise Linux 5.
- Amministratore Monitoring - Questo ruolo deve essere garantito a tutti gli utenti che istallano i probe, per la creazione dei metodi di notifica, o che alterano in alcun modo l'infrastruttura di monitoring. (Ricordate, l'Amministratore di Satellite eredita in modo automatico le caratteristiche di ogni altro ruolo presente all'interno dell'organizzazione, e quindi sarà in grado di eseguire tali compiti.) Assegnare questo ruolo attraverso la pagina Informazioni utente.
- Red Hat Network monitoring daemon - Questo demone, insieme con la chiave SSH per lo scout, deve essere presente sui sistemi da monitorare per poter eseguire i processi interni di controllo. Potreste, tuttavia, essere in grado di eseguire i suddetti probe utilizzando il demone SSH già esistente (
sshd). Per informazioni sull'installazione consultate la Sezione 1.2.2, «Configurazione di Red Hat Network Monitoring Daemon (rhnmd)» e un breve elenco di probe che richiedono questo tipo di collegamento sicuro. Per un elenco completo di probes disponibili, consultate l'Appendice A, Probe.
Come abilitare il monitoring
Il monitoring è disabilitato per impostazione predefinita e sarà necessario abilitarlo prima di poterlo utilizzare.
- Eseguite un log in come Amministratore satellite e navigate attraverso → . Selezionare Abilita Monitoring e successivamente per salvare le impostazioni.
- Per confermare le modifiche riavviate i servizi. Andate sulla scheda per riavviare Satellite. Tale azione imposterà Satellite in modalità offline per qualche minuto.
- Controllate se la scheda è disponibile con la per confermarne la sua abilitazione.
- Andate su → → . Selezionare per abilitare lo scout. Selezionate per salvare.
Nota
È consigliato lasciare i valori relativi alla configurazione del monitoring sui rispettivi valori predefiniti. Configurare Sendmail per utilizzare le notifiche.
1.2.2. Configurazione di Red Hat Network Monitoring Daemon (rhnmd)
Per ottenere il massimo da un entitlement di monitoring, Red Hat suggerisce l'installazione del Red Hat Network monitoring daemon sui vostri sistemi client. Basato su OpenSSH,
rhnmd permette a Satellite di comunicare in modo sicuro con il sistema client in modo da poter accedere ai processi interni e recuperare lo stato di probe.
Notare che il Red Hat Network Monitoring Daemon ha come requisito la possibilità da parte dei sistemi controllati di abilitare i collegamenti sulla porta 4545. È possibile installare il demone utilizzando
sshd senza utilizzare la porta in questione. Per maggiori informazioni consultate la Sezione 1.2.2.2, «Come configurare SSH».
Alcuni probe hanno bisogno di un demone. Per poter eseguire i seguenti probe è necessario stabilire sui sistemi client un collegamento cifrato attraverso il Red Hat Network monitoring daemon o
sshd:
- Linux::CPU Usage
- Linux::Disk IO Throughput
- Linux::Disk Usage
- Linux::Inodes
- Linux::Interface Traffic
- Linux::Load
- Linux::Memory Usage
- Linux::Process Counts by State
- Linux::Process Count Total
- Linux::Process Health
- Linux::Process Running
- Linux::Swap Usage
- Linux::TCP Connections by State
- Linux::Users
- Linux::Virtual Memory
- LogAgent::Log Pattern Match
- LogAgent::Log Size
- Network Services::Remote Ping
- Oracle::Client Connectivity
- General::Remote Program
- General::Remote Program with Data
Notate che tutti i probe presenti su Linux presentano questo requisito.
1.2.2.1. Installazione di Red Hat Network Monitoring Daemon
Installate il Red Hat Network Monitoring Daemon per poter preparare i sistemi al monitoring utilizzando i probe identificati da
rhnmd. Da notare che le fasi presenti in questa sezione risultano essere facoltative se desiderate usare sshd per ottenere i collegamenti sicuri tra l'infrastruttura di monitoring del Red Hat Network e i sistemi controllati. Per maggiori informazioni consultate la Sezione 1.2.2.2, «Come configurare SSH».
Il pacchetto
rhnmd è disponibile all'interno del canale Red Hat Network Tools su tutte le distribuzioni di Red Hat Enterprise Linux. Per poterlo installare:
- Registrate i sistemi da monitorare sul canale Red Hat Network Tools associato al sistema. Tale processo può essere eseguito in modo individuale attraverso la scheda → → , oppure simultaneamente per tutti i sistemi tramite la scheda → .
- Una volta eseguita la registrazione aprite la scheda → e trovate il pacchetto
rhnmd(sotto la lettere 'R'). - Per poter aprire la pagina Informazioni sul pacchetto fate clic sul nome del pacchetto stesso. Andate sulla tabella Sistemi target, selezionate i sistemi desiderati, e fate clic su .
- Installate la chiave pubblica SSH su tutti i sistemi client da controllare, come riportato nella Sezione 1.2.2.3, «Come installare la chiave SSH».
- Avviate il Red Hat Network monitoring daemon su tutti i sistemi client utilizzando il comando:
service rhnmd start - Quando aggiungete i probes che necessitano del demone, accettate i valori di default rispettivamente per l'Utente RHNMD e la Porta RHNMD: su
nocpulsee4545.
1.2.2.2. Come configurare SSH
Se non desiderate installare il Red Hat Network monitoring daemon e aprire la porta 4545 sui sistemi client, potrete configurare
sshd in modo da fornire il collegamento cifrato necessario tra i sistemi e Red Hat Network. Ciò potrebbe risultare particolarmente utile se sshd è già in esecuzione. Per configurare il demone al controllo:
- Assicuratevi che il pacchetto SSH sia installato sui sistemi da controllare:
rpm -qi openssh-server - Identificate l'utente da associare con il demone, esso può essere qualsiasi utente disponibile sul sistema, sul quale è possibile inserire la chiave SSH all'interno del file
~/.ssh/authorized_keys. - Installate la chiave pubblica SSH su tutti i sistemi client da controllare, come riportato nella Sezione 1.2.2.3, «Come installare la chiave SSH».
- Avviate
sshdsu tutti i sistemi cleint utilizzando il comando:service sshd start - Quando aggiungete i probes che necessitano del demone, inserite i valori derivati dalle fasi 2 e 3 nei campi Utente RHNMD e Porta RHNMD.
1.2.2.3. Come installare la chiave SSH
Se usate
rhnmd o sshd, è necessario installare la chiave SSH pubblica del Red Hat Network monitoring daemon sui sistemi da controllare in modo da poter completare il collegamento sicuro. Per installarla:
- Copiate la stringa relativa al carattere (iniziando con ssh-dss e finendo con l'hostname del Satellite).
- Selezionate Sistemi dal menu e successivamente le caselle accanto ai sistemi desiderati ai quali inviare la chiave SSH. Fate clic sul pulsante nella parte alta per terminare.
- Dal System Set Manager, fate clic su Esegui comandi remoti e successivamente digitate nella casella Script la seguente riga:
#!/bin/sh cat <<EOF >> ~nocpulse/.ssh/authorized_keys
Premere Invio, incollare la chiave SSH e aggiungere EOF. Il risultato dovrebbe essere simile al seguente:#!/bin/sh cat <<EOF>> ~nocpulse/.ssh/authorized_keys ssh-dss AABBAB3NzaC3kc3MABCCBAJ4cmyf5jt/ihdtFbNE1YHsT0np0SYJz7xk hzoKUUWnZmOUqJ7eXoTbGEcZjZLppOZgzAepw1vUHXfa/L9XiXvsV8K5Qmcu70h0 1gohBIder/1I1QbHMCgfDVFPtfV5eedau4AAACAc99dHbWhk/dMPiWXgHxdI0vT2 SnuozIox2klmfbTeO4Ajn/Ecfxqgs5diat/NIaeoItuGUYepXFoVv8DVL3wpp45E 02hjmp4j2MYNpc6Pc3nPOVntu6YBv+whB0VrsVzeqX89u23FFjTLGbfYrmMQflNi j8yynGRePIMFhI= root@satellite.example.com EOF
- Impostate una data e l'ora per l'azione e fate clic su .
Quando la chiave è presente e sarà accessibile tutti i probes interessati dovrebbero abilitare i collegamenti
ssh tra l'infrastruttura di monitoring ed il sistema controllato. Succesivamente potrete programmare l'esecuzione dei probe che necessitano del demone di monitoring nei confronti dei sistemi appena configurati.
1.2.3. Configurazione del pacchetto mysql per i probe
Se il Red Hat Satellite verrà utilizzato per servire i sistemi client abilitati al monitoring nei confronti dei quali desiderate eseguire i probe MySQL, allora è necessario configurare il pacchetto
mysql sul Red Hat Satellite. Per un elenco di tutti i probe disponibili consultate Appendice A, Probe .
Registrate Satellite sul canale di base di Red Hat Enterprise Linux e successivamente installate il pacchetto
mysql tramite up2date, yum o Red Hat Network Hosted.
Una volta terminato, Satellite potrà essere utilizzato per programmare i probe MySQL.
1.2.4. Come abilitare le notifiche
In aggiunta alla possibilità di poter visualizzare lo stato di probe all'interno dell'interfaccia Red Hat Network, è possibile ricevere una notifica ogni qualvolta varia lo stato di un probe. Tale procedura risulta essere particolarmente importante durante il monitoring dei sistemi mission-critical. Per questo motivo, Red Hat consiglia di sfruttare questa caratteristica.
Per abilitare le notifiche di probe all'interno di Red Hat Network è necessario identificare un server di scambio posta ed un dominio di posta durante l'installazione di Red Hat Satellite, ed aver configurato sendmail per gestire in modo corretto la posta in arrivo. Per maggiori informazioni consultate il capitolo Installazione della Red Hat Satellite Installation Guide.
1.2.4.1. Creazione dei metodi di notifica
Le notifiche vengono inviate tramite un metodo di notifica, oppure tramite un indirizzo email o pager associato con un utente Red Hat Network specifico. Anche se l'indirizzo è legato ad un account particolare dell'utente, esso potrebbe servire amministratori multipli per mezzo di un alias o una mailing list. A loro volta ogni account utente è in grado di contenere metodi multipli di notifica. Per poter creare un metodo di notifica:
- Registratevi sul Satellite come Amministratore Satellite oppure come Amministratore del monitoring.
- Andate su Utenti e selezionate il nome utente. Sulla pagina Informazioni utente selezionare → .
- Inserite una etichetta intuitiva e descrittiva per il nome del metodo, come ad esempio
DBA day email, e fornite l'indirizzo email corretto. Ricordate, le etichette per tutti i metodi di notifica, saranno disponibili in un elenco singolo durante la creazione di probe, per questo motivo esse devono essere uniche alla vostra organizzazione. - Se desiderate inviare messaggi abbreviati all'indirizzo email selezionate allora la casella di controllo. Il suddetto formato contiene solo lo stato di probe, l'hostname del sistema, il nome di probe, l'orario del messaggio, e l'ID d'invio. Il formato standard e quindi più lungo, visualizza testi aggiuntivi di messaggio, informazioni su probe e sul sistema, e le istruzioni per la risposta.
- Una volta terminato fate clic su . Il nuovo metodo apparirà all'interno della scheda → e sulla pagina Notifica sotto la categoria principale Monitoring. Fate clic sul suo nome per apportare una modifica o per cancellarlo.
- Durante l'aggiunta dei probe, selezionate la casella Notifiche probe, selezionando il nuovo metodo di notifica presente sul menu a tendina. Da notare che i metodi di notifica assegnati ai probe, non possono essere cancellati fino a quando non si rimuove l'associazione corrispondente.
1.2.4.2. Ricezione delle notifiche
Se create alcuni metodi di notifica, associandoli ai probe, allora dovete essere pronti anche alla loro ricezione. Queste notifiche arriveranno sottoforma di brevi messaggi di testo inviati all'indirizzo email. Ecco un esempio di una email di notifica:
Subject: CRITICAL: [hostname]: Satellite: Users at 1 From: "Monitoring Satellite Notification" (rogerthat01@redhat.com) Date: Mon, 26 Aug 2013 13:42:28 -0800 To: user@organization.com This is Red Hat Monitoring Satellite notification 01dc8hqw. Time: Mon Aug 26, 21:42:25 PST State: CRITICAL System: [hostname] ([IP address]) Probe: Satellite: Users Message: Users 6 (above critical threshold of 2) Notification #116 for Users Run from: Red Hat Monitoring Satellite
Come potete vedere, le email di notifica più lunghe contengono virtualmente ogni informazione necessaria per conoscere il probe associato. In aggiunta al comando di probe, del tempo di esecuzione, del sistema monitorato, e dello stato, il messaggio contiene l'ID d'invio, il quale risulta essere una stringa di carattere unica, che rappresenta il messaggio preciso ed il probe. Nel messaggio sopra riportato, l'ID d'invio è 01dc8hqw.
Nota
Poichè le notifiche possono essere generate ogni qualvolta si verifica una modifica allo stato di probe, piccoli cambiamenti nella rete potrebbero risultare in un flusso elevatissimo di notifiche. Le notifiche potrebbero essere ridirezionate ad una casella di posta apposita, in modo da evitare possibili problemi con la posta prioritaria. La sezione successiva affronta il ridirezionamento delle notifiche.
1.2.4.3. Ridirezionamento delle notifiche
Dopo aver ricevuto una notifica sarete in grado di ridirezionarla implementando le regole avanzate di notifica presenti all'interno di una email di conferma. Abilitare la ridirezione della risposta della email aprendo
/etc/aliases ed aggiungendo la seguente riga:
rogerthat01: "| /etc/smrsh/ack_queuer.pl"
Una volta impostato il parametro rispondere alla email di notifica ed includere l'opzione desiderata. Di seguito sono riportate le opzioni possibili, o i tipi di filtro:
- ACK METOO - Invia la notifica alla destinazione finale dopo aver eseguito la ridirezione, in aggiunta alla destinazione di default.
- ACK SUSPEND - Sospende il metodo di notifica per un periodo di tempo specificato.
- ACK AUTOACK - Non modifica la destinazione della notifica, ma automaticamente riconosce le alert corrispondenti appena inviate.
- ACK REDIR - Invia la notifica alla destinazione finale dopo aver eseguito un processo di ridirezionamento, invece della destinazione di default.
Il formato della regola deve essere filter_type probe_type duration email_address, dove filter_type risulta essere uguale ad uno dei seguenti comandi avanzati, probe_type indica
check o host, duration indica il tempo necessario per eseguire una procedura di ridirezionamento, e email_address corrisponderà al destinatario. Per esempio:
ACK METOO host 1h boss@domain.com
La capitalizzazione non sarà necessaria. La durata può essere elencata in minuti (m), ore (h), oppure in giorni (d). Gli indirizzi email sono necessari solo per eseguire le procedure di ridirezionamento (REDIR), e per notifiche (METOO) supplementari.
La descrizione del tipo d'azione contenuta all'interno della email risultante, risulterà essere il comando di default inserito dell'utente. Il contenuto elencato risulterà essere il riassunto dell'azione, come ad esempio email ack redirect by user@domain.com dove l'utente sarà uguale al mittente dell'email.
Nota
Potete arrestare o ridirezionare tutte le notifiche di probe, rispondendo alle email di notifica con una variante del comando
ack suspend host. Tuttavia non è possibile arrestare le notifiche probe di Satellite rispondendo con ack suspend host, o utilizzando altri tipi di comandi per il ridirezionamento. È necessario per questi probe, modificare le notifiche all'interno della web interface di Satellite.
1.2.4.4. Cancellazione dei metodi di notifica
Sfortunatamente l'esistenza di un rapporto tra metodi e probe potrebbe complicare il processo di cancellazione dei metodi di notifica. Seguire le fasi riportate per rimuovere il metodo di notifica:
- Registratevi sul Satellite come Amministratore Satellite oppure come Amministratore del monitoring.
- Andate sulla pagina → e selezionate il nome del metodo da rimuovere.
- Sulla scheda → → selezionate cancella metodo. Se il metodo non è associato con alcun probe, visualizzerete una pagina di conferma. Fate clic su . A questo punto il metodo di notifica verrà rimosso.
Nota
Poichè sia il nome del metodo di notifica che l'indirizzo possono essere modificati, considerate aggiornare il metodo invece di cancellarlo. Ciò ridirezionerà le notifiche di tutti i probe, senza modificarli, creando quindi un nuovo metodo di notifica. - Se il metodo è stato associato con uno o più probe, visualizzerete un elenco di probe che utilizzano il metodo ed i sistemi ai quali i probe stessi sono collegati. Fate clic sul nome dei probe per andare direttamente sulla scheda → .
- Selezionate un altro metodo di notifica e fate clic su .
- Ritornate sulla pagina → e cancellate il metodo di notifica.
1.2.5. Informazioni sui Probe
Ora che il Red Hat Network monitoring daemon è stato installato e che i metodi di notifica sono stati creati, potrete iniziare a installare i probe sui sistemi con un entitlement di monitoring. Se un sistema presenta un entitlement di monitoring, all'interno della pagina Informazioni del sistema apparirà la scheda Probe. È proprio qui che sarete in grado di eseguire molti dei compiti relativi ai probe.
1.2.5.1. Gestione dei probes
I probe vengono creati attraverso il server di Red Hat Satellite. Una volta creati, i probe verranno inoltrati ai sistemi con entitlement di monitoring specificatiche risultano registrati con il Satellite. Seguire le fasi riportate per aggiungere un probe nel server di Satellite:
- Registratevi sul Satellite come Amministratore Satellite o come Amministratore gruppi di sistemi.
- Andate sulla scheda → e selezionate crea nuovo probe.
- Nella pagina Creazione probe del sistema, completate tutti i campi necessari. Come prima cosa selezionate il Gruppo di comando di probe. Tale operazione modificherà l'elenco dei probe disponibili insieme ad altri campi e requisiti. Per un elenco completo basato sul gruppo di comandi dei probe consultate l'Appendice A, Probe. Per poter usare determinati probe è necessario installare Red Hat Network monitoring daemon sul sistema client.
- Selezionate il Comando probe desiderato ed il Monitoring Scout, generalmente
Red Hat Monitoring Satellite, ma possibilmente un Red Hat Satellite Proxy Server. Inserite una breve ed unica descrizione per il probe. - Selezionate la casella Notifiche Probe per poter ricevere le notifiche dopo il cambiamento dello stato di un probe. Utilizzate il menu a tendina Intervallo di controllo dei Probe, per determinare quando inviare le notifiche. Selezionando
1 minute(e la casella Notifica probe), riceverete le notifiche ogni minuto, ogni qualvolta probe supererà i suoi limiti CRITICAL o WARNING. Consultate la Sezione 1.2.4, «Come abilitare le notifiche» per creare i metodi di notifica e come accettare i relativi messaggi. - Utilizzate i campi Utente RHNMD e Porta RHNMD, se appaiono, per forzare probe a comunicare tramite
sshd, invece di utilizzare il Red Hat Network monitoring daemon. Per informazioni consultare la Sezione 1.2.2.2, «Come configurare SSH». In caso contrario accettate i valori di defaultnocpulsee4545. - Se appare il campo Timeout, ricontrollate i valori di default e regolateli in modo da far fronte alle vostre esigenze. La maggior parte dei timeout risultano in uno stato di UNKNOWN. Se le metriche dei probe sono basate su intervalli di tempo, assicuratevi che il timeout non risulti essere inferiore al tempo limite selezionato. In caso contrario, le metriche non avranno alcuno scopo, poichè il probe raggiungerà il tempo di scadenza prima di superare qualsiasi valore limite.
- Se applicabile utilizzate i campi restanti per stabilire i limiti di allerta di probe. I valori CRITICAL e WARNING determinano in quale punto probe ha modificato il suo stato. Per maggiori informazioni su questi limiti consultate la Sezione 1.2.5.2, «Come stabilire i limiti».
- Una volta terminata tale operazione fate clic su . Ricordate, è necessario confermare le modifiche apportate alla configurazione per il monitoring sulla pagina Scout Config Push.
Per cancellare un probe, navigate attraverso la sua pagina Stato attuale (facendo clic sul nome del probe presente sulla scheda → ), e fate clic su cancella probe. Per finire, confermare la rimozione.
1.2.5.2. Come stabilire i limiti
La maggior parte dei probe offerti da Red Hat Satellite contengono dei limiti di allerta che, una volta superati, indicano un cambiamento dello stato. Per esempio, il probe Linux::CPU Usage, vi permette d'impostare i limiti CRITICAL e WARNING per la quantità di CPU utilizzata. Se il sistema monitorato riporta 75 percento della CPU, ed il limite WARNING è stato impostato su 70, il probe entrerà in uno stato di WARNING. Alcuni probe offrono una certa varietà dei suddetti limiti.
Per poter ottenere il massimo dai vostri entitlement di monitoring e quindi evitare le notifiche false, Red Hat consiglia l'esecuzione dei probe senza alcuna notifica per un determinato periodo di tempo, in modo tale da stabilire una prestazione di base per ogni sistema. Anche se il valore di base offerto potrebbe risultare ideale, ogni organizzazione presenta un ambiente diverso che potrebbe richiedere una modifica dei suddetti limiti.
1.2.5.3. Monitoraggio del server di Satellite
In aggiunta al monitoring di tutti i sistemi client sarà possibile utilizzare Red Hat Network per controllare Satellite o Proxy. Per poter controllare il Satellite o il Proxy identificate un sistema controllato dal server e andate sulla scheda → .
Fate clic su crea nuovo probe e selezionate il Gruppo di comando del probe
Satellite. Successivamente completate i campi rimanenti. Per maggiori informazioni consultate la Sezione 1.2.5.1, «Gestione dei probes».
Anche se il Satellite o il Proxy appaiono essere controllati dal sistema client, probe verrà eseguito dal server stesso. I limti e le notifiche funzioneranno normalmente.
Nota
Qualsiasi probe che richiede un collegamento al Red Hat Network monitoring daemon non potrà essere utilizzato con un Red Hat Satellite o Red Hat Satellite Proxy Server sui quali il software per il Monitoring risulta essere in esecuzione. Ciò include numerosi probe nel gruppo di comandi di Linux, i probe del Log Agent e quelli del Remote Program. Utilizzate i probe del gruppo di comandi di Satellite per controllare Red Hat Satellite ed i Red Hat Satellite Proxy Server. Nel caso di Proxy scout, i probe vengono elencati sotto il sistema per il quale essi riportano i dati.
1.2.6. Monitoring
Se fate clic sulla scheda Monitoring nella barra superiore di navigazione, sarà possibile visualizzare i link insieme alla categoria Monitoring. Queste pagine, che richiedono il possesso degli entitlement di Monitoring, permettono di visualizzare i risultati dei probe impostati per sistemi con un entitlement di Monitoring e di gestirne la configurazione dell'infrastruttura.
Iniziate il processo di monitoraggio di un sistema attraverso la scheda Probe della pagina Informazioni del sistema. Consultate Appendice A, Probe per un elenco dei probe disponibili.
1.2.6.1. Stato di Probe
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Per impostazione predefinita la pagina Stato di probe verrà visualizzata se si seleziona Monitoring nella barra di navigazione superiore.
La pagina Stato di Probe visualizza un sommario del conteggio dei probes nei vari stati, e fornisce una interfaccia semplice in grado di rilevare velocemente i probe problematici. Da notare che il totale delle verifiche presente nelle tabelle della parte superiore della pagina, potrebbe non corrispondere al numero di probe visualizzato nelle tabelle inferiori. I conteggi situati nella parte superiore includono i probe per tutti i sistemi presenti nella vostra organizzazione, mentre le tabelle visualizzano i probe eseguiti solo sui sistemi ai quali avete accesso, attraverso il ruolo di System Group Administrator. Altresì il conteggio dei probe qui mostrato potrebbe essere sfasato di un massimo di un minuto.
Il seguente elenco descrive ogni stato ed identifica le icone ad essi associati:
- Critico - Il probe ha altrepassato il limite CRITICAL.
- Avvertenza - Il probe ha oltrepassato il limite di WARNING.
- Sconosciuto - Il probe non è in grado di eseguire un riporto accurato delle metriche o dei dati relativi allo stato.
- Sospeso - Il probe è stato programmato per una esecuzione ma non è stato ancora eseguito o non può essere eseguito.
- OK - Il probe è in esecuzione correttamente.
La pagina Stato di Probe contiene le tabelle per ogni stato insieme alla tabella in grado di elencare tutti i probe. Ogni tabella contiene delle colonne che indicano lo stato di probe, il sistema monitorato, i probe utilizzati, e la data ed ora dell'ultimo aggiornamento dello stato.
Facendo clic sul nome del sistema presente all'interno delle suddette schede verrete direzionati sulla scheda Monitoring della pagina Informazioni del sistema. Selezionando il nome desiderato potrete visualizzare la pagina Stato corrente. Da lì sarete in grado di modificare il probe, cancellarlo, e di generare i riporti basati sui propri risultati.
I dati del Monitoring e le informazioni sullo stato di probe precedentemente disponibili solo attraverso l'interfaccia web di Satellite, possono ora essere esportati come file CSV. Selezionate i link Scarica CSV su tutte le pagine relative al Monitoring, per scaricare i file CSV contenenti informazioni rilevanti. I dati esportati possono includere e non limitarsi a quanto segue:
- Stato di probe
- Tutti i probe in un particolare stato (OK, WARN, UNKNOWN, CRITICAL, PENDING)
- Una cronologia degli eventi di Probe
1.2.6.1.1. Stato di Probe ⇒ Critical
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
I probe che hanno superato i propri limiti CRITICAL, o che hanno raggiunto uno stato critico per altre ragioni. Per esempio alcuni probe entrano in uno stato critico (e non sconosciuto) quando superano il proprio periodo di timeout.
1.2.6.1.2. Stato di Probe ⇒ Warning
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
I probes che hanno oltrepassato i propri limiti di WARNING.
1.2.6.1.3. Stato di Probe ⇒ Unknown
Importante
Per visualizzare questa funzione è necessario avere un entitlement di Monitoring.
I Probe non sono in grado di raccogliere le metriche necessarie per determinare il loro stato. La maggior parte dei probe entrano in uno stato di unknown 'sconosciuto' quando oltrepassano il loro periodo di timeout. Ciò potrebbe significare che il limite di timeout deve essere aumentato, in caso contrario non sarà possibile eseguire il collegamento col sistema monitorato.
È possibile anche che i parametri di configurazione dei probes non siano corretti, e per questo motivo i propri dati non risultano essere reperibili. Per finire, il suddetto stato potrebbe indicare che si è verificato un errore al software.
1.2.6.1.4. Stato di Probe ⇒ Pending
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Informazioni riguardanti i probes non ricevute da Red Hat Network. Tale stato è indicativo di una verifica che risulta essere stata programmata, ma che non è stata ancora eseguita. Se tutte le verifiche sono in uno stato di In attesa, la vostra infrastruttura di monitoring potrebbe avere alcuni problemi.
1.2.6.1.5. Stato di Probe ⇒ OK
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
I probe eseguiti senza alcuna eccezione. Questo è lo stato desiderato per tutti i probe.
1.2.6.1.6. Stato di Probe ⇒ Tutti
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Tutti i probe programmati sui sistemi presenti nell'account, elencati in ordine alfabetico in base al nome del sistema.
1.2.6.1.7. Stato corrente
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Identifica lo stato della verifica selezionata e quando la stessa è stata eseguita per l'ultima volta, fornendo altresì la possibilità di generare un riporto sulla verifica. Anche se tale pagina fà parte del monitoring, essa risulta essere disponibile nella tabella Probes, all'intenro della pagina Informazioni del sistema, poichè la propria configurazione risulta essere specifica al sistema monitorato.
Per poter visualizzare un riporto su probe, selezionate una durata utilizzando i campi data, e scegliete se desiderate visualizzare dati metrici, la cronologia dei cambiamenti oppure entrambi i riporti. Per ottenere i dati metrici selezionate il tipo di metrica desiderata, e decidete (utilizzando le caselle) se i risultati devono essere visualizzati in modo grafico, tramite un log di errore o seguendo entrambi i metodi. Successivamente fate clic su nella parte inferiore della pagina. Se non esistono dati riguardanti le metriche di probe, verrà visualizzato un messaggio che indica: NO DATA SELECTED TIME PERIOD AND METRIC.
1.2.6.2. Notifica
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Identifica i metodi di contatto stabiliti per l'organizzazione. Questi metodi contengono gli indirizzi email o pager ideati per ricevere i messaggi d'allerta provenienti dai probe.
Qui sulla schermata di default Notifica, vengono elencati i metodi di notifica disponibili per la vostra organizzazione. I suddetti metodi vengono elencati a seconda del tipo di utente ad essi applicati.
Per creare un nuovo metodo di notifica fate clic sul nome dell'utente al quale applicare la notifica. A questo punto apparirà la pagina Informazioni Utente ⇒ Metodi di notifica. Fate clic sul titolo del metodo di notifica per modificarne le proprietà.
1.2.6.2.1. Notifica ⇒ Filtri
I filtri di notifica vi permettono di creare delle regole per un utilizzo duraturo, permettendovi di sospendere, ridirezionare, di essere a conoscenza automaticamente della presenza di notifiche standard, oppure di inviare notifiche supplementari. Il tutto vi assisterà nella gestione delle comunicazioni con probe frequenti o di tipo verbose.
1.2.6.2.1.1. Notifica ⇒ Filtri di notifica ⇒ Filtri attivi
Questa risulta essere la schermata di default per la tabella Filtri di notifica. Vengono elencati tutti i filtri attivi disponibili per la vostra organizzazione. Fate clic sul nome del filtro per modificarne le sue proprietà.
Per creare un filtro di notifica, fae clic sul link crea nuovo filtro di notifica nella parte alta sulla destra della schermata. Configurate ogni opzione e fate clic sul pulsante , per creare un nuovo filtro.
- Descrizione: Inserire un valore che vi permetta di distinguere il suddetto filtro dagli altri.
- Tipo: Determina il tipo di azione che il filtro deve intraprendere: ridireziona, accetta, sospende, o integra informazioni alla notifica in ingresso.
- Invia a: Le opzioni Ridireziona Notifica e Notifica Supplementare nella seconda fase, richiedono un indirizzo email al quale inviare le notifiche. Le opzioni restanti non necessitano di alcun indirizzo email.
- Scopo: Determina quale componente è soggetto all'zione del filtro.
- Organizzazione/Scout/Probe: Questa opzione vi permette di selezionare l'organizzazione, lo scout o il probe ai quali viene applicato il suddetto filtro. Per poter selezionare degli oggetti multipli da questo elenco, tenere premuto il tasto Ctrl mentre cliccate i nomi degli oggetti. Per poter selezionare una gamma di oggetti, tenere pigiato il tasto Shift mentre cliccate sul primo e sull'ultimo oggetto della gamma.
- Probe con Stato: Seleziona quale stato sia in relazione al filtro. Per esempio, potreste scegliere di creare una notifica supplementare solo per i probe con uno stato critical. Deselezionate ogni casella corrispondente agli stati che devono essere ignorati dal filtro.
- Notifiche inviate a : Questo è il metodo con il quale viene inviata la notifica se non viene eseguito alcun tipo di filtro. Per esempio potreste ridirezionare tutte le notifiche di un utente, se quest'ultimo risulta essere in vacanza, lasciando inalterate le altre notifiche provenienti dal probe.
- Corrispondi Output: Seleziona in modo preciso i risultati della notifica inserendo qui una espressione regolare. Se la sezione "Message:" della notifica non corrisponde alla espressione regolare, allora il filtro non viene applicato.
- Ricorrente: Selezionate se il filtro deve essere costantemente eseguito oppure eseguito in tempi prestabiliti. Un filtro ricorrente 'recurring filter' viene eseguito diverse volte in un periodo di tempo più piccolo, rispetto alla durata del filtro stesso. Per esempio, un filtro ricorrente può essere eseguito per 10 minuti ogni ora, tra l'inizio e la fine della durata del filtro in questione. Un filtro non ricorrente viene eseguito continuamente tra il tempo di inizio e quello di fine del filtro.
- Inizio: Inserire una data ed un orario di inizio delle operazioni da parte del filtro.
- Fine: Inserire una data ed un orario di fine operazioni del filtro.
- Recurring Duration: La durata entro la quale il filtro risulta attivo. Questo campo, applicabile solo ai filtri ricorrenti, avrà luogo al momento dell'inizio sopra pecificato. Qualsiasi notifica generata all'esterno della durata specificata, non verrà filtrata.
- Recurring Frequency: La frequenza con la quale viene attivato il filtro.
I filtri di notifica non possono essere cancellati. Tuttavia un filtro può essere cancellato impostando la data di fine attività nel passato. (Da notare che la data di fine attività del filtro, deve essere uguale o successiva alla data di inizio, altrimenti la modifica desiderata fallirà.) Un altro metodo è quello di selezionare un set di filtri dalla pagina Attivi e fare clic sul pulsante . Così facendo il filtro verrà cancellato, visualizzando la tabella Filtri scaduti.
1.2.6.2.1.2. Notifica ⇒ Filtri di Notifica ⇒ Filtri Scaduti
Questa tabella elenca tutti i filtri di notifica scaduti. I suddetti filtri vengono conservati in modo indefinito; tale processo di conservazione permette alle organizzazioni di reciclare i filtri più utili in base alle proprie esigenze, fornendo altresì una cronologia per eventuali operazioni di troubleshooting.
1.2.6.3. Suite di Probe
Le Suite di Probe vi permettono di configurare ed applicare uno o più probe ad uno o più sistemi. Esse possono essere configurate una sola volta, e poi applicate a qualsiasi gruppo di sistemi. Tale processo permette di risparmiare tempo e conferisce una certa continuità per il Monitoring dei clienti.
Per creare e applicare una Suite di Probe, create prima una Suite di Probe vuota, successivamente configurate i probe da essa contenuti, e per finire applicate la Suite sui sistemi selezionati.
- Dal Monitoring ⇒ pagina Suite di Probe, selezionare il link crea suite di probe. Inserire un nome facilmente distinguibile per la Suite di Probe. Potreste scegliere di aggiungere una breve descrizione della Suite. Per continuare fate clic su
- Aggiungere e configurare i probe che compongono la suite. Fate clic sul link crea nuovo probe in alto a destra.
- Configurate il probe e fate clic sul pulsante in basso a destra. Ripetere questo processo fino a quando sono stati aggiunti tutti i probe desiderati.
Nota
Sendmail deve essere configurato in modo corretto sul Red Hat Satellite e su ogni sistema client sul quale la suite di probe verrà applicata, installare il demonerhnmdil quale deve essere in esecuzione. Per informazioni aggiuntive consultate la Red Hat Satellite Installation Guide - Sulla scheda "Sistemi" aggiungere i sistemi sui quali viene applicata la Suite di Probe. Per continuare fate clic sul link aggiungi sistemi alla suite di probe, nella parte alta a destra della schermata.
- La pagina successiva visualizza un elenco di tutti i sistemi con gli entitlement di Monitoring. Selezionate le caselle corrispondenti ai sistemi sui quali desiderate applicare la Suite di Probe ed il monitoring scout da utilizzare, e successivamente fate clic sul pulsante per completare la creazione della Suite di Probe.
Potete cancellare o scollegare i probe dalla suite. Scollegando un probe, verranno dissociati i probe dalla suite, convertendoli in probe specifici al sistema per il sistema specificato. Ciò significa che le modifiche ai probe scollegati, influenzeranno solo il sistema interessato. Cancellando un probe, rimuoverete il probe stesso dalla Suite di ogni sistema.
Per rimuovere i probe dalla Suite di Probe:
- Dal Monitoring ⇒ pagina Suite di Probe, fate clic sul titolo della Suite di Probe che desiderate alterare.
- Selezionate la sottotabella Probe.
- Selezionate la casella corrispondente al probe che desiderate rimuovere.
- Fate clic sul pulsante
È possibile altresì rimuovere un sistema dalla Suite di Probe. A tale scopo sono disponibili due modalità. La prima è quella di separare il sistema dalla Suite di Probe. Quando eseguite questa procedura il sistema avrà ancora gli stessi probe ad esso assegnati. Tuttavia, ora avrete la possibilità di configurare questi probe individualmente senza influenzare altri sistemi.
Per scollegare un sistema dalla suite:
- Dal Monitoring ⇒ pagina Suite di Probe, fate clic sul titolo della Suite di Probe che desiderate alterare.
- Selezionate la sottotabella Sistemi.
- Selezionate la casella corrispondente ai sistemi che desiderate rimuovere dalla Suite di Probe.
- Fate clic sul pulsante
Il secondo metodo è quello di rimuovere il sistema dalla suite. Tale procedura rimuove il sistema dalla suite stessa, e cancella tutti i probe in esecuzione dal sistema.
Nota
La suddetta azione cancella tutti i probe della Suite di Probe dal sistema insieme alla cronologia Time Series e ai dati di Event Log. Tale azione risulta essere irreversibile.
Per rimuovere un sistema dalla Suite di Probe e cancellare tutti i probe associati dal sistema:
- Dal Monitoring ⇒ pagina Suite di Probe, fate clic sul titolo della Suite di Probe che desiderate alterare.
- Selezionate la sottotabella Sistemi.
- Selezionate la casella corrispondente ai sistemi che desiderate rimuovere dalla Suite di Probe.
- Fate clic sul pulsante
E per finire, come con i Probe singoli, è possibile scaricare un file CSV contenente informazioni sulle Suite di Probe. Selezionate il link Scarica CSV nella parte bassa della pagina Monitoring ⇒ Suite di Probe, per scaricare il file.
1.2.6.4. Scout Config Push
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Facendo clic sul nome del server aprirete la chiave pubblica SSH del Red Hat Network Monitoring Daemon corrispondente. Ciò permetterà di copiare ed incollare la chiave SSH sui sistemi controllati dallo scout. Tale processo è necessario per eseguire il collegamento del demone Red Hat Network Monitoring Daemo sul Satellite.
1.2.6.5. Configurazione Monitoring generale
Importante
Per visualizzare questa scheda è necessario avere un entitlement di Monitoring.
Generalmente i valori di default forniti con gli altri campi sono accettabili, poichè essi derivano dalla vostra installazione di Satellite. Tuttavia, potete utilizzare i campi presenti in questa pagina, per alterare la vostra configurazione di Monitoring. Per esempio, qui sarete in grado di modificare il server di scambio posta. Questa pagina permette altresì di alterare la destinazione di tutte le email amministrative provenienti da Satellite. Una volta terminato, fate clic su .
1.3. Satellite multipli
Inter-Satellite Synchronization (ISS) permette a Satellite di sincronizzare il contenuto ed i permessi da un'altra istanza di Satellite in un rapporto peer-to-peer. Tuttavia nella seguente sezione il Satellite che riceve un contenuto verrà classificato come "Satellite Slave" ed il Satellite che si comporta come sorgente dal quale viene generato il contenuto verrà chiamato "Satellite Master". Se utilizzate ISS per sincronizzare il contenuto, l'istanza del Satellite Slave potrà avere una impostazione diversa da quella del Master per entità non-content, come ad esempio Utenti e Organizzazioni. L'Amministratore Satellite sull'istanza Slave è libero di aggiungere, rimuovere e modificare le identità in modo indipendente rispetto all'istanza Master.
Nota
Master e Slave sono termini che presentano connotazioni non imposte dal protocollo ISS. Ricordate il loro significato, come sopra riportato, durante la consultazione di questa sezione.
È possibile utilizzare la funzione ISS in diversi modi a seconda delle necessità dell'organizzazione. Sono presenti configurazioni ISS dove due Satellite possono comportarsi entrambi come Master e Slave di entrambi. Questa sezione contiene alcuni esempi sul modo di utilizzo e sull'impostazione ottimale dell'ISS per soddisfare i requisiti dell'organizzazione.
Requisiti ISS
Di seguito sono riportati i requisiti per poter utilizzare ISS:
- Due o più server Red Hat Satellite
- Un minimo di un Red Hat Satellite popolato con almeno un canale
- Privilegi per l'Amministratore SAtellite su tutti i sistemi Satellite da usare con ISS
1.3.1. Sincronizzazione Inter-Satellite
ISS può essere configurato manualmente o usando un nuovo toll chiamato
spacewalk-sync-setup. Entrambi i metodi sono idonei e disponibili all'utente.
1.3.1.1. Configurazione manuale
Procedura 1.1. Configurazione del server Satellite master
Con Satellite 5.6, ISS permette al Satellite Slave di duplicare la gerarchia fidata dell'organizzazione e i permessi del canale personalizzato tramite le impostazioni configurate sul master. Per fare questo esportare le informazioni relative alle organizzazioni specifiche dal Satellite Master a quello Slave di destinazione. L'Amministratore Satellite per lo Slave può successivamente mappare le Organizzazioni Master su Organizzazioni Slave specifiche. Operazioni future di
satellite-sync utilizzano queste informazioni per assegnare una proprietà del canale personalizzato all'Organizzazione Slave mappata ad una Organizzazione Master specifica. È possibile mappare anche il rapporto fidato tra l'Organizzazione Master esposta con le Organizzazione Slave corrispondenti, creando i rapporti equivalenti sullo Slave.
- Sull'interfaccia web:
- Registratevi come Amministratore Satellite.
- Selezionare → → .
- Nell'angolo alto sulla destra della schermata selezionare .
- Inserire le seguenti informazioni:
- Slave Fully Qualified Domain Name (FQDN)
- Permetti allo Slave di eseguire la Sincronizzazione? - Selezionando questo campo permetterete al Satellite Slave di accedere a questo Satellite Master. In caso contrario il contatto con questo Slave verrà negato.
- Sincronizza tutte le organizzazioni con lo Slave? - Selezionando questo campo sincronizzerete tutte le organizzazioni con il Satellite Slave.
Nota
Selezionando Sincronizza tutte le organizzazioni con lo Slave? sulla pagina di Impostazione del Master, sovrascriverete qualsiasi organizzazione selezionata specifica nella tabella Organizzazione locale. - Selezionare .
- (Facoltativa) Eseguire la selezione su qualsiasi organizzazione locale da esportare sul Satellite slave.
- Selezionare .
Nota
Con Satellite 5.5, il Satellite Master utilizzava il parametroiss_slavesnel file/etc/rhn/rhn.confper identificare lo slave in grado di contattare il Satellite Master. Satellite 5.6 utilizza le informazioni presenti nella pagina di impostazione del Master per determinare queste informazioni.
- Sulla linea di comando:
- Abilitare la funzione inter-satellite synchronization (ISS) nel file
/etc/rhn/rhn.conf:disable_iss=0
- Salvare il file di configurazione e riavviare il servizio
httpd:service httpd restart
Procedura 1.2. Configurazione dei server slave
I server satellite slave sono macchine che ricevono un contenuto sincronizzato dal server master.
- Per trasferire in modo sicuro il contenuto ai server slave sarà necessario avere il certificato
ORG-SSLdel server master. Tale certificato può essere scaricato attraverso HTTP dalla directory/pub/di qualsiasi Satellite. Il file viene chiamatoRHN-ORG-TRUSTED-SSL-CERTma può essere rinominato e posizionato in qualsiasi posizione sul filesystem locale dello slave, come ad esempio sulla directory/usr/share/rhn/. - Registratevi nel Satellite Slave come Amministratore Satellite.
- Selezionare → → .
- Nell'angolo alto sulla destra della schermata selezionare .
- Inserire le seguenti informazioni:
- Master Fully-Qualified Domain Name
- Master predefinito?
- Nome del file di questo certificato CA del Master - Usare il percorso completo del certificato CA scaricato nella fase iniziale di questa procedura.
- Selezionare .
Procedura 1.3. Esecuzione di Inter-Satellite Synchronization
Una volta configurati i server slave e master sarà possibile eseguire una sincronizzazione.
- Iniziare la sincronizzazione eseguendo il comando
satellite-sync:satellite-sync -c your-channel
Nota
Qualsiasi opzione della linea di comando per il comandosatellite-syncsovrascriverà qualsiasi impostazione predefinita o personalizzata nel file/etc/rhn/rhn.conf.
Procedura 1.4. Mappatura delle Organizzazioni esportate del Satellite master sulle organizzazioni del Satellite slave
Prerequisiti
Dopo aver seguito le procedure precedenti a quest'ultima, il Satellite master dovrebbe essere disponibile all'interno delle impostazioni di Satellite Slave in → → . In caso contrario ricontrollate le fasi sopra riportate.
Una mappatura dei nomi dell'organizzazione sul Satellite Master permette di impostare i permessi di accesso del canale sul Satellite master. Successivamente essi verranno inoltrati quando il contenuto risulta essere sincronizzato sul Satellite slave. Non è necessario mappare tutte le informazioni del canale e dell'organizzazione per tutti i Satellite slave, gli amministratori Satellite possono selezionare i permessi e le organizzazioni da sincronizzare abilitando o omettendo le mappature.
Per completare la mappatura seguire questa procedura sul Satellite slave:
- Registratevi come Amministratore Satellite.
- Selezionare → → .
- Selezionare un Satellite Master facendo clic sul nome corrispondente.
- Usare la casella a tendina per mappare il nome dell'organizzazione master esportato su una orgaizzazione locale corrispondente nel Satellite slave.
- Selezionare .
- Sulla linea di comando emettere
satellite-syncsu ogni canale personalizzato per ottenere la struttura corretta ed i permessi del canale:satellite-sync -c your-channel
1.3.1.2. Configurazione automatizzata
spacewalk-sync-setup permette agli utenti di specificare una istanza del Satellite slave e master e utilizzare i file di configurazione per impostare le informazioni descritte nelle impostazioni per lo Slave e Master. Se necessario così facendo verrà creato un insieme di file di configurazione predefiniti. Questo processo automatizza la configurazione mappata e l'impostazione precedente per i rapporti tra Master e Slave.
Prerequisiti
Per un corretto funzionamento della configurazione automatizzata:
- È necessario installare il pacchetto spacewalk-util sul sistema che emetterà il comando
spacewalk-sync-setup. - È necessaria la presenza di organizzazioni esistenti con permessi personalizzati sul Satellite master.
- È necessaria la presenza di organizzazioni esistenti all'interno del Satellite slave.
Procedura 1.5. Configurazione del server Satellite master
- Abilitare la funzione inter-satellite synchronization (ISS) nel file
/etc/rhn/rhn.conf:disable_iss=0
- Salvare il file di configurazione e riavviare il servizio
httpd:service httpd restart
Procedura 1.6. Configurazione dei server slave
I server satellite slave sono macchine con un contenuto sincronizzato con il server master.
- Per trasferire in modo sicuro il contenuto ai server slave sarà necessario avere il certificato
ORG-SSLdel server master. Tale certificato può essere scaricato attraverso HTTP dalla directory/pub/di qualsiasi Satellite. Il file viene chiamatoRHN-ORG-TRUSTED-SSL-CERTma può essere rinominato e posizionato in qualsiasi posizione sul filesystem locale dello slave, come ad esempio sulla directory/usr/share/rhn/. - Registratevi nel Satellite Slave come Amministratore Satellite.
- Selezionare → → .
- Nell'angolo alto sulla destra della schermata selezionare .
- Inserire le seguenti informazioni:
- Master Fully-Qualified Domain Name
- Master predefinito?
- Nome del file di questo certificato CA del Master - Usare il percorso completo del certificato CA scaricato nella fase iniziale di questa procedura.
- Selezionare .
Procedura 1.7. Mappare le Organizzazioni del Satellite master sulle organizzazioni del Satellite slave usando spacewalk-sync-setup
- Eseguire una registrazione su un sistema. Per questo processo non è importante se il sistema appartenga ad un Satellite master, Satellite slave o un sistema diverso, è importante che il sistema sia in grado di accedere l'API XMLRPC pubblica dei Satellite slave o master.
- Emettere
spacewalk-sync-setupsull'interfaccia a linea di comando:spacewalk-sync-setup --ms=[Master_FQDN] \ --ml=[Master_Sat_Admin_login] \ --mp=[Master_Sat_Admin_password] \ --ss=[Slave FQDN] --sl=[Slave_Sat_Admin_login] \ --sp=[Slave_Sat_Admin_password> \ --create-templates --apply
Dove:- --ms=MASTER, --master-server=MASTER è il FQDN del Master al quale collegarsi
- --ml=MASTER_LOGIN, --master-login=MASTER_LOGIN è il lofin dell'amministratore Satellite per il Satellite Master
- --mp=MASTER_PASSWORD, --master-password=MASTER_PASSWORD è la password per il login dell'Amministrtore Satellite sul Satellite Master
- --ss=SLAVE, --slave-server=SLAVE è il FQDN del Satellite Slave al quale collegarsi.
- --sl=SLAVE_LOGIN, --slave-login=SLAVE_LOGIN è il login dell'Amministratore satellite per Satellite slave
- --sp=SLAVE_PASSWORD, --slave-password=SLAVE_PASSWORD è la password per il login dell'Aaamministrtore satellite sul Satellite slave
- --ct, --create-templates è l'opzione usata per creare il file di impostazione sia per lo slave che per il master, per la coppia master/slave indicata
- --apply indica alle istanze di Satellite di eseguire le modifiche specificate dai file di impostazione sulle istanze Satellite specificate
Nota
Per ulteriori opzioni di impostazione:spacewalk-sync-setup --help
L'output di questo comando sarà il seguente:INFO: Connecting to [admin@master-fqdn] INFO: Connecting to [admin@slave-fqdn] INFO: Generating master-setup file $HOME/.spacewalk-sync-setup/master.txt INFO: Generating slave-setup file $HOME/.spacewalk-sync-setup/slave.txt INFO: Applying master-setup $HOME/.spacewalk-sync-setup/master.txt INFO: Applying slave-setup $HOME/.spacewalk-sync-setup/slave.txt
- Sulla linea di comando emettere
satellite-syncsu ogni canale personalizzato per ottenere la struttura corretta ed i permessi del canale:satellite-sync -c your-channel
1.3.2. Sincronizzazione per organizzazione
Inter-Satellite Synchronization può essere usato anche per importare il contenuto su qualsiasi organizzazione specifica. Questo processo può essere eseguito localmente o usando una sincronizzazione remota. Questa funzione è utile per un satellite di tipo scollegato con organizzazioni multiple, dove il contenuto è ripristinato attraverso i dump del canale o tramite una esportazione dai satellite collegati e successivamente importandolo sui satellite scollegati. È possibile usare una sincronizzazione delle organizzazioni per esportare i canali personalizzati da satellite collegati. La stessa sincronizzazione può essere usata per spostare il contenuto tra organizzazione multiple.
La sincronizzazione per organizzazione presenta alcune regole per mantenere l'integrità dell'organizzazione sorgente:
- Se il contenuto sorgente appartiene all'organizzazione
NULL(qualsiasi contenuto Red Hat) verrà eseguito il default sull'organizzazioneNULLanche se si specifica una organizzazione di destinazione. Tale approccio assicura che il contenuto specificato sia sempre nella organizzazioneNULLprivilegiata. - Se si specifica una organizzazione sulla linea di comando il contenuto verrà importato da quella organizzazione.
- Se non è stata specificata alcuna organizzazione il default sarà org 1.
Di seguito sono disponibili tre scenari d'esempio dove vengono usati gli ID delle organizzazioni (
orgid) per la sincronizzazione tra Satellite:
Esempio 1.1. Come importare il contenuto da un satellite master ad uno slave
In questo esempio il contenuto viene importato da un satellite master ad uno slave:
satellite-sync --parent-sat=master.satellite.example.com -c channel-name --orgid=2
Esempio 1.2. Come importare il contenuto da un dump esportato di una organizzazione
In questo esempio il contenuto viene importato da un dump esportato di una organizzazione specifica:
$ satellite-sync -m /dump -c channel-name --orgid=2
Esempio 1.3. Importazione del contenuto da un Red Hat Network Hosted
In questo esempio il contenuto viene importato da un Red Hat Network Hosted (assumendo che il sistema sia stato registrato ed attivato):
$ satellite-sync -c channel-name
1.3.3. Casi di utilizzo dell'Inter-Satellite Synchronization
È possibile utilizzare nter-Satellite Synchronization (ISS) in diversi modi in base ai requisiti dell'organizzazione. Questa sezione fornisce gli esempi su come utilizzare ISS insieme ai metodi per l'impostazione ed il funzionamento relativo.
Esempio 1.4. Staging Satellite
Nel seguente esempio viene usato il satellite di staging per preparare il contenuto ed eseguire il quality assurance (QA) sui pacchetti per assicurare l'idoneità dei pacchetti stessi ad un uso di produzione. Dopo l'approvazione del contenuto il Production Satellite sincronizzerà il contenuto proveniente dal Satellite di staging.
- Eseguire il comando
satellite-syncper sincronizzare i dati con rhn_parent (generalmente Red Hat Network Hosted Hosted):satellite-sync -c your-channel
- Eseguire il seguente comando per sincronizzare i dati dal server di stage:
satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel
Esempio 1.5. Slave sincronizzati
In questo esempio Satellite master fornisce i dati direttamente agli slave e le modifiche regolarmente sincronizzate.
Esempio 1.6. Contenuto personalizzato degli slave
In questo esempio il Satellite master è il canale di sviluppo dal quale viene distribuito il contenuto su tutti i Satellite slave di produzione. Alcuni slave presentano un contenuto aggiuntivo il quale non è presente nei canali Satellite master. I suddetti pacchetti vengono preservati ma tutti i cambiamenti del Satellite master sono sincronizzati con il Satellite slave.
Esempio 1.7. Sincronizzazione bidirezionale
In questo ambiente due server di Red Hat Satellite si comportano sia come master che come slave di entrambi, e sono in grado di sincronizzare il rispettivo contenuto. Il server di Satellite sul quale viene eseguito il comando
satellite-sync estrarrà il contenuto dall'altro server Satellite, e i dati sincronizzati dipenderanno dalle opzioni eseguite con satellite-sync. Senza alcuna opzione la sincronizzazione cercherà di aggiornare qualsiasi dato precedentemente sincronizzato.
Consultare Sezione 1.3.1.1, «Configurazione manuale» per la configurazione del Satellite Master. La configurazione di entrambi i server Satellite come Master creerà una sincronizzazione bidirezionale.
Capitolo 2. Informazioni specifiche al Red Hat Satellite e Solaris
Questa sezione fa riferimento all'uso di Red Hat Satellite con sistemi Solaris.
2.1. UNIX Support Guide
2.1.1. Introduzione
Questo capitolo documenta la procedura di installazione per, ed identifica le differenze in, la funzionalità di Red Hat Network se usato per la gestione dei sistemi client basati su UNIX. Red Hat Network offre un support UNIX per assistere alla migrazione di utenti da UNIX a Linux. A causa dello scopo limitato di questo compito, le funzioni offerte per la gestione del client UNIX non sono complete come quelle disponibili per la gestione dei sistemi Red Hat Enterprise Linux.
Le sezioni seguenti riportano le varianti UNIX supportate, le funzioni di Red Hat Network supportate dal sistema di gestione UNIX, i prerequisiti per la gestione di un sistema UNIX con Red Hat Network e la procedura di installazione per i client UNIX.
2.1.1.1. Varianti di UNIX supportate
Le seguenti varianti UNIX, versioni e architetture sono supportate da Red Hat Satellite:
Tabella 2.1. Versioni ed architetture di Solaris supportate:
| Versioni di Solaris | sun4m | sun4d | sun4u | sun4v | sun4us | x86 |
|---|---|---|---|---|---|---|
| Solaris 8 | si | no | si | n/a | no | no |
| Solaris 9 | si | n/a | si | n/a | no | si |
| Solaris 10 | n/a | n/a | si | si | no | si |
2.1.1.2. Prerequisiti
Di seguito vengono riportati i requisiti per il supporto UNIX:
- Red Hat Satellite 5.0 o versione più recente
- Un certificato Satellite con entitlement di Management
- Entitlement di Management per ogni client di UNIX
- Pacchetti di Red Hat Network per UNIX incluso python, pyOpenSSL, ed i pacchetti Red Hat Network Client
- Pacchetti Sunfreeware che forniscono le librerie di supporto
Nota
Alcuni di questi pacchetti sono disponibili tramite il Red Hat Satellite. Consultare Sezione 2.1.3.1, «Scaricare ed installare i pacchetti aggiuntivi» per un elenco completo.
2.1.1.3. Caratteristiche incluse
Le seguenti caratteristiche sono state incluse con UNIX support service level agreement come riportate all'interno di Red Hat Network:
- Il Red Hat Network Service Daemon (
rhnsd), il quale aziona ilrhn_checkin base ad un intervallo configurabile - Il Red Hat Network Configuration Client (
rhncfg-client), il quale esegue tutte le azioni di configurazione programmate dal Satellite - Red Hat Network Configuration Manager (
rhncfg-manager), il quale permette una amministrazione tramite una linea di comando dei canali di configurazione di Red Hat Network - Il programma
rhn_check, il quale esegue il check in con Satellite, ed esegue qualsiasi azione programmata dal server - Tutte le funzionalità Management-level, come ad esempio il grouping, il confronto del profilo del pachetto, e l'utilizzo del System Set Manager in modo da amministrare contemporaneamente i sistemi multipli
- Una caratteristica di Provisioning chiamata Comando Remoto, che permette agli utenti di programmare dei comandi root-level, su qualsiasi client gestito attraverso il sito web di Satellite, sempre se il client sia stato configurato in modo da abilitare la suddetta azione.
2.1.1.4. Differenze di funzionalità
Le seguenti funzioni di Red Hat Network operano in modo diverso in un ambiente UNIX:
- Red Hat Update Agent per UNIX offre un set più piccolo di opzioni rispetto alla sua controparte di Linux, e si affida al toolset nativo del sistema operativo per l'installazione dei pachetti, invece di
rpm- Per un elenco preciso di opzioni consultate la Sezione 2.1.4.2.4, «Aggiornamento attraverso la linea di comando». - L'applicazione Red Hat Network Push è stata modificata in modo simile per il caricamento dei tipi di file UNIX nativi, incluso i pacchetti, patch e cluster di patch.Dal pacchetto Solaris, il patch ed i patch cluster file risultano essere diversi dai file rpm, il meccanismo per il caricamento del canale risulta essere differente. Per Solaris sono presenti due applicazioni nel pacchetto
rhnpush:- Il primo,
solaris2mpm, è una utilità di Red Hat Network in grado di creare un file MPM per ogni patch o pacchetto Solaris. Il formato neutrale del file MPM permette a Satellite di comprendere e gestire i file caricati. - Il secondo,
rhnpush, è stato esteso in modo da poter gestire MOM insieme ai file RPM. In caso contrario esso opera in modo identico alla versione Linux dirhnpush.
- La scheda Canali del sito web di Red Hat Network è stata estesa per ospitare l'archiviazione e l'installazione dei file UNIX nativi.
2.1.1.5. Funzionalità escluse
Le seguenti funzioni di Red Hat Network non sono disponibili con il sistema di supporto UNIX:
- Tutte le funzionalità del Provisioning-level, come ad esempio il kickstarting ed il rollback del pacchetto, con l'eccezione della gestione del file di configurazione
- Tutte le opzioni relative all'Errata, poichè in UNIX il concetto di Aggiornamenti Errata non viene compreso
- File sorgenti per i pacchetti
I file Answer non sono supportati. Il supporto per i suddetti file è programmato per una release futura.
Non vi è alcun supporto per IPV6 per sistemi Solaris.
Altresì non è supportato il riposizionamento dei file
RHAT*.pkg durante l'installazione.
2.1.2. Preparazione/Configurazione del Satellite Server
È necessario configurare Satellite per poter supportare i client UNIX, prima che i file necessari risultino essere disponibili all'impiego da parte dei sistemi client. Tale processo può essere eseguito seguendo le modalità riportate a seconda se avete installato il server di Satellite:
- Durante l'installazione di Satellite:Abilitate il supporto UNIX su Satellite selezionando la casella "Abilita Supporto Solaris" durante il processo di installazione, come di seguito mostrato:
Figura 2.1. Abilitazione del supporto UNIX durante l'installazione di Satellite
- Dopo aver installato Satellite:Abilitate il supporto UNIX configurando Satellite dopo la sua installazione. Per fare questo, selezionate nella barra del menù superiore, e successivamente selezionate sulla barra di navigazione sinistra. Nella schermata seguente selezionate la casella Abilita Supporto Solaris, come di seguito indicato:
Figura 2.2. Abilitazione del supporto UNIX dopo l'installazione di Satellite
Fate clic sul pulsante per confermare le modifiche. - Per finire, creare un canale di base al quale il sistema client può essere sottoscritto, questo poichè Red Hat Network non fornisce alcun contenuto UNIX; come risultato, non sarà possibile utilizzare
satellite-syncper creare il canale desiderato.Per creare un canale Solaris eseguite il login sull'interfaccia web di Satellite come Amministratore di Satellite o come certificate authority. Andate sulla scheda Canale, e successivamente da Gestisci canali software della barra di navigazione di sinistra. Fate clic sul link crea nuovo canale nella parte alta sulla destra della schermata risultante. Fornite un nome e l'etichetta per il vostro nuovo canale, e successivamente selezionate SPARC Solaris o i386 Solaris in base all'architettura del client.
2.1.3. Preparazione del Sistema Client di Unix
Prima che i sistemi client basati su UNIX siano in grado di usufruire dei vantaggi offerti da Red Hat Network, gli stessi devono essere pronti al collegamento:
- Scaricate ed installate
gzipinsieme alle librerie third-party necessarie. - Scaricate la Red Hat Network application tarball dal Satellite sul client, installandone i contenuti.
- Successivamente implementate i certificati SSL necessari per un collegamento sicuro.
- Configurate le applicazioni client da collegare al Red Hat Satellite.
Una volta terminato i sistemi saranno pronti a ricevere gli aggiornamenti di Red Hat Network. Le seguenti sezioni affrontano in dettaglio queste fasi.
2.1.3.1. Scaricare ed installare i pacchetti aggiuntivi
Questa sezione vi guiderà attraverso il processo di download e installazione di applicazioni third-party e delle applicazioni Red Hat Network dal Satellite su client UNIX.
Di primaria importanza è il Red Hat Update Agent per UNIX (
up2date), il quale fornisce un link tra i vostri sistemi client e Red Hat Network. La versione specifica a UNIX del Red Hat Update Agent risulta essere limitata in funzionalità rispetto alla propria controparte di Linux, ma è in grado di permettere una registrazione del sistema e di facilitare le installazioni del pacchetto e dei patch. Consultate la Sezione 2.1.4, «Registrazione e aggiornamenti del client Unix» per una descrizione dettagliata delle opzioni del tool.
Nota
Al momento della registrazione all'interno del client Solaris è consigliato inserire il comando
bash. Se la shell BASH risulta disponibile, verrà conferito al sistema un comportamento molto simile a quello di Linux.
2.1.3.1.1. Installazione dei pacchetti Third-Party
L'installazione delle applicazioni Red Hat Network non può procedere se non sono presenti le seguenti utilità e librerie:
gziplibgccopensslzlib
L'utilità
gzip viene fornita dal pacchetto SUNW gzip e può essere scaricata tramite http://www.sunfreeware.com.
Sulle versioni recenti di Solaris, le librerie necessarie vengono fornite dai seguenti pacchetti nativi installati:
SUNWgccruntimeSUNWopenssl*SUNWzlib
Per versioni più vecchie di Solaris è possibile scaricare i seguenti pacchetti tramite http://www.sunfreeware.com:
SMClibgccoSMCgccSMCosslSMCzlib
Utilizzate il comando
pkginfo per verificare se un pacchetto sia stato installato sul client. Per esempio, per la ricerca di un pacchetto che contenga all'interno del suo nome "zlib", eseguite il comando di seguito riportato:
# pkginfo | grep zlib
Nota
I nomi dell'archivio del pacchetto di Solaris differiscono dal nome del pacchetto installato. Per esempio, l'archivio del pacchetto
libgcc<version>-sol<solaris-version>-sparc-local.gz diviene SMClibgcc dopo l'installazione
2.1.3.1.2. Configurazione percorso di ricerca della libreria
Per abilitare l'utilizzo delle librerie installate durante la fase precedente da parte di Solaris, è necessario aggiungere la loro posizione all'interno del percorso di ricerca della libreria. Per fare questo controllate prima il percorso corrente di ricerca della libreria:
# crle -c /var/ld/ld.config
Prendete nota del Percorso corrente della libreria di ricerca. Successivamente modificate il percorso in modo da includere anche i componenti mostrati qui di seguito. Da notare che l'opzione
-l resetta il valore invece di aggiungerlo, quindi se sono stati precedentemente impostati alcuni valori all'interno del vostro sistema, aggiungeteli al parametro -l.
Su sparc:
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib
Su x86:
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib:/usr/sfw/lib
2.1.3.1.3. Come scaricare i pacchetti del client di Red Hat Network
Scaricate il tarball appropriato dei pacchetti dalla directory
/var/www/html/pub/ del vostro Satellite. Se siete in grado di utilizzare un GUI web browser come Mozilla, andate sulla directory /pub di Satellite, e salvate il tarball appropriato sul vostro client:
http://your-satellite.example.com/pub/rhn-solaris-bootstrap-<version>-<solaris-arch>-<solaris-version>.tar.gz
Se è necessario scaricare il tarball dalla linea di comando, allora potreste utilizzare
ftp per trasferire il file dal Satellite al client.
Utilizzando
gzip sarete in grado di decomprimere il tarball. In tal senso i seguenti pacchetti dovrebbero essere presenti:
RHATposslRHATrhnrcfgRHATrhnrcfgaRHATrhnrcfgcRHATrhnrcfgmRHATrhncRHATrhnlRHATrpushRHATsmart
SMClibgcc e SMCosslg possono essere inclusi all'interno del tarball.
2.1.3.1.4. Installazione dei pacchetti di Red Hat Network
Dalla directory non compressa utilizzate il tool d'installazione nativo della variante UNIX in modo da installare ogni pacchetto. Per esempio su Solaris utilizzate il comando
pkgadd. Rispondete "si" ad ogni prompt durante l'installazione del pacchetto.
Ecco come potrebbe procedere una installazione tipo:
# pkgadd -d RHATpossl-0.6-1.p24.6.pkg all # pkgadd -d RHATpythn-2.4.1-2.rhn.4.sol9.pkg all # pkgadd -d RHATrhnl-1.8-7.p23.pkg all ...
Nota
È possibile utilizzare
-n di pkgadd, per eseguire il comando in modalità non-interattiva. Tuttavia ciò potrebbe causare il fallimento 'silenzioso' durante l'installazione di alcuni pacchetti su Solaris 10.
Continuate fino a quando ogni pacchetto è stato installato all'interno del percorso specifico di Red Hat Network:
/opt/redhat/rhn/solaris/.
2.1.3.1.5. Includere i pacchetti di Red Hat Network nel PATH
Aggiungete al PATH i pacchetti in modo da renderli disponibili ad ogni login. Per fare questo aggiungete i seguenti comandi allo script di login:
# PATH=$PATH:/opt/redhat/rhn/solaris/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin # export PATH
Per abilitare l'accesso alle pagine man del comando del client di Red Hat Network aggiungetele al MANPATH. Per fare questo aggiungete i seguenti comandi allo script di login:
# MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man # export MANPATH
Alternativamente è possibile accedere alle pagine man direttamente dalla linea di comando tramite il seguente comando:
# man -M /opt/redhat/rhn/solaris/man <man page>
Per finire, aggiungere le librerie di Red Hat al vostro PATH come fatto in precedenza con
libgcc, openssl e zlib.
crle -c /var/ld/ld.config -l <current library paths>:/opt/redhat/rhn/solaris/lib
2.1.3.2. Implementazione certificati SSL del client
Per avere un trasferimento sicuro dei dati, Red Hat consiglia vivamente l'utilizzo di SSL. Red Hat Satellite è in grado di facilitare l'implementazione SSL attraverso la generazione dei certificati necessari durante la propria installazione. Il certificato rigurdante il server viene installato automaticamente sullo stesso Satellite, mentre il certificato client viene posto nella directory
/pub/ del Web server di Satellite.
Per installare il certificato seguite le fasi di seguito riportate per ogni client:
- Scaricate il certificato SSL dalla directory
/var/www/html/pub/di Red Hat Satellite sul sistema client. Il certificato verrà nominato in modo simile aRHN-ORG-TRUSTED-SSL-CERT. Potrete accedere al suddetto certificato tramite web sul seguente URL:https://your-satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT. - Spostate il certificato SSL del client sulla directory Red Hat Network-specifica per la vostra variante di UNIX. Per Solaris tale operazione può essere eseguita con un comando simile al seguente:
mv /path/to/RHN-ORG-TRUSTED-SSL-CERT /opt/redhat/rhn/solaris/usr/share/rhn/
Una volta terminato il nuovo certificato client verrà installato nella directory appropriata per il sistema UNIX. Se siete in possesso di un gran numero di sistemi da predisporre per la gestione di Red Hat Network, sarà possibile creare uno script per questo processo.
Ora è necessario riconfigurare le applicazioni client di Red Hat Network in modo da riferirsi al nuovo certificato SSL installato. Per informazioni consultate la Sezione 2.1.3.3, «Configurazione dei client».
2.1.3.3. Configurazione dei client
La fase finale prima della registrazione dei sistemi client con Red Hat Network è quella della riconfigurazione delle rispettive applicazioni in modo da utilizzare il nuovo certificato SSL e ottenere gli aggiornamenti da Red Hat Satellite. Entrambe queste modifiche possono essere effettuate modificando il file di configurazione del Red Hat Update Agent, il quale fornisce una funzionalità di registrazione e di aggiornamento.
Seguite le fasi di seguito riportate su ogni sistema client:
- Come utente root andate sulla directory di configurazione di Red Hat Network per il sistema. Per Solaris il percorso completo è
/opt/redhat/rhn/solaris/etc/sysconfig/rhn/. - Aprite il file di configurazione
up2datein un editor di testo. - Trovate la voce
serverURLed impostate i valori per il fully qualified domain name (FQDN) per il Red Hat Satellite:serverURL[comment]=Remote server URL serverURL=https://your-satellite.example.com/XMLRPC
- Assicuratevi che l'applicazione si riferisca al Red Hat Satellite anche quando SSL è disabilitato, impostando il valore
noSSLServerURLper il Satellite:noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://your-satellite.example.com/XMLRPC
- Con il file di configurazione
up2dateancora aperto, trovate la vocesslCACerted impostatene il valore sul nome e la posizione del certificato SSL descritto nella Sezione 2.1.3.2, «Implementazione certificati SSL del client», per esempio:sslCACert[comment]=The CA cert used to verify the ssl server sslCACert=/opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
I sistemi client sono ora pronti per la registrazione con Red Hat Network e alla gestione del Satellite.
2.1.4. Registrazione e aggiornamenti del client Unix
Ora che avete installato i pacchetti relativi a Red Hat Network, implementato SSL e riconfigurato i vostri sistemi client in modo da eseguire un collegamento con il Red Hat Satellite, sarete pronti ad iniziare la registrazione dei sistemi e ottenere quindi gli aggiornamenti.
2.1.4.1. Registrazione dei sistemi Unix
Questa sezione descrive il processo di registrazione di Red Hat Network per i sistemi UNIX. È necessario utilizzare
rhnreg_ks per eseguire questa fase, l'utilizzo delle chiavi di attivazione per registrare i vostri sistemi è facoltativo. Le suddette chiavi vi permetteranno di predeterminare le impostazioni presenti all'interno di Red Hat Network, come ad esempio i canali di base ed i gruppi di sistemi, e come applicarle automaticamente sui sistemi durante la loro fase di registrazione.
Poichè la generazione delle chiavi ed il loro utilizzo vengono affrontati in modo più dettagliato in altri capitoli, questa sezione si concentrerà sulle differenze presenti quando applicate sulle varianti UNIX.
Per registrare i sistemi UNIX con il Red Hat Satellite, eseguite le seguenti fasi nell'ordine di seguito riportato:
- Eseguite il login sull'interfaccia web di Satellite e fate clic sulla tabella Sistemi nella barra di navigazione superiore, seguito da Chiavi di attivazione nella barra di navigazione di sinistra. Successivamente fate clic sul link crea nuova chiave nell'angolo in alto a destra della pagina.
- Sulla seguente pagina selezionate il canale di base creato alla fine della Sezione 2.1.2, «Preparazione/Configurazione del Satellite Server».
- Dopo aver creato la suddetta chiave, fate clic sul nome corrispondente all'interno dell'elenco Chiavi di attivazione, per migliorare le proprie impostazioni Red Hat Network associando il software, i canali di configurazione ed i gruppi di sistemi.
- Aprite un terminal sul sistema client da registrare, ed eseguite un login come utente root.
- Utilizzate
rhnreg_ksinsieme con l'opzione--activationkey, per registrare il client con Satellite. La stringa di caratteri della chiave può essere copiata direttamente dall'elenco di Chiavi di attivazione all'interno del sito web. Il comando sarà simile al seguente:rhnreg_ks --activationkey=b25fef0966659314ef9156786bd9f3af
- Tornate sul sito web, fate clic sul nome della chiave di attivazione, ed assicuratevi che il nuovo sistema compaia all'interno della tabella Sistemi Attivati.
2.1.4.2. Acquisizione degli aggiornamenti
Gli aggiornamenti dei pacchetti con UNIX vengono gestiti in modo molto diverso rispetto a Linux. Per esempio, Solaris si affida ai Patch Clusters per aggiornare contemporaneamente pacchetti multipli, mentre i sistemi operativi di Red Hat utilizzano gli Errata Updates per associare gli aggiornamenti stessi ai pacchetti specifici. In aggiunta, Solaris utilizza i file di risposta per automatizzare le installazioni interattive dei pacchetti, tale procedura non viene compresa da Linux, mentre Red HAt offre il concetto dei pacchetti sorgenti. Per questo motivo, la suddetta sezione cerca di evidenziare le differenze nell'utilizzo dei tool di Red Hat Network sui sistemi UNIX. (Nota: Red Hat Network non supporta i file di risposta di Solaris con la release corrente, tale supporto verrà implementato nelle release future.)
Nonostante le differenze, come ad esempio un numero non sufficiente di Errata, il canale e le interfacce di gestione del pacchetto presenti all'interno del sito web di Red Hat Network su Satellite, funzionano in modo piuttosto simile per i sistemi UNIX. I canali software creati per servire le varianti di UNIX, possono essere creati in modo del tutto simile ai canali personalizzati descritti nella Red Hat Satellite Getting Started Guide. La differenza sostanziale è presente nell'architettura. Durante la creazione di un canale software UNIX, assicuratevi di selezionare l'architettura appropriata del canale di base per i sistemi da servire.
Suddividere i pacchetti in canali di base e canali figlio in base alla loro natura. Per esempio, su Solaris, i pacchetti d'installazione dovrebbero andare nel canale di base di Solaris, mentre le patch e Patch Cluster dovrebbero risiedere nel canale figlio del canale di base di Solaris. I pacchetti Extra di installazione, possono risiedere in canali figlio Extra.
Red Hat Network affronta le patch in modo simile ai pacchetti; le suddette patch vengono elencate ed installate nello stesso modo e con la stessa interfaccia dei pacchetti normali. Le patch vengono numerate da Solaris, e avranno nomi simili al seguente "patch-solaris-108434". La versione di una patch di Solais viene estratta dal metadata originale di Solaris, e la release è sempre 1.
I Patch Cluster sono un gruppo di patch installate sotto forma di una unità. Red Hat Network mantiene le informazioni sull'ultima installazione, con esito positivo, di un Patch Cluster sul sistema. Tuttavia i Patch Cluster non vengono controllati sul client come entità installate, quindi non appaiono nei pacchetti installati o all'interno dell'elenco delle patch. I nomi dei Patch Cluster somiglieranno al seguente "patch-cluster-solaris-7_Recommended". La versione viene rappresentata da una stringa riportante la data, come ad esempio "20040206", e la release è sempre 1 ed epoch è sempre 0.
2.1.4.2.1. Caricamento pacchetti sul Satellite
Red Hat Network non fornisce alcun contenuto UNIX; qualsiasi pacchetto Solaris, patch o Patch Clusters deve essere caricato su Satellite in un formato comprensibile da un sistema client. Il pacchetto in questione può essere gestito e distribuito su altri sistemi. Red Hat Network ha creato
solaris2mpm in modo da tradurre i pacchetti Solaris, le patch ed i patch cluster in un formato comprensibile da parte di Satellite.
2.1.4.2.1.1. solaris2mpm
Come precedentemente affrontato nella Sezione 2.1.1.4, «Differenze di funzionalità»,
solaris2mpm è parte integrante di Red Hat Network Push per Solaris. Il contenuto inviato ad un canale Solaris su Satellite deve essere prima in formato .mpm.
Un file .mpm è un archivio contenente una descrizione dei dati relativi al pacchetto ed il pacchetto/pacth stesso. Il comando solaris2mpm deve essere eseguito col client e mai su Satellite.
Nota
solaris2mpm necessita di uno spazio disponibile uguale a tre volte la misura di qualsiasi pacchetto, patch o Patch Cluster da convertire. Nornalmente lo spazio in
/tmp/ verrà utilizzato a tale scopo. L'opzione --tempdir vi permette di specificare se necessario un'altra directory.
File multipli possono essere specificati sulla linea di comando di solaris2mpm. Di seguito viene riportato un esempio:
# solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg Opening archive, this may take a while Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm Opening archive, this may take a while Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm
Poichè non è stata specificata alcuna directory, i file .mpm risultanti vengono scritti sulla directory /tmp/. Da notare che il nome del file .mpm risultante, include l'architettura del client sul quale è stato creato, in questo caso SPARC Solaris. Il formato generale dei nomi del file mpm è:
name-version-release.arch.mpm
Patch clusters sono "esplosi" - in ogni cluster vengono generati file .mpm per ogni patch, insieme ai file .mpm "meta" di livello superiore, contenenti informazioni sull'intero cluster.
Di seguito sono riportate le opzioni di solaris2mpm:
Tabella 2.2. opzioni di solaris2mpm
| Opzione | Descrizione |
|---|---|
--version
|
Mostra il numero della versione del programma ed esce
|
-h, --help
|
Mostra queste informazioni ed esce
|
-?, --usage
|
Stampa le informazioni relative all'utilizzo del programma ed esce
|
--tempdir=<tempdir>
|
Directory temporanea dalla quale poter lavorare
|
--select-arch=<arch>
|
Seleziona l'architettura (i386 o SPARC) per pacchetti usati su architetture multiple.
|
2.1.4.2.1.2. rhnpush con file .mpm
La versione Solaris di
rhnpush funziona come una utility standard, con l'aggiunta di una funzione che gli permette di gestire i file .mpm. Di seguito viene riportato un esempio sul suo utilizzo:
% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \ RHATrpush-3.1.5-*.mpm Red Hat Network password: Connecting to http://testbox.example.com/APP Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm
Nota
I file .mpm del Patch cluster devono essere inviati simultaneamente, insieme o subito dopo - mai prima -, ai file .mpm per le patch contenute nel cluster in questione.
Utilizzate solaris2mpm su ogni pacchetto, patch o patch cluster che desiderate gestire tramite Satellite, e successivamente utilizzate Red Hat Network Push per caricarli sul canale creato appositamente per loro.
2.1.4.2.2. Aggiornamento attraverso il sito web
Per installare i pacchetti o le patch su di un sistema individuale, fate clic sul nome del sistema corrispondente nella categoria Sistemi, selezionare i pacchetti dagli elenchi Installa o Aggiorna della tabella Pacchetti o Patches, e fate clic su .
Per eseguire un comando remoto mentre installate il pacchetto, fate clic su invece di . Per istruzioni consultate la Sezione 2.1.5, «Comandi remoti».
Per installare contemporaneamente i pacchetti o le patch su sistemi multipli, selezionate i sistemi e fate clic su System Set Manager sulla barra d navigazione di sinistra. Successivamente, nella tabella Pacchetti, selezionate i pacchetti dagli elenchi Aggiorna o Installa e fate clic su . Per completare l'azione, programmate gli aggiornamenti.
2.1.4.2.3. rhnsd
Sui sistemi ed Hat Enterprise Linux il demone
rhnsd, il quale indica al sistema client di eseguire un check in con Red Hat Network, viene avviato automaticamente al momento dell'avvio. Sui sistemi Solaris rhnsd non viene avviato per default al momento dell'avvio, ma può essere avviato dalla linea di comando nel seguente modo:
rhnsd --foreground --interval=240
La posizione di default per
rhnsd è /opt/redhat/rhn/solaris/usr/sbin/rhnsd. Di seguito vengono riportate le opzioni disponibili per rhnsd su Solaris:
Tabella 2.3. Opzioni rhnsd
| Opzione | Descrizione |
|---|---|
-f, --foreground
|
Eseguito in primo piano
|
-i, --interval=MINS
|
Collega a Red Hat Network ogni MIN minuti
|
-v, --verbose
|
Registra tutte le azioni su syslog
|
-h, --help
|
Conferisci questo elenco d'aiuto
|
-u, --usage
|
Conferisci questo elenco d'aiuto
|
-V, --version
|
Stampa versione programma
|
2.1.4.2.4. Aggiornamento attraverso la linea di comando
In modo simile al sito web, l'utilizzo di Red Hat Update Agent da parte della linea di comando viene interessato dalle limitazioni di UNIX package management. Detto questo, è posibile eseguire la maggior parte delle funzioni principali tramite il comando
up2date. La differenza più importante è l'assenza di tutte le opzioni che riguardano i file sorgenti. Consultate la Tabella 2.4, «Argumento della linea di comando dell'Update Agent» per un elenco completo di opzioni disponibili per i sistemi UNIX.
La versione della linea di comando di Red Hat Update Agent accetta i seguenti argomenti sui sistemi UNIX:
Tabella 2.4. Argumento della linea di comando dell'Update Agent
| Argomento | Descrizione |
|---|---|
--version | Mostra le informazioni sulla versione del programma. |
-h, --help | Mostra questo messaggio di aiuto ed esce. |
-v, --verbose | Mostra output aggiuntivi. |
-l, --list | Elenca le ultimissime versioni di tutti i pachetti installati. |
-p, --packages | Aggiorna i pacchetti associati con questo profilo del sistema. |
--hardware | Aggiorna questo profilo hardware del sistema su Red Hat Network. |
--showall | Elenca tutti i pacchetti disponibili per il download. |
--show-available | Elenca tutti i pacchetti disponibili che non sono attualmente installati. |
--show-orphans | Elenca tutti i pacchetti attualmente installati ma che non sono presenti all'interno dei canali ai quali il sistema è sottoscritto. |
--show-channels | Mostra i nomi del canale insieme ai nomi del pacchetto dove appropriato. |
--installall | Installa tutti i pacchetti disponibili. Utilizzare con l'opzione --channel. |
--channel=CHANNEL | Specifica da quale canale aggiornare utilizzando le etichette dei canali. |
--get | Riprende il pacchetto specificato senza risolvere le dipendenze. |
2.1.5. Comandi remoti
Insieme al supporto UNIX, Red Hat Network offre la possibilità di digitare comandi remoti su sistemi client attraverso il sito web di Satellite. Questa caratteristica vi permette di eseguire virtualmente qualsiasi applicazione (compatibile) o script, su qualsiasi sistema presente all'interno del vostro dominio, senza aprire alcun teminale.
2.1.5.1. Abilitazione dei comandi
Insieme alla flessibilità offerta dal tool in questione è da tener presente anche i rischi ad esso connessi. La suddetta caratteristica garantisce un prompt BASH di root con accesso amministrativo, al sistema presente sul sito web.
Tale tendenza può essere controllata attraverso lo stesso meccanismo 'config-enable', utilizzato per determinare su quale sistema è posibile gestire i rispettivi file di configurazione attraverso Red Hat Network.
In breve, è necessario creare una directory ed un file sul sistema UNIX che indicano a Red Hat Network la possibilità di eseguire sulla macchina i comandi remoti. La directory deve essere chiamata
script, il file run, ed entrambi devono essere posizionati all'interno della directory /etc/sysconfig/rhn/allowed-actions/ specifica alla vostra variante UNIX.
Per esempio, in Solaris digitare questo comando per creare la diretory:
mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script
Digitare questo comando in Solaris per creare il file richiesto:
touch /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script/run 2.1.5.2. Come digitare i comandi
È possibile programmare un comando remoto in diversi modi: su di un sistema individuale, contemporaneamente su sistemi multipli, e per accompagnare un'azione relativa ad un pacchetto.
Per eseguire un comando remoto su di un sistema individuale, aprite la pagina Informazioni del sistema, fate clic sulla sottotabella Comando Remoto. (Da notare che questa sottotabella appare solo se il sistema presenta un entitlement di Provisioning.) Su questa pagina stabilite le impostazioni per il comando in questione. Potrete identificare un utente specifico, un gruppo ed un periodo di timeout, insieme allo stesso script. Scegliete l'ora e la data entro le quali inizierete a digitare il comando, facendo clic sul link .
In modo simile, è possibile digitare un comando remoto su sistemi multipli contemporaneamente attraverso il System Set Manager. Selezionate i sistemi, andate su System Set Manager, fate clic sulla scheda Provisioning e raggiungete la sezione Comando Remoto. Da li potrete eseguire contemporaneamente un comando remoto sui sistemi selezionati.
Per eseguire un comando remoto con l'azione di un pacchetto, programmate l'azione attraverso la tabella Pacchetti della pagina Informazioni del sistema, e fate clic su durante la conferma dell'azione. Usate i comandi di selezione nella parte alta, per determinare se il comando deve essere eseguito prima o dopo l'azione del pacchetto, stabilite le impostazioni per il comando, e fate clic su .
Notate che l'installazione di pacchetti multipli che presentano comandi remoti differenti, richiede la programmazione di installazioni separate, o la combinazione dei comandi all'interno di uno script singolo.
Capitolo 3. Informazioni sul Red Hat Satellite Proxy
Questa sezione si riferisce all'uso di Red Hat Satellite Proxy con il Red Hat Network Package Manager.
3.1. Utilizzo di Red Hat Network Package Manager e Serving Local Package attraverso il Red Hat Network Proxy
Il Red Hat Network Package Manager è uno strumento della linea di comando il quale permette ad una organizzazione di servire i pacchetti locali associati con un canale Red Hat Network privato attraverso il Red Hat Network Proxy Server. Non installate Red Hat Network Package Manager se desiderate aggiornare solo i pacchetti Red Hat ufficiali per il Red Hat Network Proxy Server.
Per usare il Red Hat Network 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 Red Hat Network. Le intestazioni sono necessarie a Red Hat Network per risolvere le dipendenze del pacchetto per i sistemi client. I file del pacchetto (
*.rpm) sono archiviati sul Red Hat Network Proxy Server.
Il Red Hat Network 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 Red Hat Network Package Manager
rhn_package_manager:
Tabella 3.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 intestazioni 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 corrente ed esci. |
-XPATTERN, --exclude=PATTERN | Esclude 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 Red Hat Network Package Manager cerca di passare solo i pacchetti firmati. |
--username=USERNAME | Specifica il nome utente di Red Hat Network. Se non ne fornite uno con questa opzione, allora vi sarà richiesto di specificarne uno in questo modo. |
--password=PASSWORD | Specifica la password di Red Hat Network. 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 di aiuto con 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 Red Hat Network Package Manager sia in grado di servire i pacchetti locali seguire le fasi di seguito riportate:
- Creazione di un canale privato.
- Caricare i pacchetti locali all'interno del canale.
Le fasi verranno approfondite nelle sezioni successive.
3.1.1. Creazione di un canale privato
Prima di rendere disponibili i pacchetti locali attraverso un Red Hat Network 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:
- Eseguite un login sull'interfaccia web di Red Hat Network in https://rhn.redhat.com o sul server di Red Hat Satellite locale nella rete.
- 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.
- Nella barra di navigazione di sinistra, fate clic su Gestisci Canali Software, e successivamente sul pulsante nell'angolo a destra della pagina.
- 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 Red Hat Network Channel Management Guide.
- Fate clic su .
3.1.2. Caricamento dei pacchetti
Nota
È necessario essere un Amministraore dell'organizzazione per caricare i pacchetti sui canali Red Hat Network privati. Lo script richiederà di inserire il nome utente e password di Red Hat Network.
Dopo aver creato il canale privato, caricate le intestazioni del pacchetto per i vostri RPM sorgente e binari sul server Red Hat Network, e copiate i pacchetti sul Red Hat Network 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. Red Hat Network 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 Red Hat Network 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 Red Hat Network 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 Red Hat Network 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 Red Hat Network.
Se state utilizzando Red Hat Network Package Manager per aggiornare i pacchetti locali, è necessario andare sul sito web di Red Hat Network per registrare il sistema sul canale privato.
Capitolo 4. Gestione dei pacchetti personalizzati
Questo capitolo fornisce una panoramica su come creare i pacchetti e renderli disponibili correttamente tramite Red Hat Network. Gli argomenti affrontati riguardano il motivo per il quale viene utilizzato RPM, la creazione dei pacchetti per Red Hat Network e come firmarli in modo corretto.
4.1. Creazione dei pacchetti per Red Hat Network
Red Hat Network utilizza la tecnologia RPM Package Manager (RPM), per determinare il tipo di aggiornamento o le implementazioni software aggiuntive applicabili ad ogni sistema client. I pacchetti ripristinati da Red Hat Network sono generalmente in formato RPM. Tuttavia le immagini ISO sono disponibili attraverso la tabella Software del sito web di Red Hat Network, ma non sono disponibili nelle installazioni Red Hat Satellite. Se il supporto Solaris è stato abilitato sul vostro server Satellite, sarà possibile utilizzare Red Hat Network Push per caricare i pacchetti Solaris sui canali personalizzati utilizzati dai client di Solaris.
RPM è un tool in grado di fornire agli utenti un metodo molto semplice di installazione, disinstallazione, aggiornamento e verifica dei pacchetti software. Altresì permette agli sviluppatori software di contenere il codice sorgente e le versioni compilate di un programma per utenti finali e sviluppatori.
4.1.1. Vantaggi offerti da RPM
RPM fornisce i seguenti vantaggi:
- Processi di aggiornamento semplici
- Utilizzando RPM è possibile aggiornare singoli componenti di un sistema senza eseguire un processo completo di reinstallazione. Quando Red Hat rende disponibile una nuova versione di Red Hat Enterprise Linux, per poter eseguire un processo di aggiornamento gli utenti non dovranno eseguire un nuovo processo di installazione. RPM rende possibile l'esecuzione di processi di aggiornamento intelligenti e completamente automatizzati. Durante l'esecuzione dei suddetti processi, i file di configurazione presenti all'interno dei pacchetti non verranno alterati, in questo modo gli utenti non perderanno le proprie impostazioni. Non è necessario alcun tipo di file di aggiornamento per eseguire tale operazione su di un pacchetto, poichè viene utilizzato lo stesso tipo di file RPM per installare o aggiornare il pacchetto.
- Interrogazione dei pacchetti
- RPM fornisce delle opzioni per il processo di interrogazione atte ad eseguire una ricerca, attraverso il vostro database RPM, di pacchetti o di determinati file. È possibile altresì stabilire il file di appartenenza di un pacchetto e la sua provenienza. I file contenuti nel pacchetto si trovano in un archivio compresso con una intestazione binaria personalizzata contenente infiromazioni utili sul pacchetto e sui rispettivi contenuti. RPM interroga le intestazioni in modo veloce a semplice.
- Verifica del sistema
- Un'altra caratteristica è quella della verifica dei pacchetti. Se credete che un file relativo ad un pacchetto sia stato cancellato, sarà possibile verificare il pacchetto in modo da controllare lo stato del file corrispondente. Tale verifica notificherà la presenza di eventuali anomalie. Se sono presenti degli errori sarà possibile reinstallare i file in modo semplice. I file di configurazione modificati vengono conservati durante il processo di reinstallazione.
- Pristine Sources
- Uno degli scopi più importanti di RPM è quello di permettere l'utilizzo dei pristine software sources, come diffuso dagli autori originali del software. Insieme a RPM sono presenti all'interno di un prodotto sia i pristine sources che le patch utilizzate insieme alle istruzioni per l'impostazione. Tale caratteristica rappresenta un vantaggio per diversi motivi. Per esempio, nel caso in cui viene rilasciata una nuova versione di un programma, non sarà necessario eseguire la sua compilazione partendo da zero. È necessario solo controllare la patch relativa per seguire le fasi a voi necessarie. Tutti i valori di default e le modifiche eseguite per impostare correttamente il vostro software, sono facilmente visibili utilizzando questa tecnica.Il mantenimento inalterato dei codici sorgenti non solo potrebbe interessare gli sviluppatori, ma potrebbe anche dar luogo ad un software con qualità maggiori per gli utenti finali.
4.1.2. Guide linea per l'RPM di Red Hat Network
Il vantaggio di RPM stà nel fatto che esso è in grado di definire le dipendenze e di identificare i conflitti in modo accurato, per questo motivo Red Hat Network si affida molto a questa funzione. Red Hat Network offre altresì un ambiente automatizzato, ciò significa che non è possibile eseguire alcun intervento manuale durante il processo di installazione di un pacchetto. Pertanto, al momento della creazione di RPM per una distribuzione tramite Red Hat Network, è necessario seguire le regole di seguito riportate:
- Conoscere RPM. È cruciale comprendere in modo approfondito l'importanza delle funzioni essenziali di RPM in modo da creare correttamente i pacchetti. Per maggiori informazioni su RPM, consultate le seguenti risorse:
- Quando create un RPM per un canale figlio, create il pacchetto tramite una nuova installazione di Red Hat Enterprise Linux con la stessa versione del canale di base del figlio. Assicuratevi di applicare prima tutti gli aggiornamenti provenienti da Red Hat Network.
- È necessario installare il pacchetto RPM senza l'utilizzo delle opzioni
--forceo--nodeps. Se non siete in grado d'installare in modo pulito un RPM sul vostro sistema di compilazione, Red Hat Network non sarà in grado di installarlo automaticamente sul sistema. - Il filename del pacchetto RPM deve essere in formato NVR (name, version, release), e deve contenere l'architettura per il pacchetto. Il formato corretto è
name-version-release.arch.rpm. Per esempio, un filename valido per il pacchetto RPM èpkgname-0.84-1.i386.rpm, dove il nome è pkgname, la versione è 0.84, la release è 1, e l'architettura è i386. - Il pacchetto RPM dovrebbe essere firmato dal manutentore del pacchetto. I pacchetti non firmati possono essere distribuiti attraverso Red Hat Network, ma yum deve essere forzato ad accettarli. La firma dei pacchetti è fortemente consigliata e viene affrontata nella Sezione 4.2, «Firme digitali per i pacchetti di Red Hat Network».
- Se il pacchetto viene in alcun modo modificato, incluso la modifica della firma o la sua ricompilazione, la versione o la release deve essere aumentata in maniera incrementale. In altre parole, l'NVRA (incluso il tipo di architettura) per ogni RPM distribuito attraverso Red Hat Network deve corrispondere una creazione unica nel genere per evitare doppioni.
- Nessun pacchetto RPM può rendere la propria versione obsoleta.
- Se il pacchetto viene diviso in due o più pacchetti separati, fate molta attenzione alle dipendenze. Non dividete un pacchetto esistente a meno che non siete costretti a farlo.
- Nessun pacchetto si può affidare agli script di pre-installazione, post-installazione, pre-disinstallazione o post-disinstallazione interattiva. Se il pacchetto in questione ha bisogno dell'intervento di un utente durante l'installazione, tale procedura non sarà in grado di funzionare con Red Hat Network.
- Qualsiasi script di pre-installazione, post-installazione, pre-disinstallazione e post-disinstallazione non dovrebbe mai eseguire alcun processo di scrittura su stderr o stdout. Ridirezionate i messaggi su
/dev/null, se essi non risultano necessari, in caso contrario scriveteli su di un file. - Quando create il file spec, utilizzate le definizioni del gruppo presenti in
/usr/share/doc/rpm-<version>/GROUPS. Se non è disponibile un abbinamento ideale, selezionate quello più idoneo. - Utilizzate la funzione della dipendenza RPM, in modo da assicurare una esecuzione corretta del programma dopo la sua installazione.
Importante
Non create alcun RPM tramite il processo di archiving e unarchiving dei file all'interno dello script post-installazione. Tale processo annulla l'obiettivo di RPM.
Se i file presenti all'interno dell'archivio non vengono inclusi nell'elenco, essi non possono essere verificati o esaminati per la presenza di conflitti. Nella maggior parte dei casi RPM è in grado di compattare e scompattare gli archivi nel modo migliore. Per esempio, non create alcun file in un %post non riordinato in una sezione %postun.
4.2. Firme digitali per i pacchetti di Red Hat Network
Tutti i pacchetti distribuiti attraverso Red Hat Network dovrebbero avere una Firma Digitale. La suddetta firma viene creata attraverso una chiave unica privata, e può essere verificata con la chiave pubblica corrispondente. Dopo aver creato un pacchetto SRPM (Source RPM) e l'RPM possono essere firmati in modo digitale tramite una chiave GnuPG. Prima di installare il pacchetto, è necessario utilizzare una chiave pubblica in modo da verificare che il pacchetto sia stato firmato da una entità fidata, e che lo stesso non sia stato modificato dopo l'ultima firma.
4.2.1. Generazione di una coppia di chiavi GnuPG
Una coppia di chiavi GnuPG consiste in una chiave pubblica ed una privata. Per la sua generazione:
- Nel prompt della shell digitare come utente root il seguente comando:
gpg --gen-keyLa coppia di chiavi GPG non deve essere creata da utenti non root. L'utente root è in grado di bloccare le pagine della memoria, ciò significa che le informazioni non verranno mai scritte sul disco, diversamente dagli utenti non-root. - Dopo aver eseguito il comando per generare una coppia di chiavi sarete in grado di visualizzare una schermata introduttiva contenente alcune opzioni della chiave, simili a quanto segue:
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection?
- Accettate l'opzione: (2) DSA and ElGamal. Questa opzione vi permetterà di creare una firma digitale e di eseguire una codifica/decodifica con due tipi di tecnologie. Digitate
2e poi premete Invio. - Successivamente scegliete la misura della chiave, ciò indicherà la lunghezza della chiave. Più la chiave è lunga e più sarà resistente agli attachi. A questo scopo è consigliato la creazione di una chiave a 2048 bit.
- L'opzione successiva richiederà di stabilire la validità della vostra chiave. Se selezionate una data di scadenza, ricordate che tutti gli utenti che utilizzano la vostra chiave pubblica dovranno essere informati della suddetta data, e quindi acquisire una nuova chiave pubblica. È consigliato non selezionare alcuna data di scadenza. Se non impostate alcuna data sarà chiesto di confermare la vostra scelta:
Key does not expire at all Is this correct (y/n)?
- Premete y per confermare.
- Il compito successivo sarà quello di fornire un User-ID contenente il nome, l'indirizzo email ed un commento aggiuntivo, ognuno di essi viene richiesto individualmente. Una volta terminato verrà mostrato un sommario contenente le informazioni da voi inserite.
- Una volta confermata la vostra selezione inserite una frase d'accesso.
Nota
In modo simile alle password una frase d'accesso efficace è fondamentale per la sicurezza in GnuPG. Utilizzate un giusto mix di lettere maiuscole e minuscole, numeri e/o punteggiatura. - Dopo aver inserito e verificato la frase d'accesso verranno generate le chiavi. A questo punto sarà visualizzato un messaggio simile al seguente:
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++.+++++.++++++++....++++++++++..+++++.+++++.+++++++.+++++++ +++. ++++++++++++++++++++++++++++++++++++++..........................++++
Terminata l'attività nella schermata, le nuove chiavi verranno posizionate nella directory.gnupgnella home directory di root. Questo rappresenta la posizione predefinita delle chiavi generate dall'utente root.
Per elencare le chiavi di root usare il comando:
gpg --list-keys
L'output sarà simile al seguente:
gpg: key D97D1329 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2013-08-28
pub 2048D/D97D1329 2013-08-27 [expires: 2013-08-28]
Key fingerprint = 29C7 2D2A 5F9B 7FF7 6411 A9E7 DE3E 5D0F D97D 1329
uid Your Name<you@example.com>
sub 2048g/0BE0820D 2013-08-27 [expires: 2013-08-28]
Per ripristinare la chiave pubblica, utilizzate il seguente comando:
gpg --export -a 'Your Name' > public_key.txt
La chiave pubblica è scritta sul file
public_key.txt.
Questa chiave pubblica è molto importante, infatti essa risulta essere la chiave da impiegare su tutti i sistemi client che ricevono un software personalizzato attraverso
yum. Le tecniche utilizzate per impiegare questa chiave attraverso un'organizzazione, sono disponibili nella Red Hat Network Client Configuration Guide.
4.2.2. Firma dei pacchetti
Prima di poter firmare i pacchetti è necessario configurare il vostro file
~/.rpmmacros in modo da includere quanto segue:
%_signature gpg %_gpg_name B7085C8A
Sostituire il valore ID della chiave
_gpg_name di B7085C8A, con l'ID della chiave dal vostro keyring GPG utilizzato per firmare i pacchetti. Questo valore indica all'RPM la firma da utilizzare.
Per firmare il pacchetto package-name-1.0-1.noarch.rpm, utilizzate il seguente comando:
rpm --resign package-name-1.0-1.noarch.rpm
Inserire la frase d'accesso. Per assicurarvi che il pacchetto sia stato firmato, utilizzate il seguente comando:
rpm --checksig -v package-name-1.0-1.noarch.rpm
Nota
Prima di eseguire il comando
rpm --checksig -v importare la chiave gpg. Consultare Sezione 4.3, «Come importare le chiavi GPG personalizzate» nella sezione successiva per maggiori informazioni.
A questo punto dovreste visualizzare la frase: Good signature from "Your Name" nell'output, con Your Name sostituito con il nome associato con la chiave utilizzata per la firma.
4.3. Come importare le chiavi GPG personalizzate
Per gli utenti che desiderano creare e distribuire in modo sicuro i propri RPM, è fortemente consigliato firmare tutti gli RPM personalizzati con la GNU Privacy Guard (GPG). La generazione delle chiavi GPG e la creazione di pacchetti firmati con GPG vengono affrontati all'interno della Sezione 4.2.1, «Generazione di una coppia di chiavi GnuPG».
Una volta firmati i pacchetti la chiave pubblica deve essere implementata su tutti i sistemi che importano gli RPM interessati. Questo processo presenta due fasi: la prima è relativa alla creazione di una posizione centrale per la chiave pubblica in modo che gli utenti siano in grado di recuperarla, e la seconda è l'aggiunta della chiave al keyring GPG locale per ogni sistema.
La prima fase del processo è comune e può essere gestita utilizzando il sito web consigliato per l'implementazione delle applicazioni client di Red Hat Network. Per fare questo create una directory pubblica sul Web server e posizionate la firma pubblica GPG al suo interno:
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
Successivamente i sistemi client potranno scaricare la chiave utilizzando Wget:
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
L'opzione
-O- invia i risultati agli output standard, mentre l'opzione -q imposta Wget in modo da essere eseguito in modalità quiet. Ricordate di sostituire la variabile YOUR-RPM-GPG-KEY con il nome del file della vostra chiave.
Una volta disponibile la chiave sul file system del client importatela all'interno del keyring GPG locale. Diversi sistemi operativi richiedono metodi diversi.
Per Red Hat Enterprise Linux 3 o versioni più recenti utilizzate il seguente comando:
rpm --import /path/to/YOUR-RPM-GPG-KEY
Una volta aggiunta la chiave GPG al client, il sistema dovrebbe essere in grado di convalidare gli RPM personalizzati firmati con la chiave corrispondente.
Nota
Durante l'uso di canali e RPM personalizzati creare sempre una chiave GPG personalizzata per questi pacchetti. La posizione della chiave GPG deve essere aggiunta al profilo kickstart.
La chiave GPG personalizzata dovrà essere aggiunta ai sistemi client, in caso contrario l'installazione kickstart fallirà.
Capitolo 5. Troubleshooting
Questo capitolo fornisce alcuni suggerimenti per poter determinare le cause e per poter risolvere gli errori più comuni associati con Red Hat Satellite. Se avete bisogno di ulteriori informazioni, contattate il supporto di Red Hat Network su https://access.redhat.com/support/. Eseguite un log in utilizzando il vostro account abilitato al Satellite in modo da visualizzare un elenco completo di opzioni.
Per iniziare il troubleshooting dei problemi generali esaminare il file di log o i file relativi al componente in questione. Un esercizio utile è quello di eseguire il comando
tail -f per tutti i file di log, per poi eseguire yum list. Successivamente esaminate tutte le nuove entry per possibili indizi.
- 5.1. Spazio del disco
- 5.2. Installazione ed aggiornamento
- 5.3. Servizi
- Domanda: Perchè l'Apache Web server non è in esecuzione?
- Domanda: Come faccio a sapere qual è lo stato di Red Hat Network Task Engine?
- Domanda: Come faccio a sapere qual è lo stato del database embedded di Satellite?
- Domanda: Cosa devo fare se la funzione push di Red Hat Satellite non funzionano più?
- 5.4. Connettività
- 5.5. Registrazione e notifiche
- Domanda: Quali sono i diversi tipi di file di log?
- Domanda: Come posso usare spacewalk-report?
- Domanda: Come posso determinare la mia versione dello schema del database?
- Domanda: Come faccio a sapere quali sono i tipi di caratteri a mia disposizione?
- Domanda: Perchè l'amministratore non è in grado di ricevere le email?
- Domanda: Come faccio a modificare il mittente della posta di traceback?
- 5.6. Errori
- Domanda: Visualizzo l'errore "Errore di convalida del certificato satellite" durante l'installazione di Red Hat Satellite. Come posso correggerlo?
- Domanda: Visualizzo l'errore "ERRORE: server.mount_point non impostato nel file di configurazione" quando provo ad attivare o sincronizzare Red Hat Satellite. Come lo correggo?
- Domanda: Perchè cobbler check genera un errore il quale indica che è necessaria una versione diversa di yum-utils?
- Domanda: Visualizzo un errore "versione non supportata" durante il tentativo di attivazione del certificato di Red Hat Satellite. Come posso correggerlo?
- Domanda: Visualizzo un errore "Internal Server Error" relativo ad ASCII quando provo a modificare il profilo kickstart. Per quale motivo?
- Domanda: Visualizzo errori "host non trovato" o "Impossibile determinare il FQDN". Cosa posso fare ora?
- Domanda: Visualizzo il seguente messaggio "This server is not an entitled Satellite" quando provo a sincronizzare il server di Red Hat Satellite. Come posso correggerlo?
- 5.7. Interfaccia web
- 5.8. Anaconda
- 5.9. Messaggi di Traceback
- 5.10. Registrazione
- 5.11. Kickstart e Snippet
- 5.12. Monitoring
- 5.13. Satellite di organizzazioni multiple e Certificati satellite
- Domanda: Come posso registrare i miei sistemi in un ambiente con organizzazioni multiple quando non sono in possesso di un numero sufficiente di entitlement nel mio Certificati Satellite?
- Domanda: Sono presenti alcuni entitlement supplementari su Certificati Satellite che non vengono utilizzati. Cosa può succedere ai suddetti entitlement?
- 5.14. Installazione e configurazione del Proxy
- Domanda: Dopo aver configurato il Red Hat Network Package Manager come posso determinare se i pacchetti locali sono stati aggiunti con successo al canale di Red Hat Network privato?
- 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 Red Hat Satellite Proxy. Come posso risolvere questo problema?
- Domanda: La configurazione del mio Red Hat Satellite Proxy non funziona. Da dove posso iniziare il suo processo di troubleshooting?
- Domanda: Come risolvo i problemi generali presenti in the Red Hat Satellite Proxy?
- Domanda: Sul mio Red Hat Satellite Proxy ho riscontrato un errore di tipo "Host Not Found"/"Could not Determine FQDN". Cosa posso fare?
- Domanda: Ho alcuni problemi con Red Hat Satellite Proxy e con la connessione di rete. Cosa posso fare?
- Domanda: Ho alcuni problemi con la disponibilità dei pacchetti e con la corruzione degli oggetti. Cosa posso controllare?
5.1. Spazio del disco
Domanda:
Lo spazio del mio disco si è esaurito molto velocemente. Cosa è successo e cosa posso fare?
Risposta:
Un problema molto comune è quello reltivo al consumo dello spazio del disco. Un segno indicativo di questo problema è la comparsa di linee non complete all'interno dei file di log. Se il processo di login è stato arrestato durante l'azione di scrittura, ad esempio una parola rimasta a metà, molto probabilmente questo sarà un segno che lo spazio del disco è stato riempito. Per una conferma, eseguite questo comando e controllate le percentuali nella colonna Utilizzo%.:
# df -h
In aggiunta ai file di log, è possibile ottenere informazioni aggiuntive riprendendo lo stato del vostro Red Hat Satellite e dei suoi vari componenti. Per eseguire questa procedura utilizzate il seguente comando:
# /usr/sbin/rhn-satellite status
In aggiunta, è possibile ottenere lo stato dei componenti come ad esempio Apache Web e Red Hat Network Task Engine in modo individuale. Per esempio, per visualizzare lo stato del server Apache Web eseguire il comando:
# service httpd status
5.2. Installazione ed aggiornamento
Domanda:
SELinux mi invia messaggi durante l'installazione. Perchè?
Risposta:
Se avete difficoltà con i messaggi di SELinux (come ad esempio i messaggi di negazione AVC) durante l'installazione di Red Hat Satellite, assicuratevi di avere a disposizione i file
audit.log in modo da poter usufruire del supporto offerto da Red Hat. Il file è disponibile su /var/log/audit/audit.log ed è consigliato allegarlo al vostro Support ticket per il supporto del nostro personale.
Domanda:
Ho modificato
/var/satellite in un NFS mount e ora SELinux impedisce il suo funzionamento corretto. Cosa devo fare?
Risposta:
È necessario modificare i parametri di SELinux in base al nuovo montaggio NFS per far si che SELinux possa abilitarne il traffico. Per fare questo usare il seguente comando:
# /usr/sbin/setsebool -P spacewalk_nfs_mountpoint on
Se utilizzate Red Hat Enterprise Linux 6 sarà necessario usare anche il seguente comando:
# /usr/sbin/setsebool -P cobbler_use_nfs on
Domanda:
Il mio Satellite non funziona correttamente. Perchè?
Risposta:
Non registrate Red Hat Satellite ai seguenti canali figlio disponibili dai server centrali di Red Hat Network:
- Red Hat Developer Suite
- Red Hat Application Server
- Red Hat Extras
- Canali del prodotto di JBoss
Con la sottoscrizione ai suddetti canali e l'aggiornamento di Satellite potreste installare versioni nuove ma incompaibili di componenti software critici, con un conseguente fallimento di Satellite.
5.3. Servizi
Domanda:
Perchè l'Apache Web server non è in esecuzione?
Risposta:
Se Apache Web server non è in esecuzione le voci presenti all'interno del file
/etc/hosts potrebbero non essere corrette.
Domanda:
Come faccio a sapere qual è lo stato di Red Hat Network Task Engine?
Risposta:
Per poter ottenere lo stato di Red Hat Network Task Engine, eseguire il comando:
# service taskomatic status
Domanda:
Come faccio a sapere qual è lo stato del database embedded di Satellite?
Risposta:
Per ottenere lo stato del database embedded di Satellite, se presente, eseguire il comando:
# db-control status
Domanda:
Cosa devo fare se la funzione push di Red Hat Satellite non funzionano più?
Risposta:
Se la funzione di push di Red Hat Satellite non è più funzionale, è possibile che i file di log più vecchi possano presentare degli errori. Arrestate il demone jabberd prima di rimuovere questi file. Per fare questo emettere i seguenti comandi come utente root:
# service jabberd stop # rm -f /var/lib/jabberd/db/_db* # service jabberd start
5.4. Connettività
Domanda:
Non sono in grado di collegarmi! Come faccio a sapere qual è il problema?
Risposta:
I seguenti accorgimenti potrebbero essere usati per la risoluzione di errori riguardanti i collegamenti generali:
- Cercate di collegarvi al database di Red Hat Satellite sulla linea di comando utilizzando la stringa corretta di collegamento come mostrato in
/etc/rhn/rhn.conf:# sqlplus username/password@sid
- Assicuratevi che Red Hat Satellite stia utilizzando il Network Time Protocol (NTP), il quale a sua volta risulta impostato sul fuso orario appropriato. Ciò viene applicato anche a tutti i sistemi client ed alle macchine separate del database in Red Hat Satellite con database stand-alone.
- Confermate l'uso del pacchetto corretto:
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpmsia stato installato su Red Hat Satellite e che ilrhn-org-trusted-ssl-cert-*.noarch.rpmcorrispondente o il certificato raw CA SSL public (client), sia installato su tutti i sistemi client. - Verificate che i sistemi client siano stati configurati in modo da utilizzare il certificato appropriato.
- Se vengono utilizzati uno o più server di Red Hat Proxy, assicuratevi che ogni certificato SSL di Proxy sia creato in modo corretto. Il Proxy dovrebbe presentare sia la coppia di chiavi SSL che il certificato CA SSL public (client), in quanto esso verrà utilizzato in entrambi i casi. Consultate il capitolo riguardante i Certificati SSL della Red Hat Satellite Client Configuration Guide per informazioni specifiche.
- Assicuratevi che i sistemi client non utilizzino i firewall bloccando quindi le porte necessarie come riportato nella Red Hat Satellite Installation Guide all'interno della sezione Requisiti aggiuntivi.
Domanda:
Cosa posso fare se il processo di importazione o sincronizzazione di un canale fallisce e non sono in grado di ripristinarlo?
Risposta:
Se l'importazione/sincronizzazione di un canale riporta un errore che voi non siete in grado di risolvere, eseguite questo comando per cancellare la cache:
# rm -rf temporary-directory
Nota
La sezione Red Hat Satellite Installation Guide presente in Preparazione per una importazione dal dispositivo locale riporta
/var/rhn-sat-import/ come directory temporanea.
Successivamente potrete riavviare il processo di importazione o sincronizzazione.
Domanda:
Visualizzo errori "SSL_CONNECT". Cosa posso fare ora?
Risposta:
Un problema comune per quanto riguarda il collegamento, indicato dagli errori
SSL_CONNECT, è quello dovuto all'installazione di un Satellite installato su di una macchina dove l'orario è stato impostato in modo errato. Durante il processo di installazione di Satellite i certificati SSL vengono creati con orari incorretti. Se l'orario di Satellite viene corretto l'orario e la data del certificato potrebbero essere impostati in futuro, marcandoli così come validi.
Per risolvere questo problema, controllate la data e l'ora sui client e sul Satellite con il seguente comando:
# date
I risultati dovrebbero essere quasi tutti identici per tutte le macchine, e all'interno delle finestre di validità "notBefore" e "notAfter" dei certificati. Controllate le date e gli orari del certificato del client con il seguente comando:
# openssl x509 -dates -noout -in /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
Controllate le date e gli orari del certificato del server di Satllite con il seguente comando:
# openssl x509 -dates -noout -in /etc/httpd/conf/ssl.crt/server.crt
Per default, il certificato del server è valido un anno mentre quelli del client sono validi per 10 anni. Se i ceritificati sono incorretti, potrete aspettare il periodo di inizio della validità, se possibile, oppure creare un nuovo certificato, preferibilmente con gli orari del sistema impostati su GMT.
5.5. Registrazione e notifiche
Domanda:
Quali sono i diversi tipi di file di log?
Risposta:
Virtualmente ogni fase riguardante il processo di troubleshooting dovrebbe iniziare controllando il file di log associato oppure i file in questione. Tale processo è in grado di fornire informazioni importantissime sull'attività svolta sul dispositivo o all'interno dell'applicazione utilizzata per controllare la prestazione ed assicurare una configurazione corretta. Consultate la Tabella 5.1, «File di log» per i percorsi di tutti i file di log rilevanti:
Un numero di file di log possono essere disponibili (come ad esempio as /var/log/rhn/rhn_satellite_install.log.1, /var/log/rhn/rhn_satellite_install.log.2, ecc.) all'interno della directory
/var/log/rhn/. Essi sono log ruotati i quali sono file di log creati con una estensione .<NUMBER> quando il file rhn_satellite_install.log corrente raggiunge una misura specificata dal demone logrotate(8) ed i contenuti scritti su di un file di log ruotato. Per esempio rhn_satellite_install.log.1 contiene il file di log ruotato più vecchio mentre rhn_satellite_install.log.4 contiene il log più recente.
Tabella 5.1. File di log
| Componente/Compito | Posizione del file di log |
|---|---|
| Apache Web server | directory /var/log/httpd/ |
| Red Hat Satellite | directory /var/log/rhn/ |
| Red Hat Satellite Installation Program | /var/log/rhn/rhn_satellite_install.log |
| Installazione del database - Database Embedded | /var/log/rhn/install_db.log |
| Popolazione del database | /var/log/rhn/populate_db.log |
| Red Hat Satellite Synchronization Tool | /var/log/rhn/rhn_server_satellite.log |
| Infrastruttura di monitoraggio | directory /var/log/nocpulse/ |
| Notifiche di monitoraggio | Directory /var/log/notification/ |
| Red Hat Network DB Control - Database Embedded | /var/log/rhn/rhn_database.log |
| Red Hat Network Task Engine (taskomatic) | /var/log/messages |
| yum | /var/log/yum.log |
| Transazioni XML-RPC | /var/log/rhn/rhn_server_xmlrpc.log |
Domanda:
Come posso usare
spacewalk-report?
Risposta:
Sono presenti istanze dove gli amministratori avranno bisogno di un riassunto formattato e breve delle proprie risorse Red Hat Satellite per l'inventario dei propri entitlement, sistemi sottoscritti o utenti e organizzazioni. Invece di raccogliere manualmente tali informazioni tramite l'interfaccia web di Satellite, Red Hat Network Satellite include il comando
spacewalk-report per la raccolta e la visualizzazione di informazioni vitali sul Satellite.
Nota
Per poter utilizzare
spacewalk-report è necessario aver installato il pacchetto spacewalk-reports.
spacewalk-report permette agli amministratori di organizzare e visualizzare le notifiche sui contenuti, sistemi e le risorse degli utenti presenti sul Satellite. Utilizzando spacewalk-report sarà possibile generare le notifiche su:
- Inventario dei sistemi - Elenca tutti i sistemi registrati con Satellite.
- Entitlements - Elenca tutte le organizzazioni presenti su Satellite e raggruppate in base agli entitlement del canale o del sistema.
- Errata - Elenca tutti gli errata rilevanti per i sistemi registrati e raggruppa gli errata in base alla severità e al sistema applicato ad un errata particolare.
- Utenti - Elenca tutti gli utenti registrati con Satellite e qualsiasi sistema associato con un particolare utente.
- Cronologia del sistema - Elenca tutti, o un insieme secondario, gli eventi del sistema verificati.
Per ottenere la notifica con un formato CSV eseguire quanto di seguito riportato sulla riga di comando del server di Satellite.
# spacewalk-report report_name
Sono disponibili le seguenti notifiche:
Tabella 5.2. Notifiche spacewalk-report
| Notifica | Invocata come | Descrizione |
|---|---|---|
| Inventario del sistema | inventory | Elenco di sistemi registrati con il server insieme con le informazioni hardware e software. |
| Entitlement | entitlements | Elenca tutte le organizzazioni sul Satellite insieme ai rispettivi entitlement del canale o del sistema. |
| Errata nei canali | errata-channels | Elenca gli errata nei canali |
| Tutti gli Errata | errata-list-all | Elenco completo di tutti gli errata |
| Errata per i sistemi | errata-systems | Elenca gli errata applicabili e qualsiasi sistema registrato interessato |
| Utenti in un sistema | users | Elenca tutti gli utenti registrati con Satellite |
| Sistemi amministrati | users-systems | Elenca i sistemi che gli utenti individuali possono amministrare |
| Alberi kickstart | kickstartable-trees | Elenca gli alberi nei confronti dei quali è possibile eseguire kickstart |
| Cronologia del sistema | system-history | Elenca la cronologia degli eventi relativi al sistema |
| Canali cronologia del sistema | system-history-channels | Elenca la cronologia degli eventi relativi al sistema |
| Cronologia configurazione del sistema | system-history-configuration | Elenca la cronologia degli eventi sulla configurazione del sistema |
| Cronologia entitlement del sistema | system-history-entitlements | Elenca la cronologia degli eventi relativi all'entitlement del sistema |
| Cronologia errata del sistema | system-history-errata | Elenca la cronologia eventi dell'errata relativi al sistema |
| Cronologia di kickstart del sistema | system-history-kickstart | Elenca la cronologia degli eventi di provisioning e kickstart del sistema |
| Cronologia pacchetti del sistema | system-history-packages | Elenca la cronologia degli eventi relativi ai pacchetti del sistema |
Per maggiori informazioni su notifiche singole eseguire
spacewalk-report con --info o --list-fields-info ed il nome della notifica. Verranno riportati i campi possibili per la descrizione e l'elenco presenti nella notifica.
Per maggiori informazioni sarà possibile utilizzare la pagina man
spacewalk-report(8) insieme al parametro --help del programma spacewalk-report per informazioni aggiuntive sulle opzioni ed i metodi di richiamo del programma.
Domanda:
Come posso determinare la mia versione dello schema del database?
Risposta:
Per determinare la versione dello schema del vostro database, eseguire il comando:
# rhn-schema-version
Domanda:
Come faccio a sapere quali sono i tipi di caratteri a mia disposizione?
Risposta:
Per ottenere i diversi tipi di set del carattere del database del vostro Satellite, eseguire il comando:
# rhn-charsets
Domanda:
Perchè l'amministratore non è in grado di ricevere le email?
Risposta:
Se l'amministratore non riceve le email provenienti da Red Hat Satellite confermare gli indirizzi email corretti impostati per
traceback_mail in /etc/rhn/rhn.conf.
Domanda:
Come faccio a modificare il mittente della posta di traceback?
Risposta:
Se la posta di traceback viene marcata da dev-null@rhn.redhat.com, e se desiderate che l'indirizzo sia valido per la vostra organizzazione, includete l'opzione
web.default_mail_from ed il valore appropriato in /etc/rhn/rhn.conf.
5.6. Errori
Domanda:
Visualizzo l'errore "Errore di convalida del certificato satellite" durante l'installazione di Red Hat Satellite. Come posso correggerlo?
Risposta:
L'errore "Errore di convalida del certificato satellite" durante l'installazione di Red Hat Satellite si verifica a causa della presenza di un proxy HTTP nell'ambiente. Per una conferma controllare il file
install.log ed individuare il seguente errore:
ERROR: unhandled exception occurred:
Traceback (most recent call last):
File "/usr/bin/rhn-satellite-activate", line 45, in ?
sys.exit(abs(mod.main() or 0))
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 585, in main
activateSatellite_remote(options)
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 291, in activateSatellite_remote
ret = s.satellite.deactivate_satellite(systemid, rhn_cert)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 603, in __call__
return self._send(self._name, args)
File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 326, in _request
self._handler, request, verbose=self._verbose)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 171, in request
headers, fd = req.send_http(host, handler)
File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 698, in send_http
self._connection.connect()
File "/usr/lib/python2.4/site-packages/rhn/connections.py", line 193, in connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
socket.timeout: timed out
Per risolvere questo problema:
- Eseguire lo script di installazione in modalità scollegato e saltare l'installazione del database precedentemente eseguita:
# ./install.pl --disconnected --skip-db-install
- Aprire
/etc/rhn/rhn.confcon l'editor di testo desiderato ed aggiungere o modificare la seguente riga:server.satellite.rhn_parent = satellite.rhn.redhat.com
Rimuovere la seguente riga:disconnected=1
Se utilizzate un proxy per il collegamento al Red Hat Network sarà necessario aggiungere o modificare le seguenti righe in modo da riflettere le impostazioni del proxy.server.satellite.http_proxy = <hostname>:<port> server.satellite.http_proxy_username = <username> server.satellite.http_proxy_password = <password>
- Attivare nuovamente Satellite in modalità collegato usando il comando
rhn-satellite-activatecome utente root, incluso il percorso del nome del file del certificato di satellite:# rhn-satellite-activate --rhn-cert=/path/to/file.cert
Alternativamente provare ad eseguire lo script
install.pl in modalità collegato includendo l'opzione --answer-file=answer file. Assicurarsi che il file di risposta abbia le informazioni relative al proxy:
rhn-http-proxy = <hostname>:<port> rhn-http-proxy-username = <username> rhn-http-proxy-password = <password>
Domanda:
Visualizzo l'errore "ERRORE: server.mount_point non impostato nel file di configurazione" quando provo ad attivare o sincronizzare Red Hat Satellite. Come lo correggo?
Risposta:
L'errore "ERRORE: server.mount_point non impostato nel file di configurazione" durante l'attivazione o la sincronizzazione di Red Hat Satellite si verifica se il parametro di configurazione
mount_point presente nel file /etc/rhn/rhn.conf non indica alcun percorso della directory, oppure se il percorso stesso indica una posizione non esistente o se non possiede i permessi per l'accesso della directory.
Per risolvere questo problema controllare il valore del parametro di configurazione
mount_point in /etc/rhn/rhn.conf. Se impostato sul valore predefinito di /var/satellite verificare la presenza delle directory /var/satellite e /var/satellite/redhat. Per tutti i valori assicurarsi che il percorso per il file sia corretto e che i permessi siano stati impostati correttamente.
Domanda:
Perchè
cobbler check genera un errore il quale indica che è necessaria una versione diversa di yum-utils?
Risposta:
Talvolta l'esecuzione di
cobbler check può generare un errore simile al seguente:
# cobbler check The following potential problems were detected: #0: yum-utils need to be at least version 1.1.17 for reposync -l, current version is 1.1.16
Questo è un problema conosciuto presente nel pacchetto
reposync di Cobbler. L'errore può essere ignorato senza alcun problema. Il suddetto errore verrà corretto nelle versioni future di Red Hat Satellite.
Domanda:
Visualizzo un errore "versione non supportata" durante il tentativo di attivazione del certificato di Red Hat Satellite. Come posso correggerlo?
Risposta:
Se il certificato di Red Hat Satellite è corrotto allora sarà possibile visualizzare uno dei seguenti errori:
ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 96'>
RHN_PARENT: satellite.rhn.redhat.com
Error reported from RHN: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
ERROR: unhandled XMLRPC fault upon remote activation: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
Invalid satellite certificate
Per risolvere questo problema contattare il supporto di Red Hat per un nuovo certificato.
Domanda:
Visualizzo un errore "Internal Server Error" relativo ad ASCII quando provo a modificare il profilo kickstart. Per quale motivo?
Risposta:
Se avete aggiunto alcuni parametri del kernel al profilo kickstart sarà possibile durante il tentativo di Visualizzare un elenco di profili Kickstart ottenere il seguente Internal Server Error:
'ascii' codec can't encode character u'\u2013'
Questo errore di verifica poichè parte del testo presente nel profilo non è stato riconosciuto correttamente.
Per risolvere questo problema:
- Eseguire ssh direttamente sul server di Satellite come utente root:
# ssh root@satellite.fqdn.com
- Andate alla ricerca del profilo kickstart che causa questo problema controllando le date dei file in
/var/lib/cobbler/config/profiles.de selezionando la data più recente:# ls -l /var/lib/cobbler/config/profiles.d/
- Aprire il profilo con l'editor di testo preferito ed individuare il seguente testo:
\u2013hostname
Modificare la voce nel modo seguente:--hostname
- Salvare le modifiche e chiudere il file.
- Riavviare i servizi di Red Hat Satellite per implementare il profilo aggiornato:
# rhn-satellite restart Shutting down rhn-satellite... Stopping RHN Taskomatic... Stopped RHN Taskomatic. Stopping cobbler daemon: [ OK ] Stopping rhn-search... Stopped rhn-search. Stopping MonitoringScout ... [ OK ] Stopping Monitoring ... [ OK ] Stopping httpd: [ OK ] Stopping tomcat5: [ OK ] Shutting down osa-dispatcher: [ OK ] Shutting down Oracle Net Listener ... [ OK ] Shutting down Oracle DB instance "rhnsat" ... [ OK ] Shutting down Jabber router: [ OK ] Done. Starting rhn-satellite... Starting Jabber services [ OK ] Starting Oracle Net Listener ... [ OK ] Starting Oracle DB instance "rhnsat" ... [ OK ] Starting osa-dispatcher: [ OK ] Starting tomcat5: [ OK ] Starting httpd: [ OK ] Starting Monitoring ... [ OK ] Starting MonitoringScout ... [ OK ] Starting rhn-search... Starting cobbler daemon: [ OK ] Starting RHN Taskomatic... Done.
- Ritornate sull'interfaccia web. Da notare che l'interfaccia potrebbe richiedere un po di tempo per risolvere i servizi ma dovrebbe ritornare alle sue normali funzioni dopo qualche minuto.
Domanda:
Visualizzo errori "host non trovato" o "Impossibile determinare il FQDN". Cosa posso fare ora?
Risposta:
Poichè i file di configurazione di RHN si affidano esclusivamente ai fully qualified domain name (FQDN), è necessario che le applicazioni siano in grado di risolvere il nome di Red Hat Satellite in un indirizzo IP. Red Hat Update Agent, Red Hat Network Registration Client, e Apache Web sono particolarmente propensi a questo tipo di problema con le applicazioni di Red Hat Network, le quali emettono messaggi d'errore del tipo "host non trovato" ed il Web server che emette il seguente "Impossibile determinare il fully qualified domain name del server" quando si verifica un errore durante l'avvio.
Questo errore viene originato generalmente dal file
/etc/hosts. Potrete ottenere una conferma esaminando /etc/nsswitch.conf, il quale definisce i metodi e l'ordine per mezzo dei quali i nomi del dominio vengono risolti. Generalmente, il file /etc/hosts viene prima controllato, seguito dal Network Information Service (NIS), se usato, e dal DNS. Per far si che Apache Web server sia in grado di eseguire un avvio e che le applicazioni client di Red Hat Network funzionino corretamente, una delle suddette entità non deve presentare alcun problema.
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
Come prima cosa, in un editor di testo, rimuovere le informazioni in questione come di seguito riportato:
127.0.0.1 localhost.localdomain.com localhost
Successivamente, salvate il file e cercate di eseguire nuovamente le applicazioni client di Red Hat Network oppure Apache Web server. Se si verificano ancora degli errori identificate esplicitamente l'indirizzo IP di Satellite nel file:
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 attuale di Satellite. Questa operazione dovrebbe risolvere il problema. Ricordate che se viene specificato l'indirizzo IP specifico, il file deve essere aggiornato quando la macchina ottiene un nuovo indirizzo.
Domanda:
Visualizzo il seguente messaggio "This server is not an entitled Satellite" quando provo a sincronizzare il server di Red Hat Satellite. Come posso correggerlo?
Risposta:
Se
satellite-sync riporta che il server non è stato attivato come Red Hat Satellite, ciò significa che non è sottoscritto al canale Red Hat Satellite relativo. Se il sistema è stato appena installato allora assicuratevi che il certificato satellite sia stato attivato sul sistema. Se è stato attivato in precedenza allora risulterà disattivato.
Controllare i canali figlio del sistema per confermare la sottoscrizione al canale Red Hat Satellite. Visualizzare i canali sottoscritti con il seguente comando:
# yum repolist
Attivare nuovamente lo stesso certificato sul vostro Satellite usando questo comando come utente root:
# rhn-satellite-activate -vvv --rhn-cert=/path/to/certificate
5.7. Interfaccia web
Domanda:
Ho problemi con l'interfaccia utente di Red Hat Satellite. Quali file di log devo controllare?
Risposta:
In presenza di errori durante la visualizzazione, programmazione o lavorando con kickstart utilizzando l'interfaccia utente di Red Hat Satellite controllare il file di log
/var/log/tomcat6/catalina.out.
Per tutti gli altri errori con l'interfaccia utente controllare
/var/log/httpd/error_log.
5.8. Anaconda
Domanda:
Visualizzo il seguente errore
Error downloading kickstart file. Qual è il problema e come posso correggerlo?
Risposta:
Questo problema è generalmente il risultato di un errore di rete. Per individuare il problema eseguire il comando
cobbler check e consultare l'output il quale dovrebbe essere simile al seguente:
# cobbler check The following potential problems were detected: #0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils? #1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils? #2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed #3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
Se
cobbler check non fornisce alcuna risposta controllare quanto di seguito riportato:
- Verificare che
httpdsia in esecuzione:service httpd status - Verificare che
cobblerdsia in esecuzione:service cobblerd status - Verificate se siete in grado di recuperare il file di kickstart usando
wgetda un host diverso:wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386-u3:1:Example-Org
Domanda:
Ho un errore di installazione del pacchetto il quale indica
The file chkconfig-1.3.30.1-2.i386.rpm cannot be opened.. Qual è il problema e come posso correggerlo?
Risposta:
I client eseguiranno il recupero del contenuto dal Red Hat Satellite in base al parametro
--url presente nel kickstart. Per esempio:
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Se ricevete un errore da Anaconda il quale indica che non è possibile trovare le immagini o i pacchetti, controllate che l'URL di kickstar sia in grado di generare una risposta
200 OK. Per fare questo eseguite wget nei confronti del file posizionato sull'URL in questione:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3 --2011-08-19 15:06:55-- http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3 Resolving satellite.example.com... 10.10.77.131 Connecting to satellite.example.com|10.10.77.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 0 [text/plain] Saving to: `ks-rhel-i386-server-5-u3.1' 2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
Se ricevete una risposta diversa da
200 OK, controllate i log d'errore per individuare il problema. Sarà possibile altresì controllare il file che Anaconda ha cercato di scaricare controllando il file access_log:
# grep chkconfig /var/log/httpd/access_log 10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 5-u3/Server /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig- 1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig- 1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19" 10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
Se le richieste non vengono visualizzate nel file
access_log il sistema potrebbe avere problemi con l'impostazione del networking. Se invece le richieste possono essere visualizzate e le stesse generano un errore, allora controllate i log d'errore.
È possibile scaricare manualmente i file in modo da controllare se il pacchetto è disponibile:
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm
5.9. Messaggi di Traceback
Domanda:
Ricevo delle email con oggetto "WEB TRACEBACK". Come mi devo comportare?
Risposta:
Una email di traceback tipica potrebbe somigliare alla seguente:
Subject: WEB TRACEBACK from satellite.example.com Date: Wed, 19 Aug 2011 20:28:01 -0400 From:Red Hat Satellite <dev-null@redhat.com> To: admin@example.com java.lang.RuntimeException: XmlRpcException calling cobbler. at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72) at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76) at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54) at org.quartz.core.JobRunShell.run(JobRunShell.java:203) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed. at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434) at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376) at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165) at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69) ... 4 more Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236) at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420) ... 7 more
Ciò indica la presenza di un errore di comunicazione tra Cobbler ed il servizio
taskomatic. Provate a controllare quanto segue:
- Verificare che
httpdsia in esecuzione:# service httpd status - Verificare che
cobblerdsia in esecuzione:# service cobblerd status - Verificate che non ci siano regole per il firewall in grado di impedire i collegamenti
localhost.
5.10. Registrazione
Domanda:
Il comando
rhnreg_ks fallisce quando eseguito ed indica il seguente messaggio, ERROR: unable to read system id. Qual è il problema?
Risposta:
Alla fine del file di kickstart è presente una sezione
%post la quale registra la macchina con Red Hat Satellite:
# begin Red Hat management server registration mkdir -p /usr/share/rhn/ wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/* rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d # end Red Hat management server registration
Seguendo l'ordine con il quale è stato aggiunto, ciò comporterà una:
- Creazione della directory in modo da contenere il certificato SSL personalizzato usato dal Red Hat Satellite.
- Ripristino del certificato SSL da usare durante la registrazione.
- Verrà eseguita una ricerca e sostituzione delle stringhe del certificato SSL dai file di configurazione
rhn-registere successivamente verrà eseguita una registrazione con Red Hat Satellite usando il certificato SSL ed una chiave di attivazione. Ogni profilo kickstart include una chiave di attivazione per l'assegnazione al sistema dei canali figlio e di base corretti, ottenendo altresì gli entitlement corretti. Se si esegue il reprovisioning di un sistema esistente la chiave di attivazione assicurerà una associazione con il profilo del sistema precedente.
Se il comando
rhnreg_ks fallisce sarà possibile visualizzare errori simili al seguente all'interno del file di log ks-post.log:
ERROR: unable to read system id.
Questi errori si verificano anche se l'utente cercherà di eseguire
rhn_check ed il sistema non è registrato con Red Hat Satellite.
Il modo migliore per risolvere il problema è quello di controllare il file di kickstart ed eseguire un copia ed incolla delle quattro fasi direttamente al prompt del comando dopo aver completato kickstart. Così facendo verranno generati i messaggi d'errore più dettagliati per assistervi all'individuazione del problema.
5.11. Kickstart e Snippet
Domanda:
Qual è la struttura della directory per kickstart?
Risposta:
Il percorso di base dove sono archiviati i file di kickstart è
/var/lib/rhn/kickstarts/. All'interno di questa directory i kickstart raw si trovano nella sottodirectory upload, ed i kickstart basati sul wizard si troveranno nella sottodirectory wizard:
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
Domanda:
Qual è la struttura della directory per gli snippet di Cobbler?
Risposta:
Gli snippet di Cobbler sono archiviati in
/var/lib/rhn/kickstarts/snippets. Cobbler è in grado di accedere gli snippet usando il link simbolico /var/lib/cobbler/snippets/spacewalk.
Snippets: /var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name
Importante
Non modificate la posizione delle directory snippet e del kickstart di Cobbler poichè gli RPM di Red Hat Satellite accettano solo la loro posizione predefinita.
5.12. Monitoring
Domanda:
Sono disponibili alcuni tool per assistere a determinare la causa degli errori relativi al monitoring?
Risposta:
Anche se tutte le attività relative al monitoring vengono condotte attraverso l'interfaccia di Satellite, Red Hat permette l'accesso ad alcuni tool di diagnosi della linea di comando in grado di determinare la causa dell'errore. Per poter utilizzare i suddetti tool è necessario diventare un utente
nocpulse su Satellite che esegue il monitoring.
Come prima cosa eseguite la registrazione all'interno di Satellite come utente root. Successivamente selezionate l'utente
nocpulse attraverso il seguente comando:
su - nocpulse
Per eseguire il troubleshooting di un probe è necessario ottenere l'ID del probe stesso. Potrete ottenerlo eseguendo
rhn-catalog sul server di Red Hat Satellite come l'utente nocpulse. L'output somiglierà al seguente:
2 ServiceProbe on example1.redhat.com (199.168.36.245): test 2 3 ServiceProbe on example2.redhat.com (199.168.36.173): rhel2.1 test 4 ServiceProbe on example3.redhat.com (199.168.36.174): SSH 5 ServiceProbe on example4.redhat.com (199.168.36.175): HTTP
L'ID di probe risulta essere il primo numero presente sulla riga, mentre il suo nome (presente nell'interfaccia di Satellite), risulta essere la voce finale della stessa riga. Per esempio, l'ID 5 di probe corrisponde al probe HTTP.
Ancora, potete passare le opzioni
--commandline (-c) e --dump (-d), insieme all'ID di probe, a rhn-catalog, in modo da ottenere informazioni aggiuntive:
rhn-catalog --commandline --dump 5
L'opzione
--commandline produce i parametri di comando impostati per probe, mentre --dump riprende qualsiasi altra informazione, incluso i limiti alert, i metodi e gli intervalli di notifica.
Il comando sopra riportato risulterà in un output simile al seguente:
5 ServiceProbe on example4.redhat.com (199.168.36.175 ):
linux:cpu usage
Run as: Unix::CPU.pm --critical=90 --sshhost=199.168.36.175
--warn=70 --timeout=15 --sshuser=nocpulse
--shell=SSHRemoteCommandShell --sshport=4545
Una volta ottenuto l'ID utilizzatelo con
rhn-rhnprobe per poter esaminare l'output del probe.
Domanda:
Come posso interpretare l'output di
rhn-runprobe?
Risposta:
Ora che siete riusciti ad ottenere l'ID di probe tramite
rhn-catalog, potrete utilizzarlo insieme con rhn-runprobe, in modo da poter esaminare l'output completo di probe. Notate che per default, rhn-runprobe funziona in modalità test, ciò significa che nessun risultato verrà inserito all'interno del database. Ecco le sue opzioni:
Tabella 5.3. Opzioni rhn-runprobe
| Opzione | Descrizione |
|---|---|
--help | Elenca le opzioni disponibili ed esce. |
--probe=PROBE_ID | Esegue probe con questo ID. |
--prob_arg=PARAMETER | Annulla ogni parametro di probe dal database. |
--module=PERL_MODULE | Nome del pacchetto di un codice alternativo da eseguire. |
--log=all=LEVEL | Imposta il livello di log per un pacchetto o per un prefisso. |
--debug=LEVEL | Imposta un livello di debugging numerico. |
--live | Esegue il probe, ordina i dati ed invia le notifiche (se necessario). |
È necessario includere l'opzione
--probe e --log con i relativi valori. L'opzione --probe assume il probeID come proprio valore e l'opzione --log prende come valore "all" (per tutti i run level), ed il livello di verbosità numerico. Ecco un esempio:
rhn-runprobe --probe=5 --log=all=4
Il comando sopra riportato necessita di un output di probe per probeID 5, per tutti i run level, con un livello più alto di verbosità.
In modo più specifico, potrete fornire i parametri di comando derivati da
rhn-catalog:
rhn-runprobe 5 --log=all=4 --sshuser=nocpulse --sshport=4545
Ciò produrrà un output verbose che riproduce il tentativo di esecuzione di probe. Gli errori vengono chiaramente identificati.
5.13. Satellite di organizzazioni multiple e Certificati satellite
Domanda:
Come posso registrare i miei sistemi in un ambiente con organizzazioni multiple quando non sono in possesso di un numero sufficiente di entitlement nel mio Certificati Satellite?
Risposta:
In alcune situazioni vi troverete costretti a rimuovere gli entitlement avendo a disposizione una quantità di tempo molto limitata, e possibilmente senza avere accesso ad ogni organizzazione per poterlo fare da soli. In questa circostanza è disponibile una opzione in Multi-Org Satellite, la quale permette all'amministratore di Satellite di ridurre gli entitlement rispetto all'utilizzo previsto. Per fare questo è necessario essere registrati all'interno dell'organizzazione amministrativa.
Per esempio, dopo aver eseguito il login all'interno dell'organizzazione amministrativa, se al vostro certificato risultano mancare cinque entitlement di gestione del sistema per essere in grado di coprire tutti i sistemi registrati sul vostro Satellite, allora verranno rimossi gli entitlement ai cinque sistemi registrati per ultimi all'organizzazione in questione. Di seguito viene descritto il seguente processo:
- Nel file
/etc/rhn/rhn.conf, impostareweb.force_unentitlementsu 1. - Riavviare Satellite.
- Ridurre gli entitlement assegnati alle organizzazioni desiderate tramite la scheda Sottoscrizioni di ogni organizzazione, o tramite le schede Organizzazioni dei singoli entitlement.
- Un certo numero di sistemi all'interno dell'organizzazione dovrebbe avere uno stato di unentitled 'senza entitlement'. Il numero di sistemi senza gli entitlement all'interno di una organizzazione, dovrebbe essere uguale alla differenza tra il numero totale di entitlement rimossi dall'organizzazione, ed il numero di entitlement non applicati sui sistemi da parte dell'organizzazione.Per esempio, se avete rimosso 10 entitlement dall'organizzazione nella fase 3 e l'organizzazione possiede 4 entitlement non utilizzati dai sistemi, allora 6 sistemi presenti nell'organizzazione saranno sprovvisti di entitlement.
Se siete in possesso del numero necessario di entitlement dovreste essere in grado di attivare il vostro certificato Satellite. Da notare che la modifica della variabile
web.force_unentitlement è necessaria solo per la riduzione degli entitlement assegnati di una organizzazione al di sotto del numero di entitlement utilizzati. Se una organizzazione possiede un numero maggiore di entitlement rispetto a quelli da essa utilizzati attivamente, allora non sarà necessario impostare questa variabile per una loro rimozione.
Domanda:
Sono presenti alcuni entitlement supplementari su Certificati Satellite che non vengono utilizzati. Cosa può succedere ai suddetti entitlement?
Risposta:
Se avete ricevuto un nuovo certificato Satellite con un numero maggiore di entitlement rispetto a quelli utilizzati dalle organizzazioni sul vostro Satellite, qualsiasi entitlement aggiuntivo verrà assegnato all'organizzazione amministrativa. Se eseguite un login nell'interfaccia web come amministratore di Satellite, sarà possibile assegnare i suddetti entitlement ad altre organizzazioni. Gli entitlement precedentemente assegnati ad altre organizzazioni non verranno interessati.
5.14. Installazione e configurazione del Proxy
Domanda:
Dopo aver configurato il Red Hat Network Package Manager come posso determinare se i pacchetti locali sono stati aggiunti con successo al canale di Red Hat Network privato?
Risposta:
Utilizzate il comando
rhn_package_manager -l -c "name_of_private_channel", per elencare i pacchetti del canale privato conosciuti al Satellite. Oppure visitate l'interfaccia di Satellite.
Dopo aver sottoscritto un sistema registrato su di un canale privato è possibile eseguire il comando
yum --disablerepo="*" --enablerepo="your_repo_name" list available sul sistema registrato, andando alla ricerca dei pacchetti provenienti dal canale Satellite privato.
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 Red Hat Satellite Proxy. 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 Red Hat Satellite Proxy. È 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 Red Hat Satellite Proxy è una estensione di Apache. Consultare la sezione dei File di Log della Red Hat Satellite Proxy Installation Guide per la posizione relativa.
Domanda:
La configurazione del mio Red Hat Satellite Proxy 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.
Consultare i file di log. È disponibile un elenco nella sezione dei File di Log della Red Hat Satellite Proxy Installation Guide.
Domanda:
Come risolvo i problemi generali presenti in the Red Hat Satellite Proxy?
Risposta:
Per iniziare il troubleshooting di problemi generali esaminate i file di log oppure i file relativi sul componente che presenta gli errori.
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 riceve le email provenienti da Red Hat Satellite Proxy confermare gli indirizzi email corretti impostati per
traceback_mail in /etc/rhn/rhn.conf.
Domanda:
Sul mio Red Hat Satellite Proxy ho riscontrato un errore di tipo "Host Not Found"/"Could not Determine FQDN". Cosa posso fare?
Risposta:
Poichè i file di configurazione di RHN si affidano esclusivamente ai fully qualified domain name (FQDN), è necessario che le applicazioni siano in grado di risolvere il nome di Red Hat Satellite Proxy in un indirizzo IP. Red Hat Update Agent, Red Hat Network Registration Client, e Apache Web sono particolarmente propensi a questo tipo di problema con le applicazioni di Red Hat Network, le quali emettono messaggi d'errore del tipo "host non trovato" ed il Web server che emette il seguente "Impossibile determinare il fully qualified domain name del server" quando si verifica un errore durante l'avvio.
Questo errore viene originato dal file
/etc/hosts. Potrete ottenere una conferma esaminando /etc/nsswitch.conf, il quale definisce i metodi e l'ordine per mezzo dei quali i nomi del dominio vengono risolti. Generalmente, il file /etc/hosts viene prima controllato, seguito dal Network Information Service (NIS), se usato, e dal DNS. Per far si che Apache Web server sia in grado di eseguire un avvio e che le applicazioni client di Red Hat Network funzionino corretamente, una delle suddette entità non deve presentare alcun problema.
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
Salvate il file e cercate di eseguire nuovamente le applicazioni client di Red Hat Network oppure Apache Web server. Se si verificano ancora degli errori identificate esplicitamente l'indirizzo IP del Proxy nel file:
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.
Domanda:
Ho alcuni problemi con Red Hat Satellite Proxy e con la connessione di rete. Cosa posso fare?
Risposta:
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.rpmsia stato installato su Red Hat Satellite Proxy e che ilrhn-org-trusted-ssl-cert-*.noarch.rpmcorrispondente o il certificato raw CA SSL public (client) sia stato installato su tutti i sistemi client. - Verificate che i sistemi client siano stati configurati in modo da utilizzare il certificato appropriato.
- Se si utilizzano uno o più Red Hat Satellite Proxy, assicuratevi che ogni certificato SSL sia stato creato correttamente. Se si utilizza il Red Hat Satellite Proxy insieme con un Red Hat Satellite, 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 Red Hat Satellite Client Configuration Guide per istruzioni specifiche.
- Se il Red Hat Satellite Proxy 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 Requisiti aggiuntivi della Red Hat Satellite Proxy Installation Guide.
Domanda:
Ho alcuni problemi con la disponibilità dei pacchetti e con la corruzione degli oggetti. Cosa posso controllare?
Risposta:
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 Red Hat Satellite Proxy presenta due tipi di cache: una per Squid e l'altra per l'autenticazione.
La cache Squid è disponibile in
/var/spool/squid/. Per azzerarla:
- Arrestare Apache Web server:
service httpd stop - Arrestare il server Squid:
service squid stop - Cancellare il contenuto della directory:
rm -fv /var/cache/rhn/* - 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 Red Hat Network.
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/* Nota
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 Red Hat Satellite. Il modo migliore per fare questo è quello di rendere noto i vostri parametri di configurazione di Satellite, i file di log, e le informazioni del database, e inviare questo pacchetto direttamente a Red Hat.
Red Hat Network fornisce uno strumento della linea di comando idoneo a questo scopo. Il Satellite Diagnostic Info Gatherer, comunemente conosciuto tramite il suo comando
satellite-debug. Per poter utilizzare questo tool, emettere il suddetto comando come utente root. Così facendo verranno visualizzate alcune parti di informazione ed una tarball singola come di seguito riportato:
# satellite-debug
Collecting and packaging relevant diagnostic information.
Warning: this may take some time...
* copying configuration information
* copying logs
* querying RPM database (versioning of Red Hat Satellite, etc.)
* querying schema version and database character sets
* get diskspace available
* timestamping
* creating tarball (may take some time): /tmp/satellite-debug.tar.bz2
* removing temporary debug tree
Debug dump created, stored in /tmp/satellite-debug.tar.bz2
Deliver the generated tarball to your Red Hat Network contact or support channel.
Una volta terminato, inviate una email del nuovo file dalla directory
/tmp/, al vostro rappresentante di Red Hat per una diagnosi immediata.
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 Red Hat Satellite è 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. Probe
È possibile eseguire i probe sui sistemi aventi un entitlement di Monitoring per confermare in modo costante il loro stato e la loro efficacia operativa. La suddetta sezione elenca i probe disponibili, suddivisi in base al gruppo di comando, come ad esempio Apache.
Numerosi probe in grado di monitorare gli aspetti interni dei vostri sistemi (come ad esempio il probe Linux::Disk Usage), invece di occuparsi dei componenti esterni (come il probe Network Services::SSH) , richiedono l'installazione del Red Hat Network monitoring daemon (
rhnmd). Tale requisito è presente all'interno del riferimento del probe individuale.
Ogni probe presenta il proprio riferimento in questa sezione che identifica i campi richiesti (contrassegnati da un *), i valori predefiniti, ed i limiti che possono essere impostati in modo da attivare i messaggi di allerta. In modo simile, l'inizio di ogni sezione del gruppo di comando, contiene delle informazioni applicabili a tutti i probes presenti in quel gruppo. La sezione Sezione A.1, «Direttive su Probe» affronta le direttive generali, le sezioni restanti esaminano i probe in modo individuale.
Nota
Quasi tutti i probes utilizzano il Transmission Control Protocol (TCP) come proprio protocollo di trasporto. Delle eccezioni sono presenti all'interno dei riferimenti probe individuali.
A.1. Direttive su Probe
Le seguenti direttive riportano i significati dei diversi stati di probe, e forniscono delle indicazioni su come impostare i limiti per i vostri probe.
Il seguente elenco fornisce una breve descrizione sul significato dello stato di probe:
- Sconosciute
- I probe che non sono in grado di raccogliere le metriche necessarie per determinare lo stato. La maggior parte dei probe entrano in questo stato, quando eccedono il propio periodo di timeout, essi altresì possono essere configurati in modo incorretto.
- Pending
- Dati dei probe non riceuti da Red Hat Satellite. È normale per i nuovi probe trovarsi nel suddetto stato. Tuttavia, se tutti i probe si trovano in questo stato l'infrastruttura del monitoring può presentare un errore.
- OK
- I probe eseguiti senza alcun errore. Questo è lo stato desiderato per tutti i probe.
- Avvertenza
- I probes che hanno oltrepassato i propri limiti di WARNING.
- Critico
- I probe che hanno superato i propri limiti CRITICAL, o che hanno raggiunto uno stato critico per altre ragioni. (Alcuni probe entrano in uno stato critico quando superano il proprio periodo di timeout.)
Durante l'aggiunta dei probe, selezionate i limiti oltre i quali verrà notificata a voi ed ai vostri amministratori la presenza di problemi all'interno della vostra infrastruttura. I periodi di timeout vengono inseriti in secondi se non diversamente indicato. Le eccezioni a queste regole sono presenti all'interno dei riferimenti probe individuali.
Importante
Alcuni probe presentano dei limiti basati sul tempo. Per far si che i limiti CRITICAL eWARNING basati su questo criterio funzionino in modo corretto, i propri valori non possono eccedere la quantità di tempo selezionato per il periodo di timeout. In caso contrario verrà ritornato uno stato UNKNOWN in tutti i casi di latenza estesa, annullando così tutti i limiti predisposti. Per questa ragione, Red Hat consiglia vivamente di accertarsi che i periodi di timeout eccedano tutti i limiti basati sul tempo limite.
Eseguire i probe per un periodo di tempo senza alcuna notifica, in modo da stabilire la prestazione di base dei sistemi. Anche se i valori predefiniti forniti possono far fronte alle vostre esigenze, ogni organizzazione presenta un ambiente diverso che potrebbe aver bisogno di una modifica dei limiti.
A.2. Apache 1.3.x e 2.0.x
I probes presenti in questa sezione possono essere applicati su esempi di Apache web server. Anche se i valori di default presuppongono l'applicazione dei suddetti probes utilizzando HTTP standard, è possibile anche utilizzarli attraverso collegamenti sicuri, semplicemente modificando il protocollo di applicazione su
https, e la porta su 443.
A.2.1. Apache::Processes
Il probe Apache::Processes controlla i processi eseguiti su di un Apache web server, e raccoglie altresì le seguenti metriche:
- Data Transferred Per Child - Registra le informazioni sul trasferimento dati solo su processi figli individuali. Un processo figlio viene creato da un altro processo o da un processo genitore.
- Data Transferred Per Slot - La quantità di dati comulativi trasferiti da un processo figlio che esegue un riavvio. Il numero di alloggiamenti viene configurato all'interno del file
httpd.conf, utilizzando l'impostazioneRichiesteMaxPerFiglio
La direttiva
ExtendedStatus presente nel file httpd.conf del web server, deve essere impostata su On per un funzionamento corretto di questo probe.
Tabella A.1. Impostazione di Apache::Processes
| Campo | Valore |
|---|---|
| Protocollo di attivazione* | http |
| Porta* | 80 |
| Nome del percorso* | /server-status |
| UserAgent* | NOCpulse-ApacheUptime/1.0 |
| Nome utente | |
| Password | |
| Timeout* | 15 |
| Critical Megabytes Massimi Trasferiti per Figlio | |
| Warning Megabytes Massimi Trasferiti per Figlio | |
| Critical Megabytes Massimi Trasferiti per Alloggiamento | |
| Warning Megabytes Massimi Trasferiti per Alloggiamento |
A.2.2. Apache::Traffic
Il probe Apache::Traffic controlla le richieste eseguite su di un Apache web server e raccoglie altresì le seguenti metriche:
- Current Requests - Il numero di richieste processate dal server al momento di esecuzione del probe.
- Request Rate - Numero di ingressi al server, espressi in secondi, dall'ultima esecuzione di probe.
- Traffic - Quantità di traffico, espressa in kilobytes per secondo, che il server è stato in grado di processare dall'ultima esecuzione del probe.
La direttiva
ExtendedStatus presente nel file httpd.conf del web server, deve essere impostata su On per un funzionamento corretto di questo probe.
Tabella A.2. Impostazioni Apache::Traffic
| Campo | Valore |
|---|---|
| Protocollo di attivazione* | http |
| Porta* | 80 |
| Nome del percorso* | /server-status |
| UserAgent* | NOCpulse-ApacheUptime/1.0 |
| Nome utente | |
| Password | |
| Timeout* | 15 |
| Critical Richieste Massime Correnti (numero) | |
| Warning Richieste Massime Attuali (numero) | |
| Critical Rapporto Massimo di Richiesta (eventi per secondo) | |
| Warning Numero Massimo di Richieste (eventi per secondo) | |
| Critical Traffico Massimo (kilobytes per secondo) | |
| Warning Traffico Massimo (kilobytes per second) |
A.2.3. Apache::Uptime
Il probe Apache::Uptime conserva il tempo cumulativo dall'ultimo avvio del Web server. Questo probe non raccoglie alcuna metrica, esso infatti ha la funzione di controllare i service level agreements (SLA).
Tabella A.3. Impostazioni di Apache::Uptime
| Campo | Valore |
|---|---|
| Protocollo di attivazione* | http |
| Porta* | 80 |
| Nome del percorso* | /server-status |
| UserAgent* | NOCpulse-ApacheUptime/1.0 |
| Nome utente | |
| Password | |
| Timeout* | 15 |
A.3. BEA WebLogic 6.x e versione più recente
I probes presenti in questa sezione (con l'eccezione del JDBC Connection Pool), possono essere configurati in modo da controllare le proprietà di qualsiasi server BEA WebLogic 6.x o più recente (di Amministrazione o Gestito) in esecuzione su di un dato host, anche se quest'ultimo risulta presente in un ambiente clustered. Il controllo di un cluster viene eseguito inviando tutte le interrogazioni SNMP ad un Server di Amministrazione del dominio, e successivamente interrogando i propri Server Gestiti in modo da ottenere i dati individuali.
Per poter ottenere un più alto livello di granularità, il parametro BEA Domain Admin Server deve essere utilizzato per differenziare il Server di Amministrazione che riceve le interrogazioni SNMP, ed il Server di Gestione interessato dal probe specifico. Se l'host da verificare risulta essere il Server di Amministrazione, allora il parametro BEA Domain Admin Server può essere lasciato in bianco, ed entrambe le interrogazioni SNMP ed il probe verranno inviati ad allo stesso.
Se l'host da verificare è un Server Gestito, allora l'indirizzo IP del Server di Amministrazione deve essere fornito all'interno del parametro BEA Domain Admin Server, ed il nome del Server Gestito dovrebbe essere incluso nel parametro BEA Server Name, ed appeso alla fine del campo SNMP Community String. Tale operazione causerà l'invio delle interrogazioni SNMP all'host del Server di Amministrazione, come necessario, ridirezionando però il probe specifico all'host del Server Gestito.
È da notare che la community string necessaria per i probes eseguiti nei confronti degli host dei Server Gestiti, deve presentare la forma seguente,
community_prefix@managed_server_name, in questo modol'interrogazione SNMP sarà in grado di ritornare i risultati necessari per il Server Gestito desiderato. Per finire, SNMP deve essere abilitato su ogni sistema monitorato. Il supporto SNMP può essere abilitato e configurato attraverso la console WebLogic.
Consultare la documentazione presente con il vostro server BEA, oppure di consultare le informazioni presenti sul sito web BEA, per maggiori dettagli sulla community string naming conventions di BEA.
A.3.1. BEA WebLogic::Execute Queue
Il probe BEA WebLogic::Execute Queue controlla il WebLogic execute queue e fornisce le seguenti metriche:
- Idle Execute Threads - Numero di esecuzioni del thread in uno stato idle.
- Queue Length - Numero di richieste presenti nella coda.
- Request Rate - Numero di richieste per secondo.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.4. Impostazioni di BEA WebLogic::Execute Queue
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Nome della coda* | default |
| Critical Idle Massimo di Esecuzione dei Thread | |
| Warning Idle Massimo di Esecuzione dei Threads | |
| Critical Lunghezza massima della coda | |
| Warning Lunghezza Massima della Coda | |
| Critical Rapporto Massimo di Richiesta | |
| Warning Rapporto Massimo di Richiesta |
A.3.2. BEA WebLogic::Heap Free
Il probe BEA WebLogic::Heap Free raccoglie la seguente metrica:
- Heap Free - La percentuale di spazio libero disponibile.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.5. Impostazioni di BEA WebLogic::Heap Free
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Critical Heap Massimo disponibile | |
| Warning Heap Massimo disponibile | |
| Warning Heap Minimo disponibile | |
| Critical Heap Minimo Disponibile |
A.3.3. BEA WebLogic::JDBC Connection Pool
Il probe BEA WebLogic::JDBC Connection Pool controlla il pool di Java Database Connection (JDBC) presente solo su di un domain Admin Server (e non sui Managed Servers),e raccolgie le seguenti metriche:
- Connections - Il numero di collegamenti al JDBC.
- Connections Rate - Velocità con la quale vengono eseguiti i collegamenti per il JDBC, misurato in collegamenti al secondo.
- Waiters - Numero di sessioni in attesa di collegamento al JDBC.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.6. Impostazioni di BEA WebLogic::JDBC Connection Pool
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| JDBC Pool Name* | MyJDBC Connection Pool |
| Critical Collegamenti Massimi | |
| Warning Collegamenti Massimi | |
| Critical Rapporto Massimo di Collegamento | |
| Warning Velocità di Collegamento Massima | |
| Critical Waiter Massimo | |
| Warning Waiter Massimo |
A.3.4. BEA WebLogic::Server State
Il probe BEA WebLogic::Server State controlla lo stato corrente di un Web server BEA Weblogic. Se il probe non è in grado di eseguire un colegamento col server, verrà riportato uno stato CRITICAL.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.7. Impostazioni di BEA WebLogic::Server State
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* |
A.3.5. BEA WebLogic::Servlet
Il probe BEA WebLogic::Servlet controlla le prestazioni di un servlet particolare impiegato su di un server WebLogic, altresì è in grado di raccogliere le seguenti metriche:
- High Execution Time - La quantità più elevata di tempo, espressa in millisecondi, necessaria al servelt per essere eseguito dopo l'avvio del sistema.
- Low Execution Time - La quantità di tempo più bassa espressa in millisecondi, necessaria al servlet per essere eseguito dopo l'ultimo riavvio.
- Execution Time Moving Average - Una media di spostamento del tempo di esecuzione.
- Execution Time Average - Un tempo di esecuzione medio standard.
- Velocità di Ricarica - Numero di volte al minuto che il servlet specificato viene ricaricato.
- Invocation Rate - Il numero di volte che il servlet specificato esegue una invocazione al minuto.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.8. Impostazioni di BEA WebLogic::Servlet
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 1 |
| BEA Domain Admin Server | |
| BEA Server Name* | myserver |
| Nome del servlet* | |
| Critical Tempo di Esecuzione Alto Massimo | |
| Warning Tempo di Esecuzione Alto Massimo | |
| Critical Tempo Medio Massimo di Esecuzione dello Spostamento | |
| Warning Tempo Medio di Esecuzione dello Spostamento Massimo |
A.4. Generale
I probe presenti in questa sezione sono stati ideati per controllare gli aspetti di base dei vostri sistemi. Durante la loro applicazione, assicuratevi che i limiti di tempo relativi, non eccedano la quantità di tempo associata al periodo di timeout. In caso contrario, verrà ritornato uno stato di UNKNOWN in tutti i casi di latenza estesa, annullando così tutti i limiti.
A.4.1. General::Remote Program
Il probe General::Remote Program vi permette di eseuire un qualsiasi comando o script sul vostro sistema, ottenendo così una stringa dello stato. Da notare che il messaggio risultante sarà limitato a 1024 byte.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.9. Impostazioni di General::Remote Program
| Campo | Valore |
|---|---|
| Comando* | |
| OK Exit Status* | 0 |
| Warning Stato di Abbandono* | 1 |
| Critical Stato di Abbandono* | 2 |
| Timeout | 15 |
A.4.2. General::Remote Program with Data
Il probe General::Remote Program with Data vi permette di eseguire qualsiasi comando o script sul vostro sistema, ottenendo così un valore insieme ad una stringa sullo stato. Per usare il suddetto probe è necessario includere alcuni codici XML all'interno del vostro script. Altresì esso è in grado di supportare le seguenti tag XML:
- <perldata> </perldata>
- <hash> </hash>
- <item key =" "> </item>
Il programma remoto avrà bisogno di eseguire un output di alcune iterazioni del seguente codice su
STDOUT:
<perldata> <hash> <item key="data">10</item> <item key="status_message">status message here</item> </hash> </perldata>
Il valore necessario per
data, è il punto dati da inserire nel database per la famiglia time-series. status_message è facoltativo, e può essere eseguito sotto forma di stringa desiderata, con una lunghezza massima di 1024 byte. I programmi remoti che non includono uno status_message, riporteranno ancora il valore e lo stato ritornato.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe. XML è 'case-sensitive'. Il nome della chiave del simbolo data non può essere modificato, e deve essere in grado di raccogliere un valore numero, per utilizzarlo a sua volta come proprio velore.
Tabella A.10. Impostazioni di General::Remote Program with Data
| Campo | Valore |
|---|---|
| Comando* | |
| OK Exit Status* | 0 |
| Warning Stato di Abbandono* | 1 |
| Critical Stato di Abbandono* | 2 |
| Timeout | 15 |
A.4.3. General::SNMP Check
Il probe General::SNMP Check controlla il vostro server SNMP, specificando un object identifier (OID) singolo suddiviso da punti (come ad esempio
1.3.6.1.2.1.1.1.0), ed un limite associato con il valore ritornato. Esso è in grado di raccogliere la seguente metrica:
- Remote Service Latency - Il tempo necessario, espresso in secondi, al server SNMP per rispondere ad una richiesta di collegamento.
Requisiti - SNMP deve essere in eseccuzione sul sistema monitorato per poter eseguire questo probe. Per i valori limiti è possibile utilizzare solo valori interi.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.11. Impostazioni di General::SNMP Check
| Campo | Valore |
|---|---|
| SNMP OID* | |
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 2 |
| Timeout* | 15 |
| Critical Valore Massimo | |
| Warning Valore Massimo | |
| Warning Valore Minimo | |
| Critical Valore Minimo |
A.4.4. General::TCP Check
Il probe General::TCP Check controlla il vostro server TCP verificando la sua connessione ad un sistema, tramite il numero di porta specificato. Esso è in grado di raccogliere la seguente metrica:
- Remote Service Latency - La quantità di tempo necessaria, espressa in secondi, al server TCP per rispondere ad una richiesta di collegamento.
Il probe passerà la stringa specificata all'interno del campo Invio, previa instaurazione del collegamento. Esso sarà in grado di anticipare la risposta dal sistema, la quale dovrebbe includere la sottostringa specificata all'interno del campo In attesa. Se la stringa attesa non viene trovata, il probe ritornerà uno stato CRITICAL.
Tabella A.12. Impostazione di General::TCP Check
| Campo | Valore |
|---|---|
| Invio | |
| In attesa | |
| Porta* | 1 |
| Timeout* | 10 |
| Critical Latenza Massima | |
| Warning Latenza Massima |
A.4.5. General::UDP Check
Il probe General::UDP Check verifica il vostro server UDP, controllando il suo collegamento ad un sistema tramite una porta specificata. Esso è in grado di raccogliere la seguente metrica:
- Remote Service Latency - La quantità di tempo necessaria, espressa in secondi, al server UDP, per rispondere ad una richiesta di collegamento.
Il probe passerà la stringa specificata all'interno del campo Invio, previa instaurazione del collegamento. Esso sarà in grado di anticipare la risposta dal sistema, la quale dovrebbe includere la sottostringa specificata all'interno del campo In attesa. Se la stringa attesa non viene trovata, il probe ritornerà uno stato CRITICAL.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.13. Impostazioni General::UDP Check
| Campo | Valore |
|---|---|
| Porta* | 1 |
| Invio | |
| In attesa | |
| Timeout* | 10 |
| Critical Latenza Massima | |
| Warning Latenza Massima |
A.4.6. General::Uptime (SNMP)
Il probe General::Uptime (SNMP) registra l'orario dell'ultimo avvio del dispositivo. Esso utilizza SNMP object identifier (OID) per ottenere questo valore. L'unico messaggio di errore che riporta è quello di UNKNOWN.
Requisiti - Per poter eseguire questo probe, SNMP deve essere in esecuzione sul sistema monitorato, e l'accesso all'OID deve essere abilitato.
Questo protocollo di trasporto di probe è User Datagram Protocol (UDP).
Tabella A.14. Impostazioni General::Uptime (SNMP)
| Campo | Valore |
|---|---|
| SNMP Community String* | pubblico |
| Porta SNMP* | 161 |
| Versione SNMP* | 2 |
| Timeout* | 15 |
A.5. Linux
Il probe in questa sezione controlla gli aspetti essenziali dei vostri sistemi Linux, dall'uso della CPU alla memoria virtuale. Applicateli sui sistemi mission-critical, per poter ottenere i messaggi di avvertimento prima del verificarsi di un errore.
Diversamente da altri gruppi probe, i quali possono o meno aver bisogno di Red Hat Network monitoring daemon, su ogni probe di Linux il demone
rhnmd deve essere in esecuzione sul sistema monitorato.
A.5.1. Linux::CPU Usage
Il probe Linux::CPU Usage controlla l'utilizzo della CPU su di un sistema, raccogliendo la seguente metrica:
- CPU Percent Used - Utilizzo percentuale, in cinque secondi, della CPU al momento dell'esecuzione del probe.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.15. Impostazioni utilizzo di Linux::CPU
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Critical Utilizzo Percentuale CPU Massimo | |
| Warning Utilizzo Percentuale CPU Massimo |
A.5.2. Linux::Disk IO Throughput
Il probe Linux::Disk IO Throughput controlla un dato disco e raccoglie la seguente metrica:
- Read Rate - La quantità di dati letti, in kilobytes, al secondo.
- Write Rate - Quantità di dati scritti, in kilobytes, al secondo.
Per ottenere il valore per il campo Numero del disco o nome del disco in questione, eseguite
iostat sul sistema da monitorare, e controllate il nome assegnato al disco desiderato. Il valore predefinito 0, vi permetterà di visualizzare le statistiche riguardanti il disco fisso, collegato direttamente al sistema.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe. Altresì il parametro Numero del disco o nome del disco, deve corrispondere al formato visualizzato durante l'esecuzione del comando iostat. Se tale formato non risulta essere identico, il probe configurato entrerà in uno stato di UNKNOWN.
Tabella A.16. Impostazioni di Linux::Disk IO Throughput
| Campo | Valore |
|---|---|
| Numero disco o nome disco* | 0 |
| Timeout* | 15 |
| Critical Lettura/secondo KB Massima | |
| Warning lettura/secondo Massima di KB | |
| Warning lettura/secondo di KB Minima | |
| Critical Lettura/secondo di KB Minima | |
| Critical Scrittura/secondo di KB Minima | |
| Warning scrittura/secondo di KB Massima | |
| Warning scrittura/secondo di KB Minima | |
| Critical Scrittura/secondo di KB Minima |
A.5.3. Linux::Disk Usage
Il probe Linux::Disk controlla lo spazio del disco su di un file system specifico, raccogliendo le seguenti metriche:
- File System Usato - La percentuale del file system attualmente in uso.
- Spazio usato - La quantità di file system, espressa in megabyte, attualmente in uso.
- Spazio disponible - La quantità di file system, espressa in megabyte, attualmente disponibile.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.17. Impostazioni di Linux::Disk Usage
| Campo | Valore |
|---|---|
| File system* | /dev/hda1 |
| Timeout* | 15 |
| Critical Utilizzo Massimo Percentuale del File System | |
| Warning Utilizzo Massimo Percentuale del File System | |
| Critical Spazio Massimo Utilizzato | |
| Warning Spazio Massimo Utilizzato | |
| Warning Spazio Minimo Disponibile | |
| Critical Spazio Minimo Disponibile |
A.5.4. Linux::Inodes
Il probe Linux::Inodes controlla il file system specificato e raccoglie la seguente metrica:
- Inodes - La percentuale di inodes attualmente in uso.
Un inode è una struttura dati contenente informazioni sui file presenti in un file system di Linux. Solo un inode è presente per ogni file, ed il file stessoviene identificato in modo unico dal file system sul quale risiede, e dal proprio numero inode presente sul sistema in questione.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.18. Impostazioni di Linux::Inodes
| Campo | Valore |
|---|---|
| File system* | / |
| Timeout* | 15 |
| Critical Percentuale dell'inode Massimo Utilizzato | |
| Warning Percentuale Inode Massimo Utilizzato |
A.5.5. Linux::Interface Traffic
Il probe Linux::Interface Traffic misura la quantià di traffico internamente ed esternamente all'interfacia specificata (come ad esempio eth0), e raccoglie le seguenti metriche:
- Velocità di Input - Traffico espresso in byte al secondo, in entrata rispetto ad una interfaccia specifica.
- Velocità output - Traffico espresso in byte al secondo in uscita rispetto all'interfaccia specificata.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.19. Impostazioni di Linux::Interface Traffic
| Campo | Valore |
|---|---|
| Interfaccia* | |
| Timeout* | 30 |
| Critical Velocità Input Massima | |
| Warning Velocità Input Massima | |
| Warning Velocità Input Minima | |
| Critical Velocità Input Minima | |
| Critical Velocità Output Massima | |
| Warning Velocità Output Massima | |
| Warning Velocità Minima di Output | |
| Critical Velocità Output Minima |
A.5.6. Linux::Load
Il probe Linux::Load controlla la CPU di un sistema e raccoglie la seguente metrica:
- Carico - Il carico medio presente sulla CPU del sistema attraverso vari periodi.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.20. Impostazioni di Linux::Load
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Critical Carico medio di 1 minuto della CPU | |
| Warning carico medio di 1 minuto della CPU | |
| Critical Carico medio di 5 minuti della CPU | |
| Warning carico medio di 5 minuti della CPU | |
| Critical Carico medio di 15 minuti della CPU | |
| Warning carico medio di 15 minuti della CPU |
A.5.7. Linux::Memory Usage
Il probe Linux::Memory Usage controlla la memoria presente su di un sistema e raccoglie la seguente metrica:
- RAM disponibile - La quantità di random access memory (RAM) espressa in megabyte presente sul sistema.
Potete includere in questa metrica anche la memoria rivendicabile, inserendo semplicemente
yes o no nel campo Includi memoria rivendicabile.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.21. Impostazioni di Linux::Memory Usage
| Campo | Valore |
|---|---|
| Includi memoria rivendicabile | no |
| Timeout* | 15 |
| Warning RAM massima disponibile | |
| Critical RAM massima disponibile |
A.5.8. Linux::Process Counts by State
Il probe Linux::Process Counts by State identifica il numero di processi nel seguente stato:
- Bloccato - Un processo passato sulla coda di attesa, il quale stato risulta essere stato smistato su
waiting. - Defunto - Processo terminato (perchè è stato interrotto 'killed' da un segnale o perchè è stato utilizzato il comando
exit()), il quale processo genitore non ha ancora ricevuto la notifica della sua terminazione, dopo aver eseguito la chiamata del sistemawait(). - Arrestato - Un processo arrestato prima che la sua esecuzione sia stata completata.
- Riposo - Un processo che risulta essere in un riposo
Interruptible, e integrabile nella memoria in un secondo momento, con possibilità di ripresa dell'esecuzione dove precedentemente arrestata.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.22. Impostazioni di Linux::Process Counts by State
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Critical Processi massimi arrestati | |
| Warning Processi Massimi Bloccati | |
| Critical Processi Massimi Morti | |
| Warning Processi Massimi Morti | |
| Critical Processi Massimi Arrestati | |
| Warning Processi Massimi Arrestati | |
| Critical Processi Massimi in Riposo | |
| Warning Processi Massimi in Riposo | |
| Critical Processi Figlio Massimi | |
| Warning Processi Figlio Massimi |
A.5.9. Linux::Process Count Total
Il probe Linux::Process Count Total è in grado di controllare un sistema e di racogliere la seguente metrica
- Conteggio processo - Il numero totale di processi attualmente in esecuzione sul sistema.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.23. Impostazioni di Linux::Process Count Total
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Critical Conteggio Massimo dei Processi | |
| Warning Conteggio Massimi del Processo |
A.5.10. Linux::Process Health
Il probe Linux::Process Health controlla i processi specificati dall'utente e racoglie le seguenti metriche:
- Utilizzo della CPU - Tasso di utilizzo della CPU di un dato processo espresso in millisecondi. Questa metrica riporta la colonna del tempo dell'output
ps, il quale risulta essere il tempo comulativo della CPU utilizzato dal processo. Ciò rende la metrica indipendente dall'intervallo di probe, permette l'impostazione corretta dei limiti, e genera delle grafiche utilizzabili (es. una improvvisa variazione nell'utilizzo della CPU, viene tradotta con un picco all'interno del grafico). - Gruppi di processi figlio - Il numero di processi figli originati dal processo genitore specificato. Un processo figlio eredita la maggior parte dei propri attributi, come gli open file, dal proprio genitore.
- Thread - Il numero di thread in esecuzione per un dato processo. Un thread è una unità di base riguardante l'utilizzo della CPU, e consiste in un conteggiatore di programma, un set registratore, ed uno spazio dello stack. Un thread viene anche chiamato processo leggero.
- Memoria fisica utilizzata - La quantità di memoria fisica (o RAM), espressa in kilobyte, utilizzata dal processo specificato.
- Memoria Virtuale utilizzata - Quantità di memoria virtuale utilizzata, espressa in kilobyte, da un processo specificato, oppure la misura del processo presente nella memoria reale più lo swap.
Specifica il processo inserendo il nome del comando o l'I.D. del processo (PID). Inserendo un PID, verrà annullata la entry nome del comando. Se nessun nome o PID viene inserito, verrà visualizzato l'errore Command not found ed il probe verrà impostato su CRITICAL.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.24. Impostazioni di Linux::Process Health
| Campo | Valore |
|---|---|
| Nome del comando | |
| File ID del processo (PID) | |
| Timeout* | 15 |
| Critical Utilizzo Massimo della CPU | |
| Warning Utilizzo CPU Massimo | |
| Critical Gruppi Massimi di Processi Figli | |
| Warning Gruppi Massimi di Processo Figlio | |
| Critical Thread Massimi | |
| Warning Trhead Massimi | |
| Critical Memoria Fisica Massima Utilizzata | |
| Warning Memoria Fisica Massima Utilizzata | |
| Critical Memoria Virtuale Massima Utilizzata | |
| Warning Memoria Virtuale Massima Utilizzata |
A.5.11. Linux::Process Running
Il probe Linux::Process Running verifica che il processo specificato sia correttamente in funzione. Esegue un conteggio sia dei processi che dei gruppi, a seconda se è stata selezionata la casella Conteggio gruppi del processo.
La casella viene selezionata per default, indicando che probe sarà in grado di conteggiare il numero di process group leader indipendenti del numero di processi figli. Ciò permette, per esempio, di verificare che due esempi di Apache web server siano in esecuzione senza tener conto del numero (dinamico) di processi figli. Se non selezionata, probe condurrà un conteggio del numero dei processi (figli e leader) che corrispondono al processo specificato.
Specifica il processo inserendo il nome del comando o l'I.D. del processo (PID). Inserendo un PID, verrà annullata la entry nome del comando. Se nessun nome o PID viene inserito, verrà visualizzato l'errore Command not found ed il probe verrà impostato su CRITICAL.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.25. Impostazioni di Linux::Process Running
| Campo | Valore |
|---|---|
| Nome del comando | |
| File PID | |
| Gruppi di conteggio del processo | (controllato) |
| Timeout* | 15 |
| Critical Numero Massimo in Esecuzione | |
| Critical Numero Minimo in Esecuzione |
A.5.12. Linux::Swap Usage
Il probe Linux::Swap Usage controlla le partizioni swap in esecuzione su di un sistema, e riporta la seguente metrica:
- Swap disponibile - La percentuale di memoria swap attualmente disponibile.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.26. Impostazioni di Linux::Swap Usage
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Warning Swap Minimo Disponibile | |
| Critical Swap Disponibile Minimo |
A.5.13. Linux::TCP Connections by State
Il probe Linux::TCP Connections by State identifica il numero totale di collegamenti TCP, insieme al numero degli stessi aventi i seguenti stati:
- TIME_WAIT - Il socket è in attesa dopo essersi chiuso per una trasmissione di arresto remota, sarà in grado di gestire i pacchetti presenti nella rete.
- CLOSE_WAIT - La parte remota è stata arrestata e ora risulta essere in attesa della chiusura del socket.
- FIN_WAIT - Il socket risulta chiuso ed il collegamento stà per terminare.
- ESTABLISHED - Il socket ha stabilito un collegamento.
- SYN_RCVD - La richiesta di collegamento è stata ricevuta dalla rete.
Questo probe risulta essere molto utile nel processo di ricerca ed isolazione del traffico di rete per gli indirizzi IP specifici, oppure durante lo studio dei collegamenti di rete all'interno del sistema monitorato.
I parametri di filtraggio del probe vi permettono di eseguire un processo molto più selettivo. Il suddetto probe utilizza un comando
netstat -ant per riprendere i dati. I parametri Indirizzo IP locale e Porta locale, utilizzano i valori presenti nella colonna Local Address dell'output; mentre i parametri Indirizzo IP remoto e Porta remota, utilizzano i valori presenti nella colonna Foreign Address dell'output per l'esecuzione di un riporto.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.27. Impostazioni di Linux::TCP Connections by State
| Campo | Valore |
|---|---|
| Elenco del pattern di filtraggio dell'indirizzo IP locale | |
| Filtro del numero della porta locale | |
| Elenco del pattern di filtraggio dell'indirizzo IP remoto | |
| Filtro del numero della porta remota | |
| Timeout* | 15 |
| Critical Collegamenti totali Massimi | |
| Warning Collegamenti Totali Massimi | |
| Critical Collegamenti TIME_WAIT Massimi | |
| Warning Collegamenti TIME_WAIT Massimi | |
| Critical Collegamenti CLOSE_WAIT Massimi | |
| Warning Collegamenti CLOSE_WAIT Massimi | |
| Critical Collegamenti FIN_WAIT Massimi | |
| Warning Collegamenti FIN_WAIT Massimi | |
| Critical Collegamenti ESTABLISHED Massimi | |
| Warning Collegamenti ESTABLISHED Critici Massimi | |
| Critical Collegamenti SYN_RCVD Massimi | |
| Warning Collegamenti SYN_RCVD Massimi |
A.5.14. Linux::Users
Il probe Linux::Users controlla gli utenti di un sistema e riporta la seguente metrica:
- Utenti - Il numero di utenti attualmente registrati.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.28. Impostazioni di Linux::Users
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Critical Utenti Massimi | |
| Warning Utenti Massimi |
A.5.15. Linux::Virtual Memory
Il probe Linux::Virtual Memory controlla la memoria totale del sistema,e raccoglie la seguente metrica:
- Memoria Virtuale - La percentuale di memoria totale del sistema - random access memory (RAM) più swap - disponibile.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.29. Impostazioni di Linux::Virtual Memory
| Campo | Valore |
|---|---|
| Timeout* | 15 |
| Warning Memoria Virtuale Minima Disponibile | |
| Critical Memoria Virtuale Minima Disponibile |
A.6. LogAgent
I probe presenti in questa sezione controllano i file di log presenti sui vostri sistemi. È possibile utilizzare i suddetti probe per interrogare i log su certe espressioni, e controllare le dimensioni dei file. Per poter eseguire i probe del Log Agent, è necessario garantire all'utente
nocpulse i diritti di lettura dei vostri file log.
Da notare che i dati provenienti dalla prima esecuzione dei probe, non verranno misurati utilizzando i limiti fissati per la prevenzione di false notifiche causate dalla presenza di dati metrici incompleti. Le misurazioni verranno effettuate utilizzando la seconda colonna.
A.6.1. LogAgent::Log Pattern Match
Il probe LogAgent::Log Pattern Match utilizza espressioni regolari per corrispondere il testo presente all'interno del file di log controllato, ed è in grado di raccogliere le seguenti metriche:
- Corrispondenze di Espressioni Regolari - Il numero di corrispondenze presenti dopo l'ultima esecuzione di probe.
- Tasso di Corrispondenze di Espressioni Regolari - Il numero di corrispondenze al minuto dopo l'ultima esecuzione di probe.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema controllato per poter eseguire questo probe. A tale scopo, è necessario conferire all'utente nocpulse i diritti di lettura dei vostri file log.
In aggiunta al nome ed alla posizione del file di log da controllare, è necessario fornire una espressione regolare da poter confrontare. L'espressione deve essere formattata per
egrep, il quale risulta essere equivalente a grep -E in supporto alle espressioni estese regolari. Il seguente risulta essere il set di espressione regolare per egrep:
^ beginning of line $ end of line . match one char * match zero or more chars [] match one character set, e.g. '[Ff]oo' [^] match not in set '[^A-F]oo' + match one or more of preceding chars ? match zero or one of preceding chars | or, e.g. a|b () groups chars, e.g., (foo|bar) or (foo)+
Avvertimento
Non includere il carattere virgolette singole (') all'interno dell'espressione. In caso contrario
egrep fallirà in modo silenzioso causando il timeout di probe.
Tabella A.30. Impostazioni di LogAgent::Log Pattern Match
| Campo | Valore |
|---|---|
| Log file* | /var/log/messages |
| Espressione regolare di base* | |
| Timeout* | 45 |
| Critical Corrispondenze Massime | |
| Warning Corrispondenze Massime | |
| Warning Corrispondenze Minime | |
| Critical Corrispondenze Minime | |
| Critical Velocità di Corrispondenze Massima | |
| Warning Velocità di Corrispondenza Massima | |
| Warning Velocità di Corrispondenza Minima | |
| Critical Velocità di Corrispondenze Massima |
A.6.2. LogAgent::Log Size
Il probe LogAgent::Log Size controlla la crescita del file log e racoglie le seguenti metriche:
- Dimensione - La dimensione della crescita del file di log, espressa in byte, dopo l'ultima esecuzione di probe.
- Velocità Output - La crescita del file di log, espressa in numero di byte al minuto, dall'ultima esecuzione di probe.
- Linee - Il numero di linee scritte sul file di log dall'ultima esecuzione di probe.
- Velocità di linea - Il numero di linee scritte al minuto sul file di log dall'ultima esecuzione di probe.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema controllato per poter eseguire questo probe. A tale scopo, è necessario conferire all'utente nocpulse i diritti di lettura dei vostri file log.
Tabella A.31. Impostazioni di LogAgent::Log Size
| Campo | Valore |
|---|---|
| Log file* | /var/log/messages |
| Timeout* | 20 |
| Critical Misura Massima | |
| Warning Misura Massima | |
| Warning Misura Minima | |
| Critical Misura Minima | |
| Critical Velocità Output Massima | |
| Warning Velocità Output Massima | |
| Warning Velocità Minima di Output | |
| Critical Velocità Output Minima | |
| Critical Linee Massime | |
| Warning Linee Massime | |
| Warning Linee Minime | |
| Critical Linne Minime | |
| Critical Velocità di linea Massima | |
| Warning Velocità di Linea Massima | |
| Warning Velocità di Linea Minima | |
| Critical Velocità della Linea Minima |
A.7. MySQL 3.23 - 3.33
I probe presenti all'interno di questa sezione controllano gli aspetti del database MySQL utilizzando il binario
mysqladmin. Per i suddetti probe non sono necessari alcuni privilegi specifici.
Da notare che per poter completare queste probe, il pacchetto
mysql-server deve essere installato sul sistema che esegue il monitoring. Consultate la sezione inerente l'installazione di MySQL del Red Hat Satellite Installation Guide per maggiori informazioni.
A.7.1. MySQL::Database Accessibility
Il probe MySQL::Database Accessibility verifica il collegamento attraverso un account del database che non presenta alcun privilegio database. Verrà ritornato uno stato CRITICAL se non viene eseguito alcun collegamento.
Tabella A.32. Impostazioni di MySQL::Database Accessibility
| Campo | Valore |
|---|---|
| Nome utente* | |
| Password | |
| Porta MySQL | 3306 |
| Database* | mysql |
| Timeout | 15 |
A.7.2. MySQL::Opened Tables
Il probe MySQL::Opened Tables controlla il server MySQL e raccoglie la seguente metrica:
- Tabelle Aperte - Il numero di tabelle che sono state aperte dall'ultimo processo d'avvio del server.
Tabella A.33. Impostazioni di MySQL::Opened Tables
| Campo | Valore |
|---|---|
| Nome utente | |
| Password | |
| Porta MySQL* | 3306 |
| Timeout | 15 |
| Critical Oggetti Aperti Massimi | |
| Warning Oggetti Aperti Massimi | |
| Warning Oggetti Aperti Minimi | |
| Critical Oggetti Aperti Minimi |
A.7.3. MySQL::Open Tables
Il probe MySQL::Open Tables controlla il server MySQL e raccoglie la seguente metrica:
- Tabelle Aperte - Il numero di tabelle che risultano essere aperte durante l'esecuzione di probe.
Tabella A.34. Impostazioni di MySQL::Open Tables
| Campo | Valore |
|---|---|
| Nome utente | |
| Password | |
| Porta MySQL* | 3306 |
| Timeout | 15 |
| Critical Oggetti Aperti Massimi | |
| Warning Oggetti Aperti Massimi | |
| Warning Oggetti Aperti Minimi | |
| Critical Oggetti Aperti Massimi |
A.7.4. MySQL::Query Rate
Il probe MySQL::Query Rate controlla il server MySQL e raccoglie la seguente metrica:
- Velocità di interrogazione - Numero medio di interrogazioni al secondo per server database.
Tabella A.35. Impostazioni di MySQL::Query Rate
| Campo | Valore |
|---|---|
| Nome utente | |
| Password | |
| Porta MySQL* | 3306 |
| Timeout | 15 |
| Critical Velocità di Interrogazione Massima | |
| Warning Velocità di Interrogazione Massima | |
| Warning Velocità di Interrogazione Minima | |
| Critical Velocità di Interrogazione Massima |
A.7.5. MySQL::Threads Running
Il probe MySQL::Threads Running controlla il server MySQL e raccoglie la seguente metrica:
- Thread in esecuzione - Numero totale di thread in esecuzione all'interno del database.
Tabella A.36. Impostazioni di MySQL::Threads Running
| Campo | Valore |
|---|---|
| Nome utente | |
| Password | |
| Porta MySQL* | 3306 |
| Timeout | 15 |
| Critical Thread Massimi in Esecuzione | |
| Warning Thread Massimi in Esecuzione | |
| Warning Thread Minimi in Esecuzione | |
| Critical Thread Minimi in Esecuzione |
A.8. Network Services
I probe presenti all'interno di questa sezione, controllano i vari servizi che fanno parte di una rete in funzione. Una volta applicati, assicuratevi che i rispettivi limiti di tempo, non eccedano la quantità di tempo relativa al periodo di timeout. In caso contrario, verrà ritornato una stato UNKNOWN in tutti gli esempi di latenza estesa, annullando così i limiti stabiliti.
A.8.1. Network Services::DNS Lookup
Il probe Network Services::DNS Lookup utilizza il comando
dig per cercare di risolvere il sistema oppure il domain name specificato nel campo Host o Indirizzo da cercare. Esso è in grado di raccogliere la seguente metrica:
- Periodo di Interrogazione - Il tempo necessario per eseguire la richiesta
dig, espresso in millisecondi.
Ciò risulta utile per il monitoring dello stato dei vostri server DNS. Se desiderate controllare uno dei vostri server DNS, fornite un nome host/dominio conosciuto, come ad esempio un motore di ricerca molto grande, oppure un sito web corporativo.
Tabella A.37. Impostazioni di Network Services::DNS Lookup
| Campo | Valore |
|---|---|
| Host o indirizzo da cercare | |
| Timeout* | 10 |
| Critical Periodo di interrogazione Massimo | |
| Warning Periodo di Interrogazione Massimo |
A.8.2. Network Services::FTP
Il probe Network Services::FTP utilizza i sockets di rete per verificare la disponibilità della porta FTP. Esso raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario al server FTP, espresso in secondi, per rispondere ad una richiesta di collegamento.
Questo probe supporta il processo di autenticazione. Fornite un nome utente ed una password all'interno dei campi appropriati, per poter utilizzare questa funzione. Il valore opzionale di In Attesa corrisponde alla stringa da tener in considerazione, dopo aver eseguito un collegamento al server FTP. Se la stringa in questione non viene trovata, il probe ritornerà uno stato CRITICAL.
Tabella A.38. Impostazioni di Network Services::FTP
| Campo | Valore |
|---|---|
| In attesa | FTP |
| Nome utente | |
| Password | |
| Porta FTP* | 21 |
| Timeout* | 10 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.3. Network Services::IMAP Mail
Il probe Network Services::IMAP Mail determina se è possibile eseguire un collegamento al servizio IMAP 4 presente sul sistema. Specificando una porta opzionale verrà annullata la porta di default 143. Esso raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario al server IMAP, espresso in secondi, per rispondere ad una richiesta di collegamento.
Il valore In attesa richiesto risulta essere la stringa da corrispondere dopo aver stabilito un collegamento al server IMAP. Se la stringa designata non viene trovata, il probe ritornerà uno stato CRITICAL.
Tabella A.39. Impostazioni di Network Services::IMAP Mail
| Campo | Valore |
|---|---|
| Porta IMAP* | 143 |
| Attesa* | OK |
| Timeout* | 5 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.4. Network Services::Mail Transfer (SMTP)
Il probe Network Services::Mail Transfer (SMTP) probe determina se è possibile eseguire un collegamento alla porta SMTP presente sul sistema. Specificando una porta opzionale verrà annullata la porta di default 25. Esso raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario al server SMTP, espresso in secondi, per rispondere ad una richiesta di collegamento.
Tabella A.40. Impostazioni di Network Services::Mail Transfer (SMTP)
| Campo | Valore |
|---|---|
| Porta SMTP* | 25 |
| Timeout* | 10 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.5. Network Services::Ping
Il probe Network Services::Ping determina se il server Red Hat Satellite è in grado di eseguire il
ping del sistema monitorato o di un indirizzo IP specificato. Esso controllerà altresì la presenza di perdite dei pacchetti, e confronta il tempo medio di viaggio rispetto ai livelli limiti di Warning e Critical. Il valore necessario di Pacchetti da inviare, vi permette di controllare il numero di pacchetti ICMP ECHO inviati al sistema. Questo probe raccoglie le seguenti metriche:
- Tempo medio di vaggio - Il tempo necessario, in millisecondi, al pacchetto ECHO ICMP per raggiungere il sistema monitorato e rientrare al suo punto di partenza originale.
- Perdita del pacchetto - Percentuale di dati persi durante il traffico.
Anche se facoltativo, il campo Indirizzo IP può risultare molto importante durante la raccolta delle metriche per i sistemi con indirizzi IP multipli. Per esempio, se il sistema è stato configurato con indirizzi IP virtuali multipli, oppure se lo stesso utilizza il Network Address Translation (NAT) per supportare gli indirizzi IP interni ed esterni, questa opzione può essere usata per controllare l'indirizzo IP secondario, invece di quello primario associato all'hostname.
Da notare che il suddetto probe è in grado di eseguire il
ping da un server Red Hat Satellite e non dal sistema monitorato. In questo modo popolando il campo corrispondente all'indirizzo IP, non verrà eseguito il test di connettività tra il sistema e l'indirizzo IP specificato, ma solo tra il server Red Hat Satellite e l'indirizzo IP. Per questo motivo inserendo lo stesso indirizzo IP per i probe di Ping su diversi sistemi, verrà portato a termine lo stesso compito. Per eseguire un ping da un sistema monitorato nei confronti di un indirizzo IP, utilizzare invece il probe Remote Ping. Consultate Sezione A.8.7, «Network Services::Remote Ping».
Tabella A.41. Impostazioni di Network Services::Ping
| Campo | Valore |
|---|---|
| Indirizzo IP (default per l'IP del sistema) | |
| Pacchetti da inviare* | 20 |
| Timeout* | 10 |
| Critical Viaggio Medio Massimo | |
| Warning Viaggio Medio Massimo | |
| Critical Perdita Massima del Pacchetto | |
| Warning Perdita Massima del Pacchetto |
A.8.6. Network Services::POP Mail
Il probe Network Services::POP Mail determina se è posibile eseguire un collegamento sulla porta POP3 presente sul sistema. È necessario specificare un numero di porta; specificando un'altra porta si annullerà la porta di default 110. Questo probe è in grado di raccogliere la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server POP per rispondere ad una richiesta di collegamento.
Il valore In Attesa richiesto, risulta essere la stringa di riferimento dopo aver eseguito un collegamento con il server POP. Il probe andrà alla ricerca della stringa sulla prima riga, presente all'interno della risposta proveniente dal sistema. Il default risulta essere
+OK. Se la stringa attesa non viene trovata, il probe ritornerà uno stato CRITICAL.
Tabella A.42. Impostazioni di Network Services::POP Mail
| Campo | Valore |
|---|---|
| Porta* | 110 |
| Attesa* | +OK |
| Timeout* | 10 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.7. Network Services::Remote Ping
Il probe Network Services::Remote Ping determina se il sistema monitorato è in grado di eseguire il
ping di un indirizzo IP specificato. Esso controllerà altresì la presenza di perdite dei pacchetti, e confronta il tempo medio di viaggio rispetto ai livelli limiti di Warning e Critical. Il valore necessario di Pacchetti da inviare, vi permette di controllare il numero di pacchetti ICMP ECHO inviati all'indirizzo. Questo probe raccoglie le seguenti metriche:
- Viaggio medio - Il tempo necessario, espresso in millisecondi, per il pacchetto ECHO ICMP a raggiungere e tornare da un indirizzo IP.
- Perdita del pacchetto - Percentuale di dati persi durante il traffico.
Il campo Indirizzo IP identifica l'indirizzo esatto per eseguire il ping. Diversamente da un campo simile presente nel probe di un ping standard, il quale risulta essere opzionale, questo campo è indispensabile. Il sistema monitorato direziona il ping su di un terzo indirizzo invece di direzionarlo al server Red Hat Satellite. Poichè il probe Remote Ping verifica la connettività dal sistema monitorato, è necessario specificare un altro indirizzo IP. Per eseguire un ping da un server Red Hat Satellite nei confronti di un sistema o un indirizzo IP, utilizzate invece il probe di un ping standard. Consultare Sezione A.8.5, «Network Services::Ping».
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema monitorato per poter eseguire questo probe.
Tabella A.43. Impostazioni di Network Services::Remote Ping
| Campo | Valore |
|---|---|
| Indirizzo IP* | |
| Pacchetti da inviare* | 20 |
| Timeout* | 10 |
| Critical Viaggio Medio Massimo | |
| Warning Viaggio Medio Massimo | |
| Critical Perdita Massima del Pacchetto | |
| Warning Perdita Massima del Pacchetto |
A.8.8. Network Services::RPCService
Il probe Network Services::RPCService verifica la disponibilità dei programmi remote procedure call (RPC) di un dato indirizzo IP. Esso raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server RPC per rispondere ad una richiesta di collegamento.
I programmi server RPC, i quali forniscono le chiamate di funzione tramite la rete RPC in questione, si registrano all'interno della rete RPC dichiarando un ID del programma insieme al nome corrispondente. NFS risulta essere un esempio di servizio che funziona tramite il meccanismo RPC.
I programmi client che desiderano utilizzare le risorse dei programmi server RPC, eseguono una richiesta alla macchina sulla quale risiede il programma server, in modo che la stessa sia in grado di fornire l'accesso alle funzioni RPC presenti all'interno del numero del programma RPC o del nome dello stesso. Queste conversazioni possono verificarsi attraverso TCP oppure UDP (anche se risultano essere quasi sempre UDP).
Questo probe vi permette di testare la disponibilità semplice di un programma. È necessario specificare il nome del programma o il suo numero insieme al protocollo, attraverso i quali avverrà il collegamento, insieme al periodo di timeout.
Tabella A.44. Impostazioni di Network Services::RPCService
| Campo | Valore |
|---|---|
| Protocollo (TCP/UDP) | udp |
| Nome del Servizio* | nfs |
| Timeout* | 10 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.9. Network Services::Secure Web Server (HTTPS)
Il probe Network Services::Secure Web Server (HTTPS) determina la disponibilità del Web server sicuro, e raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server HTTPS per rispondere ad una richiesta di collegamento.
Questo probe conferma che sarà in grado di collegarsi alla porta HTTPS sull'host specificato, e di riprendere così l'URL in questione. Se non viene specificato alcun URL, il probe riprenderà il documento root. Il suddetto probe andrà alla ricerca di un messaggio HTTP/1 proveniente dal sistema, sempre che il valore non sia stato modificato. Specificando un altro numero di porta, verrà annullata la porta di default 443.
Questo probe supporta il processo di autenticazione. Fornite un nome utente ed una password all'interno dei campi appropriati, per poter utilizzare questa funzione. Diversamente da altri, il suddetto probe ritornerà uno stato CRITICAL se risulta non essere in grado di contattare il sistema all'interno del periodo di timeout.
Tabella A.45. Impostazioni di Network Services::Secure Web Server (HTTPS)
| Campo | Valore |
|---|---|
| Percorso URL | / |
| Testo atteso | HTTP/1 |
| Contenuto atteso | |
| UserAgent* | NOCpulse-check_http/1.0 |
| Nome utente | |
| Password | |
| Timeout* | 10 |
| Porta HTTPS* | 443 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.10. Network Services::SSH
Il probe Network Services::SSH determina la disponibilità del SSH presente sulla porta specificata, e raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server SSH per rispondere ad una richiesta di collegamento.
Previo contatto con il server SSH e dopo aver ricevuto una risposta valida, il probe mostrerà il protocollo e le informazioni riguardanti la versione del server. Se il probe riceve una risposta non valida, esso visualizzerà un messaggio ritornato dal server, generando uno stato di WARNING.
Tabella A.46. Impostazioni di Network Services::SSH
| Campo | Valore |
|---|---|
| Porta SSH* | 22 |
| Timeout* | 5 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.8.11. Network Services::Web Server (HTTP)
Il probe Network Services::Web Server (HTTP) determina la disponibilità del Web server e raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server HTTP per rispondere ad una richiesta di collegamento.
Questo probe conferma che sarà in grado di collegarsi alla porta HTTP sull'host specificato, e di riprendere così l'URL in questione. Se non viene specificato alcun URL, il probe riprenderà il documento di root. Il suddetto probe andrà alla ricerca di un messaggio HTTP/1 proveniente dal sistema, sempre che il valore non sia stato modificato. Specificando un altro numero di porta, verrà annullata la porta di default 80. Diversamente da altri, il suddetto probe ritornerà uno stato CRITICAL, se risulta non essere in grado di contattare il sistema all'interno del periodo di timeout.
Questo probe supporta il processo di autenticazione. Fornite un nome utente ed una password all'interno dei campi appropriati, per poter utilizzare questa caratteristica. Altresì, il campo opzionale Host Virtuale può essere utilizzato per controllare un set di documentazione separato, presente sulla stessa macchina fisica presentata come server standalone. Se il vostro Web server non risulta essere configurato in modo da poter utilizzare gli host virtuali (tale caso risulta essere quello tipico), lasciate questo campo in bianco. Se al contrario gli host virtuali risultano configurati, inserite qui il nome del dominio del primo host. Aggiungete i probe necessari per poter controllare tutti gli host virtuali presenti sulla macchina.
Tabella A.47. Impostazioni di Network Services::Web Server (HTTP)
| Campo | Valore |
|---|---|
| Percorso URL | / |
| Host virtuale | |
| Testo atteso | HTTP/1 |
| Contenuto atteso | |
| UserAgent* | NOCpulse-check_http/1.0 |
| Nome utente | |
| Password | |
| Timeout* | 10 |
| Porta HTTP* | 80 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.9. Oracle 8i, 9i, 10g, e 11g
I probe presenti in questa sezione, potrebbero essere applicati agli esempi del database di Oracle che corrispondono alle versioni supportate. I probe di Oracle richiedono una configurazione del database e delle associazioni fatte eseguendo il seguente comando:
$ORACLE_HOME/rdbms/admin/catalog.sql
In aggiunta, per poter eseguire i suddeti probe in modo corretto, l'utente di Oracle configurato all'interno di probe deve possedere i privilegi minimi di CONNECT e SELECT_CATALOG_ROLE.
Alcuni probe di Oracle sono stati creati in modo specifico, in modo da regolare i dispositivi per poter ottenere a lungo termine, dei miglioramenti nella prestazione, invece di limitare il numero di interruzioni. Per questo motivo, Red Hat consiglia una loro programmazione minima, ogni ora oppure ogni due giorni. Tale impostazione fornirà una rappresentazione statistica migliore, rispetto a quella ottenuta utilizzando una impostazione più frequente, riducendo così l'enfasi sulle anomalie che possono verificarsi. Tale impostazione viene applicata sui seguenti probe: Cache Buffer, Cache del Dizionario Dati, Rapporto di Suddivisione del Disco, Cache della Libreria, e Riesegui il Log.
Per i limiti CRITICAL e WARNING basati sul tempo di lavoro, i rispettivi valori non possono eccedere la quantità di tempo stanziata per il periodo di timeout. In caso contrario, verrà ritornato uno stato di UNKNOWN in tutti i casi di latenza estesa, annullando così i limiti presenti. Per questo motivo, Red Hat consiglia fortemente di assicurarsi che i periodi di timeout eccedano tutti i limiti di tempo. In questa sezione, viene fatto riferimento in modo specifico al ping TNS di probe.
Per finire, i clienti che utilizzano i probe di Oracle nei confronti di un database che utilizza il Multi-Threaded Server (MTS) di Oracle, avranno bisogno di contattare il supporto di Red Hat, per poter aggiungere delle entry nel file /etc/hosts del server Red Hat Network, e per risolvere in modo corretto il nome DNS.
A.9.1. Oracle::Active Sessions
Il probe Oracle::Active Sessions controlla l'istanza di Oracle e raccoglie le seguenti metriche:
- Sessioni attive - Numero di sessioni attive basate sul valore di
V$PARAMETER.PROCESSES. - Sessioni disponibili - Percentuale di sessioni attive disponibili, basate sul valore di
V$PARAMETER.PROCESSES.
Tabella A.48. Impostazioni di Oracle::Active Sessions
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Critical Sessioni Attive Massime | |
| Warning Sessioni Attive Massime | |
| Critical Sessioni Disponibili Massime Utilizzate | |
| Warning Sessioni Disponibili Massime Utilizzate |
A.9.2. Oracle::Availability
Il probe di Oracle::Availability determina la disponibilità del database dal Red Hat Satellite.
Tabella A.49. Impostazioni di Oracle::Availability
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
A.9.3. Oracle::Blocking Sessions
Il probe Oracle::Blocking Sessions controlla una istanza di Oracle e raccoglie la seguente metrica:
- Blocco delle sessioni - Il numero di sessioni in grado di impedire ad altre sessioni l'azione di commit delle modifiche eseguite sul database di Oracle, come determinato dal valore di Time Blocking richiesto e da voi fornito. Solo quelle sessioni che hanno eseguito il blocco per tutta la durata in questione, la quale viene misurata in secondi, verranno conteggiate come sessioni di bloccaggio.
Tabella A.50. Impostazioni di Oracle::Blocking Sessions
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Tempo di bloccaggio (secondi)* | 20 |
| Timeout* | 30 |
| Critical Blocco Massimo delle Sessioni | |
| Warning Blocco Massimo delle Sessioni |
A.9.4. Oracle::Buffer Cache
Il probe Oracle::Buffer Cache elabora il Buffer Cache Hit Ratio in modo da ottimizzare la misura del Buffer database del system global area (SGA). Esso raccoglie le seguenti metriche:
- Db Block Gets - Numero di blocchi accessibili tramite un get a blocco singolo (non attraverso il meccanismo consistent get).
- Consistent Get - Il numero degli ingressi eseguiti nel buffer del blocco, per raccogliere i dati in una modalità consistent.
- Letture Fisiche - Il numero cumulativo di blocchi letti dal disco.
- Buffer Cache Hit Ratio - Il rapporto con il quale il database accede all'interno del buffer, invece del disco fisso, per riprendere i dati desiderati. Un rapporto basso stà ad indicare la necessità di aggiunta di maggiore RAM al sistema.
Tabella A.51. Impostazioni di Oracle::Buffer Cache
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle | 1521 |
| Timeout* | 30 |
| Warning Rapporto Minimo di accesso alla Cache Buffer | |
| Critical Rapporto Minimo di accesso alla Cache Buffer |
A.9.5. Oracle::Client Connectivity
Il probe Oracle::Client Connectivity probe determina se il database sia correttamente in funzione ed in grado di ricevere i collegamenti provenienti dal sistema monitorato. Questo probe è in grado di aprire un collegamento
rhnmd per il sistema, emettendo anche un comando sqlplus connect sul sistema monitorato.
Il parametro Nome DB atteso risulta essere il valore atteso di
V$DATABASE.NAME. Questo valore è case-sensitive, riconosce i caratteri maiuscoli da quelli minuscoli. Se tale valore non viene trovato, verrà ritornato uno stato CRITICAL.
Requisiti - Il Red Hat Network monitoring daemon (
rhnmd) deve essere in esecuzione sul sistema controllato per poter eseguire questo probe. A tale scopo, è necessario conferire all'utente nocpulse i diritti di lettura dei vostri file log.
Tabella A.52. Impostazioni di Oracle::Client Connectivity
| Campo | Valore |
|---|---|
| Hostname di Oracle o Indirizzo IP* | |
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| ORACLE_HOME* | /opt/oracle |
| Nome DB atteso* | |
| Timeout* | 30 |
A.9.6. Oracle::Data Dictionary Cache
Il probe Oracle::Data Dictionary Cache elabora il Data Dictionary Cache Hit Ratio in modo da ottimizzare lo SHARED_POOL_SIZE in
init.ora. Esso è in grado di raccogliere le seguenti metriche:
- Data Dictionary Hit Ratio - Il rapporto di accesso alla cache durante il tentativo di ricerca della cache all'interno della cache del dizionario. In altre parole, il rapporto con il quale il database accede al dizionario, invece del disco fisso, per riprendere i dati. Un rapporto basso indica la necessità di aggiungere una quantità maggiore di RAM all'interno del sistema.
- Gets - Il numero di blocchi accessibili tramite gets a blocco singolo (non attraverso il meccanismo consistent get).
- Cache Misses - Numero di ingressi eseguiti nei confronti del buffer del blocco per la ripresa dei dati in modalità consistent.
Tabella A.53. Impostazioni di Oracle::Data Dictionary Cache
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Warning Rapporto Minimo di Data Dictionary Hit Ratio | |
| Critical Rapporto Minimo di Data Dictionary Hit Ratio |
A.9.7. Oracle::Disk Sort Ratio
Il probe Oracle::Disk Sort Ratio controlla una istanza del database di Oracle e raccoglie la seguente metrica:
- Rapporto di suddivisione del disco - Rapporto delle suddivisioni di Oracle risultate troppo grandi per poter essere completate all'interno della memoria, e suddivise utilizzando un segmento temporaneo.
Tabella A.54. Impostazioni di Oracle::Disk Sort Ratio
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Critical Disk Sort Ratio Massimo | |
| Warning Disk Sort Ratio Massimo |
A.9.8. Oracle::Idle Sessions
Il probe Oracle::Idle Sessions controlla una istanza di Oracle e raccoglie la seguente metrica:
- Sessioni Idle - Il numero di sessioni di Oracle in uno stato di idle, come determinato dal valore richiesto Time Idle da voi fornito. Solo quelle sessioni in uno stato di idle per tutta la durata indicata, misurata in secondi, verranno indicate come sessioni idle.
Tabella A.55. Impostazioni di Oracle::Idle Sessions
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Periodo Idle (secondi)* | 20 |
| Timeout* | 30 |
| Critical Sessioni Idle Massime | |
| Warning Sessioni Idle Massime |
A.9.9. Oracle::Index Extents
Il probe Oracle::Index Extents controlla una istanza di Oracle e raccoglie la seguente metrica:
- Estensioni assegnate - Numero di estensioni allocate per ogni indice.
- Estensioni disponibili - Percentuale di estensioni disponibili per ogni indice.
Il campo Nome indice richiesto, contiene il valore di default di
% che corrisponderà ad ogni nome dell'indice.
Tabella A.56. Impostazioni di Oracle::Index Extents
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Proprietario dell'Indice* | % |
| Nome dell'indice* | % |
| Timeout* | 30 |
| Critical Estensioni Massime Allocate | |
| Warning Estensioni Massime Allocate | |
| Critical Estensioni Massime Disponibili | |
| Warning Estensioni Disponibili Massime |
A.9.10. Oracle::Library Cache
Il probe Oracle::Library Cache elabora la Library Cache Miss Ratio in modo da ottimizzare lo SHARED_POOL_SIZE in
init.ora. Esso è in grado di raccogliere le seguenti metriche:
- Library Cache Miss Ratio - Il rapporto con il quale si verifica un errore del pin della cache della libreria. Ciò accade quando una sessione esegue una istruzione precedentemente analizzata, ma non più presente all'interno del pool condiviso.
- Esecuzioni - Numero di richieste pin per oggetti presenti in questo spazio.
- Cache Misses - Il numero di pin per il ripristino dell'oggetto del disco. I suddetti pin sono costituiti da oggetti che presentano pin precedenti dopo la creazione della gestione dell'oggetto.
Tabella A.57. Impostazioni di Oracle::Library Cache
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Critical Library Cache Miss Ratio Massimo | |
| Warning Library Cache Miss Ratio Massimo |
A.9.11. Oracle::Locks
Il probe Oracle::Locks controlla una istanza del database di Oracle e raccoglie la seguente metrica:
- Active Locks - Numero corrente di blocchi attivi riportato dal valore presente all'interno della tabella v$locks. Gli amministratori del database devono essere a conoscenza della presenza di un numero elevato di blocchi presenti in una istanza del database.
I blocchi vengono utilizzati in modo che gli utenti multipli o i processi che aggiornano gli stessi dati presenti all'interno del database, non entrino in conflitto. Il suddetto probe risulta essere utile per allertare gli amministratori del database, quando un elevato numero di blocchi sono presenti in una data istanza.
Tabella A.58. Impostazioni di Oracle::Locks
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Critical Active Locks Massimi | |
| Warning Active Locks Massimi |
A.9.12. Oracle::Redo Log
Il probe Oracle::Redo Log controlla una istanza del database di Oracle e raccoglie le seguenti metriche:
- Redo Log Space Request Rate - Il numero medio di richieste redo log space al minuto, dopo l'avvio del server.
- Redo Buffer Allocation Retry Rate - Il numero medio dei tentativi di allocazione del buffer al minuto, dopo l'avvio del server.
Le metriche ritornate ed i limiti con i quali esse vengono confrontate, sono dei numeri che rappresentano il rapporto di modifica degli eventi al minuto. Il rapporto di variazione per queste metriche, dovrebbe essere controllato poichè un aumento rapido può indicare la presenza di problemi che richiedono una vostra azione.
Tabella A.59. Impostazioni di Oracle::Redo Log
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Timeout* | 30 |
| Critical Redo Log Space Request Rate Massimo | |
| Warning Redo Log Space Request Rate Massimo | |
| Critical Redo Buffer Allocation Retry Rate Massimo | |
| Warning Redo Buffer Allocation Retry Rate Massimo |
A.9.13. Oracle::Table Extents
Il probe Oracle::Table Extents controlla una istanza del database di Oracle e raccoglie le seguenti metriche:
- Allocated Extents-Any Table - Il numero totale di estensioni per ogni tabella.
- Available Extents-Any Table - La percentuale di estensioni disponibili per ogni tabella.
In Oracle, le estensioni permettono alla tabella di crescere. Quando una tabella risulta piena, essa viene estesa da una quantità di spazio configurato quando la tabella viene creata. Le estensioni vengono configurate in base ad ogni tabella, con una dimensione estesa e un numero massimo di estensioni.
Per esempio, una tabella che inizia con uno spazio di 10 MB ed è configurata con una misura estesa di 1 MB, con delle estensioni massime di 10, può crescere fino ad un massimo di 20 MB (estesa dieci volte 1 MB). Il suddetto probe può essere configurato in modo da allertare in presenza di (1) un numero di estensioni allocate (es. "vai in uno stato critical quando la tabella è stata estesa 5 o più volte"), o (2) se la tabella è stata estesa oltre una certa percentuale che và oltre le estensioni massime (es. " vai in uno stato critical quando la tabella ha esaurito l'80% (o oltre) le proprie estensioni massime").
I campi Proprietario della tabella e Nome della tabella, contengono un valore di default di
% che corrisponderà ad ogni proprietario della tabella o nome.
Tabella A.60. Impostazioni di Oracle::Table Extents
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Proprietario della tabella* | % |
| Nome della tabella* | % |
| Timeout* | 30 |
| Critical Estensioni massime assegnate | |
| Warning Estensioni massime assegnate | |
| Critical Estensioni massime disponibili | |
| Warning Estensioni massime disponibili |
A.9.14. Utilizzo di Oracle::Tablespace
Il probe Oracle::Tablespace Usage controlla una istanza del database di Oracle e raccoglie la seguente metrica:
- Spazio disponibili utilizzato - Percentuale di spazio disponibile utilizzato presente in ogni tablespace.
Tablespace è un pool condiviso di spazio nel quale è presente un set di tabelle. Il suddetto probe avvisa l'utente quando la quantità totale di spazio disponibile và al di sotto del limite stabilito. Tablespace viene misurato in byte, per questo motivo le estensioni non influenzano direttamente l'intero processo (anche se ogni estensione è in grado di rimuovere spazio disponibile dal pool condiviso).
Il campo Nome del Tablespace richiesto risulta essere case-sensitive, e contiene un valore di default
%, in grado di corrispondere aqualsiasi nome della tabella.
Tabella A.61. Impostazioni di Oracle::Tablespace Usage
| Campo | Valore |
|---|---|
| Oracle SID* | |
| Nome utente di Oracle* | |
| Password di Oracle* | |
| Porta di Oracle* | 1521 |
| Nome tablespace* | % |
| Timeout* | 30 |
| Critical Spazio disponibile massimo usato | |
| Warning Spazio disponibile massimo usato |
A.9.15. Oracle::TNS Ping
Il probe Oracle::TNS Ping determina se un listener di Oracle sia in uno stato 'alive', e raccoglie la seguente metrica:
- Latenza del Servizio Remoto - Il tempo necessario, espresso in secondi, al server Oracle per rispondere ad una richiesta di collegamento.
Tabella A.62. Impostazioni di Oracle::TNS Ping
| Campo | Valore |
|---|---|
| TNS Listener Port* | 1521 |
| Timeout* | 15 |
| Critical Latenza Massima del Servizio Remoto | |
| Warning Latenza Massima del Servizio Remoto |
A.10. Red Hat Satellite
I probe presenti in questa sezione possono essere applicati sullo stesso Red Hat Satellite, in modo da controllare il proprio stato di salute e le proprie prestazioni. Poichè i suddetti probe vengono eseguiti in modo locale, nessuna applicazione specifica o protocolli di trasporto sono necessari.
A.10.1. Red Hat Satellite::Disk Space
Il probe Red Hat Satellite::Disk Space controlla lo spazio del disco disponibile su di un Satellite e raccoglie le seguenti metriche:
- File system utilizzato - Percentuale di file system attualmente in uso.
- Spazio utilizzato - Dimensione del file utilizzato dal file system corrente.
- Spazio disponibile — Dimensione del file disponibile per il file system corrente.
Tabella A.63. Impostazioni Red Hat Satellite::Disk Space
| Campo | Valore |
|---|---|
| Nome percorso del dispositivo* | /dev/hda1 |
| Critical File system Massimo Utilizzato | |
| Warning File system Massimo Utilizzato | |
| Critical Spazio Massimo Utilizzato | |
| Warning Spazio Massimo Utilizzato | |
| Critical Spazio Massimo Disponibile | |
| Warning Spazio Massimo Disponibile |
A.10.2. Red Hat Satellite::Execution Time
Il probe Red Hat Satellite::Execution Time controlla il tempo di esecuzione dei probe eseguiti da un Satellite, e raccoglie la seguente metrica:
- Probe Execution Time Average - La quantità di secondi necessaria per eseguire in modo completo un probe.
Tabella A.64. Impostazioni Red Hat Satellite::Execution Time
| Campo | Valore |
|---|---|
| Critical Probe Execution Time Average Massimo | |
| Warning Probe Execution Time Average Massimo |
A.10.3. Red Hat Satellite::Interface Traffic
Il probe Red Hat Satellite::Interface Traffic controlla il traffico dell'interfaccia presente su di un Satellite e raccoglie le seguenti metriche:
- Velocità di Input - Quantità di traffico, espressa in byte al secondo, che il dispositivo riceve.
- Velocità Output - Quantità di traffico, espressa in byte al secondo, che il dispositivo invia.
Tabella A.65. Impostazioni Red Hat Satellite::Interface Traffic
| Campo | Valore |
|---|---|
| Interfaccia* | eth0 |
| Timeout (secondi)* | 30 |
| Critical Velocità Input Massima | |
| Critical Velocità Output Massima |
A.10.4. Red Hat Satellite::Latency
Il probe Red Hat Satellite::Latency controlla la latenza dei probe presenti su di un Satellite e raccoglie la seguente metrica:
- Probe Latency Average - Il ritardo espresso in secondi, tra il tempo entro il quale un probe risulta essere pronto all'esecuzione, ed il tempo entro il quale il probe stesso viene eseguito. In condizioni normali, tale periodo risulterà essere meno di un secondo. Quando un Satellite risulta essere sovraccarico (poichè presenta troppi probe rispetto al tempo di esecuzione normale), tale valore cresce.
Tabella A.66. Impostazioni Red Hat Satellite::Latency
| Campo | Valore |
|---|---|
| Critical Probe Latency Average Massima | |
| Warning Probe Latency Average Massima |
A.10.5. Red Hat Satellite::Load
Il probe Red Hat Satellite::Load controlla il carico della CPU su di un Satellite e raccoglie la seguente metrica:
- Load - Il carico medio presente in una CPU per un periodo di 1-, 5-, e 15-minuti.
Tabella A.67. Impostazioni Red Hat Satellite::Load
| Campo | Valore |
|---|---|
| Critical Media Massima di 1 minuto | |
| Warning Media Massima di 1 minuto | |
| Critical Media Massima di 5 minuti | |
| Warning Media Massima di 5 minuti | |
| Critical Media Massima di 15 minuti | |
| Warning Media Massima di 15 minuti |
A.10.6. Red Hat Satellite::Probe Count
Il probe Red Hat Satellite::Probe controlla il numero di probe presenti su di un Satellite e raccoglie la seguente metrica:
- Probe - Numero di probe individuali su di un Satellite.
Tabella A.68. Impostazioni Red Hat Satellite::Probe Count
| Campo | Valore |
|---|---|
| Critical Probe Count Massimo | |
| Warning Probe Count Massimo |
A.10.7. Red Hat Satellite::Process Counts
Il probe Red Hat Satellite::Process Counts controlla il numero di processi presenti su di un Satellite e raccoglie le seguenti metriche:
- Blocked - Il numero di processi smistati sia su di una coda che su di uno stato di attesa.
- Child - Il numero di processi emessi da un altro processo che risulta essere già in esecuzione sulla macchina.
- Defunct - Il numero di processi terminati (sia perchè sono stati interrotti 'killed' da un segnale, oppure perchè chiamati dal comando
exit()), dei quali i rispettivi processi genitori non hanno ancora ricevuto una notifica della loro terminazione, eseguendo una chiamatawait(). - Stopped - Numero di processi arrestati prima del completamento della loro esecuzione.
- Riposo - Un processo che risulta essere in un riposo
Interruptible, e integrabile nella memoria in un secondo momento, con possibilità di ripresa dell'esecuzione dove precedentemente arrestata.
Tabella A.69. Impostazioni Red Hat Satellite::Process Counts
| Campo | Valore |
|---|---|
| Critical Processi massimi arrestati | |
| Warning Processi Massimi Bloccati | |
| Critical Processi Figlio Massimi | |
| Warning Processi Figlio Massimi | |
| Critical Processi Massimi Morti | |
| Warning Processi Massimi Morti | |
| Critical Processi Massimi Arrestati | |
| Warning Processi Massimi Arrestati | |
| Critical Processi Massimi in Riposo | |
| Warning Processi Massimi in Riposo |
A.10.8. Red Hat Satellite::Processes
Il probe Red Hat Satellite::Processes controlla il numero di processi presenti su di un Satellite e raccoglie le seguenti metriche:
- Processi - Il numero di processi in esecuzione simultaneamente sulla macchina.
Tabella A.70. Impostazioni Red Hat Satellite::Processes
| Campo | Valore |
|---|---|
| Critical Processi Massimi | |
| Warning Processi Massimi |
A.10.9. Red Hat Satellite::Process Health
Il probe Red Hat Satellite::Process Health controlla i processi specificati dall'utente e raccoglie le seguenti metriche:
- Utilizzo CPU - Percentuale di utilizzo della CPU per un processo dato.
- Gruppi di processi figlio - Il numero di processi figli originati dal processo genitore specificato. Un processo figlio eredita la maggior parte dei propri attributi, come gli open file, dal proprio genitore.
- Thread - Il numero di thread in esecuzione per un dato processo. Un thread è una unità di base riguardante l'utilizzo della CPU, e consiste in un conteggiatore di programma, un set registratore, ed uno spazio dello stack. Un thread viene anche chiamato processo leggero.
- Memoria Fisica Utilizzata - Quantità di memoria fisica, espressa in kilobytes, utilizzata dal processo specificato.
- Memoria Virtuale utilizzata - Quantità di memoria virtuale utilizzata, espressa in kilobyte, da un processo specificato, oppure la misura del processo presente nella memoria reale più lo swap.
Specifica il processo inserendo il nome del comando o l'I.D. del processo (PID). Inserendo un PID, verrà annullata la entry nome del comando. Se nessun nome o PID viene inserito, verrà visualizzato l'errore Command not found ed il probe verrà impostato su CRITICAL.
Tabella A.71. Impostazioni Red Hat Satellite::Process Health
| Campo | Valore |
|---|---|
| Nome del comando | |
| File ID del processo (PID) | |
| Timeout* | 15 |
| Critical Utilizzo Massimo della CPU | |
| Warning Utilizzo CPU Massimo | |
| Critical Gruppi Massimi di Processi Figli | |
| Warning Gruppi Massimi di Processo Figlio | |
| Critical Thread Massimi | |
| Warning Trhead Massimi | |
| Critical Memoria Fisica Massima Utilizzata | |
| Warning Memoria Fisica Massima Utilizzata | |
| Critical Memoria Virtuale Massima Utilizzata | |
| Warning Memoria Virtuale Massima Utilizzata |
A.10.10. Red Hat Satellite::Process Running
Il probe Red Hat Satellite::Process Running verifica che il processo specificato sia in esecuzione. Specificare il processo a seconda del nome del comando o tramite il process I.D. (PID). Inserendo un PID verrà annullata la entry del nome del comando. Se il probe non è in grado di verificare il comando o il PID, verrà ritornato uno stato Critical.
Tabella A.72. Impostazioni Red Hat Satellite::Process Running
| Campo | Valore |
|---|---|
| Nome del comando | |
| File ID del processo (PID) | |
| Critical Numero Massimo in Esecuzione | |
| Critical Numero Minimo in Esecuzione |
A.10.11. Red Hat Satellite::Swap
Il probe Red Hat Satellite::Swap controlla la percentuale di spazio di swap disponibile presente su di un Satellite. Se il valore risulta inferiore a quello del limite Critical, verrà ritornato uno stato CRITICAL. Se invece il valore risulta inferiore a quello del limite di Warning, verrà ritornato uno stato di WARNING.
Tabella A.73. Impostazioni Red Hat Satellite::Swap
| Campo | Valore |
|---|---|
| Critical Percentuale di Swap Massima Disponibile | |
| Warning Percentuale di Swap Minima Disponibile |
A.10.12. Red Hat Satellite::Users
Il probe Red Hat Satellite::Users controlla il numero di utenti attualmente registrati all'interno di Satellite. Se il valore risulta superiore al limite Critical, verrà ritornato uno stato CRITICAL. Se invece il valore risulta superiore a quello del livello di Warning, verrà ritornato uno stato di WARNING.
Tabella A.74. Impostazioni Red Hat Satellite::Users
| Campo | Valore |
|---|---|
| Critical Utenti Massimi | |
| Warning Utenti Massimi |
Appendice B. Diario delle Revisioni
| Diario delle Revisioni | ||||||||
|---|---|---|---|---|---|---|---|---|
| Revisione 4-32.2.400 | 2013-10-31 | |||||||
| ||||||||
| Revisione 4-32.2 | Fri Aug 30 2013 | |||||||
| ||||||||
| Revisione 4-32.1 | Fri Aug 30 2013 | |||||||
| ||||||||
| Revisione 4-32 | Thu Aug 29 2013 | |||||||
| ||||||||
| Revisione 4-31 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-30 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-29 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-28 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-27 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-26 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-25 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-24 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-23 | Tue Aug 27 2013 | |||||||
| ||||||||
| Revisione 4-22 | Thu Aug 15 2013 | |||||||
| ||||||||
| Revisione 4-21 | Sun Jul 28 2013 | |||||||
| ||||||||
| Revisione 4-20 | Wed Jul 24 2013 | |||||||
| ||||||||
| Revisione 4-19 | Tue Jul 23 2013 | |||||||
| ||||||||
| Revisione 4-18 | Thu Jul 12 2013 | |||||||
| ||||||||
| Revisione 4-17 | Thu Jul 12 2013 | |||||||
| ||||||||
| Revisione 4-16 | Thu Jul 11 2013 | |||||||
| ||||||||
| Revisione 4-15 | Fri Jul 5 2013 | |||||||
| ||||||||
| Revisione 4-14 | Fri Jul 5 2013 | |||||||
| ||||||||
| Revisione 4-13 | Fri June 28 2013 | |||||||
| ||||||||
| Revisione 4-12 | Tue June 4 2013 | |||||||
| ||||||||
| Revisione 4-11 | Fri May 17 2013 | |||||||
| ||||||||
| Revisione 4-10 | Thu Apr 25 2013 | |||||||
| ||||||||
| Revisione 4-9 | Thu Feb 28 2013 | |||||||
| ||||||||
| Revisione 4-8 | Wed Jan 2 2013 | |||||||
| ||||||||
| Revisione 4-7 | Wed Sept 19 2012 | |||||||
| ||||||||
| Revisione 4-6 | Thu Aug 16 2012 | |||||||
| ||||||||
| Revisione 4-5 | Thu Aug 16 2012 | |||||||
| ||||||||
| Revisione 4-4 | Wed Aug 15 2012 | |||||||
| ||||||||
| Revisione 4-3 | Thu Aug 9 2012 | |||||||
| ||||||||
| Revisione 3-2 | Fri Aug 3 2012 | |||||||
| ||||||||
| Revisione 3-1 | Tue Jun 17 2012 | |||||||
| ||||||||
| Revisione 3-0 | Thurs May 24 2012 | |||||||
| ||||||||
| Revisione 2-6 | Mon Jan 9 2012 | |||||||
| ||||||||
| Revisione 2-5 | Wed Jan 4 2012 | |||||||
| ||||||||
| Revisione 2-4 | Fri Sep 23 2011 | |||||||
| ||||||||
| Revisione 2-3 | Mon Aug 15 2011 | |||||||
| ||||||||
| Revisione 2-2 | Wed Jun 15 2011 | |||||||
| ||||||||
| Revisione 2-1 | Fri May 27 2011 | |||||||
| ||||||||
| Revisione 2-0 | Fri May 6 2011 | |||||||
| ||||||||
| Revisione 1-29 | Fri March 25 2011 | |||||||
| ||||||||
| Revisione 1-28 | Thu March 24 2011 | |||||||
| ||||||||
| Revisione 1-27 | Mon Feb 14 2011 | |||||||
| ||||||||
| Revisione 1-26 | Wed Feb 9 2011 | |||||||
| ||||||||
| Revisione 1-25 | Mon Jan 31 2011 | |||||||
| ||||||||
Nota Legale
Copyright © 2013 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.