The toplevel derivations of systems that have `networking.hostName`
set to `""` (because they want their hostname to be set by DHCP) used
to be all named
`nixos-system-unnamed-${config.system.nixos.label}`.
This makes them hard to distinguish.
A similar problem existed in NixOS tests where `vmName` is used in the
`testScript` to refer to the VM. It defaulted to the
`networking.hostName` which when set to `""` won't allow you to refer
to the machine from the `testScript`.
This commit makes the `system.name` configurable. It still defaults to:
```
if config.networking.hostName == ""
then "unnamed"
else config.networking.hostName;
```
but in case `networking.hostName` needs to be to `""` the
`system.name` can be set to a distinguishable name.
The resilio module places the directoryRoot configuration in the webui
section. However, the generated configuration fails on the current
version of Resilio Sync with:
Invalid key context: 'directory_root' must be in global config section
This change places this key in the global configuration section to
solve this error.
Build error introduced in fe7053f75a:
parser error : Opening and ending tag mismatch: commmand line 6139 and command
escription><para>Base64 preshared key generated by <commmand>wg genpsk</command>
^
Writing "command" with only two "m" fixes building the NixOS manual.
Signed-off-by: aszlig <aszlig@nix.build>
> WARNING: PID file creation will be removed in Sidekiq 6.0, see #4045.
Please use a proper process supervisor to start and manage your
services
Since NixOS uses a proper process supervisor AND does not use the PID
file anywhere, we can just drop it to be upwards compatible and fix that
warning.
This is analogous to #70447.
With security.lockKernelModules=true, docker commands result in the following
error without at least loading veth:
$ docker run hello-world
/nix/store/mr50kaan2vs4gc40ymwncb2vci25aq7z-docker-19.03.2/libexec/docker/docker: Error response from daemon: failed to create endpoint epic_kare on network bridge: failed to add the host (veth8b381f3) <=> sandbox (veth348e197) pair interfaces: operation not supported.
ERRO[0003] error waiting for container: context canceled
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._
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.
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.
