Modules¶
Apt Configure¶
Internal name: cc_apt_configure
Apt Pipelining¶
Internal name: cc_apt_pipelining
Bootcmd¶
Internal name: cc_bootcmd
Byobu¶
Internal name: cc_byobu
Ca Certs¶
Internal name: cc_ca_certs
Chef¶
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:
chef:
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
/etc/chef/validation.pem)
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)
chef:
client_key:
environment:
file_backup_path:
file_cache_path:
json_attribs:
log_level:
log_location:
node_name:
pid_file:
server_url:
show_time:
ssl_verify_mode:
validation_cert:
validation_key:
validation_name:
Debug¶
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:
debug:
verbose: (defaulting to true)
output: (location to write output, defaulting to console + log)
Note
Log configurations are not output.
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
Foo¶
Internal name: cc_foo
Growpart¶
Internal name: cc_growpart
Grub Dpkg¶
Internal name: cc_grub_dpkg
Keys To Console¶
Internal name: cc_keys_to_console
Landscape¶
Internal name: cc_landscape
Locale¶
Internal name: cc_locale
Mcollective¶
Internal name: cc_mcollective
Migrator¶
Internal name: cc_migrator
Mounts¶
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
Puppet¶
Internal name: cc_puppet
Resizefs¶
Internal name: cc_resizefs
Resolv Conf¶
Internal name: cc_resolv_conf
Rightscale Userdata¶
Internal name: cc_rightscale_userdata
Rsyslog¶
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: [“. @192.168.1.1”]
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:
- configs:
- “. @@192.158.1.1”
- content: “. @@192.0.2.1:10514” filename: 01-example.conf
- content: | . @@syslogd.example.com
- remotes:
- maas: “192.168.1.1” juju: “10.0.4.1”
config_dir: config_dir config_filename: config_filename service_reload_command: [your, syslog, restart, command]
- Example Legacy config:
#cloud-config rsyslog:
- “. @@192.158.1.1”
rsyslog_dir: /etc/rsyslog-config.d/ rsyslog_filename: 99-local.conf
Runcmd¶
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
Ssh¶
Internal name: cc_ssh
Ssh Authkey Fingerprints¶
Internal name: cc_ssh_authkey_fingerprints
Ssh Import Id¶
Internal name: cc_ssh_import_id
Timezone¶
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:
init_switch:
target: systemd (can be 'systemd' or 'upstart')
reboot: true (reboot if a change was made, or false to not reboot)
Note
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.
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