Micah Anderson wrote:
>> b) The Debian default in the versions so far which tried /once/ and then
>> exited without looping *at all*. That was what puppet <= 0.24 did
>> with "-w 0" and that's what the documentation still (incorrectly)
>> says.
>
> Doyou have a reference, or a commitsh where this changed? I suspect it
> was done inadvertantly by myself.
You had "-w 0" as the default for the package for sometime.
The semantics of this have been changed upstream in 0.24.5.
Puppet <= 0.24.4 had this:
bin/puppetd:345
if options[:waitforcert] > 0
begin
while ! caclient.request_cert do
Puppet.notice "Did not receive certificate"
sleep options[:waitforcert]
end
rescue => detail
Puppet.err "Could not request certificate: %s" % detail.to_s
exit(23)
end
else
unless caclient.request_cert
Puppet.notice "No certificates; exiting"
exit(1)
end
end
Note the special-casing of waitforcert=0; it requests a certificate and
if that fails it logs and exits puppetd.
0.24.5 moved all of the certificate code to a separate module that reads:
lib/puppet/executables/client/certhandler.rb:36
while true do
begin
if caclient.request_cert
break if read_new_cert
else
Puppet.notice "Did not receive certificate"
if @one_time
Puppet.notice "Set to run 'one time'; exiting with no
certificate"
exit(1)
end
end
rescue StandardError => detail
Puppet.err "Could not request certificate: %s" % detail.to_s
exit(23) if @one_time
end
sleep @wait_for_cert
end
That special case doesn't exist anymore, contrary to the (old)
documentation. waitforcert=0 results in a loop that never sleeps.
That was the bug all along.
The change that Thom made does something entirely different than the
original, pre-0.24.5 behavior. Not necessarily wrong, but different.
> I think that the prickly nature of how you have portrayed this has made
> your concerns seem confrontational, rather than constructive. At least
> from my outside perspective catching up on all of this from being
> gone.
Ack and sorry for this; the truth is that I'm frustrated by the way this
has been handled by Thom and you. I think that my private mail was
explaining all of my concerns over this. My offer for help by joining
the team still stands but I can understand any hesitations that you may
have right now.
>> Anyway, I think we can live for now until a proper debconf prompt is
>> made, even if it's not a real question but just used for preseeding.
>> "wishlist" is a bit of an understatement though, IMHO.
>
> A debconf prompt for how long the loop delay should be? This seems like
> an unnecessary use of debconf IMHO, but perhaps I misunderstand this piece.
Not an actual question; just a promptless question for enabling the init
script that can be preseeded.
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
