Score:1

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

br flag

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
nf flag
Based on your update where the server is back-leveled from the expected `oslevel`, I would guess that it's missing a package or two. Try `instfix -ic | grep 7200-04 | grep :-:` to find packages that are referenced in the TL4 level that aren't installed.
Jeff Schaller avatar
nf flag
The build dates are crossed up with the TL/SP's -- the repo is a newer TL4SP2 but the running OS is TL4SP1, while the repo has an older build date than the running OS. Perhaps there's a package in the repo that's not installed in the OS, and there's been a patch to the running OS of a package with a newer build date.
cn flag
Please state again why are you unable to run `oslevel -s` _before patching_ only _after it?_
Score:0
nf flag

One possibly helpful step along the way could be to use the bffcreate command to convert those bff filenames into package-based filenames. Something along the lines of bffcreate -c -d /path/to/repo.

To answer the question, though, once you've run inutoc to create the .toc file, you can ask installp to list the contents of that repo's TOC file in colon-separated output, which includes the build date in field 17. The bos.rte.install package will be among those that have the most recent build date, so you could search for that and extract its VRMF (Version, Release, Modification, Fix) and build date:

sudo installp -L -d /path/to/repo | grep :bos\.rte\.install: | sort -t: -k17n | tail -1 | awk -F: '{print $3, $17}'

That will output the VRMF and build date of the most recent build of the bos.rte.install package in that repo. Adjust the awk printing statement if you're only interested in one field or the other. The build number is in YYww format (2-digit year, 2-digit week of that year). The VRMF of bos.rte.install will loosely correspond with the output from oslevel; you could perhaps rely on the first three fields to match up with oslevel -r output; for example, a VRMF of 7.2.4.6 correlates to an oslevel of 7200-04, as would a VRMF of 7.2.4.2 -- the initial 7.2 gives the "7200" portion and the 4 gives the "-04" portion.

Score:0
br flag

In the end, this is the solution that I've implemented (and which does provide me with the correct full oslevel):

Creating the repo

  1. Copy all packages as *.bff into ${REPO_SNAPSHOT_PATH}
  2. Recreate the .toc file: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; inutoc .
  3. Cleanup the repo: /usr/lib/instl/lppmgr -rubxVd "${REPO_SNAPSHOT_PATH}"
  4. Rename the bff files to understandable package names: bffcreate -c -d "${REPO_SNAPSHOT_PATH}"
  5. Recreate the .toc file once more: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; inutoc .

Figure out the full oslevel

  1. Create an LPP Source from the repo: nim -o define -t lpp_source -a server=master -a location="${REPO_SNAPSHOT_PATH}" "${LPP_SOURCE_NAME}"
  2. Create Spot from this LPP Source: nim -o define -t spot -a source="${LPP_SOURCE_NAME}" -a server=master -a location="${SPOT_PATH}" "${SPOT_NAME}"
  3. Get the full oslevel from this Spot: FULL_OSLEVEL="$(lsnim -l ${SPOT_NAME} 2>/dev/null | awk '$1=="oslevel_s" {print $3}')"
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.