Wednesday, 29 August 2007

Installing JIRA, a bug & issue tracker

Installing the WAR version
Obtain and extract the WAR file:
gunzip atlassian-jira-enterprise-3.10.2.tar.gz
gtar -xf atlassian-jira-enterprise-3.10.2.tar.gz

Tomcat is installed through Blastwave. The path is /opt/csw/share/tomcat5. Follow the Tomcat installation instructions. The transaction factory in the WAR's edit-webapp/WEB-INF/classes/entitymanager.xml is set to Tomcat and does not need to be changed. There are only two settings to be changed for use with PostgreSQL. Build the distribution and copy from dist-tomcat/ to the web server.

Copy and edit the jira.xml file:
cp {WAR}/dist-tomcat/tomcat5.5/jira.xml /opt/csw/share/tomcat5/conf/Catalina/localhost

The resource should now have four lines:

Obtain the JDBC driver for Tomcat and move it to common/lib:

Extract the jars to Tomcat's common/lib/ directory:

Start Tomcat and go do the setup wizard. LDAP authentication is not tightly coupled therefore you must create JIRA users with the same name as the LDAP users for this to work. A bulk-import of LDAP users can be done if desired.

Grinder 3, a Java load tester

The file download is available here. Once downloaded, you can extract it out to any location. It is used through the java command as explained at this site and here as well.

To get it running as soon as possible, run TCPProxy and set the browser proxy to the port 8001. The proxy will record the actions you take through the browser. Once complete, close the proxy and start the console. Create a from the example given and start the agent. Use the console to start the processes and stop it when you have had enough.

The results obtained are mostly time statistics. One would have to create or edit a script to obtain more specific details. Testing against a local webapp using Tomcat revealed a Java heap memory exception in the Tomcat logs. Against the same webapp on a public server, there was no errors in the Grinder logs.

Tuesday, 28 August 2007

Installing XWiki

Before installing the XWiki WAR version listed here, you'll need to install a servlet container and a relational database, in this case Tomcat and PostgreSQL, following the instructions given.

After configuring XWiki (the concluding step), you will need to import the default skin for functionality. It can be downloaded at the same place as the WAR file.

The LDAP Authentication is basically straightforward. Replace the values with your own and you are set. LDAP users have to login to XWiki before they have a presence there. XWiki groups have to be assigned as the LDAP groups are not imported in.

Friday, 24 August 2007

Installing Confluence

Follow the install guide here. Going through the standalone version, ensure that the Java JDK is installed. Obtain the latest Confluence archive, note: 2.5.6 has a bug that will not allow LDAP authentication to work properly. Also following trying to use the old database with LDAP authentication will open up this bug.

With Solaris, there is no need for the X11 libraries. The home directory is where Confluence data will be kept, Confluence itself is in the archive. Go to the Confluence Setup Wizard Guide. Create the admin user.

LDAP Authentication
Follow this. Note Step 3.2. Step 5 must be successful. For Step 6, refer to this and this. There is a problem with linking LDAP users with their groups, currently both are shown but are not connected. Current solution is to create a Confluence group and use that.

Tuesday, 21 August 2007

LDAP Authentication with TWiki

Using LdapContrib for transparent authentication. Follow the installation instructions, first installing the required dependencies either through the script or manually. This explains more on what LdapContrib does. The LdapNgPlugin and NewUserPlugin may be desired.

Friday, 17 August 2007

Installing TWiki

This post is regarding the installation steps of TWiki on a remote Solaris 11 server. This assumes the installer has root access. The main reference for this post is here - Installing TWiki 4.x on Solaris 10.

Create the following (arbitrary) directory structure in the filesystem:
/apps/twiki-root/twiki - A symlink to the directory below

Download and unpack the latest TWiki version. Create the LocalLib.cfg file in /apps/twiki-root/twiki/bin. Modify it to set the twikiLibPath and the path for TWiki related Perl modules:
$twikiLibPath = "/apps/twiki-root/twiki/lib";

@localPerlLibPath = ('/apps/twiki-root/perlmodules', '/apps/twiki-root/perlmodules/i86pc-solaris-64int');

Building CPAN Perl modules on Solaris 10

Go over to CPAN and download the CGI::Session and Digest::SHA1 modules. Unpack them into temporary directories and use these commands:
$ /usr/perl5/bin/perlgcc Makefile.PL [LIB=/apps/twiki-root/perlmodules]
$ make
$ make test
$ make install

Blastwave for GNU grep, diff and rcs

Follow Blastwave installation instructions to enable pkg-get and install grep, diff and rcs. They will be available in /opt/csw/bin. Create symlinks for egrep(->ggrep), fgrep(->ggrep) and diff(->gdiff).


Create the /etc/apache2/httpd.conf from the example in that directory. Use the ApacheConfigGenerator to configure a twiki.conf file. Settings used for the generator:
Enter the full file path to your twiki root directory (mandatory):

Enter the IP address range or hostnames that will have access to configure - separate with spaces

Enter the list of user names that are allowed to view configure

Enable mod_perl

Choose your Login Manager:
None - No login

Prevent execution of attached files as PHP scripts if PHP is installed:
No PHP Installed

Block direct access to viewing attachments that ends with .htm or .html

Block direct access to viewing attachments in Trash web


Append the file to httpd.conf or otherwise have Apache load it. Restart the Apache Web Server:
svcadm disable apache2
svcadm enable apache2

Check /var/svc/log/network- http:apache2.log to check whether the server is up or it failed to start. Troubleshoot as required.

Browser configuration

Go to http://hostname/twiki/bin/configure to continue configuring TWiki. Use /opt/csw/bin to add to the path. Also use it or create a symlink for rcs. Complete the setup.

Done. More details as forthcoming.

Friday, 10 August 2007

LDAP Authentication with SugarCRM

Both SugarCRM and LDAP are installed. LDAP is to be used to authenticate users in SugarCRM.

Login to SugarCRM as admin. Click on the 'Admin' button at the top of the page and then 'System Settings' in the main page.

Set 'Enable LDAP'. The default LDAP server and port number are localhost and 389 respectively. Change as required. The base dn is the location where the search for users begin, in this case dc=nodomain.

For the bind attribute, disregarding the example text, it should be dn. More information here. The login attribute is the username to be used. Any attribute can be used (e.g uid, sn, cn). An important thing to note is with 'Auto Create Users' set, a change in login attribute will create new users with that attribute as the username. If 'Auto Create Users' is not set, authentication will fail as the user may be present in LDAP but not in the SugarCRM database due to the username.

Authenticated user and password is the LDAP account to be used for searching. The 'Auto Create Users', as mentioned before, creates new users from their LDAP information if they are not present in SugarCRM. The encryption key may be left empty.

Tuesday, 7 August 2007

svnsync: A Subversion Mirror

The steps to mirror a subversion repository are detailed here

My take on those steps:
$ svnadmin create /var/svn/backup
$ echo '#!/bin/sh' > /var/svn/backup/hooks/pre-revprop-change
$ chmod +x /var/svn/backup/hooks/pre-revprop-change
$ svnsync init file:///var/svn/backup svn+ssh://[username][username]/svn/projects
$ svnsync sync file:///var/svn/backup
Other places of interest are here, here and here