Release: Enterprise Chef 11.2.0 and Chef Analytics 1.0.1

We are pleased to announce the release of the Enterprise Chef 11.2.0 server and Chef Analytics 1.0.1.

Enterprise Chef 11.2.0

What’s New

  • oc-id Adds the Chef Identity Service. This enables Supermaket and Analytics authentication against the Enterprise Chef Server.
  • Analytics Support
    • dark_launch['actions'] defaults to true. You no longer need to manually set this in the private-chef.rb
    • Reconfigure will copy /etc/opscode/webui_priv.pem into /etc/opscode-analytics if actions is enabled
    • This change adds a new ‘oc-id’ key to the private-chef-secrets.json.
  • private-chef-ctl Add a gather-logs command to create a tarball of important logs and system information.
  • orgmapper Bump orgmapper to a new minor revision. This enables support for the bifrost/authz API and fixes several bugs.
    • Add bifrost_sql_database uri to orgmapper.conf
    • Upgrade to rel-0.5.1

Bug Fixes:

The following items are the set of bug fixes that have been applied since Enterprise Chef 11.1.8:

  • [OC-11297] tweak partybus migration-level subscribes for a more reliable workaround
  • [OC-11585] Allow ['lb']['upstream'] to have a custom setting
  • [OC-11459] Allow opscode-manage to easily be moved off of 443
  • [OC-11540] Fix invalid opscode-account config when forcing SSL
  • [OC-11575] Don’t start services by default on the standby backend node in HA topology
  • [OC-11601] Fix a race condition that sometimes caused redis_lb to attempt to reconfigure itself before it was restarted.
    • This change causes redis_lb to restart during every reconfigure. This restart can cause a short period of 500 errors on the on the FE nodes.
  • [OC-11668] enable ipv6 in standalone mode
  • [OC-11672] Upgrade PostgreSQL to 9.2.9
  • [OC-11673] Tune PostgreSQL keepalive timeouts
  • [OC-11702] Fix bug that prevents ACL and group expansion when containing group that no longer exists
  • [OC-11708] Fix user association bug when last updater of users group is no longer associated
  • [OC-11710] Fix couchdb compaction log rotation

Security Fixes:

The following items are the set of security fixes that have been applied since Enterprise Chef 11.1.8:

  • OpenSSL 1.0.1i addresses CVE-2014-3512, CVE-2014-3511, CVE-2014-3510, CVE-2014-3507, CVE-2014-3506, CVE-2014-3505, CVE-2014-3509, CVE-2014-5139, and CVE-2014-3508.
  • PostgreSQL 9.2.9 addresses CVE-2014-0060, CVE-2014-0061, CVE-2014-0062, CVE-2014-0063, CVE-2014-0064, CVE-2014-0065, CVE-2014-0066, CVE-2014-0067

Download

Contact your sales representative for a link to download the patched version of Enterprise Chef.

Upgrade Instructions

Follow the upgrade instructions on the Chef Documentation site:

Chef Analytics 1.0.1

Improvements

  • feature(profile): Remove profile URL from web frontend pending redesign of profile page
  • feature(omnibus): Use latest omnibus-ctl 0.1.0
  • feature(dateRangePicker): Implemented date range picker
  • features(tagging) Update consumer to add Chef Manage on actions from UI
  • feature(actionDetails): Clicking on the remote request id in the details adds a filter for that id.
  • feature(tooltips): Added tooltips to toggle icons in the search area.

Bug fixes

  • fix(upgrade): Always start postgres and rabbitmq during upgrade process
  • fix(cursor): fix inconsistent cursor use
  • fix(actions): Added support for organizations named “login”
  • fix(login): Login page shows ‘Signed in as’ when you have an active session
  • fix(export): Can now supply a base filename to exports before downloading
  • fix(savedSearched): Selecting a saved search now populates the date pickers.
  • fix(e2e): Protractor E2E tests should pass reliably.
  • fix(search): Improve fuzzy search
  • fix(saved search): updating existing search throws 500

Security updates

  • Update openssl to 1.0.1i
  • Update rails to 4.1.5

Upgrading Chef Analytics

