Greg Meiste

Gerrit Code Review Installation

// June 12th, 2009 // Comments Off // Development, Guides

I ran into a lot of trouble when I was installing Gerrit on my home server and decided I needed to publish a supplement to the Gerrit2 – Installation Guide to help others so they don’t spend a day beating their head into a wall like I did.  My home server is running Ubuntu 9.04, so you may need to adjust a few of the commands if your OS of choice is different.  The Gerrit installation is one of the worst procedures I’ve seen, but it is worth it once installed.  Let’s get started!

Step 1: You need to install an SQL database on your system if you haven’t already.  I chose to use MySQL because that is what I’m more familiar with.  The rest of this guide will assume you also chose MySQL.  You can install MySQL using apt-get in Ubuntu.

Step 2: You need to create a new user on your system for Gerrit.  This user will be used to run Gerrit.  You can create the user with this command:

sudo adduser --system --shell /bin/sh --gecos 'Gerrit Code Review' --group --disabled-password --home /home/gerrit2 gerrit2

Step 3: Download the latest version of Gerrit from the Gerrit Downloads page.  Keep this file somewhere in your home directory for now.  It will be moved in a later step.

Step 4: Create a Gerrit specific user within the database and assign it a password, create a database, and give the user full rights.  I “cheated” and used phpMyAdmin to do this.  When creating the user, phpMyAdmin gives you the option to create a database with the same name as the new user and grant all privileges to that user.  That’s exactly what we needed!  (phpMyAdmin is also available in Ubuntu’s package manager.)

Step 5: Next we need to initialize the Gerrit2 tables.  To do that, first run the following two commands from the directory containing the war file downloaded in step 3:

java -jar gerrit-*.war --cat extra/GerritServer.properties_example >GerritServer.properties


curl -O http://repo1.maven.org/maven2/mysql/mysql-connector-java/5.0.8/mysql-connector-java-5.0.8.jar

Step 6: Open the GerritServer.properties file in your favorite text editor.  Scroll down to the MySQL 5.0 section at the bottom of the file.  Uncomment the three database lines.  Modify the database.url line to match the database, user, and password you created in step 4.  For example, my line looks like this:

database.url = jdbc:mysql://localhost/gerrit2?user=gerrit2&password=secretcode

Step 7: We’re now ready to initialize the Gerrit2 tables.  Run the following command and cross your fingers:

java -jar gerrit-*.war CreateSchema

I got two info prints when I issued that command, which can be ignored.

Step 8: A script should be run to create the query indexes, so Gerrit can avoid table scans when looking up information. Run the index script through the MySQL query tool:

java -jar gerrit-*.war --cat sql/index_generic.sql | mysql -u gerrit2 gerrit2 -p
java -jar gerrit-*.war --cat sql/mysql_nextval.sql | mysql -u gerrit2 gerrit2 -p

Step 9: Now the site_path must be configured:

sudo -u gerrit2 mkdir /home/gerrit2/cfg
mysql -u gerrit2 -p
use gerrit2;
UPDATE system_config SET site_path='/home/gerrit2/cfg';
exit

Step 10: Create the Git repository base, which will hold the Git repositories that Gerrit knows about and can service:

sudo -u gerrit2 mkdir /home/gerrit2/repositories

sudo -u gerrit2 git config --file /home/gerrit2/cfg/gerrit.config gerrit.basePath /home/gerrit2/repositories

Step 11: Download the latest version of Jetty (version 6.1.18 at the time of this writing) from the Jetty Downloads page and unzip to /home/gerrit2/jetty.

Step 12: The required JDBC drivers need to be installed.  Download the c3p0 JDBC driver and unzip to a temporary directory.  Take the c3p0-0.9.1.2.jar from the lib folder and the mysql-connector-java-5.0.8.jar from step 5 and move them into /home/gerrit2/jetty/lib/plus.

Step 13: Move Gerrit into the Jetty deployment:

java -jar gerrit-*.war --cat extra/jetty_gerrit.xml >gerrit.xml
sudo mv gerrit-*.war /home/gerrit2/jetty/webapps/gerrit.war
sudo chown gerrit2:gerrit2 /home/gerrit2/jetty/webapps/gerrit.war
sudo rm -f /home/gerrit2/jetty/contexts/test.xml

Step 14: Open the gerrit.xml file that was created in the previous step in your favorite text editor.  Uncomment out the MySQL section.  Modify the jdbcUrl value to have the correct database, username and password.  Also, at the time of this writing, there is a syntax error on that line.  The ampersand should be “&” (without the quotes).  Without this fix, Gerrit will not start.  My edited jdbcUrl value looks like this:

jdbc:mysql://localhost/gerrit2?user=gerrit2&password=secretkey

Save and close the file.  Move to /home/gerrit2/jetty/contexts/gerrit.xml

Step 15: Finally, create the startup script for Gerrit.  Create /etc/init.d/gerrit2-jetty with the following contents:

#!/bin/sh

export JETTY_HOST=127.0.0.1
export JETTY_PORT=8081
export JETTY_USER=gerrit2
export JETTY_PID=/var/run/jetty$JETTY_PORT.pid
export JETTY_HOME=/home/$JETTY_USER/jetty
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.13/jre

JAVA_OPTIONS=""
JAVA_OPTIONS="$JAVA_OPTIONS -Djetty.host=$JETTY_HOST"
export JAVA_OPTIONS

C="jetty-logging jetty"
[ -f "$JETTY_HOME/etc/jetty_sslproxy.xml" ] && C="$C jetty_sslproxy"

exec $JETTY_HOME/bin/jetty.sh "$@" $C

