0

I have a domain called abc.com which points to a static html page, in /var/www/abc.com/public_html.

I want to host a Flask application on same droplet (different port maybe?), which is accessible using a subdomain demo.abc.com.

I followed instructions here, and here, but they seem not to be working for me right now.

Here is a how my Zone file looks like currently

$ORIGIN abc.com.
$TTL 1800
abc.com. IN SOA ns1.digitalocean.com. hostmaster.abc.com. 1451918078 10800 3600 604800 1800
abc.com. 1800 IN NS ns1.digitalocean.com.
abc.com. 1800 IN NS ns2.digitalocean.com.
abc.com. 1800 IN NS ns3.digitalocean.com.
abc.com. 1800 IN A 111.222.333.44
*.abc.com. 1800 IN CNAME abc.com.

I have created an app.py in /var/www/demo.abc.com/ which has

from flask import Flask
application = Flask(__name__)

@application.route("/")
def hello():
    return 'Hello World!'

if __name__ == "__main__":
    application.run(host='0.0.0.0')

I have 3 files in /etc/nginx/sites-available -

default

abc.com

demo.abc.com

of which only abc.com and demo.abc.com are symlinked to /etc/nginx/sites-enabled

Here is what demo.abc.com looks like:

server {
    listen 80;
    server_tokens off;
    server_name demo.abc.com;

     location / {
         include uwsgi_params;
         uwsgi_pass unix:/tmp/demo.sock;
     }

     location /static {
         alias /var/www/demo.abc.com/static;
     }

     ## Only requests to our Host are allowed
     if ($host !~ ^(demo.abc.com.com|www.demo.abc.com)$ ) {
        return 444;
     }
}

Here is what abc.com looks like:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/abc.com/public_html;

        server_name abc.com;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ \.php$ {
                include snippets/fastcgi-php.conf;

                # With php5-cgi alone:
                #fastcgi_pass 127.0.0.1:9000;
                # With php5-fpm:
                fastcgi_pass unix:/var/run/php5-fpm.sock;
        }
}

Here is default:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }
}

Here is what /etc/uwsgi/apps-available/demo.abc.com.ini looks like

[uwsgi]
vhost = true
socket = /tmp/demo.sock
venv = /var/www/demo.abc.com/.env
chdir = /var/www/demo.abc.com
module = app
callable = application

master = true
processes = 5

chmod-socket = 660
vacuum = true

die-on-term = true

abc.com works fine, while demo.abc.com is not running. I don't get any error while starting service nginx and uwsgi. I am however beginner in both of them. Please guide me on what I am doing wrong.

EDIT

Attaching the full uwsgi log, and nginx access.log (The second one is 88 MB). I am not sure, how to get only the failed requests parts of the log. To my understanding, they look like this -

uwsgi.log

