Difference between revisions of "ItsFinallyInstalledNowWhat"

From Request Tracker Wiki
Jump to navigation Jump to search
m (6 revisions imported)
 
(2 intermediate revisions by one other user not shown)
Line 5: Line 5:
== root failed login ==
== 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.
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 ==
== Goal ==
Line 81: Line 81:


See [[LdapSummary]].
See [[LdapSummary]].
See [[Kerberos SSO with Active Directory Integration]]


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

Latest revision as of 16:11, 6 April 2016

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 /etc/aliases

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 "rt-dev@your.host.name" and "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.