frenck/spook includes a second manifest for an integration. The current
copyCustomComponents script assumed that only one component directory
will be found, which in this case resulted in a malformed symlink
destination:
lrwxrwxrwx 1 hass hass 224 Jun 23 17:23 spook -> '/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook/integrations/spook_inverse'$'\n''/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook'
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.
