Step by step JIRA Installation

JIRA
JIRA provides issue tracking and project tracking for software development teams to improve code quality and the speed of development.

Combining a clean, fast interface for capturing and organising issues with customisable workflows, OpenSocial dashboards and a pluggable integration framework, JIRA is the perfect fit at the centre of your development team.

Bug tracking with JIRA
Bugs are an inevitable part of software development for every team—large or small. We believe your bug tracker should be simple and intuitive without sacrificing functionality or forcing you to change the way you work. JIRA makes bug tracking personalized and painless, so your team focuses energy on what matters most: great code.

Powerful, yet simple
JIRA simplifies every step of tracking bugs for everyone involved. Creating, triaging and resolving bugs is a snap with a clean, intuitive interface.
View issue details including custom fields, attachments, workflow actions and recent activity
Create new bugs in seconds from your browser, email, IDE or smart phone client
Navigate JIRA and execute issue actions using keyboard shortcuts
Quickly triage issues with auto–complete entry fields for labels, components and versions
Leverage activity history to quickly access recently opened issues, projects and searches

JIRA 4.3.3
#  Download the JIRA Standalone TAR (.GZ) file here.
wget http://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-4.3.3.tar.gz

#  Unzip the downloaded file.
tar xzvf atlassian-jira-4.3.3.tar.gz

#  Create JIRA Installation/Home Directory
mkdir /opt/jira

