Who would have thought, right? :-)

After installing my certificate from Let’s Encrypt last week I was immediately confronted with the fact that I had made the wrong choice in regard to key sizes. By using a 4096-bit private key I was relying too heavily on the RPi2’s CPU. This became abundantly clear as page load times were increased by 500 – 1000ms.

So you’re hosting your own WordPress blog on a Raspberry Pi 2 and want to join the HTTPS everywhere movement to ensure optimal privacy for your visitors. That’s great, but what kind of performance penalty can you expect as CPU intensive tasks are hardly a favorite with the RPi2. Is the extra computational cost of encrypting data and doing handshakes going to significantly slow down your site?

I had some issues today with the Akonadi server failing on my Slackware 14.1 box at the office, so I resorted to killing X for a quick revival. However, issuing startx only resulted in the following errors:

I woke up this morning to a mail informing me that WordPress had been upgraded to version 4.4.1. Shortly after I tried to access my blog to verify that everything had gone smoothly, but unfortunately my webserver showed no sign of life. Since I’ve previously had a few hard learned lessons with the RPi2, that made me a bit uneasy. A couple of hours later though, as I was reviewing my logs, the problem became pretty obvious:

Distrowatch had an interesting “feature story” on Void Linux last year that caught my attention. Though the review painted a rather bleak image of the distribution, it still came through as an original project with some exiting features.

So the “DELETE your logs” message hit my server last night and at first glance it does look like a HTTP DELETE request :-)

Some big news was revealed through the Slackware Current (pre-release) changelog today as the switch from udev to eudev was finally announced.

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.

So I wanted to split a 3840×1080 wallpaper in two halves for my dual monitor based KDE 4.10.5 setup. Obviously there are several applications that would do the job, but why bother when ImageMagick can do it with a one-liner. The “magick” is achieved by using a geometry argument:

Just for the record: collecting failed logins from Logwatch and feeding them to the firewall is by no means a viable strategy against brute force attacks or other intrusion attempts. There are better means to mitigate these kind of security concerns in real time.

The shadow.service unit reported that it had failed and threw the following error message: “user ‘colord’: directory ‘/var/lib/colord’ does not exist”. I had no recollection of housing such a user, but by issuing the command below there was hard proof (image to the right) that colord was indeed a homeless user on my system, and her home was supposed to have been /var/lib/colord.

Remember that old saying: if you don’t know the source, don’t click it? With all these new URL shortening services, that advice seems to have been thrown out the window. As a result, evildoers are embracing the technology to disguise their malware sites behind shortened URLs.

This is obviously effective as an URL like hxxps://goo.gl/3BSi65 would have a much easier time getting past your spamfilter than say something like hxxp://h4x0r.tld/inject.aspx

Excited by the prospect of hosting my blog on the new Raspberry Pi 2, I decided lately to wave goodbye to the local datacenter and unleash a Slackware Linux box into the wild (full story here).

Everything went (mostly) without a hitch until I wanted to get back in sync with the Slackware-current tree. After applying the available updates and issuing a reboot, the system seemed operational and nothing from the logs gave any indication of imminent failure.

Two weeks ago, I decided to move this blog from its old hosting and deploy it on a Raspberry Pi 2. The geek in me could no longer resist the urge to discover if a $35 worth computer could replace the need for commercial hosting. Besides, what a great opportunity to finally get my hands on Slackware’s official ARM port.

No additional software is required on a full Slackware 14.1 install.
Slackware 14.1 ships with KDE 4.10.5.

Instead of logging on to each of your external email accounts, you can retrieve all your accounts’ email messages directly from Zimbra. It’s one of those things you just expect to work with an enterprise ready solution like Zimbra.

What was supposed to be a quiet Saturday morning quickly turned into a couple of hours trying to mitigate an increasing strain on a  WordPress based site. After getting around 800 post requests per minute to the WordPress xmlrpc.php file, resources for the site in question was getting sparse.

I usually prefer VirtualBox for my non-commercial virtualization needs, but since I already had VMware Player 6.0.2 installed on a Windows 8.1 64-bit host I decided go with it for my Slackware Linux 64-bit guest.

I’ve not been doing any serious distro hopping since 2008 and figured it was about time to see if there is anything new under the sun. Enter Arch Linux, a highly touted and matured distribution with a development model and philosophy I can appreciate. Honestly though, writing a review of Arch is somewhat daft as each installation will depend upon your own choices and preferences.

I did a review of Slackware Linux 14.0 a year ago and I was unsure as to whether I should make another one or not. There is rarely much change from a user point of view between different Slackware releases, and I expected to end up ripping off most of my previous review. Speaking of which, for a more well rounded assessment of Slackware Linux, please check out the Slackware 14.0 review.