5 ways to track installed applications on Linux

Linux makes it easy to track software on servers and workstations. Package management has been part of Linux since very early in the operating system's life, and the toolset has been perfected over the decades. There's no reason that even a total system rebuild should require more than one quick Ansible playbook or shell script to return to its previous state.

Even though Linux has robust package management, new software for Linux is released all the time, and not all of it is integrated with the system's package manager. However, it doesn't take much beyond a little organization and consistency to ensure that even application outliers are well-accounted for.

[ Take a Linux infrastructure planning assessment. ]

Here are the five tactics I use to track applications installed on my fleet.

1. List packages with RPM

Do the easy one first. Red Hat Enterprise Linux (RHEL), CentOS, Fedora, and several others catalog all supported software as RPM packages, and the dnf command is usually the best interface to that manifest.

However, you can get a dump of all installed packages with just the rpm command:

$ rpm --query --all
publicsuffix-list-dafsa-20190417-4.noarch
ncurses-base-6.2-3.20200222.noarch
libssh-config-0.9.5-1.noarch
kbd-misc-2.3.0-2.noarch
[...]

That's a lot of information, and it's specific to the versions of packages installed on a system you might be planning to upgrade. I find its output even more useful when I look at the full package information coupled with a simple awk command to extract just the package name:

$ rpm --query --all --info | \
awk --field-separator ': ' '/^Name/ {print $2;}'
publicsuffix-list-dafsa
ncurses-base
libssh-config
kbd-misc
[...]

The advantage of getting a package name without the version is that you can pipe the whole list into dnf on an upgraded system, and dnf doesn't fail due to mismatched version numbers.

2. Flatpakrefs

The Flatpak system makes it trivial for even non-administrative users to install applications on workstations safely. It also makes it trivial to report what's installed:

$ flatpak list --app --columns=application | head -n-1
im.element.Element
io.github.Cockatrice.cockatrice
net.scribus.Scribus
org.audacityteam.Audacity
org.inkscape.Inkscape
org.kde.kdenlive
org.kde.krita
org.signal.Signal
org.synfig.SynfigStudio
[...]

This reports only on applications installed as Flatpaks, not runtimes. Installing an application as a Flatpak also installs its required runtime, so I don't bother to report installed runtimes.

Flatpaks are usually installed in the user environment, but with root privileges, they can also be installed on the system. If you're auditing what's been installed, keep that in mind.

Finally, Flatpaks might not all come from the same repository. When in doubt, you can see what Flatpak remotes were added to a system with the flatpak remotes command.

3. Outliers

Some vendors provide software for Linux as plain old tarballs, self-extracting scripts with embedded "install wizards" that unarchive the software's components to your chosen system location. Whether you use /usr/local or /opt or some other location, make sure to set a strict standard within your organization for the outlier location.

These outlier applications are the hardest to track, and it takes discipline. You must define a process for installing to /opt (or whatever place you use), and part of that process must be keeping a log. In my experience, many of the applications I end up installing to /opt are also applications that require a license, so I keep a copy of the tarball or installer in a central directory along with the licensing information. (But don't let that create a loophole where applications installed to /opt without licenses are never logged.)

4. SDKMAN and Maven and Pip and Node and Cargo

Many popular languages have package managers of their own. Luckily, these tend to restrict themselves to a user's environment. The best way to deal with language-specific package managers is for developers to actually use them. These tools are designed to be all the big words: programmatic, ephemeral, and idempotent.

Reinforce with your developers that their environments are meant to be easy to replicate. As long as their code is pushed to the organization's version control system, it should be self-migratory.

5. The stuff you almost forgot

I'm a testament to just how customized a home directory can become. There are scripts I've written and thrown into my personal ~/bin directory that I've sometimes forgotten weren't just default Linux commands. It can be genuinely difficult to separate actual Linux from your Linux, and that's one reason why people use Linux. You want it to be yours, and an organization often needs Linux to be uniquely crafted for its needs.

The key is to keep track of what's yours.

At some point, that useful script everyone's shared around the office isn't just a useful script; it's a product of the organization. Encourage its maintainer to give it a version number, commit it to Git, and package it up so it can be included in the upgrade process.

[ Learn best practices for implementing automation across your organization. Download The automation architect's handbook. ] 

Be aware

Tracking applications in your organization is often a matter of being aware of what's being used, whether it's an officially supported package or something surprisingly useful that an intern drummed up while accidentally learning Python one day. And knowing the right tools to get complete reports about applications on your systems is vital to any upgrade, recovery, or architectural planning.