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.
After upgrading to 3.5.0 we noticed, that registering would redirect to
the login page and not work at all. At the same time the admin user was
unable to access its user settings.
This issue could be tracked back to the template cache, that must be
invalidated between release upgrades.
This was broken by the Rust 1.80 upgrade, and is an old version that
we’d have to patch to keep working.
We have already done the 0.4 → 0.5 update without keeping around
the old version or adding in any additional `stateVersion` logic
in <https://github.com/NixOS/nixpkgs/pull/280221>. As a result,
migration for 0.3 users is going to be a little awkward. I’ve done
my best to provide comprehensive instructions for anyone who hasn’t
already bumped to 0.4.
It is probably a footgun to add `stateVersion` logic for any
package that makes backwards‐incompatible schema changes and only
supports migration from the immediately previous version. Users
won’t get migrated by default and we have to either package and
maintain an endlessly growing list of old versions or add complicated
instructions like this. It’s not really practical for us to support
a significantly better migration story than upstream does.
Miniflux supports provisioning users via SSO, which renders admin
accounts unnecessary for some use-cases. This change retains the
existing default, but makes it easier to disable admin provisioning.
Systemd units with `PrivateUsers` set get their capabilities within the user namespace only [1].
As a result they do cannot bind to privileged ports even though they *appear* like they should be able to.
The units in this commit [2] set `PrivateUsers` unconditionally so binding to privileged ports is currently impossible.
Granting them CAP_NET_BIND_SERVICE is useless and misleading any reader of those modules.
Technically, this commit also hardens these modules ever so slightly.
(There are corner cases where this could make sense (e.g. across units, using `JoinsNamspaceOf`) but this is arcane enough to not to be present in nixpkgs.)
[1]: systemd.exec(5): PrivateUsers
[2]: found using `rg -e 'PrivateUsers.?=\s+[^f][^a]' -l | xargs rg -e '\bCAP_' -l`
Found a few instances, where celery intermittently complained about a
misconfigured redis instance and exited.
> redis.exceptions.ResponseError: MISCONF Redis is configured to save RDB
> snapshots, but it's currently unable to persist to disk. Commands that
> may modify the data set are disabled, because this instance is
> configured to report errors during writes if RDB snapshotting fails
> (stop-writes-on-bgsave-error option). Please check the Redis logs for
> details about the RDB error.
