This is a pull request to implement devpi-ldap support, including exposing optional configurability through environment variables or a configuration file. I would have waited until the pull request for nginx support was merged in, but since it looks like that's been on pause for about week I figured I'd move forward on this.
While this is a pretty straightforward implementation, there are a few changes in this pull request I wanted to bring to your attention. Please let me know if you have any conflicts with them:
Dependencies
I futzed around with the dependencies since (1) the plugin mechanism used by devpi-ldap is only supported in devpi-server>=2.1.0, and (2) without upgrading the version of Python or enforcing pyOpenSSL support the log could get inundated with InsecurePlatform errors.
DEVPI_SERVERDIR Mount Point
While implementing support for loading the LDAP configuration through a mounted YAML configuration file I ran into a weird issue: if the DEVPI_SERVERDIR directory is not empty but does not yet contain the devpi-server data (.serverversion, etc...), on start the devpi-server believes the DEVPI_SERVERDIR points to the data directory for an incompatible version of the devpi-server and refuses to start until the directory has been emptied. This was reproducible if I added a YAML config file to /mnt/ldap-config.yml and then started the server.
To avoid confusion and having to expose a separate volume to allow users to mount a non-empty directory for I changed the DEVPI_SERVERDIR to: /mnt/devpi-server. I've only been able to think of one implication for backwards compatibility so far:
Assume user already has a devpi container running from a previous image with the host data directory mounted at /docker-data/devpi/ (or something)
User downloads new image, stops their devpi container, and runs the new image with the host data directory mounted at /docker-data/devpi/ (to retain the state of their previous container)
The devpi-server starts up and spins up an entirely new data directory, which is equivalent to /docker-data/devpi/devpi-server on the host.
Since this wouldn't remove any of the previous state, the user would resolve this by running something along the lines of:
Since the implications for backwards-compatibility depends on the use-case and doesn't endanger any pre-existing data I figured I'd leave that in and see if you have a preference for one way or another.
tmeneau
commented
2 years ago
This is a pull request to implement devpi-ldap support, including exposing optional configurability through environment variables or a configuration file. I would have waited until the pull request for nginx support was merged in, but since it looks like that's been on pause for about week I figured I'd move forward on this.
While this is a pretty straightforward implementation, there are a few changes in this pull request I wanted to bring to your attention. Please let me know if you have any conflicts with them:
Dependencies
I futzed around with the dependencies since (1) the plugin mechanism used by devpi-ldap is only supported in devpi-server>=2.1.0, and (2) without upgrading the version of Python or enforcing pyOpenSSL support the log could get inundated with InsecurePlatform errors.
DEVPI_SERVERDIRMount PointWhile implementing support for loading the LDAP configuration through a mounted YAML configuration file I ran into a weird issue: if the
DEVPI_SERVERDIRdirectory is not empty but does not yet contain the devpi-server data (.serverversion, etc...), on start the devpi-server believes theDEVPI_SERVERDIRpoints to the data directory for an incompatible version of the devpi-server and refuses to start until the directory has been emptied. This was reproducible if I added a YAML config file to /mnt/ldap-config.yml and then started the server.To avoid confusion and having to expose a separate volume to allow users to mount a non-empty directory for I changed the
DEVPI_SERVERDIRto:/mnt/devpi-server. I've only been able to think of one implication for backwards compatibility so far:/docker-data/devpi/(or something)/docker-data/devpi/(to retain the state of their previous container)/docker-data/devpi/devpi-serveron the host.Since this wouldn't remove any of the previous state, the user would resolve this by running something along the lines of:
Since the implications for backwards-compatibility depends on the use-case and doesn't endanger any pre-existing data I figured I'd leave that in and see if you have a preference for one way or another.
Thanks in advance!