The following changes are included:
1) install user unit files from upstream dbus
2) use absolute paths to config for --system and --session instances
3) make socket activation of user units configurable
There has been a number of PRs to address this, so this one does the
bare minimum, which is to make the functionality available and
configurable but defaults to off.
Related PRs:
- #18382
- #18222
(cherry picked from commit f7215c9b5b)
Signed-off-by: Domen Kožar <domen@dev.si>
KDM and LightDM (at least with autologin) call the xsession-script with
two arguments: the first is the path of the xsession script itself,
while the second one are the actual arguments. The line to re-exec the
script under systemd-cat only forwarded a single argument, therefore
breaking LightDM and KDM login. This commit fixes the issue by always
forwarding all the arguments.
When displaying a warning about a removed Option we should always
include reasoning why it was removed and how to get the same
functionality without it.
Introduces such a description argument and patches occurences (mostly
with an empty string).
startGnuPGAgent: further notes on replacement
... rather than ~/.xsession-errors. It might make sense to make this
the default, in order to eliminate ad hoc, uncentralised, poorly
discoverable log files.
This ensures that "journalctl -u display-manager" does what you would
expect in 2016. However, the main reason is to ensure that our VM
tests show the output of the X server.
A slight problem is that with KDE user switching, messages from the
various X servers end up in the same place. However, that's an
improvement over the previous situation, where the second X server
would overwrite the /var/log/X.0.log of the first. (This was caused by
the fact that we were passing a hard-coded value for -logfile.)
`dbus-launch` is executed early in the script, before desktop managers
had a chance to setup the environment. If DBus activation is used,
applications launched by this may therefore lack necessary environment
variables. This patch sends the complete environment to DBus after
launching the desktop manager.
GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no
longer requires (or even supports) the "start everything as a child of the
agent" scheme we've implemented in NixOS for older versions.
To configure the gpg-agent for your X session, add the following code to
~/.xsession or some other appropriate place that's sourced at start-up:
gpg-connect-agent /bye
GPG_TTY=$(tty)
export GPG_TTY
If you want to use gpg-agent for SSH, too, also add the settings
unset SSH_AGENT_PID
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"
and make sure that
enable-ssh-support
is included in your ~/.gnupg/gpg-agent.conf.
The gpg-agent(1) man page has more details about this subject, i.e. in the
"EXAMPLES" section.
This reverts most of 89e983786a, as those references are sanitized now.
Fixes#10039, at least most of it.
The `sane` case wasn't fixed, as it calls a *function* in pkgs to get
the default value.
- added numlock on boot switch
- simply add :
services.xserver.displayManager.sddm.autoNumlock = true;
to configuration.nix and sddm will start
with numlock enabled.
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
This reverts most of 89e983786a, as those references are sanitized now.
Fixes#10039, at least most of it.
The `sane` case wasn't fixed, as it calls a *function* in pkgs to get
the default value.
- if xserver.tty and/or display are set to null, then don't specify
them, or the -logfile argument in the xserverArgs
- For lightdm, we set default tty and display to null and we determine
those at runtime based on arguments passed. This is necessary because
we run multiple X servers so they can't all be on the same display
These options allow setting the start and stop scripts for the display
manager. Making these configurable is necessary to allow some hardware
configurations. Upstream ships empty scripts by default, anyway.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
As discussed on https://github.com/NixOS/nixpkgs/pull/9642, the option
is not necessary because all desktop managers already stopped handling
it (and delegated to systemd).
Or else users may see this unfriendly message:
error: cannot coerce null to a string, at .../nixos/modules/services/x11/display-managers/gdm.nix:107:49
Changes the option and explicitely sets it for each desktopManager.
Reasoning: Currently,
services.xserver.displayManager.desktopManagerHandlesLidAndPower is set
to true by default. This creates a problem for users without desktop
environments activated, since lid management simply doesn't work
(and they have to be lucky to find this option).
See issue #9671
This is needed by most window managers. Desktop environments
usually launch dbus-launch if a session hasn't been started yet
so this shouldn't hurt. The worst it can happen is that one
dbus session will be unused in case it's started twice.
The GDM change is backported from recent gdm.
With this patch, systemd-inhibit outputs a descriptive message when
desktopManagerHandlesLidAndPower=true (the default).
Before the patch:
$ systemd-inhibit
Who: /nix/store/[...]-xsession [...] (UID 1000/cassou, PID 18561/systemd-inhibit)
What: handle-power-key:handle-lid-switch
Why: Unknown reason
Mode: block
After the patch:
$ systemd-inhibit
Who: /nix/store/[...]-xsession [...] (UID 1000/cassou, PID 18561/systemd-inhibit)
What: handle-power-key:handle-lid-switch
Why: See NixOS configuration option 'services.xserver.displayManager.desktopManagerHandlesLidAndPower' for more information.
Mode: block
This was lost back in
ffedee6ed5. Getting this to work is
slightly tricky because ssh-agent runs as a user unit, and so doesn't
know the user's $DISPLAY.
Any reasonably new version of fontconfig does search that path by default,
and setting this globally causes problems, as 2.10 and 2.11 need
incompatible configs.
Tested: slim+xfce desktop, chrootenv-ed steam.
I have no idea why we were setting the global variable;
e.g., neither Fedora nor Ubuntu does that.
Option defaults should not refer to store paths, because they cause
the manual to be rebuilt gratuitously. It's especially bad to refer to
a highly variable path like a computed configuration file.
Should bring most of the examples into a better consistency regarding
syntactic representation in the manual.
Thanks to @devhell for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has some advantages:
* You get ssh-agent regardless of how you logged in. Previously it was
only started for X11 sessions.
* All sessions of a user share the same agent. So if you added a key
on tty1, it will also be available on tty2.
* Systemd will restart ssh-agent if it dies.
* $SSH_AUTH_SOCK now points to the /run/user/<uid> directory, which is
more secure than /tmp.
For bonus points, we should patch ssh-agent to support socket-based
activation...
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
This reverts commit f7d5e83abb. It
breaks the Firefox and Xfce tests:
in job ‘tests.firefox.x86_64-linux’:
cannot coerce a boolean to a string
in job ‘tests.xfce.x86_64-linux’:
infinite recursion encountered
The difference between xsession and xprofile is that xsession is exec'd and xprofile is sourced.
So with xprofile all commands after sourcing will still be exectued. This allows for instance
autostarting of applications while configuring the start of a window manager via configuration.nix.
That is, you can say
security.pam.services.sshd = { options... };
instead of
security.pam.services = [ { name = "sshd"; options... } ];
making it easier to override PAM settings from other modules.
