Rt-mailgate/apache 404/405 errors

Hello:

I’m using RT3.0.10 with Apache 1.3.31 & mod_perl along
with fetchmail.

When fetchmail executes rt-mailgate, I get the following
in Apache error log:

[Fri Aug 6 13:12:43 2004] [error] [client 127.0.0.1] File does not exist: /bld/RT/apache/htdocs//REST/1.0/NoAuth/mail-gateway
and access_log has:

127.0.0.1 - - [06/Aug/2004:13:12:41 -0400] “POST //REST/1.0/NoAuth/mail-gateway HTTP/1.1” 404 315

The problem is that “htdocs” is NOT defined as the DocumentRoot of
my virtual server. Here is the lines from httpd.conf:

<VirtualHost 135.7.16.181>
ServerName bison.cb.lucent.com
DocumentRoot /bld/RT/share/html
AddDefaultCharset UTF-8

PerlModule Apache2 Apache::compat

    PerlModule Apache::DBI            
    PerlRequire /bld/RT/bin/webmux.pl 
    <Location />                      
            SetHandler perl-script    
            PerlHandler RT::Mason     
    </Location>                       

So I decided to create a symbolic link in htdocs to REST
directory:

$ cd /bld/RT/apache/htdocs
$ ln -s /bld/RT/share/html/REST REST

Now the “404” error turns into a “405” error with the following
error message in fetchmail log (from rt-mailgate):

405 Method Not Allowed

I guess my questions are:

1. How did the reference to /bld/RT/apache/htdocs occurr ??
2. Why didn't the symbolic link fix the problem?
3. Where else did I screw up?

There were no new entries in rt.log for this event.
I noticed that rt-mailgate has many references to “http://localhost

-Paul McFerrin

We’re currently running RT 2.0.15 with plans to upgrade to a current
version of RT3 in the near future. My particular interest is in the perl
API, because I have written a lot of perl scripts that allow us to
integrate RT functionality into some of our other processes.

With RT2, I’ve been using the primitive CLI in my scripts, mostly because
when I started I didn’t even know there was a real perl API to RT. But a
few months ago, I was told on this list that RT2, as well as RT3, has an
API. If not now, then at least when we go to RT3, I’d like to start using
the API instead.

My problem is that I’d like some documentation on how to use the API, e.g.
how to create a ticket, update a ticket (change its queue, its status, add
a comment, resolve it, etc.) from perl. The main benefit over the CLI I’m
using now would be return codes and error messages so that my scripts can
have reliable information about success and failure of particular
functions.

But I was also told on this list that there’s no documentation; that I
should look at the source. But this can be quite time-consuming. I’ve
looked at some of the perl code that comes with RT, so I have an idea of
what the API looks like. But what I’d really like is what would normally
appear on a man page, e.g, prototype function calls with return values.

If this isn’t actually documented, perhaps someone could post sample code
to do the following kinds of things. (Where RT2 and RT3 differ, I’d
prefer the RT3 version). I’ve shown the CLI equivalent that I’m using
now:

o Create a ticket:
rt --create --noedit --status=sssss --owner=ooooo --queue=qqqq
–requestors=rrrrr --subject=‘sss sss’ --source [filename | -]

o Change a ticket’s queue, status, etc.:
rt --id=nnnnn --queue=qqqqq --status=ssssss

o Add a comment to a ticket (using a file or STDIN as the source):
rt --id=nnnnn --comment --noedit --source [filename | -]

o Search for a ticket with particular contents in the Subject:
rt --limit-subject=‘sss sss sss’ --summary %id5%created25%subject80

o Update the set of Requestors for a ticket:
Currently, I need to retrieve the list of Requestors, subtract
each Requestor one at a time, then add each new Requestor, one
at a time (pseudo-code follows):
$rtout = rt --id=nnnnn --summary '%requestor200';

@requestors = split(/,/,$rtout);
for ($i = 0; $i <= $#requestors; $i++) {
system(“rt --id=nnnnn --requestors=-$requestors[$i]”);
}

Then add new Requestors, one at a time.

You get the idea. If I could see sample code to do each, or some, of the
above using the API, I could proceed from there.

Thanks.

Mike

Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu

At 06:26 PM 8/6/2004, Mike Friedman wrote:

But I was also told on this list that there’s no documentation; that I
should look at the source. But this can be quite time-consuming. I’ve
looked at some of the perl code that comes with RT, so I have an idea of
what the API looks like. But what I’d really like is what would normally
appear on a man page, e.g, prototype function calls with return values.

Most of the API should be internally documented with POD. Just run perldoc
on the file you are interested in and you will get the sort of
documentation that is standard with a Perl module. On the wiki, there are
some howtos and examples that might help you get started. However, the
actual Mason components are the definitive reference implementation of the
API and it is often worth looking through that code.

Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

[Fri Aug 6 13:12:43 2004] [error] [client 127.0.0.1] File does not exist: /bld/RT/apache/htdocs//REST/1.0/NoAuth/mail-gateway
<VirtualHost 135.7.16.181>

The problem is that “htdocs” is NOT defined as the DocumentRoot of
my virtual server. Here is the lines from httpd.conf:

No, that’s not your problem, and you failed to read your error
message. RT mailgate is accessing apache via localhost, 127.0.0.1,
while your virtual server is defined as only being for 135.7.16.181

seph

I figureed it was a localhost problem but can I configure Apache with a VirtualServer of
more that one IP address? (127.0.0.1 & 135.7.16.181)

seph wrote:

I figureed it was a localhost problem but can I configure Apache with a VirtualServer of
more that one IP address? (127.0.0.1 & 135.7.16.181)

Yes, if you are doing IP based vhosts, just list all IP’s involved
in the VirtualHost tag. If you are doing name based vhosts and
want to tie to all interfaces, use:
NameVirtualHost *:80
and
<VirtualHost *:80>
ServerName firstvhost.mydomain


<VirtualHost *:80>
ServerName secondvhost.mydomain


Names that aren’t an exact for a SeverName or ServerAlias
entry go to the first VirtualHost for the IP:port combination.

However you could solve this particular problem by telling
rt-mailgate to send to the 135.7.16.181 address or name
instead of localhost so apache will match the correct existing
vhost.

Les Mikesell
les@futuresource.com