Once you report the bug do you mind posting a link to the Bugzilla entry here for my curiosity? > On 23 Aug 2019, at 15:07, DaV <snowfrs@xxxxxxxxx> wrote: > > William, > YES. The most simple way is adding cname ds.example.com to tc-389ds-1.example.com on DNS Server. > > Sincerely, > -- > DaV > > On Fri, Aug 23, 2019, at 13:05, William Brown wrote: >> Great, the issue is certainly in SSSD truncating the ldap URI then. I'd >> report the issue on the Red Hat Bugzilla against RHEL 6, report all the >> details of the rpm, logs, nsswitch.conf and sssd.conf. The SSSD team is >> pretty responsive, so I hope they can help you fix it. In the mean time >> you have also found a possible work around so you have a way around it. >> >> Happy to have helped! >> >>> On 23 Aug 2019, at 15:03, DaV <snowfrs@xxxxxxxxx> wrote: >>> >>> Hi William >>> >>> The nsswitch on my client is: >>> # >>> # /etc/nsswitch.conf >>> # >>> # An example Name Service Switch config file. This file should be >>> # sorted with the most-used services at the beginning. >>> # >>> # The entry '[NOTFOUND=return]' means that the search for an >>> # entry should stop if the search in the previous entry turned >>> # up nothing. Note that if the search failed due to some other reason >>> # (like no NIS server responding) then the search continues with the >>> # next entry. >>> # >>> # Valid entries include: >>> # >>> # nisplus Use NIS+ (NIS version 3) >>> # nis Use NIS (NIS version 2), also called YP >>> # dns Use DNS (Domain Name Service) >>> # files Use the local files >>> # db Use the local database (.db) files >>> # compat Use NIS on compat mode >>> # hesiod Use Hesiod for user lookups >>> # [NOTFOUND=return] Stop searching if not found so far >>> # >>> >>> # To use db, put the "db" in front of "files" for entries you want to be >>> # looked up first in the databases >>> # >>> # Example: >>> #passwd: db files nisplus nis >>> #shadow: db files nisplus nis >>> #group: db files nisplus nis >>> >>> passwd: files sss >>> shadow: files sss >>> group: files sss >>> >>> #hosts: db files nisplus nis dns >>> hosts: files dns >>> >>> # Example - obey only what nisplus tells us... >>> #services: nisplus [NOTFOUND=return] files >>> #networks: nisplus [NOTFOUND=return] files >>> #protocols: nisplus [NOTFOUND=return] files >>> #rpc: nisplus [NOTFOUND=return] files >>> #ethers: nisplus [NOTFOUND=return] files >>> #netmasks: nisplus [NOTFOUND=return] files >>> >>> bootparams: nisplus [NOTFOUND=return] files >>> >>> ethers: files >>> netmasks: files >>> networks: files >>> protocols: files >>> rpc: files >>> services: files sss >>> >>> netgroup: files sss >>> >>> publickey: nisplus >>> >>> automount: files sss >>> aliases: files nisplus >>> >>> >>> >>> Sincerely, >>> -- >>> DaV >>> >>> On Fri, Aug 23, 2019, at 13:01, William Brown wrote: >>>> Indeed - for one last detail can you please show me your /etc/nsswitch.conf? >>>> >>>> After that, I'd advise you to open a bug on Red Hat bugzilla against >>>> SSSD and include the //etc/nsswitch.conf, and the rpm and log out put >>>> you have provided me here. >>>> >>>> Hope that helps, and great work to debug this. >>>> >>>>> On 23 Aug 2019, at 14:49, DaV <snowfrs@xxxxxxxxx> wrote: >>>>> >>>>> Hi William, >>>>> I can confirm that the automount issue can be reproduced. >>>>> >>>>> My 389ds Client environment: >>>>> OS: CentOS release 6.9 (Final) >>>>> openldap: openldap-clients-2.4.40-16.el6.x86_64 >>>>> sssd: >>>>> sssd-client-1.13.3-60.el6.x86_64 >>>>> sssd-ipa-1.13.3-60.el6.x86_64 >>>>> sssd-proxy-1.13.3-60.el6.x86_64 >>>>> sssd-common-1.13.3-60.el6.x86_64 >>>>> sssd-common-pac-1.13.3-60.el6.x86_64 >>>>> sssd-ad-1.13.3-60.el6.x86_64 >>>>> sssd-ldap-1.13.3-60.el6.x86_64 >>>>> python-sssdconfig-1.13.3-60.el6.noarch >>>>> sssd-krb5-common-1.13.3-60.el6.x86_64 >>>>> sssd-krb5-1.13.3-60.el6.x86_64 >>>>> sssd-1.13.3-60.el6.x86_64 >>>>> >>>>> the sssd configuration under /etc/sssd/sssd.conf >>>>> [domain/default] >>>>> >>>>> autofs_provider = ldap >>>>> cache_credentials = False >>>>> ldap_search_base = dc=example,dc=com >>>>> krb5_realm = EXAMPLE.COM >>>>> krb5_server = kerberos.example.com >>>>> id_provider = ldap >>>>> auth_provider = ldap >>>>> chpass_provider = ldap >>>>> ldap_uri = ldaps://389ds.example.com >>>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>>> ldap_group_member = uniqueMember >>>>> ldap_schema = rfc2307bis >>>>> debug_level = 5 >>>>> >>>>> ldap_autofs_map_object_class = nisMap >>>>> ldap_autofs_map_name = nisMapName >>>>> ldap_autofs_entry_object_class = nisObject >>>>> ldap_autofs_entry_key = cn >>>>> ldap_autofs_entry_value = nisMapEntry >>>>> ldap_autofs_search_base = ou=service,dc=example,dc=com >>>>> ldap_id_use_start_tls = False >>>>> >>>>> [sssd] >>>>> services = nss, pam, autofs >>>>> filter_users = root >>>>> filter_groups = root >>>>> domains = default >>>>> [nss] >>>>> homedir_substring = /home >>>>> >>>>> [pam] >>>>> >>>>> [sudo] >>>>> >>>>> [autofs] >>>>> debug_level = 9 >>>>> >>>>> [ssh] >>>>> >>>>> [pac] >>>>> >>>>> [ifp] >>>>> >>>>> >>>>> to compare the difference, I have two LDAP automount entry on 389ds server. >>>>> # /tools, auto.master, service, example.com >>>>> dn: cn=/tools,nismapname=auto.master,ou=service,dc=example,dc=com >>>>> nisMapName: tools >>>>> objectClass: nisObject >>>>> objectClass: top >>>>> cn: /tools >>>>> nisMapEntry: ldap tc-389ds-1.example.com:nismapname=auto.tools,ou=service,dc=example,dc=com >>>>> >>>>> # /home, auto.master, service, example.com >>>>> dn: cn=/home,nismapname=auto.master,ou=service,dc=example,dc=com >>>>> nisMapName: home >>>>> objectClass: nisObject >>>>> objectClass: top >>>>> cn: /home >>>>> nisMapEntry: ldap 389ds.example.com:nismapname=auto.home,ou=service,dc=example,dc=com >>>>> >>>>> >>>>> When I restart autofs on client, I get message: >>>>> >>>>> Aug 23 12:28:03 centos6 automount[1887]: autofs stopped >>>>> Aug 23 12:28:05 centos6 automount[3051]: Starting automounter version 5.0.5-139.el6, master map auto.master >>>>> Aug 23 12:28:05 centos6 automount[3051]: using kernel protocol version 5.02 >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_nss_read_master: reading master files auto.master >>>>> Aug 23 12:28:05 centos6 automount[3051]: do_init: parse(sun): init gathered global options: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_read_master: lookup(file): read entry +auto.master >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_nss_read_master: reading master files auto.master >>>>> Aug 23 12:28:05 centos6 automount[3051]: do_init: parse(sun): init gathered global options: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_nss_read_master: reading master sss auto.master >>>>> Aug 23 12:28:05 centos6 automount[3051]: do_init: parse(sun): init gathered global options: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup(file): failed to read included master map auto.master >>>>> >>>>> Aug 23 12:28:05 centos6 automount[3051]: master_do_mount: mounting /tools >>>>> Aug 23 12:28:05 centos6 automount[3051]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-tools >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_nss_read_map: reading map ldap ldap:tc-389ds-1.example.com:nismapname=auto.tools,ou=service,dc=example,dc=com >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "ldap:tc-389ds-1.example.com:nismapname=auto.tools,ou=service,dc=example,dc=com". >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_server_string: lookup(ldap): server "ldap://tc-389ds-1.example.com/";, base dn "nismapname=auto.tools,ou=service,dc=example,dc=com" >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 1, sasl_mech: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: (null) credential cache: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: do_init: parse(sun): init gathered global options: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: read_one_map: map read not needed, so not done >>>>> Aug 23 12:28:05 centos6 automount[3051]: mounted indirect on /tools with timeout 300, freq 75 seconds >>>>> Aug 23 12:28:05 centos6 automount[3051]: st_ready: st_ready(): state = 0 path /tools >>>>> >>>>> Aug 23 12:28:05 centos6 automount[3051]: master_do_mount: mounting /home >>>>> Aug 23 12:28:05 centos6 automount[3051]: automount_path_to_fifo: fifo name /var/run/autofs.fifo-home >>>>> Aug 23 12:28:05 centos6 automount[3051]: lookup_nss_read_map: reading map ldap ldap:ds.example.com:nismapname=auto.home,ou=service,dc=example,dc=com >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "ldap:ds.example.com:nismapname=auto.home,ou=service,dc=example,dc=com". >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_server_string: lookup(ldap): server "ldap://ds.example.com/";, base dn "nismapname=auto.home,ou=service,dc=example,dc=com" >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 1, sasl_mech: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: (null) credential cache: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: do_init: parse(sun): init gathered global options: (null) >>>>> Aug 23 12:28:05 centos6 automount[3051]: read_one_map: map read not needed, so not done >>>>> Aug 23 12:28:05 centos6 automount[3051]: mounted indirect on /home with timeout 300, freq 75 seconds >>>>> Aug 23 12:28:05 centos6 automount[3051]: st_ready: st_ready(): state = 0 path /home >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet: type = 3 >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet_missing_indirect: token 5, name ithelpdesk, request pid 1700 >>>>> Aug 23 12:28:16 centos6 automount[3051]: attempting to mount entry /home/ithelpdesk >>>>> Aug 23 12:28:16 centos6 automount[3051]: lookup_mount: lookup(ldap): looking up ithelpdesk >>>>> Aug 23 12:28:16 centos6 automount[3051]: do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) >>>>> Aug 23 12:28:16 centos6 automount[3051]: bind_ldap_simple: lookup(ldap): Unable to bind to the LDAP server: , error Can't contact LDAP server >>>>> Aug 23 12:28:16 centos6 automount[3051]: do_bind: lookup(ldap): ldap simple bind returned -1 >>>>> Aug 23 12:28:16 centos6 automount[3051]: lookup(ldap): lookup for ithelpdesk failed: connection failed >>>>> Aug 23 12:28:16 centos6 automount[3051]: key "ithelpdesk" not found in map source(s). >>>>> Aug 23 12:28:16 centos6 automount[3051]: dev_ioctl_send_fail: token = 5 >>>>> Aug 23 12:28:16 centos6 automount[3051]: failed to mount /home/ithelpdesk >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet: type = 3 >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet_missing_indirect: token 6, name ithelpdesk, request pid 1700 >>>>> Aug 23 12:28:16 centos6 automount[3051]: dev_ioctl_send_fail: token = 6 >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet: type = 3 >>>>> Aug 23 12:28:16 centos6 automount[3051]: handle_packet_missing_indirect: token 7, name ithelpdesk, request pid 1700 >>>>> Aug 23 12:28:16 centos6 automount[3051]: dev_ioctl_send_fail: token = 7 >>>>> >>>>> You can see the prefix 389 is gone. When I want to go to /home/ithelpdesk, client log shows >>>>> Unable to bind to the LDAP server, error can't contact LDAP server. >>>>> Because the client try to connect to ds.example.com, not 389ds.example.com >>>>> >>>>> >>>>> Sincerely, >>>>> -- >>>>> DaV >>>>> >>>>> On Fri, Aug 23, 2019, at 10:08, William Brown wrote: >>>>>> >>>>>> >>>>>>> On 23 Aug 2019, at 11:03, DaV <snowfrs@xxxxxxxxx> wrote: >>>>>>> >>>>>>> Hi William, >>>>>>> >>>>>>>> So, where did you read the docs on the setup? Maybe the docs are incomplete? >>>>>>> We are using Sun directory Server version 7, the configure on 389ds copied from Sun Directory Server for the automount part. >>>>>>> >>>>>>>> Can you correctly do a "ldapsearch" or "ldapwhoami" with -H >>>>>>>> ldap://389ds.example.com? >>>>>>> YES. the ldapsearch can work propertly. Just the automount part has some issue. >>>>>>> I will double check this today and reply. Thanks! >>>>>> >>>>>> In that case, it would be best to see how automount is configured on >>>>>> your centos host, and what rpm versions are involved. Thanks! >>>>>> >>>>>>> >>>>>>> Sincerely, >>>>>>> -- >>>>>>> DaV >>>>>>> >>>>>>> On Fri, Aug 23, 2019, at 08:53, William Brown wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 23 Aug 2019, at 10:39, DaV <snowfrs@xxxxxxxxx> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> First of all, I don't know whether if this is a bug and I don't know where to submit a bug. >>>>>>>> >>>>>>>> Let's do some investigation here first, but then I'd advise the RH >>>>>>>> bugzilla if we determine what the cause is. >>>>>>>> >>>>>>>>> >>>>>>>>> My 389ds info: >>>>>>>>> OS: CentOS Linux release 7.6.1810 (Core) >>>>>>>>> 389ds: 389-ds-base-1.3.8.4-15.el7.x86_64 >>>>>>>>> >>>>>>>>> On 389ds server, I have configured like this >>>>>>>>>> # auto.master, service, example.com >>>>>>>>>> dn: nismapname=auto.master,ou=service,dc=example,dc=com >>>>>>>>>> nisMapName: auto.master >>>>>>>>>> objectClass: nisMap >>>>>>>>>> objectClass: top >>>>>>>>>> >>>>>>>>>> # /home, auto.master, service, example.com >>>>>>>>>> dn: cn=/home,nismapname=auto.master,ou=service,dc=example,dc=com >>>>>>>>>> nisMapName: home >>>>>>>>>> objectClass: nisObject >>>>>>>>>> objectClass: top >>>>>>>>>> cn: /home >>>>>>>>>> nisMapEntry: ldap 389ds.example.com >>>>>>>>>> >>>>>>>>>> # *, auto.home, service, example.com >>>>>>>>>> dn: cn=*,nismapname=auto.home,ou=service,dc=example,dc=com >>>>>>>>>> nisMapName: home >>>>>>>>>> nisMapEntry: -fstype=nfs4,defaults,_netdev,acl sun:/home/& >>>>>>>>>> objectClass: nisObject >>>>>>>>>> objectClass: top >>>>>>>>>> cn: *:nismapname=auto.home,ou=service,dc=example,dc=com >>>>>>>>>> >>>>>>>>> >>>>>>>>> On client side >>>>>>>>> When I want to change directory under home (cd /home/username), I can't. >>>>>>>>> So I enable the autofs debug mode, and I see some message like this >>>>>>>>> >>>>>>>>>> Aug 22 15:55:36 centos automount[2424]: parse_server_string: lookup(ldap): server "ldap://ds.example.com/";, base dn "nismapname=auto.home,ou=service,dc=example,dc=com" >>>>>>>>> >>>>>>>>> The prefix 389 has gone. The client says can't connect LDAP server because in 389ds server I write ldap 389ds.example.com but I see ds.example.com on client-side. >>>>>>>>> >>>>>>>>> I don't know whether this is a bug. Just write this to let you know. Thanks! >>>>>>>> >>>>>>>> So, where did you read the docs on the setup? Maybe the docs are incomplete? >>>>>>>> >>>>>>>> What client tool are you using to read the mount? I seem to recall sssd >>>>>>>> has some stuff for it, or automount directly does. Seeing your >>>>>>>> automount "configs" would help here. >>>>>>>> >>>>>>>> Can you correctly do a "ldapsearch" or "ldapwhoami" with -H >>>>>>>> ldap://389ds.example.com? >>>>>>>> >>>>>>>> Anyway, it seems like a url/uri parsing issue, so let's work out what >>>>>>>> part is failing :) >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> My solution is: >>>>>>>>> change the 389ds server-side using nisMapEntry: ldap tc-389ds.example.com. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> -- >>>>>>>>> DaV >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>> 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.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>> >>>>>>>> — >>>>>>>> Sincerely, >>>>>>>> >>>>>>>> William Brown >>>>>>>> >>>>>>>> Senior Software Engineer, 389 Directory Server >>>>>>>> SUSE Labs >>>>>>>> _______________________________________________ >>>>>>>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>> 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.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>> >>>>>> >>>>>> — >>>>>> Sincerely, >>>>>> >>>>>> William Brown >>>>>> >>>>>> Senior Software Engineer, 389 Directory Server >>>>>> SUSE Labs >>>>>> >>>>>> >>>> >>>> — >>>> Sincerely, >>>> >>>> William Brown >>>> >>>> Senior Software Engineer, 389 Directory Server >>>> SUSE Labs >>>> >>>> >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> >> — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
