RT 3.6.3 web interface problems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve just installed 3.6.3, pointed it to a database that was copied from a
3.4.5 instance and run the appropriate upgrade script. On the surface,
things look OK. However, I’ve been noticing some weirdness that is hard
to diagnose, so I’m hoping someone might suggest how I can investigate
this further:

  1. I can login OK and view individual tickets by clicking on them from my
    Home page. But if I enter the ticket number in the little ‘Search’ box at
    the top, I get the following symptoms:

Opera: everything just hangs until I click ‘Stop’ in my browser, at which
point I can resume my session.

Firefox: As soon as I click ‘Search’, I get a Firefox popup saying the
following:

hostname.berkeley.edu has sent an incorrect or unexpected message.
Error Code: -12263

            [ OK ]

where ‘hostname.berkeley.edu’ represents the URL by which I access RT.

Looking at my rt.log and my apache logs, I see nothing that would appear
to correspond to these symptoms. As far as the log files are concerned,
there was no error. Unless the following represents a problem (line
wrapped by me for readability):

127.0.0.1 HTTP/1.0{X-Forwarded-For} - [11/Apr/2007:15:43:36 -0700]
   "GET / HTTP/1.0" 200 2658 "-" "Apache (internal dummy connection)"

I see a few of those at around the time I’m doing the search.

Also, I should say that the database is running on a remote host, to which
I don’t have access. So, I asked my db guy to reproduce the problem and
look at what’s happening in the db, which he did. He saw the following
queries corresponding to the search:

3 Query  SELECT  * FROM Users WHERE Name = 'RT_System'
3 Query  SELECT  * FROM Users WHERE Name = 'Nobody'
3 Query  SELECT  GET_LOCK('Apache-Session-99f30b2b6f94784e6aa196d1d93f050e', 3600)
3 Query  SELECT  a_session FROM sessions WHERE id = '99f30b2b6f94784e6aa196d1d93f050e'
3 Query  SELECT  * FROM Users WHERE id = '2558'
3 Query  SELECT  * FROM Groups WHERE Type = 'Privileged' AND Domain = 'SystemInternal'
3 Query  SELECT  * FROM Principals WHERE PrincipalType = 'User' AND ObjectId = '2558'
3 Query  SELECT  * FROM GroupMembers WHERE GroupId = '4' AND MemberId = '2558'
3 Query  SELECT  RELEASE_LOCK('Apache-Session-99f30b2b6f94784e6aa196d1d93f050e')

(where ‘2558’ is his numeric user ID in RT).

Does this tell you anything?

  1. If I select a ticket by clicking on its number, and it happens to be a
    merged ticket (two other tickets were merged into it), I get a ticket
    display OK, but rt.log shows about a couple of dozen consecutive messages
    like this (line wrapped by me for readability):

[Tue Apr 10 19:45:43 2007] [debug]: We found a merged ticket.558/561
(/users/ist-rt/RT/rt/ist-rt/lib/RT/Ticket_Overlay.pm:271)

all having a timestamp within the same second!

On my other RT systems (3.4.2 and 3.4.5) I don’t see this behavior. Does
this reflect a problem?

  1. In my Opera browser (FreeBSD 5.4), periodically the RT web display
    just hangs, even if I’m not doing a search. And usually I can’t cause
    the hang to stop; I have to kill the browser window. This doesn’t seem
    to occur with Firefox.

Perhaps a couple of suggestions is all I need to pursue these issues
further in a more systematic way. Ideas welcome.

Thanks.

Mike

Mike Friedman Information Services & Technology
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://socrates.berkeley.edu/~mikef http://ist.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRh1zZa0bf1iNr4mCEQI/6ACfWxj7eEddaXiNBE7oujYkFGLthY4AmQG7
q+4RaEClYU+5hgAGRpZwlXZe
=HJ/p
-----END PGP SIGNATURE-----

Looking at my rt.log and my apache logs, I see nothing that would
appear to correspond to these symptoms. As far as the log files
are concerned, there was no error. Unless the following
represents a problem (line
wrapped by me for readability):

127.0.0.1 HTTP/1.0{X-Forwarded-For} - [11/Apr/2007:15:43:36 -0700]
“GET / HTTP/1.0” 200 2658 “-” “Apache (internal dummy
connection)”

That suggests that possibly there’s an httpd.conf misconfig to me,

Anybody else?

PGP.sig (186 Bytes)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Wed, 11 Apr 2007 at 19:49 (-0400), Jesse Vincent wrote:

On Apr 11, 2007, at 7:46 PM, Mike Friedman wrote:

Looking at my rt.log and my apache logs, I see nothing that would
appear to correspond to these symptoms. As far as the log files are
concerned, there was no error. Unless the following represents a
problem (line wrapped by me for readability):

127.0.0.1 HTTP/1.0{X-Forwarded-For} - [11/Apr/2007:15:43:36 -0700]
“GET / HTTP/1.0” 200 2658 “-” “Apache (internal dummy connection)”

That suggests that possibly there’s an httpd.conf misconfig to me,

