Thanks for the post, it was quite interesting. For the attributes, I've seen some reasonable text about storing serialized JSON in LDAP attributes which should work quite well for preserving ordering, etc...
In terms of infrastructure, if you've got any significant number of users, you're probably already using LDAP, whether or not it's bound with Kerberos so this shouldn't be something that is rocket surgery for an enterprise scenario. Yes, I *completely* agree that for smaller infrastructures, Hiera makes a lot of sense but I'm starting to feel people pushing at the edges in such a way that we're going to start reinventing the wheel in terms of needing multi-master replication, synchronization, localized offline caching, etc.... LDAP is certainly verbose, but there are enough libraries to be able to wrap it in pretty much any data structure that you like so that shouldn't be too bad overall. Interesting conversation. Thanks, Trevor On Wed, Jul 18, 2012 at 5:39 PM, Christopher Wood <[email protected]> wrote: > (inline, verbosely rhubarbing for the audience not the poster) > > On Wed, Jul 18, 2012 at 05:09:42PM -0400, Trevor Vaughan wrote: >> So, I was following the thread "how to conditionally add users to a >> virtualized group?" and had a bit of a realization that I'm not quite >> sure why Hiera is a better backend than LDAP. >> >> Hiera: >> >> - Stores hierarchical data locally on your system >> - Uses YAML > > YAML is... something that nearly everything can read/write. People who don't > often write YAML (like me) write our YAML in our favourite scripting > languages and then export via one of the many export modules. YAML is a > simple text file, or four. > >> - Integrates with puppet >> >> LDAP >> >> - Stores hierarchical data across potentially multiple systems (think >> puppet master scaling and data sync) >> - Uses LDIFs >> - Needs some glue code written > > s/some/much/ > > The skills to deal with LDAP are much less commonplace than the skills to > deal with YAML. YAML is much more standardized than all the different LDAP > implementations out there (I have used several). > >> However, both are hierarchical databases based on 'read often/write >> rarely' principals. >> >> Besides the glue code to make LDAP do Hiera-like things, what are the >> issues? It also seems that using a well known and supported system, >> such as LDAP, would foster greater enterprise support (except in those >> places where you have to spawn your own due to insane directory >> admins). > > LDAP is quite verbose. Compare: > > operations: > bind: ssh HOST "hostname;ps -ef | grep named" > date: ssh HOST "echo \`hostname\` \`date\`" > df: ssh HOST "df -h -l" > > Versus pseudo-ldif: > > dn: dc=operations,dc=c,dc=scripts,dc=mycompany,dc=com > dc: operations > objectclass: yamlthing > item:: YmluZDogc3NoIEhPU1QgImhvc3RuYW1lO3BzIC1lZiB8IGdyZXAgbmFtZWQi > item:: ZGF0ZTogc3NoIEhPU1QgImVjaG8gXGBob3N0bmFtZVxgIFxgZGF0ZVxgIg== > item:: PW4gZGY6IHNzaCBIT1NUICJkZiAtaCAtbCIK > > One big difference between LDAP and YAML: You can have ordered attributes > (lists) in YAML. There is no guaranteed attribute ordering in LDAP; > attributes may be returned in any order, on an implementation-specific basis. > (To the best of my knowledge.) > > Depending on your access method (and likely implementation details), you may > have to implement client-side logic to get your heirarchical values working > just right. For instance, which order will the following entries be returned > in? > > dc=three > dc=two,dc=three > dc=two,dc=two,dc=three > dc=one,dc=two,dc=three > > It might be the above order, as I've seen from OpenLDAP. Then the entries' > attributes will be returned in any order. Happy parsing. > > LDAP also requires another client/server infrastructure, more daemons to > patch and maintain, et cetera. > >> And, yes, I know that a hiera back-end could be written to support >> LDAP but that would just be an unnecessary data transference if I'm >> reading it right. >> >> If you wanted local "fast" copies of the data on all of your puppet >> masters (and you do) then a simple LDAP slave would be spawned on each >> master. > > Replicating between ldap instances isn't simple to set up. (Are you using > single-master, hub-spoke, multimaster, etc.?) Some light reading: > > http://www.openldap.org/doc/admin24/replication.html > > http://directory.fedoraproject.org/wiki/Howto:MultiMasterReplication > > Of course, I don't know the point at which the ldap advantages outweigh the > setup costs, or how these compare to YAML. > >> Thanks, >> >> Trevor >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> [email protected] >> >> -- This account not approved for unencrypted proprietary information -- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
