Micro Focus Server Automation – Trucs et astuces

30 octobre 2021

Table des matières

  • Micro Focus Server Automation – Trucs et astuces – Janvier 2021
    • 1. Lorsque l'utilisateur ne peut pas supprimer un agent SA sous Windows
    • 2. Lorsqu'un module Opsware-agent est perdu sur le cœur principal
    • 3. Résoudre l'erreur word_uploads n'a pas été complètement installé lors de la mise à niveau
    • 4. Résoudre l'espace du système de fichiers surchargé
    • 5. Correction de l'erreur lorsque Server Automation n'a pas réussi à trouver le fichier de version Oracle principal pendant le processus d'installation
    • 6. Gestion de la taille du tas de torsion pour de meilleures performances
    • 7. Résoudre l'échec des prérequis observé au moment de la mise à niveau
    • 8. Instructions pour désactiver le composant buildmgr
    • 9. Instructions sur la recherche et l'identification des versions SA
    • 10. Correction du système ne peut pas trouver l'erreur install_tool_x64.exe
  • Micro Focus Server Automation – Trucs et astuces – Février 2021
    • 1. Server Automation (SA) : la mise à niveau du noyau SA vers RH7.6/RH7.7 échoue
    • 2. Server Automation (SA) : la commande uln_import échoue avec la chaîne de tampon attendue Erreur
    • 3. Prise en charge de la plate-forme - Erreur SuSE 15
    • 4. L'agent utilise l'algorithme de signature sha1WithRSAEncryption dans l'erreur de certificat
    • 5. Server Automation (SA) : Échec de l'enregistrement de l'erreur utilisateur lors de l'exécution de l'erreur uln_import
    • 6. Server Automation (SA) : message d'expiration du délai d'attente affiché lors de l'installation des derniers correctifs Windows Erreur
    • 7. Automatisation du serveur (SA) : étapes de préparation de SA pour le portage du code Python 2 vers l'erreur Python 3
    • 8. Server Automation (SA) : l'utilitaire MpC échoue en raison d'une erreur d'authentification de l'utilisateur
    • 9. Opsware-sas : Impossible de démarrer la torsion - la vérification des dépendances a échoué. Erreur
    • 10. OSBP 'Set Media Source' ne fonctionne pas lors du démarrage avec l'erreur Windows PE 10
  • Micro Focus Server Automation – Trucs et astuces – Mars 2021
    • 1. Procédure pour réinstaller l'agent sur un satellite après une corruption récente de l'outil en raison de problèmes de certificat
    • 2. Résolution du problème avec SLES pour SAP qui affiche un système d'exploitation inconnu
    • 3. Solution pour les erreurs de script par l'agent SA
    • 4. Correctif pour Windows 2016 signalé comme un système d'exploitation inconnu
    • 5. Comment débloquer les utilisateurs de la base de données
    • 6. Exécution du déploiement du programme d'installation de la plate-forme
    • 7. Solution pour les erreurs de transaction ActionStatus.ABORT_Only n'est pas dans un état valide
    • 8. Comment définir SQLNET.ALLOWED_LOGON_VERSION_SERVER sur 11 ou moins
    • 9. Comment installer l'extension de serveur pour les logiciels enregistrés ne peut pas être installé
    • 10. Solution pour l'absence de réponse de l'automatisation du serveur 10.60
  • Micro Focus Server Automation – Trucs et astuces – Avril 2021
  • Micro Focus Server Automation – Trucs et astuces – Mai 2021
    • 1. Questions sur la construction de l'ancien 10.20 au nouveau 2018.08.
    • 2. Questions sur la politique des logiciels
    • 3. Capacités de seuil de verrouillage de compte - 64256 #jm#.
    • 4. Erreur lors de l'exécution de la commande cora dans SA 10.60
    • 5. Problèmes avec les tâches HPSA après la mise à niveau
    • 6. L'installation de l'agent a échoué sur le satellite crsauapz3pa0
    • 7. Comment utiliser nohup dans un script SA avec 10.60 ?
    • 8. Erreur d'installation de la plate-forme
    • 9. Prise en charge d'Exadata pour HPSA/DMA
    • 10. Prise en charge des serveurs HPE Proliant pour un approvisionnement intelligent
  • Micro Focus Server Automation – Trucs et astuces – Juin 2021
    • 1. Avertissement : /packages/any/nt/5.2/PsSasHost.exe n'a pas pu être téléchargé
      • Je souhaite connaître l'avertissement /packages/any/nt/5.2/PsSasHost.exe qu'ils reçoivent lors de l'exécution d'une correction d'audit et le script de correction est un script PowerShell personnalisé. En arrière-plan, cela se produit dans mon environnement 10.60 où j'ai migré tout notre contenu et nos serveurs à partir de 10.21.
      • C'est très reproductible dans mon environnement de production et de développement. La correction semble s'exécuter avec succès, mais c'est un avertissement qui dérange les utilisateurs. Cela ne se produit pas pour les stratégies d'audit qui utilisent des scripts personnalisés bat ou python, uniquement lorsque le script de correction est un Power Shell. Et cela se produit avec du contenu nouvellement créé, pas seulement avec du contenu migré.
      • Je sais que Windows 5.2 est Windows 2003 qui n'est pas pris en charge dans 10.60, donc je suppose qu'une politique logicielle ou QUELQUE CHOSE contient cela et que nous devons le supprimer ?
    • Solution
    • 2. Le correctif Q4025337 a été installé plusieurs fois avec succès, mais s'affiche comme manquant
    • 3. Existe-t-il un moyen d'exporter les résultats d'audit au format PDF à partir d'OGFS ?
    • 4. ÉTATS-UNIS UNIQUEMENT Question HPSA sur l'envoi de journaux.
    • 5. Les seuils peuvent-ils être modifiés lorsque la sonde vérifie table_space ?
    • 6. L'agent SA donne une erreur pour tous les scripts
    • 7. Erreurs sur le tableau de bord OBR, le flux suivant est erroné ; conformité du logiciel.
    • 8. Les travaux d'installation de l'agent SA ne s'arrêtent qu'à l'étape binaire de l'agent
    • 9. HPSA 10.60 Production – Problèmes de sécurité à corriger.

