Nested VirtualBox virtual machine on a VirtualBox virtual machine

There can be reasons when we want to run a VirtualBox virtual machine on another VirtualBox virtual machine.

I am setting up a Windows virtual machine to interview job candidates and want to run a small Ubuntu virtual machine on the Windows virtual machine. It is not recommended for performance reasons, but I want to set up a base interview machine that I can wipe and recreate any time for the next candidate.

Besides the performance hit there is one more rule: the nested guest operating system needs to be 32 bit.

Even if you have a 64 bit workstation, and run a 64 bit guest operating system on it, the VirtualBox on the guest operating system can only host 32 bit guest-guest operating systems, because for a 64 bit operating system to run, the host machine needs to have the CPU Extension feature turned on. Currently only physical CPUs have the CPU Extension feature, so even a 64 bit guest virtual machine cannot provide it.

To set up the 32 bit nested virtual machine

  1. Download ISO image of the 32 bit version of Ubuntu from http://releases.ubuntu.com/artful/
  2. Start VirtualBox
  3. Click the New icon to create a new virtual machine
  4. Select Linux (32 bit)
  5. Accept the default memory and hard drive settings

Start the virtual machine the first time

  1. Select the new virtual machine
  2. Click the Start button
  3. Browse to the downloaded 32 bit Ubuntu ISO image
  4. Follow the prompts to set up the operating system

 

Resize the VirtualBox image hard drive

When your VirtualBox virtual machine’s hard drive fills up Virtual Box does not provide a user interface to extend it. If you run VirtualBox on a Macintosh workstation

  1. Stop the virtual machine
  2. On a Macintosh workstation, the virtual machine image files are located at ~/VirtualBox VMs
  3. The name of the subdirectory and the image file matches the name of the machine
  4. Open a terminal window
  5. Navigate to the VirtualBox application directory 
    $ cd /Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app/Contents/MacOS
  6. Check the current size of the hard drive. Place a backslash in front of every space character in the path. 
    VBoxManage showhdinfo ~/VirtualBox\ VMs/Win\ 10/Win\ 10.vdi
  7. Resize the drive. Place a backslash in front of every space character in the path, and specify the size in megabytes, so 100 GB is approximately 100000 MB 
    VBoxManage modifyhd --resize 100000 ~/VirtualBox\ VMs/Win\ 10/Win\ 10.vdi

    UMG/Win\ 10\ UMG.vdi
    0%…10%…20%…30%…40%…50%…60%…70%…80%…90%…100%

  8. Check the size again to make sure the resizing succeeded.

Extend the volume on the enlarged partition

Windows 10 virtual machine

  1. Start the virtual machine
  2. Click the Start button and the Gear icon to start the control panel
  3. Type admin into the search box and select Administrative Tools
  4. Double-click Computer Management
  5. Select Disk Management
  6. Right-click the partition and select Extend Volume…
  7. Click Next on every page of the wizard to extend the volume to the maximum available size.

Ruby tips and tricks

Bang methods

(Exclamation point at the end of the method name)

There are methods that have a permanent or dangerous version. The exclamation point designates to use the dangerous version of the method.

String manipulation

The bang versions of the string manipulation methods (with the exclamation point), modify the string variable in place. Some of these methods are

  • sub
  • gsub
  • reverse
  • sort

The original string ‘gsub’ substitution method:

original = 'My old cat'
new = original.gsub('old', 'new')

results:
original = 'My old cat'
new ='My new cat'

The dangerous (bang) ‘gsub’ method with the exclamation point modifies the original variable:

original = 'My old cat'
original.gsub!('old', 'new')

results:
original = 'My new cat'

Kernel::exit

The script exits with Kernel::exit, but Kernel::exit! causes an immediate exit, bypassing any exit handlers.

 

Find the AWS account number

The AWS account number uniquely identifies the AWs account you are working with. All AWS “arn” identifiers contain it, and you need to know it when you want to share AMIs with other accounts.

