The general concensus among members of the SEO community seem to be that there is really no reason to do this. There is little to no SEO benefit. The user experience really is not effected by this. Nevertheless, as a systems administrator, you may be asked to make this happen – just in case there is a benefit.

My solution here works on the CentOS Linux operating system. I have not tested it elsewhere. It assumes mod_rewrite is installed which by default it is.

You cannot do this from the .htaccess file. It can only be done by making a change in the httpd.conf file. At that, it is an entry in the host section for each individual site on your server.

Here is the change.

<VirtualHost an_ip_address:80>
  A bunch of virtual host information needed for the site.

  RewriteEngine on
  RewriteMap lowercase int:tolower
  RewriteCond $1 [A-Z]
  RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

</VirtualHost>

I found the solution in this discussion thread after striking out from others – http://www.daniweb.com/forums/thread46647.html

Here is how I resolved it.

1. Download the security certificate of the webservice using a browser. You should be able to save the certificate as a .cer or .crt file name. Then transfer the certificate to your Linux server that is running Jive SBS. Save this file in a unique place we will call “somedirectory”. If the step of downloading a certificate is new to you, from IE, go to File -> Properties -> Certificates -> Details -> Copy to File.

2. Run these commands from the Linux console, modified to your environment.

/usr/local/jive/java/bin/keytool -import -alias somename -file /usr/local/jive/etc/httpd/ssl/somename.cer -keystore /usr/local/jive/java/jre/lib/security/cacerts

When it asks for the password, use the default of – changeit

3. Test getting a connection using the SSLPoke class – described below.

4. Add the truststore into the setenv file located at /usr/local/jive/applications/sbs/bin/setenv.
export JAVA_OPTS=”\
-XX:+UseParNewGC \
-XX:+UseConcMarkSweepGC \
-XX:CMSInitiatingOccupancyFraction=75 \
-XX:+CMSParallelRemarkEnabled \
-XX:+CMSScavengeBeforeRemark \
-XX:CMSMaxAbortablePrecleanTime=1000 \
-XX:+PrintGCDetails \
-XX:+PrintGCTimeStamps \
-XX:+PrintClassHistogram \
-Djava.awt.headless=true \
-Djava.net.preferIPv4Stack=true \
-Djavax.net.ssl.trustStore=/somedirectory/keystore.jks \
-Xloggc:${JIVE_LOGS}/${JIVE_NAME}-gc.log”

Another command I found useful in troubleshooting this issue was as follows:
ps -ef | grep java

Using SSLPoke
I actually picked this up from an attlasian web page so I am not the original author. But here is the source code.

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;

/** Establish a SSL connection to a host and port, writes a byte and
 * prints the response. See
 * http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services
 */
public class SSLPoke {
    public static void main(String[] args) {
    if (args.length != 2) {
      System.out.println("Usage: "+SSLPoke.class.getName()+" <host> <port>");
      System.exit(1);
    }
    try {
      SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
      SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(args[0], Integer.parseInt(args[1]));

      InputStream in = sslsocket.getInputStream();
      OutputStream out = sslsocket.getOutputStream();

      // Write a test byte to get a reaction :)
      out.write(1);

      while (in.available() > 0) {
        System.out.print(in.read());
      }
      System.out.println("Successfully connected");

    } catch (Exception exception) {
      exception.printStackTrace();
    }
  }
}

Compile this simple class and test your connection with this expected behavior:

works
java -Djavax.net.ssl.trustStore=/somedirectory/keystore.jks SSLPoke webserviceurl.com 443
Successfully Connected

Does not work
java SSLPoke webserviceurl.com 443

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path bui lding failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find vali d certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:192)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.j ava:1074)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java :128)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.j ava:1120)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:73)
at SSLPoke.main(SSLPoke.java:23)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security .provider.certpath.SunCertPathBuilderException: unable to find valid certification path to re quested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:294)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:200)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.ja va:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustMana gerImpl.java:209)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustMana gerImpl.java:249)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.j ava:1053)
… 9 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid c ertification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.j ava:174)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:289)
… 15 more

