[chef] Re: Question about new client registration for VM


Chronological Thread 
  • From: Dreamcat4 < >
  • To:
  • Subject: [chef] Re: Question about new client registration for VM
  • Date: Thu, 11 Nov 2010 15:23:24 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=quEJFUBklpJDIGgaUo/OoQ0r1XiYGTOkaMZ58VeiHaFhNW9uV8zZOhbsaNibIu9QNO yW4LzZ0dPRBPUdmbyKWq676ZZ7eJdV07MtLu37OhC0Z8ZNwQTCriojsNuova/LDQCl1K nQdCPKAHaU+raE/oxv8k0RnPSGm2knXzZVC2s=

Perhaps this happens:

chef-server-api/app/controllers/clients.rb:
  # POST /clients
  def create
    params[:name] ||= params[:inflated_object].name

    begin
      Chef::ApiClient.cdb_load(params[:name])
    rescue Chef::Exceptions::CouchDBNotFound
      exists = false
    end
    raise Conflict, "Client already exists" if exists

Although not 100% sure, i'm guessing that params[:name] comes from
node_name in chef-client's POST request:

    #
    # === Returns
    # rest<Chef::REST>:: returns Chef::REST connection object
    def register
      if File.exists?(Chef::Config[:client_key])
        Chef::Log.debug("Client key #{Chef::Config[:client_key]} is
present - skipping registration")
      else
        Chef::Log.info("Client key #{Chef::Config[:client_key]} is not
present - registering")
        Chef::REST.new(Chef::Config[:client_url],
Chef::Config[:validation_client_name],
Chef::Config[:validation_key]).register(node_name,
Chef::Config[:client_key])
      end
      # We now have the client key, and should use it from now on.
      self.rest = Chef::REST.new(Chef::Config[:chef_server_url],
node_name, Chef::Config[:client_key])
    end

So... it would seem that perhaps my initial assumption about the ip
address was unfounded. Node_name might not be getting set correctly,
or is an empty string "", etc, some other problem. Some of extra
logging won't hurt, should help to figure it out.

On Thu, Nov 11, 2010 at 12:16 PM, Dreamcat4 
< >
 wrote:
> On Thu, Nov 11, 2010 at 12:14 PM, Dreamcat4 
> < >
>  wrote:
>> Hi!
>>
>> I'm trying to register a Virtual Machine as new node. As we know -
>> chef-client sends up the validation.pem to download a new client.pem
>> file and register itself as a new node...
>>
>> An error occurs at the point where the client is expecting to receive
>> its new client.pem file from the server:
>>
>> "/var/lib/gems/1.8/gems/chef-0.9.12/bin/../lib/chef/rest.rb:80:in
>> `register': The response from the server did not include a private
>> key! (Chef::Exceptions::CannotWritePrivateKey)"
>>
>> Full log:
>https://gist.github.com/669039
>>
>>
>> Could this be because the chef server thinks the node is already
>> registered (because the host node shares the same IP address as the
>> Virtual Machine)?
>
> Another thing...
>
> In the mean time (as a work-around) I can create new VM nodes manually
> with "knife create client && knife create node".
>
> Then copy over the client.pem file into the Virtual Machine. However
> creating a node in that manner seems not to be ideal. All the Ohai
> attributes are missing. They are never uploaded / synced to the
> chef-server. Only the original attributes get updated (the run_list,
> node_name).
>
> However I think thats an entirely different issue to the original
> problem. They're missing probably just as only existing json
> attributes are being synced / updated. For my manually created nodes -
> by default do not start life with the ohai attributes. So no FQDN,
> uptime, ohai_time or anything else... :(
>
>
> Anyway. It would be great to better understand the initial problem
> regarding downloading the client.pem. I.e - Whats happening during the
> client validation / handshake. However its proving rather tough-going
> for me with all that encryption / security stuff going on in there! -
> Any help appreciated :)
>
>>
>> Regards
>>
>> dreamcat4
>
>>
>



Archive powered by MHonArc 2.6.16.

§