AIX for Linux Administrators - part1

Introduction

I frequently encounter curiosity among Linux administrators regarding what AIX administration looks like and how much it differs from what they already know. Most specialists are aware that Linux is derived from Unix, but many have at least once wondered to what extent their knowledge and experience would translate to working with a system like AIX. Some have even had the opportunity to log into an AIX system and perform basic administrative operations, but were unsure if the commands they knew were reflected in the new environment or had the same application.

As we know, encountering something new can involve a whole range of emotions, ranging from fascination to frustration and fear of the unknown.

I believe that when learning any technology, it is worth keeping an open mind and not getting discouraged by differences right at the beginning. While I consider questioning existing solutions and constructive criticism to be extremely important in IT, I encourage a relaxed approach, at least at the start of this new journey :). It is definitely not worth waging a war over which system is “better”; instead, it is worth focusing on which approach works best for a given application.

The worlds of AIX and Linux often intersect – not only through technology itself but also through the habits of administrators who deal with these systems and look for equivalents of their favorite tools. For example, many Linux administrators use NMON, but do not know that it was originally written for AIX and has been a part of it for many years. It is also quite common to use LVM on Linux, but few realize that LVM appeared for the first time in AIX back in 1989 – about 10 years before LVM on Linux. Interestingly, AIX was also the first operating system to implement journaling.

In turn, thanks to Linux administrators and their attachment to their favorite tools, a dedicated OpenSource repository exists and continues to develop for AIX (AIX Toolbox for Open Source Software), addressing the issue of certain software not being available in the standard installation.

Initially, I planned to write a single article, but after outlining the topics that seemed important or interesting, it turned out to be too much for one publication. Therefore, I decided to divide it into at least three separate parts.

This text is aimed specifically at Linux administrators, but if you do not feel like the target audience or are interested in AIX at a more general level, I encourage you to check out my other publications:

Initial information

It is worth emphasizing that:

Linux is derived from Unix (but is not Unix)
AIX is one of the systems in the Unix family

Although Linux itself is actually just the system kernel, and the operating system constitutes the entire Linux distribution, it has become common in everyday language to refer to Linux as an operating system.

Both free and commercial Linux systems are known, but if we were to compare them to AIX, the closest equivalents would be systems like Red Hat Enterprise Linux and SUSE Linux Enterprise Server. This is because these are enterprise-class systems, typically designed for servers.

The AIX system has been developed by IBM from the very beginning, with its origins dating back to 1986. AIX is a commercial and licensed system, and as of this writing, there is no free edition of this system – here we have the first major reason why it is so little known compared to Linux. It is a system dedicated to server applications and exclusively for IBM Power servers.

Does this mean that only AIX can run on IBM Power servers? No, because in addition to AIX, IBM Power servers can also run the “IBM i” system (formerly known as OS/400 and i5/OS), as well as… Linux systems, including RHEL, SLES, and even Ubuntu.

Many people might ask themselves: why use AIX if you can run Linux on these servers?

It is worth realizing that AIX has been created for Power servers from the start, so it is fully compatible with this hardware platform. The probability that an operating system and hardware from a single manufacturer will work best together is certainly much higher than in the case of a system developed by external companies or the community. The Power processor architecture is also associated with specific features (such as support for up to 8 threads per processor core) that are not found in the x86 architecture.

Is AIX always the best choice for IBM Power servers? No, because as always, everything depends on the specific use case. AIX will certainly be excellent for databases such as Oracle, Informix, or DB2, but OpenSource databases like PostgreSQL or MariaDB will likely have new versions released more frequently for Linux and enjoy greater community support. In many scenarios, it might be easier to migrate an application/database from the same Linux distribution on x86 to Linux on a Power server (e.g., RHEL 9.4 x86/ppc64le).

If you want to get to know the AIX system from a practical side, you need an IBM Power server or access to one in the cloud (e.g., PowerVS). Running it on a home laptop or a virtual machine in a home lab is unfortunately rather out of the question.

