Am 01.04.14 schrieb Noriko Hosoi <nhosoi(a)redhat.com>:
Hello Carsten,
Could it be possible to share your failed test cases with us for our debugging?
I have setup an winsync replication agreement with a W2K8R2 AD. There is enabled
the SFU for managing the Posix attributes uidnumber, gidnumber, unixshell, unixhomedir,
nisdomain, ...
The test failes if I change some of the Posix attributes. These changes will not synched.
The reason is that for #716980 the value for rawentry is reseted before winsync cb is
called and for #47314 the cb posix_winsync_pre_ds_mod_user_cb returns immediately if
rawentry is NULL.
Before #47314 only account enable/disable have to fail.
sync_acct_disable I took from ipa.
I don't know exactly what is the difference beteween ad_entry and rawentry. Perhaps
all works as before if I ignore rawentry in the cb code and use ad_entry instead.
Carsten
Thanks,
--noriko
Rich Megginson wrote:
> On 04/01/2014 07:34 AM, Carsten Grzemba wrote:
>
>
> > Hi Rich,
> >
> > this breaks the current implementaion for posix-winsync:
> >
> > Bug 716980 - winsync uses old AD entry if new one not found
> >
https://bugzilla.redhat.com/show_bug.cgi?id=716980
> > Resolves: bug 716980
> > Bug Description: winsync uses old AD entry if new one not found Reviewed by:
nhosoi (Thanks!)
> > Branch: master
> > Fix Description: Clear out the old raw_entry before doing the search. This
will leave a NULL in the raw entry. winsync plugins will need to handle a NULL for the
raw_entry and/or ad_entry.
> >
> > In the moment posix_winsync_pre_ds_mod_user_cb returns imediataly on raw_entry
== NULL
> > How should the plugin handle the NULL for raw_entry?
> >
>
> Not sure. Please reopen that ticket. If it broke posix-winsync, it is likely to
break other winsync plugins (e.g. ipa winsync).
>
>
> >
> > Carsten
> >
> >
> > --
> > 389-devel mailing list
> > 389-devel(a)lists.fedoraproject.org
> >
https://admin.fedoraproject.org/mailman/listinfo/389-devel
> >
>
>
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>