`privacyidea-token-janitor`[1] is a tool which helps to automate
maintenance of tokens. This is helpful to identify e.g. orphaned tokens,
i.e. tokens of users that were removed or tokens that were unused for a
longer period of time and apply actions to them (e.g. `disable` or
`delete`).
This patch adds two new things:
* A wrapper for `privacyidea-token-janitor` to make sure it's executable
from CLI. To achieve this, it does a `sudo(8)` into the
`privacyidea`-user and sets up the environment to make sure the
configuration file can be found. With that, administrators can
directly invoke it from the CLI without additional steps.
* An optional service is added which performs automatic cleanups of
orphaned and/or unassigned tokens. Yes, the tool can do way more
stuff, but I figured it's reasonable to have an automatic way to clean
up tokens of users who were removed from the PI instance. Additional
automation steps should probably be implemented in additional
services (and are perhaps too custom to add them to this module).
[1] https://privacyidea.readthedocs.io/en/v3.7/workflows_and_tools/tools/index.html
In order to be able to use the unixd service with the `verify_ca` and
`verify_hostnames` set to `true` it needs to be able to read the
certificate store. This change bind mounts the cacert paths for the
unixd service.
most of these are hidden because they're either part of a submodule that
doesn't have its type rendered (eg because the submodule type is used in
an either type) or because they are explicitly hidden. some of them are
merely hidden from nix-doc-munge by how their option is put together.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
there are sufficiently few variable list around, and they are
sufficiently simple, that it doesn't seem helpful to add another
markdown extension for them. rendering differences are small, except in
the tor module: admonitions inside other blocks cannot be made to work
well with mistune (and likely most other markdown processors), so those
had to be shuffled a bit. we also lose paragraph breaks in the list
items due to how we have to render from markdown to docbook, but once we
remove docbook from the pipeline those paragraph breaks will be restored.
the way these are written they introduce lots of whitespace in each
line, which will cause those lines to render as code when converted to
markdown. override the whole description instead.
no change in rendered output. the html manual could render <screen>
blocks differently, but so far it hasn't (and if we need to make a
distinction we can use a special info string).
using regular strings works well for docbook because docbook is not as
whitespace-sensitive as markdown. markdown would render all of these as
code blocks when given the chance.
this renders the same in the manpage and a little more clearly in the
html manual. in the manpage there continues to be no distinction from
regular text, the html manual gets code-type markup (which was probably
the intention for most of these uses anyway).
now nix-doc-munge will not introduce whitespace changes when it replaces
manpage references with the MD equivalent.
no change to the manpage, changes to the HTML manual are whitespace only.
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
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`.
* Update to the latest upstream version of pass-secret-service that includes
systemd service files.
* Add patch to fix use of a function that has been removed from the Python
Cryptography library in NixOS 22.05
* Install systemd service files in the Nix package.
* Add NixOS test to ensure the D-Bus API activates the service unit.
* Add myself as a maintainer to the package and NixOS test.
* Use checkTarget instead of equivalent custom checkPhase.
* nixos/vault: add option to start in dev mode.
This is not only useful for nixos tests i.e. when testing vault agent
setups but also when playing around with vault in local setups. In our
tests we can now make use of this option to test more vault features.
i.e. adding this feature has uncovered the need for a `StateDirectory`.
* Update nixos/modules/services/security/vault.nix
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Jonas Chevalier <zimbatm@zimbatm.com>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
