Re: [rt-users] plugins link to module file, not package file

2014-12-10 Thread Alex Peters 
No problem.  Sorry to see you go.

On Thu, 11 Dec 2014 12:49 pm Jo Rhett  wrote:

> I’ve been using Perl for 20 years now. I grok perl.
>
> Good run with the insults and rudeness. Because yeah, that’s a great way
> to treat someone who’s pointing out a way to improve the usability of
> something. Treat them like dirt, and talk down to them like they’ve never
> used Perl before.
>
> I’ll stop offering advice on ways to improve the UI. Unintelligible and
> prone to confusion on the part of people isn’t my problem. I’m not going to
> be helpful if I get treated like shit when I’m trying to make someone’s
> profit-making production better and more likely to be used.
>
> I forgot why I dropped this list. Thanks for reminding me.
>
> On Dec 9, 2014, at 5:10 AM, Alex Peters  wrote:
>
> I feel that there are actually several issues to discuss in this thread:
>
>1. Perl modules vs. Perl module distributions
>2. Perl module distribution sources
>3. Perl module distribution installation
>4. knowledge assumed by the CPAN site
>5. knowledge assumed by RT's documentation
>6. what documentation should actually change
>
> Based on your description of the steps you performed in an attempt to
> install a Perl module from CPAN, with all due respect, I believe you've
> been improperly advised on Perl module installation and possibly haven't
> been made aware of some crucial things about how Perl's modules work.  I'll
> go over some of those things, then with everything in mind, maybe we can
> agree on what documentation changes are needed where.
>
>
> *Perl modules vs. Perl module distributions*
>
> A Perl *module* is (for all intents and purposes of this thread) a single
> .pm file.  A Perl module *distribution* consists of a number of Perl
> modules (which can be just one), a Makefile (or more commonly, a Makefile
> generator in Makefile.PL), and instructions for installation of the
> distribution and hence its modules (usually in README or INSTALL).
> Distributions exist because often, a single module isn't enough to provide
> some meaningful form of functionality.
>
> Modules are never installed directly.  Modules are always made available
> as a side effect installing module distributions.  The distribution (not
> the module) is the smallest unit involved in the action of installation.
> Installation of a distribution might result in the installation of only one
> module, but nonetheless, it's the distribution that's acted upon directly
> for installation rather than the module.
>
> In summary, direct installation of single modules doesn't happen.
>
>
> *Perl module distribution sources*
>
> Distributions are typically (but not always) available on the CPAN site
> (typically capitalised as "CPAN"), and can be downloaded as an *archive*.
> Other distribution sources include (but are not limited to) GitHub,
> Bitbucket, CD-ROMs, FTP sites and personal web pages.
>
> In summary, distribution files can come from many different places.
>
>
> *Perl module distribution installation*
>
> Every distribution includes installation instructions in README or
> INSTALL, and the most typical experience for installing a Perl module
> distribution (after obtaining an archive of it) goes like this:
>
> $ tar xzf My-Perl-Module-0.01.tar.gz
> $ cd My-Perl-Module-0.01
> $ perl Makefile.PL
> $ make
> $ make test
> $ make install
>
> Distributions on CPAN can be installed without first downloading an
> archive, using the CPAN installation tool (typically capitalised as
> "cpan").  cpan is actually smart enough to take a module name (rather than
> a distribution name) on the command line, determine the distribution to
> which that module belongs, and install that distribution.  Since one
> distribution generally depends on others ("prerequisites") being installed
> in advance, cpan also manages the installation of prerequisite
> distributions.  This makes the use of a tool like cpan the generally
> preferred means of installing distributions (and by extension, modules).
>
> Other similar tools exist which do the job in a more streamlined fashion.
> I personally prefer cpanm
> .
>
> In summary, distribution installation tools function on distributions, not
> modules—although some tools have the ability to infer the right
> distribution if given a module name.
>
>
> *Knowledge assumed by the CPAN site*
>
> Given that a CPAN module page
> 
> only offers a single Download link, and that link points to an archive of
> the module's distribution, it's safe to say that the CPAN site assumes that
> its users already know the distinction between modules and distributions,
> and expects that the user then refer to the documentation found within the
> downloaded archive.  I suppose the reasoning is that anyone who knows about
> CPAN already knows about Perl modules, and how to

