samba as AD DC - can the single process mode "-M single" atm still been used ?

Tue Jun 3 21:35:41 MDT 2014

Am 02.06.2014 13:07, schrieb Kai Blin:
> On 2014-05-29 00:00, Andrew Bartlett wrote:
>>
>> However, it isn't likely to work with the internal DNS server if there
>> is ever a blocking DNS lookup.  We shouldn't do that (we should always
>> us the async code), but this is the main concern I would have.
> 
> As far as I'm aware, external DNS lookups always go via tevent_req async calls. Any particular pieces of code that you have in mind?
> 
>> (When the single mode server was first done, the DNS was always
>> external, so it didn't matter previously).
>>
>> We could either find the code that needs to be fixed, or force the dns
>> task to operate as a separate task.
> 
> I've pretty much done all my testing in single mode, so I'm a bit surprised by your assertion that single mode won't work with the internal DNS.
> 
> Cheers,
> Kai
> 

Hi Kai,

it mustn't be your dns code, also other parts of samba do
dns lookups (e.g. heimdal). Also ./source4/libcli/resolve/dns_ex.c
might play a role sometimes.

I noticed the *complete* hang of samba (using internal dns) some months
ago when i run it in single process mode "samba -i -M single -d3".

The following backtrace is taken during samba startup, when samba is hanging.
Note - that i run it in an environment with 4 AD DCs joined to a domain.
Also the nameserver ip in /etc/resolv.conf must be set to the (local) ip
of this samba server.

Cheers, Günter

(gdb) bt
#0  0x00007ffff3ae1b20 in __poll_nocancel () from /lib64/libc.so.6
#1  0x00007fffebcbec90 in __libc_res_nsend () from /lib64/libresolv.so.2
#2  0x00007fffebcbcce5 in __libc_res_nquery () from /lib64/libresolv.so.2
#3  0x00007fffebcbd30f in __libc_res_nquerydomain () from /lib64/libresolv.so.2
#4  0x00007fffebcbd90f in __libc_res_nsearch () from /lib64/libresolv.so.2
#5  0x00007fffebcbdbfc in __res_nsearch () from /lib64/libresolv.so.2
#6  0x00007fffede33168 in dns_lookup_int (domain=0x7fffffffa970 "_kerberos._udp.ADDLZ.KUKKUKK.COM.", rr_class=1, rr_type=33) at
../source4/heimdal/lib/roken/resolve.c:565
#7  0x00007fffede3332a in rk_dns_lookup (domain=0x7fffffffa970 "_kerberos._udp.ADDLZ.KUKKUKK.COM.", type_name=0x7ffff2748d53 "SRV") at
../source4/heimdal/lib/roken/resolve.c:607
#8  0x00007ffff2726b33 in srv_find_realm (context=0x5555562976b0, res=0x7fffffffade8, count=0x7fffffffaddc, realm=0x555556004aa0 "ADDLZ.KUKKUKK.COM",
dns_type=0x7ffff2748d53 "SRV",
    proto=0x7ffff2748ca8 "udp", service=0x7ffff2748e92 "kerberos", port=0) at ../source4/heimdal/lib/krb5/krbhst.c:88
#9  0x00007ffff27277c5 in srv_get_hosts (context=0x5555562976b0, kd=0x555555a40df0, proto=0x7ffff2748ca8 "udp", service=0x7ffff2748e92 "kerberos") at
../source4/heimdal/lib/krb5/krbhst.c:441
#10 0x00007ffff2728184 in kdc_get_next (context=0x5555562976b0, kd=0x555555a40df0, host=0x7fffffffae98) at ../source4/heimdal/lib/krb5/krbhst.c:660
#11 0x00007ffff2728da9 in krb5_krbhst_next (context=0x5555562976b0, handle=0x555555a40df0, host=0x7fffffffae98) at
../source4/heimdal/lib/krb5/krbhst.c:968
#12 0x00007ffff273e59c in krb5_sendto (context=0x5555562976b0, send_data=0x7fffffffaf70, handle=0x555555a40df0, receive=0x7fffffffaf60) at
../source4/heimdal/lib/krb5/send_to_kdc.c:381
#13 0x00007ffff273ea8a in krb5_sendto_context (context=0x5555562976b0, ctx=0x555555e5cee0, send_data=0x7fffffffaf70, realm=0x555555e45270
"ADDLZ.KUKKUKK.COM", receive=0x7fffffffaf60)
    at ../source4/heimdal/lib/krb5/send_to_kdc.c:625
