Si les contenus d'un patch signé sont extraits dans le même répertoire en tant que patch signé, le patch extrait ne peut pas être installé au moyen de la commande /usr/sbin/patchadd. Le patch signé est exécuté lorsque vous exécutez la commande /usr/sbin/patchadd ./id_patch. Le patch extrait non signé est ignoré.
Dans certains cas, les messages d'erreur suivants peuvent s'afficher :
Verifying signed patch patchid... ERROR: Unable to open keystore /var/sadm/security/patchadd /truststore for reading ERROR: Unable to lock keystore /var/sadm/security for exclusive access Signature invalid on signed patch patchid. Patchadd is terminating. |
Solution : choisissez l'une des solutions ci-dessous.
Extrayez le patch signé dans un autre répertoire que celui où il figure. Utilisez le chemin d'accès au patch extrait lorsque vous exécutez la commande /usr/sbin/patchadd.
Après avoir extrait le patch signé mais avant d'exécuter la commande /usr/sbin/patchadd, supprimez le fichier .jar.
N'extrayez pas le patch signé. Au lieu de cela, remplissez le fichier Keystore du package et installez le patch signé directement. Procédez comme suit :
Devenez superutilisateur.
Exécutez les commandes suivantes :
# /usr/bin/mkdir /var/sadm/security |
# /usr/bin/keytool -export -storepass changeit -alias \ gtecybertrustca -keystore usr/java/jre/lib/security/cacerts -file \ /tmp/gte.crt |
# /usr/bin/pkgadm addcert -t -f der /tmp/gte.crt |
modifiez le mot de passe par défaut changeit par celui qui est utilisé pour protéger le fichier Keystore de Java.
Lorsque vous utilisez la commande lucreate pour créer un nouvel environnement d'initialisation, cette dernière échoue dans les cas suivants :
Le chemin d'accès d'un périphérique de stockage monté est un sous-ensemble du chemin d'accès d'un autre périphérique de stockage monté.
Par exemple, un système de fichiers est actuellement monté sur /dev/md/dsk/ d1 alors qu'un autre système de fichiers est monté sur /dev/md/dsk/d10.
Le chemin d'accès d'un périphérique monté est un sous-ensemble du chemin d'accès d'un périphérique de stockage utilisé comme argument de la commande lucreate.
Par exemple, un système de fichiers est actuellement monté sur /dev/md/dsk/ d10, et /dev/md/dsk/d100 est utilisé comme option de la commande lucreate pour spécifier un système de fichiers du nouvel environnement d'exploitation.
Des messages d'erreurs trompeurs tels que ceux-ci s'affichent :
The file system creation utility /usr/lib/fs/ufsufs/mkfs is not available. |
Unable to create all required file systems for environnement_initialisation. |
Cannot make file systems for environnement_initialisation |
Solution : assurez-vous qu'il n'y a pas, sur les périphériques de stockage, de systèmes de fichiers en cours d'utilisation portant des noms correspondant à des sous-ensembles d'autres périphériques de stockage dont les systèmes de fichiers sont aussi en cours d'utilisation.
S'il existe une ambiguïté au niveau des noms des systèmes de fichiers montés, renommez les métapériphériques de la gestion de volumes Solaris existants.
Dans la solution suivante, d10 et d100 ne sont utilisés qu'à titre d'exemples. Voici d'autres exemples de noms de périphériques ambigus : d20 et d200 ou d377 et d37, où d20 correspond à d200 et d377 correspond à d37.
Devenez superutilisateur.
Utilisez la commande metarename pour modifier un des noms de métapériphériques ambigus.
# metarename d10 d300 |
Le métapériphérique d10 est renommé d300.
le système de fichier installé sur d10 doit être démonté avant l'utilisation de la commande metarename.
Une fois le système de fichiers démonté, modifiez le fichier /etc/vfstab. Éditez également tous les fichiers de configuration contenant le nom du métapériphérique que vous renommez. Vous devrez modifier toute référence à l'ancien nom de métapériphérique par son nouveau nom.
Si un processus est en cours d'accès aux données sur le système de fichiers, démontez celui-ci en faisant passer le système en mode monoutilisateur. Réinitialisez le système après avoir fait les modifications.
Des erreurs se produisent si vous utilisez Solaris Management Console pour effectuer des opérations sur un compte utilisateur ou groupe d’un système agissant comme un serveur DNS. Ces erreurs se produisent si le fichier /etc/named.conf figure sur le système.
Les erreurs surviennent lorsque vous effectuez ces opérations depuis l'interface utlisateur graphique ou lorsque vous utilisez les commandes smuser et smgroup, interfaces de la ligne de commande pour la console.
La console ouvre une nouvelle boîte de dialogue ou la commande smuser envoie les messages d'erreur ci-après lorsqu'elle est effectuée sur un utilisateur :
"The attempt to view Users or Roles has failed due to an unexpected error. This was caused by the following error: CIM_ERR_FAILED." |
La console ouvre une nouvelle boîte de dialogue ou la commande smuser envoie les messages d'erreur ci-après lorsqu'elle est effectuée sur un groupe :
"Attempted Read of Group IDs failed with unexpected CIM error: CIM_ERR_FAILED."operations from the GUI or command-line interface. |
Solution : choisissez l'une des solutions indiquées ci-dessous.
Pour résoudre le problème en redémarrant le serveur DNS, suivez les étapes ci-dessous.
Devenez superutilisateur.
Placez le fichier named.conf dans un autre répertoire. Exemple :
# mv /etc/named.conf /var/named/named.conf |
Redémarrez le serveur DNS.
# pkill -9 in.named |
# /usr/sbin/in.named /var/named/named.conf |
Pour résoudre le problème en redémarrant le serveur WBEM, suivez les étapes ci-dessous :
Devenez superutilisateur.
À l'aide d'un éditeur de texte, éditez le fichier /usr/sadm/lib/wbem/WbemUtilityServices.properties .
Remplacez la chaîne /etc/named.conf par /tmp/nouveau_nom_fichier.
assurez-vous que le nom de fichier que vous avez choisi n'est pas déjà attribué sur le système.
Arrêtez le serveur WBEM.
# /etc/init.d/init.wbem stop |
Démarrez le serveur WBEM.
# /etc/init.d/init.wbem start |
Pour obtenir de plus amples informations, consultez les pages smuser( 1M) et smgroup (1M) du manuel.
Vous initialisez un serveur d'entrée Sun LX50 sur lequel sont installés une partition de service et le logiciel Solaris 9 12/03 (Édition pour plate-forme x86). Vous avez la possibilité d’initialiser la partition de service à l’aide de la touche F4. Cependant, cela efface le contenu de l’écran. Le système ne parvient pas à initialiser la partition de service.
Solution : n'appuyez pas sur la touche F4 lorsque l'écran d'initialisation du BIOS apparaît. Après quelques secondes, l'écran affichant les informations sur la partition de disque actuelle apparaît. Sélectionnez le chiffre dans la colonne Part# correspondant à type=DIAGNOSTIC type=DIAGNOSTIC puis appuyez sur la touche Entrée. le système initialise la partition de service.
Dans la version Solaris 912/03, le message d'événement CP accompagnant certains messages d'erreur de mémoire incorrigible n'est pas toujours généré sur les systèmes basés sur la plate-forme UltraSPARC II. Ceci affecte les systèmes suivants :
Sun EnterpriseTM 10000 ;
Sun Enterprise 6500 ;
Sun Enterprise 6000 ;
Sun Enterprise 5500 ;
Sun Enterprise 5000 ;
Sun Enterprise 4500 ;
Sun Enterprise 4000 ;
Sun Enterprise 3500 ;
Sun Enterprise 3000.
Résultat : certaines informations nécessaires à l'identification d'une CPU défectueuse risquent de ne pas toujours être présentes.
Solution : pour obtenir les dernières informations sur ce problème, allez sur le site SunSolveSM à l'adresse http://sunsolve.sun.com.
Le démon Solaris WBEM Services 2.5 ne peut pas localiser les fournisseurs indiqués pour l'interface com.sun.wbem.provider ou l'interface com.sun.wbem.provider20. Même si vous créez une instance Solaris_ProviderPath pour un fournisseur indiqué pour ces interfaces, le démon Solaris WBEM Services 2.5 ne localise pas le fournisseur.
Solution : pour permettre au démon de localiser un tel fournisseur, arrêtez et redémarrez le démon Solaris WBEM Services 2.5.
# /etc/init.d/init.wbem stop # /etc/init.d/init.wbem start |
si vous utilisez l'API javax
pour développer
votre fournisseur, vous n'avez pas besoin d'arrêter puis de redémarrer
le démon Solaris WBEM Services 2.5. De fait, ce dernier reconnaît
les fournisseurs javax
de façon dynamique.
Si vous décidez d'utiliser l'interface de programmation d'application com.sun plutôt que l'API javax
pour développer votre logiciel WBEM, seul l'appel de
méthode distant (RIM) CIM est totalement supporté. Il n'est
pas certains que d'autres protocoles, tels que XML/HTTP, fonctionnent tout
à fait avec l'interface de programmation d'application com.sun.
Le tableau suivant répertorie des exemples d'appels qui sont exécutés avec succès sous RMI, mais échouent sous XML/HTTP.
Appel de méthode |
Message d'erreur |
---|---|
CIMClient.close() |
NullPointerException |
CIMClient.execQuery() |
CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED |
CIMClient.getInstance() |
CIM_ERR_FAILED |
CIMClient.invokeMethod() |
XMLERROR: ClassCastException |
L'outil de montage et de partage de Solaris Management Console ne peut pas modifier les options de montage sur des systèmes de fichiers critiques tels que root (/), /usr et /var.
Solution : choisissez l'une des solutions indiquées ci-dessous.
Utilisez l'option de remontage avec la commande de montage.
# mount -F type_système_fichiers -o remount,options_montage_supplémentaires \ périphérique_à_monter point_montage |
les modifications de propriété de montage apportées en utilisant l'option -remount avec la commande mount ne sont pas persistantes. En outre, toutes les options de montage non spécifiées dans la portion options_montage_supplémentaires de la commande précédente héritent des valeurs par défaut spécifiées par le système. Reportez-vous à la page de manuel mount_ufs(1M) pour obtenir de plus amples informations.
Modifiez l'entrée appropriée dans le fichier /etc/vfstab pour changer les propriétés de montage de système, puis réinitialisez le système.
Le message d'erreur suivant s'affiche lorsque la mémoire est insuffisante :
CIM_ERR_LOW_ON_MEMORY |
Vous ne pouvez plus ajouter d'entrées si la mémoire disponible pour CIM Object Manager devient insuffisante. Le cas échéant, vous devez réinitialiser le référentiel CIM Object Manager.
Solution : pour réinitialiser le référentiel CIM Object Manager, procédez comme indiqué ci-dessous.
Devenez superutilisateur.
Arrêtez le programme CIM Object Manager.
# /etc/init.d/init.wbem stop |
Supprimez le répertoire d'enregistrement JavaSpacesTM.
# /bin/rm -rf /var/sadm/wbem/log |
Redémarrez le programme CIM Object Manager.
# /etc/init.d/init.wbem start |
lorsque vous remettez le programme CIM Object Manager à zéro, vous perdez toutes les définitions propriétaires de votre mémoire de données. Vous devez recompiler les fichiers MOF qui contiennent ces définitions en utilisant la commande mofcomp. Voyez l'exemple ci-dessous.
# /usr/sadm/bin/mofcomp -u root -p mot_de_passe_superutilisateur votre_fichier_mof |