Re: [rt-users] RT-Extension-AceEditor

2014-12-10 Thread Brumm, Torsten / Kuehne + Nagel / Ham GI-ID 
Hi Remi,
nice work, love this, but the Custom Action Prep Code and Custom Condition are 
changed in the display order?!?

[cid:image001.png@01D01519.BE459020]

Torsten

Von: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von 
Rémi
Gesendet: Mittwoch, 10. Dezember 2014 18:23
An: rt Users
Betreff: [rt-users] RT-Extension-AceEditor

Hi list,
Here is an extension that replace the default scrip edition textarea with the 
embeded Ace editor (http://ace.c9.io)

https://github.com/valmiRe/rt-extension-aceeditor
Rémi

Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Dirk 
Blesius, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Christian 
Marnetté, Christian Solf, Jens Wollesen.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: 
Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, 
Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Hans-Georg Brinkmann 
(Stellv.), Richard Huhn, Björn Johansson, Bruno Mang, Stefan Paul, Tim 
Scharwath, Dominic Edmonds, Peder Winther.

Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen 
Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen 
insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von Ziffer 
23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen gerne auf 
Anfrage und können Sie auch unter http://www.kuehne-nagel.com einsehen. 
Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen internationaler 
Übereinkommen weder unsere Haftung noch die Zurechnung des Verschuldens von 
Leuten und sonstigen Dritten zu Gunsten des Auftraggebers erweitert, und (2) 
wir in den im deutschen Seehandelsrecht aufgeführten Fällen des nautischen 
Verschuldens oder Feuer an Bord nur für eigenes Verschulden und (3) im Sinne 
der CMNI genannten Voraussetzungen nicht für nautisches Verschulden, Feuer an 
Bord oder Mängel des Schiffes haften.

Re: [rt-users] plugins link to module file, not package file

2014-12-10 Thread rick 
Jo, I honestly think that Alex simply misunderstood you. That's not
uncommon in these kind of lists. Better to not attribute to malice what
can be explained by miscommunication. Even in the very rare occasion that
it _is_ malice, you are better off assuming the best of people.

- Rick

> I’ve been using Perl for 20 years now. I grok perl.
>
> Good run with the insults and rudeness. Because yeah, that’s a great way
> to treat someone who’s pointing out a way to improve the usability of
> something. Treat them like dirt, and talk down to them like they’ve never
> used Perl before.
>
> I’ll stop offering advice on ways to improve the UI. Unintelligible and
> prone to confusion on the part of people isn’t my problem. I’m not going
> to be helpful if I get treated like shit when I’m trying to make someone’s
> profit-making production better and more likely to be used.
>
> I forgot why I dropped this list. Thanks for reminding me.
>
> On Dec 9, 2014, at 5:10 AM, Alex Peters  wrote:
>> I feel that there are actually several issues to discuss in this thread:
>> Perl modules vs. Perl module distributions
>> Perl module distribution sources
>> Perl module distribution installation
>> knowledge assumed by the CPAN site
>> knowledge assumed by RT's documentation
>> what documentation should actually change
>> Based on your description of the steps you performed in an attempt to
>> install a Perl module from CPAN, with all due respect, I believe you've
>> been improperly advised on Perl module installation and possibly haven't
>> been made aware of some crucial things about how Perl's modules work.
>> I'll go over some of those things, then with everything in mind, maybe
>> we can agree on what documentation changes are needed where.
>>
>>
>> Perl modules vs. Perl module distributions
>>
>> A Perl module is (for all intents and purposes of this thread) a single
>> .pm file.  A Perl module distribution consists of a number of Perl
>> modules (which can be just one), a Makefile (or more commonly, a
>> Makefile generator in Makefile.PL), and instructions for installation of
>> the distribution and hence its modules (usually in README or INSTALL).
>> Distributions exist because often, a single module isn't enough to
>> provide some meaningful form of functionality.
>>
>> Modules are never installed directly.  Modules are always made available
>> as a side effect installing module distributions.  The distribution (not
>> the module) is the smallest unit involved in the action of installation.
>>  Installation of a distribution might result in the installation of only
>> one module, but nonetheless, it's the distribution that's acted upon
>> directly for installation rather than the module.
>>
>> In summary, direct installation of single modules doesn't happen.
>>
>>
>> Perl module distribution sources
>>
>> Distributions are typically (but not always) available on the CPAN site
>> (typically capitalised as "CPAN"), and can be downloaded as an archive.
>> Other distribution sources include (but are not limited to) GitHub,
>> Bitbucket, CD-ROMs, FTP sites and personal web pages.
>>
>> In summary, distribution files can come from many different places.
>>
>>
>> Perl module distribution installation
>>
>> Every distribution includes installation instructions in README or
>> INSTALL, and the most typical experience for installing a Perl module
>> distribution (after obtaining an archive of it) goes like this:
>>
>> $ tar xzf My-Perl-Module-0.01.tar.gz
>> $ cd My-Perl-Module-0.01
>> $ perl Makefile.PL
>> $ make
>> $ make test
>> $ make install
>>
>> Distributions on CPAN can be installed without first downloading an
>> archive, using the CPAN installation tool (typically capitalised as
>> "cpan").  cpan is actually smart enough to take a module name (rather
>> than a distribution name) on the command line, determine the
>> distribution to which that module belongs, and install that
>> distribution.  Since one distribution generally depends on others
>> ("prerequisites") being installed in advance, cpan also manages the
>> installation of prerequisite distributions.  This makes the use of a
>> tool like cpan the generally preferred means of installing distributions
>> (and by extension, modules).
>>
>> Other similar tools exist which do the job in a more streamlined
>> fashion.  I personally prefer cpanm.
>>
>> In summary, distribution installation tools function on distributions,
>> not modules—although some tools have the ability to infer the right
>> distribution if given a module name.
>>
>>
>> Knowledge assumed by the CPAN site
>>
>> Given that a CPAN module page only offers a single Download link, and
>> that link points to an archive of the module's distribution, it's safe
>> to say that the CPAN site assumes that its users already know the
>> distinction between modules and distributions, and expects that the user
>> then refer to the documentation found within the downloaded archive.  I
>> suppose the reasoning is that an

[rt-users] REST API and acting as users

2014-12-10 Thread Andrew Ruthven 
Hey,

I'm looking at integrating RT with the OpenStack Horizon Dashboard for
at least ticket creation, ideally listing tickets and showing ticket
details for our customers.

The RESTful API appears to require logging in with credenials for the RT
user. Is it possible to masquerade as another user?

Given passwords are stored encrypted, I can't use the users passsword to
login. I might be able to cook up a RT::Authen::ExternalAuth plugin to
use the existing OpenStack tokens to allow SSO, I haven't look into that
yet.

Any assistance would be appreciated.

-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2015 
  New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
https://catalyst.net.nz/cloud | http://lca2015.linux.org.au

Re: [rt-users] plugins link to module file, not package file

2014-12-10 Thread Jo Rhett 
I’ve been using Perl for 20 years now. I grok perl.

Good run with the insults and rudeness. Because yeah, that’s a great way to 
treat someone who’s pointing out a way to improve the usability of something. 
Treat them like dirt, and talk down to them like they’ve never used Perl before.

I’ll stop offering advice on ways to improve the UI. Unintelligible and prone 
to confusion on the part of people isn’t my problem. I’m not going to be 
helpful if I get treated like shit when I’m trying to make someone’s 
profit-making production better and more likely to be used.

I forgot why I dropped this list. Thanks for reminding me.

On Dec 9, 2014, at 5:10 AM, Alex Peters  wrote:
> I feel that there are actually several issues to discuss in this thread:
> Perl modules vs. Perl module distributions
> Perl module distribution sources
> Perl module distribution installation
> knowledge assumed by the CPAN site
> knowledge assumed by RT's documentation
> what documentation should actually change
> Based on your description of the steps you performed in an attempt to install 
> a Perl module from CPAN, with all due respect, I believe you've been 
> improperly advised on Perl module installation and possibly haven't been made 
> aware of some crucial things about how Perl's modules work.  I'll go over 
> some of those things, then with everything in mind, maybe we can agree on 
> what documentation changes are needed where.
> 
> 
> Perl modules vs. Perl module distributions
> 
> A Perl module is (for all intents and purposes of this thread) a single .pm 
> file.  A Perl module distribution consists of a number of Perl modules (which 
> can be just one), a Makefile (or more commonly, a Makefile generator in 
> Makefile.PL), and instructions for installation of the distribution and hence 
> its modules (usually in README or INSTALL).  Distributions exist because 
> often, a single module isn't enough to provide some meaningful form of 
> functionality.
> 
> Modules are never installed directly.  Modules are always made available as a 
> side effect installing module distributions.  The distribution (not the 
> module) is the smallest unit involved in the action of installation.  
> Installation of a distribution might result in the installation of only one 
> module, but nonetheless, it's the distribution that's acted upon directly for 
> installation rather than the module.
> 
> In summary, direct installation of single modules doesn't happen.
> 
> 
> Perl module distribution sources
> 
> Distributions are typically (but not always) available on the CPAN site 
> (typically capitalised as "CPAN"), and can be downloaded as an archive.  
> Other distribution sources include (but are not limited to) GitHub, 
> Bitbucket, CD-ROMs, FTP sites and personal web pages.
> 
> In summary, distribution files can come from many different places.
> 
> 
> Perl module distribution installation
> 
> Every distribution includes installation instructions in README or INSTALL, 
> and the most typical experience for installing a Perl module distribution 
> (after obtaining an archive of it) goes like this:
> 
> $ tar xzf My-Perl-Module-0.01.tar.gz
> $ cd My-Perl-Module-0.01
> $ perl Makefile.PL
> $ make
> $ make test
> $ make install
> 
> Distributions on CPAN can be installed without first downloading an archive, 
> using the CPAN installation tool (typically capitalised as "cpan").  cpan is 
> actually smart enough to take a module name (rather than a distribution name) 
> on the command line, determine the distribution to which that module belongs, 
> and install that distribution.  Since one distribution generally depends on 
> others ("prerequisites") being installed in advance, cpan also manages the 
> installation of prerequisite distributions.  This makes the use of a tool 
> like cpan the generally preferred means of installing distributions (and by 
> extension, modules).
> 
> Other similar tools exist which do the job in a more streamlined fashion.  I 
> personally prefer cpanm.
> 
> In summary, distribution installation tools function on distributions, not 
> modules—although some tools have the ability to infer the right distribution 
> if given a module name.
> 
> 
> Knowledge assumed by the CPAN site
> 
> Given that a CPAN module page only offers a single Download link, and that 
> link points to an archive of the module's distribution, it's safe to say that 
> the CPAN site assumes that its users already know the distinction between 
> modules and distributions, and expects that the user then refer to the 
> documentation found within the downloaded archive.  I suppose the reasoning 
> is that anyone who knows about CPAN already knows about Perl modules, and how 
> to install module distributions.
> 
> I don't feel that the installation of Perl modules/distributions is within 
> the domain of RT's documentation.  However, given RT's use of Perl modules as 
> extensions, and that CPAN would probably be the main source for RT

Re: [rt-users] Errors on user logins --

2014-12-10 Thread Matt Wells 
Jeff my upgrade to V25 failed before.  This time it worked (well after two
attempts); thanks for the reply and the assist.

Lesson of the day read your output.

Thanks all!

On Wed, Dec 10, 2014 at 11:33 AM, Jeff Voskamp 
wrote:
>
> On 12/10/2014 01:09 PM, Matt Wells wrote:
>
>> I'm getting what seems to be a common error when users login.
>>
>> "The page you requested could not be found"
>> This is only with non-root users.
>>
>> When the users login it redirects to
>> https://rt.example.com/HASH(0x68193a8)
>>
>> If I remove the 'HASH(0x68193a8)' I get my dashboard.
>> I've cleaned out the mason cache and walked through many of the existing
>> 'how to' but to no avail.
>>
>> I've ensured that CPAN modules are all up to date.
>>
>> CentOS 6.6
>> RT 4.2.9
>>
>> ==> /var/log/httpd/error_log <==
>> [30947] [Wed Dec 10 17:22:23 2014] [info]:
>> RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK (
>> ldapserver_LDAP ): joe.bob
>> (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/
>> Authen/ExternalAuth/LDAP.pm:161)
>> [30947] [Wed Dec 10 17:22:23 2014] [info]:
>> RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1:
>> example, EmailAddress: joe@example.com ,
>> Name: joe.bob, RealName: Joe Bob, WorkPhone: 7025551234
>> (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/
>> Authen/ExternalAuth.pm:665)
>> [30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob
>> from 10.10.10.10
>> (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/
>> Authen/ExternalAuth.pm:341)
>>
>>
>> Thanks for any and all assistance.
>>
>
> Which version of RT::Authen::ExternalAuth are you using?
> Hint 0.25 would be the recommended version. There was a fix for this
> somewhere between 0.17 and 0.21 if I remember correctly.
>
> Jeff
>

Re: [rt-users] Installation error for RT 4.2.9 - cannot initialize database

2014-12-10 Thread Kristan Wagner 
Solved this issue. When I created the user 'root'@'10.10.10.3' on the 
MySQL server, I used this command:

GRANT ALL PRIVILEGES ON rt4.* TO 'root'@'10.10.10.3';

This gave the root user privileges to manipulate the database, but 
**not** to pass on their privileges to others. When I re-granted using 
this command:

GRANT ALL PRIVILEGES ON rt4.* TO 'root'@'10.10.10.3' WITH GRANT OPTION;

...the "Access denied" error vanished. I also had to readjust my 
RT_SiteConfig.pm back to using root as the db admin. Solved and archived 
for posterity. Thanks!





On 10 December 2014 at 01:56, Kristan Wagner 
> wrote:


I am having troubles with the database initialization, for a fresh
install of RT 4.2.9. The error message is: DBD::mysql::st execute
failed: Access denied for user 'root'@'10.10.10.3' to database
'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. make:
*** [initialize-database] Error 255

Here's my setup: Separate servers for the web frontend and the
database, both running Ubuntu 14.04. The web frontend is running
Apache/2.4.7 and has an IP address 10.10.10.3. The database
machine is running MySQL  5.5.40 and has the IP address
10.20.20.5.  Both of these are fresh installs, and RT is a fresh
install, but we plan to migrate our old RT database (3.6.5) when
the 4.2.9 is (eventually) running and tested.  Right now, I'm just
trying to get 4.2.9 going.

Here's the context for the error: I've been following the README
on the bestpractical website. At step 2, I ran configure with only
one flag,  --with-db-host=10.20.20.5. At step 4, fixdeps kept
claiming that MySQL was missing, so I had to install MySQL on the
web frontend as well, just to get it to install. At step 6a, make
initialize-database is failing with the following output:
root@10.10.10.3/tmp/rt-4.2.9#
 make initialize-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib
sbin/rt-setup-database --action init --prompt-for-dba-password
In order to create or update your RT database, this script needs
to connect to your  mysql instance on 10.20.20.5 (port '3306') as root
Please specify that user's database password below. If the user
has no database password, just press return.

Password:
Working with:
Type:   mysql
Host:   10.20.20.5
Port:   3306
Name:   rt4
User:   rtuser
DBA:root
Now creating a mysql database rt4 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs.
[23346] [Mon Dec  8 21:27:35 2014] [warning]: DBD::mysql::st
execute failed: Access denied for user 'root'@'10.10.10.3' to
database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
(/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm:452)
[23346] [Mon Dec  8 21:27:35 2014] [critical]: DBD::mysql::st
execute failed: Access denied for user 'root'@'10.10.10.3' to
database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
(/tmp/rt-4.2.9/sbin/../lib/RT.pm:388)
DBD::mysql::st execute failed: Access denied for user
'root'@'10.10.10.3' to database 'rt4' at
/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.
make: *** [initialize-database] Error 255

I've spent a lot of time reading forum questions about
mysqld.sock, but please note that there is NO mention of any
socket trouble in the error, so I don't think that's it. Plus,
it's able to get through the first two steps just fine.

Here is some of RT_SiteConfig.pm from the web frontend:
Set($DatabaseHost, '10.20.20.5' );
Set($DatabasePort, "3306");
Set($DatabasePassword, q{passwordhere});
Set($DatabaseUser, "rtuser");
Set($DatabaseName, q{rt4});

On the database server, here is some of my.cnf:
[mysqld]
user= mysql
pid-file= /var/run/mysqld/mysqld.pid
socket  = /var/run/mysqld/mysqld.sock
port= 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir  = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address   = 0.0.0.0

I've already tried this using the option skip-name-resolve, but
that did not help.

Here are the permissions for the root user, as shown on
10.20.20.5's MySQL instance:

++
| Grants for root@10.10.10.3 

++
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.10.10.3' IDENTIFIED BY
PASSWORD '*hash'
| GRANT ALL PRIVILEGES ON `rt4`.* TO 'root'@'10.10.10.3'

+---

Re: [rt-users] Errors on user logins --

2014-12-10 Thread Jeff Voskamp 

On 12/10/2014 01:09 PM, Matt Wells wrote:

I'm getting what seems to be a common error when users login.

"The page you requested could not be found"
This is only with non-root users.

When the users login it redirects to
https://rt.example.com/HASH(0x68193a8)

If I remove the 'HASH(0x68193a8)' I get my dashboard.
I've cleaned out the mason cache and walked through many of the existing
'how to' but to no avail.

I've ensured that CPAN modules are all up to date.

CentOS 6.6
RT 4.2.9

==> /var/log/httpd/error_log <==
[30947] [Wed Dec 10 17:22:23 2014] [info]:
RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK (
ldapserver_LDAP ): joe.bob
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:161)
[30947] [Wed Dec 10 17:22:23 2014] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1:
example, EmailAddress: joe@example.com ,
Name: joe.bob, RealName: Joe Bob, WorkPhone: 7025551234
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:665)
[30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob
from 10.10.10.10
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:341)


