Správce Služeb

Správce služeb Micro Focus – tipy a triky

30. října 2021

Obsah

  • 1. Správce služeb Micro Focus – Tipy a triky – prosinec 2020
    • 1. Pokyny k získání transakcí SSL pomocí aplikace Java Virtual Machine (JVM)
    • 2. Pokyny k odeslání e-mailu, který je specifický pro hodnotu uživatelské volby z požadavku z katalogu
    • 3. Kroky k vyřešení webové vrstvy SM 9.52 P5 zobrazující prázdnou stránku indexu v Internet Exploreru
    • 4. Pokyny, které uživatelům pomohou tisknout proměnné na Workflow/RuleSet pro odstraňování problémů
    • 5. Když se moduly Rabbitmq nespustí a zůstanou ve fázi čekání
    • 6. Podpora ServiceManager pro simultánní multithreading (SMT)
    • 7. Řešení pro podporu SM DevOps 1.10 pro práci na Unixu po selhání
    • 8. Pokyny, jak zjistit, která akce/sada pravidel vede k automatickému načtení stavu Otevřeno-Idle
    • 9. Když upgrade SM nesplnil svou povinnost
    • 10. Když plánovací skript nefunguje přesně
  • 2. Správce služeb Micro Focus – Tipy a triky – leden 2021
    • 1. Když dojde k selhání poštovního adaptéru Smart Email, když spotřebuje e-mail, který obsahuje zdroj formuláře
    • 2. V režimu HPSM nelze přidat Oblast ve správě problémů
    • 3. Pokyny k definování SCHVALOVATELE konkrétní požadované položky katalogu v lístku SD katalogu služeb ITSM
    • 4. Je možné, aby tenant SM pracoval nebo se připojil k vyrovnávání zátěže SM?
    • 5. Když není název CI zachycen v modulu SM pro události serveru
    • 6. Pokyny k aktualizaci uživatele Postgres dba v konfigurační mapě databáze
    • 7. Řešení problému, kdy je e-mailové upozornění IM poškozené nebo v něm chybí soubory
    • 8. Oprava chyby, kdy model Migrated Change Model není schopen správně zobrazovat úlohy
    • 9. Když se IDM nemůže spustit kvůli chybě serveru úložiště klíčů /opt/apache-tomcat/conf/tomcat.keystore nenalezen
    • 10. Řešení opakované chyby plánovače, kdy nedokáže vyhodnotit výraz 1 + ‚dd/mm/rr‘ (plánovač. Proces, přeplánování)
  • 3. Správce služeb Micro Focus – Tipy a triky – únor 2021
    • 1. Nefunkční plánovač incidentu s automatickým zavřením
    • 2. Rabbitmq moduly se nespouštějí, stále se čeká na chybu stavu
    • 3. Chyba XSS založená na modelu DOM
    • 4. Inteligentní vyhledávání: Chybný název pro chybu interakce ve výsledcích vyhledávání
    • 5. Nelze přenést datové razítko změny přiřazení nebo timeduration4probsummary do chyby formuláře rychlé zprávy
    • 6. Chyba ve zpřístupnění podrobných informací
    • 7. SD02770580-F2 – Zvětšit, upravit hodnotu aktuálního pole v samostatném okně nefunguje chyba
    • 8. Chyba při zobrazování hodnot v tabulkách
    • 9. Instalace CDF se zasekla při chybě Check component’s pods status
    • 10. Jak nakonfigurovat pole pouze pro čtení pro 2 konkrétní skupiny přiřazení ve fázi uzavření chyby Lístek incidentu
  • 4. Správce služeb Micro Focus – Tipy a triky – březen 2021
    • Jak vytisknout proměnné v Workflow / RuleSet pro odstraňování problémů?
    • Rabbitmq pody nezačínají udržovat stav čekající na vyřízení
    • Problém se stavem pozastaveno
    • Podrobné informace
    • Djavax.net.debug se používá ke sledování komunikace SSL mezi klienty a serverem
    • Poštovní adaptér Smart Email selže, pokud spotřebuje e-mail, který obsahuje zdroj formuláře
    • Jak odeslat e-mail na základě hodnoty uživatelské možnosti z požadavku na položku katalogu
    • Webtier SM 9.52 P5 zobrazuje v Internet Exploreru prázdnou stránku indexu
  • 5. Správce služeb Micro Focus – Tipy a triky – duben 2021
    • 1. Upgrade SM selhal ve výrobě
    • 2. SMA Jak kopírovat soubory z/do kontejnerů/podů
    • 3. Spuštění se nezdaří se zprávou: JRTE E Tomcat – HTTPS port […] není dostupný
    • 4. Možnosti uživatelského výběru nemohou používat proměnnou $L.file pro SMA-SM Service Portal
    • 5. Problém kvůli chybějícímu katalogu procházení z SRC
    • 6. Obsah Smart Analytics nelze spustit
    • 7. SM 9.x: E-mailové řešení HTML ořezává e-maily. B-SL:400 HPSL:300 LIB4:skutečný TYP:chybyg HPTYPE:technické_dokumenty ATT:0
    • 8. Vytvořte plánovač pro související synchronizaci SD, pokud sd není vyřešen se souvisejícím stavem IM
    • 9. Chyba při instalaci klienta SM Windows: Flexeraart nelze přenést na Flexeraasv
  • 6. Správce služeb Micro Focus – Tipy a triky – květen 2021

