The third and wonderful “conclusion” to the Pirates of the Caribbean trilogy was released last week, and I had the opportunity to take my wife to go see it two days after it came out. Suprisingly, the crowd at the movie theater was small, with the show being only 3/4 of the way filled. But, that’s to be suspected with the college crowd almost completely gone for summer.

The movie is slow to begin, but quickly ramps up once the underlying story is presented. Then, when you least expect it, it hits the ground running with a nice full-town battle ensuing between allies (?) and foes. ‘Tis unusual without the biggest character of the story, Jack Sparrow, present. Fret not, however, as his re-appearance is one of peculiarity, but undoubtedly reminds you of the Jack Sparrow you knew from the other two movies.

As many people have claimed, there seems to be more battles and more fighting in this movie than in the past two. This, I can agree with, but likewise disagree with. The difference between At World’s End and either of the other two movies is the complete interweaving of all characters that had been introduced up to the final movie. A lot of drama and arguing ensue, yet there’s always the ever-so-often hint of humor.

One of the more enjoyable aspects of this movie was the addition of more “traditional” things from the Pirates of the Caribbean ride at Disney. You hear more songs and see things that are oddly reminiscent of the ride, should you have had the wonderful opportunity of riding it before.

Overall, this nearly 3-hour long adventure is one well suited for any Pirate fan, and in my case, I can only hope the DVD is right around the corner.

4.5 / 5 Stars

So, I now have one of our new servers sitting in a datacenter in Dallas. It is to replace one of our dedicated servers we are renting through The Planet. Well, our client’s website is doing extremely well right now and is averaging roughly 2,000 hits per day. This is one of the various eCommerce websites we have built for various customers. So, credit card data does get transmitted (always securely) between the database server residing on the dedicated server. Well, in order to minimize downtime for our customer’s website and to retain no loss of data, we have to do something about database connectivity between the old server and the new server. Luckily, MySQL is resilient enough to allow for remote connections, and as long as the latency between the servers isn’t bad, the website will operate at the same rate as normal.

However, the difference between connecting to a database residing on localhost and a database server residing on some other machine is the type of connectivity. By default, connections are unencrypted, so eCommerce information should NOT be transmitted in this manner. We need to transmit it over SSL-style connections. Again, MySQL is resilient enough to have these features built-in, assuming you compiled your server with SSL support.

I began by taking a copy of our customer’s database and sending it over to the new server:

oldServer> mysqldump -u root databasename -p > databasename.mysql
oldServer> scp databasename.mysql newserver:/home/customer/databasename.mysql
oldServer> ssh newserver
newServer> mysql -u root databasename -p < /home/customer/databasename.mysql

No problems were encountered here. So, the difference between SSL connections using SSH and SSL connections using MySQL is that MySQL requires SSL certificates and keys, much like web servers and mail servers do. However, you don’t have to purchase one of these. You CAN use self-signed certificates, as long as you have access to the Certificate Authority certificate file (shouldn’t be a problem if you are acting as the Certificate Authority). I’m not going to go into signing your own certificates, but there are several great websites that tell you how to do this, such as this one.

So, I did the usual things necessary to create my certificate (since I act as the certificate authority for my company), and copied the certificate data into the following locations:

newServer> cp /root/sslcerts/newServer.key /etc/ssl/private/newServer.key
newServer> cp /root/sslcerts/newServer.crt /etc/ssl/certs/newServer.crt
newServer> cp /root/sslcerts/CA.crt /etc/ssl/certs/CA.pem
newServer> cd /etc/ssl/certs
newServer> /usr/bin/c_rehash

I followed the same pattern for the CA certificate as everything else that was in that directory. All extensions were .pem. Note that openssl generates PEM formatted certificates and keys anyways, so it is perfectly legal and acceptable. c_rehash is used to parse the /etc/ssl/certs directory for new certificate authority certificates and create a symbolic link that has a name that’s a hashed value of the certificate. Read the man page for c_rehash for further information.

Anywho, everything was in their respective location, and I had added the following lines in my /etc/mysql/my.cnf file (under the server section):

ssl-ca = /etc/ssl/certs/CA.pem
ssl-key = /etc/ssl/private/newServer.key
ssl-cert = /etc/ssl/certs/newServer.crt
ssl-cipher = ALL:-AES:-EXP

I started MySQL and no errors were detected. As the MySQL Manual states for SSL connectivity, you issue the command show variables like ‘have%’ to show if you have SSL connectivity available. Here’s what mine showed:

