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>
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 🙂
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)
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).
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
* 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>
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.
* 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.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
