This 711-line file was expanded into 817-line file by nixfmt.
Readability was hurt as now I can’t see as much in my editor at a time;
this directly makes editing & reviewing slower as reading is harder. I
am upset about this change.
`nextcloud-notify_push.service` requires
`nextcloud-notify_push-setup.service`. If the latter fails (e.g. because
of Nextcloud not being there yet), the push service would also fail with
result 'dependency'.
RestartMode=direct doesn't put a unit into failed state IF it's about to
be restarted again. That way, `nextcloud-notify_push` will await several
restart attempts. Only if the unit fails due to a rate-limit (i.e. too
many restarts), the push service will also fail.
If the startup is still too slow, it may make sense for administrators to
configure higher intervals between the start attempts with RestartSec.
Enabling HSTS "just by default" when a module user requests HTTPS support to be enabled is prone to creating kind of DoS scenarios. This commit at least informs module users about this.
Originally, I only wanted to remove
"The logreader application doesn't work, as it was the case before.".
But then, the rest sounded a little weird, so I reworded the paragraph a
bit more ;-)
nixos/manual: add archtika module to 25.05 release notes
nixos/archtika: fix module formatting, add description and remove trailing whitespace
nixos/archtika: refactor module
nixos/archtika: refactor module
nixos/archtika: make SystemCallFilter addition for postgres systemd service
nixos/archtika: refactor module
nixos/archtika: grant only necessary authentication permissions to archtika db
Now that we are disabling telemetry by default, we should attempt to
override it and other options in existing mutable configs,
if the user had a mutable config and advances their system.stateVersion.
We should disable telemetry but enable security update checks. Make both
controlable in the module without digging into settings.
Disabling telemetry also makes NixOS tests faster because the server
tries to send telemetry on first start.
The error is only logged as an info since https://github.com/nextcloud/logreader/pull/1449.
This was a bug in the app, since the error is not fixable by the admin due to the logging configuration.
This patch adds support for using systemd's LoadCredential
feature to read various secret files used by nextcloud service
units.
Previously credentials had to be readable by the nextcloud user,
this is now no longer required.
The nextcloud-occ wrapper script has been adjusted to use
systemd-run for loading credentials when being called from
outside a service.
In detail this change touches various details of the module:
- The nix_read_secret() php function now takes the name of a
file relative to the path specified in the CREDENTIALS_DIRECTORY
environment variable.
- The nix_read_secret() now exits with error code 1 instead of
throwing a RuntimeException as this will properly error out
the nextcloud-occ script
- Only the nextcloud-setup service unit has the adminpass credential
added in addition to the other credentials
- Uses of ExecCondition= in nextcloud-cron and nextcloud-update-db
have been replaced by a shell conditional as ExecCondition currently
doesn't support credentials
- The phpfpm-nextcloud service now runs a preStart script to make
the credentials it gets readable by the nextcloud user as the
unit runs as root but the php process itself as nextcloud.
- To invoke occ notify_push:setup when using nextcloud notify_push
a new service has been added that replaces the preStart script
in nextcloud-notify_push.service. This has been done as the
main executable only needs the database password credential.
Co-authored-by: lassulus <lassulus@lassul.us>
This patch replaces the use of writeScriptBin for the nextcloud-occ
script with writeShellApplication, enabling shell checking.
This patch also updates various invocations of the script to
use lib.getExe.
Based on #198040. Prioritizes backwards compatibility, including
database and plugin compatibility, while adding more sensible
defaults like database peer authentication.
Expand the scope of tests to include plugins (including building
from source) and testing that a piece of media uploads and downloads
to make sure the storage directory doesn't vanish.
Since matomo-5.2.0, the config.php.ini is already created when first
accessing the installer page without completing it. This breaks our
discovery of whether to run database migrations.
Attempting to run DB migrations without provided database credentials
causes a crash -> causing matomo-setup-update.service to fail -> causing
phpfpm-matomo.service to fail.
This is normally done by kimai:reload command (which also include cache
clearing and warming up). But because we skip that command, run config
linting ourselves.
Prevent 'kimai:install' console command from both clearing and warming
cache in one go. Instead, run 'cache:clear' and 'cache:warmup'
separately. This seems fix the following error which appears on the
first init after an upgrade:
Fatal error: Cannot declare class App\Entity\Timesheet, because the name
is already in use in /nix/store/<...>/share/php/kimai/src/Entity/
Timesheet.php on line 50
23:42:49 CRITICAL [php] Fatal Compile Error: Cannot declare class
App\Entity\Timesheet, because the name is already in use ["exception"
=> Symfony\Component\ErrorHandler\Error\FatalError { …}] ["channel" =>
"php"]
In Timesheet.php line 50:
Compile Error: Cannot declare class App\Entity\Timesheet, because the
name is already in use
kimai:install [--no-cache]
nixosTests.cryptpad started failing recently.
Investigating the issue shows that seccomp has become problematic during
the init phase, (e.g. this can be reproduced by removing the customize
directory in /var/lib/cryptpad):
machine # [ 10.774365] systemd-coredump[864]: Process 756 (node) of user 65513 dumped core.
machine #
machine # Module libgcc_s.so.1 without build-id.
machine # Module libstdc++.so.6 without build-id.
machine # Module libicudata.so.74 without build-id.
machine # Module libicuuc.so.74 without build-id.
machine # Module libicui18n.so.74 without build-id.
machine # Module libz.so.1 without build-id.
machine # Module node without build-id.
machine # Stack trace of thread 756:
machine # #0 0x00007ff951974dcb fchown (libc.so.6 + 0x107dcb)
machine # #1 0x00007ff95490d0c0 uv__fs_copyfile (libuv.so.1 + 0x150c0)
machine # #2 0x00007ff95490d89a uv__fs_work (libuv.so.1 + 0x1589a)
machine # #3 0x00007ff954910c76 uv_fs_copyfile (libuv.so.1 + 0x18c76)
machine # #4 0x0000000000eb8a39 _ZN4node2fsL8CopyFileERKN2v820FunctionCallbackInfoINS1_5ValueEEE (node + 0xab8a39)
machine # #5 0x0000000001cda5e2 Builtins_CallApiCallbackGeneric (node + 0x18da5e2)
[...]
machine # [ 10.877468] cryptpad[685]: /nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/bin/cryptpad: line 3: 756 Bad system call (core dumped) "/nix/store/fkyp1bm5gll9adnfcj92snyym524mdrj-nodejs-22.11.0/bin/node" "/nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/lib/node_modules/cryptpad/scripts/build.js"
nodejs 20.18 rightly did not require chown when the source and
destination are the same owner (heck, the script does not run as
root so even if it is not blocked there is no way it'd work with a
different owner...)
For now just allow chown calls again, this is not worth wasting more
time.
Fixes https://github.com/NixOS/nixpkgs/issues/370717