It is worth noting that both AIX and Linux on new Power servers will operate within virtual machines, most commonly known as LPARs (LPAR – Logical Partition) or Partitions.

Virtualization is an indispensable element of the Power platform, and a system running as Bare Metal is encountered very rarely, mostly for very specific applications. In the vast majority of cases, Linux or AIX on IBM Power will run as an isolated, virtualized part of the server, i.e., as a virtual machine.

IBM Power Architecture

While Linux systems can be run on various processor architectures (not only x86, but also on Power using the ppc64le architecture), AIX was designed specifically for servers with IBM POWER processors. Officially, there is no support for running it on x86 architecture (although some enthusiasts have managed to run it on x86 using QEMU with ppc64 emulation as a curiosity).

For more context regarding Power servers themselves and PowerVM virtualization, I refer you to my other publication: https://www.linkedin.com/pulse/discover-power-ibm-powervm-virtualization-michal-wiktorek-sagtf

A significant difference is that new versions of distributions such as Red Hat Enterprise Linux or SUSE Linux Enterprise Server are primarily released for the ppc64le architecture. In the past, they were also released for ppc64 (Big Endian), but this is now a rarity. New Linux versions are released primarily for ppc64le, although Debian uses the name ppc64el.

What is the difference between ppc64le and ppc64?

In short, ppc64 is the Big Endian standard, while ppc64le is Little Endian (used in x86 architecture); this refers to the bit order (endianness). For details, I refer you to this page: https://www.ibm.com/support/pages/just-faqs-about-little-endian

IBM Power servers allow operation in both modes (since the Power8 generation). Interestingly, we do not have to decide on a specific mode for the entire physical machine or force one mode for all LPARs running on it. Big Endian and Little Endian can function independently across different LPARs, which is a unique feature of IBM Power servers; this is why these servers are referred to as bi-Endian.

Why isn’t there a single standard?

Big Endian has been present in IBM Power servers from the beginning, and support for Little Endian mode is, in my opinion, actually a nod from IBM to customers who want to migrate or integrate systems from x86 to Power servers. Thanks to this, bit order conversion is not required, for example, when importing databases.

Commands, POSIX Compliance, and Shell

The POSIX standard was created as an initiative to unify operating system interfaces in order to ensure software portability between different platforms. The creation of POSIX was a response to the so-called “Unix wars,” when various manufacturers introduced their own, mutually incompatible versions of systems, which made life difficult for developers.

Although Linux is not Unix, it is partially compliant with the POSIX standard. This means, among other things, that many shell commands will work on both Unix systems (including AIX) and Linux. For examples of such commands, I refer you to Wikipedia: https://en.wikipedia.org/wiki/List_of_POSIX_commands

In practice, this means that a person proficient in Linux, upon logging into AIX for the first time, will be able to execute many basic commands, e.g., those related to file operations such as cat, ls, cd, cp, mv, rm, chmod, chown, and many others. However, it is worth noting that these commands will not always work identically. For example, although the grep command belongs to the POSIX standard, most Linux distributions use its “GNU grep” variation; consequently, there are differences regarding, for instance, command parameters. The situation is similar with AWK, because Linux uses GNU AWK (gawk), and the awk command itself is usually just an alias or a link to gawk

Knowledge of Linux is certainly helpful when learning AIX, but it is worth being careful and not assuming that every command will work in the same way. sometimes this requires breaking old habits. Linux commands often feature the -h parameter (meaning “human-readable”), e.g., du -h or df -h. In AIX, parameters for these commands will not work; instead, it is necessary to specify the parameter reflecting the unit, e.g., du -m / du -g or df -m / df -g (in megabytes/gigabytes, respectively).

Learning a new system is a bit like learning a new language – on the one hand, similarities help, but on the other, misunderstandings can easily occur when one assumes that a word means the same thing in both languages (like the word pants in American vs. British English :).

