Since `connectionStringFile` reads the file and puts it into the
invocation of the exporter, it's part of the cmdline and thus
effectively world-readable.
Added a new `connectionEnvFile` which is supposed to be an environment
file of the form
PGBOUNCER_EXPORTER_CONNECTION_STRING=...
that will be added to the systemd service. The exporter will read the
connection string from that value.
The Rust `switch-to-configuration-ng` rewrite was carefully written
to be compatible with the original Perl script, has been checked
against NixOS VM tests, and has been available on an opt‐in basis
for testing for the 24.05 release cycle.
The next step towards replacing the Perl script entirely is to
switch it on by default so that we can get real‐world testing from
a much greater number of users. Maintaining two implementations in
parallel is becoming a burden; we are having to adjust the systemd
service activation behaviour slightly to fix a long‐standing bug,
and backporting the changes to the Perl script is an unpleasant
process. We will do it anyway to ensure that the Rust and Perl
implementations keep parity with each other throughout the 24.11
release cycle, but we think the time has come to flip the switch.
Taking this step now will give us two to three months to test this in
the wild before the 24.11 release and gain confidence that there are
no regressions. If any non‐trivial problems arise before the final
release, we will revert to the Perl implementation by default. Doing
this switch ASAP will help to disentangle any problems that might
arise from the Rust implementation from problems that arise from the
systemd service activation changes, or the upcoming switch to using
systemd in stage 1 by default.
The main concern that was raised about replacing the Perl script in the
PR that added `switch-to-configuration-ng` was that it is currently
possible to run NixOS on systems that cannot natively host a Rust
compiler. This does not apply to any platforms that have official
support from NixOS, and as far as I know we do not know of any such
systems with users that are not cross‐compiling anyway.
My understanding is that these systems are already broken by default
anyway, as `systemd.shutdownRamfs.enable` is on by default and uses
`make-initrd-ng`, which is also written in Rust. Switching the default
while keeping the Perl implementation around will give us at least
an entire release cycle to find out if there are any users that will
be affected by this and decide what to do about it if so.
There is currently one known inconsistency between
the Perl and Rust implementations, as documented in
<https://github.com/NixOS/nixpkgs/issues/312297>; the Rust
implementation has more accurate handling of failed systemd units.
We slightly adjust the semantics of `system.switch.enable{,Ng}` to
not conflict with each other, so that `system.switch.enableNg` is
on by default, but turning off `system.switch.enable` still results
in no `switch-to-configuration` implementation being used. This
won’t break the configuration of anyone who already opted in to
`system.switch.enableNg` and is probably how the option should have
worked to begin with.
ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
Prior to this contribution, the Kernel's frame buffer output
boot log wasn't visible on the graphical console.
Now, we can also test applications with graphical output that run
during the boot process.
this change fixes 2 major bugs in the endlessh-go service's firewall options:
1. prometheus port unexpectedly allowed through firewall (services.endlessh-go.openFirewall)
the description of the option is "Whether to open a firewall port for the SSH listener." however as we can see, both the ssh listener AND the prometheus listener have their ports opened. this is especially troublesome because endlessh-go (i guess as an artifact of being developed for docker) defaults the prometheus listener to 0.0.0.0.
2. the prometheus port unexpectedly allowed through firewall when prometheus is disabled (services.endlessh-go.prometheus.enable)
even when prometheus is disabled, its port is allowed through the firewall
Otherwise we get a clash when generating the initrd since the initrd tmpfiles
options create a symlink at /etc/tmpfiles.d/ and any subsequent writes inside
this directory because of initrd.systemd.contents will cause a permission denied
error.
This gives the ability to not write `NTP=` to the `timesyncd.conf` file
(servers = null) as opposed to writing `NTP=` (servers = []) which is
interpreted slightly differently by systemd:
> When the empty string is assigned, the list of NTP servers is reset,
and all prior assignments will have no effect.
Shellcheck complains:
> args=(
> ^-- SC2054 (warning): Use spaces, not commas, to separate array elements.
Add a comment disabling shellcheck in this case and annotating why.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
The inclusion of the "meta ipsec" rule in the default reverse path
filtering breaks systems not built with specific XFRM kernel config
options. Specifically CONFIG_XFRM must be set, which gets selected
by CONFIG_NFT_XFRM, which is hidden behind CONFIG_XFRM_USER.
These options are not selected by default in most defconfig's provided
by the kernel with the exception of some device-specific defconfigs.
These options are not set by the nix kernel common_config, and I would
argue that IPSec support does not belong in a minimal kernel as that
elevates its support status above other in-kernel VPN interfaces.
The contributor of this feature does not seem interested in working
towards a solution that does not break systems running kernels built
with "autoModules = false" while supporting this feature, and as this
silently breaks firewalls into an insecure state and poses an immediate
security issue I propose this be reverted until a solution that does not
break such systems is proposed.
https://github.com/NixOS/nixpkgs/pull/310857#discussion_r1742834970
Devices used as firewalls, if they do not have the required kernel
config, will fail to load the new firewall rules and will upon boot pass
traffic without any filtering into the internal network.
Devices exposed directly to the internet, after reboot, will boot
without filtering potentially exposing services not intended to be
exposed to the internet, such as databases.
The following platforms in nixpkgs appear to be impacted:
- pc_simplekernel
- pogoplug4
- sheevaplug
- zero-gravitas
- zero-sugar
- utilite
- guruplug
- beaglebone
- fuloong2f_n32
References to hardware without autoModules can be found in
nixos-hardware, as well as in active third-party repos on github.
I suspect there are other users impacted that do not have their configurations
public, as autoModules = true leads to long compile times when targeting
kernels to less standard hardware or hardware with quirks that require
patches that cannot be upstreamed.
This reverts commit 3c12ef3f21.
In d9dc50dc11 the usage of `with lib;` has
been removed from thinkfan.nix. Unfortunately, adjusting the check line
and its usage of the functions all,id,zipListsWith has not been updated
resulting in evaluation errors complaining about "undefined variable".
Update: partly covered in 0646a0771b of #339084
rel: #208242
Untrimmed mbrola-voices is leaking into the installer images again.
Instead of trying to manually squash every path it could possibly
leak through, use a very big hammer.
Exposes all currently available command-line arguments that were
missing, including some that were impossible to use with the catch-all
option `extraArgs` alone, requiring changes to other parts of the
system.
Those are now all self-contained in the module.
The service now uses systemd's `DynamicUsers`.
