[Pki-devel] [PATCH] pki-ftweedal-0015-Monitor-database-for-changes-to-LDAP-profiles.patch

[Endi Sukma Dewata]

On 3/30/2015 2:27 AM, Fraser Tweedale wrote:
>> 1. I have not actually tested this, but suppose the LDAP server is running
>> on a separate machine, then the network is down, and during that time a
>> profile is removed from the database. When the network is restored, the
>> ProfileSubsystem will reload all remaining profiles, but it will still have
>> the profile that was deleted in its memory. I think the ProfileSubsystem
>> should clear its memory before running the persistent search.
>>
>> 2. In ProfileSubsystem.createProfileDN() the basedn is no longer used so it
>> can be removed.
>>
>> 3. If the LDAP server is stopped the debug log says it's retrying in 5
>> seconds, but it's actually trying every second.
>>
>> I think #1 should be fixed, but the others are very trivial to fix too.
>
> New patch attached.  All issues have been addressed.

Let's say a profile is modified then deleted. These operations are 
replicated to a clone which is monitoring the changes using persistent 
search. When the clone receives the modify operation it will call 
readProfile(), which will call createProfile(), which will create an 
LDAPConfigStore for that profile. When LDAPConfigStore is created, it 
will read the profile from the database using a separate query. The 
problem is, at that point it's unclear whether the profile still exists.

The current code might ignore the error if the entry doesn't exist, but 
in general I don't think the code should make a separate query to 
retrieve the profile info because it could lead to inconsistencies. It 
should have used the LDAP entry returned by the persistent search that 
corresponds to the operation being processed.

-- 
Endi S. Dewata