[Freeipa-devel] "Commit comments log" functionality in IPA

[Dmitri Pal]

John Dennis wrote:
> Dmitri Pal wrote:
>> The argument for storing in DS is:
>> a) There is no other place to store it.
>
> Nonsense, there are many other good places, but see my comment below.
>> f) The company policies might require that the changes to the 
>> critical object be commented . Without this feature and DS plugin 
>> this can't be enforced. If it is done in UI or CLI the admin might 
>> circumvent it by using ldap calls directly. So DS is the only common 
>> denominator.
>> I strongly believe that based on the last reason it should be done in 
>> DS plugin and only there. It can be done in different ways though.
> I wrote an email earlier about how we have conceptual impedance 
> illustrated with Aseoph's Fable about the 5 Blind Men and the 
> Elephant. I elected not to send it. But I want to point out something 
> out which has been worrying me, we might be locking ourselves into a 
> series of bad design decisions.
>
> The problem goes like this: We've put DS at the center of the IPA 
> universe. We've built an entire management system on top of it which 
> we then say is completely optional to use, it's just sugar, feel free 
> reach inside and use ldapmodify and do whatever you want behind our 
> backs. Because we've deliberately picked one data store and provided a 
> wide open back door to it we constantly find ourselves in the 
> situation of having to enforce our business logic inside that data 
> store. Perhaps I'm the only one, but that strikes me as crazy and it 
> won't scale. IPA is going to keep growing features, for goodness sake 
> not everything can nor should be implemented in the directory server. 
> I think we would be better off to say our XMLRPC server is what 
> implements IPA functionality, we provide multiple ways to interact 
> with it, it implements all our business logic, it is a heavy user of 
> LDAP but NOT AN EXCLUSIVE user of LDAP. You're free to use the 
> ldapmodify backdoor if you want but that comes with all the caveats 
> about backdoor out-of-band updates. To be a good IPA citizen use the 
> IPA interfaces.
>> We can do this but if we agree that DS plugin is anyway inevitable ...
> No! Endless DS plugins are not inevitable. They are only inevitable if 
> you buy into a flawed model which says everything in IPA needs to be 
> implemented in DS.
>
> LDAP makes a lot of sense for what IPA does with the "I" of IPA, but 
> let's have the freedom to use other tools and technologies for the 
> remainder. If you do buy into the fact we need more flexibility then 
> there has to be a "central agent" which interacts with all the 
> components and enforces business logic (I am not convinced that 
> central agent can or should be a LDAP server).
>
> With this in mind capturing comments becomes trivial. Use the IPA 
> interface to make the change, it optionally captures the comment. IPA 
> then updates DS and every other relevant component AND enforces the 
> integrity of our business logic. IPA generates an ID for the entire 
> set of operations it performed (e.g. a transaction), IPA then writes 
> the comment tagged with the ID wherever it wants to. When we need to 
> present the comment to a user the GUI, command line tool, or whatever 
> calls the defined IPA interface (e.g. XMLRPC). Which retrieves the 
> comment from wherever the heck it wants to (in v2 it might be a file, 
> in v3 it might be a database).
>
> You only need to store everything in DS and enforce all business logic 
> in DS if you believe ldapmodify is the one true IPA interface (which 
> IMHO is driving us to make bad design decisions).
>
> BTW, if someone uses ldapmodify IPA can still identify when and how 
> the change occurred because it will be in an audit log of DS 
> modifications.
>

John,

This is a very good point. I think we should clarify this and come to 
terms  about it.
If we are not on the same page with fundamental approach to data store  
than we should come to agreement (or at least state the rule that 
everybody would have to comply - I wonder who has such authority :-)).

I am operating under the following assumptions:
a) DS is our data store and whatever we need to store there we will 
store there unless there is a better place for it
b) There is a better place for audit data so we won't store it there but 
for most other things it the store.
c) We allow direct access by LDAP . Even if we state that we does not 
allow it the LDAP channel will be there. No security operation check or 
enforcement should be bypassed on this route. Otherwise there is no 
sense of building such checks. DS has to be the common denominator 
unless we create some other abstraction layer as you suggest and stop 
exposing LDAP interface at all.  The abstraction layer (agent as you 
called it) reminds me of the effort that was undertaken by my previous 
company. They spent 2 years and 20 people building such  layer. Did it 
wrong, threw it away and started over using different technologies. 
Spent another 3 years, doubled team and finally got the product out. We 
just can't afford this. :-)

I think it is too late to change the course.
DS is our data store and we need to be prepared for the long list of 
data going into it together with a long list of the integrity, 
consistency and security plugins.
XML-RPC is just a convenience layer. We have to admit that. From this 
perspective all attempt to keep DS "pure" seems at least strange.
Based on the assumptions above my original proposal seems perfectly 
reasonable.

If we can't agree to DS being the core and being the common low level 
denominator we would have to start from day 1.
Any other opinions are welcome.

Thanks
Dmitri