Execute Arbitrary Perl Script on resolve

Hi all,
I was wondering what the best way to execute an arbitrary perl
script on resolution of ticket is.

That is all,
Ryan

I was surprised to see no answer to this question below.

We really need to be able to execute perl scripts upon
resolution of tasks in various queues… isn’t there
some way to do this?

One Internet with Equal Access for All,

Will Doherty
Online Policy Group, Inc.
http://www.onlinepolicy.org

Yes, Sir there is.
There is probably a reason you recieved no response.
The answer to the question you asked is easily found in the documentation.
If you had looked on the website, in the docs section you would have found
A tutorial on how to write a Scrip, which is RT’s built-in extension method.
In Short, it allows you to write conditions and actions to be checked and
fired when the condition criteria is met. Since there is already a OnResolve
scrip condition written (Packaged with RT) all You need to write is the
action for said condition.
In the future please don’t get snippy with the list.
I saw your first post yesterday, I hardly think that you should be expecting
a 24 hour response from free support.

Having said that, if there is a Specific question that you have after reading
All the docs, I or others I’m sure will be happy to respond.
But just as some advice for future incidents, please read All available
documentation AND search the list archives before posting to the list,
especially on a topic as broad as yours.

Thank you and have a wonderful day,

MGOn Thursday 30 May 2002 11:27 am, Will Doherty wrote:

I was surprised to see no answer to this question below.

We really need to be able to execute perl scripts upon
resolution of tasks in various queues… isn’t there
some way to do this?

One Internet with Equal Access for All,

Will Doherty
Online Policy Group, Inc.
http://www.onlinepolicy.org

Delivered-To: rt-users@pallas.eruditorum.org
Date: Tue, 28 May 2002 19:02:39 -0700 (PDT)

From: Ryan Stark rstark@silcon.silcon.com

To: rt-users@lists.fsck.com
Subject: [rt-users] Execute Arbitrary Perl Script on resolve
Sender: rt-users-admin@lists.fsck.com
X-BeenThere: rt-users@lists.fsck.com
X-Mailman-Version: 2.0beta5
List-Id: For users of RT: Request Tracker <rt-users.lists.fsck.com>

Hi all,
I was wondering what the best way to execute an arbitrary perl
script on resolution of ticket is.

That is all,
Ryan


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Dear Michael,

I didn’t mean to come across as snippy, more like surprised!
I have posted a question before a couple of weeks ago and I
got several replies within a couple days of the posting.

We have read the documentation.

Anyway, there seem to be a lot of actions pre-defined… we
are trying to figure out which one would be best to simply
execute an external Perl script.

Any advice would be much appreciated!

And so far RT rocks! Thanks very much, especially to Jesse
and the other developers.

One Internet with Equal Access for All,

Will Doherty
Online Policy Group, Inc.
http://www.onlinepolicy.org

At 11:38 AM 5/30/2002 -0500, Michael Grubb wrote:

Anyway, there seem to be a lot of actions pre-defined… we are trying
to figure out which one would be best to simply execute an external
Perl script.

You seem to be missing the point:

A ScripAction IS an arbitrary perl script.

Make a new one.

-Robin

Robin Powell's Old Home Page BTW, I’m male, honest.
le datni cu djica le nu zifre .iku’i .oi le so’e datni cu to’e te pilno
je xlali – RLP http://www.lojban.org/

Well Put.

Anyway if you REALLY want to just execute external perl code you could do
something like this:

WARNING*
This is untested code.
I just slapped it together.
I know that the principals behind it work because I’ve done this before but as
for making sure that RT does it properly is anybody’s guess =]
Sure you could use the system function to execute a new perl interpreter but I
liked this solution a little better.
Also I don’t know how well this will scale so if you have lots of tickets in a
short amount of time that this will act on I don’t know how this will do.
Any way. As it is… Merry Christmas.

-M

package RT::Action::ExecExternal;
require RT::Action::Generic;
@ISA=qw(RT::Action::Generic);

#Do what we need to do and send it out.

#What does this type of Action does
our $queue = undef;
our $prog_txt = undef;

{{{ sub Describe

sub Describe {
my $self = shift;
return (ref $self . " will execute arbritrary perl code\n");
}

}}}

{{{ sub Prepare

sub Prepare {
my $self = shift;
open(EXTPRG, “<” . $self->Argument()) or return 0;
while() { $prog_txt .= $_ }
close(EXTPRG) or return 0;
return 1;
}

}}}

