Now that the terraform 0.12 compatibility is not needed anymore, the
`terraform.withPlugins` and `terraform-providers.mkProvider`
implementations can be simplified.
Instead of building a bunch of bin wrappers on instantiation, the
providers are now stored in
`$out/libexec/terraform-providers/<registry>/<owner>/<name>/<version>/<os>_<arch>/terraform-provider-<name>_v<version>`
and then a simple `buildEnv` can be used to merge them.
This breaks back-compat so it's not possible to mix-and-match with
previous versions of nixpkgs. In exchange, it now becomes possible to
use the providers from
[nixpkgs-terraform-providers-bin](https://github.com/numtide/nixpkgs-terraform-providers-bin)
directly.
This is a squashed commit. These are the original commit messages:
lib/option: Improve comment
better comment
Update documentation
Updated nixos/doc/manual/development/options-declarations.md with info on mkEnableOption and mkPackageOption.
Updated the comment on mkEnableOption in lib/options.nix
remove trailing whitespace
nixos/doc/option-declarations: Update IDs & formatting
nixos/docs/option-declarations: Escape angle brackets
Build DB from MD
(Amended) Fix typo
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
(Amended) Build DB from MD (again)
This replaces the naive K=V unit parser with a proper INI parser from a
library and adds proper support for override files. Also adds a bunch of
comments about parsing, I hope this makes it easier to understand and
maintain in the future.
There are multiple reasons to do so, the first one is just general
correctness with is nice imo. But to get to more serious reasons (I
didn't put in all that effort for nothing) is that this is the first
step torwards more clever restart/reload handling. By using a library
like Data::Compare a future PR could replace the current way of
fingerprinting units (which is to compare store paths) by comparing the
hashes. This is more precise because units won't get restarted because
the order of the options change, comments are added, some dependency of
writeText changes, .... Also this allows us to add a feature like
`X-Reload-Triggers` so the unit can either be reloaded when these change
or restarted when everything else changes, giving module authors the
ability to have their services reloaded without having to fear that
updates are not applied because the service doesn't get restarted.
Another reason why this feature is nice is that now that the unit files
are parsed correctly (and values are just extracted from one section),
potential future rewrites can just rely on some INI library without
having to implement their own weird parser that is compatible with this
script.
This also comes with a new subroutine to handle systemd booleans because
I thought the current way of handling it was just ugly. This also allows
overriding values this script reads in an override file.
Apart from making this script more compatible with the world around it,
this also fixes two issues I saw bugging exactly 0 (zero) people. First
is that this script now supports multiple override files, also ones that
are not called override.conf and the second one is that `1` and `on` are
treated as bools by systemd but were previously not parsed as such by
switch-to-configuration.
Since release 1.18.4, the ModemManager daemon no longer automatically
performs the FCC unlock procedure by default. The user must, under their
own responsibility, enable the automatic FCC unlock as shipped by
ModemManager.
`assert` has the annoying property that it dumps a lot of code at the
user without the built in capability to display a nicer message. We have
worked around this using `assertMsg` which would *additionally* display
a nice message. We can do even better: By using `throw` we can make
evaluation fail before assert draws its conclusions and prevent it from
displaying the code making up the assert condition, so we get the nicer
message of `throw` and the syntactical convenience of `assert`.
Before:
nix-repl> python.override { reproducibleBuild = true; stripBytecode = false; }
trace: Deterministic builds require stripping bytecode.
error: assertion (((lib).assertMsg (reproducibleBuild -> stripBytecode)) "Deterministic builds require stripping bytecode.") failed at /home/lukas/src/nix/nixpkgs/pkgs/development/interpreters/python/cpython/2.7/default.nix:45:1
After:
nix-repl> python.override { reproducibleBuild = true; stripBytecode = false; }
error: Deterministic builds require stripping bytecode.
The `extraConfig` parameter only handles text - it doesn't support
arbitrary secrets and, with the way it's processed in the setup
script, it's very easy to accidentally unescape the echoed string and
run shell commands / feed garbage to bash.
To fix this, implement a new option, `config`, which instead takes a
typed attribute set, generates the `.env` file in nix and does
arbitrary secret replacement. This option is then used to provide the
configuration for all other options which change the `.env` file.
When upgrading bookstack, if something in the cache conflicts with the
new installation, the artisan commands might fail. To solve this, make
the cache lifetime bound to the setup service. This also removes the
`cacheDir` option, since the path is now handled automatically by
systemd.
This removes `/run/nixos/activation-reload-list` (which we will need in
the future when reworking the reload logic) and makes
`/run/nixos/activation-restart-list` honor `restartIfChanged` and
`reloadIfChanged`. This way activation scripts don't have to bother with
choosing between reloading and restarting.
Still actively developed and yet stuck on python2. Also marked as
vulnerable and their issue tracker contains yet another security issue
reported in 2021/10 that the upstream hasn't acknowledged yet.
Mind blown.
Closes: #135543, #97274, #97275
Why the f*** would anyone ever add generated stuff to a git repository,
where the sources for the generated stuff AND the scripts to generate
them are in the repository?
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We take the idris2 projects version of the derivation. Originally,
Idris2 did not maintain their own nix derivation, so we created our
own. Now they maintain their own derivation, so we should try to
keep ours as close to theirs.
This change comes with the following differences:
* support files are in its own output, instead of packaged with idris2
- This makes it necessary to provide --package for contrib and network
!!! This is a breaking change !!!
* IDIRS2_PREFIX is set to ~/.idris2 instead of pointing to nix-store
- This makes --install work as expected for the user
* Properly set IDRIS2_PACKAGE_PATH
* non-linux platform uses chez-racket instead of chez
This renames our `firmwareLinuxNonfree` package to `linux-firmware`.
There is prior art for this in multiple other distros[1][2][3].
Besides making the package more discoverable by those searching for the
usual name, this also brings it in-line with the `kebab-case` we
normally see in `nixpkgs` pnames, and removes the `Nonfree` information
from the name, which I consider redundant given it's present in
`meta.license`.
The corresponding alias has been added, so this shouldn't break
anything.
[1]: https://archlinux.org/packages/core/any/linux-firmware/
[2]: https://src.fedoraproject.org/rpms/linux-firmware
[3]: https://packages.gentoo.org/packages/sys-kernel/linux-firmware
This is a useful utility for monitoring network performance over time
using a combination of MTR and Prometheus. Also adding a service definition.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
most modules can be evaluated for their documentation in a very
restricted environment that doesn't include all of nixpkgs. this
evaluation can then be cached and reused for subsequent builds, merging
only documentation that has changed into the cached set. since nixos
ships with a large number of modules of which only a few are used in any
given config this can save evaluation a huge percentage of nixos
options available in any given config.
in tests of this caching, despite having to copy most of nixos/, saves
about 80% of the time needed to build the system manual, or about two
second on the machine used for testing. build time for a full system
config shrank from 9.4s to 7.4s, while turning documentation off
entirely shortened the build to 7.1s.
Other services such as minecraft-server and plex allow configuration of
the dataDir option, allowing the files stored by each service to be in a
custom location.
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
Previously, this was only implicitly enabled if xserver.enable = true.
However, Wayland-based desktops do not require this, and so configuring
SSH_ASKPASS on a Wayland desktop becomes cumbersome. This simplifies
that by adding a new option that defaults to the old conditional.
- Add the migrations directory to the package
- Add postgres support to the package
- Add a service for powerdns-admin
Co-authored-by: Zhaofeng Li <hello@zhaofeng.li>
* elk7: 7.11.1 -> 7.16.1
* nixosTests.elk: Improve reliability and compatibility with ELK 7.x
- Use comparisons in jq instead of grepping
- Match for `.hits.total.value` if version >= 7, otherwise it always
passes
- Make curl fail if requests fails
* nixos/filebeat: Add initial module and test
Filebeat is an open source file harvester, mostly used to fetch logs
files and feed them into logstash.
This module can be used instead of journalbeat if used with
`filebeat7` and configured with the `journald` input.
* python3Packages.parsedmarc.tests: Fix breakage
- Don't use the deprecated elasticsearch7-oss package
- Improve jq query robustness and add tracing
* rl-2205: Note the addition of the filebeat service
* elk6: 6.8.3 -> 6.8.21
The latest version includes a fix for CVE-2021-44228.
* nixos/journalbeat: Add a loose dependency on elasticsearch
Avoid unnecssary back-off when elasticsearch is running on the same
host.
The GTK+ 2 version of Claws Mail, major version number three, relies on
Python 2, which is end-of-life and might be dropped in the nixpkgs.
In favour of #148779, this older branch of Claws Mail was removed.
This reverts commit 57961d2b83, reversing
changes made to b04f913afc.
(I.e. this reverts PR #141192.)
While well-intended, this change does unfortunately introduce very
serious regressions that are especially disruptive/noticeable on desktop
systems (e.g. users of Sway will loose their graphical session when
running "nixos-rebuild switch").
Therefore, this change has to be reverted ASAP instead of trying to fix
it in "production".
Note: An updated version should be extensively discussed, reviewed, and
tested before re-landing this change as an earlier version also had to
be reverted for the exact same issues [0].
Fix: #146727
[0]: https://github.com/NixOS/nixpkgs/pull/73871#issuecomment-559783752
See the added comment in all-packages.nix for a more detailed
explanation. This makes the top-level GHC different from
haskellPackages.ghc (which is build->host and used for building the
package set), but more consistent with gcc, gnat etc.
Specifically, pkgsCross.${platform}.buildPackages.ghc will now be a
cross-compiler instead of a native build->build compiler.
Since this change has a slight chance of being disruptive, add a note to
the changelog.
Update the default GNAT version from 9 to 11, as GNAT >= 11 is required
to compile the 22.* AdaCore libraries.
To allow this, we need to pick a patch from ghdl's master fixing a
compilation problem with GNAT 11.
The option `services.prometheus.environmentFile` has been removed since it was causing [issues](https://github.com/NixOS/nixpkgs/issues/126083) and Prometheus now has native support for secret files.
pam_mkhomedir should create homedirs with the same umask as the rest
of the system. Currently it creates homedirs with go+rx which makes
it readable for other non-privileged users.
Use service internal bind mounts instead of global ones.
This also moves the logs to /var/log/unifi on the host
and the run directory to /run/unifi.
Closes#61424
The new option `services.prometheus.enableReload` has been introduced
which, when enabled, causes the prometheus systemd service to reload
when its config file changes.
More specifically the following property holds: switching to a
configuration (`switch-to-configuration`) that changes the prometheus
configuration only finishes successully when prometheus has finished
loading the new configuration.
`enableReload` is `false` by default in which case the old semantics
of restarting the prometheus systemd service are in effect.
the `nixos-rebuild` command has multiple subcommands, and not each of
them would fix the problem of a large `/boot` partition, so let’s be
more precise here.
* FluidSynth 1.1.11 was kept around as a dependency of some packages
that hadn't yet adjusted to API breakages. All of these packages now
use FluidSynth 2.x, so fluidsynth_1 can be removed. It has been broken
ever since glib was updated to 2.70 and was affected by an unpatched
CVE.
* Refactor expression a bit, use pname instead of name.
* Add changelog entry in case someone was using this downstream
(accidentally?).
Fixes#141508.
Fixes#124624.
The version 20 of Nextcloud will be EOLed by the end of this month[1].
Since the recommended default (that didn't raise an eval-warning) on
21.05 was Nextcloud 21, this shouldn't affect too many people.
In order to ensure that nobody does a (not working) upgrade across
several major-versions of Nextcloud, I replaced the derivation of
`nextcloud20` with a `throw` that provides instructions how to proceed.
The only case that I consider "risky" is a setup upgraded from 21.05 (or
older) with a `system.stateVersion` <21.11 and with
`services.nextcloud.package` not explicitly declared in its config. To
avoid that, I also left the `else-if` for `stateVersion < 21.03` which
now sets `services.nextcloud.package` to `pkgs.nextcloud20` and thus
leads to an eval-error. This condition can be removed
as soon as 21.05 is EOL because then it's safe to assume that only
21.11. is used as stable release where no Nextcloud <=20 exists that can
lead to such an issue.
It can't be removed earlier because then every `system.stateVersion <
21.11` would lead to `nextcloud21` which is a problem if `nextcloud19`
is still used.
[1] https://docs.nextcloud.com/server/20/admin_manual/release_schedule.html
mosquitto needs a lot of attention concerning its config because it doesn't
parse it very well, often ignoring trailing parts of lines, duplicated config
keys, or just looking back way further in the file to associated config keys
with previously defined items than might be expected.
this replaces the mosquitto module completely. we now have a hierarchical config
that flattens out to the mosquitto format (hopefully) without introducing spooky
action at a distance.