If there are no resources created yet in the account, you can find the account number in the “arn” of your user account.

  1. Log into the AWS Console
  2. In the upper right corner click your username and select My Security Credentials
  3. On the left side select Users, and click any of the usernames in the list
  4. The account number is part of the “User ARN”

Execute Terraform scripts with Octopus

Terraform is a very powerful, free command-line tool to launch servers in any cloud or virtual machine environment. Hashicorp, the creator of Terraform just introduced the paid Terraform Enterprise server, that orchestrates the execution of the Terraform scripts.

Octopus is another tool that added Terraform orchestration functionality in version 2018.3

In this example, we will set up a Multi-Tenant Octopus project to launch servers in AWS with Terraform scripts and configure them with Chef.

Quick Links

Terraform script location

Create a GitHub repository for the Terraform script

GitHub is the most flexible way to store the Terraform scripts. Octopus can download and execute the same script in multiple Octopus projects. This eliminates the code duplication and makes the scripts available for execution from the command line.

Create a GitHub user with read access to the repository

If the GitHub repository is private, Octopus will need a way to access it with a username and password.

Tag the source code version, Octopus needs a version to refer to the version of your script

git tag 1.0.0
git push --tags

Automation with Octopus

We will create a Multi-Tenant Octopus project to be able to use the same Octopus project for multiple server types in multiple AWS environments.

We will create

  • an Octopus project group to hold the AWS launch projects,
  • a generic Octopus project to launch an AWS EC2 instance,
  • an operating system specific Octopus project that calls the generic project
  • environments for each AWS account, application, application environment,
  • tenants for each server.

Create the Environments

  1. On the Infrastructure Octopus page select Environments
  2. On the Environments page click the ADD ENVIRONMENT button
  3. Create the environments you need (aws-dev, aws-qa, aws-uat, aws-prod)
    1. In the Dynamic Infrastructure section check the Allow managing dynamic infrastructure checkbox

Create a Lifecycle

The lifecycle governs how the project is promoted between environments.

  1. On the Library Octopus page select Lifecycles
  2. Click the ADD LIFECYCLE button
  3. Enter the name and description of the Lifecycle and click the ADD PHASE button

  4. Enter a name for the Phase and click the ADD ENVIRONMENT link to select the environment
  5. Select the environment and the Users will need to manually… radio button
  6. Keep the All environments must be deployed… and click the Save button.

Create a project group

The project group holds your launch projects together.

  1. On the Projects Octopus page select ADD GROUP
  2. Enter a name and description for the project group

Create a GitHub feed

This feed will allow Octopus to connect to GitHub

  1. On the Library Octopus page select External Feeds
  2. Click the ADD FEED button
  3. Select the GitHub Repository Feed type, enter a name and copy the recommended URL. Add the GitHub user’s name and password you have created above, and click the SAVE AND TEST link

  4. Enter the complete name of your Terraform repository and click the SEARCH button to make sure Octopus has access to the private repository. If you do not specify the full path of the repository, the search will display public repositories with similar names.

Store an AWS account reference in Octopus

AWS accounts store the credentials to connect to Amazon Web Sevices

  1. On the Infrastructure page select Accounts
  2. In the Amazon Web Services section click the ADD ACCOUNT button and select the account type
  3. Enter a name, description, Access Key and Secret Key for the account. Enable the usage in tenanted and untenanted deployments, and click the SAVE AND TEST link.


Store SSH Keys in Octopus

Store your private keys in Octopus, so you can reference them in your variables.

  1. On the infrastructure page select Accounts
  2. In the SSH Key Pairs section click the ADD ACCOUNT button
  3. Enter the SSH key name, the username, and click the up arrow to upload the SSH private key file to the Octopus server.
    1. Select the Include in both tenanted and untenanted deployments radio button.
    2. In the Associated Tenants section select the tenant groups you want to use the key for.
  4. Click the SAVE button to save the certificate in Octopus

Create a Project

