Hi Steve, thanks for tracking this down! The LDAP node terminus is a useful but pretty cobwebby corner of Puppet (IIRC it predates the existence of the External Node Classifier API which is what most sites are using now). So as you found its docs do not get a lot of love and there are no acceptance/CI tests that cover its use.
I have a couple of comments inline. Our education team ran across this issue, which is why I'm replying to a months-old thread. We're tracking it in JIRA at https://tickets.puppetlabs.com/browse/SERVER-711 On Tuesday, February 3, 2015 at 2:40:50 PM UTC-8, Steve Huston wrote: > > So, I've spent another day beating on this problem and finally > achieved success. We started with: > > > # puppetserver gem install ruby-ldap > > Nobody pointed out, either here or in the documentation, that when > using puppetserver you have to use "jruby-ldap" instead. Once I did > that, the gem installed, yay! But it still didn't work. When the > server attempted to do a lookup it would still report that the search > failed, even though tcpdump showed it asking for the CN and getting > the right answer. > > After quite a bit of prodding and help from a colleague I found that > jruby-ldap does not have a to_hash method in LDAP::Entry. This was > confirmed by a bit of code and comment at the top of > > https://github.com/alibby/ldap_authenticated/blob/master/lib/ldap_authenticated.rb > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Falibby%2Fldap_authenticated%2Fblob%2Fmaster%2Flib%2Fldap_authenticated.rb&sa=D&sntz=1&usg=AFQjCNHByxK-zpNHjvHylNOMedsrd7ciBw> > > > I inserted that code into the ruby module, since I would have to > manually upgrade that but the puppetserver RPM might get upgraded (and > wipe out that change), and got a little further. Now, however, it > failed with another error: "Puppet Cannot reassign variable macaddress > on node syrinx.astro.princeton.edu" > It seems like the to_hash change would be better off as a patch to the upstream module vs a monkey-patch in Puppet. > > On our old server running under passenger, if I look at > /var/lib/puppet/yaml/node/syrinx.astro.princeton.edu I see there's > both a "macaddress" and a "macAddress", so I realized what's going on > - the downcase in that code snippet is causing two facts to appear at > once. > That's not great either :( > > All in all, this tells me a few things: > > 1) The documentation for using LDAP with the new puppetserver needs to > be updated to reflect not only that one must use 'jruby-ldap' (and > puppetserver gem install at that) but that the tests listed (running > ruby -rpuppet -e 'p Puppet.features.ldap?' and such) are incorrect as > they will report 'true' if you have the gem installed through the > normal system commands but puppetserver will not see it. > That's true. Would you be willing to work up a pull request against the puppet-docs repo with the things you've learned? The source markdown for the guide is here: https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/ldap_nodes.markdown > > 2) There needs to be a patch, perhaps somewhere in puppetserver, that > makes sure the jruby-ldap LDAP::Entry class has a 'to_hash' method (or > code around the necessity of needing it), for example: > > if RUBY_PLATFORM =~ /^java.*/i > class LDAP::Entry > def to_hash > h = {} > get_attributes.each { |a| h[a.to_sym] = self[a] } > h[:dn] = [dn] > h > end > end > end > As I said, I think this would be better as an upstream patch to the jruby-ldap project, especially since you found another project that had to do the same thing. Carrying individual monkey-patches against upstream projects is a practice that rarely ends well in my experience. > 3) I discovered when I spun up my VM this morning that puppetserver > failed to start because it wanted to create a /var/run/puppet (which > it does not appear to actually use thereafter). Since /var/run is on > a tmpfs on RHEL7, and owned by root, yet the puppetserver process runs > as user 'puppet', this will fail on every reboot. Admittedly I'm not > running the puppetlabs RPM, but our package maintainer does a very > good job of making sure that the scripts and setups are duplicated if > he rebuilds something - please correct me if the logic to recreate > this directory is included somewhere and I can point it out to him to > fix in our repository. > > This one is fixed in Puppet Server 1.0.8 and 2.1.0: https://tickets.puppetlabs.com/browse/SERVER-336 --eric0 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f2cb5d50-7ea5-45a0-9e5e-c117eda82fe3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
