RT 2.0.13 upgrade on Redhat 7.2

RT Users
1

Hi,

Has anybody managed to get RT working on a Redhat 7.2 install?

Had 2.0.4 working like a charm for a while, then upgraded Redhat
to 7.2. No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No
messages in any of the logs (rt, Apache, or the system log).

make testdeps is happy, and I have as well upgraded manually all
required packages by hand.

Any ideas? Bit lost at what to do, with no errors to follow anywhere!

Thanks
Yan
Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

2

Hi,

Hello,

Has anybody managed to get RT working on a Redhat 7.2 install?

Yes, I tested this with success.

Had 2.0.4 working like a charm for a while, then upgraded Redhat
to 7.2. No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No
messages in any of the logs (rt, Apache, or the system log).

I had exactly the same problem. Solution :

compiling mod_perl into apache sources solved it (as mentioned
in the FAQ too) solved my problems and since then it works great.

make testdeps is happy, and I have as well upgraded manually all
required packages by hand.

Any ideas? Bit lost at what to do, with no errors to follow anywhere!

I hope this helps you

Thanks
Yan

friendly regards,

Frank Reppin

Heidestr. 15
39112 Magdeburg
Germany

3

Thanks Paul,

I’ve now fixed it by compiling Apache manually (as opposed to the
RH rpms) and built mod_perl within Apache (as recommended in
the FAQ …).

I’m now off to figure out how to enable SSL in all this.

Good luck with your,

Yan---- On 28 Mar 2002, at 15:05, Paul.Taylor@equifax.com wrote: ----

Yan,

Going through the same ‘pain’ myself at the moment but
with 2.0.12. Now I’ve just read the security alert it will be 2.0.13.
I’ll drop a note to the list once I get it resolved.

My current issue is that mod_perl seems to be compiled up with
perl 5.6.0, but make fixdeps upgraded perl to 5.6.1.

The strategy I was about to pursue was to subscribe to the RedHat
Network, get RH7.2 upgraded (hopefully including perl / Apache) and
progress from there.

Regards

Paul Taylor
Technical Consultant
Equifax

paul.taylor@equifax.com

==================

Message: 11
From: “Yan Fitterer” y.fitterer@ram.ac.uk
Organization: Royal Academy of Music
To: rt-users@lists.fsck.com
Date: Thu, 28 Mar 2002 12:51:35 -0000
Subject: [rt-users] RT 2.0.13 upgrade on Redhat 7.2

Hi,

Has anybody managed to get RT working on a Redhat 7.2 install?

Had 2.0.4 working like a charm for a while, then upgraded Redhat
to 7.2. No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No
messages in any of the logs (rt, Apache, or the system log).

make testdeps is happy, and I have as well upgraded manually all
required packages by hand.

Any ideas? Bit lost at what to do, with no errors to follow anywhere!

Thanks
Yan

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

Protect yourself against identity theft with Equifax Credit Watch.
Visit http://www.creditalert.equifax.com.

This message contains information from Equifax Inc. which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of
this information and note that such actions are prohibited. If you
have received this transmission in error, please notify by e-mail
postmaster@equifax.com.

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

4

Thanks Paul,

I’ve now fixed it by compiling Apache manually (as opposed to the
RH rpms) and built mod_perl within Apache (as recommended in
the FAQ …).

FWIW, it works fine for me on RH 7.2 with the default Red Hat apache &
mod_perl packages. The only thing I needed to compile was RT itself.

Then again, my installation wasn’t an upgrade - this particular machine
started its current incarnation as a Red Hat 7.2 box.

Graham Freeman Executive Director, CalTEG
tel: +1 831 466 0853 http://www.calteg.org/

5

Frank Reppin wrote:> On Thu, 28 Mar 2002, Yan Fitterer wrote:

Hi,

Hello,

Has anybody managed to get RT working on a Redhat 7.2 install?

Yes, I tested this with success.

Had 2.0.4 working like a charm for a while, then upgraded Redhat
to 7.2. No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No
messages in any of the logs (rt, Apache, or the system log).

I had exactly the same problem. Solution :

compiling mod_perl into apache sources solved it (as mentioned
in the FAQ too) solved my problems and since then it works great.

Another fix should be to upgrade to perl-5.6.1 and the according
mod_perl and apache packages. updates are available from redhat.
Remember though, that You mght have to reinstall all the needed modules.

Regards,
Harald

Harald Wagener * An der Alster 42 * 20099 Hamburg *
http://www.fcb-wilkens.com

6

At 13:13 02.04.2002 +0200, Harald Wagener wrote:

Frank Reppin wrote:

Hi,

Hello,

Has anybody managed to get RT working on a Redhat 7.2 install?

Yes, I tested this with success.

Had 2.0.4 working like a charm for a while, then upgraded Redhat to 7.2.
No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No messages in
any of the logs (rt, Apache, or the system log).

