On Friday, October 21, 2022 at 3:23:00 AM UTC-5 Graham Dumpleton wrote:
>
> On 21 Oct 2022, at 6:40 pm, Malcolm Cook <malcol...@gmail.com> wrote:
>
> Hello,
>
> I have configured apache2 for running any .wsgi apps out of ~/public_html
>
> It works for a simple ~/public_html/hello_world.wsgi
>
> Hooray!
>
> However, I am having trouble when my app uses
>
> /usr/bin/python3 -m venv venv
>
> with the simplest of dash apps.
>
> I have so far learned to include in my app.wsgi the following:
>
> site.addsitedir('/home/mec/public_html/dash101/dash101.wsgi')
>
>
> The site.addsitedir() function accepts a directory, not a file. For
> working with virtual environments ensure you read
>
>
> https://modwsgi.readthedocs.io/en/master/user-guides/virtual-environments.html
>
>
Apologies - for some bad reason I edited the message after copy-pasting. I
had read your fine documentation and followed its advice only failed to
share correct details.
> allowing the app to find the dash modules installed into its venv when run
> under apache mod_wsgi.
>
> The app now works from the command line; when run under apache mod_wsgi it
> only successfully finds the modules in the venv but then fails with:
>
> [root@hd1991356yb mec]# [Fri Oct 21 01:04:29.974555 2022] [wsgi:info] [pid
> 69391] mod_wsgi (pid=69391): Create interpreter
> 'hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'.
> [Fri Oct 21 01:04:29.989457 2022] [wsgi:info] [pid 69391] [client
> 10.2.20.25:41124] mod_wsgi (pid=69391, process='',
> application='hd1991356yb.sgc.loc|/~mec/dash101/app.wsgi'): Loading Python
> script file '/home/mec/public_html/dash101/app.wsgi'., referer:
> http://hd1991356yb/~mec/dash101/
> [Fri Oct 21 01:04:30.891229 2022] [wsgi:error] [pid 69391]
> /home/mec/public_html/dash101/app.py:2: UserWarning:
> [Fri Oct 21 01:04:30.891279 2022] [wsgi:error] [pid 69391] The
> dash_html_components package is deprecated. Please replace
> [Fri Oct 21 01:04:30.891289 2022] [wsgi:error] [pid 69391] `import
> dash_html_components as html` with `from dash import html`
> [Fri Oct 21 01:04:30.891298 2022] [wsgi:error] [pid 69391] import
> dash_html_components as html
> [Fri Oct 21 01:04:33.661364 2022] [wsgi:error] [pid 69391]
> /home/mec/public_html/dash101/app.py:4: UserWarning:
> [Fri Oct 21 01:04:33.661397 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:33.661403 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:33.661408 2022] [wsgi:error] [pid 69391] The
> dash_core_components package is deprecated. Please replace
> [Fri Oct 21 01:04:33.661413 2022] [wsgi:error] [pid 69391] `import
> dash_core_components as dcc` with `from dash import dcc`
> [Fri Oct 21 01:04:33.661417 2022] [wsgi:error] [pid 69391]
> [Fri Oct 21 01:04:34.825419 2022] [core:info] [pid 69391] [client
> 10.2.20.25:41124] AH00128: File does not exist: /
> var/www/html/_dash-component-suites/dash/deps/poly...@7.v2_6_2m1666328797.12.1.min.js,
>
> referer: http://hd1991356yb/~mec/dash101/app.wsgi/
>
> I am for now ignoring the deprecation warnings.
>
> I error comes from the app looking for dash's .js files within
> /var/www/html (apache's root).
>
> How can my app.wsgi alter this path?
>
> I tried adding this to my app.wsgi:
>
> os.environ["DASH_URL_BASE_PATHNAME"] = "/home/mec/public_html/dash101/"
>
>
> That is a file system path you are giving it, not a URL path the web
> server understands.
>
Yes. I expect I should have been trying "~mec/dash101" (except dash
complains, wanting it to begin and end with a '/').
> which does effect where the js files are sought, only not correctly, as
> the error is now:
>
> [Fri Oct 21 01:48:29.019458 2022] [core:info] [pid 8597] [client
> 10.2.20.25:43445] AH00128: File does not exist: /
> var/www/html/home/mec/public_html/dash101/_dash-component-suites/dash/deps/poly...@7.v2_6_2m1666328797.12.1.min.js,
>
> referer: http://hd1991356yb/~mec/dash101/app.wsgi
>
>
> Where is the "_dash-component-suites" actually located on the file system.
>
The directory itself does not exist. It is a route that appears to be
detected
<https://github.com/plotly/dash/blob/6cfb7874800152794d8d603e8d9c4334bf61e3fd/%40plotly/webpack-dash-dynamic-import/src/index.js#L38>
by the dash application and then re-written
<https://github.com/plotly/dash/blob/6cfb7874800152794d8d603e8d9c4334bf61e3fd/%40plotly/webpack-dash-dynamic-import/src/index.js#L66>to
existing resources.
That directory should be copied into /var/www/html
> and DASH_URL_BASE_PATHNAME not set, or, you need to set up the Apache Alias
> directory to map some URL prefix to filesystem location where it is.
>
I hope not to have to copy anything to /var/www/html as that runs counter
to my goal of letting all users of shared server "deploy" .wsgi apps.
>
> So far, apache2 is configured with:
>
> LoadModule wsgi_module /usr/lib64/python3.6/site-packages/mod_wsgi/server/
> mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so
>
> <IfModule mod_userdir.c>
> UserDir public_html
> </IfModule>
>
> <Directory "/home/*/public_html">
> AllowOverride FileInfo AuthConfig Limit Indexes
> Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec ExecCGI
> Require method GET POST OPTIONS
> AddHandler cgi-script .cgi
> AddHandler wsgi-script .wsgi
> </Directory>
>
> I am not issuing any other wSGI configuration directives in my apache2
> configuration.
>
> Perhaps I should not expect apache2+userdir+mod_wsgi to work at all...???
>
>
> In general it is best to avoid using mod_userdir with mod_wsgi as it
> confuses typical WSGI application URL handling.
>
>
So I am finding...
Do you recommend that I should not instead enable handling .wsgi anywhere,
like this:
<Directory "/var/www/html">
AddHandler wsgi-script .wsgi
</Directory>
It seems like the next thing to try, if userdir is going to introduce such
conflicts.
> Why are you trying to use mod_userdir. Do you not control the whole Apache
> server?
>
Yes I do control/administer it, but I do it as a service for the institute
in which I am a member who has other members who wish to deploy wsgi/dash
applications. They are not all apache admins. So, I am seeking an
approach that gives them a simple approach to deploym wsgi/dash apps (e.g.
out of to public_html) that requires no additional server
administration/configuration. UserDir in my past experience was sufficient
to this need w.r.t. .cgi applications. I thought I should be able to adapt
the approach for .wsgi. I hope that any application specific wsgi
configuration could be handled by the app.wsgi and/or .htaccess (as, for
example, I see is possible with WSGIRestrictProcess
<https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIRestrictProcess.html?highlight=htaccess#wsgirestrictprocess>
directives,
among others)
Perhaps I should not try either of these, given the advice you give in Mounting
The WSGI Application
<https://modwsgi.readthedocs.io/en/master/user-guides/quick-configuration-guide.html?highlight=htaccess#mounting-the-wsgi-application>
that
".(the WSGIScriptAlias) directive can only appear in the main Apache
configuration files. The directive can be used at server scope but would
normally be placed within the VirtualHost container for a particular site.
It cannot be used within either of the Location, Directory or Files
container directives, nor can it be used within a “.htaccess” file."
Is it a fools errand to try otherwise?
> All advice as to how to proceed very welcome.
>
> update: I've now read
> https://groups.google.com/g/modwsgi/c/Lnik3YHFujA/m/3QRuwEZXP6sJ and have
> tried the approach mentioned there:
>
> WSGIRestrictEmbedded On
>
> WSGIDaemonProcess mec
> <Directory /home/mec/public_html>
> WSGIProcessGroup mec user=mec
> </Directory>
>
> I modifed it remove the (now deprecated?) `user=mec` (which causes apache
> restart to fail)
>
> But it did not alter the error sequence I am getting.
>
> That advice is from 2011. Perhaps things have changed and there is now a
> best approach to this (possibly including a "means for dynamic creation of
> daemon
> process groups")...???
>
>
> Daemon process groups still have to be defined up from.
>
Got it.
Thanks for all your advice.
~Malcolm
--
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 modwsgi+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/3e786f91-8d0f-41ce-b999-0e52a1781a6en%40googlegroups.com.
