Add documentation for deploying with mod_wsgi #168
Conversation
Add documentation for how to deploy the SATOSA proxy using Apache HTTP Server and mod_wsgi.
| production release of mod\_wsgi: | ||
|
|
||
| ``` | ||
| curl https://bootstrap.pypa.io/get-pip.py | python3 |
There was a problem hiding this comment.
I wouldn't do this really. It does not matter if we have the latest version of pip. We only need pip to fetch application dependencies, and unless there something in this very latest release, there is no need for it. I would suggest to keep things simple and use the package provided by the distribution.
yum install python-pip
There was a problem hiding this comment.
The version packaged by RedHat and delivered with CentOS is old and not documented and has significant bugs that have been fixed in the latest release.
|
|
||
| ``` | ||
| curl https://bootstrap.pypa.io/get-pip.py | python3 | ||
| pip install mod_wsgi |
There was a problem hiding this comment.
Same here – Centos already provides this as a distribution package. Why would I need the latest from pip? The distribution package guarantees a level of stability of the installed artefact. I would chose that over pip.
yum install mod_wsgi
There was a problem hiding this comment.
The mod_wsgi version packaged by RedHat and available with CentOS, even that from the SCL repositories, is old and buggy and explicitly disavowed by the package's developer.
There was a problem hiding this comment.
If things are that bad with CentOs packaging, maybe one shouldn't be using CentOs in the first place. This is not a pun, I really mean it. If the distribution cannot provide you with up-to-date packages or backported security fixes, then it provides no value.
I am not aware of CentOs development processes, but if that's the situation I would suggest to abandon CentOs.
There was a problem hiding this comment.
When I have a choice I do not choose RHEL based operating systems, but it is not my choice. But it is a choice that many people do make. For this example I documented CentOS because that is the platform we are using for the project that paid for the work and the time to make contributions to SATOSA.
|
|
||
| ## Installation | ||
|
|
||
| Use pip to install SATOSA: |
There was a problem hiding this comment.
I would rephrase this to:
Use pip to install SATOSA.
- To install the latest stable version run:
pip install satosa
- To install the latest version from git run:
yum install git pip install git+https://github.com/IdentityPython/SATOSA.git#egg=SATOSA
| pip install --upgrade pysaml2 | ||
| ``` | ||
|
|
||
| ## Installation of SATOSA Microservices |
There was a problem hiding this comment.
This is yet another discussion that should be opened on the dev mailing list.
Now that microservices are split into their own repository we should set the process which acquires them back to the setup. There are many options here:
- have each microservice be its own python package and selectively install it using pip
- have the microservices repo be a package itself and use pip to install it
- have microservices repo as a git module under satosa (not suggested)
- have microservices as something completely external and fetch using http/git (as shown below). This could mean a lot of different things - ie, should microservices use code from satosa? if so, satosa is a dependency to microservices and as such this makes microservices a package with dependencies, etc.
I'm fine with leaving this as is for now, but lets keep this in mind and open this discussion.
| && rm -f satosa_microservices.tar.gz | ||
| ``` | ||
|
|
||
| If you need the LDAP Attribute Store microservice you must also install |
There was a problem hiding this comment.
This indicates that certain microservices have dependencies. Users cannot guess what dependencies are needed for a certain microservice. This information should be explicit and automatically resolved on the microservice installation. This points to having each microservice be its own package, with its own dependencies and deployment process.
| WSGIPythonHome "/usr" | ||
| ``` | ||
|
|
||
| Edit the Apache config and in the global section (not within a virtual |
There was a problem hiding this comment.
This seems to be needed because mod_wsgi is not managed by the distribution. I think that if you install mod_wsgi through yum this can be skipped. Apache provides tools to automatically (un)load modules with a2enmod (and a2dismod) which should be automatically invoked by the mod_wsgi installation by the package manager.
There was a problem hiding this comment.
Again the version packaged and available through yum has significant bugs.
Add documentation for how to deploy the SATOSA proxy using
Apache HTTP Server and mod_wsgi.