[SSSD] [PATCH] Last USN patches

Jan Zelený jzeleny at redhat.com
Tue Mar 15 08:40:35 UTC 2011


Simo Sorce <ssorce at redhat.com> wrote:
> Sorry Jan but it doesn't seem to do what I asked for.

I'm not sure you are entirely right here. Let me explain:

> As far as I can see you are overriding the last_usn when you connect,
> which is the exact opposite of what should be done.

No, I'm not overriding it. I suppose you are referring to the first patch (Add 
value of the last USN to server configuration). This is indeed adding the value 
of last USN to sdap_server_opts during connection, but this structure instance 
is only temporary and it is stored internally after the connection creating 
process is finished (see the second patch, the comparison of USN and server ID 
is in there).

> last_usn must never be set to whatever value is available from ldap.
> 
> You only need to check if the value from ldap is lower then the
> currently internally value for last_usn if we are reconnecting to
> the same server,and you need to reset last_usn to 0 if the highest
> value reported from ldap is lower than the highest we internally stored.
> 
> If we are connecting to a different server we always unconditionally
> reset last_usn to 0, as USNs are not global so checking values between
> different servers have no meaning.

I'm not sure we should be resetting the value to 0. Even after fresh replica 
installation the USN is not zero. In fact I didn't stumble upon a single case 
of USN being zero (considering that it was supported and used on the server). 
Can you please explain a little bit more why we should do this and not just 
leave the USN which is currently on the server?

-- 
Thank you
Jan Zeleny

Red Hat Software Engineer
Brno, Czech Republic



More information about the sssd-devel mailing list