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.
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.
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 193ac67ba337990c22126da24a775c497dbc7e7d.
* 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).
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.
Fixes#112834 where incorrect documentation of options was reported.
customIni used to replace the entire default configuration while the
new settings option is merged in with the default configuration
and still allows overriding options when needed.
Since the upstream graylogctl script will prefer finding its java
executable based on JAVA_HOME, we now set this instead of PATH in
order to allow it to find the JRE. By setting it conditionally on it
not already being set, we allow selecting a different JRE at runtime.
We also explicitly use openjdk11, which supports the
UseConcMarkSweepGC option which graylog insists on using.
This allows for shared hledger installations, where the web interface is
available via network and multiple user share a SSH access to the
hledger user.
Also added `--serve` to the CLI options, as hledger-web tries to open a
webbrowser otherwise:
hledger-web: xdg-open: rawSystem: runInteractiveProcess: exec: does not
exist (No such file or directory)
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
Maximum password length per cjdns code is somehwhere less than that, see
ecd01e7681/client/AdminClient.c (L80)
Currently we generate 96 char long passwords that don't work
This changes it so password length is just 32 chars long
