In preparation for our YippieMove ’09 unveiling next week (you can get a pre-announcement sneak peek now) WireLoad is today releasing version 0.2 of OFC WireLoad Edition.

When we began work on the new Status page of YippieMove ’09 we searched high and low for good charting software, both server based and dynamic. OFC 2 came out on top. OFC is an excellent Flash charts program written primarily by John Glazebrook. It supports several different chart types including line graphs, bar graphs and pie charts. It dynamically reads its data using JSON.

To meet WireLoad’s specific design goals for YippieMove’s status page a number of modifications were made. We needed a particular look and feel, we wanted the fastest possible load times and there were a couple of glitches when using our particular data sets that needed fixing. Since many of these changes were very specific to our use case we opted to just branch the software and not disturb the ordinary development of OFC. This branch is what we are releasing today as OFC WireLoad Edition 0.2. We hope it will benefit the OFC community and perhaps interested parties will be able to find pieces and parts they can use elsewhere.

OFC 2 Hyperion was used as the base. An overview of the changes can be found below.

Visual Changes

• Support for a gradient background.
• Chart encompassing border.
• Look of axises changed.
• Pie chart drop shadow.
• “Fuzzy” grid lines sharpened up.
• New ‘spinner’ progress indicator.

Functional Changes

• Fast loading progress indicator which starts showing before the whole flash file has downloaded and remains until the graph data has been loaded.
• New on the side legend for pie charts.
• New build script for building without the Windows specific Flash Develop.

Size Reduction

• Each chart type can be enabled or disabled at build time, which enables a site specific light-weight build. Many individual functions such as image saving can similarly be disabled.
• Embedded fonts are no longer required for 0-90 degree rotated X axis labels or rotated Y axis labels.
• Reduction of some redundant code.

The final version used on YippieMove’s status page is about 50KiB, down from 200KiB in the original.

If you want to set OFC WireLoad Edition 0.2 up for a test, be aware that when using IE7, SWFObject did not always properly detect the running Flash version in our testing. So you may see unexpected degradation to your non Flash content. Updating to the latest version of Flash seems to resolve the issue, regardless of your installed version – it’s the reinstalling itself that fixes the problem. Word on the net is that there is an installation corruption issue happening to some IE7 users.

Downloads and a complete change log can be found on WireLoad’s open source page.

About three years ago, when we first installed our mailserver, we decided to give Postgrey a shot. It worked pretty well for about two years. It did pretty much what we needed it to do — block SPAM. Since everyone here uses either a Mac or a Linux setup, we didn’t have a big need for scanning incoming emails for virus. Well, the situation didn’t change much, but the amount of emails going through our system did. We’ve started to see more and more SPAM going through the graylisting as spammers become more sophisticated. However, over the past few months, we’ve received a few complaints from customers about emails that did not go through (only a few, but that is serious enough). Hence we needed to take action.

Since our system is pretty straight forward (Postfix + DBmail), our conclusion was that it was the graylisting that caused us trouble. We took a fresh look on the market and realized that SpamAssassin probably was the best way to go. Thanks to FreeBSD’s ports, we were able to replace Postgray with SpamAssassin in less than an hour.

This morning when I woke up, I took a look at the maillogs. SpamAssassin seems to be doing it’s job pretty well, as it caught a bunch of SPAM. Bye Bye Postgrey. Welcome SpamAssassin.

‘If Joomla! is Linux, then WordPress is Mac OS X. WordPress might offer only 90% of the features of Joomla!, but in most cases WordPress is both easier to use and faster to get up and running.’

Over the course of the last few years, I’ve been in charge of putting up a number of websites for various companies, often as favors for friends. In most cases, I’ve ended up using one out of two solutions: Joomla! and WordPress. While both of these projects have evolved greatly over the last few years, they are vastly different. Joomla! has always been intended as a ‘fit-all-your-possible-needs’-kind of CMS solution, while WordPress was developed as a blog with CMS capabilities. Recently WordPress has opened up to allow its users to set up a site with static-only material (with the option of a blog-page), without having to hack the code. Hence it’s one step closer to being a direct competitor to Joomla!.

Joomla!’s Control Panel	WordPress’ Dashboard

