Issue #2776 has been updated by Daniel Pittman. Priority changed from Normal to Low
Ashley Penney wrote: > I want to bump this ticket because with 2.7.9 this is still relevant. Changing the Affected version doesn't actually do anything much around our scheduling, actually. :) > In my environment I was relying on two nameservers and one of these was > decommissioned (without anyone notifying me). I was able to correct all the > nameserver lines but I noticed that none of my clients had checked into > puppet overnight. I had to restart puppet on every single machine hit by > this issue in order to get it to operate again. Has there been any progress > in the last six months on this? I consider this to be kind of important > because a DNS issue shouldn't be enough to cause puppet to fail permanently > until restarted. Sadly, there is literally *nothing* that we can do to fix this - the failure happens in the depths of `Net::HTTP` from the standard Ruby library, which uses the standard `TCPSocket` class from Ruby core, which uses C code to call `getaddrinfo(3)` to fetch the data from the system. In other words, the upstream bug report - which was rejected - is entirely missing the point; as I wrote there: Sadly, the subject is a little misleading, which led to the ticket being closed, when the actual issue is quite real. We have this problem because we use `Net::HTTP` to make a request, which uses `TCPSocket`, which in turn uses `sock_addrinfo` down in the C code under Ruby 1.8.7 to resolve the name to an address. I have not actually dug into the implementation of that, but it certainly doesn't look to be using the `Resolv` library. Unfortunately, just loading `resolv-replace` wouldn't be enough, either: that uses Resolv to do the lookup, which is great, but it uses the class method family `Resolv.get*` to obtain the addresses. They, in turn, use `Resolv::DefaultResolver`, which is created at load time for the `resolv` code and never replaced - and neither is there a mechanism for us to replace that at runtime without hacking directly into code in that class and, obviously, breaking if a newer version of Ruby changed the structure. It would, ultimately, be great if the C implementation could support platform things like `res_init()` at the appropriate time, but even a fallback where we could use the Ruby level `Resolv` library without having to rewrite it ourselves or hack into the internals would be OK... Until that can be fixed upstream, there isn't much we can do here. If anyone else can figure out a way to resolve this, no pun intended, we would welcome the patch. ---------------------------------------- Bug #2776: changes to resolv.conf are not followed by puppet on clients https://projects.puppetlabs.com/issues/2776 Author: Ludwin Janvier Status: Accepted Priority: Low Assignee: Category: network Target version: Affected Puppet version: 2.7.9 Keywords: Branch: How to reproduce : 1) Comment "nameserver" lines in your resolv.conf (or, I suppose, any DNS-resolution config on the system) 2) Start puppet demon. Of course, I get messages : puppetd[10109]: Could not request certificate: Certificate retrieval failed: Could not find server puppet puppetd[10109]: Could not find server : getaddrinfo: Temporary failure in name resolution 3) Edit resolv.conf and restore namserver lines. Puppet is not able to get its server (same lines) This is not just a paper issue. In my farms, server get their DNS config via DHCP. And parameters are written a few seconds AFTER puppet start (even if network service is started before puppet). Thus, puppet is never working on my server ; I have to restart puppet by hand. See https://bugzilla.redhat.com/show_bug.cgi?id=532085 Version : 0.25.1 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