Jesse,

Do you think the above could be related to the other symptoms I described?

In any case, I should elaborate on my environment. I’m running RT in a
’virtual private server’, behind a proxy web server. What this means
(among other things) is the following:

  1. Everything runs under my (unprivileged) account on the server. This
    means I had to install the RT prereq perl modules in my own home
    directory. (Notice the PERL5LIB definition in my httpd.conf below).

  2. I have my own copy of apache and httpd.conf, but it’s configured for
    virtual hosts at 127.0.0.1 and reserved high-numbered ports. The proxy
    apache, which faces externally, has its own httpd.conf that directs the RT
    URL ‘inward’, to my local virtual host. SSL is done only on the proxy,
    but all the RT-related configs are in my local httpd.conf.

  3. My local httpd.conf contains the following RT-related stuff (RT is
    installed in /users/ist-rt/RT/rt/ist-rt):

    DocumentRoot /users/ist-rt/RT/rt/ist-rt/share/html

    AddDefaultCharset UTF-8

    PerlOptions +Parent
    PerlRequire /users/ist-rt/RT/rt/ist-rt/bin/webmux.pl

    SetHandler perl-script
    PerlHandler RT::Mason

    if images are dynamic, change the Client Caching section above

    Alias /images /users/ist-rt/apache2/https-ist-rt/images

    ScriptAlias /cgi-bin/ “/users/ist-rt/apache2/https-ist-rt/cgi-bin/”
    <Directory “/users/ist-rt/apache2/https-ist-rt/cgi-bin”>
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all

    mod_perl

    SetEnv PERL5LIB /users/ist-rt/lib/perl5:/users/ist-rt/lib/perl5/site_perl:\

/users/ist-rt/lib/perl:/users/ist-rt/lib/perl/5.8.8:/users/ist-rt/share/perl:
/users/ist-rt/share/perl/5.8.8

Is there a problem with the above config? If not, is there something
specific I should be inquiring about concerning the external apache proxy
config (which is maintained by the admins of our ‘webfarm’ environment, so
I can’t look at it myself)?

Or perhaps something in my httpd.conf that’s outside the VirtualHost
config shown above?

Thanks.

Mike

Mike Friedman Information Services & Technology
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://socrates.berkeley.edu/~mikef http://ist.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRh2p260bf1iNr4mCEQLadgCgs8Xr6S0FDgt4sm6kbhslrSUYjgwAoNbv
/XwjCVoR9d8PrhPGL8ZTytX/
=GlBG
-----END PGP SIGNATURE-----

Actually, Apache2 will create those “internal dummy connections” and tell it’s children to gracefully die. I just ran into that issue yesterday when I was processing some web log files on a new server.

The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Stonebridge Bank immediately by replying to this message and deleting it from your computer.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’m still trying to track down the cause of an error that’s generated when
I use the simple search facility, e.g., the ‘Search’ box at the top of my
Home Page.

In Firefox, the message is this (a pop-up):

ist-rt-dev.berkeley.edu has sent an incorrect or unexpected message.
Error Code: -12263

            [ OK ]

(where ‘https://ist-rt-dev.berkeley.edu’ is the URL by which I access RT).

I have noticed something interesting that might relate to this.

The session cookie that RT is issuing to my browser looks like this:

     RT_SID_80

Yet I’m coming in via port 443 and RT should be using $ENV{SERVER_PORT} to
construct the cookie value. Which now causes me to wonder about something
in RT_SiteConfig.pm which didn’t exist in 3.4.5 but appears in 3.6.3.
Namely the $WebPort variable. The comment in RT_SiteConfig.pm says this:

# If we're running as a superuser, run on port 80
# Otherwise, pick a high port for this user.

Now I’m running as a non-privileged user, but I’m on a ‘virtual private
server’ behind an external web server proxy that listens on port 443.
Since RT_SiteConfig constructs $WebURL using $WebPort, I had to get around
this by the following:

  1. I set $WebPort to 443 (not necessarily useful)
  2. I set $WebURL to the actual URL, which is “https://ist-rt-dev.berkeley.edu

I don’t think $WebPort is being used in this case, but I had to set it to
something! Meanwhile, it appears that $ENV{SERVER_PORT} is still
returning ‘80’, because that’s what’s showing up in the cookie value.

So, I’m wondering if this discrepancy (not necessarily the cookie value
itself) is somehow connected to my problem. It’s beginning to look like
under some circumstances, RT is doing internal Redirection improperly,
causing the Firefox message shown above (and causing Opera just to hang
completely).

Any comments on the above? I’m currently supporting two other RT systems
(at 3.4.2 and 3.4.5) and I’ve not had this kind of problem.

Thanks.

Mike

Mike Friedman Information Services & Technology
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://socrates.berkeley.edu/~mikef http://ist.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRh7ouq0bf1iNr4mCEQKf9ACcDg1BSi9ekbQLHcbgoRJmhr43YewAn2U7
NyuzFdvDNZaHEOWbG/nOVr0q
=GoSX
-----END PGP SIGNATURE-----