Can't log in to web interface with fresh RT install on OSX

If this is a FAQ and a variant of this question can be found in the
archives, I apologize, but several minutes of poking around in the
archives and in the wiki didn’t give me any leads here.

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

The install appears to go smoothly, and when I try to load RT in the web
interface, I get the login screen. This is as far as I can get though.
If I log in, I’m immediately sent back to the login screen, no matter
what I use for login credentials: root/password didn’t work, and going
into MySQL and deleting the value for the password field (which seems
like an emergency way to have a blank password) didn’t help either.

When trying to access the site, nothing relevant shows up in Apache’s
access_log or error_log, or in /var/log/system.log – just normal GET
requests recorded in the access log file.

I used to have RT working on my old Mac, but when it died and I copied
the files & config over to my new one, this was the behavior I got. I
thought maybe something got garbled in the move, so I’m trying now with
a fresh install of the current build of RT, and it does the same thing.

Does RT just not get along with Panther’s “old” version of Perl? Is
there something else I can do to tease out more diagnostic information?

Any suggestions would be appreciated; more details available on request.

Chris Devers

See the notes I posted earlier this week about installing rt 2.4.1 on mac os
x server

Can you turn on rt logging to path_to_rt/var/log/rt.log make sure
permissions are set correctlyOn 3/4/05 4:22 PM, “Chris Devers” cdevers@pobox.com wrote:

If this is a FAQ and a variant of this question can be found in the
archives, I apologize, but several minutes of poking around in the
archives and in the wiki didn’t give me any leads here.

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

The install appears to go smoothly, and when I try to load RT in the web
interface, I get the login screen. This is as far as I can get though.
If I log in, I’m immediately sent back to the login screen, no matter
what I use for login credentials: root/password didn’t work, and going
into MySQL and deleting the value for the password field (which seems
like an emergency way to have a blank password) didn’t help either.

When trying to access the site, nothing relevant shows up in Apache’s
access_log or error_log, or in /var/log/system.log – just normal GET
requests recorded in the access log file.

I used to have RT working on my old Mac, but when it died and I copied
the files & config over to my new one, this was the behavior I got. I
thought maybe something got garbled in the move, so I’m trying now with
a fresh install of the current build of RT, and it does the same thing.

Does RT just not get along with Panther’s “old” version of Perl? Is
there something else I can do to tease out more diagnostic information?

Any suggestions would be appreciated; more details available on request.

If I log in, I’m immediately sent back to the login screen,

Sounds almost like cookies are blocked in your browser.

Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
“Never moon a werewolf.”

If I log in, I’m immediately sent back to the login screen,

Sounds almost like cookies are blocked in your browser.

I’m seeing this behavior in both Firefox & Safari.

Neither has cookies disabled.

I can connect to the RT server at work without problems using either
browser.

I suspect the problem is something else… :-/

Chris Devers

Do the logs (apache, dmesg, or rt.log) say anything at allOn 3/4/05 4:54 PM, “Chris Devers” cdevers@pobox.com wrote:

On Fri, 4 Mar 2005, Russell Mosemann wrote:

On Fri, 4 Mar 2005, Chris Devers wrote:

If I log in, I’m immediately sent back to the login screen,

Sounds almost like cookies are blocked in your browser.

I’m seeing this behavior in both Firefox & Safari.

Neither has cookies disabled.

I can connect to the RT server at work without problems using either
browser.

I suspect the problem is something else… :-/

Do the logs (apache, dmesg, or rt.log) say anything at all

As noted in the first message, the Apache logs show only normal HTTP GET
requests, e.g. (modified combined log format) :

==> /var/log/httpd/access_log <==
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:56 -0500] "POST / HTTP/1.1" 200 2714 "http://rt-vhost:8080/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12"
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:58 -0500] "GET /NoAuth/webrt.css HTTP/1.1" 200 12276 "http://rt-vhost:8080/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12"
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:59 -0500] "GET /NoAuth/images//bplogo.gif HTTP/1.1" 200 825 "http://rt-vhost:8080/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12"

Nothing shows up in the error log when accessing RT.

