BenV's notes

Slackware recently upgraded the MySQL version from 5.0 to 5.1, from the Changelog:

Sun Oct 4 00:17:50 CDT 2009
ap/mysql-5.1.39-x86_64-1.txz: Upgraded.
This bumps the version of the shared libraries to .so.16.0.0.

Yeah, that’s all great, but for me this broke on several of my machines. (continue reading…)

Now that we have Xenbro up and running with a domain attached to it and a bunch of toy domU’s running, we soon ran into the need for a dns server and mailer.
Needless to say I don’t like the default Sendmail and Bind junk very much (wonder why Slackware still ships it…), and my experiences with Exim and Postfix aren’t all too great either.
Sure, they work, but they’re too complex for my liking. I like to know what’s going on, so I still use my trusty old Qmail and Djbdns for mail and dns.
However, since those packages haven’t been updated in years, some newer features are missing. So I patch them 4 times over and stab them a bit so they work the way I like 😉 (continue reading…)

In order to get some disk and sensor stats I decided to recompile Net-SNMP on Xenbro. Since I did this before on my server at home (32 bit slackware-current) I figured it would be a breeze. Was I in for a surprise. Since I use quite a big configure string that slackbuild doesn’t handle yet I have it handy in a ‘bla’ file:

root@xenbro:/usr/src/net-snmp-5.5# cat bla
./configure --prefix=/usr --with-defaults --localstatedir=/var --sysconfdir=/etc --with-sys-contact="Jemoeder" --with-mib-modules="host disman/event-mib mibII/mta_sendmail smux ucd_snmp ucd-snmp/lmSensors ucd-snmp/diskio" --enable-shared --with-perl-modules="PREFIX=$PKG/usr INSTALLDIRS=vendor" --enable-embedded-perl --with-cflags="-O2" --with-libwrap --with-python-modules --with-ldflags=-lsensors --enable-ipv6 --disable-debugging --enable-static=no


However, when compiling like this both v5.5 and v5.4.2.1 of net-snmp gave me:

