78a9656906
1. fixed conflation of user-data and cloud-init user-data. Cloud-init user-data is now namespaced as 'cloud-init:user-data'. 2. user-scripts are now fetched from the meta-data service each boot and executed as in the scripts directory 3. datacenter name is now namespaced as sdc:datacenter 4. user-scripts should be shebanged if there is no file magic
150 lines
5.5 KiB
ReStructuredText
150 lines
5.5 KiB
ReStructuredText
==================
|
|
SmartOS Datasource
|
|
==================
|
|
|
|
This datasource finds metadata and user-data from the SmartOS virtualization
|
|
platform (i.e. Joyent).
|
|
|
|
Please see http://smartos.org/ for information about SmartOS.
|
|
|
|
SmartOS Platform
|
|
----------------
|
|
The SmartOS virtualization platform uses meta-data to the instance via the
|
|
second serial console. On Linux, this is /dev/ttyS1. The data is a provided
|
|
via a simple protocol: something queries for the data, the console responds
|
|
responds with the status and if "SUCCESS" returns until a single ".\n".
|
|
|
|
New versions of the SmartOS tooling will include support for base64 encoded data.
|
|
|
|
Meta-data channels
|
|
------------------
|
|
|
|
Cloud-init supports three modes of delivering user/meta-data via the flexible
|
|
channels of SmartOS.
|
|
|
|
* user-data is written to /var/db/user-data
|
|
- per the spec, user-data is for consumption by the end-user, not provisioning
|
|
tools
|
|
- cloud-init entirely ignores this channel other than writting it to disk
|
|
- removal of the meta-data key means that /var/db/user-data gets removed
|
|
- a backup of previous meta-data is maintained as /var/db/user-data.<timestamp>
|
|
- <timestamp> is the epoch time when cloud-init ran
|
|
|
|
* user-script is written to /var/lib/cloud/scripts/per-boot/99_user_data
|
|
- this is executed each boot
|
|
- a link is created to /var/db/user-script
|
|
- previous versions of the user-script is written to
|
|
/var/lib/cloud/scripts/per-boot.backup/99_user_script.<timestamp>.
|
|
- <timestamp> is the epoch time when cloud-init ran.
|
|
- when the 'user-script' meta-data key goes missing, the user-script is
|
|
removed from the file system, although a backup is maintained.
|
|
- if the script is not shebanged (i.e. starts with #!<executable>), then
|
|
or is not an executable, cloud-init will add a shebang of "#!/bin/bash"
|
|
|
|
* cloud-init:user-data is treated like on other Clouds.
|
|
- this channel is used for delivering _all_ cloud-init instructions
|
|
- scripts delivered over this channel must be well formed (i.e. must have
|
|
a shebang)
|
|
|
|
Cloud-init supports reading the traditional meta-data fields supported by the
|
|
SmartOS tools. These are:
|
|
* root_authorized_keys
|
|
* hostname
|
|
* enable_motd_sys_info
|
|
* iptables_disable
|
|
|
|
Note: At this time iptables_disable and enable_motd_sys_info are read but
|
|
are not actioned.
|
|
|
|
disabling user-script
|
|
---------------------
|
|
|
|
Cloud-init uses the per-boot script functionality to handle the execution
|
|
of the user-script. If you want to prevent this use a cloud-config of:
|
|
|
|
#cloud-config
|
|
cloud_final_modules:
|
|
- scripts-per-once
|
|
- scripts-per-instance
|
|
- scripts-user
|
|
- ssh-authkey-fingerprints
|
|
- keys-to-console
|
|
- phone-home
|
|
- final-message
|
|
- power-state-change
|
|
|
|
Alternatively you can use the json patch method
|
|
#cloud-config-jsonp
|
|
[
|
|
{ "op": "replace",
|
|
"path": "/cloud_final_modules",
|
|
"value": ["scripts-per-once",
|
|
"scripts-per-instance",
|
|
"scripts-user",
|
|
"ssh-authkey-fingerprints",
|
|
"keys-to-console",
|
|
"phone-home",
|
|
"final-message",
|
|
"power-state-change"]
|
|
}
|
|
]
|
|
|
|
The default cloud-config includes "script-per-boot". Cloud-init will still
|
|
ingest and write the user-data but will not execute it, when you disable
|
|
the per-boot script handling.
|
|
|
|
Note: Unless you have an explicit use-case, it is recommended that you not
|
|
disable the per-boot script execution, especially if you are using
|
|
any of the life-cycle management features of SmartOS.
|
|
|
|
The cloud-config needs to be delivered over the cloud-init:user-data channel
|
|
in order for cloud-init to ingest it.
|
|
|
|
base64
|
|
------
|
|
|
|
The following are exempt from base64 encoding, owing to the fact that they
|
|
are provided by SmartOS:
|
|
* root_authorized_keys
|
|
* enable_motd_sys_info
|
|
* iptables_disable
|
|
* user-data
|
|
* user-script
|
|
|
|
This list can be changed through system config of variable 'no_base64_decode'.
|
|
|
|
This means that user-script and user-data as well as other values can be
|
|
base64 encoded. Since Cloud-init can only guess as to whether or not something
|
|
is truly base64 encoded, the following meta-data keys are hints as to whether
|
|
or not to base64 decode something:
|
|
* base64_all: Except for excluded keys, attempt to base64 decode
|
|
the values. If the value fails to decode properly, it will be
|
|
returned in its text
|
|
* base64_keys: A comma deliminated list of which keys are base64 encoded.
|
|
* b64-<key>:
|
|
for any key, if there exists an entry in the metadata for 'b64-<key>'
|
|
Then 'b64-<key>' is expected to be a plaintext boolean indicating whether
|
|
or not its value is encoded.
|
|
* no_base64_decode: This is a configuration setting
|
|
(i.e. /etc/cloud/cloud.cfg.d) that sets which values should not be
|
|
base64 decoded.
|
|
|
|
disk_aliases and ephemeral disk:
|
|
---------------
|
|
By default, SmartOS only supports a single ephemeral disk. That disk is
|
|
completely empty (un-partitioned with no filesystem).
|
|
|
|
The SmartOS datasource has built-in cloud-config which instructs the
|
|
'disk_setup' module to partition and format the ephemeral disk.
|
|
|
|
You can control the disk_setup then in 2 ways:
|
|
1. through the datasource config, you can change the 'alias' of
|
|
ephermeral0 to reference another device. The default is:
|
|
'disk_aliases': {'ephemeral0': '/dev/vdb'},
|
|
Which means anywhere disk_setup sees a device named 'ephemeral0'
|
|
then /dev/vdb will be substituted.
|
|
2. you can provide disk_setup or fs_setup data in user-data to overwrite
|
|
the datasource's built-in values.
|
|
|
|
See doc/examples/cloud-config-disk-setup.txt for information on disk_setup.
|