RT server configuration
RT has the following perl dependencies, along with the corresponding Ubuntu packages they reside in:
Digest::MD5 perl Storable perl DBI 1.18 libdbi-perl DBIx::DataSource 0.02 libdbix-datasource-perl DBIx::SearchBuilder 0.48 libdbix-searchbuilder-perl HTML::Entities libhtml-parser-perl MLDBM libmldbm-perl Net::Domain perl-modules Net::SMTP perl-modules Params::Validate 0.02 libparams-validate-perl HTML::Mason 1.02 libhtml-mason-perl CGI::Cookie 1.20 perl-modules Apache::Cookie libapache2-request-perl Apache::Session 1.53 libapache-session-perl Date::Parse libtimedate-perl Date::Format libtimedate-perl MIME::Entity 5.108 libmime-tools-perl Mail::Mailer 1.20 libmailtools-perl Getopt::Long 2.24 perl-base Tie::IxHash libtie-ixhash-perl Text::Wrapper libtext-wrapper-perl Text::Template libtext-template-perl File::Spec 0.8 perl-base Errno perl-base FreezeThaw libfreezethaw-perl File::Temp perl-modules Log::Dispatch 1.6 liblog-dispatch-perl
The data in RT is stored in a PostgreSQL database. The postgresql Ubuntu package will install the recommended version of PostgreSQL for the current Ubuntu version.
The mail interface to RT is handled by Postfix, so the postfix package is required. The libsendmail-pmilter-perl package is required for the custom milter script.
The web front end to RT is an Apache2 web server, so the apache2 package is required. RT uses a FastCGI server which must run as the rt user, so the libapache2-mod-fastcgi and apache2-suexec-pristine packages are required.
In sum, the following packages must be installed on the RT server:
apache2 apache2-suexec-pristine libapache-session-perl libapache2-mod-fastcgi libapache2-request-perl libdbi-perl libdbix-datasource-perl libdbix-searchbuilder-perl libfreezethaw-perl libhtml-mason-perl libhtml-parser-perl liblog-dispatch-perl libmailtools-perl libmime-tools-perl libmldbm-perl libparams-validate-perl libsendmail-pmilter-perl libtext-template-perl libtext-wrapper-perl libtie-ixhash-perl libtimedate-perl perl perl-base perl-modules postfix postgresql
The postgresql package will create a postgres user account.
The following user accounts and group entries must be created manually:
- group rt
- user rt: primary group rt, homedir /var/rt2, shell /bin/false
- user rtcvs: primary group rt, homedir /var/rt2, shell /bin/sh
These accounts could be created with:
groupadd -r rt useradd -r -m -g rt -d /var/rt2 -s /bin/false rt useradd -r -g rt -d /var/rt2 rtcvs
Some of the above accounts may be created by ops during provisioning.
/var/rt2 should contain an empty .k5login file, managed by ops. It should contain a .ssh/authorized_keys file, managed by ops, containing the krbsnap key from /git/krb5.git/hooks/krbsnap_rsa_key.pub on drugstore.mit.edu.
Our installation of Request Tracker is a modified version 2.0.13. Most of the modifications were tracked in CVS; the repository is on drugstore at /cvs/krbdev in the tracking subdirectory. drugstore no longer serves CVS, so the repository must be copied out and checked out locally. A few changes have been made on the running server without version control. Absent a proper version control setup for the running version of RT, it is necessary to transfer the contents of /var/rt2 from the old server to the new.
Several scripts do come from the krbdev-services repository, in the rt-cvs and rt-scripts directories. All are installed in /var/rt2/bin.
In root's crontab file ("crontab -e" as root), add the following to perform daily maintenance:
0 3 * * * /var/rt2/bin/krb5-daily.sh
Many PostgreSQL files live in directories specific to the PostgreSQL major and minor version, such as /etc/postgresql/8.3 for PostgreSQL 8.3.
The Ubuntu postgresql package will create a "main" cluster with a configuration directory in /etc/postgresql/<version>/main.
In /etc/postgresql/<version>/main/pg_ident.conf, add:
local root root local root postgres local root rt_user local rt rt_user local rtcvs rt_user local postfix rt_user local nobody rt_user
In /etc/postgresql/<version>/main/pg_hba.conf, find the line that reads "local all all peer" and add "map=local" to the end, so it reads "local all all peer map=local". Comment out the line that reads "local all postgres peer", despite the warning not to disable it. Run "service postgresql restart" to reread the affected files. Run "psql -Upostgres --list" to verify that the identity map works.
Run "createuser -Upostgres rt_user" to create the rt_user role.
Run "createdb -ESQL_ASCII -Upostgres -Ttemplate0 rt2" to create the database. This database can be removed with "dropdb -Upostgres rt2" if it becomes necessary to recreate it.
Run "pg_dump -Upostgres -Fc rt2 > /path/to/dumpfile" on the old server, transfer the file to the new server, and run "pg_restore -Upostgres -d rt2 /path/to/dumpfile" on the new server to restore the database. As a simple verification, run "psql -Upostgres -c 'SELECT * FROM keywords;' rt2" on both servers and verify that the tables have the same number of rows.
- Set myhostname = krbdev.mit.edu
- Set mydestination = krbdev.mit.edu, krbdev-prod-app-1.mit.edu, localhost.mit.edu, localhost
- Add the following to the end:
# Suppress some headers to avoid leaking internal addresses to spammers. prepend_delivered_header = enable_original_recipient = no # RT header milter smtpd_milters = unix:private/milter
Copy /etc/aliases from the old server. To avoid aiding spammers, its contents are not reproduced here. In particular, /etc/aliases contains an internal address corresponding to the membership of the krb5-bugs-incoming mailman list; revealing this address could allow spammers to bypass moderation of incoming bug reports.
In root's crontab file ("crontab -e" as root):
@reboot /var/rt2/bin/rtmilter.pl /var/spool/postfix/private/milter
Run the command by hand (backgrounded) to start the milter process before the next reboot.
Run "postfix reload" to pick up the changed configuration.
Apache httpd configuration
Create /etc/apache2/ssl.crt and /etc/apache2/ssl.key.
Copy /etc/apache2/ssl.key/server.key and /etc/apache2/ssl.crt/server.crt from the old server, or follow the instructions at http://kb.mit.edu/confluence/display/istcontrib/Obtaining+an+SSL+certificate+for+a+web+server to obtain a new one. server.key and server.crt may be symlinks using whatever scheme seems convenient for renewing certificates every few years.
Install /etc/apache2/ssl.crt/chain.crt from /mit/apache-ssl/certificates/InCommon-chain.crt.txt (requires tokens). Cutting and pasting is effective for transferring certificates as they are represented as short text files.
Install /etc/apache2/ssl.crt/clientCA.crt from /mit/apache-ssl/certificates/mitCAclient.pem (requires tokens).
Install the RT site file as /etc/apache2/sites-available/rt.conf . (Copy from the old server; this could probably be put into the krbdev-services repository.)
Edit /etc/apache2/mods-enabled/fastcgi.conf and uncomment the FastCgiWrapper line.
Edit /etc/apache2/mods-available/proxy.conf and set:
ProxyVia On ProxyPass /buildbot/ http://krbdev-buildbot.mit.edu:8010/ <Proxy http://krbdev-buildbot.mit.edu:8010/*> Allow from all </Proxy>
Clean out /var/www and install index.html and robots.txt from the krbdev-www directory of the krbdev-services repository. (TBD: index.html needs to be updated not to expect buildbot on the same server.)
a2enmod ssl a2enmod userdir a2enmod rewrite a2enmod proxy_http a2dissite 000-default a2ensite rt service apache2 restart