RT 3.6 requires two or three logins with firefox and IE

RT Users
1

Bizarre problem I could not spot with Google which leads me to
believe I’m doing something very wrong.

I have perl-5.8.8, apache 2.6, mp 2.0.3 and RT 3.6.5
under Solaris 10 and Oracle 10.

With firefox2 and IE, I am prompted to authenticate two or three
times before I can navigate RT pages without prompting.

However, with lynx and opera I only need to authenticate once.

I have turned on logging and don’t see anything interesting.

I see RT’s cookie in firefox’s cookie manager.

Any thoughts on how I can debug further?

John
groenveld@acm.org

2

Bizarre problem I could not spot with Google which leads me to
believe I’m doing something very wrong.

I have perl-5.8.8, apache 2.6, mp 2.0.3 and RT 3.6.5
under Solaris 10 and Oracle 10.

With firefox2 and IE, I am prompted to authenticate two or three
times before I can navigate RT pages without prompting.

It’s almost certainly the case that you have multiple valid DNS domain
names for your RT server. And RT’s cookies are tied to a specific
domain.

Something like this:
http://rt/
http://rt.mycompany.com/
http://rt3.mycompany.com/
http://www.rt.mycompany.com/

If you start at one and RT canonicalizes it to another, you might be
fored to reauth.

3

In message 20071206203102.GH30165@bestpractical.com, Jesse Vincent writes:

It’s almost certainly the case that you have multiple valid DNS domain
names for your RT server. And RT’s cookies are tied to a specific
domain.

Something like this:
http://rt/
http://rt.mycompany.com/
http://rt3.mycompany.com/
http://www.rt.mycompany.com/

If you start at one and RT canonicalizes it to another, you might be
fored to reauth.

The test host only has one valid DNS name.

Currently testing from the coffee shop and I’m tunneling via ssh.

