Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
A backtrace and a snippet of code follow:
#0 0x00007fda39c80a70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fda38d17e0d in send_dg (resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0x7fff2548cb30, gotsomewhere=<synthetic pointer>, v_circuit=<synthetic pointer>, ns=0, terrno=0x7fff2548bab0, anssizp=0x7fff2548bbf0, ansp=0x7fff2548baa8, buflen2=0, buf2=0x0, buflen=36, buf=0x7fff2548bc20 "\tg\001", statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>) at res_send.c:1059 #2 __libc_res_nsend (statp=statp@entry=0x7fda39f533e0 <_res@GLIBC_2.2.5>, buf=buf@entry=0x7fff2548bc20 "\tg\001", buflen=<optimized out>, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0, ans=ans@entry=0x7fff2548c700 "", anssiz=anssiz@entry=1024, ansp=ansp@entry=0x7fff2548cb30, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_send.c:556 #3 0x00007fda38d15d47 in __GI___libc_res_nquery ( statp=statp@entry=0x7fda39f533e0 <_res@GLIBC_2.2.5>, name=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=answerp@entry=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:226 #4 0x00007fda38d16963 in __libc_res_nquerydomain (domain=0x0, resplen2=0x0, nanswerp2=0x0, answerp2=0x0, answerp=0x7fff2548cb30, anslen=1024, answer=0x7fff2548c700 "", type=1, class=1, name=0x7fff2548d140 "client.example.com", statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>) at res_query.c:582 #5 __GI___libc_res_nsearch (statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>, name=name@entry=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:378 #6 0x00007fda2f2777e4 in __GI__nss_dns_gethostbyname3_r ( name=name@entry=0x7fff2548d140 "client.example.com", af=af@entry=2, result=result@entry=0x7fff2548d120, buffer=buffer@entry=0x1f33590 "\177", buflen=buflen@entry=992, errnop=errnop@entry=0x7fda3d8966a0, h_errnop=h_errnop@entry=0x7fff2548d10c, ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at nss_dns/dns-host.c:192 #7 0x00007fda2f277af0 in _nss_dns_gethostbyname_r ( name=0x7fff2548d140 "client.example.com", result=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=992, errnop=0x7fda3d8966a0, h_errnop=0x7fff2548d10c) at nss_dns/dns-host.c:273 #8 0x00007fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", name@entry=0x0) at util-int.c:748 #11 0x00007fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743
735 /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option, 736 * because the SSL/TLS context is initialized from this value. */ 737 ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, 738 &ldap_opt_x_tls_require_cert); 739 if (ret != LDAP_OPT_SUCCESS) { 740 DEBUG(SSSDBG_CRIT_FAILURE, 741 "ldap_set_option failed: %s\n",sss_ldap_err2string(ret)); 742 return EIO; 743 }
Thanks,
On 06/11/2014 08:41 AM, Jan Synacek wrote:
Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
It's the program's first call to libldap, so libldap needs to initialize itself. I guess it's looking up the default host. I don't think that's documented.
There should be an "initialize libldap" function so you can do it yourself earlier, but for now you can do that with ldap_get_option(), ldap_set_option() or create an LDAP* (with ldap_initialize() etc).
Hallvard Breien Furuseth wrote:
On 06/11/2014 08:41 AM, Jan Synacek wrote:
Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
It's the program's first call to libldap, so libldap needs to initialize itself. I guess it's looking up the default host. I don't think that's documented.
Can this be disabled with LDAPNOINIT=1 or the accompanying call to ldap_set_option()?
Ciao, Michael.
On 06/19/2014 01:49 PM, Michael Ströder wrote:
Hallvard Breien Furuseth wrote:
It's the program's first call to libldap, so libldap needs to initialize itself. I guess it's looking up the default host. I don't think that's documented.
Can this be disabled with LDAPNOINIT=1 or the accompanying call to ldap_set_option()?
That's what I meant in next somewhat unclear paragraph: Get/set any option or create an LDAP*, this forces libldap to initialize itself.
LDAPNOINIT - I don't think that helps, it uses gethostname() and proceeds. Or maybe it always does that, haven't looked too closely.
On Thu, 2014-06-19 at 15:09 +0200, Hallvard Breien Furuseth wrote:
On 06/19/2014 01:49 PM, Michael Ströder wrote:
Hallvard Breien Furuseth wrote:
It's the program's first call to libldap, so libldap needs to initialize itself. I guess it's looking up the default host. I don't think that's documented.
Can this be disabled with LDAPNOINIT=1 or the accompanying call to ldap_set_option()?
That's what I meant in next somewhat unclear paragraph: Get/set any option or create an LDAP*, this forces libldap to initialize itself.
LDAPNOINIT - I don't think that helps, it uses gethostname() and proceeds. Or maybe it always does that, haven't looked too closely.
(again, re-sending an e-mail to the list, previously I replied to Hallvard only, sorry)
Fair enough, but my point is that the initialization shouldn't include a blocking call over the network.
On Wed, 2014-06-11 at 08:41 +0200, Jan Synacek wrote:
Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
A backtrace and a snippet of code follow:
#0 0x00007fda39c80a70 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fda38d17e0d in send_dg (resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0x7fff2548cb30, gotsomewhere=<synthetic pointer>, v_circuit=<synthetic pointer>, ns=0, terrno=0x7fff2548bab0, anssizp=0x7fff2548bbf0, ansp=0x7fff2548baa8, buflen2=0, buf2=0x0, buflen=36, buf=0x7fff2548bc20 "\tg\001", statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>) at res_send.c:1059 #2 __libc_res_nsend (statp=statp@entry=0x7fda39f533e0 <_res@GLIBC_2.2.5>, buf=buf@entry=0x7fff2548bc20 "\tg\001", buflen=<optimized out>, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0, ans=ans@entry=0x7fff2548c700 "", anssiz=anssiz@entry=1024, ansp=ansp@entry=0x7fff2548cb30, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_send.c:556 #3 0x00007fda38d15d47 in __GI___libc_res_nquery ( statp=statp@entry=0x7fda39f533e0 <_res@GLIBC_2.2.5>, name=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=answerp@entry=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:226 #4 0x00007fda38d16963 in __libc_res_nquerydomain (domain=0x0, resplen2=0x0, nanswerp2=0x0, answerp2=0x0, answerp=0x7fff2548cb30, anslen=1024, answer=0x7fff2548c700 "", type=1, class=1, name=0x7fff2548d140 "client.example.com", statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>) at res_query.c:582 #5 __GI___libc_res_nsearch (statp=0x7fda39f533e0 <_res@GLIBC_2.2.5>, name=name@entry=0x7fff2548d140 "client.example.com", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fff2548c700 "", anslen=anslen@entry=1024, answerp=0x7fff2548cb30, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:378 #6 0x00007fda2f2777e4 in __GI__nss_dns_gethostbyname3_r ( name=name@entry=0x7fff2548d140 "client.example.com", af=af@entry=2, result=result@entry=0x7fff2548d120, buffer=buffer@entry=0x1f33590 "\177", buflen=buflen@entry=992, errnop=errnop@entry=0x7fda3d8966a0, h_errnop=h_errnop@entry=0x7fff2548d10c, ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at nss_dns/dns-host.c:192 #7 0x00007fda2f277af0 in _nss_dns_gethostbyname_r ( name=0x7fff2548d140 "client.example.com", result=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=992, errnop=0x7fda3d8966a0, h_errnop=0x7fff2548d10c) at nss_dns/dns-host.c:273 #8 0x00007fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", name@entry=0x0) at util-int.c:748 #11 0x00007fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743
735 /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option, 736 * because the SSL/TLS context is initialized from this value. */ 737 ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, 738 &ldap_opt_x_tls_require_cert); 739 if (ret != LDAP_OPT_SUCCESS) { 740 DEBUG(SSSDBG_CRIT_FAILURE, 741 "ldap_set_option failed: %s\n",sss_ldap_err2string(ret)); 742 return EIO; 743 }
Thanks,
Hi,
I already replied on the 18th, but I sent the mail to Jan only by accident. I'm copying my previous reply below:
FWIW, the backtrace comes from the SSSD. Only frames #14 and up are really relevant.
Since SSSD is often used in some kind of offline mode (either completely offline or just not connected to the VPN), startup should in my opinion be non-blocking.
Could there maybe be an option to pass in the hostname during initialization instead of having openldap figure it out? I'm fine with contributing a patch, if we agree on what the direction should be.
Jakub Hrozek wrote:
On Wed, 2014-06-11 at 08:41 +0200, Jan Synacek wrote:
Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
A backtrace and a snippet of code follow:
#8 0x00007fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", name@entry=0x0) at util-int.c:748 #11 0x00007fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743
735 /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option, 736 * because the SSL/TLS context is initialized from this value. */ 737 ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, 738 &ldap_opt_x_tls_require_cert); 739 if (ret != LDAP_OPT_SUCCESS) { 740 DEBUG(SSSDBG_CRIT_FAILURE, 741 "ldap_set_option failed: %s\n",sss_ldap_err2string(ret)); 742 return EIO; 743 }
Thanks,
Hi,
I already replied on the 18th, but I sent the mail to Jan only by accident. I'm copying my previous reply below:
FWIW, the backtrace comes from the SSSD. Only frames #14 and up are really relevant.
Since SSSD is often used in some kind of offline mode (either completely offline or just not connected to the VPN), startup should in my opinion be non-blocking.
Could there maybe be an option to pass in the hostname during initialization instead of having openldap figure it out? I'm fine with contributing a patch, if we agree on what the direction should be.
Put the hostname in /etc/hosts, end of story.
On Mon, 2014-06-23 at 06:22 -0700, Howard Chu wrote:
Jakub Hrozek wrote:
On Wed, 2014-06-11 at 08:41 +0200, Jan Synacek wrote:
Is it intentional? If yes, could you please explain why, or point me to a documentation where I can find the answer?
A backtrace and a snippet of code follow:
#8 0x00007fda39c9e163 in __gethostbyname_r ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buffer=0x1f33590 "\177", buflen=buflen@entry=992, result=result@entry=0x7fff2548d118, h_errnop=h_errnop@entry=0x7fff2548d10c) at ../nss/getXXbyYY_r.c:266 #9 0x00007fda3bb1b3de in ldap_pvt_gethostbyname_a ( name=name@entry=0x7fff2548d140 "client.example.com", resbuf=resbuf@entry=0x7fff2548d120, buf=buf@entry=0x7fff2548d110, result=result@entry=0x7fff2548d118, herrno_ptr=herrno_ptr@entry=0x7fff2548d10c) at util-int.c:350 #10 0x00007fda3bb1b5d0 in ldap_pvt_get_fqdn (name=0x7fff2548d140 "client.example.com", name@entry=0x0) at util-int.c:748 #11 0x00007fda3bb19b47 in ldap_int_initialize ( gopts=gopts@entry=0x7fda3bd40000 <ldap_int_global_options>, dbglvl=dbglvl@entry=0x0) at init.c:645 #12 0x00007fda3bb1a627 in ldap_set_option (ld=0x0, option=24582, invalue=0x7fff2548d2b0) at options.c:446 #13 0x00007fda30951cf6 in setup_tls_config (basic_opts=0x1f30450) at src/providers/ldap/sdap.c:533 #14 0x00007fda308214b3 in ldap_id_init_internal (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x7fff2548d5e8) at src/providers/ldap/ldap_init.c:146 #15 0x00007fda30821ba0 in sssm_ldap_id_init (bectx=0x1f12b40, ops=0x1f12cb0, pvt_data=0x1f12cb8) at src/providers/ldap/ldap_init.c:199 #16 0x000000000041b227 in load_backend_module (ctx=0x1f12b40, bet_type=BET_ID, bet_info=0x1f12ca8, default_mod_name=0x0) at src/providers/data_provider_be.c:2346 #17 0x000000000041ce4c in be_process_init (mem_ctx=0x1f0ba80, be_domain=0x1f093f0 "localipaldap", ev=0x1f0a630, cdb=0x1f0bb90) at src/providers/data_provider_be.c:2520 #18 0x000000000041fde6 in main (argc=3, argv=0x7fff2548e008) at src/providers/data_provider_be.c:2743
735 /* LDAP_OPT_X_TLS_REQUIRE_CERT has to be set as a global option, 736 * because the SSL/TLS context is initialized from this value. */ 737 ret = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, 738 &ldap_opt_x_tls_require_cert); 739 if (ret != LDAP_OPT_SUCCESS) { 740 DEBUG(SSSDBG_CRIT_FAILURE, 741 "ldap_set_option failed: %s\n",sss_ldap_err2string(ret)); 742 return EIO; 743 }
Thanks,
Hi,
I already replied on the 18th, but I sent the mail to Jan only by accident. I'm copying my previous reply below:
FWIW, the backtrace comes from the SSSD. Only frames #14 and up are really relevant.
Since SSSD is often used in some kind of offline mode (either completely offline or just not connected to the VPN), startup should in my opinion be non-blocking.
Could there maybe be an option to pass in the hostname during initialization instead of having openldap figure it out? I'm fine with contributing a patch, if we agree on what the direction should be.
Put the hostname in /etc/hosts, end of story.
I don't think it's that simple. What IP address you'd put there? The public one? Then you'd break dynamic DNS and roaming clients (keep in mind this issue mostly hits laptops) as the client would have to synchronize the new IP address and the /etc/hosts record.
You could probably also try 127.0.0.1 (IIRC some distros even had this default record in /etc/hosts..) but then I suspect various issues with Kerberos..
What I was going to propose was an option that would let you set what ldap_pvt_get_fqdn() instead of the normalisation done with gethostname() and the following ldap_pvt_gethostbyname_a().
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Howard Chu -
Jakub Hrozek -
Jan Synacek -
Michael Ströder