This allows us to continue to have the automatically sized image attempt
to build on Hydra, which should give us a good indication of when we've
got this fixed.
For reasons we haven't been able to work out, the aarch64 EC2 image now
regularly exceeds the output image size on hydra.nixos.org. As a
workaround, set this back to being statically sized again.
The other images do seem to build - it's just a case of the EC2 image
now being too large (occasionally non-determinstically).
This is supeer useful to allow the normal sd-image code to be used by
someone who wants to setup multiple partitions with a sd-image.
Currently I'm manually copying the sd-image file and modifying it
instead.
This ensures that newly created secrets will have the permissions
`0640`. With this change it's ensured that no sensitive information will
be word-readable at any time.
Related to #121293.
Strictly speaking this is a breaking change since each new directory
(including data-files) aren't world-readable anymore, but actually these
shouldn't be, unless there's a good reason for it.
This is what is still exposed, and it allows me to control my lamps from
within home-assistant.
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ DeviceAllow= Service has a device ACL with some special devices 0.1
✗ IPAddressDeny= Service does not define an IP address allow list 0.2
✗ PrivateDevices= Service potentially has access to hardware devices 0.2
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
✗ SupplementaryGroups= Service runs with supplementary groups 0.1
✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1
→ Overall exposure level for zigbee2mqtt.service: 1.3 OK 🙂
Until now, the `touch + chmod 600 + write` approach made it possible for
an unprivileged local user read the private key file, by opening
the file after the touch, before the read permissions are restricted.
This was only the case if `generatePrivateKeyFile = true` and the parent
directory of `privateKeyFile` already existed and was readable.
This commit fixes it by using `umask`, which ensures kernel-side that
the `touch` creates the file with the correct permissions atomically.
This commit also:
* Removes `mkdir --mode 0644 -p "${dirOf values.privateKeyFile}"`
because setting permissions `drw-r--r--` ("nobody can enter that dir")
is awkward. `drwx------` would perhaps make sense, like for `.ssh`.
However, setting the permissions on the private key file is enough,
and likely better, because `privateKeyFile` is about that file
specifically and no docs suggest that there's something special
about its parent dir.
* Removes the `chmod 0400 "${values.privateKeyFile}"`
because there isn't really a point in removing write access from
the owner of the private key.
- Set an explicit umask that allows u+rwx and g+r.
- Adds `ProtectControlGroups` and `ProtectKernelLogs`, there should be
no need to access either.
- Adds `ProtectClock` to prevent write-access to the system clock.
- `ProtectProc` hides processes from other users within the /proc
filesystem and `ProcSubSet` hides all files/directories unrelated to
the process management of the units process.
- Sets `RemoveIPC`, as there is no SysV or POSIX IPC within nginx that I
know of.
- Restricts the creation of arbitrary namespaces
- Adds a reasonable `SystemCallFilter` preventing calls to @privileged,
@obsolete and others.
And finally applies some sorting based on the order these options appear
in systemd.exec(5).
See #119615 for more details. The aarch64-linux test failed with
"qemu-system-aarch64: Virtio VGA not available" so I've restricted the
test to x86_64-linux (the virtio paravirtualized 3D graphics driver is
likely only available on very few platforms).
The result still looks far from ideal but at least it gets recognized
now. "-fa Monospace" is required to switch to a font from the FreeType
library so that "-fs 24" works.
Note: Using linuxPackages_latest is not required anymore.
On reboots and shutdowns promtail blocks for at least 90 seconds,
because it would still try to deliver log messages for loki, which isn't
possible when the network has already gone down.
Upstreams example unit also uses a ten seconds timeout, something which
has worked pretty well for me as well.
systemd-nspawn can react to SIGTERM and send a shutdown signal to the container
init process. use that instead of going through dbus and machined to request
nspawn sending the signal, since during host shutdown machined or dbus may have
gone away by the point a container unit is stopped.
to solve the issue that a container that is still starting cannot be stopped
cleanly we must also handle this signal in containerInit/stage-2.
This reverts commit d6e0d38b84.
We need shorter secrets to continue working, since the earlier
recommendation was too short and there's no way to rotate the them.
The upstream recommended minimum length for db_key_base is 30 bytes,
which our option descriptions repeated. Recently, however, upstream
has, in many places, moved to using aes-256-gcm, which requires a key
of exactly 32 bytes. To allow for shorter keys, the upstream code pads
the key in some places. However, in many others, it just truncates the
key if it's too long, leaving it too short if it was to begin
with. This adds a patch that fixes this and updates the descriptions
to recommend a key of at least 32 characters.
See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53602
This version contains a vulnerability[1], and isn't maintained. The
original reason to have two jellyfin versions was to allow end-users to
backup the database before the layout was upgraded, but these backups
should be done periodically.
[1]: <https://nvd.nist.gov/vuln/detail/CVE-2021-21402>
Work around missing /dev files inside runInLinuxVM by creating a
symlink before calling nixos-enter.
This fixes https://github.com/NixOS/nixpkgs/issues/93381.
I ran into this issue when trying to create a VMware image that boots from EFI.
Thanks @colemickens for reporting this and @danielfullmer for fixing the same thing in in qemu-vm.nix (37676e77cb) and explaining what the issue was.
This ensures the following gptfdisk warning won't happen:
```
Warning: File size is not a multiple of 512 bytes! Misbehavior is likely!
```
Additionally, helps towards aligning the partition to be more optimal
for the underlying storage.
It is actually impossible to align for the actual underlying storage
optimally because we don't know what the block device will be!
But aligning on 1MiB should help.
Current module add backups forever, with no way to prune old ones.
Add an option to remove backups after n full backups or after some
amount of time.
Also run duplicity cleanup to clean unused files in case some previous
backup was improperly interrupted.
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
This is a bit of a thorny issue. See, the actual `diskSize` variable is
for the *total* disk size, not for the filesystem!
The automatic numbers are meant to compute the *filesystem* required
space. So we have to add any other reserved space!
We have different requirements for reserved space. E.g. there could be
none (when it's actually a filesystem image). There could also be 1MiB
for alignment for an MBR image, legacy+gpt needs 2MiB, then GPT with an
ESP ("bootSize") needs to take the boot partition and GPT size into
account too!
Though luckily(?) for this latter situation we can cheat! As noted in the
change, `bootSize` is NOT the boot partition size. It is actually the
offset where the target filesystem starts.
Reserved space includes:
- inodes space in use (2 blocks per)
- about 5.2% of the space
The 5.2% reserved space was computed empirically when working on a
previous EXT4 image builder. It seems to stabilize around 5% even for
much larger filesystems.
On some filesystems, `du` without `--apparent-size` will not give the
actual size for a file. Using `--apparent-size` will give us the actual
file size.
Though, this is not actually correct still. 1000 × 1 bytes is not 1000
bytes. It is 1000 × ceil(filesize/blockSize)*blockSize.
So instead of adding up the actual file sizes. We are adding up the
block sizes.
Note that this also changes the builder to work with *bytes*, rather
than with any other units. Doing maths on bytes is less likely to go
awry than doing it on other units.
some ban actions need additional packages (eg ipset). since actions can be
provided by the user we need something general that's easy to configure.
we could also enable ipset regardless of the actual configuration of the system
if the iptables firewall is in use (like sshguard does), but that seems very
clumsy and wouldn't easily solve the binary-not-found problems other actions may
also have.
it's not possible to set a different default maxretry value in the DEFAULT jail
because the module already does so. expose the maxretry option to the
configuration to remedy this. (we can't really remove it entirely because
fail2ban defaults to 5)
As a temporary workaround for #120473 while the image builder is patched
to correctly look up disk sizes, partially revert
f3aa040bcb for EC2 disk images only.
We retain the type allowing "auto" but set the default back to the
previous value.
When performing OCR, some of the Tesseract settings perform better than
others on a variety of different workloads, but they mostly take
~negligible incremental time to run compared to the overhead of running
the ImageMagick filters.
After this commit, we try using all three of the current Tesseract
models (classic, LSTM, and classic+LSTM) to generate output text. This
fixes chromium-90's tests at release-20.09, and should make cases where
you're looking for *specific* text better, with the tradeoff of running
Tesseract multiple times.
To make it sensible to cherrypick this into release-20.09, this doesn't
change the existing API surface for the test driver. In particular,
get_screen_text continues to have the existing behaviour.
backends changing shouldn't be very likely, but services may well change. we
should restart sshguard from nixos-rebuild instead of merely plopping down a new
config file and waiting for the user to restart sshguard.
First because IFD (import-from-derivation) is not allowed on hydra.nixos.org,
and second because without https://github.com/NixOS/hydra/pull/825
hydra-eval-jobs crashes instead of skipping aggregated jobs which fail
(here because they required an IFD).
Rather than relying on carefully avoiding touching the 9P-mounted
/nix/store, we instead install a small NixOS system, similar to
the installer tests, and boot from that.
This avoids the various pitfalls associated with trying to unsuspend
properly and trades off a bunch of boilerplate for what will hopefully
be a more reliable test.
Additionally, this test now actually tests booting the system using a
bootloader, rather than the previous method of just booting the kernel
directly.
There is no need for a separate unit. Simplify the NixOS module by adding the shell code to preStart of the main unit, where the other initialization code already is.
Things will get quite broken if an /etc/passwd entry contains a
colon (which terminates a field), or a newline (which terminates a
record). I know because I just accidentally made a user whose home
directory path contained a newline!
So let's make sure that can't happen.
The buildkite agent supports multiple tags with the same key. This
functionality is used to have a [single agent listen on multiple
queues](https://buildkite.com/docs/agent/v3/queues#setting-an-agents-queue).
However, having the tags be of type `attrsOf str` means that
we cannot suport this use case. This commit modifies the type
of tags to be `attrsOf (either str (listOf str))` where the list
is expanded into multiple tags with the same key.
Example:
```
{tags = {queue = ["default", "testing"];};}
```
generates
```
tags="queue=default,queue=testing"
```
in the buildkite agent configuration.
Upstream repositories do no longer exists. There has been no release in
a while. - Not a good combination for a network daemon running as root
in C that parses network packets...
A too low number of inotify user instances causes similar problems as
max_user_watches. Without this, my workstation keeps running into things
like this:
$ sudo systemctl restart display-manager.service
Failed to allocate directory watch: Too many open files
aa22be179a dropped the backend setting
which was used in the test, breaking evaluation of the test in the
process. Kind of defeats the purpose of a test if it isn't executed
before merging a change to a module…
Remove old CUDA toolkits (and corresponding CuDNN versions).
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Fixes#107131.
* nixos/nginx: add upstreams examples
I am not fully sure if they are fully correct but they deployed the right syntax.
* nixos/nginx: use literal example
* Update nixos/modules/services/web-servers/nginx/default.nix
* Update nixos/modules/services/web-servers/nginx/default.nix
Bash doesn't handle subshell errors properly if the result is used as
input to a command. To cause the services to fail when the files can't
be read, we need to assign the value to a variable, then export it
separately.
For a while now it's possible to specify an additional config file in
`wpa_supplicant`[1]. In contrast to the file specified via `-c` this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of `wpa_supplicant` is that
if the `SAVE_CONFIG` command is invoked (e.g. via `wpa_cli`), all known
networks will be written to `/etc/wpa_supplicant.conf` and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:
* The `networking.wireless`-module now uses `-I` for declarative config,
so the user-controlled mode can be used along with the
`networks`-option.
* I added an `ro`-field to the `ssid`-struct in the
`wpa_supplicant`-sources. This will be set to `1` for each network
specified in the config passed via `-I`.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.
[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
With the config suggested in the module docs both Mailman core and
Hyperkitty are running, but Mailman core can not connect to Hyperkitty,
since the default hyperkitty.baseUrl is not set up by the module.
This adds a http listener to the uwsgi config and changes the default
hyperkitty.baseUrl to connect to this http listener.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
* Make it clearer what code comments apply to
* Fix the state directory (this was changed in the update)
* Add m1cr0man as a maintaner
Co-authored-by: Lucas Savva <lucas@m1cr0man.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Pass the args from kernel-generic.nix's top-level to the individual
tests. Makes `nix-build -A nixosTests.kernel-generic.<attr>` and
`nix-build nixos/tests/kernel-generic.nix -A <attr>` work as expected.
Upstream has been providing a very thoroughly designed set of systemd units,
udev and polkit rules. With these the brltty daemon is activated
asynchronously via udev, runs as a dedicated user with runtime and state
directories set up using systemd-tmpfiles.
This is much better than the current unit, which runs a single instance
as root and pulls in systemd-udev-settle to wait for the hardware.
The haskellPackages.spacecookie derivation also includes a library and
thus a lot of propagated haskell dependencies. The top-level attribute
uses haskell.lib.justStaticExecutables and therefore only the
executable. This should reduce the runtime closure users have to
download considerably if they only want the server.
* Move `hostname` and `root` into a settings submodule with a freeform
type, allowing users to also use options not known to the NixOS
service. Compatibility with a warning for the renamed options is also
trivial to achieve.
* `port` stays where it is as we don't actually use the `port` option of
spacecookie to set up the socket, but only to inform spacecookie about
the port we have set in the `systemd.socket` file, this makes more
sense. Additionally the configuration of the listening port and
address change in the next spacecookie release — we can dodge this
issue altogether by doing our own thing, but I'm interested to hear
opinions on this.
To ensure that this is not misconfigured, we add an assertion for
the port option.
* Add an assertion for `user` in settings which has no effect the way
we are starting spacecookie as it wouldn't be able to call setuid.
The message also explains how a specific user can be used with
spacecookie if desired.
This configuration option reflects a new feature from the unreleased
spacecookie version allowing to customize the address spacecookie will
listen on (e. g. "::1" to bind on link-local addresses only). We will
not use this feature in the future, since the configuration option of
spacecookie naturally only has an effect if we don't use socket
activation (and spacecookie sets up its own socket), but having the same
functionality in the service seems like a good idea.
We can luckily emulate this behavior with socket activation as well.
This allows to change the derivation to use for the spacecookie server
binary. We probably should also use justStaticExecutables by default to
reduce the runtime closure of the service.
* Use proper gopher urls
* The client vms name is also controlled in a single place now
* fileContent holds the precise file content now
* wait for the spacecookie unit instead of the port
* avoids sending an empty request
* since spacecookie is a notify service it only is fully started when
the socket has been set up.
* github-runner: init at 2.277.1
* nixos/github-runner: initial version
* nixos/github-runner: add warning if tokenFile in Nix store
* github-runner: don't accept unexpected attrs
* github-runner: formatting nits
* github-runner: add pre and post hooks to checkPhase
* nixos/github-runner: update ExecStartPre= comment
* nixos/github-runner: adapt tokenFile option description
Also note that not only a change to the option value will trigger a
reconfiguration but also modifications to the file's content.
* nixos/github-runner: remove mkDefault for DynamicUser=
* nixos/github-runner: create a parent for systemd dirs
Adds a parent directory "github-runner/" to all of the systemd lifecycle
directories StateDirectory=, RuntimeDirectory= and LogDirectory=.
Doing this has two motivations:
1. Something like this would required if we want to support multiple
runners configurations. Please note that this is already possible
using NixOS containers.
2. Having an additional parent directory makes it easier to remap
any of the directories. Without a parent, systemd is going to
complain if, for example, the given StateDirectory= is a symlink.
* nixos/github-runner: use specifier to get abs runtime path
* nixos/github-runner: use hostname as default for option `name`
Until now, the runner registration did not set the `--name` argument if
the configuration option was `null`, the default for the option.
According to GitHub's documentation, this instructs the registration
script to use the machine's hostname.
This commit causes the registration to always pass the `--name` argument
to the runner configuration script. The option now defaults to
`networking.hostName` which should be always set on NixOS.
This change becomes necessary as the systemd service name includes the
name of the runner since fcfa809 and, hence, expects it to be set. Thus,
an unset `name` option leads to an error.
* nixos/github-runner: use types.str for `name` option
Forcing a `name` option to comply with a pattern which could also be
used as a hostname is probably not required by GitHub.
* nixos/github-runner: pass dir paths explicitly for ExecStartPre=
* nixos/github-runner: update variable and script naming
* nixos/github-runner: let systemd choose the user/group
User and group naming restrictions are a complex topic [1] that I don't
even want to touch. Let systemd figure out the username and group and
reference it in our scripts through the USER environment variable.
[1] https://systemd.io/USER_NAMES/
* Revert "nixos/github-runner: use types.str for `name` option"
The escaping applied to the subdirectory paths given to StateDirectory=,
RuntimeDirectory= and LogsDirectory= apparently doesn't use the same
strategy that is used to escape unit names (cf. systemd-escape(1)). This
makes it unreasonably hard to construct reliable paths which work for
StateDirectory=/RuntimeDirectory=/LogsDirectory= and ExecStartPre=.
Against this background, I decided to (re-)apply restrictions to the
name a user might give for the GitHub runner. The pattern for
`networking.hostName` seems like a reasonable choice, also as its value
is the default if the `name` option isn't set.
This reverts commit 193ac67ba3.
* nixos/github-runner: use types.path for `tokenFile` option
* nixos/github-runner: escape options used as shell arguments
* nixos/github-runner: wait for network-online.target
* github-runner: ignore additional online tests
This should reduce memory fragmentation drastically and is recommended
by both the Puma and the Sidekiq author. It's also the default value
for Ruby deployments on Heroku.
Although the quotes here aren't necessary, they may be if a user cargo-cults this example with a database name with hyphens (or other "unusual" characters).
At the moment, it's not possible to override the libvirtd package used
without supplying a nixpkgs overlay. Adding a package option makes
libvirtd more consistent and allows enabling e.g. ceph and iSCSI support
more easily.
Xen is now enabled unconditionally on kernels that support it, so the
xen_dom0 feature doesn't do anything. The isXen attribute will now
produce a deprecation warning and unconditionally return true.
Passing in a custom value for isXen is no longer supported.
The upstream pipewire config is written in an almost, but not quite
JSON format. The parser accepts standard JSON, though, so we don't
need to write our file in the same nonstandard version.
The typing for all config options is changed from `types.attrs`, which
behaves poorly when the option is set from multiple locations, to the
formats.json-type.
Also, rewrite some very long one-liners for improved readability.
