[chef] Re: Re: Re: Re: providing signing key from an alternative source

[andi abes < >]

I ended up creating a little monkeypatch for the rest client. This was complicated a bit by having different Chef objects instantiate their own REST client in subtly different ways...

In case it helps other folks still on 10.x, (and in case folk spot issues I didn't...)

https://gist.github.com/4502759

The idea is that once you "replace_authenticator", all future REST instances will use the alternative client/key.

On Mon, Jan 7, 2013 at 1:48 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Monday, January 7, 2013 at 10:41 AM, andi abes wrote:

what version are you looking at? I'm on 10.8

Ticket is:

http://tickets.opscode.com/browse/CHEF-3438

Which I think is only merged to master. If you're using Chef as a library in another application it should be fine to start from there (and super easy to do if you're using bundler).

-- 

Daniel DeLeo

 

On Mon, Jan 7, 2013 at 1:32 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Monday, January 7, 2013 at 10:14 AM, andi abes wrote:

I'm using the chef REST API client (in code), and I would like to provide the signing key from somewhere other than the filesystem.

Looking at Chef::REST::AuthCredentials, I'm thinking of replacing the load_signing_key by redefining the method.

Anyone else play with this? Any caveats? 

Looks like you just need to pass :raw_key => true to Chef::REST.new

-- 

Daniel DeLeo