this renders the same in the manpage and a little more clearly in the
html manual. in the manpage there continues to be no distinction from
regular text, the html manual gets code-type markup (which was probably
the intention for most of these uses anyway).
According to pulseaudio(1), a system wide pulseaudio instance
can only be accessed by members of the `pulse-access` group.
This name seems to be hardcoded in
pulseaudio -- I didn't find any switch to change it.
We need to define the group so users can connect to the deamon.
This commit also fixes the systemwide pulseaudio vm test:
Previously, the test user `alice`
was just a member of the `audio` group.
This blocked access to the daemon and failed the test.
The commit changes the group assignment and fixes the vm test.
now nix-doc-munge will not introduce whitespace changes when it replaces
manpage references with the MD equivalent.
no change to the manpage, changes to the HTML manual are whitespace only.
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
we can't embed syntactic annotations of this kind in markdown code
blocks without yet another extension. replaceable is rare enough to make
this not much worth it, so we'll go with «thing» instead. the module
system already uses this format for its placeholder names in attrsOf
paths.
markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
The suspend-then-hibernate functionality is implemented by systemd in
the suspend-then-hibernate.target, separately from suspend.target and
hibernate.target. Thus post-resume would not run after resuming from
suspend-then-hibernate.
Fix this by explicitly making post-resume run after
suspend-then-hibernate.
It was never meant to be used for anything other than testing
and setting it globally can cause weird loops in GTK-based portals,
where the portal will end up waiting for itself until it times out.
https://github.com/NixOS/nixpkgs/issues/135898
Or it can mess up fonts:
https://github.com/NixOS/nixpkgs/issues/155291#issuecomment-1166199585
Having the option in NixOS makes it look like it is okay or even
desirable to enable, when in fact it is a hack that can subtly break apps.
Some apps allow opting into using portal-based APIs, e.g. for Firefox,
you can set `widget.use-xdg-desktop-portal.file-picker` to `1` in about:config.
Otherwise, you can set the `GTK_USE_PORTAL` environment variable to 1
for individual apps.
People who really want it and aware of the downsides can just set
`environment.sessionVariables.GTK_USE_PORTAL = "1";` NixOS option
directly to set the environment variable globally.
More nixpkgs code such as `boot.initrd.systemd.emergencyAccess` defines
options that takes hashed passwords, so move the type definition from
modules/ into lib/.
The type definition itself stays unchanged.
`console.{font,keyMap}` may be a path or a string to a store path,
which should be added to initrd for `systemd-vconsole-setup` before
the prompt for the LUKS password.
For systems without internet connections, it doesn't make sense to
require the existence of an /etc/resolv.conf file to disable
resolvconf, so let's expose networking.resolveconf.enable as a public
option that can be set to false.
Previously we allocated subuids automatically for all normal users.
Make this explicitly configurable, so that one can use this for system
users too (or explicitly disable for normal users). Also don't allocate
automatically by default if a user already has ranges specified statically.
Just setting the XKB_CONFIG_ROOT should be enough, so we don't need to
rebuild the xserver, xkbcomp and other packages anymore.
However, the variable has to be passed explicitely to scripts running at
build time: in particular to xkbvalidate and xkb-console-keymap.
Recommend to use services.xserver.dpi option instead. Mention in the
documentation that it's a sledgehammer approach and monitor settings should be
used instead.
Also don't set DPI in fontconfig settings; fontconfig should use Xft settings
by default so let's not override one value in multiple places. For example,
user now can set DPI via ~/.Xresources properly.
Most desktop environments manage the cursor using the Xcursor library
by default; this comes with scalable or multiple-sized cursor themes.
However, when running just a simple WM (twm, bspwm, ...) the cursor
handling is left to the X server, which uses a very simple fixed bitmap
font (this is called a "core" cursor). The font is uncomfortably small
on a high DPI display and must be replaced with a saner default.
Up until recently[1] it used to be possible to change the font on the
xserver command line, however the font name is now hardcoded. It's still
possible to change it, though: here I override the `fontcursormisc`
package and set an alias that points to a vector variant of the original
cursor font. The font size is set to match the standard cursor
dimensions on a 96dpi display. It's not perfect but it's a very simple
and effective solution.
[1]: 56ea4c769c
This change makes it so that accessing config.users.groups.*.members isn't
empty by default, but instead contains all the users whose `extraGroups`
includes that group, allowing fancy things like
{ config, ... }: {
users.groups.libvirt.members = config.users.groups.wheel.members;
}
to add all users in the wheel group to the libvirt group
- The order of NSS (host) modules has been brought in line with upstream
recommendations:
- The `myhostname` module is placed before the `resolve` (optional) and `dns`
entries, but after `file` (to allow overriding via `/etc/hosts` /
`networking.extraHosts`, and prevent ISPs with catchall-DNS resolvers from
hijacking `.localhost` domains)
- The `mymachines` module, which provides hostname resolution for local
containers (registered with `systemd-machined`) is placed to the front, to
make sure its mappings are preferred over other resolvers.
- If systemd-networkd is enabled, the `resolve` module is placed before
`files` and `myhostname`, as it provides the same logic internally, with
caching.
- The `mdns(_minimal)` module has been updated to the new priorities.
If you use your own NSS host modules, make sure to update your priorities
according to these rules:
- NSS modules which should be queried before `resolved` DNS resolution should
use mkBefore.
- NSS modules which should be queried after `resolved`, `files` and
`myhostname`, but before `dns` should use the default priority
- NSS modules which should come after `dns` should use mkAfter.
The attributes got renamed in PR #126440 and in some places this caused
evaluation errors, e.g. the tarball job was saying (locally)
> attribute 'alsaUtils' missing, at /build/source/nixos/modules/services/audio/alsa.nix:6:4
and I suspect that trunk-combined jobset's failure to evaluate was also caused.
Things will get quite broken if an /etc/passwd entry contains a
colon (which terminates a field), or a newline (which terminates a
record). I know because I just accidentally made a user whose home
directory path contained a newline!
So let's make sure that can't happen.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
This cropped up, because I have a set-up where my work username is
different to my home desktop username, and I am using a parameterized
config for both, so I have something akin to
config.users.users.default-user = ...;
and using
config.users.users.default-user.{name, home}
in certain places to cope with this. Noticed my home-manager bought in
packages (which use the users.users.<name>.packages hence NixOS issue
not home-manager) weren't present.
It's a dull and boring day, it's cold outside and I'm stuck at home: let
me tell you the story of systemd-vconsole-setup.
In the beginnings of NixOS[1], systemd-vconsole-setup was a powerful
sysinit.target unit, installed and running at boot to set up fonts
keyboard layouts and even colors of the virtual consoles. If needed, the
service would also be restarted after a configuration change, consoles
were happy and everything was good, well, almost.
Since the service had no way to specify the dependency "ttys are ready",
modesetting could sometimes happen *after* systemd-vconsole-setup had
started, leaving the console in a broken state. So abbradar worked
around that by putting a systemd-udev-settle `After=`.
In the meanwhile, probably realizing their mistake, systemd added a
shiny udev rule to start the systemd-udev-settle at the right time[2].
However, the rule bypassed systemd by directly running the binary
`systemd-udev-settle`, and the service - though still installed - fell
into disuse.
Two years would pass before a good samaritan, seeing the poor jobless
systemd-udev-settle service, decided to give it the coup de grâs[3] by
unlisting it from the installed units.
This, combined with another bug, caused quite a commotion[4] in NixOS;
to see why remember the fact that `WantedBy=` in upstream units doesn't
work[5], so it had to be added manually in cc542110, but while systemd
removed it, the NixOS unit continued to install and restart the service,
making a lot of fuss when switching configuration.
After at least thee different tentative fixes, deedrah realised[6] what
the root cause was and fpletz put the final nail[7] in the coffin of
systemd-udev-settle. The service would never see the light of a boot
again, NixOS would not restart it all the time but thanks to udev
consoles would still get their pretty fonts and playful colors.
The En..
..no, wait! You should ask what came of systemd-udev-settle, first.
And why is the service even around if udev is doing all the work?
Udev-settle, like the deceitful snake that he is, laid hidden for years.
He looks innocuous doesn't it? A little hack. Only until it leaves his
den and a poor user[8] drops dead. Obviously, it serves no purpose, as
the service is not part of the boot process anymore, so let's remove it
for good!
About the service, it may not be useful at boot, but it can be started
to pick up changes in vconsole.conf and set the consoles accordingly.
But wait, this doesn't work anymore: the service is never started at
boot (remember f76d2aa6), so switch-to-configuration.pl will not restart
it. Fortunately it can be repaired: here I install a new unit which
does *nothing* on start, but restarts the real service when reloaded.
This perfectly reproduces the original behavior, hopefully without the
original bugs too.
The End?
[1]: cc54211069
[2]: f6ba8671d8 (diff-84849fddcef81458f69725dc18c6614aade5c4f41a032b6908ebcf1ee6740636)
[3]: 8125e8d38e
[4]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470
[5]: https://github.com/NixOS/nixpkgs/issues/81138
[6]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470#issuecomment-330930456
[7]: f76d2aa6e3
[8]: https://github.com/NixOS/nixpkgs/issues/107341
configuration.nix(1) states
users.extraUsers.<name>.createHome
[...] If [...] the home directory already exists but is not
owned by the user, directory owner and group will be changed to
match the user.
i.e. ownership would change only if the user mismatched; the code
however ignores the owner, it is sufficient to enable `createHome`:
if ($u->{createHome}) {
make_path($u->{home}, { mode => 0700 }) if ! -e $u->{home};
chown $u->{uid}, $u->{gid}, $u->{home};
}
Furthermore, permissions are ignored on already existing directories and
therefore may allow others to read private data eventually.
Given that createHome already acts as switch to not only create but
effectively own the home directory, manage permissions in the same
manner to ensure the intended default and cover all primary attributes.
Avoid yet another configuration option to have administrators make a
clear and simple choice between securely managing home directories
and optionally defering management to own code (taking care of custom
location, ownership, mode, extended attributes, etc.).
While here, simplify and thereby fix misleading documentation.
Only set Before=display-manager.service if it is actually present.
On headless systems, `systemctl list-units --state not-found` will
otherwise show display-manager.service.
Reported-In: https://github.com/NixOS/nixpkgs/issues/88597
This allows capping the total amount of memory that will be used for
zram-swap, in addition to the percentage-based calculation, which is
useful when blanket-applying a configuration to many machines.
This is based off the strategy used by Fedora for their rollout of
zram-swap-by-default in Fedora 33
(https://fedoraproject.org/wiki/Changes/SwapOnZRAM), which caps the
maximum amount of memory used for zram at 4GiB.
In future it might be good to port this to the systemd zram-generator,
instead of using this separate infrastructure.
This attribute is a generalized version of cryptHomeLuks for creating an
entry in /etc/security/pam_mount.conf.xml. It lets the configuration
control all the attributes of the <volume> entry, instead of just the
path. The default path remains the value of cryptHomeLuks, for
compatibility.
This reverts commit fb6d63f3fd.
I really hope this finally fixes#99236: evaluation on Hydra.
This time I really did check basically the same commit on Hydra:
https://hydra.nixos.org/eval/1618011
Right now I don't have energy to find what exactly is wrong in the
commit, and it doesn't seem important in comparison to nixos-unstable
channel being stuck on a commit over one week old.
- Fix wrong order in which font indexes are created
mkfontdir requires the file fonts.scale to consider scalable fonts,
thus, mkfontscale should be run before
- Search more font formats, in particular, bit-mapped formats
Having the .tmp suffix is broken w.r.t. to multiple writers,
as they would overwrite existing files. using the atomic flag
will make write_file to create a unique temporary file it gets renamed
to its target.
This hook moves systemd user service file from `lib/systemd/user` to
`share/systemd/user`. This is to allow systemd to find the user
services when installed into a user profile. The `lib/systemd/user`
path does not work since `lib` is not in `XDG_DATA_DIRS`.
This fixes the case when Jack Audio Daemon is running
as a service via `services.jack.jackd` and Pulseaudio
running as a *user* service.
Two issues prevented connecting `pulse` with `jackd`:
* Missing `JACK_PROMISCUOUS_SERVER` environment variable for `pulse` user service,
resulting in `pulse` trying to access `jackd` as if it was running as part of
the users session.
* `jackd` not being able to access socket created by `pulse` due to socket
created using user ID and `users` group. Change allows `jackd` to access
the socket created by `pulse` correctly.
`pulse` now also autoloads `module-jack-sink` and `module-jack-source`
if `services.jack.jackd.enable` is set.
The default `pulse` package is now set to `pulseaudioFull` automatically
if `services.jack.jackd.enable` is set.
readd perl (used in shell scripts), rsync (needed for NixOps) and strace (common debugging tool)
they where previously removed in https://github.com/NixOS/nixpkgs/pull/91213
Co-authored-by: Timo Kaufmann <timokau@zoho.com>
Co-authored-by: 8573 <8573@users.noreply.github.com>
The incompatibility does not seem to exist any more: programs linked against fc 2.12
on fc 2.14 system seem to at least display text, even while printing tons of errors
(as long as you generate fc cache manually), and same thing the other way around.
Hopefully it will not be an issue in the future.
In some tests, e.g. -f nixos/release.nix tests.simple.x86_64-linux
we use noXlibs and qemu.ga. Now that output is tiny but to get it
a full qemu build is done, and some dependencies like gtk3 won't build
with noXlibs due to their dependencies being too stripped down.
Therefore let's reduce qemu features in noXlibs case.
The `sdlSupport = false;` part probably wasn't needed,
but I added it for consistency.
Turns out lot of software (including Chromium) use bundled fontconfig
so we either need to wrap every one of those, or re-introduce the global unversioned config.
The latter is easier but weakens hermetic configs. But perhaps those are not really worth the effort.
This allows disabling users.mutableUsers without configuring any
authentication mechanisms (passwords, authorized SSH keys) other than
Google OS Login.
This is required by (among others) Podman to run containers in rootless mode.
Other distributions such as Fedora and Ubuntu already set up these mappings.
The scheme with a start UID/GID offset starting at 100000 and increasing in 65536 increments is copied from Fedora.
Falling back to unversioned `/etc/fonts/conf.d` when versioned one does not exist
is problematic since it only occurs on non-NixOS systems and those are likely
to have a different version of fontconfig. When those versions use incompatible
elements in the config, apps using fontconfig will crash.
Instead, we are now falling back to the in-package `fonts.conf` file that loads
both the versioned global `conf.d` directory and the in-package `conf.d` since using
upstream settings on non-NixOS is preferable to not being able to use apps there.
In fact, we would not even need to link `fonts.conf`, as the in-package `fonts.conf`
will be always used unless someone creates the global one manually (the option is still
retained if one wants to write a custom NixOS module and to avoid unnecessary stat call on NixOS).
Additionally, since the `fonts.conf` will always load `conf.d` from the package, we no longer
need to install them to sytem `/etc` in the module. This needed some mucking with `50-user.conf`
which disables configs in user directories (a good thing IMO, NixOS module will turn it back on)
but otherwise, it is cleaner. The files are still prioritized by their name, regardless of their location.
See https://github.com/NixOS/nixpkgs/pull/73795#issuecomment-634370125 for more information.
This explanation was contained in the description of
security.initialRootPassword but got lost when it was deprecated
a long ago (f496c3c) and removed.
This option has been deprecated for a long time because is redundant
(users.users.root.initialHashedPassword exists).
Moreover, being of type string, it required to handle the special value
"!" separately, instead of using just `null`.
This explains the
# Allow the user to log in as root without a password.
users.users.root.initialHashedPassword = "";
that the NixOS installer live systems use in
`profiles/installation-device.nix`.
This fixes the output of "hostname --fqdn" (previously the domain name
was not appended). Additionally it's now possible to use the FQDN.
This works by unconditionally adding two entries to /etc/hosts:
127.0.0.1 localhost
::1 localhost
These are the first two entries and therefore gethostbyaddr() will
always resolve "127.0.0.1" and "::1" back to "localhost" [0].
This works because nscd (or rather the nss-files module) returns the
first matching row from /etc/hosts (and ignores the rest).
The FQDN and hostname entries are appended later to /etc/hosts, e.g.:
127.0.0.2 nixos-unstable.test.tld nixos-unstable
::1 nixos-unstable.test.tld nixos-unstable
Note: We use 127.0.0.2 here to follow nss-myhostname (systemd) as close
as possible. This has the advantage that 127.0.0.2 can be resolved back
to the FQDN but also the drawback that applications that only listen to
127.0.0.1 (and not additionally ::1) cannot be reached via the FQDN.
If you would like this to work you can use the following configuration:
```nix
networking.hosts."127.0.0.1" = [
"${config.networking.hostName}.${config.networking.domain}"
config.networking.hostName
];
```
Therefore gethostbyname() resolves "nixos-unstable" to the FQDN
(canonical name): "nixos-unstable.test.tld".
Advantages over the previous behaviour:
- The FQDN will now also be resolved correctly (the entry was missing).
- E.g. the command "hostname --fqdn" will now work as expected.
Drawbacks:
- Overrides entries form the DNS (an issue if e.g. $FQDN should resolve
to the public IP address instead of 127.0.0.1)
- Note: This was already partly an issue as there's an entry for
$HOSTNAME (without the domain part) that resolves to
127.0.1.1 (!= 127.0.0.1).
- Unknown (could potentially cause other unexpected issues, but special
care was taken).
[0]: Some applications do apparently depend on this behaviour (see
c578924) and this is typically the expected behaviour.
Co-authored-by: Florian Klink <flokli@flokli.de>
