Several questions/suggestions on configuring Chef server using your hardware or cloud provider


The few that know me here know that I am a little OCD about documentation, so I have some suggestions and questions regarding “Install and configure Chef server using your hardware or cloud provider” ( ):

Suggestion: - Tell the user to make sure that the node in which they will install the Chef server has enough resources (I tried in AWS with a t2.micro and it complained of lack of memory; it worked fine with a t2.large; it seems it will work with a t2.medium, as that’s the one I used for the Chef server from the AWS marketplace).

Suggestion: - Tell the user that when running sudo chef-manage-ctl reconfigure, the installer will ask them to read a license, and that you exit from it with the “q” key and then you need to write “yes”.

Question: It says “You always create the initial user account directly from the Chef server on the command line. Later, you can add additional users from the command line or through the management console.”. Are you sure? If the management console is installed, the first user can be created with it (at least that’s what I did when I installed my Chef Server from the AWS marketplace).

Suggestion: Document this: When creating the organization with the chef-server-ctl command: the ORG_SHORT_NAME has to be all-lowercase otherwise it will complain:

$ sudo chef-server-ctl org-create mayitoOrg “MayitoO” --association_user mrincodi
ERROR: The data in your request was invalid
Response: Field ‘name’ invalid

$ sudo chef-server-ctl org-create mayito “Mayito Org, Inc.” --association_user mrincodi

This looks like a cosmetic bug to me: at least specify in the Response the constraints of this field.

Suggestion: Of course, another cosmetic suggestion is this one: Do not to generate nor display the RSA private key that chef-server-ctl org-create writes to the console in the chef-server-ctl org-create command (I imagine this will be done eventually).

Question: It says ” During the bootstrap process, knife copies the [Chef Server] certificate from your workstation to the node.” To the node? What for? Are you sure this is OK?

@tpetchel :slight_smile:



For a Chef server you really want ~4G minimum, and that should probably be specified. (I think t2.medium is 3.75G, which is close enough?)

As for the PEM that is created when you create an organization, that’s your validator key for the org. You need that to bootstrap nodes under normal circumstances, and the private key is not saved on the Chef server to the best of my knowledge so if you don’t save it right then, you have to reset it later on, you can’t just retrieve it. This is the key that is copied during bootstrap, and the only purpose of that key is to authorize nodes with that key to create themselves as clients. (It’s a glorified pre-shared key, really, just using a PEM format instead of a passphrase.)

Nathan Clemons
DevOps Engineer
Moxie Cloud Services (MCS)

O +1.425.467.5075
M +1.360.861.6291
W www.gomoxie.com


I want to clarify a few things here. Firstly, Chef 12 defaults to a “validatorless” bootstrapping mode which uses your user’s credentials to create the client identity and key for nodes when you bootstrap them with knife bootstrap. This improves security and audit-ability since you’re not passing a shared key around, and also improves the user experience by making several error conditions happen before launching a new VM and waiting for it to boot and install Chef. Therefore, you only really need the validator client if you are doing unattended installs (of whatever sort).

Also, you are no longer limited to just a single validator client, you can create as many as you want now; you just specify that a new client should be a validator when you create it.