This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
This adds a NixOS module for XScreenSaver (from @aidalgol in #130218,
with a few updates).
The module:
* Installs XScreenSaver
* Sets up a suid wrapper for xscreensaver-auth
* Sets up a user service for xscreensaver
The suid wrapper should function correctly when xscreensaver is
installed via the derivation update in 40a00547b71.
Co-authored-by: Aidan Gauland <aidalgol@fastmail.net>
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
The sshKey options do not need to be a valid path at build time. Using
string instead allow use case when the path is not known at build time
such as when using systemd credentials (e.g. `sshKey =
"\${CREDENTIALS_DIRECTORY}/zfs-replication_ed25519";`).
- Use lazyAttrs (for config references) settings for main server.properties.
- Drop dangerous default for "log.dirs"
- Drop apache-kafka homedir; unused and confusing
- Support formatting kraft logdirs
Do not assume that port and unixSocket are the only options that affect
address families used by Redis. There are other options, e.g. tls-port,
and also clustered setup that are not covered by the declarative
configuration. Instead of trying to selectively restrict unused address
families based on the configuration, limit address families to IP and
Unix sockets and let users lib.mkForce a stricter sandboxing is needed.
See also
https://docs.redis.com/latest/rs/networking/port-configurations/
A remote builder does not need to evaluate anything, so let's trim
it down to (eventually) save some space, and make the purpose of
the builder clear.
Users should evaluate on the host instead.
The CAKE section for systemd.network units allows configuring whether or
not redundant ACKs should be dropped. This option corresponds to the
respective tc-cake(8) params "ack-filter", "ack-filter-aggressive" or
"no-ack-filter".
Add support for these values in the `cakeConfig` module so that users
can configure it.
The previous -home argument worked as such:
"Set common configuration and data directory. The default configuration directory is $HOME/.config/syncthing (Unix-like), $HOME/Library/Application Support/Syncthing (Mac) and %LOCALAPPDATA%\Syncthing (Windows)"
This resulted in syncthing not respecting different home and data dirs
declared in its config. The default behaviour will remain the same, as
we set the datadir default value to homeDir + .config/syncthing.
Depends on EOL software and no maintenance has been attempted to change this after a ping
(https://github.com/NixOS/nixpkgs/issues/259178)
Feel free to adopt and re-introduce if you care about this software.
This will probably seriously hamper ELK usability in nixpkgs, but as it
receives no maintenance…
* nixos/forgejo: changelog and migration instructions
* nixos/forgejo/docs: clarify sentence
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
* nixos/forgejo/docs: document migration via gitea impersonation
* nixos/forgejo/docs: note about url change on migration
* nixos/forgejo/docs: note about migration (non-)requirement
* nixos/forgejo/docs: header ids
* nixos/forgejo/docs: clarify release notes entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: improve manual entry
Co-authored-by: Emily <git@emilylange.de>
* nixos/forgejo/docs: move changelog line to the middle of the section
as noted <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
---------
Co-authored-by: Trolli Schmittlauch <schmittlauch@users.noreply.github.com>
Co-authored-by: Emily <git@emilylange.de>
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.
Given that SourceHut uses unfortunate defaults for database name, it will not
be realistic to fix this in time for 23.11.
We will leave the workaround and leave it to SourceHut maintainers to pick up the work
to clean this up after 23.11.
