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

Prerequisites: xdg-utils

When clicking a magnet link, the Chrome (or Chromium) browser will launch an external application to handle the link (remember it’s a URI, hence the external protocol request message). Anyhow, if your system doesn’t have an application associated with magnet links, then the result will be no action at all.

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 message in question as shown below made its appearance while I was trying to shut down my laptop. The job went on for about a minute before completing its task.

Recently, I became aware that Apache’s access and error_log on a BlueOnyx 5107R server were both zero byte files. Restarting Apache to correct the issue resulted in the following error message:

(98) Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

Dump MySQL rdbms … mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’ bytes when dumping table ‘article_plain’ at row: 8704 … failed

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.