6. Správce služeb Micro Focus – tipy a triky – květen 2021

1. CHYBA Soubor úložiště klíčů serveru /opt/apache-tomcat/conf/tomcat.keystore nenalezen

Nelze spustit modul IDM, protože nebyl nalezen soubor úložiště klíčů serveru ERROR /opt/apache-tomcat/conf/tomcat.keystore. Protokol IDM modulu sady zobrazuje následující zprávy:

Chyba při získávání certifikátu místního vydání a neschopnost zapsat „náhodný stav“ aktualizujte tomcat keystoreType na normální. Import úložiště klíčů optapache-tomcatconftomcat.p12 do úložiště optapache-tomcatconftomcat.keystore… chyba keytool java.io.FileNotFoundException optapache-tomcatconftomcat.p12 (Žádný takový soubor nebo adresář).

CHYBA Soubor úložiště klíčů serveru optapache-tomcatconftomcat.keystore nebyl nalezen, kontaktujte prosím správce.

Důvodem této chyby je, že certifikáty nejsou správně synchronizovány.

Řešení

Na tuto chybu máme řešení. Postupujte podle těchto jednoduchých kroků.

Krok 1: Vyberte na hlavní uzel: aktualizujte certifikát zbavení ve jmenném prostoru sady pomocí níže uvedených 3 příkazů:

První příkaz – kubectl get configmap/public-ca-certificates -n core -o json| jq ‚.data.RID_ca.crt‘ | xargs -i echo {data:{RID_ca.crt:{}}}>/tmp/tmp_rid.json

Druhý příkaz – kubectl patch configmap/public-ca-certificates -n -p $(cat /tmp/tmp_rid.json)

Třetí příkaz – rm -f /tmp/tmp_rid.json

Krok 2: Poté zastavte modul certifikátu pomocí daného příkazu.

Kubectl scale deployment itom-itsma-certificate-deployment -n –replicas=0

Krok 3: Zálohujte tento soubor na serveru NFS. Například

✓ mv /var/vols/itom/global-volume/certificate/ca-trust/itsma-truststore.jks /tmp

