3:30 a.m.
Hi,
might be https://github.com/SSSD/sssd/issues/6505 /
https://bugzilla.redhat.com/show_bug.cgi?id=2143159
(difficult to confirm without coredump/backtraces).
Should be fixed in C9S/9.2
(
https://composes.stream.centos.org/development/latest-CentOS-Stream/compo...
...)
On Tue, Jan 24, 2023 at 10:13 PM Prentice Bisbal <pbisbal(a)pppl.gov> wrote:
sssd-users,
I'm having an odd problem with autmount, that seems to be specific to
using sssd for autofs. The operating system is Springdale Open
Enterprise Linux 9.1, which is a rebuild of RHEL maintained by Princeton
University, so it should be 100% bug compatible with RHEL (and Rocky).
My configuration is using Kerberos for auth, and LDAP directory
services. When my nsswitch.conf entry for automount looks like this:
automount: sss files
Testing the configuration of automount/sssdwith 'automount -m' leads to
a segfault:
# automount -m
autofs dump map information
===========================
global options: none configured
Mount point: /p
source(s):
Segmentation fault (core dumped)
If I change nsswitch.conf to use files only or use ldap like this:
automount: files
or this:
automount files ldap
Everything works as expected. LDAP searches using ldapsearch works just
fine, and using getent to get user and group information (which is
stored in LDAP) works just fine. I've increased the debugging levels
for the relevant SSSD daemons:
# egrep '^\[|debug_level' /etc/sssd/sssd.conf
[domain/PPPL]
debug_level = 8
[sssd]
debug_level = 8
[nss]
debug_level = 8
[pam]
[autofs]
debug_level = 8
Looking in the related log files the logs for my default domain show
that it is getting information from the LDAP directory, and then it
fails saying it can't contact the LDAP server:
(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/lldap:ou\3Dauto.local\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [sysdb_entry_attrs_diff] (0x0400):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
differs, reason: ts_cache doesn't trace this type of entry.
(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [fo_resolve_service_send] (0x0100):
[RID#6] Trying to resolve service 'LDAP'
(2023-01-24 16:01:31): [be[default]] [get_server_status] (0x1000):
[RID#6] Status of server 'host-a.pppl.gov' is 'working'
(2023-01-24 16:01:31): [be[default]] [get_port_status] (0x1000): [RID#6]
Port status of port 389 for server 'host-a.pppl.gov' is 'not working'
Not only do the earlier log file entries show that sssd_bes actually
getting data from LDAP before it reports an error, but I can run queries
from this machine to our LDAP server with 'ldapsearch', and all the
other computers in our environment, which are running CentOS 7 or Rocky
8 using the same configuration files.
--
Prentice
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue