Unofficial Installation Guide
This is an unofficial installation guide. It may be outdated or apply only to very specific configurations and versions. The official and maintained installation steps for RT are in the README and UPGRADING documents included in the official
|This page 'FedoraCore5InstallGuide' is tagged as OUTDATED|
|This page contains out of date and possibly misleading information or instructions such as installation methods or configuration examples that no longer apply. Please consider this warning when reading the page below.|
|If you have checked or updated this page and found the content to be suitable, please remove this notice by editing the page and remove the Outdated template tag.|
This is a guide on how to install the current "yum" version of RT 3.x on a Fedora Core 5 server using Sendmail as a mail server. Note: Specifics may differ from system to system. As of 14 December 2006, the current version of RT installed via "yum install rt3" is RT 3.4.5. (At 29 June 2007, RT3.6.3)
This installation procedure was tested on a system with the following software already installed:
- Fedora Core 5
- Apache2 2.2.0
- Mysql 5.0.18
- Perl 5.8.8
1. OS Installation
Install Fedora Core 5 and select to install mysql and apache. Make sure httpd and mysql services are running:
service mysqld start service httpd start
You may need to create files in /etc/init.d for this to work.
To make sure everything is up up-to-date, it may be prudent to do an update of all binaries using yum:
Note: This will completely update everything that yum has to offer so if you have an operational system be careful that you don't upgrade services or applications that will destroy--or at least mess up--your exiting applications. You may want to update only the applications and services necessary, mysql, postgres, perl, etc.
Note: To start the httpd and mysqld service automatically at startup (after reboot):
chkconfig httpd on chkconfig mysqld on
2. RT Installation
With the OS correctly installed and apache & mysql running, we can now proceed with the RT stuff.
A version of RT3 can be easily installed using Fedora's "yum" installation utility:
yum install rt3
The above command will prompt you for the installation of RT3, as well as any other required packages for RT3 which are not yet installed on your machine. After installation completes, all the necessary components for RT3 should now be present on your machine.
2.1 Installation Locations
- /etc/rt3 - RT3 configuration files
- /etc/httpd/conf.d/rt3.conf - RT3 configuration file for apache
- /usr/sbin/rt3-* - RT3 "helper" applications
- /usr/share/doc/rt3 - documentation
- /var/www/rt3 - installed files for RT3 to be accessed via the web interface
2.2. Fedora-specific configuration of RT3
See the file /usr/share/doc/rt3-3.4.5/README.fedora for details of configuration of RT3 for FC5. Follow the instructions as indicated.
2.3. Restart httpd now that RT3 has been installed
/sbin/service httpd restart
Once this works, you may move on to setting up your email gateway.
2.4. Helpful utilitilies
3. Setting up RT to talk to your mail gateway
1) Documentation for setting up the mail gateway can be found by typing:
2) You need to tell your Mail Transfer Agent (ex. sendmail, postfix, or qmail) how to forward messages to RT's mail gateway. To do this, create an aliases in your system's mail aliases file. Here's an example, which routes mail to the mailbox [=firstname.lastname@example.org] (and [=email@example.com]) into new tickets in the RT queue named General. Note that the queue name is case-insensitive.
Add the following lines to /etc/aliases (or your local equivalent such as /etc/mail/aliases):
rt: "|/usr/sbin/rt-mailgate --queue 'general' --action correspond --url http://localhost/" rt-comment: "|/usr/sbin/rt-mailgate --queue 'general' --action comment --url http://localhost/"
NOTES: When you add each line above they should be all one line; make sure you include the quotes. Replace general with the name of your queue and rt with the email address you wish people to send their messages to. You might, for example, have messages to support go into the service queue, and abuse go into the ops queue. You can have more than one set of aliases point to the same queue, if, for example, you wanted mail to both abuse and security both go to the ops queue.
The queue name may have spaces.
rt-mailgate works as well with them, do not forget to escape these spaces by enclosing the queue name in single quote:
my-queue: "|/usr/sbin/rt-mailgate --queue 'My Queue' --action correspond --url http://localhost/"
If you are using the default sendmail you may need need to cp rt-mailgate to /etc/smrsh or create a symbolic link and change /usr/sbin above to /etc/smrsh or sendmail will complain. These sendmail's will only execute programs as alias targets which have been blessed by placing them in a special directory.
You'll choose from "--action correspond" and "--action comment" depending on whether the mail should be resent to the requestor. If you want the requestor to see it, choose correspond; if you want to keep it from the requestor, choose comment. The URL will be the URL for RT's web interface; whatever is the root of your RT install.
(If you're using sendmail, you may find your installation defaults to not accepting external mail. If this is the case, to accept mail from other sources you need to remove the loopback restriction directive from the sendmail configuation. To do this, modify the following in sendmail.mc:
and remove the localhost restriction:
The update the sendmail.cf file with make:
make -C /etc/mail
3) Stop and start your mail server, so it picks up your configuration changes. (Postfix just requires you execute `newaliases`, probably via sudo.)
4) Change the password. The default root password for the web interface is password, as installed. Changing this should be the first thing you do after installation.
Until you configure RT, RT will not be able to send or receive email, nor will it be more than marginally functional. This is not an optional step. RT has many configuration options, and you should read Chapter 4: Adminning RT for a broader view, but here's a quick guide to things you should probably look at.
4. Creating users
In its default configuration, RT uses an internal users database to keep track of who can access RT and who has which rights within the system. One of your first tasks should be to create users for anyone who will need to work with tickets within RT.
click Configuration -> click Users -> click New user
For more details, see 'Users: Creating a user' in ManualAdministration.
5. Granting User Rights
RT provides a rich access control system that allows rights to be granted to groups, individual users and users in specific roles.
To allow arbitrary remote users to submit tickets into a given queue by email, grant the system group Everyone the rights See Queue, Create Ticket, Reply To Ticket, and Comment On Ticket for that queue.
If you intend to let ticket requestors use the requestor-mode web interface, you should grant the role of Requestor the right Show Ticket.
To make sure your staff can work with tickets, you should grant them all the following additional rights:
For more details, see Users: Granting user rights in ManualAdministration.
6. Creating queues
By default, RT has one queue called 'general'. You might want to change the values for this.
click Configuration -> click Queues -> click general
To create a new queue:
click Configuration -> click Queues -> click New queue
For more details, see Queues in ManualAdministration.
7. Setting up scrips
The default global Scrips installed with RT 3 are:
- On Create, Autoreply to Requestors with Global Template: Autoreply
- On Create, Notify AdminCcs with Global Template: Transaction
- On Correspond, Notify AdminCcs with Global Template: Admin Correspondence
- On Correspond, Notify Requestors and Ccs with Global Template: Correspondence
- On Correspond, Notify Other Recipients with Global Template: Correspondence
- On Comment, Notify AdminCcs as Comment with Global Template: Admin Comment
- On Comment, Notify Other Recipients as Comment with Global Template: Correspondence
- On Resolve, Notify Requestors with Global Template: Resolved
- On Correspond, Open Ticket with Global Template: Blank (this scrip replaces old built-in behavior that would automatically open tickets if privileged users replied to a new ticket or if anyone replied to a stalled or closed ticket.)