Create a new server image for a RightScale server template

The RightScale server templates publish server images to launch. It is advisable to create your own server image because the cloud providers can remove their published images anytime. If you generate your own image, you control the lifecycle of those.

Create your own server image

  1. Use Packer to create a new server image.
    1. Install RightLink.
      1. On Windows
            1. Create a PowerShell script and save it as install-rightlink.ps1
              $wc = New-Object System.Net.Webclient
              $wc.DownloadFile("https://rightlink.rightscale.com/rll/10/rightlink.install.ps1",
                 "$pwd\rightlink.install.ps1")
              Powershell -ExecutionPolicy Unrestricted -File rightlink.install.ps1
            2. Execute it from the Packer template
              "provisioners": [
                {
                  "type": "powershell",
                  "pause_before":"10s",
                  "scripts": [
                  "install-rightlink.ps1"
                  ]
                }
              ]
    2. For more information see “Create Custom Images with RightLink” at  http://docs.rightscale.com/rl10/getting_started.html
  2. Make the image public, so RightScale can see it
    1. Open the AWS console
    2. On the EC2 Dashboard select AMIs
    3. Find the image by AMI resource ID
    4. On the Permission tab click the Edit button
    5. Keep the image private, but share it with the AWs account you create the server template in.

Attach the image to your RightScale server template

Make sure the image is visible in RightScale.

It can take 30 minutes for the new image to appear in the list.

  1. Open the RightScale Cloud Management console
  2. In the upper right corner select the account you want to work in,
  3. In the Clouds menu find the region where you created the image and click the Images link
  4. Search for the image

If you have an existing MultiCloud image and want to update the server image in it

  1. In the Design menu select the MultiCloud Images link
  2. Find the existing image by name
  3. Click the name of the image to open it
  4. On the Clouds tab select region, you are working in and click the pencil icon
  5. Click the Edit Image button
  6. Type a part of the name of the new server image you have just created to find it
  7. Click the name of the image to select it
  8. Click the Save button to add it to the MultiCloud image
  9. Click the Update button to save the MultiCloud image

Test the new MultiColud Image

Set the MultiCloud image version in the Server Template

Test the new MultiCloud image by TEMPORARILY using the HEAD revision of the Server Template and the MultiCloud image

To test the new image TEMPORARILY select the HEAD revision of the MultiCloud image to be used by the Server Template

  1. In the Design menu select the ServerTemplates link
  2. Find your Server Template
  3. Click the name of the template to open the info page
  4. Select the HEAD revision of the Server Template
  5. On the Images tab click the pencil to set the revision of the MultiCloud image to use
  6. TEMPORARILY select the HEAD revision for the MultiCloud Image and click the green check mark to save the selection.

In your CAT file set revision 0 to use the HEAD revision of the Server Template

Launch a new server using Self Service with the HEAD revision of the Server Template


Create the new version of the MultiCloud Image

When you have successfully tested the new MultiCloud Image create a new version of it.

  1. Find your MultiCloud Image in Desing, MultiCloud Images
  2. Click the Commit button and enter a description for the change

Create the new version of the Server Template

Save a new version of the Server Template

  1. Find your Server Template in Design, ServerTemplates
  2. Click the Commit button

Publish the Server Template

  1. Select the last revision and click the Publish to MultiCloud Marketplace button
  2. Keep it private
  3. Select the account group to share with and click the DESCRIPTIONS button
  4. Click the PREVIEW button
  5. Click the PUBLISH button

Import the Server Image to the other accounts you use

To be able to use the new version of the Server Image switch to the other accounts and import the template

  1. In the Design menu under MultiCloud Marketplace select the ServerTemplates link
  2. Enter a portion of the Server Template name in the Keyword box and click the GO button
  3. Click the name of the template
  4. Click the Import button

If you want to use a new MultiCloud image in the Server Template

To create a new MultiCloud image

 

Add the new MultiCloud image to the server template

  1. Open the RightScale Cloud Management console
  2. In the Design menu select ServerTemplates
  3. Find your server template
  4. On the Images tab click the Add MultiCloud Image button

windows_task, ArgumentError: invalid date

When the windows_task resource is called to “create” a Windows Scheduled Task that already exists, an error message is returned. In the past, the “modify” action was responsible for the modification of the scheduled tasks, since Chef 13 the “create” action would update the task if exists.

ArgumentError: …[…] (…:… line …) had an error: ArgumentError: windows_task[…] (… line …) had an error: ArgumentError: invalid date

C:/opscode/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4-universal-mingw32/lib/chef/provider/windows_task.rb:507:in `strptime’
C:/opscode/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4-universal-mingw32/lib/chef/provider/windows_task.rb:507:in `parse_day’
C:/opscode/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4-universal-mingw32/lib/chef/provider/windows_task.rb:239:in `convert_user_date_to_system_date’
C:/opscode/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4-universal-mingw32/lib/chef/provider/windows_task.rb:99:in `action_create’

It looks like Chef tries to get a date from the existing scheduled task, and cannot parse it successfully.

As we currently cannot update existing tasks, we need to put a guard into the windows_task resource to prevent the execution if the task exists.

 
startup_task_name = 'chef-client-at_startup'

windows_task "create #{startup_task_name}" do
  task_name "#{startup_task_name}"
  ...
  guard_interpreter :powershell_script
  only_if "(Get-ScheduledTask | Where-Object {$_.TaskName -eq "#{startup_task_name}"}).TaskName.Length -eq 0"
