Apt Configure

Internal name: cc_apt_configure

Apt Pipelining

Internal name: cc_apt_pipelining


Internal name: cc_bootcmd


Internal name: cc_byobu

Ca Certs

Internal name: cc_ca_certs


Internal name: cc_chef

Summary: module that configures, starts and installs chef.

Description: This module enables chef to be installed (from packages or from gems, or from omnibus). Before this occurs chef configurations are written to disk (validation.pem, client.pem, firstboot.json, client.rb), and needed chef folders/directories are created (/etc/chef and /var/log/chef and so-on). Then once installing proceeds correctly if configured chef will be started (in daemon mode or in non-daemon mode) and then once that has finished (if ran in non-daemon mode this will be when chef finishes converging, if ran in daemon mode then no further actions are possible since chef will have forked into its own process) then a post run function can run that can do finishing activities (such as removing the validation pem file).

It can be configured with the following option structure:

   directories: (defaulting to /etc/chef, /var/log/chef, /var/lib/chef,
                 /var/cache/chef, /var/backups/chef, /var/run/chef)
   validation_cert: (optional string to be written to file validation_key)
                    special value 'system' means set use existing file
   validation_key: (optional the path for validation_cert. default
   firstboot_path: (path to write run_list and initial_attributes keys that
                    should also be present in this configuration, defaults
                    to /etc/chef/firstboot.json)
   exec: boolean to run or not run chef (defaults to false, unless
                                         a gem installed is requested
                                         where this will then default
                                         to true)

chef.rb template keys (if falsey, then will be skipped and not
                       written to /etc/chef/client.rb)

cloudinit.config.cc_chef.handle(name, cfg, cloud, log, _args)[source]

Handler method activated by cloud-init.


Internal name: cc_debug

Summary: helper to debug cloud-init internal datastructures.

Description: This module will enable for outputting various internal information that cloud-init sources provide to either a file or to the output console/log location that this cloud-init has been configured with when running.

It can be configured with the following option structure:

   verbose: (defaulting to true)
   output: (location to write output, defaulting to console + log)


Log configurations are not output.

cloudinit.config.cc_debug.handle(name, cfg, cloud, log, args)[source]

Handler method activated by cloud-init.

Disable Ec2 Metadata

Internal name: cc_disable_ec2_metadata

Disk Setup

Internal name: cc_disk_setup

Emit Upstart

Internal name: cc_emit_upstart

Final Message

Internal name: cc_final_message


Internal name: cc_foo


Internal name: cc_growpart

Grub Dpkg

Internal name: cc_grub_dpkg

Keys To Console

Internal name: cc_keys_to_console


Internal name: cc_landscape


Internal name: cc_locale


Internal name: cc_mcollective


Internal name: cc_migrator


Internal name: cc_mounts

Package Update Upgrade Install

Internal name: cc_package_update_upgrade_install

Phone Home

Internal name: cc_phone_home

Power State Change

Internal name: cc_power_state_change


Internal name: cc_puppet


Internal name: cc_resizefs

Resolv Conf

Internal name: cc_resolv_conf

Rightscale Userdata

Internal name: cc_rightscale_userdata


Internal name: cc_rsyslog

rsyslog module allows configuration of syslog logging via rsyslog Configuration is done under the cloud-config top level ‘rsyslog’.

Under ‘rsyslog’ you can define:
  • configs: [default=[]] this is a list. entries in it are a string or a dictionary. each entry has 2 parts:

    • content
    • filename

    if the entry is a string, then it is assigned to ‘content’. for each entry, content is written to the provided filename. if filename is not provided, its default is read from ‘config_filename’

    Content here can be any valid rsyslog configuration. No format specific format is enforced.

    For simply logging to an existing remote syslog server, via udp:

    configs: [“. @”]

  • remotes: [default={}] This is a dictionary of name / value pairs. In comparison to ‘config’s, it is more focused in that it only supports remote syslog configuration. It is not rsyslog specific, and could convert to other syslog implementations.

    Each entry in remotes is a ‘name’ and a ‘value’.
    • name: an string identifying the entry. good practice would indicate using a consistent and identifiable string for the producer. For example, the MAAS service could use ‘maas’ as the key.

    • value consists of the following parts: * optional filter for log messages

      default if not present: .

      • optional leading ‘@’ or ‘@@’ (indicates udp or tcp respectively). default if not present (udp): @ This is rsyslog format for that. if not present, is ‘@’.
      • ipv4 or ipv6 or hostname ipv6 addresses must be in [::1] format. (@[fd00::1]:514)
      • optional port port defaults to 514
  • config_filename: [default=20-cloud-config.conf] this is the file name to use if none is provided in a config entry.

  • config_dir: [default=/etc/rsyslog.d] this directory is used for filenames that are not absolute paths.

  • service_reload_command: [default=”auto”] this command is executed if files have been written and thus the syslog daemon needs to be told.

Note, since cloud-init 0.5 a legacy version of rsyslog config has been present and is still supported. See below for the mappings between old value and new value:

old value -> new value ‘rsyslog’ -> rsyslog/configs ‘rsyslog_filename’ -> rsyslog/config_filename ‘rsyslog_dir’ -> rsyslog/config_dir

the legacy config does not support ‘service_reload_command’.

Example config:

#cloud-config rsyslog:

  • . @@”
  • content: “. @@” filename: 01-example.conf
  • content: | .
maas: “” juju: “”

config_dir: config_dir config_filename: config_filename service_reload_command: [your, syslog, restart, command]

Example Legacy config:

#cloud-config rsyslog:

  • . @@”

rsyslog_dir: /etc/rsyslog-config.d/ rsyslog_filename: 99-local.conf


Internal name: cc_runcmd

Salt Minion

Internal name: cc_salt_minion

Scripts Per Boot

Internal name: cc_scripts_per_boot

Scripts Per Instance

Internal name: cc_scripts_per_instance

Scripts Per Once

Internal name: cc_scripts_per_once

Scripts User

Internal name: cc_scripts_user

Scripts Vendor

Internal name: cc_scripts_vendor

Seed Random

Internal name: cc_seed_random

Set Hostname

Internal name: cc_set_hostname

Set Passwords

Internal name: cc_set_passwords


Internal name: cc_ssh

Ssh Authkey Fingerprints

Internal name: cc_ssh_authkey_fingerprints

Ssh Import Id

Internal name: cc_ssh_import_id


Internal name: cc_timezone

Ubuntu Init Switch

Internal name: cc_ubuntu_init_switch

Summary: reboot system into another init.

Description: This module provides a way for the user to boot with systemd even if the image is set to boot with upstart. It should be run as one of the first cloud_init_modules, and will switch the init system and then issue a reboot. The next boot will come up in the target init system and no action will be taken.

This should be inert on non-ubuntu systems, and also exit quickly.

It can be configured with the following option structure:

  target: systemd (can be 'systemd' or 'upstart')
  reboot: true (reboot if a change was made, or false to not reboot)


Best effort is made, but it’s possible this system will break, and probably won’t interact well with any other mechanism you’ve used to switch the init system.

cloudinit.config.cc_ubuntu_init_switch.handle(name, cfg, cloud, log, args)[source]

Handler method activated by cloud-init.

Update Etc Hosts

Internal name: cc_update_etc_hosts

Update Hostname

Internal name: cc_update_hostname

Users Groups

Internal name: cc_users_groups

Write Files

Internal name: cc_write_files

Yum Add Repo

Internal name: cc_yum_add_repo