barn swallows: alive and well

Today I saw the four fledgelings perched on a nearby railing. Their parents still bring them food.

When I got home last night, two of them were perched on a door frame near where the nest used to be.

barn swallows: moving on

When I left for work this morning, the nest appeared to be empty--I didn't even see Stoopy lurking in it. I guess they were all off doing...well, whatever barn swallows do (eat insects and make poop, I suppose).

When I got home from work, I saw that the painters had taken down the nest so that they could paint the entryway. Lame, but at least they waited until the hatchlings had become fledgelings. If that was a deliberate decision, it was a nice one.

This evening as I left for a bike ride, the entire crew swooped past me single file through the entryway, as if to say "hello" (or perhaps "oh god it's a human fly away as fast as you can"--it's a subtle difference). And when I came back, one of the fledgelings was perched on the doorframe close to where the nest used to be.

So I guess they'll be OK. It was nice having them as neighbors for a while.

fledgeling barn swallows

Maybe they hatched earlier than I thought, because a couple of them were flying a bit today.

When I came home from work, one of them was perched on a rail about 30 feet away from the nest.

Another one was fluttering around a bit near my doorway. He didn't seem comfortable going too far, but he was able to hover and then land on the nest. (That was pretty cool to see.)

A third one was staying in the nest. That one holds his (her?) wings a bit funny--up higher closer to his head. It almost makes him look like an old man with a stoop. I'm wondering if that one is healthy.

When one of the parents came to bring food, Stoopy was the only one I saw stick his head out of the nest. So I can't account for one of the hatchlings. I looked around a bit but didn't find the fourth anywhere nearby on the ground.

Update: I just stepped outside to have a look, and all four hatchlings are back in the nest. They're big enough now that it's pretty crowded.

barn swallows; bigger and bolder

They're painting my building, so each day I fear that I'll come home to find that the painters have "evicted" the hatchlings (which they probably wouldn't survive). But they were still there again today.

It amazes me how much they've grown in just over a week. wikipedia says that barn swallows fledge (I believe that more-or-less means "leave the nest") after about 18-23 days, so they've got another week or two.

php|arch article

I got another article published. In fact, it looks like I made the cover of the June 2008 issue of php|architect. The article is titled "EAV Modeling" and talks about a database design I've used in a couple of recent projects.

Working with the editor on this assignment was a good experience. She made me feel a lot more involved in the process than I did with the Linux Journal article. *shrug*

barn swallows

About a month ago I started noticing a bird's nest attached to the wall near the door to my apartment. I'd occasionally see a couple of small, orange-and-black birds coming and going. Because of something that happened a couple of days ago, I wanted to find out what kind of birds they were.

A Web search directed me to whatbird.com. This site has a pretty cool search feature allowing you to enter certain characteristics of a bird (size, color, tail shape, etc.), and it'll help you figure out what kind of bird it is. Turns out that my neighbors are barn swallows.

The thing that happened earlier in the week is that their eggs hatched. So now I have about four other new neighbors. I took a few pictures and posted some of the better ones to my flickr account:

PHP frameworks: performance

For some time now I've been trying to figure out what to do about PHP frameworks. Most notably I've been wondering which one would be best for my needs and whether or not it's worth my time learning one. The problem is that there are so many. Zend, Cake, and Symfony appear to be pretty popular (at least, they are frequently mentioned in PHP blogs).

developertutorials.com has a post which highlights a recent performance analysis of Zend, Cake, and CogeIgniter. The concluding sentence is a good summation:

...if you’re building small applications, CakePHP will clearly save you time in development, CodeIgniter will offer massive performance benefits, and Zend will give you a reasonable middle ground.

Still not sure which one I want to try, but I lean a bit toward Zend (although it has received some recent criticism regarding its coding conventions and documentation). I like it that you can use it as a full-blown framework or just import the features you need for your application.

When I get some time, I guess *shrug*

mod_security

mod_security is an open source Web application firewall which operates as an Apache module. mod_security inspects incoming requests (and, I believe, can also inspect outgoing responses) and take certain actions if a request (or response) matches a pattern. These actions can include logging and/or blocking the request. mod_security works sort of like anti-virus software, in that it comes with a ruleset which can identify common malicious activity (like cross-site scripting and SQL injection attempts). Like anti-virus software, it's necessary to update the ruleset from time to time.

I installed mod_security on a couple of production RHEL5 Web servers lately, and here are a few of my observations.

Installing mod_security is pretty easy and is documented in the mod_security download. I found that I needed to install the following packages to meet some dependencies and to build mod_security:

• apr-devel
• gcc-c++
• httpd-devel
• pcre and pcre-devel
• libxml2-devel
  

I had the support of my managers to put mod_security in full blocking mode, so after copying the rules directory to /etc/httpd/modsecurity.d, I saved the following in /etc/httpd/conf.d/modsecurity.conf:

LoadFile /usr/lib/libxml2.so.2

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so

<IfModule mod_security2.c>
Include modsecurity.d/*.conf
Include modsecurity.d/optional_rules/*.conf
</Ifmodule>

The Web servers run a variety of custom Web applications as well as some canned software like Webcalendar and Wordpress. I didn't experience any problems with the custom applications or Webcalendar, but mod_security took issue when someone tried to edit an existing blog post in Wordpress (curiously, there wasn't any trouble when submitting a new post). So I put the following in /etc/httpd/modsecurity.d/modsecurity_crs_15_customrules.conf:

<Directory /path/to/wordpress/wp-admin>
SecRuleEngine Off
</Directory>

I'm in the fortunate (and perhaps unusual) situation of being able to restrict access to the wp-admin directory by IP address, so I don't have the entire Internet hammering at the thing. Looks like blogsecurity.net has a custom mod_security configuration for Wordpress which I just haven't had time to try yet.

Another wrinkle I had was that some command-line Perl programs I run would be blocked because they weren't providing "accept" and "user-agent" request headers. One of these programs looked something like this:

#!/usr/bin/perl -w

use strict;
use HTTP::Request::Common;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $uri = shift @ARGV;
my $res = $ua->request( GET $uri );
print $res->content();

I had to make the following two changes/addition:

$ua->agent('whinerack');
my $res = $ua->request( GET $uri, accept => 'text/html' );

(Looks like just about any non-blank user-agent will do.)

Another trick I've learned is that instead of using SecRuleEngine Off (like I did for the Wordpress wp-admin directory, which makes mod_security totally ignore that directory), you can use SecRuleEngine DetectionOnly, which makes mod_security log what it would do without actually blocking requests. This can be good for debugging.

And although I haven't needed it, the mod_security documentation suggests a way to whitelist requests from a specific host:

SecRule REMOTE_ADDR "^192\.168\.1\.100$" nolog,phase:1,allow

All in all, installing mod_security has been a fairly easy transition, and it's nice having another layer of protection.

xephem in Ubuntu

I was out with friends last night (4th of July fireworks), and they asked me to identify a bright object in the sky (I used to be an astronomer). I'm really out of practice at that kind of thing, so I speculated that it was Sirius (there was some light cloud cover, and I couldn't see whether or not this object was southeast of Orion, but it was pretty bright). Turns out I was wrong.

There's a really cool desktop ephemeris program called Xephem from the Clear Sky Institute. So I installed that on my Ubuntu desktop this morning to find what that thing was last night. I had to fulfill a few dependencies to compile xephem. Here's what I had to install first (I just explicitly installed the ones in bold--apt-get installed the packages in parentheses as dependencies):

• libxt-dev (libsm-dev, libice-dev)
• x11proto-print-dev
• libxp-dev
• libxext-dev (x11proto-xext-dev)
• libxmu-headers (?)
• libxmu-dev
  

(I'm not sure I needed libxmu-headers.)

After that I mostly just followed the directions in the INSTALL file from the xephem download. I copied the data directories (auxil, catalogs, etc.) to /usr/share/xephem (a directory I created) and put the following in ~/.xephem/XEphem (xephem didn't seem to want to read /usr/X11R6/lib/X11/app-defaults/XEphem as the INSTALL file suggested):

XEphem.ShareDir: /usr/share/xephem

I also gziped the man page (xephem.1) before copying it to /usr/share/man/man1/xephem.1.gz. And I created /usr/share/doc/xephem-3.7.3/ and copied in the Copyright, INSTALL, and README files.

By the way, that object turned out to be Jupiter. shrug

apt-get: "kept back"

I have the following (executable) file in /etc/cron.daily on my Ubuntu desktop:

#!/bin/bash

apt-get update
apt-get -s upgrade

This lets me know when updates are available: the -s option lists available updates without running them unattended.

Occasionally I'll get a list saying that some updates have been "kept back." I always have trouble remembering what to do in this case. It's typically just some dependency problem. This issue is addressed in the APT HOWTO on the Debian Web site. In my (limited) experience, this has always been overcome by doing apt-get instal pgkname, where pkgname is the offending package which is being "kept back."