If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

btm/cookbooks 6

Opscode Cookbooks for Chef

btm/emonMbus 4

Arduino firmware for a dedicated mbus master for Emoncms

btm/gem2deb 4

Set of tools to create Debian packages from Ruby software distributed with rubygems

btm/chef 3

A systems integration framework, built to bring the benefits of configuration management to your entire infrastructure.

btm/btm-cookbooks 2

Random unsupported cookbooks for Opscode Chef

btm/debian 2

Central storage for my work on debian packages

btm/aws-s3 1

AWS-S3 is a Ruby implementation of Amazon's S3 REST API

btm/chef-install 1

A perl based installer for Chef

btm/chef-repo 1

A blank Chef repository - useful to bootstrap your own

btm/chef-server-solo-install 1

Bootstrap a Chef Server via Chef Solo

issue commentchef/automate

IAM permissions for Automate users of InfraServer views

@kalroy I said something in the meeting, but I'll say again what you started here is great. :partying_face:

The permissions matrix feels pretty big and hard for us to make sure it is implemented and works as we desired. Have you thought about how to document that? For the ticket itself, for the tests, and/or for the final docs?

I thought about Administrator/Editors/Viewers versus Project Owner/Editor/Viewer some when I was drafting #5742, and it was clear we need to write down what this is holistically somewhere, but also I wasn't 100% sure on the appropriate terminology of policies/roles and which we would apply to the API and ultimately to the UI or UX decisions we would make based on that (e.g. don't display a tab, or leave it there but have it gray with a mouse-over that explains they don't have access or what).

Some of those decisions, like in #5742, we might need to make as we go. Or we could play it safe and require 'Administrator' for some new functionality, like the users tab, and then do a better job at identifying/discussing the personas that apply to those IAM policies in this epic.

I was looking at the IAM docs today and noticed this:

Two categories of resources exist for project assignment:

Ingested client run and compliance nodes Teams, API Tokens, Policies, and Roles created in Automate

Which doesn't mention Infra Server organizations. Which is a "doc bug" but, mostly, it's a reminder for me that this epic is a big body of work to do well.


comment created time in a day

issue commentchef/automate

Chef Automate supports managing Infra Server users

I split the org work out into


comment created time in 7 days

issue openedchef/automate

Automate Infra: Server + Organization Management

As the administrator of my companies Automate instance, I need to be able to easily add and manage the Infra Servers and Infra Server Organizations to Automate, so I can ensure everyone has appropriate access to only the Infra Server Organizations they're authorized to.

Context Users are global on each Infra Server or cluster (including Hosted Chef), there can be only one user named btm. Most other objects are separated into individual tenants called organizations.

Most customers have a small number of Infra Servers and a small number of Infra organizations on each server. However, some customers have hundreds of organizations on each Infra Server or Cluster.

Each server has a two global special default credentials, these are pivotal and webui, which are quite different in their use. These have similar broad permissions, sometimes called "super admin" in reference the the configurable "server admin" permission. They're different however, in that the pivotal credential is a "user" similar to other users, while the webui credential is not a user and has the special ability to impersonate other users. The webui credential is meant to only be used for service to service communication between the Infra Server and another service which users authenticate to, such as Chef Manage.

While users are global, they only have access to specific organizations. Provided an organization already exists, they gain access one of two ways:

  • An administrator adds them to the organization with chef-server-ctl org-user-add
  • They are invited to an organization by an existing member, then they accept the invitation. Both steps are possible using Chef Manage

Currently our implementation in Chef Automate has a username/client name and key attached to each organization when the organization is added. Then any user can access the organization through Chef Automate, provided they aren't limited or prevented by the current IAM Project based filtering/authorization (to be revisited later). This notably is not a 1:1 mapping of user keys to organizations, and was not intended to be the final implementation. This was an MVP to enable the body of work.

Rather than attempt an extremely complex integration of the Infra Server's authorization system (bifrost) with that of Automate (IAM), we want to perform all access control for Automate Infra using IAM in Automate, and provide the "infra-server-proxy" service in Automate with the webui key for each server. The Infra Server and infra-server-proxy are trusted services, just like the Infra Server and Chef Manage were. Because the webui key is unique for each server, rather than each organization, we need to move the key association up from the organization level to server level.

Before working on adding some remaining "Workflow Parity" like user management (which is global, and not per-organization) and organization management, we need to return to complete work on the Server and Organization management.


All Servers Page - https://AUTOMATE/infrastructure/chef-servers

  • [ ] Adding an Infra Server should require a key
  • The user/client/admin name field and key should be on the "add server" modal instead of add organization.
  • There should instructions to use the servers webui key (/etc/opscode/webui_priv.pem), although others could be used with varying results.
  • There should be a checkbox to indicate if the key provided is the servers "webui key" or not. If it is checked, the box for the name should be disabled and we will use save the name pivotal instead, but we don't need to display this in the box.
  • If the webui key is not checked, we should warn that functionality will be reduced and global objects such as users and organizations cannot be managed.
  • [ ] The Infra Server should be validated when added
  • When an IP address or hostname is provided, we should connect to the https://SERVER/_status, which is an unauthenticated API, and verify both an HTTP 200 return code, and also valid JSON.
  • With the credentials provided, we should connect to https://SERVER/license and verify a 200 and valid JSON as well. This is an authenticated API and will return a 404 if no authentication is provided, 401 with bad authentication, etc.
  • [ ] The list of configured servers ) should confirm basic status for each of them
  • We are able to connect to /_status, and the top level status key returns pong
  • We are able to authenticate to /license and it returns valid JSON
  • If both are true, display a ✔️ , otherwise a ❌
  • mouse-over of the ✔️ icon should show the /_status and /license results
  • mouse-over of the ❌ icon should describe what failed
  • [ ] The list of configured servers shows the number of organizations on the server and the number configured, e.g. "4 / 53"
  • currently this only shows the number configured
  • this can be counted by using the GET /organizations end point.
  • The webui key must be used to access this end point, if we get a 403 error we should show an ❓ instead and show the error in a mouse-over
  • [ ] All changes to the list of servers should require at least a global IAM 'Editor' role, if not an 'Owners' role?

