[rt-users] RFC: RT install w/o setgid Perl or mod_perl

[Mark D. Roth]

I've only recently discovered RT and joined the list, so I apologize
in advance if any of this is an FAQ.  I didn't see anything similar in
the list archives, and I thought people might be interested in how I
have RT (2.0.13) set up.  I'd also like to hear any suggestions that
anyone may have on how to improve my configuration.


Background Information
----------------------

My group's primary function is to run systems that host central
services such as mail, LDAP, news, web servers, etc.  We don't run the
applications that run on our systems; we just provide the underlying
platform on which our customers install and manage their
applications.

As a result of this division of responsibilities, we've developed a
lot of infrastructure to allow our customers to control as much of
their software and data as possible, even though they don't have root
access.  In particular, we create a unique pseudo-user for each
application, and we try to install everything related to the
application in the pseudo-user's home directory.  The customer then
su's to the pseudo-user to manage the service.

For example, for our LDAP service, we created a pseudo-user named
"ldap" with home directory "/services/ldap".  All of the LDAP server
software, directory data, and support scripts are owned by this user
and installed in its home directory.

For web-based services, we've established this convention for
URL-to-directory mappings:

   DIRECTORY			    URL
   ----------------------------------------------------------------
   ~pseudouser/public_html/http     http://hostname/pseudouser/
   ~pseudouser/public_html/https    https://hostname/pseudouser/

Rather than just using an Apache "Alias" directive to establish this
mapping, we use mod_rewrite to rewrite the requested URL internally
using ~pseudouser notation.  This allows us to use Apache's suEXEC
mechanism to invoke CGI scripts as the appropriate pseudo-user, rather
than as user httpd.


Goals for RT Installation
-------------------------

Given that we already have infrastructure in place for running
applications as pseudo-users, I wanted to use the same model for my RT
installation.  In particular, I had two main goals:

 1. Install RT under a single pseudo-user account and run every part
    of it as that user.  (I created a pseudo-user named "rt" with a
    home directory of "/services/rt" for this purpose.)

 2. Use my site's existing perl and apache packages instead of
    creating special builds just for RT.  (This means no set[ug]id
    perl scripts and no mod_perl.)

These goals presented several interesting challenges.


Installation Process
--------------------

Because the RT installation procedure assumes that you'll be running
different parts as different users, it includes commands that chown
various files, so it must be run as root.  After closely scrutinizing
what it was going to do, I ran it as root, but quickly chown'ed all of
the installed files to user rt.  I also removed all of the set[ug]id
bits.


RT Mail Gateway
---------------

Since rt-mailgate could not be a setgid script, I needed to find a way
to run it as user "rt".  The RT docs say to run it directly from
sendmail's aliases file, as follows:

  sysmgr: "|/services/rt/rt2/bin/rt-mailgate --queue sysmgr --action correspond"

That would result in rt-mailgate being run as user daemon.  To get
around this, I changed the alias to point to the rt user:

  sysmgr: rt

Then, as user rt, I use procmail to run rt-mailgate with the
appropriate options depending on what address the message was sent to.
Thus, rt-mailgate gets run as user rt.


RT Web Interface
----------------

The next problem was getting the web interface to run as user rt
instead of as user httpd.  In this case, even though I didn't want to
use mod_perl in the first place, the fact that I couldn't worked out
in my favor, since FastCGI can be configured to use Apache's suEXEC
mechanism to run external programs as alternate users.

The first problem I ran into in setting up FastCGI was a mod_perl
dependency problem in mason_handler.fcgi.  Commenting out this line
seemed to fix it:

   use HTML::Mason::ApacheHandler;

(I hope commenting this out doesn't have any bad side-effects, but I
haven't noticed any problems so far.  Is this a bug, or is there
something weird about my setup?)

Next, in order to be processed by our mod_rewrite rules and suEXEC,
the FastCGI handler had to be installed in ~rt/public_html/https.
However, since I had installed RT in ~rt/rt2, I solved this problem
with a hard link.  (The down-side of this is that I'll probably need
to recreate the hard link when I upgrade RT.)

Finally, I needed to create a symlink ~rt/public_html/https/images ->
~rt/rt2/WebRT/html/images so that the images would be accessible.

Here are the relevant snippets from httpd.conf:

--------------------------------------------------------------------------
LoadModule fastcgi_module            /usr/local/libexec/mod_fastcgi.so

AddModule mod_fastcgi.c

<IfModule mod_fastcgi.c>
    AddHandler fastcgi-script .fcgi
    FastCgiWrapper /usr/local/sbin/suexec
    FastCgiIpcDir /var/lib/httpd
</IfModule>

    <IfModule mod_rewrite.c>
        RewriteEngine on

        ### Allow the translated subrequest to pass straight through.
        RewriteCond %{IS_SUBREQ}                =true
        RewriteRule ^/~rt/https/ -       [L,PT]

        ### In case the rewritten URI leaks out to the browser,
        ### redirect it back to the advertised location.
        RewriteRule ^/~(rt)(/https)?(/(.*))?$      /$1/$4    [R=permanent,L]

        ### Redirect to add trailing '/' for directory names.
        RewriteRule ^/(rt)$           /$1/      [R=permanent,L]

        ### Handle requests for the advertised URIs by translating them
        ### and passing them through in a subrequest.
        RewriteRule ^/rt/images(/(.*))?$        /~rt/https/images/$2     [L,PT]
        RewriteRule ^/rt/(.*)$  /~rt/https/mason_handler.fcgi/$1         [L,PT]
    </IfModule>
--------------------------------------------------------------------------

Running the RT web interface as user rt eliminated the need for the
WebRT/data and WebRT/sessiondata directories to be owned by user
httpd.


Conclusion and Suggestions
--------------------------

There were a lot of issues that needed to be identified and addressed
in order to install RT under its own pseudo-user.  However, once this
was done, the procedure was actually fairly easy.

Based on this experience, here are a few off-the-cuff suggestions, for
whatever they're worth:

 * Change the installation procedure to use autoconf.  This would make
   it easier to install different parts of RT in different locations
   and with different options.  It would also make it easier to build
   distributable packages of RT.

 * Change the installation procedure not to assume that different
   files and directories need to have different ownerships.  This
   would allow RT to be installed by a user other than root.

 * Improve the documentation.  In particular, the installation
   instructions need to be more precise and more detailed.


Well, I think that's it for now...  Please let me know if you have any
questions, comments, or suggestions.  Thanks!

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/