U-PATCH -- A mechanism for distributing patches in Ubuntu

In my job, I manage a number of Ubuntu Linux systems that are networked. Most of these systems are desktop systems, intended to be used by faculty. Some systems are in offices and others in classrooms. As you can imagine, there are times when changes to these systems need to be made. I don't have an Ubuntu for Enterprise subscription and the enterprise-wide support and management tools that come with it, so I often find myself creating my own management tools. In this post, I'll be covering one such tool that I've created, and I'll be sharing the code that I've written. I've dubbed this tool Ur Patches Applied To Computers Herewith, or U-PATCH for short.

U-PATCH

So what does one do when managing multiple Ubuntu Linux systems on a single network with the need to be able to install new software, remove old software, change settings, or perform general maintenance on all of these systems? One option is to visit each system one-by-one, in person or over the network, but that gets to be time consuming when there are more than a few systems to update. The better option is to create a system to host patches that are, in turn, pulled by clients and installed automatically. This is precisely what I have done. My patch distribution system has seen a couple of rewrites over the years, but I'm fairly happy with the way it currently operates.

Before I get too far, all of the code, which is composed of a few Bash scripts and one PHP file, is available on my GitHub page. There I've laid out all of the files needed to get this up and running. The README.md file on this page provides a fairly detailed explanation of how everything works. I'll keep it a little more concise here.

Basically, U-PATCH is made up of a server component and a client component. The server component is installed on a single machine. Patches, which are just Bash scripts themselves (plus any additional required files), perform desired changes are created and packaged on the server. Any clients that have been configured to point to the U-PATCH server will check for new patches every so often. If new patches are found, they are pulled down and installed.

System Requirements

There's not much to this on the client side. Aside from my scripts, there is no need to install any extra software that's not already shipped with Ubuntu by default. On the server side, PHP and Apache2 are used to create a public listing of patches and make them available for download. The server-setup.sh script handles the installation and configuration of these applications.

All coding and testing took place in Ubuntu 16.04.3. I cannot say for certain whether or not additional modification would be needed for other releases.

Security

Of course, if clients are going to automate the running of scripts to make what could be system changes, these scripts are going to need to run as root on the clients. At this point, you should pause for reflection on the potential consequences. To ensure that only valid packages are run, I configured U-PATCH to use GnuPG. When patches are packaged for release, they are signed with a PGP key. The client systems should have ideally downloaded the public key at setup. Armed with the public key, clients only install patches after they have been checked for a valid signature. If there's no valid signature, the patch is skipped.

Packaged patches are hosted by a web server. All of the U-PATCH server scripts are hosted right along with this content. If the default settings are used when running the server-setup.sh script, then Apache2 will be configured to honor .htaccess files. By default, the server-setup.sh script will lock down all content so that only the patches and patch list page are accessible through the web interface.

Room for growth

U-PATCH is by no means the best that it could ever be. There is room for improvement. That being said, it does what I need it to for now. It's on GitHub for a reason. Pull it down. Play with it. Enhance it. There's plenty of room for growth.