Hello, we were running RT 2.4 and we decided to upgrade to 3.8. we built a
new server and instead of running it in-house, we moved it into our data
centre.
The we started getting a problem were you would click on a link in RT or
refresh the page and suddenly you would be logged in as somebody else.
I asked about this and was told that it was down to some sort of NAT issue
between here and our DC as we all appeared to be coming from the same IP
address.
After trying and failing to get to the bottom of the NAT issue, we decided
to move the server back in-house. It’s now in the same rack, plugged in to
the same switch as the old server (that NEVER had this issue)
That was two days ago and now we see the problem is still happening.
Hello, we were running RT 2.4 and we decided to upgrade to 3.8. we built a
new server and instead of running it in-house, we moved it into our data
centre.
There was no RT release labeled 2.4, and you should be more specific
about which release of 3.8. 3.8 covers releases of RT over more than
2.5 years.
You haven’t really provided helpful details (such as authorization and
webserver configurations) so any speculating is guesswork.
Usually this involves a proxy server or incorrect caching.
You really need to sort out if there are cookies being passed from
user to user or something else going on.
You’re right, we went from 3.3 to 3.8.7. I think 2.4 was the nagios version I
recently upgraded.
There’s no proxy. I wouldn’t have thought that cookies were being passed
about, the network is identical, it hasn’t changed.
All we’ve changed is the server and version. All this server does is RT
Kevin Falcone-2 wrote:
Hello, we were running RT 2.4 and we decided to upgrade to 3.8. we built
a
new server and instead of running it in-house, we moved it into our data
centre.
There was no RT release labeled 2.4, and you should be more specific
about which release of 3.8. 3.8 covers releases of RT over more than
2.5 years.
You haven’t really provided helpful details (such as authorization and
webserver configurations) so any speculating is guesswork.
Usually this involves a proxy server or incorrect caching.
You really need to sort out if there are cookies being passed from
user to user or something else going on.
-kevin
The we started getting a problem were you would click on a link in RT or
refresh the page and suddenly you would be logged in as somebody else.
I asked about this and was told that it was down to some sort of NAT
issue
between here and our DC as we all appeared to be coming from the same IP
address.
After trying and failing to get to the bottom of the NAT issue, we
decided
to move the server back in-house. It’s now in the same rack, plugged in
to
the same switch as the old server (that NEVER had this issue)
That was two days ago and now we see the problem is still happening.
You’re right, we went from 3.3 to 3.8.7. I think 2.4 was the nagios version I
recently upgraded.
There’s no proxy. I wouldn’t have thought that cookies were being passed
about, the network is identical, it hasn’t changed.
All we’ve changed is the server and version. All this server does is RT
Kevin Falcone-2 wrote:
Hello, we were running RT 2.4 and we decided to upgrade to 3.8. we built
a
new server and instead of running it in-house, we moved it into our data
centre.
There was no RT release labeled 2.4, and you should be more specific
about which release of 3.8. 3.8 covers releases of RT over more than
2.5 years.
You haven’t really provided helpful details (such as authorization and
webserver configurations) so any speculating is guesswork.
Usually this involves a proxy server or incorrect caching.
You really need to sort out if there are cookies being passed from
user to user or something else going on.
-kevin
The we started getting a problem were you would click on a link in RT or
refresh the page and suddenly you would be logged in as somebody else.
I asked about this and was told that it was down to some sort of NAT
issue
between here and our DC as we all appeared to be coming from the same IP
address.
After trying and failing to get to the bottom of the NAT issue, we
decided
to move the server back in-house. It’s now in the same rack, plugged in
to
the same switch as the old server (that NEVER had this issue)
That was two days ago and now we see the problem is still happening.
Well we upgraded from debian sarge to debian lenny so that included an apache
upgrade. I don’t see mod_cache enabled on the new or the old server, do you
think that would help?
Jeff Voskamp wrote:
You’re right, we went from 3.3 to 3.8.7. I think 2.4 was the nagios
version I
recently upgraded.
There’s no proxy. I wouldn’t have thought that cookies were being passed
about, the network is identical, it hasn’t changed.
All we’ve changed is the server and version. All this server does is RT
Kevin Falcone-2 wrote:
Hello, we were running RT 2.4 and we decided to upgrade to 3.8. we
built
a
new server and instead of running it in-house, we moved it into our
data
centre.
There was no RT release labeled 2.4, and you should be more specific
about which release of 3.8. 3.8 covers releases of RT over more than
2.5 years.
You haven’t really provided helpful details (such as authorization and
webserver configurations) so any speculating is guesswork.
Usually this involves a proxy server or incorrect caching.
You really need to sort out if there are cookies being passed from
user to user or something else going on.
-kevin
The we started getting a problem were you would click on a link in RT
or
refresh the page and suddenly you would be logged in as somebody else.
I asked about this and was told that it was down to some sort of NAT
issue
between here and our DC as we all appeared to be coming from the same
IP
address.
After trying and failing to get to the bottom of the NAT issue, we
decided
to move the server back in-house. It’s now in the same rack, plugged in
to
the same switch as the old server (that NEVER had this issue)
That was two days ago and now we see the problem is still happening.
Well we upgraded from debian sarge to debian lenny so that included an apache
upgrade. I don’t see mod_cache enabled on the new or the old server, do you
think that would help?
I thought I recalled issues with mod_cache in apache and mixed sessions.
I don’t recall if you mentioned any apache changes at the same time.
Thank you for that, it’s very interesting. what’s most interesting is that
when I brought this up in january I was laughed at like an idiot for
suggesting that the problem might possibly be something other than a faulty
proxy server or caching router, but I digress.
It turns out that mod_cache is actually enabled, I’ve been trying to disable
it without breaking apache but no joy so far. I’ve done an apt-get apache
upgrade to see if that’ll help.
Am I being daft because I don’t actually see a solution in that thread?
There’s a patch but the responder says it doesn’t work.
Jeff Voskamp wrote:
Well we upgraded from debian sarge to debian lenny so that included an
apache
upgrade. I don’t see mod_cache enabled on the new or the old server, do
you
think that would help?
I thought I recalled issues with mod_cache in apache and mixed sessions.
I don’t recall if you mentioned any apache changes at the same time.
Thank you for that, it’s very interesting. what’s most interesting is
that
when I brought this up in january I was laughed at like an idiot for
suggesting that the problem might possibly be something other than a
faulty
proxy server or caching router, but I digress.
It turns out that mod_cache is actually enabled, I’ve been trying to
disable
it without breaking apache but no joy so far. I’ve done an apt-get
apache
upgrade to see if that’ll help.
Am I being daft because I don’t actually see a solution in that thread?
There’s a patch but the responder says it doesn’t work.
If you end up needing to build your apache from source, I think the ./configure option is --disable-module=cache
Josh Narins
Director of Application Development
SeniorBridge
845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Mobile: (917) 488-6248
Fax: (212) 994-4260 jnarins@seniorbridge.com
SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.
Am I being daft because I don’t actually see a solution in that thread?
There’s a patch but the responder says it doesn’t work.
I think the solution was disabling mod_cache
If there is documentation on what we can set to tell mod_cache not to
cache headers, RT can be patched to use it. At this point, I don’t
think we’ve found the appropriate documentation.