thoughts of a doug

Yesterday I published my first full module to CPAN: Nagios::Plugin::OverHTTP. The module is based on Moose and includes the Nagios plugin in the distribution in bin/check_over_http. I will be improving this module, but wanted to push it out to CPAN as soon as it was at least usable. The module is avaiable in my Github account under perl5-nagios-plugin-overhttp for forking and public versioning.

Once again, things change in the software world. This time it is Windows PowerShell. PowerShell was been around for quite a while now, but I am settling down to start using it regularly. So far it seems to be pretty hit-and-miss with finding documentation online through search engines, but then again I am not too sure what I should be searching just yet.

For managing computers, I have many batch scripts, which I would like to fully replace with PowerShell scripts. With just a little bit of work, I can gladly say that Microsoft has a very well-designed shell environment on their hands here.

Please, never trust the client. I’m not sure how much this can be stressed. After writing unsupported interfaces for various programs (most commercial) I find that this basic rule is not always followed. Gone are the days where people submit forms and then the server checks the inputs and will return one or more error messages for bad input. Now much of the error checking is done in the browser to make it more convenient for the end-user, as they won’t have to wait for a round-trip of their data to realize that they entered only four numbers for a U.S. zip code.

The problem is at one time all checking was done server-side. Then for end-user convenience, most or all of the checks were duplicated on the client-side. Now I am seeing developers “forget” to check things on the server-side. In the days of increased attacks on web sites, this becomes more critical. The client can never be trusted. Once the JavaScript is loaded in the end-user’s browser, it can be manipulated and checks disabled, allowing them to submit bad data. They may even just submit the data to your server by just constructing the HTTP request themselves.

Just today I was working on creating an unsupported interface to a popular commercial software that many companies use. While reverse-engineering different parts or their interface’s code, I found that they must have been lazy, because they send an “API” command that looks suspiciously exactly like PHP. I put a syntax error in it and it complained about a syntax error in an eval() statement. An eval() statement?! Yes, I can execute anything I want on the server, making any kind of access control obsolete, as I have direct access to the running PHP instance, the database server, and the file system.

So, please,

die unless $i_am_a_number =~ m{\A\d+\z}mx;

So what is the business with the following global variable I keep seeing in CPAN modules these days?

our $AUTHORITY;

So I searched a bit to figure it out, and found it made its way from Perl 6. A description of its use in Perl 6 can be found in Synopsis 11: Modules. Essentially Perl 6 saw that there would be no reason why there can’t be more than one module named Foo::Bar. You can already designate a minimum version required of a module, and you still can in Perl 6, but they saw that Foo::Bar is just a short name for the module. Its full name includes more parts, including the authority. So to load up the Foo::Bar I wrote in CPAN (note: I have no such module), you would say:

use Foo::Bar:auth<cpan:DOUGDUDE>;

When in the Foo::Bar module I specify:

our $AUTHORITY = 'cpan:DOUGDUDE';

From my earlier post, after talking in #Perl, I have changed the name of the module from Archive::OPC to File::OPC. It is still not on CPAN, as I won’t release it until it can at least read Open Packaging Convention files. The module is being written using Moose.

Recently I installed TortoiseSVN on a Windows Vista machine (though from reading different sources on the Internet, it applies to all platforms TortoiseSVN runs on, like Windows XP) and I was presented with the following error message when trying to connect to a repository over SSH (that is, svn+ssh):

I was looking around the Internet trying to find the solution, and after a bit stumbled upon the answer on some random forum. The error appears to be in the way in which TortoiseSVN calls PuTTY. The solution is to open the settings for TortoiseSVN and then go to the Network pane and under the SSH section, make sure the SSH client box is empty and does not have the path to PuTTY.

If you were wondering this applies to PuTTY 0.60 and TortoiseSVN 1.5.5 build 14361.

I’ve recently been working on reading Open Office XML files using Perl, and I’ve made a lot of progress with the implementation of the Open Packaging Convention specification as a Perl module. I think soon I will be releasing a version of it to CPAN. I am not too sure of what the module should be named as of yet. I am thinking possibly Archive::OPC since it is a packaging format (it is actually a ZIP file with a specific file layout).

Many Microsoft formats are using this convention and it is a standard (ISO/IEC 29500:2008 and ECMA-376) for anyone to use if they wish. I know it is used for Open Office XML and XPS.

I just installed MySQL 5.0.27 today. I used to use MySQL 4.1.x, but I decided that I’d move to 5.0.x since it is now the GA release. I had all my previous databases backed up in their binary format, and since I didn’t have MySQL 4.1 installed when I installed 5.0.x, it did not update my tables. The interesting note about that is that on Windows, the process to do this manually is not as easy as it should be. Here are the steps:

1. Stop the MySQL service (net stop mysql).
2. Move the binary files into the new /data/ directory.
3. Delete ib_logfile0 and ib_logfile1 if they exist.
4. Start the MySQL service (net start mysql).
5. mysqlcheck --check-upgrade --all-databases --auto-repair --user=root --password
6. mysql --database=mysql --user=root --password
7. mysql> source c:\mysql\scripts\mysql_fix_priviledge_tables.sql

And now you’re all done!

I have traced the mail problem down to the USF Mail server itself and whatever policy it has. I enabled SMTP logging in Thunderbird and was able to see the SMTP conversation Thunderbird was having with the server. It turned out that my Thunderbird is giving the USF mail server (and only the USF mail server) ELHO [127.0.0.1]. I changed some settings around in Thunderbird and got it to send ELHO [10.0.22.10] like it should, but after sending one message fine with that, I continued to get the blacklisted message.

As far as I can tell, the USF mail server will add internal IP addresses to its blacklist if the client saying ELHO with an internal IP address is coming from an external USF address. This may be due to their policy of no unauthorized switches, hubs, or routers within their network policy. I will continue to resort to using Tor to send my USF e-mail.

Recently I started using OpenDNS (a very good service by the way). I have had no problems and the internet is snappier due to less time looking up IP addresses. I have had (and am still having) just one problem: sending mail using my college e-mail address.

I use Mozilla Thunderbird for just about all my e-mail accounts; this includes my college e-mail address. For some strange reason when I attempt to send an e-mail using the school’s SMTP server when I have OpenDNS configured, the server responds back that my IP address is blocked from sending e-mail. The only thing I can think of is that the way Thunderbird sends its EHLO when on OpenDNS causes the server to not allow me to relay through it. This is certainly something wrong with either Thunderbird 1.5 or USF’s mail servers, not OpenDNS. I have currently reverted to sending my college mail through the Tor Anonymous Network until I can figure out how to fix this problem.

Update: I have found the problem; and no, it is not OpenDNS.