Getting Big Brother to monitor custom processes
This is very easy to do - and the documentation is bang on the money… but as always, there are no examples!
So without further a do…
Create a bb-proctab file in the etc folder in your Big Brother’s home folder with the following syntax:
<host name>: <yellow alert processes> : <red alert processes>
Processes are space delimited (enclosed in quotes where necessary) and can be followed by a semicolon if you want to specify a minimum or maximum of times it should be running.
The example below will issue a yellow alert if myscript.pl is running more than 8 times (to check for over forking or excessive load) and then a red alert if cron, bbrun or myscript.pl stop running.
localhost: "myscript.pl;<8" : cron;>=1 bbrun;>=1 “myscript.pl”
PHP, OpenSSL and MySQL
Oh boy, oh boy have I had a hellish few days…
I’ve been trying to get OpenSSL working in PHP 5.2.3 so that I could use file_get_contents() to access secure pages (over https) and it’s been a real pain.
Of course it worked fine on the development environment but when it came to the staging and live environments a nightmare ensued… First trying to compile OpenSSL into PHP resulted in a segmentation fault when we tried to run PHP’s unit test script but after our sysadmin played with it for a bit we managed to get the unit test to run with the following errors:
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #16069 (ICONV transliteration failure) [ext/iconv/tests/bug16069.phpt]
iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
openssl_csr_new() tests [ext/openssl/tests/004.phpt]
Bug #28382 (openssl_x509_parse extensions support) [ext/openssl/tests/bug28382.phpt]
Bug #36732 (add support for req_extensions in openss_csr_new and sign) [ext/openssl/tests/bug36732.phpt]
openssl_sign/verify: accept different algos [ext/openssl/tests/bug37820.phpt]
Bug #39217 (Large serial number return -1) [ext/openssl/tests/bug39217.phpt]
=====================================================================
Taking that on the chin we decided to ho ahead with the install and see what happened. It turned out that trying to use file_get_contents() on an https url resulted in this error:
Warning: file_get_contents(): SSL operation failed with code 114. OpenSSL Error messages:
error:00000000:lib(0):func(0):reason(0) in /server/path/httpsTest.php on line 5
Warning: file_get_contents(): Failed to enable crypto in /server/path/httpsTest.php on line 5
Warning: file_get_contents(https://www.securesite.com/data.xml): failed to open stream: Bad file descriptor in /server/path//httpsTest.php on line 5
So what was the solution? To cut a long story short there is a conflict between OpenSSL and the secure socket stuff in MySQL client api versions 5.0.22 (possibly earlier versions too) < 5.0.25. Upgrading to the latest version and then recompiling PHP against it should work a treat!
As I say, I've had a real pain with this - especially as I wasn't expecting the problem to be with MySQL! Hope this helps someone...
Perl’s MIME::Base64 on Mac OS X 10.4.9
I was having a problem using MIME::Base64 on Mac OS X. My script would run on the RedHat Dev server but not on my Mac Desktop which was making developing a bit of a nightmare.
The error was:
MIME::Base64 object version 3.05 does
not match bootstrap parameter 3.07 at
/System/Library/Perl/5.8.6/darwin-thread-multi-2level/
XSLoader.pm line 92.
Compilation failed in require at
/System/Library/Perl/5.8.6/darwin-thread-multi-2level/
MIME/QuotedPrint.pm line 14.
The weird thing was that MIME::Base64 was already installed and up to date! After a few brief minutes of frustration I went into CPAN and gave it a:
force install MIME::Base64
And lo and behold… it work! I guess when it said it was already installed it didn’t check dependancies or something. I wonder if there are any pre-installed Perl modules in OS X that aren’t quite installed… hrmmm.
Resurrecting an Instiki under OS X
So, not so long ago we had a wiki running under Instiki and it was great… Everyone put everything on it and we were happy.
Then the bad man came and replaced it with a Media Wiki… which actually was much better - the only thing that was lacking was some legacy content that wasn’t copied across. Today I needed that data and this is how I got it.
Firstly, I downloaded a standalone version of Instiki for OS X - I didn’t want to have to recompile Apace with ROR support. You can get the DMG here:
http://www.2sheds.ru/files/instiki-0.10.2.dmg.
Once you’ve got that installed just double click it to get it running (it’s a headless unix process, so don’t expect an icon in the Dock!) After that open a terminal and run:
ps aux | grep Instiki
This should show you what parameters were passed to the mini Ruby server when it was started. We’re looking for –storage as this will tell you were you nee to put your old wiki’s data files. Mine were in /Users/dark0/Library/Application Support/Instiki/. In that folder is another folder called 2500 (might be different on your set up) and in there are all the .snapshot files - so if you delete the existing ones and copy across the files from your old Insta-Wiki and your done!
Operation: Doggy Be Gone!
I work for a company that is part of a large group of other companies… all of which, at various times, have had corporate web sites independently developed for them by different developers using varying technologies and producing varying qualities of code.
The result of this is Doggy Day. This is a day that happens once a month when we get emailed a digest of all the press releases and copy changes that need to be added to the various different web sites because the required content management systems are either non existent or too buggy to be used by non-developers.
Now, the result of Doggy Day, no matter how well we thought we documented it last time, is always chaos (rampant in an age of mistrust) as: No one ever set up an FTP server up on the MS IIS box, so all changes have to be made over VNC… The press realise is larger than the varchar(4000) limit some muppet put on the MsSQL database… The Cold Fusion box’s been crashed for six months and no one noticed…
Need I go on?
The answer to Doggy Day is something dreamed up by Rob and myself (well mainly Rob actually) and it is called Operation: Doggy Be Gone!:
- Step 1: Set up a central Word Press blog with a Category for each site.
- Step 2: Use wget to recursively spider the sites in question, download all links and rewrite then to .html files with relative paths.
- Step 3: Check the newly flat sites still work as wget won’t have wgot files linked via JavaScript (rollover states etc) or files loaded in via SWFs.
- Step 4: Put the files in some kind of consistent structure (like ‘domain/subdomain/files/’).
- Step 5: Rip out all the pages that need CMSing and rewrite them in PHP with a RSS aggregator like Magpie that looks at the feeds of the sections on your central Word Press Blog.
- Step 6: Check into Subversion and deploy.
- Step 7: There are no more doggy… I mean steps.
All the above took less than a day… thanks to the sheer hackibility (sorry I mean flexibility) of PHP, the neatness of Word Press and the always amazing wget! And the best bit is: No more doggy days!
Subversion: Please cut the crap!
I don’t know about you, but on our development environment we have lots of files that aren’t under version control and never will be… they are tests… they are temp files… they are just there.
I know it could be argued that they shouldn’t be there but they are - it is the development environment after all!
The only problem I have with this is that when you ask to see the status of your files you have to sift through loads of unknown files with ‘?’ in front of them… so I wrote the below shell script to only list files that have been modified and then just tell you how many unknown files there are!
echo "Modified files:"
svn status | grep ^[^?]
echo "Unknown files:"
svn status | grep ^[?] | wc -l
It’s pretty simple and not perfect but it’s made my life easier!