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/compose/BaseOS/x86_64/os/Packages/sssd-2.8.2-2.el9.x86_64.rpm ...) On Tue, Jan 24, 2023 at 10:13 PM Prentice Bisbal <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
