Database provisioning was shown to be racy since adding a recorder test
using PostgreSQL. There is no harm in waiting for these services,
because if they're not available they will be ignored.
It simply should not be required to override the package for such a
common use case, especially since the module usually adds another
override on top to inherit extraComponents.
After this change users with non-declarative configs need to set
`services.home-assistant.config` to an `null`, or their
`configuration.yaml` will be overwritten.
The reason for this is that with rfc42 style defaults the config
attribute set will never be empty by default.
If people take the time to setup network-online.target correctly we
should wait for it. If they don't it's basically the same as
network.target anyway, so no harm done.
Over time I've seen multiple integrations that have dealt badly with
missing network connectivity at startup, this should alleviate further
pains.
The given example is now closer to a sane default people will want to
start with. It also displays the existance of extraComponents, a feature
that will receive more usage with home-assistant warning about
components that have completely migrated away from YAML configuration.
--port and --address have both been deprecated and are nonfunctional
starting with kubernetes 1.23. Use --secure-port and --bind-address
instead. This means that users can no longer rely on the insecure port
for anything, so update the release notes accordingly.
The `substituters` option in `nix.settings` uses the order
of the substituters listed to define priority. Prior to https://github.com/NixOS/nixpkgs/pull/139075,
the corresponding option `binaryCaches` is declared in the `nix` namespace,
which is guaranteed to be merged last. However, the order of merging isn't
guaranteed in submodules. This cause definitions to be appended to the default
value instead of prepended, breaking backwards compatibility as reported in https://github.com/NixOS/nixpkgs/issues/158356.
The way this is addressed in the module system is with order priorities via
`mkOrder` and sorting definitions before merging. This PR restores the previous
behavior by setting a higher priority to the substituters option defined internally,
thus all definitions with default priority will be merged before it. This was chosen because
the `mkRenamedOption` function does not preserve order priority so users using legacy options do not have
precise control on placement.
This change should suffice for simple configuration, but further revision to the module system
is needed for to make various `mk*` functions aware of order priorities.
logrotate global options only affect rules following them - as such,
services.logrotate.extraConfig being added last makes the option only
useful for adding new paths but not for setting global options (e.g.
'dateext' so all logs are rotate with a date suffix).
Moving this first solves this problem, and we can then use this instead
of default paths config to append missingok/notifempty.
wtmp and btmp are created by systemd, so the rules are more appropriate there.
They can be disabled explicitly with something like
services.ogrotate.paths = {
"/var/log/btmp".enable = false;
"/var/log/wtmp".enable = false;
};
if required.
In #139075, mandatoryFeatures was removed from the generated
supportedFeatures, which breaks backward compatibility and is
different from what the description of supportedFeatures says.
Addresses #16545. Allows for user defined environment variables that
hold paths to wordlists. This is to allow for easy access to wordlists
for users and scripts, (in other distributions a convenient wordlist is
typically found in /usr/share/dict/words or similar). The default
wordlist is the one found in scowl, for no other reason than that's the
one that was mentioned in the linked issue.
It is possible to specify multiple environment variables as well. This
is for users who need multiple wordlists (such as multilingual users).
This is accomplished by comparing the hashes that the unit files
contain. By filtering for a special key `X-Reload-Triggers` in the
`[Unit]` section, we can differentiate between reloads and restarts.
Since activation scripts can request reloads of units as well, more
checking of this behaviour is implemented. If a unit is to be restarted,
it's never reloaded as well which would make no sense.
Also removes a useless subroutine and perl dependencies that are
nowadays handled by the propagated build inputs feature of
`perl.withPackages`.
