Palvelinautomaatio

Micro Focus Server Automation – vinkkejä ja temppuja

30. lokakuuta 2021

Sisällysluettelo

  • Micro Focus Server Automation – vinkkejä ja temppuja – tammikuu 2021
    • 1. Kun käyttäjä ei pysty poistamaan SA-agenttia Windowsissa
    • 2. Kun Opsware-agenttimoduuli katoaa ensisijaisessa ytimessä
    • 3. Virheen ratkaiseminen Word_uploads ei ole täysin asennettu päivityksen aikana
    • 4. Ylikuormitetun tiedostojärjestelmän ratkaiseminen
    • 5. Virheen korjaaminen, kun palvelinautomaatio ei löytänyt ensisijaista Oracle-versiotiedostoa asennuksen aikana
    • 6. Käsittele Twist Heap -kokoa paremman suorituskyvyn saavuttamiseksi
    • 7. Päivityshetkellä havaitun edellytysvian ratkaiseminen
    • 8. Ohjeet buildmgr-komponentin poistamiseen käytöstä
    • 9. Ohjeet SA-versioiden etsimiseen ja tunnistamiseen
    • 10. Järjestelmä ei löydä install_tool_x64.exe-virhettä, kun korjataan sen
  • Micro Focus Server Automation – vinkkejä ja temppuja – helmikuu 2021
    • 1. Palvelinautomaatio (SA): SA-ytimen päivittäminen RH7.6:ksi/RH7.7:ksi epäonnistuu -virhe
    • 2. Palvelinautomaatio (SA): uln_import-komento epäonnistuu odotetun puskurin merkkijonon kanssa.
    • 3. Alustatuki – SuSE 15 -virhe
    • 4. Agentti käyttää sha1WithRSAEncryption Signature Algorithmia varmennevirheessä
    • 5. Palvelinautomaatio (SA): Käyttäjän rekisteröinti epäonnistui, kun uln_import Error ajettiin
    • 6. Palvelinautomaatio (SA): Aikakatkaisu -viesti, joka näkyy asennettaessa uusimpia Windows-korjauksia. Virhe
    • 7. Palvelinautomaatio (SA): vaiheet SA:n valmistelemiseksi Python 2 -koodin siirtämiseksi Python 3 -virheeseen
    • 8. Server Automation (SA): MpC-apuohjelma epäonnistuu käyttäjän todennusvirheen vuoksi
    • 9. Opsware-sas: Kiertoa ei voi käynnistää – riippuvuustarkistus epäonnistui Virhe
    • 10. OSBP 'Set Media Source' ei toimi käynnistettäessä Windows PE 10 -virheellä
  • Micro Focus Server Automation – vinkkejä ja temppuja – maaliskuu 2021
    • 1. Toimenpide agentin uudelleenasentamiseksi satelliitille äskettäin sertifikaattiongelmien aiheuttaman työkalun vioittumisen jälkeen
    • 2. SLES for SAP:n ongelman ratkaiseminen, jossa on tuntematon käyttöjärjestelmä
    • 3. SA-agentin komentosarjavirheiden ratkaisu
    • 4. Korjaus Windows 2016:lle ilmoitetaan tuntemattomaksi käyttöjärjestelmäksi
    • 5. DB-käyttäjien lukituksen avaaminen
    • 6. Alustan asennusohjelman käyttöönotto
    • 7. Ratkaisu tapahtumavirheisiin ActionStatus.ABORT_Only ei ole kelvollisessa tilassa
    • 8. Kuinka asettaa SQLNET.ALLOWED_LOGON_VERSION_SERVER arvoon 11 tai sitä pienemmäksi
    • 9. Palvelinlaajennuksen asentaminen rekisteröityjä ohjelmistoja ei voi asentaa
    • 10. Ratkaisu palvelinautomaation reagoimattomuuteen 10.60
  • Micro Focus Server Automation – vinkkejä ja temppuja – huhtikuu 2021
  • Micro Focus Server Automation – vinkkejä ja temppuja – toukokuu 2021
    • 1. Kysymyksiä rakentamisesta vanhasta 10.20 uuteen 2018.08.
    • 2. Ohjelmistopolitiikkaan liittyvät kysymykset
    • 3. Tilin lukituksen kynnysominaisuudet – 64256 #jm#.
    • 4. Virhe suoritettaessa cora-komentoa SA 10.60:ssa
    • 5. Ongelmia HPSA-töiden kanssa päivityksen jälkeen
    • 6. Agentin asennus epäonnistui satelliitissa crsauapz3pa0
    • 7. Kuinka käytän nohupia SA-komentosarjassa, jossa on 10.60?
    • 8. Alustan asennusvirhe
    • 9. Exadata-tuki HPSA/DMA:lle
    • 10. Tuki HPE Proliant -palvelimille älykkääseen hallintaan
  • Micro Focus Server Automation – vinkkejä ja temppuja – kesäkuu 2021
    • 1. Varoitus: /packages/any/nt/5.2/PsSasHost.exe ei voitu ladata
      • Haluan tietää varoituksesta /packages/any/nt/5.2/PsSasHost.exe, jonka he saavat tarkastuksen korjauksen aikana, ja korjauskomentosarja on mukautettu PowerShell-komentosarja. Taustalla tämä tapahtuu 10.60-ympäristössäni, jossa siirsin kaiken sisältömme ja palvelimemme 10.21.
      • Se on hyvin toistettavissa sekä tuotanto- että kehitysympäristössäni. Korjaus näyttää toimivan onnistuneesti, mutta se on varoitus, joka saa käyttäjät häiritsemään minua. Sitä ei tapahdu tarkastuskäytännöissä, jotka käyttävät mukautettuja bat- tai python-skriptejä, vain silloin, kun korjauskomentosarja on tehon kuori. Ja se tapahtuu vasta luodulle sisällölle, ei vain siirretylle sisällölle.
      • Tiedän, että Windows 5.2 on Windows 2003, jota ei tueta versiossa 10.60, joten arvelen, että jossain ohjelmistokäytännössä tai JOSTAkin on se ja meidän on poistettava se?
    • Ratkaisu
    • 2. Patch Q4025337 asennettu onnistuneesti useita kertoja, mutta näkyy puuttuvana
    • 3. Onko mahdollista viedä tarkastustuloksia PDF-muotoon OGFS:stä?
    • 4. VAIN YHDYSVALLAT HPSA-kysymys lokien lähettämisestä.
    • 5. Voiko kynnysarvoja muuttaa, kun koetin tarkistaa table_spacen?
    • 6. SA-agentti antaa virheilmoituksen kaikille skripteille
    • 7. Virheet OBR-hallintapaneelissa, seuraava stream on virheellinen; ohjelmistojen yhteensopivuus.
    • 8. Asenna SA Agent -työt pysähtyvät vain Agent Binary Stagediin
    • 9. HPSA 10.60 Tuotanto – Korjattavat tietoturvahavainnot.

