Saturday, November 11, 2006

Smart Ideas That Pay - Parked Pages

Heres an Idea that gave me 33 new income generating web sites. I have, as well as my associates, reserved many specific domain names for later use. Usually these domain names are parked at the registrar doing no harm... except generating them income and not me! So I decided to make my own income generating "parked" page. I take one of the unused domains and make a nice income page.. here at http://park.godlc.com. Once that was completed, I simply aliased all the unused websites to the "parked" page. Very nice... I now have 33 income generating web sites. I used the server environment variables to display the name of the "parked" page. If you have any parked pages, make the parked page yours and not theirs!!

Written by Dan Sharp
www.sharprez.com
www.GuideCycle.com

Tuesday, November 07, 2006

Multi Platform Integration

I have been programming way too long, too many programming languages running around my head. Todays blog is about web site maintenance. I recent took over a website for a new client. It was a graceful transition, meaning that the previous website developer was leaving and no longer wanted to work on the website. After getting my hands in it code... I wonder if this spaghetti code wasn't the reason this guy was leaving town.
A small order from the customer can be a big bill. The customer asks "Please change our calendar program to do this and then that." Okay, how do you like mixing PHP and Perl with Access and MySQL? That was the hidden question.
The reason we have a potpourri of back end technology is that several developers have worked on this site. Oh, and they each have their talents in completely different technologies.
Well I was actually impressed how easy it was for me to change PHP code, I've never actually used this language before today. I'm a Perl developer, and wouldn't change. I won't knock any other programming languages either, because they all have their place, or they wouldn't be around. The mechanics of the modification mostly involved SQL changes in how data was grouped and displayed. So the framework of the application remained. Looking under the hood can be intimidating, but careful examination revealed only a SELECT statement and some table formatting in PHP was all that was required.
At what point do we revamp the whole web site... ? Fortunately, this customer is planning an overhaul, and will be planning carefully to keep spaghetti code from happening again. A word to web site owners, if your not the developer yourself, be sure to ask what the back end technologies are. Then research what it would take to replace a developer skilled in the required technologies. You may find talent hard to find, and technologies expensive to maintenance.
Article Written by Dan Sharp
www.guidecycle.com

Friday, November 03, 2006

LWP Segmentation fault - Plesk - Red Hat FC4

Its really interesting to see how my goals and projects progress over time. I'm talking about this blog, and its purpose, a project in its own right. The purpose of this blog is to promote my websites, blogs do that well. So I've got to come up with content right? Well, here it is, that is to say.... here is content other than direct references to my wonderful web sites, which you must absolutely see. I have decided to write about select programming tasks that I worked on the day I write in my blog. In hope that it can help someone else with a similar problem....and myself at the same time. :) Nice!

Today, my task was to fix a web site I had recently moved to a new server. This task was for a customer moving from a domain hosting account to a dedicated server. When the domain moved it had inadvertently broke the credit card processing system. The credit card interface was a missing a required Perl module. Could it get any worse for the customer? It will for me later. The culprit was that the Crypt::SSLeay Perl module used for https protocol was not installed. The https protocol is used to validate credit card information in real time. The server is a virtual dedicated server, so we have root access. But error reporting is not the greatest either, partly due to the soon to be discovered "Segmentation fault" error itself.

The online customers did not complain about the problem, because the system caught the error and told the customer the problem was with the communication to the credit card company, and not them, and to place call in their order. Not all was a disaster ... thank goodness. When enough customers called, I got called. So I look in the web logs for errors, I get nothing. I look in the transaction database, I see the message returned from the LWP::UserAgent module, said the Crypt::SSLeay Perl module was missing. So you don't miss anything the LWP::UserAgent module requires the Crypt::SSLeay Prel module when https protocol (encrypted) is needed.

Being new to the server, I decide to install the Crypt::SSLeay Perl module. This would not be hard, I've done this before. The install process said it needed OpenSSL installed, but it can't find it. Yup, it's becoming one of those chain reaction things.. more to go wrong, and it does. I find and install the latest OpenSSL. Reinstall Crypt::SSLeay Perl module to include the OpenSSL, and now LWP::UserAgent can use the https protocol.

Time to test, but what happens??? Server error, no CGI::Carp error. I run the script at the command prompt and I get the "Segmentation fault" but nothing to tell me why. Putting check in the code indicate its the Crypt::SSLeay Perl module I just installed. The bugger is, it compiled fine. This is where I thank the Internet, sure I find several informative articles, but not one for my configuration. I discover what I knew, Crypt::SSLeay Perl module is required. My biggest mistake was installing OpenSSL, since it was already installed, just not in the default locations. The solutions came in two parts, one the OpenSSL needed compiled in the correct location, and second the correct compatible version of OpenSSL was required for LWP::UserAgent and Crypt::SSLeay Perl modules.

Here is the configuration of the software. This is a dedicated server from http://sharp-resolutions.com . It consists of Plesk v8.0 and Red Hat Fedora Core 4, and you will see that Plesk made a simple installation, complex.

Path for OpenSSL is not in the default location. For Plesk 8.0 it is here:

/usr/local/psa/admin/sbin/openssl

Correct versions:

OpenSSL is 0.9.7f
LWP 5.69 (Perl module)

Best way to install Crypt::SSLeay Perl module:

yum install perl-Crypt-SSLeay

By Dan Sharp
Copyright 2006 Sharp Resolutions
Okay to use this article as is, unmodified.