*** This bug is a duplicate of bug 1934393 ***
https://bugs.launchpad.net/bugs/1934393
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: nis (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
*** This bug is a duplicate of bug 1934393 ***
https://bugs.launchpad.net/bugs/1934393
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: nis (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug notification because you are a member of
*** This bug is a duplicate of bug 1934393 ***
https://bugs.launchpad.net/bugs/1934393
In order to consolidate discussion around how to best fix this, i opened
bug 1934393 and will mark this as a dup of that bug
** This bug has been marked a duplicate of bug 1934393
systemd-logind network
** Also affects: systemd via
https://github.com/systemd/systemd/issues/7074
Importance: Unknown
Status: Unknown
** Also affects: nis (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
I can confirm that installing nscd also solves the problem without
needing to fiddle with the systemd-logind restrictions. However, I am no
fan of nscd. Caching passwords for ten minutes (its default) causes all
sorts of confusion when a user changes his password, or requests a
password reset, for
** Bug watch added: Debian Bug tracker #878625
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1915502
Title:
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625
Am Do., 10. Juni 2021 um 20:23 Uhr schrieb Michael Biebl :
>
> The relevant upstream bug report afaics is
> https://github.com/systemd/systemd/issues/7074
>
> Am Do., 10. Juni 2021 um 20:14 Uhr schrieb Michael Biebl :
> >
> > Am
The relevant upstream bug report afaics is
https://github.com/systemd/systemd/issues/7074
Am Do., 10. Juni 2021 um 20:14 Uhr schrieb Michael Biebl :
>
> Am Do., 10. Juni 2021 um 14:50 Uhr schrieb Dan Streetman
> <1915...@bugs.launchpad.net>:
> >
> > Ok, so it does sound like this and bug 1916235
Am Do., 10. Juni 2021 um 14:50 Uhr schrieb Dan Streetman
<1915...@bugs.launchpad.net>:
>
> Ok, so it does sound like this and bug 1916235 are the same issue. And
> this might be 'as designed', since upstream systemd wants systemd-logind
> to talk to systemd-userdb instead of directly connecting to
Slightly odd behaviour with systemd version 245.4-4ubuntu3.6. In
/etc/systemd/system/systemd-logind.service.d/override.conf I have:
[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any
On a cold boot I don't get the user session started:
amcvey@ottub2004tst01:~$ systemctl --user
Failed
I can confirm the workaround is good for me too. I don't seem to need
the "ProtectHostname=no" option though, and in fact, the workaround in
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1916235 is also
now working as well. Looking at the test system I used today it's
running systemd
Thanks for that. I can confirm that
systemctl daemon-reload; systemctl restart systemd-logind
(in that order) avoids the need for a reboot, and for a couple of my
machines I am very grateful for this information.
--
You received this bug notification because you are a member of Ubuntu
Touch
Ok, so it does sound like this and bug 1916235 are the same issue. And
this might be 'as designed', since upstream systemd wants systemd-logind
to talk to systemd-userdb instead of directly connecting to NIS servers;
however Debian (and Ubuntu) disable systemd-userdb.
@rbalint @ahasenack @mbiebl,
A little more information, after some investigation.
The issue affects xdm logins at the console, as well as remote ssh
logins. This also means that audio at the console fails to work, as ACLs
for the console's user are not added to the audio devices.
It seem that it can be solved by putting in
Just to clarify my earlier comments, I went back and tested using sssd,
removing NIS entirely, with AD used as an RFC2307-compliant LDAP back
end. I was not able to reproduce the problem, implying that this issue
is restricted to NIS only.
--
You received this bug notification because you are a
** Also affects: systemd
Importance: Undecided
Status: New
** No longer affects: systemd
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1915502
Title:
"systemd
We are seeing the same issue with essentially the same setup (NIS for
accounts with nsswitch in compat mode, Kerberos for authentication).
We see the same pam_systemd debug message when attempting to log in as
regular/remote user:
pam_systemd(sshd:session): Failed to create session: No such
Dan, thanks for the comments, appreciate it. In reply:
Using only "compat" in /etc/nsswitch.conf is legitimate and we use it
without issue on multiple Linux distributions as well as older Ubuntu
releases. It invokes a different behaviour to using "nis", allowing
more fine grained control of who
First, from re-reading the bug description, it seems like you don't have
nis in your nsswitch.conf file? I'm not an expert in NIS config/usage,
but I think you need to add that, e.g. at *least*:
passwd: compat nis systemd
you might need to add it to group, shadow, and gshadow as well.
Second,
Below is contents of /var/log/syslog right at the point I press return
on entering the password. I've removed the systemd-resolved messages as
all they're showing is the response from the kerberos service, which is
clean.
Apr 7 12:28:45 myhostname systemd[1]: n/a: New incoming connection.
Apr
Ok I think we need to see the pam_systemd side of this then; can you add
'systemd.log_level=debug' to the boot params and reboot, and then
recreate the failure? There will be a whole lot of debug in the journal,
but it should include the pam-side failure.
--
You received this bug notification
To confirm, this is not a duplicate of bug 1916235. I see none of the
associated errors in the logs and the workaround is ineffective.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1915502
Title:
"systemd --user" fails
A good idea, but it made no difference for me. I even went a little
further and tried
[Service]
RestrictAddressFamilies=AF_INET
IPAddressAllow=any
SystemCallFilter=
ProtectSystem=off
CapabilityBoundingSet=
but still no change, even after a reboot. Logins produce the pair of
lines
Apr 5
I suspect this is a dup of bug 1916235 (or it a dup of this); have you
tried the workaround (shown below) of allowing systemd-logind network
access?
$ sudo systemctl edit systemd-logind
(opens an editor, put in the text below and save it, then reboot and retest)
[Service]
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
I think I am suffering from the same issue.
I have always run without "UsePAM yes" in sshd_config, but I recently
tried turning it on in order to get XDG_ variables set correctly and
proper systemd sessions for ssh logins.
In 18.04 it worked as expected, but in 20.04 I get
sshd[387766]:
27 matches
Mail list logo
