RT 4.08 on Apache 2 won't load

Hi,

I’ve installed 4.0.8 on CentOS 6.3, satisfied all dependencies etc, run the
web installer to get things started, but I can’t actually get my RT pages
to load. I’ve tried using all of the apache options on web_deployment on
the installation pages at bestpractical.com but with no luck.

using mod_fcgi and mod_fcgid I get 404 not found, with a corresponding log
entry in /var/log/httpd/error.log of:

File does not exist: /opt/rt4/sbin/rt-server.fcgi
The file does exist, and won’t start manually even when invoked from sbin
with ./

Trying the mod_perl apache setup results in Apache failing to start:

Undefined subroutine &main::. called. END failed-- call queue aborted.
(/opt/rt4/sbin/…/lib/RT.pm:341)

Any ideas - this has got me totally stuck!

Thanks in advance.

Hi,

I’ve installed RT 4.0.8 on a RHEL 6.2 system and overall it’s working
fine with one notable exception. We authenticate users with Shibboleth,
and once so authenticated they are able to create tickets. First time
users have their accounts auto-created. We had a previous instance of
RT 3.0.7 and used perl-based forms for ticket creation. Auto-creation
of accounts worked fine, with the displayname, email, and userid
returned from Shibboleth and passed to RT. However, these same forms
when used on RT 4.0.8 while they do create the account if it doesn’t
exist, and it does set the “Name” to the email address, the
“EmailAddress” itself and “RealName” are left blank.

This means that users cannot get email on their tickets (confirmatory or
otherwise), unless an administrator goes in, selects the account, and
manually adds the email address. I’ve tried several workarounds,
including doing a mysql query to see if the account exists, and if not,
to create it using an RT CLI command encased in backticks. This is
contained in our “contact” ticket creation form. I’ve experimented with
several options, including escaping the “@” in the email address.
Recently, I used Encode to ensure the values obtained from Shibboleth
were converted into UTF-8 before being passed to the RT CLI command, and
this sort of worked. Interestingly, it added the account but dropped
the letter “e” from the mymail.edu address (to leave mymail.du). Also
interesting, is if I bypass the Shibboleth values and hard code in an
email address like:

my $clean_email = “skippy@mailme.edu”

And pass it to the RT CLI command like:

$result = /opt/rt4/bin/rt create -t user add Name=$your_netid EmailAddress=$clean_email ;

…again, it works fine.

I’ve been banging my head on this for awhile. Any insights would be
appreciated.

JohnOn 11/21/2012 1:03 PM, Guy Baxter wrote:

Hi,

I’ve installed 4.0.8 on CentOS 6.3, satisfied all dependencies etc,
run the web installer to get things started, but I can’t actually get
my RT pages to load. I’ve tried using all of the apache options on
web_deployment on the installation pages at bestpractical.com
http://bestpractical.com/ but with no luck.

using mod_fcgi and mod_fcgid I get 404 not found, with a corresponding
log entry in /var/log/httpd/error.log of:

File does not exist: /opt/rt4/sbin/rt-server.fcgi
The file does exist, and won’t start manually even when invoked from
sbin with ./

Trying the mod_perl apache setup results in Apache failing to start:

Undefined subroutine &main::. called. END failed-- call queue aborted.
(/opt/rt4/sbin/…/lib/RT.pm:341)

Any ideas - this has got me totally stuck!

Thanks in advance.


We’re hiring! Careers — Best Practical Solutions

I’ve installed 4.0.8 on CentOS 6.3, satisfied all dependencies etc, run the web installer to
get things started, but I can’t actually get my RT pages to load. I’ve tried using all of the
apache options on web_deployment on the installation pages at [1]bestpractical.com but with no
luck.
using mod_fcgi and mod_fcgid I get 404 not found, with a corresponding log entry in
/var/log/httpd/error.log of:
File does not exist: /opt/rt4/sbin/rt-server.fcgi
The file does exist, and won’t start manually even when invoked from sbin with ./

