Tag Archives: update

Auto-update Pi-hole with systemd timer

I have two Pi-hole servers at home running Fedora with DNS over TLS, both of which auto update on different days (to avoid having both down if something goes wrong).

First, create a script to get the latest updates if any are available, rebooting the Pi-hole if they were successful.

cat << \EOF | sudo tee /usr/local/sbin/update-pihole.sh
#!/bin/bash
PIHOLE_UPDATE="$(pihole -up --check-only)"
if ! grep -q 'Everything is up to date' <<< "${PIHOLE_UPDATE}" ; then
  pihole -up
  if [[ $? -eq 0 ]] ; then
    echo "$(date "+%h %d %T") update: success" >> /var/log/pihole.log
    reboot
  fi
else
    echo "$(date "+%h %d %T") update: nothing to do" >> /var/log/pihole.log
fi
EOF

Make the script executable.

sudo chmod a+x /usr/local/sbin/update-pihole.sh

Next, let’s create a systemd service for the update, which is required to be able to create a timer.

cat << EOF | sudo tee /etc/systemd/system/update-pihole.service 
[Unit]
Description=Update pihole
After=network-online.target
 
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/update-pihole.sh
EOF

Now we can create the systemd timer. Here I am updating weekly on Mondays at midnight (my other Pi-hole updates weekly on Thursdays), feel free to adjust as you see fit. If you have two, perhaps update on alternate days, like I do.

cat << EOF | sudo tee /etc/systemd/system/update-pihole.timer 
[Unit]
Description=Timer for updating pihole
Wants=network-online.target
 
[Timer]
OnBootSec=
OnCalendar=Mon *-*-* 00:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

Now that we have the timer, we can tell systemd about it and enable the timer.

sudo systemctl daemon-reload
sudo systemctl enable --now update-pihole.timer

That it’s it! Your systems will now check for updates and be rebooted if necessary. It might be good to pair this with some monitoring to ensure that your Pi-holes are working as expected and be alerted if otherwise…

Updating OpenStack TripleO Ceph nodes safely one at a time

Part of the process when updating Red Hat’s TripleO based OpenStack is to apply the package and container updates, viaupdate run step, to the nodes in each Role (like Controller, CephStorage and Compute, etc). This is done in-place, before the ceph-upgrade (ceph-ansible) step, converge step and reboots.

openstack overcloud update run --nodes CephStorage

Rather than do an entire Role straight up however, I always update one node of that type first. This lets me make sure there were no problems (and fix them if there were), before moving onto the whole Role.

I noticed recently when performing the update step on CephStorage role nodes that OSDs and OSD nodes were going down in the cluster. This was then causing my Ceph cluster to go into backfilling and recovering (norebalance was set).

We want all of these nodes to be done one at a time, as taking more than one node out at a time can potentially make the Ceph cluster stop serving data (all VMs will freeze) until it finishes and gets the minimum number of copies in the cluster. If all three copies of data go offline at the same time, it’s not going to be able to recover.

Continue reading

Automatically updating containers with Docker

Running something in a container using Docker or Podman is cool, but maybe you want an automated way to always run the latest container? Using the :latest tag alone does not to this, that just pulls the latest container at the time. You could have a cronjob that just always pulls the latest containers and restarts the container but then if there’s no update you have an outage for no reason.

It’s not too hard to write a script to pull the latest container and restart the service only if required, then tie that together with a systemd timer.

To restart a container you need to know how it was started. If you have only one container then you could just hard-code it, however it gets more tricky to manage if you have a number of containers. This is where something like runlike can help!

Continue reading

Fix problem updating packages in Fedora/Korora due to broken SELinux update

Unfortunately an update to the SELinux policy package in Fedora 20 (and therefore Korora 20) caused RPM scriptlets to fail when updating packages.

This bug only affects systems that have SELinux mode set to enforcing (which is the default) and were updated to version 3.12.1-116 of the selinux-policy package. If you have seen the following sort of error when updating packages, then this bug may affect you:

warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64

Below are the commands to resolve this issue (which has been fixed in an updated 3.12.1-117 version of selinux-policy).

sudo setenforce 0
sudo yum clean expire-cache
sudo yum update selinux-policy\*
sudo setenforce 1

The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum cache and install the SELinux policy update which fixes this issue. The last command re-enables SELinux enforcement.

If you previously installed any packages which failed with scriptlet errors like above, you can reinstall them using the following command:

sudo yum reinstall

You can find out what packages were installed after the broken update using a command like this:

sudo sed '1,/selinux-policy-3.12.1-116/d' /var/log/yum.log

If you require any assistance please don’t hesitate to ask for help using Engage or jump onto the #korora channel in IRC freenode.net servers.

Karmic upgrade, broken printing. Workaround.

So on another machine (my Dad’s to be exact) after an upgrade to Karmic, both sound and printing were broken.

I fixed the printing issue last night, which was truly strange. The original printer was still there (as I would expect) and could be seen in the GNOME print manager. The problem was that it just wouldn’t print at all. Taking a closer look, for some reason the driver had been reset to “Alps MD-1000” even though it’s a Samsung.

Broken printer

Changing the driver to anything else and saving the changes did not actually change the driver – it went straight back to “Alps MD-1000.” Adding a new printer resulted in the same problem.

The fix was to log into the CUPS server directly (http://localhost:631) and from here I was able to select the right driver – and it stuck. It could now print correctly.

Going back to the GNOME print manager still shows the driver as being the “Alps MD-1000” which is just wrong.

So I’m not sure why GNOME print manager is broken, but if I configure the printer directly with CUPS it works.

Security, ahh, update?

This morning I turned on my openSUSE work machine and was greeted (as I often am) with a message to update the system.

Today’s message was special however, and perhaps one for The Daily WTF.

I wonder whether “Do not warn me again” means

Don’t tell me when there’s a non-existent update again

Still, it seemed pretty important so I did it straight away!

It’s good to know that I’m protected from security threats so real, they cannot be named 🙂

P.S. If you’re wondering what awesome icon set I’m using, it’s Oxy-GNOME.