James M. Cape wrote: > I'm attaching a patch against cobbler git (stable) to support an LDAP-backed > serializer. > > It's mode of operation is as follows: > > 1. Read-only from inside the cobbler TUI/WUI > - Users must handle adding the desired values to LDAP >
In all fairness, I can't see this as being something many people would use, when there is an extensive amount of validation and other logic in Cobbler that does not get executed if you do not use one of Cobbler's APIs to add that data. It would seem to cause lots of support problems with users entering invalid data. Also, adding data in such a manner would not execute any of the sync code for particular objects, nor triggers. The serializer would need to also /populate/ LDAP, IMO. If the logic to validate input is not part of Cobbler, it would have to be implemented in a higher level application, and at that point, it's going to be a lot of work for minimal gain. Ultimately I think it comes down to what sort of functionality that we are getting that we didn't have before, and what sort of applications need to be manipulating Cobbler that can't use it's XMLRPC API. > 2. Custom schema must be manually installed into LDAP server(s), but you can > customize the mappings between LDAP attributes and the cobbler object > variables (e.g. rather than "name" = "cn", you can have "name" = "uid" or > something). > > There are some gotchas regarding the way inheritance/overlays work with LDAP, > though. In particular, it doesn't handle the the NULL = "" mapping that the > YAML serializers do. > > Kind of. Empty string is just empty string. Rather it's more of a policy of not storing anything as Null, ever, for any reason. This is easy to think about if you think of Null/None as being a memory management concept. There's as a good reason for doing this too -- XMLRPC transmission of None is non-standard (though reasonably widely supported). To make things easier on XMLPRC consumers, we never store/transmit anything as None/Null. > It also doesn't completely handle the way "<<inherit>>" and default values > work in the YAML serializers yet, so cobbler sync doesn't really work. This > is the showstopper, but I don't know what kind of policy to pursue here: > > Do I emulate the behavior of the TUI/WUI inside the LDAP serializer, or > depend on the user to do so by setting "<<inherit>>" manually? > The serializers are supposed to be pretty braindead ways to save a datastructure in a file format. In the webapp itself, the templates are there to ensure "<<inherit>>" is loaded as the default value for when it's appropriate. They will get marginally more complicated if we ever support SQL DB's. Ultimately I think implementing domain logic outside of Cobbler to simulate what Cobbler does is a bit of a design problem -- we have to ask what we want to achive with this in terms of interoperability that we could not do before. I think Cobbler /has/ to be able to manipulate the LDAP records for it to be a useful interface/tool in this context. > -- > James Cape > http://jcape.ignore-your.tv/ > > "If there’s one thing I know, it’s that managers have the least > information about every technical issue, and they are the last > people who should be deciding anything" > -- Joel Spolsky > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
