The Data Jelly Blog

Adding a Prefix to All Page Titles in Joomla!

webmaster@datajelly.com (Data Jelly) — Sun, 21 Sep 2008 08:55:53 +0000

For our web site and blog, we wanted all of our page titles to start with a prefix that said "Data Jelly". We use Joomla! 1.5 as our Content Management System (CMS), so we couldn't just edit every page to add it in. There doesn't appear to be a native option to do this in the administration, but apparently there are some plugins that can help. However, in our experience, these plugins have been hit or miss, so we decided to simply try to edit the Joomla! source files ourselves. You've got to love open source software!

We used grep to search around and find the right place to edit. To save you some time, it seems the correct file is located under:

libraries/joomla/document/html/renderer/head.php

Edit this file and search for the <title> tag, it should be around line 86. You can then add a prefix or suffix by editing this line.

That's all there is to it! The one caveat is that if you ever upgrade your version of Joomla!, these changes will be lost. However, the steps to edit the title are hopefully easy enough that you can simply re-apply your changes.

About Us: A (Re)Introduction to the Data Jelly Blog

webmaster@datajelly.com (Data Jelly) — Sun, 21 Sep 2008 07:35:46 +0000

Normally, the very first post on a blog would be the best spot for an "About Us" page. However, we seem to do things a little bit differently, and felt it was now finally a good time to introduce ourselves. Not really so much about our company, but more about our blog and our employees.

The Data Jelly Blog began as a single employee's own personal blog under a different name. The original idea was to publish various tips and tricks that were learned throughout the course of building and launching our software. The topics were generally technical in nature, ranging from hosting topics such as Tomcat, Apache, and MySQL, to programming topics such as Java, JSP, and automated testing. Any time he would get stuck on an issue, he would be sure to publish a post describing the solution to help others who might run into the same problem.

We felt this was a great idea, and wanted to turn it into a company-sponsored blog. We worked to shift the blog onto the company domain name, and just recently moved it off of Blogger and onto our own web site. Now, any employees are free to add their own writeup to our blog. Choosing to publish a corporate blog is always a risky decision, as it could expose some internal secrets or even mistakes we've made. However, we felt it was important to do this for a couple reasons. First, we've learned plenty from the online community, and felt it was only fair that we try to share some of our knowledge in return. Additionally, we felt it was a good way to share information about the tools, technologies, and methodologies that we use with our clients. Lastly, it is a great way to get feedback about our approach and learn about best practices, to help us in our quest to constantly improve our service.

Since this shift, we have expanded the role of the blog a bit. Rather than writing purely about technical problems and their solutions, we have begun posting some tutorials even for issues that are relatively straightforward. To be honest, the intent of some of these articles was so that we could remember how we setup our environment, as we often need to grow and reprovision systems. However, as we've seen with our earlier posts, we would expect that these tutorials will also prove useful for others.

Over time, we've found a couple issues in particular have gained a bit of popularity, which shows that we're not alone in dealing with these technical hurdles that seem to come up rather often. We appreciate all the comments that our readers have left, and have found many of them to be especially helpful. We do feel it is worth pointing out that, while we try our best, we may not be able to help out with all questions that are left on our blog. Regardless, we encourage all of our readers to keep leaving comments, and hope that we can build a community around our blog.

Moving forward, we are hoping to expand the blog even further into new topics. Now that we have successfully opened the blog to all employees, we'd like to begin blogging about a wide variety of topics, all centered around the theme of starting a web company. Of course, everything will still be technical in nature, but we also hope to show a bit of our company culture, things we learn about business, and most importantly hope to invite feedback about how we can improve our software and our company.

We hope you find our blog helpful, and now that you know a little bit about us we'd love to hear from you... feel free to reach us as blog@datajelly.com or leave a note in the comments!

We've Moved

webmaster@datajelly.com (Data Jelly) — Fri, 19 Sep 2008 21:53:44 +0000

Hopefully you've already noticed, but we've moved our blog onto the same platform as our web site. This should make it a little bit easier for us to maintain and have more control over the layout. We hope you enjoy the upgrade!

We've done our best to copy all the original posts and comments from our Blogger account. You may notice some of the dates aren't quite right and there are a few more fixes we need still to make. If you notice any issues, don't hesitate to let us know. While we're at it, we'd like to thank everybody who has left comments and contributed to the knowledge we try to share on this blog.

Installing MySQL on Ubuntu

webmaster@datajelly.com (Data Jelly) — Wed, 10 Sep 2008 00:00:00 +0000

As we ramp up to begin using Amazon Web Services as our host, we find ourselves having to re-install and re-configure alot of software. One of the most important pieces of any web application is your database server, so today's tutorial will be a quick walkthrough of how to install MySQL on Ubuntu.

Step 1 - Install MySQL

Installing MySQL is relatively simple using apt-get. During the installation, you will be prompted to enter a password for the root login. Note that MySQL will automatically configure itself to boot on startup, which is probably a good thing.

apt-get install mysql-server

Step 2 - Create Your Schema

There are a couple ways to create a new schema, sometimes also known as a database. Our recommendation would be to first login to MySQL as follows:

mysql -p

You will be prompted to enter your password, after which you will be brought to a MySQL prompt. From there, create your new schema as follows:

create schema sample; use sample;

You can then create tables, stored procedures, etc. using standard SQL. For example, to create a new table you could use the following commands:

create table tbl (col1 int, col2 varchar(30));

Step 3 - Create Your User

If you are still logged into the MySQL prompt, you can create a new user that has access to the sample schema. It is generally good practice to create a user for each schema on your server, or in general dividing access among several user accounts. This ensures that if somebody hijacks an account (for example, through a SQL injection attack to one of your web sites), you limit the damage they can do and ensure they cannot access a different schema. For each user, you should only grant the permissions necessary for their role, but in our case we will grant full access to the sample schema for the sake of example:

create user 'me'@'localhost' identified by 'pass1234'; grant all on sample.* to 'me'@'localhost';

You can then login as this user to access the sample schema. First, leave the MySQL prompt by typing exit. Next, re-enter MySQL with the following command:

mysql -D sample -u me -p

You will be prompted for your password, after which you can use the sample database (create tables, add data, and run queries using SQL).

Conclusion
That's really all there is to it. From here, you would most likely want to install your web or application server and get it linked up to your brand new MySQL database. Best of luck!

Using SSL in Apache for Certain Pages

webmaster@datajelly.com (Data Jelly) — Fri, 05 Sep 2008 00:00:00 +0000

A commenter in an earlier thread had a terrific question that we thought would make for a good post. The question was essentially, "How can I require the use of SSL for some pages of my site, but not for others?"

Assuming that you are using Apache's web server, and even possibly using it as a reverse proxy to host a J2EE server behind it (such as Tomcat or JBoss), this is relatively easy to setup. There are probably a number of different ways to accomplish this, but our approach has been that if the user hits a page that requires SSL, we will do a redirect to send them to the HTTPS version of the page.

Again, in our earlier post, we had shown the setup to enable SSL in Apache. Let's build upon that configuration. You will need to edit your Apache config file (for Windows it is typically conf/httpd.conf, for Ubuntu it may be under apache2/sites-enabled/000-default). Say that you are starting with a configuration similar to this:

NameVirtualHost *:80 NameVirtualHost *:443 <VirtualHost *:80> ServerName www.domain.com <Location /> ProxyPass http://appserver:8080/ ProxyPassReverse http://www.domain.com/ </Location> </VirtualHost> <VirtualHost *:443> ServerName www.domain.com SSLEngine on SSLCipherSuite ALL:!ADH:! EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile "C:/cert.pem" SSLCertificateKeyFile "C:/private.pem" BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 <Location /> ProxyPass http://appserver:8080/ ProxyPassReverse https://www.domain.com/ </Location> </VirtualHost>

From here, what we'd like to do is add in redirects so that if the user connects to the wrong port, they get redirected to the correct one. For this, the Redirect and RedirectMatch commands can come in handy.

As an example, let's say that you want the directory /secure to require SSL. You might add a line like this:

Redirect permanent /secure https://www.domain.com/secure
So that your configuration would look like this:

NameVirtualHost *:80 NameVirtualHost *:443 <VirtualHost *:80> ServerName www.domain.com <Location /> Redirect permanent /secure https://www.domain.com/secure ProxyPass http://appserver:8080/ ProxyPassReverse http://www.domain.com/ </Location> </VirtualHost> <VirtualHost *:443> ServerName www.domain.com SSLEngine on SSLCipherSuite ALL:!ADH:! EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile "C:/cert.pem" SSLCertificateKeyFile "C:/private.pem" BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 <Location /> ProxyPass http://appserver:8080/ ProxyPassReverse https://www.domain.com/ </Location> </VirtualHost>
Again, we added this line to say that if the user connects to port 80, and is requesting anything under the /secure directory, to redirect them to the HTTPS version.

