Sending mail from scrip action

Hi,

I would like to send e-mails from the scrip preparation code. I use

require RT::Action::SendEmail;
use strict;
use vars qw/@ISA/;
@ISA = qw(RT::Action::SendEmail);

and would like to set

$self->SetTemplate(25);

but against my expectation $self is not the scrip object but
Action::UserDefined which does not allow setting the template. At the
end I would send the mail by

 @{ $self->{'To'} } = $followerEmail;
 $self->SUPER::Prepare();
 $self->SUPER::Commit();

If I do not set the template, then the ::Prepare call does not work,
lacking the TemplateObj.

How could I do this properly?

  • Gergely

Hello,

I’m trying to install RT and I’m a bit confused.
I have read many documentations.

During the install process I did

cd rt-4.0.5

./configure --with-db-database=rtrackerdb --with-db-rt-user=rt --with-db-rt-pass=‘rtpwd’ --with-db-dba=mydba --prefix=/var/www/htdocs/rt

In the documentations that I read they say that I’ll have to access the URL http://192.168.1.1/rt
But if I list the directory /var/www/htdocs/rt there is no webpage

ls /var/www/htdocs/rtx/

bin etc local share
docs lib sbin var

I would like to mention that I change the http.conf, configuredRT_SiteConfig.pm and ran make initialize-database
I ran the ./configure command in the first step of my installation and I would expect to see in the /var/www/htdocs/rt directory a file such as index.pl or index.html

Does anyone have an idea ?
For those who doesn’t have an idea could you ls the rt directory.

Thank you

Hello,

I’m trying to install RT and I’m a bit confused.
I have read many documentations.

During the install process I did

cd rt-4.0.5

./configure --with-db-database=rtrackerdb --with-db-rt-user=rt --with-db-rt-pass=‘rtpwd’ --with-db-dba=mydba --prefix=/var/www/htdocs/rt

In the documentations that I read they say that I’ll have to access the URL http://192.168.1.1/rt
But if I list the directory /var/www/htdocs/rt there is no webpage

ls /var/www/htdocs/rtx/

bin etc local share
docs lib sbin var

I would like to mention that I change the http.conf, configuredRT_SiteConfig.pm and ran make initialize-database
I ran the ./configure command in the first step of my installation and I would expect to see in the /var/www/htdocs/rt directory a file such as index.pl or index.html

Does anyone have an idea ?
For those who doesn’t have an idea could you ls the rt directory.

Thank you

In your case what you are locking for is in:
/var/www/htdocs/rt/share/html/

Also 4.0.6 is the current version and 4.0.7 will be release in the next
days/weeks. So you should use an more recent version for an new
installation.

Chris

----- Mail original -----

De : Christian Loos cloos@netsandbox.de

In the documentations that I read they say that I’ll have to access the
URL http://192.168.1.1/rt
But if I list the directory /var/www/htdocs/rt there is no webpage

ls /var/www/htdocs/rtx/

bin etc local share
docs lib sbin var

I would like to mention that I change the http.conf,
configuredRT_SiteConfig.pm and ran make initialize-database
I ran the ./configure command in the first step of my installation and I
would expect to see in the /var/www/htdocs/rt directory a file such as index.pl
or index.html

Does anyone have an idea ?
For those who doesn’t have an idea could you ls the rt directory.

Thank you

In your case what you are locking for is in:
/var/www/htdocs/rt/share/html/

Also 4.0.6 is the current version and 4.0.7 will be release in the next
days/weeks. So you should use an more recent version for an new
installation.

Chris

Hello Christian,

Thank you for your answer.

I didn’t install RT 4.0.6 because there was a compatibility version issue with URI (>= 1.59). Mine was older.
Now that I have and updated URI perl module, I installed RT 4.0.6
My second problem is the Apache virtualhost configuration. I use Apache 1.3.29
So far it looks like this:
<VirtualHost *>
ServerAdmin root@localhost
DocumentRoot /htdocs
ServerName 192.168.99.1
PerlModule Apache::PerlRun
<Location /rtx/>
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler Apache::PerlRun
PerlRequire /var/www/htdocs/rty/mystartup.pl
Options ExecCGI Indexes FollowSymLinks
PerlSendHeader On
Order allow,deny
Allow from all

