10:17 a.m.
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" <mdehaan(a)redhat.com> 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
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler