Closes#320381
Installation with a custom dbtableprefix is not allowed anymore for a
while[1] and we shouldn't advertise it as such.
The option is deprecated for now since I'm not sure if there are some
weird corner-cases where removing the option directly would break
existing installations from before <20 with a custom dbtableprefix. The
migration-path for such a case is as follows:
* Check if /var/lib/nextcloud/config/config.php has the correct
dbtableprefix set and if not, take care of it.
* Remove `dbtableprefix` from the NixOS configuration. It's effectively
state anyways.
After a bit of time to switch (perhaps after the next release
branchoff), the option can be removed.
[1] https://github.com/nextcloud/server/issues/24836
These messages should be able to be printed in all cases. In particular, trying to coerce a `null` to a string is an error unless passed through `toString`.
Set PATH order correctly for systemd user services (see NixOS/nixpkgs#320734
Signed-off-by: Reputable2722 <153411261+Reputable2772@users.noreply.github.com>
- rename hardware.opengl to hardware.graphics
- remove hardware.opengl.driSupport, which does nothing
- remove hardware.opengl.setLdLibraryPath, which should never be done
- rename hardware.opengl.driSupport32Bit to hardware.graphics.enable32Bit
- lost of small docs / formatting cleanups
Set `StateDirectory=firefly-iii` instead of trying to derive it from
`dataDir` + add `dataDir` to `ReadWritePaths`, allowing `dataDir` to be
set to full paths outside of `/var/lib`.
Allows users to refer to `config.programs.ydotool.group` rather than
hard-coding "ydotool".
Allows users to override the group name for whatever reason.
This closes#317013.
Co-authored-by: Cosima Neidahl <opna2608@protonmail.com>
This was meant to make amazon-ssm-agent work "out of the box" on non-NixOS
systems but the feature never really worked.
The problem is that amazon-ssm-agent looks for the files "amazon-ssm-agent.json"
and "seelog.xml" but the files in the package are named
"amazon-ssm-agent.json.template" and "seelog.xml.template". So even with
this overrideEtc = true it would not be able to find the config.
E.g. you'd get an error like
Error occurred fetching the seelog config file path: open /nix/store/pyfxjr0i0hszcj9b6fqly6344zf9zhcb-amazon-ssm-agent-3.3.484.0/etc/amazon/ssm/seelog.xml: no such file or directory
on startup.
Removing this parameter from the from the package doesn't break things as it didn't work in the first place.
The tests had very much duplication and some if it was even wrong! For
instance, `withRcloneEnv` in the MySQL test didn't have the `"$@"` at
the bottom to execute commands passed to it. Because of that, the MySQL
testcase never checked whether files can be uploaded.
Since tests are just another module-system I decided to abstract away
common things by using it:
* Define a base module with
* an empty `client` node and a `nextcloud` node with defaults
shared among all tests.
* rclone scripts that are used by all tests.
* a `testScript` checking upload/download. Additional checks can be
added via `test-helpers.extraTests`.
* Make common information such as admin user & password shared via
options.
Also, changed the following things:
* The `name` of the final derivation also includes the Nextcloud major
it was tested against.
* Improved the objecstore test by making sure the file was actually
uploaded into the bucket.
config.boot.loader.grub.device is just an alias that gets assigned to config.boot.loader.grub.devices.
If config.boot.loader.grub.device is set to null, it will fail with the following error
as described in https://github.com/nix-community/nixos-generators/issues/339
* Make sure `withRcloneEnv` actually invokes the command it gets as
`argv`. Until no, nothing was uploaded. This mistake was copied from
the MySQL test that appears to have the same issue (will be addressed
in the next commit).
* Test upload/download through with rclone once to see if Nextcloud
interaction with S3 works fine.
* Make sure we actually have something in the bucket (until now with an
`ls` and no real check, will do some larger cleanups and make this
better in the next commit).
* Use actual AWS-style access keys.
Allow users to disable the shadow authentication suite.
My primary motivation is to reduce the attack surface via setuid
binaries, which shadow understandably introduces many. I realised,
however, that I don't use any of these.
The test demonstrates login working without needing the shadow suite.
We can expose the PLAT prefix to the client via DNS64 so clatd is able
to determine the prefix dynamically. We can also test that some
systemd-networkd PREF64 settings work as expected when exposed on the
router.
This follows 6ee84bcda0.
Here I prefer a simple mention in the release notes instead of some
automatic migration, which could interfere with all the other changes
already potentially requiring some admin interventions.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
This adds a NixOS module for Grafana Alloy.
I started from the grafana-agent one but dropped all settings and config
management whatsoever.
Grafana Alloy uses its own Alloy config format (similar to HCL), which
is not really possible to express in Nix.
Simply pointing to a path in `/etc`, and leaving it up to the user to configure
it via `environment.etc` allows the user to arrange config files however
it makes most sense for them.
The module, systemd unit etc is called "alloy", not "grafana-alloy" to
follow the way it's packaged on other distros, to follow POLA.
- Introduce more possible options by using the krb format generator.
- Enforce package choice is using a correct package.
- Use meta attribute to decide implementation, allows for overriding the
package.
- Make necessary changes to the format, to allow for multiple ACL files in
heimdal.
- Add systemd target and slice for both implementations.
- Move state to `/var/lib`
- Add documentation
auto-cpufreq is similar to tlp in that it shouldn't be run with
power-profiles-daemon. There functionality can conflict and bugs can
show up. On my system this materialized by auto-cpufreq frequently
shutting down, but there may be other consequences.
This change follows the same pattern as the tlp assertion
When I initially wrote this test, I wasn't aware that services.openssh
could opt into using OpenSSH's default algorithms by just setting the
relevant settings to null.
That's a better approach since:
* it's a simpler setting for this test to have to worry about
* it introduces test coverage for the null case
* the null case should be demonstrated as an example for those that
want to compile without OpenSSL