ErrorDocument 404 /404.html
ErrorLog logs/192.168.99.1-error_log
CustomLog logs/192.168.99.1-access_log common

Should I use RT::Mason as the PerlHandler ? (Many wikis talk about it)
In my setup I have Apache chrooted, so mod_perl loads the installed modules at startup (I specify the list in mystartup.pl)
As you can see RT is installed in /htdocs/rty directory. Do you have any comment on my Apache configuration ?

Thank you

Hello Christian,

Thank you for your answer.

I didn’t install RT 4.0.6 because there was a compatibility version issue with URI (>= 1.59). Mine was older.
Now that I have and updated URI perl module, I installed RT 4.0.6
My second problem is the Apache virtualhost configuration. I use Apache 1.3.29
So far it looks like this:
<VirtualHost *>
ServerAdmin root@localhost
DocumentRoot /htdocs
ServerName 192.168.99.1
PerlModule Apache::PerlRun
<Location /rtx/>
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler Apache::PerlRun
PerlRequire /var/www/htdocs/rty/mystartup.pl
Options ExecCGI Indexes FollowSymLinks
PerlSendHeader On
Order allow,deny
Allow from all

ErrorDocument 404 /404.html
ErrorLog logs/192.168.99.1-error_log
CustomLog logs/192.168.99.1-access_log common

Should I use RT::Mason as the PerlHandler ? (Many wikis talk about it)
In my setup I have Apache chrooted, so mod_perl loads the installed modules at startup (I specify the list in mystartup.pl)
As you can see RT is installed in /htdocs/rty directory. Do you have any comment on my Apache configuration ?

Thank you

You should read docs/web_deployment.pod or the online version:

Notice that mod_perl 1.xx (which I think apache 1.3 is using) isn’t
supported.

Chris

Thank you Christian for the link it really helped,

I looked at that page
http://wiki-archive.bestpractical.com/view/ManualApacheConfig
and the one you gave me

And they said that only mod_perl 1.9x causes problems. Actually I use version 1.31

The reason why I use Apache 1.3.29 and mod-perl 1.31 is because they are provided with OpenBSD (I use version 5.1 which has been release in may)

I tried this configuration for my virtualhost configuration

<VirtualHost *>
ServerAdmin root@localhost
DocumentRoot /htdocs
ServerName 192.168.1.1
<Location /rty/>
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler Plack::Handler::Apache1
PerlSetVar psgi_app /var/www/htdocs/rty/sbin/rt-server
PerlRequire /var/www/htdocs/rty/monstartup.pl
Options ExecCGI Indexes FollowSymLinks
PerlSendHeader On
Order allow,deny
Allow from all


use Plack::Handler::Apache1;
Plack::Handler::Apache1->preload("/var/www/htdocs/rty/sbin/rt-server");

ErrorDocument 404 /404.html
ErrorLog logs/192.168.1.1-error_log
CustomLog logs/192.168.1.1-access_log common

I have now the following error in my logs when my Apache is chrooted

[Mon Aug 27 14:17:37 2012] [error]: could not find component for initial path ‘/share/html’ (component roots are: ‘/var/www/htdocs/rty/local/html’, ‘/var/www/htdocs/rty/share/html’) (/var/www/htdocs/rty/sbin/…/lib/RT/Interface/Web/Handler.pm:208)

If I remove the chroot I have this error
[Mon Aug 27 16:24:00 2012] [error] [client 192.168.1.111] File does not exist: /var/www/htdocs/Install/index.html
It’s trying to look the index.html in /var/www/htdocs/Install/ instead of /var/www/htdocs/rty/share/html/Install/

Both problems seem to be path related. I’m going to keep on searching but by chance if anyone had this problem, I’ll be pleased to hear it