The project contains the reference to the Terraform script to launch the server, the connection to the GitHub repository where the Terraform script is stored, and credentials to access the AWS account. The Terraform script and GitHub connection are going to be the same for every server launch, but the AWS account credentials have to be different for each AWS account. If you work with multiple AWS accounts, you need to create separate projects for each AWS account.

  1. On the Projects Octopus page scroll down to the DevOps project group and click the ADD PROJECT button
  2. Enter a name and description for the new project, and click the ADVANCED SETTINGS link
  3. Select the lifecycle you have created earlier, and click the SAVE button.

Create the launch process

  1. On the left side select the Process menu item
  2. On the Process page click the ADD STEP button
  3. Type “terraform” into the filter field and select Apply a Terraform template step

Create the variables

  1. In the project click the Variables menu item
  2. Enter the name of the variable and click the value field
  3. Click the CHANGE TYPE link
  4. Select the Amazon Web Services Account type
  5. Enter a description and select the AWS account you have created above, and click the DONE button.
  6. Create the rest of the variables.
  7. Add prefixes to the variables that will be set in the OS-specific child project, in the tenant, environment, and target.

Update the variable names in the Terraform script

When we added prefixes to the project variables to show which component is responsible for setting it, we have changed the variable name. Update the Terraform script to reflect it.

ami = "#{os.instance_ami}"

Create an OS-specific child project that calls the generic parent project

There are values that are different for each operating system in each AWS account.

The AMI ID depends on the operating system and the application environment. We can test the new version of the operating system in the development environment, while we are still launching servers with the old, tested version for production.

The common, OS-specific security group ID is different in every AWS account. It depends on the AWS account and the operating system.

To be able to set the value of this variable based on the OS and the AWs account, or the OS and application environment, we need to create an OS-specific project that passes in the appropriate variable values to the generic project.

  1. On the Projects page scroll down to the DevOps project group and click the ADD PROJECT button
  2. Enter the name and description of the new project and click the ADVANCED SETTINGS link
  3. Select the DevOps-aws-lifecycle
  4. Click the Process menu item
  5. Click the ADD STEP button
  6. Select the Deploy a Release step
  7. Enter the name for the step and select the generic AWS EC2 Launch project

Create variables

Set the OS-specific variables in the OS-specific child project. To avoid variable name collision later add the parent.prefix to the variables passed in from the child to the parent project.

Settings

  1. Click the Settings menu item
  2. Require tenant for the deployment, allow the deployment without target, and ask if there is an error. Chef raises an error when it reboots the server, so if the Chef cookbook contains the reboot resource, we need to accept the error for a successful deployment.
  3. Click the Variables menu item
  4. Add the OS-specific variables

Create Library Variable Templates

Library Variable Sets specify the variables that have to be set in a higher level component, like a tenant, environment, and target.

  1. On the Library Octopus page select Variable Sets
  2. On the Variable Sets page click the ADD NEW VARIABLE SET button
  3. Enter a name and description for the library variable set
  4. Click the VARIABLE TEMPLATES tab
  5. On the VARIABLE TEMPLATES tab click the ADD TEMPLATE link
  6. Add the variables to the Library Variable Template. For pre-defined choices use the Drop down control type. To avoid variable name collisions when we pass the variable values to the parent project later, add the “parent.” prefix to every variable.

  7. Save the Library Variable Template

Add the Library Variable Templates to the OS-specific child project

Add the Library Variable Sets to the OS-specific project, so the tenants can set them with the instance-specific values.

  1. Open the project and select the Variables menu item
  2. Select the Library Sets menu item
  3. Click the INCLUDE LIBRARY VARIABLE SETS button
  4. Select the newly created Library Variable Set

Pass the variables from the child project to the generic parent project

The child project can pass variables into the parent project. Select the variable to pass into the parent project. You need to do this in every child project that calls the common parent project.

  1. In every child project select Process
  2. Select the process that calls the parent project
  3. Click the Variables section
  4. Click the ADD VARIABLE link
  5. Add the OS-specific variables set in the child project and the host-specific variables defined in the Library Variable Template and set in the tenant.