✓ mv /var/vols/itom/global-volume/certificate/imported/* /tmp/imported

Krok 4: Restartujte sadu IDM pod pomocí daného příkazu.

kubectl smazat pod idm-xxxxxxxxxx-xxxxx -n

Krok 5: Restartujte modul certifikátu. Zde je příkaz.

kubectl scale deployment itom-itsma-certificate-deployment -n –replicas=1

Krok 6: IDM certifikát je vytvořen pod /var/vols/itom/global-volume/certificate/source

Krok 7: Počkejte, až bude spuštěno nasazení certifikátu (2/2). Bude vytvořen nový itsma-truststore.jks.

Krok 8: Soubor certifikátu je importován a umístěn na /var/vols/itom/global-volume/certificate/imported/

Krok 9: Restartujte itom-bo-login pod pomocí příkazu uvedeného níže.

kubectl delete pod itom-bo-login-deployment-xxxxxxxxxx-xxxxx -n

POZNÁMKA: Nahraďte prosím jmenným prostorem sady, např. itsma-xxxx

2. Stav čekající na změnu v modulu správy incidentů není potřeba v bezkódovém SM

Setkal jsem se s tím mnohokrát. Existují některé stavové hodnoty, které se nepoužívají v SM codeless, ale zobrazují se ve formátu vyhledávání pro incidenty. To vytváří zmatek. V SM9.62 codeless vidíme na obrazovce Incident Search. Tyto nepoužité hodnoty v rozevíracím seznamu pro Stav jsou:

Přijato

Čeká na změnu

Doporučeno

Odmítnuto

Vyměněný problém

Řešení

Tyto předpokládané nepoužité stavové hodnoty zůstaly z Classic SM před vylepšením procesního návrháře (bez kódu). Hodnoty se stále používají v Hybrid SM a Classic SM. S bezdrátovým SM můžeme bezpečně přizpůsobit formát vyhledávání nebo upravit dotaz v globálním seznamu podle návrhu.

Zde je několik kroků, které je třeba dodržet, abyste se přizpůsobili globalistovi.

Krok 1: Od Globalist Incident Local Statuseschange Omezení SQL z module=probsummary na module=probsummary a ((is.bkgstatus=false nebo is.bkgstatus=NULL) nebo status=Pending nadřazený incident)

Krok 2: Znovu sestavit Globallist.

Krok 3: Přihlaste se znovu SM.

Nyní rozbalovací pole Stav ve formátu incidentů vyhledávání již neobsahuje hodnoty pozadí.

3. Ověření prostřednictvím serveru Service Manager se nezdařilo

Ověření prostřednictvím serveru Service Manager se nezdařilo.

Pro nastavení SMA-SM můžete použít níže uvedený odkaz: Automatizace řízení služeb, přítomná na microfocus.com doc.

_SM:2019.11/Home Chyba nalezená v protokolu: EVP_CipherFinal_ex se nezdařilo v desDecryptWithAES256CBC() [OPENSSL] chyba:06065064:digitální obálka

7984( 5292) 18. 11. 2020 16:19:06 RTE I Jazyk en je platný. Zde jsou některé chyby.

7984( 5292) 18. 11. 2020 16:19:06 RTE E EVP_CipherFinal_ex se nezdařilo v desDecryptWithAES256CBC()

7984( 5292) 18. 11. 2020 16:19:06 RTE E [OPENSSL] chyba:06065064:rutiny digitální obálky:EVP_DecryptFinal_ex:špatné dešifrování

7984( 5292) 18. 11. 2020 16:19:06 RTE I Nastavit přihlašovacího uživatele lwsso na dbuser1

7984( 5292) 18. 11. 2020 16:19:06 RTE I Jazyk je platný

7984( 5292) 18. 11. 2020 16:19:06 RTE E EVP_CipherFinal_ex se nezdařilo v desDecryptWithAES256CBC()

7984( 5292) 18. 11. 2020 16:19:06 RTE E [OPENSSL] chyba:06065064:rutiny digitální obálky:EVP_DecryptFinal_ex:špatné dešifrování

Tento problém vznikl, protože strong.queryhash.key v tabulce společnosti SM měl nesprávnou hodnotu.

>d strong.queryhash.key v $file

BDEF27F1721557B56539028A6AB70CA5072429729C7EB0FD4BFCB0E3CFB7CB08257BED875EE1E9314711A3F7D788102654E9074FBBB17BE907ABFBBD17

Řešení

Na to existuje jednoduché řešení. Použijte hash dotazu pomocí níže uvedeného skriptu a restartujte službu SM:

// Vymazat hash klíč dotazu

lib.c.$(‘info’).select(‘type=company‘).iterate( funkce (položka) {

item[‘strong.queryhash.key‘] = nula ;

item.doUpdate();

});

4. Feature Tracker (DevOps): Potřebujeme načíst DevOps_Deploy_SM960P1_SM950.unl do systému Deploy, pokud používáme pouze svc_import?

V SM9.6x si můžeme stáhnout DevOps z Marketplace. Ale myslel jsem, že je nutné nahrát DevOps_Deploy_SM960P1_SM950.unl do systému, kde nasazujeme pouze věci pomocí svc_import?

Řešení

Odpověď je ne. Nemusíme načítat DevOps_Deploy_SM960P1_SM950.unl do systému, kde nasazujete pouze pomocí svc_import. Můžeme vám to dokázat provedením malého testu. Postupujte podle níže uvedených písemných kroků.

Příprava ve vývojovém systému:

Krok 1: Vytvořte novou ScriptLibrary TESTX.

Krok 2: Vytvořte nové vydání ve Featuretrackeru

Krok 3: Vytvořte novou funkci pro tuto verzi ve Featuretracker a propojte objekt SL TESTX a sestavte verzi.

Krok 4: Zkopírujte informace o vydání z vašeho místního git do počítače s vaším Deployment System. Mohlo by to vypadat takto:

C:PROJEKT.git

C:PROJECTdataScriptLibrary TESTX–p3.xml

C:PROJECTDoc_R3.1.html

Krok 5: Přejděte na systém nasazení. Otevřete příkazový řádek.

přejděte například do C:Program Files (x86)Micro FocusService Manager 9.60ServerRUN>

import pomocí svc_import:

sm -svc_import -svc_rootdir:C:PROJECT -svc_mode:99 -svc_cleanbuild:1 -svc_updatedbdict

zkontrolujte, zda existuje ScriptLibrary TESTX

Ano

5. Jaký je rozdíl mezi úplnou reindexací a plánovanou komprimací indexu IDOL?

Existuje rozdíl mezi úplným přeindexováním a naplánováním zhutnění indexu IDOL? Ano to je. Dokonce jsem je nedávno poznal.

Existují dvě kapitoly pro indexy, první je pro úplné reindexování Dokument je na microfocus.com. Přesné umístění je itom, SMAX:2020.08, úplný reindex a druhý stručně popisuje něco o plánování komprimace indexu IDOL Dokumenty jsou na microfocus.com. Přesné umístění je v itom, SMAX:2020.08, Schedule Index Compact .

Řešení

Úplné přeindexování znovu vytvoří všechny indexy s očekávanými dokumenty filtrovanými znalostními bázemi. Compact zavolá akci DRECOMPACT z IDOL, která zmenší prostor zbývající při mazání dokumentů z datového indexu. Indexová akce DRECOMPACT vyplní prostor vytvořený odstraněním dokumentu novými dokumenty. Tento proces je podobný procesu defragmentace.

6. Problém s linkerem

Máme uživatele linkeru, který je zodpovědný za vytvoření RF po schválení interakce. Ale RF se nevytváří, takže máme špatný dopad na naše podnikání. Máme také mnoho nevyřízených interakcí a RF nebyla dosud vytvořena. Potřebujeme tedy následující:

1- Opravte současnou situaci, protože se nyní nevytvořil žádný RF ani poté, co spustíme příkaz „Stav“ a ukončíme proces a spustíme plánovač a stále existuje problém

2- Musíme najít hlavní příčinu.

3- Potřebujeme řešení pro vytvoření RF pro schválenou interakci, protože se neočekává, že bude komunikovat se všemi uživateli, kteří vytvářejí svou interakci, aby je znovu vytvořili.

Řešení

Shrnutí Webexu:

Problém zákazníka je způsoben procesem sla na pozadí souvisejícím se záznamem o výpadku:

výpadek={[10, '28/12/2018 13:20:30′, , 100737, '05/11/2020 15:09:47′, false, false, false, , , 119801, sla, '05/ 11/2020 15:15:25′, ]}

outageevent={[probsummary;SD-IM-TS1092169, 10, '31/10/2020 00:09:15′, '31/10/2020 01:16:40′, true, 100737/205/11 15:09:47′, sla, 1]}

device={[10, , , , , , , , Síťové komponenty, , , , , falcon, , , , , , , , , , , , Používá se, , , Router, , , , {}, , , , pravda, nepravda, '28/12/2018 13:20:55′, , 1, sla, , , , , , , , , , , , , , , , , , , , , , , {}, , IT Provoz sítě, , , , {}, , , , , , , , , , , , , , , , {{[, , , ]}}, , , , {{[, , , ]}}, { {[, , , , , ]}}, {{[, , ]}}, , , , , , , , , , , , , , , , , , , {}, , {}, , , , '22/11/2018 11:47:06′, , , , , , , , , , , {}, , , , , , , , '22/11/2018 11:47:06′, , 10 , , , , , , , , , , , , , , , {}, ]}

Pokaždé, když se proces SLA pokusí aktualizovat záznamy o výpadku a souvisejících záznamech o výpadcích (cca 40 000 záznamů o výpadcích), systém generuje zámky bez konce. Současně jsme restartovali problémový proces, který nebyl spuštěn. Po kontrole souborů protokolu a konfiguračních souborů navrhuji tyto kroky:

Krok 1 – Pro chybu 1488( 8112) 11/09/2020 16:49:11 RTE E sm_alloct: Není k dispozici dostatek sdílené paměti pro přidělení 5736 bajtů

Navrhuji zvýšit sdílenou paměť v sm.ini úpravou parametru

sdílená_paměť:156000000

na

sdílená_paměť:256000000

Krok 2 – Chcete-li snížit použitou vyrovnávací paměť IR Expert, přidejte tento parametr do souboru sm.ini

ir_max_shared:50000000

Krok 3 – Pro vydání 7556( 16552) 11/09/2020 16:30:02 Zásobník RTE I RAD je využit ze 70 %, ukončete prosím aktuální aplikaci. přidejte tento parametr do sm.ini

agstackl:2000

Krok 4 – Problém RAD E RuleSet „RSD.et.IT.rm.set.set.UAT.EXTIME“ způsobuje mrtvou smyčku! Upravte konfiguraci, abyste se vyhnuli DEAD LOOP.

Navrhuji, abyste si přečetli kód spojený s RuleSet „RSD.et.IT.rm.set.set.UAT.EXTIME“

Krok 5 – V souboru sm.cfg upravte řádek

sm -que:ir forceque -ir_trace:101 -log:D:SMLogsirtrace.log -maxlogsize:50000000 -počet souborů protokolu:10 -sessiontimeout:1800 -interval srdečního tepu:300 -debugnode

Některé parametry nejsou relevantní, použijte prosím tento:

sm -que:ir forceque -log:D:SMLogsirtrace.log -maxlogsize:50000000 -numberoflogfiles:10

Krok 6 – Přidány tyto parametry do sm.ini

filesnocache:sla,plán<– To exclude the SLA and Schedule from the cache

enableAnubisMonitor:1<– to enable the anubis.

Po úpravě konfiguračních souborů vyčistěte adresář log a restartujte platformu.

7. Jak změnit výchozí uživatelské jméno db nastavené pro SMA

Potřebujeme postup pro změnu výchozího uživatelského jména db nastaveného pro SMA.

Řešení

Podle níže uvedených kroků můžeme změnit výchozí uživatelské jméno db.

Krok 1: za prvé aktualizujte uživatelské jméno databáze změnou DEFAULT_DB_USERNAME. Zde je příkaz.

kubectl upravit cm default-database-configmap -n core

Krok 2: Poté aktualizujte parametr hesla db password key, abyste nastavili heslo pro uživatelské jméno definované v předchozím kroku. Můžeme získat názvy idm podů:

kubectl get pods -n core |grep idm

idm-d68b85b57-ntvsw 2/2 Běh 0 5h39m

idm-d68b85b57-qzlq2 2/2 Běh 0 5h39m

Krok 3: Přejděte do jednoho z modulů idm:

kubectl exec -ti idm-d68b85b57-ntvsw bash -n core

Krok 4: Poté nastavte heslo pomocí daného příkazu.

update_secret dbpasswordkey

$ kubectl create -f /suite-install/yamlContent/idm.yaml