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"
];
```
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.
The MemoryDenyWriteExecute systemd option is widely known to be
incompatible with nodejs, and causes service crashes as reported in #119687.
Fixes#119687.
This is to address a regression introduced in #131118.
When syncing the first dataset, syncoid expects that the target
dataset doesn't exist to have a clean slate to work with. So during
runtime we'll check if the target dataset does exist and if it doesn't
- delegate the permissions to the parent dataset instead.
But then, on unallow, we do the unallow on both the target and the
parent since the target dataset should have been created at this
point, so the unallow can't know which dataset that got permissions
just by which datasets exists.
This change is strictly functionally equivalent because we're just
lifting the transformation of `source` out of `mapAttrs` to the single point of
use (in escapeShellArgs).
This is also much faster because we can skip a map over all `etc` items.
When restoring a backup, discourse decompresses the backup archive in
the /share/discourse/tmp dir. Before this change, it is linked to /run
which is typically backed by memory, so the backup will fail to
restore if you do not have enough memory on your system to contain the
backup. This has already happened to me on two small forums.
This moves tmp to the StateDirectory /var/lib/discourse/tmp which is
typically backed by disk.
Using builtins.readFile to load upstream defaults is a clever trick, but
it's not allowed in restricted evaluation mode: which means it fails on
Hydra, for example. Besides - in Nixpkgs - depending on derivation as
inputs is considered bad practice and should be avoided.
