I’m just started a new job and I’d like to set up RT here as well.
Help requests without my RT remind me of TV without using TiVo to skip
commercials: I can only stand it for a short while.
Please comment as to the correctness of my assumptions and feasibility
of my game plan. Thanks
Now that I’m doing a new install, with 3.x instead of 2.x, I want to
start with the right infrastructure to set it up so that I can:
do external authentication to (either kerberized windows
authentication or LDAP authentication - through w2k active directory).
use https
My assumptions:
Apache 2.x handles external LDAP authentication better (or at least
it is easier to set up) than Apache 1.x.
mod_perl isn’t ready for Apache 2.x
fastcgi could work with Apache 2.x to support RT 3.x ?
The game plan:
Install apache 2.x with https: and fastcgi with postgresql on a redhat
9.0 system (installing apache from src instead of rpms).
This one time, at band camp, Mike Patterson wrote:
The game plan:
Install apache 2.x with https: and fastcgi with postgresql on a redhat
9.0 system (installing apache from src instead of rpms).
I use Apache, mod_ssl and PostgreSQL from RPMs on a Red Hat 9 system, and I use
locally built RPMs of mod_fastcgi and the required CPAN modules (google for
cpan2rpm for a useful tool). So your game plan will work, but you don’t
have to build RPMs for everything.
Now that I’m doing a new install, with 3.x instead of 2.x, I want to
start with the right infrastructure to set it up so that I can:
do external authentication to (either kerberized windows
authentication or LDAP authentication - through w2k active directory).
the way you say that, makes me think of something that authorizes to
either the tickets a user has cached on their local machine. I believe
this will be Very Hard, if even possible. I don’t think there’s a
useful way for the browser to send that auth along. Of course, maybe
you just mean having apache check the password it gets against one of
those backends…
My assumptions:
Apache 2.x handles external LDAP authentication better (or at least
it is easier to set up) than Apache 1.x.
I would not assume this. As mentioned above, I assume your apache is
doing basic auth, and you’re trying to verify the
username/password. There are several ways to do that in apache 1.x,
and I assume apache 2.x as well.
fastcgi could work with Apache 2.x to support RT 3.x ?
fastcgi works fine with RT3. I have no experience with apache 2.x
What I would really like to see is a matrix of configurations. Known good OSs, RTs, Apaches, perl and modules.
It would require
- someone to host it,
- someone to write the code (or some freeware) to make it available and last but not least
- a plethora of users submitting their configurations
The user input is where this sort of thing usually falls apart. This list is great and there are quite a few generous supporters, but the output is only as valid as the input that is sent in.
Anyone feel inspired?
Gregory L. Hering
(256) 722-6420
4807 Bradford Dr
Benchmark Electronics, Inc.
Hunvtsville, Al 35805From: Robert Spier [mailto:rspier@pobox.com]
Sent: Tuesday, June 17, 2003 7:23 PM
To: Mike Patterson
Cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] Apache 2.x vs 1.x - and external auth
My assumptions:
Apache 2.x handles external LDAP authentication better (or at least
it is easier to set up) than Apache 1.x.
Maybe.
mod_perl isn’t ready for Apache 2.x
This is more of “mod_perl2 is not compatible with mod_perl1, and RT is
written against mod_perl1”
fastcgi could work with Apache 2.x to support RT 3.x ?
Yes. I do this.
The game plan:
Install apache 2.x with https: and fastcgi with postgresql on a redhat
9.0 system (installing apache from src instead of rpms).