Since 3edde6562e, we can no longer use
aliases inside the test framework. This has the implication that we can
no longer use aliases in any NixOS modules used by the test framework as
well (which is good), but does mean we need to clean up any instances
where this is the case.
Add support for folder jobs
(https://plugins.jenkins.io/cloudbees-folder/) by reworking the service
to support nested jobs.
This also fixes this deprecation warning (as a happy side effect):
WARNING:jenkins_jobs.cli.subcommand.test:(Deprecated) The default output behavior of `jenkins-jobs test` when given the --output flag will change in JJB 3.0. Instead of writing jobs to OUTPUT/jobname; they will be written to OUTPUT/jobname/config.xml. The new behavior can be enabled by the passing `--config-xml` parameter
* Most significant is probably the patching necessary to run plausible
with postgres without superuser privilege. This change includes:
* updating ecto_sql to 3.6 where `CREATE DATABASE` is only executed if
it doesn't exist[1].
* patching a migration to only modify the `users.email` column (to use
`citext` rather than creating the extension. `plausible-postgres`
takes care of that).
* Correctly declare dependencies in systemd.
* A few minor fixes.
[1] 051baf669e
Without this change, mailman-settings.service is not guaranteed to
complete before dependent services. This can lead to various errors
like:
mailman-web-setup.service: Changing to the requested working directory failed: No such file or directory
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>
As per `man systemd.path`:
> When a service unit triggered by a path unit terminates
> (regardless whether it exited successfully or failed),
> monitored paths are checked immediately again,
> **and the service accordingly restarted instantly**.
Thus the existence of the path unit made it impossible to stop the
wireguard service using e.g.
systemctl stop wireguard-wg0.service
Systemd path units are not intended for program inputs such
as private key files.
This commit simply removes this usage; the private key is still
generated by the `generateKeyServiceUnit`.
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.
this adds support for software defined radio (SDR) devices by SDRplay.
SDRplay provides an unfree binary library and api-service as well
as a MIT licensed adapter library for SoapySDR for integration
with many popular SDR applications.
The absence of current-context in the right place resulted in obscure
bugs. The reason this has not been detected before can only be that
it was unused.
