[chef] Re: Re: Re: Re: Using chef-server as Berkshelf source

[Gregory Patmore < >]

without manipulating the original cookbook you can just execute an overwrite recipe afterwards. I'm sure there are slicker, more oop oriented ways to do it though. 

This is a common problem in a lot of the community cookbooks though. Partially hard coded values in resources are the most difficult to work around without altering the original recipes. 

Sent from my iPhone

On Jun 20, 2014, at 3:37 PM, Nathan L Smith < "> > wrote:

Ringo,

It won't ever be part of the Management Console, because that's just the web interface. There has been talk of making an endpoint in the Chef server itself, but not any work currently in progress.

Supermarket will be implementing the Berks /universe endpoint (see https://github.com/opscode/supermarket/pull/431), and you can run your own internal instance of Supermarket (this isn't super easy yet, but we will have Omnibus packages for it at some point.)

Hope that's useful.

Thanks,

On Thu, Jun 19, 2014 at 9:16 AM, Ringo De Smet < " target="_blank"> > wrote:

Will the "Enterprise Chef" (https://manage.opscode.com) ever act as a Berkshelf API source?

Ringo

On 7 January 2014 05:44, Pete Cheslock < " target="_blank"> > wrote:

One of our engineers wrote (and we subsequently open sourced [1]) a simple API endpoint for Berks 2x.  This allows us to use an organization on our enterprise chef server - but give an API endpoint for the Berksfile to point to so that there is no need to give any engineers keys to the chef server.   

With Berks 3 - you will need to run an API [2] (or use api.berkshelf.com) anyway, so when berks 3.0 ships should be a minor change to your berksfile (if and when you do upgrade).

[1] https://github.com/dyninc/cookbookapi

[2] https://github.com/berkshelf/berkshelf-api

On Mon, Jan 6, 2014 at 7:00 PM, Joe Nuspl < " target="_blank"> > wrote:

Since a chef-server can be a Berkshelf source, I'm wondering how people are dealing with client keys.

Our CI will take care of uploading cookbook so "developer" access will be read-only.

I see a couple ways to approach this:

1) One global client.pem that all developers will use.  Since the endpoint is behind a VPN, if that key gets out, the  exposure is mitigated.

2) Managing individual client per developer.  Although this is the most "secure", it does carry the highest ongoing maintenance cost.

3) Disabling authentication all together (i.e. chef-zero)

4) Since I already have access to the developer's ssh public via LDAP, somehow tie them together.

What are others doing?

        Joe

--

Nathan L Smith

" style="color:rgb(17,85,204)" target="_blank">