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

Reply via email to