I will probably step on a few peoples feelings here, but I will argue that Joomla! is an example of a poorly managed open source project and that WordPress is a very successfully managed one. Certainly I don’t mean that Joomla! is a useless piece of junk, but that the lead developers have quite a bit to learn from WordPress. The main thing that Joomla! is vastly behind on is usability. While it is true that Joomla! 1.5 is a step in the right direction, it is still light years behind WordPress. Let me illustrate with two examples of common tasks.

Example 1: Create a blog-post with an image

Joomla!

1. From the ‘Control Panel,’ click ‘Add New Article.’
2. There are two image buttons. If you use the wrong one, you won’t be able to upload an image (as you will only browse the existing images). You must use the one below the text field.
3. Select a ‘Title,’ the right ‘Section’, and then the right ‘Category.’
4. Write the content and save.

WordPress

1. Select QuickPress in the Dashboard.
2. Click on the image icon and upload the image.
3. Select title, write your content and press publish.

‘Add New Article’ in Joomla!	‘QuickPress’ in WordPress

Example 2: Create a static page accessible from the menu

Joomla!

1. From the ‘Control Panel,’ click ‘Add New Article.’
2. Select a ‘Title,’ the right ‘Section’, and then the right ‘Category.’
3. Write the content and save it.
4. From the top-menu, select ‘Menu’ and ‘Main Menu’ (assuming you want to add it to the main menu.)
5. Click ‘New.’
6. Select ‘Internal link,’ and ‘Articles,’ and then finally ‘Article Layout.’
7. Fill in the title of the object as well as the parent item.
8. In the column to the right, you now need to browse your list of articles and select the desired article.
9. Press ‘Save.’

WordPress

1. From the Dashboard, click ‘Pages.’
2. Select ‘Add New.’
3. Fill in the title and contents.
4. Select the parent item (if other than root.)
5. Click ‘Publish.’

‘Add New Article’ in Joomla!	‘Add New Page’ in WordPress

Let’s step back for a minute and imagine the following scenario: you’re in charge of putting up a website for a company. They might want to put up about 10 or so pages with various information. According to my experience this is a pretty common situation. You can do this with either Joomla! or WordPress – both are fully capable of delivering this. Assuming you’re going to buy a template to solve the design issue, it will probably take you about an hour with either of the software to get to the first draft (assuming you’ve been working with them in the past.) So far so good. This is where they start to differ. With WordPress you’re pretty much done by now. However, with Joomla!, you’ll probably have to spend another hour or two just trying to re-organize the different modules to fit the template you bought (in many cases, just to get the basics to work.) Next you will end up spending even more time trying to figure out how to re-organize the different menus. You need to link up a particular document to a particular menu-entry (as illustrated above.) If you want a blog-feed, you need to set up a dedicated section or category (I still don’t really know the difference between the two.) Moreover, you need to select the ‘style’ of blog you want.

‘New menu item’ in Joomla!	‘Modules’ in Joomla!

Let’s say you managed to figure all of that out and that you got the site ready. Now it’s time to hand over the site to the customer. There will obviously be some training involved, and here’s another crucial difference between Joomla! and WordPress. Training someone to learn WordPress takes (in my experience) less than 30 minutes, and they truly understand it. Training someone to use Joomla! takes at least an hour, and they still don’t really understand it.

Again, I’m not saying that Joomla! is useless, it’s that WordPress is a more intuitive piece of software. Let me throw an analogy out there that will probably help you better understand my point. If Joomla! is Linux, then WordPress is Mac OS X. WordPress might offer only 90% of the features of Joomla!, but in most cases WordPress is both easier to use and faster to get up and running. I use and love Linux, it just doesn’t have that elegant touch to Mac OS X does.

To Joomla!’s defense, there are at least two scenarios I can think of where Joomla! is a better fit than WordPress. The first one would be eCommerce. If you install VirtueMart on Joomla! you can be up running with an eCommerce site pretty quickly. However, the problem is that it does not feel like it is a part of Joomla!, but rather as a 3rd party module that works in Joomla! (which is pretty much what it is.) The second one would be a site where you need to have multiple levels of permissions (ie. an extranet). WordPress only offers three levels of permission (public, private, and password protected), while Joomla! is much more flexible.

‘Global Configuration’ in Joomla!	‘General Settings’ in WordPress

