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
For some reason, StateDirectory does not work very well with the sqlite format.
This acts as a workaround of such, and allows the service to alternatively work
in an alternative, user-created directory if the issue does arise again.
See https://github.com/muety/wakapi/issues/731 for context and
motivations for this change.
Merge conflict in `pkgs/by-name/en/envision/package.nix` between efb2d2b815fe9f7d12f4aab42c83e759db5ec716 (staging) and b9d59c4515ea7cd4595d342c9d87877b544e6dbd+de7a60960219b303cc44ad446f9e7ddaf23b9944 (staging-next).
script initially copied from nextcloud and run with run.php as requested by this big warning:
*******************************************************************************
NOTE: Do not run maintenance scripts directly, use maintenance/run.php instead!
Running scripts directly has been deprecated in MediaWiki 1.40.
It may not work for some (or any) scripts in the future.
*******************************************************************************
This typo is confusing because it seems like the assertion requires nginx to be non-null (old text: "either nginx or nginx.webServerUser is mandatory").
It broke somewhere between NixOS 24.05 and 24.11 due to flask-session
being upgraded. It now requires an explicit value and an empty string
will no longer do.
cachelib's SimpleCache was chosen as it doesn't require any other
configuration, and keeps previous behaviour.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
Caddy usually expects just a hostname without scheme to do its automatic
HTTPS. It is possible to get the old behavior (only HTTP) by setting
`services.caddy.virtualHosts.<host>.hostName`.
I've already made it so that Kimai's PHP package has all required
extensions. So use that instead of the default PHP package.
This fixes a warning in Kimai's doctor page.
This will be EOL at the end of November, so there's little reason to
keep it in 24.11[1]. As discussed, we'd like to keep it for as long as
possible to make sure there's a state in nixpkgs that has the latest
minor of postgresql_12 available with the most recent CVEs fixed for
people who cannot upgrade[2].
This aspect has been made explicit in the manual now for the next .11
release.
During the discussions it has been brought up that if people just do
`services.postgresql.enable = true;` and let the code decide the
postgresql version based on `system.stateVersion`, there's a chance that
such EOL dates will be missed. To make this harder, a warning will now
be raised when using the stateVersion-condition and the oldest still
available major is selected.
Additionally regrouped the postgresql things in the release notes to
make sure these are all shown consecutively. Otherwise it's a little
hard to keep track of all the changes made to postgresql in 24.11.
[1] https://endoflife.date/postgresql
[2] https://github.com/NixOS/nixpkgs/pull/353158#issuecomment-2453056692
This makes it so that the upgrade script also runs when the
configuration changed, or when plugins were added.
This is also a hack to force everyone to run the upgrade script again,
since static files might have been copied incorrectly (see parent commit)
1. Removed the #!/bin/sh shebang at the beginning, because
systemd.services.<name>.script already adds a #!/nix/store/.../bin/bash
shebang.
Previously:
#!/nix/store/516kai7nl5dxr792c0nzq0jp8m4zvxpi-bash-5.2p32/bin/bash
set -e
#!/bin/sh
umask 077
...
2. Exec into nodejs, so that the startup script is no longer running but
replaces itself by nodejs.
This way, only one processus is running inside peertube.service.
Using implication here (->) causes the assertions to fail haphazardly due to the ordering *implied* by the operator. By using AND, we avoid this case. Unsurprisingly, this was caught by the NixOS test.
the redis module expects a user and group to exist with this name.
previously if there was no group with the same name as
`services.immich.user` the immich redis server would fail to start.
instead we can use the redis module's default behaviour: it will
create a user & group named "redis-immich".
These options are a good start for sandboxing the service. It's planned
to set `ProtectSystem` to `strict` instead of `full`, but that requires
specific directories to be configured as writable. It's also planned to
filter system calls. However, that requires more testing but it
shouldn't prevent us from applying these options for now and add others
later.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
The rss-bridge service changes introduced in f2201789fe
resp. https://github.com/NixOS/nixpkgs/pull/223148 removes the need for
the package patch. This commit removes the patch to ease updating and
maintenance.
Relevant service functionality was also removed (e.g. the setting of
RSSBRIDGE_DATA).
The explicit definition of FileCache.path so users can easily see its
default value and change it, requires to use a freeformType to let users
freely add potentially upcoming config options. This type is restricted
to ini types (although we coerce them to environment variables).
This however makes the list of enabled_bridges impossible. That was
fixed by explicitly introducing this option with a type allowing lists.
The default value however should be unset, which is expressed as `null`,
which further spurred a change in the environment variable generation to
ignore null values (instead of coercing them to an empty string).
A breaking change note was added to highlight this change. A check that
warns users of the not-application of their existing config file is
not easily possible, as people could have only added or changed the
config.ini.php file on the file system without changing a nix variable.
I have no idea what this escape sequence even is, but it breaks the nix parser with cryptic errors if not used in a comment.
A friend let me know MacOS is prone to input weird spaces, not sure if that is the source.
Candidates were located and created with:
chr="$(echo -e '\xc2\xa0')"; rg -F "$chr" -l | xe sd -F "$chr" " "
There are some examples left, most being example output from `tree` in various markdown documents, some patches which we can't really touch, and `pkgs/tools/nix/nixos-render-docs/src/tests/test_commonmark.py` which I'm not sure if should be addressed
We mistakenly used a non-existing nginx variable for the X-Forwarded-Proto causing
the well-known redirect to return erroneous Location headers like:
Location: ://dav.example/dav
instead of the correct:
Location: https://dav.example/dav
That was... interesting to debug. It took a me a bit of reading C code
until I realized that the realpath cache is internally used for
`file_get_contents`, but not for `file_exists` 🙃
I'm not comfortable on doing the workaround in the module, but I think
it's good to have this documented in the manual.
Currently the NixOS module for Wakapi will create the database
automagically if the user has database dialect configured in the Wakapi
configuration file. By all means, this is undocumented behaviour and an
anti-feature.
This MR adds a database.createLocally option that allows the end-user to
create auto-creation behaviour, and lays out groundwork for automated
database setups for different database dialects supported by Wakapi.