Can the webserver access it? Check selinux permissions for the
webserver having access to RT.

Also, you didn’t say how it failed when run manually.

-kevin

I’ve installed RT 4.0.8 on a RHEL 6.2 system and overall it’s working fine with one notable
exception. We authenticate users with Shibboleth, and once so authenticated they are able to
create tickets. First time users have their accounts auto-created. We had a previous
instance of RT 3.0.7 and used perl-based forms for ticket creation. Auto-creation of accounts
worked fine, with the displayname, email, and userid returned from Shibboleth and passed to
RT. However, these same forms when used on RT 4.0.8 while they do create the account if it
doesn’t exist, and it does set the “Name” to the email address, the “EmailAddress” itself and
“RealName” are left blank.

How do your forms create tickets/accounts? Using bin/rt or sending
mail as the user or something else? I can see what you’ve done with
testing, but knowing how they normally work is helpful.

Unfortunately, without some logs, or a clearer sense of exactly what
runs during the non-debugging form, it’s hard to guess at what is
going on.

-kevin

Thanks Kevin,

We’ve been using the REST API for creating the tickets. We assign
certain critical variables using the values returned by Shibboleth
authentication first:

my $your_netid = $ENV{‘REMOTE_USER’};
my $your_full_name = $ENV{‘displayName’};
my $your_phone = $query->param(“PHONE”);
my $your_subject = $query->param(“SUBJECT”);
my $your_comments = $query->param(“COMMENTS”);
my $your_public = $query->param(“PUBLIC”);

Set the server and then login using an authorized admin user:

my $rt = RT::Client::REST->new(
server => ($ENV{RTSERVER} || ‘http://our.domain.com’),
);

 $rt->login(
 username=> "adminusername",
 password=> "adminpassword",
 );

Then create the ticket.

my $ticket = RT::Client::REST::Ticket->new(
rt => $rt,
queue => “General”,
subject => “$your_subject”,
requestor => [$your_netid],
cf => {
‘public’ => $your_public,
},
)->store(text => “$your_comments”);

my $newticket = $ticket->id;

To elaborate on the forms further, they were created by someone no
longer with our organization, and modifications were not well documented
(if at all). The action on our old RT instance was as the “netid” was
passed into RT, the account (if it did not already exist), was created
with the username and email set to the netid. When these forms were
moved to the new RT instance, everything was pretty much the same,
except that the email address field was not filled in. To work around
this problem, we tried adding this code using bin/RT:

my $clean_email = $ENV{‘mail’};
$clean_email =~ s/@/\@/g;
$result = /opt/rt4/bin/rt create -t user add Name=$your_netid EmailAddress=$clean_email ;

As I said previously, if you “hard code” in an email for $clean_email,
it works every time as one would expect. If not, and you pass in the
shib variable as shown above, it fails.

Thanks for any input.

JohnOn 11/27/12 12:25 PM, Kevin Falcone wrote:

On Wed, Nov 21, 2012 at 01:24:11PM -0500, John Johnston wrote:

I've installed RT 4.0.8 on a RHEL 6.2 system and overall it's working fine with one notable
exception.  We authenticate users with Shibboleth, and once so authenticated they are able to
create tickets.  First time users have their accounts auto-created.  We had a previous
instance of RT 3.0.7 and used perl-based forms for ticket creation.  Auto-creation of accounts
worked fine, with the displayname, email, and userid returned from Shibboleth and passed to
RT.  However, these same forms when used on RT 4.0.8 while they *do* create the account if it
doesn't exist, and it does set the "Name" to the email address, the "EmailAddress" itself and
"RealName" are left blank.

How do your forms create tickets/accounts? Using bin/rt or sending
mail as the user or something else? I can see what you’ve done with
testing, but knowing how they normally work is helpful.

Unfortunately, without some logs, or a clearer sense of exactly what
runs during the non-debugging form, it’s hard to guess at what is
going on.

-kevin

This means that users cannot get email on their tickets (confirmatory or otherwise), unless an
administrator goes in, selects the account, and manually adds the email address.  I've tried
several workarounds, including doing a mysql query to see if the account exists, and if not,
to create it using an RT CLI command encased in backticks.  This is contained in our "contact"
ticket creation form.  I've experimented with several options, including escaping the "@" in
the email address.  Recently, I used Encode to ensure the values obtained from Shibboleth were
converted into UTF-8 before being passed to the RT CLI command, and this *sort of* worked.
Interestingly, it added the account but dropped the letter "e" from the mymail.edu address (to
leave mymail.du).  Also interesting, is if I bypass the Shibboleth values and hard code in an
email address like:

my $clean_email = [1]"skippy@mailme.edu"

And pass it to the RT CLI command like:

$result = `/opt/rt4/bin/rt create -t user add Name=$your_netid EmailAddress=$clean_email `;

...again, it works fine.

I've been banging my head on this for awhile.  Any insights would be appreciated.

We’re hiring! Careers — Best Practical Solutions

We’ve been using the REST API for creating the tickets. We assign certain critical variables
using the values returned by Shibboleth authentication first:

my $your_netid = $ENV{‘REMOTE_USER’};

Presumably REMOTE_USER is set to johnj rather than johnj@msu.edu?

   my $ticket = RT::Client::REST::Ticket->new(
       rt  => $rt,
       queue   => "General",
       subject => "$your_subject",
       requestor => [$your_netid],
       cf => {
               'public' => $your_public,
           },
   )->store(text => "$your_comments");

my $newticket = $ticket->id;

With this call, I don’t see how RT could possibly know your Email
Address. My assumption is that your RT 3.0 install had a local
modification to set empty Email Addresses to the Username +
@yourdomain. This is a pretty common thing to do using the
CanonicalizeUserInfo method. I’d suggest checking for a missed
customization.

-kevin

Actually no, REMOTE_USER in our institution includes the domain name, so
in this example it would be johnj@msu.edu. I have double checked this
by having the form spit out the variables returned by the Shibboleth IdP.

JohnOn 11/27/12 10:07 PM, Kevin Falcone wrote:

On Tue, Nov 27, 2012 at 01:30:41PM -0500, John Johnston wrote:

We've been using the REST API for creating the tickets.  We assign certain critical variables
using the values returned by Shibboleth authentication first:

my $your_netid = $ENV{'REMOTE_USER'};

Presumably REMOTE_USER is set to johnj rather than johnj@msu.edu?

    my $ticket = RT::Client::REST::Ticket->new(
        rt  => $rt,
        queue   => "General",
        subject => "$your_subject",
        requestor => [$your_netid],
        cf => {
                'public' => $your_public,
            },
    )->store(text => "$your_comments");
my $newticket =  $ticket->id;

With this call, I don’t see how RT could possibly know your Email
Address. My assumption is that your RT 3.0 install had a local
modification to set empty Email Addresses to the Username +
@yourdomain. This is a pretty common thing to do using the
CanonicalizeUserInfo method. I’d suggest checking for a missed
customization.

-kevin


We’re hiring! Careers — Best Practical Solutions

Actually no, REMOTE_USER in our institution includes the domain name, so in this example it
would be johnj@msu.edu. I have double checked this by having the form spit out the
variables returned by the Shibboleth IdP.

    my $ticket = RT::Client::REST::Ticket->new(
        rt  => $rt,
        queue   => "General",
        subject => "$your_subject",
        requestor => [$your_netid],
        cf => {
                'public' => $your_public,
            },
    )->store(text => "$your_comments");
my $newticket =  $ticket->id;

Unfortunately, I’m not sure what’s different between your code and the
straight REST interface, but using bin/rt to create a ticket:

id: ticket/new
Queue: General
Requestor: johnj@msu.edu

Nets me a new user with your email address as the username and the email
address. This is plain RT4. If you’re seeing different behavior, I
assume there is a modification, go looking for a local definition of
CanonicalizeUserInfo.

-kevin