I have a /usr/local/var/log/rt.log file, but it shows no new activity
since the last time I took a crack at getting RT working at home, back
in July of 2004. If the RT instance I installed yesterday is logging
anything anywhere, it isn’t going into a file named rt.log.

I see the $Log* variables in RT_SiteConfig.pm; would it make sense to
crank up the debug level on those variables for this? Hmm… I guess
I’ll give that a try…

Chris Devers

In your RT_Siteconfig.pm
Do you have “http://rt-vhost:8080/” set as the RT_UrlOn 3/4/05 5:21 PM, “Chris Devers” cdevers@pobox.com wrote:

On Fri, 4 Mar 2005, steverieger wrote:

Do the logs (apache, dmesg, or rt.log) say anything at all

As noted in the first message, the Apache logs show only normal HTTP GET
requests, e.g. (modified combined log format) :

==> /var/log/httpd/access_log <==
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:56 -0500] "POST / HTTP/1.1"

200 2714 “http://rt-vhost:8080/” “Mozilla/5.0 (Macintosh; U; PPC Mac OS X;
en-us) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12”
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:58 -0500] “GET
/NoAuth/webrt.css HTTP/1.1” 200 12276 “http://rt-vhost:8080/” “Mozilla/5.0
(Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML, like Gecko)
Safari/125.12”
rt-vhost 192.168.0.1 - - [04/Mar/2005:16:04:59 -0500] “GET
/NoAuth/images//bplogo.gif HTTP/1.1” 200 825 “http://rt-vhost:8080/
“Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML,
like Gecko) Safari/125.12”

Nothing shows up in the error log when accessing RT.

I have a /usr/local/var/log/rt.log file, but it shows no new activity
since the last time I took a crack at getting RT working at home, back
in July of 2004. If the RT instance I installed yesterday is logging
anything anywhere, it isn’t going into a file named rt.log.

I see the $Log* variables in RT_SiteConfig.pm; would it make sense to
crank up the debug level on those variables for this? Hmm… I guess
I’ll give that a try…

In your RT_Siteconfig.pm
Do you have “http://rt-vhost:8080/” set as the RT_Url

The string /RT_Url/ doesn’t show up anywhere, but I do have –

Set($WebBaseURL , "http://rt-vhost:8080");

– which appears to be equivalent. Do I also need $RT_Url defined?

Chris Devers

See the notes I posted earlier this week about installing rt 2.4.1 on
mac os x server

You mean this post about RT 3.4.1 (not 2.4.1) on OSX 10.4?

http://lists.bestpractical.com/pipermail/rt-users/2005-March/029146.html

That message suggests that these lines may be the problem:

Set($DatabaseHost , ‘localhost’);
Set($DatabaseRTHost , ‘localhost’);

The file comment suggests that leaving those fields blank may improve
performance, but in my case the behavior doesn’t seem to have changed.

Can you turn on rt logging to path_to_rt/var/log/rt.log make sure
permissions are set correctly

In my RT config, I have:

Set($LogToSyslog , ‘debug’);
Set($LogToScreen , ‘error’);
#Set($LogToFile , undef);
Set($LogToFile , ‘debug’);
Set($LogDir, ‘/usr/local/rt3/var/log’);
Set($LogToFileNamed , “rt.log”); #log to rt.log

The log file itself, after mucking around with broadened permissions,
is:

$ ls -la /usr/local/rt3/var/log/rt.log
-rw-rw-rw- 1 rt www 0 Mar 4 18:21 /usr/local/rt3/var/log/rt.log
$

And again, a

