apt-get install make wget
mkdir -p /usr/local/src/rt
addgroup rt
adduser www-data rt
cd /usr/local/src/rt
wget http://www.fsck.com/pub/rt/devel/rt-2-0-12-pre6.tar.gz
tar xzf rt-2-0-12-pre6.tar.gz
Perl Dependancies
This is the fun part.
basicly, keep running make testdeps until it finds everything. You'll likely need the following packages. (all in the debian archives)
- libhtml-mason-perl
- libapache-mod-perl
- libmd5-perl
- libstorable-perl
- libdbix-datasource-perl
- libdbix-searchbuilder-perl (note: there may be a newer version in cpan, that you want)
- libapache-request-perl
- libcgi-perl
- libcgi-pm-perl
- libapache-session-perl
- libtimedate-perl
- libmime-perl
- libtie-ixhash-perl
- libtext-wrapper-perl
- libtext-template-perl
- libfreezethaw-perl
- liblog-dispatch-perl
- libapache-dbi-perl (very important. not in testdeps)
- perl-suid (very important. not in testdeps)
Install RT
follow the install guide.make installthis will prompt you for several passwords. most of the time it wants the mysql admin/root passwords, but sometimes it wants the rt users's password. pay attention to what it says.
Full install notes for RedHat 7.2
From the mailing list.
You may need to twiddle the <s and >s around
From: Gary Leong <gwleong@XXX.XXX>
To: rt-users@lists.fsck.com
Subject: [rt-users] RH 7.2 step by step
Message-ID: <3CED786B.59C06A31@lbl.gov>
Date: Thu, 23 May 2002 16:16:59 -0700
Here are the step by step instructions I promised way back when. I
didn't get a chance to write it up until now. It's off the top of my
head, so I do apologize if I neglected a step or two. Please let me
know of any mistakes, so I can update the instructions on
documenations.. Thanks.
I also attached the file.
Gary
1)Install Redhat 7.2
2)Remove apache in distributed Redhat 7.2
To a get a list, run this command:
rpm -qa | grep apache
apacheconf-0.8.1-1
apache-manual-1.3.22-2
apache-devel-1.3.22-2
apache-1.3.22-2
then run
rpm -e apacheconf-0.8.1-1
rpm -e apache-manual-1.3.22-2
rpm -e apache-devel-1.3.22-2
rpm -e apache-1.3.22-2
3)Download mod_perl and apache source. I put the source in /temp. Unzip
and untar the source.
gunzip -c apache_1.13.9.tar.gz | tar xvf -
gunzip -c mod_perl-1.26.tar.gz | tar xvf -
4)To install Apache with mod_perl statically compiled.
cd into the mod_perl directory and run the following commands to
configure mod_perl for apache install:
cd /temp/mod_perl-1.26
perl Makefile.PL \
APACHE_SRC=../apache_1.13.9/src \
NO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1 \
make
make install
cd into apache source directory. To install apache, run the following
commands:
cd /temp/apache_1.3.19/
./configure --prefix=/usr/local/apache \
--activate-module=src/modules/perl/libperl.a \
5) Download and install CPAN
unzip and untar source and cd into CPAN source directory.
follow these commands to install:
gunzip -c CPAN-1.59.tar.gz | tar xvf -
cd /temp/CPAN*
perl Makefile.PL
make
make install
6) Install Mason manually as CPAN doesn't seem to download and install
it automatically.
unzip and untar source and cd into Mason directory.
gunzip -c HTML-Mason-1.04.tar.gz | tar xvf -
cd /temp/HTML-*
perl Makefile.PL
make
make install
7) Download and unpackage RT.
gunzip -c rt.tar.gz | tar xvf -
8) Get dependent modules.
cd /temp/rt-2-0-9/
make testdeps
make fixdeps
9) Configure preliminarily apache.
a)In http.conf, change the following lines. They are in this order,
but not juxtaposed vertically. Do a search
make the changes.
ServerType stand
ServerRoot "/usr/local/apache"
MinSpareServers 5
MaxSpareServers 20
StartServers 8
MaxClients 150
MaxRequestsPerChild 100
Listen 80
Port 80
User apache
Group apache
ErrorLog /var/log/httpd/error.log
CustomLog /var/log/httpd/access_log combined
b)Make log directories.
mkdir -p /var/log/httpd/error.log /var/log/httpd/access_log
chown -R apache:apache /var/log/httpd/error.log
/var/log/httpd/access_log
10) Create user rt.
groupadd -g 35 rt
useradd -m -d /home/rt -u 4040 -g 35 rt
11) Set root password for MySQL database.
e.g.
username: root
password: 123456
The syntax is as follows:
/mysql/admin -u root password '123456'
12) Install RT
a) Make changes to Makefile
cd /tmp/rt-2-0-9
vi Makefile
for these entries
RT_PATH = /opt/rt2
RT_LOG_PATH = /var/log/rt2
DB_TYPE = Mysql
DB_HOME = /usr/bin/mysql
DB_DBA = root
DB_DBA_PASSWORD = "123456"
DB_RT_USER = rt
WEB_USER = apache
WEB_GROUP = apache
c) mkdir -p /var/log/rt2
chown -R root:rt /var/log/rt2
chmod 755 /var/log/rt2
b) Install rt: build database and install rt files.
make install
13) Set up Sendmail
a) configure Sendmail to receive connections outside of localhost.
Sendmail from Redhat
by default doesn't allow outside email.
change the mc file
vi /etc/mail/sendmail.mc
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
<-------------dnl this entry
run the command
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
vi /etc/aliases
rt-comment: "|/opt/rt2/bin/rt-mailgate --queue general --action
comment" <----------add the following entry
rt: "|/opt/rt2/bin/rt-mailgate --queue general --action
correspond" <----------add the following entry
14) Configure config.pm file for rt
Let's say our domain is wheats.com.
a) Change the following in the file, accordingly.
e.g.
$rtname="wheats.com";
$rtname="wheats.com";
$DatabaseUser='rt';
$DatabasePassword='123456';
$CorrespondAddress='rt';
$CommentAddress='rt';
15) Make sure user rt can access and manipulate database.
e.g.
username: root
password: 123456
mysql -u root -p
GRANT ALL ON rt2.db.* To rt@localhost Identified By "123456"
quit
16) Setup rt to access by Apache.
e.g.
IP address of rt machine: 128.5.3.11
Only machines in wheats.com domain will allow be accessed.
In the httpd.conf file in /usr/local/apache/conf
a) Add the following entries, accordingly.
#NameVirtualHost *
<VirtualHost 128.5.3.11>
DocumentRoot /opt/rt2/WebRT/html
ServerName dummy.wheats.com
PerlModule Apache::DBI
PerlRequire /opt/rt2/bin/webmux.pl
<Location />
SetHandler perl-script
PerlHandler RT::Mason
Order allow,deny
Allow from *.wheats.lbl.gov
</Location>
</VirtualHost>
17) Add apache to run scripts.
cp /usr/local/apache/bin/apachect1 /etc/init.d/
ln -s /etc/init.d/apachect1 /etc/rc3.d/S99httpd
18) Reboot the machine. I hope everything works. Please, please let me
know if things don't go right or how
I can make things clearer.
1)Install Redhat 7.2
2)Remove apache in distributed Redhat 7.2
To a get a list, run this command:
rpm -qa | grep apache
apacheconf-0.8.1-1
apache-manual-1.3.22-2
apache-devel-1.3.22-2
apache-1.3.22-2
then run
rpm -e apacheconf-0.8.1-1
rpm -e apache-manual-1.3.22-2
rpm -e apache-devel-1.3.22-2
rpm -e apache-1.3.22-2
3)Download mod_perl and apache source. I put the source in /temp. Unzip and untar the source.
gunzip -c apache_1.13.9.tar.gz | tar xvf -
gunzip -c mod_perl-1.26.tar.gz | tar xvf -
4)To install Apache with mod_perl statically compiled.
cd into the mod_perl directory and run the following commands to configure mod_perl for apache install:
cd /temp/mod_perl-1.26
perl Makefile.PL \
APACHE_SRC=../apache_1.13.9/src \
NO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1 \
make
make install
cd into apache source directory. To install apache, run the following commands:
cd /temp/apache_1.3.19/
./configure --prefix=/usr/local/apache \
--activate-module=src/modules/perl/libperl.a \
5) Download and install CPAN
unzip and untar source and cd into CPAN source directory.
follow these commands to install:
gunzip -c CPAN-1.59.tar.gz | tar xvf -
cd /temp/CPAN*
perl Makefile.PL
make
make install
6) Install Mason manually as CPAN doesn't seem to download and install it automatically.
unzip and untar source and cd into Mason directory.
gunzip -c HTML-Mason-1.04.tar.gz | tar xvf -
cd /temp/HTML-*
perl Makefile.PL
make
make install
7) Download and unpackage RT.
gunzip -c rt.tar.gz | tar xvf -
8) Get dependent modules.
cd /temp/rt-2-0-9/
make testdeps
make fixdeps
9) Configure preliminarily apache.
a)In http.conf, change the following lines. They are in this order, but not juxtaposed vertically. Do a search
make the changes.
ServerType stand
ServerRoot "/usr/local/apache"
MinSpareServers 5
MaxSpareServers 20
StartServers 8
MaxClients 150
MaxRequestsPerChild 100
Listen 80
Port 80
User apache
Group apache
ErrorLog /var/log/httpd/error.log
CustomLog /var/log/httpd/access_log combined
b)Make log directories.
mkdir -p /var/log/httpd/error.log /var/log/httpd/access_log
chown -R apache:apache /var/log/httpd/error.log /var/log/httpd/access_log
10) Create user rt.
groupadd -g 35 rt
useradd -m -d /home/rt -u 4040 -g 35 rt
11) Set root password for MySQL database.
e.g.
username: root
password: 123456
The syntax is as follows:
/mysql/admin -u root password '123456'
12) Install RT
a) Make changes to Makefile
cd /tmp/rt-2-0-9
vi Makefile
for these entries
RT_PATH = /opt/rt2
RT_LOG_PATH = /var/log/rt2
DB_TYPE = Mysql
DB_HOME = /usr/bin/mysql
DB_DBA = root
DB_DBA_PASSWORD = "123456"
DB_RT_USER = rt
WEB_USER = apache
WEB_GROUP = apache
c) mkdir -p /var/log/rt2
chown -R root:rt /var/log/rt2
chmod 755 /var/log/rt2
b) Install rt: build database and install rt files.
make install
13) Set up Sendmail
a) configure Sendmail to receive connections outside of localhost. Sendmail from Redhat
by default doesn't allow outside email.
change the mc file
vi /etc/mail/sendmail.mc
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA') <-------------dnl this entry
run the command
m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
vi /etc/aliases
rt-comment: "|/opt/rt2/bin/rt-mailgate --queue general --action comment" <----------add the following entry
rt: "|/opt/rt2/bin/rt-mailgate --queue general --action correspond" <----------add the following entry
14) Configure config.pm file for rt
Let's say our domain is wheats.com.
a) Change the following in the file, accordingly.
e.g.
$rtname="wheats.com";
$rtname="wheats.com";
$DatabaseUser='rt';
$DatabasePassword='123456';
$CorrespondAddress='rt';
$CommentAddress='rt';
15) Make sure user rt can access and manipulate database.
e.g.
username: root
password: 123456
mysql -u root -p
GRANT ALL ON rt2.db.* To rt@localhost Identified By "123456"
quit
16) Setup rt to access by Apache.
e.g.
IP address of rt machine: 128.5.3.11
Only machines in wheats.com domain will allow be accessed.
In the httpd.conf file in /usr/local/apache/conf
a) Add the following entries, accordingly.
#NameVirtualHost *
<VirtualHost 128.5.3.11>
DocumentRoot /opt/rt2/WebRT/html
ServerName dummy.wheats.com
PerlModule Apache::DBI
PerlRequire /opt/rt2/bin/webmux.pl
<Location />
SetHandler perl-script
PerlHandler RT::Mason
Order allow,deny
Allow from *.wheats.lbl.gov
</Location>
</VirtualHost>
17) Add apache to run scripts.
cp /usr/local/apache/bin/apachect1 /etc/init.d/
ln -s /etc/init.d/apachect1 /etc/rc3.d/S99httpd
18) Reboot the machine. I hope everything works. Please, please let me know if things don't go right or how
I can make things clearer.
Installation notes for Solaris
These notes courtsey of Stanislav Sinyagin:
Most of the installation process goes without problems. The only known concern is Sendmail configuration.
In Solaris 8, Sendmail executable is placed where you normally don't expect it: /usr/lib/sendmail. Thus, you need to set $SendmailPath in etc/config.pm.
In addition, you might want to change the default Sendmail configuration. In /usr/lib/mail/ you will find the sources for Sendmail configuration files (available via package SUNWsndmu). Note that the default configuration supplied by Solaris rewrites the sender's address with the fully qualified hostname. You may change this with MASQUERADE_AS(support.yourdomain.com) statement. Note that it's incompatible with FEATURE(`remote_mode').
Administration Guide
Concepts
RT is a complex application. You need to understand the concepts behind RT and the terminology describing these concepts if you are going to deploy it to the best effect in your organisation.
Terminology
Ticket
Each ticket is identified by a unique ticket number. The terms ticket and request are used interchangably. Users with a background with the commercial Clarify helpdesk system will be used to the term Case, which also means the same thing.
Links
Tickets can be linked to each other with these relationships:
- MemberOf
- RelatedTo
- DependsOn
- MergedInto
Requestor
The user who created the request. He may or may not be a user on the local Unix system. Depending on how RT is configured, he might instead be someone sending an email whose identity cannot be verified.
Status
A ticket will always have a status which may be one of:
- New: The ticket has never been viewed or acted upon.
- Open: The ticket has been viewed, and is being dealt with.
- Stalled: The ticket has been put on hold as it cannot presently be resolved. If there is any further correspondance, the ticket will automatically be reopened.
- Resolved: The ticket has been dealt with, and is no longer an issue.
- Dead: This indicates that the ticket was deleted. Usually tickets are only deleted in the case of duplicate requests or spam email. For technical reasons a ticket is never erased from the database, it just has the Dead status.
Sites will sometimes have their own interpretation of each status.
Users
Every person or program that interacts with RT has a username and is therefore a user. A user has attributes stored against their username. There is only one type of user, but the attributes means that users have very different capabilities within the RT system.
Examples of attributes used to differentiate users are:
- Ticket privileges, where a user has the ability to perform a certain action to tickets such as create or delete
- Group memberships, where a user shares attributes with other users
- Unix username, which gives the user the right to use RT from the Unix commandline interface
Sometimes it looks like someone can interact with RT without having a username. As you'll find out elsewhere in this documentation, this is not correct.
-
Attributes
Some attribute information is stored for every user.- Name. This is the username that all activity is logged by. It need not correspond to a username in any other system at all, although it can do either via the external authentication scheme or via the Gecos Unix Username attribute.
- Password. This can be null, although of course it is normally bad policy to do so.
- Gecos (Unix Username). If this is not set then the user cannot log in via RT's commandline tool, which uses the unix username for authentication.
-
Privileged Users
Privileged users are users who can be granted rights and responsibilities. Typically they are the staff of the organisation using RT but that entirely depends how your organisation is structured. For example, you can easily create privileged users with minimal privileges to allow your customers to contribute to tickets about a certain topic. -
Nonprivileged Users
These users can not be granted rights or responsibilites (except as members of pseudogroups. These users can not access the normal RT web interface. When they access the web interface, they are immediately shunted to RT's "SelfService" interface for requestors.When email is submitted to RT's email gateway from an unknown email address, RT will automatically create a Nonprivileged user with a name derived from the email address. RT will assign the ticket to the special nonprivileged user nobody. The newly-created Nonprivileged user is required in order for RT to function (eg to track correspondance) and has nothing to do with ticket ownership, queue privileges or anything else. It is a very good idea to put RT behind a spam filter such as Spamassasian.
It is not currently possible to force tickets that are automatically created like this to be owned by a particular user.
Queue
A queue contains tickets generally of a similar nature, for example, a technical support queue. Queues are an administrative unit with their own privileges, scrip actions, templates and keywords. Each ticket can only be associated with one queue.
Multiple queues may be set up, and each will have its own email address. So you might have a queue called noc@example.com which is monitored by technical staff, and billing@example.com which is used by accounts staff. Tickets may be moved between queues, so a tech could pass a ticket onto the accounts department once work has completed.
Queues can be configured differently, so the noc queue may issue an autoresponse when a ticket is created, whereas the accounts queue might be configured to prevent internal correspondance being sent to the requestor.
Groups
Groups are logical collections of usernames. In general, if an RT operation can be performed on a single user it can be performed on a group as well.
This is particularly useful when dealing with permissions and ACLs. So for example it often makes sense to give a particular group read-only access to a certain queue rather than the many members of that group. Removing a username from the group causes all privileges granted via that group membership to be revoked.
-
Normal Groups
These consists of collections of usernames. -
Pseudogroups
These are special collections of usernames, and contain some special usernames. These come configured by default. Pseudogroups cannot be created by an Administrator, they are built in to RT. Some memberships in pseudogroups can be changed, however. A list of the pseudogroups is:
Watchers
Watchers are (essentially) people that get email about tickets. Watchers can be added globally (all queues), per-queue, or per-ticket. Right now, watchers can only be individual users, not groups. I expect this to change.
There are three sorts of watchers, as follows.
-
Types of Watchers
There are three types of watchers.-
Requestors
Requestors are people making the request which ended up in a particular queue by some means. The requestor does not own a ticket because they made the request (and in most installations the requestor cannot own a ticket), but the requestor usually does get at least some correspondance via email, for example an automated reply via the AutoReply scrip.Requestors traditionally see only correspondence, however since RT knows about some kinds of users (either because they are RT users, or because RT does a matching between email address and RT username) a requestor may also be someone with privileges to do things to the ticket.
-
Ccs
Ccs are people other than the Requestor who need to see email traffic relating to the ticket (exactly what traffic depends on the scripactions that have been set up.) The thing distinguishing a Cc is that while they receive this email they do not necessarily have privileges to do anything in the RT system. Any email address anywhere on the Internet can be in the Cc list. -
AdminCc
An AdminCc is just like a Cc, except that the recipient is someone with privileges to do things in RT. Often this may be used so that AdminCcs get to see more details about ticket activity, however this is not necessarily so (for example, some queue administrators might not wish to be burdened with a lot of email.)The only people that can be added as a AdminCcs for a queue are those with permissions to administer tickets in that queue.
-
Requestors
-
Watcher Scopes
Keywords
Keywords are tags specific to your organisation that are presented to queue administrators for their use in classifying tickets. The definition and use of keywords is entirely site-specific. Keywords are definied in a hierachical tree.
Keywords can be used for searching and reporting, and as trigger values in Scrips. This Administration Guide has an extensive section on keywords which includes a tutorial.
Access Control (ACLs)
rt2 includes a rich acl scheme which supports granting rights to users and groups for a given queue or for the entire RT instance.
rights can be granted to:
a specific user who has the privileged flag set and doesn't have the disabled flag set
a specific locally defined group
one of several 'pseudogroups':
everyone, requestor, cc, admincc, owner
Rights granted to an individual user are granted to that user and only that user
Rights granted to a locally defined group will be made available to all members
of that group, so long as they remain members of the group.
rights granted to the pseudo-group 'everyone' will be granted to all users.
Rights granted to any of the following pseudo-groups will be dynamically
granted to users based on the current ticket being dealt with:
requestor, cc, admincc, owner.
Description of Rights
Rights can be granted to users and groups to define what the user is allowed to do and change in RT. Rights can apply to the whole of RT and all the queues (global) or can apply to a single specific queue. Rights can be granted to individual users and to defined groups of users.
Rights can also be assigned to pseudogroups that define users in a context. The pseudogroups are "Everyone" (all the users on the system), "Requestor" (users that are requestor in the context of the current ticket), "Cc" (users that are Cc , either direct by the ticket or defined in the queue, of the selected ticket) and "AdminCc" (users that are Administrative Cc to the ticket or the ticket's queue).
The effective rights of a user are the combination of the global personal right, the combined global rights of the groups the user is in, the rights of the user and all the groups that the user is in to the currently selected queue and the rights the user gets through the pseudogroups.
A description of all the rights that users and groups can be assigned in RT follows:
- AdminGroups (global only)
- Users with this right are allowed to create new groups, modify the name and description of the group and add and remove registered users to and from the group.
- AdminKeywordSelects (global and queue)
- Users with the AdminKeywordSelects should be able to add, delete and modify keyword selections for a specific queue (or all queues if this right is set globally).
- AdminKeywords (global only)
- Users with the AdminKeywords rights can add, modify and delete keywords. Keywords are global to RT.
- AdminQueue (global and queue)
- Users with the AdminQueue right can change can change anything on the queue 'basics' screen. They can create queues (if granted the right globally) They can "disable" a queue. Which means that no new tickets can be created in the queue.
- AdminUsers (global only)
- Users with this right are allowed to add and modify users. All privileged users are allowed to browse all the registered users.
- CommentOnTicket (global and queue)
- Users with the CommentOnTicket right are allowed to add comments to tickets. When this right is global a user can add comments to all the tickets in RT otherwise the user is only allowed to comment on tickets in the specified queue.
- CreateTicket (global and queue)
- Users with the CreateTicket right can create requests in the specified queue or in all the queues if global is selected.
- ModifyACL (global and queue)
- If a user has the ModifyACL right he/she can change the rights different users and groups can be assigned regarding queues. If the ModifyACL right was granted globally the user can change all the ACLs in RT, including the global ones (including granting him/herself SuperUser privileges). ModifyACL does strange things without ShowACL.
- ModifyQueueWatchers (global and queue)
- This rights enables a user to register and remove other users as watchers (Cc and AdminCc) to a queue. If this right is assigned globally the user can modify watcher settings of all the queues.
- ModifyScrips (global and queue)
- This right allows a user to add and delete scrips from a queue of, if the right is granted globally, change the global default scrips.
- ModifySelf (global only)
- This allows the user to change his/her personal settings. The following fields are now only modifiable by folks with "AdminUsers" permission: Organization, Disabled, Privileged, Name, ExternalContactInfoId, ContactInfoSystem, ExternalAuthId, AuthSystem, Gecos The basic philosophy behind the decision about what to limit editing to is that the user should be free to modify their own contact info, but should not be able to modify RT username or fields that could effect ACLs. (Organization is something that folks may be keying external lookups off. I could probably be convinced to make this 'open')
- ModifyTemplate (global and queue)
- The user is allowed to modify the templates. If this right is granted globally the user may modify the global templates and the templates for all the queues. >
- ModifyTicket (global and queue)
- The user is allowed to modify the ticket. Modifying the ticket includes changing the subject, status, time worked, time left, priorities. ticket dates, keyword values, owner (to users that are allowed to own the ticket?), requestor and watchers and relationships with other tickets. The user can also comment and correspond on tickets.
- OwnTicket (global and queue)
- Only users that have the OwnTicket right can be owners of a ticket. This right can be granted globally or per queue.
- ReplyToTicket (global and queue)
- User with a ReplyToTicket right can add replies to a ticket.
- SeeQueue (global and queue)
- This right right allows the user to see that a given queue (or all queues) exists
- ShowACL (global and queue)
- This allows the user to view the currently active ACLs (rights granted to users and groups). When this rights is applies globally the user is allowed to view all system ACLS
- ShowScrips (global and queue)
- Users with this right are allowed to view scrips.
- ShowTemplate (global and queue)
- Users with this right are allowed to view the mail templates.
- ShowTicket (global and queue)
- Users with this right are allowed to display the ticket.
- ShowTicketComments (global and queue)
- Users are allowed to view the comments entered with tickets.
- SuperUser (global only)
- A SuperUser is allowed to do anything.
- Watch (global and queue)
- The user is allowed to sign up to "watch" this queue or tickets in this queue as a cc or a requestor. The user is also allowed to stop watching tickets in this queue. Think of this as AdminWatchers, but only for oneself as requestor or CC.
- WatchAsAdminCc (global and queue)
- Like Watch, but only as an Admin
Scrips
RT 2.0 includes a powerful system for implementing local business logic, called 'Scrips'. (The 'Scrips' system is a combination of a 'script' system and a 'subscription' system).
With RT 1.0, the requestors of a ticket were automatically emailed on any correspondence that RT couldn't determine came from them. RT 2.0 allows each site to control this and many other behaviors at the queue level. Through the scrips mechanism, RT 2.0 allows local administrators to define what actions should be taken on each transaction.
Scrips can be defined per-queue and system-wide. Each scrip is composed of a Condition, an Action and a Template.
For 2.0 there isn't an exposed user interface for defining new actions and conditions, though the programming API is simple and well defined.
Conditions
Conditions are things like:
- OnCorrespond OnComment
- OnCreate
- OnStall
- OnResolve
- OnTransaction
Actions
Actions include things like:
- NotifyRequestorsAsCorrespondence
- NotifyCcsAsCorrespondence
- NotifyAdminCcsAsCorrespondence
- NotifyAllWatchersAsCorrespondence
- NotifyRequestorsAsComment
- NotifyCcsAsComment
- NotifyAdminCcsAsComment
- NotifyAllWatchersAsComment
Note: Notify scrips do not send mail to the user performing the action.
Templates
There are a bunch of predefined system-wide templates like:
- Autoreply
- Transaction
- Correspondence
- Comment
Additionally, RT allows local RT administrators to define new system-wide tempaltes and allows queue administrators to define per-queue templates.
Templates can optionally have RFC822 headers which will be appended
to an outgoing mail message. If a template has such headers, it
B
Relationships
RT2 has the concept of arbitary relationships that link two (or more) tickets together. A ticket can have multiple relationships with multiple tickets.
- Depends on / Depended on By
- A ticket can depend on another ticket. The normal usage is when a given project (ticket) cannot be completed until another project (ticket) has been completed.
- Parent / Child, Children
- A given project (ticket) can be a sub-project of another, larger project (ticket). This also has some of the implications of Depends on/Depended on by, but the focus is on a vertical, rather than horizontal dependency.
- Refers to / Referred to by
- This is primarily for documentation purposes. A given ticket can contain the interesting/useful information that doesn't need to be repeated in another ticket.
Backup and Restoration
The RT system is primarily database driven. To backup your working RT installation, it is suggested that you first understand the pitfalls behind backup and restoration of a relational database. The MySQL chaps have written an excellent guide, with specifics. This states in parts:
The key to safe database management is taking regular backups. To take a 'binary' backup of your database you have to do the following:
* Shut down your MySQL database and make sure it shuts down without errors.
* Copy all your data files into a safe place.
* Copy all your log files to a safe place.
* Copy your `my.cnf' configuration file(s) to a safe place.
* Copy all the `.frm' files for your InnoDB tables into a safe place.
A script to perform a backup of RT exists for RT 1.0.x in the
contrib directory right here, but you do want to read the README first.
TODO - Verify suggestions from rt-users for RT 2.0.x, also clarify restoration procedures - bc.
Administrative Procedures
Creating a user
with the CLI
with the web interface
Creating a queue
Granting users rights to access a queue
- To allow any user to create a ticket in any queue, grant the right 'CreateTicket' to the Pseudogroup 'Everyone' globally.
- To allow any user to create a ticket in the queue 'general', grant the right 'CreateTicket' to the pseudogroup 'Everyone' for the queue 'general'
- To allow anyone to send in an email update to a ticket in the queue 'general', grant the rights 'ReplyToTicket' and 'CommentOnTicket' to the pseudogroup 'Everyone for the queue 'general'
Using scrips to notify users of changes to tickets in a queue
Keywords
RT2 has a very useful new feature, called keywords, for tracking characteristics of tickets. Keywords allow you to assign any sort of tracking metrics you want to tickets in your queues. For instance, you could track job applications by geographic region in order to determine where you should locate new offices; or you could add a "severity" level to tickets in order to help you prioritize your work. Once keywords are added, they become part of the ticket display, and you can use them as restrictions in a ticket search.
Another important use for keywords is reporting. A common requirement is a regular report that includes a brief summary of the tickets that have been closed recently. Keywords can save a lot of time in doing this without requiring the workers to write detailed explanations. Just assign a keyword category such as "Reason for Closure" and the report can be mostly constructed from a normal RT search screen.
Keywords are very easy to add to your RT installation -- they can be added completely through the Web interface. There are two basic steps to adding keywords to RT:
- Create a set of keywords that you want to track; and
- Add your keywords to all queues, or to one or more individual queues.
This tutorial will teach you how to add a "Progress" keyword selection to a job application tracking queue. This keyword will allow you to track how far along each candidate is in the review process. Using this example you can add any keywords appropriate for your uses to your site's RT configuration.
Creating a Set of Keywords
The first step in using keyword selections is to
set up a set of keywords that will be useful to you. A "keyword" is
either any individual ticket characteristic (such as an urgency level
like "Critical"), or a category of individual keywords (such as
"Urgency"). In planning your keywords, take a look at the example
job-applicant keyword selection to the right, and use it as a model.
This example shows one keyword selection, with a category named
"Progress," and six individual keywords in that category (of which
five are shown in the graphic) named "1. Requested interview,"
"2. Interviewed once," and so on.
Internally, RT does not make a distinction between categories and individual keywords -- all keywords are stored in one "tree" structure (just like a filesystem with a root directory and subdirectories). Any keyword can contain other keywords. This fact can be helpful in organizing keywords for easy administration.
In our example, we want to create a keyword selection to track candidate review progress for a queue named 'jobs'. Since this keyword selection applies only to the jobs queue, and no other queue on our system, we'll create a top-level keyword called Jobs. This is not required -- you could put the Progress keyword at the top level -- but doing this will allow us to keep ourselves organized by grouping any keywords specific to the 'jobs' queue together. Inside Jobs, we'll create a subcategory called Progress, which is our category keyword. Then, inside Progress, we will create one keyword for each of the selections we want to appear in the form. Our plan, then, is to create the following keyword structure:
- Jobs
- Progress
- 1: Requested interview
- 2: Interviewed once
- 3: Interviewed more than once
- 4: Offer made
- 5: Hired
- 6: Offer rejected
- Progress
One thing to note is that when RT displays keyword selections on a ticket, it sorts them alphabetically. If you would like to have your selections appear in a specified, non-alphabetic order, it is helpful to add a sequential number or letter to the front of each individual keyword. In our example, our interviewing process has several steps that need to follow each other, so we've added "1:", "2:", etc. to the beginning of each step.
Now that we've planned out our keywords, we can add them to RT. While logged into our RT system as a SuperUser (for instance, using the "Administrator" account), first select [Configuration], and then within configuration, select [Keywords]. The keywords administration page shows a list of existing top-level keywords (probably empty at this point), and then a field for adding a new keyword. Following our plan above, type "Jobs" into the entry field and hit the "Add" button. The result should look like this:
Once this is done, we then want to create keywords within the Jobs keyword. To do this, first click on the word "Jobs" (not the "edit" next to "Jobs" -- edit only changes the name of the "Jobs" keyword -- but instead the word "Jobs" itself), and then use the text field to add the "Progress" keyword. Then click on "Progress" and add each of the individual keywords planned out above. When all of the keywords have been added, the result appears as follows:
(In the image above, the numbers "16", "17" and so on may be different on your system -- don't worry about that. These numbers are RT's internal id's for each keyword, and they do not affect your configuration.)
We have now added all the keywords we need to the system. As of right now, these keywords do not appear in any of our tickets, because they have not been added to the queue configuration. What we have done so far is make RT aware of the keywords -- now we need to associate our keywords with our "jobs" queue.
Adding a keyword selection to a queue
Once we have entered keywords into RT, we then need to specify Keyword Selections, which are sets of keywords available for selection on a ticket. To do this, we need to choose a selection model (single or multiple), a selection depth, and which queue or queues will use the keyword selection. Each choice is described below.
A keyword selection is represented in the RT
interface as one form selection field -- a list of items that a user
may select. Our example keyword selection is pictured at right.
There are two varities of keyword selection: Single selection
and Multiple selection. In single selection, a user may select
any one keyword in the list, but not more than one. In our example,
we use a single selection since each step in the interview process is
distinct. In a multiple selection, a user may choose one or more
keywords in the selection list (usually by holding down the "Control"
key while selecting each keyword). For instance, if you had a keyword
category called "Ways to contact" containing the individual keywords
"Email," "Phone," "Fax," and "Pager," you might want to allow multiple
selection to include several contact methods.
A keyword selection's depth represents how many levels down in the keyword tree the selection should include. A keyword selection starts at what we've been calling the category keyword -- in our example, "Progress." This keyword can contain other keywords, which themselves might contain keywords. As an example, let's say you wanted to change our keyword tree to look like this:
- Jobs
- Progress
- 1: Requested interview
- 2: Interviewed once
- 3: Interviewed more than once
- 3a: Manager interviewed
- 3b: Peer interviewed
- 3c: CEO interviewed
- 4: Offer made
- 5: Hired
- 6: Offer rejected
- Progress
In this case, if we used "Progress" as our category keyword, and set a depth of "1," the 3a, 3b, and 3c steps would not be included in the selection field -- they are two levels deep, so they would not meet the depth requirement. If instead we used a depth of "2" or more, steps 3a, 3b, and 3c would be included in the selection field. Another way to include these steps would be to use a depth "0," which includes all keywords under "Progress," no matter how deep they are.
Next, we can use the keyword selection in two ways: either we can add a keyword selection to a single queue, or we can add a keyword selection to all queues at once. For our example, our keyword selection is specific to the 'jobs' queue, so we will add it to that queue's configuration only. To do this, we first choose [Configuration], then [Queues], and then select the 'jobs' queue. If we had a general keyword selection we wanted to apply to all of our queues (for instance, "Requestor satisfaction: Happy, Okay, Unhappy, Unknown") we would instead choose [Configuration] and then [Global].
Once we have selected the queue to modify (or chosen "Global"), the next step is to click [Keyword Selections]. Doing this will bring up a form with which we can add a keyword selection to a queue. The form uses four fields to configure the keyword selection. The first field is the label that will be put above the selection form field. In our example above, we used the label "Progress." (Note that the label does not need to be a keyword itself -- the label can be any text you want to use.) Next, choose between Single and Multiple selection models, as described above. We are using "Single" selection in our example. Next, choose your category keyword from the pop-up list of keywords. This is the keyword that contains the selections you want to appear in the form. For our example, we choose "Jobs/Progress". Finally, choose the selection depth for the keyword selection. We enter '0', which is interpreted as "unlimited depth beneath the category keyword." Once these selections are made, hit the submit button, and the following form should appear:
Your keywords are now enabled. Go to the 'jobs' queue and open a ticket, then click on "Keyword Selections." You should see the "Progress" keyword selection, and it should contain the six progress steps entered above, plus the keyword "(empty)," which indicates that no keyword selection has been made for this ticket.
Once you have entered some keyword selections, go to the search form and search for the queue 'jobs'. At the bottom of your results page, you will see that the 'Progress' keyword is now included as a search restriction, so you can use the progress step as a term in searches. (If you associate a keyword with a queue, the keyword search form will only appear on searches within that queue. Global keyword selections will appear on all search forms.)
Hopefully this tutorial will help you get the most out of keywords in RT. Keywords can be an enormous help in adding order and searchability to a large set of tickets. If you come up with creative uses for keywords, send them in to <rt-users@lists.fsck.com> and let us know what they are!
Sample Keyword Tree for IT Support
Since many people use RT for IT support desks the following example is included to illustrate how keywords can be applied, adapted from one in use by Rich Lafferty of Ottawa, Canada.
Support staff are trained to always set the keywords on a ticket, even if they don't have time to write a lot in the notes. This way basic sorting and reporting can always be done, giving an idea how time has been spent and what kinds of requests are arising.
There are two main queues, sysadmin and support, with different keywords available to a ticket in each. Here are some highlights of this tree design:
- The keyword 'Closure reason' saves large amounts of time when compiling reports on RT activity. For summary purposes there is no longer any need to plough through the ticket notes. For example, doing a search on the Closure Reason keyword for 'Done - tranferred responsibility' gives an indication of how often problems are being fielded that actually belong to some other area.
- The idea of reactive tickets(those that arose through the user getting a surprise, eg a hardware failure) and planned tickets (where the user is making contact because he wants somwething to change, eg buying a new computer.)
- Knowledgebase. Articles that have this set to "required" will show up in a regular search, and something can then be written for the Knowledgebase from the ticket notes. This keyword can then be set to "article written", so it doesn't turn up again.
(root)
global
queue
sysadmin
closure reason
Done
Transferred responsibility elsewhere
Won't do - not reasonably fixable
Won't do - not our fault
Won't do - can't reproduce
ticket classification
reactive
System fault
User problem
planned
New feature request
Purchase - software
Purchase - hardware
Inhouse app1 - user issue
Inhouse app1 - hardware
Inhouse app1 - software
other
support
ticket classification
bug
handholding / user understanding
documentation problem
new feature request
customization
billing inquiry
flat-rate account
closure reason
Done
No support
Inappropriate
Bug raised
Timeout
Software-version
5.5, 6000R2
5.1.2
5.1.1, 6000R1
5.0
4.1.2
4.1 or prior
taxonomy
Server
Hardware
Hardware
Internet connection
DNS
Installation - initial configuration
Local networking
Users - Groups - Directories
Fileserver - I-Bays
Mail
Webserver
Proxy
Printing
Backup
Remote Access
Security
Customization
Housekeeping
ServiceLink
Partner Zone
Sync
Guaranteed Email
DNS Hosting
Virus Protection
VPN
Blades
Updates
Mp3 Jukebox
knowledge base
Article Written
Needs Article
Performance Tuning
RT can be quite sensitive to bottlenecks and poor optimisation choices, particularly if the number queues is high (for example, greater than 50) or the total number of tickets is large (for example, greater than 100k). Exactly what is 'large' for you depends on many factors. (Someone reported to the rt-users mailing list that they had an installation of WebRT on a Pentium 100 running FreeBSD, so this site would have a very small value for 'large' :-)
A very simple thing to check is the version of RT you are running. If you are well out of date in the current stable series then you should consider upgrading. Upgrading is usually not too painful a job and there are regular improvements in RT's performance gained through better coding.
Database Optimisation
Database tuning is very important. If all your RT tables are indexed correctly, and if transactions are working properly, and whatever regular maintenance your database requires is being carried out then there is a much better chance that RT will run smoothly.
Postgresql
- Version. You should have checked this long ago, but RT is not expected to work with versions of Postgresql less than 7.1.1, or 7.3.0 or higher. It will, after a fashion, but don't be surprised if it doesn't run well.
- Optimisation via queries. This is done using VACUUM, ANALYZE and CLUSTER. VACUUM and CLUSTER change the organisation of rows on the physical media, getting rid of information the database no longer needs.
- Postgresql buffer optimisation. Make sure you have sufficient buffers allocated to your server to contain all of the more static tables (keywords, scripactions, etc.) and some reasonable number of rows from the dynamic tables (tickets, attachments, transactions, etc.). Some moderately intense users find that one week's worth of dynamic table rows does a good job.
- Logging. Turn it down! If you have verbose logging turned up (as you may for testing) you can cause up to four separate writes per interface click.
- Hardware optimisation. Most of this concerns general principles that are common to all RDBMS, however there is a very thorough hardware optimisation document for Postgres by Bruce Momjam at http://www.postgresql.org/docs/momjian/hw_performance.pdf
MySQL
Operating System and Environment
The faster your Unix, the faster RT may run (see the other parts of the Performance Tuning section for other factors that contribute to RT speed.) So make sure that your Unix is running well. Use vmstat and iostat (or the equivalents for your OS) to keep an eye on system performance. You'll find a tool such as Netsaint at http://netsaint.org invaluable for keeping ongoing records of key system performance indicators at regular intervals. It even has pretty graphs.
RT needs a responsive Apache/Perl webserver installation. This requires matching to your hardware requirements. If you have a small server, look at tuning Apache with the start servers and spare servers command. If you have large amounts of memory and you're getting lots of simultaneous incoming requests, increase the number of waiting servers.
Watch your logging. Apache and mod_perl can both do a lot of logging if you turn it on, enough to significantly affect performance. If many of your connections are from the Internet you may wish to turn off reverse DNS mapping in Apache.
If you think you are running tight on resources, have a look at what other services are running. Maybe you don't need them. If this is a critical server and it is heavily loaded, perhaps you need to split the web/perl server out from the database server, because they have different optimisati