NixOS has traditionally enabled the `ext` family of file systems by
default. Originally, when switching to systemd initrd, we wanted to
transition to making this explicit so that initrds could be made
without `ext`. The problem is that anyone with `fsType = "auto";` for
an `ext` file system in initrd will fail to boot, which is not really
an acceptable regression as we switch to systemd initrd by default.
By removing `default = "auto"` from `fsType`, we rule out the vast
majority of these regressions as eval errors, since most users of
`fsType = "auto"` for ext file systems are using it because of the
default value.
In hindsight, this is probably what #225352 was really about.
Paths are purposedly not changing for now.
Signed-off-by: Ludovic Ortega <ludovic.ortega@adminafk.fr>
Signed-off-by: Nicolas Dumazet <nicdumz.commits@gmail.com>
- It lacks a consistent and transparent baseline or standard,
- It may introduce unexpected breakage or degrade performance without clear benefit,
- It is difficult to manage user expectations, especially since the implications of enabling it are not always obvious,
- and as multiple contributors have noted, it is often more of a “grab bag” of settings than a cohesive security policy.
By default it will look for the cred names supported by the upstream package, but alternate cred names can be chosen to produce a rename on the ImportCredential.
With Lego since 4.25.0 instead of --days we can pass --dynamic to pick
the renewal date based on a fraction of its total validity duration.
This provides a reasonable default that accomodates varying certificate
validy durations we're going to be seeing through the profile option and
LE's plans to reduce the default validity duration in multiple steps down
to 45 days in 2028.
This changes changes the default valid duration to null to enable dynamic
renewal calculation. To that end the expiration skip function gained the
ability to calculate the total and remaining duration and to apply the
correct remainder based on the certificates total duration.
Closes#495278
Turns out that the documentation about secrets[1] is actually a little
misleading and I let myself fool by it: the rotation is about moving
to envelope-based encryption, i.e. a way where a key is generated and
stored in the DB that is encrypted with `secret_key` and used to
decrypt actual secrets.
In fact, there's no official way to rotate this on a running instance.
The reason this wasn't noticed so far is because I'd expect most people
to
* use provisioning to set up their datasources (or)
* talk to a local Prometheus (or else) API that is exposed on the
machine only and thus no authentication is needed if you trust that
machine enough.
On top, the encryption is unauthenticated so only changing secret_key
appears to work, but uses gibberish as password for authentication
against data-sources.
So effectively there are two ways to migrate (short of a fresh setup):
* keep the old secret and call it a day. IMHO this is fine if the setup
is e.g. a single-node machine where both the secret and the DB are on
the same file-system, in the same data-dir and protected by the same
permissions.
* use a 3rd-party rotation tool[2]. I ensured by hand on a test-instance
that following the instructions works and you end up with a freshly
generated secret_key that you need to deploy. With that key deployed,
the credentials still decrypt to the same plaintext.
[1] https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-database-encryption/#envelope-encryption
[2] d9dc788902
Adds a NixOS service module for kiwix-serve, which was requested quite a
while ago. kiwix-serve allows one to host ZIM files (such as for
archives of Wikipedia) over HTTP.
A NixOS VM test that generates and serves a basic ZIM file has also been
added. The ZIM file is generated as part of the test, since the output
file is relatively large (~60 KB) relative to the source content (~100
bytes).
See: <https://wiki.kiwix.org/wiki/Kiwix-serve>