$ tail -f /usr/local/rt3/var/log/rt.log /var/log/{httpd/*log,system.log}

shows no activity on page loads other than the GET requests to Apache.

I’m able to connect to the MySQL server using the database user account
I’ve set up for RT to use, so that doesn’t seem to be the problem…

Chris Devers

See the notes I posted earlier this week about installing rt 2.4.1 on
mac os x server

You mean this post about RT 3.4.1 (not 2.4.1) on OSX 10.4?

http://lists.bestpractical.com/pipermail/rt-users/2005-March/029146.html

By the way, that message mentions:

Other than that I used fink to installed OSXUserUtils from 
www.osxgnu.org so that we can add the rt group via command line

This can be done with OSX’s built-in NetInfo command line tools.

To create a ‘rt’ group with group-id 82:

nicl / create /groups/rt gid 82
nicl / create /groups/rt passwd \*

To create a ‘rt’ user account with user-id 261:

nicl / -create /users/rt uid 261
nicl / -create /users/rt shell /usr/bin/false
nicl / -create /users/rt home /usr/local/rt3
nicl / -create /users/rt realname "RT Daemon Account"
nicl / -create /users/rt passwd \*
nicl / -create /users/rt gid 82 

You can also use /etc/password syntax, with something like this:

niload passwd . <<EOF
rt:*:261:82::0:0:RT Daemon Account:/usr/local/rt3:/usr/bin/false
EOF

Conceivably, the RT installer can run these commands automatically…

Chris Devers

If this is a FAQ and a variant of this question can be found in the
archives, I apologize, but several minutes of poking around in the
archives and in the wiki didn’t give me any leads here.

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

The install appears to go smoothly, and when I try to load RT in the
web interface, I get the login screen. This is as far as I can get
though. If I log in, I’m immediately sent back to the login screen, no
matter what I use for login credentials: root/password didn’t work,
and going into MySQL and deleting the value for the password field
(which seems like an emergency way to have a blank password) didn’t
help either.

When trying to access the site, nothing relevant shows up in Apache’s
access_log or error_log, or in /var/log/system.log – just normal GET
requests recorded in the access log file.

…and, as noted in later messages in this thread, rt.log doesn’t show
any activity either, even though RT_SiteConfig.pm has it set to ‘debug’.

Has anyone seen this problem, and worked past it?

A google search of the list archives for login issues turns up lots and
lots of hits, but a lot of the threads don’t seem to have a resolution:

http://www.google.com/search?q=site%3Ahttp%3A%2F%2Flists.bestpractical.com+login

Any suggestions would be greatly appreciated.

I’d be happy to provide more configuration details if it would help.

Chris Devers

If this is a FAQ and a variant of this question can be found in the
archives, I apologize, but several minutes of poking around in the
archives and in the wiki didn’t give me any leads here.

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

The install appears to go smoothly, and when I try to load RT in the
web interface, I get the login screen. This is as far as I can get
though. If I log in, I’m immediately sent back to the login screen, no
matter what I use for login credentials: root/password didn’t work,
and going into MySQL and deleting the value for the password field
(which seems like an emergency way to have a blank password) didn’t
help either.

When trying to access the site, nothing relevant shows up in Apache’s
access_log or error_log, or in /var/log/system.log – just normal GET
requests recorded in the access log file.

…and, as noted in later messages in this thread, rt.log doesn’t show
any activity either, even though RT_SiteConfig.pm has it set to ‘debug’.

Has anyone seen this problem, and worked past it?

A google search of the list archives for login issues turns up lots and
lots of hits, but a lot of the threads don’t seem to have a resolution:

http://www.google.com/search?q=site%3Ahttp%3A%2F%2Flists.bestpractical.com+login

Any suggestions would be greatly appreciated.

You know, Chris, I had a problem similar to that about 6 months ago, in
my first round of evaluation of ticketing systems, I’d log in, and get
an empty screen.

I strongly suspicion that your mod_perl or the perl underlying it is
hosed. Yeah: can you describe your setup a bit? All the components,
complete version numbers, RPM, DEB, or source, and maybe build
switches?

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system adminstrator.  Or two.  --me

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

You know, Chris, I had a problem similar to that about 6 months ago,
in my first round of evaluation of ticketing systems, I’d log in, and
get an empty screen.

Okay, but I’m not getting an empty screen though – I get the proper RT
login screen, just the way it looks elsewhere (e.g. the Debian box that
serves it at work, etc), with a banner, a footer, un/pw fields, etc. It
just doesn’t appear to be connected to anything :-/

I strongly suspicion that your mod_perl or the perl underlying it is
hosed. Yeah: can you describe your setup a bit? All the components,
complete version numbers, RPM, DEB, or source, and maybe build
switches?

I wouldn’t be at all surprised if Apple’s Perl were buggy. :frowning:

The version numbers were posted above & earlier, but to reiterate:
Apple’s Perl 5.8.1 and mod_perl 1.26 plugged in to Apache 1.3.33 all
running on Mac OS X 10.3.8. In more detail, here’s the Perl info:

% /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 1 RC3) configuration:
  Platform:
    osname=darwin, osvers=7.0, archname=darwin-thread-multi-2level
    uname='darwin hampsten 7.0 darwin kernel version 6.0: fri jul 25 16:58:41 pdt 2003; root:xnu-344.frankd.rootsxnu-344.frankd~objrelease_ppc power macintosh powerpc '
    config_args='-ds -e -Dprefix=/usr -Dccflags=-g  -pipe  -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include',
    optimize='-Os',
    cppflags='-no-cpp-precomp -g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-ldbm -ldl -lm -lc
    perllibs=-ldl -lm -lc
    libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
  Locally applied patches:
        RC3
  Built under darwin
  Compiled at Sep 12 2003 19:50:49
  %ENV:
    PERL5LIB="/sw/lib/perl5:/sw/lib/perl5/darwin"
    PERL5_CPANPLUS_CONFIG="/Users/cdevers/.cpanplus/config"
  @INC:
    /sw/lib/perl5/5.8.1/darwin-thread-multi-2level
    /sw/lib/perl5/5.8.1
    /sw/lib/perl5
    /sw/lib/perl5/darwin
    /System/Library/Perl/5.8.1/darwin-thread-multi-2level
    /System/Library/Perl/5.8.1
    /Library/Perl/5.8.1/darwin-thread-multi-2level
    /Library/Perl/5.8.1
    /Library/Perl
    /Network/Library/Perl/5.8.1/darwin-thread-multi-2level
    /Network/Library/Perl/5.8.1
    /Network/Library/Perl
    .

It seems like mod_perl is working, at least partially. I have a
collection of Apache::Registry scripts that all seem to work fine, and I
have Apache::MP3 set up and working as well. Additionally, I can invoke
an Apache::Status served URL to browse mod_perl settings, and it doesn’t
seem like it’s choking on anything; in particular, if I browse the
modules that mod_perl can see, there’s a large block of them in the
RT::* namespace coming out of /usr/local/rt3, which is the correct
location of the current RT installation.

Here’s what Apache says about how it was built:

$ httpd -V
Server version: Apache/1.3.33 (Darwin)
Server built:   Nov 29 2004 17:59:31
Server's Module Magic Number: 19990320:16
Server compiled with....
 -D EAPI
 -D HAVE_MMAP
 -D USE_MMAP_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_FLOCK_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D DYNAMIC_MODULE_LIMIT=64
 -D HARD_SERVER_LIMIT=2048
 -D HTTPD_ROOT="/usr"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/run/httpd.pid"
 -D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="/var/run/httpd.lock"
 -D DEFAULT_ERRORLOG="/var/log/httpd/error_log"
 -D TYPES_CONFIG_FILE="/etc/httpd/mime.types"
 -D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
 -D ACCESS_CONFIG_FILE="/etc/httpd/access.conf"
 -D RESOURCE_CONFIG_FILE="/etc/httpd/srm.conf"
$ httpd -v
Server version: Apache/1.3.33 (Darwin)
Server built:   Nov 29 2004 17:59:31
macgarnicle:/etc/httpd root# httpd -l
Compiled-in modules:
  http_core.c
  mod_so.c
suexec: disabled; invalid wrapper /usr/sbin/suexec
$

The relevant Apache virtual host config is as follows:

<VirtualHost *>
    ServerName        rt-test-server
    ServerAdmin       cdevers@rt-test-server
    DocumentRoot      /usr/local/rt3/share/html
    AddDefaultCharset UTF-8
    PerlRequire       /usr/local/rt3/bin/webmux.pl
    <Location />
        SetHandler    perl-script
        PerlHandler   RT::Mason
    </Location>
</VirtualHost>

And for completness, RT’s RT_SiteConfig.pm is as follows:

package RT;
Set($rtname , "rt-test-server");
Set($Organization , "rt-test-server");
Set($MinimumPasswordLength , "5");
Set($Timezone , 'US/Eastern');
Set($DatabaseType , 'mysql');
Set($DatabaseHost   , '');
Set($DatabaseRTHost , '');
Set($DatabasePort , '');
Set($DatabaseUser , 'rt_user');
Set($DatabasePassword , 'serum114');
Set($DatabaseName , 'rtnew');
Set($DatabaseRequireSSL , undef);
Set($OwnerEmail , 'cdevers');
Set($LoopsToRTOwner , 1);
Set($StoreLoops , undef);
Set($MaxAttachmentSize , 10000000);
Set($TruncateLongAttachments , undef);
Set($DropLongAttachments , undef);
Set($ParseNewMessageForTicketCcs , undef);
Set($RTAddressRegexp , '^rt\@rt-test-server$');
Set($CanonicalizeOnCreate , 0);
Set($SenderMustExistInExternalDatabase , undef);
Set($CorrespondAddress , 'rt@rt-test-server');
Set($CommentAddress , 'rt-comment@rt-test-server');
Set($MailCommand , 'sendmailpipe');
Set($SendmailArguments , "-oi -t");
Set($SendmailPath , "/usr/sbin/sendmail");
Set($UseFriendlyFromLine , 1);
Set($FriendlyFromLineFormat , "\"%s via RT\" <%s>");
Set($UseFriendlyToLine , 1);
Set($FriendlyToLineFormat, "\"%s of $RT::rtname Ticket #%s\":;");
Set($NotifyActor, 0);
Set($RecordOutgoingEmail, 1);
Set($LogToSyslog    , 'debug');
Set($LogToScreen    , 'error');
Set($LogToFile      , 1);
Set($LogDir         , '/usr/local/rt3/var/log');
Set($LogToFileNamed , "rt.log");    #log to rt.log
@LogToSyslogConf = () unless (@LogToSyslogConf);
Set($WebPath , "");
Set($WebBaseURL , "http://rt-test-server:8080");
Set($WebURL , $WebBaseURL . $WebPath . "/");
Set($WebImagesURL , $WebPath . "/NoAuth/images/");
Set($LogoURL , $WebImagesURL . "rt-dhn-logo.jpg");
Set($WebNoAuthRegex, qr!^(?:/+NoAuth/|
                            /+REST/\d+\.\d+/NoAuth/)!x );
Set($MessageBoxWidth , 84);
Set($MessageBoxWrap, "HARD");
Set($TrustHTMLAttachments , undef);
Set($RedistributeAutoGeneratedMessages, 1);
Set($PreferRichText, undef);
Set($WebExternalAuth , undef);
Set($WebFallbackToInternalAuth , undef);
Set($WebExternalGecos , undef);
Set($WebExternalAuto , undef);
Set($WebFlushDbCacheEveryRequest, '1');
Set($MaxInlineBody, 13456);
Set($MyTicketsLength, 10);
Set($MyRequestsLength, 10);
@MasonParameters = () unless (@MasonParameters);
Set ($DefaultSearchResultFormat, qq{
   '<b><a href="$RT::WebPath/Ticket/Display.html?id=__id__">__id__</a></b>/title:#',
   '<b><a href="$RT::WebPath/Ticket/Display.html?id=__id__">__Subject__</a></b>/title:Subject',
   Status,
   QueueName, 
   OwnerName, 
   Priority, 
   '__NEWLINE__',
   '', 
   '<small>__Requestors__</small>',
   '<small>__CreatedRelative__</small>',
   '<small>__ToldRelative__</small>',
   '<small>__LastUpdatedRelative__</small>',
   '<small>__TimeLeft__</small>'});
@LexiconLanguages = qw(*) unless (@LexiconLanguages);
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless (@EmailInputEncodings);
Set($EmailOutputEncoding , 'utf-8');
Set($DateDayBeforeMonth , 1);
Set($AmbiguousDayInPast , 1);
@ActiveStatus = qw(new open stalled) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;
Set($DevelMode => '0');
1;

I mean, I suppose I could start over with a clean Apache/mod_perl/Perl
build, but that’s a huge project & a pain in the ass when all I want to
do is set up a spare RT instance to test things out without messing up
the real version that we’ve got running on a Debian box at work… :-/

That & it bugs me that I seem to be this close to having it working
but there’s just some little misconfiguration somewhere that’s keeping
it from getting off the ground…

Chris Devers

I recall a thread a couple months back that implied Apple’s perl
wouldn’t run RT properly. Have you tried removing it and installing
from source?

DB

Chris Devers wrote:>On Mon, 7 Mar 2005, Jay R. Ashworth wrote:

On Mon, Mar 07, 2005 at 06:12:04PM -0500, Chris Devers wrote:

On Fri, 4 Mar 2005, Chris Devers wrote:

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

You know, Chris, I had a problem similar to that about 6 months ago,
in my first round of evaluation of ticketing systems, I’d log in, and
get an empty screen.

Okay, but I’m not getting an empty screen though – I get the proper RT
login screen, just the way it looks elsewhere (e.g. the Debian box that
serves it at work, etc), with a banner, a footer, un/pw fields, etc. It
just doesn’t appear to be connected to anything :-/

I strongly suspicion that your mod_perl or the perl underlying it is
hosed. Yeah: can you describe your setup a bit? All the components,
complete version numbers, RPM, DEB, or source, and maybe build
switches?

I wouldn’t be at all surprised if Apple’s Perl were buggy. :frowning:

The version numbers were posted above & earlier, but to reiterate:
Apple’s Perl 5.8.1 and mod_perl 1.26 plugged in to Apache 1.3.33 all
running on Mac OS X 10.3.8. In more detail, here’s the Perl info:

% /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 1 RC3) configuration:
Platform:
osname=darwin, osvers=7.0, archname=darwin-thread-multi-2level
uname=‘darwin hampsten 7.0 darwin kernel version 6.0: fri jul 25 16:58:41 pdt 2003; root:xnu-344.frankd.rootsxnu-344.frankd~objrelease_ppc power macintosh powerpc ’
config_args=’-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib’
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc=‘cc’, ccflags =‘-g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include’,
optimize=‘-Os’,
cppflags=‘-no-cpp-precomp -g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include’
ccversion=‘’, gccversion=‘3.3 20030304 (Apple Computer, Inc. build 1495)’, gccosandvers=‘’
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype=‘long’, ivsize=4, nvtype=‘double’, nvsize=8, Off_t=‘off_t’, lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld=‘env MACOSX_DEPLOYMENT_TARGET=10.3 cc’, ldflags =‘-L/usr/local/lib’
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
gnulibc_version=‘’
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=’ ’
cccdlflags=’ ‘, lddlflags=’-bundle -undefined dynamic_lookup -L/usr/local/lib’

Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
RC3
Built under darwin
Compiled at Sep 12 2003 19:50:49
%ENV:
PERL5LIB=“/sw/lib/perl5:/sw/lib/perl5/darwin”
PERL5_CPANPLUS_CONFIG=“/Users/cdevers/.cpanplus/config”
@INC:
/sw/lib/perl5/5.8.1/darwin-thread-multi-2level
/sw/lib/perl5/5.8.1
/sw/lib/perl5
/sw/lib/perl5/darwin
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
/System/Library/Perl/5.8.1
/Library/Perl/5.8.1/darwin-thread-multi-2level
/Library/Perl/5.8.1
/Library/Perl
/Network/Library/Perl/5.8.1/darwin-thread-multi-2level
/Network/Library/Perl/5.8.1
/Network/Library/Perl
.

It seems like mod_perl is working, at least partially. I have a
collection of Apache::Registry scripts that all seem to work fine, and I
have Apache::MP3 set up and working as well. Additionally, I can invoke
an Apache::Status served URL to browse mod_perl settings, and it doesn’t
seem like it’s choking on anything; in particular, if I browse the
modules that mod_perl can see, there’s a large block of them in the
RT::* namespace coming out of /usr/local/rt3, which is the correct
location of the current RT installation.

Here’s what Apache says about how it was built:

$ httpd -V
Server version: Apache/1.3.33 (Darwin)
Server built: Nov 29 2004 17:59:31
Server’s Module Magic Number: 19990320:16
Server compiled with…
-D EAPI
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_FLOCK_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D DYNAMIC_MODULE_LIMIT=64
-D HARD_SERVER_LIMIT=2048
-D HTTPD_ROOT=“/usr”
-D SUEXEC_BIN=“/usr/sbin/suexec”
-D DEFAULT_PIDLOG=“/var/run/httpd.pid”
-D DEFAULT_SCOREBOARD=“/var/run/httpd.scoreboard”
-D DEFAULT_LOCKFILE=“/var/run/httpd.lock”
-D DEFAULT_ERRORLOG=“/var/log/httpd/error_log”
-D TYPES_CONFIG_FILE=“/etc/httpd/mime.types”
-D SERVER_CONFIG_FILE=“/etc/httpd/httpd.conf”
-D ACCESS_CONFIG_FILE=“/etc/httpd/access.conf”
-D RESOURCE_CONFIG_FILE=“/etc/httpd/srm.conf”
$ httpd -v
Server version: Apache/1.3.33 (Darwin)
Server built: Nov 29 2004 17:59:31
macgarnicle:/etc/httpd root# httpd -l
Compiled-in modules:
http_core.c
mod_so.c
suexec: disabled; invalid wrapper /usr/sbin/suexec
$

The relevant Apache virtual host config is as follows:

<VirtualHost *>
ServerName rt-test-server
ServerAdmin cdevers@rt-test-server
DocumentRoot /usr/local/rt3/share/html
AddDefaultCharset UTF-8
PerlRequire /usr/local/rt3/bin/webmux.pl

SetHandler perl-script
PerlHandler RT::Mason

And for completness, RT’s RT_SiteConfig.pm is as follows:

package RT;
Set($rtname , “rt-test-server”);
Set($Organization , “rt-test-server”);
Set($MinimumPasswordLength , “5”);
Set($Timezone , ‘US/Eastern’);
Set($DatabaseType , ‘mysql’);
Set($DatabaseHost , ‘’);
Set($DatabaseRTHost , ‘’);
Set($DatabasePort , ‘’);
Set($DatabaseUser , ‘rt_user’);
Set($DatabasePassword , ‘serum114’);
Set($DatabaseName , ‘rtnew’);
Set($DatabaseRequireSSL , undef);
Set($OwnerEmail , ‘cdevers’);
Set($LoopsToRTOwner , 1);
Set($StoreLoops , undef);
Set($MaxAttachmentSize , 10000000);
Set($TruncateLongAttachments , undef);
Set($DropLongAttachments , undef);
Set($ParseNewMessageForTicketCcs , undef);
Set($RTAddressRegexp , ‘^rt@rt-test-server$’);
Set($CanonicalizeOnCreate , 0);
Set($SenderMustExistInExternalDatabase , undef);
Set($CorrespondAddress , ‘rt@rt-test-server’);
Set($CommentAddress , ‘rt-comment@rt-test-server’);
Set($MailCommand , ‘sendmailpipe’);
Set($SendmailArguments , “-oi -t”);
Set($SendmailPath , “/usr/sbin/sendmail”);
Set($UseFriendlyFromLine , 1);
Set($FriendlyFromLineFormat , “"%s via RT" <%s>”);
Set($UseFriendlyToLine , 1);
Set($FriendlyToLineFormat, “"%s of $RT::rtname Ticket #%s":;”);
Set($NotifyActor, 0);
Set($RecordOutgoingEmail, 1);
Set($LogToSyslog , ‘debug’);
Set($LogToScreen , ‘error’);
Set($LogToFile , 1);
Set($LogDir , ‘/usr/local/rt3/var/log’);
Set($LogToFileNamed , “rt.log”); #log to rt.log
@LogToSyslogConf = () unless (@LogToSyslogConf);
Set($WebPath , “”);
Set($WebBaseURL , “http://rt-test-server:8080”);
Set($WebURL , $WebBaseURL . $WebPath . “/”);
Set($WebImagesURL , $WebPath . “/NoAuth/images/”);
Set($LogoURL , $WebImagesURL . “rt-dhn-logo.jpg”);
Set($WebNoAuthRegex, qr!^(?:/+NoAuth/|
/+REST/\d+.\d+/NoAuth/)!x );
Set($MessageBoxWidth , 84);
Set($MessageBoxWrap, “HARD”);
Set($TrustHTMLAttachments , undef);
Set($RedistributeAutoGeneratedMessages, 1);
Set($PreferRichText, undef);
Set($WebExternalAuth , undef);
Set($WebFallbackToInternalAuth , undef);
Set($WebExternalGecos , undef);
Set($WebExternalAuto , undef);
Set($WebFlushDbCacheEveryRequest, ‘1’);
Set($MaxInlineBody, 13456);
Set($MyTicketsLength, 10);
Set($MyRequestsLength, 10);
@MasonParameters = () unless (@MasonParameters);
Set ($DefaultSearchResultFormat, qq{
id/title:#’,
Subject/title:Subject’,
Status,
QueueName,
OwnerName,
Priority,
NEWLINE’,
‘’,
Requestors’,
CreatedRelative’,
ToldRelative’,
LastUpdatedRelative’,
TimeLeft’});
@LexiconLanguages = qw(*) unless (@LexiconLanguages);
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless (@EmailInputEncodings);
Set($EmailOutputEncoding , ‘utf-8’);
Set($DateDayBeforeMonth , 1);
Set($AmbiguousDayInPast , 1);
@ActiveStatus = qw(new open stalled) unless @ActiveStatus;
@InactiveStatus = qw(resolved rejected deleted) unless @InactiveStatus;
Set($DevelMode => ‘0’);
1;

I mean, I suppose I could start over with a clean Apache/mod_perl/Perl
build, but that’s a huge project & a pain in the ass when all I want to
do is set up a spare RT instance to test things out without messing up
the real version that we’ve got running on a Debian box at work… :-/

That & it bugs me that I seem to be this close to having it working
but there’s just some little misconfiguration somewhere that’s keeping
it from getting off the ground…

Chris Devers wrote:>On Mon, 7 Mar 2005, Jay R. Ashworth wrote:

On Mon, Mar 07, 2005 at 06:12:04PM -0500, Chris Devers wrote:

On Fri, 4 Mar 2005, Chris Devers wrote:

I’m trying to set up RT 3.4.1 on a Mac, running OSX 10.3.8, and the
built in Perl (5.8.1), Apache (1.3.33), and mod_perl (1.26).

You know, Chris, I had a problem similar to that about 6 months ago,
in my first round of evaluation of ticketing systems, I’d log in, and
get an empty screen.

Okay, but I’m not getting an empty screen though – I get the proper RT
login screen, just the way it looks elsewhere (e.g. the Debian box that
serves it at work, etc), with a banner, a footer, un/pw fields, etc. It
just doesn’t appear to be connected to anything :-/

This is the same symptom I was seeing when I tried to update a 3.2.2
system to 3.4.1. I couldn’t figure it out, the database calls were
working, no errors in rt.log (even with debug set). See the “All
password / username combinations invalid after upgrade…” thread from
last weekend.

Are people running 3.4.1 on apache 1.3 and mod_perl 1.2[69], mysql 4.0.x?

Thanks,
Graham

graham.dunn.vcf (313 Bytes)

I recall a thread a couple months back that implied Apple’s perl
wouldn’t run RT properly. Have you tried removing it and installing
from source?

DB

If Apple’s Perl is 5.8.1 then you are out of luck. RT requires
Perl 5.8.3 or newer.