Micro Focus Server Automation – vinkkejä ja temppuja – huhtikuu 2021

Palvelinautomaatio (SA): SA-ytimen päivittäminen RH7.6:ksi/RH7.7:ksi epäonnistuu

Oletko yrittänyt päivittää ytimen sisältävän Server Automationin (SA) käyttöjärjestelmän RH7.x:stä RH7.6/RH7.7:ään? Se epäonnistuu arviointivaiheessa ksh rpm -virheen takia.

Virhe yritettäessä suorittaa pientä käyttöjärjestelmän päivitystä Redhat 7.x:stä (7.0 - 7.5) Redhat 7.6:een tai 7.7:ään. Tässä on virhe suoritettaessa yum upgrade -komentoa.

Paketti: OPSWoracle_rdbms_part3-12.1.0.2.0-6.x86_64 (asennettu)

Vaatii: /usr/bin/ksh

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

Ei löydetty

Päivitetty: ksh-20120801-139.el7.x86_64 (rhel-7-server-rpms)

Ei löydetty

Päivitys keskeytyy sitten.

Huomautus #1 : Poistettava ksh-pakettiversio (ksh-20120801-137) vaihtelee jo ladatun Redhat 7.x -version mukaan.

Muistio 2: Vain pienet käyttöjärjestelmän päivitykset ovat sallittuja SA-ydinpalvelimissa. Suuret käyttöjärjestelmän päivitykset (esimerkiksi RH 6.x - RH7.x) eivät ole sallittuja.

Tämä ongelma johtuu Redhatin myöhempien versioiden ksh-binäärissä käyttämän linkin muutoksesta. Redhatin aikaisemmat versiot tarjosivat linkin tiedostojen /bin/ksh ja /usr/bin/ksh välillä.

Ongelman ratkaisemiseksi voidaan käyttää toista kahdesta kiertotavasta.

Tapa 1: Pyydä yumia ohittamaan ksh rpm -päivitys käyttöjärjestelmän päivityksen aikana. Käytä yum-päivityksen sijaan yum -x ksh -päivitystä

