Hello list,
As I mentioned, the upgrade on my test server from 4.2.8 to 4.4.1 went
well. On the production server, though, it’s not; the upgrade-database
script is failing when it tries to connect to the database. I’ve been in
MySQL messing around with user permissions, trying to get things to work,
but to no avail.
How can I know exactly what username/password the script is using? It says
in the error that the user is ‘rt_user’, yet in /opt/rt4/RT_Config.pm the
configuration comment says it should be ‘rtuser’ (note the lack of an
underscore). It may be important to say that this line remains unchanged no
matter how often I re-run ./configure with new options. On a related note,
I have no idea what password is in use since it won’t take my configuration
command.
I’m not sure what to try next. Do I erase RT_Config.pm and re-run
./configure? Is there a different way to “start over”? I’ve already run
‘make upgrade’ and am now trying to upgrade my database. As directed,
though, I’m operating on a duplicate of my 4.2.8 database, not the
original. Thus I should be able to return functionality to 4.2.8 for the
work day today so people can use it with no problem. I was trying this over
the weekend and early this morning, figuring it wouldn’t be hard after my
test went so well. Thanks in advance for any ideas anyone has.
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
Hello list,
As I mentioned, the upgrade on my test server from 4.2.8 to 4.4.1 went well.
On the production server, though, it’s not; the upgrade-database script is
failing when it tries to connect to the database. I’ve been in MySQL messing
around with user permissions, trying to get things to work, but to no avail.
How can I know exactly what username/password the script is using? It says
in the error that the user is ‘rt_user’, yet in /opt/rt4/RT_Config.pm the
configuration comment says it should be ‘rtuser’ (note the lack of an
underscore).
Okay.
It may be important to say that this line remains unchanged no
matter how often I re-run ./configure with new options. On a related note, I
have no idea what password is in use since it won’t take my configuration
command.
Your password should be in either RT_SiteConfig.pm or in a config
snippet in RT_SiteConfig.d/.
I’m not sure what to try next. Do I erase RT_Config.pm and re-run
./configure?
Perhaps.
RT_Config.pm has all the default values shipped from upstream.
RT_Config.pm should never be edited by the administrator (you.)
There is RT_SiteConfig.pm and RT_SiteConfig.d for the admin to
override defaults.
-m
Oh, so the same rules apply for configuration as normal. Good, I thought an
upgrade was a different case.
The database upgraded successfully, but now I’m having a similar problem.
When I spawn the FCGI server, it exits immediately, because ‘rt_user’ can’t
log into MySQL. The problem is that /opt/rt4/RT_SiteConfig.d/
51-dbconfig-common.pm’ lists the user as ‘rtuser’, not ‘rt_user’. I’m again
in the position of not knowing where the username and password are coming
from. You’ve said before that simply starting RT is enough to get the
config files to be used, but I’ve restarted both the FCGI server and Nginx
and that username won’t change. I have a user in the database called
rt_user as well, but again, I don’t know what password RT is trying to use.
I’ve looked in SiteConfig.pm, but no DB credentials are defined there.On Mon, Oct 24, 2016 at 8:16 AM, Matt Zagrabelny mzagrabe@d.umn.edu wrote:
On Mon, Oct 24, 2016 at 7:09 AM, Alex Hall ahall@autodist.com wrote:
Hello list,
As I mentioned, the upgrade on my test server from 4.2.8 to 4.4.1 went
well.
On the production server, though, it’s not; the upgrade-database script
is
failing when it tries to connect to the database. I’ve been in MySQL
messing
around with user permissions, trying to get things to work, but to no
avail.
How can I know exactly what username/password the script is using? It
says
in the error that the user is ‘rt_user’, yet in /opt/rt4/RT_Config.pm the
configuration comment says it should be ‘rtuser’ (note the lack of an
underscore).
Okay.
It may be important to say that this line remains unchanged no
matter how often I re-run ./configure with new options. On a related
note, I
have no idea what password is in use since it won’t take my configuration
command.
Your password should be in either RT_SiteConfig.pm or in a config
snippet in RT_SiteConfig.d/.
I’m not sure what to try next. Do I erase RT_Config.pm and re-run
./configure?
Perhaps.
RT_Config.pm has all the default values shipped from upstream.
RT_Config.pm should never be edited by the administrator (you.)
There is RT_SiteConfig.pm and RT_SiteConfig.d for the admin to
override defaults.
-m
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
I’ve confirmed that my RT_SiteConfig.d directory doesn’t seem to be
working. As soon as I added my database credentials to RT_SiteConfig.pm,
everything worked. The problem is that I have a lot of settings in the .d
directory that I’d really rather no add to the main file. Is there a trick
to getting the files in the .d directory recognized? In 4.2.8 on Debian,
they didn’t need .pm extensions, but I’ve added those. I’ve restarted FCGI
and Nginx multiple times. Have I missed anything?On Mon, Oct 24, 2016 at 8:49 AM, Alex Hall ahall@autodist.com wrote:
Oh, so the same rules apply for configuration as normal. Good, I thought
an upgrade was a different case.
The database upgraded successfully, but now I’m having a similar problem.
When I spawn the FCGI server, it exits immediately, because ‘rt_user’ can’t
log into MySQL. The problem is that /opt/rt4/RT_SiteConfig.d/51-
dbconfig-common.pm’ lists the user as ‘rtuser’, not ‘rt_user’. I’m again
in the position of not knowing where the username and password are coming
from. You’ve said before that simply starting RT is enough to get the
config files to be used, but I’ve restarted both the FCGI server and Nginx
and that username won’t change. I have a user in the database called
rt_user as well, but again, I don’t know what password RT is trying to use.
I’ve looked in SiteConfig.pm, but no DB credentials are defined there.
On Mon, Oct 24, 2016 at 8:16 AM, Matt Zagrabelny mzagrabe@d.umn.edu wrote:
On Mon, Oct 24, 2016 at 7:09 AM, Alex Hall ahall@autodist.com wrote:
Hello list,
As I mentioned, the upgrade on my test server from 4.2.8 to 4.4.1 went
well.
On the production server, though, it’s not; the upgrade-database script
is
failing when it tries to connect to the database. I’ve been in MySQL
messing
around with user permissions, trying to get things to work, but to no
avail.
How can I know exactly what username/password the script is using? It
says
in the error that the user is ‘rt_user’, yet in /opt/rt4/RT_Config.pm
the
configuration comment says it should be ‘rtuser’ (note the lack of an
underscore).
Okay.
It may be important to say that this line remains unchanged no
matter how often I re-run ./configure with new options. On a related
note, I
have no idea what password is in use since it won’t take my
configuration
command.
Your password should be in either RT_SiteConfig.pm or in a config
snippet in RT_SiteConfig.d/.
I’m not sure what to try next. Do I erase RT_Config.pm and re-run
./configure?
Perhaps.
RT_Config.pm has all the default values shipped from upstream.
RT_Config.pm should never be edited by the administrator (you.)
There is RT_SiteConfig.pm and RT_SiteConfig.d for the admin to
override defaults.
-m
–
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com