Keeping pihole up to date with Aria Automation Config

I’ve recently begun keeping components of my lab up to date using Aria Automation Config. I’ve scheduled a daily job to inventory Linux packages that need updated and a weekly task to update Linux VMs and reboot if necessary. Both of these tasks leave a paper trail showing what updates were made, so I can refer back to them if needed.

I recently was checking the pihole admin interface and noticed some text at the bottom of the page that said ‘Update available!’ This is an easy process to complete, just SSH into the appliance and run pihole -up. However, since I’m keeping other systems up to date automatically, I wanted to add this service into the mix.

I debated on whether or not I should tack this process on to the end of the current OS update state file, or create a new state. I opted for option 2, but wrote the state in a way that it could run on any system and only run the commands if present. I created a new state file named /updates/pihole.sls with the following contents:

{%- if salt['file.file_exists']('/usr/local/bin/pihole') %}
    - name: /usr/local/bin/pihole updatePihole
{%- endif %}

This is a pretty basic state, it checks for the presence of the pihole script file, and if found, tries to run the updatePihole argument.

Before running the state on a test system, the footer looked like:

Pi-hole v5.17.2 FTL v5.23 Web Interface v5.20.2 · Update available!

The stdout of the minion return stated:
[i] Update local cache of available packages…\r\u001b[K [✓] Update local cache of available packages\n [i] Existing PHP installation detected : PHP version 7.3.31-1~deb10u5\n [i] Checking for git…\r\u001b[K [✓] Checking for git\n [i] Checking for iproute2…\r\u001b[K [✓] Checking for iproute2\n [i] Checking for dialog…\r\u001b[K [✓] Checking for dialog\n [i] Checking for ca-certificates…\r\u001b[K [✓] Checking for ca-certificates\n\n [i] Checking for updates…\n [i] Pi-hole Core:\tup to date\n [i] Web Interface:\tupdate available\n [i] FTL:\t\tup to date\n\n [i] Pi-hole Web Admin files out of date, updating local repo.\n [i] Check for existing repository in /var/www/html/admin…\r\u001b[K [✓] Check for existing repository in /var/www/html/admin\n [i] Update repo in /var/www/html/admin…HEAD is now at be05b0f v5.21 (#2860)\n\r\u001b[K [✓] Update repo in /var/www/html/admin\n\n [i] If you had made any changes in '/var/www/html/admin/', they have been stashed using 'git stash'\n [i] Local version file information updated.

After the state.apply operation completed, refreshing the web interface the footer changed to:

Pi-hole v5.17.2 FTL v5.23 Web Interface v5.21

We can see that the web interface was updated from v5.20.2 to v5.21.

I created a job to apply this state file, then created two schedules to stagger the patching to different minions on different days. This was a pretty quick solution to keeping the pihole software up to date on a schedule, using the centralized scheduling & reporting of Aria Automation Config.

This entry was posted in Lab Infrastructure, Scripting, Virtualization. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


Notify me of followup comments via e-mail. You can also subscribe without commenting.