ItsFinallyInstalledNowWhat - Revision history

Admin: 6 revisions imported

2016-04-06T20:11:29Z

6 revisions imported

← Older revision		Revision as of 16:11, 6 April 2016
(No difference)

94.202.226.162: /* root failed login */

2012-04-24T12:01:30Z

root failed login

New page

= Request Tracker is finally installed, now what? =

The [[RHEL4InstallGuide]] was very helpful in getting this dependency nightmare up and running. However, once it was finally working, it took some Wiki-diving and Googling to solve a few basic problems. It's my hope that by putting the problems and solutions here I can save someone else the same effort.

== root failed login ==

The initial root password for the web interface is different than the database password you set in the Config file. Re-read the README. This is typically root/password.

== Goal ==

I wanted to have [[RequestTracker]] configured to accept tickets via E-mail into several queues and allow those submitting the requests to provide updates via E-mail and receive a notification when the request has been fulfilled. Optionally I wanted to allow them to see the status of the request any time via a web browser.

----

== Problems/Solutions ==

=== Associating E-mail addresses with RT queues ===

See: [[SendmailWithoutQueueAliases]] for a slightly more elegent solution without using <code>/etc/aliases</code>

This was easy-- add new lines to the /etc/aliases file and change the --queue option. Most of the queues I set up had spaces in them, so I needed to use single quotes around the queue name. Don't use double quotes like I did the first time or you'll end up with double quotes embedded between the double quotes around the whole command line. As you might expect, this didn't work at all.

For example, for the queue "Dev Group" you might create the following /etc/aliases entries:

rt-dev: "|/etc/smrsh/rt-mailgate --queue 'Dev Group' --action correspond --url http://your.host.name/rt/"
rt-dev-comment: "|/etc/smrsh/rt-mailgate --queue 'Dev Group' --action comment --url http://your.host.name/rt/"

=== Allowing users to open tickets via E-mail ===

The Wiki page on [[Rights]] was a great help here. When I first sent a message to the alias I had created I got a nasty-gram back:

RT could not load a valid user, and RT's configuration does not allow
for the creation of a new user for your email.

This was solved by granting [[CreateTicket]] and [[ReplyToTicket]] to the group Everyone. This is done via Configuration - > Queues - > (queue name) - > Group Rights in the web interface while logged in as the RT user "root".

Chris adds:

After upgrading my RT from 3.4.5 to 3.6.1, I received this error message. The permissions were all set properly, but apparently 3.6.1 is less forgiving about the mailgate setup. My aliases line looked like this:

helpdesk: "|/usr/local/rt/bin/rt-mailgate --url http://rt.bluenoteweb.com/"

In 3.4.5, RT assumed that the queue was General and the action was correspond. I changed my aliases line to this:

helpdesk: "|/usr/local/rt/bin/rt-mailgate --queue 'General' --action correspond --url http://rt.bluenoteweb.com/"

This solves the problem.

=== Allowing users to respond via E-mail to tickets they've opened ===

When the E-mail responses came back the !From: address wasn't set to anything useful, since I hadn't set this up properly when I created the queue. There are two fields in the Configuration - > Queues - > (queue name) - > Basics configuration screen that need to match the E-mail aliases you created for this queue. The "Reply Address" should be the the one with the "--action correspond" and the "Comment Address" should be the one with the "--action comment". In our example these would be "[mailto:rt-dev@your.host.name rt-dev@your.host.name]" and "[mailto:rt-dev-comment@your.host.name rt-dev-comment@your.host.name]".

After these were set up, sending a reply to a mail received gave the following less-than-helpful message in reply:

Subject: Message not recorded
Permission Denied

To get this sorted out I needed to grant [[ReplyToTicket]] to "Requestor" via the same Configuration - > Queues - > (queue name) - > Group Rights path in the RT web interface as "root".

--

For us, this turned out to be a simple issue of trying to update the ticket with a user that had been disabled in the system.

=== Allow users to see their tickets via the web interface ===