Joomla! is not doomed. It just has a long way to go when it comes to usability. WordPress has really been developed by the KISS-principle, while Joomla! appears to have been developed to solve every problem on Earth (by engineers, for engineers). Going back to the two problems I mentioned above, where Joomla! beats WordPress. I think it would actually be less of a challenge to add support for eCommerce and more permission levels to WordPress, than it would be to improve the usability in Joomla! to reach WordPress’ level.

Just as a side note, a quick line-count on the latest versions of both software reveals that Joomla 1.5.9 has 350,975 lines of codes, while WordPress 2.7.1 has a mere 159,682 (might not be completely accurate, but that’s what ‘wc -l’ said). Hence, even if WordPress only offers 70% of the features of Joomla!, which I am pretty sure it does, their code is written much more efficiently.

It’s exciting times here at WireLoad. We’re currently in the works of developing a major new version of YippieMove. While we were doing this, we searched the Open Source community for an awesome data visualization tool. The best thing we found was Open Flash Chart. However, we were not completely happy with it, and put our engineers to work on improving it. The result is something we call Open Flash Chart – WireLoad Edition. True to the Open Source mentality, we’ve published the modified version in a new section on our site called Open Source.

This is the intial version 0.1. The next version is already in the works, and we will be releasing it as soon as we think it is ready for the spotlight.

Since we started writing here at Playing With Wire, we’ve managed to write two articles about Cacti. In January 2007 we introduced Cacti in the article “What’s Your Utilization, Kenneth?“. Six months later we wrote another article about how to monitor remote hosts with Cacti.

While the setup we described in these article worked out great, there were a few things that we didn’t really like about the setup:

1. We connected with SSH from the Cacti server to the server we wanted to monitor (security issue).
2. We were using regular SSH tunnels. While these are great, they do have a tendency to die (reliability issue).
3. Due to security and portability, we wanted to isolate Cacti to a separate server (or VM).

1. Turning the tunneling around

The reason why we didn’t like to have the Cacti server connecting to the servers was simply that we needed one more user account on the remote servers. If these are production servers, it’s desirable to keep the publicly accessible user accounts to a minimum.

As it turned out, replacing the ‘-L’ with a ‘-R’ in the tunneling command turns the tunnel around. Instead of opening a port on the local machine, it opens a forwarded port on the remote server. By doing this, we can connect from the remote server to the Cacti server and still fulfilling the same purpose (but without creating an additional user on the remote server).

2. Creating more reliable tunnels

One of the major problems we were having with the setup was that the tunnels died for one reason or another. We initially solved this by writing a bash-loop that automatically reloaded the tunnel if that occurred. However, we were still experiencing some problems with dead tunnels.

The solution to the problem was autossh, a simple front-end to SSH that keeps the tunnel alive.

With autossh, we could simply launch the tunnels at boot-time on the remote server (in rc.local) without having to worrying about them dying. As we were implementing this on a number of servers, we wrote a small bash-script that launches autossh with the server-specific settings. The script looks like this:

#!/bin/sh
REMOTEPORT=2001
MONITORPORT=29001
/usr/bin/autossh -M $MONITORPORT -q -f -N -R
127.0.0.1:$REMOTEPORT:127.0.0.1:161 [email protected]

This script creates a tunnel on port 2001 ($REMOTEPORT) on the Cacti host (cacti.server.tld) that goes to port 161 on the local machine (in this case, the server we want to monitor).

Isolate Cacti

In order to make our monitoring both more secure and portable, we felt that we wanted to isolate the monitoring to a separate Virtual Machine. This was easily done by creating a new VM under VMware Server. If you’re lazy, there are ready-to-use VMware images to download on the Cacti forum.

Bonus: Monitor several hosts with one tunnel

While reading the Cacti forum the other day, I ran across this article that talks about SNMP Proxies. By adding an extra entry in the SNMP config file, it’s possible for a single host to relay SNMP information about the other hosts on the network. This is very useful if you’re trying to monitor more than one host on the same network, as you don’t need one tunnel per server (beware that this creates a single-point-of-failure though).

Conclusion

After implementing these changes, we feel much more comfortable with our Cacti setup. Not only is it more reliable with more robust tunnels, but it’s also more secure.

The next Cacti-related task we will be looking at is to design custom plug-ins to monitor our own apps.