This sets the exception handler to show the full exception on startup.
We don't think it does anything else, with respect to logging, for
instance. Everything else can be configured in the config file, and this
is plain reasonable to simply always enable in our view.
This service performs operations that significantly increase the
performance of Nextcloud, can take a while. These are designed however
to not require maintenance mode and can be executed during normal
operation[1].
Make nextcloud-cron a simple unit instead of oneshot: otherwise we risk
that it'll be stopped by the startup timeout (oneshot executes ExecStart
while "activating") which can be an issue for very long running tasks or
if Nextcloud needs to catch up if one task was broken for a while.
[1] https://docs.nextcloud.com/server/29/admin_manual/maintenance/upgrade.html#long-running-migration-steps
Currently there is an issue with $PATH & parallel causing build errors.
It’s probably best to just remove the dependency where bash forking is
good enough here.
Currently the installWrapper warning is issued if sudo (and sudo-rs)
aren't installed. This is fine, except we get the warning even if we
explicitly turn off installWrapper -- say, for this very reason!
Rather than warning on every build until either sudo is installed or
Akkoma is uninstalled, only warn if cfg.installWrapper is true.
* PHP 8.3 seems supported, so let's go for it!
* The conditions for which Nextcloud will be the default were bogus: for
<24.11 I'd suggest to go for nextcloud29 already. The people on
unstable relying on the condition were on nextcloud28 so the upgrade
will work fine.
Also, it's unstable, so such upgrades are to be expected IMHO.
* Update the release notes to reflect that the new default is Nextcloud
29 and warn that only one major upgrade at a time can be done.
Prior to this patch, FreshRSS fails to load with an initial
`authType = "none"` setting, instead providing an error:
"Error during context user init!"
To fix this, this patch changes the freshrss-config service to
setup the initial `defaultUser` when `authType = "none"`
is configured.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
new versions of akkoma require the upload base url to be specified in
order for updates to work properly.
this will be a breaking change in 24.05, but for now a reasonable
default is set.
- new maxUploadSize option
- new dataDir option (with ReadWritePaths systemd support)
- admin page reports correct free disk space (instead of /nix/store)
- fix example configuration in documentation
- now podcast creation and file upload are tested during NixOS test
- move castopod from audio to web-apps folder
- verbose logging from the browser test
The main idea behind that was to be able to do more sophisticated
merging for stuff that goes into `postgresql.conf`:
`shared_preload_libraries` is a comma-separated list in a `types.str`
and thus not mergeable. With this change, the option accepts both a
comma-separated string xor a list of strings.
This can be implemented rather quick using `coercedTo` +
freeform modules. The interface still behaves equally, but it allows to
merge declarations for this option together.
One side-effect was that I had to change the `attrsOf (oneOf ...)` part into
a submodule to allow declaring options for certain things. While at it,
I decided to move `log_line_prefix` and `port` into this structure as
well.
The postgresql runs on a different node than my mastodon itself. Sometimes when
rebooting the entire host it can happen that mastodon gets started
before the DB[1] is up. In that case `mastodon-init-db.service` ran
through with the following log output:
2024-03-07 15:30:56.856
Migrating database (this might be a noop)
2024-03-07 15:30:56.856
/nix/store/xzm7www0qb7jg5zrgg7knynckx5yhki9-unit-script-mastodon-init-db-start/bin/mastodon-init-db-start: line 9: [: -eq: unary operator expected
It seems wrong to me to have this unit pass if the DB isn't even up,
especially with such an error.
This patch now checks if the exit code of the psql check was non-zero
and fails the entire unit. A retry can be implemented e.g. with
Restart/RestartSec then (which is more elegant than adding a while/sleep
loop anyways) like this:
systemd.services.mastodon-init-db = {
serviceConfig = {
Restart = "on-failure";
RestartSec = "5s";
RestartMode = "direct";
RemainAfterExit = true;
};
unitConfig = {
StartLimitBurst = 5;
StartLimitIntervalSec = "60";
};
};
Also using `-t --csv` now to not render the column name and to not
render a table so we don't need to rely on the format of psql (and parse
it with `sed(1)`).
[1] I added a script that blocks until postgres is there in the meantime
though.
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.
Fix the alias for displaying media.
Also the more_set_headers for Content-Disposition was invalid and broke
browsers. While I was at it, I also quoted the other more_set_headers
directives.
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
This makes sure we don't need any workarounds for running Invidious with a local
PostgreSQL database.
Changing the default user should be fine as the new init script for PostgreSQL automatically
creates the new user and changes the existing database's owner to the new user. The old user
will still linger and must be removed manually.
See also: https://github.com/NixOS/nixpkgs/pull/266270
This fixes the following eval error:
```
error: nodePackages.node-red cannot be found in pkgs
```
when having `services.node-red.enable = true;` without specifying
`services.node-red.package`, just like the nixos VM test.
Follow-up of f509382c11, which attempted
to fix this as well.
Breakage introduced in 0a37316d6c.
* Always use PHP 8.2: at the time of writing, Nextcloud also suggests to
use 8.2 rather than 8.3 in the manual for v28.
One contributing factor is probably that all plugins need new releases
to declare PHP 8.3 support.
* Fix upgradeWarning for installing v27 now that v28 is out.
* Drop upgrade warning for v24. This one is EOL for quite a while
already, so right now everybody should've switched (or carefully
studied the release notes in case they were upgrading from <23.05) and
we can clean up the module a little bit.
v25 was dropped not so long ago, so if it's still referenced (because
somebody didn't declare `services.nextcloud.package` and has
`system.stateVersion = "22.11";`) it's appropriate to still give a
specialized error.