sub Commit {
my $self = shift;
eval $prog_txt;
$RT::Logger->debug($@ ? $@ : “Executed External App:\n$prog_txt\n”);
return !$@;
}

Applicability checked in Commit.

{{{ sub IsApplicable

sub IsApplicable {
my $self = shift;
1;
return 1;
}

}}}

1;On Thursday 30 May 2002 12:17, Robin Lee Powell wrote:

On Thu, May 30, 2002 at 09:43:54AM -0700, Will Doherty wrote:

Anyway, there seem to be a lot of actions pre-defined… we are trying
to figure out which one would be best to simply execute an external
Perl script.

You seem to be missing the point:

A ScripAction IS an arbitrary perl script.

Make a new one.

-Robin

Yesterday Michael Grubb wrote:

Anyway if you REALLY want to just execute external perl code you
could do something like this:

{{{ sub Prepare

sub Prepare {
my $self = shift;
open(EXTPRG, “<” . $self->Argument()) or return 0;
while() { $prog_txt .= $_ }
close(EXTPRG) or return 0;
return 1;
}

}}}

sub Commit {
my $self = shift;
eval $prog_txt;

Surely the above open, while, close, and eval can be simplified to:

do $self->Argument();

Possibly you’d want to make sure the external script always returns true
if it succeeds, so that the return code gets propagated properly.

Smylers
GBdirect

Yesterday Michael Grubb wrote:

Anyway if you REALLY want to just execute external perl code you
could do something like this:

open(EXTPRG, "<" . $self->Argument()) or return 0;
while(<EXTPRG>) { $prog_txt .= $_ }
close(EXTPRG) or return 0;

Surely the above open, while, close, and eval can be simplified to:

do $self->Argument();

Possibly you’d want to make sure the external script always returns true
if it succeeds, so that the return code gets propagated properly.

Actually, if you want some perl code that will allow you to pipe something
(the current transaction) to an arbitary command and reading the output,
and being able to kill the command after an arbitary timeout, try:

http://www.fsck.com/rtfm/factoid.html?id=153

The above is part of a ScripAction that I’m wanting to finish that does
essentially ‘execute arbitary perl code’ ($self->Argument, although
checking to make sure one can execute it :wink: ), although I’m intending to
finish it as part of a ScripAction tutorial when I get spare time (and
that’ll probably be when I next get pissed off at spam in my queues and
want SpamAssassin on it :wink: )

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

‘What would be the killer app assuming serious sized bandwidth?’
‘Obvious. More bits per boob.’
– Q&A from SANE2002 inSANE quiz.

Yes, You could,
I had forgotten the do “function”, it would be a better solution.
than the open, while, close, eval. method.
But as I said in my post,
I was in a rush and I threw that solution together to help.On Friday 31 May 2002 03:06, Smylers wrote:

Yesterday Michael Grubb wrote:

Anyway if you REALLY want to just execute external perl code you
could do something like this:

{{{ sub Prepare

sub Prepare {
my $self = shift;
open(EXTPRG, “<” . $self->Argument()) or return 0;
while() { $prog_txt .= $_ }
close(EXTPRG) or return 0;
return 1;
}

}}}

sub Commit {
my $self = shift;
eval $prog_txt;

Surely the above open, while, close, and eval can be simplified to:

do $self->Argument();

Possibly you’d want to make sure the external script always returns true
if it succeeds, so that the return code gets propagated properly.

Smylers

[this is a bit stream-of-conciousnessy, so bear with me ;-)]On Fri, May 31, 2002 at 10:20:35PM +0200, Bruce Campbell wrote:

finish it as part of a ScripAction tutorial when I get spare time (and
that’ll probably be when I next get pissed off at spam in my queues and
want SpamAssassin on it :wink: )

:slight_smile:

I kinda had a think about that before, but I’m not sure about the best
way of dealing with spam.

Many sites have just one common request queue, where the email
address is commonly known, and hence a bit of a spam-trap. It’s
not really an option to go changing around your support addresses
to block spam :wink:

Filtering the spam by hand is simply unpractical in some sites, due to
the volume received.

The only (bad) way I could think of doing was something like…

* Mail into a procmail script for the support address
* Through SpamAssassin
* If good, it goes into the normal queue
* If bad...
	- Bounce back to sender, with a note
	  asking them to enter the ticket
	  number in some form (with an image
	  number on the page or the like that
	  they also have to enter, to avoid
	  bots defeating it).
	- Chuck the ticket into a *different*
	  queue, which contains suspected spam
* If the user fills in the details required,
  use RT to move the ticket back into the real
  queue
* Autokill tickets which aren't hit in that
  queue after a week/month/whatever, through
  a cron job.

It’s bad because…

* It would confirm that the account is active, for
  harvesters... though as far as I can see, this is
  unavoidable as...
  	- we need to autoreply to requests
	- there's no way that I can think of to
	  differentiate between real spam, and
	  reports of spam!

* A bit more awkward for the end users

* The two queues thing probably isn't the best
  idea design-wise... it might be better for it to be
  integrated into RT, like

  	- Call SpamAssassin from within RT(?!)
	- if SpamAssassin says it is spam, RT
	  replies with the appropriate note,
	  *doesn't* send the ticket to AdminCCs,
	  and tags it as dead.
	- If the webform stuff is done, then
	  re-open, and renotify the AdminCCs

  (this approach would be better, as it could
   be generically applied to any queue)

* Reliant upon the external functionality of
  SpamAssassin (or whatever) , and that remaining
  constant.  That's probably not a big deal though...

Thoughts anyone?

Niall
  • Niall Brady bradyn@maths.tcd.ie [2002-06-07 13:29]:> On Fri, May 31, 2002 at 10:20:35PM +0200, Bruce Campbell wrote:

finish it as part of a ScripAction tutorial when I get spare time
(and that’ll probably be when I next get pissed off at spam in my
queues and want SpamAssassin on it :wink: )

I kinda had a think about that before, but I’m not sure about the best
way of dealing with spam.

Many sites have just one common request queue, where the email address
is commonly known, and hence a bit of a spam-trap. It’s not really an
option to go changing around your support addresses to block spam :wink:

If your rt address is not a publicly used one, you can use
whitelist-based filtering to determine which mail to accept.

(darren)

The knowledge that makes us cherish innocence makes innocence
unattainable.
– Irving Howe

“NB” == Niall Brady bradyn@maths.tcd.ie writes:

NB> Filtering the spam by hand is simply unpractical in some sites, due to
NB> the volume received.

NB> The only (bad) way I could think of doing was something like…

Well, I hope you’d exempt your “email abuse” queue from such a
scheme…

I think it depends entirely on your user population. For us, we
really can’t do any aggressive blocking because the potential for
collateral damage (and harm to our repuation) is great. For other
uses I have in mind, I’d have no problem putting spamassassin in front
of the inbound queue address at the mail server level, and have that
reject any suspected spam (probably at a higher than default
threshhold).

I’d hate to see RT bloat with spamassassin. Let your mail server deal
with blocking the spam.

“NB” == Niall Brady bradyn@maths.tcd.ie writes:

NB> Filtering the spam by hand is simply unpractical in some sites, due to
NB> the volume received.

NB> The only (bad) way I could think of doing was something like…

Well, I hope you’d exempt your “email abuse” queue from such a
scheme…

Actually, theres a very good argument for filtering your network-abuse
queue using the split-queue method put forward by Niall; its an address
that has been made public, and thus, will receive spam. You would make
the filter be rather loose in what it rejects of course.

( IMHO, sending complainers a seperate email if their message really
looks like spam (excluding the idiots who use their mailer’s bounce
function to send a complaint) has the additional future behavioural
benefit of getting them to properly format their complaint mails. )

I think it depends entirely on your user population. For us, we

Yes. The case of the RIPE NCC’s ‘email abuse’ queue is further
complicated, mainly by ignorant 'merkins. :wink:

                         Bruce Campbell                            RIPE
                          Currently at:                             NCC
             NANOG 25, Toronto, Canada.                      Operations

Actually, theres a very good argument for filtering your network-abuse
queue using the split-queue method put forward by Niall; its an address
that has been made public, and thus, will receive spam. You would make
the filter be rather loose in what it rejects of course.

Yep, that’s the point I was making… where I work, we combine
(root|time|news|abuse|whatever@maths.tcd.ie) to go to our request
queue. The addresses are commonly known from computer info pages,
and we house a reasonably popular time server (hence email address
widely known), so we get a fair few spams to the queue each day.
At the moment, we sift it by hand, but it’s a smelly job :wink:

I’m sure we’re not the only site who combines all their system
addresses!

If I get something whacked together, I’ll send it back to the list.

Niall