Sssd-maintainers August 2020

sssd-maintainers@lists.fedoraproject.org

1 participants
4 discussions

[Bug 1857104] New: Using FreeIPA breaks IPv4/IPv6 flags for SSH
by bugzilla＠redhat.com 03 Feb '22

03 Feb '22

https://bugzilla.redhat.com/show_bug.cgi?id=1857104 Bug ID: 1857104 Summary: Using FreeIPA breaks IPv4/IPv6 flags for SSH Product: Fedora Version: 32 Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: ossman(a)cendio.se QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: If a client is configured using ipa-client-install then the -4 and -6 flags stop working for ssh. Version-Release number of selected component (if applicable): Doesn't matter. Seen on RHEL 6 through 8, and on current Fedora. How reproducible: 100% Steps to Reproduce: 1. ipa-client-install 2. ssh -4 host.example.com Actual results: Connected via IPv6 Expected results: Connected via IPv4 Additional info: The bug is that sss_ssh_knownhostsproxy is configured on the client and that command doesn't respect the flags given to ssh. The issue affects all hosts, not just those part of the same FreeIPA domain. A practical effect of this is that connections get rejected or misbehave because of IP based rules in place for this connection. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 17

[Bug 1853261] New: sssd fails to start on read-only filesystem
by bugzilla＠redhat.com 30 Nov '21

30 Nov '21

https://bugzilla.redhat.com/show_bug.cgi?id=1853261 Bug ID: 1853261 Summary: sssd fails to start on read-only filesystem Product: Fedora Version: rawhide Status: NEW Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: zbyszek(a)in.waw.pl QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: sssd refuses to start when /var/log is read-only. It is obviously a problem when trying to recover from a file system issue. Since logging is non-essential, sssd should just continue. At most is should emit a warning. $ touch /var/tmp/foo touch: cannot touch '/var/tmp/foo': Read-only file system $ sudo systemctl start sssd.service Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xe" for details. [fedora@workstation-uefi ~]$ Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:46 CEST): sssd[900]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[903]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[905]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[906]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02 11:16:47 CEST): sssd[907]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only file system] We see multiple issues here: - the main one is that sssd should not fail to start as described above - but also, why is sssd not just logging to the journal? Why is it spamming with broadcast messages? If sssd would just log to the journal like any modern service, all those problems would be avoided. Version-Release number of selected component (if applicable): sssd-2.3.0-2.fc33.x86_64 How reproducible: Deterministic Steps to Reproduce: 1. Make /var/log read-only, either by not remounting the filesystems rw, or by using udev.blockdev-read-only with systemd-246+ 2. Try to start sssd -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 18

[Bug 1868696] New: sssd_kcm loops on NFS server occasionally after an NFSv4.0 mount using Kerberos
by bugzilla＠redhat.com 25 May '21

25 May '21

https://bugzilla.redhat.com/show_bug.cgi?id=1868696 Bug ID: 1868696 Summary: sssd_kcm loops on NFS server occasionally after an NFSv4.0 mount using Kerberos Product: Fedora Version: 32 Hardware: All OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: chuck.lever(a)oracle.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, jhrozek(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, rharwood(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Description of problem: Multi-homed Fedora 32 NFS client and server, both with keytabs. Sometimes after performing an NFSv4.0 mount, the sssd_kcm daemon on the server runs at 100% and fills up the sssd_kcm.log file (and eventually, the root partition). (2020-08-10 15:03:04:680265): [kcm] [kcm_input_parse] (0x1000): Received message with length 0 (2020-08-10 15:03:04:680284): [kcm] [kcm_input_parse] (0x0020): Illegal zero-length message (2020-08-10 15:03:04:680302): [kcm] [kcm_recv] (0x0010): Failed to parse data (74, Bad message), aborting client (2020-08-10 15:03:04:680319): [kcm] [kcm_reply_error] (0x0040): KCM operation returs failure [74]: Bad message (2020-08-10 15:03:04:680353): [kcm] [kcm_failbuf_construct] (0x1000): Sent reply with error -1765328188 Version-Release number of selected component (if applicable): sssd-kcm-2.3.1-2.fc32.x86_64 How reproducible: Happens every second or third mount operation. Steps to Reproduce: 1. Set up NFS client and server with keytabs 2. Repeat: "mount -o vers=4.0,sec=sys" / do some operations / umount 3. Watch the server with "top" Actual results: Sometimes sssd_kcm goes to 100% of a CPU and must be killed. Expected results: No looping. Additional info: The NFSv4.0 backchannel, in this case, is secured with GSS krb5i. It appears that gssd on the server is accessing the Kerberos ticket cache while setting up the backchannel, and sometimes this triggers the kcm loop. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

1 3

[Bug 1785229] Auth fails with "Could not start TLS encryption. unknown error"
by bugzilla＠redhat.com 19 Aug '20

19 Aug '20

https://bugzilla.redhat.com/show_bug.cgi?id=1785229 VG <gopalv(a)us.ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gopalv(a)us.ibm.com --- Comment #20 from VG <gopalv(a)us.ibm.com> --- Do we know if there is on openldap issue related to this? -- You are receiving this mail because: You are the assignee for the bug.

1 0

2024

2023

2022

2021

2020

Sssd-maintainers August 2020