To upgrade to Chef analytics 1.0.1 you do not need to stop your Enterprise Chef . You do need to stop your running Chef analytics 1.0.0 instance.

  1. Stop Chef analytics
    opscode-analytics-ctl stop
  2. Install the new package, e.g.:
    rpm -qa opscode-analytics-1.0.1-1.el6.x86_64.rpm
  3. You can re-run the preflight-check at this point to check if your Enterprise Chef is configured correctly
        opscode-analytics-ctl preflight-check
        Preflight check successful!
  4. Reconfigure Chef Analytics
    opscode-analytics-ctl reconfigure
  5. Start Chef Analytics
    opscode-analytics-ctl start
  6. Check it is running
    # opscode-analytics-ctl test 
    OK: Chef Actions running at 'https://analytics.example.com/'
    

Compatability

Chef analytics 1.0.1 is compatible with both Enterprise Chef 11.1.8 and 11.2.0.

Getting Started with oc-id and Supermarket

Enterprise Chef 11.2.0 includes oc-id, the OAuth2 service that powers id.opscode.com.   After upgrading to this release, Chef customers can run their own Supermarket service behind a firewall.

oc-id setup:

1: Add the following setting to your /etc/opscode/private-chef.rb configuration file and then run ‘private-chef-ctl reconfigure’:

oc_id['administrators'] = ["boiardie"]

This must be an Array of Enterprise Chef users who are authorized to manage the oc-id service. An extended list of oc-id related options for private-chef.rb is available on the docs site.

2: Log in to your Enterprise Chef server’s oc-id management portal at https://mychefserver/id and you will be directed to the oc-id authentication page. Log in as an administrative user as defined in step 1, and you will be displayed a screen showing that you don’t have any authorized applications:

3: Change your URL to https://mychefserver/id/oauth/applications (sorry, there’s no button or link to do this yet) and you’ll see a screen to add/manage applications:

NOTE: Applications in this context refers to OAuth2 client systems that will authenticate against the oc-id service (like Supermarket).

4: Click the New Application button and fill in the application name and Redirect url:

NOTE: the Redirect URL must contain the oauth2 callback URL, which is /auth/chef_oauth2/callback for supermarket.
NOTE2: If your users access the supermarket server by different URLs please note those here.

5: After you click Submit you will be shown the Application Id and Secret strings which you must supply to Supermarket.  Copy these down, but don’t worry about losing them. You can always retrieve them from the /id/oauth/applications URL of your Chef server.

 

Supermarket setup

Currently Supermarket does not have an Omnibus package and must be configured using the supermarket cookbook.  These instructions will use test-kitchen to setup your Supermarket instance in Vagrant.

1:  Download the supermarket cookbook, and edit the .kitchen.yml file to add a private_network IP address:

---
 driver:
 name: vagrant
 customize:
 memory: 1024
 network:
   - ["private_network", {ip: "33.33.33.30"}]

2: Edit the chef_oauth2 section of the data_bags/apps/supermarket.json file.  Note that the url field is the URL of your Chef server without a URI.

"chef_oauth2": {
"app_id": "14dfcf186221781cff51eedd5ac1616761b31e8947e51f28232537313c5c9c40",
"secret": "a49402219627cfa6318d58b13e90aca164aad2e263fb8f05b766e01f97450c1d",
"url": "https://54.187.77.86"
},

3:  Fire up your supermarket instance

kitchen converge default-ubuntu-1404

4:  Once running navigate to http://33.33.33.30 and log in to your new Supermarket instance.   You will see a request to authorize the application. This only needs to happen once.

5:  Success!  You should be logged in to your Supermarket server as the requested user.

oc-id Caveats as of EC 11.2.0

  • There is a known issue with Supermarket that it verifies the SSL certificate of the oc-id server and this setting cannot be overridden (workaround provided).
    • When this happens (at application authorization time) users will only be displayed a generic “something went wrong” error message.
  • There is no link to the application management interface in oc-id, you must enter it manually.
  • If you are not logged in as an oc-id administrator, the application management URL will display a 404 “Page Not Found” error instead of a 403.
  • Many of the links in Supermarket will take you to manage.opscode.com instead of your Chef server

 

Release: Chef Development Kit 0.2.1

Ohai Chefs,

As of today version 0.2.1 of Chef Development Kit is available on our download page. Starting with this version, Chef Development Kit is now supported on Mac OS X 10.8 in addition to 10.9.

The other changes included in this release are:

  • chef gem install can now install gems with native extensions on Windows.
  • Fixed a bug in chef exec to set the ENV correctly. This resolves errors like this when running commands with chef exec.
  • Make supermarket the default source in generated Gemfiles.
  • chef generate repo command is now available. This command generates a chef repository which is equivalent to chef-repo.
  • Generators do not require Administrator privileges on Windows anymore.

