Package sssd_22.214.171.124-1 on Debian FTBFS for mips and mipsel.
dyndns_test_ok is failing with following log:
[ RUN ] dyndns_test_ok(Tue Jul 8 15:53:55:004476 2014) [sssd] [be_nsupdate_args] (0x0200): (Tue Jul 8 15:53:55:004521 2014) [sssd] [child_handler_setup] (0x2000): nsupdate auth type: GSS-TSIGSetting up signal handler up for pid (Tue Jul 8 15:53:55:004693 2014) [sssd] [__wrap_execv] (0x0200): nsupdate success test case(Tue Jul 8 15:53:55:004825 2014) [sssd] [__wrap_execv] (0x1000): Child exiting with status 0(Tue Jul 8 15:53:55:005275 2014) [sssd] [child_handler_setup] (0x2000): Signal handler set up for pid (Tue Jul 8 15:54:55:837623 2014) [sssd] [write_pipe_handler] (0x0020): write failed [Broken pipe].(Tue Jul 8 15:54:55:837801 2014) [sssd] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete(Tue Jul 8 15:54:55:837869 2014) [sssd] [nsupdate_child_stdin_done] (0x0040): Sending nsupdate data failed : Broken pipe(Tue Jul 8 15:54:55:837947 2014) [sssd] [be_nsupdate_done] (0x0040): nsupdate child execution failed : Dynamic DNS update failed(Tue Jul 8 15:54:55:837985 2014) [sssd] [dyndns_test_ok] (0x1000): Child request returned : Unknown error 14321582280x555d0014 != 0../src/tests/cmocka/test_dyndns.c:222: error: Failure![ FAILED ] dyndns_test_okChild part has finished before the child handler was created.
I have created and attached a patch which is workaround for this issue.
Could someone please take a look and comment this?
one of our users ran into an interesting problem -- her AD
infrastructure was different from the DNS server. Because by default, we
perform update against the server we're connected to, the DNS update
Per Simo's suggestion, I've implemented a new option that allows the
administrator to override the DNS server used for DNS updates.
the attached patches implement
I'm sorry the patches took so long, but only during testing I realized the
deleting of users not updated by the wildcard lookup is flawed. In case
there were more entries in cache that match the wildcard than the limit
on the wildcard search, we might be deleting legitimate entries that might
contain cached credentials..
What I did instead was never remove any entries during wildcard lookups,
but instead, only return entries that were updated during the wildcard
lookup in the cache_req. That way, stale entries would be deleted by a
direct lookup (maybe as a result of getpwuid when examining a file) or
can be deleted by the cleanup task.
I'm a bit nervous about the LDAP changes, please review ruthlessly :-)
I would also like for the option defaults to be carefully checked during
One question about the by-name-and-domain lookups -- should we check the
domain we receive from the cache_req is the same as we requested?
btw I really like how the cache_req and the infopipe code are structured. It
was quite easy to extend without any hacks.
I was able to reproduce failed build in covergae phase on local machine.
It seems that gcc did some optimization and
used execve instead of execle when the code was
instrumented for coverage analysis.
So the exec* function was not wrapped and it tried to call
real binary ipa-getkeytab. Obviously it failed.