Having just gone through this conversion recently, it's not as hard as it seems.
- Puppet variables are managed through the puppetVar entries for the objectClass so theres no need to extend the schema. - All variables are passed to the manifests as a string. You need to identify your hashes in your manifests and split them over a delimiter. - No parametrized classes (as of 2.6.x) can be called directly from LDAP. We had to locate our paramterized classes that were impacted and convert them over to using variables, and throwing a parse error if required variables were not located. This took maybe an hour to do. - At least as of 2.6.x it appears that the environment variable is completely ignored from the client. This behavior is actually desired but if you have gotten used to --environment=newfeatureenv it can be a change. We are also leveraging dynamic environments as described in http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ which helps separate development from production. On Wed, Jan 25, 2012 at 10:44 AM, Brian Wong <bwl...@gmail.com> wrote: > I have been reading about the LDAP ENC at the wiki > http://projects.puppetlabs.com/projects/puppet/wiki/LDAP_Nodes. > > I am considering using the LDAP ENC, but I have a couple of concerns > when it comes to the implementation. > - It seems that the example using the entry attribute 'ipHostNumber' > as a puppet variable is not really viable, for the LDAP schema would > have to be updated to support arbitrary LDAP attributes such as this. > Or perhaps this is an attribute that is part of the 'core' LDAP > schema? > - To support arrays it would require puppet parser functions and > extraneous code in manifests to expand the LDAP arrays to puppet > arrays. > - It is not clear how parameterized classes can be handled. > > One of the important advantages of the LDAP ENC in my opinion is that > modification can be tied directly to LDAP authorization. I want > developers to be able to modify the classes pulled in by their > development hosts and the write access to a specific LDAP OU > containing these hosts can be granted. Another LDAP OU containing the > configuration of productions hosts will only be writable by a select > few. In addition, there are many tools available which can modify LDAP > entries. This lowers the entry barrier to using such the LDAP backend. > > Can someone confirm or dispel my concerns? Are there any other ENC > backends which would be appropriate given my goals? Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
