Month: March 2009

So in the process of applying the new SSL cert here at work, I discovered an issue with the reCAPTCHA service.

The problem was that I was getting errors saying that my forms were only partially encrypted.  This was due to my use of the reCAPTCHA library, which by default doesn’t use an SSL connection to grab the challenge HTML.

The documentation at the reCaptcha site has a section on this.  Specifically it says:

In order to avoid getting browser warnings, if you use reCAPTCHA on an SSL site, you should replace http://api.recaptcha.net with https://api-secure.recaptcha.net.

Ref: http://recaptcha.net/apidocs/captcha/client.html

The example it uses shows how to change the Javascript itself.  While this was nice to know it really didn’t help too much in my particular case. To solve this when using the reCAPTCHA PHP library, all you need to do is change the value of a single variable.  In the file recaptchalib.php look for the function recaptcha_get_html then change the declaration to read as follows:

function recaptcha_get_html ($pubkey, $error = null, $use_ssl = true)

This will force all calls to be transmitted over an SSL connection, thus eliminating the dialog box in Internet Explorer and the slashed-lock in Firefox.

However since I am not encrypting the entire site by default, yet due to an issue with our website editing/management system, Adobe Contribute, I had to do a bit more than just updating the boolean variable.  Since some of my forms are encrypted and some are not, I added the following code to the function referenced above:

if ($_SERVER['SERVER_PORT'] = 443) { $use_ssl = true;

}

This needs to be added just above the check for the value of the variable use_ssl in the function recaptcha_get_html.  Once you do this you can use the same copy of the recpatchalib.php file for both secure and non-secure forms.

As some of you might have noticed, I have just recently moved my WordPress installation into a subdirectory of arfore.com.

There are several reasons for this, the main one being that I would like for my blog to become a component of my website rather than the blog being the entire site.

Moving the WordPress installation itself was quite simple, and there are many pages out there describing the process as well as the pitfalls of doing it incorrectly, so I won’t repeat them here.

What was less easy to find was the proper changes to put in the .htaccess file to ensure that any existing links would get redirected to the proper location in the moved WordPress setup.

I have my permalinks configured to create a URL like follows:

http://arfore.com/blog/2008/10/12/foo-bar-baz/

In order to add the subdirectory blog to the front of the URL I used the following rule in my .htaccess file:

RewriteRule ^([0-9](.*))$ http://arfore.com/blog/$1 [R=301,L]

Similarly, to redirect the categories I used the following:

RewriteRule ^category/(.*)$ http://arfore.com/blog/category/$1 [R=301,L]

Now this may not be the most correct method to accomplish the goal, so if it needs correcting by all means let me know.

My last two posts, Starting NRPE via launchd and Nagios NRPE on OS X Server 10.5, concerned getting NRPE to run on OS X Server 10.5 and having it startup at system boot.

However, this is only part of the battle.  Once you have Nagios monitoring setup on your server you also need to have some nice options for checking the availability of your running services.

Tim Wilson from the Savvy Technologist, wrote an NRPE plugin that helps out with this.  The plugin check_osx_services does an excellent job of checking on the status for many services running on 10.5 Server.

The documentation on the plugin at the NagiosExchange site is pretty thorough.  One thing that is not mentioned is that you will need to run the check_osx_services script as superuser since it calls the system level command serveradmin which must be run as root.

This next week the Senate is expected to vote on legislation to delay the transition of broadcast television in the United States from analog signals to digital signals.

The initial deadline was to have been February 17, 2009, however some in Congress as well as President Obama claim that more time is needed due to the fact that evidence has shown that consumers are not prepared. The new legislation sets a deadline for the switch to June 12, 2009, however broadcasters can switch over to digital prior to that deadline if they so choose.

While I am sure that enough money was not provided to fund the coupon program, and that the whole information campaign has been bungled from the beginning, I don’t think that extending the deadline is really going to do any good. The consumers have been seeing ads from both the federal government as well as their local cable providers informing them about the transition and what they can do. Changing this deadline is not going to help any.

No matter when they switch the deadline to consumers are going to be left out in the cold. Sometimes you have to pull the band-aid off fast in order to lessen the long term pain.

So, a friend of mine was setting up a Linksys WRE54G Range Extender on her wireless network to eliminate a dead spot in her house.

She had issues with the Windows-based setup utility because it hardcodes the TCP/IP settings on the computer due to the fact it assumes that your network won’t be setup to work with the device out of the box.  After that failed, and spending a while on the phone with a hapless Linksys tech support person, we finally got it configured via the web interface.

So everything is going fine until she notices that the MAC filter that was configured on the WRT54G was no longer effective.

It turns out that when you setup the WRE54G to work it invalidates the purpose of your MAC filtering.  All traffic sent through the range extender is automatically flagged as OK.

From a Linksys forum post:

As a result, Wireless MAC Filtering on the main wireless router or access point will have no effect on clients connecting through a WRE54G Range Expander.

You have to wonder who makes the decisions on options with stuff like this.  The Linksys tech I was chatting with online about this said that the best solution would be to enable WPA security, but their user guide for device specifically recommends doing MAC address filtering in addition to the encryption, except for the fact that you can’t.

Good game Linksys.