Create a Tenant

Tenants are server types that use the same Octopus project. A tenant can be an application or a software development project where the servers share common attributes and run on the same operating system type, like all Linux, or all Windows, so the same Terraform script can launch them.

  1. In Octopus select the Tenants page and click the ADD TENANT button
  2. Enter the name of the new tenant
  3. Click the Setting button to select a logo for the tenant
  4. Click the logo placeholder to open the region
  5. Click the file selection button to browse to a 100×100 image file

Tag the Tenant

Tags help you to organize your tenants.

  1. On the Library page select Tenant Tag Sets
  2. Click the ADD TAG SET button
  3. Enter a name and description for the tag set, and create the first tag, and click the ADD link
  4. Click the EDIT TAGS link to add tags to the tenant
  5. Click the small arrow to select the tags

Connect the Tenant to the project

  1. On the Tenants page select the tenant you want to add to the project
  2. Click the CONNECT PROJECT button
  3. Select the project and all environments you want to launch instances for this tenant (software project)

Set the tenant variable values

  1. On the Tenant page select Variables
  2. Select the COMMON VARIABLES tab
  3. Click the name of the template to open it
  4. Set the value and click the Bind icon
  5. When all required variables are set, the SAVE button becomes available.

Create a deployment target (server)

Deployment targets are the servers we are launching. In enterprise settings, all servers have a standardized name that conforms to the company standards.

  1. In the
  2. Click the ADD DEPLOYMENT TARGET button
  3. Select the Cloud Region radio button
  4.  Enter the server name, deployment and a role, and do not press the Save button yet
  5. In the Restrictions region select the Include in both tenanted and untenanted deployments radio button select the Tenant you have created.

Create project releases

If there was a change in the parent project, we need to create a release for the parent project and all child projects that call it.

Create a release of the generic parent project

  1. On the project page click the CREATE RELEASE button
  2. If you use GitHub as the Terraform script source, the no version specified message displays in the Packages section
  3. Tag the GitHub repository. Octopus needs a version to link to a GitHub package. 
    git tag 1.0.0
git push --tags
  4. Click the SEARCH link to find the latest version of the repository
  5. Select the latest version of the GitHub repository
  6. Click the SAVE button

Create releases for the child projects

  1. Open the project
  2. Click the CREATE RELEASE button
  3. Enter the Release Notes, so later you can identify this release

Deploy the server

  1. Open the OS-specific project
  2. Click the Releases menu item
  3. Select the release
  4. Click the DEPLOY TO button and select the environment

    1. If the project was already deployed to an environment, that environment does not show up in the list, so click the ellipsis and select Delpoy To from the dropdown menu.
    2. Select the environment from the list
  5. Click the tenant section to select the tenant (server) to launch
  6. Click the DEPLOY button

Maintenance

Changing the Terraform script, adding new servers, operating systems, environments, and AWS accounts

Changing the Terraform script

The Octopus project release is tied to a specific Git tag (release). When we change the Terraform script in the Git repository we need to

  1. Create a new Git tag with 
    git tag 1.0.12
git push --tags
  2. Create a new release of the generic parent project. Make sure the generic parent project references the new tag:
    1. Open the project in Octopus,
    2. On the left side select Releases, and select the new generic parent project release,
    3. Make sure the new generic parent project release references the new Git tag.
  3. Create a new release of every OS-specific child project that calls the generic parent project.

Adding new tenant variable

  1. Add the new variable to the Terraform script or JSON file
    “set_external”: “#{host.set_external}”
  2. Add the new variable to the generic parent project (host.set_external)
  3. Add the variable to the Library -> Variable Sets -> “DevOps-aws-host” -> Variable Templates
    1. Click the ADD TEMPLATE button
    2. Enter the Variable name ( parent.host.set_external )
    3. Control type: Single-line text box
    4. Enter UNDEFINED as the default value, so it will not throw an error until added to all tenants
    5. Click Add
    6. Click Save
  4. Populate the new variable value in the Tenant manually or during Tenant creation with your automation tool ( Octotenant )
    parent.host.set_external
  5. Add the variable assignment to the Variables section of the Process of every child project
    host.set_external = #{parent.host.set_external}

