10:49 a.m.
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
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.
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?
--
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
9:28 a.m.
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
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
11:14 a.m.
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" <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
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
5638
days inactive
5639
days old
cobbler@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
James Cape -
Michael DeHaan