Eclipse Luna 4.4 – Code Assist can’t render HTML on KDE4 Slackware Linux 14.1

Eclipse SDK
Version: Luna (4.4)
Build id: I20140606-1215
PHP Development Tools (PDT)

After upgrading my workstation to Slackware 14.1 with KDE 4.10.5 as my default desktop, I was left with some issues regrading my new Eclipse Luna installation. Notably the tooltip was unreadable with its black background color, and much worse, the code assist would not render any HTML whatsoever.

Eclipse 4.4 - Code Assist unable to render HTML
Eclipse 4.4 – Code Assist unable to render HTML

Fixing the dark tooltip background:

KDE4 Application Apperance
KDE4 – Application Apperance

After searching through most of Eclipse’s menus and settings, it became evident that the easiest solution would be to change the tooltip background color by using KDE’s application appearance setting. Navigate to “System Settings” => “Application Apperance” => “Colors” => “Colors” => “Color set: Tooltip” and pick a lighter background. There might be a more sophisticated way of doing this on a per-app basis but it evaded me.

Fixing  HTML rendering for the Code Assist:

Eclipse uses SWT which is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented. Further, the SWT Browser widget is used to display HTML documents. It is designed to provide a basic and portable API sufficient for essential HTML browsing and rendering on the platforms on which it is implemented. On a Linux system, this means GTK.

Since I used the SlackBuilds repository to install Eclipse with all dependencies I believed I had everything covered. However, after reading this information at the aforementioned SWT FAQ, I learned that Eclipse Luna (4.4) uses GTK 3 by default. Thus I needed to configure WebKitGTK+ with GTK3. The simple solution is to pick up webkitgtk3 from the SlackBuilds repository and install it alongside or instead of  webkitgtk.

Eclipse 4.4 with webkitgtk3 rendering HTML
Eclipse 4.4 with webkitgtk3 seen rendering HTML using an internal browser

As a simple PDT user with limited understanding of the inner workings of Eclipse, I got to admit I might start looking for a more simplistic IDE.  At least I’ll be hesitant to upgrade to any new major release.

WordPress xmlrpc.php – Brute Force Attacks

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.

Examining the Apache access log didn’t reveal much as Apache doesn’t log post requests per default as shown below.

www.domain.tld - - [16/Aug/2014:10:54:17 +0200] "POST /xmlrpc.php HTTP/1.1" 200 405 "-" "-"

Obviously having Apache logging all input data will get ugly fast, so I figured the best approach would be to edit the xmlrpc.php script to log all post data to a file for closer inspection.

Examining the payload below showed it contained a xml encoded call to the wp_getUsersBlogs( $args ) function.

<?xml version="1.0" encoding="iso-8859-1"?>

wp_getUsersBlogs takes two parameters, a username and a password and tries to authenticate the user. If the login attempt is successful the function will return an array containing the values ‘isAdmin’ – ‘url’ – ‘blogid’ – ‘blogName’ – ‘xmlrpc’. In short, this will tell the attacker that the account was successfully compromised.

I thought a good solution to mitigate the attack would be to deny access to the xmlrpc.php file with a .htaccess directive as shown below, but alas the attacker did not care much about my response codes.

<Files xmlrpc.php>
        Order Deny,Allow
        Deny from all

To put an end to the suffering, I decided to log every request to this particular xmlrpc.php file for a period of 20 minutes. After removing dupes and friendly bots from the list, I was left with a collection just short of 1500 IP addresses. Feeding those IP’s to the firewall quickly convinced the attacker to move on to the next target and subsequently let me get back to the bloodthirsty world of Joe Abercrombie.

I’ve later done a bit of googling on the subject, and I’m now aware that these brute force attacks on xmlrpc.php are well known. Anyhow, if you have no need for the XMLRPC server implementation then you might want to consider disabling XML-RPC altogether.

If you’re managing your own server though, then Fail2ban would be an excellent tool for killing off these kinds of brute force attacks.

I have attached the IP’s of this rather small but persistent botnet for “educational” purposes: XML-RPC-botlist

VMware Player – How to install VMware Tools on a Slackware Linux guest

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.

Installing VMware Tools with VMware Player
The VMware Tools installer failing to load the CD image.

To get any kind of performance and functionality on the guest system, it’s necessary to install VMware Tools. This should in theory be as easy as navigating to “Manage” => “Install VMware Tools…” from the Player menu, but in my case this got me nowhere. The expected result was having the guest operating system mounting the VMware Tools installation CD, but that just didn’t work.
After reading through the vmware.log the problem became pretty obvious.

2014-06-22T17:30:43.945+02:00| vmx| I120: TOOLS INSTALL entering BEGINNING state.
2014-06-22T17:30:43.945+02:00| vmx| I120: TOOLS INSTALL 'C:\Program Files (x86)\VMware\VMware Player\linux.iso' not present or not readable
2014-06-22T17:30:43.945+02:00| vmx| I120: TOOLS INSTALL Initialization failed.
2014-06-22T17:30:43.945+02:00| vmx| I120: TOOLS INSTALL entering IDLE state. 

For some reason my VMware Player installation was missing the linux.iso which contains the actual VMware Tools. I have no idea if this is a bug or just a calculated oversight on VMware’s behalf, but either way it’s rather annoying.

After some digging around I found the packages I needed at Be aware that the packages are organized by Player version and build number, so make sure you pick whatever matches your installation.

As of June 22, 2014, 6.0.2/1744117 is the latest version of VMware Tools:

Download the file named tools-linux-9.6.2.exe.tar and extract the archive. Subsequently run the tools-linux-9.6.2.exe file. This will create the linux.iso containing the VMware tools in your VMware Player installation folder.

With the linux.iso image in place, the “Install VMware Tools” procedure will now work as expected by auto mounting the CD image.

The following commands are for installing VMware Tools on Slackware Linux 14.1 64-bit. The installation require a working build environment, which you’ll have with a full Slackware installation.

cd /media/VMware\ Tools/
tar zxf VMwareTools-9.6.2-1688356.tar.gz -C /tmp/

# change to root, create the expected pam directory and execute the installer
su -
mkdir /etc/pam.d
cd /tmp/vmware-tools-distrib

With a Slackware guest you’ll do fine with the default options as suggested by the installer. When the installation completes, log out and restart X and you’re done.

The screenshots below show Slackware booting with VMware tools installed, and using the unity mode which allow guest applications on the host system desktop.