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
  • Micro Focus Server Automation – Trucs et astuces – Avril 2021
    • Server Automation (SA) : la mise à niveau du noyau SA vers RH7.6/RH7.7 échoue
    • WINDOWS 2016 apparaît comme système INCONNU dans HPSA
    • Échec de la vérification de la signature Session
    • Ajouter du contenu RH8 à redhat_import
    • Server Automation (SA) : l'utilitaire MpC échoue en raison de l'authentification de l'utilisateur
    • Server Automation (SA) : étapes de préparation de SA pour le portage du code Python 2 vers Python 3
    • Impossible d'installer l'agent HPSA : le système ne trouve pas install_tool_x64.exe
    • Server Automation (SA) : message d'expiration du délai d'attente affiché lors de l'installation des derniers correctifs Windows
    • Server Automation (SA) : la commande uln_import échoue avec la chaîne de tampon attendue
    • Server Automation (SA) : Échec de l'enregistrement de l'erreur utilisateur lors de l'exécution de uln_import
  • 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 – 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

Des observations ont été faites sur de multiples problèmes survenus sur le cœur et le satellite après le lancement de l'outil récent. Même après des tentatives répétées pour résoudre la complication sur les satellites, ils ne sont pas encore entièrement fonctionnels.

L'agent s'est présenté et les scripts ont pu être exécutés, mais l'OGFS n'a pas fonctionné et l'un d'eux n'avait aucune connectivité avec le test de communication. Les tentatives de copie des certificats de lieu des SR précédents n'ont pas complètement résolu le problème car ces satellites doivent être en bon état ou utiliser OGFS pour tenter un récent.



Ces problèmes rencontrés peuvent être résolus en suivant les étapes ci-dessous.

1. Si des correctifs CORD sont installés, les utilisateurs sont invités à les annuler.

/opsware_installer/patch_opsware.sh –verbeux

S'il s'agit d'un système patché, le message suivant s'affiche :

Bienvenue dans le programme d'installation d'Opsware. Il semble que vous
avez déjà terminé l'installation de ce correctif sur
ce système.
Appuyez sur 'r' pour supprimer ce patch.
Appuyez sur 's' pour afficher le contenu du patch.
Appuyez sur 'q' pour quitter.
Sélection:

Entrez r à l'invite pour supprimer le correctif.

2. Le script de désinstallation doit être appelé.

/opsware_installer/uninstall_opsware.sh -r
L'utilisateur peut décider où le fichier de réponse est enregistré lors de l'installation, mais il se trouve normalement dans le répertoire /usr/tmp.

3. Désactivez et supprimez le serveur en accédant à l'interface graphique Web SA, une fois la désinstallation terminée.

4. Vérifiez puis forcez la suppression de tous les RPM SA (si l'ID satellite sous Linux) :

rpm -e –nodeps `rpm -qa
grep ˆOPSW`

5. Vérifiez si les processus SA sont en cours d'exécution et arrêtez-les s'ils le sont.

|__+_|

6. Effacez tous les fichiers ou répertoires SA présents.

Ne créez aucun fichier manuellement. Copiez et collez cette commande multiligne.

|__+_|

7. Redémarrez les cœurs.

2. Résolution du problème avec SLES pour SAP qui affiche un système d'exploitation inconnu

Les utilisateurs ont signalé avoir rencontré des problèmes avec un serveur doté du système d'exploitation SLES 15 pour SAP et indiquant que le système d'exploitation est inconnu dans les clients Java.

Le correctif pour le problème est,

|__+_|

Il y a 3 façons de résoudre le problème rencontré comme dit ci-dessus,

1. rpm -q sles-release –queryformat. Ce qui pour SAP I qui a déjà été mentionné manquait et n'est pas considéré comme une option car il rompra les dépendances pour la version SAP.

2. rpm -q suse-release –queryformat ne sera pas non plus utilisé ici.

3. Dans SLES, /etc/SuSE-release n'est pas présent car il était obsolète.

Pour le correctif, le fichier /etc/SuSE-release doit être créé avec les informations mentionnées ci-dessous.

|__+_|

3. Solution pour les erreurs de script par l'agent SA

Il a été rapporté qu'un agent SA donne à plusieurs reprises des messages d'erreur.

Pour résoudre ce problème,

Le problème survient principalement parce que la variable d'environnement COMSPEC n'est pas définie dans le processus de l'agent. Il y a des chances qu'il manque à l'échelle du système.

Vous trouverez ci-dessous une reproduction à petite échelle où il était possible de supprimer manuellement l'environnement COMSPEC dans un shell cmd.exe.

|__+_|

Le correctif est effectué en ajoutant la valeur ou en modifiant la valeur. Pour l'obtenir, cliquez avec le bouton droit de la souris sur 'Mon ordinateur' ou 'Ce PC' dans l'explorateur Windows. Allez dans la boîte de dialogue 'propriétés système', puis dans l'onglet 'Avancé', puis cliquez sur le bouton (variables d'environnement).

