BenV's notes

A while ago when faced ‘why is my disk slow’ I realized “hej, I have an SSD… let’s use it as cache!”.
Easier said than done, because these days you have tons of options. A quick glance at them shows BCache, DM-Cache, FaceBook’s Flash-Cache or what I went for which is based on Flash-Cache: EnhanceIO. There’s probably more of them, while writing this I ran into this article on LVM cache – sounds interesting too.
Here’s a little comparison between a few of the above options: different ssd to hdd cacheing options on askubuntu.com. (continue reading…)

This one has been on my todo list for a while, so today I took a stab at it: a fail2ban plugin for Check_MK.
My previous plugin (LMSensors plugin for Check_MK) still gets quite a few hits, so I figured you guys might like this one as well.

Why? Pretty graphs of course 😉
Another reason might be that you want to keep an eye on how many ssh bots etc fail2ban keeps out. (continue reading…)

Just ran into this one, noting it down for anyone else with this error:

Trying to compile Lua 5.2.3 (which should try to invest some in autoconf / cmake or something) gave me this lovely error:

make[2]: Entering directory `/usr/src/lua-5.2.3/src'
gcc -o lua lua.o liblua.a -lm -Wl,-E -ldl -lreadline
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tputs'
echo Stom product, Makefile editen, dan make MYLIBS="-lncurses" anders breekt ie op readline.
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tgoto'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tgetflag'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `UP'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tgetent'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tgetnum'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `PC'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `tgetstr'
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../lib64/libreadline.so: undefined reference to `BC'
collect2: error: ld returned 1 exit status
make[2]: *** [lua] Error 1
make[2]: Leaving directory `/usr/src/lua-5.2.3/src'
make[1]: *** [linux] Error 2
make[1]: Leaving directory `/usr/src/lua-5.2.3/src'
make: *** [linux] Error 2


Reason: it needs to link against ncursus in Slackware (or alternatively libtermcap, but ncursus worked for me).
Solution – use make MYLIBS=”-lncursus”:

make MYLIBS="-lncurses"
cd src && make linux
make[1]: Entering directory `/usr/src/lua-5.2.3/src'
make all SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl -lreadline"
make[2]: Entering directory `/usr/src/lua-5.2.3/src'
gcc -o lua lua.o liblua.a -lm -Wl,-E -ldl -lreadline -lncurses
gcc -o luac luac.o liblua.a -lm -Wl,-E -ldl -lreadline -lncurses
make[2]: Leaving directory `/usr/src/lua-5.2.3/src'
make[1]: Leaving directory `/usr/src/lua-5.2.3/src'


I just ran into something funny:

root@machine:~$ slackpkg update

root@machine:~$

Huh. I didn’t do anything weird with slackpkg….
Waaait a minute…

root@machine:~$ unset GREP_OPTIONS
root@machine:~$ slackpkg update
# Cut out the fetching of Changelog.txt
No changes in ChangeLog.txt between your last update and now.
Do you really want to download all other files (y/N)?

Apparently slackpkg breaks if you set GREP_OPTIONS to “–color=always”. Good to know for when I break it this way next time 😉

Yay, another new linux kernel. Of course this broke the closed NVidia driver, I tried 331.38:

[ 110.917769] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)

The fix for this is easy, unpack the installer and then patch file kernel/nv-acpi.c hack out line 306:

// NV_ACPI_OS_WAIT_EVENTS_COMPLETE();

Run nvidia-installer and you should be good to go. Incredible that it always takes NVidia forever to fix these things, this bug has been known since at least 3.13-rc1. Oh well.

Next up, testing nftables. Looks like iptables will soon be obsolete 🙂
Here’s a nice howto to get you started – https://home.regit.org/netfilter-en/nftables-quick-howto/.
Update:
Might you be wondering (like me) where the heck the libnftables git repository went: they decided to rename the thing to libnftnl. You can find the repository here – https://git.netfilter.org/libnftnl/

Another thing: compiling nftables from git breaks on my Slackware64-current machine atm because 1. configure.ac still points to libnftables (instead of libnftl), I assume this will be fixed within the hour. 2: it tries to compile against libreadline without linking libncurses.
Fix for that is running configure like: LDFLAGS=-lncurses ./configure

So far I like what Valve has been doing with Steam on Linux. Obviously there’s always a lot to be improved, but they try and it works pretty well for me.
Since they don’t have a native 64 bit steam client yet and I don’t want to clobber my Slackware64 install with multilibs and other 32 bit garbage I still have my old 32 bit Slackware-current install mounted that I can chroot into and run 32 bit garbage.
Running steam for me looks a bit like:

benv@steammachine:~$ su -lc "chroot /slackware32"
Password: jemoeder
root@steammachine:~# su benv
benv@steammachine:~$ steam


A bit of a hassle but it works, and I need that 32 bit chroot for running windows garbage in wine32 anyway.

Lately I noticed a lot of games that have a linux version under Steam crashed. When running them a window pops up, disappears, and your last played date is set to “Today” in steam. Trying to run the game on the console shows something like this:

