BenV's notes

So today I noticed my pretty Check MK graphs were broken. Trying to view a random Check_MK service’s PNPGraphs gave this error:

Warning: preg_match() [function.preg-match]: Compilation failed: unknown option bit(s) set at offset 0 in /usr/lib/kohana/system/core/utf8.php on line 30

Fatal error: PCRE has not been compiled with UTF-8 support. See PCRE Pattern Modifiers for more information. This application cannot be run without UTF-8 support. in /usr/lib/kohana/system/core/utf8.php on line 38

Of course this is after I had upgraded some Slackware packages in the daily upgrades (I still run Slackware Current on non production machines, keeps things interesting) including PHP and Perl, so I wasn’t really surprised.
I reinstalled RRDTool since the perl bindings were gone (and of course I once again had to fight it) and decided to upgrade PNP4Nagios while I was at it.
However, no dice. Searching for the error gave nothing, hence this post.

To be sure it wasn’t what they (google) claimed it would be, I checked for UTF-8 support in my libpcre:
—

benv@graphs$ pcretest -C
PCRE version 8.12 2011-01-15
Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

Jup, UTF-8 support is there, along with Unicode stuff. Yay.

Next thing I noticed was that the new PHP version was complaining about extensions that wouldn’t load.
For instance dbase.so didn’t exist anymore, and some other junk failed as well. It’s possible that this error has been around for a while on that machine, but it was time to fix it!
Since my php.ini was from 2008 I decided to simply take the stock /etc/httpd/php.ini-production for now.
After that change php was again bitching about not being able to load extensions, but this times it were different ones.
Apparently they now have ‘libenchant‘ for spell checking, so that was one of the other failures.
To fix that problem use ‘slackpkg install enchant‘. (that’ll teach me to run the slackpkg install-new every once in a while :p)

Restarting Apache the hard way (not “apachectl restart” but /etc/rc.d/rc.httpd restart) helped for the PNP4Nagios error.
However, upgrading it introduced a new gimmick called:

Please check the documentation for information about the following error.

back

Right. Upgrading my Check_MK to 1.1.10p3 didn’t help.
However, checking the pnp4nagios config.php file made me aware that they added some options.
After merging in the new config.php options from their sample dir it finally worked again.
The new options I had to add when going from pnp4nagios version 0.6.7 to 0.6.13 were:

$conf['zgraph_width'] = "750";
$conf['zgraph_height'] = "450";
$conf['auth_enabled'] = FALSE;
# Adjust the next one to your configuration, it's probably different :)
$conf['livestatus_socket'] = "unix:/var/lib/nagios/rw/live";
$conf['allowed_for_all_services'] = "";
$conf['allowed_for_all_hosts'] = "";


Hooray, pretty graphs are back 🙂

Pretty graphs!

Yesterday when I was messing around with our homebrew IRC bot (written from scratch in perl) it somehow managed to segfault.
Which surprised me, it doesn’t happen very often that I see perl segfault.
It was caused by the fairly new module that handles RSS feeds. Running it through gdb quickly pointed a finger at XML::LibXML, which probably surprises nobody 😉
(at least I suspected the moment it crashed)
It looked like LibXML tried to free up some resource that didn’t exist anymore.

Today I wrote a little test script to figure out the exact cause. Apparently, using Storable to store things that LibXML returned is a recipe for great fun 🙂
Actually, storing it works pretty good. It works so damn good that LibXML actually believes that the objects loaded through Storable are still valid.

Example.
First store a piece of XML::LibXML to disk:

#!/usr/bin/perl
use Data::Dumper;
use Storable qw/lock_nstore/;
use XML::LibXML;

my $xmlp = XML::LibXML->new();
my $xml = $xmlp->parse_string($rssfeed);
$data->{'xml'} = $xml->find('/rss/channel/title/text()');
my $s = lock_nstore($data, $ARGV[0]);
print "Stored.\n";



#!/usr/bin/perl
use Storable qw/retrieve/;
use XML::LibXML;

die "Usage: $0 file.storable" unless(scalar(@ARGV));
my $s = retrieve($ARGV[0]);
my $link = $s->{'xml'};
print "Segfault in progress! $link\n";


The execution looks like this:

benv@janeman:~:0>./test-store.pl asd
Stored.
benv@janeman:~:0>./test-load.pl asd
Segmentation fault (core dumped)

Fun!

When nectarine died a few years ago (or at least, that’s how I view it) with their broken harddisks, lost backups and whatnot, I gave up on the necta.pl tool me and a friend of mine had written.
However, a few months ago I got back into listening to the new scenemusic.eu who got everything back up and running based on recovered data from the old Nectarine.
It seems like they did a proper job of setting up a new site, and they even provide a nice xml backend for tools like this.

So after a while I decided to revive our tool. This time I took the time to curse even more at Irssi and their script support, so I implemented the nonblocking fetcher and nectarine parser
in separate libraries. Well, isn’t that fun. Reloading those things was a problem (/script load necta wouldn’t reload those underlying libraries), but fortunately Garion helped me out here after a mail to the Irssi mailing list. Thanks Garion!

Anyway, I’ve put the first release up for download on this page:
http://notes.benv.junerules.com/necta/

Or a direct link to the download:
[Download not found]

Let the bug report begin 😉

Another annoying thing: morons that save their files with dos line endings.
Also known as “I’ve got motherfucking ^M in my file, AAAIIEEEEYGGrrgrll“.
I usually find out about this when bash complains about stuff like this:

benv@janeman:~$ ./bla.pl
-bash: ./bla.pl: /usr/bin/perl^M: bad interpreter: No such file or directory

(HAAAAAT!!!)

Solution:

benv@janeman:~$ vim kankerfile
:set fileformat=unix
:wq

(Don’t confuse fileformat with filetype, one is used for encoding, the other for things as syntax highlighting)

Solution 2:

benv@janeman:~$ dos2unix kankerfile

I never use this since I never have that piece of cancer called dos2unix, but some distros do.

Solution 3:

sed -ie 's/\r//g' bla.pl


That should fix it. On to the “let’s trash my home directory with my fancy new perl script that I just converted” 😉

So while messing around with some perl/curses stuff I got fancy with colors and soon found out about the limited support of colors in terminals and therefore also Curses.
Anyway, I made this little “fractal plasma” thingy with it, see if you can get it running 😉
It’s not really a fractal plasma, so don’t get technical on that, but it describes it best I think.

To get it running, open up your favorite terminal that supports 256 colors and allows palette changing – I found both xterm and urxvt to work.
Make sure your TERM variable is set to something that allows this, for instance in urxvt:

$ export TERM=rxvt-256color
$ ./fractplasm.pl

or this worked for me with xterm:

$ export TERM=xterm-256color
$ ./fractplasm.pl


Something like this is the result:

Enjoy!

Hej readers,

I decided to work on making slackbuild.pl a bit more acceptable in terms of usability and looks. The reason for this is that the dialog program doesn’t exactly do what I want.
That is, it works…. but that’s pretty much all I can say about it. It doesn’t allow me to make a comined checkbox/menu thing that I want for my configure options part. Next to that it’s tedious to fork and parse its output all the time, and let’s not even get started about looks and input issues.
So I figured: hmm, dialog is made in ncurses, perl has a Curses lib…. let’s play! (continue reading…)