AIX playbook requires an update

[Haroon-Khel]

• Failing Yum task

The task Install yum package support fails with the error coreutils-8.29-4.ppc conflicts mktemp. A temporary solution is to skip the coreutils package.

• Outdated installation links

The task Install yum package support contains 3 links to rpm packages which no longer exist:

http://www.bullfreeware.com/download/bin/2328/libiconv-1.14-22.aix6.1.ppc.rpm
http://www.bullfreeware.com/download/bin/2591/libunistring-0.9.6-2.aix6.1.ppc.rpm
http://www.bullfreeware.com/download/bin/3944/perl-5.24.0-3.aix6.1.ppc.rpm

Causing the error Failed to get nevra information from RPM package

• Installation packages/archives need to be in /Vendor_Files/aix on the ansible controller

This isn't really an error, but what I feel to be an inconvenient method of installing packages. Many of the installation packages are required to be in /Vendor_Files/aix on the machine which run the ansible playbook, which I didnt have, causing the playbook to fail many times. So my question is, is there a more efficient way of doing this?

Examples include

• /Vendor_Files/aix/XLC/XL_C_Cpp_FOR_AIX_V16.1_EMG.tar.Z

• /Vendor_Files/aix/OpenGL_X11.tar

• /Vendor_Files/aix/openssl/openssl-1.0.2.1601.tar.Z

• Transfer and extracting /Vendor_Files/aix/openjdk-7u-aix.tar results in the following error

    "msg": "Failed to find handler for \"/.ansible/tmp/ansible-tmp-1594290693.3986292-109761101654969/source\". Make sure the required command to extract the file is installed. Command \"/opt/freeware/bin/unzip\" could not handle archive. Command \"/usr/bin/gtar\" detected as tar type None. GNU tar required."
}

After trying to transfer and extract /Vendor_Files/aix/openjdk-7u-aix.tar manually, i get the error:

x j2sdk-image/jre/lib/rt.jar, 60290313 bytes, 117755 tape blocks
tar: tape read error: unexpected EOF

I suspect that this is the error that causes ansible to stumble, since the same ansible error does not occur when transfering and extracting /Vendor_Files/aix/OpenGL_X11.tar. Hence, I can only conclude that there maybe something wrong with the openjdk-7u-aix.tar file

• {{ bootjdk }} variable will not load for AdoptOpenJDK 9 through 12 tasks.
  Despite there being a

name: Load AdoptOpenJDKs variable file
include_vars: ../adoptopenjdk_variables.yml

tasks at the beginning of the playbook, in which the variable bootjdk: openj9 is supposed to load, it doesnt. To temporarily overcome I replace instances of {{ bootjdk }} with openj9

[jdekonin]

I agree that this is very out of date. The reason behind the file being "hidden", is because some might have a license that not all users might have access too. Others are not available for direct download (or weren't at the time of writing).

openssl-1.0.2.1601.tar.Z for instance there was no direct download url as there was an agreement acceptance required by IBM. For XC_C, whether its 13 or 16, there are license implications, so there couldn't be a posting of the binary free for all to obtain. :)

For some sections there are comments detailing reasons.

[Haroon-Khel]

Moving the - name: Load AdoptOpenJDKs variable file task, which is run in its own task block, to its own role seems to have fixed the issue of the bootjdk variable not loading. Changes are being made in #1434

[Haroon-Khel]

The Failing Yum task may have been intermittent, as it did not occur on 2 'out of the box' aix machines

[aixtools]

How can I help?

I'll help patch this one up - but if you (openjdk) are game, I'd like to attempt an alternative - with fewer dependencies re: the Opensource tooling.

FYI: IBM is very committed to using yum - which requires their packaging of python2, which has it's dependencies, etc. etc. Personally, I liked the idea - very much - back in 2001 - but by 2004 I was against because mixing package managers just leads, sooner or later - to conflicts.

I see that IBM is working hard to correct the issues of the past, but I know I'll never really embrace using two package managers - e.g., Debian base, and all additonal OSS installed using RPM rather than 'native' aptitude.

Back on point: how I can I help with the current situation!

[aixtools]

The Failing Yum task may have been intermittent, as it did not occur on 2 'out of the box' aix machines

If those are the two new systems I prepped at OSU - then that is probably because I spent some time getting yum fixed and installed by default. So, the stray dependencies coreutils needed before were already resolved.

If it is not those systems - then I am would have to guess differently.

[aixtools]

As I mention in #1581 - in part by your concerns above (I did not have this ...), this should be part of a verification check. IMHO it is wrong to assume that the playbook installs software requiring a license.

My opinion is that whoever is supplying the LPAR (or WPAR) is responsible for supplying licensed software. So, maybe IBM provides the software - but not via a (relatively) uncontrolled licensed version stored as a file in an OSS supported site.

I do not care who put it there, it does not make it suddenly available as licensed software. IBM support would not agree - at least I would not expect them to agree formally.

[Haroon-Khel]

This can be closed. The issues have since been resolved