Atlassian Stack: FishEye (auto start)

Today's ticket is to rig up FishEye so that it starts at boot time.  I scoured the FishEye docs and googled but came up empty.  There is a Mac OS X solution and one for an older version of FishEye and CentOS.  Nothing for Karmic Koala.  My solution?  Emulate what was done for Jira.  I copied /etc/init/jira.conf and created /etc/init/fisheye.conf.  My resulting file looks like this:

# fisheye

description     "Atlassian FishEye - Source control viewer"

start on runlevel [2345]
stop on runlevel [!2345]

kill timeout 30

env RUN_AS_USER=fisheye
env BASEDIR=/opt/fisheye

script
    LOGFILE=$BASEDIR/fisheye.out.`date +%Y-%m-%d`.log
    exec su - $RUN_AS_USER -c "$BASEDIR/bin/start.sh" >> $LOGFILE 2>&1
end script

The solution does not appear to be perfect, however.  If I issue sudo service jira stop, I get this: jira stop/waiting.  If I issue sudo service fisheye stop, I get this:  stop: Unknown instance.  Not good. I don't want to just kill the process when I shutdown the box.  Who knows what type of data corruption will occur?  I need to figure out what is wrong with my script and fix it.  One difference is that the other Atlassian pieces bundle their own copy of Tomcat and that is what we invoke in the start scripts.  FishEye uses something else. 

I googled about Upstart and decided that I won't ever fully understand how it works.  So, I've decide to make two upstart scripts.  One that controls starting up FishEye and boot time (fisheye-start.conf) and one that controls shutting down FishEye during shutdown (fisheye-stop.conf).  Perhaps not the most elegant solution but it appears to work.  All I'm doing is calling start.sh in one and stop.sh in the other.  Nothing fancy.

How Do I Use Spring Security To Secure Spring MVC and Spring BlazeDS In The Same Application?

Context: I have a single web application that is based on Spring 3.  It serves up RESTful resources using the new Spring MVC annotations and it works fine.  After some head scratching and research, I finally figured out the configuration required to lock down the Spring MVC calls with Digest Authentication via Spring Security 3.  I then wanted the ability to provide access to the same set of services to our Flex clients using AMF so I added Spring BlazeDS Integration to the mix.  Remoting a service via Spring is almost trivial.  Add an annotation or two and you are good to go.  Adding security to the mix is almost as easy.  If you follow the directions on how to lock down your AMF channels, it'll work fine.  The problem I ran into is that set of security filters set up by the Spring BlazeDS Integration directions interfere with the set of filters needed by Spring MVC.  The solution?  Watch things in the debugger in a working environment, reverse engineer the required filters for Spring BlazeDS and then specify them by hand in your Spring Security set up.  Spring Security uses a chain of filters to apply authentication logic to servlets.  Spring MVC and Spring BlazeDS get their own instance of DispatcherServlet in the application.  You then apply the required filters to the appropriate servlet.  My solution was to break up the Spring Security beans into three files:

• common-security-context.xml - holds beans that are common to both Spring MVC and Flex authentication
• mvc-security-context.xml - holds the beans specific to authentication of the RESTful API
• flex-security-context.xml - holds the beans specific to authentication of the BlazeDS calls

What you should end up with is the ability to invoke the service in two ways: one as a RESTful resource and one as a Flex Remote Object.  In each case, providing the same set of credentials should authenticate you.  In summary, relying on the Spring Security namespace to set up your security environment does not work if you are combining Flex and Digest authentication: you need to set things up by hand.

Here are my versions of the files in question.  I hope that it saves you some time and effort.

• web.xml
• common-security-context.xml
• mvc-security-context.xml
• flex-security-context.xml

  

Atlassian Stack: FishEye

Today's mission: install FishEye, the source control repository analysis tool. Quoting the online docs: "FishEye unlocks Subversion, Git, Perforce, Clearcase, CVS, and Mercurial with real-time notifications of code changes plus web-based reporting, visualisation, search and code sharing." I'll be installing 2.3.5 Standalone edition.

1. create a new user account and group named fisheye
2. add the fisheye account to the subversion group -- it needs read only access to the Subversion repository 
3. extract the fisheye zip into /opt
4. make a softlink from the new installation directory to /opt/fisheye
5. change ownership of the installation directory over to fisheye:fisheye.
6. mkdir /opt/fisheye-home
7. change ownership over to the fisheye account
8. export FISHEYE_INST in /etc/environment so that it points to /opt/fisheye-home
9. copy /opt/fisheye/config.xml to /opt/fisheye-home
10. logged out and then back into the account to make sure that the environment variable was set correctly
11. as the fisheye account, start fisheye: sudo -u fisheye /opt/fisheye/bin/run.sh
12. connect to http://localhost:8060/ and run through the wizard
13. had to do something odd, in order to get the server id I had to start with the "obtain evaluation license" option and then back out and do the "enter existing license option"
14. Added the Subversion repository by specifying svn://localhost/opt/svn

The initial installation is done.  Next step, integrate it with the rest of the stack.