Puncte:1

Determine the full oslevel (incl build date) of a local AIX repository without patching / installing

drapel br

In our environment, only one of our AIX servers is permitted to access the internet through the firewall. On this one server, I use suma to download all fixes for all base levels, technology levels and service packs that we have in our environment; this is done daily. Once a month, I copy all fixes together in one folder per base level and I use inutoc to create a couple repositories that are frozen and that can be used to patch all of our AIX servers. This way we can ensure all servers are on the same oslevel. We call this a "monthly patchset".

We have a CSV file that lists all kernel versions for each "monthly patchset" for all of our UNIX/Linux OS flavors. That CSV file is used by our patching / validation scripts. For Linux / Solaris I've found "tricks" to determine the kernel version from the repository files themselves, but on AIX I'm failing to figure out the oslevel without actually patching a server with it. After patching, I can run 'oslevel -s' to figure the oslevel, but that is too late, as our patching scripts use / require the oslevel before starting the actual patching.

Does anyone know a trick to accomplish this? I've tried the following so far:

  • Our repository folder contains many *.bff files, which are binary files, so inside those files I can't find the oslevel
  • The *.bff file names are mostly 'U' followed by some numbers and '.bff' (so not usable for determining the oslevel). But some filenames actually do contain (parts of) the oslevel in the filename. For example: 7200-01-06.bff 7200-02-01-1732.bff 7200-02-06.bff 7200-03-06.bff 7200-03.bff 7200-04-01.bff 7200-04-02.bff 7200-04-03.bff 7200-04.bff 7200-05-01.bff 7200-05-02.bff 7200-05.bff. However, as you can see, from the latest oslevels, the 'build date' part is missing in the filename.
  • We patch using the install_all_updates -Y -d <path_to_repo> command. I've tried using install_all_updates -p -d <path_to_repo>, hoping that it would be visible somewhere in the output, but it isn't.
  • I've also tried installp -[lL] -d <path_to_repo>, but also there the oslevel isn't visible.

I hope someone can assist me with this.

Edit below (as a response to @Jeff Schaller his answer)

Thanks a lot for your assistance!

It's very close to matching, but not exactly I'm afraid...

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep :bos\.rte\.install: | sort -t: -k17n | tail -1 | awk -F: '{print $3, $17}'
7.2.4.2 1937
root@servername /nim/export
--> oslevel -s
7200-04-01-1939
root@servername /nim/export

Not sure why though... Any idea?

More detail:

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep 1937 | wc -l
     613
root@servername /nim/export
--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep 1939 | wc -l
       0
root@servername /nim/export
--> 

So I thought that there must be some package installed with a builddate of 1939 that is causing 'oslevel-s' to display that builddate. So I ran following commands to find this package:

--> lslpp -Lc all | awk -F':' '{print $2" "$3" "$18}' | grep 1937 | wc -l
     288
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> lslpp -Lc all | awk -F':' '{print $2" "$3" "$18}' | grep 1939 | wc -l
       0
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> oslevel -s
7200-04-01-1939
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> 

As you can see, I wasn't able to find this package... :(

Edit #2 below (as a response to @Jeff Schaller his comment)

root@servername /
--> instfix -ic | grep 7200-04 | grep :-:
root@servername /

That didn't come back with anything I'm afraid.

Also I'm not sure what you mean exactly with "... server is back-leveled from the expected oslevel...". Isn't it the opposite? 'oslevel -s' gives back 1939 as build date, while all packages indicate that the build date should be 1937. Isn't that "front-leveled" then?

Jeff Schaller avatar
drapel nf
Pe baza actualizării dvs. în care serverul este nivelat înapoi de la „oslevel” așteptat, aș presupune că îi lipsește un pachet sau două. Încercați `instfix -ic | grep 7200-04 | grep :-:` pentru a găsi pachete la care se face referire la nivelul TL4 care nu sunt instalate.
Jeff Schaller avatar
drapel nf
Datele de construire sunt încrucișate cu cele TL/SP -- repo-ul este un TL4SP2 mai nou, dar sistemul de operare care rulează este TL4SP1, în timp ce repo-ul are o dată de construire mai veche decât sistemul de operare care rulează. Poate că există un pachet în repo care nu este instalat în sistemul de operare și a existat un patch pentru sistemul de operare care rulează a unui pachet cu o dată de construire mai nouă.
drapel cn
Vă rugăm să spuneți din nou de ce nu puteți rula `oslevel -s` _înainte de corecție_ numai _după aceasta?_
Puncte:0
drapel nf

Un pas posibil util de-a lungul drumului ar putea fi folosirea bffcreate comandă pentru a converti acele nume de fișiere bff în nume de fișiere bazate pe pachet. Ceva de tipul bffcreate -c -d /path/to/repo.

Pentru a răspunde la întrebare, totuși, odată ce ai fugit inutoc pentru a crea fișierul .toc, puteți întreba installp pentru a lista conținutul fișierului TOC al acelui depozit în ieșire separată prin două puncte, care include data de construire în câmpul 17. Pachetul bos.rte.install va fi printre cele care au cea mai recentă dată de construire, așa că ați putea căuta aceasta și extrageți-i VRMF (Versiune, Lansare, Modificare, Remediere) și data construirii:

sudo installp -L -d /path/to/repo | grep :bos\.rte\.install: | sortare -t: -k17n | coada -1 | awk -F: „{printează $3, $17}”

Aceasta va scoate VRMF și data construirii celei mai recente versiuni a pachetului bos.rte.install din acel depozit. Ajustează awk tipărirea declarației dacă sunteți interesat doar de un domeniu sau altul. The numărul versiunii este în format YYww (an cu 2 cifre, săptămâna din 2 cifre din acel an). VRMF al bos.rte.install va corespunde vag cu ieșirea de la oslevel; te-ai putea baza probabil pe primele trei câmpuri cu care se potrivesc oslevel -r ieșire; de exemplu, un VRMF de 7.2.4.6 se corelează cu un nivel os de 7200-04, la fel ca un VRMF de 7.2.4.2 -- 7.2 inițial dă porțiunea „7200” și 4 dă porțiunea „-04”.

Puncte:0
drapel br

În cele din urmă, aceasta este soluția pe care am implementat-o ​​(și care îmi oferă nivelul corect complet):

Crearea repo

  1. Copiați toate pachetele ca *.bff în ${REPO_SNAPSHOT_PATH}
  2. Recreează fișierul .toc: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd „${REPO_SNAPSHOT_PATH}” ; inutoc .
  3. Curățați depozitul: /usr/lib/instl/lppmgr -rubxVd „${REPO_SNAPSHOT_PATH}”
  4. Redenumiți fișierele bff în nume de pachete ușor de înțeles: bffcreate -c -d „${REPO_SNAPSHOT_PATH}”
  5. Recreează încă o dată fișierul .toc: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd „${REPO_SNAPSHOT_PATH}” ; inutoc .

Aflați nivelul complet

  1. Creați o sursă LPP din depozit: nim -o define -t lpp_source -a server=master -a location="${REPO_SNAPSHOT_PATH}" "${LPP_SOURCE_NAME}"
  2. Creați spot din această sursă LPP: nim -o define -t spot -a source="${LPP_SOURCE_NAME}" -a server=master -a location="${SPOT_PATH}" "${SPOT_NAME}"
  3. Obțineți nivelul complet de oslevel din acest spot: FULL_OSLEVEL="$(lsnim -l ${SPOT_NAME} 2>/dev/null | awk '$1=="oslevel_s" {print $3}')"

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.