What's the username to log in? root/password does not work

Hi. Did the root password change from ‘password’ ? I cannot log
in… I am trying “root” with password “password” as per the docs,
but I am getting “Your username or password is incorrect”

In httpd logs, I see HTTP 200 OK, “POST /rt/ HTTP/1.1” 200

What’s happening, please?

Aleksey Tsalolikhin
UNIX System Administrator
“I get stuff done!”
http://www.lifesurvives.com/

[Wed Dec 3 01:02:28 2008] [warning]: DBD::Pg::st execute failed:
ERROR: permission denied for relation sessions at
/usr/lib/perl5/site_perl/5.8.8/Apache/Session/Store/DBI.pm line 44.
(/usr/lib/perl5/site_perl/5.8.8/Apache/Session/Store/DBI.pm:44)

I did grant SELECT on all tables to rt_user

any suggestions?On Tue, Dec 2, 2008 at 4:52 PM, Aleksey Tsalolikhin atsaloli.tech@gmail.com wrote:

Hi. Did the root password change from ‘password’ ? I cannot log
in… I am trying “root” with password “password” as per the docs,
but I am getting “Your username or password is incorrect”

In httpd logs, I see HTTP 200 OK, “POST /rt/ HTTP/1.1” 200

What’s happening, please?


Aleksey Tsalolikhin
UNIX System Administrator
“I get stuff done!”
http://www.lifesurvives.com/

Aleksey Tsalolikhin
UNIX System Administrator
“I get stuff done!”
http://www.lifesurvives.com/

Aleksey Tsalolikhin said the following on 12/2/08 8:01 PM:

[Wed Dec 3 01:02:28 2008] [warning]: DBD::Pg::st execute failed:
ERROR: permission denied for relation sessions at
/usr/lib/perl5/site_perl/5.8.8/Apache/Session/Store/DBI.pm line 44.
(/usr/lib/perl5/site_perl/5.8.8/Apache/Session/Store/DBI.pm:44)

I did grant SELECT on all tables to rt_user

any suggestions?

rt_user should have all permissions on the tables–it is, after all,
the user controlling the database.

Best,
–Glenn

…destination is merely a byproduct of the journey
–Eric Hansen

rt_user should have all permissions on the tables–it is, after all,
the user controlling the database.

Thanks, Glenn. Here is what I ran. Did I miss anything?
I tried putting in CREATE as Ruslan suggested but had to take
it out as Postgres said “ERROR: invalid privilege type CREATE for table”

So here is what I did run:

\connect rt3;
GRANT SELECT, UPDATE, DELETE on attachments_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Attachments TO rt_user;
GRANT SELECT, UPDATE, DELETE on Attributes TO rt_user;
GRANT SELECT, UPDATE, DELETE on attributes_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on queues_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Queues TO rt_user;
GRANT SELECT, UPDATE, DELETE on links_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Links TO rt_user;
GRANT SELECT, UPDATE, DELETE on principals_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Principals TO rt_user;
GRANT SELECT, UPDATE, DELETE on groups_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Groups TO rt_user;
GRANT SELECT, UPDATE, DELETE on scripconditions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ScripConditions TO rt_user;
GRANT SELECT, UPDATE, DELETE on transactions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Transactions TO rt_user;
GRANT SELECT, UPDATE, DELETE on scrips_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Scrips TO rt_user;
GRANT SELECT, UPDATE, DELETE on acl_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ACL TO rt_user;
GRANT SELECT, UPDATE, DELETE on groupmembers_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on GroupMembers TO rt_user;
GRANT SELECT, UPDATE, DELETE on cachedgroupmembers_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CachedGroupMembers TO rt_user;
GRANT SELECT, UPDATE, DELETE on users_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Users TO rt_user;
GRANT SELECT, UPDATE, DELETE on tickets_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Tickets TO rt_user;
GRANT SELECT, UPDATE, DELETE on scripactions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ScripActions TO rt_user;
GRANT SELECT, UPDATE, DELETE on templates_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Templates TO rt_user;
GRANT SELECT, UPDATE, DELETE on objectcustomfieldvalues_id_s TO rt_user;
GRANT SELECT, UPDATE, DELETE on ObjectCustomFieldValues TO rt_user;
GRANT SELECT, UPDATE, DELETE on customfields_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CustomFields TO rt_user;
GRANT SELECT, UPDATE, DELETE on objectcustomfields_id_s TO rt_user;
GRANT SELECT, UPDATE, DELETE on ObjectCustomFields TO rt_user;
GRANT SELECT, UPDATE, DELETE on customfieldvalues_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CustomFieldValues TO rt_user;
GRANT SELECT, UPDATE, DELETE on sessions TO rt_user;

