This is a full rewrite independent of the previously removed cryptpad
module, managing cryptpad's config in RFC0042 along with a shiny test.
Upstream cryptpad provides two nginx configs, with many optimizations
and complex settings; this uses the easier variant for now but
improvements (e.g. serving blocks and js files directly through nginx)
should be possible with a bit of work and care about http headers.
the /checkup page of cryptpad passes all tests except HSTS, we don't
seem to have any nginx config with HSTS enabled in nixpkgs so leave this
as is for now.
Co-authored-by: Pol Dellaiera <pol.dellaiera@protonmail.com>
Co-authored-by: Michael Smith <shmitty@protonmail.com>
Their Dockerfile uses Alpine’s ffmpeg package, which is already
on 6. They just invoke the command‐line tool and nothing they do
looks particularly version‐sensitive.
This helps supporting sudo-rs, which currently does not implement the
--preserve-env flag and probably won't so in the foreseeable future [1].
The replacement just sets both environment variables behind the sudo
invocation with env, as sudo-rs also doesn't implement env var lists.
The OC_PASS variable is dropped, as it is seemingly unused and would
leak through this approach through /proc.
[1] https://github.com/memorysafety/sudo-rs/issues/129
This change enables server:port combinations like "localhost:5432" but
also socket paths like "/run/postgresql". Without this change a port was
mendatory and attached to the path (/run/postgresql:5432) resulting in
an incorrect socket path. The underlying script already configures paths
correctly, so this small change should be enough.
Originally, I wanted to execute `nextcloud-occ` with a higher memory
limit because I needed to trigger an expensive operation by hand,
regenerating a bunch of previews.
While doing so, I realized how painful it is to put an invocation of
nextcloud-occ together for that, especially when you need to put it
into another systemd unit in Nix code.
That's why I decided to use the memory limit now for every
CLI invocation just in case. The stuff you do in those units (e.g.
running background jobs) is something you can also do by hand with
`nextcloud-occ` and you'll most likely want to have the same memory
limit there.
This option is actually useful when having a systemd unit invoking
`nextcloud-occ`, then you want to do something like
path = [ config.services.nextcloud.occ ]
This is possible today, but not documented (and the option completion
from nil doesn't pick it up as a result).
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
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`.
This prevents the post start script from running
before necessary sockets have been created.
It also prevents an unused shell from being kept around
by using `exec` to make `notify_push` the main process.
The memory limit is equal to what's configured in php-fpm. Given that we
run in a different environment, it seems reasonable to allow different
memory contraints here.
Module has been fixed and now uses the maintenance service to cache
settings so as to not require environment files wherever possible.
The tests now test using mariadb and postgresql as well as sqlite to be
more complete. A test has been added for testing whether app.js has been
compiled successfully, as well as to check whether the cronjob fires
successfully.
Allow loading pretalx plugins in a declarative manner. They are passed
into the package dependencies at build time, so that collectstatic and
other django maintenance functions account for them, since we cannot
regenerate assets at runtime anyway.
This makes it possible for other systemd units to depend on
keycloak.service using `after` and `wants` relationships, and systemd
will actually wait for Keycloak to finish its initialization before
starting any dependent units. This can be important for services like
oauth2-proxy, which (when configured to use Keycloak as its auth
provider) will fail to start until Keycloak's
`.well-known/openid-configuration` endpoint is available.
The state directory contains static files that need to be accessible by
a webserver, but homeMode defaults to 0750 and switching the generation
will always force the homeMode, thereby breaking access to the assets.
Instead, fully rely on systemd to provide the StateDirectory with the
correct mode.
The state directory contains static files that need to be accessible by
a webserver, but homeMode defaults to 0750 and switching the generation
will always force the homeMode, thereby breaking access to the assets.
Instead, fully rely on systemd to provide the StateDirectory with the
correct mode.
In 8bb777ee37 a condition was added to
only execute the createdb.sh script if database setup was configurated.
However a superfluace " was added at the end of the line which cased an
escaping error the resulted in #309520.
Fixes#309520
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.
the nix `recommendedProxySettings` optiononly takes effect if `proxyPass`
is set, but since we manually invoke `proxy_pass` inside nginx we need
to also manually specify proxy settings. failing to do so leads to
symptoms such as "Incoming activity has invalid signature".
see: <https://github.com/LemmyNet/lemmy/issues/3273>
* 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
