Questa sezione descrive i problemi di Solaris 10 connessi all'amministrazione dei sistemi.
La SolarisTM Management Console si blocca e non consente il login di root dopo aver abilitato Solaris Trusted Extensions. Può essere visualizzato il seguente messaggio di errore quando la Solaris Management Console si blocca:
Configuring the Management Server... |
Soluzione. Procedere come segue:
Configurare Solaris Trusted Extensions e avviare la Solaris Management Console.
Selezionare “Apri toolbox” dal menu Console.
Selezionare localhost se compare nell'elenco.
Diversamente, digitare localhost.
Scegliere il toolbox Policy=TSOL.
Eseguire nuovamente il login nella Solaris Management Console come utente root.
(Opzionale) Se il secondo login in Solaris Management Console non riesce, ripetere i punti da 1 a 5 digitando 127.0.0.1 al posto di localhost al punto 3.
Quando si collega una zona, se l'host originale e il nuovo host contengono pacchetti con lo stesso livello di patch ma con una cronologia intermedia differente, il collegamento della zona può non riuscire. Vengono visualizzati vari messaggi di errore. Il messaggio di errore dipende dalla cronologia delle patch dei due host.
Soluzione. Verificare che sui due host (originale e nuovo) le patch siano state applicate nella stessa sequenza.
Nei sistemi che utilizzano un controller SATA compatibile AHCI, la configurazione del BIOS consente in genere di impostare il controller nelle modalità AHCI, legacy o RAID. Solaris supporta le modalità AHCI e legacy.
L'impostazione della modalità SATA nel BIOS non deve essere modificata dopo l'installazione iniziale di Solaris. Inoltre, tale modalità SATA non deve essere modificata prima o dopo un aggiornamento di Solaris. Se l'impostazione della modalità SATA nel BIOS viene modificata dopo l'installazione di Solaris, il sistema si ripristina e non può essere avviato, senza alcuna indicazione della causa dell'errore.
Soluzione. Se dopo la modifica dell'impostazione del BIOS non è più possibile avviare il sistema, ripristinare l'impostazione originale.
A partire dalle patch 119254-42 e 119255-42, i programmi di installazione delle patch, patchadd e patchrm, sono stati modificati per cambiare il modo in cui le patch installano le nuove funzioni o gestiscono i file esistenti che sono incompatibili con il sistema in esecuzione. Questa modifica ha effetto sull'installazione delle patch in tutte le versioni di Solaris 10. Le patch ad “attivazione differita” gestiscono in modo migliore le estese modifiche contenute nelle patch del kernel.
La funzione di attivazione differita utilizza il file system di loopback, lofs, per creare una copia del file system radice. I file originali a cui viene applicata la patch vengono copiati in una posizione sicura e la patch viene applicata alla copia lofs del file system radice. In seguito, il file originale viene attivato di nuovo con lofs sopra il nuovo file a cui viene applicata la patch. In questo modo, il sistema in esecuzione resta sempre coerente, per l'intera durata della procedura di applicazione della patch. Le nuove funzioni ed eventuali modifiche non compatibili vengono nascoste fino al riavvio del sistema.
Dopo aver applicato una patch ad attivazione differita, gli utenti dovrebbero riavviare il sistema appena possibile, ma non è necessario che lo facciano immediatamente: possono applicare altre patch e quindi riavviare il sistema.
Il file README delle patch fornisce indicazioni sulle patch che richiedono il riavvio.
Sun raccomanda di applicare sempre le patch in modalità monoutente, in particolare quando questo viene richiesto esplicitamente nel file README della patch.
Se sul sistema sono presenti zone non globali o se il file system lofs è disabilitato, tenere in considerazione questi aspetti durante l'installazione o la rimozione delle patch ad attivazione differita:
Per applicare queste patch tutte le zone non globali devono essere in uno stato di arresto. È necessario arrestare la zona non globale prima di applicare la patch.
Per il corretto funzionamento, le patch ad attivazione differita richiedono che sia attivo il file system di loopback (lofs). Sulla maggior parte dei sistemi che eseguono Sun Cluster 3.1 o Sun Cluster 3.2 lofs è spesso disattivato, per le limitazioni che comporta alle funzionalità HA-NFS. Prima di installare una patch ad attivazione differita è necessario riabilitare il file system di loopback; procedere come segue.
Rimuovere o commentare la riga seguente nel file /etc/system:
exclude:lofs |
Riavviare il sistema.
Installare la patch.
Dopo aver completato l'installazione della patch, reinserire o rimuovere il commento dalla stessa riga di /etc/system.
Riavviare il sistema per riprendere le normali funzionalità.
Non viene visualizzato nessun messaggio di errore.
Soluzione. Sun consiglia l'utilizzo di Solaris Live Upgrade per gestire le patch. Solaris Live Upgrade risolve i problemi legati all'installazione delle patch su un sistema in esecuzione. Solaris Live Upgrade riduce i tempi di inattività legati all'applicazione delle patch e riduce i rischi consentendo di ripristinare lo stato originale del sistema in caso di problemi. Per maggiori informazioni, vedere la Guida all’installazione di Solaris 10 5/08: Solaris Live Upgrade e pianificazione degli aggiornamenti.
Sui file system di grandi dimensioni, ad esempio ZFS, le applicazioni che usano statvfs(2) o statfs(2) per ottenere informazioni sullo stato del file system possono produrre un errore. Viene visualizzato il seguente messaggio di errore:
Il valore è troppo grande per il tipo di dati definito |
Soluzione. Le applicazioni dovrebbero utilizzare statvfs64().
Sui sistemi che eseguono una versione di Solaris che non supporta le zone, l'utilizzo di patchadd -R o di qualsiasi comando che accetta l'opzione -R per specificare un percorso radice alternativo per una zona globale in cui sono installate zone non globali, non funziona correttamente.
A differenza di quanto accade con il comando luupgrade [-t, -T, -p, -P] non viene visualizzato nessun messaggio di errore che indica le opportune limitazioni del comando.
Non viene segnalato che l'opzione -R non funziona correttamente. Come conseguenza di questa condizione, i pacchetti o le patch di Solaris 10 non vengono installati in nessuna delle zone non globali presenti.
Il problema si verifica durante l'installazione o la disinstallazione dei pacchetti o delle patch.
L'opzione -R funziona se nell'ambiente di boot alternativo sono state configurate zone non globali ma non sono state installate zone non globali. Per evitare potenziali problemi, o se non si è certi della presenza di zone non globali usate come percorsi radice alternativi, limitare l'utilizzo dell'opzione -R in tutte le istanze.
Per maggiori informazioni, vedere le seguenti pagine man:
Soluzione 1. Aggiornare il sistema operativo a Solaris 10 1/06 o versione successiva.
Se si esegue Solaris 10 3/05, installare le seguenti patch per consentire l'utilizzo dei comandi che accettano l'opzione -R per creare un percorso radice alternativo:
Patch con ID 119254-19 per i sistemi SPARC
Patch con ID 119255-19 per i sistemi x86
Soluzione 2. Limitare l'utilizzo di patchadd -R o di altri comandi che accettano l'opzione -R per creare un percorso radice alternativo.
Avviare la radice alternativa, ad esempio Solaris 10, come sistema operativo attivo. Quindi installare e disinstallare i pacchetti e le patch di Solaris 10 senza usare l'opzione -R.
Un sistema che esegue Sun Patch Manager Tool 2.0 può gestire i sistemi remoti che utilizzano Patch Manager Tool, anche nella versione 1.0.
Tuttavia, un sistema con una versione precedente di Patch Manager Tool non può gestire i sistemi remoti che utilizzano Patch Manager Tool 2.0. Le versioni precedenti includono:
Sun Patch Manager Base Software 1.x
Sun Patch Manager Tool 1.0
Il sistema operativo Solaris 8 non supporta il modello CIM/WBEM (Common Information Model/Web Based Enterprise Management) per Patch Manager Tool. Ciò comporta che sui sistemi Solaris 8 non è possibile eseguire la gestione remota con Patch Manager.
Se si utilizza il comando smdiskless per eliminare un client diskless, il comando non riesce. Il client diskless non viene rimosso dai database del sistema. Viene visualizzato il seguente messaggio di errore:
Failing with error EXM_BMS. |
Soluzione. Disabilitare la condivisione della partizione /export prima di aggiungere il client.
Se si utilizza il comando smosservice delete per rimuovere un servizio di un client diskless, il comando non rimuove correttamente tutte le directory del servizio.
Soluzione. Procedere come segue.
Verificare che non siano presenti client che utilizzano il servizio.
# unshare /export/exec/Solaris_10_sparc.all # rm -rf /export/exec/Solaris_10_sparc.all # rm -rf /export/exec/.copyofSolaris_10_sparc.all # rm -rf /export/.copyofSolaris_10 # rm -rf /export/Solaris_10 # rm -rf /export/share # rm -rf /export/root/templates/Solaris_10 # rm -rf /export/root/clone/Solaris_10 # rm -rf /tftpboot/inetboot.sun4u.Solaris_10 |
Rimuovere la voce seguente dal file /etc/bootparams.
fs1-24 boottype=:os |
Rimuovere questa voce solo se il file server non fornisce funzioni o risorse per altri servizi.
Rimuovere la voce seguente dal file /etc/dfs/dfstab.
share -F nfs -o ro /export/exec/Solaris_8_sparc.all/usr |
Modificare il file /var/sadm/system/admin/services/Solaris_10.
Se il file server non è Solaris_10, eliminare il file.
Se il file server è Solaris_10, rimuovere tutte le voci che compaiono dopo le prime tre righe. Le righe eliminate indicano i pacchetti del servizio USR_PATH e SPOOLED ROOT in /export/root/templates/Solaris_10 e nelle piattaforme supportate.
Dopo aver modificato il contenuto di snmpd.conf, è possibile eseguire il comando kill -HUP ID processo snmp. Questo comando arresta il processo snmp. Il comando invia quindi un segnale all'agente master del System Management Agent (snmpd) perché rilegga snmpd.conf e implementi le modifiche apportate. Non sempre il comando produce la rilettura del file di configurazione da parte dell'agente master. Di conseguenza, non sempre l'uso del comando rende effettive le modifiche del file di configurazione.
Anziché utilizzare kill -HUP, riavviare il System Management Agent dopo una modifica al file snmpd.conf. Procedere come segue:
Diventare superutente.
Digitare il comando seguente:
# /etc/init.d/init.sma restart
Si supponga di dover avviare un sistema Sun LX50 che dispone di una partizione di servizio e su cui è installato Solaris 10 per x86. Premendo il tasto funzione F4, quando richiesto, per avviare la partizione di servizio, lo schermo diventa vuoto. Il sistema non avvia la partizione di servizio.
Soluzione. Non premere il tasto F4 mentre è visualizzata la schermata di avvio del BIOS. Dopo un periodo di timeout, compare la schermata con le informazioni sulla partizione attiva del disco. Nella colonna del numero di partizione, selezionare il numero corrispondente a type=DIAGNOSTIC. Premere Invio. Il sistema avvia la partizione di servizio.
Se si sceglie di usare la API com.sun al posto della API javax
per sviluppare un software WBEM, sono pienamente supportate solo le chiamate remote (RMI) ai metodi CIM (Common Information Model). Non è garantito che altri protocolli, ad esempio XML/HTTP, funzionino perfettamente con la API com.sun.
La tabella seguente riporta alcuni esempi di chiamate che vengono eseguite correttamente con RMI ma non con XML/HTTP.
Chiamata del metodo |
Messaggio di errore |
---|---|
CIMClient.close() |
NullPointerException |
CIMClient.execQuery() |
CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED |
CIMClient.getInstance() |
CIM_ERR_FAILED |
CIMClient.invokeMethod() |
XMLERROR: ClassCastException |