benv@steammachine:~/.local/share/Steam/SteamApps/common/Ittle Dew:0>./IttleDew.x86
Set current directory to /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew
Found path: /home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew.x86
Mono path[0] = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Managed'
Mono path[1] = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono'
Mono config path = '/home/benv/.local/share/Steam/SteamApps/common/Ittle Dew/IttleDew_Data/Mono/etc'
Aborted (core dumped)

The reason was simple, but took me a lot of digging through strace etc to figure out. (gdb didn’t help since the included libmono that caused this segmentation fault was obviously stripped). At some point the program tries to read from /sys/devices/, which failed since I hadn’t bothered to mount /sys in my chroot. My mistake. (note that I did bother to mount /dev to get gamepad support etc).

Strace output:
[pid 16978] openat(AT_FDCWD, "/sys/devices/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
segfault

Conclusion: make sure that Steam for Linux games have access to /sys/devices/ 😉

At work they’ve been busy changing the building a bit. In fact, lots of bits. This resulted in me having to indicate how and where they had to move the server rack to, and having to point out obvious facts such as that the cabling has to be redone.
So last week they moved the rack, fucked up the cabling and wondered why outgoing phonecalls didn’t work anymore (“because you put the line jack in the wrong port”) and why the printer didn’t work (“Because it doesn’t work on a telephone line, try connecting the network port next time”) etc.
Another casualty of this was the windows 2008 server. Scheduled to be replaced by a virtual machine soon(TM) along with the rest of the obsolete hardware in the rack, it decided it wouldn’t boot anymore after being shutdown. Fortunately giving it a new power supply helped it move along for another couple of days.
Today however, after another shutdown, it didn’t want to boot anymore again. Being sick of the old failing hardware I decided to move it temporarily to a new workstation for the CAD division until the new server is ready. The old hardware was a lousy Pentium 4 (3Ghz orso) with 8GB RAM, the temporary workstation is a HP Z420 with a quad core Xeon E5-1620 and 16GB of ECC. Quite an upgrade…. if only windows would agree.

The problem with changing hardware in windows is simple: It’ll BSOD on boot. Who cares about your business, you changed the hardware, so you’d better make some time to either reinstall windows (from backup if you’re lucky) or kick it hard enough to work on the new hardware. Microsoft has some details on fixing it here.
For me it fortunately would still boot in safe mode, where I could issue from an administrator command prompt:

BCDEDIT /set detecthal YES

After this it would reboot without a BSOD and I could get busy installing 23984732984723 drivers, obviously starting with an ethernet driver. (in 2013… still having to install ethernet drivers for run of the mill broadcom cards… pffrt.)
Oh well, at least I didn’t need a reinstall. YET.

Did I mention it wants to be reactivated? 😉

One of my older (stable, works like a train) database servers still on Slackware 11 — well, heavily modified Slackware 11 😉 — is running MariaDB 5.1.something. Because I was tinkering with mysql settings I decided ‘hej, let’s see if upgrading to the latest version is a fun project!’.
Well, it sure is 😉

First of all, the newer MySQL and therefore also MariaDB versions have dumped a perfectly fine autoconf system for Cancer Make aka CMake. Well, that’s just great. There’s no cmake in Slackware 11, so I figured to grab the latest slackware cmake sources and build it myself. No big deal, except in order to use the latest slackware sources you’ll need tar with xz support. Well, while we’re at it anyway might as well build them. So I headed over to the nearest slackware repository and built myself a new xz, tar, findutils and pkgtools using the slackware 14 build scripts (slightly helped/modified to handle the absense of xz in my old system). There, now back to cmake. (continue reading…)

If Opera continues living the way it does right now it’ll die within a few years. At least, that’s what I expect. Every new release there are more and more little nuisances. New features? Yeah, they have plenty of new garbage slowing the browser down.
Soon they’ll dump their rendering engine for Webkit. Who knows, it might even improve the browser, but then again… soon I might jump to Chrome or another piece of garbage.
I wonder why browser vendors have determined they all have to inject cancer into them. Must be contageous or something.

Anyhow, my Opera issue for today: Webfonts.
Ever seen a page rendered like this?

Opera with weird webfont

Those of you running Slackware 14 or current probably have noticed the move to the Apache httpd v2.4 already.
On my webservers I haven’t yet dared to upgrade from the stable 2.2 version, but I figured it might be a good time to test out an upgrade procedure.

Notable problems / changes

This new version of the Apache httpd brings a few things that you should really pay attention to before attempting to upgrade. Well, you could ignore it, but it would surprise me if you wouldn’t end up with a broken webserver 😉
So you might want to look into these things:

1. Configuration syntax changes
2. Handling the Pleuris-Hoeren-Paaltjes aka PHP disaster
3. Switching to the MPM-event module

Of course you’ve already done your homework and read upgrading to 2.4 from 2.2, right? 😉 (continue reading…)