Menetelmä 2 : Lataa uusin ksh rpm ja päivitä ksh ENNEN yum-komennon antamista käyttöjärjestelmän päivittämiseksi. Lataa uusin ksh rpm ja tallenna se kansioon /tmp (esimerkiksi ksh-20120801-139.el7.x86_64.rpm). Päivitä ksh rpm komennolla rpm -U /tmp/ksh-20120801-139.el7.x86_64.rpm jatka käyttöjärjestelmän päivittämistä komennolla yum upgrade

WINDOWS 2016 näkyy HPSA:ssa Tuntemattomana järjestelmänä

Windows 2016 -palvelimien käyttäjät ovat äskettäin valmiita, ja HPSA:ssa näytetään TUNTEMATTOMAT. Uusimmat 10.23 HPSA-korjaukset on asennettu. Tämä asia on kriittinen, koska emme voi ottaa käyttöön Windows 2016 -palvelimia.

Mitä tulee ongelmaan, SA 10.23 ei oletuksena tue Windows 2016:ta, joten aseta vain Windows 2016 Platform Installer, jotta SA voi havaita ja käsitellä Windows 2016:ta.

Käytä annettua viitettä: Alustan asennusohjelma – Windows 2016 50.0.73174.0.1

Allekirjoituksen vahvistus epäonnistui istunto

Voit suorittaa kaikki mittaustyökalutietueet.

Running WAY:1018:wayrpc testi: FAILURE

Tarkista tilakone: SUCCESS

Tarkista istuntotaulukot: SUCCESS

Tarkista lukituksen tila: SUCCESS

Tarkista allekirjoitusvirheet: FAILURE (tiedot alla)

————————––

Allekirjoituksen vahvistus epäonnistui: Istunto:350430100

————————–

Ratkaisu

Itse asiassa on zombi-istuntoja, mutta ei tässä tapauksessa. Istunto päättyi waybotin uudelleenkäynnistyksen jälkeen.

Lisää RH8-sisältöä redhat_importiin

Tiedätkö kuinka lisätä oikeat sisältötunnisteet mahdollistaaksesi RH 8 -korjausten lataamisen redhat_importin avulla? RH 8 -agentin tuki on julkaistu SA:lle ja uudet merkinnät ovat tarpeen, jotta redhat_import voi ladata korjaustiedostoja Redhatista.

Käyttöjärjestelmätunnisteita tarvitaan korjauksiin, sovellusvirran tunnisteet ovat esimerkki siitä, kuinka voit lisätä muita RH content_labels -sivustolta saatavia streameja:

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

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

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

platform=Red Hat Enterprise Linux 8 X86_64

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

platform=Red Hat Enterprise Linux 8 X86_64

Palvelinautomaatio (SA): MpC-apuohjelma epäonnistuu käyttäjän todennuksen vuoksi

Tapahtui virhe yritettäessä käyttää marketplace-connector.sh-apuohjelmaa sisällön lataamiseen ja tuomiseen MarketPlace-verkkosivustolta. Virhe Lataus epäonnistui käyttäjän todennusvirheen vuoksi.

Server Automation (SA) käyttää komentosarjaa marketplace-connector.sh ottaakseen yhteyttä MarketPlace-verkkosivustoon ja ladatakseen sisältöä verkkosivustolta. Kun apuohjelmaa yritetään suorittaa, näyttöön tulee seuraava virhe:

Striimin sisällön tilatietojen määrittäminen

Suoratoiston sisällön tilatietojen määrittäminen on valmis

Lataus epäonnistui käyttäjän todennusvirheen vuoksi.

Missä on yksi MarketPlace-verkkosivuston sisältöhuudoista.

Tämä virhe voidaan nähdä, kun yrität käyttää MarketPlace-liitintä ensimmäisen kerran tai sen jälkeen, kun sitä on käytetty onnistuneesti aiemmin.

Marketplace-connector.sh-komentosarja on määritettävä käyttämään käyttäjälle määritettyä MarketPlace/MySupport-käyttäjää. Tämä virhe ilmenee, koska Marketplace-connector.sh-apuohjelmassa määritettyä käyttäjätunnusta ei ole MarketPlace-verkkosivustolla, se on olemassa, mutta siinä on väärä salasana tai käyttäjätunnus on vanhentuneessa (sähköpostipohjaisessa) muodossa.

Voit ratkaista tämän ongelman määrittämällä ensin Marketplace-connector.sh-apuohjelman käyttämän käyttäjätunnuksen.

yksi. Siirry palvelimella, jossa Marketplace-connector.sh-apuohjelma on käynnissä, hakemistoon, johon apuohjelma on asennettu, ja anna komento ./marketplace-connector.sh read-config. Näytetyssä vaihtoehtojen/arvojen kaaviossa käytetty MpC-käyttäjätunnus näkyy käyttäjätunnusvaihtoehdon arvona.

