allows configuration of foo-over-udp decapsulation endpoints. sadly networkd
seems to lack the features necessary to support local and peer address
configuration, so those are only supported when using scripted configuration.
9fea6d4c85 broke rtl_433-exporter by
introducing several hardening options which do not play well with
rtl_433 requiring writing to USB. More precisely, rtl_433 requires
(a) AF_NETLINK to configure the radio; (b) access to the USB device,
but PrivateDevices=true hides them; (c) rw access to the USB device,
but DeviceAllow= block-lists everything.
This commit was tested on real hardware with a standard NixOS setup.
Checks whether all spaces are inside double quotes, thus ensuring that one
string parses as no more than one kernel param.
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
unifi does not shut down properly when stopped via systemd (it always exits with
SIGTERM exit status) because systemd wants stop commands to not exit before the
main command is gone and unifi does not comply. the easiest way around this is
to have systemd send an ignored signal after the stop command has exited.
unifi may still throw exceptions during shutdown, but it *does* exit cleanly as
far as systemd is concerned now.
The timex collector (enabled by default) needs the
adjtimex syscall, which was disabled by
9fea6d4c85.
So allow it unless the timex collector is disabled.
The systemd collector needs AF_UNIX to talk to
/var/run/dbus/system_bus_socket, which was broken
with 9fea6d4c85.
This commit allows AF_UNIX when needed.
In case of a power loss shortly after first boot,
the host keys gernerated by ssh-keygen could exist
in the file system but have zero size, preventing
sshd from starting up.
This commit changes the behaviour to generate host
keys if the file either does not exist or has zero
size, fixing the problem on the next boot.
Thanks to @SuperSandro2000 for figuring this out.
On some systems bootctl cannot write the `LoaderSystemToken` EFI variable
during installation, which results in a failure to install the boot
loader. Upstream provides a flag (--graceful) to ignore such write failures -
this change exposes it as a configuration option.
As the exact semantics of this option appear to be somewhat volatile it
should be used only if systemd-boot otherwise fails to install.
A few minor changes to get #119638 - nextcloud: add option to set
datadir and extensions - ready:
* `cfg.datadir` now gets `cfg.home` as default to make the type
non-nullable.
* Enhanced the `basic` test to check the behavior with a custom datadir
that's not `/var/lib/nextcloud`.
* Fix hashes for apps in option example.
* Simplify if/else for `appstoreenable` in override config.
* Simplify a few `mapAttrsToList`-expressions in
`nextcloud-setup.service`.
Note the appstoreEnable which will prevent nextcloud form updating
nix-managed apps. This is needed because nextcloud will store an other
version of the app in /var/lib/nextcloud/store-apps and it will
no longer be manageable.
The multipath-tools package had existed in Nixpkgs for some time but
without a nixos module to configure/drive it. This module provides
attributes to drive the majority of multipath configuration options
and is being successfully used in stage-1 and stage-2 boot to mount
/nix from a multipath-serviced iSCSI volume.
Credit goes to @grahamc for early contributions to the module and
authoring the NixOS module test.
Don't worry, it's is true by default. But I think this is important to
have because NixOS indeed shouldn't need Nix at run time when the
installation is not being modified, and now we can verify that.
NixOS images that cannot "self-modify" are a legitamate
use-case that this supports more minimally. One should be able to e.g. do a
sshfs mount and use `nixos-install` to modify them remotely, or just
discard them and build fresh ones if they are run VMs or something.
The next step would be to make generations optional, allowing just
baking `/etc` and friends rather than using activation scripts. But
that's more involved so I'm leaving it out.
I realized quite recently that running a test VM - as documented in the
manual - like
QEMU_NET_OPTS='hostfwd=tcp::8080-:80' ./result/bin/nixos-run-vms
doesn't work anymore on `master`. After bisecting I realized that the
introduction of a forward-port option[1] is the problem since it adds a
trailing comma even if no forwarding options are specified via
`virtualisation.forwardPorts`. In that case, the networking options
would look like `-netdev user,id=user.0,,hostfwd=tcp::8080-:80' which
confused QEMU and thus the VM refused to start.
Now, the trailing comma is only added if additional port forwards are
specified declaratively.
[1] b8bfc81d5b
The `$(</path/to/file)`-expansion appears verbatim in the cmdline of
`nextcloud-occ` which means that an unprivileged user could find
sensitive values (i.e. admin password & database password) by monitoring
`/proc/<pid>/cmdline`.
Now, these values don't appear in a command line anymore, but will be
passed as environment variables to `nextcloud-occ`.
* Linkify documentation about objectstore-feature rather than only
mentioning it.
* Use `<literal>` where it makes sense.
* Remove unnecessary `Whether to load` from `enableImagemagick` because
`mkEnableOption` already prepends `Whether to enable` to the given
description.
NixOS should be able to support the Nintendo Switch Pro controller for
steam and non-steam at the same time. Currently there are two mutually
exclusive ways to support the Pro Controller: Steam and `hid-nintendo`.
Unfortunately these don't work together, but there's a workaround in
newer versions of `joycond` (described [here](https://wiki.archlinux.org/title/Gamepad#Using_hid-nintendo_pro_controller_with_Steam_Games_(with_joycond))). To use this
workaround `hid-nintendo` and `joycond` need to be updated, and the
systemd and udev configuration needs to be made available in NixOS.
We have no usecase for manually/selectively starting or stopping VLANs
in integration tests.
By starting and stopping the VLANs with the constructor and destructor
of VLAN objects, we remove the obligation and complexity to maintain
network lifetime separately.
This commit encapsulates the involved domain into classes and
defines explicit and typed arguments where untyped dicts where used.
It preserves backwards compatibility through legacy wrappers.
* less: enable by default and set LESS=-R via lesskey
* since we set PAGER=less, programs.less.enable should default to
true.
* some programs, notably git, set a custom LESS environment if none is
present. using the lesskey mechanism to set LESS=-R lets such
programs continue to run less as they see fit.
This reverts commit 0e7b4e60a8.
* less: remove use of deprecated lesskey binary format
* less: enable in environment.nix rather than less.nix
per discussion in #139988
This module allows setting global configuration for htop in /etc/htoprc,
for example to disable showing userland threads by default
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
This is the first version of the mautrix-facebook module. Due to lack of secret support on NixOS as well as the requirement of a homeserver domain it requires some setup. For completeness here is my working config using NixOps secrets:
```nix
deployment.keys."mautrix-facebook-config.env" = {
text = ''
MAUTRIX_FACEBOOK_APPSERVICE_AS_TOKEN=${secrets.as_token}
MAUTRIX_FACEBOOK_APPSERVICE_HS_TOKEN=${secrets.hs_token}
'';
destDir = "/var/keys";
};
deployment.keys."mautrix-facebook-registration.yaml" = {
text = builtins.toJSON config.services.mautrix-facebook.registrationData;
destDir = "/var/keys";
user = "matrix-synapse";
};
users.users.matrix-synapse.extraGroups = ["keys"];
systemd.services.matrix-synapse.after = ["keys.service"];
systemd.services.matrix-synapse.wants = ["keys.service"];
services.mautrix-facebook = {
enable = true;
settings = {
homeserver.domain = "bots.kevincox.ca";
bridge = {
displayname_template = "{displayname}";
permissions = {
"@kevincox:matrix.org" = "admin";
};
};
};
environmentFile = "/var/keys/mautrix-facebook-config.env";
registrationData = {
as_token = secrets.as_token;
hs_token = secrets.hs_token;
};
};
systemd.services.mautrix-facebook = rec {
wants = ["keys.target"];
after = wants;
};
services.matrix-synapse.app_service_config_files = [
"/var/keys/mautrix-facebook-registration.yaml"
];
```
Since 7a10478ea7, all /var except
/var/lib/acme gets mounted in a read-only fashion. This behavior
breaks the existing acme deployments having a webroot set outside of
/var/lib/acme.
Collecting the webroots and adding them to the paths read/write
mounted to the systemd service runtime tree.
Fixes#139310
Previously, the `nix_read_pwd` function was only used for reading the
`dbpassFile`, however it has since been refactored to handle reading
other secret files too. This fixes the message of the exception that is
thrown in the case that the file is not present so that it no longer
refers specifically to the `dbpass` file.
Removes the submodule in favour of using an attrset.
Also:
- Makes better use of nix's laziness in config expansion.
- Makes use of `boolToString` where applicable.
We should discourage users from adding secrets in a way that allows for
them to end up in the globally readable `/nix/store`. Users should use
the `objectstore.s3.secretFile` option instead.
This allows to declaratively configure an S3 class object storage as the
primary storage for the nextcloud service. Previously, this could only
be achieved by manually editing the `config.php`.
I've started testing this today with my own digitalocean nextcloud
instance, which now points to my digitalocean S3-compatible "Space" and
all appears to be working smoothly.
My motivation for this change is my recent discovery of how much cheaper
some S3-compatible object storage options are compared to digitalocean's
"Volume" options.
Implementation follows the "Simple Storage Service" instructions here:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/primary_storage.html
I have neglected to implement a submodule for the OpenStack Swift
object storage as I don't personally have a use case for it or a method
to test it, however the new `nextcloud.objectstore.s3` submodule should
act as a useful guide for anyone who does wish to implement it.
