James M. Cape wrote: > That's fine to have a set of scripts to update cobbler from LDAP. Is there > any resistance to maintaining a common-use version of those scripts in a > contrib dir in cobbler? >
Definitely a good idea, I think that would be much better than having multiple people try to have to implement the same thing. We could have pointers to this on the Wiki as well. --Michael > -- > 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: >> >>> 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. >> >>> >> This seems like it might be easier to have a way to sync cobbler from >> LDAP, in that case, which I think a few folks have done. >> >> The serializers, especially in 1.4, need to save updated data -- in >> particular, the modification times of objects and their ID's are going >> to become increasingly important internally. >> >> Also if the storage format is read only there is no way to upgrade >> cobbler and have things work effectively, due to the way things like >> deserialize_raw work for XMLRPC and the Web app (which are also >> growing >> in importance -- even if you don't use the webapp, cobbler does use >> XMLRPC to generate kickstart files). >> >> I think populating and updating cobbler from LDAP may be a better way >> to >> go in this instance. >> >> --Michael >> >> >>> -- >>> 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 >>> >>> >> _______________________________________________ >> 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
