Ok, problem solved! I specifically disabled the apparmor profile definition for apache by running the following commands:
ln -s /etc/apparmor.d/usr.sbin.apache2 /etc/apparmor.d/disable/ apparmor_parser -R /etc/apparmor.d/usr.sbin.apache2 That did the trick Thanks for the help! On Thursday, May 2, 2019 at 10:08:15 AM UTC+3, Amit Amely wrote: > > Ownership and permissions on '/var/run/apache2': > > drwxr-xr-x 2 root root > > apparmor is installed and enabled > I executed apparmor_status and saw this: > > apparmor module is loaded. > 27 profiles are loaded. > 25 profiles are in enforce mode. > ... > /usr/sbin/apache2 > /usr/sbin/apache2//DEFAULT_URI > /usr/sbin/apache2//HANDLING_UNTRUSTED_INPUT > ... > 4 processes are in enforce mode. > /usr/sbin/apache2 (994) > /usr/sbin/apache2 (995) > /usr/sbin/apache2 (996) > ... > > I tried disabling apparmor as explained here > https://help.ubuntu.com/community/AppArmor#Disable_AppArmor_framework > > But afterwards I got the same output from apparmor_status, and the issue > of the SOCK files wasn't solved > > > On Wednesday, May 1, 2019 at 7:34:39 PM UTC+3, Graham Dumpleton wrote: >> >> What are the ownership/permissions on the directory '/var/run/apache2'? >> >> Is apparmor installed and enabled? >> >> On 1 May 2019, at 10:29 am, Amit Amely <[email protected]> wrote: >> >> Hi >> >> We run a Django software under Apache HTTP server using mod_wsgi in the >> cloud >> To debug it with a Pycharm IDE from our developers hosts, we use the >> remote server debug procedure that is recommended by JetBrain >> We stop Apache service and start it directly with -X flag >> The complication here is that the cloud host doesn't know the local host, >> so we overcome it by doing SSH tunneling >> Another limitation is that this procedure requires that the wsgi will run >> on single process, single thread >> Otherwise we can only stop on a breakpoint if it was initiated by the >> first WSGI request >> So for debug purposes we change the Apache settings, and tell it to run >> a WSGIDaemonProcess with threads=1 >> (by default our application runs without WSGI deamon process) >> It worked well for a while, until we had to move from Ubuntu 14 to Ubuntu >> 18.04 >> Since then this procedure no longer works >> >> I spent some time investigating it and noticed that the wsgi SOCK file is >> created as 'root', and as a result, we get this error: >> >> Permission denied: [client 127.0.0.1:35112] mod_wsgi (pid=11687): Unable >> to connect to WSGI daemon process 'debug' on >> '/var/run/apache2/wsgi.11687.0.1.sock' as user with uid=33. >> >> I tried setting socket-user=www-data but got the same result, with this >> warning: >> >> Operation not permitted: mod_wsgi (pid=11687): Couldn't change owner of >> unix domain socket '/var/run/apache2/wsgi.11687.0.1.sock' to uid=33. >> >> I tried setting WSGISocketPrefix to a folder owned by www-data but it >> didn't matter. The SOCK file was created by 'root' and mod_wsgi wasn't able >> to change its ownership >> >> Additional info: >> Ubuntu 18.04 >> Custom build of Python with some minor changes we do for security >> purposes - based on version 2.7.15rc1 >> Precompiled Apache version 2.4.39 >> MPM mode is 'event' >> Apache runs as www-data >> Precompiled mod_wsgi version is 4.5.17 >> >> To check what might have gone wrong, I launched a clean cloud host with >> Ubuntu 18.04 and prepared a similar configuration that runs a very simple >> django app >> I did manage to debug it >> The differences are: >> I compiled python version with no hacks based on version 2.7.15 >> I compiled HTTP Server based on sources of 2.4.29 >> I compiled mod_wsgi for version 4.5.17 >> Unlike the full software, I didn't define SSL and virtual host >> (But then again, we were able to debug this software with SSL and virtual >> host definition when it was running on Ubuntu 14) >> >> There may be some information I'm not fully aware of, some special >> configurations done by our build manager as part of the migration to Ubuntu >> 18 >> But we weren't able to make the links yet... >> >> -- >> 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. >> >> >> -- 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.