For example, halt on Linux should stop the system gracefully, but on AIX, this command acts brutally, much like unplugging the server from the power source. The same applies to the reboot command.

Jeśli potrzebujesz zatrzymać system AIX w „ładny” sposób użyj polecenia shutdown -F lub shutdown -Fr do restartu.

If you need to stop the AIX system in a “nice” way, use the shutdown -F command, or shutdown -Fr for a restart.

What might be discouraging upon the first encounter with AIX is the ksh shell (Korn Shell). It is generally considered that Korn Shell is more efficient than bash, but it is also less popular, and for Linux administrators, using it might be problematic, especially at the beginning.

If you cannot live without bash, you can use it as your shell. Since AIX version 7.3, bash is included with the system, and for older versions, it can be installed from the AIX Toolbox for Open Source Software repository. However, keep in mind that ksh has the greatest compatibility with AIX, and I definitely recommend writing scripts in ksh if you want to be sure they will work correctly.

To use ksh more comfortably, I recommend using the command:

set -o vi

This will allow you to interact with the shell using vi commands (including searching for previous commands and move position using the h/j/k/l keys, just like arrows in bash), and file path completion (instead of the Tab key) can be performed using ESC+\

If you do not know how to use the Vi editor yet, I definitely recommend learning the basics, simply because it should be standard on the vast majority of Unix/Linux systems – so it is beneficial to know an editor that is universally available across many operating systems.

It is worth noting that on Linux, the vi command is often actually an alias or symbolic link to the vim command, but they are not the same editor.

Open Source Software

I have already mentioned that on Linux, tools like grep, awk, sed, etc., are used in their GNU versions. Does this mean that on AIX you are restricted only to these POSIX-compliant tools?

Fortunately, no. These tools, along with many, many other useful utilities frequently used on Linux (including ncdu, mc, netperf, tmux, screen), can be installed from the AIX Toolbox for Open Source Software repository. You can check the list of packages on the repository page:

https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads-alpha

Although the standard software package format for AIX is the Fileset (which will be discussed more in the next article of this series), Open Source packages come in the RPM format (.rpm), known from distributions like Fedora, RHEL, CentOS, and SLES.

It is best to perform the installation and management of RPM packages on AIX using the dnf tool, just as you would in RHEL, Fedora, etc.

dnf install ncdu

Packages are installed in the /opt/freeeware location, so we do not have to worry that, for example, gawk will overwrite the original /usr/bin/awk.

It is worth noting that the AIX Toolbox for Open Source repository contains not only utilities but also databases such as MariaDB or PostgreSQL, as well as programming environments like Python, Ruby, Rust, etc.

SMIT

When writing about AIX, it is impossible not to mention SMIT (System Management Interface Tool) – an interactive tool that allows you to perform many tasks related to AIX system configuration. It is particularly useful for beginner administrators, but it is also used by advanced users.

Using SMIT helps avoid errors such as typos, allows you to perform actions without knowing the specific command, and is also very convenient. From within SMIT, you can perform a multitude of tasks related to operating system management and maintenance by selecting the appropriate menus, submenus, and list items using the keyboard arrows.

For those who have administered SUSE Enterprise Linux Server, it might remind them of the YaST tool.

An extremely useful feature in SMIT is the ability to preview the command for the current action in a given submenu using the ESC+6 (or F6) key combination. This allows you to verify exactly what will be executed or learn how to perform the task via the CLI.

The tool can be launched by executing the smit or smitty command, but you can also access the appropriate menu using a shortcut (fast path). For example, use smit lvm to go directly to LVM settings, or smitty chvg to proceed to Volume Group modification.

That is the end of part one 🙂

In the upcoming articles of this series, I plan to cover, among other things, the differences in working with devices, LVM, ODM, software package management, the bootloader and maintenance mode, as well as system security tools and DevOps.