I figured out that I need to use the session file instead of the database. I
linked the error together with what I found in RT_SiteConfig.pm.
Now I can get the login screen but can't login. I'm guessing that the remote
database isn't being located/connected to.
Keep up with me and what I'm up
It should actually be the web server process that is trying to write to
the directory, not MySQL, if you're using Apache::Session::File. Have
you changed the WebSessionClass in your RT_SiteConfig.pm? It should be
trying to save to the MySQL DB, and not /usr/local/rt3/var/session_data,
unless you
I'm guessing the problem here is that MySQL is trying to write the session data
to this directory. However, with the database now on another server it clearly
doesn't have access to it. Is this correct?
Keep up with me and what I'm up to: http://theillien.blogspot.com
Mathew Snyder wrote:
Most likely, RT can't talk to the database on the remote server. Have you
verified database rights on the remote server? Do you have Selinux enabled
on either server?
James Moseley
Mathew Snyder
Matthew;
It sounds to me you forgot to :
GRANT SELECT,INSERT,CREATE,INDEX,UPDATE,DELETE ON ${RT::DatabaseName}.*
TO ${RT::DatabaseUser}\@'${RT::DatabaseRTHost}' IDENTIFIED BY
'${RT::DatabasePassword}'
;);
Roy
Mathew Snyder wrote:
I figured out that I need to use the session file instead
Well thats your answer Mathew, unless you grant the permissions RT is
not going to work for you..
What errors are you getting when you granting permissions??
Roy
Mathew Snyder wrote:
I ran
GRANT ALL ON rt_database.* to 'rt_user'@'rt_server' IDENTIFIED BY 'rt_password'
when I first migrated
Let me clarify. I ran that query and added the user. However, this did not
make RT work. The query itself did, though.
Keep up with me and what I'm up to: http://theillien.blogspot.com
Roy El-Hames wrote:
Well thats your answer Mathew, unless you grant the permissions RT is
not going to
Have you poked a hole for tcp 3306 in the firewall on your new db server?
Mathew Snyder wrote:
I ran
GRANT ALL ON rt_database.* to 'rt_user'@'rt_server' IDENTIFIED BY
'rt_password'
when I first migrated it. It didn't work. I then actually went through the
process of installing RT on the
My version is 3.6.4
I'm working on a script to update users' data from LDAP. Everything is
working fine for the most part, but updating a custom field.
If I use code like this, the value is updated...
my $CFObj = new RT::CustomField($RT::SystemUser);
$CFObj-Load('Department');
I ran
GRANT ALL ON rt_database.* to 'rt_user'@'rt_server' IDENTIFIED BY 'rt_password'
when I first migrated it. It didn't work. I then actually went through the
process of installing RT on the database server in order to utilize `make
initialize-database`. This didn't work either.
Keep up with
Ah ok sorry ..
When you logged in via sql from another host did you login as the rt
user and the rt password??
Have you got logging enabled on your sql server and debug level logging
on RT? what is in the log files??
Roy
Mathew Snyder wrote:
Let me clarify. I ran that query and added the
No need. When installing MySQL via rpm or when installing Red Hat this is
automatically taken care of. But to be sure, I connected to it using the mysql
shell from another host.
Keep up with me and what I'm up to: http://theillien.blogspot.com
Drew Barnes wrote:
Have you poked a hole for tcp
I have no idea what happened but I pointed the RT host to the new database
server again and restarted httpd again. This time it seems to have worked.
I wish I knew what I did that fixed it.
Keep up with me and what I'm up to: http://theillien.blogspot.com
Roy El-Hames wrote:
Ah ok sorry ..
Have a new deployment of RT and trying to work out a few bugs.
A user submits a ticket via email. He CC's his boss.
The ticket is created just fine and everyone is notified appropriately. The
problem is that if the boss replies to the
first email, it generates another ticket. Is there a
Hello,
We are looking to write a scrip to email a pager address if an email comes
into a queue with the priority set to high in the header. Can anyone point
me to a sample or give me a push in the right direction? I tried to adapt
this scrip
Hi Jeremy,
If you're having problems with the scrip condition, try using this as a
User Defined condition:
my $Trans = $self-TransactionObj;
return $Trans-Type eq 'Create'
$Trans-Attachments-First-GetHeader('X-Priority') =~ /^1\b/ ;
This will trigger the scrip if a new ticket
To all,
We wanted to have TransactionBatch as a scrip stage option so we made
the change as:
RT::TransactionBatch1
in the configuration. When we go to a scrip, we still do not see it in
the stage drop-down. Anyone have this experience and resolve it? Thanks.
Kenn
LBNL
Have you restarted httpd?
Keep up with me and what I'm up to: http://theillien.blogspot.com
Kenneth Crocker wrote:
To all,
We wanted to have TransactionBatch as a scrip stage option so we
made the change as:
RT::TransactionBatch 1
in the configuration. When we go to a
Mathew,
Yes we did.
Kenn
LBNL
On 10/4/2007 12:20 PM, Mathew Snyder wrote:
Have you restarted httpd?
Keep up with me and what I'm up to: http://theillien.blogspot.com
Kenneth Crocker wrote:
To all,
We wanted to have TransactionBatch as a scrip stage option so we
made the
Stephen,
Yep. That did it. Thanks.
Kenn
LBNL
On 10/4/2007 12:46 PM, Stephen Turner wrote:
At Thursday 10/4/2007 02:50 PM, you wrote:
To all,
We wanted to have TransactionBatch as a scrip stage option
so we made the change as:
RT::TransactionBatch1
in the
20 matches
Mail list logo
