(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.

Reply via email to