_h5ai on ‎LiteSpeed Web Server

To get rid of “Javascript disabled error” when running _h5ai on LSWS, you’ve got to edit the following file:


Jump to line 72:


As you can already tell I’ve commented out the following line:

define("APP_HREF", Util::normalize_path(dirname(dirname(dirname($script_name))), true));

You’ve got to do the same, else it won’t work on LSWS. Alas, replace the above line with the following entry:

define("APP_HREF", "/_h5ai/");
Update 17.02.2017

The most recent fix for using _h5ai on LiteSpeed has changed just slightly. You need to edit the following file (line 98):


Commenting out the following line:

$this->set('H5AI_HREF', Util::normalize_path(dirname(dirname($script_name)), true));

Replace it with the following code:

$this->set('H5AI_HREF', "/_h5ai/");

This should result in a working, or at least operable, copy of _h5ai.

A few example sites of mine running _h5ai:


An update on the ‘subrosa situation’

Hi friends,

As most of you know by now the entire network hosted by subrosa is dead due to the following reason:

Now you know why you cannot reach it. At any rate: some of the people in our group say they had trouble getting on the self-hosted version that is maintained by myself, so I made a few changes to make the whole process simpler.

I explain it all in the below video. If you look in the description you will find the relevant information. However, one needn’t change anything. The old URL is still the same. All that you must do is create a new account as my server has no affiliation with the one/s run by the subrosa developers.

If you have any have issues, let me know and I’ll help you out as best I can.

Update: 27 April 2015

The subrosa.io network is apparently online again. I logged in to their network and it’s all normal, so it appears as if they “only” forgot to renew their domain. Whatever. We will be using my network from this point on anyway

Update: 1 May 2016

I am not using subrosa anymore. The project died. I have deployed an entirely new platform which is available only by invitation.
If you would like an invite, send an e-mail to this address: invite@60ych.net.


Locking Down WordPress WP-Admin

I’m pretty sure every WordPress [1] user out there has read much about different ways to limit access to the WordPress administration back-end (WP-Admin), and many of them are certainly good. My way is quite simple, although it most likely has a couple of penalties and some pitfalls I’m not yet aware of, but I can live with it.

My procedure of locking down the WP-Admin area consists of running Nginx [2] on a dedicated port (whichever port you prefer) bound to a internal/private/local IP address (i.e, et cetera), configured with PHP-FPM, coupled with Apache2 as the front-end (with mod_proxy [3] enabled) to serve and process all requests to the WordPress administrative back-end. The requests are proxied to the Nginx instance via Apache. This configuration effectively translates to the following: I only keep Nginx running whenever I access the administration back-end of WordPress (WP-Admin), and when I’m done, I simply shutdown Nginx. Simple. The end result is that nobody will be able to access the WP-Admin area if Nginx isn’t running.

The only issues I have run into so far is that static resources are not being served properly, but that should be easy a fix. I’m looking into it.

Try accessing the WP-Admin area of k0nsl.org and see the result:


Everything in “/blog/wp-admin” results in a 503 ‘Service Temporarily Unavailable’ (check the headers with “curl -I https://k0nsl.org/wp-admin”) because Nginx is shutdown. It certainly is a simple solution; but it works

This configuration above coupled with various other tweaks (such as the CloudFlare-Country-Login [4]) makes WordPress a bit more secure to use.

Update: 11.21.13

I solved the assets issue not being served properly JS too; Earlier, I had accidentally forgot to enable Javascript concatenation by commenting out CONCATENATE_SCRIPTS define in wp-config.php. Everything works perfectly right now.


1. WordPress: Blog Tool, Publishing Platform, and CMS -> http://wordpress.org/
2. Nginx: The High Performance Reverse Proxy, Load Balancer, Edge Cache, Origin Server -> http://nginx.com/products/
3. Apache Module mod_proxy -> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
4. WordPress: CloudFlare-Country-Login -> https://k0nsl.org/blog/wordpress-cloudflare-country-login/


Hide Google+ Goobly Gook from WP-Jetpack

I was annoyed with the injection of my Google+ details beneath every post when I activated the ‘Google+ Profile’ option in the WordPress plugin Jetpack [1] and couldn’t find any option to actually hide it entirely or change it’s placement. So I hacked it away, effectively hiding it, using a simple divider.
Like so:
You will want to jump to line 189 [2] in the file ‘gplus-authorship.php’ located in a subfolder of Jetpack (in effect: modules).
I do know it is possible to toggle it with the option ‘Show Google+ infomation with this post’. Perhaps the best practice would be to just remove the entire code block. Probably.
The authorship relation tag is not affected by this.

Here’s a gist of it:

$output = '';
$output .= '<div style="display:none" id="k0nsl">';
$output .= '<div class="sharedaddy sd-block sd-social sd-gplus">';
$output .= '<h3 class="sd-title">' . __( 'Google+', 'jetpack' ) . '</h3>';
$output .= '<div class="sd-content">';
$output .= $this->byline( $post );
$output .= $this->follow_button( $post );
$output .= '</div>';
$output .= '</div>';
$output .= '</div>';


1. Jetpack by WordPress.com http://wordpress.org/plugins/jetpack/
2. Exact position in pico: 189/209 (90%), col 1/30 (3%), char 6562/7082 (92%)


Speaking of WHMCS..

There has been a lot of talk recently about a failed ‘all-in-one client management, billing & support solution’ called WHMCS. In any case, I discovered something to my colossal surprise the other day too:
[NOTE: I did notify the provider in question about this apparent fault, of course.]


Fedora 18 “Spherical Cow” Released

Fedora 18 Fedora 18

Fedora 18 has finally been released and here are the highlights:

The firewall daemon firewalld will be the default firewall solution for Fedora 18, replacing system-config-firewall. Using firewalld will allow for application of policy changes without reloading, allowing connection states to stay unbroken when rules are changed.

UEFI Secure Boot will be supported in Fedora 18. This will allow Fedora to boot on systems that have Secure Boot enabled. Tools are available for administrators to create custom certificates to sign local changes to GRUB or the kernel.

Fedora 18 adds FedFS, a mechanism to provide a coherent namespace across multiple file servers.

Fedora 18 includes Samba4, which provides improved cross-platform file server support.

The X.org server has been rewritten to support ‘hot’ plugging and unplugging of GPUs. Specifically, this allows Fedora to provide better support for USB connected graphics devices exposed by many modern systems and laptop docking stations. The user is no longer required to restart the X.org server for such devices to be recognised.

And more…see:

You can download it via k0nsl.org, see:



This is my way of keeping out unwanted visitors from accessing my PimpMyLog [1] instance — using CloudFlare and ordinary nginx directives. A temporary solution as potsky is already working on a final solution [2].

map $http_cf_ipcountry $allow {
        default no;
        DK yes; # Set this to match your country (default is Denmark)

And to get it all working we add this in the server block:

location /LocationForPimpMyLog/ {
    log_not_found off; # I do not need this for PimpMyLog
    access_log off; # see above

    # Return 403 if GEO mismatch is found
    if ($allow = no) {
        return 403;

    allow; # Change this to your IP (or range)
    deny all;
    # the end

That’s it


1. PimpMyLog on GitHub
2. Anonymous access #76