mysql> show variables like 'have%';
+-----------------------+----------+
| Variable_name         | Value    |
+-----------------------+----------+
| have_archive          | NO       | 
| have_bdb              | YES      | 
| have_blackhole_engine | NO       | 
| have_compress         | YES      | 
| have_crypt            | YES      | 
| have_csv              | NO       | 
| have_dynamic_loading  | YES      | 
| have_example_engine   | NO       | 
| have_federated_engine | NO       | 
| have_geometry         | YES      | 
| have_innodb           | DISABLED | 
| have_isam             | NO       | 
| have_merge_engine     | YES      | 
| have_ndbcluster       | NO       | 
| have_openssl          | DISABLED | 
| have_ssl              | DISABLED | 
| have_query_cache      | YES      | 
| have_raid             | NO       | 
| have_rtree_keys       | YES      | 
| have_symlink          | YES      | 
+-----------------------+----------+
20 rows in set (0.00 sec)

Well that’s interesting, SSL is disabled. After a few hours of trying to figure out what this is, including starting SSL with those configuration options on the command line rather than through the my.cnf file, I found out the culprit of this was the ssl-cipher line in the config. Even setting this to just ALL caused the same result. However, when I removed that option and restarted MySQL, I got the following results:

mysql> show variables like 'have%';
+-----------------------+----------+
| Variable_name         | Value    |
+-----------------------+----------+
| have_archive          | NO       | 
| have_bdb              | YES      | 
| have_blackhole_engine | NO       | 
| have_compress         | YES      | 
| have_crypt            | YES      | 
| have_csv              | NO       | 
| have_dynamic_loading  | YES      | 
| have_example_engine   | NO       | 
| have_federated_engine | NO       | 
| have_geometry         | YES      | 
| have_innodb           | DISABLED | 
| have_isam             | NO       | 
| have_merge_engine     | YES      | 
| have_ndbcluster       | NO       | 
| have_openssl          | YES      | 
| have_ssl              | YES      | 
| have_query_cache      | YES      | 
| have_raid             | NO       | 
| have_rtree_keys       | YES      | 
| have_symlink          | YES      | 
+-----------------------+----------+
20 rows in set (0.00 sec)

I have filed a bug with MySQL about this, because it’s a critical flaw, not being able to specify which Ciphers you wish to allow.

So, now that I see SSL connectivity is allowed, I need to create an account and fully restrict it to require SSL connections. This is done in my grant statement. Full instructions on Granting with SSL Requirements are available in the MySQL Reference Manual. So, in MySQL, I issue the following command:

mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON `databasename`.* TO 'customer_dbuser'@'192.168.1.1' \
    -> IDENTIFIED BY 'goodsecret' \
    -> REQUIRE ISSUER '/C=US/ST=Texas/L=College Station/O=Company Name/OU=Certification Authority Name/CN=My Root Certificate Authority' \
    -> SUBJECT '/C=US/ST=Texas/L=College Station/O=Company Name/OU=Department/CN=oldserver.domain.com/emailAddress=admin@domain.com' \
    -> CIPHER 'DHE-RSA-AES256-SHA';

The ISSUER and SUBJECT lines come from what you filled out when creating the certificate authority CSR and the host CSR, respectively. You can get this value by looking for the issuer and subject lines in the ouput from the following command:

shell> openssl x509 -noout -in oldServer.crt -text

The CIPHER is what openssl uses by default for creating SSL certificates. If you used a different cipher when creating the key, CSR, and Certificates, then specify it accordingly.

So, after having those problems and now having SSL connectivity (half-way) completed, it’s time to move onto the old server. I send over the newly created SSL certificates to the old server via SSH and install them in roughly the same places:

oldServer> cp /root/sslcerts/CA.crt /etc/ssl/certs/CA.pem
oldServer> cp /root/sslcerts/oldServer.crt /etc/ssl/certs/oldServer.crt
oldServer> cp /root/sslcerts/oldServer.key /etc/ssl/private/oldServer.key

I then added the following lines under the client section in the /etc/mysql/my.cnf file:

ssl-ca = /etc/ssl/certs/CA.pem
ssl-key = /etc/ssl/private/oldServer.key
ssl-cert = /etc/ssl/certs/oldServer.crt
# ssl-cipher = ALL:-AES:-EXP

The specification of certificate information on the server as well as certificate information on the client is ESSENTIAL in the success of this. RTFM, if you haven’t already.

So, time to fire up the connection to see if it works:

oldServer> mysql -u customer_dbuser -h newServer -p --ssl-ca=/etc/ssl/certs/CA.pem --ssl-key=/etc/ssl/private/oldServer.key --ssl-cert=/etc/ssl/certs/oldServer.crt
Password: <enter goodsecret>
SSL Connect Failed

