Serving website with Apache, with Nginx as interface?

Server NGINX
1

Hello all,
Here’s what I’m trying to do. I have two sites, sd1.mysite.com and
sd2.mysite.com. The fun part is that sd1 is a Flask app, served by
Nginx.
However, sd2 is OSTicket, which must be served by Apache, it seems. Of
course, Apache and Nginx can’t listen to port 80 at the same time, and
as
this is a subdomain on a local, Windows DNS, I can’t make sd2.mysite.com
point to myip:8080 or anything like that.

Thus, my best option appears to be this: Nginx listens to all incoming
traffic on 80. If the request is for anything to do with sd1, it handles
it
just like it does now. However, if the request is for sd2, Nginx somehow
hands off the request to Apache, then returns what Apache gives it back
to
the user.

I’ve heard that people use Apache and Nginx together, but I haven’t
found
anyone who uses them to serve two subdomains, with Nginx as the
“gateway”
and handler of one subdomain, and Apache as the handler for the other
subdomain. Is there any way to do this? Am I even making sense? Thanks
for
any ideas anyone has.

2

Hello,

let Apache listen on a different port and create two server blocks in
nginx, one for each site. Then configure nginx to proxy the requests to
sd2
to apache.
Just google “nginx reverse proxy” and you will find much information.

Yours sincerely
Sven Kirschbaum

2016-05-12 23:34 GMT+02:00 Alex H. [email protected]:

3

Hi, you can use vhost in Apache and configure proxy_pass in nginx
configuration
For apache2 somthing like that
<VirtualHost *:8080>
ServerName foo.bar

DocumentRoot /home/sites/
<Directory /home/sites/>
Order deny,allow
Allow from all

ErrorLog /home/sites/logs/apache_error.log
CustomLog /home/sites/logs/apache_access.log combined

etc…

For nginx
server {
listen 80;
server_name foo.bar;

access_log /home/sites/logs/nginx_access.log;
error_log /home/sites/logs/nginx_error.log;

location / {
    proxy_pass  http://backend1;

etc…
}
}

2016-05-13 0:34 GMT+03:00 Alex H. [email protected]:

4

Sorry, backend1 its upstream in nginx configuration
upstream backend1 {
#ip of Apache back-end
server 192.168.0.1:8080;
}

2016-05-13 1:59 GMT+03:00 Alex H. [email protected]:

5

Thanks! I followed you, until the proxy_pass. What is backend1, and
where is it defined? I know it’s something you made up, but how does it
know about Apache, or Apache about it?

6

As a quick update, setting
proxy_set_header Host $host;
seems to have gotten the URL working, but OSTicket is still giving me
the
same error I was getting when I was serving it with Nginx directly.
Worse,
the Apache2 access log shows none of my recent attempts to access the
site,
though it does show older ones. The Nginx access log shows all the
accesses, though. 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?

On Fri, May 13, 2016 at 1:20 AM, Yuriy M. [email protected]

7

On Fri, May 13, 2016 at 01:24:57PM -0400, Alex H. wrote:

Hi there,

}

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.

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.

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.

Good luck with it,

f

Francis D. [email protected]

8

Alex H. Wrote:

upstream apache2Redirect {
server 127.0.0.1:8080;
}

location / {
proxy_set_header Host $host;
proxy_pass http://apache2Redirect;
}

Browser(get localhost:8080) → osticket (return responses with
localhost:8080)

Browser(get localhost:80) → nginx proxy_pass localhost:8080 → osticket
(return responses with localhost:8080)
Browser attempts 8080 which is not the nginx proxy.

Ea. sometimes you need to tell the backend (osticket) what it’s frontend
address/port is.

This is a typical issue with tomcat applications, where you have to tell
it
is running on port 443 eventhough it is listening on port 8443 because
nginx
is setting in between handling port 443 proxying to 8443.

Posted at Nginx Forum:

9

server 127.0.0.1:8080;

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.

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).

10

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.

11

On Mon, May 16, 2016 at 08:50:44AM -0400, Alex H. wrote:

Hi there,

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.

Thanks for reporting that result – it’ll help the future reader of the
mailing list (xkcd: Wisdom of the Ancients).

I re-granted
privileges to my OST user, and suddenly the installation completed.

You have a working system, so it is sensible to leave well-enough alone.

But if you feel like further investigations – does it now work for you
with nginx/fastcgi, using an nginx config like the one previously
posted?

Cheers,

f

Francis D. [email protected]

12

On Tue, May 17, 2016 at 1:37 PM, Francis D. [email protected]
wrote:

I re-granted
privileges to my OST user, and suddenly the installation completed.

You have a working system, so it is sensible to leave well-enough alone.

But if you feel like further investigations – does it now work for you
with nginx/fastcgi, using an nginx config like the one previously posted?

I haven’t tried it. As you said, it’s working now. If it were a matter
of
two supported servers–Nginx and Apache–I’d try it. But whenever I read
about it, someone has some obscure problem that doesn’t crop up until
later, and I don’t want to risk my work’s switching to a system that
starts
behaving unexpectedly seemingly out of nowhere. That said, I feel like
setting up a FastCGI setup would be easier now that I’ve gone through
UWSGI
for one subdomain and Apache for another, both behind Nginx.