Hi all,
Well, it seems to be working now, and I'm thoroughly embarrassed about it.
The Nginx/Apache setup is fine, and has been, it seems. The OST error was
rather cryptic, but once I finally found where in the OST code it was being
generated, I discovered that it was likely a database failure. I re-granted
privileges to my OST user, and suddenly the installation completed.
Thus far, everything is running normally. I guess the lesson is to always
check your DB user privileges, and hope OST puts in better error messages.
Thanks for the help, everyone; this taught me a lot, about Nginx
configuration, upstream contexts, and so on. Even if the final answer was
my own mistake in privilege settings, I couldn't have done the rest of the
setup without the help of the list. I'll likely be back with more
questions, but for now, everything seems stable and okay.
On Sat, May 14, 2016 at 7:32 AM, Alex Hall <ahall@autodist.com> wrote:
>
> > On May 14, 2016, at 05:19, Francis Daly <francis@daoine.org> wrote:
> >
> > On Fri, May 13, 2016 at 01:24:57PM -0400, Alex Hall wrote:
> >
> > Hi there,
> >
> >> It's as though the proxy weren't working properly at all.
> >> I have it set up in a location:
> >>
> >> upstream apache2Redirect {
> >> server 127.0.0.1:8080;
> >> }
> >>
> >> location / {
> >> proxy_set_header Host $host;
> >> proxy_pass http://apache2Redirect;
> >> }
> >>
> >> My understanding is that the / will match everything, from /index.html
> to
> >> /images/small/235.jpg. Is that not the case? Do I need to do something
> to
> >> my location block, by chance?
> >
> > If the "location" you show above is the entire content of your server{}
> > block, then all requests that get to nginx should be handled in it.
> >
> > If you have more config that you are not showing, then possibly that
> > extra config is interfering with what you want to do.
> >
> Sorry I should have said. Yes, that's all there is to my config file. I
> wanted every request to go to Apache, including any subdirectories.
> >
> > The best chance of someone being able to help, is if you can include
> > very specific details about what you do, what you see, and what you
> > expect to see instead.
>
> The problem is that the error I'm seeing is in OSTicket. All I can say is
> that the OST forums aren't any help, that I don't see the error on Apache
> under Windows, and that I do see it under this configuration. It's the
> exact same error I saw when serving OST with Nginx directly, which is why I
> think the proxy isn't working correctly. Plus, I don't see the access to
> the OST pages in the Apache access log after 11:14, despite trying it all
> day yesterday. Nginx registers them, but not Apache. Yet, if I stop Apache,
> I get a 502 when trying to pull up OST.
> >
> > If you use the "curl" command-line tool instead of a normal browser, you
> > can make one request and see the full response. If you know what response
> > you expect, you can compare it to the response that you actually get.
> >
> >
> > curl -v http://ngninx-server/OSTicket/
> >
> > (or whatever url you have set things up at).
> >
> > Without knowing what you do want to see, I'm pretty sure that you do
> > not want to see "127.0.0.1" or "8080" anywhere in the response.
>
> Curl is a good idea. I'll try that Monday when I'm back in the office
> (this is an intranet site, so I can't test it from home, though I can ssh
> into the server).
> >
> > Good luck with it,
> >
> > f
> > --
> > Francis Daly francis@daoine.org
> >
> > _______________________________________________
> > nginx mailing list
> > nginx@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
--
Alex Hall
Automatic Distributors, IT department
ahall@autodist.com
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