4. Correctif pour Windows 2016 signalé comme un système d'exploitation inconnu

Les utilisateurs se sont plaints que même après avoir installé avec succès le programme d'installation de la plate-forme pour Windows 2016 sur SA 10.21, les serveurs Windows signalent une erreur indiquant un système d'exploitation inconnu lors de la vérification des propriétés de l'interface utilisateur/de l'appareil HPSA.

La solution au problème est,

Les deux versions des fichiers de configuration de la carte n'ont pas été mises à jour avec la nouvelle version des fenêtres.

/etc/opt/opsware/spin/os_version_map.conf
/opt/opsware/spin/etc/os_version_map.conf

A l'ouverture, ces deux fichiers verront les autres fenêtres mais pas celle avec 2016, même si l'installation de la plateforme a réussi, elle ne parvient pas à modifier les deux fichiers.

L'ID du programme d'installation de la plate-forme doit être vérifié dans la NGUI et assurez-vous que le programme d'installation a l'ID 170402. Après cela, la version du système d'exploitation doit être ajoutée dans les deux fichiers de configuration (. *Windows. *Server 2016. *x64. * : 170402), exemple :

|__+_|

Modifiez et ajoutez les deux lignes dans deux os_maps sur TOUS les cœurs/tranches de votre environnement.

À la fin, exécutez le bs_hardware sur des serveurs OS inconnus, le serveur sera signalé comme Windows 2016.

5. Comment débloquer les utilisateurs de la base de données

L'utilisateur de la base de données s'est avéré verrouillé. Le problème peut apparaître lorsque l'utilisateur essaie de se connecter plusieurs fois avec un mot de passe incorrect.

Le correctif pour le problème est,

Exécutez les commandes suivantes.

son – oracle
sqlplus /as sysdba
SQL> sélectionnez le nom d'utilisateur, la date d'expiration, le statut du compte à partir de dba_users ;

Après avoir obtenu la sortie de ce SQL , vérifiez quel compte est verrouillé.

Le compte verrouillé peut être déverrouillé par la requête suivante :

SQL> modifier le déverrouillage du compte utilisateur ;

6. Exécution du déploiement du programme d'installation de la plate-forme

Les étapes de l'installation du déploiement du programme d'installation de la plate-forme sont indiquées ci-dessous.

Le programme d'installation de la plate-forme pour les nouveaux systèmes d'exploitation est disponible à partir du lien

1. télécharger sur le serveur principal SA via SFTP (WinSCP, FileZilla, etc.)

2. SSH dans le noyau du serveur présent ci-dessus.

3. (En tant que racine) /opt/opsware/bin/apxtool import
Exemple:
[root]/home/$user# /opt/opsware/bin/apxtool import /home/$user/PlatformInstaller-Windows2012R2-50.0.46817.0.0.zip
APX avec le nom unique « com.hp.sa.platform.installer.Windows_2012_R2 » n'existe pas.
L'enregistrer dans le système ? O/N O
Info : APX enregistré avec succès 'Windows 2012 R2 Platform Installer' (5120001) dans le dossier '/Opsware/Tools/Managed Platforms Support'.

4. Connectez-vous au serveur principal SA par le haut via le client de bureau.

5. Passez à la colonne Administration dans la prise en charge de la plate-forme et l'utilisateur remarquera Windows 2012 R2.