end

.NET Framework Detection in the Windows Registry

To determine which .NET framework is installed on the Windows computer check the values in the registry.

The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full key contains two values you can check:

  • Release
  • Version

You can use InSpec, part of the Chef DK, to check the values:

describe registry_key('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full') do
  it { should have_property 'Release' }
  it { should have_property_value('Release', :dword, 460805) } # For dword use the decimal value, no quotes
end

describe registry_key('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full') do
  it { should have_property 'Version' }
  it { should have_property_value('Version', :string, '4.7.02053') }
end
.NET version Release hexadecimal Release decimal Version
4.6.2 60636 394806 4.6.01590
4.7 70805 460805 4.7.02053
4.7.1 709FE 461310 4.7.02558

For more information see

https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed

 

Chef exit codes

Chef uses the standard RFC 062 exit codes.

In your .kitchen.yml file, you can supply an array of exit codes in the “retry_on_exit_code” option to retry the operation in case the Chef script execution is interrupted. The usual values are

 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

Chef exit codes

  0: SUCCESS            - Successful run     - Any successful execution of a Chef utility should return this exit code
  1: GENERIC_FAILURE    - Failed execution   - Generic error during Chef execution.
  2: SIGINT_RECEIVED    - SIGINT received    - Received an interrupt signal
  3: SIGTERM_RECEIVED   - SIGTERM received   - Received an terminate signal
 35: REBOOT_SCHEDULED   - Reboot Scheduled   - Reboot has been scheduled in the run state
 37: REBOOT_NEEDED      - Reboot Needed      - Reboot needs to be completed
 41: REBOOT_FAILED      - Reboot Failed      - Initiated Reboot failed - due to permissions or any other reason
 42: AUDIT_MODE_FAILURE - Audit Mode Failure - Audit mode failed, but chef converged successfully.
213: CLIENT_UPGRADED    - Chef upgrade       - Chef has exited during a client upgrade

Relevant Windows exit codes

 20: ERROR_BAD_UNIT     - The system cannot find the device specified.

The list of all Windows error codes is located at https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

The Linux exit codes for

FATAL: Chef::Exceptions::Reboot: Rebooting server at a recipe’s request.

When your Chef recipe requests a reboot using the “reboot” Chef resource, the output window shows an error message:

Chef Client finished, …/… resources updated in … seconds
[…] WARN: Rebooting server at a recipe’s request. Details: {:delay_mins=>1, :reason=>”…”, :timestamp=>…, :requested_by=>”…”}

Running handlers:
[…] ERROR: Running exception handlers
Running handlers complete
[…] ERROR: Exception handlers complete
Chef Client failed. … resources updated in … seconds
[…] FATAL: Stacktrace dumped to C:/Users/…/AppData/Local/Temp/kitchen/cache/chef-stacktrace.out
[…] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[…] FATAL: Chef::Exceptions::Reboot: Rebooting server at a recipe’s request. Details: {:delay_mins=>1, :reason=>”…”, :timestamp=>…, :requested_by=>”…”}

Chef also saves the error message in the stacktrace.out file at C:/Users/…/AppData/Local/Temp/kitchen/cache

As coderanger wrote it, replying to a StackOverflow post, it is not an error, it is a necessity to be able to stop the Chef cookbook execution when a reboot is requested. See https://stackoverflow.com/questions/39057254/why-does-chef-throw-fatal-error-on-restart-request

“Because we want to avoid running anything further in the Chef converge and the easiest way to do that is to raise an exception.”

“It’s a weird special case because Ruby doesn’t have any other non-local code execution flow construct that would work well in this case. You’ll just have to add a filter for it. Such are the realities of building software in an imperfect world :) – coderanger Aug 21 ’16 at 5:24″

 

 

Unable to satisfy constraints on package

When you make a change to the version restrictions in the metadata.rb file and execute berks install in your Chef cookbook directory, you may get the error message:

Unable to satisfy constraints on package … due to solution constraint (…). Solution constraints that may result in a constraint on …: [(…)], [(…) -> (…)]
Demand that cannot be met: (…)
Artifacts for which there are conflicting dependencies: … = … -> [(…), (… ~> …)]Unable to find a solution for demands:…

 

Execute

berks update

to

  • find the latest allowed versions of all referenced cookbooks,
  • update the Berksfile.lock file and
  • download the missing cookbooks to the cookbook cache folder at ~/.berkshelf/cookbooks
  • This command executes berks install too behind the scenes.

 

 

amazon-ebs: Error waiting for SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

When you launch a Linux AWS EC2 instance with Terraform or create a Linux AWS image with Packer, one of the following errors are displayed:

amazon-ebs: Error waiting for SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

aws_instance.default: 1 error(s) occurred:
* ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Possible causes

Incorrect username

In the Packer template the “ssh_username”, in the Terraform script the “user” attribute contains the username to connect to the instance. It is important to use the correct username for each operating system. For the list of correct usernames for each operating system, see Create a server image with Packer

Wrong SSH key

Make sure you use the correct SSH key to connect to the instance. In the Terraform file, the “key_name”  attribute of the “aws_instance resource” specifies the SSH key to launch the instance with, and the “private_key” attribute of the “connection” contains the key itself as a string.