I have been able to run RT in standalone four hours ago, I was very happy about that.

Am Mon, 27 Aug 2012 15:39:05 +0100 (BST)
schrieb Mik J mikydevel@yahoo.fr:

Thank you Christian for the link it really helped,

I looked at that page
http://wiki-archive.bestpractical.com/view/ManualApacheConfig
and the one you gave me

And they said that only mod_perl 1.9x causes problems. Actually I use
version 1.31

The reason why I use Apache 1.3.29 and mod-perl 1.31 is because they
are provided with OpenBSD (I use version 5.1 which has been release
in may)

Isn’t there an apache22 port for OpenBSD?

OpenBSD refused to import apache2…

I would like to send e-mails from the scrip preparation code. I use

First thing - Don’t send mail or make changes from the Preparation
stage of a scrip, do it from the commit.

You also don’t say what you’re trying to do, but trying to invoke
SendEmail from a UserDefined scrip action probably isn’t going to work
quite right.

Are you trying to change @ISA from inside the boxes in the Admin UI?

If you actually need to subclass SendEmail (like Notify does) you
almost certainly need to write code on the filesystem and load it in.

If you tell the list what you’re trying to do, someone might be able
to point you to a simpler solution.

-kevin

Why RT and RTIR are so hard to install and work properlly? I dont know perl
but and I’d like an easy way to install RT.

Can anybody send me a “how to”?

Hábner

Which part of the installation documentation is causing you trouble? What
type of system are you installing on?On 28 Jan 2015 7:06 am, “Hábner Teixeira Costa” habner@outlook.com wrote:

Why RT and RTIR are so hard to install and work properlly? I dont know
perl but and I’d like an easy way to install RT.

Can anybody send me a “how to”?

Hábner

Why RT and RTIR are so hard to install and work properlly? I dont know perl

Here’s your problem :wink:
Most people probably stopped reading right there.

Seriously, though:
when I first installed it, I didn’t know that much Perl but I could make it work (RT2.something).

Your problem is most likely that you try to use your distribution’s Perl and have RT’s dependency-fixer install additional modules on top of it via CPAN.
That has never been a good idea.

These days, FreeBSD has all the required modules pre-packaged, as do (I think) Debian and Ubuntu.

But I would be tempted to use a „clean“ Perl installed somewhere else as the basis for RT even in the case of FreeBSD (which I know best, admittedly).

How difficult would it be for BestPractical to tar up such a custom perl install done in e.g. /opt/rt/perl, together with all the dependencies and throw in a „complete“ install of RT+RTIR with FastCGI-support?
While historically, the mod_perl installation is the most common one, the FastCGI installation can work with nginx, which faster and also decouples the web server from the installed version of Perl (I don’t know if you can have and RT-installation and mod_perl compiled against different versions of perl for example).

You just needed one such archive for the current version of Ubuntu, Debian, CentOS/RedHat and maybe SuSE.

OK, so it would probably come with MySQL/MariaDB per default. But for those with a different setup in mind, the source is still available…

In the DevOps world, this is what chef is doing to get a software with a lot of 3rd-party dependencies running smoothly and consistently on many platforms.

But I would be tempted to use a „clean“ Perl installed somewhere else
as the basis for RT even in the case of FreeBSD (which I know best,
admittedly).

See https://docs.bestpractical.com/rt_perl

How difficult would it be for BestPractical to tar up such a custom
perl install done in e.g. /opt/rt/perl, together with all the
dependencies and throw in a „complete“ install of RT+RTIR with
FastCGI-support?

The problem is in the binary libraries that RT (and its CPAN
dependencies) use. Any such deploy would be specific to one particular
release of a particular distribution, and as such would be quite
resource-heavy to produce in sufficient variety to be useful.
Shipwright is a BPS tool that builds relocatable installs of
software that package everything above glibc, but that doesn’t quite
solve the right problem.

We’ve begun pondering building Docker vessels for RT, but the database
dependency complicates matters.