Sun Jan 17 07:54:58 2016 - *** Starting uWSGI 2.0.7-debian (64bit) on [Sun Jan 17 07:54:58 2016] ***
Sun Jan 17 07:54:58 2016 - compiled with version: 5.2.1 20150903 on 08 September 2015 19:33:31
Sun Jan 17 07:54:58 2016 - os: Linux-4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015
Sun Jan 17 07:54:58 2016 - nodename: Poolka.com
Sun Jan 17 07:54:58 2016 - machine: x86_64
Sun Jan 17 07:54:58 2016 - clock source: unix
Sun Jan 17 07:54:58 2016 - pcre jit disabled
Sun Jan 17 07:54:58 2016 - detected number of CPU cores: 1
Sun Jan 17 07:54:58 2016 - current working directory: /
Sun Jan 17 07:54:58 2016 - writing pidfile to /run/uwsgi/app/demo.poolka.com/pid
Sun Jan 17 07:54:58 2016 - detected binary path: /usr/bin/uwsgi-core
Sun Jan 17 07:54:58 2016 - setgid() to 33
Sun Jan 17 07:54:58 2016 - setuid() to 33
Sun Jan 17 07:54:58 2016 - your processes number limit is 1833
Sun Jan 17 07:54:58 2016 - your memory page size is 4096 bytes
Sun Jan 17 07:54:58 2016 - detected max file descriptor number: 1024
Sun Jan 17 07:54:58 2016 - VirtualHosting mode enabled.
Sun Jan 17 07:54:58 2016 - lock engine: pthread robust mutexes
Sun Jan 17 07:54:58 2016 - thunder lock: disabled (you can enable it with --thunder-lock)
Sun Jan 17 07:54:58 2016 - uwsgi socket 0 bound to UNIX address /run/uwsgi/app/demo.poolka.com/socket fd 3
Sun Jan 17 07:54:58 2016 - uwsgi socket 1 bound to UNIX address /tmp/demo.sock fd 5
Sun Jan 17 07:54:58 2016 - Python version: 2.7.10 (default, Oct 14 2015, 16:09:02)  [GCC 5.2.1 20151010]
Sun Jan 17 07:54:58 2016 - Set PythonHome to /var/www/demo.poolka.com/.env
Sun Jan 17 07:54:58 2016 - *** Python threads support is disabled. You can enable it with --enable-threads ***
Sun Jan 17 07:54:58 2016 - Python main interpreter initialized at 0x1f08d00
Sun Jan 17 07:54:58 2016 - your server socket listen backlog is limited to 100 connections
Sun Jan 17 07:54:58 2016 - your mercy for graceful operations on workers is 60 seconds
Sun Jan 17 07:54:58 2016 - mapped 436608 bytes (426 KB) for 5 cores
Sun Jan 17 07:54:58 2016 - *** Operational MODE: preforking ***
Sun Jan 17 07:54:58 2016 - WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1f08d00 pid: 17624 (default app)
Sun Jan 17 07:54:58 2016 - *** uWSGI is running in multiple interpreter mode ***
Sun Jan 17 07:54:58 2016 - spawned uWSGI master process (pid: 17624)
Sun Jan 17 07:54:58 2016 - spawned uWSGI worker 1 (pid: 17632, cores: 1)
Sun Jan 17 07:54:58 2016 - spawned uWSGI worker 2 (pid: 17633, cores: 1)
Sun Jan 17 07:54:58 2016 - spawned uWSGI worker 3 (pid: 17634, cores: 1)
Sun Jan 17 07:54:58 2016 - spawned uWSGI worker 4 (pid: 17635, cores: 1)
Sun Jan 17 07:54:58 2016 - spawned uWSGI worker 5 (pid: 17636, cores: 1)

access.log