You can visit http://downloads.getchef.com/chef-dk to get this version. If you run into any issues please file a bug in our issue tracker.

Behaving Responsibly in the Chef Community

Today one of our most prolific community members announced his decision to leave Chef and go on a software engineering sabbatical, in part because of how he was treated by a few members in our community. As a company, Chef takes the safety and security of our employees extremely seriously. Further, it is our heartfelt desire to have a community where diverse opinion is welcome and where members feel safe and secure to engage in healthy, and sometimes spirited, dialog with the mutual goal of creating value and growing as professionals and human beings. As a community, we need to use this event as a moment to reflect on how we treat each other.

De-humanizing the authors of software

It is easy to anthropomorphize software and praise it when things go well and curse or even hate it when things do not. In open source projects it’s easy to identify the authors and maintainers of a particular software project and direct your feelings about the software towards those individuals. Likewise it is easy for the individuals who see comments made in public forums such as twitter, mailing lists, and GitHub to take these comments very personally.

Often times, the most prolific contributors are very dedicated and, as a result, can be very opinionated and passionate about their projects. This dedication and passion are, in fact, characteristics of many great engineers. At times, these very same characteristics can make these people targets of misguided rage, anger, and hurtful words and actions. It is sad to see a talented and passionate member of our community make the decision to leave as a result of how they were treated. We, the collective individuals that make up the Chef Community, should take this opportunity to reflect on how we treat one another and on how we can use the power of the community to lift people up rather than tear them down. And at the same time, we should also consider how diversity in opinion and style can make us all stronger and better.

The Chef Community

The Chef community is a mixture of professionals and volunteers who come from all over the world and work together to make Chef better, including mentoring, teaching, and connecting with other members of the community. Diversity is one of our biggest strengths, but it can also bring increased communication challenges at times.

As a community member, you know that the Chef community is an environment built on generosity, professionalism, friendship, and hugs. As a result, we’ve adopted and published a set of community guidelines.

As a company, Chef stands behind and helps enforce these community guidelines. As a community, we must be ever vigilant of our guidelines and ensure that they are comprehensive and supportive of our diverse community.

Behavior that violates these guidelines is unacceptable and should and will not be tolerated by anyone in our community nor by Chef.

We are reviewing and enhancing these guidelines right now as part of our ongoing efforts to improve the Chef Community. Going forward, our community guidelines will include a clear path for handling incidents and a discussion on the actions that will be taken when someone violates our guidelines. Specifically, our guidelines must:

  • Outline actions that will result in punitive action
  • Indicate who is responsible for determining when punitive action is warranted
  • Specify punitive actions and an appeals process

The code of conduct we use for #ChefConf is explicit about these things and will inform the new guidelines.

Committed to the Community

Chef takes allegations of misconduct very seriously and will investigate and address each incident. As a community, we are refining our policies and procedures for upholding our community guidelines.

Behavior outside of our community guidelines is unacceptable and should and will not be tolerated by anyone. If you encounter such behavior, please contact a member of the Chef community team immediately.

Next Steps

Thank you for participating in these conversations. Here are some immediate actions you can take to help us improve the community.

  1. Behave responsibly and help us address unacceptable behavior when it occurs.
  2. Participate in the RFC to rewrite our community guidelines.
  3. Join us at the next Chef Developers’ IRC Meeting to discuss the RFC.
  4. Join us at one of our upcoming Chef Community Summit events to discuss this topic in person with other community members.

Thank you for helping our community grow and evolve.

Nathen and Adam

Serving Up Delight at the Community Summits

We are excited to announce this year’s Chef Community Summits! The Chef Community Summit is a a unique opportunity for open-source contributors, Chef engineers, and Chef users of all experience levels to come together and share their passion and excitement for Chef.

This intimate gathering of enthusiasts is facilitated as an Open Space event. Participants of the Summit will propose topics, organize an agenda, and meet to discuss and work on the ideas that are most important to the community.

This year we’ll be hosting Community Summits in both Seattle and London

Some likely topics include:

  • What is the roadmap for Chef?
  • What best practices have emerged & how should we share them?
  • How will our community grow while serving experts & welcoming newcomers?
  • What should #ChefConf & other events in 2015 cover?
  • Additional topic ideas are being proposed on the Chef Community Wiki.

Seattle – October 2-3

London – October 15-16

Limited sponsorship opportunities are available for the Seattle Chef Community Summit checkout the sponsorship prospectus for additional details.

See you in Seattle and London!

DSC… WHAT IS IT FOR, REALLY?