You can also use the RedirectMatch directive to use regular expressions to control which directories should require SSL. As an example, say that you wanted any directory that starts with a number to require SSL:

RedirectMatch permanent ^/(\d.*)$ https://www.domain.com/$1
If inclined, you can also update your configuration so that if the user hits the HTTPS version of their site for pages that don't require SSL, you can send them back to the plain HTTP version. We'll leave this as an exercise for the reader, but feel free to leave comments if you need some help.

5 Things to Love (or Hate) About Google Chrome

webmaster@datajelly.com (Data Jelly) — Thu, 04 Sep 2008 00:00:00 +0000

There's been alot of buzz about Google's new Chrome browser. We've downloaded it primarily so that we could do some testing to ensure our site works well with it, but we've ended up mostly playing around with all the new features. At first impression, there are a handful of things that we both love and dislike about Google's newest browser.

5 Things to Love

New Tab Thumbnails Granted, this idea was taken from Opera, but it is a terrific and easy way to get started visiting your favorite sites.
Tabs on Top We feel it is much more intuitive to include the address bar within the tab you are currently viewing. Tabs have always been meant to hold or contain content, so it is strange when things outside the tabs change when you switch.
Application Shortcuts It still needs a little work, but we love the concept of viewing a web site as if it were an application. Google obviously did this for their own apps, but it also suits us well as our site is essentially a web app as well.
Built-In Javascript Tools Again, nothing new, but we're happy to see that Google plans on supporting web developers with tools in their browser.
History/Downloads Not sure why, but we love the fact that your history and downloads are displayed as just another tab in the browser. No annoying popups or hover-overs to get in your way.

5 Things to Hate

No Home Button Maybe we're missing something, but would love to be able to easily get back to the thumbnail dashboard navigation without having to open a new tab or restart the browser.
Non-Native Window We've always liked having a consistent GUI for our windows, and don't like that Google went with a non-native window GUI for their browser. We suppose they needed to do it due to the way the tabs are laid out.
CPU Bugs Our CPU sits at 50% utilization just because we have the Javascript console open.
Phishing Although we say we love the application view for web sites, we also worry about the implications it may have in terms of phishing. Seems relatively easy to trick somebody to sending off their sensitive data if you can't clearly see the URL.
Plugins Google says they tried to take the best parts of all the browsers when making their own, but they missed out on how awesome Firefox's plugin architecture is. Or perhaps they will soon be available?

Setting the sender address in Ubuntu

webmaster@datajelly.com (Data Jelly) — Sat, 30 Aug 2008 00:00:00 +0000

Sometimes, you may want to be able to send an e-mail from a shell script or manually from the command line. For example, you may want to periodically send out a server health e-mail. We found that when doing this, it is a little tough to control how the sender's e-mail address will appear. The first problem we ran into was that our domain was appearing as something like user@localhost.local. The second problem is that we didn't want to expose the user's name, which could be root or www. We were looking for a way to have the sender's address appear as noreply@domain.com (or something along those lines).

Step 1 - Install Postfix & Mailutils
In our environment, we had already installed Postfix to send outgoing mail. This can be done as follows:

sudo ant-get install postfix
You may need to step through some configurations to get it up and running. Once installed, you then need to install additional mail tools to be able to send email from the command line:

sudo apt-get install mailutils
Step 2 - The Easy Solution
Once installed, you can send e-mails from the command line like so:

echo Email body | mail -s "subject line" -a From:noreply@domain.com recipient@example.com
This will send an e-mail to recipient@example.com, and will use the address of noreply@domain.com.

We say this is the "easy solution" because, although it works, the recipient would still be able to look at the mail message headers and see the address of user@localhost.local. This simply sets the "From" header of the email, but the sender envelope still contains the original user's address.

Step 3 - Sender Aliases
We took this a step further to try to fully control the sender's e-mail address. There were two configurations we made; one to control the sender's domain, the other to apply an alias to our user name.

First, edit your Postfix configuration file as follows:

sudo nano /etc/postfix/main.cf
You must either change or add the following lines, using the domain you would like to show in the sender's address:

myhostname = domain.com smtp_generic_maps = hash:/etc/postfix/generic
Next, you need to configure the alias file. This file maps users to the proper external name to use. You can also have a catch-all alias.

sudo nano /etc/postfix/generic user1@domain.com noreply@domain.com user2@domain.com noreply@domain.com @domain.com noreply@domain.com
After this file is created, you'll need to use postmap to install it, then reboot Postfix:

sudo postmap /etc/postfix/generic sudo /etc/init.d/postfix restart
After this is all done, you can send an email without needing to specify the From header, and it will still show as our noreply address:

echo Email body | mail -s "subject line" recipient@example.com

Running Multiple Instance of Tomcat in Ubuntu

webmaster@datajelly.com (Data Jelly) — Mon, 25 Aug 2008 00:00:00 +0000

As we hinted at in our last post, it is possible to run multiple instances of Apache Tomcat in Ubuntu, without having to install it twice. Multiple Tomcat servers can be helpful for several reasons. Although we do all our QA testing on a local staging network, we still like to host a beta server next to our live server to help us verify proper functionality in our production environment.

Before diving into how we run two Tomcat servers, let's first look at the directory structure of the Tomcat installation. Assuming that you already have a single Tomcat server up and running within /usr/local/tomcat/, you might see the following sub-directories:

bin/ conf/ lib/ logs/ temp/ webapps/ work/
To run two Tomcat instances, we only need to copy the sub-directories that contain information specific to each instance (such as configurations), but the binaries can stay in this home location and be shared.

Step 1 - Create the Directories
To begin, create two directories that will hold the information for each server:

mkdir /path/to/server1 /path/to/server2
Next, make a copy of the necessary sub-directories into these locations:

cp -rd /usr/local/tomcat/conf /usr/local/tomcat/webapps /path/to/server1 cp -rd /usr/local/tomcat/conf /usr/local/tomcat/webapps /path/to/server2
Let's also create empty directories for things like log files and temp space:

mkdir /path/to/server1/logs /path/to/server1/temp /path/to/server1/work mkdir /path/to/server2/logs /path/to/server2/temp /path/to/server2/work
Step 2 - Configure Each Instance
Each instance will need to use its own set of ports, to ensure there are no conflicts. In Tomcat, the ports are controlled within the server.xml file. We'll leave server1 alone, but we'll change server2's to use different ports.

nano /path/to/server2/conf/server.xml
First, look for the line that says something like:

<Server port="8005" shutdown="...">
Change the port to 8006, or any other of your choosing. Next, look for any other lines that contain ports. There should be at least one other, but may be more:

<Connector port="8080" protocol="HTTP/1.1" ... />
Change this port to listen on 8081, or any other of your choosing. Note that this is the port that web browsers will connect to. Or, in our case, our reverse proxy will connect to so that our users don't need to type in crazy ports in their URL.

Of course, you'll need to deploy your J2EE application to each server. Deploying is beyond the scope of this article. However, if you already had your app up and running and you've followed the steps so far, you should be able to boot up the same app twice for the purposes of learning.

Step 3 - Configure Your Bootup Scripts
Now the only part left is to boot up each instance. This is done by specifying an environment variable called CATALINA_BASE, which points to the new directories we've created. A sample bootup script might look like this (read our previous tutorial for installing this as a bootup script):

export JAVA_HOME=/usr/lib/jvm/java-6-sun export CATALINA_BASE=/path/to/server1 export CATALINA_OPTS="-server -Xmx512m" case $1 in start) sh /usr/local/tomcat/bin/startup.sh ;; stop) sh /usr/local/tomcat/bin/shutdown.sh ;; restart) sh /usr/local/tomcat/bin/shutdown.sh sh /usr/local/tomcat/bin/startup.sh ;; esac exit 0
For the other server, you'll need to use the same script again, but this time use /path/to/server2 as your CATALINA_BASE.

Conclusion
That should be all you need to boot two Tomcats. You can use the same technique to run even more instances if necessary. As new fixes or upgrades are made to Tomcat, you only need to update one set of binaries in the original location, and it will take effect for all instances you have running.

Installing Apache Tomcat 6 on Ubuntu

webmaster@datajelly.com (Data Jelly) — Sun, 24 Aug 2008 00:00:00 +0000

I recently had to re-install Apache Tomcat on our Ubuntu box, when I realized that version 6 was not available in aptitude. As such, I had to manually install it from a download, and figured I'd share these steps with everybody.

Step 1 - Make Sure Java is Installed
Getting Java installed is relatively pain-free. Just run this command:

