I was tasked with making some changes to a Django application. I've never worked with Django and I am having trouble figuring out how to get my changes to compile and be available online.
What I know so far is that the application is currently available online. netstat tells me that httpd is listening on port 80. My change was made in the myapp/views.py file.
I tried to restart httpd using services httpd restart but my changes did not take effect. I've been looking into the issue a bit an I believe that I need to run a command along the lines of:
I tried calling python manage.py runserver MY.IP.AD.DR:8000 and I get:
python manage.py runserver 129.64.101.14:8000
Validating models...
0 errors found
Django version 1.4.1, using settings 'cutsheets.settings'
Development server is running at http://MY.IP.AD.DR:8000/
Quit the server with CONTROL-C.
Nice that no errors are found but when I navigate to http://MY.IP.AD.DR:8000/ I just get a "Unable to connect" message from my browser. I tried with port 81 too and had the same problem.
Without knowing exactly how your application is set up, I can't really say exactly how to solve this problem.
I can tell you that it's quite common to use two web servers with Django - one handles the static content, and reverse proxies everything else to a different port where the Django app is listening. Restarting the normal HTTP daemon therefore wouldn't affect the Django app, so you need to restart the one handling the Django app. Until you restart it, the prior version of the code will be running.
I generally use Nginx as my static server and Gunicorn with the Django app, with Supervisor used to run Gunicorn, and this is a common setup. I recommend you take a look at the config for the main web server to see if it forwards anything to another port. If so, you need to see what server is running on that port and restart it.
Also, is there a Fabric configuration (fabfile.py)? A lot of people use Fabric to automate Django deployments, and if there is one then there may be a command already defined for deploying.
Related
Up to now I followed this advice to reload the code:
https://code.google.com/archive/p/modwsgi/wikis/ReloadingSourceCode.wiki
This has the drawback, that the code changes get detected only every N second. I could use N=0.1, but this results in useless disk IO.
AFAIK the inotify callback of the linux kernel is available via python.
Is there a faster way to detect code changes and restart the wsgi handler?
We use daemon mode on linux.
Why code reload for mod_wsgi at all
There is interest in why I want this at all. Here is my setup:
Most people use "manage.py runserver" for development and some other wsgi deployment for for production.
In my context we have automated the creation of new systems and prod and development systems are mostly identical.
One operating system (linux) can host N systems (virtual environments).
Developers can use runserver or mod_wsgi. Using runserver has the benefit that it's easy for debugging, mod_wsgi has the benefit that you don't need to start the server first.
mod_wsgi has the benefit, that you know the URL: https://dev-server/system-name/myurl/
With runserver you don't know the port. Use case: You want to link from an internal wiki to a dev-system ....
A dirty hack to get code reload for mod_wsgi, which we used in the past: maximum-requests=1 but this is slow.
Preliminaries.
Developers can use runserver or mod_wsgi. Using runserver has the
benefit that you it easy for debugging, mod_wsgi has the benefit that
you don't need to start the server first.
But you do, the server needs to be setup first and that takes a lot of effort. And the server needs to be started here as well though you can configure it to start automatically at boot.
If you are running on port 80 or 443 which is usually the case, the server can be started only by the root. If it needs to be restarted you will have to ask the super user's help again. So ./manage.py runserver scores heavily here.
mod_wsgi has the benefit, that you know the URL:
https://dev-server/system-name/myurl/
Which is no different from the dev server. By default it starts on port 8000 so you can access it as http://dev-server:8000/system-name/myurl/. If you wanted to use SSL with the development server you can use a package such as django-sslserver or you can put nginx in front of django development server.
With runserver you don't know the port. Use case: You want to link from >an internal wiki to a dev-system ....
With runserver, the port is well defined as mentioned above. And you can make it listen on a different port for exapmle with:
./manage.py runserver 0.0.0.0:9090
Note that if you put development server behind apache (as a reverse proxy) or NGINX, restarting problems etc that I have mentioned above do not apply here.
So in short, for development work, what ever you do with mod_wsgi can be done with the django development server (aka ./manage.py runserver).
Inotify
Here we are getting to the main topic at last. Assuming you have installed inotify-tools you could type this into your shell. You don't need to write a script.
while inotifywait -r -e modify .; do sudo kill -2 yourpid ; done
This will result in the code being reloaded when ...
... using daemon mode with a single process you can send a SIGINT
signal to the daemon process using the ‘kill’ command, or have the
application send the signal to itself when a specific URL is
triggered.
ref: http://modwsgi.readthedocs.io/en/develop/user-guides/frequently-asked-questions.html#application-reloading
alternatively
while inotifywait -r -e modify .; do touch wsgi.py ; done
when
... using daemon mode, with any number of processes, and the process
reload mechanism of mod_wsgi 2.0 has been enabled, then all you need
to do is touch the WSGI script file, thereby updating its modification
time, and the daemon processes will automatically shutdown and restart
the next time they receive a request.
In both situations we are using the -r flag to tell inotify to monitor subdirectories. That means each time you save a .css or .js file apache will reload. But without the -r flag changes to python code in subfolders will be undetected. To have the best of both worls, remove css, js, images etc with the --exclude directive.
What about when your IDE saves an auto backup file? or vim saves the .swp file? That too will cause a code reload. So you would have to exclude those file types too.
So in short, it's a lot of hard work to reproduce what the django development server does free of charge.
You can use inotify hooktables to run any command you want depending on a i-notify signal (here's my source link: http://terokarvinen.com/2016/when-files-change-take-action-inotify-hookable).
After looking the tables you can just reload the code of apache.
For your specific problem, it should be something like:
inotify-hookable --watch-directories sources/ --recursive --on-modify-command './code_reload.sh'
In the previous link, the command to execute was just a simple touch flask/init.wsgi
So, the whole code (adding ignored files was):
inotify-hookable --watch-directories flask/ --recursive --ignore-paths='flask/init.wsgi' --on-modify-command 'touch flask/init.wsgi'
As stated here: Flask + mod_wsgi automatic reload on source code change, if you have enabled WSGIScriptReloading, you can just touch that file. It will cause the entire code to reload (not just the config file). But, if you prefer, you can set any other script to reload the code.
After googling a bit, it seems to be a pretty standard solution for that problem and I think that you can use it for your application.
I'm running a Django based server on a Mac. When running it using the default "python manage.py runserver" I can access it through a browser using "http://127.0.0.1:8000/".
The thing is I want to access it from other machines on the network. When I go to network settings I can see that the IP is for example 10.0.0.15. In the past I used to be able to run a Django based server using "python manage.py runserver 10.0.0.15:8000" and then access it using that address from any other machine in the local network, including the machine running the server.
Now, when I'm trying to access it using "http://10.0.0.15:8000/" even from a browser on the same machine I can see in the terminal that the server has received a request, but I get a Bad Request (400) response. What am I doing wrong?
I tried running python manage.py runserver 0.0.0.0:8000 as Leonardo Andrade suggested. It still didn't work, but it was the first part of the solution. The problem was that the DEBUG setting was False. In that case Django takes into account the ALLOWED_HOSTS setting.
Possible solutions:
Set DEBUG setting to True. This is a good idea for debugging anyway. ALLOWED_HOSTS setting is not taken into account in that case.
Keep DEBUG setting as False and add to ALLOWED_HOSTS '0.0.0.0' or '*' or your local ip (e.g. '10.0.0.15'). This is only for testing purposes. Make sure you don't allow just any hosts when you run a production server.
Of course, run the server on 0.0.0.0:8000.
A nice solution for accessing the server from other machines when the server runs an OS X is to go to Settings->Sharing on your Mac. There, under Computer Name you can see the name other computers can use to access this computer in a local network (e.g. my-mac.local). You can add that name to ALLOWED_HOSTS and then access the server using it (e.g. http://my-mac.local:8000/).
Try to run python manage.py runserver 0.0.0.0:8000
So, I have looked around stack overflow + other sites, but havent been able to solve this problem: hence posting this question!
I have recently started learning django... and am now trying to run it on ec2.
I have an ec2 instance of this format: ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com on which I have a django app running. I changed the security group of this instance to allow http port 80 connections.
I did try to run it the django app the following ways: python manage.py runserver 0.0.0.0:8000 and python manage.py runserver ec2-xx-xxx-xx-xxx.us-west-2.compute.amazonaws.com:8000 and that doesnt seem to be helping either!
To make sure that there is nothing faulty from django's side, I opened another terminal window and ssh'ed into the instance and did a curl GET request to localhost:8000/admin which went through successfully.
Where am I going wrong? Will appreciate any help!
You are running the app on port 8000, when that port isn't open on the instance (you only opened port 80).
So either close port 80 and open port 8000 from the security group, or run your app on port 80.
Running any application on a port that is less than 1024 requires root privileges; so if you try to do python manage.py runserver 0.0.0.0:80 as a normal user, you'll get an error.
Instead of doing sudo python manage.py runserver 0.0.0.0:80, you have a few options:
Run a pre-configured AMI image for django (like this one from bitnami).
Configure a front end server to listen on port 80, and then proxy requests to your django application. The common stack here is nginx + gunicorn + supervisor, and this blog post explains how to set that up (along with a virtual environment which is always a good habit to get into).
Make sure to include your IPv4 Public IP address in the ALLOWED_HOSTS section in Django project/app/settings.py script...
So, probably a dumb question, but I am beginning to learn all this so your feedback will be valuable for me.
The question is: In flask documentation it says start the flask server by entering the command 'python hello.py' and I do it successfully to see the output on localhost:5000. Now, I have a shared hosting plan and if I upload this file over there will i need to initiate the server over there as well like this? If so, when I close the terminal over there, will the flask server shut down (because when I close the terminal on my computer it shuts down the flask server and the results are no more available on localhost:5000)?.. It basically suggests me that I have to keep running the terminal all the time..please tell me what is the basic idea here? Thanks.
What you're asking is how you deploy your app. There are many options, that will depend on your needs, your hosting service, etc.
You should check the flask docs for the options. http://flask.pocoo.org/docs/deploying/
In essence, you'll have your flask app running as a local service on the server, so it's not shut down when you close the terminal, and an HTTP server that somehow proxies requests to that service. I guess the most popular is uWSGI with nginx.
When you upload your code to a remote host, you will need to provide a way to start the server and get things running. How this works is host- and software-dependent. As an example, here is some documentation for how you would fire Flask up on Heroku.
I am hosting a django-based site on a local machine (I have full access/control to it).
This site authenticates users against a remote active directory via the django ldap plugin.
authenticating against LDAP server used to work!
Now, when trying to authenticate against the LDAP server, the request just hangs until it times out. I couldn’t find anything useful in the logs.
The server setup is:
NginX, Django 1.3, Fedora 15, mySql 5.1.
I don’t know what logs I should try to look at.
(I've tried looking in nginx access and error logs but to no use.)
Things I tried:
Running the site on django's and accessing it via localhost (not going through Nginx, but accessing python manage.py directly, via the runserver command). this works
Running ldapsearch from the command line. this works
edit:
i used wireshark to look at the back-and-forth with the ldap server. the interaction seems to be fine - django sends a request to bind and it receives a success msg, and then sends a search query and a user object is returned. however, after this communication django seems to hang. when i "Ctrl-c" in the django shell after running "authenticate(username=user, password=pass)", the stack trace is sitting somewhere in the django-ldap library.
Please help, I have no idea what changed that caused this problem.
Thank you in advance
Active Directory does not allow anonymous binds for authorization; you can bind anonymously but you cannot do anything else.
Check if the user that is being used to bind with AD has valid credentials (ie, the account hasn't expired). If it has, you'll get these strange errors.