kaksi. Varmista, että käyttäjänimen arvo EI ole sähköpostiosoitteen muodossa. Esimerkiksi john.doe@company.com.

Sähköpostipohjaiset käyttäjätunnukset vanhentuivat yhtenäisten tai yksisanaisten käyttäjänimien hyväksi. Esimerkiksi johndoe tai john_doe_user.

Jos näet sähköpostiin perustuvan käyttäjänimen, siirry kohtaan Marketplacen verkkosivusto ja luo uusi tili. Pyydä tarvittaessa Microfocus-tilitiimiä auttamaan tässä.

3. Jos käytössä on kelvollinen yksisanainen käyttäjätunnus, varmista, että sillä voi kirjautua MarketPlace-verkkosivustolle. Jos tämä kirjautuminen toimii, siirry kohtaan Palvelinkeskusautomaatio Valitse Web-sivuston Security and Compliance for Server Automation -osio ja napsauta Lataa-painiketta sen MpC-sisältövirran vieressä, jota yritettiin, kun virhe havaittiin. Tämä varmistaa, että tähän käyttäjätunnukseen liitetyllä tilillä on riittävät oikeudet tämän sisällön hakemiseen.

Neljä. Kirjoita uudelleen/korjaa Marketplace-connector.sh-apuohjelman käyttämät käyttäjätunnus- ja salasanakentät menemällä hakemistoon, johon apuohjelma on asennettu, ja antamalla komennon ./marketplace-connector.sh write-config –käyttäjänimi= .Sinua pyydetään antamaan tilin salasana.. kirjoita se, jota käytit kirjautuessasi MarketPlace-verkkosivustolle yllä olevassa vaiheessa.

5 . Suorita ./marketplace-connector.sh-komento uudelleen, jotta voit yrittää ladata ja tuoda MpC-sisältövirran.

Jos tämä virhe näkyy edelleen, avaa Micro Focus Support -kotelo (jos sitä ei ole jo avattu) ja anna komennon tulos. ./marketplace-connector.sh read-config ja marketplace-connector.log-lokitiedosto (sijaitsee hakemistossa, johon apuohjelma on asennettu).

Palvelinautomaatio (SA): vaiheet SA:n valmistelemiseksi Python 2 -koodin siirtämiseksi Python 3:een

Mihin vaiheisiin voidaan valmistaa nykyiset Python 2 -koodikannat olemassa olevissa Server Automation (SA) -ympäristöissä toimimaan tulevissa Python 3:a käyttävissä SA-versioissa?

Palvelinautomaation nykyiset versiot (SA-versiot 2018.08 ja sitä vanhemmat) käyttävät tällä hetkellä Python 2 -resoluutiota. Python 2 on kuitenkin lähestymässä tukiikänsä loppua. Tämä asiakirja on yleiskatsaus Python 3:ssa toimivien SA:n seuraavien versioiden valmisteluun. Tämä valmistelu on suoritettava ennen kuin kaikki olemassa olevat SA-versiot (2018.08 ja vanhemmat) päivitetään tuleviin SA:n versioihin.

Ensinnäkin olemassa olevia SA-versioita (2018.08 ja vanhemmat) ei päivitetä Python 3:een. Vaiheet on mainittu alla.

Voimme vain lisätä tuen Python 2/3 -yhteensopivan koodin käyttämiselle ja antaa käyttäjille mahdollisuuden alkaa muuntaa olemassa olevaa Python-koodikantaa sellaiseksi, joka toimii tulevissa Python 3:a käyttävissä SA:n versioissa.

Osa 1 – SA:n valmistaminen python 2 -koodin siirtämiseen python 3:een

Jotta voit ottaa python 2 & 3 -yhteensopivuuden käyttöön ytimissäsi/satelliiteissasi/agenteissasi, sinun on asennettava seuraavat paketit:

SA 2018.08:

SRVA_00278 – palvelinautomaatio 2018.08.004 kokoelma

SRVA_00266 – palvelinautomaatio 2018.08.002 Agentit

SRVA_00267 – palvelinautomaatio 2018.08.002 HPSAPython

SA 10,60

SRVA_00280 – palvelinautomaatio 10.60.014 kokoelma

SRVA_00281 – palvelinautomaatio 10.60.014 Agentit

SRVA_00263 – palvelinautomaatio 10.60.012 HPSApython

SA10.51

SRVA_00271 – palvelinautomaatio 10.51.011 kokoelma

SRVA_00272 – palvelinautomaatio 10.51.011 Agentit

SRVA_00273 – palvelinautomaatio 10.51.011 HPSAPython

SA10.23

