> Is the bug worth investigating, given that it occurs with a setting > that is not deeply supported?
Well I spoke too soon saying it no longer occurs: over the weekend I received a number of emails giving the same backtrace that I reported originally. In syslog, there are a number of backtraces from winbindd: Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] lib/util_sock.c:write_data(556) Jan 7 10:04:38 boco winbindd[6677]: write_data: write failure. Error = Connection reset by peer Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] libsmb/clientgen.c:write_socket(138) Jan 7 10:04:38 boco winbindd[6677]: write_socket: Error writing 108 bytes to socket 3: ERRNO = Connection reset by peer Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] libsmb/clientgen.c:cli_send_smb(168) Jan 7 10:04:38 boco winbindd[6677]: Error writing 108 bytes to client. -1 (Connection reset by peer) Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] rpc_client/cli_ds.c:rpccli_ds_enum_domain_trusts(93) Jan 7 10:04:38 boco winbindd[6677]: PANIC: assert failed at rpc_client/cli_ds.c(93) Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] lib/util.c:smb_panic2(1544) Jan 7 10:04:38 boco winbindd[6677]: smb_panic(): calling panic action [/usr/share/samba/panic-action 6677] Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] lib/util.c:smb_panic2(1552) Jan 7 10:04:38 boco winbindd[6677]: smb_panic(): action returned status 0 Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] lib/util.c:smb_panic2(1554) Jan 7 10:04:38 boco winbindd[6677]: PANIC: bad auth level Jan 7 10:04:38 boco winbindd[6677]: [2006/01/07 10:04:38, 0] lib/util.c:smb_panic2(1562) Jan 7 10:04:38 boco winbindd[6677]: BACKTRACE: 12 stack frames: Jan 7 10:04:38 boco winbindd[6677]: #0 /usr/sbin/winbindd(smb_panic2+0x6d) [0x555555605aed] Jan 7 10:04:38 boco winbindd[6677]: #1 /usr/sbin/winbindd(rpc_api_pipe_req+0x129) [0x55555566c9a9] Jan 7 10:04:38 boco winbindd[6677]: #2 /usr/sbin/winbindd(rpccli_ds_enum_domain_trusts+0x19f) [0x555555678dff] Jan 7 10:04:38 boco winbindd[6677]: #3 /usr/sbin/winbindd [0x5555555b3814] Jan 7 10:04:38 boco winbindd[6677]: #4 /usr/sbin/winbindd [0x5555555a50dc] Jan 7 10:04:38 boco winbindd[6677]: #5 /usr/sbin/winbindd(winbindd_dual_list_trusted_domains+0x63) [0x5555555a96b3] Jan 7 10:04:38 boco winbindd[6677]: #6 /usr/sbin/winbindd [0x5555555b4e01] Jan 7 10:04:38 boco winbindd[6677]: #7 /usr/sbin/winbindd(init_child_connection+0x24f) [0x55555559f82f] Jan 7 10:04:38 boco winbindd[6677]: #8 /usr/sbin/winbindd(rescan_trusted_domains+0xfd) [0x55555559f9ad] Jan 7 10:04:38 boco winbindd[6677]: #9 /usr/sbin/winbindd(main+0x44b) [0x555555598e2b] Jan 7 10:04:38 boco winbindd[6677]: #10 /lib/libc.so.6(__libc_start_main+0xda) [0x2aaaab9644ca] Jan 7 10:04:38 boco winbindd[6677]: #11 /usr/sbin/winbindd [0x55555559774a] > My opinion: I'm not sure that the Samba Team considers > "security=server" as completely obsolete and, on the other hand, we > seem to have valid debug output so it might be worth sending the whole > stuff to upstream Bugzilla. Comments? Personally, IMHO for all bugs (samba or not) if the problem is not debian specific and there's sufficient evidence, I think all reported bugs should be reported upstream as the upstream code will benefit. -- Andy, BlueArc Engineering