Micro Focus Server Automation – Trucs et astuces – Avril 2021

Server Automation (SA) : la mise à niveau du noyau SA vers RH7.6/RH7.7 échoue

Avez-vous essayé de mettre à niveau le système d'exploitation d'un Server Automation (SA) avec un noyau de RH7.x vers RH7.6/RH7.7 ? Il échoue dans la phase d'évaluation avec une erreur sur le régime ksh.

Une erreur s'affiche lors de la tentative d'exécution d'une mise à niveau mineure du système d'exploitation de Redhat 7.x (7.0 à 7.5) vers Redhat 7.6 ou 7.7. Voici l'erreur lors de l'exécution de la commande yum upgrade.



Paquet : OPSWoracle_rdbms_part3-12.1.0.2.0-6.x86_64 (installé)

Nécessite : /usr/bin/ksh

Suppression : ksh-20120801-137.el7.x86_64 (@rhel-7-server-rpms

Pas trouvé

Mis à jour par : ksh-20120801-139.el7.x86_64 (rhel-7-server-rpms)

Pas trouvé

La mise à niveau est alors abandonnée.

Note 1 : La version du package ksh en cours de suppression (ksh-20120801-137) variera en fonction de la version de Redhat 7.x déjà chargée.

Note 2: Seules les mises à niveau mineures du système d'exploitation sont autorisées sur les serveurs principaux SA. Les mises à niveau majeures du système d'exploitation (par exemple, RH 6.x vers RH7.x) ne sont pas autorisées.

Ce problème survient en raison du changement de lien utilisé par les versions ultérieures de Redhat pour le binaire ksh. Les versions précédentes de Redhat fournissaient un lien entre /bin/ksh et /usr/bin/ksh.

Pour résoudre le problème, l'une des deux solutions de contournement peut être utilisée.

Méthode 1 : Demandez à yum d'ignorer la mise à niveau ksh rpm lors de la mise à niveau du système d'exploitation. Au lieu de la mise à niveau yum, utilisez yum -x ksh upgrade

Méthode 2 : Téléchargez le dernier RPM ksh et mettez à niveau ksh AVANT d'émettre la commande yum pour mettre à niveau le système d'exploitation. Téléchargez le dernier RPM ksh et stockez-le dans /tmp (par exemple ksh-20120801-139.el7.x86_64.rpm). Mettez à niveau le rpm ksh avec la commande rpm -U /tmp/ksh-20120801-139.el7.x86_64.rpm continuez à mettre à niveau le système d'exploitation à l'aide de la commande yum upgrade

WINDOWS 2016 apparaît comme système INCONNU dans HPSA

Les utilisateurs des serveurs Windows 2016 sont nouvellement provisionnés et affichent UNKNOWN dans HPSA. Les derniers correctifs HPSA 10.23 ont été appliqués. Cette question est critique car nous ne pouvons pas déployer de serveurs Windows 2016.

En ce qui concerne le problème, SA 10.23 par défaut ne prend pas en charge Windows 2016, il suffit donc d'installer le programme d'installation de la plate-forme Windows 2016 pour que SA puisse détecter et gérer Windows 2016.

Utilisez la référence fournie : Programme d'installation de la plate-forme - Windows 2016 50.0.73174.0.1

Échec de la vérification de la signature Session

Vous pouvez exécuter tous les enregistrements d'outil de sondes.

Exécution WAY:1018:test wayrpc : ÉCHEC

Vérifier la machine d'état : RÉUSSITE

Vérifier les tables de session : RÉUSSITE

Vérifier l'état de verrouillage : SUCCÈS

Vérifier les échecs de signature : ÉCHEC (détails ci-dessous)

————————–

Échecs de vérification de la signature : Session : 350430100

————————–

Solution

En fait, il y a des sessions zombies mais pas dans ce cas. La session a disparu après le redémarrage du waybot.

Ajouter du contenu RH8 à redhat_import

Savez-vous comment ajouter les étiquettes de contenu appropriées pour permettre le téléchargement des correctifs RH 8 à l'aide de redhat_import ? La prise en charge de l'agent RH 8 a été publiée pour SA et de nouvelles entrées sont nécessaires pour permettre à redhat_import de télécharger des correctifs depuis Redhat.

Les étiquettes os sont nécessaires pour les correctifs, les étiquettes appstream sont un exemple de la façon d'ajouter d'autres flux disponibles à partir de RH content_labels :

rhel-8-pour-x86_64-baseos-rpms{8}

rhel-8-for-x86_64-appstream-rpms{8}

[rhel-8-pour-x86_64-baseos-rpms{8}]

plate-forme=Red Hat Enterprise Linux 8 X86_64

[rhel-8-for-x86_64-appstream-rpms{8}]

plate-forme=Red Hat Enterprise Linux 8 X86_64

Server Automation (SA) : l'utilitaire MpC échoue en raison de l'authentification de l'utilisateur

Une erreur s'est produite lors de la tentative d'utilisation de l'utilitaire marketplace-connector.sh afin de télécharger et d'importer du contenu à partir du site Web MarketPlace. L'erreur est Échec du téléchargement en raison d'une erreur d'authentification de l'utilisateur.

Server Automation (SA) utilise le script marketplace-connector.sh pour contacter le site Web MarketPlace et télécharger le contenu du site Web. Lors de la tentative d'exécution de l'utilitaire, l'erreur suivante s'affiche :

Détermination des informations d'état du contenu pour le flux

Fin de la détermination des informations d'état du contenu pour le flux

Le téléchargement a échoué en raison d'une erreur d'authentification de l'utilisateur.

Où est l'un des cris de contenu disponibles sur le site Web MarketPlace.

Cette erreur peut être vue lors de la première tentative d'utilisation du connecteur MarketPlace ou après l'avoir utilisé avec succès dans le passé.

Le script marketplace-connector.sh doit être configuré pour utiliser l'utilisateur MarketPlace/MySupport configuré pour l'utilisateur. Cette erreur s'affiche car l'ID utilisateur configuré dans l'utilitaire marketplace-connector.sh n'existe pas sur le site Web MarketPlace, existe mais possède un mot de passe incorrect ou l'ID utilisateur se trouve dans un formulaire obsolète (basé sur un e-mail).

Pour résoudre ce problème, déterminez d'abord l'ID utilisateur utilisé par l'utilitaire marketplace-connector.sh.

un. Sur le serveur où l'utilitaire marketplace-connector.sh est exécuté, accédez au répertoire où l'utilitaire est installé et lancez la commande ./marketplace-connector.sh lecture-config. Dans le tableau des options/valeurs affichées, l'identifiant d'utilisateur MpC utilisé apparaîtra comme valeur pour l'option de nom d'utilisateur.

deux. Vérifiez que la valeur du nom d'utilisateur N'EST PAS sous la forme d'une adresse e-mail. Par exemple, john.doe@company.com.

Les noms d'utilisateur basés sur le courrier électronique étaient obsolètes au profit de noms d'utilisateur unifiés ou composés d'un seul mot. Par exemple johndoe ou john_doe_user.

Si un nom d'utilisateur basé sur une adresse e-mail s'affiche, passez à la Site Web de la place de marché et créer un nouveau compte. Si nécessaire, contactez l'équipe du compte Microfocus pour obtenir de l'aide.

3. Si un nom d'utilisateur valide composé d'un seul mot est utilisé, vérifiez qu'il peut être utilisé pour se connecter au site Web MarketPlace. Si cette connexion fonctionne, rendez-vous sur Automatisation du centre de données section du site Web, sélectionnez la section Sécurité et conformité pour l'automatisation des serveurs, puis cliquez sur le bouton Télécharger à côté du flux de contenu MpC qui était en cours de tentative lorsque l'erreur s'est produite. Cela garantira que le compte associé à cet ID utilisateur dispose des autorisations suffisantes pour extraire ce contenu.

Quatre. Ressaisissez/corrigez les champs de nom d'utilisateur et de mot de passe utilisés par l'utilitaire marketplace-connector.sh en accédant au répertoire où l'utilitaire est installé et en lançant la commande ./marketplace-connector.sh write-config –username= .Vous serez invité à entrer le mot de passe du compte. Entrez celui utilisé lors de la connexion au site Web MarketPlace à l'étape ci-dessus.

5 . Réexécutez la commande ./marketplace-connector.sh afin de tenter de télécharger et d'importer le flux de contenu MpC.

Si cette erreur persiste, ouvrez un dossier de support Micro Focus (s'il n'y en a pas déjà un ouvert) et fournissez le résultat de la commande ./marketplace-connector.sh lecture-config et le fichier journal marketplace-connector.log (situé dans le répertoire où l'utilitaire est installé).

Server Automation (SA) : étapes de préparation de SA pour le portage du code Python 2 vers Python 3

Quelles sont les étapes qui peuvent être suivies pour préparer les bases de code Python 2 actuelles dans les environnements Server Automation (SA) existants afin qu'ils fonctionnent dans les futures versions SA qui utilisent Python 3 ?

Les versions existantes de Server Automation (versions SA 2018.08 et antérieures) utilisent actuellement la résolution Python 2. Cependant, Python 2 approche de la fin de sa durée de vie. Ce document est un aperçu de la préparation nécessaire pour les prochaines versions de SA qui s'exécuteront sur Python 3. Cette préparation doit avoir lieu avant la mise à niveau de toutes les versions SA existantes (2018.08 et antérieures) vers les futures versions de SA.

Tout d'abord, les versions SA existantes (2018.08 et antérieures) ne seront pas mises à jour vers Python 3. Les étapes sont mentionnées ci-dessous.

Nous ne pouvons qu'ajouter la prise en charge de l'exécution de code compatible Python 2/3 et permettre aux utilisateurs de commencer à convertir leur base de code Python existante en quelque chose qui fonctionnera sur les futures versions de SA qui exécuteront Python 3.

Section 1 – Comment préparer SA pour le portage du code python 2 vers python 3

Pour activer la compatibilité python 2 & 3 sur vos cœurs/satellites/agents, vous devez installer les packages ci-dessous :

SA 2018.08 :

SRVA_00278 - correctif cumulatif 2018.08.004 pour l'automatisation du serveur

SRVA_00266 – Automatisation du serveur 2018.08.002 Agents

SRVA_00267 – automatisation du serveur 2018.08.002 HPSAPython

SA 10.60

SRVA_00280 - cumul de l'automatisation du serveur 10.60.014

SRVA_00281 – Agents d'automatisation de serveur 10.60.014

SRVA_00263 – automatisation du serveur 10.60.012 HPSApython

SA10.51

SRVA_00271 – correctif cumulatif 10.51.011 pour l'automatisation du serveur

SRVA_00272 – Agents d'automatisation de serveur 10.51.011

SRVA_00273 – automatisation du serveur 10.51.011 HPSAPython

SA10.23

SRVA_00274 - Automatisation du serveur 10.23.015 cumulatif

SRVA_00275 – Agents d'automatisation de serveur 10.23.015

SRVA_00276 – automatisation du serveur 10.23.015 HPSAPython

Note 1: Au moment de la création de ce document, les packages répertoriés ci-dessus étaient les plus récents pour chaque version de SA répertoriée. Si des versions plus récentes du type de package de cumul ou d'agent sont disponibles, elles peuvent être utilisées à la place. Cependant, le package HPSAPython doit rester

identique et peut être installé avec les packages de cumul et d'agent les plus récents.

Note 2: Les versions SA10.2x antérieures à 10.23 devront être mises à niveau vers 10.23 avant de pouvoir utiliser ce document. De même, les environnements SA 10.50 devront être mis à niveau vers SA 10.51 avant de pouvoir utiliser ce document. Les versions SA antérieures à 10.2x NE PEUVENT PAS utiliser cette nouvelle fonctionnalité Python 3 et devront être mises à niveau vers au moins 10.23.

Pour installer le correctif cumulatif d'automatisation du serveur, suivez les instructions d'installation de patch.sh.txt. Les agents disposent des instructions d'installation dans AGENT_README.txt et le package HPSAPython peut être installé en suivant les instructions du fichier README.txt.

Section 2 – Comment porter vos scripts python

Vous avez le choix entre deux outils pour porter automatiquement votre code : Futurize et Modernize. L'outil que vous choisirez dépendra de la façon dont vous voulez que votre code ressemble à Python 3.

Futurize fait de son mieux pour que les idiomes et les pratiques de Python 3 existent dans Python 2, par ex. rétroporter le type d'octets de Python 3 afin d'avoir une parité sémantique entre les principales versions de Python.

Modernize, en revanche, est plus conservateur et cible un sous-ensemble Python 2/3 de Python, s'appuyant directement sur 'six' pour aider à assurer la compatibilité.

Comme Python 3 est l'avenir, il serait peut-être préférable d'envisager Futurize pour commencer à s'adapter à toutes les nouvelles pratiques introduites par Python 3 auxquelles vous n'êtes pas encore habitué. Quel que soit l'outil que vous choisissez, ils mettront à jour votre code pour qu'il s'exécute sous Python 3 tout en restant compatible avec la version de Python 2 avec laquelle vous avez commencé.

Selon le niveau de prudence que vous souhaitez utiliser, vous pouvez d'abord exécuter l'outil sur votre suite de tests et inspecter visuellement le diff pour vous assurer que la transformation est précise. Après avoir transformé votre suite de tests et vérifié que tous les tests réussissent toujours comme prévu, vous pouvez transformer votre code d'application en sachant que tout test qui échoue est un échec de traduction.

Malheureusement, les outils ne peuvent pas tout automatiser pour que votre code fonctionne sous Python 3 et il y a donc une poignée de choses que vous devrez mettre à jour manuellement pour obtenir une prise en charge complète de Python 3 (lesquelles de ces étapes nécessaires varient selon les outils).

Une description détaillée qui doit être suivie pour ce processus peut être trouvée dans la documentation officielle. Pour chaque outil, il existe une documentation officielle qui doit être consultée et suivie.

Les librairies nécessaires sont livrées et disponibles dans le python livré avec SA. Les versions des bibliothèques sont future-0.17.1 pour future et six-1.11.0 pour moderniser. Ces versions doivent être utilisées lors du portage du code.

Nous vous recommandons fortement d'effectuer d'abord le portage du code dans des environnements de test. Aucune des deux solutions n'offre un processus de portage de code direct ou propre, il y aura des problèmes que vous devrez résoudre manuellement.

Remarque : le nouveau contenu doit être développé en tenant compte de la compatibilité Python 3.

Section 3 – Références

Futuriser Moderniser Documentation officielle de Python 2 et 3

Impossible d'installer l'agent HPSA : le système ne trouve pas install_tool_x64.exe

Savez-vous que nous ne pouvons pas installer d'agents HPSA ? Si vous essayez de le faire, il y a une erreur. L'erreur est répertoriée ci-dessous.

[01/Aug/2019 12:39:48] [TRACE] RunCommand('install_tool_x64.exe –zap –loglevel=trace') [01/Aug/2019 12:39:48] [ERROR] RunCommand() - Popen a échoué : 'install_tool_x64.exe –zap –loglevel=trace' : Erreur : (2) : 'Le système ne trouve pas le fichier spécifié. [01/août/2019 12:39:48] [ERREUR] zap_agent : ÉCHEC

[01/Aug/2019 12:39:48] [ERREUR] RunCommand() - Popen a échoué : 'install_tool_x64.exe –unpack=C:UsersX18303~1AppDataLocalTemp3~5504-1 .WRKopsware-agent.exe,C:Program FilesOpswareagent –install=C:Program FilesOpswareagent,C:UsersX18303~1AppDataLocalTemp3~5504 -1.WRK –loglevel=trace' : Erreur : (2) : 'Le système ne trouve pas le fichier spécifié. [01/Aug/2019 12:39:48] [TRACE] install_tool : FAIL [01/Aug/2019 12:39:48] [ERROR] Échec de l'installation de l'agent Opsware.

Le serveur montrait le problème suivant. ComSpec=C:Windowssystem32cmd.exe;C:WindowsSysWOW64cmd.exe

Et sur nos serveurs de test, il était défini comme ceci :

ComSpec=C:Windowssystem32cmd.exe

Ouvrez le CMD en tant qu'administrateur sur le serveur Windows avec des problèmes et exécutez la commande suivante :

écho %COMSPEC%

Si plusieurs chemins, impliquez votre équipe d'administration Windows et laissez-les modifier la valeur dans les fichiers de registre. Une fois cela fait, vous pouvez confirmer que seul C:windowssystem32cmd.exe est utilisé et vous ne devriez pas avoir le problème.

Server Automation (SA) : message d'expiration du délai d'attente affiché lors de l'installation des derniers correctifs Windows

Lors de l'utilisation de Server Automation pour installer les derniers correctifs mensuels de Microsoft Windows, plusieurs serveurs renvoient un message Timed out lors de l'installation.

Lors de l'exécution d'un travail Server Automation (SA) pour installer le dernier correctif cumulatif Microsoft Windows, de nombreux serveurs sur lesquels le travail est exécuté renvoient un résultat Échec avec l'erreur Expiration du délai. En vérifiant les serveurs, l'erreur est signalée, beaucoup d'entre eux montrent en fait que le ou les correctifs ont été installés correctement.

Lors de l'exécution de ce type de tâche, SA s'assurera d'abord qu'il peut communiquer avec le serveur géré (auquel l'agent SA sur le serveur géré répond), puis procédera au téléchargement des fichiers correctifs nécessaires. Si ces deux étapes réussissent, l'agent SA est invité à demander à son serveur de commencer l'installation du correctif.

Par défaut, le travail SA attend jusqu'à une heure pour que le serveur géré SA termine cette installation. Si après une heure, le travail SA n'a pas reçu de réponse du serveur géré indiquant que l'installation du correctif est terminée, il marquera le serveur comme ayant échoué l'installation du correctif et indiquera qu'il a expiré.

Cependant, l'installation du processus sur le serveur géré peut prendre plus de temps que prévu pour installer le correctif. Le fait de marquer ce serveur comme ayant expiré dans le travail SA n'annule/n'arrête pas la poursuite du processus d'installation sur le serveur géré.

Si l'installation du correctif réussit, le serveur géré renverra ses résultats au travail SA. Toutefois, puisque le travail SA a déjà marqué le serveur comme Échec, il n'annule pas cet état car il pourrait y avoir des étapes post-installation supplémentaires dans le travail SA qui n'ont pas été exécutés.

De cette façon, le travail SA affichera le serveur comme Échec - Expiration du délai et pourtant l'installation du correctif s'est terminée avec succès.

Il est possible de modifier la durée par défaut pendant laquelle le travail SA attendra que les serveurs gérés terminent les actions qui lui ont été demandées (comme l'installation de correctifs, l'exécution d'un script, etc.). Pour modifier cette valeur par défaut, ouvrez l'interface graphique Java SA, sélectionnez Administration, puis Configuration système, puis Paramètres de configuration.

Dans le volet de droite, cliquez sur Command Engine (way). Cela montrera tous les paramètres de voie qui peuvent être modifiés. Parcourez les paramètres disponibles (ou filtrez-les via le champ de recherche dans la partie supérieure droite du volet de la fenêtre) et localisez le paramètre way.remediate.package_alarm_timeout.

Par défaut, ce paramètre aura une valeur de 3600 secondes (ou 1 heure). Vous pouvez augmenter cette valeur puis l'enregistrer. La modification de ce paramètre n'aura pas d'incidence sur les travaux SA en cours d'exécution, mais tous les nouveaux travaux SA utiliseront cette valeur.

Remarque : Faites attention lorsque vous modifiez ce paramètre. si une valeur très élevée est utilisée (disons plusieurs heures), l'exécution de l'ensemble du travail SA pourrait potentiellement être retardée pendant ce laps de temps si même UN serveur géré rencontre un retard dans l'exécution de l'action demandée. Il est recommandé de modifier ce paramètre par petites étapes.

Server Automation (SA) : la commande uln_import échoue avec la chaîne de tampon attendue

Lors de l'utilisation de l'outil Server Automation (SA) uln_import, l'erreur TypeError : chaîne ou tampon attendu est rencontrée lors de la tentative d'enregistrement du noyau SA auprès du serveur Web Oracle Linux.

Server Automation (SA) peut télécharger et importer dans sa base de données le contenu OEL. Pour ce faire, il utilise un utilitaire sur le serveur principal SA appelé uln_import, qui se connecte au site Web Oracle Linux qui fournit du contenu OEL aux utilisateurs/comptes qui ont acheté un compte auprès d'Oracle pour accéder à ce contenu.

L'enregistrement initial du serveur principal SA sur le site Web Oracle Linux est effectué en définissant des variables dans le fichier /etc/opt/opsware/patch_importer/uln_import.conf, puis en exécutant la commande /opt/opsware/patch_importer/bin/uln_import –verbose –show_conf.

Lors de l'exécution de la commande ci-dessus pour enregistrer le serveur SA sur le site Web d'Oracle, l'erreur suivante s'affiche : patch_importer_versioned 807 ERROR Erreur inattendue : échec de l'enregistrement de l'utilisateur : Erreur du serveur XML-RPC : TypeError : chaîne ou tampon attendu.

Cette erreur s'affiche à la fois sur l'écran de la session à partir de laquelle la commande est exécutée et dans le fichier journal de l'utilitaire

(/var/log/opsware/patch_importer/uln_importer.log)

Le problème apparaît car le code uln_import ne peut pas traiter correctement les variables définies dans le fichier de configuration de l'utilitaire (/etc/opt/opsware/patch_importer/uln_import.conf).

Des précautions doivent être prises lors de la modification du fichier /etc/opt/opsware/patch_importer/uln_import.conf pour s'assurer que des espaces blancs supplémentaires ou des caractères de contrôle ne sont pas accidentellement ajoutés dans le fichier. Une bonne recommandation serait de sauvegarder/sauvegarder le fichier uln_import.conf existant, puis de copier le /etc/opt/opsware/patch_importer/uln_import.conf-sample dans le fichier uln_import.conf (en l'écrasant) pour s'assurer qu'il n'y a pas de corruption dans le fichier.

Modifiez ensuite chacun des paramètres requis pour votre environnement dans le fichier uln_import.conf et essayez à nouveau d'enregistrer le serveur SA auprès du site Web Oracle à l'aide de la commande uln_import.

Si cela ne résout toujours pas le problème, apportez une nouvelle copie du fichier de configuration (à partir de uln_import.conf-sample) puis, un par un, ajoutez chacun des paramètres dans le fichier de configuration, en réexécutant la commande uln_import après chaque une addition.

Bien que la connexion puisse ne pas fonctionner car certains paramètres sont manquants, l'erreur de chaîne ou de tampon attendue ne doit pas s'afficher À MOINS QUE la variable modifiée dans le fichier de configuration ne soit la cause du problème.

REMARQUE: Les caractères blancs/espaces NE PEUVENT PAS précéder les noms de variables.

username=JOHN.DOE@ACME.COM (sans les guillemets) est acceptable

username=JOHN.DOE@ACME.COM (sans les guillemets) ne l'est pas.

Server Automation (SA) : Échec de l'enregistrement de l'erreur utilisateur lors de l'exécution de uln_import

Lors de l'utilisation de l'utilitaire Server Automation (SA) uln_import pour enregistrer le système central SA auprès d'Oracle, l'erreur Échec de l'enregistrement de l'utilisateur s'affiche.

Server Automation (SA) peut télécharger et importer dans sa base de données le contenu OEL. Pour ce faire, il utilise un utilitaire sur le serveur principal SA appelé uln_import, qui se connecte au site Web Oracle Linux qui fournit du contenu OEL aux utilisateurs/comptes qui ont acheté un compte auprès d'Oracle pour accéder à ce contenu.

L'enregistrement initial du serveur principal SA sur le site Web Oracle Linux est effectué en définissant des variables dans le fichier /etc/opt/opsware/patch_importer/uln_import.conf, puis en exécutant la commande /opt/opsware/patch_importer/bin/uln_import –verbose –show_conf.

Lors de l'exécution de cette commande, l'erreur suivante est rencontrée et la commande est abandonnée. -07 20:19:58,679 patch_importer_versioned 807 ERROR Erreur inattendue : échec de l'enregistrement de l'utilisateur : Erreur du serveur XML-RPC : MaxRetryError : Erreur SSL : Échec de la vérification du certificat [SSL : CERTIFICATE_VERIFY_FAILED] (_ssl.c:590)

Cette erreur s'affiche à la fois sur la session de console où la commande uln_import est exécutée et dans le fichier uln_importer.log trouvé dans le répertoire /var/log/opsware/patch_importer.

L'utilitaire uln_import utilise des variables de configuration définies dans le fichier /etc/opt/opsware/patch_importer/uln_import.conf. Trois de ces variables (nom d'utilisateur, mot de passe, csi) sont utilisées lors de l'enregistrement du SA sy

stem avec le site Web Oracle Linux qui fournit le contenu OEL. L'erreur s'affiche lorsque ces informations ne sont pas acceptées par le site Web d'Oracle.

En supposant que les valeurs de ces trois variables ont été ajoutées correctement, vérifiez qu'elles peuvent être utilisées pour se connecter directement au site Web Oracle Linux en pointant un navigateur Web vers l'URL http://linux.oracle.com et en vous connectant à l'aide de ces informations. Cela vérifiera que les informations de compte sont valides.

Si les valeurs fonctionnent en se connectant manuellement au site Web d'Oracle, une autre cause potentielle du problème peut être due aux certificats fournis par défaut pour l'utilisation de l'utilitaire uln_import. Dans certains cas, il peut être nécessaire d'importer le certificat du site Web Oracle Linux dans le fichier de certificat ca-bundle.crt. Cela est particulièrement vrai si un proxy n'est PAS défini dans le fichier uln_import.conf.

Pour importer le certificat Oracle Linux dans le fichier ca-bundle.crt des serveurs SA, suivez les étapes écrites ci-dessous.

Étape 1: Effectuez une sauvegarde du fichier de certificat existant cp /opt/opsware/openssl/certs/ca-bundle.crt /opt/opsware/openssl/certs/ca-bundle.crt_backup.

Étape 2: Obtenir le dernier certificat d'Oracle

Étape 3: Ouvrez le fichier téléchargé (ULN-CA-CERT.sha2) et regardez à la fin du fichier pour localiser le dernier certificat.

Étape 4: Copiez ce certificat (commençant par et incluant la ligne BEGIN CERTIFICATE jusqu'à et incluant la ligne END CERTIFICATE).

Étape 5 : Ouvrez/modifiez le fichier /opt/opsware/openssl/certs/ca-bundle.crt et ajoutez ce certificat à la fin du fichier.

Étape 6 : Enregistrez le fichier.

Étape 7 : Réessayez avec la commande uln_import et essayez de vous enregistrer sur le site Web d'Oracle.

Si aucune de ces solutions ne fonctionne, ouvrez un ticket de support et fournissez le /var/log/opsware/patch_importer/uln_importer.log et

les fichiers /etc/opt/opsware/patch_importer/uln_import.conf.