This document contains an overview of significant customer-facing changes in the release. For a detailed list of changed components, refer to CHANGELOG.md.
This document contains release notes for the current major release and all patches. For prior releases, see PRIOR_RELEASE_NOTES.md.
- The verbose option for the user list API now also includes the display_name attribute.
-
A bug in our pre-flight validation for Elasticsearch heap_size that resulted in a confusing error rather than a helpful validation warning has been fixed.
-
We now explicitly set TMPDIR during Elasticsearch startup. This should resolve Elasticsearch startup failures for some users who have temporary filesystems mounted with the noexec option and are using SELinux.
-
We now retry in more cases when attempting to create the Elasticsearch index which should prevent upgrade failures for some users.
-
Updated Components
- elasticsearch (6.8.1 -> 6.8.12)
Upgrading to Chef Infra Server 14 will require a reindexing operation for users not currently using elasticsearch. We expect this reindexing operation to take an estimated 2 minutes for each 1000 nodes. However, this estimate can be substantially impacted by your server hardware and the complexity of your Chef data. Generally the size of Elasticsearch indices is observed to be 1/10th of the Postgres database size. To be safe we would recommend that the filesystem containing the /var/opt/opscode directory should have at least 20% free space before upgrade. Learn more about upgrading to Chef Infra Server 14 18.
- Elasticsearch-based search indexing: Chef Infra Server now uses Elasticsearch as its search index. Solr RabbitMQ and opscode-expander, which supported the older search indexing pipeline, have been removed. Hosted Chef and some of Chef Infra Server's largest customers are already using the Elasticsearch-based search indexing. The simplified indexing pipeline should reduce the operational complexity of Chef Infra Server.
- Oracle Java is now removed and fully replaced with OpenJDK. This removal resolves a number of CVEs in Oracle Java by switching to a newer, compatible build, which does not have the license restrictions that Oracla Java releases after 8u202 have.
- Erlang 22: All Erlang components now run on Erlang 22. This upgrade sets the groundwork for new features and bug fixes currently in development.
- Improved Indexing Metrics: The /_stats API endpoint now returns metrics about search indexing. These new metrics should allow us to more easily investigate problems that users report with search indexing.
- Integration Testing: In Chef Infra Server 13.2, we added a new integration testing pipeline. We've further improved this pipeline, expanding the testing scenarios and improving the fidelity of the existing scenarios.
- New Command: chef-server-ctl now features the check-config command, which runs only the configuration portion of the reconfigure cookbooks and preflight checks.
- Reduced API errors caused by a change to the HTTP library used in Erchef.
- Expanded the cases where we gracefully report errors that result from a chef-server-ctl reindex command instead of failing early.
- Fixed a bug that prevented API Signing version 1.2 from working with FIPS-enabled Chef Infra Servers.
- Updated NginX SSL configuration format to avoid warnings in the log.
- Restricted permissions on the dhparams.pem file used by NginX.
- The /controls API endpoint now always returns HTTP 410 Gone. This endpoint was disabled as it requires RabbitMQ to work. The /controls API endpoint was used by Chef Infra Client's audit mode. In Chef Infra Client 14, this change will produce a non-fatal error that results in the audit log being written to disk. This feature was removed in Chef Infra Client 15. The main consumer of this endpoint was Chef Analytics, which has been end-of-life since December 31, 2018.
- Chef Infra Server no longer sends data to Chef Analytics. Chef Analytics was declared end-of-life on December 31, 2018.
- Chef Reporting is not supported. Chef Reporting was declared end-of-life on December 31, 2018.
- Chef Infra Server will no longer send data to Chef Automate 1.x via the Actions queue. Chef Infra Server still sends data to Chef Automate 2 and Chef Automate 1.x via the data-collector endpoint. Chef Automate 1.x was declared end-of-life on December 31, 2019.
-
Updated Components
- libiconv (1.15 -> 1.16)
- pcre (8.38 -> 8.44)
- cacerts (2019-10 -> 2020-07)
- openssl (1.0.2u -> 1.0.2w)
- openresty (1.15.8.1 -> 1.17.8.2)
- veil-gem (58373899 -> 2875f29d)
- erlang (20.3.8.9 -> 22.2)
- server-open-jre (11.0.4+1 -> 11.0.7+1)
- ohai (d78fd24c -> 0b8b5ccf)
- liblzma (5.2.4 -> 5.2.5)
- libarchive (3.4.2 -> 3.4.3)
- chef (3fe96500 -> 20230f04)
- knife-opc (5a3a804b -> dd17d445)
- knife-ec-backup (61b8c43f -> 1f397622)
- chef_fixie (04c686ac -> e445b2d7)
-
Removed Components
- rabbitmq (3.6.15)
- server-jre (8u202)
- opscode-solr4 (4.10.4)
- opscode-expander
-
Azure support for external PostgreSQL:
In the previous release we added support for ssl while connecting to PostgreSQL.
With this release we add the ability to connect to an external PostgreSQL database in Azure.
-
Update HAProxy configuration:
We have updated the configuration for HAProxy to make it more responsive. The changes include:
- Set the connect, client, server, and tunnel timeouts to reasonable defaults.
- Set client-fin and server-fin to try to mitigate connection pile-ups in the case of failing frontend services.
- Set on-marked-down shutdown-session to avoid stale sessions to previous leaders living longer than they need to.
-
Integration testing pipeline:
We have put a lot of effort into creating a test pipeline with the test infrastructure previously created. This runs multiple scenarios for Chef Infra Server with different configurations and topologies.
-
Chef Infra Server supports Elasticsearch version 6 for external Elasticsearch:
Chef Infra Server previously supported index creation for ElasticSearch versions 2 and 5. We now support index creation for ElasticSearch 6 as well.
-
Cookstyle changes applied to the cookbooks.
-
Disable actions rabbitmq queue by default.
-
Log all errors triggered due to Elasticsearch reindex.
- Fix a regression that broke FIPS 140-2 support in Chef Infra Server 13.1.13.
- Fix habitat db config for external database.
- Elasticsearch recipes should not create indexes at compile time.
- Chef Infra Client: 15.5.17 -> 15.8.23
- rack(oc-chef-pedant): 2.0.7 -> 2.0.8
- rack(oc-id): 1.6.11 -> 1.6.12
- Ruby(oc-id): 1.6.11 -> 1.6.12
- Ruby: 2.6.3 -> 2.6.5 fixes the following CVEs:
- CVE-2019-16255: A code injection vulnerability of Shell#[] and Shell#test
- CVE-2019-16254: HTTP response splitting in WEBrick (Additional fix)
- CVE-2019-15845: A NUL injection vulnerability of File.fnmatch and File.fnmatch?
- CVE-2019-16201: Regular Expression Denial of Service vulnerability of WEBrick's Digest access authentication
- CVE-2012-6708
- CVE-2015-9251
- rubyzip(oc-id): 1.2.3 -> 1.3.0 (fixes CVE-2019-16892)
- Erlang(habitat): 18 -> 20
A lot of work for this release has gone into improving our test infrastructure to test the release with various topologies and configurations. This leads to increased confidence and reduced risk of regressions with future releases of Chef Infra Server. We have also addressed some technical debt, cleaning up our codebase and enabling us to better serve our community with increased velocity.
We have been performing issue triage for Chef Infra Server for three months, and we have been hard at work cleaning up GitHub issues to highlight active issues. Recordings of Chef Infra Server triage sessions can be found here. Part of keeping our issue backlog relevant is ensuring that active issues are prominently featured over inactive issues. As a part of this effort we will be more aggressively closing issues that are inactive or do not apply to supported features. If you find that an issue or PR that you are invested in has closed, please feel free to reopen it. All feature requests can be made using the Aha! Portal.
Simplifying the management of Chef’s product portfolio is something that we are very focused on currently. As a part of that effort, we are preparing to move from Solr to Elasticsearch to align with several other projects and products that currently leverage Elasticsearch. Migration to Elasticsearch will also improve performance and provide an up-to-date dependency. Chef Infra server still continues to use Solr4 for search for the purposes of this release, but Elasticsearch packages are now also included albeit still unused.
_statusendpoint reports healthy even if data_collector is down not causing unnecessary failovers.- Data collector proxy-header X-Forwarded for is set as expected.
chef-server-ctlis no longer installed in the user path only the appbundled version is installed in the user path- Fixes issue with Chef Support Zendesk sign-ins when a first name is not set in Hosted Chef.
- Added support for running the Chef Infra Server on Red Hat Enterprise Linux 8.
- Improvements to
chef-server-ctl gather-logs- Add AWS to known platforms
- Add AWS Native Chef Server info
- Add elasticsearch info
- Switched compression from
bzip2togzip
- SLES 11 is no longer supported per our platform policy, as upstream support ended in March of this year.
- Postgres 9.6.10 -> 9.6.15
- Chef Infra Client v15.3.14 -> v15.4.45
- OpenResty 1.13.6.2 -> 1.15.8.1
- Nokogiri 1.8.5 -> 1.10.4 to resolve the following CVE's
- Rebar3 -> 3.12.0
- Updated erlang deps to be the latest
- Loofah 2.2.3 -> 2.3.1
- Erlang R18 -> 20.3.8.9
- Updated ChefInfraServer setup cookbooks for cookstyle fixes
- Ruby 2.5.5 -> 2.6.3
- Openssl 1.0.2s -> 1.0.2t to resolve the following CVE's
Chef Server has a new name, but don’t worry, it’s the same Chef Server you’ve grown used to. You’ll notice new branding throughout the application and documentation but the command chef-server-ctl remains the same.
Chef Infra Server requires an EULA to be accepted by users before it can be installed. Users can accept the EULA in a variety of ways:
chef-server-ctl reconfigure --chef-license acceptchef-server-ctl reconfigure --chef-license accept-no-persistCHEF_LICENSE="accept" chef-server-ctl reconfigureCHEF_LICENSE="accept-no-persist" chef-server-ctl reconfigure
Finally, if users run chef-server-ctl reconfigure without any of these options, they will receive an interactive prompt asking for license acceptance. If the license is accepted, a marker file will be written to the filesystem unless accept-no-persist is specified. Once this marker file is persisted, users no longer need to set any of these flags.
See our Frequently Asked Questions document for more information on the EULA and license acceptance.
- Deprecated PowerPC and s390x platforms
- Deprecated Keepalived/DRBD-based HA
- Deprecated Ubuntu 14.04 support. (Ubuntu 14 was EoL’d at the end of April 2019)
- Updated OpenResty to 1.13.6.2
- This fixes two CVEs: CVE-2018-9230 and CVE-2017-7529.
- This version cannot be built on PowerPC and s390x because those platforms are not supported in mainline luajit.
- Updated Ruby version to 2.5.5
- Updated Chef Infra Client to 14.11.21
- Updated runit cookbook to 5.1.1
- Migrated unit tests from Travis to Buildkite. Reorganized them for improved speed, stability and portability.
- Added some Habitat packaging improvements with parameterized search_server.
- Erchef request size increased from 1,000,000 to 2,000,000 bytes to better support inspec scanning via the audit cookbook.
- Nginx error logs no longer log 404s. In the Chef API, 404s are typically not errors as they are often the expected response about an object that doesn't exist. The logs will continue to show 404s in the request logs.
- Profiles and data-collector upstreams now render correctly if their root_url is configured. If the data_collector token secret is not set, a 401 response code and an error message will be seen instead of 404.
This release was triggered by the update to Habitat base plans. (https://blog.chef.io/2019/01/28/base-plans-refresh-is-coming-to-habitat-core-plans/) Omnibus release was done to keep in sync with the Habitat release.
chef-server-ctlleverages HAB_LISTEN_CTL envvar if available.
This release contains some minor improvements and updates to include software:
- Added request id to nginx log to easily track the Chef request through the logs.
- Bundler pinned to 1.17 to avoid taking the 2.0 upgrade.
- Erlang updated to 18.3.4.9
- Fixed two CVEs CVE-2017-1000385 and CVE-2016-10253. SSL headers got stricter which unfortunately broke LDAP. (Issue #1642)
- Removed
et,debugger,gs, andobserveras they depend onwx, which is not available on all platforms.
- Ruby updated to 2.5.3.
- Chef Client updated to 14.5.
- Erchef and Bookshelf can optionally use mTLS protocol for their internal communications.
- Added configuration for pedant SSL-signed requests to include mTLS support.
- Habitat package improvements:
- Increased
authn:keygen_timeoutamount foroc_erchefhab pkg. - Removed
do_endfunction fromchef-server-ctlhab plan. - Enhanced
chef-server-ctlto function in more habitat environments. chef-server-ctlcommands pass relevant TLS options during bifrost API calls.
- Increased
- Used standard ruby-cleanup definition, which shrinks install size by ~5% on disk.
- Removed unused couchdb configurables.
- Postgresql updated to 9.6.10
- In a standalone install postgresql listens on all loopbacks, not just localhost. This
- Enhance bifrost to use SSL/TLS
- Updates to ruby libraries (rubyzip)
- Updates to erlang libraries (sqerl, epgsql)
- Improvements to the habitized chef-server
- Segment free cookbooks are implemented. (https://github.com/chef/chef-rfc/blob/master/rfc067-cookbook-segment-deprecation.md) This bumps the API version
- acl for cookbook artifacts
- Security headers for HTTP
- Optional disabling of welcome page
- Ruby updated to 2.5.1
- Chef Client updated to 14.3
chef-server-ctlnow has version subcommand- Datestamps are now in UTC
- Fixie is now shipped with chef server
- Security issue with old doorkeeper fixed by upgrading. CVE-2018-1000211
This release upgrades the version of Ruby to 2.4.3.
- Add FIPS support for PPC64 (big-endian).
- Fixed invalid search query issue with elasticsearch where forward slashes not getting escaped properly..
- Fix a regression in IPv6 address handling
- Allow disabling of request logging
- opscode-erchef['enable_request_logging'] defaults to true
- oc_bifrost['enable_request_logging'] defaults to true
- bookshelf['enable_request_logging'] defaults to false
- bookshelf is a change from prior behavior as this logging is redundant with the existing nginx logs
chef-server-ctl reconfigurefixes permissions on gems with an overly restrictive umask- Make the display of the welcome page configurable
- nginx['show_welcome_page'] defaults to true
- Inferring the current database migration level and necessary upgrades for
chef-server-ctl upgrade - Catch server_name resolution errors during
chef-server-ctl reconfigureand continue - Add XSS related HTTP headers when chef-manage is not installed (chef-manage adds these itself)
- knife-opc upgraded to 12c02a to support prompting for a user password on creation
- Do not create the default rabbitmq guest useR
- Add /_acl endpoint for cookbook artifacts
This release fixes a regression.
- Set nginx['use_implicit_hosts'] = false by default. This fixes a regression for users deploying on Digital Ocean and potentially other non-AWS cloud platforms where nginx['use_implicit_hosts'] = true results in incorrect nginx configuration.
This release has security updates and enhancements.
- Update the version of java to 8u144 to address CVE-2017-3526.
- Add a
/_statsendpoint to Chef Server that conforms to Chef RFC 93 (https://github.com/chef/chef-rfc/blob/master/rfc093-server-stats-endpoint.md) Currently, it exposes statistics about connection pool usage inside Erchef, Postgresql, and the Erlang VM. Further statistics will be added as needed.
This release upgrades the version of Ruby to 2.2.8 to address multiple upstream security vulnerabilities:
https://www.ruby-lang.org/en/news/2017/09/14/ruby-2-2-8-released/
This release is a minor release addressing two problems in the PostgreSQL 9.6 upgrade process
-
Ensure that the disk has the required disk space before starting the PostgreSQL upgrade.
-
Make pg_upgrade timeout configurable for users with large databases. Also, increase the default timeout to 2 hours.
-
Upgrade to PostgreSQL 9.6, Chef Server now uses the latest stable version of the 9.6 series (9.6.3). Upgrades of existing installations are done automatically, but creating backups is advised.
The information below only applies if you have set a custom value for
checkpoint_segmentsin your/etc/opscode/chef-server.rb. If you have not set a custom value, there is nothing to change:The
checkpoint_segmentsconfiguration setting is gone, so if you before have setpostgresql['checkpoint_segments'] = 10you now have to specify (for example, please consult the documentation linked below)
postgresql['max_wal_size'] = '3G'The default setting for
max_wal_sizeis 1G. The PostgreSQL release notes mention a conversion rule:max_wal_size = (3 * checkpoint_segments) * 16MB. They also say that the default value formax_wal_size(1GB) should fit in most settings, so this conversion is not done automatically.The
shmmaxandshmallconfiguration settings are no longer used as PostgreSQL 9.6 relies on System V shared memory much less than PostgreSQL 9.2. Theshared_buffersconfiguration setting is still respected and can be used to modify the amount of shared memory used by PostgreSQL.This update also adds two further new configurables in the "Checkpoints" group,
min_wal_sizeandcheckpoint_flush_after.As part of the upgrade procdure, running
chef-server-ctl cleanupwill remove Postgres 9.2's data and logs. -
Elasticsearch 5 support: Chef Server now supports Elasticsearch 5. This allows Chef Server and Chef Automate 1.6 to use the same Elasticsearch instance.
-
EPMD patch: The Erlang Port Mapper Daemon (EPMD) included in this package is now patched to only listen on the addresses specified in
ERL_EPMD_ADDRESS. Before, it would implicitly add ::1 and 127.0.0.1 to the set of addresses to listen on, causing trouble for systems without a ::1.The preflight check that was in place to catch these situations has been removed.
-
RabbitMQ health check in status endpoint: Chef Server's
_statusendpoint now checks the health of the analytics and internal RabbitMQ vhosts. For these checks to work, the RabbitMQ management plugin must be installed. If it is not, the checks are not done. If Chef Server is configured not to use Actions, a check will not be performed against the Actions vhost. If an indexing queue is not used, thechef_indexRabbitMQ vhost will not be checked. -
Notification of affected services when updating secrets with set-secret:
chef-server-ctl set-secretwill notify the user of services that depend on the secret being changed. With the optional flag--with-restart,chef-server-ctl set-secretwill attempt to automatically restart the dependent services.
-
Stricter validation of non-functional user record fields, Chef Server now uses a regular expression to validate first, middle, and last name of a user on creation. The regex used is
[[:word:][:digit:]!'. -]*(UTF-8). This tries to accommodate a wide range of names, while also strengthening Chef Server's role in preventing XSS attacks in web-based API clients. For compatibility reasons, a user's first, middle, or last name may also be""(empty string). -
Search user by email case-insensitively: while technically only the host-part of an email address is to be treated case-insensitively, most email providers treat the entire email address as case-insensitive. Chef Server now adopts that behaviour for searching users: querying for
user@host(GET /users?email=user%40host) will now also return users with the recorded email ofUSER@HOSTetc. -
API requests including an unknown group now return 404 instead of 500 (#1286)
-
opscode-erchefnow allows for configuring an optional ulimit viaopscode_erchef['memory_maxbytes'](#1279). -
Fixed regression where credentials consumed by Analytics would be left plainly on disk after the
insecure_addon_compatoption was set tofalse. -
Fixed regression where parts of the available data (e.g. cookbook upload events) weren't sent to Chef Automate with the proper data collector token.
- Upgrade zlib to 1.2.11: this addresses CVE-2016-9841, CVE-2016-9842, and CVE-2016-9843.
- Fixed regression that prevented some Open Source Chef 11 upgrades due to too-strict validations on object names in ACLs. This issue would also prevent editing of ACLs directly on node objects if the node name contained a ".". This issue was introduced in 12.15.0
- Fixed regression that prevented the
reindexcommand from working. This issue was a side effect of consolidating the multiple Erlang runtimes that we distributed with Chef Server into one for 12.15.0.
- Fixed regression in oc-id. The identity service was using the wrong Chef Server API version level. .
- Fixed regression in the nginx proxy that prevented Automate-based Compliance profiles from being reachable
- Fixed regression in Bookshelf's preflight checks.
- Fixed regression that would cause Manage to be misconfigured to enable LDAP by default.
- PUT to
/users/USERNAME/_acl/PERMwill no longer return a 400 when the request is valid.
Note: There was no released version 12.15.1 or 12.15.2 due to issues identified internally.
See Chef RFC 89 for a fuller description
Add the ability to serve a required recipe file to chef-clients.
/organizations/<orgname>/required_recipe returns 404 for all organizations
by default.
/organizations/<orgname>/required_recipe returns 401 when the request is
not made by a client from the requested org and the feature is
enabled.
/organizations/<orgname>/required_recipe returns the required recipe and
200 when the endpoint is enabled and requested by an authorized client.
required_recipe["enable"] in chef-server.rb enables the required recipe
feature.
required_recipe["path"] in chef-server.rb specifies the recipe file to
serve.
The server-admins group is useful, but it breaks roundtripping when it appears in an organizations ACLs and groups. This was particularly painful when using the API for backups.
We add a new syntax for referring to global objects from org local context. ORGNAME::name and for global objects ::name. This can, and is omitted whereever the context is clear. So if the server-admins appears in an organizations ACL, you will see the name ::server-admins
Attributes from a user's LDAP record are used during account-linking to populate the erchef user record when it is created. Previously, the mapping between LDAP attributes and chef user attributes were fixed. Now, they are configurable.
For example, if the user's LDAP record stores their email address in a field named 'address' instead of 'mail', then you could set the following in private-chef.rb:
ldap['email_attribute'] = "address"
We've substantially reduced the number of configuration files
that contain plaintext passwords. Now, no passwords or
credentials are rendered outside of /etc/opscode/ in Chef
Server's default configuration.
To ensure backwards compatibility, Chef Server still renders
passwords and keys to multiple files in /etc/opscode. However,
if you are not using any Chef Server add-ons or if you have
updated to the latest releases of all add-ons, you can set:
insecure_addon_compat false
in chef-server.rb and remove these other occurrences of secrets as well.
If you are using LDAP integration, external postgresql, or other
Chef Server features that require providing passwords in
/etc/opscode/chef-server.rb, we've also provided commands that
allow you to set these passwords outside of the configuration
file. For information about these commands see:
https://docs.chef.io/ctl_chef_server.html#secrets-management
Note: Users of the DRBD-based HA configuration may still see passwords related to keepalived and DRBD in /var/opt/opscode.
For further information see:
See Chef Server Secrets Management for more details.
Support for a new platform was added: Red Hat Enterprise Linux 6 on s390x.
With this release, the admin UI of Solr4 has been removed. The underlying API has also been disabled. Users that depend on the admin API endpoints can enable them via adding
opscode_solr4['enable_full_admin_api'] = true
to chef-server.rb.
The Chef Server package now exposes a fips configuration flag in
chef-server.rb. Setting fips true and reconfiguring will start the
server in FIPS mode. The default value of this flag is false except
on systems where FIPS is enabled at the Kernel where it defaults to true.
The only supported systems at this time for FIPS mode are RHEL. Packages for
other systems will be missing the required OpenSSL FIPS module and will fail
to start if reconfigured with fips true.
This release addresses a number of bugs, the most notable are describe below.
Starting in version 12.10.0, a bug in the backup command produced backups that did not include the configuration data in the resulting tarball. This bug is now resolved. We recommend taking a new backup after upgrading to 12.12.0.
When configured to use ElasticSearch, the Chef Server now correctly
respects the rows parameter to search requests rather than returning
all rows.
We recommend upgrading to 12.12.0 for all users of Chef Backend to receive this search fix.
Chef Server now uses Java's native rotation for the gclog. This prevents situations where logrotate creates large sparse files on disk which may be problematic to manage with tools that can't handle sparse files.
As a consequence of this change, the Solr 4 GC log can now be found at
/var/log/opscode/opscode-solr4/gclog.log.N.current where N is an
integer. The .current extension denotes the log currently being
written to.
To remove the older GC logs, run chef-server-ctl cleanup after
upgrading.
To suppress the GC Log completely, the Chef Server now accepts the
following option in /etc/opscode/chef-server.rb:
# true (default) to enable gc logging,
# false to disable gc logging
opscode_solr4['log_gc'] = false
The oc_id service now includes configuration for outbound email to
ensure password reset emails can be sent correctly. Chef Server now
accepts the following options in /etc/opscode/chef-server.rb:
# defaults to the value of the from_email configuration option
oc_id['email_from_address'] = "[email protected]"
# defaults to the api_fqdn
oc_id['origin'] = "mail.yourco.io"
This release addresses an incompatibility with Push Jobs Server 1 by:
- Re-enabling TLS 1.0 and 1.1 in the default TLS configuration
- Re-enabling the AES cipher suite in the default TLS configuration
Further, Chef Server is now available on the s390x platform.
-
A new endpoint
/organizations/ORGNAME/validate/PATHis now available. This endpoint accepts a signed request and validates it as if it had been sent to
PATH. It returns 200 if the request is authentic and 401 if it is not. -
A new endpoint
/organizations/ORGNAME/data-collectoris now available. This endpoint forwards requests for a data-collector service after authenticating the request using Chef Server's standard authentication headers. To use this endpoint, users must set both of the following options in
/etc/opscode/chef-server.rb:data_collector['token'] data_collector['root_url'] -
A new endpoint
/organizations/ORGNAME/owners/OWNER/compliance[/PROFILE]is now available. This endpoint forwards requests for compliance profiles to a user-configurable Chef Automate server after authenticating the request using Chef Server's standard authentication headers. To use this endpoint, users must set both of the following options in
/etc/opscode/chef-server.rb:profiles['root_url'] data_collector['token']
-
The default allowed SSL ciphers now include AES256-GCM-SHA384 to ensure compatibility with AWS's Classic ELB health check tool.
-
chef-server-ctl psqlpreviously revealed the postgresql password viaps.
- Smaller download - the download size has been reduced by around 35% via removal of redundant, cached, and unused components. The installed size has been similarly reduced.
- add retry support to opscode-expander
chef-server-ctl reindexwill now continue even if some objects are not indexable, and will show which objects failed at the conclusion of the run.- Data Collector support for Policyfiles.
chef-server-ctl installadd-on installation now pulls from the correct source.- Regression fix: that caused errors on reconfigure when LDAP bind password is nil has been fixed.
- Upgrade to OpenSSL 1.0.2j. The prior release (1.0.1u) is approaching EOL.
- Updated TLS ciphers. See compatibility notes, below.
- The change of TLS ciphers can cause older tooling to fail to negotiate
SSL sessions with the Chef Server. The changes to the cipher list are
captured here.
Upgrading any custom clients of the Chef Server API to use a current SSL
release will resolve this.
- Alternatively, you can set
nginx['ssl_protocols']in/etc/opscode/chef-server.rbto a set of ciphers that are compatible with your tooling, then runningchef-server-ctl reconfigureto pick up the changes.
- Alternatively, you can set
- With this TLS cipher suite change, the Reporting add-on will report
errors when
opscode-reporting-ctl testis run. A fix for this is available in thecurrentchannel for reporting, and will be released to stable in November. This issue does not otherwise affect the Reporting add-on, but you can resolve this locally by modifying/etc/opscode-reporting/pedant_config.rband adding the following line:
ssl_version :TLSv1_2
- The update of OpenSSL 1.0.1u addresses the following:
-
This release still has a known issue in the user ACL endpoint:
ACLs: updating ACLs of a specific user (
/users/USER/_acl) will not succeed. This undocumented API is very rarely used and is not supported by tooling provided by Chef Software.If you make internal use of PUTs to this endpoint, please wait to upgrade.
- clean up legacy expander-reindexer service
- Fix logrotate configuration to make it work with SELinux enabled
- constrain ACL updates so that all users provided in an ACE must also
be in the organization. Users from outside the organization that are
already in the ACL of an object or container will not be removed.
- Note that we do not recommend adding users directly to ACLs - instead, the best approach is to use groups and control membership based on your organizational policies
- See important compatibility note below.
- ACL updates now permit adding a client to ACLs when a user of the same name exists in the system 111
- chef-server-ctl user-delete will now report in which organizations the user is an adminstrator of when that blocks deletion. It also provides a new option to attempt to auto-remove those users from the admin groups, but will prevent removal if doing so would leave the admin group(s) empty.
- The Identity Management component will now send a verification email when updating email addesses, and the update will be made only after
- Identity Management now uses secure cookies. the verification link is clicked.
- LDAP bind passwords now support special characters.
- Fix crash that can occur when logging into an ldap-enabled server when bypassing LDAP.
- multiple improvements to DVM, the development environment that resides in the Chef Server repository
- This release includes a fix for an issue where policies of the same name could be accessed across organizations 643
- Fixed logging LDAP password in event of some errors 156
- The object ACL update API (
/organizations/ORG/OBJECT_TYPE/OBJECT_NAME/_acl/PERM) now requires that any users being added to an object's ACL exist in the same organization as the object itself. Existing users that are not organization members and have already been added to an ACL will not be affected, and can still be seen in the GET response for this API. - When a client and a user of the same name exist in the organization,
the HTTP response code
422is returned and the error text will indicate which client/user was ambiguous. - The object ACL API now accepts
clientsandusersfields which will allow you to disambiguate in this situation by separating clients from users in the request. When using this option, theactorsfield must be set to[]in the request. - 400 responses in object ACL updates will now include the specific missing or incorrect entities where appropriate.
- The GET API response for object ACL has not been changed by default,
but if the query argument
?detail=granularis provided, the json body will containactorswhich will be an empty array; andclients:[...],users:[...]. This body is compatible with the PUT API changes, and can be used in that request without modification.
-
ACLs: updating ACLs of a specific user (
/users/USER/_acl) will not succeed. This undocumented API is very rarely used and is not supported by tooling provided by Chef Software.If you make internal use of PUTs to this endpoint, please wait to upgrade.
This change is being tracked as #938.
-
ACLs: users must be a member of an organization in order to be added to the ACLs of an object within an organization. If you GET an ACE that contains a user not in the org, you will not be able to re-PUT the same ACE.
-
Initial support for sending updates to a Chef RFC 077-compliant datacollection service.
-
Minor bug fixes in the postgresql preflight check and upgrade migration 29.