On Feb 10, 2016 12:23 AM, "John Travolta" <travolta...@gmail.com> wrote: > > Hi, > > I succeeded to run development python application: python3 ./manage.py runserver 0.0.0.0:8080 > > but now I need to make deployment, honestly I didn't succed to do it from august. I hope here I will get help. > > first of all, settings.py had to be corrected from debug = true to DEBUG = False & ALLOWED_HOSTS = ['*',] should be with domain name, let's say: mijaw.com, ALLOWED_HOSTS = ['https://mijaw.com',] > > I use debian + apache with iRedMail (I think iredmail already installed wsgi module for apache), all my sites at my VPS are redirected from port 80 to 443, visitors are forced to use httpS, it means when I tried 443 and 80, port was alrwady in use and I had to choose 8080. but I want that my python application is deployed with ssl, 443 port. > if it is too much complicated let's try first with 8080, it doesn't matter so much, > > the biggest problem for me is connecting python application (placed in root folder) with domain/apache configuration file (virtual host): /etc/apache2/sites-available/mijaw-ssl.conf > mijaw-ssl.conf is apache configuration file for domain with port 443. as I said, it is forced from 80 to 443, so, it is httpS://mijaw.com >
Don't place your project in the root folder, meaning both /root on the box, or wherever Apache has configured as the root folder (probably /var/www/html or similar). WSGI can access your project outside of the Apache root, and if left there, a bad configuration in Apache can expose your source code, including your settings file and consequently, your database password, among other things. Pick a folder somewhere you can remember, maybe /srv/django or /var/lib/django. Wherever you put it, make sure that the Apache system user has read access to that directory and all subdirectories, and no write access (special consideration may be needed for an SQLite DB file). > first I will tell you my python paths: > my settings.py is located at: /root/mercury/mercury > but there is also urls.py and wsgi.py in this folder: /root/mercury/mercury > admins.py, urls.py, templates folder are located at: /root/mercury/messages > my virtualenv folder is: /root/env/bin/activate > if static folder is important, there are css,fonts,javascript and other folders: /root/mercury/static > html files are here: /root/mercury/messages/templates > Same goes for your virtualenv. Move it out of your /root directory. You probably should just recreate the virtualenv at the new location, rather than trying to move the existing one. The process is easy enough to duplicate your existing one with a freeze output from pip. > my problem is: all of this should be connected with /etc/apache2/sites-available/mijaw-ssl.conf > > here it is automatically created by iRedMail, I suppose it should be added similar for my python app: > So you already have an instance of iRedMail running using HTTPS on the server? That heavily complicates your deployment. What site do you expect to show up when you go to the domain? Trying not to get into a technical discussion about how HTTPS works, but basically you can only have a single site running on a single IP on the server, unless your server is capable of handling something called the Server Name Indicator (SNI). You have 4 choices: A. Completely remove the instance of iRedMail from Apache and update the configuration to only serve your Django site via WSGI. See https://docs.djangoproject.com/en/1.9/howto/deployment/wsgi/modwsgi/ for the Apache config. B. Acquire a second public IP address for the server and attach your Django site to it with its own TLS certificate. All requests for Django would go to the new IP, while your original IP would still serve iRedMail, each with their own TLS certificate. C. Configure an SNI domain and certificate within Apache, assuming your version of Apache and OpenSSL support it. Most recent distros should, but it's still a new enough feature that you should check. D. Deploy your site on a separate VPS without a conflicting HTTPS configuration. HTTPS is not fun to deal with, especially when dealing with publicly signed certificates, intermediate CA chains (which are quite common), DNS, and SNI. Include on top of that several SSL/TLS versions and cipher types that are being deprecated by browsers on an ongoing basis, and keeping up with the various OpenSSL vulnerabilities that are now more frequent since the POODLE attack was made famous and brought attention to the fragmented and complex code base that OpenSSL uses (which they're fixing, but it's a slow process). Your system updates will take care of most of that for you, but a few of the things I mentioned would require configuration file changes down the road. There's a bit of work involved in keeping the green padlock icon in the browser (visit the login page for your bank website and look for it, usually near the address bar or done message saying that this site is secure), and avoiding the "this site can't be trusted, continue anyway?" errors in the browser. I guess what I'm trying to say is, what you're trying to do is possible, but not easy if you aren't familiar with how Apache (or insert name of web server process) handles HTTPS. All of them will have the same trouble, and you can't run more than one on the same port. You can run Apache on a different port using HTTPS, though, as you mentioned. But that obviously changes your URL to include the non-standard port (https://mydomain.com:8080). Don't expect that to climb very high in the search rankings, if the crawlers find it at all (if you care about that sort of thing). Once you get past all that, though, and assuming you generate relative URL's within Django (which is the default using reverse() or {% url %} in your templates), then your site should run fine assuming you make the settings tweaks recommended by the Django team for HTTPS connections: https://docs.djangoproject.com/en/1.9/topics/security/#ssl-https I apologize if this seems a bit cynical. Having done other HTTPS deployments with Apache (not with Django specifically, but the process is the same, Django itself is the easy part), I've found that you'll almost never get the HTTPS settings right on the first, second, or 15th try. Even with experience, it's difficult to get everything lined up correctly due to the number of components that require configuration for a successful connection. I'm not trying to dissuade you from attempting to implement HTTPS, just trying to warn and prepare you for the many esoteric issues that may creep up. It'll be a good learning experience. -James -- 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+unsubscr...@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/CA%2Be%2BciVDBAvcTeiOFEYxRjytaseommxjNop-Za7icD-EJ5F65A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