Thanks,
Aleksey

rt_user should have all permissions on the tables–it is, after all,
the user controlling the database.

Thanks, Glenn. Here is what I ran. Did I miss anything?
I tried putting in CREATE as Ruslan suggested but had to take
it out as Postgres said “ERROR: invalid privilege type CREATE for table”
Sorry, it should be INSERT instead of CREATE.

So here is what I did run:

\connect rt3;
GRANT SELECT, UPDATE, DELETE on attachments_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Attachments TO rt_user;
GRANT SELECT, UPDATE, DELETE on Attributes TO rt_user;
GRANT SELECT, UPDATE, DELETE on attributes_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on queues_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Queues TO rt_user;
GRANT SELECT, UPDATE, DELETE on links_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Links TO rt_user;
GRANT SELECT, UPDATE, DELETE on principals_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Principals TO rt_user;
GRANT SELECT, UPDATE, DELETE on groups_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Groups TO rt_user;
GRANT SELECT, UPDATE, DELETE on scripconditions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ScripConditions TO rt_user;
GRANT SELECT, UPDATE, DELETE on transactions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Transactions TO rt_user;
GRANT SELECT, UPDATE, DELETE on scrips_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Scrips TO rt_user;
GRANT SELECT, UPDATE, DELETE on acl_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ACL TO rt_user;
GRANT SELECT, UPDATE, DELETE on groupmembers_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on GroupMembers TO rt_user;
GRANT SELECT, UPDATE, DELETE on cachedgroupmembers_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CachedGroupMembers TO rt_user;
GRANT SELECT, UPDATE, DELETE on users_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Users TO rt_user;
GRANT SELECT, UPDATE, DELETE on tickets_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Tickets TO rt_user;
GRANT SELECT, UPDATE, DELETE on scripactions_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on ScripActions TO rt_user;
GRANT SELECT, UPDATE, DELETE on templates_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on Templates TO rt_user;
GRANT SELECT, UPDATE, DELETE on objectcustomfieldvalues_id_s TO rt_user;
GRANT SELECT, UPDATE, DELETE on ObjectCustomFieldValues TO rt_user;
GRANT SELECT, UPDATE, DELETE on customfields_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CustomFields TO rt_user;
GRANT SELECT, UPDATE, DELETE on objectcustomfields_id_s TO rt_user;
GRANT SELECT, UPDATE, DELETE on ObjectCustomFields TO rt_user;
GRANT SELECT, UPDATE, DELETE on customfieldvalues_id_seq TO rt_user;
GRANT SELECT, UPDATE, DELETE on CustomFieldValues TO rt_user;
GRANT SELECT, UPDATE, DELETE on sessions TO rt_user;

Thanks,
Aleksey


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Woo-hoo! That did it! So to summarize, for anybody reading this in the list
archives, the solution was to remove USAGE from etc/acl.Pg and then
to re-run “make init” and “make initdb”.

Thanks!!
AlekseyOn Tue, Dec 2, 2008 at 6:18 PM, Ruslan Zakirov ruz@bestpractical.com wrote:

do make install, files for init step are used from destination dir.

On Wed, Dec 3, 2008 at 5:14 AM, Aleksey Tsalolikhin atsaloli.tech@gmail.com wrote:

On Tue, Dec 2, 2008 at 6:11 PM, Ruslan Zakirov ruz@bestpractical.com wrote:

As you stopped at ACL step during initialization of the DB then your
DB just has no data.

Ok. That makes sense. I tried updating etc/acl.Pg as you suggested
but my make still fails:

[root@hwd-ddc-app-prod01 rt-3.8.1]# grep GRANT etc/acl.Pg
push @acls, “GRANT SELECT, UPDATE ON $table TO $db_user;”
push @acls, “GRANT SELECT, INSERT, UPDATE, DELETE ON
$table TO $db_user;”
[root@hwd-ddc-app-prod01 rt-3.8.1]#

[root@hwd-ddc-app-prod01 rt-3.8.1]# make initdb
/usr/bin/perl sbin/rt-setup-database --action init --dba postgres
–prompt-for-dba-password
In order to create or update your RT database, this script needs to
connect to your Pg instance on localhost as postgres
Please specify that user’s database password below. If the user has no database
password, just press return.

Password:
Working with:
Type: Pg
Host: localhost
Name: rt3
User: rt_user
DBA: postgres
Now creating a Pg database rt3 for RT.
Done.
Now populating database schema.
Done.
Now inserting database ACLs
Couldn’t finish ‘acl’ step.

ERROR: Couldn’t run SQL query:
GRANT USAGE, SELECT, UPDATE ON attachments_id_seq TO rt_user;

ERROR: ERROR: invalid privilege type USAGE for table

make: *** [initialize-database] Error 255
[root@hwd-ddc-app-prod01 rt-3.8.1]#

What gives? Where is it getting USAGE?

Thanks,
Aleksey


Best regards, Ruslan.

Aleksey Tsalolikhin
UNIX System Administrator
“I get stuff done!”
http://www.lifesurvives.com/

Dear list, dear Emmanuel,

today I used cpan (cpan -i RT::Extension::SearchResults::XLS) to install
SearchResults-XLS to one of our RT instances (RT v3.6.6, Apache/2.2.3,
Perl v5.8.8 on a SUSE Linux Enterprise Server 10).

After that I got some error messages (see below my posting).
Looks like RT::Handle::cmp_version is not known in RT 3.6.6 yet. As
small workaround it was sufficient, to comment out the condition in the
callback:
% #if (RT::Handle::cmp_version( ‘3.8.1’, $RT::VERSION ) > 0 ) {
XLS
% #}

Maybe you can have a look at this.

Best regards,
Ben

error: Undefined subroutine &RT::Handle::cmp_version called at
/opt/rt3/share/html/Callbacks/Results-XLS/Search/Results.html/SearchActions
line 3.
context:
1: % # Don’t display this callback if our RT Version contains the
new ResultsView
2: % # AfterTools Callback
3: % if (RT::Handle::cmp_version( ‘3.8.1’, $RT::VERSION ) > 0 ) {
4: XLS
5: % }
6: <%ARGS>
7: $QueryString => undef

code stack:
/opt/rt3/share/html/Callbacks/Results-XLS/Search/Results.html/SearchActions:3
/opt/rt3/share/html/Elements/Callback:85
/opt/rt3/share/html/Search/Results.html:94
/opt/rt3/share/html/Search/Build.html:783
/opt/rt3/share/html/autohandler:291

Undefined subroutine &RT::Handle::cmp_version called at /opt/rt3/share/html/Callbacks/Results-XLS/Search/Results.html/SearchActions line 3.

Dear list, dear Emmanuel,

today I used cpan (cpan -i RT::Extension::SearchResults::XLS) to install
SearchResults-XLS to one of our RT instances (RT v3.6.6, Apache/2.2.3,
Perl v5.8.8 on a SUSE Linux Enterprise Server 10).

After that I got some error messages (see below my posting).
Looks like RT::Handle::cmp_version is not known in RT 3.6.6 yet. As
small workaround it was sufficient, to comment out the condition in the
callback:
% #if (RT::Handle::cmp_version( ‘3.8.1’, $RT::VERSION ) > 0 ) {
XLS
% #}

Yep, cmp_version exists only in 3.8.x.

Maybe you can have a look at this.

Well, latest version was updated to fit 3.8.x without concern about 3.6
:/. For 3.6.x you should use 0.02.

RT::Extension::SearchResults::XLS follow the evolution of Results.tsv
code and so I cannot be sure that it is backward compatible between
major versions.

I promise to add information on RT version dependency in next uploads :wink: