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.
- 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.