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/
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.
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.
This fixes the case where users enable harmonia but also have allowed-users set.
Having extra-allowed-users is a no-op when nix.settings.allowed-users is set to "*" (the default)
As it is technically a breaking change, we should at least make a strong deprecation
of `ensurePermissions` and leave it in the broken state it is, for out of tree users.
We give them a 6 months notice to migrate away by doing so, which is honest.
In the meantime, we forbid usage of `ensurePermissions` inside of nixpkgs.
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
This fixes the case where users enable nix-serve but also have allowed-users set.
Having extra-allowed-users is a no-op when nix.settings.allowed-users is set to "*" (the default)
Newer version of the gitsrht-api service call setrlimit() on startup,
thus allow it in the `SystemCallFilter` definition for the service.
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
I changed my nickname from Ninjatrappeur to Picnoir. My github id is
stable, it shouldn't break too much stuff.
I took advantage of this handle change to remove myself from the
hostapd maintainers: I don't use NixOS as a router anymore.
Allows passing custom component packages, that get installed into
home-assistant's state directory.
Python depedencies, that are propagated from the custom component
get passed into `extraPackages`, so they are available to
home-assistant at runtime.
This is implemented in a way, that allows coexistence with custom
components not managed through the NixOS module.
Was introduced in dde6a4f397
but it doesn't work on my machine:
fwupdmgr[439074]: Failed to connect to daemon: The connection is closed
Creating a persistent user does work however
If username is set, then unbound will try to become that user using
`setusercontext`. But this is pointless since we are already instructing
systemd to launch unbound with that user.
So force username to be empty, which disables this behaviour in unbound.
This allows us to remove the capability granted, and also tighten the
syscall filter.
`environment.variables` gets sourced by shells & the x11 wrapper
through bash's `/etc/profile`, but not by systemd services, dbus
services, wayland sessions...
`environment.sessionVariables` sets these variables with PAM early in
the login process so it gets applied in all contexts.
I ran into a similar issue before in #109060.
upstream is in the process of renaming to `hickory-dns`.
a consequence of this is that the main binary has been renamed from
`trust-dns` to `hickory-dns` and the repository has been moved (though
for the time being the old repo is still usable on account that it
redirects to the new one).
see: <https://bluejekyll.github.io/blog/posts/announcing-hickory-dns/>
This changes the syscall filter to match that of upstream. Note that
SystemCallFilter=~foo bar
is completely different from
SystemCallFilter=~foo
SystemCallFilter=bar
The former one means that foo and bar are forbidden, and the latter
one means foo is forbidden and bar is granted!
The PAM service `greetd` creates now autostarts GNOME Keyring when it is
enabled via `services.gnome.gnome-keyring.enable`.
Should cause a lot fewer headaches for people like me who didn't know
why GNOME Keyring was complaining that it was never supplied with login details.
Fixes#246197
In https://github.com/NixOS/nixpkgs/pull/254071, a mismatch between usage of
the Nix language and the NixOS module system was introduced. By merging the
kwin_wayland wrapper attrset into the mkIf representation, the former was
effectively ignored.
As a result, the capability wrapper for kwin_wayland stopped being installed,
leading to realtime scheduling being disabled. The issue was not detected
because the behavioral change is very subtle.
By consistently using language-level constructs, this mismatch is resolved.
The capability wrapper is thus installed again and realtime scheduling is
restored.
[Motivation](NixOS#257817 (comment))
`extraLayouts` was missed in #259891, so moving it to the other xkb
options with this PR.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
https://learn.netdata.cloud/docs/logs/systemd-journal/
need acces to
Kernel Logs (dmesg):
Capability: CAP_SYSLOG
Description: This capability allows the program to read kernel logs using the dmesg command or by reading the /dev/kmsg file.
System Logs (e.g., /var/log/syslog):
Capability: CAP_DAC_READ_SEARCH
Description: This capability allows the program to read system logs located in directories such as /var/log/.
User Logs (e.g., /var/log/auth.log):
Capability: CAP_DAC_READ_SEARCH
Description: This capability allows the program to read user logs located in directories such as /var/log/.
Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
Remove the deprecated --models option, as models are now discovered
and loaded dynamically from all configured model dirs at runtime.
Allow setting up custom model directories, so wake words other than the
built-in ones can be used, e.g. from
https://github.com/fwartner/home-assistant-wakewords-collection.
As described in the release lifecycle docs from postgresql[1], v11 will
stop receiving fixes as of Nov 9 2023. This means it's EOL throughout
the entire lifetime of 23.11, so let's drop it now.
A lot of examples are also referencing postgresql_11. Where it's
sensible, use postgresql_15 as example now to avoid confusion.
This is also handy because the LLVM 16 fix for postgresql is not
available for postgresql 11 ;-)
[1] https://www.postgresql.org/support/versioning/
When using iproute2's ip binary, you can omit the dev parameter, e.g. ip link set up eth0 instead of ip link set up dev eth0.
This breaks if for some reason your device is named e.g. he, hel, … because it is interpreted as ip link set up help.
I just encountered this bug using networking.bridges trying to create an interface named he.
I used a grep on nixpkgs to try to find iproute2 invocations using variables without the dev keyword, and found a few, and fixed them by providing the dev keyword.
I merely fixed what I found, but the use of abbreviated commands makes it a bit hard to be sure everything has been found (e.g. ip l set … up instead of ip link set … up).
If the PAPERLESS_SECRET_KEY environment variable is left unset
paperless-ngx defaults to a well-known value, which is insecure.
Co-authored-by: Erik Arvstedt <erik.arvstedt@gmail.com>
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
The previous implementation works fine when the plugins do not already
contain store paths, which is the case for stuff from munin-contrib.
However, for plugins generated via nix (e.g. with writeShellScriptBin),
it tries to fix the paths in it which already point to the nix store,
ruining everything.
If extraAutoPlugins contains values that carry context (e.g. it comes
from a flake input), the keys generated from them using baseNameOf
inherit that context and the config doesn't compile.
This doesn't actually need to be an attrset anyways, so a bit of
internal refactoring lets us fix this without changing the visible API.
Changes the `mkIf` to trigger if *either* `data_dir`/`metadata_dir` use
`/var/lib/garage`, not only if both do. This is useful to me because I
want to store metadata in `/var/lib/garage` but I also want to store
data in a different mountpoint (via `data_dir` and `ReadWritePaths`).
nixosTests.forgejo: test backup/dump service; nixos/forgejo: pass {env}`GIT_PROTOCOL` via ssh to forgejo; nixosTests.forgejo: test git wire protocol version
when using the host's openssh service (not the builtin golang one).
This enables the use of the much faster and more efficient wire protocol
version 2.
See https://git-scm.com/docs/protocol-v2
The new exporter has proper console scripts definition, that sets up
another executable name.
The package now also shells out to pidof, which is why we require procps
in the unit PATH.
Runs dbus-update-activation-environment and systemctl import-environment on session start
to ensure xdg portals work, and user services have correct PATH / XDG env vars.
Matches behavior of Plasma/Gnome sessions.
From `postgresql_15`'s release notes:
> PostgreSQL 15 also revokes the CREATE permission from all users except
a database owner from the public (or default) schema.
https://www.postgresql.org/about/news/postgresql-15-released-2526/
This directly affects `services.postgresql.ensureUsers` in NixOS,
leading to
> permission denied for schema public
`postgresql_15` is now the default for stateVersion `23.11`/`unstable`.
So until this is resolved globally, we work around this issue.
This adds a NixOS module for Soft Serve, a tasty, self-hostable Git
server for the command line. The module has a test that checks some
basic things like creating users, creating a repo and cloning it.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