In a great stroke of luck, I ran across the Wiki page on [[SelfService]] which is a configuration to allow users to view their own tickets. The biggest change needed is to replace the default [[AutoReply]] template with the one on the [[AutogeneratedPassword]] page. Note that since this is an open Wiki you should sanity check the code before blindly pasting it in lest someone do something nasty with it.

To use this new template change the "content" box in Configuration - > Global - > Templates - > [[AutoReply]] to use the [[AutogeneratedPassword]] version. If you don't want to blow away the default Autoreply template, though, you can instead create a new template on the same screen and then modify your global scrips so that this new template is sent to users instead of the Autoreply one.

Additional rights are needed in either the Queue or Global configuration as described on the Rights page:

* Everyone gets [[SeeQueue]]
* Everyone gets [[ModifySelf]] (so they can change their own password and other info)
* Requestors get [[ShowTicket]] (not essential, but a good backup if Everyone rights are later changed)

=== Allow users to login with single sign-on ===

See [[LdapSummary]].

== Spam filtering ==

If you're using RT to follow any public address like info@ or support@, you are likely to get a lot of spam. So you probably want to setup some [[SpamFiltering]].

== Unsolved Problems ==

=== Manipulate auto-added users ===

I can forsee these users forgetting their passwords or otherwise needed help with their "account" yet I don't see them listed along with manually created users. I currently have no idea how to manipulate these accounts short of doing some database-diving.

Answer: Only users in the "Privileged" group (ie those which have the "Let this user be granted rights" checkbox ticked when they are created) show up in this list. You should find that you have the same problem even with manually created users if you don't check this option (as they then go into the "Unprivileged" group). The only way I've found to find non-privileged users is if you know their userid (or enough of it to match them), as when you use the search function at the bottom of the "Select Users" page, this will search all users.

I'm not sure how to change the default "Select Users" page to show all users, I only installed RT 3.4.3 an hour ago :-)

one way is to search any email address with a period or a userid without a space.

another way is to search for "%" which returns all users.

203.134.63.222: /* Allow users to login with single sign-on */

2011-08-16T03:37:14Z

Allow users to login with single sign-on

← Older revision		Revision as of 23:37, 15 August 2011
Line 81:		Line 81:

	See [[LdapSummary]].		See [[LdapSummary]].

			See [[Kerberos SSO with Active Directory Integration]]

	== Spam filtering ==		== Spam filtering ==

81.134.139.242: /* Associating E-mail addresses with RT queues */ expand w/o into English

2011-06-16T08:57:59Z

Associating E-mail addresses with RT queues: expand w/o into English

New page

= Request Tracker is finally installed, now what? =

The [[RHEL4InstallGuide]] was very helpful in getting this dependency nightmare up and running. However, once it was finally working, it took some Wiki-diving and Googling to solve a few basic problems. It's my hope that by putting the problems and solutions here I can save someone else the same effort.

== root failed login ==

The initial root password for the web interface is different than the database password you set in the Config file. Re-read the README.

== Goal ==

I wanted to have [[RequestTracker]] configured to accept tickets via E-mail into several queues and allow those submitting the requests to provide updates via E-mail and receive a notification when the request has been fulfilled. Optionally I wanted to allow them to see the status of the request any time via a web browser.

----

== Problems/Solutions ==

=== Associating E-mail addresses with RT queues ===

See: [[SendmailWithoutQueueAliases]] for a slightly more elegent solution without using <code>/etc/aliases</code>

This was easy-- add new lines to the /etc/aliases file and change the --queue option. Most of the queues I set up had spaces in them, so I needed to use single quotes around the queue name. Don't use double quotes like I did the first time or you'll end up with double quotes embedded between the double quotes around the whole command line. As you might expect, this didn't work at all.

For example, for the queue "Dev Group" you might create the following /etc/aliases entries:

rt-dev: "|/etc/smrsh/rt-mailgate --queue 'Dev Group' --action correspond --url http://your.host.name/rt/"
rt-dev-comment: "|/etc/smrsh/rt-mailgate --queue 'Dev Group' --action comment --url http://your.host.name/rt/"

=== Allowing users to open tickets via E-mail ===