6. Vérifiez la colonne d'état. S'il n'est pas installé, cliquez avec le bouton droit de la souris et sélectionnez Exécuter.

7. Après l'installation, vérifiez si l'état est défini sur installé. Si c'est le cas, faites un clic droit et supprimez le programme d'installation de la plate-forme.

7. Solution pour les erreurs de transaction ActionStatus.ABORT_Only n'est pas dans un état valide

Un utilisateur a signalé qu'il était en mesure de se connecter à HPSA, mais qu'il n'était pas en mesure d'installer le logiciel. Le logiciel qui a été tenté d'être installé était un logiciel Windows.

Ils ont également eu des problèmes de maillage et ont dû redémarrer SA sur l'ensemble du maillage. L'erreur persiste même après plusieurs tentatives. Le travail n'a pas réussi à obtenir un JOBID et n'apparaît pas dans les journaux et les sessions.

L'erreur qui est apparue était,

Transaction TransactionImple n'est pas dans un état valide pour appeler des opérations de cache.

La solution au problème rencontré est,

Commande pour résoudre le problème avec les utilisateurs : la commande à une ligne doit être exécutée séparément dans chaque cœur.

|__+_|

Remarque : La commande est la même, mais elle inclut désormais une instruction de validation pour réellement mettre à jour les enregistrements de la base de données.

Par précaution, il est conseillé d'exécuter la requête sur tous les cœurs.

/opt/opsware/support/bin/sql -a select ar_p.role_id, ar_p.rolespace, ar_p.namespace, ar_p.role_name, ar_p.role_hash, ar_c.role_id, ar_c.namespace, ar_c.namespace, ar_c.role_name, ar_c .role_hash de aaa.role ar_p, aaa.role_child arc, aaa.role ar_c où ar_p.role_id=arc.role_id et arc.child_role_id=ar_c.role_id et ar_c.namespace='OPE' et ar_c.role_name pas comme '%'

ar_p.role_name

Si la sortie est obtenue, le 1-liner dans l'environnement doit être exécuté pour corriger les comptes qui y sont également impactés.

Une fois exécuté dans tous les cœurs, il sera possible de corriger à nouveau.

8. Comment définir SQLNET.ALLOWED_LOGON_VERSION_SERVER sur 11 ou moins

Pour ajouter le paramètre SQLNET.ALLOWED_LOGON_VERSION_SERVER au sqlnet.ora de la base de données oracle, il doit être défini sur 11 ou moins. Si la valeur est augmentée à 12 ou plus, le processus échouera.

Le message d'erreur qui s'affichera est que le compte est verrouillé.

AVERTISSEMENT : une erreur a été détectée lors de l'exécution d'un

commande ou script. La sortie suit :

|__+_|

Au cours de l'installation, le composant ADM tentera de se connecter à la base de données 30 fois. Dans l'exemple ci-dessus qui est donné, l'utilisateur du schéma 'TWIST' avait mis en place une configuration de politique qui verrouillerait automatiquement le compte après 10 tentatives de connexion infructueuses. À la suite de cela, la dernière erreur indiquait que le compte était verrouillé.

La cause du problème a été trouvée par l'utilisation d'une ancienne version de ojdbc6.jar pour se connecter à la base de données.

Un message d'échec de connexion s'affichera si la valeur du paramètre SQLNET.ALLOWED_LOGON_VERSION_SERVER de sqlnet.ora est définie sur 12 ou plus.

Dans les versions précédentes de l'oracle, la confusion des protocoles de connexion affichera l'une des erreurs.

ORA-28040 : Aucune erreur de protocole d'authentification correspondant

ORA-03134 : les connexions à cette version de serveur ne sont plus prises en charge

Pour résoudre le problème, suivez les étapes ci-dessous.

1. modifiez le paramètre SQLNET.ALLOWED_LOGON_VERSION_SERVER dans sqlnet.ora à 11 ou moins.

2. Redémarrez la base de données.

3. Le 3rdrésultats de l'étape en raison de la création initiale alors que SQLNET.ALLOWED_LOGON_VERSION_SERVER est défini sur 12 ou supérieur, le mot de passe sera alors stocké sans la version 10G.

