In my previous blog post I showed how to set up InfluxDB and Grafana (and Prometheus). This is how I configured my OpenWrt devices to provide monitoring and graphing of my network.
OpenWrt includes support for collectd (and even graphing inside Luci web interface) so we can leverage this and send our data across the network to the monitoring host.
Prometheus and InfluxDB are powerful time series database monitoring solutions, both of which are natively supported with graphing tool, Grafana.
Setting up these simple but powerful open source tools gives you a great base for monitoring and visualising your systems. We can use agents like node-exporter to publish metrics on remote hosts which Prometheus will scrape, and other tools like collectd which can send metrics to InfluxDB’s collectd listener (more on that later!).
I’m using CentOS 7 on a virtual machine, but this should be similar to other systems.
Read the rest of this entry »Work on Linux almost always means git for me, but the version provided by CentOS and RHEL is too old. Software collections is a convenient way to get a newer version and enable it for everyone by default.
First, enable software collections (different for RHEL and CentOS).
# CentOS sudo yum install centos-release-scl # RHEL sudo yum-config-manager --enable rhel-server-rhscl-7-rpms
Install the newer version of git you want (e.g. git 2.18).
sudo yum install rh-git218
Enable it for everyone for any new sessions.
cat << EOF | sudo tee /etc/profile.d/git-scl.sh source scl_source enable rh-git218 EOF
Test with a new session.
git --version $SHELL git --version
The Ansible Hardening role from the OpenStack project is a great way to secure Linux boxes in a reliable, repeatable and customisable manner.
It was created by former colleague of mine Major Hayden and while it was spun out of OpenStack, it can be applied generally to a number of the major Linux distros (including Fedora, RHEL, CentOS, Debian, SUSE).
The role is based on the Secure Technical Implementation Guide (STIG) out of the Unites States for RHEL, which provides recommendations on how best to secure a host and the services it runs (category one for highly sensitive systems, two for medium and three for low). This is similar to the Information Security Manual (ISM) we have in Australia, although the STIG is more explicit.
Read the rest of this entry »Quick and dirty guide to using Pi-hole with Stubby to provide both advertisement blocking and DNS over TLS. I’m using Fedora 30 ARM server edition on a Raspberry Pi 3.
Download Fedora Server ARM edition and write it to an SD card for the Raspberry Pi 3.
sudo fedora-arm-image-installer --resizefs --image=Fedora-Server-armhfp-30-1.2-sda.raw.xz --target=rpi3 --media=/dev/mmcblk0
Make sure your Raspberry Pi can already resolve DNS queries from some other source, such as your router or internet provider.
Read the rest of this entry »Home Assistant is a really great, open source home automation platform written in Python which supports hundreds of components. They have a containerised version called Hass.io which can run on a bunch of hardware and has a built-in marketplace to make the running of addons (like Let’s Encrypt) easy.
I’ve been running Home Assistant on a Raspberry Pi for a couple of years, but I want something that’s more poweful and where I have more control. Here’s how you can use the official Home Assistant containers on Fedora (note that this does not include their Hass.io marketplace).
First, install Fedora Server edition, which comes with the handy web UI for managing the system called Cockpit.
Once you’re up and running, install Docker and the Cockpit plugin.
sudo dnf install -y docker cockpit-docker
Now we can start and enable the Docker daemon and restart cockpit to load the Docker plugin.
Korora Project is a Linux distro I created over 13 years ago, which (since 2010) takes Fedora and applies dozens of tweaks in an effort to make it more usable “out of the box” for every day users.
Even with one or two others helping, it has been a lot of work so I’ve taken a break from the project for the last year to focus on other things. There has been no release of Korora since and so lately I’ve been running stock Fedora 29 Workstation (GNOME) on my laptop.
I enjoy the Korora defaults though and given that my family also runs Korora, I wanted a way to be able to move them to stock Fedora while keeping the same packages as well as the look and feel.
So, I created a Korora Ansible Role (it’s also on Ansible Galaxy) to apply the same Korora tweaks for stock Fedora Workstation (GNOME) plus an example playbook which uses it.
I tried to make it flexible by using variables so that users can change default package lists and settings for each machine, as required.
Running it on your local machine is pretty trivial, there’s a shell script with a sample inventory for localhost.
Hardkernel is a Korean company that makes various embedded ARM based systems, which it calls ODROID.
One of their products is the ODROID-HC1, a mini NAS designed to take a single 2.5″ SATA drive (HC stands for “Home Cloud”) which comes with 2GB RAM and a Gigabit Ethernet port. There is also a 3.5″ model called the HC2. Both of these are based on the ODROID-XU4, which itself is based on the previous iteration ODROID-XU3. All of these are based on the Samsung Exynos5422 SOC and should work with the following steps.
The Exynos SOC needs proprietary first stage bootloaders which are embedded in the first 1.4MB or so at the beginning of the SD card in order to load U-Boot. As these binary blobs are not re-distributable, Fedora cannot support these devices out of the box, however all the other bits are available including the kernel, device tree and U-Boot. So, we just need to piece it all together and the result is a stock Fedora system!
To do this you’ll need the ODROID device, a power supply (5V/4A for HC1, 12V/2A for HC2), one of their UART adapters, an SD card (UHS-I) and probably a hard drive if you want to use it as a NAS (you may also want a battery for the RTC and a case).
ODROID-HC1 with UART, RTC battery, SD card and 2.5″ drive.
Note that the default Fedora 27 ARM image does not support the Realtek RTL8153 Ethernet adapter out of the box (it does after a kernel upgrade) so if you don’t have a USB Ethernet dongle handy we’ll download the kernel packages on our host, save them to the SD card and install them on first boot. The Fedora 28 image works out of the box, so if you’re installing 28 you can skip that step.
Running Linux on your router and wifi devices is fantastic, but it’s important to keep them up-to-date. This is how I auto-update my devices with the latest packages from OpenWrt (but not firmware, I still do that manually when there’s a new release).
This is a very simple shell script which uses OpenWrt’s package manager to fetch a list of updates, and then install them, rebooting the machine if that was successful. The log file is served up over http, in case you want to get the log easily to see what’s been happening (assuming you’re running uhttpd service).
Make a directory to hold the script.
root@firewall:~# mkdir -p /usr/local/sbin
Make the script.
root@firewall:~# cat > /usr/local/sbin/update-system.sh << \EOF
#!/bin/ash
opkg update
# upgrade netifd first as it causes drop out and system upgrade fails
opkg upgrade netifd
# install luci-ssl, so we get web back after upgrades
opkg install luci-ssl
/etc/init.d/uhttpd restart
# do package upgrades
PACKAGES="$(opkg list-upgradable |awk '{print $1}')"
if [ -n "${PACKAGES}" ]; then
opkg upgrade ${PACKAGES}
if [ "$?" -eq 0 ]; then
echo "$(date -I"seconds") - update success, rebooting" \
>> /www/update.result
exec reboot
else
echo "$(date -I"seconds") - update failed" >> /www/update.result
fi
else
echo "$(date -I"seconds") - nothing to update" >> /www/update.result
fi
EOF
Make the script executable and touch the log file.
root@firewall:~# chmod u+x /usr/local/sbin/update-system.sh
root@firewall:~# touch /www/update.result
Make sure the script and results are kept when upgrading the firmware.
root@firewall:~# echo "/usr/local/sbin/" >> /etc/sysupgrade.conf
root@firewall:~# echo "/www/update.result" >> /etc/sysupgrade.conf
Next schedule the script in cron.
root@firewall:~# crontab -e
My cron entry looks like this, to run at 2am every day.
0 2 * * * /usr/local/sbin/update-system.sh
Now just start and enable cron.
root@firewall:~# /etc/init.d/cron start
root@firewall:~# /etc/init.d/cron enable
Give it a run manually, if you want.
root@firewall:~# /usr/local/sbin/update-system.sh
Download a copy of the log from another machine (once the router has finished rebooting).
chris@box:~$ curl http://router/update.result
2018-03-18T10:14:49+1100 - nothing to update
That’s it! Now if you have multiple devices you can do the same, but maybe just set the cron entry for a different time of the night.
Recently I wrote about creating an OpenStack Ironic deploy image with Buildroot. Doing this manually is good because it helps to understand how it’s pieced together, however it is slightly more involved.
The Ironic Python Agent (IPA) repo has some imagebuild scripts which make building the CoreOS and TinyCore images pretty trivial. I now have some patches which add support for creating the Buildroot images, too.
The patches consist of a few scripts which wrap the manual build method and a Makefile to tie it all together. Only the install-deps.sh script requires root privileges, if it detects missing dependencies, all other Buildroot tasks are run as a non-privileged user. It’s one of the great things about the Buildroot method!