New Server

  1. Create a new Tenant

New AMI

  1. Update the AMI in the OS-specific child project
  2. Open the Releases page of the child project
  3. Select the latest release
  4. Click the UPDATE VARIABLES link

New Application

  1. Create a new Tenant Tag in the “DevOps Applications” Tenant Tag Set
  2. Add the new Tenants to the Tenant Tag of the application

New Operating System

  1. Clone one of the DevOps AWS EC2 OS… projects
  2. Update the project settings, because those are not cloned
    1. Tenants required for all deployments
    2. Deployments with no target allowed
  3. Update the project variables for the new operating system
  4. Create a release of the new project
  5. Create new Tenants and link them to the new OS project

New Environment or AWS account

  1. Create the DevOps-env-[environment][account number] environment. See Create the Environments
    1. Infrastructure, Environments, ADD ENVIRONMENT
    2. Check the Dynamic Infrastructure -> Allow managing dynamic infrastructure checkbox
  2. Add the new environment to the “DevOps-aws-lifecycle”
    1. Library, Lifecycles, DevOps-aws-lifecycle
    2. Click Phase 1
    3. ADD ENVIRONMENT
    4. Keep Users will need to manually queue the deployment to this environment selected
    5. Click the SAVE button
  3. Add the new account if necessary. See Add AWS AccountStore an AWS account reference in Octopus above.
  4. Add the new environment to the variable scopes in
    1. the base project: “DevOps AWS EC2 Launch”
      1. account.aws_key
      2. account.aws_key_name
      3. environment.aws_account_credentials (zoom out to be able to see the Done button at the bottom of the popup)
      4. create a new environment.chef_environment
      5. environment.instance_tag_environment
  5. Create a new release of the “DevOps AWS EC2 Launch” base project that will be called by the OS specific projects
    1. Add the new environment to the variable scopes in all OS specific projects: “DevOps AWS EC2 OS…”
      1. parent.os.account.instance_common_security_group_id
    2. Create a new release of all updated OS specific “DevOps AWS EC2 OS…” projects.

New Chef Attribute

To pass in a new Chef attribute from the Tenant

  1. Add the new attribute to the chef_attributes.json file with variable substitution 
    {
 "set_hostname": "#{host.set_hostname}",
 "agent_name": "#{host.agent_name}",
 "add_to_domain": "#{host.add_to_domain}"
}
  2. Add the new variable to the Library Variable Set’s Variable Template with the parent. prefix
  3. Add the new variable to the passed in variable list in every parent project process. See Pass the variables from the child project to the parent project

Troubleshooting

To save the variable values to the log add the following two variables to the project

OctopusPrintVariables True
OctopusPrintEvaluatedVariables True

For the change to take effect

Create a new release

or 

Update the variable snapshot of the existing release

  1. On the Project -> Releases  page select the latest release
  2. In the Variable Snapshot section click the SHOW link
  3. Click the UPDATE VARIABLES link

More info at https://octopus.com/docs/support/debug-problems-with-octopus-variables

Migrating from Chef Client version 12 to 13

Chef is under heavy development, every new major version introduces new features, and many times changes, deprecates, or removes some commands or options.

Chef Client 13 introduced a new way of handling reboots and Windows scheduled tasks.

reboot resource

In Chef version 12, the “:reboot_now” action continued the execution of the Chef cookbook but after the specified “delay_mins” the instance was forcefully rebooted even if an application was still running. This could unexpectedly interrupt software installations that did not finish during the specified delay.

