I mentioned back in January that I’d taken a fresh look at OpenSUSE 42.1 and had been impressed.
I still am, although I’ve read all sorts of people complaining that the distro is unstable, or that its use of KDE 5 makes it unusable.
Not for me it hasn’t: in fact, I find KDE 5 its saving grace and it’s been pretty much rock-solid for the sorts of things I do with a Linux distro. It’s been good enough, in fact, for me to whip out the old Gparted live distro, shrink my Windows 10 partitions down to half their original size and to start dual-booting with a proper, physical OpenSUSE 42.1 installation. And I haven’t had to touch the Windows 10 installation in over a fortnight.
We shall see: Linux has broken my heart several times before now, but for the moment, it’s a whirlwind of wonderment. Or something. Sufficient to make re-partitioning the laptop too a plausible move.
Anyway: I got to wondering what the Linux replacement for Hyper-V would be (apart from the obvious VirtualBox and VMware candidates). My new article on using KVM with OpenSUSE is the result. On the whole, apart from one or two GUI glitches, it works a treat and feels “native” in the same way that Hyper-V does on Windows, which is a bonus.
If you start searching, you will find that quite a lot of people running WordPress have a strange habit of suddenly finding their GUI or ‘visual editor’ has stopped working. Usually, they can still type hand-crafted HTML, but the visual editor just appears blank, dead and useless.
And that happened to me just this week for no apparent reason, and so I did do that search …and found a bazillion suggestions, none of which worked. Most consisted of :
Try a different browser -I was merely able to confirm that the visual editor was broken in IE, Edge, Firefox and Chrome.
De-activate all plugins -I did that. Even deleted all plugins. I even renamed the plugin directory to plugin.old, so the WordPress dashboard declared I had no plugins at all installed. The visual editor remained broken and still complained about the inability to load two files from the tinymce advanced plugin directory.
Clear browser cache -I did so repeatedly. Everything was still broken.
By switching on the Firefox developer tools, I could see two ‘failed to load’ errors were happening right at the point where the TinyMCE GUI toolbar should get displayed. Naturally, I neglected to note down precisely what two files it couldn’t load, but they were along the lines of wordpress/wp-includes/js/tinymce/plugins/wpembed/plugin.min.js and wordpress/wp-includes/js/tinymce/plugins/wpgallery/plugin.min.js. Naturally, I verified that both of those files actually existed and had the correct permissions and ownership set… all was fine in that regard.
I think the most bizarre bit was the fact that the Firefox developer tools showed these two files failed to load even when every single plugin had been deleted. Something still wanted to load the tinymce advanced plugin scripts, even though nothing could possibly warrant it. A mystery, then.
Now I’ll back up a bit: I’m self-hosted and have been aware of a lot of attempts to log on to my server via SSH -mostly from China, so if you are responsible for server 126.96.36.199 (to pick just one of many), which is registered as belonging to Chinanet Jiangxi province network, No. 31 jingrong street Beijing 100032, please stop trying!
To combat this, I recently ramped up my fail2ban configuration: you attempt an SSH login now and fail 5 times in 10 minutes, and I ban your entire IP address from all contact with my server for 6 months. Previously, the rule was that you’d only be banned for an hour… and that meant people were constantly re-trying and the resulting flood of notifications about invalid ssh logins was driving me bonkers. By upping the ban time, it means that an IP address gets added to my routing table as being ‘denied all’ and stays there for a long time. Accordingly, the number of IP addresses in my firewall rules ballooned: when I last checked, some 134 IP addresses had been added to my list of banned IPs.
I also added the WP Fail2ban plugin to my site: this sets up IP blocks if someone repeatedly attempts to log into your WordPress installation as the administrator. I had about 15 of them turn up in the space of a week, too: the Internet can be a nasty place! But anyway: that’s another 15 IP addresses falling under the long-term ban-hammer.
And this afternoon, the penny dropped: about the only thing that had changed on my server from the time the WordPress Visual Editor worked to the time it stopped working was this explosion in the number of banned IP addresses thanks to my fail2ban re-configurations.
So I just did a service iptables stop and a swift service iptables start. That has the effect of wiping all previously-stored routing table rules -in other words, my list of banned IP addresses was wiped. And Lo! The Visual Editor started working once more (allowing me to type this, in fact).
I can’t begin to explain what’s going on here, but it’s very annoying. For starters, the errors saying that it couldn’t load the various tinymce java script files were displayed even though I’d deleted all plugins, and cleared my browser cache entirely. Why something would continue to reference a tinymce plugin directory/file when the entire plugin had been wiped, I have no idea -but it doesn’t sound like best practice to me!
Second, why would anything about the tinymce advanced plugin fail to work because some IP addresses were blocked by my firewall? What possible relationship is there between a visual editor toolbar and needing to try an ssh login to my webserver or to try a WordPress administrator’s log in? That doesn’t pass the sniff test with me.
But anyway: I’ll leave speculation about precisely what’s going on until the next time I encounter the problem and do my research a little more carefully. For now, all I can do is to add to the pile of suggestions that are made whenever this problem is asked about on the forums: switch your firewall off and on. It did the trick for me in an instant.
And when/if it happens again, I’ll take proper screenshots!
I am happily (and as regular readers will realise, somewhat miraculously) still running Windows 10 and its baked-in Hyper-V virtualization.
I wanted to build a Linux Mint 17.2 virtual machine the other day, however, and encountered a problem: whilst it all installed perfectly fine, it refused to display anything other than in 800×600 screen resolution.
Fortunately, there is a solution, but it’s not exactly lightweight!
(That’s all on the one line, no matter that it wraps here for formatting reasons). You can pick the specific screen resolution you want there, but beware setting it beyond 1920×1080, since that’s all the Hyper-V drivers support as far as I’m aware.
With that file edited and saved, you need to update Grub as follows:
sudo vi /etc/initramfs-tools/modules
To the existing list of modules (by default, there aren’t any except a couple of lines commented out mentioning raid1 and sd_mod), add the following on separate lines:
Save the file, then:
sudo update-initramfs –u
When your VM comes back on and you log in, you should see the screen resize to whatever screen resolution you typed in to start with.
Of course, faffing around like this on the Hyper-V manager slightly misses the point: the Hyper-V virtual machine connections are supposed to be for server administration purposes, not cutesy graphical-ness! At the command line, no-one can hear you scream that your desktop is only 800×600 🙂
So an alternative is to install something like NX onto the Linux Mint guest machine, install the NX client on your Windows desktop and do it all via NX.
But either way, I do now have a usable Linux Mint 17.2 KDE virtual machine that looks good!
This blog piece is by way of catching up on a couple of bits of past news.
First, we did eventually pick up the new car, a couple of days later than I’d hoped. The delay annoyed me a bit (wave enough wads of banknotes around and I tend to feel service levels should go up not down!), but say what you will about car salesmen, ours went the extra mile:
That’s him crouched behind the car in a white shirt, trying to hide, whilst pulling back the car cover in a fine attempt at a dramatic reveal! Nice of him to try. Just a shame I am such a crap photographer.
Anyway: the car is fun and its ability to steer itself round corners and stay between the lane lines on a motorway is uncanny. I also have far more confidence in its ability to automatically slow down to maintain a distance between it and the next car than I have in my own, so it feels an altogether safer ride -though again, when the car starts breaking and accelerating all by itself, it is a touch unnerving! Complete autonomous vehicles are not so very far away, I think.
Second: bluetooth headphones. The Sennheisers went back with not a squeak out of JB Hi-fi, for which I am grateful; and the replacement Bose’s have been a delight. They came in a nicer carry case; they are lighter; their ear cushions don’t pop-off every time you look at them; and most importantly perhaps, their sound quality is delightful. Where the Sennheisers had seemed a bit boomy, the Bose’s are exactly as I like my music reproduction hardware to be: completely neutral, no added bass and crystal clear. So they get a thumbs-up and a ringing endorsement from me. As do JB Hi-fi.
And third: my Oracle bug. This has now been confirmed to be a bug by Oracle Support (number 14458214, though I am not allowed to actually see it’s content), though it is unfixable in 188.8.131.52 (as I expected it would be, given that version is now out of extended support).
The bug mentioned has a patch available in 184.108.40.206 and doesn’t arise in 12c. For some reason, I was also pointed to bug 17258090, but I can’t see the contents of that bug report either. 😥
Possible workarounds in 220.127.116.11 is to do an alter session set “_subquery_pruning_enabled”=false; …though since X$KSPPI lists _subquery_pruning_enabled as a hidden parameter, I assume you can also set it instance-wide, though obviously the consequences for other queries at that point would need to be evaluated quite carefully. You can also, of course, set skip_unusable_indexes=false either at the session or system-wide level, though again the consequences of that at the system-wide level are pretty bad!
I actually had a developer encounter this bug again just last week and had him add the line:
execute immediate 'alter session set skip_unusable_indexes=false';
…into his PL/SQL package: it did the trick, but I am now slightly worried he’ll include that as “magic boilerplate” in every PL/SQL procedure he goes on to write in the future!
Other than that triple blast from the past, I am busy planning for one of my sisters to (finally!) visit me in Australia this coming August. It will be the first time any of my family have made the trans-global commute to see what I’ve made of myself in the past 20 years, so I am rather looking forward to it 🙂