Forcibly restarting NSCD is unnecessary and breaks setups that use SSSD for
authentication. NSCD is capable of detecting changes to /etc/resolv.conf and
invalidating its caches internally. Restarting NSCD/SSSD breaks user name and
UID resolution.
The usage of nixpkgs.config.packageOverrides is deprecated and we do
have overlays since quite a while.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
When doing source routing/multihoming, it's practical to give names to routing
tables. The absence of the rt_table file in /etc make this impossible.
This patch recreates these files on rebuild so that they can be modified
by the user see NixOS#38638.
iproute2 is modified to look into config.networking.iproute2.confDir instead of
/etc/iproute2.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
With #36556, a check was introduced to make sure the user and group
names do not exceed their respective maximum length. This is in part
because systemd also enforces that length, but only at runtime.
So in general it's a good idea to catch as much as we can during
evaluation time, however the maximum length of the group name was set to
16 characters according groupadd(8).
The maximum length of the group names however is a compile-time option
and even systemd allows more than 16 characters. In the mentioned pull
request (#36556) there was already a report that this has broken
evaluation for people out there.
I have also checked what other distributions are doing and they set the
length to either 31 characters or 32 characters, the latter being more
common.
Unfortunately there is a difference between the maximum length enforced
by the shadow package and systemd, both for user name lengths and group
name lengths. However, systemd enforces both length to have a maximum of
31 characters and I'm not sure if this is intended or just a off-by-one
error in systemd.
Nevertheless, I choose 32 characters simply to bring it in par with the
maximum user name length.
For the NixOS assertion however, I use a maximum length of 31 to make
sure that nobody accidentally creates services that contain group names
that systemd considers invalid because of a length of 32 characters.
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #38548
Cc: @vcunat, @fpletz, @qknight
Currently broken on NixOS due to hardcoded modprobe binary path (see
bug #30756 from Oct 2017), no activity on a proposed fix for months.
As the protocol is terribly broken anyways, let's better remove it
completely, and not talk about anymore ;-)
Closes#30756.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
`nixos-generate-config` detects the `cpuFreqGovernor` suited best for my
machine, e.g. `powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";`.
However the `powerManagement` module sets a sensitive default for
`cpuFreqGovernor` using `mkDefault` to avoid breackage with older
setups. Since 140ac2f1 the `hardware-configuration.nix` sets the
gorvernor with `mkDefault` as well which causes evaluation errors if the
powermanagement module is enabled:
```
error: The unique option `powerManagement.cpuFreqGovernor' is defined multiple times, in `/home/ma27/Projects/nixos-config/hardware-configuration.nix' and `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/config/power-management.nix'.
```
Using `mkOptionDefault` rather than `mkDefault` in the powermanagement
module fixes this issue as it decreases the priority of the module and
prefers the value set in `hardware-configuration.nix`.
I have confirmed the change using the following VM declaration:
```
{
cpuFreq = { lib, ... }: {
powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";
powerManagement.enable = true;
};
}
```
- /var/run -> /run as the former is deprecated
- configure openal to use pulseaudio if pulseaudio is enabled
- configure libao to use pulseaudio if pulseaudio is enabled
Commit 987aac7 and issue #18183 were intended to fix support for other
things, but in the process, changed mdns_minimal to use the wrong return
setting, resulting in permanent failures in early boot, affecting things
like issue #30459.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This reverts commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
(cherry picked from commit 23a021d12e8f939cd0bfddb1c7adeb125028c1e3)
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
(cherry picked from commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6)
This commit was accidentally merged to 17.09 but was intended for
master. This is the cherry-pick to master.
In order for DynamicUser = true to work in services, we need the
nss-systemd module to be able to resolve the user and group names
generated dynamically.
Evaluation error introduced in a0d464033c.
If the value for timeZone is null it shouldn't be even tried to coerce
it into a string.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @joachifm
Creating and then erasing the key relies on the disk erasing data
correctly, and otherwise allows attackers to simply decrypt swap just
using "secretkey". We don't actually need a LUKS header, so we can save
ourselves some pointless disk writes and identifiability.
In addition, I wouldn't have made the awful mistake of backing up my swap partition's LUKS header instead of my zpool's. May my data rest in peace.
While systemd suggests using the pre-defined graphical-session user
target, I found that this interface is difficult to use. Additionally,
no other major distribution, even in their unstable versions, currently
use this mechanism.
The window or desktop manager is supposed to run in a systemd user service
which activates graphical-session.target and the user services that are
binding to this target. The issue is that we can't elegantly pass the
xsession environment to the window manager session, in particular
whereas the PassEnvironment option does work for DISPLAY, it for some
mysterious reason won't for PATH.
This commit implements a new graphical user target that works just like
default.target. Services which should be run in a graphical session just
need to declare wantedBy graphical.target. The graphical target will be
activated in the xsession before executing the window or display manager.
Fixes#17858.