14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=37008&ts=1426138782918&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
86.129.146.109 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=6006&ts=1427056285299&m=30&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
86.129.146.109 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=48005&ts=1397342348934&m=30&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=28006&ts=1409495783294&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=20008&ts=1426240752454&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
31.18.246.156 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=6008&ts=1427052397699&m=10&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
31.18.246.156 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=41008&ts=1423783986283&m=10&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
31.18.246.156 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=23008&ts=1427067411049&m=10&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=37009&ts=1426108634237&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=46001&ts=1409495784000&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=20009&ts=1426224478835&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
14.183.60.220 - - [17/Jan/2016:13:38:52 -0500] "GET /items?c=11001&ts=1426240749118&m=20&T= HTTP/1.1" 404 177 "-" "Apache-HttpClient/UNAVAILABLE (java 1.4)"
kampta
  • 101
  • 4
  • What does the `nginx` log say? Is `uwsgi` running? Could you provide the output while being started? – gxx Jan 17 '16 at 09:28
  • Why does one file say `abc.sock` and another say `demo.sock`? Is that a typo in the question or a potential source of the problem? – Richard Smith Jan 17 '16 at 10:05
  • Did you symlink `/etc/uwsgi/apps-available/demo.abc.com.ini` into `/etc/uwsgi/apps-enabled/`? – gxx Jan 17 '16 at 10:33
  • @RichardSmith - That was a typo, just corrected it. – kampta Jan 17 '16 at 12:55
  • @gf_ nginx error log (`/var/log/nginx/error.log`) is empty. I think uwsgi is running as `/var/log/uwsgi/app/demo.abc.com.log` file says - `Sun Jan 17 07:54:58 2016 - *** uWSGI is running in multiple interpreter mode *** Sun Jan 17 07:54:58 2016 - spawned uWSGI master process (pid: 17624)` – kampta Jan 17 '16 at 12:59
  • @gf_ - yes, I made the symlink – kampta Jan 17 '16 at 13:00
  • what I did with nginx, is that a correct way of hosting sub-domain? In `/etc/nginx/sites-available`, right now, I have three files - default, demo.abc.com and abc.com (the latter two symlinked in `/etc/nginx/sites-enabled`) – kampta Jan 17 '16 at 13:03
  • Yes, that's correct. Please show the full `uwsgi` log and `/var/log/nginx/access.log` (for the failed requests). – gxx Jan 17 '16 at 13:13
  • 1
    Thanks. Please ping me, via @gf_ for example, otherwise I won't be notified. – gxx Jan 18 '16 at 10:54
  • 1
    Are the requests in your `nginx` log supposed to hit `demo.abc.com`? In your `flask` app, you only defined `/`, so getting 404 for `/items?c=11001&ts=1426240749118&m=20&T=` doesn't surprise me. (Are this requests really send `Host: demo.abc.com`?) – gxx Jan 18 '16 at 10:58
  • @gf_ - Sorry about that. When I open `demo.abc.com` in my browser, Chrome says `Unable to load the webpage because the server sent no data`. Also I am not sending server any request other then `/`, then why is it showing requests like `/items?c=11001&ts=1426240749118&m=20&T=` – kampta Jan 18 '16 at 14:37
  • Could you show the output of `curl demo.abc.com`? – gxx Jan 18 '16 at 14:39
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/34479/discussion-between-kampta-and-gf). – kampta Jan 18 '16 at 14:39
  • Thanks for the help again @gf_. I have added the content of other nginx files in the question itself – kampta Jan 18 '16 at 15:17
  • Remove the default config completely (you don't need this) and all occurrences of `default_server` in your `abc.com` config file. – gxx Jan 18 '16 at 15:37
  • @gf_: removed, and restarted services `nginx` and `uwsgi`. Same situation. This log appeared in `/var/log/nginx/error.log` now, `2016/01/18 10:39:43 [alert] 17107#17107: *2115302 open socket #227 left in connection 260 2016/01/18 10:39:43 [alert] 17107#17107: *2114839 open socket #243 left in connection 434 2016/01/18 10:39:43 [alert] 17107#17107: aborting ~` – kampta Jan 18 '16 at 15:42
  • I basically commented these two lines in abc.com - `listen 80 default_server; listen [::]:80 default_server;` – kampta Jan 18 '16 at 15:44
  • Which user / group is running `uwsgi`? – gxx Jan 18 '16 at 17:01
  • @gf_ : If I do a `ps -ef | grep uwsgi`, it shows me `www-data` is running 6 different `uwsgi` processes. Should I check something else? – kampta Jan 18 '16 at 17:16
  • We've to get more insight: Please define two separate log files for `demo.abc.com` using `access_log /var/log/nginx/demo.abc.com.access.log;` and `error_log /var/log/nginx/demo.abc.com.error.log debug;`. Put these to in your `demo.abc.com` `nginx` config file, restart `nginx`, do `curl demo.abc.com` and show the output of both files. – gxx Jan 18 '16 at 17:55
  • @gf_ - I added the two lines in `/etc/nginx/sites-available/demo.abc.com`, and even without doing the curl, the log got very huge within few seconds, I am copying here last 20000 lines of the log (as the actual files are 6 MB and 200 MB resp. at present) https://drive.google.com/file/d/0B_5mm3_taAXoSWprX0ozb0R3WjQ/view?usp=sharing, and https://drive.google.com/file/d/0B_5mm3_taAXoWUdMXzgzb3I0dFU/view?usp=sharing – kampta Jan 19 '16 at 15:24
  • Put this `if ($host !~ ^(demo.abc.com.com|www.demo.abc.com)$ ) { return 444; }` before the `location /` directive. As it stands, this doesn't work. – gxx Jan 19 '16 at 22:06
  • Did you had a look into the logs? All these requests send `Host: api.caphe.mobi`. Any idea what `api.caphe.mobi` is about? The IP points to your server. – gxx Jan 19 '16 at 22:08
  • To get rid of all these requests, in the logs at least, create a `nginx` config with `server_name api.caphe.mobi;` and whatever config you need (?) inside. – gxx Jan 19 '16 at 22:10
  • After this, reload `nginx`, do `curl demo.abc.com` and show the logs, which are then, hopefully, only showing requests going to demo.abc.com. – gxx Jan 19 '16 at 22:11
  • @gf_ - I have no clue what `api.caphe.mobi` is. Should I just `return 444; ` in the `nginx` config for `api.caphe.mobi;`? – kampta Jan 20 '16 at 03:49
  • Yeah...or maybe `403` is more appropriate... – gxx Jan 20 '16 at 08:06
  • Also: Please set up different log files in this config, to get rid of these requests in the other important log files, or disable logging completely. – gxx Jan 20 '16 at 08:22
  • Actually, doing `dig ...` gives: `api.caphe.mobi. 1591 IN CNAME server.ageofmobile.com.` and `server.ageofmobile.com. 1591 IN A 128.199.215.95`. Any idea what `server.ageofmobile.com` is about? – gxx Jan 20 '16 at 08:27
  • @gf_ - I tried doing `dig demo.abc.com` and `dig abc.com` but didn't find `server.ageofmobile.com`. Is there a way to not log any of 444 requests? Since there seems to be a flood of them (even if we exclude the one from `api.caphe.mobi`) – kampta Jan 20 '16 at 13:57
  • 1.) The `dig` result I've posted was the outcome of `dig api.caphe.mobi`. 2.) As I've said: You need to create another `nginx` config so the requests for `api.caphe.mobi` are handled there. Inside this config, set up either different log files or disable logging completely via `access_log off;` and `error_log off;`. 3.) You need to somehow sort out, why someone is sending you all these requests because the domain is pointed to your server. – gxx Jan 20 '16 at 14:15
  • @gf_ : Created a new nginx config with following content - `access_log off; error_log off; server { server_name api.caphe.mobi; location / { return 403; } } ` and made a symlink, however the same requests are still flooding the access/error logs of demo.abc.com. I researched a bit, and issue seems to be https://wiki.apache.org/httpd/ProxyAbuse and http://security.stackexchange.com/questions/54926/strange-apache-access-logs – kampta Jan 20 '16 at 15:32
  • However that doesn't resolve the nginx/flask issue stiil :( – kampta Jan 20 '16 at 15:35
  • 1.) You have to put the `access_log ...;` and `error_log ...;` directives into the `server {}` block. 2.) I don't think this is a proxy issue: Someone pointed a domain to your IP, so these requests are not proxied, but instead "working as they should": The clients are doing a DNS request, getting the IP of your server, and send the request to you. 3.) I didn't said nor implied that this config will solve your main issue. But it will make sure, that we'll get a log which only contains data, which is _necessary_ to debug your problem. – gxx Jan 20 '16 at 16:37
  • @gf_ Sorry, what I meant was - this proxy issue doesn't resolve the nginx/flask problem. Changed the config file to `server { server_name api.caphe.mobi; access_log off; error_log off; location / { return 403; } } ` – kampta Jan 20 '16 at 19:58
  • Also thanks for bearing with me so far. `demo.abc.com` error log still has `2016/01/20 14:59:40 [debug] 29392#29392: *55717 event timer del: 12: 1453320040534 2016/01/20 14:59:40 [debug] 29392#29392: *55717 generic phase: 0 2016/01/20 14:59:40 [debug] 29392#29392: *55717 rewrite phase: 1 2016/01/20 14:59:40 [debug] 29392#29392: *55717 http script var 2016/01/20 14:59:40 [debug] 29392#29392: *55717 http script var: "api.caphe.mobi" 2016/01/20 14:59:40 [debug] 29392#29392: *55717 http script regex: "^(demo.poolka.com.com|www.demo.poolka.com)$" ` – kampta Jan 20 '16 at 20:00
  • also I just noticed that `abc.com` has stopped working (it was working fine couple of hours back) – kampta Jan 20 '16 at 20:01
  • Well...actually I'm not sure if this process leads to something valuable or it's a route to nowhere. I've got the impression, that I'm telling you, what to do, and you're doing this then. You've to try to solve the problems you encounter for yourself at first. There has to be a reason that `abc.com` stopped working: Things don't just break, instead something has changed, for sure. – gxx Jan 20 '16 at 22:47

0 Answers0