You’ll need to update JETTY_HOST with the correct hostname or IP address.  You’ll also need to verify the JAVA_HOME path is correct for your system.  Save and close the file, then make the file executable.

Step 16: Start Gerrit!

sudo /etc/init.d/gerrit2-jetty start

Now, wait a minute.  It take a little bit to bring Gerrit up.  If having problems, you can check the stderrout.log in /home/gerrit2/jetty/logs.

Step 17: Congratulations, Gerrit is now running.  You now need to setup accounts and projects.  However, the rest of the Gerrit installation instructions are much more clear, so my tutorial will end here.  You can continue with Administrator Setup in the Gerrit2 – Installation Guide.

Note: I did skip the Apache2 Reverse Proxy step because I didn’t need it.  If this is something you need, read the Apache2 Reverse Proxy instructions.

Projects Moved to GitHub

// April 27th, 2009 // 1 Comment » // Development

For many years I’ve been hosting my phpWebSite projects on SourceForge. Most started as separate projects, but then I merged into the phpWebSite-comm project. I never liked SourceForge, and I’ve always wanted to find something better.

Eventually, I found GitHub, and I signed up for an account on 11 January 2009. After a few months of debating whether to make the move, I finally pulled the trigger and imported all my projects. The release of the GitHub issues tracker on 15 April 2009 pushed me over the edge.

Now my goal is to convince the phpWebSite development team to transition to Git, and maybe even GitHub.

Mirror Android repositories on a local server

// February 8th, 2009 // Comments Off // Development

I have downloaded the Android source many times on several computers.  I was about to do it again when I began to wonder about all the bandwidth I use for each download.  With the Android source being 2.1GB, I wondered if it was possible to mirror the source locally on my home server and download the source from it.  That would also make syncing faster.  I found my weekend project.

Turns out it is very simple to set up.  I’ll walk you through the steps to set up an Android local mirror for yourself.

First, I needed to install git and repo on my Ubuntu 8.04 home server as outlined on the Android source download page.  After some searching online, I decided to go with gitosis to manage the local repositories, so I found some great instructions that I used to help me set it up.  I won’t rehash the steps here.

In addition to authorized access, I wanted the option to allow public access to the mirror.  For that, I used git-daemon.  It already comes with git, so it just needs to be configured and started.  You can download my git-daemon init script from GitHub and place in the appropriate directory (/etc/init.d/ for Ubuntu servers).

I was now ready to download the mirror of the Android repositories.  Run the following commands on the server:

cd /home/git/repositories
sudo -u git mkdir android
cd android
sudo -u git repo init -u git://android.git.kernel.org/platform/manifest.git --mirror
sudo -u git repo sync

Next, instruct gitosis to share the new repositories.  Using the gitosis instructions from above, modify your gitosis.conf to be similar to mine, found on GitHub.  Obviously replace my user with your user.

It is then necessary to modify the Android manifest, so that when users attempt to create clones of the Android git trees it directs them to the local server and not to the external servers (defeating the purpose of the mirror in the first place). To do this, create a clone of the Android manifest on your local PC as shown below. Please note that in this example the IP address of the local server is 192.168.1.100.

cd ~
git clone git@192.168.1.100:android/platform/manifest.git
cd manifest
git branch local
git checkout local

Open the default.xml file in and editor and replace the “fetch” location for the remote korg with the IP address and directory name of your local mirror:

git@192.168.1.100:android/

Finally, commit this change to the Git repository and push this change back to the parent Git tree:

git commit -a -m "Using local mirror"
git push origin local

Your mirror is now ready!  To use it, simply use the following init command, then sync like normal:

repo init -u git@192.168.1.100:android/platform/manifest.git -b local
repo sync

That’s it!  Don’t forget to sync the mirror every now and then to keep it up to date.

Eating your own dogfood

// February 1st, 2009 // 1 Comment » // Development

The phrase “eating one’s own dogfood” means a developer uses their own code for their own daily needs.  It allows a developer to quickly see what features are missing, or what features may be annoying.

I have long been a believer in this philosophy.  For example, I contribute to the phpWebSite content management system project, and have used the phpWebSite software to power my personal website for years.  Every time a new version was released, I immediately upgraded my site.

The phpWebSite community has been debating over the dogfood theory for years.  The unofficial support forums do not use the phpWebSite phpwsbb module.  The phpWebSite Community Wiki did not use the phpWebSite Wiki module.  I, along with other fellow community members, complained that visitors will think poorly about phpWebSite since we don’t even use the software ourselves.  In addition, using phpWebSite would give us a chance to improve it to meet our needs.

Then, one day my friend Ross posted on his blog that he was upgrading his site to WordPress 2.7.  After he finally did the upgrade, I went to his site and was immediately impressed with the difference.  I had heard about WordPress before, but never took the time to investigate it.  Now curious, I decided to install it on my development server.

I was impressed again.  The features and the power of WordPress are well above and beyond the current capabilities of phpWebSite.  I immediately began filing feature requests to phpWebSite, basically saying “WordPress does this and that, and well, we should too!”

The realization slowly hit me.  Since I had used phpWebSite for all these years, thought it was the greatest thing since sliced bread, and I didn’t know any better.  I began to think that maybe eating your own dogfood has its downsides.  Maybe one should try another dogfood from time to time just so one knows what else is out there.

With that realization, I installed WordPress on this site.  I’m going to use it here for awhile to give it a taste.  But don’t think I’ve jumped ship completely.  I have no plans to start writing WordPress plugins.  In fact, you’ll still find me in the phpWebSite IRC channel, in the forums, submitting feature requests, and contributing modules to the community.

Plus, now that I know the ingredients to the WordPress dogfood, and can take my knowledge back and help improve the phpWebSite dogfood recipe.