This is not a problem if the reboot resource was called with the “:request_reboot” action because in that case, the delay before the reboot starts when the cookbook execution has completed.

In Chef version 13, when the reboot command is ultimately sent to the operating system handling the”:reboot_now” or”:request_reboot” action, a Ruby error is raised to stop the execution of the Chef cookbooks. This prevents the execution of further commands, that would be interrupted by the imminent reboot but puts misleading error messages into the “C:/Chef/Cache/chef-stacktrace.out” file.

Generated at …
Chef::Exceptions::Reboot: Rebooting server at a recipe’s request. Details: {:delay_mins=>1, :reason=>”…”, :timestamp=>…, :requested_by=>”…”}

This is unnecessary in the case of the “:request_reboot” action because the instance is only rebooted when the Chef cookbook execution has already been completed. Chef still raises the error in both cases.

In Test Kitchen

In Chef 12 when the instance was rebooted the DevOps engineer had to wait for the instance to reboot and issue the “kitchen converge” command again to execute the cookbook again.

In Chef 13 Test Kitchen executes the “kitchen converge” command if the cookbook execution failed. This simulates the execution of the Chef Client when the instance starts after the reboot. The error raised by the reboot command helps to test cookbooks with multiple reboots without the need of paying attention to every reboot. This new behavior causes a timeout error when Test Kitchen tries to access the instance while it is still rebooting.

To avoid this we need to add lines to the provisioner section of the .kitchen.yml file

provisioner:
  name: chef_zero
  always_update_cookbooks: true
  retry_on_exit_code: # An array of exit codes that can indicate that kitchen should retry the converge command. Defaults to an empty array.
    - 35              # Reboot is scheduled
    - 20              # The Windows system cannot find the device specified.
    - 1               # Generic failure
  wait_for_retry: 120 # Number of seconds to wait between converge attempts. Defaults to 30.
                     # Chef starts another converge after reboot was requested.
                     # If the 'wait_for_retry' (seconds) is shorter than the 'delay_mins', the converge starts before the reboot happens.
                     # 'wait_for_retry' (set in seconds!) has to be greater than any 'delay_mins' passed to reboot
  max_retries: 10 # Number of times to retry the converge before passing along the failed status. Defaults to 1.

It is very important to set the value of the “wait_for_retry” option greater in seconds, than the longer “delay_mins” set in any “reboot” resources of the cookbook, for Test Kitchen to wait with the retry of the cookbook execution until the instance is rebooted. If Test Kitchen does not wait for the reboot, the next “converge” starts before the instance is rebooted, and the execution will be interrupted by the reboot. After the “wait_for_retry” delay Test Kitchen will try to connect to the instance for “max_retries” times waiting “wait_for_retry” seconds between the tries until the box starts to accept WINRM connections again.

 

windows_task resource

There are two major changes in the windows_task resource.

If the scheduled task already exists and the resource tries to create it again with the same values, an error is thrown

It looks like the error is in the step that tries to parse the start time of the task. Make sure

To change an existing scheduled task

Chef version 13 does not understand the “:change” action. To change an existing scheduled task, use the “:create” action. If you run your cookbooks on multiple Chef versions, you have to make sure those work on the old and the new versions of Chef.

The transition is not so simple, both versions of Chef throw errors when we switch to the :create action.

If you try to modify an existing scheduled task with the “:create” action in Chef 12:

