If you’ve never heard of iReport and Jasper before, you really ought to take a look at it. It’s a really impressive suite of reporting tools that can generate reports from pretty much any data source out there.

Almost exactly a year ago, we wrote a similar article on how to fix the launcher in version 2.0.x. While I’m sure Jasper improved iReport a lot during this time, they also managed to break the launcher in new ways with version 3.0.0.

This is how you can get it working (assuming you’ve downloaded it):

tar xvfz iReport-3.0.0.tar.gz
cd iReport-3.0.0/bin
awk ‘{ sub(“r$”, “”); print }’ startup.sh > startup2.sh
chmod +x startup2.sh
./startup2.sh

The commands above fixes two problems with the launcher. First we convert the line feed from DOS format to UNIX format (the awk-part). The second problem was that the launcher was not executable. If you just make the original launcher executable (chmod +x startup.sh), you will end up with this:

-bash: ./startup.sh: /bin/sh^M: bad interpreter: No such file or directory

Good luck, and have fun generating all those new cool reports.

If you’re a regular here at Playing With Wire, you’ve probably already read our articles about Cacti. While Cacti does do a great job on visualizing load on your servers, it does not provide (by default) alerts when a server goes down.

When we launched YippieMove we quickly realized that we needed a reliable 3rd party that could ping our servers from several locations across the globe to ensure that we were not experiencing any problems with the access to our site. As we are quite tech-savvy here at WireLoad, we had a hard time justifying paying more than a few bucks per months for a service like this, since the service is so easy to write (we actually did write our own uptime-monitor with alerts a few years back using Curl, Crontab and some other tools, but would rather outsource this service).

So the search began. We required a few thing for this service:

• Several servers across the globe that ping our servers.
• Cheap. Preferably free (we don’t mind some ads).
• Decent statistics showing response-times etc.
• Reliable alert system by e-mail (luckily most US Cell providers allow you to send email to your phone, using [email protected].)
• Must allow monitoring of both SSL and non-SSL servers.
• A minimum of 4 monitors (we needed to monitor playingwithwire.com, wireload.net, yippiemove.com [with and without SSL]), but it would also be great if we could monitor our mail-server.
• The more frequent the pings the better.
• No back-links required.

One of the most impressive sites we found was Pingdom, a small Swedish firm that is trusted by companies such as IBM, Loopt and Twitter (wow, they must spend more bandwidth on alerts than pings with Twitter for sure). What we really liked about Pingdom was the general look and feel of their site. It feels fresh, responsive and reliable. The pricing is definitely within reason: they charge $9.95 for their Basic plan, which includes 5 checks and 20 SMS.

The next site we stumbled upon was SiteUptime. The site has a decent look and feel (but does not come close to Pingdom). After examining their pricing, we realized that we needed their Advanced plan, since none of their lower plans allowed SSL monitoring. The price for this plan is $10 per month. While their site and visualization does not come close to Pingdom, they do give you 10 monitors, as apposed to 5 monitors with Pingdom, with their Advanced plan.

Another site we found was Pingability. The general look and feel of the site is OK, but the service offered was not great. The free plan requires a back-link (which we think is unacceptable for a professional site). At the same time the premium service, for $9.95, only offers one monitor.

Next up for review is Wormly. Priced at $9 per month, their Bronze-plan seems to be a reasonable alternative. The plan includes 5 monitors and they ping your server 5 times every 5 minutes, which is good enough. Unfortunately there’s a big ‘but’ — no SSL monitoring (at least as far as we can tell). That’s a deal-breaker. To Wormly’s defense though, they do offer something that sets them apart from the competition, namely the ‘Server Health Monitor.’ This service is something similar to Cacti (it definitely looks RRDTool-based), that visualizes server-load. However, they will probably have a hard time selling this service to security-concerned organizations, as they require a monitoring-client to be installed on the server (it’s hard to get this data otherwise).

Basicstate is the final service we will cover in this article. A lot can be said about Basicstate’s web design (it’s _really_ bad). However, they do offer a very competitive service. They ping every 15 minutes and allows you monitor as many sites as you want (including SSL). While it might not be a very pleasing site to browse, they do offer sufficient statistics (with graphs) on their site. In addition to that, they also send you daily reports about all your monitored sites (with time data for dns, connect, request, ttfb, ttlb). The only drawback we discovered with Basicstate is that you cannot monitor the same domain-name with SSL and non-SSL (sub-domains is fine though). This may or may not be an issue for you.

The verdict? We settled for Basicstate. Later on, as we grow, we might consider switching to Pingdom. We’re happy with Basicstate for now. Although we did experiencing some false alerts, the guy who runs the site (I assume), Spenser, did a great job on providing an in-depth explanation to the alerts by email. So if you’re on a tight budget, Basicstate is our recommendation. If you have more money to spend, go for Pingdom.

We are really excited to announce that YippieMove now offers both volume discount and custom migrations. Let me explain how these two things works and how it affects you.

Volume Discount

In order to qualify for a volume discount, you obviously need to migrate more than one account. We’ve decided that five accounts is a reasonable number to start offering volume discounts at. However, if you’re interested in migrating a larger number of email accounts, we are willing to work with you to make your migration as easy as possible.

Custom Migration

First, let me explain what we mean by custom migration. Normally, YippieMove integrates seamlessly with Gmail / Google Apps. However, with our custom migration, we enable you to migrate your email between virtually any two email servers (assuming they both support IMAP).

Since this is a custom migration, we can unfortunately not offer this service for single account migrations. However, we do offer volume discounts on custom migrations too.

For questions regarding volume discount and custom migrations, please contact our sales team.

One more thing…

Since last post we’ve kept adding more providers. As of this very moment, the number of providers we now support has exceeded 90. That’s quite a few. You would imagine that we would be satisfied with that numbers, but you’d be wrong. We will keep on adding more providers.

We know, we should post updates more frequently here at PWW about our work (and about technology in general). To our defense, we’ve been busy working on improving YippieMove. So what have we been up to?

Since our last post, we’ve added many more pre-configured profiles. At the time I’m writing this, the current number of pre-configured providers has reached 63! Keep in mind that this is only the number of pre-configured providers – any IMAP service may be used. We think that’s pretty impressive. To take a look at the list of supported providers, go to the About-page on YippieMove.

What’s even more exciting than the long list of supported providers is the improvements we’ve made under the hood. In order to improve the speed and flexibility of YippieMove, we have made significant changes to the back-end. With these changes, we have cut the transfer time in half (or even more in some cases). With the help of this new back-end, we were also able to improve the information passed on to the user about current jobs on the status-page.

In addition to more providers and an improved back-end, we’ve also worked hard on writing documentation related to our service and other problems related to e-mail migration. One of the problems that people who migrate their email is facing relates to how to migrate all their contacts. Because of this, we’ve compiled a guide on how to cope with this problem. Our guide includes a steps-by-step instructions on how to export and import the contacts for some of our most popular providers. Note that even if your particular provider is not listed, it’s quite likely that by reading though our instructions, you will be able to figure it out.

If you haven’t already checked out YippieMove, please go ahead and do so. A great place to start is to take a look on our screencast on how to use the service.

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.