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?
-- 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
