The option `services.jira.sso.applicationPassword` has been replaced by
`applicationPasswordFile` that needs to be readable by the `jira`-user
or group.
The new `crowd.properties` is created on startup in `~jira` and the
secret is injected into it using `replace-secret`.
Rely on services.jenkins-job-builder to reload the configuration instead
of doing that manually in the test.
(If this had been implemented already, it would have caught the bug
fixed by the parent commit, that services.jenkins-job-builder failed to
reload jenkins config from disk.)
The current authentication code is broken against newer jenkins:
jenkins-job-builder-start[1257]: Asking Jenkins to reload config
jenkins-start[789]: 2022-07-12 14:34:31.148+0000 [id=17] WARNING hudson.security.csrf.CrumbFilter#doFilter: Found invalid crumb 31e96e52938b51f099a61df9505a4427cb9dca7e35192216755659032a4151df. If you are calling this URL with a script, please use the API Token instead. More information: https://www.jenkins.io/redirect/crumb-cannot-be-used-for-script
jenkins-start[789]: 2022-07-12 14:34:31.160+0000 [id=17] WARNING hudson.security.csrf.CrumbFilter#doFilter: No valid crumb was included in request for /reload by admin. Returning 403.
jenkins-job-builder-start[1357]: curl: (22) The requested URL returned error: 403
Fix it by using `jenkins-cli` instead of messing with `curl`.
This rewrite also prevents leaking the password in process listings. (We
could probably do it without `replace-secret`, assuming `printf` is a
shell built-in, but this implementation should be safe even with shells
not having a built-in `printf`.)
Ref https://github.com/NixOS/nixpkgs/issues/156400.
Instead of hard-coding a single `configFile` for
`privacyidea-ldap-proxy.service` which is pretty unmergable with other
declarations it now uses a RFC42-like approach. Also to make sure that
secrets can be handled properly without ending up in the Nix store, it's
possible to inject secrets via envsubst
{
services.privacyidea.ldap-proxy = {
enable = true;
environmentFile = "/run/secrets/ldap-pw";
settings = {
privacyidea.instance = "privacyidea.example.org";
service-account = {
dn = "uid=readonly,ou=serviceaccounts,dc=example,dc=org";
password = "$LDAP_PW";
};
};
};
}
and the following secret file (at `/run/secrets`):
LDAP_PW=<super-secret ldap pw>
For backwards-compat the old `configFile`-option is kept, but it throws
a deprecation warning and is mutually exclusive with the
`settings`-attrset. Also, it doesn't support secrets injection with
`envsubst` & `environmentFile`.
Wait until home-assistant is fully reloaded or restarted to spot
possible errors during startup.
Swap out bluetooth_tracker for esphome, since the bluetooth tracker
causes errors, when it does not find a bluetooth device.
Drop mosquitto from the environment. It wasn't used since the 2022.3.0
release when MQTT stopped being configurable from the YAML config.
It has been like this since the module was added, but it hasn't caused
problems because greetd assumes a default user of "greeter"[1] when it
isn't found anyway
[1]: d700309623/item/greetd/src/config/mod.rs (L127)
Suppose you want to provide a LDAP-based directory search to your
homeserver via a service-user with a bind-password. To make sure that
this doesn't end up in the Nix store, it's now possible to set a
substitute for the bindPassword like
services.mxisd.extraConfig.ldap.connection = {
# host, bindDn etc.
bindPassword = "$LDAP_BIND_PW";
};
and write the actual secret into an environment file that's readable for
`mxisd.service` containing
LDAP_BIND_PW=<your secret bind pw>
and the following setting in the Nix expression:
services.mxisd.environmentFile = "/runs/ecrets/mxisd";
(cherry picked from commit aa25ce7aa1a89618e4257fd46c7d20879f54c728)