The Crowd application is a java based program which runs on Tomcat. It is best installed by downloading the stand-alone application from Atlassian and installing it on a dedicated server. If you do plan to run other java applications on this same server, then you should use a separate instance of Tomcat.

Managing users is rather simple. It gives you an out of the box directory for you to use as the listing of your users. It also gives you the ability to integrate with your Active Directory. And best of all, it allows you to manage the users of your application by allowing the application to draw from the users of the Active Directory and the users of your own directories. So now you can give contractors access to the applications without adding them to the AD.

Crowd has been well developed to easily integrate with your Java applications that use well known standards such as Acegi. Getting the other Atlassian products to use Crowd takes about 20 minutes each (if that long). Set up the application in Crowd and establish the user base and establish the groups used by the application. Next, go to the application, add the version compatible jar file, make some minor modifications in a couple of xml files and you are good to go – actual instructions are on the Atlassian site.

I have never seen an implementation of single sign-on go so easily as it does with Jira, Confluence, Fisheye, and Bamboo. Even getting Subversion over Apache to work with Crowd was not a difficult task. Crowd integration with all of these applications is well documented. The next application I need to try this on will be Jive SBS – this integraton is not well documented except I do know that Jive does make use of Acegi. I am hoping this will be easy.

Lastly, Crowd will work as an OpenID server for you. If you are not familiar with OpenID, it is a standard that many applications have adopted. By logging onto the Crowd OpenID application, you can get a URL that OpenID compliant applications will accept for authentication. When you drop the url into the third party application the first time, it will send notification to your Crowd server for you to allow Crowd to acknowledge the third party application as a valid application of yours for authentication. From that time forward, you no longer need to remember your password -just drop in the URL and you are logged in. I tested the functionality on the Teligent community application and it worked beautifully.

One current weakness is the lack of documentation of getting dotNet applications to work with Crowd.

I really like this Crowd Application. I intend to continue working with it for some time now.

Performance – Fedora
My first concern came when I tried to log on to my first server which was on the Fedora operating system. There seems to be some pretty serious latency between the time you get your user prompt and the time it takes for the password prompt to show up and let you in. This problem also translated into problems when trying to ftp files to the server. The FTP client would often time out while simply making the initial connection. Once the connection is made the file transfers worked just fine.

The second issue I had with the fedora server had to do with running PHP / MySQL applications such as OSCommerce. While static web pages and dynamic web pages from the shopping cart displayed well, when someone tried to add information to the database, it was extremely slow – even unusable. My first customer to purchase on my shopping cart while hosted on this server ended up being listed in the shopping cart as having three purchases. I also discovered that as one uses any php to database operations, the application would seemingly hang for about 30 seconds prior to completing the processing of the data and taking you to the next page.

On the positive side, I had some java based applications sitting on Tomcat that were not serious database consumers. These applications worked acceptably well in this environment as these apps tended to be more memory intensive and less dependent on processor / disk IO / database performance.

Performance – CentOS
I tried using one of the CentOS servers. This server seemed to work better. The logon latency was much improved. I did not test my php applications on this CentOS server. I only tested my java apps with one instance of Tomcat running. This particular application was Fisheye – an Atlassian product. This application works well on this virtual machine. It is memory intensive and comes close to using the entire 1GB of memory that is allocated to this server.

Customer Service:
In spite of them not giving out thier phone number, I found thier customer support to actually be quite effective. It is not good for 24/7 support, but if you are okay with submitting a trouble ticket and waiting about 4 hours, they appear to be fairly reliable.

Conclusion:
In the end, my review is mixed. I continue to be a customer with them as I have the Fisheye application running on the CentOS server. The rest of my applications I got back onto a dedicated server where they seem to work much better. If you decide to try thier services, I recommend starting with the CentOS flavor of a virtual server and not use the Fedora servers.

Don’t be overwhelmed. Once you have gotten one Tomcat instance to work with Apache, the second (and third for that matter) is no big deal.

By the way, this is all being run on a dedicated CentOS Linux server sitting in the racks of Godaddy.