If you fail to put anything in the client section of the my.cnf file and DONT specify a ssl-key or ssl-cert on the command line, you will see a generic SSL connection error on the client side and the following error message on the server’s logs (IF you have debugging turned on):

tls peer did not respond with certificate list

This even occurs if you only entered REQUIRE SSL for the client and nothing further. But, this was not my case. I spend yet another few hours trying to figure out what happened with this and finally recompiled the newServer MySQL with the debug option. After trying again and parsing the debug files, I found the following line:

Error:  "error:00000005:lib(0):func(0):DH lib"

This was in the sslaccept function. After Googling this for about an hour, I found nothing relevant to the problem. It’s a generic openssl error, assuming that you are using openssl and not another SSL library set.

To make a long story short, the error message was extremely misleading and it boiled down to a permissions problem. I coulda sworn that all my permissions were correct, but it turns out they weren’t. Here’s how it was setup:

newServer> ls -alF /etc/ssl/private 
drwx------ 2 root root  184 May 19 21:47 ./
drwxr-xr-x 5 root root  152 Apr 19 19:52 ../
-rw-r--r-- 1 root root 3247 May 19 20:32 newServer.key

For those still unfamiliar with Linux, if you look at the permissions for ./, you’ll notice it’s Read, Write, and Execute for the owner ONLY. This means that nobody else could traverse into this directory, EVEN THOUGH the newServer.key was at least readable by everyone.

Moral of the Story

Double check your permissions.

Of all the things Microsoft can do, this has got to be the lowest of the low. Read the story on CNN Money.

Essentially, Microsoft is gearing up for the biggest series of law suits since SCO made their ridiculous claims. Who’s going to be the target? The Open Source community. Microsoft is about to open a can of worms against a group of individuals who’s significantly more expansive and quite a bit more populous than their own company. And why? For money. As if the company doesn’t make enough money on their own, they’ve decided to be greedy and go out to fight other products that cost…nothing? That’s right, Microsoft is wanting to sue (get this) the USERS of software that compete against their patents - not the WRITERS of these pieces of software. Essentially, that’s the same things as suing everyone in America for eating a patented hot dog. Absurdity wreaks from Microsoft’s claims.

Not only is Microsoft getting ready to sue these USERS of software, but they’re doing it over FREE products. So, this turns out to be the same situation as a bread manufacturing company suing everyone in the world on the grounds that Jane Doe made her bread from scratch instead of buying the bread manufacturing companies bread. Again, absurdity.

Once again, situations like this really make me hope that Microsoft begins disintegrating due to government hooplah and pushes to use open source software rather than the greedy poorly-constructed giant’s software.

Well now, here’s an interesting problem I had with Perl on the new Mac Xserve running Intel Xeon 64-bit processors. One of our customer’s had a CGI website (cringes) and was using DBD::MySQL to access the MySQL database. Upon initial observations, permissions had been setup incorrectly and the httpd.conf file was not setup properly for CGI executables.

Past this, I find that the server has dependency problems. This was found due to the following error message in the /var/log/httpd/error_log file. The particular error was:

[Mon May  7 15:43:45 2007] [error] [client xx.xx.xx.xx] Premature end of script headers: /Library/WebServer/CGI-Executables/webevent.cgi
install_driver(mysql) failed: Can't locate DBD/mysql.pm in @INC (@INC contains: /Library/WebServer/webevent/lib /System/Library/Perl/5.8.6/darwin-t
hread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Per
l/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /
System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at (eval 8) line 3.
Perhaps the DBD::mysql perl module hasn't been fully installed,
or perhaps the capitalisation of 'mysql' isn't right.
Available drivers: DBM, ExampleP, File, Gofer, Proxy, Sponge.
 at /Library/WebServer/webevent/lib/db/dbconnect.pm line 58

So, I proceed to install Perl modules. But wait, CPAN’s bitching about an upgrade to CPAN being available. Fine, let’s give it what it wants:

CPAN> install Bundle::CPAN
 
-- CPAN INSTALLS UPDATE --

Cool, now time to move to installing DBI:

CPAN> install DBI
 
-- INSTALL SUCCESSFUL --

Now for the last bit, DBD::mysql:

CPAN> install DBD::MySQL
 
<snip>
t/utf8...............install_driver(mysql) failed: Can't find 'boot_DBD__mysql' symbol in /Library/Perl/DBD-mysql-4.001/blib/arch/auto/DBD/mysql/mysql.bundle
at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
 
2 tests skipped.
Failed 25/28 test scripts. 413/418 subtests failed.
Files=28, Tests=418,  2 wallclock secs ( 1.54 cusr +  0.35 csys =  1.89 CPU)
Failed 25/28 test programs. 413/418 subtests failed.
make: *** [test_dynamic] Error 255
</snip>

