By having the environment explicit on each service, we both document
the settings and have more control over what each service is allowed
to see.
This avoids weird things like nginx having access to postgresql's
credentials on its environment.
As a bonus: we are able to use one single environment file, which is
basically dd.conf with some values that are dynamically-calculated and
added from dd-ctl.
That issue is fixed in NC 25, but it will likely not be backported to
NC 24.
It produces issues when modifying users and not modifying their
display name.
See also: https://github.com/nextcloud/server/issues/33751
NotaBLE és la col·laboració entre Gwido i el Workspace educatiu DD.
És un projecte de Xnet, IsardVDI, Gwido i Taller de Músics, guanyador
de la Ciutat Proactiva 2021, suport a la innovació urbana de la
Fundació BitHabitat.
The API spec file can be generated with:
python -m admin.views.test.test_ApiViews --generate-spec
From the admin development environment.
A simple testing ground that serves the Swagger UI can also be started with:
python -m admin.views.test.test_ApiViews
We do this more reliably on HAProxy, as doing it from WP requires
specialised plugins and in DD we are sure that traffic goes through
the corresponding HAProxy backend.
This fixes several issues where services would see the internal IP of
the proxy and not that of the client.
It works by first unsetting any proxy-related headers that arrive from
the internet, then setting those as seen by HAProxy's entrypoint
frontend.
And finally making sure that neither WAF when enabled nor other
HAProxy backends touch these headers, while they are actually used by
the final services.
Services affected: Netcloud, Keycloak, Moodle
The environment / dd.conf variables: PROXY_PROTOCOL and DISABLE_WAF
determine how DD and HAProxy will behave.
- PROXY_PROTOCOL: whether or not the PROXY protocol will be accepted
- DISABLE_WAF: whether or not WAF will be enabled
This simplifies maintenance, as well as the overall architecture and operation.
While at it, we now publish images for DD's HAProxy as well.
This enables more advanced customisation by allowing for
administrators to fully replace the footer of the login theme.
We try to take into account maintainability, at the same time mention
that it is the administrators' responsibility to keep their
customisations compatible with newer versions of DD.
We thought the name parameter was the account name to be shown in the
plugin, but it is the contents of the "From" email header instead.
While changing that, we also update the code to better match the open
Pull Request upstream that adds the update-account to the mail plugin
for nextcloud.
The class was only checking whether or not a specific token exists in
moodle, and it should ensure that it has access to the right permissions
Reported by: @elena61
This can be used by setting up HAPROXY_CONF in dd.conf, which will
determine which config file will be used.
We also add haproxy.proxy-protocol.conf which is cleaner than
haproxy.conf and allows the PROXY protocol on certain ports.
With this setup it is possible to e.g. run DD without a public IPv4
address by proxying it from an edge server.
When introducing typing, we erroneously started passing an empty parent
Id instead of None, and the underlying Keycloak library failed to create
the groups.
Closes#15
From minio's documentation:
- MINIO_ACCESS_KEY and MINIO_SECRET_KEY are deprecated in lieu of
MINIO_ROOT_USER and MINIO_ROOT_PASSWORD respectively
- In order to rotate secrets we only need to change
MINIO_ROOT_{USER,PASSWORD}
Using this commit and the previous one affecting keycloak we can use
per-instance keys as opposed to the current state.
In order to achieve this, AVATARS_ACCESS_KEY and AVATARS_SECRET_KEY must
be set to the desired values.
The only guidelines as to how to generate ACCESS_KEY and SECRET_KEY are:
> Specify a unique, random, and long string for both the ACCESSKEY and
> SECRETKEY. Your organization may have specific internal or regulatory
> requirements around generating values for use with access or secret keys.
See:
- https://docs.min.io/minio/baremetal/reference/minio-server/minio-server.html#envvar.MINIO_ACCESS_KEY
- https://docs.min.io/minio/baremetal/security/minio-identity-management/user-management.html
This was needed because previously the DEFAULT_SERVER_URL was hardcoded
in the compiled keycloak module and that URL has changed.
For consistency sso-admin uses the same environment variables (except it
needs AVATARS_SERVER_HOST instead of AVATARS_SERVER_URL).