SRVA_00274 – palvelinautomaatio 10.23.015 koonti

SRVA_00275 – palvelinautomaatio 10.23.015 Agentit

SRVA_00276 – palvelinautomaatio 10.23.015 HPSAPython

Huomautus #1: Tämän asiakirjan luomishetkellä yllä luetellut paketit olivat viimeisimmät jokaiselle luetellulle SA:n versiolle. Jos Rollup- tai Agent-pakettityypistä on saatavilla uudempia versioita, niitä voidaan käyttää sen sijaan. HPSAPython-paketin pitäisi kuitenkin jäädä

sama, ja se voidaan asentaa uudempien kokoelma- ja agenttipakettien kanssa.

Muistio 2: SA10.2x-versiot, jotka ovat vanhemmat 10.23, on päivitettävä versioon 10.23, ennen kuin ne voivat käyttää tätä asiakirjaa. Samoin SA 10.50 -ympäristöt on päivitettävä versioon SA 10.51, ennen kuin niitä voidaan käyttää. SA-versiot 10.2x vanhemmat EIVÄT voi käyttää tätä uutta Python 3 -toimintoa, ja ne on päivitettävä vähintään versioon 10.23.

Asenna palvelinautomaatiokokoelma noudattamalla patch.sh.txt-tiedoston asennusohjeita. Agenttien asennusohjeet ovat tiedostossa AGENT_README.txt ja HPSAPython-paketti voidaan asentaa README.txt-tiedoston ohjeiden mukaan.

Osa 2 – Python-skriptien siirtäminen

Voit valita kahdesta työkalusta koodisi automaattiseen siirtämiseen: Futurize ja Modernize. Valitsemasi työkalu riippuu siitä, kuinka paljon Python 3:n kaltaista haluat koodisi olevan.

Futurize tekee parhaansa, jotta Python 3:n idiomit ja käytännöt olisivat olemassa Python 2:ssa, esim. tavutyypin takaisinsiirto Python 3:sta, jotta sinulla on semanttinen pariteetti Pythonin pääversioiden välillä.

Modernisointi puolestaan ​​​​on konservatiivisempi ja kohdistuu Pythonin Python 2/3 -alajoukkoon luottaen suoraan 'kuuteen' yhteensopivuuden tarjoamiseen.

Koska Python 3 on tulevaisuus, saattaa olla parasta harkita Futurizen käyttöä ja alkaa sopeutua kaikkiin Python 3:n tuomiin uusiin käytäntöihin, joihin et ole vielä tottunut. Riippumatta siitä, minkä työkalun valitset, he päivittävät koodisi toimimaan Python 3:ssa ja pysyvät yhteensopivana aloittamasi Python 2 -version kanssa.

Riippuen siitä, kuinka konservatiivinen haluat olla, saatat haluta suorittaa työkalun ensin testisarjassasi ja tarkastaa visuaalisesti erotus varmistaaksesi, että muunnos on tarkka. Kun olet muuttanut testipakettisi ja varmistanut, että kaikki testit läpäisevät edelleen odotetusti, voit muuttaa sovelluskoodisi tietäen, että kaikki epäonnistuneet testit ovat käännösvirheitä.

Valitettavasti työkalut eivät voi automatisoida kaikkea, jotta koodisi toimisi Python 3:ssa, joten sinun on päivitettävä manuaalisesti muutamia asioita saadaksesi täyden Python 3 -tuen (mikä näistä vaiheista on tarpeen, vaihtelee työkalujen välillä).

Yksityiskohtainen kuvaus, jota tässä prosessissa tulee noudattaa, löytyy virallisesta dokumentaatiosta. Jokaiselle työkalulle on olemassa virallinen dokumentaatio, jota on luettava ja noudatettava.

Tarvittavat kirjastot toimitetaan ja ne ovat saatavilla SA:n mukana toimitetussa pythonissa. Kirjastojen versiot ovat tulevaisuus-0.17.1 tulevaisuutta varten ja kuusi-1.11.0 modernisointia varten. Näitä versioita on käytettävä koodin siirron aikana.

Suosittelemme koodin siirtämistä ensin testiympäristöissä. Kumpikaan ratkaisu ei tarjoa suoraa tai puhdasta koodin siirtoprosessia, vaan on ongelmia, jotka sinun on ratkaistava manuaalisesti.

Huomautus: Uusi sisältö tulee kehittää Python 3 -yhteensopivuus mielessä.

Osa 3 – Viitteet

Tulevaisuutta Modernisoi Python 2 & 3 virallinen dokumentaatio

HPSA-agenttia ei voi asentaa: järjestelmä ei löydä install_tool_x64.exe

