Shimming out the Let's Encrypt domain name to reuse client configuration
doesn't work properly (Pebble uses different endpoint URL formats), is
recommended against by upstream,[1] and is unnecessary now that the ACME
module supports specifying an ACME server. This commit changes the tests
to use the domain name acme.test instead, and renames the letsencrypt
node to acme to reflect that it has nothing to do with the ACME server
that Let's Encrypt runs. The imports are renamed for clarity:
* nixos/tests/common/{letsencrypt => acme}/{common.nix => client}
* nixos/tests/common/{letsencrypt => acme}/{default.nix => server}
The test's other domain names are also adjusted to use *.test for
consistency (and to avoid misuse of non-reserved domain names such
as standalone.com).
[1] https://github.com/letsencrypt/pebble/issues/283#issuecomment-545123242
Co-authored-by: Yegor Timoshenko <yegortimoshenko@riseup.net>
This was added in aade4e577b, but the
implementation of the ACME module has been entirely rewritten since
then, and the test seems to run fine on AArch64.
These now depend on an external patch set; add them to the release tests
to ensure that the build doesn't break silently as new kernel updates
are merged.
linux-hardened sets kernel.unprivileged_userns_clone=0 by default; see
anthraxx/linux-hardened@104f44058f.
This allows the Nix sandbox to function while reducing the attack
surface posed by user namespaces, which allow unprivileged code to
exercise lots of root-only code paths and have lead to privilege
escalation vulnerabilities in the past.
We can safely leave user namespaces on for privileged users, as root
already has root privileges, but if you're not running builds on your
machine and really want to minimize the kernel attack surface then you
can set security.allowUserNamespaces to false.
Note that Chrome's sandbox requires either unprivileged CLONE_NEWUSER or
setuid, and Firefox's silently reduces the security level if it isn't
allowed (see about:support), so desktop users may want to set:
boot.kernel.sysctl."kernel.unprivileged_userns_clone" = true;
* nixos/k3s: simplify config expression
* nixos/k3s: add config assertions and trim unneeded bits
* nixos/k3s: add a test that k3s works; minor module improvements
This is a single-node test. Eventually we should also have a multi-node
test to verify the agent bit works, but that one's more involved.
* nixos/k3s: add option description
* nixos/k3s: add defaults for token/serveraddr
Now that the assertion enforces their presence, we dont' need to use the typesystem for it.
* nixos/k3s: remove unneeded sudo in test
* nixos/k3s: add to test list
After the recent rewrite, enabled extensions are passed to php programs
through an extra ini file by a wrapper. Since httpd uses shared module
instead of program, the wrapper did not affect it and no extensions
other than built-ins were loaded.
To fix this, we are passing the extension config another way – by adding it
to the service's generated config.
For now we are hardcoding the path to the ini file. It would be nice to add
the path to the passthru and use that once the PHP expression settles down.
systemd-tmpfiles will load all files in lexicographic order and ignores rules
for the same path in later files with a warning Since we apply the default rules
provided by systemd, we should load user-defines rules first so users have a
chance to override defaults.
This reverts commit 5532065d06.
As far as I can tell setting RemainAfterExit=true here completely breaks
certificate renewal, which is really bad!
the sytemd timer will activate the service unit every OnCalendar=,
however with RemainAfterExit=true the service is already active! So the
timer doesn't rerun the service!
The commit also broke the actual tests, (As it broke activation too)
but this was fixed later in https://github.com/NixOS/nixpkgs/pull/76052
I wrongly assumed that PR fixed renewal too, which it didn't!
testing renewals is hard, as we need to sleep in tests.
For reasons yet unknown, the vxlan backend doesn't work (at least inside
the qemu networking), so this is moved to the udp backend.
Note changing the backend apparently also changes the interface name,
it's now `flannel0`, not `flannel.1`
fixes#74941
This was whitespace-sensitive, kept fighting with my editor and broke
the tests easily. To fix this, let python convert the output to
individual lines, and strip whitespace from them before comparing.
When trying to build a VM using `nixos-build-vms` with a configuration
that doesn't evaluate, an error "at `<unknown-file>`" is usually shown.
This happens since the `build-vms.nix` creates a VM-network of
NixOS-configurations that are attr-sets or functions and don't contain
any file information. This patch manually adds the `_file`-attribute to
tell the module-system which file contained broken configuration:
```
$ cat vm.nix
{ vm.invalid-option = 1; }
$ nixos-build-vms vm.nix
error: The option `invalid-option' defined in `/home/ma27/Projects/nixpkgs/vm.nix@node-vm' does not exist.
(use '--show-trace' to show detailed location information)
```
This commit:
1. Updates the path of the traefik package, so that the out output is
used.
2. Adapts the configuration settings and options to Traefik v2.
3. Formats the NixOS traefik service using nixfmt.
According to my analysis the last critical fix went into v5.4.23, I have
confirmed this by running WebGL over night and haven't seen a single
i915 GPU hang. Lets remove the notes from the release notes.
(cherry picked from commit da764d22ce3b698707861d58824843ded87cbb0a)
We already set the relevant env vars in the systemd services. That does
not help one when executing any of the executables outside a service,
e.g. when creating a new user.
we use stdenv.hostPlatform.uname.processor, which I believe is just like
`uname -p`.
Example values:
```
(import <nixpkgs> { system = "x86_64-linux"; }).stdenv.hostPlatform.uname.processor
"x86_64"
(import <nixpkgs> { system = "aarch64-linux"; }).stdenv.hostPlatform.uname.processor
aarch64
(import <nixpkgs> { system = "armv7l-linux"; }).stdenv.hostPlatform.uname.processor
"armv7l"
```
The new wording does not assume the user is upgrading.
This is because a user could be setting up a new installation on 20.03
on a server that has a 19.09 or before stateVersion!!
The new wording ensures that confusion is reduced by stating that they
do not have to care about the assumed 16→17 transition.
Then, the wording explains that they should, and how to upgrade to
version 18.
It also reviews the confusing wording about "multiple" upgrades.
* * *
The only thing we cannot really do is stop a fresh install of 17 if
there was no previous install, as it cannot be detected. That makes a
useless upgrade forced for new users with old state versions.
It is also important to state that they must set their package to
Nextcloud 18, as future upgrades to Nextcloud will not allow an uprade
from 17!
I assume future warning messages will exist specifically stating what to
do to go from 18 to 19, then 19 to 20, etc...
This allows to have multiple certificates with the same common name.
Lego uses in its internal directory the common name to name the certificate.
fixes#84409
This is an backward incompatible change from upstream dhcpcd [0], as
this could have easily locked me out of my box.
As dhcpcd doesn't allow to use only a blacklist (denyinterfaces in
dhcpcd.conf) of devices and use all remaining devices, while explicitly
allowing some interfaces like bridges, I think the best option would be
to not change anything about it and just educate the users here about
that edge case and how to solve it.
[0] https://roy.marples.name/archives/dhcpcd-discuss/0002621.html
(cherry picked from commit eeeb2bf8035b309a636d596de6a3b1d52ca427b1)
I've had Netdata crash on me sometimes. Rarely but more than once. And I lost days of data before I noticed.
Let's be nice and restart it on failures by default.
This properly supports the `supportedSystems` and
`limitedSupportedSystems` arguments of `release-combined.nix`.
Previously, evaluation would fail if `x86_64-linux` was not part either
of those, since the tested job always referenced the `x86_64-linux`
nixos tests (which won't exist in an aarch64-only eval).
Since the hydra configuration for the jobset`trunk-combined` has both
`aarch64-linux` and `x86_64-linux` as supported systems, this will make
aarch64 be part of the tested job on that jobset.
Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
Instead of making the configuration less portable by hard coding the number of
jobs equal to the cores we can also let nix set the same number at runtime.
This prevents duplication in cross-compiled nixos machines. The
bootstrapped glibc differs from the natively compiled one, so we get
two glibc’s in the closure. To reduce closure size, just use
stdenv.cc.libc where available.
Some changes might require manual migration steps:
"Due to changes to the way in which Gollum handles filenames, you may
have to change some links in your wiki when migrating from gollum 4.x.
See the release notes [0] for more details. You may find the
bin/gollum-migrate-tags script helpful to accomplish this. Also see the
--lenient-tag-lookup option for making tag lookup backwards compatible
with 4.x, though note that this will decrease performance on large wikis
with many tags." (source: [1])
[0]: https://github.com/gollum/gollum/wiki/5.0-release-notes
[1]: https://github.com/gollum/gollum/blob/v5.0.0/HISTORY.md
We have this bug https://github.com/elementary/gala/issues/636
when using notifications in gala. It's likely to not really be fixed
because all development is on the new notifications server.
Them removing cerbere and registering with the SessionManager
should make shutdown very fast. This was even done in plank [0]
which was the last factor outside cerbere causing this.
[0]]: a8d2f255b2
As discussed in https://github.com/NixOS/nixpkgs/pull/73763, prevailing
consensus is to revert that commit. People use the hardened profile on
machines and run nix builds, and there's no good reason to use
unsandboxed builds at all unless you're in a platform that doesn't
support them.
This reverts commit 00ac71ab19.
