Previously this site was run under the Mambo CMS project. Unfortunately due to code quality, security concerns, and other issues, I have decided to switch. In my opinion, one of the biggest issues faced with Mambo at the moment, is that plugin files require a specific format and sequence of checks to verify things like remote file includes and sql injections don’t occur.

Recently, a friend of mine sent an e-mail to me that bounced. After checking his server logs, he was receiving the following error:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure

It was a very interesting error to say the least. After some digging, I found that the new OpenSSL breaks mail. They claimed that this was due to an API change, but looking at the change list between 0.9.8d and 0.9.8e, no API change was noted. After some digging, I found that the problem is a programming error in the TLS patch for qmail. Read on for details.

Unfortunately there have been several severe security issues with Mambo lately, at least from my perspective. Several weeks ago, my site was defaced, and a search into the problem led me to several HTTP queries that seemed to override the mosConfig_absolute_path PHP variable in the URL. This variable was set to a remote web site and page. Even after a fresh install to fix the problem and after applying all security patches, my site was still vulnerable to the same attack. I was furious and determined to find the cause and permanent solution. Read on for the fix.

Today I was asked to take a look at an error in the Google Sitemap Tool. The problem was when this Python script was run by Mike, he was getting an malloc error. After some quick searching of the code and some newsgroups, I narrowed the problem to a loop that loops through the log lines. This is NOT a Python error as some in the newsgroups have suggested. There is a simple fix by simply altering the loop to to process each line rather than loading the entire file into memory. If you’re just interested in the patch, it can be found here. Simple instructions can be found here. Read on for the detailed information.

Recently someone mentioned to me that my site registration wasn’t working. He also mentioned that it was a Xaneon Extension issue and I wasn’t the only person to experience it. Although he was able to provide some examples that people had done to fix it, they appeared to be very complex and I couldn’t see how they would even work. Since I had been looking through the default Mambo /includes/sef.php code, I had a feeling I knew what the problem was and I was able to come up with a very simple fix.

Lately I started using the Xaneon Extensions component for Mambo to generate nicer URL’s for my site. The typical /content/view/28/31/ links were starting to irritate me, and I knew there had to be a better way. Not only that, but after digging through the code on my last projects, I noticed that the simple existence of the file components/com_sef/sef.php will cause that to be used instead of traditional includes/sef.php file. This means that the whole Search Engine Friendly capability can be achieved by installing a specifically named component. After looking around I found the Xaneon Extensions project which seemed best because it used this component style SEF ability and it also seemed to have the most features. No modifications to existing sources was impressive too. The one problem I had after using it is that there is no support for the Gallery component. Therefore all the Gallery URL’s take the form /component/ option,com_gallery/ Itemid,28/ set_albumName,73nova/ include,view_album.php/ if my Gallery component fix is used, and even worse, /index.php?option=com_gallery& Itemid=28& set_albumName=73nova& include=view_album.php if my fix is not used. Therefore, I decided to look at the possible solutions and came up with my own Gallery Xaneon Extension and Pathway fix. Both are inspired from the LogicX solution with fixes and design improvements. Read on for the details.

While using the Gallery project embedded in Mambo, it does not correctly respect the SEF URL parameter in the configuration file. Some of the URLs can’t be represented in the SEF URL syntax, because they point to the actual Gallery location. These are mostly the administration functions such as adding and removing pictures. The navigation and picture display, however, are controlled completely through the Mambo embedded component. After digging through the Mambo SEF code in a previous problem, I know that the SEF URL is converted correctly into the corresponding $_GET and $_REQUEST parameters, so therefore, they should not interfere with the operation of the gallery pages. This can be verified by manually converting the link. Fortunately I found a simple and elegant patch to fix the problem. Read on for the solution.

Recently I was getting some strange PHP errors from my Mambo site. The problem was an attempt to call a member function on a variable that was not an object. The actual error was:

[client 192.168.0.3] PHP Fatal error:  Call to a member function
   getAroGroup() on a non-object in
   /usr/local/www/mambo-4.5.2/includes/mambo.php on line 347

It was obvious that this was a Mambo issues since it’s in their includes folder, and after some digging I managed to find the problem.

There are times when you will have a project that multiple clients will be using and some of them may have permanent minor changes that need to remain even if bug fixes or code updates are made. Initially branches in CVS seem to be able to fulfill these needs, but the examples that the CVS documentation used had branches to separate to its own entity. Basically branches were only used as a bug fix branch for a particular early version. This way the bug fixes from the branch could be applied to the HEAD. I have found a relatively simple way to synchronize multiple clients each having their own changes using a single common HEAD as the generic project. Current development can be made against the head and when major releases are tagged, the release can be propagated to the clients at their own speed. The only requirement is that certain standards must be followed in order to be take advantage of the ability, but a certain amount of standardization should be performed anyway.

I have found patch files to be very helpful while using FreeBSD. Although I only use patch for altering program code, it could essentially be used in many other areas. Since not everyone is able to use CVS or Subversion because of skill level or have no write access to the repository, patch files are a basic, low level means of communicating changes to a particular file, without having to keep track of these changes yourself. This is especially important in code, since quick changes can quickly become out of hand. Patch files are also useful for the person implementing those changes. The patch file format that I currently use for tracking changes easily shows the differences between whole directory trees. This way you have a central location to view the changes that you’ve made. Another advantage is that patch automatically creates backup files for you so that if something goes wrong, you do not have to dig through the changes to fix the problem. This should get you started with using patch.