Tiedätkö, että emme voi asentaa HPSA-agentteja? Jos yrität tehdä niin, tapahtuu virhe. Virhe on lueteltu alla.

[01/Aug/2019 12:39:48] [TRACE] RunCommand('install_tool_x64.exe –zap –loglevel=trace') [01/Aug/2019 12:39:48] [VIRHE] RunCommand() – Popen epäonnistui : 'install_tool_x64.exe –zap –loglevel=trace' : Virhe : (2) : 'Järjestelmä ei löydä määritettyä tiedostoa. [01/Aug/2019 12:39:48] [VIRHE] zap_agent: FAIL

[01/Aug/2019 12:39:48] [VIRHE] RunCommand() – Avaus epäonnistui: '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' : Virhe : (2) : 'Järjestelmä ei löydä määritettyä tiedostoa. [01/Aug/2019 12:39:48] [TRACE] install_tool: FAIL [01/Aug/2019 12:39:48] [VIRHE] Opsware-agentin asennus epäonnistui.

Palvelin näytti seuraavan ongelman. ComSpec=C:Windowssystem32cmd.exe;C:WindowsSysWOW64cmd.exe

Ja testipalvelimillamme se asetettiin seuraavasti:

ComSpec=C:Windowssystem32cmd.exe

Avaa CMD järjestelmänvalvojana Windows-palvelimella, jossa on ongelmia, ja suorita seuraava komento:

kaiku %COMSPEC%

Jos polkuja on useita, ota Windowsin järjestelmänvalvojatiimi mukaan ja anna heidän muuttaa rekisteritiedostojen arvoa. Kun olet valmis, voit varmistaa, että vain C:windowssystem32cmd.exe on käytössä, eikä sinulla pitäisi olla ongelmaa.

Palvelinautomaatio (SA): Aikakatkaisuviesti, joka näkyy uusimpia Windows-korjauksia asennettaessa

Kun palvelinautomaatiota käytetään uusimpien Microsoft Windowsin kuukausikorjausten asentamiseen, useat palvelimet palauttavat Aikakatkaisu -viestin asennuksen aikana.

Kun suoritat Server Automation (SA) -työtä uusimman Microsoft Windowsin kumulatiivisen korjaustiedoston asentamiseksi, monet palvelimet, joita vastaan ​​työ suoritetaan, palauttavat epäonnistuneen tuloksen ja virheilmoituksen Timed Out. Palvelimia tarkistettaessa raportoidaan virhettä vastaan, monet niistä osoittavat, että korjaustiedostot on asennettu oikein.

Kun suoritat tämän tyyppistä työtä, SA varmistaa ensin, että se voi puhua hallitun palvelimen kanssa (johon hallitun palvelimen SA-agentti vastaa), ja jatkaa sitten tarvittavien korjaustiedostojen lataamista. Jos molemmat vaiheet onnistuvat, SA-agenttia kehotetaan käynnistämään korjaustiedoston asennus.

SA-työ odottaa oletusarvoisesti jopa tunnin ajan, jotta SA-hallittu palvelin suorittaa tämän asennuksen loppuun. Jos SA-työ ei ole kuullut hallitulta palvelimelta tunnin kuluttua, että korjaustiedoston asennus on valmis, se merkitsee palvelimen korjaustiedoston asennuksen epäonnistuneen ja ilmoittaa, että sen aikakatkaisu.

Prosessin asennus hallittavalle palvelimelle saattaa kuitenkin kestää odotettua kauemmin korjaustiedoston asentamiseen. Tämän palvelimen merkitseminen aikakatkaistuksi SA-työssä ei peruuta/pysäytä hallitun palvelimen asennusprosessia jatkumasta.

Jos korjaustiedoston asennus onnistuu, hallittu palvelin palauttaa tulokset takaisin SA-työhön. Koska SA-työ on kuitenkin jo merkinnyt palvelimen epäonnistuneeksi, se ei kumoa tätä tilaa, koska asennuksen jälkeen saattaa olla muita vaiheita SA-työ, jota ei ole suoritettu.

Tällä tavalla SA-työ näyttää palvelimen Failed – Timed Out, mutta korjaustiedoston asennus onnistui.

On mahdollista muuttaa oletusaikaa, jonka SA-työ odottaa, että hallitut palvelimet suorittavat toiminnot, jotka sen on määrä suorittaa (kuten korjaustiedostojen asentaminen, komentosarjan suorittaminen jne.). Jos haluat muuttaa tätä oletusarvoa, vedä SA java gui esiin, valitse Hallinta, sitten Järjestelmän kokoonpano ja sitten Configuration Parameters.

