> On 28 May 2016, at 4:50 AM, Tanuka Dutta <[email protected]> wrote: > > Yes, this works. I hadn't spotted that difference. Thank you! > I also re-ran runmodwsgi and the httpd.conf now contains the correct > directives without the <Files>. > > I don't know what I might have done wrong earlier…
Whoops, I missed that you were using mod_wsgi-express as mentioned in subject. Thus this is sort of my fault. I myself have been caught by this indirectly just last week as well and didn’t tweak was same issue. I never looked at the generated configuration in my case to realise Files was used how it was as I just fixed the underlying problem. Anyway, the problem was caused by the fact that the file system directory you were referencing using —url-alias didn’t exist at the time mod_wsgi-express was run to generate the setup. When —url-alias is used I need to do a check for trailing slash on the path to try and fix up a potential mistake by a user where usage of slashes on URL and target directory weren’t balanced. If I don’t then Apache doesn’t process things properly. Part of that check looks at the target path and if it is a directory does things one way and if not, does it another way. Because the check is to see whether it is a directory, it causes a problem if the directory doesn’t exist at that point. I will have to go back and look at the code again and perhaps change the logic around so that rather than fallback to assuming the target path is a file, which is less likely case, assume it will be a directory unless the target path exists and is a file. That way it will work if the directory doesn’t exist yet. Does mean it will not then work properly in case where target path is a file but doesn’t at that point, but that is less likely scenario and I have to fallback one way or the other and can’t avoid one case loosing out where stuff doesn’t exist yet. > How is this working with Apache 2.4, shouldn't the syntax now be "Require all > granted”? Apache 2.4 has a mod_access_compat module which provides older directives in Apache 2.4. I rely on that so that I don’t have to have switch log on all the places where these directives are used. Graham > Regards, > Tanuka > > On Fri, May 27, 2016 at 9:24 PM, Graham Dumpleton <[email protected] > <mailto:[email protected]>> wrote: > >> On 27 May 2016, at 3:57 AM, Tanuka Dutta <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks, Graham. >> >> I'm encountering a different problem with Apache 2.4 and mod_wsgi 4.4.22. I >> am able to upload media files but unable to view them through the browser. >> >> This is running on a RHEL 7.2 server with Django 1.8.8. >> >> I used this command to generate the httpd.conf: >> >> $ python manage.py runmodwsgi --setup-only --port=80 --user=apache >> --group=apache --server-root=/home/syt_admin/projects/vishwaas/www >> --url-alias /media /home/syt_admin/projects/vishwaas/www/media >> >> If I search for the string 'media' in the generated httpd.conf, I see these >> lines: >> >> Alias '/media' '/home/syt_admin/projects/vishwaas/www/media' >> >> <Directory '/home/syt_admin/projects/vishwaas/www'> >> <Files 'media'> >> Order allow,deny >> Allow from all >> </Files> >> </Directory> > > Instead of this try: > > <Directory '/home/syt_admin/projects/vishwaas/www/media'> > Order allow,deny > Allow from all > </Directory> > > Am not sure that Files can be used on a directory, only files. > > Graham > >> My Django settings file has the corresponding definitions: >> >> MEDIA_ROOT = '/home/syt_admin/projects/vishwaas/www/media/' >> MEDIA_URL = '/media/' >> >> The files get uploaded to the correct location, by user 'apache'. But when I >> click on the link to the file in the browser, I get the error message: You >> don't have permission to access /media/<filename> on this server. >> >> Also, the Apache error_log contains this error: >> >> [Fri May 27 06:45:05.181364 2016] [access_compat:error] [pid 24953:tid >> 140221960361728] [client <ip address>:<port>] AH01797: client denied by >> server configuration: >> /home/syt_admin/projects/vishwaas/www/media/<filename>, referer: http://<ip >> address>/admin/schools/school/1/ >> >> I know that the Alias directives for Apache 2.4 are supposed to be different >> ie "Require all granted" but I don't see that in the generated httpd.conf >> file. >> >> Am I missing some option when invoking runmodwsgi?? >> >> Regards, >> Tanuka >> >> >> >> >> On Thu, May 26, 2016 at 9:48 PM, Graham Dumpleton >> <[email protected] <mailto:[email protected]>> wrote: >> The —ssl-certificate-chain-file option was included in 4.4.23. >> >> http://modwsgi.readthedocs.io/en/develop/release-notes/version-4.4.23.html >> <http://modwsgi.readthedocs.io/en/develop/release-notes/version-4.4.23.html> >> >> Graham >> >>> On 26 May 2016, at 7:33 AM, Tanuka Dutta <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> OK, thanks. I was looking under the 4.4.x series. >>> >>> I assume 4.5.2 incorporates this change? >>> >>> Regards, >>> Tanuka >>> >>> On Thu, May 26, 2016 at 7:45 PM, Graham Dumpleton >>> <[email protected] <mailto:[email protected]>> wrote: >>> The latest in PyPi should be 4.5.2. Make sure you aren't following link by >>> version, see latest. >>> >>> Graham >>> >>> > On 26 May 2016, at 00:29, Tanuka Dutta <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Hi Graham, >>> > >>> > I see that the latest official release on https://pypi.python.org >>> > <https://pypi.python.org/> is still >>> > 4.4.22. >>> > >>> > Any timeframe set for the next official release that would incorporate the >>> > extra option =E2=80=94ssl-certificate-chain-file some/path/file.crt ? >>> > >>> > Meanwhile, I'm continuing with the developer version that you gave me. >>> > >>> > Rega >>> >> >> > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
