we have a zoo of ways to call subprocesses.
Let's just replace this with one function that has reasonable defaults.
i.e. I catched instances where commands where run in a shell.
ChangeLog: https://github.com/grafana/grafana/releases/tag/v11.1.0
A few additional changes were necessary:
* Grafana now refuses to listen on non-IP values and aborts with
Error: ✗ *apiserver.service run error: invalid IP address: localhost
* packages/grafana-e2e doesn't exist anymore, so the build fixes for
that could be removed.
* Make sure we always compile the binary parts of cypress.
* Grafana tends to set the minimum Go version to the latest Go version
available now[1].
* The `url` of a datasource was set to `localhost` by default. I don't
expect anybody to have not set it when needed, also Grafana aborts now
if `url` is non-empty for a random walk datasource (which broke the VM
tests).
[1] https://github.com/grafana/grafana/pull/88794#discussion_r1630563467
dictd doesn't handle SIGTERM and terminates with code 143 (128 + 15
(SIGTERM) instead of 0. This results in systemd marking the service as
failed when a user stops it (with `systemctl stop dictd`). Fix it by
treating code 143 as success.
It was wrong to use StateDirectory to keep the scion-control and
scion-router runtime databases on disk for the next run. I observed that
doing this means a reboot, or power outage can corrupt the temporary
runtime databases for the next service start, leading scion ping and
other functionality to stop working permanently, since those files are
not managed in an atomic manner by the golang code.
`gitlab` >= 17.0 requires at least `postgresql` >= 14.9. GitLab users
are advised to follow the mentioned steps in the manual to upgrade their
PostgreSQL installation.
Importing PATH into the systemd environment is done by default in
Hyprland v0.41.2+ (https://github.com/hyprwm/Hyprland/pull/6640)
We soft deprecate this option here for versions >= 0.41.2.
This hopefully clarifies that the preset configures the hook to expose
"nvidia devices", which includse both the userspace driver and the
device nodes.
The derivations still declare requiredSystemFeatures = [ "cuda" ] to
explicitly indicate they need to use the CUDA functionality and expect a
libcuda.so and a CUDA-capable device. Ideally, we'd also include the
specific CUDA architectures (sm_86, etc) in feature names.
Derivations that use a co-processor but do not care about the vendor or
even the particular interface may ask for the more generic "opengl",
"vulkan", or "gpu" features. It is then responsibility of the host
declaring the support for this feature to ensure the drivers and
hardware are appropriately set up.
When `services.resolved` is enabled, then `resolve [!UNAVAIL=return]`
is added to `system.nssDatabases.hosts` with priority 501,
which prevents lower-priority NSS modules from running
unless systemd-resolved is not available.
Quoting from `man nss-resolve`:
> To activate the NSS module, add "resolve [!UNAVAIL=return]" to the line
> starting with "hosts:" in /etc/nsswitch.conf. Specifically, it is
> recommended to place "resolve" early in /etc/nsswitch.conf's "hosts:"
> line. It should be before the "files" entry, since systemd-resolved
> supports /etc/hosts internally, but with caching. To the contrary, it
> should be after "mymachines", to give hostnames given to local VMs and
> containers precedence over names received over DNS. Finally, we
> recommend placing "dns" somewhere after "resolve", to fall back to
> nss-dns if systemd-resolved.service is not available.
Note that the man page (just) recommends "early" and means with this
"before the 'files' and 'dns' entries". It does not insist on being
first or excluding other modules.
For this reason, libvirt NSS modules should run before the `resolve`
module. They should come right next to `mymachines` because both are
conceptually very similar -- they resolve local VMs/containers.
Since the data source of the libvirt NSS modules are local
plain text files (see source code of the libvirt NSS module),
no performance impact is expected form this raise of priorities.
Other NSS modules in NixOS also explicitly set their priority, which is
why this change increases consistency.
Fixes#322022
Support for *runner registration tokens* is deprecated since GitLab
16.0, has been disabled by default in GitLab 17.0 and will be removed in
GitLab 18.0, as outlined in the [GitLab documentation].
It is possible to [re-enable support for runner registration tokens]
until GitLab 18.0, to prevent the registration workflow from
breaking.
*Runner authentication tokens*, the replacement for registration tokens,
have been available since GitLab 16.0 and are expected to be defined in
the `CI_SERVER_TOKEN` environment variable, instead of the previous
`REGISTRATION_TOKEN` variable.
This commit adds a new option
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`.
Defining such option next to
`services.gitlab-runner.services.<name>.registrationConfigFile` brings
the following benefits:
- A warning message can be emitted to notify module users about the
upcoming breaking change with GitLab 17.0, where *runner registration
tokens* will be disabled by default, potentially disrupting
operations.
- Some configuration options are no longer supported with *runner
authentication tokens* since they will be defined when creating a new
token in the GitLab UI instead. New warning messages can be emitted to
notify users to remove the affected options from their configuration.
- Once support for *registration tokens* has been removed in GitLab 18,
we can remove
`services.gitlab-runner.services.<name>.registrationConfigFile` as
well and make module users configure an *authentication token*
instead.
This commit changes the option type of
`services.gitlab-runner.services.<name>.registrationConfigFile` to
`with lib.types; nullOr str` to allow configuring an authentication
token in
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
instead.
A new assertion will make sure that
`services.gitlab-runner.services.<name>.registrationConfigFile` and
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
are mutually exclusive. Setting both at the same time would not make
much sense in this case.
[GitLab documentation]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#estimated-time-frame-for-planned-changes
[re-enable support for runner registration tokens]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#prevent-your-runner-registration-workflow-from-breaking
Preflight check failed with error: Journal directory
</var/lib/graylog/data/journal> has not enough free space (3412 MB) available.
You need to provide additional 1707 MB to contain 'message_journal_max_size = 5120 MB'
My reasons following Mint are:
1. Geary signed https://stopthemingmy.app, per request we shouldn't pre-ship it under a themed desktop environment.
See also b7937b4509
2. Hexchat is still gtk2 and is not maintained anymore, Mint encourages switching to Matrix instead.
See also https://blog.linuxmint.com/?p=4675 ("Joining the Matrix")
The spook package includes two separate integrations and the module was
adapted to account for that scenario. Add a test to ensure the changed
keeps working correctly going forward.
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
To allow migration from 23.11 to 24.05 without triggering re-registrations,
the account hashing behaviour of the previous release can be retained by setting
`security.acme.defaults.server` to `null`.
We better also check for hash consistency with that setting to avoid unexpected
account hash changes again.
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>
Odoo does not initialize the database by default,
it must be explicitly initialized for the test as written to succeed.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
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