Napsauta oikeanpuoleisessa ruudussa Command Engine (tapa). Tämä näyttää kaikki parametrit, joita voidaan muokata. Katso käytettävissä olevat parametrit (tai suodata ne ikkunaruudun oikeassa yläkulmassa olevan hakukentän kautta) ja etsi parametri way.remediate.package_alarm_timeout.

Oletuksena tämän parametrin arvo on 3 600 sekuntia (tai 1 tunti). Voit suurentaa tätä arvoa ja sitten tallentaa sen. Tämän parametrin muuttaminen ei vaikuta käynnissä oleviin SA-työhön, mutta kaikki uudet SA-työt käyttävät tätä arvoa.

Huomautus: Ole varovainen, kun muutat tätä parametria. jos käytetään erittäin suurta arvoa (esimerkiksi useita tunteja), koko SA-työn valmistuminen saattaa viivästyä kyseisen ajan, jos jopa YKSI hallittu palvelin kohtaa viiveen pyydetyn toiminnon suorittamisessa. Tämän parametrin muuttaminen pienin askelin on suositeltavaa.

Palvelinautomaatio (SA): uln_import-komento epäonnistuu odotetun puskurin merkkijonon kanssa

Palvelinautomaatio (SA) -työkalua uln_import käytettäessä havaitaan TypeError: odotettu merkkijono tai puskuri, kun SA-ydintä yritetään rekisteröidä Oracle Linux -verkkopalvelimeen.

Server Automation (SA) voi ladata ja tuoda tietokantaansa OEL-sisältöä. Se tekee tämän käyttämällä SA-ydinpalvelimessa olevaa uln_import-apuohjelmaa, joka muodostaa yhteyden Oracle Linux -sivustolle, joka tarjoaa OEL-sisältöä käyttäjille/tileille, jotka ovat ostaneet tilin Oraclen kautta päästäkseen tähän sisältöön.

SA-ydinpalvelimen ensimmäinen rekisteröinti Oracle Linux -sivustolle suoritetaan määrittämällä muuttujat /etc/opt/opsware/patch_importer/uln_import.conf-tiedostossa ja suorittamalla sitten komento /opt/opsware/patch_importer/bin/uln_import –verbose –show_conf.

Ajettaessa yllä olevaa SA-palvelimen rekisteröintikomentoa Oraclen Web-sivustolle, näkyy seuraava virhe: patch_importer_versioned 807 ERROR Odottamaton virhe: käyttäjän rekisteröinti epäonnistui: XML-RPC-palvelinvirhe: TypeError: odotettu merkkijono tai puskuri.

Tämä virhe näkyy sekä istuntonäytössä, josta komento suoritetaan, että apuohjelman lokitiedostossa

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

Ongelma näkyy, koska uln_import-koodi ei voi käsitellä oikein apuohjelman määritystiedostossa (/etc/opt/opsware/patch_importer/uln_import.conf) määritettyjä muuttujia.

Muokatessasi /etc/opt/opsware/patch_importer/uln_import.conf-tiedostoa tulee olla varovainen, jotta tiedostoon ei vahingossa lisätä välilyöntejä tai ohjausmerkkejä. Hyvä suositus olisi tallentaa/varmuuskopioida olemassa oleva uln_import.conf-tiedosto ja kopioida sitten /etc/opt/opsware/patch_importer/uln_import.conf-sample uln_import.conf-tiedostoon (korvaamaan se) varmistaaksesi, ettei se ole vioittunut. tiedostossa.

Muuta sitten kutakin ympäristöllesi vaadittua parametria uln_import.conf-tiedostossa ja yritä rekisteröidä SA-palvelin uudelleen Oraclen verkkosivustoon uln_import-komennolla.

Jos tämä ei vieläkään ratkaise ongelmaa, tuo uusi kopio asetustiedostosta (uln_import.conf-samplesta) ja lisää sitten yksitellen jokainen parametri conf-tiedostoon ja suorita uln_import-komento uudelleen jokaisen jälkeen. lisäys.

Vaikka yhteys ei ehkä toimi, koska jotkin parametreista puuttuvat, odotettu merkkijono- tai puskurivirhe ei tule näkyviin, ellei konfiguraatiotiedostossa muutettu muuttuja ole syynä ongelmaan.

MERKINTÄ: Välilyönnit/välilyönnit EIVÄT VOI edeltää mitään muuttujien nimiä.

username=JOHN.DOE@ACME.COM (ilman lainausmerkkejä) on hyväksyttävä

username=JOHN.DOE@ACME.COM (ilman lainausmerkkejä) ei ole.

Palvelinautomaatio (SA): Käyttäjän rekisteröinti epäonnistui, kun uln_import suoritettiin