This was originally posted on stevenmurawski.com.

An email recently came across one of the mailing lists I subscribe to. I wanted to share my answer here, because this is an important discussion.

Is DSC for Setup or Management?

Yes (notice, it’s not an XOR)

In my opinion, DSC (and Chef) is for setup and the management of the structural configuration of the system. To directly address some of the questioners initial points:
Do I need to develop custom DSC resources (for example to create DFS folders and links) and apply a new configuration each time I have to create/or modify a DFS link? Or should I stick to the traditional system administration (I mean using PowerShell cmdlets or the GUI)?
Well, currently you’d have to implement a custom resource for DFS shares, but you don’t need a custom resource per share. You would need to modify your configuration to add a new share, but modifying a configuration should be almost a non-event.

These Aren’t Your Grandma’s Shell Scripts

If you buy into the Configuration-As-Code or Infrastructure-As-Code concept, one of the first things you want to tackle is building a pipeline to deliver those configurations to your servers. Whether you use a pull server setup (my preference) or you push configurations out to individual nodes, having a solid delivery mechanism makes changing configurations not much more difficult than editing a file and checking into source control (which is way easier than the “traditional” approach). Setting up this pipeline IS work on the front end, but pays dividends in your ongoing maintenance of your environment.
I realize that it could be tempting to use DSC as a management system, but I think it is not a good use of DSC at all (please correct me if I’m wrong). Indeed, in order to manage a computer you have to modify (and reapply) the current config of the machine and that may take more time than using the usual cmdlets to get the work done.
If you are spending more time modifying the configuration (once you have resources and pipeline in place) than it would take to configure it on a server or series of servers, we need to sit down and have a chat. Yes, building a resource takes time.

Setting up a test environment takes time.

Structuring your configuration data takes time.

Building a deployment pipeline takes time.

It seems like a lot of time, when you could just RDP over the box.. or even quicker, use PowerShell remoting or some CIM cmdlets right at the box. But so does interactively managing each of your servers.

Over time, interactively managing (and rebuilding, and testing when the next OS ships) tends to take way more time than if you invest in your configuration testing and deployment process. That’s one of the advantages to the Chef ecosystem.. there’s a great testing platform, which is being rev’d to make Windows testing easier (and supports DSC via the Chef DSC integration, and hopefully as a native provisioner in the near future).

But DSC will solve my DR problem though, right?

But if I stick to the good old traditional system admin what if my server crashes? Well, I’ll need to restore my machine as usual. That being said (please react to this), in a DSC world – where I would have managed my server by reapplying a new config after each creation of DFS link (for example) – in case of crash I would only have to apply the configuration to a (bare) new machine right? This way, in a few minutes I get a fresh up and running machine with the DFS role installed AND all the configuration (DFS links recreated, etc.). Am I right???
Exactly. One of the benefits of using a declarative configuration management system is that you can more easily recreate the infrastructure that hosts a particular service.

But it is more than DR

This isn’t just a DR thing. Now that Microsoft is picking up the cadence of OS releases, that means the support cycle is tightening.

Remember the whole N-2 support for management tooling? When releases were 3 years apart, that gave you 9 years to stay current if you installed the latest release. When the release cycle is more 12 to 18 months, then you are down to 2 to 4.5 years for backward compatibility in management tooling. That means, to stay current, we have to be able to cycle to new server platforms faster.

The patching story is changing as well. Now there are servicing points you have to hit to continue to get patches (that’s the whole story behind the “with Update” thing and why the Server 2012 R2 image on MSDN was updated to “with Update”). That was roughly 6 months after the OS went Generally Available? How quickly can you get your environment up in a test lab to test those updates? With declarative configuration management, just supply some different environmental data, and you can stand up near clones of your production environment for testing.

Remember when I said SysAdmins could pull some good ideas from Development?

We need tools to help shorten the cycle in which we can deploy new operating systems and keep things patched. These tools exist – DSC, Chef, Test-Kitchen, ServerSpec, Vagrant, GuardRail, and more. These tools give us the ability to rapidly develop new resources and to build an automated pipeline that can deliver tested, high quality configurations to our servers.

We can leverage the concepts in Continuous Delivery to improve our ability to deal with infrastructure changes.

  • Automate all the tests we can.
  • Assume people checking in changes are professionals and optimize the pipeline for success.
  • Don’t leave the pipeline in a broken state.
  • Don’t be afraid to “Roll Forward” and fix things that break (vs. looking to roll back).