While historically, the mod_perl installation is the
most common one

These days, we suggest fastcgi over mod_perl, even for Apache.

the FastCGI installation can work with nginx, which
faster and also decouples the web server from the installed version
of Perl (I don’t know if you can have and RT-installation and
mod_perl compiled against different versions of perl for example).

You generally cannot. This is one reason we prefer fastcgi deployments.

  • Alex

The problem is in the binary libraries that RT (and its CPAN
dependencies) use. Any such deploy would be specific to one particular
release of a particular distribution, and as such would be quite
resource-heavy to produce in sufficient variety to be useful.

I thought that with „modern“ distributions like CentOS/RHEL (and the LTS-versions of Ubuntu), the binary ABI never changes?

So that a perl-binary built on CentOS7 will run all way through 7.10.

It has always been this way for FreeBSD at least.
:wink:

Shipwright is a BPS tool that builds relocatable installs of
software that package everything above glibc, but that doesn’t quite
solve the right problem.

We’ve begun pondering building Docker vessels for RT, but the database
dependency complicates matters.

Most people will use MySQL anyway IMO. Even if you gave them the choice of Oracle, PostgreSQL and MSSQL and a handful other „real“ databases they probably never ever even heard about.
Who downloads a „one click installer“ just to make it complicated afterwards?

You generally cannot. This is one reason we prefer fastcgi deployments.

I was suspecting that. But I never actually tried.

I’d go even further and offer pre-configured vmdks that offer one pre-configured queue „support“ that pulls in mail via fetchmail from a server and with an account the user can specify.
And one „helpdesk“ user in a „helpdesk“ group, with the typical „helpdesk“-permissions.
That should get most people started.

The problem these days is that people want everything to be working right now - no reading of a manual, no configuration. The machine should do what it should do even if they actually don’t know how to express what it should do. Much less know how to configure it. Kind of like an iPhone.
They are willing to pay for this convenience, but increasingly this willingness isn’t exceeding single-digit Dollar amounts…

Anyway: there’s nothing wrong with RT as I see it, but the people running help desks these days are getting less and less technically minded: they want something that can be configured with by entering some values and a few clicks on the „OK“-button and without too much thought.

We can’t change this, but we can try to adapt…

Why RT and RTIR are so hard to install and work properlly? I dont know
perl  

Here’s your problem :wink:
Most people probably stopped reading right there.

seriously? assuming that the sysop is comming with a basic admin skill
(knowing what “make” do and how to setup an nginx to communicate with
fcgi), perl programs are quiet easy to install when someone pointed you
on the good ressources:

https://bestpractical.com/docs/rt/4.2/

especially
https://bestpractical.com/docs/rt/4.2/initialdata.html

and
https://bestpractical.com/docs/rt/4.2/rt-server.fcgi.html

and when it comes to perl dependecies:


and if you’re using a debian derrivative; apt-get install dh-make-perl
and run your own debian repo.

I really think that the perl ecosystem makes perl applications the
easiest to install (comparing to other dynamic langages like python or
ruby… not to mention npm)

The problem is not to have a running RT but frankly, i have very hard
time to figure out how to set it up correctly. the missing documentation
is something that explain the general philosophy of RT for
administrators and some step by step tutorials (for example: installing
a notification or a basic ticket routing).

I guess that’s what we learn from the best practical trainings but
comming from a french university, london wasn’t that affordable.

regards