#14 0x00007ffff272167f in krb5_init_creds_get (context=0x5555562976b0, ctx=0x555555cf1500) at ../source4/heimdal/lib/krb5/init_creds_pw.c:1938
#15 0x00007ffff2721952 in krb5_get_init_creds_password (context=0x5555562976b0, creds=0x7fffffffd4c0, client=0x555556c591d0, password=0x555555a265a0
"JUEzRTdu4<BE(G at riT,uW-aEJIc_]<bFmFYMp",
    prompter=0x0, data=0x0, start_time=0, in_tkt_service=0x0, options=0x555556309dc0) at ../source4/heimdal/lib/krb5/init_creds_pw.c:2016
#16 0x00007ffff2b8a720 in kerberos_kinit_password_cc (ctx=0x5555562976b0, cc=0x555555cc5420, principal=0x555556c591d0, password=0x555555a265a0
"JUEzRTdu4<BE(G at riT,uW-aEJIc_]<bFmFYMp",
    target_service=0x0, krb_options=0x555556309dc0, expire_time=0x0, kdc_time=0x7fffffffd5c0) at ../lib/krb5_wrap/krb5_samba.c:1570
#17 0x00007ffff757c578 in kinit_to_ccache (parent_ctx=0x55555578c690, credentials=0x55555578c690, smb_krb5_context=0x555556b74300,
event_ctx=0x55555578b940, ccache=0x555555cc5420,
    obtained=0x7fffffffd6a8, error_string=0x7fffffffd7d8) at ../source4/auth/kerberos/kerberos_util.c:253
#18 0x00007ffff7579213 in cli_credentials_get_named_ccache (cred=0x55555578c690, event_ctx=0x55555578b940, lp_ctx=0x55555576aab0, ccache_name=0x0,
ccc=0x7fffffffd760, error_string=0x7fffffffd7d8)
    at ../auth/credentials/credentials_krb5.c:409
#19 0x00007ffff75792cd in cli_credentials_get_ccache (cred=0x55555578c690, event_ctx=0x55555578b940, lp_ctx=0x55555576aab0, ccc=0x7fffffffd760,
error_string=0x7fffffffd7d8)
    at ../auth/credentials/credentials_krb5.c:432
#20 0x00007ffff7579747 in cli_credentials_get_client_gss_creds (cred=0x55555578c690, event_ctx=0x55555578b940, lp_ctx=0x55555576aab0,
_gcc=0x7fffffffd7d0, error_string=0x7fffffffd7d8)
    at ../auth/credentials/credentials_krb5.c:551
#21 0x00007ffff68de49e in gensec_gssapi_client_creds (gensec_security=0x5555566cd550, ev=0x55555578b940) at ../source4/auth/gensec/gensec_gssapi.c:296
#22 0x00007ffff68dec34 in gensec_gssapi_update (gensec_security=0x5555566cd550, out_mem_ctx=0x555556333db0, ev=0x55555578b940, in=..., out=0x555556333db8)
    at ../source4/auth/gensec/gensec_gssapi.c:453
#23 0x00007ffff68d9ff9 in gensec_update_ev (gensec_security=0x5555566cd550, out_mem_ctx=0x555556333db0, ev=0x55555578b940, in=..., out=0x555556333db8)
at ../auth/gensec/gensec.c:235
#24 0x00007ffff4cfc110 in dcerpc_bind_auth_send (mem_ctx=0x555555beb8e0, p=0x555556a5d5b0, table=0x7ffff20b8580 <ndr_table_drsuapi>,
credentials=0x55555578c690, gensec_settings=0x555556c9abc0,
    auth_type=16 '\020', auth_level=6 '\006', service=0x7ffff1e994ca "ldap") at ../source4/librpc/rpc/dcerpc_auth.c:378