#  Copy Extracted files to JIRA’s Installation Directory (-R is for recursive)
cp -R atlassian-jira-4.3.3-standalone/* /opt/jira/

#  Lets create a directory for JIRA to store attachments, indexes, and other stuff’s:
mkdir /opt/jira/home

#  Now, we need to set the JIRA HOME property:
nano /opt/jira/atlassian-jira/WEB-INF/classes/jira-application.properties

#  Change the existing line (or a add new)
jira.home =
#  to
jira.home = /opt/jira/home

================================================
#  Change Confluence listening port
vi /opt/jira/conf/server.xml
   1. Change the port 8005 to 7101
   2. Change the port 8080 to 7100
   3. Change the port 8443 to 7102

service iptables restart
================================================
#  Almost done, we need to open up port 7100 in your local firewall (IPTABLES), or we won’t be able to hit JIRA from our browser:
nano /etc/sysconfig/iptables

#  Change this line:
-A RH-Firewall-1-INPUT -j REJECT --reject with icmp-host-prohibited
#  To include an additional 3 lines above it for 7100 traffic, like so:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 7100 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 7101 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 7102 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject with icmp-host-prohibited

service iptables restart
#  Configure Apache Tomcat to Run as a Service.
cd /etc/init.d
vi jira

===========================================================
#!/bin/bash
# description: jira Start Stop Restart
# processname: jira
# chkconfig: 234 20 80
JAVA_HOME=/usr/java/jdk1.6.0_25
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
JIRA_HOME=/opt/jira
case $1 in
start)
sh $JIRA_HOME/bin/startup.sh
;;
stop)  
sh $JIRA_HOME/bin/shutdown.sh
;;
restart)
sh $JIRA_HOME/bin/shutdown.sh
sh $JIRA_HOME/bin/startup.sh
;;
esac   
exit 0
===========================================================

#  Set the permissions for your script to make it executable:
chmod 755 jira

#  Launch JIRA:
cd /opt/jira/bin
./startup.sh

#  OR Launch JIRA:
service jira start/ stop/ restart


JIRA Configuration with MySQL Database
======================================
## Current JIRA Version 4.3.3
## XML backup
## You can also configure scheduled XML backups, as described in Automating JIRA Backups.
1. Log in as a user with the 'JIRA System Administrators' global permission.
2. Bring up the administration page by clicking either the 'Administration' link on the top bar or the title of the Administration box on the dashboard.
3. Under the 'Import & Export' sub-menu in the left-hand navigation column, click the 'Backup Data to XML' link. This will display the 'Backup JIRA data' page:

## restart jira server
/etc/init.d/jira stop

## MySQL Create Database and User
create database jiradb character set utf8;
grant select, insert, update, delete, create, drop, alter, index on jiradb.* to 'jiradbuser'@'localhost' identified by 'jiradbuserpass';
flush privileges;
select host,user from mysql.user;
select host,db,user from mysql.db;

## Edit server.xml file and update following data between dash(-)
## Please comment the existing config and paste following
vi /opt/jira/conf/server.xml

-----------------------------
<Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
    driverClassName="com.mysql.jdbc.Driver"
    url="jdbc:mysql://localhost:3306/jiradb?useUnicode=true&amp;characterEncoding=utf8&amp;sessionVariables=storage_engine=InnoDB"
    username="jiradbuser"
    password="jiradbuserpass"
    maxActive="20"
    validationQuery="select 1"
    />
-----------------------------

## Edit entityengine.xml and update following data between dash(-)
## Please comment the existing config and paste following
vi /opt/jira/atlassian-jira/WEB-INF/classes/entityengine.xml
-----------------------------
<datasource name="defaultDS" field-type-name="mysql"
      helper-class="org.ofbiz.core.entity.GenericHelperDAO"
      check-on-start="true"
      use-foreign-keys="false"
      use-foreign-key-indices="false"
      check-fks-on-start="false"
      check-fk-indices-on-start="false"
      add-missing-on-start="true"
      check-indices-on-start="true">
-----------------------------

# Copy Jira backup file from "infostore server" to 192.168.1.15 server
scp amunjal@120.136.46.140:/opt/jira/home/export/atlasian-jira-backup-20110720.xml /opt/sware/
# Copy backup file to "/opt/jira/home/import/" directory to import the backup files
cp /opt/jira/home/export/<backup-file-name.xml> /opt/jira/home/import/<backup-file-name.xml>

## restart jira server
/etc/init.d/jira start

## Now install atlassian-jira again
## Restore backup from import directory
1. Log in as a user with the 'JIRA System Administrators' global permission.
2. Bring up the administration page by clicking either the 'Administration' link on the top bar or the title of the Administration box on the dashboard.
3. Under the 'Import & Export' sub-menu in the left-hand navigation column, click the 'Restore Data from XML' link.
4. Enter file name (latest-backup-file-name.xml) in the "File name" field which is located in the "/opt/jira/home/import" then click "Restore" button.

## Now Last backup settings(usernames, passwords, configurations) will affect.

Step by Step Subversion Installation Reference for Redhat Linux

SVN Subversion installation steps on server
=============================
I am expecting you have already installed Apache http web server on your linux machine (Here using RHEL-5).

1. # Download following rpm files in the (path) /opt/sware/svn
cd /opt/sware/svn

2. # Download Following From: http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel5/x86_64/
-----------------------------
mod_dav_svn-1.5.5-1.rhel5.x86_64.rpm
neon-0.27.2-1.x86_64.rpm
neon-debuginfo-0.27.2-1.x86_64.rpm
neon-devel-0.27.2-1.x86_64.rpm
subversion-1.5.5-1.rhel5.x86_64.rpm
subversion-devel-1.5.5-1.rhel5.x86_64.rpm
subversion-perl-1.5.5-1.rhel5.x86_64.rpm
subversion-python-1.5.5-1.rhel5.x86_64.rpm
subversion-tools-1.5.5-1.rhel5.x86_64.rpm

3. # Install subversion and dependent
rpm -U neon-0.27.2-1.x86_64.rpm
rpm -U neon-devel-0.27.2-1.x86_64.rpm
rpm -i subversion-1.5.5-1.rhel5.x86_64.rpm
rpm -i mod_dav_svn-1.5.5-1.rhel5.x86_64.rpm

4. # Create an SVN repository
svnadmin create /svnroot

5. # Make it accessible to the web server
chown -R apache.apache /svnroot/

6. # Edit the web servers configuration
vi /etc/httpd/conf/httpd.conf

7. # Uncomment (remove the '#' mark) the following lines:
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_module modules/mod_dav.so

8. # Add the following lines to the configuration:
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule dav_svn_module modules/mod_authz_svn.so
<Location /svn>
    DAV svn
    SVNPath /svnroot
    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /etc/httpd/conf.d/dav_svn.passwd
    Require valid-user
</Location>

9.
# Add a new user to the authentication file. Only
# authenticated users will be able to access the repository.
# The passwords are held in this file using a one-way hashed
# encryption
htpasswd -c /etc/httpd/conf.d/dav_svn.passwd test.user1
# To add a new user (again other than first time)
htpasswd -c /etc/httpd/conf.d/dav_svn.passwd test.user1

10. # Restart the web server for the settings to take effect
/etc/init.d/httpd restart

11. http://your-domain.com/svn
Example: http://edurain.com/svn

A short setting explanation of what you just entered:
======================================
<Location /svn>: Means that the Subversion repositories are available from the URL like http://edurain.com/svn/
DAV svn: tells Apache which module will be responsible to serve that URL - in this case the Subversion module.
SVNListParentPath on: For Subversion version 1.3 and higher, this directive enables listing all the available repositories under SVNParentPath.
SVNParentPath /svnroot: tells Subversion to look for repositories below /svnroot
SVNIndexXSLT "/svnindex.xsl": Used to make the browsing with a web browser prettier.
AuthType Basic: is to activate basic authentication, i.e. Username/password
AuthName "Subversion repositories": is used as an information whenever an authentication dialog pops up to tell the user what the authentication is for
AuthUserFile passwd: specifies which password file to use for authentication
AuthzSVNAccessFile: Location of the Access file for paths inside a Subversion repository
Require valid-user: specifies that only users who entered a correct username/password are allowed to access the URL

Subversion Reference on Linux

Version Control Basics
Version control is the art of managing changes to information. It has long been a critical tool for programmers, who typically spend their time making small changes to software and then undoing or checking some of those changes the next day. Imagine a team of such developers working concurrently - and perhaps even simultaneously on the very same files! - and you can see why a good system is needed to manage the potential chaos.
A version control system (or revision control system) is a system that tracks incremental versions (or revisions) of files and, in some cases, directories over time. Of course, merely tracking the various versions of a user's (or group of users') files and directories isn't very interesting in itself. What makes a version control system useful is the fact that it allows you to explore the changes which resulted in each of those versions and facilitates the arbitrary recall of the same.

The Repository
Subversion is a centralized system for sharing information. At its core is a repository, which is a central store of data. The repository stores information in the form of a filesystem tree - a typical hierarchy of files and directories. Any number of clients connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others.
The repository is a kind of file server, but it's not your usual breed. What makes the Subversion repository special is that it remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories. When a client reads data from the repository, it normally sees only the latest version of the filesystem tree. But the client also has the ability to view previous states of the filesystem. For example, a client can ask historical questions like, “what did this directory contain last Wednesday?”, or “who was the last person to change this file, and what changes did they make?” These are the sorts of questions that are at the heart of any version control system: systems that are designed to record and track changes to data over time.

Version Control the Subversion Way
Subversion is a modern, network-aware version control system. As we described in the section called “Version Control Basics” (our high-level version control overview), a repository serves as the core storage mechanism for Subversion's versioned data, and it's via working copies that users and their software programs interact with that data. In this section, we'll begin to introduce the specific ways in which Subversion implements version control.

Subversion Repositories
Subversion implements the concept of a version control repository much as any other modern version control system would. Unlike a working copy, a Subversion repository is an abstract entity, able to be operated upon almost exclusively by Subversion's own libraries and tools. As most of a user's Subversion interactions involve the use of the Subversion client and occur in the context of a working copy, we spend the majority of this book discussing the Subversion working copy and how to manipulate it.

Revisions
A Subversion client commits (that is, communicates the changes made to) any number of files and directories as a single atomic transaction. By atomic transaction, we mean simply this: either all of the changes are accepted into the repository, or none of them is. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number assigned to the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory.

Addressing the Repository
Subversion client programs use URLs to identify versioned files and directories in Subversion repositories. For the most part, these URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL:

$ svn checkout http://svn.edurain.com:8081/repos

Subversion Working Copies
A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. You can even have multiple working copies of the same project.
After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to “publish” your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working copy (by reading from the repository).
A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy's administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out of date with respect to others' work.

How the working copy works
For each file in a working directory, Subversion records (among other things) two essential pieces of information:

•     What revision your working file is based on (this is called the file's working revision)
•     A timestamp recording when the local copy was last updated by the repository

Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:
Unchanged, and current
    The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing.
Locally changed, and current
    The file has been changed in the working directory, and no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus an svn commit of the file will succeed in publishing your changes, and an svn update of the file will do nothing.
Unchanged, and out of date
    The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision. An svn commit of the file will do nothing, and an svn update of the file will fold the latest changes into your working copy.
Locally changed, and out of date
    The file has been changed both in the working directory and in the repository. An svn commit of the file will fail with an “out-of-date” error. The file should be updated first; an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.

Fundamental working copy interactions
A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.
For example, suppose you have a repository that contains two software projects, paint and calc. Each project lives in its own top-level subdirectory.
To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)