CHEF- RESOURCES - macos_app_management Resource

Syntax of macos_app_management Resource

There are many properties that are available to the macos_app_management resource. Following is the complete syntax for all these properties:

macos_app_management 'name' do
  munki_client_download_url      String
  munki_password                 String
  munki_repo_url                 String
  munki_user                     String
  action                         Symbol # defaults to :install if not specified
end

In the above syntax,

• The resource name is macos_app_management.
• The name of the resource block is given using the name.
• The steps taken by Chef Infra Client to bring the node into the required state are identified by action.
• Munki_client_download_url, munki_repo_url, munki_password, and munki_user are the properties that are available to the resource.

Actions of macos_app_management Resource

Following are the actions that the macos_app_management resource has:

• :nothing- This resource block will not act unless it is notified by any other resource to take action. Once notified, this resource block will either run immediately or be queued up to run at the end of a Chef Infra Client run.
• :install- It is used to install the clients on the macOS node.

Properties of macos_app_management Resource

Following are the properties that the macos_app_management resource has:

• :munki_client_download_url- It is the URL from which the nodes will download the Munki client.
• :munki_password- It is the password that is associated with the munki_user account.
• :munki_repo_url- It is the repository URL nodes will use to download the apps or settings.
• :munki_user- It is the username that is used to connect to the munki_repo_url.

Common Resource Functionality of macos_app_management Resource

Chef resources also include some common properties, notifications, and resource guards.

Common Properties

Following are the properties that are common to every resource:

• compile_time: It controls the phase during which the resource is run on the node. We can set it to “true” to run while the resource collection is being created (the compile phase). We can set it to “false” to run while Chef Infra Client is working on the node configuration (the converge phase).
• ignore_failure: It helps in running a recipe even if a resource has failed for any reason. :quiet will not show the full stack trace. As a result, the recipe will continue to run even if a resource fails.
• retries: It is the number of attempts to catch an exception and retry the resource.
• sensitive: It ensures that Chef Infra Client does not log sensitive resource data.
• retry_delay: It is the delay in seconds between the retry attempts.

Notifications

• notifies: When one resource's state changes, it may notify another resource to take appropriate action. A resource can notify multiple resources. It uses a “notifies” statement for each resource that has to be notified.
• subscribes: If the status of the resource being listened to changes, the resource that is listening may take action after doing so.

A timer is used to specify the point during a Chef Infra Client run at which a notification will run. The following timers are available:

• :before- It specifies that the action on a notified resource must run before processing the resource block in which the notification is present.
• :delayed- It specifies that a notification should be queued up and executed at the end of a Chef Infra Client run.
• :immediate, :immediately- It specifies that a notification should run immediately for each resource that has been notified.

Guards

When a Chef Infra Client run is executed, a node's state can be assessed using a guard property. Depending on these results, a guard property is then used to inform the Chef Infra Client whether it should further carry out a resource's execution. A Ruby block value or a string value can be used to specify a guard property:

Properties

• not_if: It prevents a resource from executing when the condition returns true.
• only_if: It allows a resource to execute only if the condition returns true.

Examples

The following examples demonstrate various approaches for using the macos_app_management resource in recipes:

Setting up managed app management for clients:

macos_app_management 'Configure Munki on the node' do
  munki_client_download_url 'https://github.com/munki/munki/releases/download/v5.0.0/munkitools-5.0.0.4034.pkg'
  munki_repo_url 'https://something.something.tld'
  munki_user 'munki'
  munki_password 'ILoveMunki'
  action :install
end

Frequently Asked Questions

What are the three main components of a chef?

Workstations, servers, and nodes are the three main components of Chef.

What is a client in Chef?

On each node that Chef is responsible for managing, an agent called a chef-client runs locally.

What do cookbooks mean for chefs?

Fundamental working units of Chef are cookbooks, which are made up of all the information pertaining to working units and can change the configuration and the status of any system that has been set up as a node on the Chef infrastructure. Cookbooks are capable of many things.

Conclusion

In this article, in detail, we have studied one of the Chef Resources, known as the macos_app_management Resource.

We hope that this article has provided you with the help to enhance your knowledge regarding the macos_app_management Resource and if you would like to learn more, check out our articles on Chef migration and Chef Desktop. Practice makes a man perfect. To practice and improve yourself in the interview, you can check out Top 100 SQL problems, Interview experience, Coding interview questions, and the Ultimate guide path for interviews.

Do upvote our blog to help other ninjas grow. Happy Coding!