Since stalwart-mail 0.6.0, queue and report files are located in
the shared `storage.{data,blob}` stores. The `{queue,report}.path`
settings no longer had any effect since then.
I'm also removing the creation of the associated extra directories
in the `preStart` script. This should not cause any issue with old
setups since 0.6.0 was already packaged when 24.05 was released.
The GIT_PROJECT_ROOT directory is now created at runtime instead of
being assembled at build time.
This fixes ownership issues which prevented those repositories to be
read by users other than root. This also avoids creating symlinks in
the nix store pointing to the outside.
This adds a few options to properly set the ownership and permissions
on UNIX local sockets, set to private by default.
Previously, the created UNIX local sockets could be used by any local
user. This was especially problematic when fcgiwrap is running as root
(the default).
Since we're already introducing some backward-incompatible change in
the previous commit, let's make the options more tidy, also preparing
for the introduction of more options.
This also fixes the documentation of the user and group options which
are applying to the service's running user, not the socket.
This allows configuring and starting independent instances of the
fgciwrap service, each with their own settings and running user,
instead of having to share a global one.
I could not use `mkRenamedOptionModule` on the previous options
because the aliases conflict with `attrsOf submodule` now defined at
`services.fcgiwrap`. This makes this change not backward compatible.
There are several GPUs that ROCm doesn't officially support but
will work correctly if ROCm is directed to treat the GPU as a different
one that is supported and has a similar architecture.
This can be done by setting `HSA_OVERRIDE_GFX_VERSION`.
Ollama has documentation on this topic: https://github.com/ollama/ollama/blob/main/docs/gpu.md#amd-radeon
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).
debug_level 65510 (0x3f7f0) is _extremely_ verbose, far more than one
would want in normal operation. Setting these in the default config
also makes it difficult to override in a user config. Anyone who needs
greater verbosity can add these options to their own sssd config, or
adjust them at runtime with `sssctl debug-level`.
Some sites put hosts in domains outside of the IPA server's default
domain, so this needs to be user-configurable. The default is to use
the system's FQDN if it is configured, otherwise fallback to the
previous default behaviour of assuming the IPA's server's domain.
diskSize defaults to the previous hard-coded 8192:
no change for existing users.
Users can set diskSize when building images which require
larger disk space; thus avoiding the error:
ERROR: cptofs failed. diskSize might be too small for closure.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Co-authored-by: superherointj <5861043+superherointj@users.noreply.github.com>
The default for this value depends on `config.networking.domain`, which is typed as `types.nullOr types.str` in nixos/modules/tasks/network-interfaces.nix
As a result, the default for `services.bluemap.host` either has to be `types.nullOr types.str`, or we need to drop the default.
Based on PR feedback, this commit drops the default and requires configuration through the `services.bluemap.host` option.
While this is a breaking change, since the module is a month old, there should be very few users so far.
GDM uses gdm-password as the PAM service name for both logins and unlocks.
So unlock gnome-keyring as part of `gdm-password`.
Without this, keyrings may not be unlocked properly for GDM 45+.
also unlock as part of GDM autologin
Netdata is critically dependent on working wrappers, thus, we ensure that the service was successful.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
This option furthers the "zero configuration" reputation of netdata by collecting
some Python packages available in nixpkgs and offering them to the module.
It is disabled by default.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Netdata is zero-config, so we should provide some *default* packages.
If the closure size is a problem for you, reach out to maintainers.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Verify that all `href` attributes emitted as part of the entrypoint page
after logging in are reachable.
Co-authored-by: Bruno BELANYI <bruno@belanyi.fr>
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
These messages should be able to be printed in all cases. In particular, trying to coerce a `null` to a string is an error unless passed through `toString`.
Set PATH order correctly for systemd user services (see NixOS/nixpkgs#320734
Signed-off-by: Reputable2722 <153411261+Reputable2772@users.noreply.github.com>
- rename hardware.opengl to hardware.graphics
- remove hardware.opengl.driSupport, which does nothing
- remove hardware.opengl.setLdLibraryPath, which should never be done
- rename hardware.opengl.driSupport32Bit to hardware.graphics.enable32Bit
- lost of small docs / formatting cleanups
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`.
Allows users to refer to `config.programs.ydotool.group` rather than
hard-coding "ydotool".
Allows users to override the group name for whatever reason.
This closes#317013.
Co-authored-by: Cosima Neidahl <opna2608@protonmail.com>
This was meant to make amazon-ssm-agent work "out of the box" on non-NixOS
systems but the feature never really worked.
The problem is that amazon-ssm-agent looks for the files "amazon-ssm-agent.json"
and "seelog.xml" but the files in the package are named
"amazon-ssm-agent.json.template" and "seelog.xml.template". So even with
this overrideEtc = true it would not be able to find the config.
E.g. you'd get an error like
Error occurred fetching the seelog config file path: open /nix/store/pyfxjr0i0hszcj9b6fqly6344zf9zhcb-amazon-ssm-agent-3.3.484.0/etc/amazon/ssm/seelog.xml: no such file or directory
on startup.
Removing this parameter from the from the package doesn't break things as it didn't work in the first place.
Allow users to disable the shadow authentication suite.
My primary motivation is to reduce the attack surface via setuid
binaries, which shadow understandably introduces many. I realised,
however, that I don't use any of these.
The test demonstrates login working without needing the shadow suite.
This adds a NixOS module for Grafana Alloy.
I started from the grafana-agent one but dropped all settings and config
management whatsoever.
Grafana Alloy uses its own Alloy config format (similar to HCL), which
is not really possible to express in Nix.
Simply pointing to a path in `/etc`, and leaving it up to the user to configure
it via `environment.etc` allows the user to arrange config files however
it makes most sense for them.
The module, systemd unit etc is called "alloy", not "grafana-alloy" to
follow the way it's packaged on other distros, to follow POLA.
- Introduce more possible options by using the krb format generator.
- Enforce package choice is using a correct package.
- Use meta attribute to decide implementation, allows for overriding the
package.
- Make necessary changes to the format, to allow for multiple ACL files in
heimdal.
- Add systemd target and slice for both implementations.
- Move state to `/var/lib`
- Add documentation
auto-cpufreq is similar to tlp in that it shouldn't be run with
power-profiles-daemon. There functionality can conflict and bugs can
show up. On my system this materialized by auto-cpufreq frequently
shutting down, but there may be other consequences.
This change follows the same pattern as the tlp assertion
This library does not actually need to match the Nvidia driver version,
so we do not need to make it available impurely.
This reverts the following commits.
9b3461e7ae4e353b67f6
I want to use the final symlinked package in system.checks and need to
access that somehow. Instead of adding a new option, we might as well
convert tmpfiles to the new structure.
The `openssh` and `openssh_hpn` packages are now built without
the Kerberos support by default in an effort to reduce the attack surface.
The Kerberos support is likely used only by a fraction of the total users
(I'm guessing mainly users integrating SSH in an Active Directory env) so
dropping it should not impact too many users. It should also be noted that
the Kerberos/GSSAPI auth is disabled by default in the configuration.
`opensshWithKerberos` and `openssh_hpnWithKerberos` are added in order
to provide an easy migration path for users needing this support.
The `openssh_gssapi` package is kept untouched.
This is not a breaking change. Existing setups continue to work as-is.
Users of `cfg.mailerPasswordFile` will get an option rename/deprecation
warning, but that's it (assuming there is no regression).
This adds `cfg.secrets`, which is a wrapper over systemd's
`LoadCredential=` leveraging Forgejo's `environment-to-ini`.
`environment-to-ini` is intended for configuring Forgejo in OCI
containers.
It requires some fairly annoying escaping of the section names to fit
into the allowed environment variable charset.
E.g. `"log.console".COLORIZE = false` becomes
`FORGEJO__LOG_0x2E_CONSOLE__COLORIZE=false`.
- `.` needs to be replaced with `_0X2E_` and
- `-` needs to be replaced with `_0X2D_`
Those are simply the hex representation of each char from an ASCII
table:
. = ASCII 46 = 46 (decimal) = 2E (hex) = 0x2E = _OX2E_
To make interacting with `environment-to-ini` less annoying, we template
and escape the sections/keys in nix:
`cfg.secrets` takes the same free-form sections/keys as `cfg.settings`.
Meaning there is now a generalized abstraction for all keys, not just
those that have been manually implemented in the past.
It goes as far as theoretically allowing one to have `DEFAULT.APP_NAME`
read from a secret file.
I don't know why one would want to do that, but it has been made
possible by this :^)
More reasonable examples are listed in the `cfg.secrets` option example.
We also continue to bootstrap a handful of secrets like
`security.SECRET_KEY`. This is done is a sort of sidecar bootstrap unit
fittingly called `forgejo-secrets.service`.
Overriding those is, just like before, not really intended and requires
the use of `lib.mkForce` and might lead to breakage. But it is, in a
way, more possible than before.
