Helgrim.com

If you can read this, you've wasted your time. 
[Index of articles]

Content

1 Requirements
2 Unpack.
3 Configure the Makefile.
4 Check dependencies
5 Install
6 Final configuration
7 Configuration
8 Users and Queues and Scrips, Oh my!
9 Appendix

1 Requirements

You should have downloaded the latest release of RT. [
www.fsck.com/projects/rt/download.html]


[Table of Contents]  [Top of section]  

2 Unpack.

Unpack the distribution somewhere other than where you want to install RT. To do this cleanly:

% tar zxvf rt.tar.gz -C /tmp



[Table of Contents]  [Top of section]  

3 Configure the Makefile.

Check through /tmp/rt/Makefile

There are many variables you NEED to customize for your site. Even if you are just upgrading, you must set ALL variables.

Here are the some of the more likely candidates to need changing:

RT_PATH - Where you want the installation to live.
/opt/rt2 is default, /usr/local/rt2 may be more to your taste.

RT_MAN_PATH - Where to install the man pages for RT.
You may wish to change to to /usr/share/man or /usr/local/man

RT_LOG_PATH - Where to write log files.
RT writes numerous log files based on pid's, so you may want to make a directory just for rt such as /var/log/rt2

DB_TYPE - Which database backend to use.
Choices are:

  • Pg for PostgreSQL;
  • mysql for Mysql;
  • Oracle for, well, Oracle.

    DB_HOME - Where to find the executables and libraries for your database
    $DB_HOME/bin should contain the binaries themselves - e.g. if

    $ which mysql
    gives "/usr/local/mysql/bin/mysql", $DB_HOME should be "/usr/local/mysql"

    DB_DBA - A user who has permission to create new databases and database users.
    This might be "root" for Mysql, "postgres" or "pgsql" for PostgreSQL, or "system" for Oracle. This is used during installation only.

    DB_RT_USER - A user who will actually use the database
    If the username does not already exist, it will be created.

    WEB_USER and WEB_GROUP - The user that your webserver runs as. This should be something like www, or www-user, or nobody. It should *not* be root. Check your apache configuration file for the User directive.


    [Table of Contents]  [Top of section]  


    4 Check dependencies

    Satisfy RT's myriad dependencies:
    The Makefile has two targets, testdeps and fixdeps, which automate this. Make sure you have configured the Makefile as described above.
    
    % cd /tmp/rt
    
    % make testdeps
    
    
    This will check that all the perl modules which RT depends on are installed.
    If there are unsatisfied dependencies, install them by hand or run
    
    % make fixdeps
    
    

    You may need to install some modules by hand, especially Apache::Session, Apache::DBI and Msql-Mysql-Modules Either use CPAN:
    
    % perl -MCPAN -e 'install DBD::mysql::Install'
    
    

    Alternatively, you should be able to find all the neccessary modules at
    http://www.helgrim.com/perlmodules/

    Now make sure everything is installed:

    
    make testdeps
    
    
    Repeat until happy.

      4.1 Building Apache with mod_perl

      The mod_perl guide can be found at: [http://perl.apache.org/guide]

      The following is an excerpt, which should work for most people. Download the source tarballs for apache and for mod_perl, and then:

      % tar xzvf apache_x.x.x.tar.gz
      % tar xzvf mod_perl-x.xx.tar.gz                                                 
      % cd mod_perl-x.xx                                                              
      % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src USE_APACI=1  DO_HTTPD=1 EVERYTHING=1
      % make && make test && make install                                            
      % cd ../apache_x.x.x                                                           
      % make install   
      
      This builds Apache statically with mod_perl, installs Apache under the default /usr/local/apache tree and mod_perl into the site_perl hierarchy of your existing Perl installation.




    [Table of Contents]  [Top of section]  

    5 Install

    If this is a new installation, follow the steps below. If you are upgrading from an earlier version, skip this section.

    1. Create a group called 'rt'

    2. As root, type:

    # make install
    
    This will install RT, and configure your database. If it fails, you must clear the database before trying again. Do this by typing:
    # make dropdb
    




    [Table of Contents]  [Top of section]  

    6 Final configuration

        Edit etc/config.pm in your RT installation directory.  In many
        cases sensible defaults have been included. In others, you MUST
        supply a value.
    
        Configure the email and web gateways, as described below.
         
        Stop and start your webserver, so it picks up your configuration changes.
        N.B. Remember to do this any time you make changes to config.pm
    
        Using rtadmin, or the web interface add a RT user for yourself. 
        This must be done as root, as no other user has permission to do anything inside RT yet.
        Right now, root's password is 'password'. You should change that now.
    
            Commandline instructions:
    
                [root@host bin]# ./rtadmin --user  --create --password=""
    
            Web instructions:
                Log into the web ui as root
                Click on "Administration"   
                Click on "Users"
                Click on "Create a new user"
    
        NOTE: root's password for the web interface is "password" 
        (without the quotes.)  Not changing this is a SECURITY risk
        
    



    [Table of Contents]  [Top of section]  

    7 Configuration




    [Table of Contents]  [Top of section]  

    8 Users and Queues and Scrips, Oh my!

    Run through the installation
    
    Create your users
    
       In its default configuration, RT uses an internal users database to keep
       track of who can access RT and who has what 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.
    
       With the web interface, click on "Config" then "Users" then "Add new
       user". When creating new users, be sure to fill in:
    
            Name
            Email Address
            Password
    	Be sure to click on "Let this user to be granted rights"
    
    Create your queues
      RT's primary administrative unit is the 'queue.' Use queues to separate
       tickets either by the groups of people who should be dealing with them,
       the user community or ticket attributes, or some combination therein.
       Generally, you don't want to create queues for time-limited projects. In
       most situations, queues are not things you should be creating or
       deleting with any frequency.
    
    Grant the users the rights they need.
    
       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 "Everyone" the rights to "SeeQueue", "CreateTicket",
       "ReplyToTicket" and "CommentOnTicket" for that queue.  
    
       If you intend to let ticket requestors use the requestor-mode web
       interface, you should grant "Requestor" the right to "ShowTicket"
    
       To make sure that your staff can work with tickets, you should grant
       them all the following additional rights:
         "ShowTicket" 
          "ShowTicketComments" 
          "Watch" 
          "WatchAsAdminCc" 
          "OwnTicket" 
          "ModifyTicket"
    
    Set up Scrips
    
       RT's "Scrips" system lets sites configure what email gets sent by RT in
       response to ticket creation or updates.  Unless you set up Scrips, RT
       _will not_ send any email. (It's also a general extension mechanism
       which allows changes to persist across updates. But if you're reading
       this quickstart guide, you probably just don't want to go there yet.)
    
       Scrips are composed of a Condition, an Action and a Template.  A number
       of Conditions and Actions come with RT. Others are available as
       contributed add-ins from members of the RT community.  Later on, you can
       define custom templates for each queue, but for now, RT ships with a set
       of predefined templates which should get you started.
    
       A reasonable default set of scrips for a queue is something like this:
    
          OnCreate AutoReplyToRequestors with Global Template: AutoReply
          OnCreate NotifyAdminCcs with Global Template: Transaction
          OnCorrespond NotifyAllWatchers with Global Template: Correspondence
          OnComment NotifyAdminCcsAsComment with Global Template: AdminComment
          OnResolve NotifyRequestors with Global Template: Resolved
    
    Set up queue watchers
    
       RT lets you set up Cc and Administrative Cc watchers globally and for
       each queue. (Note that mail isn't sent unless you define Scrips to send
       it).  Generally, Cc watchers are folks who get notifications of ticket
       updates and can view the queue (though this, of course, depends on how
       you configure things). Administrative Ccs are usually the folks who have
       rights to modify tickets.  Set up folks you want to get Cc or AdminCc
       mail as watchers for your queue in "Configuration"/"Queues"/ 
       / Watchers.
     
    Set up keywords
    
       RT's keyword system is centered around a single global hierarchy of
       keywords and the concept of "Keyword Selections".  Keyword Selections
      allow you to set up custom fields either for your whole RT installation
       or for a single queue. Keyword Selections let you pick a node in the
       Keywords tree as its "root" and to decide whether users can pick either
       a single value or multiple values from that list.  
    
       For now, you probably don't need any keyword selections, but once you
       want to start 'tagging' requests with keywords, come back and add a
       keyword called "Queues" to the Keywords hierarchy
       ("Configuration"/"Keywords").
    
       Once you've created that keyword, click on it and add a new keyword
       named after your queue.  Click on that.  Add a keyword as the root of
       your new Keyword Select. Let's call it "operating system."  Under
       Operating system, add a bunch of operating systems.
    
       Now, click on "Configuration" / "Queues" / your queue name /  "Keyword
       Selections" Enter a name for your keyword selection, like "Client OS".
       Allow "multiple" values of "Queues//Operating System Up to 0
       (unlimited) levels deep.
    
       Now you'll be able to set 'Client OS' for tickets in your queue.
    
    
    



    [Table of Contents]  [Top of section]  

    9 Appendix




    [Table of Contents]  [Top of section]  
  • © Feargal Reilly 2003-2009 | feargal@helgrim.com | Hosting by FBI | Valid HTML 4.01 | Valid CSS