Skip to content

Archive

Archive for April, 2010

I started working with the Crowd application for single sign-on and identity management about four months ago. I have been quite impressed with it. The application allows your applications to use a centralized repository for user authentication. Additionally, it provides an OpenID service for your same users as well.

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.

I was in need of some external facing virtualized servers and ran across the website at http://vpsland.com. I was skeptical at first as the specs on the website said nothing about them running on ESX servers. But I decided to give it a try. I tried both Fedora virtualized servers and a CentOS virtualized server.

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.

There are times when you need to run multiple instances of Tomcat on the same Linux based server. My need came as I tried to run Jive Clearspace, Jira, and Bamboo all on the same instance of Tomcat in different directories. The first thing I noticed was that the logs were cluttered with all sorts of conflicting classes. The next thing I noticed was that the reporting graphs in Bamboo were not displaying. As I took my issues to Atlassian, they informed me that Bamboo and Jira have conflicting ognl files and cannot be run to on the same instance of Tomcat. Hence, I was in the situation where I needed to run separate instances of Tomcat to get the applications to work.

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.

In the quest to find the best solution for getting targeted links in the blogsphere, I decided to try the services of blogadvertisingstore.com.

There were two hooks that got me.

1. I was able to specify multiple forms of backlinks that the bloggers would use.
2. The Commissions that Blogadvertising Store was going to draw from seemed rather small.

Taken direct from thier website, this is thier charges.

As you may know, many blog advertising companies charge advertiser 30-35%/order and there is also a campaign creation fee of $5-10. Other blog advertising companies don’t charge the advertisers but charge the bloggers offering them 65% from their income.

1. Our commission is ONLY 5% (other blog advertising companies will charge you for at least 20%). Using our system, an advertiser can save at least 15-20% from their blog advertising budget. Sounds good?

I actually did two campaigns with this company and the SEO benefits were significant. I was totally sold on thier service and was even telling friends about them.

Then I recieved an email from one of the bloggers.

I have tried to help your cause by promoting your website and your mission and all I asked was to be paid on time. Here is the post I have written for your company: URL deleted

I have gone out of my way to contact people from www.blogadvertisingstore.com (Paying Post). I have sent e-mails weekly and still no reply. Here are some links to what others are saying about their site. I guess they don’t have a good reputation. I have no other choice than to contact YOU (The Company) that I posted for directly since they aren’t paying me! I have also written a post promoting their site and if I don’t get paid, all my posts WILL be deleted and I will start blogging about how BAD the company is. This in return might hinder your success and I hate to do that. Will you please try contacting them as well. My payment is already a month late! Thank You- Sorry it has come to this.

This person also included the following link in the email which was really eye opening to me.

Blog Advertising

She included a couple other links as well, but this was the most informative. Evidently Blog Advertising Store has been gaining a reputation for taking money from the advertisers and only sometimes paying the bloggers. I soon paid her for the post that she did for me.

Conclusion – I need to find another solution for my pay per post needs. While this seeming scam is to my advantage as an advertiser, I would prefer to take my business to an establishment that works reputably for all parties involved.

I have been recomended to check out these three: PayPerPost, Blogsvertise, and IZEA. These three seem to have a better reputation among the bloggers.

This blog post is not intended to replace the installation documentation put out by Atlassian. Instead, I would like to share information about the integration and installation that you may find useful.

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.

perl-requirements

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.