Chef is a powerful automation platform that transforms complex infrastructure into code, bringing your servers and services to life. Whether you’re operating in the cloud, on-premises, or a hybrid, Chef automates how applications are configured, deployed, and managed across your network, no matter its size.
Chef is built around simple concepts: achieving desired state, centralized modeling of IT infrastructure, and resource primitives that serve as building blocks. These concepts enable you to quickly manage any infrastructure with Chef. These very same concepts allow Chef to handle the most difficult infrastructure challenges on the planet. Anything that can run the chef-client can be managed by Chef.
The following items are new for chef-client 12.1 and/or are changes from previous versions. The short version:
The chef-client may be run in audit-mode. Use audit-mode to evaluate custom rules—also referred to as audits—that are defined in recipes. audit-mode may be run in the following ways:
Each audit is authored within a recipe using the control_group and control methods that are part of the Recipe DSL. Recipes that contain audits are added to the run-list, after which they can be processed by the chef-client. Output will appear in the same location as the regular chef-client run (as specified by the log_location setting in the client.rb file).
Finished audits are reported back to the Chef server. From there, audits are sent to the Chef analytics platform for further analysis, such as rules processing and visibility from the actions web user interface.
Use following option to run the chef-client in audit-mode mode:
The following diagram shows the stages of the audit-mode phase of the chef-client run, and then the list below the diagram describes in greater detail each of those stages.
When the chef-client is run in audit-mode, the following happens:
| Stages | Description |
|---|---|
| chef-client Run ID | The chef-client run identifier is associated with each audit. |
| Configure the Node | If audit-mode is run as part of the full chef-client run, audit-mode occurs after the chef-client has finished converging all resources in the resource collection. |
| Audit node based on controls in cookbooks | Each control_group and control block found in any recipe that was part of the run-list of for the node is evaluated, with each expression in each control block verified against the state of the node. |
| Upload audit data to the Chef server | When audit-mode mode is complete, the data is uploaded to the Chef server. |
| Send to Chef Analytics | Most of this data is passed to the Chef analytics platform for further analysis, such as rules processing (for notification events triggered by expected or unexpected audit outcomes) and visibility from the actions web user interface. |
A control is an automated test that is built into a cookbook, and then used to test the state of the system for compliance. Compliance can be many things. For example, ensuring that file and directory management meets specific internal IT policies—”Does the file exist?”, “Do the correct users or groups have access to this directory?”. Compliance may also be complex, such as helping to ensure goals defined by large-scale compliance frameworks such as PCI, HIPAA, and Sarbanes-Oxley can be met.
Use the control method to define a specific series of tests that comprise an individual audit. A control method MUST be contained within a control_group block. A control_group block may contain multiple control methods.
The syntax for the control method is as follows:
control_group "audit name" do
control "name" do
it "should do something" do
expect(something).to/.to_not be_something
end
end
end
where:
Matchers are available for directories. Use this matcher to define audits for directories that test if the directory exists, is mounted, and if it is linked to. This matcher uses the same matching syntax—expect(file("foo"))—as the files. The following matchers are available for directories:
| Matcher | Description, Example |
|---|---|
| be_directory | Use to test if directory exists. For example: it "should be a directory" do
expect(file("/var/directory")).to be_directory
end
|
| be_linked_to | Use to test if a subject is linked to the named directory. For example: it "should be linked to the named directory" do
expect(file("/etc/directory")).to be_linked_to("/etc/some/other/directory")
end
|
| be_mounted | Use to test if a directory is mounted. For example: it "should be mounted" do
expect(file("/")).to be_mounted
end
For directories with a single attribute that requires testing: it "should be mounted with an ext4 partition" do
expect(file("/")).to be_mounted.with( :type => 'ext4' )
end
For directories with multiple attributes that require testing: it "should be mounted only with certain attributes" do
expect(file("/")).to be_mounted.only_with(
:attribute => 'value',
:attribute => 'value',
)
end
|
Matchers are available for files and directories. Use this matcher to define audits for files that test if the file exists, its version, if it is is executable, writable, or readable, who owns it, verify checksums (both MD5 and SHA-256) and so on. The following matchers are available for files:
| Matcher | Description, Example |
|---|---|
| be_executable | Use to test if a file is executable. For example: it "should be executable" do
expect(file("/etc/file")).to be_executable
end
For a file that is executable by its owner: it "should be executable by owner" do
expect(file("/etc/file")).to be_executable.by("owner")
end
For a file that is executable by a group: it "should be executable by group members" do
expect(file("/etc/file")).to be_executable.by("group")
end
For a file that is executable by a specific user: it "should be executable by user foo" do
expect(file("/etc/file")).to be_executable.by_user("foo")
end
|
| be_file | Use to test if a file exists. For example: it "should be a file" do
expect(file("/etc/file")).to be_file
end
|
| be_grouped_into | Use to test if a file is grouped into the named group. For example: it "should be grouped into foo" do
expect(file("/etc/file")).to be_grouped_into("foo")
end
|
| be_linked_to | Use to test if a subject is linked to the named file. For example: it "should be linked to the named file" do
expect(file("/etc/file")).to be_linked_to("/etc/some/other/file")
end
|
| be_mode | Use to test if a file is set to the specified mode. For example: it "should be mode 440" do
expect(file("/etc/file")).to be_mode(440)
end
|
| be_owned_by | Use to test if a file is owned by the named owner. For example: it "should be owned by the root user" do
expect(file("/etc/sudoers")).to be_owned_by("root")
end
|
| be_readable | Use to test if a file is readable. For example: it "should be readable" do
expect(file("/etc/file")).to be_readable
end
For a file that is readable by its owner: it "should be readable by owner" do
expect(file("/etc/file")).to be_readable.by("owner")
end
For a file that is readable by a group: it "should be readable by group members" do
expect(file("/etc/file")).to be_readable.by("group")
end
For a file that is readable by a specific user: it "should be readable by user foo" do
expect(file("/etc/file")).to be_readable.by_user("foo")
end
|
| be_socket | Use to test if a file exists as a socket. For example: it "should be a socket" do
expect(file("/var/file.sock")).to be_socket
end
|
| be_symlink | Use to test if a file exists as a symbolic link. For example: it "should be a symlink" do
expect(file("/etc/file")).to be_symlink
end
|
| be_version | Microsoft Windows only. Use to test if a file is the specified version. For example: it "should be version 1.2" do
expect(file('C:\\Windows\\path\\to\\file')).to be_version(‘1.2’)
end
|
| be_writable | Use to test if a file is writable. For example: it "should be writable" do
expect(file("/etc/file")).to be_writable
end
For a file that is writable by its owner: it "should be writable by owner" do
expect(file("/etc/file")).to be_writable.by("owner")
end
For a file that is writable by a group: it "should be writable by group members" do
expect(file("/etc/file")).to be_writable.by("group")
end
For a file that is writable by a specific user: it "should be writable by user foo" do
expect(file("/etc/file")).to be_writable.by_user("foo")
end
|
| contain | Use to test if a file contains specific contents. For example: it "should contain docs.chef.io" do
expect(file("/etc/file")).to contain("docs.chef.io")
end
|
Matchers are available for packages and may be used to define audits that test if a package or a package version is installed. The following matchers are available:
| Matcher | Description, Example |
|---|---|
| be_installed | Use to test if the named package is installed. For example: it "should be installed" do
expect(package("httpd")).to be_installed
end
For a specific package version: it "should be installed" do
expect(package("httpd")).to be_installed.with_version("0.1.2")
end
|
Matchers are available for ports and may be used to define audits that test if a port is listening. The following matchers are available:
| Matcher | Description, Example |
|---|---|
| be_listening | Use to test if the named port is listening. For example: it "should be listening" do
expect(port(23)).to be_listening
end
For a named port that is not listening: it "should not be listening" do
expect(port(23)).to_not be_listening
end
For a specific port type use .with("port_type"). For example, UDP: it "should be listening with UDP" do
expect(port(23)).to_not be_listening.with("udp")
end
For UDP, version 6: it "should be listening with UDP6" do
expect(port(23)).to_not be_listening.with("udp6")
end
For TCP/IP: it "should be listening with TCP" do
expect(port(23)).to_not be_listening.with("tcp")
end
For TCP/IP, version 6: it "should be listening with TCP6" do
expect(port(23)).to_not be_listening.with("tcp6")
end
|
Matchers are available for services and may be used to define audits that test for conditions related to services, such as if they are enabled, running, have the correct startup mode, and so on. The following matchers are available:
| Matcher | Description, Example |
|---|---|
| be_enabled | Use to test if the named service is enabled (i.e. will start up automatically). For example: it "should be enabled" do
expect(service("ntpd")).to be_enabled
end
For a service that is enabled at a given run level: it "should be enabled at the specified run level" do
expect(service("ntpd")).to be_enabled.with_level(3)
end
|
| be_installed | Microsoft Windows only. Use to test if the named service is installed on the Microsoft Windows platform. For example: it "should be installed" do
expect(service("DNS Client")).to be_installed
end
|
| be_running | Use to test if the named service is running. For example: it "should be running" do
expect(service("ntpd")).to be_running
end
For a service that is running under supervisor: it "should be running under supervisor" do
expect(service("ntpd")).to be_running.under("supervisor")
end
or daemontools: it "should be running under daemontools" do
expect(service("ntpd")).to be_running.under("daemontools")
end
or Upstart: it "should be running under upstart" do
expect(service("ntpd")).to be_running.under("upstart")
end
|
| be_monitored_by | Use to test if the named service is being monitored by the named monitoring application. For example: it "should be monitored by" do
expect(service("ntpd")).to be_monitored_by('monit')
end
|
| have_start_mode | Microsoft Windows only. Use to test if the named service’s startup mode is correct on the Microsoft Windows platform. For example: it "should start manually" do
expect(service("DNS Client")).to have_start_mode.Manual
end
|
A package is installed
For example, a package is installed:
control_group "audit name" do
control "mysql package" do
it "should be installed" do
expect(package("mysql")).to be_installed
end
end
end
The control_group block is processed when the chef-client run is run in audit-mode. If the audit was successful, the chef-client will return output similar to:
Audit Mode
mysql package
should be installed
If an audit was unsuccessful, the chef-client will return output similar to:
Starting audit phase
Audit Mode
mysql package
should be installed (FAILED - 1)
Failures:
1) Audit Mode mysql package should be installed
Failure/Error: expect(package("mysql")).to be_installed.with_version("5.6")
expected Package "mysql" to be installed
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:22:in 'block (3 levels) in from_file'
Finished in 0.5745 seconds (files took 0.46481 seconds to load)
1 examples, 1 failures
Failed examples:
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:21 # Audit Mode mysql package should be installed
A package version is installed
A package that is installed with a specific version:
control_group "audit name" do
control "mysql package" do
it "should be installed" do
expect(package("mysql")).to be_installed.with_version("5.6")
end
end
end
A package is not installed
A package that is not installed:
control_group "audit name" do
control "postgres package" do
it "should not be installed" do
expect(package("postgresql")).to_not be_installed
end
end
end
If the audit was successful, the chef-client will return output similar to:
Audit Mode
postgres audit
postgres package
is not installed
A service is enabled
A service that is enabled and running:
control_group "audit name" do
control "mysql service" do
let(:mysql_service) { service("mysql") }
it "should be enabled" do
expect(mysql_service).to be_enabled
end
it "should be running" do
expect(mysql_service).to be_running
end
end
end
If the audit was successful, the chef-client will return output similar to:
Audit Mode
mysql service audit
mysql service
is enabled
is running
A configuration file contains specific settings
The following example shows how to verify sshd configration, including whether it’s installed, what the permissions are, and how it can be accessed:
control_group 'check sshd configuration' do
control 'sshd package' do
it 'should be installed' do
expect(package('openssh-server')).to be_installed
end
end
control 'sshd configuration' do
let(:config_file) { file('/etc/ssh/sshd_config') }
it 'should exist with the right permissions' do
expect(config_file).to be_file
expect(config_file).to be_mode(644)
expect(config_file).to be_owned_by('root')
expect(config_file).to be_grouped_into('root')
end
it 'should not permit RootLogin' do
expect(config_file.content).to_not match(/^PermitRootLogin yes/)
end
it 'should explicitly not permit PasswordAuthentication' do
expect(config_file.content).to match(/^PasswordAuthentication no/)
end
it 'should force privilege separation' do
expect(config_file.content).to match(/^UsePrivilegeSeparation sandbox/)
end
end
end
where
A file contains desired permissions and contents
The following example shows how to verify that a file has the desired permissions and contents:
controls "mysql config" do
control "mysql config file" do
let(:config_file) { file("/etc/mysql/my.cnf") }
it "exists with correct permissions" do
expect(config_file).to be_file
expect(config_file).to be_mode(0400)
end
it "contains required configuration" do
expect(its(:contents)).to match(/default-time-zone='UTC'/)
end
end
end
If the audit was successful, the chef-client will return output similar to:
Audit Mode
mysql config
mysql config file
exists with correct permissions
contains required configuration
Use the control_group method to define a group of control methods that comprise a single audit. The name of each control_group must be unique within the organization.
The syntax for the control_group method is as follows:
control_group "name" do
control "name" do
it "should do something" do
expect(something).to/.to_not be_something
end
end
control "name" do
...
end
...
end
where:
control_group block with multiple control blocks
The following control_group ensures that MySQL is installed, that PostgreSQL is not installed, and that the services and configuration files associated with MySQL are configured correctly:
control_group "Audit Mode" do
control "mysql package" do
it "should be installed" do
expect(package("mysql")).to be_installed.with_version("5.6")
end
end
control "postgres package" do
it "should not be installed" do
expect(package("postgresql")).to_not be_installed
end
end
control "mysql service" do
let(:mysql_service) { service("mysql") }
it "should be enabled" do
expect(mysql_service).to be_enabled
end
it "should be running" do
expect(mysql_service).to be_running
end
end
control "mysql config directory" do
let(:config_dir) { file("/etc/mysql") }
it "should exist with correct permissions" do
expect(config_dir).to be_directory
expect(config_dir).to be_mode(0700)
end
it "should be owned by the db user" do
expect(config_dir).to be_owned_by('db_service_user')
end
end
control "mysql config file" do
let(:config_file) { file("/etc/mysql/my.cnf") }
it "should exist with correct permissions" do
expect(config_file).to be_file
expect(config_file).to be_mode(0400)
end
it "should contain required configuration" do
expect(config_file.content).to match(/default-time-zone='UTC'/)
end
end
end
The control_group block is processed when the chef-client is run in audit-mode. If the chef-client run was successful, the chef-client will return output similar to:
Audit Mode
mysql package
should be installed
postgres package
should not be installed
mysql service
should be enabled
should be running
mysql config directory
should exist with correct permissions
should be owned by the db user
mysql config file
should exist with correct permissions
should contain required configuration
If an audit was unsuccessful, the chef-client will return output similar to:
Starting audit phase
Audit Mode
mysql package
should be installed (FAILED - 1)
postgres package
should not be installed
mysql service
should be enabled (FAILED - 2)
should be running (FAILED - 3)
mysql config directory
should exist with correct permissions (FAILED - 4)
should be owned by the db user (FAILED - 5)
mysql config file
should exist with correct permissions (FAILED - 6)
should contain required configuration (FAILED - 7)
Failures:
1) Audit Mode mysql package should be installed
Failure/Error: expect(package("mysql")).to be_installed.with_version("5.6")
expected Package "mysql" to be installed
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:22:in 'block (3 levels) in from_file'
2) Audit Mode mysql service should be enabled
Failure/Error: expect(mysql_service).to be_enabled
expected Service "mysql" to be enabled
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:35:in 'block (3 levels) in from_file'
3) Audit Mode mysql service should be running
Failure/Error: expect(mysql_service).to be_running
expected Service "mysql" to be running
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:38:in 'block (3 levels) in from_file'
4) Audit Mode mysql config directory should exist with correct permissions
Failure/Error: expect(config_dir).to be_directory
expected `File "/etc/mysql".directory?` to return true, got false
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:45:in 'block (3 levels) in from_file'
5) Audit Mode mysql config directory should be owned by the db user
Failure/Error: expect(config_dir).to be_owned_by('db_service_user')
expected `File "/etc/mysql".owned_by?("db_service_user")` to return true, got false
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:49:in 'block (3 levels) in from_file'
6) Audit Mode mysql config file should exist with correct permissions
Failure/Error: expect(config_file).to be_file
expected `File "/etc/mysql/my.cnf".file?` to return true, got false
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:56:in 'block (3 levels) in from_file'
7) Audit Mode mysql config file should contain required configuration
Failure/Error: expect(config_file.content).to match(/default-time-zone='UTC'/)
expected "-n\n" to match /default-time-zone='UTC'/
Diff:
@@ -1,2 +1,2 @@
-/default-time-zone='UTC'/
+-n
# /var/chef/cache/cookbooks/grantmc/recipes/default.rb:60:in 'block (3 levels) in from_file'
Finished in 0.5745 seconds (files took 0.46481 seconds to load)
8 examples, 7 failures
Failed examples:
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:21 # Audit Mode mysql package should be installed
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:34 # Audit Mode mysql service should be enabled
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:37 # Audit Mode mysql service should be running
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:44 # Audit Mode mysql config directory should exist with correct permissions
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:48 # Audit Mode mysql config directory should be owned by the db user
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:55 # Audit Mode mysql config file should exist with correct permissions
rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:59 # Audit Mode mysql config file should contain required configuration
Auditing complete
Duplicate control_group names
If two control_group blocks have the same name, the chef-client will raise an exception. For example, the following control_group blocks exist in different cookbooks:
control_group "basic control group" do
it "should pass" do
expect(2 - 2).to eq(0)
end
end
control_group "basic control group" do
it "should pass" do
expect(3 - 2).to eq(1)
end
end
Because the two control_group block names are identical, the chef-client will return an exception similar to:
Synchronizing Cookbooks:
- audit_test
Compiling Cookbooks...
================================================================================
Recipe Compile Error in /Users/grantmc/.cache/chef/cache/cookbooks
/audit_test/recipes/error_duplicate_control_groups.rb
================================================================================
Chef::Exceptions::AuditControlGroupDuplicate
--------------------------------------------
Audit control group with name 'basic control group' has already been defined
Cookbook Trace:
---------------
/Users/grantmc/.cache/chef/cache/cookbooks
/audit_test/recipes/error_duplicate_control_groups.rb:13:in 'from_file'
Relevant File Content:
----------------------
/Users/grantmc/.cache/chef/cache/cookbooks/audit_test/recipes/error_duplicate_control_groups.rb:
control_group "basic control group" do
it "should pass" do
expect(2 - 2).to eq(0)
end
end
control_group "basic control group" do
it "should pass" do
expect(3 - 2).to eq(1)
end
end
Running handlers:
[2015-01-15T09:36:14-08:00] ERROR: Running exception handlers
Running handlers complete
The ORGANIZATION-validator.pem is typically added to the .chef directory on the workstation. When a node is bootstrapped from that workstation, the ORGANIZATION-validator.pem is used to authenticate the newly-created node to the Chef server during the initial chef-client run. Starting with chef-client version 12.1, it is possible to bootstrap a node using the USER.pem file instead of the ORGANIZATION-validator.pem file. This is known as a “validatorless bootstrap”.
To create a node via the USER.pem file, simply delete the ORGANIZATION-validator.pem file on the workstation. As long as a USER.pem is also present on the workstation from which the validatorless bootstrap operation will be initiated, the bootstrap operation will run and will use the USER.pem file instead of the ORGANIZATION-validator.pem file.
Use the following options to specify items that are stored in chef-vault:
The following attributes are new for chef-client 12.1.
The verify attribute may be used with the cookbook_file, file, remote_file, and template resources.
| Attribute | Description |
|---|---|
| verify | Use to specify a block or a string that returns true or false. A string, when true is executed as a system command. For example: template "/etc/nginx.conf" do
verify "nginx -t -c %{path}"
end
A block is arbitrary Ruby defined within the resource block by using the keyword verify. When a block is true, the chef-client will continue to update the file as appropriate. For example: template "/tmp/baz" do
verify { 1 == 1 }
end
or: template "/tmp/bar" do
verify { 1 == 1}
end
or: template "/tmp/foo" do
verify do |path|
true
end
end
should all return true. Whereas, the following should return false: template "/tmp/turtle" do
verify "/usr/bin/false"
end
If a string or a block return false, the chef-client run will stop and an error will be returned. |
The following attribute is new for the dsc_script resource:
| Attribute | Description |
|---|---|
| imports | Use to import DSC resources from a module. To import all resources from a module, specify only the module name: imports "module_name"
To import specific resources, specify the module name and then the name for each resource in that module to import: imports "module_name", "resource_name_a", "resource_name_b", ...
For example, to import all resources from a module named cRDPEnabled: imports "cRDPEnabled"
And to import only the PSHOrg_cRDPEnabled resource: imports "cRDPEnabled", "PSHOrg_cRDPEnabled"
|
The following attribute is new for the chef_gem resource:
| Attribute | Description |
|---|---|
| compile_time | Use to disable compile-time installation of gems. Recommended value: false. The chef-client will emit a warning when this setting is true. Use a respond_to? check to ensure backward compatibility. For example: chef_gem 'aws-sdk' do
compile_time false if respond_to?(:compile_time)
end
|
The following attributes are new for the windows_service resource:
| Attribute | Description |
|---|---|
| run_as_password | The password for the user specified by run_as_user. |
| run_as_user | The user under which a Microsoft Windows service will run. |
A resource defines the desired state for a single configuration item present on a node that is under management by Chef. A resource collection—one (or more) individual resources—defines the desired state for the entire node. During every chef-client run, the current state of each resource is tested, after which the chef-client will take any steps that are necessary to repair the node and bring it back into the desired state.
Use the openbsd_package resource to manage packages for the OpenBSD platform.
Note
In many cases, it is better to use the package resource instead of this one. This is because when the package resource is used in a recipe, the chef-client will use details that are collected by Ohai at the start of the chef-client run to determine the correct package application. Using the package resource allows a recipe to be authored in a way that allows it to be used across many platforms. That said, there are scenarios where using an application-specific package is preferred.
The syntax for using the openbsd_package resource in a recipe is as follows:
openbsd_package "name" do
attribute "value" # see attributes section below
...
action :action # see actions section below
end
where
This resource has the following actions:
| Action | Description |
|---|---|
| :install | Default. Use to install a package. If a version is specified, use to install the specified version of a package. |
| :remove | Use to remove a package. |
This resource has the following attributes:
| Attribute | Description |
|---|---|
| options | One (or more) additional options that are passed to the command. |
| package_name | The name of the package. Default value: the name of the resource block. (See “Syntax” section above for more information.) |
| provider | Optional. Use to explicitly specify a provider. (See “Providers” section below for more information.) |
| response_file | Optional. The direct path to the file used to pre-seed a package. |
| source | Optional. Use to specify the path to a package in the local file system. |
| version | The version of a package to be installed or upgraded. |
The following client.rb settings are new:
| Attribute | Description |
|---|---|
| windows_service.watchdog_timeout | Use to specify the maximum amount of time (in seconds) available to the chef-client run when the chef-client is run as a service on the Microsoft Windows platform. If the chef-client run does not complete within the specified timeframe, the chef-client run is terminated. Default value: 2 * (60 * 60). |
A resource may specify multiple packages and/or versions for platforms that use Yum or Apt. Specifing multiple packages and/or versions allows a single transaction to
For example, installing multiple packages:
package ['package1', 'package2']
Upgrading multiple packages:
package ['package1', 'package2'] do
action :upgrade
do
Removing multiple packages:
package ['package1', 'package2'] do
action :remove
do
Purging multiple packages:
package ['package1', 'package2'] do
action :purge
do
Notifications, via an implicit name:
package ['package1', 'package2'] do
action :nothing
do
log "call a notification" do
notifies :install, "package[package1, package2]", :immediately
end
Note
Notifications and subscriptions do not need to be updated when packages and versions are added or removed from the package_name or version attributes.