Chef Server 11.0.8 Released

We are happy to announce the release of Chef Server 11.0.8 containing a number of security and bug fixes as detailed below. The MVP for this release is Joe Breu (@rackerjoe) who contributed a fix for CHEF-3889 to correct PostgreSQL tuning to allow Chef Server to be installed on systems with more than 64GB of RAM.

Updated Components:

chef-server-webui 11.0.4

This release contains an updated Rails version of 3.2.13 which contains security fixes for the following vulnerabilities:

  • [CVE-2013-1854] Symbol DoS vulnerability in Active Record
  • [CVE-2013-1855] XSS vulnerability in sanitize_css in Action Pack
  • [CVE-2013-1856] XML Parsing Vulnerability affecting JRuby users
  • [CVE-2013-1857] XSS Vulnerability in the sanitize helper of Rails

This fixes the following issues:

  • CHEF-4059 update Rails version to 3.2.13 for security issues

PostgreSQL 9.2.4

This version fixes the following vulnerabilities:

  • [CVE-2013-1899] – makes it possible for a connection request containing a database name that begins with “-” to be crafted that can damage or destroy files within a server’s data directory. Anyone with access to the port the PostgreSQL server listens on can initiate this request.
  • [CVE-2013-1900] – wherein random numbers generated by contrib/pgcrypto
    functions may be easy for another database user to guess
  • [CVE-2013-1901] – which mistakenly allows an unprivileged user to run commands that could interfere with in-progress backups. These issues are also addressed but only affect the graphical installers for Linux and Mac OS X (note used by chef-server).
  • [CVE-2013-1902] – the use of predictable filenames in /tmp
  • [CVE-2013-1903] – insecure passing of superuser passwords to a script

More details in the PostgreSQL release announcement: http://www.postgresql.org/about/news/1456/
This fixes the following issues:

Bug Fixes:

don’t override user provided nginx url

If the user did not provide a value for the nginx url we will construct one, taking the value passed into ssl_port into account. This fixes the following issues:

  • CHEF-4029 configurable bookshelf url & nginx ssl port issue

ensure the enable_non_ssl nginx attribute works

Currently trying to enable non-ssl mode has no effect. This commit ensures we render a both an HTTP and HTTPS version of the Chef API lb config. This behavior now also matches Private Chef. This fixes the following issues:

  • CHEF-4029 configurable bookshelf url & nginx ssl port issue

Ensure Nginx config respects configured ports.

This patch makes Nginx’s rewrite and proxysetheader directives respect the configured SSL port (node['chef_server']['nginx']['ssl_port']). This fixes the following issues:

  • CHEF-3849 redirect for login for webui ignores ssl_port

Add configurable bookshelf url attribute.

This new attribute will default to the value of the Nginx url which is built from the configured api_fqdn and Nginx ssl port. Values set in the /etc/chef-server/chef-server.rb file always take precedence so it is still possible to change the bookshelf vip to something like “https://s3.amazonaws.com” if S3 is being used as the backend cookbook store. This fixes the following issues:

  • CHEF-3853 checksum URLs generated by POST /sandboxes do not respect configured load balancer port

Build Erchef url off configured values for listen + port.

The default attribute value for node['chef_server']['erchef']['url'] is out of date the instant a user configures alternate values for listen or port. We’ll remove this misleading attribute and just compute a url when we need it using the following format:

http://ERCHEFLISTEN:ERCHEFPORT This fixes the following issue:

Build webui url off configured values for listen + port

The default attribute value for node['chef_server']['chef-server-webui']['url'] is out of date the instant a user configures alternate values for listen or port. We’ll remove this misleading attribute and just compute a url when we need it using the following format: http://WEBUILISTEN:WEBUIPORT node['chef_server']['chef-server-webui']['listen'] has also been updated to match the idioms of other components listen attribute.

Build solr url off configured values for ip_address + port.

The default attribute value for node['chef_server']['chef-solr']['url'] is out of date the instant a user configures alternate values for ip_address or port. We’ll remove this misleading attribute and just compute a url when we need it using the following format: http://SOLRIP:SOLRPORT

stop runit_service supervise/ok race condition

Currently we wait 10 seconds for a runit service’s supervise/ok named pipe. On slower systems (cough CentOS 5.x) this 10 second wait is not long enough. This commit updates the embedded runit cookbook that ships in omnibus-chef to match the indefinite block used in the current version of community cookbook: https://github.com/opscode-cookbooks/runit/blob/1.1.0/libraries/providerrunitservice.rb#L151-L153

Improvements:

Maximum on PostgreSQL shared_pages on machines where installed RAM/4 exceeds the size of shmmax of 14GB

On machines with installed RAM > 64GB the postgresql shared_buffers configuration would exceed shmmax. This change places a maximum on shared_pages on machines where Installed RAM / 4 exceeds the size of shmmax of 14GB
This does not solve the case where you have a 32bit installation and more than 16GB of RAM. This resolves the following issue:

  • CHEF-3889 tunables for postgresql in chef server 11 do not work when system has more than 64GB of RAM

Thanks for the contribution Joe Breu (@rackerjoe)!

Packaging code (Omnibus) improvements

  • The Omnibus-related packaging code has been moved to it’s own repository at: https://github.com/opscode/omnibus-chef-server
  • Chef Server Omnibus project has been updated to support the newly released Omnibus 1.0.
  • opscode-runsvdir -> chef-server-runsvdir – For consistency (and sanity), the upstart system job configuration should match the Omnibus project name.
  • Yiannis

    Hi there,

    I am getting this error when I run chef-server-ctl reconfigure :

    STDERR: createdb: could not connect to database template1: could not connect to server: No such file or directory

    Is the server running locally and accepting
    
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
    

    Does anybody else get that?

    Thanks a lot

Archives