sudo apt-get install sun-java6-jdk
Step 2 - Download the Latest Tomcat
Check Tomcat's web site and download the Core binaries for the latest version of Tomcat (.tar.gz file). Extract this .tar.giz file to a directory of your choosing, such as /usr/local. For example:

wget http://apache.mirrors.redwire.net/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.tar.gz tar xvzf apache-tomcat-6.0.18.tar.gz sudo mv apache-tomcat-6.0.18 /usr/local/tomcat
Step 3 - Setup Tomcat to Boot on Startup
First, create the script that will start and stop Tomcat. In this script, you need to add the JAVA_HOME environment variable which is required by Tomcat. Optionally, you can also set the CATALINA_BASE variable which allows you to run multiple Tomcat servers and the CATALINA_OPTS variable which will pass in extra Java Virtual Machine arguments.

sudo nano /etc/init.d/tomcat
Copy and paste this script, making sure to either configure or remove CATALINA_BASE and CATALINA_OPTS:

#!/bin/bash export JAVA_HOME=/usr/lib/jvm/java-6-sun export CATALINA_BASE=/path/to/catalina/base export CATALINA_OPTS="-server -Xmx512m" case $1 in start) sh /usr/local/tomcat/bin/startup.sh ;; stop) sh /usr/local/tomcat/bin/shutdown.sh ;; restart) sh /usr/local/tomcat/bin/shutdown.sh sh /usr/local/tomcat/bin/startup.sh ;; esac exit 0
Press Ctrl+X to exit, and answer Yes to save. Next, make the script executable, and install it as a startup script:

sudo chmod 755 /etc/init.d/tomcat sudo update-rc.d tomcat defaults
Step 4 - Startup Tomcat and Test
Tomcat should now be properly installed and ready to go. You'll need to configure Tomcat's server.xml according to your needs, and deploy your webapp. After you've done that, you can start Tomcat by calling:

sudo /etc/init.d/tomcat start
Tomcat should boot up and you should be able to access your Java app via your web browser.

Using Apache Front-End with Tomcat for JSP

webmaster@datajelly.com (Data Jelly) — Tue, 12 Aug 2008 00:00:00 +0000

In a previous post, we discussed how it's possible to use Apache as a reverse proxy to offload SSL and GZip compression from a Tomcat (or similar) J2EE server. Originally, we had set this up on Windows, but we have since moved it over to Ubuntu with no problems.

Another useful setup is to use Apache to serve up your static resources (such as images, javascript files, and CSS sheets), while only sending JSP or servlet requests over to Tomcat. This can be useful because Apache is generally much faster at serving up static content, not to mention that you remove any extra overhead of proxying these requests. Even better, you can continue to use Apache to handle SSL and compression.

This tutorial assumes that you've been able to get Apache and Tomcat up and running independently, and we'll walk through how to connect them.

First Attempt: Proxying All Traffic
Remember from our previous post, you simply need to use the Location tag in your Apache config file to proxy requests over to Tomcat. (For us, this configuration file is located at /path/to/apache2/sites-enabled/000-default, but this could vary based on your setup.)

<VirtualHost> ... <Location /> ProxyPass http://appserver:8080/ ProxyPassReverse http://www.domain.com/ </Location> ... </VirtualHost>
Real Attempt: Proxying JSP/Servlet Traffic
All we need to do is slightly modify this configuration so that it will only proxy JSP or servlet traffic, rather than all traffic:

<VirtualHost> ... <Location /path/to/servlet> ProxyPass http://appserver:8080/path/to/servlet ProxyPassReverse http://www.domain.com/path/to/servlet </Location> ... </VirtualHost>

If your JSP files aren't all in the same directory, you could also use the LocationMatch tag to match files ending with .jsp. Keep in mind that LocationMatch uses a regular expression, which might look something like this:

<LocationMatch .+\.jsp$> ProxyPass http://appserver:8080/ ProxyPassReverse http://www.domain.com/ </Location>
Conclusion
Assuming the remainder of your Apache was already correctly setup, that should be all there is to it. Apache will serve up most files itself, but will use Tomcat where the Location or LocationMatch tags are matched.

A special note: This tutorial was proxying to Tomcat using HTTP, but you could also use the AJP connector. AJP is a binary protocol which should reduce the amount of data that needs to be transferred between Apache and Tomcat. To do this, make sure that mod_proxy.so and mod_proxy_ajp.so are loaded, then simply tweak the ProxyPass directive:

ProxyPass ajp://appserver:8080/