Requirements

alternc with subdomain hooks
- This is a series of patches to allow plugins to interact with certain parts of the AlternC core which aren't yet included upstream. @see https://github.com/kienanstewart/AlternC/tree/subdomain_hooks
libapache2-mod-wsgi-py3
alternc-nss
- alternc-nss provides unix user integration without which wsgi cannot look up uid to users properly.

Recommends:

python3-pip
python3-venv

Server configuration

a2enmond proxy_uswgi
a2enmod wsgi
service apache2 restart

Create virtual environments

python3 -m venv --copies /path/to/virtualenv/name
mv /path/to/virtualenv/name /var/www/alternc/X/Xname/venv/name

Creating environments remotely

Normally users in AlternC do not have shell access to run commands to manage virtual environments. There are are couple of ways it may work (though it may not always do so!).

Ideally users in a remote environment build their applications with the same version of python as used on the AlternC host. In such a case, the venv can be copied normally.

Option 1: Hack venv to switch python version

Create the venv normally
Activate and install all modules necessary
Modify pyvenv.cfg and change the python version listed to match the AlternC host's python version
Create a symlink in the lib/ folder so both version work:

ln -s python-<local_version> lib/python-<alternc_host_version>

Option 2: virtualenv

It is possible with virtualenv to use a non-system python and make it relocatable; however, this functionality may not work 100% and may be deprecated.

Install non-system python in /opt/ which matches the version on the AlternC host.
Create virtualenv: virtualenv --python=/opt/python-<alternc_host_version --relocatable <name>

Create/Deploy App

eg. Django

mv /path/to/virtualenv/name
source bin/activate
pip install django
cd /var/www/alternc/X/Xname/www
# Note: projectname must not conflict with the name of the venv or any other python module
django-admin startproject projectname

Create apache configuration

<VirtualHost *:80>
  ServerName test.alternc.local
  DocumentRoot /var/www/alternc/a/admin/www/test/ourcase/
  AssignUserId #2000 #2000
  SetEnv LOGIN "2000-admin"
  <IfModule mod_wsgi.c>
    WSGIDaemonProcess test.alternc.local python-home=/var/www/alternc/a/admin/venv/test/ python-path=/var/www/alternc/a/admin/www/test/ourcase/ socket-user=#2000
    WSGIProcessGroup test.alternc.local
    WSGIScriptAlias / /var/www/alternc/a/admin/www/test/ourcase/ourcase/wsgi.py process-group=test.alternc.local
  </IfModule>

  <Directory "/var/www/alternc/a/admin/www/test/ourcase/ourcase/">
    AllowOverride All
    <Files wsgi.py>
     <IfVersion < 2.4>
        Order allow,deny
        Allow from all
      </IfVersion>
      <IfVersion >= 2.4>
        Require all granted
      </IfVersion>
    </Files>
  </Directory>
</VirtualHost>

Note: this requires '#2000' to resolve to a valid unix account. Therefore it doesn't work with the default AlternC structure. It may work with alternc-nss to provide passwd/group files and integrate with the rest of the unix system.

Template for alternc

<VirtualHost *:80>
  ServerName %%fqdn%%
  DocumentRoot %%document_root%%
  AssignUserId #%%UID%% #%%GID%%
  SetEnv LOGIN "%%UID%%-%%LOGIN%%"
  <IfModule mod_wsgi.c>
    WSGIDaemonProcess %%fqdn%% python-home=%%VENV%% python-path=%%document_root%%/%%APP_SUBDIR%% socket-user=#%%UID%%
    WSGIProcessGroup %%fqdn%%
    WSGIScriptAlias / %%document_root%%/%%APP_SUBDIR%%/wsgi.py process-group=%%fqdn%%
  </IfModule>

  <Directory "%%document_root%%/%%APP_SUBDIR%%">
    AllowOverride All
    <Files wsgi.py>
     <IfVersion < 2.4>
        Order allow,deny
        Allow from all
      </IfVersion>
      <IfVersion >= 2.4>
        Require all granted
      </IfVersion>
    </Files>
  </Directory>
</VirtualHost>

Todo

Validation/sanitization of the app_subdir and venv (especially relative paths).
Handle vhost templating properly when no venv is set

Further points of interest:

Once application code, settings, etc. are changed an apache reload is required. Are there settings or a way to allow users to request a reload in an unobtrusive manner?
Are there other steps that should be taken to prevent users applications from interfering with each other?
Is it work considering multi-process daemon setups or more complicated Vhost configurations?
When a subdomain with WSGI is misconfigured, or the app is misconfigured, the processes can spam the error log a lot. Is it possible to limit the number of retries?

License

GPLv3+, see LICENSE.txt for the full text.

kienanstewart/alternc-wsgi-py3