Download Tomcat
Go ahead and download Apache Tomcat and store them in separate locations. For example:

/var/tomcat/jira
/var/tomcat/bamboo
/var/tomcat/clearspace

Go ahead and download Tomcat into each of the directories:

wget http://download.nextag.com/apache/tomcat/tomcat-6/v6.0.26/bin/apache-tomcat-6.0.26.tar.gz (or whatever the latest version is at the time)

Deconflict the Ports
There are three ports which need to be deconflicted which are all configured in the server.xml file in the conf directory for each Tomcat installation.

1. The shutdown port – default 8005
2. The connector port – default 8080
3. The AJP port – default – default 8009

So you might as well designate the first to use the default ports, and the second to use port 8006, 8081, and 8010 (and the third using port 8007, 8082, and 8011). Simply change those numbers in the server.xml file.

<Server port="8005" shutdown="SHUTDOWN"> 

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

It is a good idea at this time to make certain that each of these instances can be started up and the default page viewed one at a time. Start the first one, test it, and then stop it. This is done by going to the bin directory and invoking ./startup.sh and ./shutdown.sh.

To test each one, use the appropriate command
wget http://localhost:8080
wget http://localhost:8081
wget http://localhost:8082

and simply see that each command downloads the index.jsp page with the default Tomcat page written to file.

Now make certain that stop each instance of Tomcat before starting and testing the next one – otherwise, you will have conflicting CATALINA_HOME variable values which should break things.

Establish Ownership and Create Startup Files
What originally concerned me about running multiple instances of Tomcat was that each instance needs a unique CATALINA_HOME environment / user variable. It use to be that you were required to establish the CATALINA_HOME as a variable in order to start the application. Today, if you do not have it defined, the application will assign it automatically during the startup process. So now you need to create a startup script which assigns the application to be automatically started by its own user.

In this example, create three users on your Linux operating system – clearspace, jira and bamboo. Go ahead and assign these three users a password. Then run the chown -Rf command to assign ownership of each application and all of the files to the appropriate user. Go to the

/var/tomcat

directory and call from the root user

chown -Rf bambo.bamboo bamboo/
chown -Rf jira.jira jira/
chown -Rf clearspace.clearspace clearspace/

Now create a startup script in the /etc/init.d directory for each of these. This particular script works for me.

Notice the /bin/su bamboo command. Replace bamboo with the appropriate user name which specifies the user you want to run the application as.

vi bamboo

#!/bin/sh
#
# Tomcat Server
#
# chkconfig: 345 96 30
# description: Java servlet container

TOMCAT_START=/var/tomcat/bamboo/apache-tomcat-6.0.26/bin/startup.sh
TOMCAT_STOP=/var/tomcat/bamboo/apache-tomcat-6.0.26/bin/shutdown.sh

start()
{
if [ -x ${TOMCAT_START} ]; then
echo “Starting bamboo server…”
/bin/su bamboo $TOMCAT_START &
else
echo “Cannot start bamboo server”
fi
}

stop()
{
if [ -x ${TOMCAT_STOP} ]; then
echo “Stopping bamboo server…”
/bin/su bamboo $TOMCAT_STOP &
else
echo “Cannot stop bamboo server”
fi
}

restart()
{
stop
sleep 10
start
}

status()
{
echo “No status available for tomcat server”
}

case “$1″ in
’start’)
start
;;
’stop’)
stop
;;
‘restart’)
restart
;;
’status’)
status
;;
*)
echo “Please supply an argument [start|stop|restart]”
esac

Do the same for all three applications.

After creating the unique files for each application, you will want to call the chkconfig command to establish these files to autostart when the server gets a physical reboot. While this is an optional step, it is necessary if you want the applications to automatically come up when the server gets rebooted. You can choose to do this later once you have completed all troubleshooting.

Now you can start up each instance of Tomcat logged in as the root user by starting each Tomcat instance as a service.

cd /etc/init.d
./bamboo start
./clearspace start
./jira start

Now check that all three are running by either using a browser or the wget command from the command prompt. Using the command prompt is the most reliable as a firewall my be blocking your browser from accessing the non-standard ports.