Thanks for any and all assistance.


Which version of RT::Authen::ExternalAuth are you using?
Hint 0.25 would be the recommended version. There was a fix for this 
somewhere between 0.17 and 0.21 if I remember correctly.


Jeff

[rt-users] Errors on user logins --

2014-12-10 Thread Matt Wells 
I'm getting what seems to be a common error when users login.

"The page you requested could not be found"
This is only with non-root users.

When the users login it redirects to
https://rt.example.com/HASH(0x68193a8)

If I remove the 'HASH(0x68193a8)' I get my dashboard.
I've cleaned out the mason cache and walked through many of the existing
'how to' but to no avail.

I've ensured that CPAN modules are all up to date.

CentOS 6.6
RT 4.2.9

==> /var/log/httpd/error_log <==
[30947] [Wed Dec 10 17:22:23 2014] [info]:
RT::Authen::ExternalAuth::LDAP::GetAuth External Auth OK ( ldapserver_LDAP
): joe.bob
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:161)
[30947] [Wed Dec 10 17:22:23 2014] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Address1: example,
EmailAddress: joe@example.com, Name: joe.bob, RealName: Joe Bob,
WorkPhone: 7025551234
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:665)
[30947] [Wed Dec 10 17:22:23 2014] [info]: Successful login for joe.bob
from 10.10.10.10
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:341)