I had exactly the same problem. Solution :
compiling mod_perl into apache sources solved it (as mentioned
in the FAQ too) solved my problems and since then it works great.

Another fix should be to upgrade to perl-5.6.1 and the according mod_perl
and apache packages. updates are available from redhat. Remember though,
that You mght have to reinstall all the needed modules.

Regards,
Harald
…

Hello,
I have, unfortunately, exact the same Problem, now .

First I updated the whole System with all RedHat 7.2 Updates (incl. Perl
5.6.1) and then I installed RT 2.0.13.

Both possibilities of start reports OK
/usr/sbin/apachectl start: httpd started
service httpd start [OK]

=> But httpd is dead. !! (no message … nothing)

Any fix / possibility without compiling a new apache with “mod_perl into” ??

best regards
Christian

PerlRequire /opt/rt2/bin/webmux.pl
#PerlModule Apache::DBI
#PerlFreshRestart On
<Location /rt2>
SetHandler perl-script
PerlHandler RT::Mason

Alias /rt2/ /opt/rt2/WebRT/html/

7

Any particular reason for commenting out PerlModule and
PerlFreshRestart ? I think those were vital to me.

I ended up re-installing RedHat from scratch, then finding that I still
got the same error. Added the PerlModule and PerlFreshRestart,
and that fixed it. Works great now. I even have other virtual hosts
using mod_perl OK with other software.

Y.

ServerAdmin xxx DocumentRoot xxx ServerName xxx PerlModule Apache::DBI PerlFreshRestart On PerlRequire /usr/local/rt2/bin/webmux.pl SetHandler perl-script PerlHandler RT::Mason ---- On 23 Apr 2002, at 9:11, Christian wrote: ----

At 13:13 02.04.2002 +0200, Harald Wagener wrote:

Frank Reppin wrote:

On Thu, 28 Mar 2002, Yan Fitterer wrote:

Hi,

Hello,

Has anybody managed to get RT working on a Redhat 7.2 install?

Yes, I tested this with success.

Had 2.0.4 working like a charm for a while, then upgraded Redhat to
7.2. No problems.

Then upgraded RT to 2.0.13 - and Apache dies on startup. No
messages in any of the logs (rt, Apache, or the system log).

I had exactly the same problem. Solution :
compiling mod_perl into apache sources solved it (as mentioned in
the FAQ too) solved my problems and since then it works great.

Another fix should be to upgrade to perl-5.6.1 and the according
mod_perl and apache packages. updates are available from redhat.
Remember though, that You mght have to reinstall all the needed
modules.

Regards,
Harald
…

Hello,
I have, unfortunately, exact the same Problem, now .

First I updated the whole System with all RedHat 7.2 Updates (incl.
Perl 5.6.1) and then I installed RT 2.0.13.

Both possibilities of start reports OK
/usr/sbin/apachectl start: httpd started
service httpd start [OK]

=> But httpd is dead. !! (no message … nothing)

Any fix / possibility without compiling a new apache with “mod_perl
into” ??

best regards
Christian

–
PerlRequire /opt/rt2/bin/webmux.pl
#PerlModule Apache::DBI
#PerlFreshRestart On
<Location /rt2>
SetHandler perl-script
PerlHandler RT::Mason

Alias /rt2/ /opt/rt2/WebRT/html/

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

8

Hi Yan and the other folks,

At 11:13 23.04.2002 +0000, Yan Fitterer wrote:

Any particular reason for commenting out PerlModule and
PerlFreshRestart ? I think those were vital to me.

Just a test, I tried with and without.

I ended up re-installing RedHat from scratch, then finding that I still
got the same error. Added the PerlModule and PerlFreshRestart,
and that fixed it. Works great now. I even have other virtual hosts
using mod_perl OK with other software.

Y.

Now I tested, because of your hint, also ones with VirtualHost.

DocumentRoot /opt/rt2/WebRT/html/ ServerName www.rt2.de PerlModule Apache::DBI PerlFreshRestart On PerlRequire /opt/rt2/bin/webmux.pl SetHandler perl-script PerlHandler RT::Mason

→ !!! fine !!!
It’s crazy, that works very well !! ???

i tested again with

PerlRequire /opt/rt2/bin/webmux.pl
PerlModule Apache::DBI
PerlFreshRestart On
<Location /rt2>
SetHandler perl-script
PerlHandler RT::Mason

…

Alias /rt2/ /opt/rt2/WebRT/html/

No success. Apache could not start

Any additional idea ??

thanks
Christian

9

Hi all,

just found a problem with RT 2.0.13 on our site, that a user with no
rights on a certain queue can access the tickets in that queue if he
access them directly by number. First realised this when just clicking a
link in an autogenerated mail and saw that I had the wrong user logged in
when testing stuff.

Can anyone else confirm this behaviour or is it just me that has managed
to screw up my config?

Some background:

Just installed RT and trying to configure this for use by our internal
support/helpdesk. Realising how neat RT is I started playing with the idea
to also let it handle the company info requests.

For certain reasons I don’t want our support clients to be able to view
these internal errors and also didn’t want those internal notes generate
any autoreplies.

So the solution was that I have removed the global scrip
OnCreate->AutoreplyRequestor->Autoreply template and added it to the
queues where I want the autoreply to be created.

Secondly I have created two groups one for company use and one for
external support clients. The local group has global rights to view any
queue whereas the support group only have access to the groups of their
interest.

Is the assumtion that this ought to work correct or should I have two
separate installations to handle it?

Best regards

Magnus Egnerfors

10

me-maillists@billskill.com wrote:

… a user with no rights on a certain queue can access the tickets in
that queue if he access them directly by number.

Can anyone else confirm this behaviour or is it just me that has
managed to screw up my config?

I’ve just asked a colleague to try ticket 164 on our system, which is in
my personal todo list queue (for which, unsurprisingly, only I have
rights), and he got a permission denied error message.

Some background:

Is the assumtion that this ought to work correct or should I have two
separate installations to handle it?

What you’re aiming for certainly is possible, and from your description
I didn’t spot on obvious howler.

If you can’t track it down, do you want to post exactly which global and
which per-queue privileges have been allocated to which groups?

Smylers
GBdirect

11

me-maillists@billskill.com brought forth from the aether:

Can anyone else confirm this behaviour or is it just me that has managed
to screw up my config?

i have also experienced this, resulting in me not opening up our ticketing
system to our clients.

we have the following perms set (Contacts is a local group with the tech
contacts for that queue in it):

Queue.Group:

  • Everyone - CreateTicket
  • Requestor - CreateTicket
    ReplyToTicket
  • Contacts - CreateTicket
    ReplyToTicket

Queue.User
No Rights For Anyone

Global.Group

  • Requestor - ReplyToTicket
  • Staff - CommentOnTicket
    CreateTicket
    DeleteTicket
    ModifyTicket
    OwnTicket
    ReplyToTicket
    SeeQueue
    ShowTicket
    ShowTicketComments
    Watch
    WatchAsAdminCc

if i create another group or user (like the Contacts group, but for
another queue), any user in that group can enter a ticket number and go
straight to the ticket.

Magnus Egnerfors

Adrian Goins
Arces Network, LLC
http://www.arces.net

12

Quoting Adrian Goins agoins@arces.net:

me-maillists@billskill.com brought forth from the aether:

Can anyone else confirm this behaviour or is it just me that has managed
to screw up my config?

i have also experienced this, resulting in me not opening up our ticketing
system to our clients.

[snip]

Found out in the end that it was me and my colleague that managed to work on
the same ticket. He had moved it to a queue that was setup when we played with
the system and had most permissions assigned to Everyone.

“It just shows that the system is perfect and it’s the people that doesn’t know
how to handle it”-scenario showed itself to be true again.

Thanx for all the help

Magnus

Magnus Egnerfors
Billskill AB (www.billskill.com)

13

Hi,

it’s working now with

 PerlModule Apache::DBI
 PerlFreshRestart On
 PerlRequire /opt/rt2/bin/webmux.pl

<Location /rt2>
SetHandler perl-script
PerlHandler RT::Mason

I don’t know exactly why ;-( but :slight_smile: . [maybe the sequencing]

thx for your help

regards
Christian

At 15:19 23.04.2002 +0200, Christian wrote:

14

Hi Magnus,

me-maillists@billskill.com wrote:

Some background:

Just installed RT and trying to configure this for use by our internal
support/helpdesk. Realising how neat RT is I started playing with the idea
to also let it handle the company info requests.

For certain reasons I don’t want our support clients to be able to view
these internal errors and also didn’t want those internal notes generate
any autoreplies.

We have a similar problem. Our customers are competitors and they don’t
want that others see their problems and we don’t want our customers see
our internal
tickets. But all tickets are about the same product, so it is impossible
to handle a lot of different queues.

The solution was to create a new kind of user between unprivileged and
privileged, so called underprivileged.

All these users share a nickname beginning with X_ and they are
unprivileged.
When logging in they get a new interface with a button show group
tickets. So they can see all their own tickets as well as the tickets
their X_ group has requested, but nothing else.

To handle this I added a new interface GroupService (copied from
SelfService) and changed the autohandler a little bit.

I’ve added the sources, so you can see if you get an idea how to handle
your problem

ciao,
Harald

Dr. Harald Koll�ra
Professional Services
fun communications GmbH
Brauerstrasse 6 76135 Karlsruhe Germany
Tel: +49 721 964480 Fax: +49 721 96448-299
email: harald.kollera@fun.de http://www.fun.de/

I trust in http://www.keytrust.de

autohandler.patch (737 Bytes)

GroupService.tar (50 KB)