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 <mzagr...@d.umn.edu> wrote:

> On Mon, Oct 24, 2016 at 7:09 AM, Alex Hall <ah...@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
RT 4.4 and RTIR training sessions, and a new workshop day! 
* Boston - October 24-26
* Los Angeles - Q1 2017

Reply via email to