The version 20 of Nextcloud will be EOLed by the end of this month[1].
Since the recommended default (that didn't raise an eval-warning) on
21.05 was Nextcloud 21, this shouldn't affect too many people.
In order to ensure that nobody does a (not working) upgrade across
several major-versions of Nextcloud, I replaced the derivation of
`nextcloud20` with a `throw` that provides instructions how to proceed.
The only case that I consider "risky" is a setup upgraded from 21.05 (or
older) with a `system.stateVersion` <21.11 and with
`services.nextcloud.package` not explicitly declared in its config. To
avoid that, I also left the `else-if` for `stateVersion < 21.03` which
now sets `services.nextcloud.package` to `pkgs.nextcloud20` and thus
leads to an eval-error. This condition can be removed
as soon as 21.05 is EOL because then it's safe to assume that only
21.11. is used as stable release where no Nextcloud <=20 exists that can
lead to such an issue.
It can't be removed earlier because then every `system.stateVersion <
21.11` would lead to `nextcloud21` which is a problem if `nextcloud19`
is still used.
[1] https://docs.nextcloud.com/server/20/admin_manual/release_schedule.html
during the rewrite the checkPasswords=false feature of the old module
was lost. restore it, and with it systems that allow any client to use
any username.
borg is able to process stdin during backups when backing up the special path -,
which can be very useful for backing up things that can be streamed (eg database
dumps, zfs snapshots).
mosquitto needs a lot of attention concerning its config because it doesn't
parse it very well, often ignoring trailing parts of lines, duplicated config
keys, or just looking back way further in the file to associated config keys
with previously defined items than might be expected.
this replaces the mosquitto module completely. we now have a hierarchical config
that flattens out to the mosquitto format (hopefully) without introducing spooky
action at a distance.
/etc/crypttab can contain the _netdev option, which adds crypto devices
to the remote-cryptsetup.target.
remote-cryptsetup.target has a dependency on cryptsetup-pre.target. So
let's add both of them.
Currently, one needs to manually ssh in and invoke `systemctl start
systemd-cryptsetup@<name>.service` to unlock volumes.
After this change, systemd will properly add it to the target, and
assuming remote-cryptsetup.target is pulled in somewhere, you can simply
pass the passphrase by invoking `systemd-tty-ask-password-agent` after
ssh-ing in, without having to manually start these services.
Whether remote-cryptsetup.target should be added to multi-user.target
(as it is on other distros) is part of another discussion - right now
the following snippet will do:
```
systemd.targets.multi-user.wants = [ "remote-cryptsetup.target" ];
```
Makes service more customizeable and makes debuggingin easier through
the use of flags like `--log-debug` or `--dump-settings`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The headless option broke with 7d8b303e3f
because the path /bin/vmware-user-suid-wrapper does not exist in the
headless variant of the open-vm-tools package.
Since the vmblock fuse mount and vmware-user-suid-wrapper seem to only
be used for shared folders and drag and drop, they should not exist in
the vmware-guest module if it is configured as headless.
Move all `virtualisation.libvirtd.qemu*` options to a
`virtualisation.libvirtd.qemu` submodule.
Also for consistency, add `virtualisation.libvirtd.qemu.swtpm.package`
(only new option during this refactor.)
The latest version of Subsonic (6.1.6) does not suport Java SE 9 or later
because it depends on the JAXB APIs. Those are considered to be Java EE
APIs are no longer contained on the default classpath in Java SE 9 and
are completely removed in Java SE 11..
This makes the order of operations the same in dry-activate and a "true"
activate. Also fixes the indentation I messed up and drop a useless
unlink() call (we are already unlinking that file earlier).
The previous logic failed to detect that units were socket-activated
when the socket was stopped before switch-to-configuration was run. This
commit fixes that and also starts the socket in question.
The first FIXME is removed because it doesn't make sense to use
/proc/1/exe since that points to a directory that doesn't have all tools
the activation script needs (like systemd-escape).
The second one is removed because there is already no error handling
(compare with the restart logic where the return code is checked).
This commit changes a lot more that you'd expect but it also adds a lot
of new testing code so nothing breaks in the future. The main change is
that sockets are now restarted when they change. The main reason for
the large amount of changes is the ability of activation scripts to
restart/reload units. This also works for socket-activated units now,
and honors reloadIfChanged and restartIfChanged. The two changes don't
really work without each other so they are done in the one large commit.
The test should show what works now and ensure it will continue to do so
in the future.
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.
The cacert package can now generate p11-kit-compatible output itself,
as well as generating the correct set of outputs for fully-joined
and unbundled "traditional" outputs (in standard PEM and
OpenSSL-compatible formats).
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.
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.
The MariaDB version 10.6 doesn't seem supported with current Nextcloud
versions and the test fails with the following error[1]:
nextcloud # [ 14.950034] nextcloud-setup-start[1001]: Error while trying to initialise the database: An exception occurred while executing a query: SQLSTATE[HY000]: General error: 4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE.
According to a support-thread in upstream's Discourse[2] this is because
of a missing support so far.
Considering that we haven't received any bugreports so far - even though
the issue already exists on master - and the workaround[3] appears to
work fine, an evaluation warning for administrators should be
sufficient.
[1] https://hydra.nixos.org/build/155015223
[2] https://help.nextcloud.com/t/update-to-next-cloud-21-0-2-has-get-an-error/117028/15
[3] setting `innodb_read_only_compressed=0`
Move to a forefront launch of the daemon. Doing so allowed us
to move the service from forking to simple to avoid the
missing pid error log.
Also:
- Make the dbus dependency explicit.
