I have a fresh Debian server that I’m using to try out 4.0.0rc1. Installation of RT and all its dependencies went perfectly and the system runs fine with RT_SiteConfig.pm containing:
rt4:/usr/src/rt-4.0.0rc1# cat /usr/local/rt3pims/etc/RT_SiteConfig.pm
2.
Set( $rtname, ‘pims.scrd.ad’);
4.
Set( $WebDomain, ‘rt4.scrd.ad’ );
5.
Set( $WebPath, ‘/’);
6.
Set($RTAddressRegexp , undef);
8.
Set($LogToFile, debug);
9.
Set($LogDir, ‘/var/log’);
10.
Set($LogToFileNamed , “rt.log”); #log to rt.log
11.
Set($LogStackTraces, ‘debug’);
12.
Set($StatementLog, ‘debug’);
13.
Set( %GnuPG,
14.
Enable => 0
15.
);
16.
1;
… and Apache2 config consisting of:
FastCgiServer /usr/local/rt3pims/sbin/rt-server.fcgi -processes 1 -idle-timeout 180 -initial-env RT_SITE_CONFIG=/usr/local/rt3pims/etc/RT_SiteConfig.pm -initial-env RT_TESTING=1
2.
<VirtualHost *>
4.
ServerName rt4.scrd.ad
5.
-
AddHandler fastcgi-script fcgi
-
Alias /NoAuth/images/ /usr/local/rt3pims/share/html/NoAuth/images/
-
ScriptAlias / /usr/local/rt3pims/sbin/rt-server.fcgi/
ErrorLog /var/log/apache2/rt3.scrd.ad-error_log
CustomLog /var/log/apache2/rt3.scrd.ad-access_log common
LogLevel debug
#### Present the PIMS instance of RT-4.0
<Directory />
- Options FollowSymLinks
- AllowOverride None
- Order deny,allow
- Deny from all
</Directory>
<Location />
- Order allow,deny
- Allow from all
- Options +ExecCGI
- AddHandler fastcgi-script fcgi
</Location>
I wanted to move the deployment to a non-root url on the server so I could deploy a second independent installation. I updated the RT_SiteConfig.pm thus:
5.
Set( $WebPath, ‘/pims’);
… and the Apache2 config like so:
7. Alias /pims/NoAuth/images/ /usr/local/rt3pims/share/html/NoAuth/images/
9. ScriptAlias /pims/ /usr/local/rt3pims/sbin/rt-server.fcgi/
-
<Directory /pims/>
-
<Location /pims/>
Then I restart apache, access the new URL with a browser and end up with a 302 redirect loop. The Apache logs look like:
172.16.10.237 - - [31/Dec/2010:14:00:36 -0800] “GET /pims/ HTTP/1.1” 302 -
172.16.10.237 - - [31/Dec/2010:14:00:36 -0800] “GET /pims/NoAuth/Login.html?next=f9c12b9fd7e33e6ee67e6bcabb2f09cb HTTP/1.1” 302 -
172.16.10.237 - - [31/Dec/2010:14:00:36 -0800] “GET /pims/NoAuth/Login.html?next=a75be78b22669054348472195b0d33a0 HTTP/1.1” 302 -
172.16.10.237 - - [31/Dec/2010:14:00:36 -0800] “GET /pims/NoAuth/Login.html?next=71f08594c78432e6afebb9152a134754 HTTP/1.1” 302 -
172.16.10.237 - - [31/Dec/2010:14:00:36 -0800] “GET /pims/NoAuth/Login.html?next=d351697bdfe2537031dc5b66b76b6e72 HTTP/1.1” 302 -
… and so on, with different IDs, for ~20 attempts before the browser trips up.
When RT is configured for the root URL and functioning correctly there are no redirects logged. The contents of access_log are:
172.16.10.237 - - [31/Dec/2010:13:03:03 -0800] “GET / HTTP/1.1” 200 3741
172.16.10.237 - - [31/Dec/2010:13:03:08 -0800] “GET /NoAuth/images/bpslogo.png HTTP/1.1” 304 -
172.16.10.237 - - [31/Dec/2010:13:03:08 -0800] “GET /NoAuth/images/jquery_ui/ui-bg_flat_75_ffffff_40x100.png HTTP/1.1” 304 -
172.16.10.237 - - [31/Dec/2010:13:03:08 -0800] “GET /NoAuth/images/favicon.png HTTP/1.1” 304 -
If I log all the sql statements going through mysql I can see an entry occuring in the sessions table when I try to connect, but the contents of the update seems a little off:
29 Query SELECT GET_LOCK(‘Apache-Session-d87debed610bbaa41cbaef2abc11221d’, 3600)
29 Query SELECT a_session FROM sessions WHERE id = ‘d87debed610bbaa41cbaef2abc11221d’
29 Query UPDATE sessions SET a_session = '\0\0\0\n d87debed610bbaa41cbaef2abc11221d\0\0\0_session_id\0\0\0\0\0\0\0Actions\0\0\0Ó\n=/pims/NoAuth/Login.html?next=334bcab84eeac77e7bfa34ab3c1b663b\0\0\0 51440de7564b1886734e355b8422fee0\n=/pims/NoAuth/Login.html?next=843a993962972ba5f04205635d677fdd\0\0\0 7f1d40b6cdcb5a3927441b15d41a0f06\n=/pims/NoAuth/Login.html?next=0b09ea3301e5021680662f434dfd819a\0\0\0 3c7a25efe3389ef7df5c9ed21abfa5ef\n=/pims/NoAuth/Login.html?next=3bba9f13cbf6bfb42406e80e40b3f894\0\0\0 c36f96c58a0b92e1d1e9100bd537ce83\n
… and it carries on with the ID from every URL called during the successive redirects.
I’ve tried completely wiping the installation and re-initing the database, no change. I’ve turned on all the debug I can find, nothing obvious appears. I’ve tried moving the Apache configuration out of a virtualhost and onto the default server, no change. I’ve deleted the contents of the Mason object cache, cleared cookies on the browser, tried a different browser (IE instead of Chrome), deleted the contents of the sessions table, verified DNS config (including the contents of hosts file on the server), still no change.
I can’t find anything on the lists regarding this behaviour. Any suggestions?
Thanks
Kris Boutilier