Invidious uses a strange setup where the database name is different from the system username
for non-explicit reasons.
Because of that, it makes it hard to migrate it to use `ensureDBOwnership`, we leave it to Invidious' maintainers
to pick up the pieces.
Mobilizon can have a custom database username and it is not trivial to sort out how to remove this.
In the meantime, for the upcoming 23.11 release, I apply the classical workaround
and defer to Mobilizon's maintainers.
This changes
* the plausible HTTP web server
to be listening on localhost only, explicitly.
This makes Plausible have an explicit safe default configuration,
like all other networked services in NixOS.
For background discussion, see: https://github.com/NixOS/nixpkgs/issues/130244
As per my upstream Plausible contribution
(https://github.com/plausible/analytics/pull/1190)
Plausible >= 1.5 also defaults to listening to localhost only;
nevertheless, this default should be stated explicitly in nixpkgs
for easier review and independence from upstream changes, and
a NixOS user must be able to configure the
`listenAddress`, as there are valid use cases for that.
Also, disable
* the Erlang Beam VM inter-node RPC port
* the Erlang EPMD port
because Plausible does not use them (see added comment).
This is done by setting `RELEASE_DISTRIBUTION=none`.
Thus, this commit also removes the NixOS setting `releaseCookiePath`,
because it now has no effect.
Closes#216989
First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.
The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).
After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].
So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that
* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
`ensureUsers`. That way, the user is actually the owner and can
perform `CREATE`.
* For such a postgres user, a database must be declared in
`ensureDatabases`.
For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.
Regarding existing setups: there are effectively two options:
* Leave everything as-is (assuming that system user == db user == db
name): then the DB user will automatically become the DB owner and
everything else stays the same.
* Drop the `createDatabase = true;` declarations: nothing will change
because a removal of `ensure*` statements is ignored, so it doesn't
matter at all whether this option is kept after the first deploy (and
later on you'd usually restore from backups anyways).
The DB user isn't the owner of the DB then, but for an existing setup
this is irrelevant because CREATE on the public schema isn't revoked
from existing users (only not granted for new users).
[1] not really declarative though because removals of these statements
are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
because it IMHO falls into the category "manage the state on your
own" (see the commit message). See also
https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
also add more things like collation for DBs or passwords that are
_never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
It's time again, I guess :>
Main motivation is to stop being pinged about software that I maintained
for work now that I'm about to switch jobs. There's no point in pinging
me to review/test updates or to debug issues in e.g. the Atlassian stack
or on mailman since I use neither personally.
But there's also a bunch of other stuff that I stopped using personally. While
at it I realized that I'm still maintainer of a few tests & modules related to
packages I stopped maintaining in the past already.
- Remove lots of declared options that were not used outside of being
included in settings. These should now be used through the freeform
module.
- Deprecate `cfg.workDir`, in favor of using systemds `StateDirectory`
- Use sqlite as default database.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
With those settings starting dex crashed with:
Oct 03 21:37:51 hydrogen (tart-pre)[11048]: dex.service: Failed to set up mount namespacing: /run/systemd/mount-rootfs/sys/fs/cgroup/system.slice/dex.service/memory.pressure: No such file or directory
Oct 03 21:37:51 hydrogen (tart-pre)[11048]: dex.service: Failed at step NAMESPACE spawning /nix/store/q8clp1lm8jznxf9330jd8cwc6mdy6glz-dex-start-pre: No such file or directory
First of all, a few cleanups were made to make it more readable:
* Reordered the sections by their priority so what you're reading in Nix
is also what you get in the final nginx.conf.
* Unified media/asset locations
Most notably, this fixes the
Your web server is not properly set up to resolve "/ocm-provider/".
warning since 27.1.2 where `ocm-provider` was moved from a static
directory in the source tarball to a dynamic HTTP route[1].
Additionally, the following things were fixed:
* The 404 checks for build/tests/etc. are now guaranteed to be before
the `.php` location match and it's not implicitly relied upon Nix's
internal attribute sorting anymore.
* `.wasm` files are supported properly and a correct `Content-Type` is
set.
* For "legacy" routes (e.g. `ocs-provider`/`cron`/etc) a `rewrite` rule
inside the location for fastcgi is used as recommended by upstream[2].
This also makes it easier to understand the purpose of the location
itself (i.e. use fastcgi for PHP code).
[1] https://github.com/nextcloud/documentation/pull/11179
[2] https://docs.nextcloud.com/server/27/admin_manual/installation/nginx.html
This commit fixes the service failing to start for the first time since
the update-schema operation requires human interaction (typing 'yes') in
order to actually perform the schema upgrade.
the schema files referenced in the current preStart are empty.
other ones exist, but don't apply cleanly either.
calling update.php with --update-schema works for initial setup and
updates. if the database schema is already up to date, it's idempotent.
This change enables _FILE variants for all secrets in Healthchecks
configuration so they can be read from a file and not stored in
/nix/store.
In particular, it adds support for these secrets:
DB_PASSWORD, DISCORD_CLIENT_SECRET, EMAIL_HOST_PASSWORD,
LINENOTIFY_CLIENT_SECRET, MATRIX_ACCESS_TOKEN, PD_APP_ID,
PUSHBULLET_CLIENT_SECRET, PUSHOVER_API_TOKEN, S3_SECRET_KEY, SECRET_KEY,
SLACK_CLIENT_SECRET, TELEGRAM_TOKEN, TRELLO_APP_KEY, and TWILIO_AUTH.
Previously, if someone changed DB to postgres or mysql and forgot to
change DB_NAME, services.healthchecks would have used the hardcoded path
that was meant for the sqlite as DB_NAME.
This change introduces DB and DB_NAME options in
services.healthchecks.settings.
exiftool is written in Perl which appears to call `chown` as part of startup. This is blocked by the `@privileged` system call group. This causes a failure when changing image orientation.
Fixes: https://github.com/NixOS/nixpkgs/issues/249120
This change also generates the invidious config by putting JSON
snippets into a bash array and then using jq to merge them all into
a single configuration where later elements override previous
elements.
This option only has an effect on the initial setup of Nextcloud and
changes later won't have any effect.
Same issue as with `adminpassFile` - it's only passed to the installer
command - but even worse because the username is frequently used as
unique ID in the database, so there's no trivial way to change it, even
imperatively.
Right now, the settings aren't additive which means that when I do
services.nextcloud.phpOptions."opcache.interned_strings_buffer = "23";
all other options are discarded because of how the module system works.
This isn't very nice in this case, though because wanting to override
a single option doesn't mean I want to discard the rest of the -
reasonable - defaults. Hence, the settings are showed as default in the
option's manual section, but are added with normal priority.
That means, to override _all_ options at once, an expression like
services.nextcloud.phpOptions = mkForce {
/* ... */
};
is needed. This is also way more intuitive IMHO because the `mkForce`
explicitly tells that everything will be modified.
Also, APCu enable and the memory & file-size limits are also written
into `services.nextcloud.phpOptions` rather than adding them
silently before passing all options to the PHP package. This has the
benefit that users will realize on evaluation time that they configured
options that would otherwise be set by the module on its own.
Now migrations are run only on upgrade / downgrade and first start,
which makes netbox much faster on a normal start.
add the reindex for NetBox > 3.5.0, to populate the index, preventing
empty search results.
Migrations were moved out of netbox-migration.service into
netbox.service, to prevent service dependency issues when upgrading
NixOS.
This patch adds an `authType` option to enable configuring FreshRSS's
`auth_type` parameter.
Upstream documentation for this feature is located here:
https://freshrss.github.io/FreshRSS/en/admins/09_AccessControl.html
An accompanying NixOS test is provided to confirm this feature works
as expected.
Upstream supports php 8.0/8.1 for the 3.3.0 release. The upgrade to 8.2
caused a type mismatch in carbon.
> PHP message: Exception: Code: 0, Message: Carbon\Carbon::setLastErrors(): Argument #1 ($lastErrors) must be of type array, bool given, called in /nix/store/2prnw9qya9kaks2rwvd6fkrz0c7l5ygd-engelsystem-3.3.0/share/engelsystem/vendor/nesbot/carbon/src/Carbon/Traits/Creator.php on line 98, File: vendor/nesbot/carbon/src/Carbon/Traits/Creator.php:928
As 3bb3859 bumped the default PHP version to 8.2, the snipe-it package
has been pinned to PHP 8.1. This commit changes the php package used in
the module to the one pinned by snipe-it.
LoadCredential was misused as it is not building any environment variable,
it is the responsibility of our preStart to do it so
Plausible's script can pick it up.
It's supposed to be `memcache.distributed`, not an associative PHP array
named `memcache` with a key `distributed`.
This was probably never caught because the initial `grep -q` check in
the test was invalid: `redis-cli` prints nothing if no keys can be found
when not writing to a tty apparently.
Lemmy checks the environment variable before the configuration file;
i.e. if the file is used to configure the database but the environment
variable is set to anything, the connection will fail because it'll
ignore the file. This was the previous behavior.
Now, the environment variable will be unset unless the user explicitly
chooses to set it, which makes the file-based configuration function
correctly. It's also possible to manually set the environment variable,
which has the major advantage of working around [this issue][0], which
prevents certain setups from working.
[0]: https://github.com/LemmyNet/lemmy/issues/2945
Part of #229910.
Unfortunately this is a little hacky because upstream doesn't intend to
support it for 2.5, but only for 3.0 which isn't out yet, however nodejs-16
will get out of maintenance during the support-span of NixOS 23.05[1].
The only breaking change is that `extract-files` uses a deprecated way
of exposing modules, I went through the list of other breaking
changes in v17 and v18[2][3] and couldn't spot any usage of removed
features, also local testing didn't reveal further issues.
Unfortunately fixing that breakage turned out to be non-trivial.
Currently, `extract-files@9.0.0` is used with the problematic portions
in its `package.json`, however it's only a transitive dependency of
`@graphql-tools/url-loader` & `apollo-upload-client`. Unfortunately, the
versions of that in use require v9 and don't work with a newer version of
`extract-files` with the problem fixed[4]. Also, upgrading the
dependencies in question is not a feasible option because `graphql-tools`
was split up into multiple smaller packages in v8 and also some of the
APIs in use in `wiki.js` were dropped there[5], so this would also be
very time-consuming and non-trivial to fix.
Since this was the only issue, I decided to go down the hacky route and
patch the problem in `package.json` of `extract-files` manually during
our `patchPhase`.
[1] https://github.com/requarks/wiki/discussions/6388
[2] https://nodejs.org/en/blog/release/v17.0.0
[3] https://nodejs.org/en/blog/release/v18.0.0
[4] Upon local testing, this broke with the following error:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './public/extractFiles' is not defined by "exports" in /wiki/node_modules/extract-files/package.json
[5] For instance `SchemaDirectiveVisitor` in
`server/graph/directives/auth`.
