Spot the error? I only wasted an hour of my life and another 30 minutes of co-workers trying to figure out why I kept getting a "NRPE: No output returned from plugin" error in Nagios. The issue? $ARG1 is missing a closing “$”. *slams head on desk*

Here is a copy of the code that I slightly modified to also include the function name from where the debug macro is being used.

First we check if the DEBUG macro has been defined at all. If it has been, we declare a function-like _DEBUG macro that will get expanded to our debugging function. If DEBUG has not been defined, we still declare our function-like macro the same but with just no body so the macro will not be expanded to anything.

Our _DEBUG macro makes use of a few predefined macros:
__FILE__: Expands to the current file name. This will not print the shortname of the file.
__FUNCTION__: Expands to the current function the code is being executed from. This is a C99 and GCC feature only.
__LINE__: Expands to the current line number in the file

We also make use of ‘variadic macros’ aka macros that accept a variable number of arguments. A variadic macro can be defined named or unnamed. We use the named method which involves putting an argument name followed by ‘…’ which is later referenced by just using the argument name in the macro body. An unnamed variadic macro just involves using ‘…’ and later referenced in the macro body using the predefined macro __VA_ARGS__

A default format string is passed into printf to take care of the formatting for the filename, function name and line number. Immediately after the default format string, we specify the fmt argument we used that will get assigned our own format string that we pass into the _DEBUG macro. This will all get expanded to "%s:%s:%d: " "val of fmt" which is valid C syntax.

To activate the _DEBUG macro we can define DEBUG in our gcc command

• 10-22mm f/3.5-4.5

• 70-200mm f/4

• 50mm f/1.8

• 18-55mm f/3.5-5.6 (kit lens)

The lens collection has been built over the last 4 years from when I first got my Canon Rebel XT and I’ve been fairly happy with them thus far. As part of looking into what new lens to get I wanted to know what focal length I shot with the most over the previous years. A quick look with

shows I have 4697 RAW images in my photos folder, so I’ll need some sort of automated solution to figure this out.

My first inclination was to poke around Python’s PIL and see if it supported reading of RAW images, it didn’t appear to do so that option was out. I looked at the Canon RAW format at http://www.sno.phy.queensu.ca/~phil/exiftool/canon_raw.html and contemplated doing some parsing of the files to extract the info I needed from the EXIF data. I remembered in the past I had used UFRaw to play around with RAW conversion in Linux a while back and saw they are using a nice simple tool to do their RAW parsing called dcraw. It’s a small C program that I was able to compile the source with the following commands…

Using dcraw seemed like the path of least resistance and now I just needed to wrap some code around it to go through all of my RAW images and extract the EXIF info and keep a hash table of the focal length value. I whipped up a small python script and posted a gist of it over on github.

It’s fairly straight forward and could easily be modified to do more, like collect aperture sizes or any other EXIF data. I may go back and build it out a bit more to make it more flexible in what data it collects, but for now this suited my needs at the time. My top 10 focal lengths ended up being

Takes close to 11 seconds on average to calculate that for 4697 images.

I had been wanting to upgrade my 50mm f/1.8 lens for a bit as I’d really started to notice the short comings of it. The lens has a hard time focusing and also had a bit of a back focusing issue. Since my Uncle borrows my camera a lot when he goes on vacation I worked out a deal with him to purchase the 50mm f/1.4 for me and in exchange I’d give him my old Canon Rebel XT with the kit lens and the 50mm f/1.8 lens.

The kit lens was a great walk about lens so I’m currently trying to decide on a good and reasonably priced lens to cover somewhere in the 18-100mm range. I’m reading through a bunch of comments on amazon reviews and dpreview forums to figure out what my best bang for my buck would be for a lens in that range.

Now back to reading about setting up a virtualenv environment

There are many others but these are just a few off the top of my head and I’m still discovering what other capabilities Varnish has. The site has not gone live yet so I’m still testing on a dev version of the site and have not had an opportunity to perform any load testing yet. So far with my current working configuration I’ve made the following tweaks

The use of mod_expires on the Apache backend controls cache times for static assets (css,js,images,etc..). In my googling around when reading about Varnish I see a lot of people are setting cache times in their VCLs. IMO you should be letting the backend or application itself control the TTLs on objects. Within your application you can set more defined TTLs for certain sections of your site or even certain types of dynamic content without having to rely on complex VCL rules or deal with the deployment of the rules into Varnish. While Varnish does support a “graceful” style restart, its not quite as eloquant as doing service apache graceful. Kristian Lyngstol (one of the Varnish devs) has a good post on his blog on dealing with this. Also with the use of mod_expires you can set TTLs based on MIME-type within Apache.

One other thing I see a lot of people blindly recommending in configurations to deal with Varnish’s behavior of not caching cookies is to take the cookie value and add it into Varnish’s hash of the object. e.g.

If a light bulb just went off in your head as to why this is a bad idea, kudos to you. What you’re basically doing is creating a cache per-user on your Varnish server. Your hit ratio will plummet from this config. There are scenarios where this can be used in a good way. In talking with some folks in #varnish on irc.linpro.no, a scenario where you’d want this is if say you had a cookie that was a display filter on your site or some sort of site customization that didn’t have a large number of combinations.

One thing that bothers me about Varnish currently is that it’s admin interface is completely unsecured. By default it listens on localhost but without any authentication, anyone with a shell on your Varnish box can bring down your Varnish instance or modify the config in anyway they feel fit. For those that allow dev’s on production servers to debug logs, this is a bit of a security concern. I’m not really sure of a workaround for this, so if anyone has any ideas, leave it in the comments below.

If you use Cacti for trending, there are some great templates available over at the cacti forums. They utilize a python script that needs access to the admin interface.

I’ll probably post some more in the future on Varnish as I do further reading and testing with it.

My first project I decided to tackle as I go through my book is writing a module that will fetch stock quotes from Yahoo’s Finance page and store them in memcached.  I just pushed it out to github available @ http://github.com/jlintz/python_quote.  I’m hoping to get some feedback from some people on where I can improve in my code and hopefully it will be useful to someone else out there.  As I go through the book I plan on going back and looking at the code and see what I can refactor and I’m sure along the way I’ll probably re-architect things.

One thing I know I need to do is write some unit tests for the module.   When I was in my Computer Science program in college, we really never had any exposure to unit tests.  The unit tests consisted of assert statements and really never had any real lessons on them.  I need to do more reading on unittest.  I know many developers write their unit tests first before writing a single line of code in a test driven development approach.  It’s something I want to look at more and see if I should consider picking that up.

Also as part of this coding project, it was a good excuse to get some exercise with Git.  It’s pretty easy to work with and I haven’t even scratched the surface of its potential.  I just need to begin looking at some of its more advanced features and incorporating them into my work flow.

Vim is another program I’m getting some finger exercise in.  When I started my job 3 years ago I had never really opened Vim/Vi but one day forced myself to learn it because as a sysadmin, Vi will always be there for you, like your friend Stewie.  In my day to day uses of Vi, I just used the basics, hjkl and :wq.  Slowly I picked up some commands from co-workers and got used to using them daily.  When writing code in Vim , there are a lot of tricks and commands to aide you in writing code , I’ve read about many but now it’s a matter of incorporating them so I don’t have to think much and breaking my old habits to use the new commands I’ve read about.