If you're not a cooking aficionado or a professional chef, the preparation of a meal could prove to be a challenging task. Mosc nat de vota (prototype) mac os. Is a simple Mac OS X application that is easy to install and use. Thanks for contributing an answer to Stack Overflow! Please be sure to answer the question.Provide details and share your research! Asking for help, clarification,.
With Domotz network monitoring software you can monitor Linux machines and MAC OS via SNMP.
It is sufficient to install an SNMP deamon on the Linux machine and make sure that the Domotz agent is using the same read-only community for that device.
In this articles you can find a list of instructions to learn how to enable SNMP for Linux and Mac OS.
Here is a list of instructions for installing SNMP deamons on most popular Linux distributions and on Mac OS:
For more information about configuring SNMP in Domotz see here.
At the end of this article, you will also find a practical use case for monitoring through Domotz the HW resources of your Linux machine, and a template to achieve that.
How to enable SNMP on Linux
Debian
1. Installation
2. Configuration
Edit the file: /etc/snmp/snmpd.conf with a text editor of your choice.
Add the following line:
rocommunity public
Note: The default Ubuntu 'snmpd' configuration specifically denies almost everything useful with this configuration (limiting access to just enough information to tell that the machine is a Linux one):view systemonly included .1.3.6.1.2.1.1 view systemonly included .1.3.6.1.2.1.25.1 rocommunity public default -V systemonly
This configuration locks the machine down, which may be 'safe' if it will be on an insecure network with little SNMP administration knowledge available. However, if you are willing to monitor the performance of your machine with an external systems, comment them and replace the access with a secure mechanism (either with SNMP v3 or different community string).
Comment the line:
#agentAddress udp:127.0.0.1:161
Uncomment the line:
agentAddress udp:161,udp6:[::1]:161
Restart the snmpd service:
Ubuntu
Mac Os Download
1. Installation
2. Configuration
Edit the file: /etc/snmp/snmpd.conf with a text editor of your choice.
Add the following line:
rocommunity public
Note: The default Ubuntu 'snmpd' configuration specifically denies almost everything useful with this configuration (limiting access to just enough information to tell that the machine is a Linux one):view systemonly included .1.3.6.1.2.1.1view systemonly included .1.3.6.1.2.1.25.1rocommunity public default -V systemonly
This configuration locks the machine down, which may be 'safe' if it will be on an insecure network with little SNMP administration knowledge available. However, if you are willing to monitor the performance of your machine with an external systems, comment them and replace the access with a secure mechanism (either with SNMP v3 or different community string).
Comment the line:
#agentAddress udp:127.0.0.1:161
Uncomment the line:
agentAddress udp:161,udp6:[::1]:161
Restart the snmpd service:
3. Allow SNMP ports in Firewall
Execute the following commands to allow necessary ports:
CentOS
1. Installation
2. Configuration
Edit the file: /etc/snmp/snmpd.conf
Chef Yum Mac Os 11
Add the following line:
rocommunity public
Replace the line below:
view systemview included .1.3.6.1.2.1.25.1.1
with the following line:
view systemview included .1.3.
Restart the snmpd service:
3. Allow SNMP ports in Firewall
Execute the following commands to allow necessary ports:
FreeBSD
1. Fetch Ports collection and install Installation
2. Configuration
Copy the following configuration file:
cp /usr/local/share/snmp/snmpd.conf.example /usr/local/etc/snmpd.conf
Add the following line:
rocommunity public
Comment the line:
#agentAddress udp:127.0.0.1:161
Uncomment the line:
agentAddress udp:161,udp6:[::1]:161
3. Allow SNMP ports in Firewall
Edit the /etc/rc.conf file and add the following lines:
snmpd_enable='YES'
snmpd_conffile='/usr/local/etc/snmpd.conf'
Uncomment the line:
agentAddress udp:161,udp6:[::1]:161
4. Start the Service
Edit the /etc/rc.conf file and add the following lines:
Red Hat Enterprise Linux (RHEL)
1. Installation
2. Configuration
Edit the file: /etc/snmp/snmpd.conf
Add the following lines:
rocommunity public
agentAddress udp:161,udp6:[::1]:161
Start the snmpd service:
systemctl enable snmpd && systemctl start snmpd
3. Allow SNMP ports in Firewall
Execute the following commands to allow necessary ports:
Edit the /etc/rc.conf file and add the following lines:
How to enable SNMP on Mac OS
1. Configuration
Edit the file: /etc/snmp/snmpd.conf
Add the following line:
rocommunity public
2. Start the SNMP service
Execute the following commands to allow necessary ports:
Monitoring SNMP OiD through Domotz
Once the SNMP daemon has been configured on the Linux machine, and the Community Strings (for V1 and V2 – or Credentials for V3) are matching between the Linux machine and the Domotz Agent, Domotz will automatically browse and report all the possible MIBs available for that specific Linux machine.
In particular, you can search with Domotz for any possible specific OiD available on that specific Linux Machine.
Open the Domotz App or the WebApp. Identify your Linux Machine. Under the tab SNMP/TCP click on Add an SNMP Sensor. You will be proposed with the entire list of SNMP OiD available for that specific device, and the possibility to search among the descriptions (available in the MIB available for that device):
You can for instance search for all the possible OiD which contains the word 'CPU' in their description, and then add the relevant ones.
A date in time mac os. By doing this, you can start monitoring the resource consumptions of your Linux machine.
Below in this article a few example of resource usage statistics extracted by Domotz out of a Linux machine using this mechanism.
CPU Usage
Through Domotz you can monitor either the spikes in the CPU usage as recorded by the CPU Load on 1 Min average:
Or the sustained CPU usage as recorded by the CPU Load on 15 Min average:
It is also possible to monitor the residual (idle) CPU available in the server:
Memory Usage
Through Domotz you can monitor the total available Memory on the Linux machine, or even more importantly the residual memory still free and available on the same:
Volume or Storage occupancy
It is also possible to add the monitoring of any volume or storage and their occupancy via the default hrStorageTable:
For more information about configuring SNMP in Domotz see here.
Alerts on resource usage
Both in the case of the above examples, you can configure alerts so that you are notified if any unexpected load is affecting your server or Linux machine.
For example you can monitor if the CPU Idle at a certain point goes below a certain threshold, or if the residual memory is too low to have a safe environment.
In order to configure alerts, visit the Alert tab, then select the Custom type under the Personal Alerts, and Configure an SNMP Alert.
You will be be provided with the option to select the previously added SNMP OiD as input for the alert.
You can then either decide to receive the notification via Email or Push Notification, as Personal Alerts, or receive the notifications on your preferred channel, via the Shared Alert configuration:
- through shared email addresses
- Your ticketing system or PSA tool integrated with Domotz (e.g. Datto Autotask, ConnectWise Manage, Syncro MSP, Zendesk, Freshservice, etc)
- Your company chat system (e.g. Microsoft Teams or Slack)
- Any Web Server through Web Hooks (or possible third party integrations via Zapier or Node-Red)
Add Resource Usage monitoring via templateing
With Domotz it is possible to configure the monitoring and alerting via SNMP for a specific Linux machine (or generically for any server) and then use that configuration as a template for all the other servers that need to be monitored.
This can be achieved by the Export/Import Device Settings and Properties capability. Boris the mutant bear with a gun mac os.
Once you have completed the configuration of the SNMP parameters you are willing to monitor for a Linux machine, and the alerts' thresholds to get notified, click on the Export Device Settings and Properties.
A json file (like a template file) is generated and saved on your client with all the Domotz settings and properties for that specific device.
This same template json file can then be edited (e.g. to replace or remove some areas) and then used to apply the same SNMP settings (e.g. OiD to be monitored and their threshold) to all the other Linux machines that you are monitoring through Domotz.
This can be achieved from the Global Search and Manage functionality. Search for all the Linux machines you want to apply the template, select them with the multi-select check box, and then click on Import Device Settings and Properties:
Chef Yum Mac Os Download
Preconfigured Template for Linux Machine Resource usage Monitoring
The following file can be used as a baseline to build a template for monitoring resource usage of your Linux Machine:
In particular, once used for the Import Device Settings and Properties functionality, it will create 6 SNMP sensors (on CPU and Memory usage) and two triggers (alerts) on the usage of those resources:
Each device will then have the SNMP and TCP configured with the OiDs for monitoring CPU and Memory usage via SNMP:
Was this article helpful?
Background
In Chef 12 the old Chef::Platform hashmap located in `lib/chef/platform/provider_mapping.rb` has been deprecated. In its place is a dynamic provider and resolver resolution mechanism which is preferred and which can be manipulated via DSL methods on the resource and provider. In Chef 11 it was common to add functionality for platforms in the Chef::Platform hashmap which looks like this:
[ruby]
class Chef
class Platform
class << self
attr_writer :platforms
def platforms
@platforms ||= begin
require ‘chef/providers'
{
:mac_os_x => {
:default => {
:package => Chef::Provider::Package::Macports,
:service => Chef::Provider::Service::Macosx,
:user => Chef::Provider::User::Dscl,
:group => Chef::Provider::Group::Dscl
}
},
:mac_os_x_server => {
:default => {
:package => Chef::Provider::Package::Macports,
:service => Chef::Provider::Service::Macosx,
:user => Chef::Provider::User::Dscl,
:group => Chef::Provider::Group::Dscl
}
},
:freebsd => {
:default => {
:group => Chef::Provider::Group::Pw,
:service => Chef::Provider::Service::Freebsd,
:user => Chef::Provider::User::Pw,
:cron => Chef::Provider::Cron
}
},
[…etc for 400 lines…]
}
end
end
[…etc…]
[/ruby]
Examples of New Syntax
With chef-12 we are starting to wire up providers and resolvers via the `provides` method on the provider and resource classes. Some examples of this include:
Wiring up a resource on all platforms
This is the most trivial example where all platforms get the same cookbook_file resource when the user types ‘cookbook_file' in a recipe:
[ruby]
class Chef
class Resource
class CookbookFile < Chef::Resource::File
provides :cookbook_file
[…etc…]
end
end
end
[/ruby]
Wiring up a resource on an os
This only wires up the ips_package resource when the node[‘os'] attribute is ‘solaris2'
Deck the balls mac os. [ruby]
class Chef
class Resource
class IpsPackage < ::Chef::Resource::Package
provides :ips_package, os: 'solaris2'
end
end
end
[/ruby]
Wiring up a resource on multiple platform_families
This is a more complicated example, showing that the provides line supports node[‘platform_family'] and that arrays of values can be used. This also wires up the the yum_package resource to whenever the user types ‘yum_package' in a recipe no matter which platform (so even on Solaris if you type ‘yum_package' in a recipe you'll get this kind of resource), but also on the redhat-like platform_families if the user types ‘package' we wire that up to resolve to the ‘yum_package' resource. This is a slight change from Chef 11 where if you typed ‘package 'foo'‘ on redhat you would get a vanilla Chef::Resource::Package object which would do vanilla package validation checking and any yum-specific options would be rejected. In Chef 12 on redhat you will get a Chef::Resource::YumPackage object which will do the correct validation for the YumPackage provider.
[ruby]
class Chef
class Resource
class YumPackage < Chef::Resource::Package
provides :yum_package
provides :package, os: 'linux', platform_family: [ 'rhel', 'fedora' ]
end
end
end
[/ruby]
Wiring up a Resource based on arbitrary node attributes
On Solaris2 for platform_version of <= 5.10 we need to use solaris_package while on platform_version of >= 5.11 we need to use ips_package so our provides line looks like this:
[ruby]
class Chef
class Resource
class SolarisPackage < Chef::Resource::Package
provides :solaris_package
provides :package, os: 'solaris2', platform_family: 'nexentacore'
provides :package, os: 'solaris2', platform_family: 'solaris2' do |node|
# on >= Solaris 11 we default to IPS packages instead
node[:platform_version].to_f <= 5.10
end
end
end
end
[/ruby]
Resource and Provider Provides Lines
For every provides line in a Resource file there should generally be a corresponding provides line in the Provider file. Resources should no longer set the provider explicitly in the constructor of the Resource. It still works to explicitly define the provider in the Resource but this will bypass dynamic provider resolution. It also still works to not have a provides line in the provider file and mangling based on the resource name will still be able to determine the provider, but this is deprecated and soon Chef will warn and then eventually fail if you don't have matching provides lines in both the Resource and Provider.
Supported Provides Syntax
The provides line has ‘os', ‘platform' and ‘platform_family' options which match either arrays or strings. It will also take a block that the node object is passed to and which is expect to return true if the wiring should be done on the node. When multiple matchers are present all of the conditionals must be true. Multiple provides lines can be used for multiple conditions, and the array syntax also matches any of the array components.
[ruby]
provides :cookbook_file
provides :package, os: 'windows'
provides :rpm_package, os: [ 'linux', 'aix' ]
provides :package, os: 'solaris2', platform_family: 'smartos'
provides :package, platform: 'freebsd'
provides :package, os: 'linux', platform_family: [ 'rhel', 'fedora' ]
provides :package, os: 'solaris2', platform_family: 'solaris2' do |node|
node[:platform_version].to_f <= 5.10
end
[/ruby]
The implementation of the syntax is contained within the lib/chef/node_map.rb file. A Chef::NodeMap object is a key-value store where the values can be inserted with conditions based on the node object (and then only if the node object matches will they be retrieved).
Chef Yum Mac Os Download
Dynamic Provider Resolution
Apple operating system os x. Providers also do dynamic resolution. They also have additional methods that they can override to implement Chef::Provider.provides? and Chef::Provider.supports? methods to determine if the platform supports a given provider (e.g. 'is systemd the init system or not?') and if the provider provides? a given resource (e.g. 'is service ‘foo' managed by sysv init scripts or upstart?'). This is almost entirely designed to dynamically handle the use case of Linux init script systems, and the details are out of the scope of this blog post for today. Adventuresome users can poke around the service providers.
LWRP usage
This can be used to wire up LWRPs to arbitrary names! You are no longer bound by the ‘[cookbook_name]_[provider_filename]' default and can even wire up your own LWRPs to the package provider if you want to (although there be dragons — consider that if we ever implement the package provider on your platform in core chef that your custom package provider will collide with the new core chef one and you may break in a minor release since this is an API extension for us, and not a breaking change for our API).
A simple example:
resources/default.rb:
[ruby]
actions :run
default_action :run
provides :foo_bar
attribute :thing, kind_of: String, name_attribute: true
[/ruby]
Mac Os Mojave
providers/default.rb:
[ruby]
use_inline_resources
provides :foo_bar
action :run do
Chef::Log.warn new_resource.thing
end
[/ruby]
recipes/default.rb:
[ruby]
foo_bar 'baz'
[/ruby]
LWRP Chef-11 BackCompat
It turns out that Chef-11 supports the ‘provides' syntax on resources, so that this feature can be used in community cookbooks and other places where Chef-11 backcompat is still important. Chef-12 simply improved on the API which was already present for Resources. It does not allow the ‘provides' syntax on Providers, and it only takes an 'on_platform:' argument (Chef-12 also supports 'on_platform' as an alias for 'platform' for back-compat). To rename LWRPs and maintain Chef-11 backcompat simply drop the ‘provides' line from the Provider, or ideally protect it with an ‘if respond_to?(:provides)' check.
Status
The dynamic Provider and Resolver features are still under development and were not completed with Chef 12. There are still entries in the Chef::Platform platform_map which need to be converted into dynamic resolution and emptied out. Eventually that hash table needs to be completely dropped. There is magic name-to-class mangling that occurs in both Resources and Providers that will be dropped. There are useful helper modules for determining the init system the host is using which need to be exposed as DSL helper methods to assist in writing cookbook code that needs to switch behavior based on the init system actually being used.
How to enable SNMP on Mac OS
1. Configuration
Edit the file: /etc/snmp/snmpd.conf
Add the following line:
rocommunity public
2. Start the SNMP service
Execute the following commands to allow necessary ports:
Monitoring SNMP OiD through Domotz
Once the SNMP daemon has been configured on the Linux machine, and the Community Strings (for V1 and V2 – or Credentials for V3) are matching between the Linux machine and the Domotz Agent, Domotz will automatically browse and report all the possible MIBs available for that specific Linux machine.
In particular, you can search with Domotz for any possible specific OiD available on that specific Linux Machine.
Open the Domotz App or the WebApp. Identify your Linux Machine. Under the tab SNMP/TCP click on Add an SNMP Sensor. You will be proposed with the entire list of SNMP OiD available for that specific device, and the possibility to search among the descriptions (available in the MIB available for that device):
You can for instance search for all the possible OiD which contains the word 'CPU' in their description, and then add the relevant ones.
A date in time mac os. By doing this, you can start monitoring the resource consumptions of your Linux machine.
Below in this article a few example of resource usage statistics extracted by Domotz out of a Linux machine using this mechanism.
CPU Usage
Through Domotz you can monitor either the spikes in the CPU usage as recorded by the CPU Load on 1 Min average:
Or the sustained CPU usage as recorded by the CPU Load on 15 Min average:
It is also possible to monitor the residual (idle) CPU available in the server:
Memory Usage
Through Domotz you can monitor the total available Memory on the Linux machine, or even more importantly the residual memory still free and available on the same:
Volume or Storage occupancy
It is also possible to add the monitoring of any volume or storage and their occupancy via the default hrStorageTable:
For more information about configuring SNMP in Domotz see here.
Alerts on resource usage
Both in the case of the above examples, you can configure alerts so that you are notified if any unexpected load is affecting your server or Linux machine.
For example you can monitor if the CPU Idle at a certain point goes below a certain threshold, or if the residual memory is too low to have a safe environment.
In order to configure alerts, visit the Alert tab, then select the Custom type under the Personal Alerts, and Configure an SNMP Alert.
You will be be provided with the option to select the previously added SNMP OiD as input for the alert.
You can then either decide to receive the notification via Email or Push Notification, as Personal Alerts, or receive the notifications on your preferred channel, via the Shared Alert configuration:
- through shared email addresses
- Your ticketing system or PSA tool integrated with Domotz (e.g. Datto Autotask, ConnectWise Manage, Syncro MSP, Zendesk, Freshservice, etc)
- Your company chat system (e.g. Microsoft Teams or Slack)
- Any Web Server through Web Hooks (or possible third party integrations via Zapier or Node-Red)
Add Resource Usage monitoring via templateing
With Domotz it is possible to configure the monitoring and alerting via SNMP for a specific Linux machine (or generically for any server) and then use that configuration as a template for all the other servers that need to be monitored.
This can be achieved by the Export/Import Device Settings and Properties capability. Boris the mutant bear with a gun mac os.
Once you have completed the configuration of the SNMP parameters you are willing to monitor for a Linux machine, and the alerts' thresholds to get notified, click on the Export Device Settings and Properties.
A json file (like a template file) is generated and saved on your client with all the Domotz settings and properties for that specific device.
This same template json file can then be edited (e.g. to replace or remove some areas) and then used to apply the same SNMP settings (e.g. OiD to be monitored and their threshold) to all the other Linux machines that you are monitoring through Domotz.
This can be achieved from the Global Search and Manage functionality. Search for all the Linux machines you want to apply the template, select them with the multi-select check box, and then click on Import Device Settings and Properties:
Chef Yum Mac Os Download
Preconfigured Template for Linux Machine Resource usage Monitoring
The following file can be used as a baseline to build a template for monitoring resource usage of your Linux Machine:
In particular, once used for the Import Device Settings and Properties functionality, it will create 6 SNMP sensors (on CPU and Memory usage) and two triggers (alerts) on the usage of those resources:
Each device will then have the SNMP and TCP configured with the OiDs for monitoring CPU and Memory usage via SNMP:
Was this article helpful?
Background
In Chef 12 the old Chef::Platform hashmap located in `lib/chef/platform/provider_mapping.rb` has been deprecated. In its place is a dynamic provider and resolver resolution mechanism which is preferred and which can be manipulated via DSL methods on the resource and provider. In Chef 11 it was common to add functionality for platforms in the Chef::Platform hashmap which looks like this:
[ruby]
class Chef
class Platform
class << self
attr_writer :platforms
def platforms
@platforms ||= begin
require ‘chef/providers'
{
:mac_os_x => {
:default => {
:package => Chef::Provider::Package::Macports,
:service => Chef::Provider::Service::Macosx,
:user => Chef::Provider::User::Dscl,
:group => Chef::Provider::Group::Dscl
}
},
:mac_os_x_server => {
:default => {
:package => Chef::Provider::Package::Macports,
:service => Chef::Provider::Service::Macosx,
:user => Chef::Provider::User::Dscl,
:group => Chef::Provider::Group::Dscl
}
},
:freebsd => {
:default => {
:group => Chef::Provider::Group::Pw,
:service => Chef::Provider::Service::Freebsd,
:user => Chef::Provider::User::Pw,
:cron => Chef::Provider::Cron
}
},
[…etc for 400 lines…]
}
end
end
[…etc…]
[/ruby]
Examples of New Syntax
With chef-12 we are starting to wire up providers and resolvers via the `provides` method on the provider and resource classes. Some examples of this include:
Wiring up a resource on all platforms
This is the most trivial example where all platforms get the same cookbook_file resource when the user types ‘cookbook_file' in a recipe:
[ruby]
class Chef
class Resource
class CookbookFile < Chef::Resource::File
provides :cookbook_file
[…etc…]
end
end
end
[/ruby]
Wiring up a resource on an os
This only wires up the ips_package resource when the node[‘os'] attribute is ‘solaris2'
Deck the balls mac os. [ruby]
class Chef
class Resource
class IpsPackage < ::Chef::Resource::Package
provides :ips_package, os: 'solaris2'
end
end
end
[/ruby]
Wiring up a resource on multiple platform_families
This is a more complicated example, showing that the provides line supports node[‘platform_family'] and that arrays of values can be used. This also wires up the the yum_package resource to whenever the user types ‘yum_package' in a recipe no matter which platform (so even on Solaris if you type ‘yum_package' in a recipe you'll get this kind of resource), but also on the redhat-like platform_families if the user types ‘package' we wire that up to resolve to the ‘yum_package' resource. This is a slight change from Chef 11 where if you typed ‘package 'foo'‘ on redhat you would get a vanilla Chef::Resource::Package object which would do vanilla package validation checking and any yum-specific options would be rejected. In Chef 12 on redhat you will get a Chef::Resource::YumPackage object which will do the correct validation for the YumPackage provider.
[ruby]
class Chef
class Resource
class YumPackage < Chef::Resource::Package
provides :yum_package
provides :package, os: 'linux', platform_family: [ 'rhel', 'fedora' ]
end
end
end
[/ruby]
Wiring up a Resource based on arbitrary node attributes
On Solaris2 for platform_version of <= 5.10 we need to use solaris_package while on platform_version of >= 5.11 we need to use ips_package so our provides line looks like this:
[ruby]
class Chef
class Resource
class SolarisPackage < Chef::Resource::Package
provides :solaris_package
provides :package, os: 'solaris2', platform_family: 'nexentacore'
provides :package, os: 'solaris2', platform_family: 'solaris2' do |node|
# on >= Solaris 11 we default to IPS packages instead
node[:platform_version].to_f <= 5.10
end
end
end
end
[/ruby]
Resource and Provider Provides Lines
For every provides line in a Resource file there should generally be a corresponding provides line in the Provider file. Resources should no longer set the provider explicitly in the constructor of the Resource. It still works to explicitly define the provider in the Resource but this will bypass dynamic provider resolution. It also still works to not have a provides line in the provider file and mangling based on the resource name will still be able to determine the provider, but this is deprecated and soon Chef will warn and then eventually fail if you don't have matching provides lines in both the Resource and Provider.
Supported Provides Syntax
The provides line has ‘os', ‘platform' and ‘platform_family' options which match either arrays or strings. It will also take a block that the node object is passed to and which is expect to return true if the wiring should be done on the node. When multiple matchers are present all of the conditionals must be true. Multiple provides lines can be used for multiple conditions, and the array syntax also matches any of the array components.
[ruby]
provides :cookbook_file
provides :package, os: 'windows'
provides :rpm_package, os: [ 'linux', 'aix' ]
provides :package, os: 'solaris2', platform_family: 'smartos'
provides :package, platform: 'freebsd'
provides :package, os: 'linux', platform_family: [ 'rhel', 'fedora' ]
provides :package, os: 'solaris2', platform_family: 'solaris2' do |node|
node[:platform_version].to_f <= 5.10
end
[/ruby]
The implementation of the syntax is contained within the lib/chef/node_map.rb file. A Chef::NodeMap object is a key-value store where the values can be inserted with conditions based on the node object (and then only if the node object matches will they be retrieved).
Chef Yum Mac Os Download
Dynamic Provider Resolution
Apple operating system os x. Providers also do dynamic resolution. They also have additional methods that they can override to implement Chef::Provider.provides? and Chef::Provider.supports? methods to determine if the platform supports a given provider (e.g. 'is systemd the init system or not?') and if the provider provides? a given resource (e.g. 'is service ‘foo' managed by sysv init scripts or upstart?'). This is almost entirely designed to dynamically handle the use case of Linux init script systems, and the details are out of the scope of this blog post for today. Adventuresome users can poke around the service providers.
LWRP usage
This can be used to wire up LWRPs to arbitrary names! You are no longer bound by the ‘[cookbook_name]_[provider_filename]' default and can even wire up your own LWRPs to the package provider if you want to (although there be dragons — consider that if we ever implement the package provider on your platform in core chef that your custom package provider will collide with the new core chef one and you may break in a minor release since this is an API extension for us, and not a breaking change for our API).
A simple example:
resources/default.rb:
[ruby]
actions :run
default_action :run
provides :foo_bar
attribute :thing, kind_of: String, name_attribute: true
[/ruby]
Mac Os Mojave
providers/default.rb:
[ruby]
use_inline_resources
provides :foo_bar
action :run do
Chef::Log.warn new_resource.thing
end
[/ruby]
recipes/default.rb:
[ruby]
foo_bar 'baz'
[/ruby]
LWRP Chef-11 BackCompat
It turns out that Chef-11 supports the ‘provides' syntax on resources, so that this feature can be used in community cookbooks and other places where Chef-11 backcompat is still important. Chef-12 simply improved on the API which was already present for Resources. It does not allow the ‘provides' syntax on Providers, and it only takes an 'on_platform:' argument (Chef-12 also supports 'on_platform' as an alias for 'platform' for back-compat). To rename LWRPs and maintain Chef-11 backcompat simply drop the ‘provides' line from the Provider, or ideally protect it with an ‘if respond_to?(:provides)' check.
Status
The dynamic Provider and Resolver features are still under development and were not completed with Chef 12. There are still entries in the Chef::Platform platform_map which need to be converted into dynamic resolution and emptied out. Eventually that hash table needs to be completely dropped. There is magic name-to-class mangling that occurs in both Resources and Providers that will be dropped. There are useful helper modules for determining the init system the host is using which need to be exposed as DSL helper methods to assist in writing cookbook code that needs to switch behavior based on the init system actually being used.
There are also currently no docs at docs.chef.io for any of these APIs (if your name is James Scott you should ping me about fixing this).
