Cricket monitoring – old library reference

We recently shutdown one of many systems we have monitored by the free and open source Cricket monitoring software. I noticed we got no notification from Cricket about this shutdown, which was puzzling. Looking through the logs I saw this error message:

Can't load '/usr/local/lib/perl5/site_perl/5.16/mach/auto/RRDs/RRDs.so' for module RRDs: Shared object "libpixman-1.so.30" not found, required by "libpangocairo-1.0.so.0" at /usr/local/lib/perl5/5.16/mach/DynaLoader.pm line 190.
 at /usr/local/cricket/cricket/./collector line 32.
Compilation failed in require at /usr/local/cricket/cricket/./collector line 32.
BEGIN failed--compilation aborted at /usr/local/cricket/cricket/./collector line 32.

So it was clear that the pango library file libpangocairo-1.0.so.0 was looking for a pixman library file it couldn’t find. The first thing I did was check out which version of pixman we currently had installed:

steve@someserver-335: pkg info pixman
pixman-0.32.4_2
Name           : pixman
Version        : 0.32.4_2
Installed on   : Mon May  5 15:30:07 EDT 2014
Origin         : x11/pixman
Architecture   : freebsd:10:x86:32
Prefix         : /usr/local
Categories     : x11
Maintainer     : x11@FreeBSD.org
WWW            : http://www.freedesktop.org/Software/xlibs
Comment        : Low-level pixel manipulation library
Shared Libs provided:
        libpixman-1.so.0.32.4
Flat size      : 1.43MiB
Description    :
This package contains the pixman library.

Ok, so now I was able to confirm that pango was trying to reference the old version (libpixman-1.so.30) of the pixman library, even though we have a newer version (libpixman-1.so.32.4) installed. Time to rebuild the pango port to update that reference.

$ sudo portmaster pango

And finally I ran the following to test Cricket out:

$ cd /usr/local/cricket/cricket
$ ./collect-subtrees normal

All was back to normal!

JSON-ing and request headers

We have this web widget that calls a particular webservice and does a JSON post. This was failing miserably on the back-end. For some reason, the data that was ending up in the session was not ending up in $session->params->{POSTDATA} but instead $session->params->{keywords}. In turn, our webservice was bombing when it was trying to access the data from POSTDATA since it wasn’t there in the session. Here’s an excerpt of the Perl data dump for the bad session:

_QUERY       => bless({
                      ".charset"     => "ISO-8859-1",
                      ".cookies"     => {
                                          sid => bless({
                                                   name  => "sid",
                                                   path  => "/",
                                                   value => ["XXXXXXXXXXXXXXXXXXXXX"],
                                                 }, "CGI::Cookie"),
                                        },
                      ".fieldnames"  => {},
                      ".parameters"  => ["keywords"],
                      "escape"       => 1,
                      "param"        => {
                                          keywords => [
                                            "{\"fname\":\"Steve\",\"lname\":\"Dickinson\",\"phone\":\"5557771000\",\"email\":\"steve\@someplace.com\",\"date\":\"2014-07-05\",\"time\":\"18:00:00\",\"size\":2,\"notes\":\"notes\"}",
                                          ],
                                        },
                      "use_tempfile" => 1,
                    }, "CGI"),
    _STATUS      => 5,
  }, "CGI::Session");

It should have instead looked like this:

_QUERY       => bless({
                      ".charset"     => "ISO-8859-1",
                      ".cookies"     => {
                                          sid => bless({
                                                   name  => "sid",
                                                   path  => "/",
                                                   value => ["XXXXXXXXXXXXXXXXXXXXX"],
                                                 }, "CGI::Cookie"),
                                        },
                      ".fieldnames"  => {},
                      ".parameters"  => ["keywords"],
                      "escape"       => 1,
                      "param"        => {
                                          POSTDATA => [
                                            "{\"fname\":\"Steve\",\"lname\":\"Dickinson\",\"phone\":\"5557771000\",\"email\":\"steve\@someplace.com\",\"date\":\"2014-07-05\",\"time\":\"18:00:00\",\"size\":2,\"notes\":\"notes\"}",
                                          ],
                                        },
                      "use_tempfile" => 1,
                    }, "CGI"),
    _STATUS      => 5,
  }, "CGI::Session");

During this time I was also building a similar Android app to mimic how this widget works. The funny thing was, that the Android app worked but the widget didn’t. In thinking back to my app code I soon realized the issue. In the app code I had correctly set the header like so:

httppost.setHeader("Accept", "application/json");
httppost.setHeader("Content-type", "application/json");

The widget had no such code for this webservice call. So I added the following handleAs & headers definitions to the developer’s JavaScript code:

var req = {
    data: JSON.stringify(requestData),
        handleAs: 'json',
        headers: {
            "Accept": "application/json",
            "Content-Type": "application/json"
            }
    };
request.post('http://somedomain.com/webservice_call', req).then(

That’s all it took!

PC reinstall – the importance of setting the date correctly.

Today I had to do a Windows 7 re-install. Nothing new there. The PC was running very sluggish and it was time to wipe everything clean. So when it came time to set the date I incorrectly set the Meridiem Indicator, or period, to AM (2:30 AM) instead of PM (2:30 PM). This made the PC’s time 12 hours in the past. This has a great affect on online services such as LastPass and its kin XMarks. I noticed I couldn’t login to LastPass or sync bookmarks using XMarks via their respective FireFox add-ons. I knew the passwords I was entering were correct. So I then tried going to LastPass’s website and got this:

Oddly enough I recalled this same issue coming up on a recent Tech Guy podcast. Leo Laport’s recommendation was to check the system time and low and behold he was right! I then corrected the period to PM (2:30 PM) and everything was back to normal.