Archive for December, 2008


Wicked Cool Ruby Scripts

Having fun and solving problems can be mutually exclusive. Even for professional programmers and system administrators who chose their career because they enjoy problem solving, there can be times when finding a solution is an exercise in the mundane. Luckily, there are tools designed to ease the pain and frustration faced by programmers and admins. Ruby is a programming language that was designed from the start to not only provide a means of solving problems, but also to be inherently intuitive and fun to use. Wicked Cool Ruby Scripts, by Steve Pugh, is a book aimed to bring to light the fact that you can use Ruby to write concise yet useful scripts that solve difficult problems.

If you’re a fan of the “Wicked Cool” books from No Starch Press, you’ll find the format of this book familiar. It’s not a hefty tome complete with syntax and “hello world” introductory lessons, rather it’s almost a recipe book of sorts, divided into sections of problems and chock full of immediately useful Ruby code. This is the “Wicked Cool” book I’ve been waiting for, because although I write PHP and shell scripts (not so much Java and Perl, other topics covered in the series), I’ve always thought Ruby was the coolest of all. Right from the start, you can tell that Steve Pugh agrees with me. His tone throughout the book is that of a friend who has something fun to share, never browbeating or lecturing. He’s not simply writing to show us that he knows how to write Ruby well, he’s really trying to help us out.

Honestly, some of the examples in Wicked Cool Ruby Scripts might leave you wondering why you’d use such a powerful language like Ruby for such seemingly simple things. What Steve Pugh tries (and succeeds!) to show us is that Ruby isn’t just for writing massive web applications, but it can also handle tasks often relegated to the ubiquitous, but cryptic Awk or shell languages. Perhaps you still wonder why you’d want to? “Just because you can doesn’t mean you should”, right? So why bother? Because Ruby is “Wicked Cool”, that’s why.

So what’s cool? How about a simple file alteration monitor to help you see what’s changed on your system? Not cool enough? How about a web based photo gallery in about 50 lines of code? Still not impressed? How about writing a Metasploit module to attack one Windows machine from another? From general purpose utilities to system security and yes, even some games, Wicked Cool Ruby Scripts has enough in it to pique the interest of just about any programmer or sysadmin. I for one am finding it hard to concentrate on this review because I want to get back to writing Ruby. If you’re a programmer waiting for a good excuse to try Ruby, or a Windows sysadmin wondering what an open source programming language can do for you, you’ll find Wicked Cool Ruby Scripts enlightening, inspiring, and of course… cool.

So as you may know, I’m working on secret PHP project using the Zend Framework. It’s coming along well and I have been taking some notes on the server which is on the local network. I was about to download my notes and print them when I decided that printing directly from the FreeBSD server to the printer in our office should not be a difficult feat.

Of course… it wasn’t difficult, but it was a bit tricky. Here are some things I just learned, in no particular order:

* When installing the port called ghostscript8-no_x11 , you are asked to configure it and set up some options via the usual curses menu interface. One of these options says “include X11 support”. Doesn’t it seem strange that the port is named with the no_x11 suffix, yet including X support is an option? I thought so. I don’t have X on this server and never will. I don’t want X there. I unchecked the option, and then the build failed. Oddly enough you need to leave this option enabled or you will run into bizarre build errors like “ert file not found”.  Don’t worry though, leaving this option checked does not build X! (I don’t think it makes sense but with the port as it is today, this is the case)

* If you didn’t think about installing CUPS early enough to set up the special options in make.conf to tell FreeBSD’s ports system to overwrite the default LPR printing base, you’ll have to move or otherwise disable /usr/bin/lp and /usr/bin/lpr and then either link /usr/local/bin/lpr and lp to /usr/bin or just edit your PATH.  I found that tidbit here: http://home.nyc.rr.com/computertaijutsu/cups.html

* The DELL 5110 printer we use has been added to our windows domain. The drivers for PCL and PS were added to the print server so that when the printer is being added there are choices. If you have the PS driver installed, just use that, trust me. You can add the printer in cups’ web interface and tell it to send the job raw. It’s much easier, in my opinion, than messing with drivers and ppd files. Using the PS driver and the raw queue I was able to print a test page the first try, which is saying something, believe me.

* I wasn’t able to print text files properly via the lpr command. I got strange stair-stepping on my printouts and they were totally unusable. Using the a2ps command to format and send the output directly to the printer worked amazingly. I never saw a printed text file look so good. a2ps is available in the ports tree and it works great even when you’re printing from a FreeBSD server via Cups and the samba/smb backend to some printer on a windows domain.

PHP/Recode fail

I use PHP on FreeBSD servers, compiled from the ports system. It works very well, except that sometimes… well… sometimes… segfaults happen. Yes random, bizarre, “how did this working system suddenly become non-working wtf” errors happen.

Here’s an example of what happened to me today. This is a snip from my lighttpd error log

(mod_fastcgi.c.2722) child signaled: 11
(mod_fastcgi.c.1051) the fastcgi-backend /usr/local/bin/php-cgi failed to start:
(mod_fastcgi.c.1065) terminated by signal: 11
(mod_fastcgi.c.1070) to be exact: it segfaulted, crashed, died, … you get the idea.
(mod_fastcgi.c.1072) If this is PHP, try removing the bytecode caches for now and try again.
(mod_fastcgi.c.2759) ERROR: spawning fcgi failed.

WHAT!?

Well in a nutshell, php-cgi is failing to start. When I attempt to run /usr/local/bin/php-cgi from the command line, it causes a segmentation fault. If you’ve seen this before, you might have thought “oh no… sig11! signal 11 could mean my hardware is fried!” At least I thought so. The truth of the matter, in this case, is that the php-cgi executable is not happy. Why isn’t it happy? I’m glad you asked. We all want our executeables to be happy, right?

This wasn’t easy for me to figure out the first time it happened to me last year. I was going nuts trying to figure out what went wrong, I even put in a request for new hardware (yes a new development server, which I actually got). This didn’t solve my problem either. I began to panic. I’m not sure what made me think of it, but after a while I decided to try minimalizing my PHP installation, by commenting out extensions from my extensions.ini file (on my sys it’s /usr/local/etc/php/extensions.ini)

With everything commented out, php-cgi was happy again, but of course I need at least a few of the extensions (specifically mysqli), and so I started adding extensions back in one at a time to find the problem. It turns out that the problem is with the recode extension.

With the recode extension out of the picture, things went along fine for quite a while and I was able to develop my small web application with Zend Framework (1.5 at the time, I think). PHP was happy, Lighttpd was happy, I was happy. There was a lot of happiness to be found! And then it happened. I updated my PHP port with portmaster. A dark cloud (a cloud named sig11) loomed over the server and the happiness turned to confusion once again. Then I remembered… “didn’t this happen last year?” Yes. Yes it did. Same problem. This time I didn’t panic though, I went straight for the extensions file.

Now I’m not sure what about the recode extension my system doesn’t like, but it doesn’t like it. It didn’t like it last year, and it doesn’t like it now. The PHP port installed a new copy of extensions.ini which includes the recode extension and so that’s why the error reoccured after updating the port. If you are experiencing weird segmentation faults with PHP, I highly recommend you start commenting out your extensions. Also, you may want to check the order of the extensions. If they are in alphabetical order, something is wrong. Some extensions rely on others to be loaded first, so be careful.

That’s it for now… PHP is happy once again, and I’m working on a new dev project, this time with Zend Framework 1.7  :) I’d tell you more about it… but it’s a secret. No, really, it’s a secret.

Wordpress Cloud Hosting