I ended up with a corrupted image with the debugfs contraption once, and
given I couldn't reproduce the problem I suppose that happens if the
filesystem of the builder runs out of space.
At least in this instance fsck could detect it, so let's add it as a
sanity check.
lib.optional returns a singleton or an empty list. Therefore the
argument does not need to be wrapped in a list.
An alternative patch could have used lib.optionals but seems like no
more elements are going to be added to the optional list.
This is apparent from the service file directory in plymouth:
├── multi-user.target.wants
│ ├── plymouth-quit.service -> ../plymouth-quit.service
│ └── plymouth-quit-wait.service -> ../plymouth-quit-wait.service
Leaving it unspecified caused gdm-wayland to crash on boot, see #39615.
The change made other display managers not quit plymouth properly however. By
removing "multi-user.target" from `plymouth-quit.after` this is resolved.
The following changes have been applied:
- the property `http.headers.X-Content-Type-Options` must a list of
strings rather than a serialized list
- instead of `/etc/docker/registry/config.yml` the configuration will be
written with `pkgs.writeText` and the store path will be used to run
the registry. This reduces the risk of possible impurities by relying
on the Nix store only.
- cleaned up the property paths to easy readability and reduce the
verbosity.
- enhanced the testcase to ensure that digests can be deleted as well
- the `services.docker-registry.extraConfig` object will be merged with
`registryConfig`
/cc @ironpinguin
Some time ago I fixed the broken package `osquery` (see #39336).
I had to test the package manually by starting the daemon locally,
however this doesn't ensure that the module is still functional.
In order to cover the package *and* the integration with the NixOS
module I thought that adding a testcase might be the best idea.
The current testcase does the following things:
* Starts an `osqueryd` service in a test machine with customized logger
path and PID file
* Ensures that the `osqueryd.service` unit is running
* Checks if the customized flags (`pidfile`, `logger_path`) are applied
to `osquery`.
* Performs a simple test query against the `etc_hosts` database to check
if the basic funcitonality of `osquery` (storing system information into
a database) works fine.
@Ekleog writes in https://github.com/NixOS/nixpkgs/pull/39526:
> I think a default of 4096 is maybe too much? See certbot/certbot#4973;
> Let's Encrypt supposedly know what they are doing and use a
> pre-generated 2048-bit DH params (and using the same DH params as
> others is quite bad, even compared to lower bit size, if I correctly
> remember the attacks available -- because it increases by as much the
> value of breaking the group).
> Basically I don't have anything personal against 4096, but fear it may
> re-start the arms race: people like having "more security" than their
> distributions, and having NixOS already having more security than is
> actually useful (I personally don't know whether a real-size quantum
> computer will come before or after our being able to break 2048-bit
> keys, let alone 3072-bit ones -- see wikipedia for some numbers).
> So basically, I'd have set it to 3072 in order to both decrease build
> time and avoid having people setting it to 8192 and complaining about
> how slow things are, but that's just my opinion. :)
While he suggests is 3072 I'm using 2048 now, because it's the default
of "openssl dhparam". If users want to have a higher value, they can
still change it.
Signed-off-by: aszlig <aszlig@nix.build>
