Re: [rt-users] Custom Fields won't show up when viewing RT through MediaWiki
Ruslan,
I was really confused by that too at first. The code on that page
must have been from a different version, the current code (which I
verified we are using) goes like this:
224 // Allow use of custom fields
225 $searchcustom = '';
226 if ( array_key_exists('custom', $args ) ) {
227 $searchcustom = trim( $args['custom'] );
228 $cfargs = trim( strtolower(
$args['custom'] ) );
229 $ticketquery .= ', customfields cf,
objectcustomfieldvalues ov';
230 $whereclause .= \nAND ov.objectid =
t.id\nAND ov.customfield=cf.id\nAND ov.disabled = 0;
231 $whereclause .= \nAND LOWER(cf.name) IN (;
232 foreach ( preg_split( '/\s*,\s*/', $cfargs
) as $word ) {
233 $word = trim( $word );
234 if ( !preg_match( '/^[\w \.-]+$/',
$word ) ) {
235 die ( wfMsg (
'rt-badcfield', $word ) );
236 }
237 $whereclause .= '$word',;
238 $ticketquery = preg_replace(
'/COALESCE/', \nov.content AS custom, COALESCE, $ticketquery);
239 }
240 $whereclause = preg_replace( '/.$/', ')',
$whereclause );
241 }
This is in RT_body.php, can be found here:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/RT.git;a=tree
-Scott
On 5/11/2012 4:38 PM, Ruslan Zakirov wrote:
On Fri, May 11, 2012 at 10:44 PM, Scott Pestana
scott.pest...@linguamatics.com wrote:
All,
We're using MediaWiki + RT to allow us to track issues currently open,
issues attributed to a customer's company, that kind of thing. However we
aren't able to get Custom Fields to be displayed when we use them:
rt custom=Customer/rt
We have only 4 Custom Fields, but none of them are displayed when we try
to pull them out. Is anyone else having this experience? For information,
we are using the replace Postgres with MySQL hack from this page:
http://www.mediawiki.org/wiki/Extension_talk:RT
I'm wondering if the MySQL alternative doesn't have the same way of
pulling the Custom Fields out the same way Postgres does. Thoughts?
As far as I can see code on the linked page has no any kind of support
of custom fields. Code linked from the primary page does mention
custom fields, but it's not to display them, but to filter by them.
--
N. Scott Pestana
IT Infrastructure
Linguamatics
--
N. Scott Pestana
IT Infrastructure
Linguamatics
[rt-users] One more Question About LDAP Import Extension
All,
We are happy with LDAP Import, with the following mapping:
Set($LDAPMapping, { 'Name' = 'uid',
'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid',
'Gecos' = 'gecos'
}
);
We're trying to figure out though; which is the key RT checks to
see if users already exist? When running in debug mode we get this output:
Processing user spestana
User spestana already exists as 494, skipping
Imported 38/48 users
But there's no way of knowing if that's the Name, or the
ExternalAuthId. Can you give us some insight here? Right now, my
inspection of the code has me feeling this defaults to the first field
listed by the LDAPMapping.
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
Re: [rt-users] One more Question About LDAP Import Extension
Johnathan,
I used perl -d to traverse the execution of rtldapimport, and found
that the module uses the Name field; it automatically assumes the Name
field is one of the fields in the mapping. It does a test on the
LDAP-RT mapping, but only to determine if one exists, not that it
explicitly includes the Name field. I found code that explicitly picked
Name as a hash key from the RT field names to query (and without
quotes... *shudder*).
I could be completely wrong about all of this, I'd love to be
corrected if Mr. Falcone (the author) has some free time.
-Scott
On 4/23/2012 2:25 PM, johnathan.b...@baker.edu wrote:
In our instance, it seems that the username is keyed on email address
(even though we've got only the 'Name' field as the mapping for
logins)… I'd check that. The main reason for this, as I understand it,
is that even though you may specify some other field, RT still needs
to have a way of interpreting this when you've users replying to
tickets via email--the email address is the only thing the server has
to go on.
Then again, I may be way off base.
- Johnathan
On Apr 23, 2012, at 12:26 PM, Scott Pestana wrote:
All,
We are happy with LDAP Import, with the following mapping:
Set($LDAPMapping, { 'Name' = 'uid',
'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid',
'Gecos' = 'gecos'
}
);
We're trying to figure out though; which is the key RT checks to
see if users already exist? When running in debug mode we get this
output:
Processing user spestana
User spestana already exists as 494, skipping
Imported 38/48 users
But there's no way of knowing if that's the Name, or the
ExternalAuthId. Can you give us some insight here? Right now, my
inspection of the code has me feeling this defaults to the first
field listed by the LDAPMapping.
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com http://www.linguamatics.com
--
Johnathan Bell
Internet System Administrator, Baker College
Office Hours: 7A-4P Eastern, M-F
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
Re: [rt-users] RT Extension LDAPImport Using LDAPS?
Hi, It looks like the issue I have with those extra [critical] messages may be resolved by a newer version that Kevin has released as a dev release. Without modifying my original configuration the release candidate from March 2012 reports only the [info] output. -Scott On 4/9/2012 4:58 PM, Thomas Sibley wrote: On 04/09/2012 04:50 PM, Scott Pestana wrote: [Mon Apr 9 19:51:49 2012] [critical]: RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for ((|(objectClass=posixAccount)(objectClass=account))(mail=userem...@linguamatics.com)) failed: LDAP_NO_SUCH_OBJECT 32 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232) [Mon Apr 9 19:51:49 2012] [critical]: RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for ((|(objectClass=posixAccount)(objectClass=account))(uid=USERID)) failed: LDAP_NO_SUCH_OBJECT 32 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232) You'll note these errors are from RT-Authen-ExternalAuth, not RT-Extension-LDAPImport. Please show us the config for ExternalAuth. For each user we get the above two critical errors, and the below info message (which I don't mind aside from the Disabled part): Those critical errors are passed along from your LDAP server. [Mon Apr 9 19:51:49 2012] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Disabled: , EmailAddress: userem...@linguamatics.com, ExternalAuthId: USERID, Gecos: USERFULLNAME, Name: USERID, Privileged: 1, RealName: USERFULLNAME (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:651) This is just an informational message. Disabled: is blank, so that's fine. When I inspected the MySQL tables that were created, I found that all the users appeared to be created as I wanted. I am having trouble with the Web view at the moment, so I need to verify them through that view as well. This is probably because you're only looking at privileged users in the admin interface and LDAPImport creates unprivileged users. You can search for them using the form on the admin page. Thomas -- N. Scott Pestana IT Infrastructure Linguamatics 275 Grove Street, Suite 2-400 Newton, MA 02466 Tel: +1-774-571-7135 US Tel: +1-617-674-3256 UK Tel: 011-44-1223-421360 UK Fax: 011-44-1223-421361 Web: www.linguamatics.com
Re: [rt-users] RT Extension LDAPImport Using LDAPS?
Thomas,
Here is the RT-Authen-ExternalAuth. As you can see, some of this
information is re-used for multiple RT Extensions. Is there an PERL/RT
approved way of creating variables that can be passed to these Set()
statements? Is it as simple as declaring the variables and passing them
into the Set() statements like in a normal script?
Set($WebExternalAuth, 1);
Set($WebExternalAuto, 1);
Set($AutoCreate, {Privileged=1});
Set($ExternalAuthPriority, ['Lingua_LDAP']);
Set($ExternalInfoPriority, ['Lingua_LDAP']);
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {
'Lingua_LDAP' = {
'type' = 'ldap',
'server'= 'OURLDAPS.linguamatics.com',
'port' = '636',
'ca_path' = '/etc/openldap/cacerts/',
'user' =
'uid=OURSYSTEMACCOUNT,dc=linguamatics,dc=com',
'pass' = 'OURSYSTEMACCOUNTPW',
'base' =
'ou=OURUSERTREE,dc=linguamatics,dc=com',
'filter'=
'(|(objectClass=posixAccount)(objectClass=account))',
'tls' = 0,
'net_ldap_args' = [ version = 3 ],
'attr_match_list' = [ 'EmailAddress',
'ExternalAuthId' ],
'attr_map' = { 'Name' = 'uid',
'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid',
'Gecos' = 'gecos'
}
}
});
I'm surprised that our LDAP server is throwing critical errors,
because I believe that the information has been set up properly.
Having a Disabled: , is a bit confusing, but if that's valid as
designed ok.
I'm not having trouble finding the users in the web view, I'm
having trouble with the web view at all. But this is an internal
reverse proxy issue, not related to RT. Interrogating the SQL tables RT
creates shows the users with all the fields I wanted to check, but I
don't see a quick way to tell from the SQL data whether a user is
Privileged or not. If you want to pass me a clue I'd like to have that
crib note for when looking at the raw SQL data. Otherwise I can wait
until I get our internal issue cleared out.
-Scott
On 4/9/2012 4:58 PM, Thomas Sibley wrote:
On 04/09/2012 04:50 PM, Scott Pestana wrote:
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
((|(objectClass=posixAccount)(objectClass=account))(mail=userem...@linguamatics.com))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
((|(objectClass=posixAccount)(objectClass=account))(uid=USERID))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
You'll note these errors are from RT-Authen-ExternalAuth, not
RT-Extension-LDAPImport. Please show us the config for ExternalAuth.
For each user we get the above two critical errors, and the below
info message (which I don't mind aside from the Disabled part):
Those critical errors are passed along from your LDAP server.
[Mon Apr 9 19:51:49 2012] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Disabled: ,
EmailAddress: userem...@linguamatics.com, ExternalAuthId: USERID, Gecos:
USERFULLNAME, Name: USERID, Privileged: 1, RealName: USERFULLNAME
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:651)
This is just an informational message. Disabled: is blank, so that's fine.
When I inspected the MySQL tables that were created, I found that
all the users appeared to be created as I wanted. I am having trouble
with the Web view at the moment, so I need to verify them through that
view as well.
This is probably because you're only looking at privileged users in the
admin interface and LDAPImport creates unprivileged users. You can
search for them using the form on the admin page.
Thomas
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
[rt-users] RT Extension LDAPImport Using LDAPS?
RT Gents,
I'm having trouble setting up LDAPImport over LDAPS. The README
with the package on CPAN details set up and includes Hostname or
ldap(s):// uri which suggests to me that secure transmission should
work. I have settings in RT_SiteConfig.pm for Security, but I don't see
a specific flag for the Extension::LDAPImport package to set that secure
communication is requested.
I run into the following error trying to run rtldapimport:
[root@owlwoman bin]# ./rtldapimport
Running test import, no data will be changed
Rerun command with --import to perform the import
Rerun command with --debug for more information
[Mon Apr 9 18:19:15 2012] [error]: LDAP search failed No such object
(/opt/rt4/local/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:866)
LDAP search failed No such object
Testing group import
[Mon Apr 9 18:19:15 2012] [warning]: Not running a group import,
configuration not set
(/opt/rt4/local/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:874)
Not running a group import, configuration not set
Finished test
Digging into the PERL code being executed by rtldapimport, I found
that the LDAP object can't be created because the configuration being
used is insecure:
DB9 x $ldap
0 Net::LDAP=HASH(0x5af6f00)
'net_ldap_async' = 0
'net_ldap_debug' = 0
'net_ldap_host' = 'OURLDAPS.linguamatics.com'
'net_ldap_port' = 389
'net_ldap_refcnt' = 1
'net_ldap_resp' = HASH(0x86044f0)
empty hash
'net_ldap_scheme' = 'ldap'
'net_ldap_socket' = IO::Socket::INET=GLOB(0x8604718)
- *Symbol::GEN46
FileHandle({*Symbol::GEN46}) = fileno(8)
'net_ldap_uri' = 'OURLDAPS.linguamatics.com'
'net_ldap_version' = 3
What flags do I need to set for rtldapimport to use secure
communication when doing the import? I have set $LDAPUser and
$LDAPPassword in the RT_SiteConfig.pm but aren't reflected here either
(perhaps they are applied later).
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
Re: [rt-users] RT Extension LDAPImport Using LDAPS?
Thomas, That was all I needed to change. For some reason in my head LDAPHost was to (strictly) take the form of a FQDN. Thanks for your help: Found new user *** to create in RT Found... ... etc. -Scott On 4/9/2012 2:37 PM, Thomas Sibley wrote: On 04/09/2012 02:25 PM, Scott Pestana wrote: RT Gents, I'm having trouble setting up LDAPImport over LDAPS. The README with the package on CPAN details set up and includes Hostname or ldap(s):// uri which suggests to me that secure transmission should work. I have settings in RT_SiteConfig.pm for Security, but I don't see a specific flag for the Extension::LDAPImport package to set that secure communication is requested. Please show us your RT_SiteConfig.pm (with passwords redacted). I suspect you have: Set($LDAPHost, 'ourldaps.linguamatics.com'); rather than what the doc suggests of: Set($LDAPHost, 'ldaps://ourldaps.linguamatics.com'); Thomas -- N. Scott Pestana IT Infrastructure Linguamatics 275 Grove Street, Suite 2-400 Newton, MA 02466 Tel: +1-774-571-7135 US Tel: +1-617-674-3256 UK Tel: 011-44-1223-421360 UK Fax: 011-44-1223-421361 Web: www.linguamatics.com
Re: [rt-users] RT Extension LDAPImport Using LDAPS?
Kevin,
Thomas's notes helped me get my import working. Users are now
imported into our RT instance. However we do get a lot of noise:
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
((|(objectClass=posixAccount)(objectClass=account))(mail=userem...@linguamatics.com))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
((|(objectClass=posixAccount)(objectClass=account))(uid=USERID))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
For each user we get the above two critical errors, and the below
info message (which I don't mind aside from the Disabled part):
[Mon Apr 9 19:51:49 2012] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Disabled: ,
EmailAddress: userem...@linguamatics.com, ExternalAuthId: USERID, Gecos:
USERFULLNAME, Name: USERID, Privileged: 1, RealName: USERFULLNAME
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:651)
When I inspected the MySQL tables that were created, I found that
all the users appeared to be created as I wanted. I am having trouble
with the Web view at the moment, so I need to verify them through that
view as well.
For reference, here are the settings / bindings from RT_SiteConfig.pm
Set($LDAPHost,'ldaps://OURLDAPS.linguamatics.com');
Set($LDAPUser,'uid=OURBINDUSER,dc=linguamatics,dc=com');
Set($LDAPPassword, 'OURBINDPW');
Set($LDAPBase, 'ou=OURUSERTREE,dc=linguamatics,dc=com');
Set($LDAPFilter, '(|(objectClass=posixAccount)(objectClass=account))');
Set($LDAPMapping, { 'Name' = 'uid',
'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid',
'Gecos' = 'gecos'
}
);
Set($LDAPCreatePrivileged, 1);
#For now we don't need groups, from what I can tell so:
#Set($LDAPGroupName, 'Imported Users');
#The previous line is commented out and we use this line:
Set($LDAPSkipAutogeneratedGroup, 1);
Set($LDAPUpdateUsers, 0);
Set($LDAPUpdateOnly, 0);
#Set($LDAPGroupBase, '');
#Set($LDAPGroupFilter, '');
#Set($LDAPGroupMapping, { });
Please let me know if anything jumps out at you about why we're
generating so many critical messages. Otherwise, I'm more or less
happy with how RT Extension LDAPImport works, inspecting the data sent
into the MySQL database showed me data that looked good.
-Scott
On 4/9/2012 3:10 PM, Kevin Falcone wrote:
On Mon, Apr 09, 2012 at 02:25:47PM -0400, Scott Pestana wrote:
I'm having trouble setting up LDAPImport over LDAPS. The README
with the package on CPAN details set up and includes Hostname or
ldap(s):// uri which suggests to me that secure transmission should
work. I have settings in RT_SiteConfig.pm for Security, but I don't
see a specific flag for the Extension::LDAPImport package to set
that secure communication is requested.
I run into the following error trying to run rtldapimport:
[root@owlwoman bin]# ./rtldapimport
Running test import, no data will be changed
Rerun command with --import to perform the import
Rerun command with --debug for more information
[Mon Apr 9 18:19:15 2012] [error]: LDAP search failed No such
object
(/opt/rt4/local/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:866)
LDAP search failed No such object
Testing group import
[Mon Apr 9 18:19:15 2012] [warning]: Not running a group import,
configuration not set
(/opt/rt4/local/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:874)
Not running a group import, configuration not set
Finished test
Please show your LDAPimport configuration for LDAPHost / LDAPUser and
a sanitized version of LDAPPassword.
Your port # implies that Net::LDAP didn't think you needed ssl.
-kevin
Digging into the PERL code being executed by rtldapimport, I
found that the LDAP object can't be created because the
configuration being used is insecure:
DB9 x $ldap
0 Net::LDAP=HASH(0x5af6f00)
'net_ldap_async' = 0
'net_ldap_debug' = 0
'net_ldap_host' = 'OURLDAPS.linguamatics.com'
'net_ldap_port' = 389
'net_ldap_refcnt' = 1
'net_ldap_resp' = HASH(0x86044f0)
empty hash
'net_ldap_scheme' = 'ldap'
'net_ldap_socket' = IO::Socket::INET=GLOB(0x8604718)
- *Symbol::GEN46
FileHandle({*Symbol::GEN46}) = fileno(8)
'net_ldap_uri' = 'OURLDAPS.linguamatics.com'
'net_ldap_version' = 3
What flags do I need to set for rtldapimport to use secure
communication when doing the import? I have set $LDAPUser and
$LDAPPassword in the RT_SiteConfig.pm but aren't reflected here
either (perhaps they are applied later).
--
N. Scott Pestana
IT Infrastructure
Linguamatics
Re: [rt-users] Problems with new users
Can someone take a look at the RT_SiteConfig.pm I have set up, let
me know if we're doing anything wrong here?
Based of the conversations I've had I think I need to make these
changes:
- Set($AutoCreate, {Privileged=1});
+ Set($AutoCreate, {Privileged=0});
-'attr_match_list' = [ 'EmailAddress' ]
+ 'attr_match_list' = [ 'EmailAddress',
+'uid' ],
-Scott
On 2/14/2012 5:44 PM, Kevin Falcone wrote:
On Tue, Feb 14, 2012 at 04:36:19PM -0500, Scott Pestana wrote:
That's correct, we don't want him to have special privileges;
other than the ability to see status of tickets that he
opened/requested. Oddly enough we have another employee who started
at roughly the same time as Ian, and Tracy doesn't have this issue,
nor does she have an un-privileged Privileged User. When she logs
in she gets a view similar to mine (I'm on IT Support, have
privileges, and haven't had an issue). At least that's what my
memory tells me. I'm going to check on this tomorrow to see what
her experience as a user is, I could be wildly wrong about this.
This sounds like you may want this user to just be Unprivileged and
use the SelfService interface. You'll still need to hand out some
rights so that Requestors can see their own tickets, etc.
However, you can go compare this user and Tracy's group memberships
from the Memberships tab on their user page and I suspect Tracy will
be in groups and Ian isn't or that Tracy has tickets requested but Ian
doesn't. Also, if Ian's user record had no Email Address then RT has
no way to associate his tickets with the logged in user (See my later
comment about how RT can't know the user's email address).
When he logs in and goes to the RT at a glance page (
rt/index.html ), his view (to me) implies he's associated with a
queue that was originally set up for testing.
What about it makes you think he is accessing a testing queue?
It just sounds like he has no rights in the system.
I'm not sure I understand it either. ;) We are using a rather
complex set up with apache spread across multiple servers performing
different roles, all united by SSO on the apache instance acting as
a gateway. The credentials are (I believe) passed through so an
employee only needs to authenticate once for all of our internal
resources. We are also getting closer to using Kerberos/Domain
authentication for seamless SSO for our windows users.
That makes more sense, you're authing with SSO and trying to pull
information from LDAP. However, your LDAP is keyed to look up on
email address and when someone logs in via the web UI, there's no way
to have their email address (think about it, RT only gets the username
they logged in with, not their email address which is stored in LDAP).
Often, ExternalAuth is keyed to look up on Username *and*
EmailAddress, but yours is configured for just EmailAddress.
Based on this I think our issues stem from him logging in via
the web before opening a ticket via email. Funnily enough when he
emailed IT support for help with something around the office, the RT
system worked like a charm. I'm starting to think I may be
over-thinking this entire situation...
This also supports my above comment, since someone emailing into your
system *would* be able to find their LDAP account, because RT has
their email account.
It sounds like many of these problems could be solved with
RT-Extension-LDAPImport pulling users into the system so they'll exist
before sending email or logging into the system.
-kevin
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston --- March 5 6, 2012
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
# Any configuration directives you include here will override
# RT's default configuration file, RT_Config.pm
#
# To include a directive here, just copy the equivalent statement
# from RT_Config.pm and change the value. We've included a single
# sample value below.
#
# This file is actually a perl module, so you can include valid
# perl code, as well.
#
# The converse is also true, if this file isn't valid perl, you're
# going to run into trouble. To check your SiteConfig file, use
# this comamnd:
#
# perl -c /path/to/your/etc/RT_SiteConfig.pm
#
# You must restart your webserver after making changes to this file.
Set( $rtname, 'Linguamatics Dev');
# You must install Plugins on your own, this is only an example
# of the correct syntax to use when activating them.
# There should only be one @Plugins declaration in your config file.
#Set(@Plugins,(qw(RT::Extension::QuickDelete RT::Extension::CommandByMail)));
Set(@Plugins, qw(RT::Authen::ExternalAuth));
Set($rtname, 'Linguamatics');
Set($Organization
Re: [rt-users] Problems with new users
Kevin,
We're setting up a new development RT server to try to pick apart
our issues (and also as a staging platform for RT upgrades). In that
spirit I thought I'd ask you to look over the RT_SiteConfig.pm I've set
up based on our existing instances (don't worry its short, and
attached). After our conversations, I think I want to make these changes:
- Set($AutoCreate, {Privileged=1});
+ Set($AutoCreate, {Privileged=0});
-'attr_match_list' = [ 'EmailAddress' ]
+ 'attr_match_list' = [ 'EmailAddress',
+'uid' ],
Then I will want to install from CPAN RT::Extension::LDAPImport.pm
(hm, that author's name seems familiar...) and then set up a
RT_User_Update.pl script that will look something like this (based on
the CPAN documentation):
#/usr/bin/perl
#RT_User_Update.pl - NSP 20120222
use RT;
use RT::Extension::LDAPImport;
Set($LDAPHost,'ldap://ldapserver.linguamatics.com');#CPAN leaves
out the $
Set($LDAPUSER,'');
# again
Set($LDAPPassword,'');
# and again
connect_ldap();
#Mirror RT_SiteConfig.pm for the Attribute Mapping:
Set($LDAPMapping, { 'Name' = 'uid', 'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid', 'Gecos' = 'gecos' };
#Pull in the records since last time:
import_users( 'import' = 1 );
#Clean up
disconnect_ldap();
1;
And then we'll run that perl script on our RT server (owlwoman,
etc) whenever new employees come on board (and have been entered into
LDAP). Does this make sense?
-Scott
On 2/14/2012 5:44 PM, Kevin Falcone wrote:
On Tue, Feb 14, 2012 at 04:36:19PM -0500, Scott Pestana wrote:
That's correct, we don't want him to have special privileges;
other than the ability to see status of tickets that he
opened/requested. Oddly enough we have another employee who started
at roughly the same time as Ian, and Tracy doesn't have this issue,
nor does she have an un-privileged Privileged User. When she logs
in she gets a view similar to mine (I'm on IT Support, have
privileges, and haven't had an issue). At least that's what my
memory tells me. I'm going to check on this tomorrow to see what
her experience as a user is, I could be wildly wrong about this.
This sounds like you may want this user to just be Unprivileged and
use the SelfService interface. You'll still need to hand out some
rights so that Requestors can see their own tickets, etc.
However, you can go compare this user and Tracy's group memberships
from the Memberships tab on their user page and I suspect Tracy will
be in groups and Ian isn't or that Tracy has tickets requested but Ian
doesn't. Also, if Ian's user record had no Email Address then RT has
no way to associate his tickets with the logged in user (See my later
comment about how RT can't know the user's email address).
When he logs in and goes to the RT at a glance page (
rt/index.html ), his view (to me) implies he's associated with a
queue that was originally set up for testing.
What about it makes you think he is accessing a testing queue?
It just sounds like he has no rights in the system.
I'm not sure I understand it either. ;) We are using a rather
complex set up with apache spread across multiple servers performing
different roles, all united by SSO on the apache instance acting as
a gateway. The credentials are (I believe) passed through so an
employee only needs to authenticate once for all of our internal
resources. We are also getting closer to using Kerberos/Domain
authentication for seamless SSO for our windows users.
That makes more sense, you're authing with SSO and trying to pull
information from LDAP. However, your LDAP is keyed to look up on
email address and when someone logs in via the web UI, there's no way
to have their email address (think about it, RT only gets the username
they logged in with, not their email address which is stored in LDAP).
Often, ExternalAuth is keyed to look up on Username *and*
EmailAddress, but yours is configured for just EmailAddress.
Based on this I think our issues stem from him logging in via
the web before opening a ticket via email. Funnily enough when he
emailed IT support for help with something around the office, the RT
system worked like a charm. I'm starting to think I may be
over-thinking this entire situation...
This also supports my above comment, since someone emailing into your
system *would* be able to find their LDAP account, because RT has
their email account.
It sounds like many of these problems could be solved with
RT-Extension-LDAPImport pulling users into the system so they'll exist
before sending email or logging into the system.
-kevin
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston --- March 5 6, 2012
--
N
Re: [rt-users] Problems with new users
Thomas,
I didn't know it existed. I can't find rtldapimport anywhere on
the CPAN page, and a google search for rtldapimport
site:bestpractical.com only finds hits in version control.
It looks as though the README (as hosted on metacpan) talks about
it. I can't install RT::Extension::LDAPImport yet because I've not yet
set up RT's DB. I want to wait for thoughts on my RT_Siteconfig.pm
before I follow through with the make initialize-database. I'll take a
look at the script then.
-Scott
On 2/23/2012 12:15 PM, Thomas Sibley wrote:
On 02/23/2012 12:07 PM, Scott Pestana wrote:
#/usr/bin/perl
#RT_User_Update.pl - NSP 20120222
use RT;
use RT::Extension::LDAPImport;
Set($LDAPHost,'ldap://ldapserver.linguamatics.com');#CPAN leaves
out the $
Set($LDAPUSER,'');
# again
Set($LDAPPassword,'');
# and again
connect_ldap();
#Mirror RT_SiteConfig.pm for the Attribute Mapping:
Set($LDAPMapping, { 'Name' = 'uid', 'EmailAddress' = 'mail',
'RealName' = 'cn',
'ExternalAuthId' = 'uid', 'Gecos' = 'gecos' };
#Pull in the records since last time:
import_users( 'import' = 1 );
#Clean up
disconnect_ldap();
1;
And then we'll run that perl script on our RT server (owlwoman,
etc) whenever new employees come on board (and have been entered into
LDAP). Does this make sense?
Why aren't you using the rtldapimport script that ships with
RT::Extension::LDAPImport?
/opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --help
Thomas
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 6, 2012
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 6, 2012
Re: [rt-users] Problems with new users
Kevin, Comments inline: On 2/13/2012 12:06 PM, Kevin Falcone wrote: On Fri, Feb 10, 2012 at 03:45:25PM -0500, Scott Pestana wrote: For example: one user can send in emails to the RT queue and proceed normally. However if he tries to log in to the web version, the RT system treats him like is associated with a different queue than the rest of our users. When he tried to create a ticket through the web RT would create the ticket in this wrong queue, and he immediately got an error that he did not have permissions to view his ticket. It'd be useful to see some sort of screenshot of what he's seeing. When logged in he got the RT at a glance page, with an empty queue in the upper right hand corner next to new ticket, and all the sections (10 highest priority tickets I own, 10 newest unowned tickets, bookmarked tickets, quick ticket creation, my reminders, quick search, dashboards, refresh) all load up / display normally, but without any content. RT creates an internal user for him, unlike the rest of our employees who don't show up in the user list because they exist in the configured LDAP. I disabled the (discontinued) queue, and As a heads up, RT *always* create an internal user, even for users pulled from LDAP. There is no password stored, but RT must have an internal user account, otherwise the user can't be associated with tickets. Noted, I had seen them by directly querying the SQL tables I'm just a bit confused by why they don't show up under the Privileged Users display. edited the user created form him to disassociate it from him (rename, re-email, etc), and then had him try to log in again. Again, RT created a user with his name/credentials in its own SQL database instead of querying LDAP, and associated his user with the now disabled queue. He can no longer create tickets because the queue is disabled, and I can't figure out how to alter his account to associate him with the proper queue. As I mentioned on your other mail, debug level logs of what happens on login are much more likely to show us what is going on than descriptions of the problem. I'll also note that your ExternalAuth config didn't allow for LDAP auth, so I'm not sure what password your users are using. -kevin Here are debug level logs of our little misadventure. ilewin is the new employee. I'm wondering now if the users have been imported into the internal RT database by an export / import, and now new users (employees) aren't pre-loaded into the DB. The way we're doing this, is there an option I could change to allow LDAP auth? I heard some back and forth from the admin who set up this instance that there was so incompatibility with ExternalAuth LDAP auth. [Tue Jan 24 17:47:48 2012] [debug]: Attempting to use external auth service: Lingua_LDAP (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:64) [Tue Jan 24 17:47:48 2012] [debug]: SSO Failed and no user to test with. Nexting (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:92) [Tue Jan 24 17:47:48 2012] [debug]: Autohandler called ExternalAuth. Response: (0, No User) (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/html/Elements/DoAuth:11) [Tue Jan 24 17:48:08 2012] [error]: WebRT: Queue could not be loaded. (/opt/rt4/share/html/Elements/Error:82) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24282 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24283 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24284 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24285 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24286 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for transaction #24287 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173) [Tue Jan 24 17:49:28 2012] [debug]: RT::Authen::ExternalAuth::CanonicalizeUserInfo called by RT::Authen::ExternalAuth /opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/E xternalAuth.pm 553 with: Disabled: 0, EmailAddress: , Gecos: ilewin, Name: ilewin, Privileged: 1 (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:450) [Tue Jan 24 17:49:28 2012] [debug]: Attempting to get user info using this external service: Lingua_LDAP (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth. pm:458) [Tue Jan 24 17:49:28 2012] [debug]: Attempting to use this canonicalization key: EmailAddress (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:472) [Tue Jan 24 17:49:28 2012] [debug]: LDAP Search === Base: ou=users,dc=linguamatics,dc=com == Filter
[rt-users] Problems with new users
Hello RT Users, To preface, I've got several years experience and training with the Linux platform and PERL, but I'm completely new to RT; I've done a few web searches and a three or four different google searches of the email archive and can't find any insight into our problem. We're having a strange problem with our users in our two RT instances, that we think are related. When our internal IT Support instance of RT was created everything was working well for some time, and we currently have RT configured to work with our LDAP database for users and their credentials. However, new users (new employees) trying to use RT are not able to get the same functionality. For example: one user can send in emails to the RT queue and proceed normally. However if he tries to log in to the web version, the RT system treats him like is associated with a different queue than the rest of our users. When he tried to create a ticket through the web RT would create the ticket in this wrong queue, and he immediately got an error that he did not have permissions to view his ticket. RT creates an internal user for him, unlike the rest of our employees who don't show up in the user list because they exist in the configured LDAP. I disabled the (discontinued) queue, and edited the user created form him to disassociate it from him (rename, re-email, etc), and then had him try to log in again. Again, RT created a user with his name/credentials in its own SQL database instead of querying LDAP, and associated his user with the now disabled queue. He can no longer create tickets because the queue is disabled, and I can't figure out how to alter his account to associate him with the proper queue. Can anyone help me with this first problem? -- N. Scott Pestana IT Infrastructure Linguamatics RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
[rt-users] RT Instance pulling names but not emails
RT Users,
My second problem (potentially related to my last) is on our
external customer support RT instance. When internal employees first
send in requests, their names are harvested, but NOT their emails,
meaning that they could not get email updates when replies were to be
sent. If we manually set their email addresses everything works from
there.
We have RT configured to pull our internal employees from LDAP, and
we are (hopefully) set up to accept new users from the outside. However
in practice the system is accepting email ids for external users, but
not harvesting their names, resulting in strings like This is
correspondence from . note the empty/null string after from and
before the period.
Is there something wrong we've done with regard to RT user
creation? This is our External* config:
ExternalAuthPriority: []
ExternalInfoPriority: [
'Lingua_LDAP'
]
ExternalServiceUsesSSLorTLS: 0
ExternalSettings: {
'Lingua_LDAP' = {
'base' = 'ou=users,dc=linguamatics,dc=com',
'net_ldap_args' = [
'version',
3
],
'filter' =
'(|(objectClass=posixAccount)(objectClass=account))',
'server' = 'ldap1.linguamatics.com',
'type' = 'ldap',
'attr_match_list' = [
'EmailAddress'
],
'tls' = 0,
'attr_map' = {
'RealName' = 'cn',
'EmailAddress' = 'mail',
'Name' = 'uid',
'Gecos' = 'gecos',
'ExternalAuthId' = 'uid'
}
}
}
--
N. Scott Pestana
IT Infrastructure
Linguamatics
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 6, 2012
Re: [rt-users] Problems with new users
Kenn, I'm not sure how to give you the info you're asking for but... If I look under Configuration-Global-Group Rights, Everyone, into the Rights for Staff tab I found that ModifySelf / Modify one's own RT account is not checked currently. The same is true for Privileged and Unprivileged. Should I start with enabling ModifySelf / Modify one's own RT account for the Privileged Users group? For Everyone? Right now the rights that are granted are the same for Everyone/Privileged/Unprivileged entries are Create tickets and Reply to tickets Under the Global-User Rights we only have root and RT Admin listed. They have the Do anything and everything right, logically enough. Under the Configuration-Queues, into itsupport, there are no Users listed for the User Rights. For Group Rights, Everyone has CreateTicket and the Unprivileged have SeeQueue ShowTicket. -Scott On 2/10/2012 6:07 PM, Kenneth Crocker wrote: Scott, I can, but it would be helpful to know how uyou have set up your privileges, both Globally and by Queue. Also, in order for LDAP info to get into a User, they must have the ModifySelf right applied. OVerall, I think this is all a privileges problem. Kenn On Fri, Feb 10, 2012 at 12:45 PM, Scott Pestana scott.pest...@linguamatics.com mailto:scott.pest...@linguamatics.com wrote: Hello RT Users, To preface, I've got several years experience and training with the Linux platform and PERL, but I'm completely new to RT; I've done a few web searches and a three or four different google searches of the email archive and can't find any insight into our problem. We're having a strange problem with our users in our two RT instances, that we think are related. When our internal IT Support instance of RT was created everything was working well for some time, and we currently have RT configured to work with our LDAP database for users and their credentials. However, new users (new employees) trying to use RT are not able to get the same functionality. For example: one user can send in emails to the RT queue and proceed normally. However if he tries to log in to the web version, the RT system treats him like is associated with a different queue than the rest of our users. When he tried to create a ticket through the web RT would create the ticket in this wrong queue, and he immediately got an error that he did not have permissions to view his ticket. RT creates an internal user for him, unlike the rest of our employees who don't show up in the user list because they exist in the configured LDAP. I disabled the (discontinued) queue, and edited the user created form him to disassociate it from him (rename, re-email, etc), and then had him try to log in again. Again, RT created a user with his name/credentials in its own SQL database instead of querying LDAP, and associated his user with the now disabled queue. He can no longer create tickets because the queue is disabled, and I can't figure out how to alter his account to associate him with the proper queue. Can anyone help me with this first problem? -- N. Scott Pestana IT Infrastructure Linguamatics RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012 RT Training Sessions (http://bestpractical.com/services/training.html) * Boston --- March 5 6, 2012 -- N. Scott Pestana IT Infrastructure Linguamatics 275 Grove Street, Suite 2-400 Newton, MA 02466 Tel: +1-774-571-7135 US Tel: +1-617-674-3256 UK Tel: 011-44-1223-421360 UK Fax: 011-44-1223-421361 Web: www.linguamatics.com RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 6, 2012
