nix-prefetch-git is either run as part of a build, usually sandboxed,
or outside a build, unsandboxed, to prefetch something that will later
be used in a build. It's important that the latter use produces
hashes that can be reproduced by the former.
One way that they can differ is if the user's git config does
something that changes the result of git clone. I ran into this,
because my global git config automatically enables git-lfs, whereas
nix-prefetch-git otherwise only uses git-lfs if specifically
requested. This led to very confusing hash mismatches.
The default just recently changed in 23.11. Users that had
swraid enabled implicitly by NixOS in previous releases got surprised
by warnings even though they do not actually use software RAID.
Fixes#254807
Clarify that the monochrome font is not included, per #221181.
The new name is also coherent with the name of the font,
according to `fontconfig`: Noto Color Emoji.
For NVLink topology systems we need fabricmanager. Fabricmanager itself is
dependent on the datacenter driver set and not the regular x11 ones, it is also
tightly tied to the driver version. Furhtermore the current cudaPackages
defaults to version 11.8, which corresponds to the 520 datacenter drivers.
Future improvement should be to switch the main nvidia datacenter driver version
on the `config.cudaVersion` since these are well known from:
> https://docs.nvidia.com/deploy/cuda-compatibility/index.html#use-the-right-compat-package
This adds nixos configuration options `hardware.nvidia.datacenter.enable` and
`hardware.nvidia.datacenter.settings` (the settings configure fabricmanager)
Other interesting external links related to this commit are:
* Fabricmanager download site:
- https://developer.download.nvidia.com/compute/cuda/redist/fabricmanager/linux-x86_64/
* Data Center drivers:
- https://www.nvidia.com/Download/driverResults.aspx/193711/en-us/
Implementation specific details:
* Fabricmanager is added as a passthru package, similar to settings and
presistenced.
* Adds `use{Settings,Persistenced,Fabricmanager}` with defaults to preserve x11
expressions.
* Utilizes mkMerge to split the `hardware.nvidia` module into three comment
delimited sections:
1. Common
2. X11/xorg
3. Data Center
* Uses asserts to make the configurations mutualy exclusive.
Notes:
* Data Center Drivers are `x86_64` only.
* Reuses the `nvidia_x11` attribute in nixpkgs on enable, e.g. doesn't change it
to `nvidia_driver` and sets that to either `nvidia_x11` or `nvidia_dc`.
* Should have a helper function which is switched on `config.cudaVersion` like
`selectHighestVersion` but rather `selectCudaCompatibleVersion`.
My system does not use `bcache` and I sould prever my `systemPackages`
not to have bcache tools.
The change does not change the default but proviced usual `enable` knob.
Add new command `nixos-rebuild list-generations`. It will show an output
like
```
$ nixos-rebuild list-generations
Generation Build-date NixOS version Kernel Configuration Revision Specialisations
52 (current) Fri 2023-08-18 08:17:27 23.11.20230817.0f46300 6.4.10 448160aeccf6a7184bd8a84290d527819f1c552c *
51 Mon 2023-08-07 17:56:41 23.11.20230807.31b1eed 6.4.8 99ef480007ca51e3d440aa4fa6558178d63f9c42 *
```
This also mentions the change in the upcoming release notes
fixes#232505
Implements the new option `security.acme.maxConcurrentRenewals` to limit
the number of certificate generation (or renewal) jobs that can run in
parallel. This avoids overloading the system resources with many
certificates or running into acme registry rate limits and network
timeouts.
Architecture considerations:
- simplicity, lightweight: Concerns have been voiced about making this
already rather complex module even more convoluted. Additionally,
locking solutions shall not significantly increase performance and
footprint of individual job runs.
To accomodate these concerns, this solution is implemented purely in
Nix, bash, and using the light-weight `flock` util. To reduce
complexity, jobs are already assigned their lockfile slot at system
build time instead of dynamic locking and retrying. This comes at the
cost of not always maxing out the permitted concurrency at runtime.
- no stale locks: Limiting concurrency via locking mechanism is usually
approached with semaphores. Unfortunately, both SysV as well as
POSIX-Semaphores are *not* released when the process currently locking
them is SIGKILLed. This poses the danger of stale locks staying around
and certificate renewal being blocked from running altogether.
`flock` locks though are released when the process holding the file
descriptor of the lock file is KILLed or terminated.
- lockfile generation: Lock files could either be created at build time
in the Nix store or at script runtime in a idempotent manner.
While the latter would be simpler to achieve, we might exceed the number
of permitted concurrent runs during a system switch: Already running
jobs are still locked on the existing lock files, while jobs started
after the system switch will acquire locks on freshly created files,
not being blocked by the still running services.
For this reason, locks are generated and managed at runtime in the
shared state directory `/var/lib/locks/`.
nixos/security/acme: move locks to /run
also, move over permission and directory management to systemd-tmpfiles
nixos/security/acme: fix some linter remarks in my code
there are some remarks left for existing code, not touching that
nixos/security/acme: redesign script locking flow
- get rid of subshell
- provide function for wrapping scripts in a locked environment
nixos/acme: improve visibility of blocking on locks
nixos/acme: add smoke test for concurrency limitation
heavily inspired by m1cr0man
nixos/acme: release notes entry on new concurrency limits
nixos/acme: cleanup, clarifications
This avoids the possible confusion with `passwordFile` being the file
version of `password`, while it should contain the password hash.
Fixes issue #165858.
This patch packages mu4e as an Emacs lisp package based on the mu4e
output of the multiple-output package mu, which makes mu4e a good
citizen of Emacs lisp packages in two aspects.
First, mu4e now utilizes the Emacs lisp package infrastructure in
Nixpkgs. This allows users who want to do AOT native compilation for
non-default Emacs variants[0] to build only mu4e itself instead of the
whole mu package[1].
Second, mu4e now conforms to the Emacs builtin package manager[2].
Without this patch, mu4e autoloaded commands do not work
out-of-the-box[3] because its directory is added to load-path by
site-start.el after the initialization of package-directory-list,
which causes package-activate-all to not load mu4e-autoloads.el. This
patch fixes this issue when mu4e is installed to Emacs using the
withPackages wrapper[4].
[0]: such as emacs-pgtk
[1]: mu.override { emacs = emacs-pgtk; }
[2]: package.el
[3]: either (require 'mu4e) or (require 'mu4e-autoloads) is needed to
be called before an autoloaded command is called
[4]: emacs-pgtk.pkgs.withPackages (epkgs: [ epkgs.mu4e ])
The free version of Aseprite has a maintained fork, LibreSprite which is
already packaged in nixpkgs. The only really useful version of Aseprite
vs LibreSprite is the unfree version, and the free version will never
receive updates.
password-store.el is on MELPA so it is available in Nixpkgs as
emacs.pkgs.password-store.
Using emacs.pkgs.password-store is preferred because of better package
quality:
- Emacs lisp package dependencies are automatically installed
- byte-compilation is done
- native-compilation is done
Use "$out/var/lib" as LOCALSTATEDIR configuration value
by default intsead of "/var/lib"
as a way toward top-level-directory independent runtime.
Add input argument externalLocalStateDir to optionally specify the
path to external LOCALSTATEDIR if not null.
Add NixOS module option
programs.singularity.enableExternalLocalStateDir (default to true)
to use "/var/lib" as LOCALSTATEDIR.
adwaita-qt tries valiantly to ensure a visual consistency
but unfortunately, it often falls into an uncanny valley instead.
Let’s make it opt-in again for more vanilla default experience.
Related: https://pagure.io/fedora-workstation/issue/351
Right now, the settings aren't additive which means that when I do
services.nextcloud.phpOptions."opcache.interned_strings_buffer = "23";
all other options are discarded because of how the module system works.
This isn't very nice in this case, though because wanting to override
a single option doesn't mean I want to discard the rest of the -
reasonable - defaults. Hence, the settings are showed as default in the
option's manual section, but are added with normal priority.
That means, to override _all_ options at once, an expression like
services.nextcloud.phpOptions = mkForce {
/* ... */
};
is needed. This is also way more intuitive IMHO because the `mkForce`
explicitly tells that everything will be modified.
Also, APCu enable and the memory & file-size limits are also written
into `services.nextcloud.phpOptions` rather than adding them
silently before passing all options to the PHP package. This has the
benefit that users will realize on evaluation time that they configured
options that would otherwise be set by the module on its own.
In some setups, and especially with sytemd-networkd becoming more widely
used, networking.useDHCP is set to false. Despite this, it may be useful
to have dhcp in the initramfs.
With this change we allow the user to configure extras, exposed as
optional-dependencies on the matrix-synapse package.
The vertical integration between package, user configuration and
deployment is a huge boon which then allows us to dynamically adapt the
python environment the service runs in, by inspecting the configuration
and autodiscovering certain used extras from config paths.
Conflicts:
- pkgs/tools/networking/shadowfox/default.nix between e989daa65f and 1c29673fcc
- pkgs/tools/networking/wuzz/default.nix between 7d80417710 and 1c29673fcc
Add `keyboards` option to define different configurations for different IDs. This creates the appropriate files in `/etc/keyd` instead of just `default.conf` as before.
Add `23.11` release note entry.
Add `mkRemovedOptionModule` for the old API with a note on how to revert the old behavior.
In 787af0f79f
I had to change ${go-modules} to $goModules to allow overrideAttrs to work;
However, env vars cannot contain -, so i had to change go-modules too.
This in turn broke nix-update because it uses the go-modules attr.
Instead of making nix-update more complicated, make go-modules naming match cargoDeps.
`fd --type f | xargs sd '\bgo-modules\b' 'goModules'`
and revert change to pkgs/applications/misc/dstask/default.nix
and pkgs/servers/http/dave/default.nix
and pkgs/os-specific/darwin/plistwatch/default.nix
release note added
swraid support will now only be enabled by default if stateVersion is
older than 23.11. nixos-generate-config will now generate explicit
config for enabling support if needed.
The whole option set was recommended against since mid-2019, and never
worked with the Raspberry Pi 4 family of devices.
We should have deprecated it in early 2020 for removal by 2021. At the
time I did not feel confident in making such a decision, and never
ended-up getting around to it.
The ***only*** supported-by-NixOS boot methods for AArch64 are
standards-based boot methods, namely UEFI or the pragmatically
almost-standard extlinux-compatible for U-Boot.
You can quote me on that.
Unfortunately the config is not compatible; data itself looks like it was compatible
from an up to date python ankisyncd but I wouldn't assume anything with the older
service (which didn't work for me with either ankidroid or recent desktop version)
At this point this is basically a full rewrite of this module, which
is a breaking change and was necessary to properly expose the useful
parts of hostapd's config. The notable changes are:
- `hostapd` is now started with additional systemd sandbox/hardening options
- A single-daemon can now manage multiple distinct radios and BSSs, which is
why all configuration had to be moved into `hostapd.radios`
- By default WPA3-SAE will be used, but WPA2 and WPA3-SAE-TRANSITION are
supported, too
- Added passwordFile-like options for wpa and sae
- Add new relevant options for MAC ACL, WiFi5, WiFi6 and WiFi7 configuration
- Implements RFC42 as far as reasonable for hostapd
- Removes `with lib;`
These changes are important to support modern APs configurations.
Short overview:
- CONFIG_IEEE80211AX support (WiFi6)
- CONFIG_SAE_PK (pubkey authenticated WPA3)
- CONFIG_DRIVER_NONE (standalone RADIUS server)
- CONFIG_OCV (Operating Channel Validation)
- Enable epoll on linux systems
- Remove deprecated TKIP support
- Fix misspelling (CONFIG_INTERNETWORKING != CONFIG_INTERWORKING)
- The .config was restructured into sections to reflect the
upstream defconfig order and for easier updating in the future
Also, make `python3Packages.sequoia` throw a message regarding it's
replacement of `python3Packages.sequoia`. The main sequoia-pgp/sequoia
repository doesn't ship Python code since 0.25.0, just a binary.
This change removes the bespoke logic around identifying block devices.
Instead of trying to find the right device by iterating over
`qemu.drives` and guessing the right partition number (e.g.
/dev/vda{1,2}), devices are now identified by persistent names provided
by udev in /dev/disk/by-*.
Before this change, the root device was formatted on demand in the
initrd. However, this makes it impossible to use filesystem identifiers
to identify devices. Now, the formatting step is performed before the VM
is started. Because some tests, however, rely on this behaviour, a
utility function to replace this behaviour in added in
/nixos/tests/common/auto-format-root-device.nix.
Devices that contain neither a partition table nor a filesystem are
identified by their hardware serial number which is injecetd via QEMU
(and is thus persistent and predictable). PCI paths are not a reliably
way to identify devices because their availability and numbering depends
on the QEMU machine type.
This change makes the module more robust against changes in QEMU and the
kernel (non-persistent device naming) and by decoupling abstractions
(i.e. rootDevice, bootPartition, and bootLoaderDevice) enables further
improvement down the line.
it's been long in the making, and with 23.05 out we can finally disable
docbook option docs and default to markdown instead. this brings a
massive speed boost in manual and manpage builds, so much so that we may
consider enabling user module documentation by default.
we don't remove the docbook support code entirely yet because it's a lot
all over, and probably better removed in multiple separate changes.
The nixos/caddy module is somewhat old by now
and has undergone quite some refactors.
This specific module option (originally named
`ca`) used to make a bit more sense when
Caddy did not have multiple ACME CAs as
fallback (LE & ZeroSSL) by configured by
default yet (ZeroSSL came with v2.3.0).
I also rephrased the description slightly,
to mention Caddy's automatic issuer fallback
and a note which this option maps to in the
Caddyfile, to provide a bit more context and
a more up-to-date recommendation.
Specifically that "fine-grained configuration"
section comes from a time when this module did
some custom tls/issuer config json merging
with the templated Caddyfile using `jq`.
The "The URL to the ACME CA's directory"
section is a word-for-word copy from the
official Caddy docs, which also include a link
to LE's docs to the referenced staging
endpoint. So I added that as well.
fontconfig before version 2.13.1 was apparently implicitly not using
subpixel antialiasing. The fontconfig NixOS module deviated from this,
using subpixel antialiasing with `rgb` layout by default. In fontconfig
2.14.1, subpixel antialiasing was inadvertently enabled as the default:
2b6afa02ab
According to https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/337,
that deviates from GNOME/GTK’s defaults, which resulted in apps taking the
settings directly from fontconfig (e.g. Firefox) from diverging from GNOME
programs.
The change was subsequently reverted in 2.14.2, choosing the greyscale
antialiasing explicitly: 030759b74f
Let’s reflect this default setting in the NixOS module.
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
PROXY protocol is a convenient way to carry information about the
originating address/port of a TCP connection across multiple layers of
proxies/NAT, etc.
Currently, it is possible to make use of it in NGINX's NixOS module, but
is painful when we want to enable it "globally".
Technically, this is achieved by reworking the defaultListen options and
the objective is to have a coherent way to specify default listeners in
the current API design.
See `mkDefaultListenVhost` and `defaultListen` for the details.
It adds a safeguard against running a NGINX with no HTTP listeners (e.g.
only PROXY listeners) while asking for ACME certificates over HTTP-01.
An interesting usecase of PROXY protocol is to enable seamless IPv4 to
IPv6 proxy with origin IPv4 address for IPv6-only NGINX servers, it is
demonstrated how to achieve this in the tests, using sniproxy.
Finally, the tests covers:
- NGINX `defaultListen` mechanisms are not broken by these changes;
- NGINX PROXY protocol listeners are working in a final usecase
(sniproxy);
- uses snakeoil TLS certs from ACME setup with wildcard certificates;
In the future, it is desirable to spoof-attack NGINX in this scenario to
ascertain that `set_real_ip_from` and all the layers are working as
intended and preventing any user from setting their origin IP address to
any arbitrary, opening up the NixOS module to bad™ vulnerabilities.
For now, it is quite hard to achieve while being minimalistic about the
tests dependencies.
Adds a new option to the virtualisation modules that enables specifying explicitly named network interfaces in QEMU VMs.
The existing `virtualisation.vlans` option is still supported for cases where the name of the network interface is irrelevant.
