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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 25, 2012, at 8:44 AM, Brian Wong 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?---- ipHost is an objectClass in the ''nis'' schema of OpenLDAP so it is essentially ''core'' but you don''t say which LDAP server you are dealing with so YMMV. ----> - 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.---- these things become fairly obvious as you start to investigate ----> 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.---- personally, I gave up on using LDAP ENC from early struggles but that was made easy because I was able to get more functionality from the foreman and it too uses LDAP Authentication and even allows granular access to specific systems for specific users if you want to go there. I have also found it useful to assign parameters within the foreman Web UI. Craig -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <bwlist@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jan 25, 2012 at 10:57 AM, Throwe, Jesse <jesse@throwe.com> wrote:> 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. >Thank you for the details. I will keep these points in mind while I test the LDAP ENC. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.