Swarm uses a cluster-wide ingress network and does not permit binding
ports to localhost. It simply ignores such a binding and prints
a warning instead.
This patch fixes this recent regression to avoid the warning.
the proxy responds with a 421, if a host header with an invalid host
name is encountered. If nothing is provided (see default .env) all hosts
are allowed. Examples:
ALLOWED_HOSTS="localhost:8000 127.0.0.1:8000"
ALLOWED_HOSTS="some.domain.example.com"
Add EXTERNAL_HTTPS_PORT. See .env for the configuration.
For a subset of the images required by a Compose or Swarm Setup,
non-default names can be configured in .env. Originally, the names were
treated as the images' complete names, i.e., including an optional
registry domain. Using this setup, it was possible to pull the
irregularly updated auxiliary images from a default registry while, at
the same time, obtaining certain images from different registries.
Commit e225a57f97 changed this behavior. Since then, the names in .env
can only be used to change part of the image name, excluding the
registry. If a default registry is configured it is always prepended to
the given image name, breaking the original use case.
This patch removes the ability to override image names in .env.
Instead, the registry of each image can be customized.
The reasoning here is that the only common reason to change an image
name is to change its Docker registry. For example, while the default
registry may be set to default.example.com, it may be necessary to
obtain the backend image private.example.com/openslides-server. With
this patch, that would be achieved by the following configuration in
.env:
DOCKER_OPENSLIDES_BACKEND_REGISTRY="private.example.com"
For special cases, for which the images' basename must indeed be changed
as well, the template would need to be customized.
The templates are not backwards-compatible.
The YAML configuration files include comments outlining how to override
the server image's default command. They are supposed to help with, for
example, replacing gunicorn with daphne.
These comments have diverged from the actual command used in current
images. Furthermore, at least to my knowledge, the setup has not been
used or tested with daphne in a long time. For these reasons, this
patch removes the comments without a replacement.
If there still is, in fact, a use case for the instructions, they would
need to be updated and their location should be reconsidered.
The proxy image is not going to be subject to regular change and is
instead more similar to services such as the database. Therefore, it
does not need to be a default build target of build.sh.
- removed big mode artifacts
- removed django_session_redis
- Enforce newly created settings.py when invalid options are set:
* OPENSLIDES_USER_DATA_DIR
* SESSION_ENGINE
- Overwrites the secret key during development to "development"
HAProxy was replaced by Caddy, so obviously variables should not longer
carry HAPROXY in their names to avoid confusion.
To hopefully make future changes less likely to break configurations,
we'll keep variable and image names generic (proxy instead of caddy).
For now, keep using HAProxy's name in most places, e.g.,
DOCKER_OPENSLIDES_HAPROXY_NAME. To avoid confusion, the specific
mentions of HAProxy should be made more generic, e.g.,
DOCKER_OPENSLIDES_PROXY_NAME.
- Cleans up log messages in the client
- Refactored the autoupdate bundle code into an own file
- Added bulk creates for History in Postgresql. This is the only database system
that supports returning all ids whan multiple elements are inserted. We can
make usage out of it.
- Added a `disable_history`, that is request-wide
- Disabled history on poll vote requests
- Removed unnecessary user ordering
- Reduced the queries for creating motion vote objects by one
- removed final_data: This was not prefetched. Using the normal data collection
the data is prefetched
- removed unnecessary user query if vore delegation is not used
- Removing channels. Going back to a wsgi deployment
- Removed server projector code
- Autoupdate throttling is now in the client
- New communication stack in the client
- Adopted all deployment methods: Docker stack and docker compose (prod and dev)
- Added autoupdate service as submodule
To configure SAML, ENABLE_SAML must be set to True in .env.
Additionally, the following files must be provided in ./secrets/saml/:
- sp.crt
- sp.key
- saml_settings.json
The files will be added as Docker secrets.
Even though saml_settings.json does not contain secret information
per se it is nonetheless added as a secret for simplicity. Technically,
the file is equally suited to be configured as a "Docker config".
Please note:
- This patch has not been tested yet.
- python3-saml's version should probably be pinned.
This setup chooses to avoid the env_file option available for Docker
Compose files. Docker has a peculiar way of parsing variables which
makes it, for example, include quotes verbatim.
This is both confusing and incompatible with shells parsing the same
file which is a requirement. For this reason, the configuration does
not import the complete environment using env_file but assigns variables
explicitly on a need-to-know basis in the YAML file, much like Docker
secrets.
Since the configuration is generated automatically, the burden on users
is the same as with env_file: they only need to edit .env for
customizations.
Since build.sh now builds more than just two images, individual queries
whether to push each image to a registry may become tedious. This patch
replaces the queries with a single checklist menu. After making
a selection, the images get pushed all at once.
In the menu, all images are unchecked by default in order to prevent
accidental uploads. This, too, may become tedious. In that case, the
default could be flipped or a new option could be introduced.
build.sh replaces docker-compose as an image build tool. Instead, all
OpenSlides services can be built using this script which offers various
important options such as tagging and configurable defaults.
The now-redundant build instructions have been removed from the YAML
templates.
The almost identical server and client build scripts have been made
fully identical.
We have decided against including an insecure default key with a mere
warning. Therefore, unlike the admin and user secrets, the availability
of this secret is a hard requirement. The instance will not be able to
start before a secret has been generated manually or by a management
tool.