Marc Chantreux,
Mes coordonnées: http://annuaire.unistra.fr/chercher?n=chantreux
Direction Informatique, Université de Strasbourg (http://unistra.fr)
“Don’t believe everything you read on the Internet”
– Abraham Lincoln

Didn’t make it to the ML due to being posted from a unknown account,
trying again.

Joop

Why RT and RTIR are so hard to install and work properlly? I dont know
perl  

Here’s your problem :wink:
Most people probably stopped reading right there.

I never had heard of perl when I installed my first RT (2.07) but
reading a bit on the topic and being familiar with make/gcc and I
managed to get it up and running.

seriously? assuming that the sysop is comming with a basic admin skill
(knowing what “make” do and how to setup an nginx to communicate with
fcgi), perl programs are quiet easy to install when someone pointed you
on the good ressources:

https://bestpractical.com/docs/rt/4.2/
Things are much better then in the 2.x days :slight_smile:

The problem is not to have a running RT but frankly, i have very hard
time to figure out how to set it up correctly. the missing documentation
is something that explain the general philosophy of RT for
administrators and some step by step tutorials (for example: installing
a notification or a basic ticket routing).
I think lots of people use it in a one queueu one purpose way. I do for
example. We move tickets manually to other queues when needed and have
little extra custom logic added to our install.

I guess that’s what we learn from the best practical trainings but
comming from a french university, london wasn’t that affordable.
What I remember of my training way back when 3.0 was out and 3.2 was
coming is that on day one we got a general tour of RT and on day two
there was a deep dive into things like scrips and internal workings of
RT but not so much about how to setup complex routing.

Maybe someone on the list who has complex ticket routing is willing to
explain how to do that, in general terms or with specific code, anyone??

Regards,

Joop

Hi Rainer

I understand your frustration.
There have been a number of products that I have installed as an IT guy where I had this same frustration - what is the most painless way to get the instance running – just so I can play with it and see if it seems to be worth pursuing more?

For those of us who have been working with RT for a number of years, it does seem rather easy or straightforward to set up.
But I imagine it is like that for everything in life, no? More practice means more familiarity and ease.

I can’t give enough praise for Best Practical and RT - so I definitely think it is well worth it to persevere until you have it running and you can evaluate it for yourself.

I have not come across any A to Z type setup documents or videos, and don’t expect I ever will.
I think this is at least in part due to the power and flexibility of the product, which is a very good thing!
I personally would not want to give up any of the amazing features of the product just to make it easier to run ‘out of the box’.

I know everyone is pointing you to the docs and they are worth it - well written, concise, complete.
I guess the point I’m trying to make is that RT is a great product and well worth it all: reading the docs, taking the time to learn it, set it up, experiment with it, and of course going to training.

If you haven’t seen it yet, this site is worth looking at too: http://requesttracker.wikia.com/wiki/HomePage

Best of luck!
Brent-----Original Message-----
From: rt-users [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Marc Chantreux
Sent: Wednesday, January 28, 2015 2:57 AM
To: Rainer Duffner
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT Installation

On Tue, Jan 27, 2015 at 09:31:26PM +0100, Rainer Duffner wrote:

Why RT and RTIR are so hard to install and work properlly? I dont know
perl

Here’s your problem :wink:
Most people probably stopped reading right there.

seriously? assuming that the sysop is comming with a basic admin skill (knowing what “make” do and how to setup an nginx to communicate with fcgi), perl programs are quiet easy to install when someone pointed you on the good ressources:

https://bestpractical.com/docs/rt/4.2/

especially
https://bestpractical.com/docs/rt/4.2/initialdata.html

and
https://bestpractical.com/docs/rt/4.2/rt-server.fcgi.html

and when it comes to perl dependecies:


and if you’re using a debian derrivative; apt-get install dh-make-perl and run your own debian repo.

I really think that the perl ecosystem makes perl applications the easiest to install (comparing to other dynamic langages like python or ruby… not to mention npm)

The problem is not to have a running RT but frankly, i have very hard time to figure out how to set it up correctly. the missing documentation is something that explain the general philosophy of RT for administrators and some step by step tutorials (for example: installing a notification or a basic ticket routing).

I guess that’s what we learn from the best practical trainings but comming from a french university, london wasn’t that affordable.

regards

Marc Chantreux,
Mes coordonnées: http://annuaire.unistra.fr/chercher?n=chantreux
Direction Informatique, Université de Strasbourg (http://unistra.fr) “Don’t believe everything you read on the Internet”
– Abraham Lincoln