Previously, pdftk (part of the ticket, badge, ... generation pipeline)
would fail with:
```
Error occurred during initialization of VM
Failed to mark memory page as executable - check if grsecurity/PaX is enabled
```
Thise caused pdf generation to fail.
Since pdftk is a java application and, according to systemd.exec(5),
> Note that [MemoryDenyWriteExecute=] is incompatible with programs and
> libraries that generate program code dynamically at runtime, including
> JIT execution engines, executable stacks, and code "trampoline" featu
> re of various C compilers.
Disabling `MemoryDenyWriteExecute=` fixes it.
Prefer setting the whitelisted bridges through the generic configuration
method. Removes the need for a whitelist.txt file.
Preserves backwards compatibility by taking the same values and
essentially just renaming the config option.
Preserve the default value for the filecache path, but also allow
modifying it, adapting the tmpfiles rule to create the directory with
the right permissions.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This allows managing rss-bridge's config with nix.
It leverages the environment variable way of setting the config options,
introduced quite [some time ago](https://github.com/RSS-Bridge/rss-bridge/pull/2100)
It is the only existing way to set config options independent of the
document root, and upstream is [hesitant](https://github.com/RSS-Bridge/rss-bridge/pull/3842)
to change the config loading methods.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
The required nginx configuration is now really simple, and e.g. SSL/ACME
already required the user to interact with `services.nginx.virtualHosts`.
Therefore, and to reduce complexity, we now leave the web server
configuration to the user.
right now, we have php81 and php (which points to php82), which means that:
- php-fpm uses php81
- the update preStart uses php81
- the actual updater uses php82
Or another way to see it:
netbox_3_7: init at 3.7.1
Make NetBox 3.7 the default version if stateVersion >= 24.05,
switch upgrade test to test upgrade from 3.6 to 3.7,
remove clearcache command for >=3.7.0,
make reindex command mandatory
Closes#169733
The issue is that Nextcloud fails to start up after a GC because the
symlink from `override.config.php` is stale.
I'm relatively certain that this is not a bug in the Nix GC - that
would've popped up somewhere else already in the past years - and one of
the reporters seems to confirm that: when they restarted
`nextcloud-setup.service` after the issue appeared, an
`override.config.php` pointing to a different hash was there.
This hints that on a deploy `nextcloud-setup` wasn't restarted properly
and thus replacing the symlink update was missed. This is relatively
hard to trigger due to the nature of the bug unfortunately (you usually
keep system generations for a few weeks and you'll need to change the
configuration - or stdenv - to get a different `override.config.php`),
so getting pointers from folks who are affected is rather complicated.
So I decided to work around this by using systemd-tmpfiles which a lot
of other modules already utilize for this use-case. Now,
`override.config.php` and the directory structure aren't created by
`nextcloud-setup`, but by `systemd-tmpfiles`.
With that, the structure is guaranteed to exist
* on boot, since tmpfiles are always created/applied then
* on config activation, since this is done before services are
(re)started which covers the case for new installations and existing
ones.
Also, the recursive `chgrp` was used as transition tool when we switched
from `nginx` as owning group to a dedicated `nextcloud` group[1][2], but
this was several releases ago, so I don't consider this relevant
anymore.
[1] fd9eb16b24
[2] ca916e8cb3
The Nextcloud admin guide says that output buffering must be turned off
or otherwise PHP will return memory-related errors [1]. As the default
value for this PHP setting is 4096 and thus enabled the Nextcloud setup
is thus misconfigured by default. This misconfiguration will be shown in
the "Security & setup warnings" dialog for the administrator.
Fix this misconfiguration by setting "output_buffering=0" by default.
[1]: https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/big_file_upload_configuration.html#configuring-php
Closes#277206
The bug mentioned above was a symptom of the issue fixed here: when
opening the `forms` app which is installed via `extraApps` (or the
app store) the site wouldn't work because `.mjs` files had the wrong
Content-Type.
The actual problem got fixed already[1], however this config was not
used for stuff from `/nix-apps` & `/store-apps` which had their own
location section with only a `root ;` statement.
In fact, this setup isn't strictly supported by Nextcloud upstream[2],
so to fix this for good, I decided to follow the upstream suggestion for
app directories outside the server root, i.e. linking them back into the
store path.
This means that the module generates a new derivation now with
* `services.nextcloud.package` linked into it via `lndir`.
* under `nix-apps` is a symlink to the link farm containing all apps
from `services.nextcloud.extraApps`.
* under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`.
Since this is only used in the NixOS module that also configures this
location for imperatively installed apps, this seems an OK thing to
do.
Successfully tested the change on a productive Nextcloud 28.0.1 with
several apps installed via `extraApps` (`forms`, `cospend`, `maps`,
`user_saml` and a few more).
[1] 292c74c7a9
[2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
