Some big news was revealed through the Slackware Current (pre-release) changelog today as the switch from udev to eudev was finally announced.
And this is a big deal because?
udev, which is a device manager for the Linux kernel was absorbed into systemd back in 2012 with a notion of fully supporting systems not running systemd.
As a response to the merging of udev into systemd, the Gentoo eudev project (an udev fork) officially launched a few months later. Their goal was to provide better compatibility with existing software, older kernels, various toolchains and anything else required by users.
By switching to eudev Slackware seem to have landed firmly on the “right” side of the systemd fence. For the time being at least, the old proven Unix philosophy still lives strong in Slackware land.
As for the actual move to eudev, everything went without a hitch on my system and I’ve had zero issues after the upgrade. All in all, pretty smooth sailing in my opinion.
Anyhow, it’s advisable to pay close attention to the changelog as you need to install the new packages before upgrading.
I used the sequence below to perform the upgrade (you can skip step 2 and 4).
So the last report from my Slackware based RPi2 hosting project ended on a cliffhanger (pun intended), as I was just recovering after suffering data corruption, the occasional kernel panic and random errors. Suspecting the instability might be caused by my overly optimistic approach to overclocking and overvolting, I decided to turn things down a few notches.
Fast forward five months and my RPi2 is still hosting this website and that takes us well past the six months mark. There have been no further issues with stability or data corruption so I’m confident the initial rollercoaster ride was all due to my lack of competence. As a matter of fact, hosting WordPress on the RPi2 has been so much fun that I’ve shelved my plans on moving to a cloud based SSD VPS indefinitely.
Performance and expectations
What most people reading my RPi2 articles seem to be interested in (according to Google Search Console) is the string “raspberry pi 2 wordpress performance”, so lets talk about that part.
There are a few prominent blogs that promotes hosting WordPress on a Raspberry Pi 2 that also might seduce you to believe that they themselves are running their website on the RPi2. However, if you look at the IP address and investigate the HTTP-headers, you’ll most likely discover a cloud hosted SSD VPS.
Sadly, a WordPress installation running on a RPi2 will always render a page in seconds rather than milliseconds. To avoid getting burned for slow loading times you’ll have no choice but to implement WordPress caching, preferably by installing a third party plugin. The good news, however, is that by serving your visitors static files there will be no noticeable drop in performance when compared to a “real” server. For the record, it’s also advisable to use a lightweight theme and stick to essential plugins only. And yes, try to stay as far away from shortcodes as possible.
Web hosting from your apartment
Alright! we’re all cached up and the RPi2 is ready to conquer the interwebs, what could possibly go wrong? While moving your website from your old hosting provider and relaunching it on the RPi2 you might not be aware of the impending dangers that might befell a tasty raspberry suddenly surrounded by hungry predators. That might sound like a joke, but actually, you’re now running the single most attacked piece of software on the internet.
Bots will blindly scan your site looking for vulnerabilities, they’ll try to bruteforce your login credentials, they’ll fill your comment section with spam and flood your site with requests, all while digesting your remaining bandwidth. In the end these attacks will trigger a multitude of PHP requests, that in turn will create a high load on the RPi2 and services will eventually become unresponsive.
Setting up your server
Didn’t you mention something about fun a few paragraphs ago?
Sure, it’s both fun and viable to host your WordPress blog on the RPi2 but it should be done foremost with an eye on security. That way we’ll try our best to avoid being a part of the Internet of compromised things. Take notice that those bots you’ll soon have filling up your server logs didn’t start out life as part of some hackers toolbox.
Most distributions have excellent documentation on how to harden your server by reducing available attack vectors. I strongly recommend following the path of learning and manual configuration as apposed to using pre-built images running WordPress out of the box. Those images might be great for testing WordPress on the RPi2, but that doesn’t mean they’re meant to be deployed on the Internet.
No thanks, I know how this goes, save me the essay and give me the patch. Here you go: latest-firefox.patch
Ruari Oedegaard’s latest-firefox script is the preferred way of keeping Firefox up to date for many slackers. It has never failed me, until today. Looking at the error messages below, it’s clear that the script is not getting the expected return values and thus things fall apart.
./latest-firefox: line 73: [: 41.0.1: binary operator expected
./latest-firefox: line 162: [: firefox-41.0.1: binary operator expected
Navigating to the folder containing the latest Firefox release for linux-x86_64 at ftp.mozilla.org shows that two versions of Firefox are available. I’m guessing that is one more than usual as both 41.0.1 and 41.0.2 are listed as of October 22.
Type Name Size Last Modified
File firefox-41.0.1.tar.bz2 47M 14-Oct-2015 16:57
File firefox-41.0.2.tar.bz2 47M 20-Oct-2015 02:54
This creates a problem when the script is determining the latest Firefox version and applies that information to subsequent statements. We’ll notice the issue by running the following command from the script.
So we need to make sure only one Firefox version is returned and used by the script. This can be achieved by piping the output through another sed expression which strips everything except the last line.
wget -qO- http://ftp.mozilla.org/pub/firefox/releases/latest/linux-x86_64/en-US/ | sed -nr 's|.*>firefox-(.*)\.tar\.bz2.*|\1|p' | sed '$!d'
Download latest-firefox.patch to the folder containing Ruario’s latest-firefox script and apply the command:
patch < latest-firefox.patch
FYI, the patch doesn’t break the latest-firefox script even if only one tarball is available.