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).
While installing some apps and extensions from the Chrome web store I noticed that there were a few well known products delivered by developers totally unknown to me (and Google search). LastPass, AVG AntiVirus, Snapchat, Viber and others were available sporting their trademark name and logo, but from publishers without any affiliation with the actual brand.
Blatant infringement aside, those were obviously fakes, but unfortunately scores of people are installing them as the publishers got the name and logo right. Further, I suspect many people believe that Google endorses the apps and extensions that ends up in the Crome web store. In reality though, as long as you pay your developer fee you may likely exploit the system to your hearts content.
Intrigued to learn more about their business model I installed a few of the rogue apps and extensions to discover what kind of scam they were pulling. Interestingly enough, it seems they are primarily abusing Google’s own ecosystem.
Here is your recipe for abusing Google services and having them pay you.
Identify a mainstream application with a large user base and steal their name and logo for use with your own app or extension. This will give you far better exposure and increase the number of user installations (protip: users put all their trust in names logos).
Download the Chrome app or extension example code (really, anybody can write an app in five minutes). Now pay attention to how you can open new browser tabs as that will be your key feature.
Register a bunch of domains with GoDaddy (fake identities only, they never check).
Sign up for Google AdSense. This will be the most demanding part of the process so be sure to make everything look legit (this is only to get approval, later on you’ll turn things around).
Now add Google AdSense to all your websites and finalize your app or extension by having it load those websites in new tabs upon installation. Pay your developer fee, upload your app, and publish it in the Chrome Web Store.
Relax and enjoy your new steady stream of ad revenue.
One would assume that it might be easy to remove the offending apps and extensions from the Chrome web store by using the “Report Abuse“ feature, but in reality it’s pointless as the developers will republish immediately after Google takes them down.
If you really want to make life hard for the scammers, the best cause of action would be make a list of the sites loaded by the rogue apps and report them to Google AdSense for policy violation.
You could of course save yourself the trouble altogether by never downloading apps and extensions from untrusted third parties.
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.