Use StateDirectory to create necessary directories and hardcode some
paths. Also drop file based audit logs, they can be found in the
journal. And add module option deprecation messages.
- Begin a new chapter "GPU Acceleration", this should also cover
VA-API, OpenGL, Vulkan, etc.
- Add a general blurb about OpenCL and how to check whether OpenCL
devices are found.
- Add a section about enabling OpenCL for AMD GPUs specifically.
`sslCACert` was used for trust store of client and server certificates. Since `smtpd_tls_ask_ccert` defaults to no the setup of `smtpd_tls_CApath` was removed.
>By default (see smtpd_tls_ask_ccert), client certificates are not requested, and smtpd_tls_CApath should remain empty.
see http://www.postfix.org/postconf.5.html#smtpd_tls_CAfile
With 'set 3 boot on' the error 'file system "/boot" is not a FAT EFI
system partition (ESP) file system' occurs when running
"nixos-install" during the basic installation (tested in in a
VirtualBox VM).
Keeping the VM state test across several run sometimes lead to subtle
and hard to spot errors in practice. We delete the VM state which
contains (among other things) the qcow volume.
We also introduce a -K (--keep-vm-state) flag making VM state to
persist after the test run. This flag makes test-driver.py to match
its previous behaviour.
Enhance the heuristics to make sure that a user doesn't accidentally
upgrade across two major versions of Nextcloud (e.g. from v17 to v19).
The original idea/discussion has been documented in the nixpkgs manual[1].
This includes the following changes:
* `nextcloud19` will be selected automatically when having a stateVersion
greater or equal than 20.09. For existing setups, the package has to
be selected manually to avoid accidental upgrades.
* When using `nextcloud18` or older, a warning will be thrown which recommends
upgrading to `nextcloud19`.
* Added a brief paragraph about `nextcloud19` in the NixOS 19.09 release
notes.
* Restart `phpfpm` if the Nextcloud-package (`cfg.package`) changes[2].
[1] https://nixos.org/nixos/manual/index.html#module-services-nextcloud-maintainer-info
[2] https://github.com/NixOS/nixpkgs/pull/89427#issuecomment-638885727
Specifying mailboxes as a list isn't a good approach since this makes it
impossible to override values. For backwards-compatibility, it's still
possible to declare a list of mailboxes, but a deprecation warning will
be shown.
Virtualbox recommends VMSVGA for Linux guests.
It is also currently the only one supporting 3D acceleration
and it works out of the box with NixOS and auto screen resizing.
Since cd1dedac67 systemd-networkd has it's
netlink socket created via a systemd.socket unit. One might think that
this doesn't make much sense since networkd is just going to create it's
own socket on startup anyway. The difference here is that we have
configuration-time control over things like socket buffer sizes vs
compile-time constants.
For larger setups where networkd has to create a lot of (virtual)
devices the default buffer size of currently 128MB is not enough.
A good example is a machine with >100 virtual interfaces (e.g.,
wireguard tunnels, VLANs, …) that all have to be brought up during
startup. The receive buffer size will spike due to all the generated
message from the new interfaces. Eventually some of the message will be
dropped since there is not enough (permitted) buffer space available.
By having networkd start through / with a netlink socket created by
systemd we can configure the `ReceiveBufferSize` parameter in the socket
options without recompiling networkd.
Since the actual memory requirements depend on hardware, timing, exact
configurations etc. it isn't currently possible to infer a good default
from within the NixOS module system. Administrators are advised to
monitor the logs of systemd-networkd for `rtnl: kernel receive buffer
overrun` spam and increase the memory as required.
Note: Increasing the ReceiveBufferSize doesn't allocate any memory. It
just increases the upper bound on the kernel side. The memory allocation
depends on the amount of messages that are queued on the kernel side of
the netlink socket.
udev gained native support to handle FIDO security tokens, so we don't
need a module which only added the now obsolete udev rules.
Fixes: https://github.com/NixOS/nixpkgs/issues/76482
This fixes the output of "hostname --fqdn" (previously the domain name
was not appended). Additionally it's now possible to use the FQDN.
This works by unconditionally adding two entries to /etc/hosts:
127.0.0.1 localhost
::1 localhost
These are the first two entries and therefore gethostbyaddr() will
always resolve "127.0.0.1" and "::1" back to "localhost" [0].
This works because nscd (or rather the nss-files module) returns the
first matching row from /etc/hosts (and ignores the rest).
The FQDN and hostname entries are appended later to /etc/hosts, e.g.:
127.0.0.2 nixos-unstable.test.tld nixos-unstable
::1 nixos-unstable.test.tld nixos-unstable
Note: We use 127.0.0.2 here to follow nss-myhostname (systemd) as close
as possible. This has the advantage that 127.0.0.2 can be resolved back
to the FQDN but also the drawback that applications that only listen to
127.0.0.1 (and not additionally ::1) cannot be reached via the FQDN.
If you would like this to work you can use the following configuration:
```nix
networking.hosts."127.0.0.1" = [
"${config.networking.hostName}.${config.networking.domain}"
config.networking.hostName
];
```
Therefore gethostbyname() resolves "nixos-unstable" to the FQDN
(canonical name): "nixos-unstable.test.tld".
Advantages over the previous behaviour:
- The FQDN will now also be resolved correctly (the entry was missing).
- E.g. the command "hostname --fqdn" will now work as expected.
Drawbacks:
- Overrides entries form the DNS (an issue if e.g. $FQDN should resolve
to the public IP address instead of 127.0.0.1)
- Note: This was already partly an issue as there's an entry for
$HOSTNAME (without the domain part) that resolves to
127.0.1.1 (!= 127.0.0.1).
- Unknown (could potentially cause other unexpected issues, but special
care was taken).
[0]: Some applications do apparently depend on this behaviour (see
c578924) and this is typically the expected behaviour.
Co-authored-by: Florian Klink <flokli@flokli.de>
The `network-link-${i.name}` units raced with other things trying to
configure the interface, or ran before the interface was available.
Instead of running our own set of shell scripts on boot, and hoping
they're executed at the right time, we can make use of udev to configure
the interface *while they appear*, by providing `.link` files in
/etc/systemd/network/*.link to set MACAddress and MTUBytes.
This doesn't require networkd to be enabled, and is populated properly
on non-networkd systems since
https://github.com/NixOS/nixpkgs/pull/82941.
This continues clean-up work done in
https://github.com/NixOS/nixpkgs/pull/85170 for the scripted networking
stack.
The only leftover part of the `network-link-${i.name}` unit (bringing
the interface up) is moved to the beginning of the
`network-addresses-${i.name}` unit.
Fixes: https://github.com/NixOS/nixpkgs/issues/74471
Closes: https://github.com/NixOS/nixpkgs/pull/87116
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
'nix build' is an experimental command so we shouldn't use it
yet. (nixos-rebuild also uses 'nix', but only when using flakes, which
are themselves an experimental feature.)
This follows upstreams change in documentation. While the `[DHCP]`
section might still work it is undocumented and we should probably not
be using it anymore. Users can just upgrade to the new option without
much hassle.
I had to create a bit of custom module deprecation code since the usual
approach doesn't support wildcards in the path.
Systemd upstream has deprecated CriticalConnection with v244 in favor of
KeepConnection as that seems to be more flexible:
The CriticalConnection= setting in .network files is now deprecated,
and replaced by a new KeepConfiguration= setting which allows more
detailed configuration of the IP configuration to keep in place.
Rework withExtensions / buildEnv to handle currently enabled
extensions better and make them compatible with override. They now
accept a function with the named arguments enabled and all, where
enabled is a list of currently enabled extensions and all is the set
of all extensions. This gives us several nice properties:
- You always get the right version of the list of currently enabled
extensions
- Invocations chain
- It works well with overridden PHP packages - you always get the
correct versions of extensions
As a contrived example of what's possible, you can add ImageMagick,
then override the version and disable fpm, then disable cgi, and
lastly remove the zip extension like this:
{ pkgs ? (import <nixpkgs>) {} }:
with pkgs;
let
phpWithImagick = php74.withExtensions ({ all, enabled }: enabled ++ [ all.imagick ]);
phpWithImagickWithoutFpm743 = phpWithImagick.override {
version = "7.4.3";
sha256 = "wVF7pJV4+y3MZMc6Ptx21PxQfEp6xjmYFYTMfTtMbRQ=";
fpmSupport = false;
};
phpWithImagickWithoutFpmZip743 = phpWithImagickWithoutFpm743.withExtensions (
{ enabled, all }:
lib.filter (e: e != all.zip) enabled);
phpWithImagickWithoutFpmZipCgi743 = phpWithImagickWithoutFpmZip743.override {
cgiSupport = false;
};
in
phpWithImagickWithoutFpmZipCgi743
It currently says that everything will be backward compatible between lego and simp-le certificates, but it’s not.
(cherry picked from commit 21c4a33cee)
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 da764d22ce)
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 eeeb2bf803)