/opt/rt3/etc/RT_SiteConfig.pm has this
Set( $rtname, ‘test.example.com’);
Set( $Organization, ‘RT Rocks’);
Set( $WebBaseURL, ‘http://test.example.com:8082’);

Oddly, sometimes I can connect localhost:8082 with Firefox without
being prompted multiple times and sometimes it takes three times.

Opera nor lynx ever have this problem.

Weird.
John
groenveld@acm.org

4

Oddly, sometimes I can connect localhost:8082 with Firefox without
being prompted multiple times and sometimes it takes three times.

Opera nor lynx ever have this problem.

I’ve had all sorts of problems with Firefox and cookies on localhost,
both with RT and with other apps.

Bes,t
Jesse

5

In message 200712062003.lB6K3QCj009112@stevens.arl.psu.edu, John D Groenveld
writes:

I have perl-5.8.8, apache 2.6, mp 2.0.3 and RT 3.6.5
under Solaris 10 and Oracle 10.

With firefox2 and IE, I am prompted to authenticate two or three
times before I can navigate RT pages without prompting.

However, with lynx and opera I only need to authenticate once.

I have turned on logging and don’t see anything interesting.

I see RT’s cookie in firefox’s cookie manager.

Any thoughts on how I can debug further?

I installed fresh on a development box and I saw the exception
below on the mainpage with Firefox where the RefreshHomepage
element should be.

On my production box, my perl has Apache::Session 1.81_01

On my devel box, my perl has 1.84 which includes error
handling.

After re-logging in two or three times, the exception goes away.

With Opera I can’t produce this exception.

I also cannot produce the exception when I run the devel Apache httpd
with -X.

My WAG is that Firefox and IE are doing parallel requests
and triggering an Apache::Session::lock::File deadlock which is
somehow forcing the session to be invalidated.

Most RT users probably use MySQL and Postgres and RT defaults
to using those databases for session management so won’t stumble
across this bug.

John
groenveld@acm.org

Trace begun at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Exceptions.pm line 129
HTML::Mason::Exceptions::rethrow_exception(‘Cannot lock: Deadlock situation detected/avoided at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/Apache/Session/Lock/File.pm line 81, line 3.^J’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/Apache/Session/Lock/File.pm line 81
Apache::Session::lock::File::acquire_write_lock(‘Apache::Session::lock::File=HASH(0x3a18380)’, ‘Apache::Session::File=HASH(0x39f4cb0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/Apache/Session.pm line 588
Apache::Session::acquire_write_lock(‘Apache::Session::File=HASH(0x39f4cb0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/Apache/Session.pm line 516
Apache::Session::save(‘Apache::Session::File=HASH(0x39f4cb0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/Apache/Session/File.pm line 40
Apache::Session::File::DESTROY(‘Apache::Session::File=HASH(0x39f4cb0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Request.pm line 1252
eval {…} at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Request.pm line 1252
HTML::Mason::Request::comp(undef, undef, undef, ‘pass’, ‘RTrocks’, ‘user’, ‘john’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Request.pm line 466
eval {…} at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Request.pm line 466
eval {…} at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/Request.pm line 418
HTML::Mason::Request::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x3abb8a0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/ApacheHandler.pm line 168
HTML::Mason::Request::ApacheHandler::exec(‘HTML::Mason::Request::ApacheHandler=HASH(0x3abb8a0)’) called at /opt/rt3/perl-5.8.8/lib/site_perl/5.8.8/HTML/Mason/ApacheHandler.pm line 826
HTML::Mason::ApacheHandler::handle_request(‘HTML::Mason::ApacheHandler=HASH(0x15ca300)’, ‘Apache2::RequestRec=SCALAR(0x37f27d0)’) called at /opt/rt3/bin/webmux.pl line 125
eval {…} at /opt/rt3/bin/webmux.pl line 125
RT::Mason::handler(‘Apache2::RequestRec=SCALAR(0x37f27d0)’) called at -e line 0
eval {…} at -e line 0

6

In message 200712102035.lBAKZhFX004090@stevens.arl.psu.edu, John D Groenveld
writes:

My WAG is that Firefox and IE are doing parallel requests
and triggering an Apache::Session::lock::File deadlock which is
somehow forcing the session to be invalidated.

Most RT users probably use MySQL and Postgres and RT defaults
to using those databases for session management so won’t stumble
across this bug.

I copied my data from Oracle to Postgres.

Then I disabled Apache::Session::Postgres in
/opt/rt3/share/html/Elements/SetupSessionCookie

As expected, I got the deadlock error and was forced to reauthenticate.

Need to do more debugging to see whether there are indeed
parallel requests.

John
groenveld@acm.org

7

To All,

I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+ and have

managed to get session control to work properly with FireFox or IE using
either the DB sessions table OR SPECIFICALLY straight to data file. We
are going straight to data file, have made sure our URL’s are correct,
use LDAP and still no joy. I can’t believe that this problem could be
ongoing in a production ORACLE environment. This problem is keeping me
from putting 3.6.4 into production. Please Help!

Kenn
LBNLOn 12/12/2007 6:37 PM, John D Groenveld wrote:

In message 200712102035.lBAKZhFX004090@stevens.arl.psu.edu, John D Groenveld
writes:

My WAG is that Firefox and IE are doing parallel requests
and triggering an Apache::Session::lock::File deadlock which is
somehow forcing the session to be invalidated.

Most RT users probably use MySQL and Postgres and RT defaults
to using those databases for session management so won’t stumble
across this bug.

I copied my data from Oracle to Postgres.

Then I disabled Apache::Session::Postgres in
/opt/rt3/share/html/Elements/SetupSessionCookie

As expected, I got the deadlock error and was forced to reauthenticate.

Need to do more debugging to see whether there are indeed
parallel requests.

John
groenveld@acm.org

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll take
up to 20 percent off the price. This sale won’t last long, so get in touch today.
Email us at sales@bestpractical.com or call us at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

8

In message 4761A949.8000803@lbl.gov, Kenneth Crocker writes:

I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+ and have

managed to get session control to work properly with FireFox or IE using
either the DB sessions table OR SPECIFICALLY straight to data file. We

Apache timed out for me when I tried to enable Apache::Session::Oracle
in /opt/rt3/share/html/Elements/SetupSessionCookie.

John
groenveld@acm.org

9

John,

So, what did you do? I assume you went to filesystems-session. Do you

still have a dbl-login problem? Were you able to get around it? I’ve
been ready to install 3.6.4 for quite awhile, but I am loathe to put
anything into production that has an inherent bug as bothersome as this one.

Kenn
LBNLOn 12/13/2007 2:37 PM, John D Groenveld wrote:

In message 4761A949.8000803@lbl.gov, Kenneth Crocker writes:

I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+ and have

managed to get session control to work properly with FireFox or IE using
either the DB sessions table OR SPECIFICALLY straight to data file. We

Apache timed out for me when I tried to enable Apache::Session::Oracle
in /opt/rt3/share/html/Elements/SetupSessionCookie.

John
groenveld@acm.org

10

Kenneth Crocker wrote:

To All,

I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+ and

have managed to get session control to work properly with FireFox or
IE using either the DB sessions table OR SPECIFICALLY straight to data
file. We are going straight to data file, have made sure our URL’s are
correct, use LDAP and still no joy. I can’t believe that this problem
could be ongoing in a production ORACLE environment. This problem is
keeping me from putting 3.6.4 into production. Please Help!
I have, sometimes, the same problem. We are using RT 3.6.5 and Oracle XE
(10g) with session files on disk and FireFox 2.0.11.
To add to the confusing I also plan on using Prism, formerly known as
WebRunner, which uses also the gecko engine and there I don’t seem to
have the problem. Keep in mind thats used so little that it hasn’t shown
itself.
I tried session data in the db but got stuck with locks. I use an
extension with Firefox called FasterFox and that might be responsible
for the session data not catching on because of multiple downloads from
the server.
Did you check the Changelog? because I think there is (are) some fix(es)
in 3.6.5 for this, but I’m not sure could be that they are already in
3.6.4 (Ruslan, Vincent??).

Joop

11

Jesse,

It seems to me that there are some few RT users that have gone to the

file-session method due to some problems with the session table in the
DB, especially in ORACLE. Are there now some fixes we can download that
will allow us to drop the file-session methodology and go back to using
the ORACLE DB? If not, has anyone at BestPractical seen some consistent
set of circumstances (and appropriate fixes) that would lead us to a
resolution to the file-session problems we’re all having with FireFox
and IE? I sure hope so. I’ve been ready to put 3.6.4 into production for
well over a month and still can’t get this bug fixed in order to do so.
Some help, please. Thanks.

Kenn
LBNLOn 12/14/2007 5:17 AM, Jason A. Diegmueller wrote:

Kenn–

My experience is:

  • If I delete all cookies from browser and “rm” the session_data
    directory on the server, the next login will be double.
  • After that, if I quit my browser and go back in, I only get a
    single-login (like expected)
  • If I only delete the session directory (but not the cookies), I only
    get a single-login
  • If I only delete the browser cookies (but not the server-side
    session_data directory), I only get a single login
  • The ony time I get double-login is “in the morning” (which probably
    more specifically is “after $x hours inactivity” but I don’t know what
    that number is)

To be specific about “double-login”, I:

  • Browse to my RT
  • I’m asked to login, and do so
  • I am presented with the "RT at a glance page
  • I click something, anything
  • I am asked to login again, and so so
  • Then I’m good to go

Unfortunately I’m not a developer, so I lack the cognitive capacity to
actually fix this. I’m decent at troubleshooting and isolating
problems, but I can’t even write “Hello, world!” in Perl so all I can do
is report this to BPS (like I have) and hope they fix it. At this point
in time, we’ve chosen to live with the problem.

Of note, I didn’t have this same problem until I migrated to the FreeBSD
box. I was previously on a Linux server, perl 5.8.8, MySQL 5.0.x.
Maybe a version of Apache::Session? Or something similar?

-jd

On Thu, 13 Dec 2007, Kenneth Crocker wrote:

Jason,

Thanks for replying. We want to use the filesystem-based session

method as well. We just can’t seem to get past that initial dbl-login
problem. As with you, it only happens the first time the session is
invoked. Once we stay in RT after the initial dbl-login, we do not see
that problem again, FOR THAT SESSION. So, do you still have that
dbl-login or have you come up with a way around it? I’ve QA tested
every functionality that exists in 3.6.4 a zillion times and it is
REALLY REALLY ready to put in and ALL my clients are waiting with
GREAT anticipation for the new version. However, I am loathe to put
anything into production that has an inherent bug. Got any suggestions?

Kenn
LBNL

On 12/13/2007 2:19 PM, Jason A. Diegmueller wrote:

[sent directly instead of on-list]

Kenn–

I run RT 3.6.5 on FreeBSD 6.2, MySQL 5.0.45a, and use
filesystem-based Sessions. I experience double-logins (not triple),
and usually it’s only the first login of that day that is double.
Happens with IE or Firefox as well.

I mentioned something to Jesse @ BPS and he believed there to be a
“locking issue” and acknowledged it sounded like a bug. When using
MySQL to store Sessions, I don’t have the problem – but we prefer
filesystem-based Sessions because it allows parallelization of RT, in
that you can have activity in multiple tabs. When using MySQL, I
don’t get the double-login but only one tab can be actively
loading/updating/whatever at a time.

-jd

On Thu, 13 Dec 2007, Kenneth Crocker wrote:

To All,

I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+

and have managed to get session control to work properly with
FireFox or IE using either the DB sessions table OR SPECIFICALLY
straight to data file. We are going straight to data file, have made
sure our URL’s are correct, use LDAP and still no joy. I can’t
believe that this problem could be ongoing in a production ORACLE
environment. This problem is keeping me from putting 3.6.4 into
production. Please Help!

Kenn
LBNL

On 12/12/2007 6:37 PM, John D Groenveld wrote:

In message 200712102035.lBAKZhFX004090@stevens.arl.psu.edu, John
D Groenveld writes:

My WAG is that Firefox and IE are doing parallel requests
and triggering an Apache::Session::lock::File deadlock which is
somehow forcing the session to be invalidated.

Most RT users probably use MySQL and Postgres and RT defaults
to using those databases for session management so won’t stumble
across this bug.

I copied my data from Oracle to Postgres.

Then I disabled Apache::Session::Postgres in
/opt/rt3/share/html/Elements/SetupSessionCookie

As expected, I got the deadlock error and was forced to
reauthenticate.

Need to do more debugging to see whether there are indeed
parallel requests.

John
groenveld@acm.org

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31,
we’ll take
up to 20 percent off the price. This sale won’t last long, so get
in touch today. Email us at sales@bestpractical.com or call us
at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly
Media. Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31,
we’ll take
up to 20 percent off the price. This sale won’t last long, so get in
touch today. Email us at sales@bestpractical.com or call us at +1
617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

12

Jesse,

It seems to me that there are some few RT users that have gone to
the file-session method due to some problems with the session table in the
DB, especially in ORACLE. Are there now some fixes we can download that
will allow us to drop the file-session methodology and go back to using
the ORACLE DB? If not, has anyone at BestPractical seen some consistent
set of circumstances (and appropriate fixes) that would lead us to a
resolution to the file-session problems we’re all having with FireFox
and IE? I sure hope so. I’ve been ready to put 3.6.4 into production for
well over a month and still can’t get this bug fixed in order to do so.
Some help, please. Thanks.

Sorry, nope. The long term fix is to replace Apache::Session with
something we have more control over. You can also likely limit the
damage it does by making sure your CSS, js and Image requeusts go
directly through apache with “Alias” lines, rather than through RT.

-jesse

13

Hi RT Users, Jesse,

Today i started to use /Tools/MyDay.html and realized this is not
working. I get all my Tickets displayed, i can change status etc but
after submit nothing happens…?!?

I searched the logs and i found nothing.

So my questions, is this still buggy or forgotten or do i something
wrong?

Thanks

Torsten

14

Hi, Jesse,2007/12/26, Jesse Vincent jesse@bestpractical.com:

On Fri, Dec 14, 2007 at 02:47:08PM -0800, Kenneth Crocker wrote:

If not, has anyone at BestPractical seen some consistent
set of circumstances (and appropriate fixes) that would lead us to a
resolution to the file-session problems we’re all having with FireFox
and IE? I sure hope so. I’ve been ready to put 3.6.4 into production for
well over a month and still can’t get this bug fixed in order to do so.

Sorry, nope. The long term fix is to replace Apache::Session with
something we have more control over.

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

P.S. If it will not help, another solution is to fix Apache::Session.

Alexandr Ciornii, http://chorny.net

SetupSessionCookie.patch (330 Bytes)

15

At Sunday 12/30/2007 08:26 PM, Alexandr Ciornii wrote:

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

P.S. If it will not help, another solution is to fix Apache::Session.

–
Alexandr Ciornii, http://chorny.net

Well I’m amazed - we’ve had this problem for years (3.4.2 and older)
and I’ve seen no solutions posted until now. But this patch seems to
solve the problem. Thanks Alexandr - what exactly does the
Transaction arg do to solve this?

Thanks,
Steve

16

Alexandr,

I agree with Stephen. How did you come across this as the answer or

what led you to look at this as a possible answer? I’m passing this off
to our techy specialists. THANKS!!!

Kenn
LBNLOn 1/2/2008 1:38 PM, Stephen Turner wrote:

At Sunday 12/30/2007 08:26 PM, Alexandr Ciornii wrote:

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

P.S. If it will not help, another solution is to fix Apache::Session.

–
Alexandr Ciornii, http://chorny.net

Well I’m amazed - we’ve had this problem for years (3.4.2 and older) and
I’ve seen no solutions posted until now. But this patch seems to solve
the problem. Thanks Alexandr - what exactly does the Transaction arg do
to solve this?

Thanks,
Steve

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll take
up to 20 percent off the price. This sale won’t last long, so get in
touch today. Email us at sales@bestpractical.com or call us at +1 617
812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy
a copy at http://rtbook.bestpractical.com

17

Alexandr Ciornii wrote:

Hi, Jesse,

If not, has anyone at BestPractical seen some consistent
set of circumstances (and appropriate fixes) that would lead us to a
resolution to the file-session problems we’re all having with FireFox
and IE? I sure hope so. I’ve been ready to put 3.6.4 into production for
well over a month and still can’t get this bug fixed in order to do so.

Sorry, nope. The long term fix is to replace Apache::Session with
something we have more control over.

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

Very cool. It sounds like folks using file-locking are definitely
winning with this. I suspect it got skipped at the time sessions were
implemented because: (From the doc)

18

Hello.

    I agree with Stephen. How did you come across this as the answer or

what led you to look at this as a possible answer?

Considering that currently I’m the Apache::Session maintainer… :slight_smile:

Apache::Session from 1.83 checks file lock failures, so I saw that
someone posted error logs here.> On 1/2/2008 1:38 PM, Stephen Turner wrote:

At Sunday 12/30/2007 08:26 PM, Alexandr Ciornii wrote:

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

Well I’m amazed - we’ve had this problem for years (3.4.2 and older) and
I’ve seen no solutions posted until now. But this patch seems to solve
the problem. Thanks Alexandr - what exactly does the Transaction arg do
to solve this?

By default Apache::Session does read lock and escalates to write lock
when necessary. ‘Transaction’ does write lock at session start. This
has disadvantages, it will require other processes to wait before this
process will finish. Ideally, ‘Transaction’ should be only for
processes that will modify session data.

Alexandr Ciornii, http://chorny.net

19

As I’m about to apply this patch, I have one question. Will the patch
be implemented in the next release of RT? I’m on 3.6.4 with no plans of
upgrading in the near future, so basically, what I’m asking is, should I
move the SetupSessionCookie file to my local directory, or just apply it
to the version in the shared folder? I don’t want to only apply it in
the shared folder, forget about it, only to have that issue come up the
next time I upgrade.

Thanks,

Craig

[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Alexandr
CiorniiSent: Thursday, January 03, 2008 9:58 AM
To: Kenneth Crocker
Cc: rt Users
Subject: Re: [rt-users] RT 3.6 requires two or three logins with firefox
and IE

Hello.

    I agree with Stephen. How did you come across this as the

answer or

what led you to look at this as a possible answer?

Considering that currently I’m the Apache::Session maintainer… :slight_smile:

Apache::Session from 1.83 checks file lock failures, so I saw that
someone posted error logs here.

At Sunday 12/30/2007 08:26 PM, Alexandr Ciornii wrote:

Did you tried adding ‘Transaction’ argument when creating session?
Patch is attached.

Well I’m amazed - we’ve had this problem for years (3.4.2 and older)
and
I’ve seen no solutions posted until now. But this patch seems to
solve
the problem. Thanks Alexandr - what exactly does the Transaction arg
do
to solve this?

By default Apache::Session does read lock and escalates to write lock
when necessary. ‘Transaction’ does write lock at session start. This
has disadvantages, it will require other processes to wait before this
process will finish. Ideally, ‘Transaction’ should be only for
processes that will modify session data.

Alexandr Ciornii, http://chorny.net
The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll
take
up to 20 percent off the price. This sale won’t last long, so get in
touch today.
Email us at sales@bestpractical.com or call us at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

20

At Thursday 1/3/2008 10:08 AM, Patterson, Craig wrote:

As I’m about to apply this patch, I have one question. Will the patch
be implemented in the next release of RT? I’m on 3.6.4 with no plans of
upgrading in the near future, so basically, what I’m asking is, should I
move the SetupSessionCookie file to my local directory, or just apply it
to the version in the shared folder? I don’t want to only apply it in
the shared folder, forget about it, only to have that issue come up the
next time I upgrade.

Thanks,

Craig

Craig,

You should definitely make a local copy and modify that. You’ll still
possibly have to re-apply the change when you upgrade, if it hasn’t
made it to the official release.

Good luck,
Steve