Les versions du mot de passe peuvent être vérifiées par la requête suivante.

# /opt/opsware/support/bin/sql select password_versions from dba_users where username='TWIST'

Requête #1 sur Facility_id 2 (SA1060B) :

PASSWORD_VERSIONS

—————–

11G 12C

Une fois que SQLNET.ALLOWED_LOGON_VERSION_SERVER est redéfini sur 11 ou moins, que la base de données est redémarrée, puis que le mot de passe TWIST de l'utilisateur du schéma est réinitialisé, la sortie de la requête ci-dessus devrait être la suivante :

# /opt/opsware/support/bin/sql select password_versions from dba_users where username='TWIST'

Requête #1 sur Facility_id 2 (SA1060B) :

PASSWORD_VERSIONS

—————–

10G 11G 12C

9. Comment installer l'extension de serveur pour les logiciels enregistrés ne peut pas être installé

Des rapports indiquent que l'extension de serveur pour les logiciels enregistrés ne peut pas être installée sur certains hôtes.

La solution à ce problème est la suivante.

2020-01-08 21:18:44:027 2204 1708 AVERTISSEMENT COMAPI : ISusInternal :: GetUpdateMetadata2 a échoué, hr=8007000E

Considérant que le système d'exploitation ici est Windows 7, le correctif requis pour le correctif qui corrigera la complication peut être obtenu auprès du lien .

Une fois l'installation terminée, les commandes suivantes doivent être entrées dans une invite de commande élevée pour qu'elle fonctionne sans erreur.

Arrêt net wuauserv
Sc config wuauserv type=propre
Démarrage net wuauserv

10. Solution pour l'absence de réponse de l'automatisation du serveur 10.60

Diverses plaintes ont été déposées concernant l'état de non-réponse de l'automatisation du serveur 10.60. Les quelques utilisateurs qui ont pu se connecter n'ont pu effectuer aucune tâche. Même après avoir redémarré l'application plusieurs fois, le problème persiste.

Ces étapes fournies ci-dessous peuvent résoudre le problème rencontré.

1. Arrêtez SA -/etc/init.d/opsware -sas stop

2. Remontez l'adaptateur de fusible.

en tant qu'utilisateur root : /opt/opsware/adapter/Linux/src/reinstall

Il y aura des messages affichés comme

Création d'un nouveau journal de construction FUSE /var/log/opsware/adapter/adapter-build-2020-02-19T21:50:58.954778168Z
Construction du module de noyau FUSE…
Construction du module d'extension OGFS…
La construction du module d'extension ogfs a réussi.
Adaptateur de bâtiment…
La reconstruction a réussi.

Si la reconstruction échoue, envoyez le fichier de l'adaptateur comme indiqué ci-dessus.

3. L'utilisateur est ensuite invité à redémarrer SA et à tester à nouveau.

La procédure pour effectuer le redémarrage,

arrêt du service opsware-sas sur la tranche 1.
arrêt du service opsware-sas sur la tranche 2.
le service opsware-sas s'arrête sur le noyau (tranche 0).

redémarrage du service opsware-sas sur le Core (tranche 0).
le service opsware-sas redémarre sur la tranche 1.
redémarrage du service opsware-sas sur la tranche 2.

Après avoir recherché la cause première du problème rencontré, les éléments suivants ont été trouvés.

À partir des journaux de rotation de la tranche 093, la sortie est :

[19/Fév/2020 20:11:22 +0000] ERREUR spin.permissions – – – – {'msg' : 'REFUSÉ', 'horodatage' : '19/Fév/2020 201121′, 'ligne' : 859, 'nom d'hôte' : 'USMAGLKFNG093', 'méthode' : 'checkObjectPerms', 'module' : 'spinmethods.py'}
[19/Feb/2020 21:57:55 +0000] INFO Ajout de la nouvelle unité kernel-2.6.32-754.27.1.el6.x86_64.rpmRPM à la table Recommended_patches – – – –
L'adaptateur hpsa_fuse sur les serveurs 093 n'est pas accessible ; c'était le principal enregistrement recueilli par ces journaux.