We introduced the gdm-fingerprint.pam in 9d41fe6fcc.
We used the [upstream Arch config] as a template, which contains an extended control field that jumps over **one** immediately-following `auth` rule unless `pam_gdm.so` succeeds.
But we decided to not include `pam_gnome_keyring.so` so there was no rule to skip over, resulting in a broken control flow and the PAM module failing with “PAM bad jump in stack”, breaking the fingerprint authentication in GDM.
Let’s actually add `pam_gnome_keyring.so`, like the Arch config does. Because we are creating the PAM file using the `text` option, `security.pam.services.gdm-fingerprint.enableGnomeKeyring` does not do anything so we need to do it manually.
For the case where gnome-keyring is not enabled, we could add a no-op rule like `optional pam_permit.so` after `pam_gdm.so` so that the branching always has something to jump over but it will be simpler to just make the both conditional. There are no further `auth` rules that could benefit from `pam_gdm.so` doing something so it should be fine.
Unlike in Arch, we are not going to invoke `pam_gnome_keyring.so` in a `session` rule since that is already done by the included `login` module.
[upstream Arch config]: 81ee658c11/data/pam-arch/gdm-fingerprint.pam
The `optional pam_permit.so` comes from the [upstream Arch config] we used as a template in 9d41fe6fcc. But I do not think it does anything in this position – see also the discussion at https://bbs.archlinux.org/viewtopic.php?id=245892 – so let’s just remove it.
Let’s also add a comment about disabling `fprintAuth` and a blank line for clarity.
[upstream Arch config]: 81ee658c11/data/pam-arch/gdm-fingerprint.pam
`gdm-autologin` and `gdm-password` PAM modules are defined using the `text` option, so the option here is a no-op.
Furthermore, `gdm-password` already includes `login` for all module types,
and that invokes `pam_gnome_keyring.so` in the same way Arch’s `gdm-password` module would:
81ee658c11/data/pam-arch/gdm-password.pam
This reverts commit c24c7933ba.
Previously, the blocky package was hardcoded to the one in pkgs. This
change allows to set it, so the user can configure the blocky service to
run blocky from nixpkgs-unstable, for example.
I am the singular maintainer for these packages. They are difficult to
maintain and are going to start to bitrot pretty much as soon as BMD
releases new software versions. Therefore, I am not only removing myself
as the maintainer but dropping them entirely.
* Syncthing: implemented folder type
* Syncthing: fix syntax (via @johnhamelink )
This commit should be rebased/squashed into the previous one if ofborg cleares it!
Co-authored-by: John Hamelink <me@johnhame.link>
---------
Co-authored-by: John Hamelink <me@johnhame.link>
This helps supporting sudo-rs, which currently does not implement the
--preserve-env flag and probably won't so in the foreseeable future [1].
The replacement just sets both environment variables behind the sudo
invocation with env, as sudo-rs also doesn't implement env var lists.
The OC_PASS variable is dropped, as it is seemingly unused and would
leak through this approach through /proc.
[1] https://github.com/memorysafety/sudo-rs/issues/129
I guess my time has come as well...
With this commit, I'm not just dropping my maintainer entry, but I'm also
resigning from my duties as a board observer and NixCon project lead.
I also terminated my Summer of Nix contract today.
I'll also stop hosting the local NixOS meetup.
The only "project" I'll finish under the NixOS Foundation umbrella is
Google Summer of Code because the mentees aren't even remotely
responsible for why I'm leaving, and it would be unfair to leave them
hanging.
I'm grateful for all the things I was able to learn, for all the experiences
I could gather, and for all the friends I made along the way.
NixOS is what makes computers bearable for me, so I'll go and work on
some fork (*something something* you always meet twice in life).
This reverts commit dbe2325603, which
was mistaken: `/` matches exactly the same things matched by `\/` but
without the warning.
Fixes#316561.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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.
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
This contribution extends the k3s module to
enable the usage of Helm charts and container
images in air-gapped environments. Additionally,
the manifests option allows to specify arbitrary
manifests that are deployed by k3s automatically.
It is now possible to deploy Kubernetes workloads
using the k3s module.
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
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")
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.