wget http://localhost:8080
wget http://localhost:8081
wget http://localhost:8082

You should see that you get the default Tomcat page from each of these wget calls just like you did before.

Get them working with Apache
Now that each instance of Tomcat is running, you need to get all three of them to work with Apache. Not intending to replace the Apache documentation, here is what you need to do in a nutshell.

Download the mod_jk libraries, place it into the modules directory (/etc/httpd/modules), rename it, and make it executable.

cd /etc/httpd/modules
wget http://apache.cs.utah.edu/tomcat/tomcat-connectors/jk/binaries/mod_jk-1.2.30-httpd-2.0.53.so (this may be different)
mv mod_jk-1.2.30-httpd-2.0.53.so mod_jk.so
chmod 755 mod_jk.so

Now add the following to your httpd.conf file (more details of where to get the files is in the Tomcat documentation). Place it immediately below the rest of where the LoadModule commands are listed.

LoadModule jk_module modules/mod_jk.so
jkWorkersFile /etc/httpd/conf/workers.properties
jkMountFile /etc/httpd/conf/uriworkermap.properties
JkShmFile /var/log/httpd/mod_jk.shm
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkLogStampFormat “[%a %b %d %H:%M:%S %Y] ”

Next, create the workers.properties file in the specified location you just added to the httdp.conf file and add the following lines to it.

# Define real workers using ajp13
worker.list=worker1, worker2, worker3

# Set properties for workers (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker2.type=ajp13
worker.worker2.host=localhost
worker.worker2.port=8010
worker.worker3.type=ajp13
worker.worker3.host=localhost
worker.worker3.port=8011

The contents of the uriworkermap.properties are optional depending on your applications. You can remove it from the httpd.conf file but for now it is best to include it and create a blank uriworkermap.properties file.

Configure and Start Apache
Now go back to your httpd.conf file and establish the workers in the appropriate sites:

NameVirtualHost 173.201.176.190:80
<VirtualHost 173.201.176.190:80>
    ServerAdmin brian@trisummit.net
    ServerName clearspace.trisummit.net
    ErrorLog logs/clearspace.trisummit.net-error_log
    CustomLog logs/clearspace.trisummit.net-access_log common
    jkMount /* worker1
</VirtualHost>
<VirtualHost 173.201.176.190:80>
    ServerAdmin brian@trisummit.net
    ServerName jira.trisummit.net
    ErrorLog logs/jira.trisummit.net-error_log
    CustomLog logs/jira.trisummit.net-access_log common
    jkMount /* worker2
</VirtualHost>
<VirtualHost 173.201.176.190:80>
    ServerAdmin brian@trisummit.net
    ServerName bamboo.trisummit.net
    ErrorLog logs/bamboo.trisummit.net-error_log
    CustomLog logs/bamboo.trisummit.net-access_log common
    jkMount /* worker3
</VirtualHost>

Now restart apache. As long as your DNS settings are correct (or Hosts file), you should access the default Tomcat page from all three of the appropriate URLs all over port 80 through Apache. Congratulations, you did it.

Crowd is a single sign on server application that allows multiple web applications to log on using a centralized user repository. The greatest beauty of Crowd is that it integrates with LDAP (Active Directory) and also allows you to create additional users not associated with the Active Directory giving system administrators the ability to grant contractors access to selected resources without bringing them full onto the network.

Subversion is a source control tool that integrates well with Apache. When integrated with Apache, subversion becomes a read only web application with exposed APIs for active source control management with a subversion client.

When Subversion is integrated with Apache, and Apache is integrated with Crowd, Subversion is then easily integrated with Crowd.

By integrating Apache with Crowd, any web application can make use of Basic Authentication requiring a user to log on with the credentials stored in Crowd. These applications are best run under https so as to avoid sending plain text authentication information over the network.

When integrating Apache with Crowd, the Subversion server instance which by default allows connections over port 3690 is not used. There is no need to start or kill the svnserve services on the Linux server when integrated with Apache. The configuration files in the subversion conf directory are not used. However, you can still start the service running independent of your Crowd / Apache instance if desired – making full use of the configuration files that come out of the box with Subversion.

In doing the installation, I ran into two issues.

Issue 1 – Perl Modules
When doing the installation of setting up Apache, Crowd, and Subversion, there are several perl modules which must be downloaded and installed onto your linux box. I ran into an issue with these libraries which took some time to figure out. I have recommended to Atlassian that they update thier documentation accordingly.

The SOAP::Lite libraries did not properly install out of the box due to one of the Core Perl packages not being part of the default installations of Fedora and Cent OS. The missing Core Perl package is the perl – version package.

I would get to the installation of the Apache-CrowdAuth-1.2.3 and I get the following message.

[root@trisummitjira Apache-CrowdAuth-1.2.3]# perl Makefile.PL

Checking for required modules:

Atlassian::Crowd is installed… no
Cache::Cache is installed… yes
Digest::SHA1 is installed… yes
Error is installed… yes
SOAP::Lite is installed… yes

You must install Atlassian::Crowd, Cache::Cache, Digest::SHA1, Error, SOAP::Lite
[root@trisummitjira Apache-CrowdAuth-1.2.3]#

This problem was solved by downloading the Perl Version modules from CPAN at
http://search.cpan.org/dist/version/ then doing the installation using

perl Makefile.PL
make
make install

Afterwards, I was able to properly install the SOAP-Lite package.
Then the rest of the installation worked.

Issue 2 – Running Subversion in the sites Root directory
The answer is – don’t do it. It does not work. I was attempting to use the site http://svn.trisummit.net and have this serve as the web based repository for my source control. It origninally had the appearance of working. Or shall I say that it works for the Read-only functionality of Subversion. However, when I would try to commit files to subversion, I would get a Permission Denied error. I discovered a web posting where I was told not use the / root of the website (sorry I don’t have the link). So instead, I moved Subversion to http://trisummit.net/svn – a subdirectory of this blog. Then it worked like a charm. It was even better when I changed to using https://trisummit.net/svn; because then the basic authentication plain text security issue was solved.

Don’t do this

<pre>
<VirtualHost 173.201.176.190:80>
    ServerAdmin brian@trisummit.net
    ServerName svn.trisummit.net
    ErrorLog logs/svn.trisummit.net-error_log
    CustomLog logs/svn.trisummit.net-access_log common
  <location />
    DAV svn
    SVNPath /var/svn/projects
    AuthName subversion
    AuthType Basic
    PerlAuthenHandler Apache::CrowdAuth
    PerlSetVar CrowdAppName subversion
    PerlSetVar CrowdAppPassword myPasswordInCrowd
    PerlSetVar CrowdSOAPURL http://localhost:8095/crowd/services/SecurityServer
    PerlAuthzHandler Apache::CrowdAuthz
    PerlSetVar CrowdAllowedGroups subversion-users
    Require valid-user
  </location>
</VirtualHost>
</pre>

The below implementation will work – however the <location /svn> tag is best placed in the ssl.conf directory where your security certificate is configured:

<pre>
<VirtualHost 173.201.176.190:80>
    ServerAdmin brian@trisummit.net
    DocumentRoot /var/www/html/trisummit
    ServerName trisummit.net
    ServerAlias trisummit.net www.trisummit.net
    ErrorLog logs/trisummit.net-error_log
    CustomLog logs/trisummit.net-access_log common
  <location /svn>
    DAV svn
    SVNPath /var/svn/projects
    AuthName subversion
    AuthType Basic
    PerlAuthenHandler Apache::CrowdAuth
    PerlSetVar CrowdAppName subversion
    PerlSetVar CrowdAppPassword mypasswordInCrowd
    PerlSetVar CrowdSOAPURL http://localhost:8095/crowd/services/SecurityServer
    PerlAuthzHandler Apache::CrowdAuthz
    PerlSetVar CrowdAllowedGroups subversion-users
    Require valid-user
  </location>
</VirtualHost>

</pre>

Following this change, I was able to save my commits to Subversion using the user credentials stored in Crowd. Pretty slick. A C program on Linux authenticating to the crowd SSO server. I like it.

Anyways, I am really very pleased with this implementation. My source code is now externally accessible yet password protected with a single sign on server. The application is configurable so that I can give access to certain projects to certain people while holding back access to others. And best of all, I don’t have to worry about being on the network when I am on the road.

Two thumbs up for integrating Subversion with Crowd and Apache.

Look at the Directory section of the httpd.conf file. By default on most operating systems (Red Hat, Fedora, CentOS) the default value for AllowOverride is “None”. Change the value to “All” and it is likely the solution to your problem.

<pre>
#
# This should be changed to whatever you set DocumentRoot to.
#
<Directory "/var/www/html">

#
# Possible values for the Options directive are "None", "All",
# or any combination of:
#   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important.  Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
    Options Indexes FollowSymLinks

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   Options FileInfo AuthConfig Limit
#
    AllowOverride All

#
# Controls who can get stuff from this server.
#
    Order allow,deny
    Allow from all

</Directory>
</pre>

rpm -qa j* and then find the name of the jive installed package.
rpm -e jive-sbs_versionnumber
rm -rf /usr/local/jive

Afterwards, I successfully installed the application by running the command prepended with sudo.

sudo rpm -ip jive-sbs-versionnumber.rpm

What I come to find out is that the Jive application runs as the Jive user. All start | stop | restart commands are inteded to be run as the user “Jive”. You can run all of these commands as root by prepending them with sudo. Or you can change the password of the jive user to a password you know, login as the jive user, and then run the commands without prepending with sudo.

java.lang.IllegalArgumentException: When not aligning with a user install you must specify a local repository location using the setLocalRepositoryDirectory( File ) method.
at org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699)
at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628)
at com.atlassian.bamboo.ww2.actions.admin.ImportMavenPlanCheckoutPomAction.parsePom(ImportMavenPlanCheckoutPomAction.java:219)
at com.atlassian.bamboo.ww2.actions.admin.ImportMavenPlanCheckoutPomAction.doExecute(ImportMavenPlanCheckoutPomAction.java:118)
at com.atlassian.bamboo.ww2.BambooActionSupport.execute(BambooActionSupport.java:705)
……..

As I searched for the solution to the problem, it appeared that this problem had been reported quite commonly to the Maven team – However, getting the details on how to fix it were not offered. The solution was rather simple.

MAVEN2 needed to be installed on the Linux server running the Tomcat instance with the Bamboo application. The M2_HOME and M2 path variables also needed to be set on the server.

One last thing to check on the Bamboo application is to make certain you have established a builder that works. The default Maven2 builder in Bamboo may not have the same path as the one you have installed. So you may have to specify your own builder to match the path of your Maven installation.

Once I had taken these steps, the Bamboo application no longer threw that stack trace and I was able to complete the installation of the project to the continuous build system.

After much investigation, we determined that the reason for the unusually high page count had to do with the Jive Application. Jive allows for an independent URL of not only threads, but for each message of each thread as well. This resulted in a high amount of duplicate content in the Google Mini. The problem was made worse with the user profiles. We had multiple websites all sharing the same user base. So for each website, each users profile was crawled again and again and again. No wonder our page count was out of site.

From the Crawl Diagnostics, I was able to determine that we were experiencing duplicate content with the following three pages: message.jspa, accountView.jspa, and profile.jspa. Furthermore “tstart” was also a part of the URL with a lot of duplicate content.

The solution was in the “Crawl URLs” section of the Google Mini. In that section is a subsection called “Do Not Crawl URLs with the following Patterns:”

From there, we added the following:

http://domainname.com/profile.jspa$
http://domainname.com/accountView.jspa$
http://domainname.com/message.jspa$
contains:tstart

These four lines added to the “Do Not Crawl” list (of course modified with the proper domain name) wiped out virtually all of the duplicate content while keeping in all of the necessary content to be searched on. The results were a success. We had a successful implementation of the Google Mini which we later ported to numerous communities.