A secret key generated by the nixos module was misspelled, which could
possibly impact the security of session cookies.
To recover from this situation we will wipe all security keys that were
previously generated by the NixOS module, when the misspelled one is
found. This will result in all session cookies being invalidated. This
is confirmed by the wordpress documentation:
> You can change these at any point in time to invalidate all existing
> cookies. This does mean that all users will have to login again.
https://wordpress.org/support/article/editing-wp-config-php/#security-keys
Meanwhile this issue shouldn't be too grave, since the salting function
of wordpress will rely on the concatenation of both the user-provided
and automatically generated values, that are stored in the database.
> Secret keys are located in two places: in the database and in the
> wp-config.php file. The secret key in the database is randomly
> generated and will be appended to the secret keys in wp-config.php.
https://developer.wordpress.org/reference/functions/wp_salt/
Fixes: 2adb03fdae ("nixos/wordpress:
generate secrets locally")
Reported-by: Moritz Hedtke <Moritz.Hedtke@t-online.de>
Assert that the PostgreSQL version being deployed is the one used
upstream. Allow the user to override this assertion, since it's not
always possible or preferable to use the recommended one.
Instead of requiring the user to bundle the certificate and private
key into a single file, provide separate options for them. This is
more in line with most other modules.
`install` copies the files before setting their mode, so there could
be a breif window where the secrets are readable by other users
without a strict umask.
Feeding `psql` the password on the command line leaks it through the
`psql` process' `/proc/<pid>/cmdline` file. Using `echo` to put the
command in a file and then feeding `psql` the file should work around
this, since `echo` is a bash builtin and thus shouldn't spawn a new
process.
Using `replace-literal` to insert secrets leaks the secrets through
the `replace-literal` process' `/proc/<pid>/cmdline`
file. `replace-secret` solves this by reading the secret straight from
the file instead, which also simplifies the code a bit.
Using `replace-literal` to insert secrets leaks the secrets through
the `replace-literal` process' `/proc/<pid>/cmdline`
file. `replace-secret` solves this by reading the secret straight from
the file instead, which also simplifies the code a bit.
This reverts commit d9e18f4e7f.
This change is broken, since it doesn't configure the proper database
username in keycloak when provisioning a local database with a custom
username. Its intended behavior is also potentially confusing and
dangerous, so rather than fixing it, let's revert to the old one.
Bash doesn't handle subshell errors properly if the result is used as
input to a command. To cause the services to fail when the files can't
be read, we need to assign the value to a variable, then export it
separately.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
This allows for shared hledger installations, where the web interface is
available via network and multiple user share a SSH access to the
hledger user.
Also added `--serve` to the CLI options, as hledger-web tries to open a
webbrowser otherwise:
hledger-web: xdg-open: rawSystem: runInteractiveProcess: exec: does not
exist (No such file or directory)
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
4255954d97 set the StateDirectory to 0750,
but nginx wasn't in the Mastodon group. This commit also deletes a line,
that probably was intended to serve this purpose, but makes no sense.
Why should the Mastodon user be added as an extraGroup to the nginx
user?
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
* It should be made explicit in the eval-error that the CVE only affects
a component which is turned off by default.
* For more clarity, the default version used by the module is noted in
the manual.
Closes#108419
The service was failing with:
gunicorn[2192104]: [2020-12-31 13:35:28 +0000] [2192104] [ERROR] Exception in worker process
gunicorn[2192104]: Traceback (most recent call last):
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/arbiter.py", line 586, in spawn_worker
gunicorn[2192104]: worker.init_process()
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 196, in init_process
gunicorn[2192104]: self.patch()
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 65, in patch
gunicorn[2192104]: monkey.patch_all(subprocess=True)
gunicorn[2192104]: File "/nix/store/fysf67w3i8iv1hfvp536nl8jbzqyk1s7-python-2.7.18-env/lib/python2.7/site-packages/gevent/monkey.py", line 1160, in patch_all
gunicorn[2192104]: from gevent import events
gunicorn[2192104]: File "/nix/store/fysf67w3i8iv1hfvp536nl8jbzqyk1s7-python-2.7.18-env/lib/python2.7/site-packages/gevent/events.py", line 67, in <module>
gunicorn[2192104]: from zope.interface import Interface
gunicorn[2192104]: ImportError: No module named zope.interface
`file_exists` also returns `FALSE` if the file is in a directory that
can't be read by the user. This e.g. happens if permissions for
`nixops(1)`-deployment keys aren't configured correctly.
This patch improves the error message for invalid files to avoid
confusion[1].
[1] https://discourse.nixos.org/t/nixops-deploy-secrets-to-nextcloud/10414/4
This adds a `package` option to allow for easier overriding of the used
CodiMD version and `runCommandLocal` with `nativeBuildInputs` is now
used to pretty print the configuration.
These were broken since 2016:
f0367da7d1
since StartLimitIntervalSec got moved into [Unit] from [Service].
StartLimitBurst has also been moved accordingly, so let's fix that one
too.
NixOS systems have been producing logs such as:
/nix/store/wf98r55aszi1bkmln1lvdbp7znsfr70i-unit-caddy.service/caddy.service:31:
Unknown key name 'StartLimitIntervalSec' in section 'Service', ignoring.
I have also removed some unnecessary duplication in units disabling
rate limiting since setting either interval or burst to zero disables it
(ad16158c10/src/basic/ratelimit.c (L16))
Please note that this is only for 21.03 since `nextcloud19` is intended
to be the default for the already feature-frozen 20.09 (the bump itself
is supposed to get backported however).
Both packages will get EOLed within the lifetime of 20.09. `nextcloud17`
can be removed entirely (the attribute-path is kept however to provide
meaningful errors), however `nextcloud18` must be kept as `insecure` to
make sure that users from `nextcloud17` can properly upgrade to
`nextcloud19` on NixOS 20.09.
Secrets are injected from the environment into the rendered
configuration before each startup using envsubst.
The test now makes use of this feature for the db password.
This patch ensures that latest Nextcloud works flawlessly again on our
`nginx`. The new config is mostly based on upstream recommendations
(again)[1]:
* Trying to access internals now results in a 404.
* All `.php`-routes get properly resolved now.
* Removed 404/403 handling from `nginx` as the app itself takes care of
this. Also, this breaks the `/ocs`-API.
* `.woff2?`-files expire later than other assets like images.
Closes#95293
[1] https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html