Being the holiday and end of year season here in Rochester, things are wrapping up for the year so I figured I'd put out my December update now instead of next month. Consider it an early Xmas present - just watch out for Santa's bicycle gun! 😉

The Santa robot crashing Futurama's Xmas party

New Packages


cron has finally come to IBM i! cronie is a modern version of the cron daemon, used by the majority of Linux distributions and based off the original cron written by Paul Vixie.

To start cron, simply run crond from a user with *ALLOBJ authority — it'll fork off a process and keep itself running. From then on, the cron daemon will run the scheduled jobs at the appropriate time. Every minute, cron will look for updates to the config files: the main config at /QOpenSys/etc/crontab, files in /QOpenSys/etc/cron.d, and under configs in /QOpenSys/var/spool/cron.

cron stores its configuration in a custom format called a crontab. While this format was created specifically for cron, other cron-like tools sometime uses the same format too. An example looks like this:

# This is a crontab, which is a field based format
# Anything after the hash is a comment
# The first 5 fields are space separated:
# minute hour day_of_month month day_of_week
# Multiple values can be specified for each field using commas
# The last field is everything after the first 5 and is the
# command string to execute.
# Examples:
# run every day at 3 am
0 3 * * * bash -c 'echo hello!'

# run at 10:19 pm on the 1st and 15th day of the month as well
# as well as every Saturday
19 22 1,15 * 6 bash -c 'echo This is a convoluted schedule'

Wikipedia has further details on the format or check the documentation by running man 5 crontab if you have man-db installed 😁.

To be quite honest, I tend to forget the format for the time fields, especially the order of the "day of week" and "day of month" fields so I tend to use an online generator.

Users can create and edit their own crontabs with crontab -e. This will open the user's default editor (using $EDITOR or vi as a fallback if not set). Users can also edit other user's crontabs with crontab -e -u <user> so long as they have *USE authority to the target user profile. All jobs in user's crontabs will run under that user profile.

Cron supports both a deny list and allow list, with the allow list taking precedence. An empty /QOpenSys/etc/cron.deny is shipped with cron and system adminstrators may add users to this file to prevent them from editing their crontab (though the crontab will still run!). If an admin only wants to allow certain users to be able to create and edit their crontabs, they can create a /QOpenSys/etc/cron.allow.

In addition to specifically scheduled commands, admins may place scripts or symlinks to scripts in the /QOpenSys/etc/cron.hourly, /QOpenSys/etc/cron.daily, and /QOpenSys/etc/cron.monthly directories. These scripts will be executed by cron once per hour, day, or month as appropriate.


Ninja is a build tool, similar to Make: it generates a dependency graph from the given rules and determines what to build when something changes. The difference between Make and Ninja is that the Ninja file format is not meant to be written by humans, but generated by other build tools, such as CMake. In addition, Ninja defaults to automatically using all the available processors on your system, whereas Make requires you to specify the number you want to use with -jN.

The easiest way to try out Ninja is by building a project that uses CMake and specifying the Ninja build generator with the -G option, eg.

# Assuming there's a CMakeLists.txt in the current directory
mkdir build && cd build

cmake -G Ninja ..



minisign is a super simple tool for signing files. Currently if you want to sign a file on IBM i, you can use either OpenSSL or GPG, but neither is ideal.

GPG is kind of a behemoth - it can do lots of things, but it has quite a learning curve to get going and there's lots to criticize about it's very "stuck in the 90s" defaults, but it certainly can be used to securely sign and verify files.

OpenSSL also works and has all the same issues as anything using SSL has: managing your public key infrastructure. You also have to use the openssl command, which looks very much like it was designed the _IBM Way_™, what with its nearly 50 "commands" and various options for each of them. Trying to remember all the different options and switches is enough to drive one mad.

Instead, if all you want to do is sign files, a much easier tool is minisign. Minisign is inspired by (and mostly compatible with) OpenBSD's signify tool. It does one thing (sign/verify files) and supports only one crypto algorithm (ed25519) - it's almost impossible to mess things up!

Here's a simple example:

# create a keypair
minisign -G

# Sign a file, creating myfile.txt.minisig
minisign -S -m myfile.txt

# Verify the file
minisign -V -m myfile.txt -p

Compare to the equivalent using OpenSSL:

# Generate a keypair (using a 4096-bit RSA key)
openssl req -nodes -x509 -sha256 -newkey rsa:4096 -keyout signing.key -out signing.crt -days 365 -subj "/CN=signing"

# Sign the file
openssl dgst -sha256 -sign signing.key -out myfile.txt.sha256 myfile.txt

# Get the signer's public key from the certificate
openssl x509 -in signing.crt -pubkey -noout >

# Verify the file
openssl dgst -sha256 -verify -signature myfile.txt.sha256 myfile.txt


libzip is a library for reading, creating, and modifying Zip archives. It's primarily used on IBM i for the PHP zip extension. Beyond that, you may find some use with the zipcmp and zipmerge utilities in the libzip-tools subpackage.


pv "pipe viewer" is a tool for monitoring the progress of data flowing through a shell pipeline. You can insert it anywhere between two commands in the pipeline to view a progress bar, estimate of time to completion, transfer speed, etc.

$ pv -cN source < matplotlib-3.2.1.tar.gz |
  gzip -d | pv -cN gzip |
  xz | pv -cN xz > matplotlib-3.2.1.tar.xz
   source: 23.0MiB 0:00:18 [1.81MiB/s] [=========>       ] 59% ETA 0:00:12
     gzip: 46.4MiB 0:00:19 [2.37MiB/s] [           <=>                   ]
       xz: 20.3MiB 0:00:19 [1.85MiB/s] [           <=>                   ]


CUPS (Common Unix Printing System) is a printing system for Unix-like systems. CUPS traditionally includes both a print server, drivers for various printers, and libraries for interacting with it. At this time, we are only providing the main CUPS library (libcups), since it is needed by OpenJDK Java 11.

We are looking to explore further capabilities for integration in the future — perhaps a CUPS driver which can generate a spool file on an output queue or perhaps CUPS could read from an output queue and route the spool files to a remote printer? If that is something you'd be interested in, please let me know!

Package Updates


With the latest update to BASH, there are 3 new IBM i-specific BASH builtin functions: liblist, cl, and getjobid. These builtins function nearly identically to the liblist, system, and getjobid commands that exist in PASE and/or QSH. I have more details about these new builtin functions [here]({% link _posts/ %}).


ca-certificates will now generate a Curl-style certificate bundle at /QOpenSys/var/lib/ca-certificates/ca-bundle.pem. This may be useful for applications that need this style of CA trust store.


NOTE: This is mostly useful for rpm packagers.

rpm ships with a new "Build Root Policy" file brp-rm-libtool-control-files which will automatically run after just prior to the %files sections being packaged and removes any libtool .la files found. If you were in the habit of removing these files manually (as we do at IBM), you no longer need to do so.


Well, that's it for 2020. It's been quite a year and despite everything going on, the IBM i Open Source ecosystem has still managed to make great strides.

Of course we wouldn't have gotten nearly as much accomplished this year without the great team we have here at IBM. Thanks and mad props goes out to Abdirahim, Eric, Mark, Meng Xu, Naveen, Vasili, Jesse, and more for their amazing contributions this year.