Here is the most common use case for LDAP: I am a senior administrator of a mid-sized company. I want to use LDAP to store a variety of data about a host: the puppet classes it should use for configuration, DNS records related to the object, my own proprietary inventory control information, and notes about quirks on the box. So I create a custom LDAP structural object which contains the following records for a host:
name owner jcapeInventoryTag description and then use the auxiliary classes provided by PowerDNS, Puppet, and Cobbler to add additional information. Once you've created an object, you can't remove structural object classes without effectively recreating the object. Further, each object class will have it's own notion of MAY and MUST fields. My on proprietary jcapeSystem class will have a jcapeInventoryTag as a MUST, so I can't enter a new system without having an inventory tag. Further, I'm not going to want to have multiple records in multiple places describing a single "system", because I don't have to and that's dumb. So if cobbler wants to write to LDAP (which is likely a non-starter to begin with, because I'm not going to risk it barfing all over my directory that I'm using to handle DNS and configuration management), it will need to take into account all the object classes that I as the administrator want it to use---and all the required fields that those object classes want it to use as well. Which means defining LDAP templates for cobbler to use when creating a new record and all the assorted madness of that, which will likely conflict with the already-existing system I have for entering hosts (either via PhpLdapAdmin or some scripted RYO solution). So telling me that cobbler *has* to write to LDAP is great, except that it's a real nightmare to actually do that in a way that is acceptable to people who use LDAP (like me)---far worse of a nightmare than factoring the assumptions you're making about the writer from the reader. -- 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 ----- "Michael DeHaan" <[email protected]> wrote: > 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 _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
