I'm using mod_wsgi (v.4.5.20), installed with pip, in daemon mode, using a "main" apache instance as front (reverse proxy). I'm serving a django application, the "main" server hosts some other applications.
I'ld like to record the log files to a "known" directory. For now, the log files are recorded into the directory generated by the daemon-mode, aka. --server-root directory. The process is launched through a systemd service.
On the "main" apache settings, I've set the ErrorLog and CustomLog directives to my "wanted" log directory, but no files are recorded.
The "main" apache settings: (Note the X-Forwarded-For switch for company reverse proxy)
https://gist.github.com/frague59/0c9717bd5668140de392019874373f0a
Thanks for your help !
When you use mod_wsgi-express behind a front end Apache serving as proxy, the mod_wsgi-express configuration is completely independent to the front end. If you want to change where logs go for mod_wsgi-express use the --log-directory option. Presuming mod_wsgi-express is started as not root user, it will not be able to write to a root owned directory. If it needed to, you would need to start it as root and define --user and --group options to then be what user and group you want the WSGI application to run as. Because it start as root initially, then it can write logs to a root owned directory. Run mod_wsgi-express with the --help option to see all the command line options.
Related
I have Copied my files to the server and also setup the domain in the route 53 and also installed the xampp server now
When i try starting the server with the command Python manage.py runserver 0.0.0.0:80
it gives me the following error
Error: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions
but when i visit the domain it autmatically redirected to
domian.com/dashboard/
and there is all the xampp and apache etc stuff
i tried to run it with out specifying the ip and port the it redirects to the domian/dashboard
i want this to use the xampp server for mysql and run on the domain
it seems you're using the the in-built Django webserver that is meant for development purposes but not the best for production follow the steps below Deploy Django Applications on windows server using XAMPP
Prerequisite: make sure that your project already have a virtual environment, and you copied your project folder into C:\xampp\htdocs.
also you might need windows 10 sdk installed.
Step 1:
first we should set mod wsgi apache rootdir to our xampp apache directory , so in you cmd type:
set “MOD_WSGI_APACHE_ROOTDIR=c:\xampp\apache”
Step 2:
activate your project environment
Step 3:
In your virtual environment type:
pip install mod_wsgi
Step 4:
then type this:
mod_wsgi-express module-config
the output result should be something like this:
LoadFile “c:/python37–32/python37.dll” LoadModule wsgi_module
“c:/python37–32/lib/site-packages/mod_wsgi/server/mod_wsgi.cp37-win32.pyd”
WSGIPythonHome “c:/python37–32”
Step 5:
open http.conf file and copy to LoadFile and LoadModule from previous step on it
Step 6:
copy this lines in http.conf too:
#path to wsgi.py file #the first “/ “ indicates the root url
WSGIScriptAlias /
“C:/xampp/htdocs/your_project_folder/your_project/wsgi.py”
#the one that you get from step 4
WSGIPythonHome “c:/python37–32”
#website path
WSGIPythonPath “C:/xampp/htdocs/your_project_folder”
#directory of website
<Directory “C:/xampp/htdocs/your_project_folder/your_project”>
Require all granted
Step 7:
Restart your xampp and enjoy
You may also find more details on this post
I am using Easy apache 4, mod_wsgi, and Python 3.5. When I called a Django project in the server I got the following error:
(13)Permission denied: mod_wsgi (pid=24223): Unable to connect to WSGI daemon
process 'user123' on '/var/run/wsgi.8442.6.7.sock' as user with uid=3708.
Your Apache installation is likely set up to run with SECURE privileges mode. This means that the Apache child worker process is forked and privileges dropped before handling the request, which in this case is simply trying to proxy the request through to the mod_wsgi daemon process. The consequence of this is that it cannot connect to the socket for the daemon process, as it was setup with ownership to match the original Apache child worker process before privileges were dropped.
This is evident because the error message has uid in the range of a normal user and not the special apache or nobody user.
To fix it, you need to modify the WSGIDaemonProcess directive configuration and add the option:
socket-user=#3708
or:
socket-user=username
where username is replaced with the actual name of the user with uid of 3708.
The addition of this option seems to be required due to recent changes in CPanel configurations for Apache.
Sometime socket-user setting does not work.
This may occur because of WSGISocketPrefix path not found
If it is VPS:
WSGISocketPrefix /var/run/wsgi
If you are in a shared hosting:
WSGISocketPrefix ../../var/run/wsgi
Thank You
I've a Debian WebServer running Apache2.
How can I disable directory listing, globally, for all websites?
Note: This should also overwrite possible settings of virtual hosts.
Issue the following in you server terminal:
sudo a2dismod autoindex
service apache2 reload
After this all websites will have directory listing disabled.
I've been searching throughout this site for a solution but haven't been able to find one. I have a CentOS 6.4 server with Apache 2.2.15, Django 1.6 and mod_wsgi 3.2. I am using Apache to display static files and mod_wsgi to display Django content.
I placed the Django project files in the /srv directory due to this page.
When I run the Django development server, the test page that I wrote up displays properly. However, when I start my Apache server and visit 127.0.0.1, I get a 403 Forbidden error.
django.wsgi (in /srv/mysite)
import os
import sys
envpath = '/usr/lib/python2.6/site-packages'
pwd = os.path.dirname(os.path.abspath(__file__))
os.chdir(pwd)
sys.path = [env] + sys.path
os.environ['PYTHON_EGG_CACHE'] = '/srv/mysite/.python-egg'
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
site.addsitedir(envpath)
from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandlers()
httpd.conf
WSGIScriptAlias / /srv/mysite/django.wsgi
WSGIPythonPath /srv/mysite
<more aliases and tags in order to get the right static files to show>
In the httpd.conf file, the user and group that is listed is the default apache. I ran a ls -l on the /srv directory and its owner and group were listed as root. So, I ran sudo chown -R apache:apache /srv/mysite which changed the directory and all subdirectories to use apache as owner and group.
However, no matter how much I Google or try, I can't get over this 403 error.
EDIT:
I've discovered that when I disable SELinux, and the WSGIPythonPath variable in the http.conf file is django.wsgi, it results in a 500 Internal Server error. However, when I change it to wsgi.py, my website displays properly. I am curious as to why that is.
In any case, since this will be a production machine, I prefer to keep SELinux on and figure out how to get the appropriate permissions figured out.
EDIT 2:
I've edited my django.wsgi file (changed above) ala this link
EDIT 3:
I tried moving my project files into the my /home/ folder. I've been alternating between trying django.wsgi and wsgi.py but still can't get past the 403 Forbidden error. I thought it was originally a permissions issue with the /srv directory but it appears that's not the case...I am trying to figure this out but nothing is working.
EDIT 4:
I decided to just stick the development server for now...but I still need to get this working and I am at the end of my rope. Is there anyone out there that can help me?
SELinux has its own system of granting access. Your process ever has to be granted to access files on filesystem depending on SELinux context. There are some default politics and contexts defined in SELinux those are usefull for default cases of your installation. Just web files are expected to be in '/var/www'. You can mostly check the current context of files or processes using switch '-Z', see
[root#localhost]# ls -Z /var
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 www
Check the context of /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root system_u:object_r:var_t:s0 mysite
The Apache HTTPD server is allowed to access files with SELinux type httpd_sys_content_t byt it is NOT allowed to access files with SELinux type var_t.
1. Change the SELinux type for your directory and check the context
[root#localhost]# chcon -R -t httpd_sys_content_t /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite
Check if your webiste is working right now.
Till now it is not finished yet, while you relabel filesystem to default or if you use a daemon to check or relabel itself, you risk to lose your new labeling.
2. Make the default labaling for your directory
Create the default labeling by 'semange' and apply it on your directory by 'restorecon'
[root#localhost]# semanage fcontext -a -t httpd_sys_content_t /srv/mysite
[root#localhost]# restorecon -v -R /srv/mysite
[root#localhost]# ls -Z /srv
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mysite
Right now your SELinux labeling is fixed.
Note: It is possible regular expressions to define default context.
Debian: I'm not a Debian user, so the SELinux type can be a bit different, the principle is just the same, check the SELinux type of your apache directory and set it on your directory you want to be accessible from apache.
Read more at RedHat:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
Fedora SELinux documentation:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
I'm just starting out with EC2, and I've pulled down a git repo that I started on my local machine and so I know that it works running the server from there, and it seems to works when I run my server from the EC2 instance I have running, but for some reason, when I visit the elastic IP address of that instance I get a page-not-found. Any idea on why that might be?
So, I've now started using nginx, and made a conf file following the instructions here: https://code.djangoproject.com/wiki/DjangoAndNginx that is as follows:
server {
listen 80;
server_name ec2-54-242-149-154.compute-1.amazonaws.com;
access_log /var/log/nginx/USBag.access.log;
error_log /var/log/nginx/USBag.error.log;
location /basicMap/ {
alias /home/www/ec2-54-242-149-154.compute-1.amazonaws.com/basicMap/;
expires 30d;
}
location / {
include fastcgi_params;
fastcgi_pass 127.0.0.1:8080;
}
}
basicMap is a place that I have already defined in my django app, and the linked ec2 ip is the one my server is running on. I am having a lot of difficulty finding documentation on how to proceed or how to determine if my conf file is correct or not. Using the standard python manage.py runserver doesn't work however. Advice on how to proceed?
There is a lot of info about setting up a production django server out there, and I'll give you my personal preferences below, but before all that let's backup and see if we can just get any response from the production server.
To start the development server on your EC2 instance run:
manage.py runserver 0.0.0.0:8000
That command will cause runserver to bind to all interfaces and serve files to the external world. You'll never want to do this outside of development, but it is a good way just to test if your django app is setup before complicating things. Now try hitting your EC2 instance and see if you get a response.
If that's still not working, make sure you allow incoming connections to the server's port (8000 in the command above, 80 once live). You could test that you have ports open using netcat (nc -l).
Once you are satisfied that you have your app setup, I'd recommend you use nginx as your front end webserver and gunicorn as your django webserver in production. You'll likely want to look into setting up a virtualenv, supervisord etc for your production setup (here is a tutorial: http://senko.net/en/django-nginx-gunicorn/), but all that depends on the specifics of your project.