NoMethodError: undefined method `tr’ for nil:NilClass

 

in Chef 13:

Invalid starttime value.

 

Use PowerShell to modify existing scheduled tasks.

To delay the execution of the chef-client scheduled task by two hours to give enough time for the application install between reboots:

$taskpath = "\\"
$taskname = "#{chef_client_task_name}"

$tsDelay = New-TimeSpan -Days 0 -Hours 2 -Minutes 0
$newStartTime = (get-date) + $tsDelay

$tsRepetition = New-TimeSpan -Days 0 -Hours 0 -Minutes 30
$tsDuration = ([timeSpan]::maxvalue)

$trigger = New-ScheduledTaskTrigger -Once -At $newStartTime -RepetitionInterval $tsRepetition -RepetitionDuration $tsDuration

$user = (schtasks.exe /query /s localhost /V /FO CSV | ConvertFrom-Csv | Where { $_.TaskName -eq ($taskpath + $taskname) })."Run As User"
$principal = New-ScheduledTaskPrincipal -UserID $user -LogonType S4U -RunLevel Highest

set-scheduledtask -TaskPath $taskpath -TaskName $taskname -Trigger $trigger -Principal $principal

To set the RunAs user of a Scheduled Task

$user = "NEW_USER_NAME"
$password = "NEW_USER_PASSWORD"

$taskpath = "\\"
$taskname = "TASK_NAME"

set-scheduledtask -TaskPath $taskpath -TaskName $taskname -User $user -Password $password

 

 

 

How to upgrade Jenkins

Jenkins regularly releases new versions. To upgrade Jenkins

On Linux

To install the Generic Java Package (.war)

  1. Write down the current version of Jenkins you have on your server
  2. Download the Jenkins “Generic Java Package (.war)” file from https://jenkins.io/download/to your workstation
  3. Upload the installer to Artifactory or other HTTP repository
  4. SSH into the Jenkins server
  5. Switch to sudo mode
  6. Stop the Jenkins service with 
    service jenkins stop
  7. Navigate to the Jenkins directory 
    cd /usr/lib/jenkins/
  8. Rename the current Jenkins .war file to include the version, so you can restore it if the new version does not work as expected 
    mv jenkins.war jenkins_2.46.3.war
  9. Download the Jenkins war file from Artifactory 
    url -O http://THE_IP_ADDRESS_OF_THE REPOSITORY/.../jenkins.war
  10. Start the Jenkins service 
    service jenkins start

 

Calling a resource in the Chef recipe

During major Chef Client version upgrades, some instructions need to be changed based on the version of the Chef Client. For example, upgrading from version 12 to version 13, the “windows_task” resource requires a different action to make changes to existing scheduled tasks.

To call a Chef resource in your cookbook, you need another resource to call from. If you execute the notifies command by itself you get the error message:

NoMethodError
————-
undefined method `declared_key’ for “….[…]”:String

In this example, we call the “windows_task” resource to delay the execution of the chef-client by two hours to give enough time for the server configuration to complete. In Chef version 12 we need to set the action to “:change”, in Chef version 13, it needs to be “:create”.

if ( Chef::VERSION.to_f >= 13.0 )
  puts "Version 13.0 or higher"

  ruby_block "call delay chef-client" do
    block do
      # Do nothing, "block do" has to be here
    end
    notifies :create, "windows_task[delay chef-client]", :immediately
  end
else
  puts "Before version 13.0"

  ruby_block "call delay chef-client" do
    block do
      # Do nothing, "block do" has to be here
    end
    notifies :change, "windows_task[delay chef-client]", :immediately
  end
end

future_time = Time.now.utc + 7200               # Offset is in seconds: 2 hour delay
new_start_day = future_time.strftime('%m/%d/%Y')
new_start_time = future_time.strftime('%H:%M')

windows_task 'delay chef-client' do
  task_name 'chef-client'
  start_day new_start_day
  start_time new_start_time
  action :nothing
  guard_interpreter :powershell_script
  only_if "(Get-ScheduledTask | Where-Object {$_.TaskName -eq 'chef-client'}).TaskName.Length -gt 0"
end

 

Make decisions in your Chef recipe based on the version of the Chef Client

There are times when you have to make a decision in your Chef recipe, based on the version of the Chef Client installed on the node.

There are two ways to get the version of the installed Chef Client:

Chef::VERSION
node['chef_packages']['chef']['version']

To make a decision based on the installed Chef Client version

if ( Chef::VERSION.to_f >= 14.0 )
  puts "Version 14.0 or higher"
else
  puts "Before version 14.0"
end