Many AIX administrators love the BFF (or LPP) format of packaging. I think the main reason Michael Felt started his aixtools.net project many years ago was his desire to package all open-source packages in AIX-native format. The format (or, more accurately, the tools to work with it) has several advantages. The most favorite is the ability to reject installed updates. But, one more time - I have problems with it!
If you want to install an AIX BFF package with Ansible, you can find several modules like ibm.power_aix.installp, ibm.power_aix.geninstall, and ibm.power_aix.nim.
Problem №1. ibm.power_aix.nim
As the name implies, the module executes some action on the NIM server. It is wonderful, because everyone (almost everyone) has a NIM in the environment, and it should be easy to use it.
Even if I have the NIM server in my environment, I typically start all actions from the NIM clients. In this case, I should perform 80% of the actions on a NIM client and then switch to the NIM server. Either I must hard-code the NIM server name in my playbooks in each action, or define it as a variable, if I manage an environment with several NIM servers. I have such environments where I need to decide every time which NIM server to use for which AIX server. That’s why I prefer to start the action from the NIM client. The NIM client already knows which NIM server it uses.
OK, we found the NIM server, where the module must be executed, and we agree to delegate the task to the NIM server. My next problem is that the action install_fileset requires a bundle name. Every time I want to install a package, I must do something like (the example below is a modified demo playbook from the ibm.power_aix collection):
- name: Create bundle
ibm.power_aix.nim_resource:
action: create
name: "{{ installp_bundle }}"
object_type: installp_bundle
attributes:
location: "{{ filesets_location }}"
delegate_to: "{{ nim_server }}"
- name: Install filesets
ibm.power_aix.nim:
action: install_fileset
targets: "{{ nim_client_v }}"
lpp_source: "{{ lpp_source_v }}"
installp_bundle: "{{ installp_bundle }}"
delegate_to: "{{ nim_server }}"
- name: Destroy bundle
ibm.power_aix.nim_resource:
action: delete
name: "{{ installp_bundle }}"
delegate_to: "{{ nim_server }}"
Problem №2. ibm.power_aix.installp
I think you understand the problem with the module, based on what I wrote above. Yes, the module installs packages, but it doesn’t know anything about NIM resources.
If you want to use it to install packages from a NIM resource, you must first mount the resource, then install the package, and then unmount the resource.
Something like:
- name: Allocate lpp_source
ansible.builtin.command:
cmd: "nimclient -o allocate -a lpp_source={{ lpp_source }}"
- name: Mount share
ibm.power_aix.mount:
node: "{{ nim_server }}"
mount_dir: "{{ lpp_source_dir }}"
mount_over_dir: /mnt
options: "soft,ro"
state: mount
- name: Install packages
ibm.power_aix.installp:
device: /mnt
extend_fs: true
agree_licenses: true
dependencies: true
install_list: "{{ packages }}"
- name: Unmount share
ansible.builtin.mount:
path: /mnt
state: unmounted
fstab: /dev/null
- name: Deallocate lpp_source
ansible.builtin.command:
cmd: "nimclient -o deallocate -a lpp_source={{ lpp_source }}"
The same applies to ibm.power_aix.geninstall.
I use the ansible.builtin.command module and the nimclient command. There is no nimclient Ansible module right now, but IBM is working on it. The best in the nimclient command is that the actions allocate and deallocate are idempotent. You can start them as many times as you wish. If the resource was allocated, it will not allocate it one more time or bother you with error messages. Same with deallocate.
I hope you see a potential for a new Ansible role.
Problem №3. NIM client vs NIM server
What I wrote above works perfectly. But only on NIM clients. If you start the nimclient command on the NIM server, you will get something like:
It means we must first check if the playbook is running on the NIM server or on the NIM client. It can be done easily by checking the nimesis service, which runs only on NIM servers:
- name: Check if nimesis exists
ansible.builtin.command:
cmd: lssrc -s nimesis
failed_when: false
changed_when: false
register: nimesis
Then, we can create two different sets of tasks—one for NIM clients and another for NIM servers.
For NIM servers, we don’t mount anything; we install packages directly:
- name: Install packages
ibm.power_aix.installp:
device: "{{ lpp_source_dir }}"
extend_fs: true
agree_licenses: true
dependencies: true
install_list: "{{ packages }}
when: nimesis.rc == 0
Support the Power DevOps Newsletter!
If you like reading technical articles about IBM Power, AIX, and Linux on IBM Power, consider upgrading to the paid tier to show your support. As a paid subscriber, you not only get regular posts, but you will get additional posts with the full code and further explanations, access to the whole archive of the blog, and take part in our monthly calls where you can ask your questions and propose topics for future newsletters. Be an active member of our community!
Were there enough problems?
I hope you still read it. Because for me, describing these three problems was already exhausting. But maybe it is only the heat here, in my usually cool place. I really don’t know how many of you live in areas with temperatures above 25°C. This is the temperature outside right now, and it is HOT! I feel like I'm in a desert. Although I must say, I felt better in the real deserts I visited - the Sahara and the Negev.
That’s why I continue with the “real code"© next week. Meanwhile, you have time to write to me about the types of problems you have when installing packages on AIX with Ansible. Maybe I must re-think and re-create my playbooks ;-)
Have fun installing packages on AIX with Ansible!
Andrey
Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.
Follow me on LinkedIn, Twitter and YouTube.
You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.