#25 0x00007ffff4cfedd6 in dcerpc_pipe_auth_send (p=0x555556a5d5b0, binding=0x555555a26630, table=0x7ffff20b8580 <ndr_table_drsuapi>,
credentials=0x55555578c690, lp_ctx=0x55555576aab0)
    at ../source4/librpc/rpc/dcerpc_util.c:694
#26 0x00007ffff4d02494 in continue_pipe_connect (c=0x555556780140, s=0x555556267b00) at ../source4/librpc/rpc/dcerpc_connect.c:768
#27 0x00007ffff4d022fb in continue_pipe_connect_ncacn_ip_tcp (ctx=0x55555663f990) at ../source4/librpc/rpc/dcerpc_connect.c:717
#28 0x00007ffff1337a10 in composite_done (ctx=0x55555663f990) at ../source4/libcli/composite/composite.c:143
#29 0x00007ffff4d017b4 in continue_pipe_open_ncacn_ip_tcp (ctx=0x555556b6fb40) at ../source4/librpc/rpc/dcerpc_connect.c:352
#30 0x00007ffff1337a10 in composite_done (ctx=0x555556b6fb40) at ../source4/libcli/composite/composite.c:143
#31 0x00007ffff4d0067d in continue_ip_open_socket (ctx=0x5555559f8430) at ../source4/librpc/rpc/dcerpc_sock.c:267
#32 0x00007ffff1337a10 in composite_done (ctx=0x5555559f8430) at ../source4/libcli/composite/composite.c:143
---Type <return> to continue, or q <return> to quit---
#33 0x00007ffff4cfffd3 in continue_socket_connect (ctx=0x555557006680) at ../source4/librpc/rpc/dcerpc_sock.c:124
#34 0x00007ffff1337a10 in composite_done (ctx=0x555557006680) at ../source4/libcli/composite/composite.c:143
#35 0x00007ffff133a792 in socket_connect_handler (ev=0x55555578b940, fde=0x55555702e2f0, flags=2, private_data=0x555557006680) at
../source4/lib/socket/connect.c:131
#36 0x00007ffff647e1a4 in epoll_event_loop (epoll_ev=0x55555578bb80, tvalp=0x7fffffffde50) at ../lib/tevent/tevent_epoll.c:728
#37 0x00007ffff647e7b5 in epoll_event_loop_once (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at
../lib/tevent/tevent_epoll.c:926
#38 0x00007ffff647b6b3 in std_event_loop_once (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at
../lib/tevent/tevent_standard.c:114
#39 0x00007ffff64758c6 in _tevent_loop_once (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at ../lib/tevent/tevent.c:530
#40 0x00007ffff6475b10 in tevent_common_loop_wait (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at
../lib/tevent/tevent.c:634
#41 0x00007ffff647b755 in std_event_loop_wait (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at
../lib/tevent/tevent_standard.c:140
#42 0x00007ffff6475bdb in _tevent_loop_wait (ev=0x55555578b940, location=0x555555564b37 "../source4/smbd/server.c:503") at ../lib/tevent/tevent.c:653
#43 0x000055555556074f in binary_smbd_main (binary_name=0x55555556430b "samba", argc=5, argv=0x7fffffffe368) at ../source4/smbd/server.c:503
#44 0x0000555555560798 in main (argc=5, argv=0x7fffffffe368) at ../source4/smbd/server.c:514
---------------------

07-05-2014 IRC
[04:41:53] <kukks> abartlet: :-) Hi, as you're around, are there atm any limitations to be aware of when running samba AD DC in single process mode? I
ask, cause i use that mode very often.
[04:48:07] <kukks> abartlet: til now, i only noticed a complete samba hang when using the internal dns server with "samba -i -M single -d3" and in
/etc/resolv.conf the (first) name server ip is set to that own local AD DC
[04:48:48] <@abartlet> kukks: yeah, that's pretty likely
[04:49:20] <@abartlet> we try and do async dns, but I've come to wonder if there are places that don't loop on our event loop, and so the internal dns
server may well fail
[04:49:42] <@abartlet> get the stack trace and we should be able to isolate the culprit
---
Following thread also made me wonder ...
https://lists.samba.org/archive/samba-technical/2014-April/099338.html
https://lists.samba.org/archive/samba-technical/2014-May/099420.html
-- 