What would you say if you could have a process that, once patches came out on Patch Tuesday, that a process kicked off spinning up a test version of your environment, applied a patch at a time, ran smoke tests, and at the end you got a report of any breakages, and which patch things broke on? That’d be awesome and is totally achievable.

Don’t get laughed at

When human beings do things that the computers are perfectly capable of… Late at night the computers get together and laugh at us – Neal Ford
We need to move away from manually implementing changes and manually checking changes and put automaton in place that does these standard, repeatable tasks and save the humans for the interesting, challenging work that we are better at.

Chef demonstrates vCloud Air integration at VMworld 2014

We’re pumped for VMworld this week, especially because our own Matt Ray is taking part in a cool joint demo with our friends at VMware. Tomorrow (8/26) at 4 pm PT, Matt is joining Jay Marshall from VMware in demonstrating Chef’s ability to automate the management and migration of enterprise workloads in both vSphere and vCloud Air environments.

Here’s an excerpt from the abstract:

“…Achieving infrastructure portability and harnessing the benefits of continuous delivery remain an elusive goal for too many users. VMware’s Jay Marshall and Chef’s Matt Ray share the stage to illustrate how to architect a multi-node application using Chef, and then deploy that application to vCloud Hybrid Service to simulate a test/dev sandbox in the cloud. That exact same Chef cookbook will then be used to deploy the application into Production in an on-premises vSphere environment… In the end, attendees will walk away with working knowledge of how to provide their developers and operators with a cloud-based Test/Dev environment on vCloud Hybrid Service instrumented with Chef, while still maintaining production SLAs and control over their Production workloads.”.

In other words, Matt and Jay will show how Chef and vCloud Air give you the ability to speed software and service delivery using a single platform for automating both virtualized and hybrid cloud environments.

In addition to Matt and Jay’s session, VMware vice president of Hybrid Services, Ajay Patel, will be introducing vCloud Air at VMworld during a breakout session today at 12:30 pm PT, where he will detail the roadmap for this new platform.

When you’re not checking out these sessions, please stop by our booth # 2346 for a Chef Tee, swag, and a chat with one of the many Chefs on-site.

Learn how Scholastic migrated to AWS with Chef automation

Daryn McCool was nice enough to share the story of Scholastic’s major IT modernization initiative with us. It was a great opportunity to have an enterprise customer walk through their journey to the cloud.

If you are considering an IT modernization project or looking for best practices in the community, I’d recommend watching the webinar.

A few themes stood out: Read more ›

On Joining Chef

As many of you in the Community have seen by now, I recently joined Chef as a Vice President (more on what in particular I will be up to in a minute).

I first came across the open source Chef project while working at ThoughtWorks, where we got to experiment with various new technologies in order to find the best solutions to solve our customers’ problems. Chef began to crop up more and more frequently in our internal discussions of which tools had been effective, and I was sufficiently impressed that it got a few mentions in the Continuous Delivery book that Dave Farley and I published in 2010.

Four years later, Chef — both the product and the company — is going from strength to strength. I have seen many companies use Chef’s platform to enable their move to continuous delivery, and I’m excited about our plans for the future. I am delighted to have the chance to be part of its evolution and growth — and to count among my colleagues some of the people I admire most in our community.

Now back to what I’ll be doing. My focus will be to grow a high velocity organization that delivers the most awesome customer experience in the industry. Organizational culture and development are topics that form the core of my forthcoming book, Lean Enterprise, and I am super excited that Chef has asked me to be part of further developing their high performance culture.

I’ll be writing periodic updates both here and at http://continuousdelivery.com/. You can also follow my progress on Twitter — and I’m hoping to make it to as many Chef community events as I can, starting with FlowCon in San Francisco.

Jez Humble Joins Chef as Vice President of Development Velocity

Continuous Delivery Pioneer to Play Leadership Role at Chef as Enterprise DevOps Adoption Surges

SEATTLE – August 20, 2014 – Chef, the leader in web-scale IT automation, today announced Jez Humble has joined the company as vice president of development velocity. Humble is the co-author of the highly influential book Continuous Delivery:Reliable Software Releases through Build, Test, and Deployment Automation. A noted speaker and lecturer at the University of California, Berkeley, Humble is widely regarded as one of the premier leaders in agile software delivery practices and the implementation of positive organizational change. At Chef, Humble will play a leadership role in shaping Chef’s own engineering processes and will guide Chef’s continuous delivery solutions strategy amidst surging enterprise DevOps adoption.

Read more ›

Archives