Kun käytät Server Automation (SA) -apuohjelmaa uln_import SA-ydinjärjestelmän rekisteröimiseen Oraclen kanssa, ilmenee virhe Käyttäjän rekisteröinti epäonnistui.

Server Automation (SA) voi ladata ja tuoda tietokantaansa OEL-sisältöä. Se tekee tämän käyttämällä SA-ydinpalvelimessa olevaa uln_import-apuohjelmaa, joka muodostaa yhteyden Oracle Linux -sivustolle, joka tarjoaa OEL-sisältöä käyttäjille/tileille, jotka ovat ostaneet tilin Oraclen kautta päästäkseen tähän sisältöön.

SA-ydinpalvelimen ensimmäinen rekisteröinti Oracle Linux -sivustolle suoritetaan määrittämällä muuttujat /etc/opt/opsware/patch_importer/uln_import.conf-tiedostossa ja suorittamalla sitten komento /opt/opsware/patch_importer/bin/uln_import –verbose –show_conf.

Tätä komentoa suoritettaessa havaitaan seuraava virhe ja komento keskeytyy.ULNERror: käyttäjän rekisteröinti epäonnistui: XML-RPC-palvelinvirhe: MaxRetryError: SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] varmenteen vahvistus epäonnistui (_ssl.c:590) 2019-09 -07 20:19:58,679 patch_importer_versioned 807 ERROR Odottamaton virhe: käyttäjän rekisteröinti epäonnistui: XML-RPC-palvelinvirhe: MaxRetryError: SSLE-virhe: [SSL: CERTIFICATE_VERIFY_FAILED] varmenteen vahvistus epäonnistui (_ssl)c:590.

Tämä virhe näkyy sekä konsoliistunnossa, jossa uln_import-komento suoritetaan, että uln_importer.log-tiedostossa, joka löytyy hakemistosta /var/log/opsware/patch_importer.

Uln_import-apuohjelma käyttää kokoonpanomuuttujia, jotka on määritetty tiedostossa /etc/opt/opsware/patch_importer/uln_import.conf. Kolmea näistä muuttujista (käyttäjätunnus, salasana, csi) käytetään SA sy:n rekisteröinnissä

Oracle Linux -sivustolla, joka tarjoaa OEL-sisällön. Virhe näkyy, kun Oraclen verkkosivusto ei hyväksy näitä tietoja.

Jos oletetaan, että näiden kolmen muuttujan arvot on lisätty oikein, varmista, että niillä voidaan kirjautua suoraan Oracle Linux -sivustolle osoittamalla verkkoselaimella URL-osoite http://linux.oracle.com ja kirjautumalla sisään näiden tietojen avulla. Tämä varmistaa, että tilitiedot ovat oikein.

Jos arvot toimivat kirjautuessaan sisään Oraclen Web-sivustoon manuaalisesti, toinen mahdollinen ongelman syy voi johtua varmenteista, jotka on oletuksena toimitettu uln_import-apuohjelman käyttöön. Joissakin tapauksissa voi olla tarpeen tuoda Oracle Linux -sivuston varmenne varmennetiedostoon ca-bundle.crt. Tämä pätee erityisesti, jos välityspalvelinta EI ole määritetty uln_import.conf-tiedostossa.

Tuo Oracle Linux -sertifikaatti SA-palvelinten ca-bundle.crt-tiedostoon noudattamalla alla olevia kirjallisia ohjeita.

Vaihe 1: Tee varmuuskopio olemassa olevasta varmennetiedostosta cp /opt/opsware/openssl/certs/ca-bundle.crt /opt/opsware/openssl/certs/ca-bundle.crt_backup.

Vaihe 2: Hanki viimeisin sertifikaatti Oraclelta

Vaihe 3: Avaa ladattu tiedosto (ULN-CA-CERT.sha2) ja etsi viimeinen varmenne tiedoston lopusta.

Vaihe 4: Kopioi tämä varmenne (alkaen rivillä BEGIN CERTIFICATE ja sisältäen END CERTIFICATE -rivin).

Vaihe 5: Avaa /edit tiedosto /opt/opsware/openssl/certs/ca-bundle.crt ja lisää tämä varmenne tiedoston loppuun.

Vaihe 6: Tallenna tiedosto.

Vaihe 7: Yritä uudelleen komennolla uln_import ja yritä rekisteröityä Oraclen verkkosivustolle.

Jos kumpikaan näistä ratkaisuista ei toimi, avaa tukipyyntö ja anna /var/log/opsware/patch_importer/uln_importer.log ja

/etc/opt/opsware/patch_importer/uln_import.conf-tiedostot.