This adds yubikey-agent as a package and a nixos module.
On macOS, we use `wrapProgram` to set pinentry_mac as default in PATH;
on Linux we rely on the user to set their preferred pinentry in PATH.
In particular, we use a systemd override to prefix PATH to select a
chosen pinentry program if specified.
On Linux, we need libnotify to provide the notify-send utility for
desktop notifications (such as "Waiting for Yubikey touch...").
This might work on other flavors of unix, but I haven't tested.
We reuse the programs.gnupg.agent.pinentryFlavor option for
yubikey-agent, but in doing so I hit a problem: pinentryFlavour's
default value is specified in a mkDefault, but only conditionally. We
ought to be able to pick up the pinentryFlavour whether or not gpg-agent
is running. As a result, this commit moves the default value to the
definition of programs.gnupg.agent.enable.
This reverts commit d3a26a5ecd.
Using ServiceConfig.ExecStart instead of script lead to the content not
being executed in a shell anymore, which broke the secrets being read
from a file and passed as a command line parameter.
This lets users do sneaky things before systemd starts, and
permanently affect the environment in which systemd runs. For example,
we could start systemd in a non-default network namespace by setting
the systemdExecutable to a wrapper script containing:
#!/bin/sh
ip netns add virtual
touch /var/run/netns/physical
mount -o bind /proc/self/ns/net /var/run/netns/physical
exec ip netns exec virtual systemd
_note: the above example does literally work, but there are unresolved
problems with udev and dhcp._
Also, add some sleep statements in between, which seems to at least feel
like it causes
> WARNING: Device /dev/vda* not initialized in udev database even after waiting 10000000 microseconds.
To occur less frequently.
This eventually still succeeds after some amount of waiting, I suspect
some racyness in the way lvm's udev-triggered scripts trigger other
units.
In the current implementation, there's no possibility to modify the default
parameter for keepalive. This is a number that indicates how frequently
keepalive messages should be sent from the worker to the buildmaster,
expressed in seconds. The default (600) causes a message to be sent to
the buildmaster at least once every 10 minutes.
If the worker is behind a NAT box or stateful firewall, these messages
may help to keep the connection alive: some NAT boxes tend to forget about
a connection if it has not been used in a while. When this happens, the
buildmaster will think that the worker has disappeared, and builds will
time out. Meanwhile the worker will not realize than anything is wrong.
This is required by (among others) Podman to run containers in rootless mode.
Other distributions such as Fedora and Ubuntu already set up these mappings.
The scheme with a start UID/GID offset starting at 100000 and increasing in 65536 increments is copied from Fedora.
Falling back to unversioned `/etc/fonts/conf.d` when versioned one does not exist
is problematic since it only occurs on non-NixOS systems and those are likely
to have a different version of fontconfig. When those versions use incompatible
elements in the config, apps using fontconfig will crash.
Instead, we are now falling back to the in-package `fonts.conf` file that loads
both the versioned global `conf.d` directory and the in-package `conf.d` since using
upstream settings on non-NixOS is preferable to not being able to use apps there.
In fact, we would not even need to link `fonts.conf`, as the in-package `fonts.conf`
will be always used unless someone creates the global one manually (the option is still
retained if one wants to write a custom NixOS module and to avoid unnecessary stat call on NixOS).
Additionally, since the `fonts.conf` will always load `conf.d` from the package, we no longer
need to install them to sytem `/etc` in the module. This needed some mucking with `50-user.conf`
which disables configs in user directories (a good thing IMO, NixOS module will turn it back on)
but otherwise, it is cleaner. The files are still prioritized by their name, regardless of their location.
See https://github.com/NixOS/nixpkgs/pull/73795#issuecomment-634370125 for more information.
The image tag can be specified or generated from the output hash.
Previously, a generated tag could be recovered from the evaluated
image with some string operations.
However, with the introduction of streamLayeredImage, it's not
feasible to compute the generated tag yourself.
With this change, the imageTag attribute is set unconditionally,
for the buildImage, buildLayeredImage, streamLayeredImage functions.
This permits using method_set_hostname but still denies
method_set_static_hostname. As a result DHCP clients can now always set
the transient hostname via the SetHostname method of the D-Bus interface
of systemd-hostnamed (org.freedesktop.hostname1.set-hostname).
If the NixOS option networking.hostName is set to an empty string (or
"localhost") the static hostname (kernel.hostname but NOT /etc/hostname)
will additionally be updated (this is intended).
From "man hostnamectl": The transient hostname is a fallback value
received from network configuration. If a static hostname is set, and is
valid (something other than localhost), then the transient hostname is
not used.
Fix#74847.
Note: It's possible to restrict access to the org.freedesktop.hostname1
interface using Polkit rules.
This was broken in 460c0d6 (PR #90431); now the nixos-unstable channel
should get unblocked.
vcunat modified this commit to use env-var instead of hardcoding /build
Per upstream:
> libvirtd-tcp.socket - the unit file corresponding to the TCP 16509
> port for non-TLS remote access. This socket should not be configured
> to start on boot until the administrator has configured a suitable
> authentication mechanism.
Fixes error
Can't use an undefined value as an ARRAY reference at /nix/store/...-install-grub.pl line 642, <FILE> line 5.
with `/boot/grub/state` being:
```
grub
2.04
no
/dev/sda
/boot
```
I am not sure where the trailing empty line can come from; the script does not
seem to write it. In any case, now we handle that situation as well.
Further, ensure that `extraGrubInstallArgs` defaults to the empty array
if its key is not present in the `jsonState`.
For example, turns the error
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot
into the more useful
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot: Read-only file system
Useful for when you need to build grub modules into your grub kernel
to get a working boot, as shown in the added example.
To store this new value, we switch to more structural JSON approach.
Using one line per value to store in `/boot/grub/state` gets really messy when
the values are arrays, or even worse, can contain newlines (escaping would be
needed). Further, removing a value from the file would get extra messy
(empty lines we'd have to keep for backwards compatibility).
Thus, from now on we use JSON to store all values we'll need in the future.
Without this, systemd-boot does not add an EFI boot entry for itself.
The reason it worked before this fix is because it would fall back to
the default installed \EFI\BOOT\BOOTX64.EFI
`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
boot.loader.grub.device` was hardcoded to `bootDevice`, which is
wrong, because that's the device for `/`, and with `useBootLoader`
the boot loader is not on that device.
This bug probably came into existence because of bad naming;
`virtualisation.bootDevice` has description
"The disk to be used for the root filesystem", which is very confusing;
it should be `.rootDevice` then!
Unfortunately, the description is right and the attribute name is wrong,
so it is not easy to change this without deprecation.
This commit ensures that even if you use `useBootLoader` and
`diskInterface == "scsi"`, the created VM can boot through, and can run
`nixos-rebuild afterwards.
It also adds extra commentary to explain what's going on in this module
in general in relation to `useBootLoader`.
This explanation was contained in the description of
security.initialRootPassword but got lost when it was deprecated
a long ago (f496c3c) and removed.
This option has been deprecated for a long time because is redundant
(users.users.root.initialHashedPassword exists).
Moreover, being of type string, it required to handle the special value
"!" separately, instead of using just `null`.
This explains the
# Allow the user to log in as root without a password.
users.users.root.initialHashedPassword = "";
that the NixOS installer live systems use in
`profiles/installation-device.nix`.
Currently the service doesn't detect if on of the packages is updated
and doesn't restart.
By manually adding a trigger we make sure the service restarts if any of
the involved packages update.
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).
In certain cases, for example when custom OpenLDAP modules are
compiled into the binary, users may want to override the package used
for OpenLDAP.
This is especially common in setups where LDAP is the primary
authentication source, as good password hashing mechanisms need to be
enabled as extra modules.
nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs
The module in this commit adds new options that allows the
integration of an OpenVPN client into the initrd.
This can be used e.g. to remotely unlock LUKS devices.
This commit also adds two tests for `boot.initrd.network.openvpn`.
The first one is a basic test to validate that a failing connection
does not prevent the machine from booting.
The second test validates that this module actually creates a valid
openvpn connection.
For this, it spawns three nodes:
- The client that uses boot.initrd.network.openvpn
- An OpenVPN server that acts as gateway and forwards a port
to the client
- A node that is external to the OpenVPN network
The client connects to the OpenVPN server and spawns a netcat instance
that echos a value to every client.
Afterwards, the external node checks if it receives this value over the
forwarded port on the OpenVPN gateway.
We remove the configFile build flag override in the NixOS module.
Instead of embedding the conf file link to the binaries, we symlink it
to /etc/nsd/nsd.nix, the hardcoded config file location for the
various CLI nsd utilities.
This config file build option override is triggerring a nsd rebuild
for each configuration change. This prevent us to use the nixos cache
in many cases.
Co-authored-by: Erjo <erjo@cocoba.work>
test failed because gnutls-cli does not properly report connection
errors any more, fixed by increasing the debug level for gnutls-cli
Fixes: #84507Closes: #90718
This can be used to explicitly specify a specific dtb file, relative to
the dtb base.
Update the generic-extlinux-compatible module to make use of this option.
Some bootloaders might not properly detect the model.
If the specific model is known by configuration, provide a way to
explicitly point to a specific dtb in the extlinux.conf.
This option exposes the builder command used to populate an image,
honoring all options except the -c <path-to-default-configuration>
argument.
Useful to have for sdImage.populateRootCommands.
Special care needs to be taken w.r.t cross - the populate command runs
on the host platform, the activation script on the build platform (so
the builders differ)
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.
Turns out, on smaller images (~800MiB uncompressed sdcard image size),
the current fudge factor is way too small to even get the system to the
phase where it can resize itself.
I first tried with 1.05, but it wasn't enough.
Merges https://github.com/NixOS/nixos-hardware into nixpkgs.
This will give better discoverability, and considering the low
turnover (less than 100 commits in the last year and only 350 total)
it won’t make any dent on the size of nixpkgs.
We have a monorepo, let’s use it
It is going to be merged into nixpkgs, under `nixos/hardware`.
This will give better discoverability, and considering the low
turnover (less than 100 commits in the last year and only 350 total)
it won’t make any dent on the size of nixpkgs.
We have a monorepo, let’s use it.
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
This option exposes the prefconfigured nextcloud-occ
program. nextcloud-occ can then be used in other systemd services or
added in environment.systemPackages.
The nextcloud test shows how it can be add in
environment.systemPackages.