Individual Server Page - https://AUTOMATE/infrastructure/chef-servers/SERVER

  • [ ] Allow creating organizations
  • Create Organization button next to Add Organization
  • Fields are: Full name (e.g. Chef, Inc) and Short name (chef), see the API docs
  • [ ] Allow deleting organizations
  • in the ellipsis (...) we should rename the current 'Delete' to 'Remove'
  • add a new 'Delete' that deletes it from the server and removes it from Automate
  • Delete should require the Owner role
  • [ ] when adding an organization, do not ask for the admin/key name or the key. All requests for this server will use the server key instead
  • [ ] The details tab should allow changing the credentials
  • Provide button that pops up a modal for a webui checkbox, name field, and key box that would change the key for the server
  • Do NOT display the existing key
  • perform the same verification as the add-server modal
  • [ ] the details tab should show the complete output of /_status and /license (pretty print, not in json)
  • [ ] the orgs tab should no longer show the "admin name" (because these will be associated with servers)
  • [ ] a user with a global IAM role of at least 'Editor' (owner?) should be able to change the IAM project on an existing organization.
  • [ ] only a user with Editor or Owner can add or delete an organization.
  • [ ] add a "reset validation key" under org ellipsis (...)
  • provides the new key as a popup, like manage
  • [ ] add a "invite user" under org ellipsis (...)
  • [ ] add a "remove user" under org ellipsis (...)
  • requires IAM Owner or owner on the project
  • [ ] add an "add user" under org ellipsis (...)
  • requires IAM Owner or owner on the project
  • [ ] When adding organizations, verify them
  • ensure that we can access /organizations/ORG_NAME with the provided key
  • [ ] When adding organizations, provide a drop down list rather than an text box if possible
  • if using the webui key, we can access GET /organizations and get the the list of organizations
  • if we're using hosted chef we can't access /organizations, we'll get a 403, so we must let them type it in
  • [ ] List the number of nodes in each organization on the server page
  • This helps easily determine which orgs are important and which ones aren't, convenience

Migrating Credentials from Orgs to Servers

  • [ ] If an org doesn't have a key, it looks up the servers key and uses that
  • we won't allow adding keys per org going forward
  • for backwards compatibility we look for an org key, and if it doesn't have one we use the server key

Out of scope?

  • [ ] Starter kit / config.rb (knife) download

created time in 7 days


issue openedchef/supermarket

Reduce automatic email responses to cookbook update emails

Supermarket sends email updates to followers of a cookbook when it is updated. The mysql cookbook currently has 781 followers.

Most (all?) email auto-responders do not recognize this as an automated email and will respond to these, e.g. a vacation autoresponder in Outlook letting someone know when you'll be back. This creates a lot of noise for the cookbook maintainer.

There are various headers that can be added to outgoing emails to indicate they are automated notifications that will prevent auto-responders from replying to them. Unfortunately there isn't a single agreed upon header, but it is a common enough problem that identifying a couple headers to add should present an easy reduction in emails.

I would suggest considering these two headers:

Auto-Submitted: auto-generated
X-Auto-Response-Suppress: OOF

A recent cookbook update email that I received from the public Supermarket contained these headers (most of these were added by intermediary email servers):


created time in a month

issue commentchef-partners/azure-chef-extension

Install fails with CC17 due to dependency on knife libraries

@ayushbhatt29 long ago, we shipped the entire Chef Infra Client in the extension. We stopped doing that, which was good. That was pretty big, so I don't think we'll have any issues if the extension wass 13M.

In this case, I think we can get by with shipping only the Ruby libraries necessary (knife, chef, some other dependencies) in the extension as well. This doesn't replace the Infra Client install but would give us the dependencies we need for this project without rewriting or duplicating code.

I'm thinking something like: add knife as a non-dev dep to the gemspec or Gemfile add bundle cache --cache-path= "#{CHEF_BUILD_DIR}/gems" somewhere in the Rakefile modify to install all the gems shipped with the extension like chef-install.psm1 currently does.


comment created time in 2 months

issue commentchef-partners/azure-chef-extension

Install fails with CC17 due to dependency on knife libraries

@ayushbhatt29 is there a limit on the size of the extension? The linux zip is 128K when built on my workstation. If I add knife to the dependencies for the gem, bundle cache, and then add the gems in vendor/cache to the build, it is 13M.

Would that work?


comment created time in 2 months

delete branch chef/supermarket

delete branch : btm/fake-fxi

delete time in 2 months

create barnchchef/supermarket

branch : btm/fake-fxi

created branch time in 2 months

issue commentchef/supermarket

Get permissions to zenhub

This should for everyone now.


comment created time in 2 months

issue commentchef/supermarket

Update the development documentation for 2021

There's a significant amount of internal documentation (some newer than others) here:


comment created time in 2 months