mkdir ucd-snmp/.libs
gcc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -O2 -Ulinux -Dlinux=linux -I/usr/include/rpm -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE -c ucd-snmp/lmSensors.c -fPIC -DPIC -o ucd-snmp/.libs/lmSensors.o
ucd-snmp/lmSensors.c: In function '_sensor_load':
ucd-snmp/lmSensors.c:943: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
ucd-snmp/lmSensors.c:943: error: 'data' undeclared (first use in this function)
ucd-snmp/lmSensors.c:943: error: (Each undeclared identifier is reported only once
ucd-snmp/lmSensors.c:943: error: for each function it appears in.)
ucd-snmp/lmSensors.c:964: warning: passing argument 1 of 'sensors_get_detected_chips' from incompatible pointer type
ucd-snmp/lmSensors.c:964: error: too few arguments to function 'sensors_get_detected_chips'
ucd-snmp/lmSensors.c:973: error: 'SENSORS_NO_MAPPING' undeclared (first use in this function)
ucd-snmp/lmSensors.c:974: error: incompatible type for argument 1 of 'sensors_get_label'
ucd-snmp/lmSensors.c:974: error: too many arguments to function 'sensors_get_label'
make[2]: *** [ucd-snmp/lmSensors.lo] Error 1
make[2]: Leaving directory `/usr/src/net-snmp-5.4.2.1/agent/mibgroup'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/net-snmp-5.4.2.1/agent'
make: *** [subdirs] Error 1

Google was as useless as ever (only 1 thread about this who solved it installing some ancient version of lmsensors or something), so I had to dick around to get this to work.
First I wondered what was different about my server at home and Xenbro. 32 vs 64 bits obviously, but otherwise… not that much.
So I tried upgrading libtool from version 1.5 to 2.2.6a. Recompile wasted another 5 minutes of my life.
Then I read something about ucd-snmp/lmSensors vs ucd-snmp/lmsensorsMib. I have no idea what this is supposed to do, but I’d be better of not having read about it. Both options won’t compile because of the same compilation error above.

Finally after hours of cursing I installed lm_sensors 2.10 to /usr/local and hinted net-snmp to compile using -L/usr/local/lib, doing that made it it compile. You just have to push it a bit when it breaks… (and yes, I found out some older lm_sensors stuff was still lingering around on that home server). It kinda went like this:

# cd net-snmp-5.5/
# bash bla
# make
# cd agent/
# vim Makefile # change LD_FLAGS to include -L/usr/local/lib
# make
# cd ..
# make
# vim apps/Makefile # same edit as above
# make

Amazing enough it even works now. You’d expect it to crash and barf all over the place…. or at least I did.

Now finally back to what I wanted to do: SENSOR GRAPHS in Cacti!!!
A pretty much excellent description on how to do this is here: Eric A. Hall’s on Cacti and lmsensor readings.
His steps summarized:

1. Get net-snmp to return sensor readings
2. Download Cacti-netsnmp-lmsensors.tar.gz which I mirrored here: [Download not found]
3. Untar, put files in right place, import templates in Cacti
4. Add data queries and graphs to hosts

For more details check out his page, it has a detailed explanation. Thanks for building it Eric!

Then there’s disk stats. Half the links on the forums are hard to find or dead, so I’ll just take my own downloads. Easier for the next time I need it 😉
This is the original thread for snmpdiskio with the templates in here. Then there’s a missing download for a copy/paste version of this post. I’ll save the copy/pasting for you, just leech it if you need it (only for when your net-snmp fails!):
[Download not found]
Finally there’s a script that fetches the stuff here. Put that script in resource/snmp_queries/partition.xml
Import the two templates from the snmpdiskio-v0.9.4 tarball.
Next add the new snmp query (“Get Device I/O”) to your device (Devices -> $yourdevice -> at bottom select it from the pulldown menu). Create graphs for this device -> have fun.

I was going to add some images, but I’m too tired now. Hope you can get it to work, good luck 🙂

Xenbro has found its way into the Coloclue racks where it is now running with real IP addresses. The Coloclue network routes all IP space to the main IP address of the machine so that precious IP addresses are not ‘lost’ to reserved network and broadcast addresses. This means that my /29 has 8 usable addresses in stead of only 6. In order to set this up you simply change the network-script and vif-script to the -route variants in /etc/xen/xend-config.sxp so it looks like this:

(network-script network-route)
(vif-script vif-route)

Easy. Make sure ip forwarding is enabled though (check /proc/sys/net/ipv4/ip_forward, it should be 1) , and for IPv6 forwarding you need to enable /proc/sys/net/ipv6/conf/all/forwarding. Note that you must enable it on the -all- directory, only enabling it on a single interface won’t do what you’d expect (this took me a while to figure out ;)).
After requesting both a set of IPv4 and IPv6 addresses I stumbled upon Xen’s /etc/xen/scripts/vif-route script which doesn’t do anything with IPv6! Since I do want my IPv6 space routed to my domU (and probably to the others as well) I decided to molest the script a little. My modification assumes you provide both the IPv4 address and IPv6 range you want to use on the domU. Here’s the diff:
[Download not found]
Note that my patch adds some extra logging as well, you can hack that out yourself if it annoys you.
If patching is too difficult for you, here’s the patched vif-route script:
[Download not found]

Don’t forget to put your IP addresses in your domU’s config file:

# domU.cfg
vif = [ 'mac=00:16:11:11:2b:11, ip=2345::1/64 192.168.2.100' ]


After patching vif-route and enabling the script in xend-config.sxp you still have to set routes to the dom0 in your domU. Example for dom0 with 192.168.1.1 and 1234::1

# IPv4
root@domU# ifconfig eth0 192.168.2.10 netmask 255.255.255.255 # Your domU's IPv4 address here
root@domU# ip ro add 192.168.1.1 dev eth0
root@domU# ip ro add default via 192.168.1.1
# IPv6
root@domU# ip -6 addr add 2345::1/64 dev eth0 # Your domU's IPv6 range here
root@domU# ip -6 ro add 1234::1 dev eth0
root@domU# ip -6 ro add default via 1234::1


Now it works (unless you did something stupid of course) 🙂

This weekend we’ll be going to some abandoned part of the country because we’re “celebrating” the 50th birthday of Lotjuh’s mom. (celebrating the fact that someone is a year closer to death…. weird rituals people engage in…). Anyway, since it’s in the middle of nowhere (“Limburg”, might as well be germany or belgium as far as I’m concerned) and the information page of the abandoned place we’re staying at didn’t hint anything about internet, I’m assuming the worst. Which means no wireless, no wired, only mobile phones. (and singing people *sigh*).
However, there is still hope to play Billy vs Snakeman this weekend.

Through a mobile phone! (continue reading…)

Everyone loves them (except for idiots of course), pretty graphs that show fancy lines and stuff. Especially stuff.
For instance stuff like this:

Why make these graphs? Because you can. Because they can show you gradual changes that you normally wouldn’t notice because the change per day is only very little. Because they’re fancy. Because they can give an indication on how hot stuff runs. Because they can kill your mother while you sleep. Because they got all the legendary items that you’ll never have. Tons of reasons.
But mainly because they’re pretty 🙂 (continue reading…)

Today the project to try out is Widelands, apparently a Settlers clone.
Since I loved the Settlers (the first one was the best) when the graphics were still acceptable, it is interesting enough to try it out. What I loved about the Settlers was the whole simulation concept. The construction of buildings, the little lemmings that moved the goods around, chopped down trees, fished, etc. The entire war aspect of the game was terrible (what do you mean my maximum level guy just got p0wnz3d by their new lowlevel rookie?!) . Therefore I liked the games that followed less and less. Settlers 2 was acceptable, a welcome upgrade in graphics and interface and stuff like that, but the war aspect… blegh. Then at 3 I had enough of the series. Why can’t it be a simulation where tribes co-exist in peace? I see how that might not attract many gamers, but how about an option huh? Another thing that was great about the Settlers 1 was the multiplayer multi-mouse splitscreen mode, where both players had a mouse on 1 PC and could control a single empire together. With SVGA mode it was great 🙂 (continue reading…)

Nope, no computer stuff this time.
When I’m not behind my computer I sometimes dare to enter the domain called “outside”.
If you like plants, and especially plants that are in some way ‘useful’ (in other words: they produce edible parts), you might want to grow some of them yourself. (continue reading…)

A while ago I talked about emulators and my quest to run them on 64 bit linux.
Today I stumbled upon pcsx-r or PCSX-Reloaded. Basically the same thing as the old pcsx emulator, only better 🙂
Why? First of all it builds and runs on my slackware64 without 32 bits garbage attached to it. Second of all, someone is actively developing it which means it’s still being improved. Finally, the interface is slightly better.
I know it’s good since slackbuild compiled it without problems 😉
Here’s the thing running on my slackware 64 install:

I loaded final fantasy 8 on it:

And to prove it does more than just the intro screen, here’s a shot from the intro movie 😉

Offtopic: Do you know what really annoys me in games?
UNSKIPPABLE CONTENT!
In this case the intro movie, but it goes for countless of things: cutscenes (either ingame or fmv), “game over” screens, long talks that I don’t give a damn about when I already know what they’re saying… I’m sure there are plenty more examples of this. If you’re developing a game, make sure you don’t force your gamer through this nonsense. Yeah, it’s cute, and we understand that you spent countless of hours wasting your time on fancy graphics, but after the first time I really don’t want to sit through it again. Especially if I just died and am forced through it -again-.

So now that I had it running in the background and could rant while it showed the intro, here’s an ingame shot 😉

Keep up the good work PCSX-Reloaded guys!
And fix your homepage.
Things that are currently wrong with it:
* It doesn’t tell me anything ABOUT the product, except for that it’s a fork/branch of PCSX
* It doesn’t have any screenshots (what is it with graphical programs that don’t have screenshots on their website? That’ s a FAIL right there)
* It doesn’t have any information on requirements etc, I just tried to compile it on 64 bit linux because I hoped it would work, not because your site tells me it does.

Don’t ask me why, but as usual Firefox (3.5.3 in this case) has issues. If it weren’t for lotjuh I didn’t even try to fix them. But since she smiles at me in such a cute way sometimes, I’ll fix it for her.

The issue was on teigetje, you remember the box from the NFS story earlier today.
Starting firefox gave nothing, it was just stuck. Running a strace on it:

root@teigetje:~# strace -p 12111
Process 12111 attached - interrupt to quit
futex(0x8056c60, FUTEX_WAIT_PRIVATE, 2, NULL
*stuck*


The exact reason isn’t known to me, probably NFS related, but this works to get it going:

root@teigetje:~# vim /etc/ld.so.preload
i
#
:wq

In other words, this comments out the /lib/libsafe.so.2 line so it wont be loaded anymore using LD_PRELOAD.
“But isn’t that unsafe?”
Pfffrt…. if you insist on firefox you’re probably opening yourself up for Adobe issues anyway. And libsafe doesn’t really make stuff “safe”, it only tries to protect your machine against buffer overflow attacks. So now it’s up to your kernel to ‘safe’ you instead.