The Wiki page on [[Rights]] was a great help here. When I first sent a message to the alias I had created I got a nasty-gram back:

RT could not load a valid user, and RT's configuration does not allow
for the creation of a new user for your email.

This was solved by granting [[CreateTicket]] and [[ReplyToTicket]] to the group Everyone. This is done via Configuration - > Queues - > (queue name) - > Group Rights in the web interface while logged in as the RT user "root".

Chris adds:

After upgrading my RT from 3.4.5 to 3.6.1, I received this error message. The permissions were all set properly, but apparently 3.6.1 is less forgiving about the mailgate setup. My aliases line looked like this:

helpdesk: "|/usr/local/rt/bin/rt-mailgate --url http://rt.bluenoteweb.com/"

In 3.4.5, RT assumed that the queue was General and the action was correspond. I changed my aliases line to this:

helpdesk: "|/usr/local/rt/bin/rt-mailgate --queue 'General' --action correspond --url http://rt.bluenoteweb.com/"

This solves the problem.

=== Allowing users to respond via E-mail to tickets they've opened ===

When the E-mail responses came back the !From: address wasn't set to anything useful, since I hadn't set this up properly when I created the queue. There are two fields in the Configuration - > Queues - > (queue name) - > Basics configuration screen that need to match the E-mail aliases you created for this queue. The "Reply Address" should be the the one with the "--action correspond" and the "Comment Address" should be the one with the "--action comment". In our example these would be "[mailto:rt-dev@your.host.name rt-dev@your.host.name]" and "[mailto:rt-dev-comment@your.host.name rt-dev-comment@your.host.name]".

After these were set up, sending a reply to a mail received gave the following less-than-helpful message in reply:

Subject: Message not recorded
Permission Denied

To get this sorted out I needed to grant [[ReplyToTicket]] to "Requestor" via the same Configuration - > Queues - > (queue name) - > Group Rights path in the RT web interface as "root".

--

For us, this turned out to be a simple issue of trying to update the ticket with a user that had been disabled in the system.

=== Allow users to see their tickets via the web interface ===

In a great stroke of luck, I ran across the Wiki page on [[SelfService]] which is a configuration to allow users to view their own tickets. The biggest change needed is to replace the default [[AutoReply]] template with the one on the [[AutogeneratedPassword]] page. Note that since this is an open Wiki you should sanity check the code before blindly pasting it in lest someone do something nasty with it.

To use this new template change the "content" box in Configuration - > Global - > Templates - > [[AutoReply]] to use the [[AutogeneratedPassword]] version. If you don't want to blow away the default Autoreply template, though, you can instead create a new template on the same screen and then modify your global scrips so that this new template is sent to users instead of the Autoreply one.

Additional rights are needed in either the Queue or Global configuration as described on the Rights page:

* Everyone gets [[SeeQueue]]
* Everyone gets [[ModifySelf]] (so they can change their own password and other info)
* Requestors get [[ShowTicket]] (not essential, but a good backup if Everyone rights are later changed)

=== Allow users to login with single sign-on ===

See [[LdapSummary]].

== Spam filtering ==

If you're using RT to follow any public address like info@ or support@, you are likely to get a lot of spam. So you probably want to setup some [[SpamFiltering]].

== Unsolved Problems ==

=== Manipulate auto-added users ===

I can forsee these users forgetting their passwords or otherwise needed help with their "account" yet I don't see them listed along with manually created users. I currently have no idea how to manipulate these accounts short of doing some database-diving.

Answer: Only users in the "Privileged" group (ie those which have the "Let this user be granted rights" checkbox ticked when they are created) show up in this list. You should find that you have the same problem even with manually created users if you don't check this option (as they then go into the "Unprivileged" group). The only way I've found to find non-privileged users is if you know their userid (or enough of it to match them), as when you use the search function at the bottom of the "Select Users" page, this will search all users.

I'm not sure how to change the default "Select Users" page to show all users, I only installed RT 3.4.3 an hour ago :-)

one way is to search any email address with a period or a userid without a space.

another way is to search for "%" which returns all users.