[Bug 1857104] New: Using FreeIPA breaks IPv4/IPv6 flags for SSH
by bugzilla＠redhat.com
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.
3 months, 2 weeks
[Bug 1853261] New: sssd fails to start on read-only filesystem
by bugzilla＠redhat.com
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 year, 3 months
[Bug 1868696] New: sssd_kcm loops on NFS server occasionally after an NFSv4.0 mount using Kerberos
by bugzilla＠redhat.com
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 year, 10 months