Invalid HTTP_HOST header in shared server

#!/bin/bash

# ./sites_installer.sh -n <projectname> -h <domain> -u <user> -r <install path> -g https://<repository url>.git -b <git branch>

NAME=""
BASE="~"
VHOME="/environment/"
PHOME="/projects/"
PYTHON="/usr/bin/python3"
PROJECT_NAME="project"
USER=`whoami`
SERVER_NAME="project"
BRANCH=''
REPO=""

while getopts ":pfg:b:n:r:h:u:" optname
do
case "$optname" in
"p")
PYTHON="/usr/bin/python2"
;;
"n")
PROJECT_NAME=$OPTARG
NAME=$PROJECT_NAME
;;
"r")
BASE=$OPTARG
;;
"h")
SERVER_NAME=$OPTARG
;;
"u")
USER=$OPTARG
;;
"g")
REPO=$OPTARG
;;
"b")
BRANCH=$OPTARG
;;
"?")
echo "-p use python2"
echo "-n name of project"
echo "-h server name ej. example.com"
echo " ? help"
return 0

;;
*)
# Should not occur
echo "Unknown error while processing options"
;;
esac
done

mkdir -p $BASE
VHOME=$BASE$VHOME$PROJECT_NAME
PHOME=$BASE$PHOME$PROJECT_NAME

mkdir -p $PHOME

virtualenv -p $PYTHON $VHOME
source $VHOME/bin/activate
pip install gunicorn
cd $PHOME
git clone $REPO

cd ..
mv $NAME $NAME.old
mv $NAME.old/$NAME .
rm -rf $NAME.old
cd $NAME

if [ -n $BRANCH ]
then
git checkout $BRANCH
fi

pip install -r requirements.txt

mkdir -p $PHOME/static/
mkdir -p $PHOME/media/
mkdir -p $PHOME/logs/
mkdir -p $PHOME/certs/

openssl req -subj '/CN='$PROJECT_NAME'/O=SOLVO./C=CR' -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout $PHOME/certs/$NAME.key -out $PHOME/certs/$NAME.crt

echo -e `cat << EOF
\n[program:$PROJECT_NAME]
\ncommand = $PHOME/gunicorn_start ; Command to start app
\nuser = $USER ; User to run as
\nstdout_logfile = $PHOME/logs/gunicorn_supervisor.log
\nredirect_stderr = true ; Save stderr in the same log
\nenvironment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8
EOF` > $PHOME/supervisor.txt
touch $PHOME/logs/gunicorn_supervisor.log

echo -e `cat << EOF #!/bin/bash
\n
\nNAME="$PROJECT_NAME" # Name of the application
\nDJANGODIR=$PHOME # Django project directory
\nSOCKFILE=$PHOME/gunicorn.sock # we will communicte using this unix socket
\nUSER=$USER # the user to run as
\nGROUP=webapps # the group to run as
\nNUM_WORKERS=3 # how many worker processes should Gunicorn spawn
\nDJANGO_SETTINGS_MODULE=$NAME.settings # which settings file should Django use
\nDJANGO_WSGI_MODULE=$NAME.wsgi # WSGI module name
\n
\necho "Starting \\$NAME as \`whoami\`"
\n
\n# Activate the virtual environment
\ncd \\$DJANGODIR
\nsource $VHOME/bin/activate
\nexport DJANGO_SETTINGS_MODULE=\\$DJANGO_SETTINGS_MODULE
\nexport PYTHONPATH=\\$DJANGODIR:$PYTHONPATH
\n
\nRUNDIR=$(dirname \\$SOCKFILE)
\ntest -d \\$RUNDIR || mkdir -p \\$RUNDIR
\n
\n# Start your Django Unicorn
\n# Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon)
\nexec $VHOME/bin/gunicorn \\${DJANGO_WSGI_MODULE}:application
--name \\$NAME
--workers \\$NUM_WORKERS
--user=\\$USER --group=\\$GROUP
--bind=unix:\\$SOCKFILE
--log-level=info
--log-file=-
EOF` > $PHOME/gunicorn_start

chmod u+x $PHOME/gunicorn_start

############################ TERMINAR ###############################

echo -e `cat << EOF
\nupstream $NAME._app_server {
\n# fail_timeout=0 means we always retry an upstream even if it failed
\n# to return a good HTTP response (in case the Unicorn master nukes a
\n# single worker for timing out).
\n
\nserver unix:$PHOME/gunicorn.sock fail_timeout=0;
\n}
\nserver {
\n listen <Server IP>:80;
\n server_name $SERVER_NAME www.$SERVER_NAME;
\n return 301 https://\\$server_name\\$request_uri;
\n}
\nserver {
\n
\nlisten <Server IP>:443;
\nserver_name $SERVER_NAME;
\nssl on;
\nssl_certificate $PHOME/certs/$NAME.crt;
\nssl_certificate_key $PHOME/certs/$NAME.key;
\nclient_max_body_size 4G;
\n
\naccess_log $PHOME/logs/nginx-access.log;
\nerror_log $PHOME/logs/nginx-error.log;
\nlocation /static/ {
\nalias $PHOME/static/;
\n}
\nlocation /media/ {
\nalias $PHOME/media/;
\n}
\n
\nlocation / {
\n# an HTTP header important enough to have its own Wikipedia entry:
\n# http://en.wikipedia.org/wiki/X-Forwarded-For
\nproxy_set_header X-Forwarded-For \\$proxy_add_x_forwarded_for;
\n
\n# enable this if and only if you use HTTPS, this helps Rack
\n# set the proper protocol for doing redirects:
\n# proxy_set_header X-Forwarded-Proto https;
\n
\n# pass the Host: header from the client right along so redirects
\n# can be set properly within the Rack application
\nproxy_set_header Host \\$http_host;
\n
\n# we don't want nginx trying to do something clever with
\n# redirects, we set the Host: header above already.
\nproxy_redirect off;
\n
\n# set "proxy_buffering off" *only* for Rainbows! when doing
\n# Comet/long-poll stuff. It's also safe to set if you're
\n# using only serving fast clients with Unicorn + nginx.
\n# Otherwise you _want_ nginx to buffer responses to slow
\n# clients, really.
\n# proxy_buffering off;
\n
\n# Try to serve static files from nginx, no point in making an
\n# *application* server like Unicorn/Rainbows! serve static files.
\nif (!-f \\$request_filename) {
\nproxy_pass http://$NAME._app_server;
\nbreak;
\n}
\n}
\n
\n# Error pages
\nerror_page 500 502 503 504 /500.html;
\nlocation = /500.html {
\nroot $PHOME/static/;
\n}
\n}
EOF` > $PHOME/nginx

#python manage.py migrate
#python manage.py runserver

Hi,

I am having some issue with gunicorn/nginx configuration. I have a shared server that support several sites (all based in Django)  with the same ip address.

Invalid HTTP_HOST header: 'www.mysite.com'. You may need to add 'www.mysite.com' to ALLOWED_HOSTS.

I checked and all projects have ALLOWED_HOSTS well configured, so I read with attention the exception and notice that all exception are send by the same gunicon socket
'gunicorn.socket': <socket.socket fd=10, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0, laddr=/<path project>/gunicorn.sock>.

So, I think are a nginx bad configuration, but I don't know what is wrong.

I followed this tutorial
http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/

I use this attach file as script to create new projects in my server.

Thanks

--

"La utopía sirve para caminar" Fernando Birri

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAG%2B5VyOwE1%2BpG-zZ6x3769BmTvsRByy6h3bhmCK9uxSTy4y%3DEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.