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 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" 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. 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. 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 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. -- Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci Princeton University | ICBM Address: 40.346344 -74.652242 345 Lewis Library |"On my ship, the Rocinante, wheeling through Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus, (267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1' -- 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/CANnpg5SpJitWLjR4LvfMHfMH8NT4kALfgkzKbDatNBZwM7SDAg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