Thanks for any and all assistance.

[rt-users] RT-Extension-AceEditor

2014-12-10 Thread Rémi 
Hi list,

Here is an extension that replace the default scrip edition textarea with
the embeded Ace editor (http://ace.c9.io)

https://github.com/valmiRe/rt-extension-aceeditor

Rémi

Re: [rt-users] Installation error for RT 4.2.9 - cannot initialize database

2014-12-10 Thread Kristan Wagner 
Thanks for the suggestion. I've tried it, but unfortunately, it 
recreated the same error:

root@10.10.10.3:/tmp/rt-4.2.9# make initialize-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database 
--action init --prompt-for-dba-password
In order to create or update your RT database, this script needs to 
connect to your  mysql instance on 10.20.20.5 (port '3306') as rtuser
Please specify that user's database password below. If the user has no 
database

password, just press return.

Password:
Working with:
Type:   mysql
Host:   10.20.20.5
Port:   3306
Name:   rt4
User:   rtuser
DBA:rtuser
Now creating a mysql database rt4 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs.
[32233] [Wed Dec 10 16:55:31 2014] [warning]: DBD::mysql::st execute 
failed: Access denied for user 'rtuser'@'%' to database 'rt4' at 
/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. 
(/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm:452)
[32233] [Wed Dec 10 16:55:31 2014] [critical]: DBD::mysql::st execute 
failed: Access denied for user 'rtuser'@'%' to database 'rt4' at 
/tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. 
(/tmp/rt-4.2.9/sbin/../lib/RT.pm:388)
DBD::mysql::st execute failed: Access denied for user 'rtuser'@'%' to 
database 'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452.

make: *** [initialize-database] Error 255

I keep wondering why it keeps getting stuck on the step "Now inserting 
database ACLs." Are those handled differently from the previous steps or 
creating and populating the database?


For reference, here are the permissions for rtuser:
+---+
| Grants for rtuser@%
+---+
| GRANT USAGE ON *.* TO 'rtuser'@'%' IDENTIFIED BY PASSWORD '*hash'
| GRANT ALL PRIVILEGES ON `rt4`.* TO 'rtuser'@'%'
| GRANT ALL PRIVILEGES ON `rt4test`.* TO 'rtuser'@'%'
+---+





On 12/10/2014 2:56 AM, Alex Peters wrote:

You're doing this:

# make initialize-database

which is in turn running this:

# /usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib 
sbin/rt-setup-database --action init --prompt-for-dba-password


which is going to connect to the database as the RT "DBA user" 
(RT_Config setting $DatabaseAdmin), which according to your pasted output:


In order to create or update your RT database, this script needs to 
connect to your  mysql instance on 10.20.20.5 (port '3306') as root


is "root".

Going off your RT_SiteConfig.pm snippet, you actually want to connect 
to the database as user "rtuser".  Therefore, adding this to 
RT_SiteConfig.pm might solve your issue:


Set($DatabaseAdmin, "rtuser");





On 10 December 2014 at 01:56, Kristan Wagner 
> wrote:


I am having troubles with the database initialization, for a fresh
install of RT 4.2.9. The error message is: DBD::mysql::st execute
failed: Access denied for user 'root'@'10.10.10.3' to database
'rt4' at /tmp/rt-4.2.9/sbin/../lib/RT/Handle.pm line 452. make:
*** [initialize-database] Error 255

Here's my setup: Separate servers for the web frontend and the
database, both running Ubuntu 14.04. The web frontend is running
Apache/2.4.7 and has an IP address 10.10.10.3. The database
machine is running MySQL  5.5.40 and has the IP address
10.20.20.5.  Both of these are fresh installs, and RT is a fresh
install, but we plan to migrate our old RT database (3.6.5) when
the 4.2.9 is (eventually) running and tested.  Right now, I'm just
trying to get 4.2.9 going.

Here's the context for the error: I've been following the README
on the bestpractical website. At step 2, I ran configure with only
one flag,  --with-db-host=10.20.20.5. At step 4, fixdeps kept
claiming that MySQL was missing, so I had to install MySQL on the
web frontend as well, just to get it to install. At step 6a, make
initialize-database is failing with the following output:
root@10.10.10.3/tmp/rt-4.2.9#
 make initialize-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib
sbin/rt-setup-database --action init --prompt-for-dba-password
In order to create or update your RT database, this script needs
to connect to your  mysql instance on 10.20.20.5 (port '3306') as root
Please specify that user's database password below. If the user
has no database password, just press return.

Password:
Working with:
Type:   mysql
Host:   10.20.20.5
Port:   3306
Name:   rt4
User:   rtuser
DBA:root
Now creating a mysql database rt4 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs.
[23346] [Mon Dec  8 21:27:35 201

Re: [rt-users] Default Configuration RT

2014-12-10 Thread Renato Gentil 
Alex, 
I'm trying to drop but I'm getting the error attached.I'm using the following 
command:
mysqladmin -u root -p  drop
but then I got the error attached and I also tried:
mysqladmin -u root -p droppassword: 
another error attached.
Thanks,

Renato Gentil 


Date: Wed, 10 Dec 2014 23:20:30 +1100
Subject: Re: [rt-users] Default Configuration RT
From: a...@peters.net
To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com

Hi Renato,
What exactly did you try, and what happened?  Going into MySQL, dropping the 
database (or all of its tables) and running the sbin/rt-setup-database script 
would restore all of your templates and scrips.  Specifically, you would 
probably do this if your MySQL user has the permissions to drop the database:
$ cd $ sbin/rt-setup-database --action 
drop,create,schema,acl,coredata,insert --dba  
--prompt-for-dba-password
You can pass "--help" to the rt-setup-database script for further details.  
Remove "drop,create," from the above line if you'd like to manually remove all 
of the tables first (using mysql).
Please let us know how you go (using "Reply All").
On 10 December 2014 at 23:02, Renato Gentil  
wrote:



Hi Alex,
I tried it but didn't work for me. Basically I'm trying to restore the default 
templates and scripts because I have deleted some of them and now some of our 
features have been gone with them.
Can you help me with that ?
thanks,


Renato Gentil 


From: a...@peters.net
Date: Wed, 10 Dec 2014 01:12:06 +
Subject: Re: [rt-users] Default Configuration RT
To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com

You could drop the database and set it up again, or also completely uninstall 
and reinstall RT.

Re: [rt-users] Capturing 'Started' Value

2014-12-10 Thread John White 
Our company does not want to upgrade, so I need to figure it out in this 
version.  Any thoughts?

John



John White
Application Support Lead

+1.301.214.7600 main
+1.301.214.6362 direct
+1.301.214.7601 fax
+1.703.615.4986 cellular

-Original Message-
From: Alex Vandiver [mailto:ale...@bestpractical.com]
Sent: Tuesday, December 09, 2014 11:34 AM
To: John White; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Capturing 'Started' Value

On 12/09/2014 08:34 AM, john.white wrote:
> This is for RT ver. 3.8.2.  I'm trying to capture the "Started" field
> value in the Dates block and place it in a Custom Field (called
> Started
> Date) so that I can output that data in the spread sheet reports to
> perform metrics (don't see how to output that data to the spreadsheets
> any other way).

This  trivial in RT 4.0 and later -- the column list that is displayed is the 
set of columns that are exported in the spreadsheet.
Additionally, upgrading to a supported release means you won't be running an RT 
with publicly disclosed remote exploits.

 - Alex



This email, including any attachments and files transmitted with it, are for 
the sole use of the intended recipient(s) to whom this email is addressed, and 
may contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please be advised that you have received this email in 
error, and please contact the sender by reply email and destroy all copies 
(including all electronic and hard copies) of the original message. Thank you.

Re: [rt-users] Default Configuration RT

2014-12-10 Thread Alex Peters 
Hi Renato,

What exactly did you try, and what happened?  Going into MySQL, dropping
the database (or all of its tables) and running the sbin/rt-setup-database
script would restore all of your templates and scrips.  Specifically, you
would probably do this if your MySQL user has the permissions to drop the
database:

$ cd 
$ sbin/rt-setup-database --action drop,create,schema,acl,coredata,insert
--dba  --prompt-for-dba-password

You can pass "--help" to the rt-setup-database script for further details.
Remove "drop,create," from the above line if you'd like to manually remove
all of the tables first (using mysql).

Please let us know how you go (using "Reply All").

On 10 December 2014 at 23:02, Renato Gentil 
wrote:

> Hi Alex,
>
> I tried it but didn't work for me. Basically I'm trying to restore the
> default templates and scripts because I have deleted some of them and now
> some of our features have been gone with them.
>
> Can you help me with that ?
>
> thanks,
>
>
>
> Renato Gentil
>
>
> --
> From: a...@peters.net
> Date: Wed, 10 Dec 2014 01:12:06 +
> Subject: Re: [rt-users] Default Configuration RT
> To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com
>
> You could drop the database and set it up again, or also completely
> uninstall and reinstall RT.
>