Damn, talk about something unexpected. After reading a few emails, forums, and getting down right frustrated with everything, I find this email note. This isn’t completely correct, in that it turns out you don’t have to install another copy of MySQL in some temporary location for the libraries - you have everything you need, assuming you’ve already installed XCode Tools.

So, what DO you have to do? The following:

shell> cd /path/to/.cpan/build/DBD-mysql-4.001/
shell> perl Makefile.PL --testuser test --testpassword test --testsocket /var/mysql/mysql.sock --cflags="-I/usr/include/mysql" --libs="-L/usr/lib/mysql -lmysqlclient -lz -lm"
shell> make
shell> make test (should work now) 
shell> make install

Understanding of why Perl was so broken

Well, it wasn’t exactly Perl’s fault. It’s MySQL that comes on Apple’s Xserve. Apple, you question with an unquestionable doubt in your mind? Yes, Apple. Check this out:

shell> mysql_config --libs
-arch ppc64  -arch x86_64 -pipe -L/usr/lib/mysql -lmysqlclient -lz -lm
shell> mysql_config --cflags
-I/usr/include/mysql -fno-omit-frame-pointer  -arch ppc64  -arch x86_64 -pipe

Now isn’t that funny! On my new Xeon Xserve, the architecture specifications (which for some odd reason appear in BOTH the cflags AND libs flags which normally appear ONLY in the cflags) are for BOTH ppc64 AND x86_64… AFAIK, this server is Intel 64-bit based, not PowerPC any longer. So, when Perl goes through and autoconfigures its switches, these architecture flags cause the tests to blow up because it’s expecting a completely different set of tools that are expected to work on the PowerPC architecture.

Anywho, it’s working now, and that make me (and my client) happy.

Well, it has been quite a few days (maybe closer to 2 weeks) since I last updated. So, in an effort to get everyone up-to-speed, and to have a somewhat politically motivated post, I’m taking extra time out of my busy hectic life to give you, my audience, and update.

First and foremost, I’ve been busier than ever at work (CIS). I can’t remember if I’ve mentioned it before, but I switched to Customer Applications from the Operations group. It meant a new title (yay for promotions), more money (always helpful), and likewise a plethora of new tasks and responsibilities. Then again, it doesn’t exactly help that the project that I’m working in is in serious distress. But luckily, I’m able to program quick enough to put me 12.5 hours ahead of schedule today. Go me. Hopefully we’ll be able to bring this project back on-track to the point that we’ll be able to actually deliver it on-time. For the most part, I’ve been able to program the past week or so, but before that I was doing a combination of consultations, analysis, and down-right project engineering for this customer because they needed everything including servers, SSL certificates, etc.

Second, Melissa and I are still moving things over from the apartment into our new house. We have most of everything (large things at least - we’re missing quite a few smaller items, and still my big fiberboard desk which will take a boheameth to transport over to the house). Most evenings are spent going to the apartment, gathering stuff, and moving it back to the house. The past couple of nights, though, we’ve had reprieve due to the bad weather and having to go to Houston for various things (such as Melissa’s recital, having a wonderful Italian dinner with her grandmother, etc.). This relaxation time has given my back a break, but sadly I’m still not getting much sleep at night. I’m anxious for the day when we finally pay-off the new mattress that we’re getting - it should cure all of our problems as far as sleeping is concerned.

As far as my business is concerned, I have a customer for my business who seems to think I can be at their beckoning call 24/7/365 for programming issues. I agree that for server issues they have to be resolved FAST (and for the most part I make certain they are taken care of at that speed), but programming issues take time to analyze, engineer, program, test, and deploy - not something that a large set of changes can be done in a short amount of time. Not to mention, the fact that this customer almost expects me to come to their office location at the drop of a dime is absurd - especially when the requests they have (which have to happen immediately) can be typed up and sent to me - that’s all that’s going to happen when I get them, type them up and put them in my bug software. Why waste my development time when you can type up the requests? These are the type of people that really push me to get out of this business.

Additionally, for anyone who is considering getting webhosting (and is not smart enough to go to www.cerberusonline.com and sign up for the best hosting in the world through that website!) should NEVER consider HostGator for a hosting provider. We have some reseller accounts through them and they have the WORST restriction, signup, and fee policies on the face of the planet. I won’t get into details, but trust me when I say do not trust them.

Well, my ride is almost here, so I’ll update this post about Vetos and Cheerios later. Give me a holler if you haven’t talked to me in a while. AIM: Nschinden15