1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
.. _datasource_smartos:
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:
.. code:: yaml
#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
.. code:: yaml
#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.
.. vi: textwidth=78
|
