Saturday, February 27, 2010

svnx on MacOSX Snow Leopard: No xauth data; using fake authentication data for X11 forwarding

This was a pretty annoying behavior. Despite most claims that it is harmless, it interferes with correct operation of svnx. I noticed two things it did wrong:

1. When committing changes, after the error it would still look like your changes are not committed, until you did a refresh.
2. Using the repository viewer, you could not get an up-to-date log listing.

After some searching I found this reference:

http://mactip.blogspot.com/2004/04/no-xauth-data.html

which works for the basic symptom. But it didn't help svnx, presumably because I am starting it from the dock. What I did was create a little shell script which I called 'xauth_fix', to first create the xauth data and then open an arbitrary OSX command:

#! /bin/bash
xauth generate $DISPLAY .
if test $# -gt 0
then
open -a $*
fi


If I fire up an X11 terminal window, then run 'xauth_fix svnx', svn runs flawlessly.

Monday, February 1, 2010

JIRA in your own application server

Recently, Atlassian changed their licensing model so that small development teams can afford to run JIRA. It's only $10 for a year for a team of 10 or less. You can't beat that. So I took the plunge at work and my startup. The standalone version of JIRA starts up without much pain at all. However, if you want to run it with mySQL for example, in your existing Tomcat 6 container, well, you have a little work to do. It took me a number of tries, focusing on the contents of the logs/catalina.out file in my tomcat directory, to figure it out. In the end, I think the documentation on how to set it up is the problem, in that there are so may varables. However, I think it could be really easy by having people post their configuration and just three files.

High level: You really only need to get five key configuration files right. You aren't going to use Tomcat's manager application to deploy JIRA. The edit-webapp directory is where you make changes. During compile, files in this subdirectory are copied to the webapp subdirectory, overwriting whatever is there. The configuration file you will give to tomcat refers to the build directory, so the war file actually gets built in the install hierarchy you download from Atlassian.

I'm ignoring the mySQL setup, which isn't difficult. There is a specific example of how to create the jira user and set her permissions in their standalone documentation regarding tomcat/mysql/linux. Just make note of the username and password, which you need to enter into one of the three key files.

Create a work directory for JIRA, make it world writeable. I suspect it just needs to be tomcat writeable, but haven't verified.

Get the mySQL connector from dev.mysql.com, copy this to the $CATALINA_HOME/lib directory.

If it doesn't exist, create $CATALINA_HOME/conf/Catalina/localhost, make it tomcat writeable.

Get the three files from me that are almost deployment-ready, in one zip file: jiraconf.zip. Extract entityengine.xml, jira-application.properties and jira.xml.

Grab (1)entityengine.xml and (2)jira-application.properties. Place in your jira build /download directory/edit-webapp/WEB-INF/classes* where they are now. Edit the jira-application.properties file to correct the jirahome property. It needs to point to a directory writeable by tomcat at least.

Do a build.

Grab my (3)jira.xml. Copy it to the $CATALINA_HOME/conf/Catalina/localhost directory. Edit it to match your mySQl user that you set up. I missed the last mod here per the instructions, modify the url entry so it reads:
url="jdbc:mysql://localhost/jiradb?autoReconnect=true&useUnicode=true&characterEncoding=UTF8"

Get the jira-jars-tomcat6.zip file from atlassian. Drop the jars into $CATALINA_HOME/lib. Make sure they didn't get placed one level below that, which is easy to do by accident.

Make the one simple change to (4)server.xml in your $CATALINA_HOME/conf directory. All you need to do is add URIEncoding="UTF-8" per the instructions.

Create (5) setenv.sh in $CATALINA_HOME per the instructions.

Stop tomcat. Here is where I delete the existing $CATALINA_HOME/logs/catalina.out just so I don't have to look through lots of stuff. If it fails it will be messy. Start tomcat. Check out catalina.out.

It is very rewarding to watch it make progress. Hopefully this helps someone else. I spent many reboots and jumping around the documentation to figure this out. Let me know if I messed anything up.

Sunday, June 14, 2009

Netbeans / OSX / "BASEDIR environment variable is not defined correctly"

This one was frustrating. You get the error message "BASEDIR environment variable is not defined correctly" after installing Netbeans packaged with Tomcat, when you try to deploy your webapp to Tomcat within Netbeans. Try as you might, you cannot fix this with an environment variable. The problem is that the script "setclasspath.sh" in the bin directory of the Tomcat installation is not executable. Change all scripts in the bin directory to be executable and it works.

Along the way I learned that you can have a private configuration by checking the "Use Private Configuration Folder" box during the "Add Server" dialog sequence. If you select an empty directory, it wil be populated for you including an appropriate set of user credentials if you also select "Create user if it does not exist". Pretty easy.

Sunday, March 22, 2009

Macbook pro with intermittent bluetooth

This one was driving me crazy. The backstory is that I have disassembled my macbook pro (15", 2.16Ghz Intel Core Duo) more times than anyone should have to. Six times. Every one of these was to deal with a disk upgrade and subsequent breaking of bluetooth. The first three of the disassemblies were to deal with a disk upgrade. More on that at the end.

The hardest part was figuring out where the bluetooth was. Someone had posted the service manual on scribd which was essential to me solving the problem.

http://www.scribd.com/doc/8237/Macbook-Pro

Page 63 shows the connection to the antennae, which gets moved out of the way when you replace a drive. This seems to be encased in something similar to scotch tape. Apparently, on the third disk swap, this tape tore just where the antennae attaches, so that the antennae sometimes could short out on the metal side to the disk compartment. Of course, this would happen only sometimes. The fix was to pull off the whole mess and replace with electrical tape. It's working grand! I saw a post someplace (I've lost it) where someone had a bluetooth problem after a disk replacement; I can see this happening often.

In my case, I think it was just lots of handling that led to the failure. (1) I replaced the disk to get more space. (2) The new drive failed, so I pulled it and put the old one back. (3) Got a replacement drive, so I had to put that in. The last three disassemblies were to fix bluetooth.

The thing I learned AFTER I put the replacement disk in, is that the Seagate drives in this series have issues. I hope this one doesn't fail also. The first one took almost 3 months to fail. It's a Seagate ST9250421AS. So I might end up taking two more trips inside, and I now have enough used space that I can no longer fit on the original drive, so replacement will be painful.