diff options
Diffstat (limited to 'doc/sources')
| -rw-r--r-- | doc/sources/altcloud/README.rst | 87 | ||||
| -rw-r--r-- | doc/sources/azure/README.rst | 134 | ||||
| -rw-r--r-- | doc/sources/cloudsigma/README.rst | 38 | ||||
| -rw-r--r-- | doc/sources/cloudstack/README.rst | 29 | ||||
| -rw-r--r-- | doc/sources/configdrive/README.rst | 123 | ||||
| -rw-r--r-- | doc/sources/digitalocean/README.rst | 21 | ||||
| -rw-r--r-- | doc/sources/kernel-cmdline.txt | 48 | ||||
| -rw-r--r-- | doc/sources/nocloud/README.rst | 71 | ||||
| -rw-r--r-- | doc/sources/opennebula/README.rst | 142 | ||||
| -rw-r--r-- | doc/sources/openstack/README.rst | 24 | ||||
| -rw-r--r-- | doc/sources/ovf/README | 83 | ||||
| -rw-r--r-- | doc/sources/ovf/example/ovf-env.xml | 46 | ||||
| -rw-r--r-- | doc/sources/ovf/example/ubuntu-server.ovf | 130 | ||||
| -rwxr-xr-x | doc/sources/ovf/make-iso | 156 | ||||
| -rw-r--r-- | doc/sources/ovf/ovf-env.xml.tmpl | 28 | ||||
| -rw-r--r-- | doc/sources/ovf/ovfdemo.pem | 27 | ||||
| -rw-r--r-- | doc/sources/ovf/user-data | 7 | ||||
| -rw-r--r-- | doc/sources/smartos/README.rst | 149 |
18 files changed, 0 insertions, 1343 deletions
diff --git a/doc/sources/altcloud/README.rst b/doc/sources/altcloud/README.rst deleted file mode 100644 index b5d72ebb..00000000 --- a/doc/sources/altcloud/README.rst +++ /dev/null @@ -1,87 +0,0 @@ -The datasource altcloud will be used to pick up user data on `RHEVm`_ and `vSphere`_. - -RHEVm -~~~~~~ - -For `RHEVm`_ v3.0 the userdata is injected into the VM using floppy -injection via the `RHEVm`_ dashboard "Custom Properties". - -The format of the Custom Properties entry must be: - -:: - - floppyinject=user-data.txt:<base64 encoded data> - -For example to pass a simple bash script: - -:: - - % cat simple_script.bash - #!/bin/bash - echo "Hello Joe!" >> /tmp/JJV_Joe_out.txt - - % base64 < simple_script.bash - IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8gSm9lISIgPj4gL3RtcC9KSlZfSm9lX291dC50eHQK - -To pass this example script to cloud-init running in a `RHEVm`_ v3.0 VM -set the "Custom Properties" when creating the RHEMv v3.0 VM to: - -:: - - floppyinject=user-data.txt:IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8gSm9lISIgPj4gL3RtcC9KSlZfSm9lX291dC50eHQK - -**NOTE:** The prefix with file name must be: ``floppyinject=user-data.txt:`` - -It is also possible to launch a `RHEVm`_ v3.0 VM and pass optional user -data to it using the Delta Cloud. - -For more information on Delta Cloud see: http://deltacloud.apache.org - -vSphere -~~~~~~~~ - -For VMWare's `vSphere`_ the userdata is injected into the VM as an ISO -via the cdrom. This can be done using the `vSphere`_ dashboard -by connecting an ISO image to the CD/DVD drive. - -To pass this example script to cloud-init running in a `vSphere`_ VM -set the CD/DVD drive when creating the vSphere VM to point to an -ISO on the data store. - -**Note:** The ISO must contain the user data. - -For example, to pass the same ``simple_script.bash`` to vSphere: - -Create the ISO ------------------ - -:: - - % mkdir my-iso - -NOTE: The file name on the ISO must be: ``user-data.txt`` - -:: - - % cp simple_scirpt.bash my-iso/user-data.txt - % genisoimage -o user-data.iso -r my-iso - -Verify the ISO ------------------ - -:: - - % sudo mkdir /media/vsphere_iso - % sudo mount -o loop JoeV_CI_02.iso /media/vsphere_iso - % cat /media/vsphere_iso/user-data.txt - % sudo umount /media/vsphere_iso - -Then, launch the `vSphere`_ VM the ISO user-data.iso attached as a CDROM. - -It is also possible to launch a `vSphere`_ VM and pass optional user -data to it using the Delta Cloud. - -For more information on Delta Cloud see: http://deltacloud.apache.org - -.. _RHEVm: https://www.redhat.com/virtualization/rhev/desktop/rhevm/ -.. _vSphere: https://www.vmware.com/products/datacenter-virtualization/vsphere/overview.html diff --git a/doc/sources/azure/README.rst b/doc/sources/azure/README.rst deleted file mode 100644 index 8239d1fa..00000000 --- a/doc/sources/azure/README.rst +++ /dev/null @@ -1,134 +0,0 @@ -================ -Azure Datasource -================ - -This datasource finds metadata and user-data from the Azure cloud platform. - -Azure Platform --------------- -The azure cloud-platform provides initial data to an instance via an attached -CD formated in UDF. That CD contains a 'ovf-env.xml' file that provides some -information. Additional information is obtained via interaction with the -"endpoint". The ip address of the endpoint is advertised to the instance -inside of dhcp option 245. On ubuntu, that can be seen in -/var/lib/dhcp/dhclient.eth0.leases as a colon delimited hex value (example: -``option unknown-245 64:41:60:82;`` is 100.65.96.130) - -walinuxagent ------------- -In order to operate correctly, cloud-init needs walinuxagent to provide much -of the interaction with azure. In addition to "provisioning" code, walinux -does the following on the agent is a long running daemon that handles the -following things: -- generate a x509 certificate and send that to the endpoint - -waagent.conf config -~~~~~~~~~~~~~~~~~~~ -in order to use waagent.conf with cloud-init, the following settings are recommended. Other values can be changed or set to the defaults. - - :: - - # disabling provisioning turns off all 'Provisioning.*' function - Provisioning.Enabled=n - # this is currently not handled by cloud-init, so let walinuxagent do it. - ResourceDisk.Format=y - ResourceDisk.MountPoint=/mnt - - -Userdata --------- -Userdata is provided to cloud-init inside the ovf-env.xml file. Cloud-init -expects that user-data will be provided as base64 encoded value inside the -text child of a element named ``UserData`` or ``CustomData`` which is a direct -child of the ``LinuxProvisioningConfigurationSet`` (a sibling to ``UserName``) -If both ``UserData`` and ``CustomData`` are provided behavior is undefined on -which will be selected. - -In the example below, user-data provided is 'this is my userdata', and the -datasource config provided is ``{"agent_command": ["start", "walinuxagent"]}``. -That agent command will take affect as if it were specified in system config. - -Example: - -.. code:: - - <wa:ProvisioningSection> - <wa:Version>1.0</wa:Version> - <LinuxProvisioningConfigurationSet - xmlns="http://schemas.microsoft.com/windowsazure" - xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> - <ConfigurationSetType>LinuxProvisioningConfiguration</ConfigurationSetType> - <HostName>myHost</HostName> - <UserName>myuser</UserName> - <UserPassword/> - <CustomData>dGhpcyBpcyBteSB1c2VyZGF0YQ===</CustomData> - <dscfg>eyJhZ2VudF9jb21tYW5kIjogWyJzdGFydCIsICJ3YWxpbnV4YWdlbnQiXX0=</dscfg> - <DisableSshPasswordAuthentication>true</DisableSshPasswordAuthentication> - <SSH> - <PublicKeys> - <PublicKey> - <Fingerprint>6BE7A7C3C8A8F4B123CCA5D0C2F1BE4CA7B63ED7</Fingerprint> - <Path>this-value-unused</Path> - </PublicKey> - </PublicKeys> - </SSH> - </LinuxProvisioningConfigurationSet> - </wa:ProvisioningSection> - -Configuration -------------- -Configuration for the datasource can be read from the system config's or set -via the `dscfg` entry in the `LinuxProvisioningConfigurationSet`. Content in -dscfg node is expected to be base64 encoded yaml content, and it will be -merged into the 'datasource: Azure' entry. - -The '``hostname_bounce: command``' entry can be either the literal string -'builtin' or a command to execute. The command will be invoked after the -hostname is set, and will have the 'interface' in its environment. If -``set_hostname`` is not true, then ``hostname_bounce`` will be ignored. - -An example might be: - command: ["sh", "-c", "killall dhclient; dhclient $interface"] - -.. code:: - - datasource: - agent_command - Azure: - agent_command: [service, walinuxagent, start] - set_hostname: True - hostname_bounce: - # the name of the interface to bounce - interface: eth0 - # policy can be 'on', 'off' or 'force' - policy: on - # the method 'bounce' command. - command: "builtin" - hostname_command: "hostname" - } - -hostname --------- -When the user launches an instance, they provide a hostname for that instance. -The hostname is provided to the instance in the ovf-env.xml file as -``HostName``. - -Whatever value the instance provides in its dhcp request will resolve in the -domain returned in the 'search' request. - -The interesting issue is that a generic image will already have a hostname -configured. The ubuntu cloud images have 'ubuntu' as the hostname of the -system, and the initial dhcp request on eth0 is not guaranteed to occur after -the datasource code has been run. So, on first boot, that initial value will -be sent in the dhcp request and *that* value will resolve. - -In order to make the ``HostName`` provided in the ovf-env.xml resolve, a -dhcp request must be made with the new value. Walinuxagent (in its current -version) handles this by polling the state of hostname and bouncing ('``ifdown -eth0; ifup eth0``' the network interface if it sees that a change has been -made. - -cloud-init handles this by setting the hostname in the DataSource's 'get_data' -method via '``hostname $HostName``', and then bouncing the interface. This -behavior can be configured or disabled in the datasource config. See -'Configuration' above. diff --git a/doc/sources/cloudsigma/README.rst b/doc/sources/cloudsigma/README.rst deleted file mode 100644 index 6509b585..00000000 --- a/doc/sources/cloudsigma/README.rst +++ /dev/null @@ -1,38 +0,0 @@ -===================== -CloudSigma Datasource -===================== - -This datasource finds metadata and user-data from the `CloudSigma`_ cloud platform. -Data transfer occurs through a virtual serial port of the `CloudSigma`_'s VM and the -presence of network adapter is **NOT** a requirement, - - See `server context`_ in the public documentation for more information. - - -Setting a hostname -~~~~~~~~~~~~~~~~~~ - -By default the name of the server will be applied as a hostname on the first boot. - - -Providing user-data -~~~~~~~~~~~~~~~~~~~ - -You can provide user-data to the VM using the dedicated `meta field`_ in the `server context`_ -``cloudinit-user-data``. By default *cloud-config* format is expected there and the ``#cloud-config`` -header could be omitted. However since this is a raw-text field you could provide any of the valid -`config formats`_. - -You have the option to encode your user-data using Base64. In order to do that you have to add the -``cloudinit-user-data`` field to the ``base64_fields``. The latter is a comma-separated field with -all the meta fields whit base64 encoded values. - -If your user-data does not need an internet connection you can create a -`meta field`_ in the `server context`_ ``cloudinit-dsmode`` and set "local" as value. -If this field does not exist the default value is "net". - - -.. _CloudSigma: http://cloudsigma.com/ -.. _server context: http://cloudsigma-docs.readthedocs.org/en/latest/server_context.html -.. _meta field: http://cloudsigma-docs.readthedocs.org/en/latest/meta.html -.. _config formats: http://cloudinit.readthedocs.org/en/latest/topics/format.html diff --git a/doc/sources/cloudstack/README.rst b/doc/sources/cloudstack/README.rst deleted file mode 100644 index eba1cd7e..00000000 --- a/doc/sources/cloudstack/README.rst +++ /dev/null @@ -1,29 +0,0 @@ -`Apache CloudStack`_ expose user-data, meta-data, user password and account -sshkey thru the Virtual-Router. For more details on meta-data and user-data, -refer the `CloudStack Administrator Guide`_. - -URLs to access user-data and meta-data from the Virtual Machine. Here 10.1.1.1 -is the Virtual Router IP: - -.. code:: bash - - http://10.1.1.1/latest/user-data - http://10.1.1.1/latest/meta-data - http://10.1.1.1/latest/meta-data/{metadata type} - -Configuration -~~~~~~~~~~~~~ - -Apache CloudStack datasource can be configured as follows: - -.. code:: yaml - - datasource: - CloudStack: {} - None: {} - datasource_list: - - CloudStack - - -.. _Apache CloudStack: http://cloudstack.apache.org/ -.. _CloudStack Administrator Guide: http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/virtual_machines.html#user-data-and-meta-data
\ No newline at end of file diff --git a/doc/sources/configdrive/README.rst b/doc/sources/configdrive/README.rst deleted file mode 100644 index 48ff579d..00000000 --- a/doc/sources/configdrive/README.rst +++ /dev/null @@ -1,123 +0,0 @@ -The configuration drive datasource supports the `OpenStack`_ configuration drive disk. - - See `the config drive extension`_ and `introduction`_ in the public - documentation for more information. - -By default, cloud-init does *always* consider this source to be a full-fledged -datasource. Instead, the typical behavior is to assume it is really only -present to provide networking information. Cloud-init will copy off the -network information, apply it to the system, and then continue on. The -"full" datasource could then be found in the EC2 metadata service. If this is -not the case then the files contained on the located drive must provide equivalents -to what the EC2 metadata service would provide (which is typical of the version -2 support listed below) - -Version 1 -~~~~~~~~~ - -The following criteria are required to as a config drive: - -1. Must be formatted with `vfat`_ filesystem -2. Must be a un-partitioned block device (/dev/vdb, not /dev/vdb1) -3. Must contain *one* of the following files - -:: - - /etc/network/interfaces - /root/.ssh/authorized_keys - /meta.js - -``/etc/network/interfaces`` - - This file is laid down by nova in order to pass static networking - information to the guest. Cloud-init will copy it off of the config-drive - and into /etc/network/interfaces (or convert it to RH format) as soon as it can, - and then attempt to bring up all network interfaces. - -``/root/.ssh/authorized_keys`` - - This file is laid down by nova, and contains the ssk keys that were - provided to nova on instance creation (nova-boot --key ....) - -``/meta.js`` - - meta.js is populated on the config-drive in response to the user passing - "meta flags" (nova boot --meta key=value ...). It is expected to be json - formatted. - -Version 2 -~~~~~~~~~~~ - -The following criteria are required to as a config drive: - -1. Must be formatted with `vfat`_ or `iso9660`_ filesystem - or have a *filesystem* label of **config-2** -2. Must be a un-partitioned block device (/dev/vdb, not /dev/vdb1) -3. The files that will typically be present in the config drive are: - -:: - - openstack/ - - 2012-08-10/ or latest/ - - meta_data.json - - user_data (not mandatory) - - content/ - - 0000 (referenced content files) - - 0001 - - .... - ec2 - - latest/ - - meta-data.json (not mandatory) - -Keys and values -~~~~~~~~~~~ - -Cloud-init's behavior can be modified by keys found in the meta.js (version 1 only) file in the following ways. - -:: - - dsmode: - values: local, net, pass - default: pass - - -This is what indicates if configdrive is a final data source or not. -By default it is 'pass', meaning this datasource should not be read. -Set it to 'local' or 'net' to stop cloud-init from continuing on to -search for other data sources after network config. - -The difference between 'local' and 'net' is that local will not require -networking to be up before user-data actions (or boothooks) are run. - -:: - - instance-id: - default: iid-dsconfigdrive - -This is utilized as the metadata's instance-id. It should generally -be unique, as it is what is used to determine "is this a new instance". - -:: - - public-keys: - default: None - -If present, these keys will be used as the public keys for the -instance. This value overrides the content in authorized_keys. - -Note: it is likely preferable to provide keys via user-data - -:: - - user-data: - default: None - -This provides cloud-init user-data. See :ref:`examples <yaml_examples>` for -what all can be present here. - -.. _OpenStack: http://www.openstack.org/ -.. _introduction: http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html -.. _python-novaclient: https://github.com/openstack/python-novaclient -.. _iso9660: https://en.wikipedia.org/wiki/ISO_9660 -.. _vfat: https://en.wikipedia.org/wiki/File_Allocation_Table -.. _the config drive extension: http://docs.openstack.org/user-guide/content/config-drive.html diff --git a/doc/sources/digitalocean/README.rst b/doc/sources/digitalocean/README.rst deleted file mode 100644 index 1bb89fe1..00000000 --- a/doc/sources/digitalocean/README.rst +++ /dev/null @@ -1,21 +0,0 @@ - The `DigitalOcean`_ datasource consumes the content served from DigitalOcean's `metadata service`_. This -metadata service serves information about the running droplet via HTTP over the link local address -169.254.169.254. The metadata API endpoints are fully described at -`https://developers.digitalocean.com/metadata/ <https://developers.digitalocean.com/metadata/>`_. - -Configuration -~~~~~~~~~~~~~ - -DigitalOcean's datasource can be configured as follows: - - datasource: - DigitalOcean: - retries: 3 - timeout: 2 - -- *retries*: Determines the number of times to attempt to connect to the metadata service -- *timeout*: Determines the timeout in seconds to wait for a response from the metadata service - -.. _DigitalOcean: http://digitalocean.com/ -.. _metadata service: https://developers.digitalocean.com/metadata/ -.. _Full documentation: https://developers.digitalocean.com/metadata/ diff --git a/doc/sources/kernel-cmdline.txt b/doc/sources/kernel-cmdline.txt deleted file mode 100644 index 0b77a9af..00000000 --- a/doc/sources/kernel-cmdline.txt +++ /dev/null @@ -1,48 +0,0 @@ -In order to allow an ephemeral, or otherwise pristine image to -receive some configuration, cloud-init will read a url directed by -the kernel command line and proceed as if its data had previously existed. - -This allows for configuring a meta-data service, or some other data. - -Note, that usage of the kernel command line is somewhat of a last resort, -as it requires knowing in advance the correct command line or modifying -the boot loader to append data. - -For example, when 'cloud-init start' runs, it will check to -see if if one of 'cloud-config-url' or 'url' appear in key/value fashion -in the kernel command line as in: - root=/dev/sda ro url=http://foo.bar.zee/abcde - -Cloud-init will then read the contents of the given url. -If the content starts with '#cloud-config', it will store -that data to the local filesystem in a static filename -'/etc/cloud/cloud.cfg.d/91_kernel_cmdline_url.cfg', and consider it as -part of the config from that point forward. - -If that file exists already, it will not be overwritten, and the url parameters -completely ignored. - -Then, when the DataSource runs, it will find that config already available. - -So, in able to configure the MAAS DataSource by controlling the kernel -command line from outside the image, you can append: - url=http://your.url.here/abcdefg -or - cloud-config-url=http://your.url.here/abcdefg - -Then, have the following content at that url: - #cloud-config - datasource: - MAAS: - metadata_url: http://mass-host.localdomain/source - consumer_key: Xh234sdkljf - token_key: kjfhgb3n - token_secret: 24uysdfx1w4 - -Notes: - * Because 'url=' is so very generic, in order to avoid false positives, - cloud-init requires the content to start with '#cloud-config' in order - for it to be considered. - * The url= is un-authed http GET, and contains credentials - It could be set up to be randomly generated and also check source - address in order to be more secure diff --git a/doc/sources/nocloud/README.rst b/doc/sources/nocloud/README.rst deleted file mode 100644 index 08a39377..00000000 --- a/doc/sources/nocloud/README.rst +++ /dev/null @@ -1,71 +0,0 @@ -The data source ``NoCloud`` and ``NoCloudNet`` allow the user to provide user-data -and meta-data to the instance without running a network service (or even without -having a network at all). - -You can provide meta-data and user-data to a local vm boot via files on a `vfat`_ -or `iso9660`_ filesystem. The filesystem volume label must be ``cidata``. - -These user-data and meta-data files are expected to be -in the following format. - -:: - - /user-data - /meta-data - -Basically, user-data is simply user-data and meta-data is a yaml formatted file -representing what you'd find in the EC2 metadata service. - -Given a disk ubuntu 12.04 cloud image in 'disk.img', you can create a sufficient disk -by following the example below. - -:: - - ## create user-data and meta-data files that will be used - ## to modify image on first boot - $ { echo instance-id: iid-local01; echo local-hostname: cloudimg; } > meta-data - - $ printf "#cloud-config\npassword: passw0rd\nchpasswd: { expire: False }\nssh_pwauth: True\n" > user-data - - ## create a disk to attach with some user-data and meta-data - $ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data - - ## alternatively, create a vfat filesystem with same files - ## $ truncate --size 2M seed.img - ## $ mkfs.vfat -n cidata seed.img - ## $ mcopy -oi seed.img user-data meta-data :: - - ## create a new qcow image to boot, backed by your original image - $ qemu-img create -f qcow2 -b disk.img boot-disk.img - - ## boot the image and login as 'ubuntu' with password 'passw0rd' - ## note, passw0rd was set as password through the user-data above, - ## there is no password set on these images. - $ kvm -m 256 \ - -net nic -net user,hostfwd=tcp::2222-:22 \ - -drive file=boot-disk.img,if=virtio \ - -drive file=seed.iso,if=virtio - -**Note:** that the instance-id provided (``iid-local01`` above) is what is used to -determine if this is "first boot". So if you are making updates to user-data -you will also have to change that, or start the disk fresh. - -Also, you can inject an ``/etc/network/interfaces`` file by providing the content -for that file in the ``network-interfaces`` field of metadata. - -Example metadata: - -:: - - instance-id: iid-abcdefg - network-interfaces: | - iface eth0 inet static - address 192.168.1.10 - network 192.168.1.0 - netmask 255.255.255.0 - broadcast 192.168.1.255 - gateway 192.168.1.254 - hostname: myhost - -.. _iso9660: https://en.wikipedia.org/wiki/ISO_9660 -.. _vfat: https://en.wikipedia.org/wiki/File_Allocation_Table diff --git a/doc/sources/opennebula/README.rst b/doc/sources/opennebula/README.rst deleted file mode 100644 index 4d7de27a..00000000 --- a/doc/sources/opennebula/README.rst +++ /dev/null @@ -1,142 +0,0 @@ -The `OpenNebula`_ (ON) datasource supports the contextualization disk. - - See `contextualization overview`_, `contextualizing VMs`_ and - `network configuration`_ in the public documentation for - more information. - -OpenNebula's virtual machines are contextualized (parametrized) by -CD-ROM image, which contains a shell script *context.sh* with -custom variables defined on virtual machine start. There are no -fixed contextualization variables, but the datasource accepts -many used and recommended across the documentation. - -Datasource configuration -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Datasource accepts following configuration options. - -:: - - dsmode: - values: local, net, disabled - default: net - -Tells if this datasource will be processed in 'local' (pre-networking) or -'net' (post-networking) stage or even completely 'disabled'. - -:: - - parseuser: - default: nobody - -Unprivileged system user used for contextualization script -processing. - -Contextualization disk -~~~~~~~~~~~~~~~~~~~~~~ - -The following criteria are required: - -1. Must be formatted with `iso9660`_ filesystem - or have a *filesystem* label of **CONTEXT** or **CDROM** -2. Must contain file *context.sh* with contextualization variables. - File is generated by OpenNebula, it has a KEY='VALUE' format and - can be easily read by bash - -Contextualization variables -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are no fixed contextualization variables in OpenNebula, no standard. -Following variables were found on various places and revisions of -the OpenNebula documentation. Where multiple similar variables are -specified, only first found is taken. - -:: - - DSMODE - -Datasource mode configuration override. Values: local, net, disabled. - -:: - - DNS - ETH<x>_IP - ETH<x>_NETWORK - ETH<x>_MASK - ETH<x>_GATEWAY - ETH<x>_DOMAIN - ETH<x>_DNS - -Static `network configuration`_. - -:: - - HOSTNAME - -Instance hostname. - -:: - - PUBLIC_IP - IP_PUBLIC - ETH0_IP - -If no hostname has been specified, cloud-init will try to create hostname -from instance's IP address in 'local' dsmode. In 'net' dsmode, cloud-init -tries to resolve one of its IP addresses to get hostname. - -:: - - SSH_KEY - SSH_PUBLIC_KEY - -One or multiple SSH keys (separated by newlines) can be specified. - -:: - - USER_DATA - USERDATA - -cloud-init user data. - -Example configuration -~~~~~~~~~~~~~~~~~~~~~ - -This example cloud-init configuration (*cloud.cfg*) enables -OpenNebula datasource only in 'net' mode. - -:: - - disable_ec2_metadata: True - datasource_list: ['OpenNebula'] - datasource: - OpenNebula: - dsmode: net - parseuser: nobody - -Example VM's context section -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -:: - - CONTEXT=[ - PUBLIC_IP="$NIC[IP]", - SSH_KEY="$USER[SSH_KEY] - $USER[SSH_KEY1] - $USER[SSH_KEY2] ", - USER_DATA="#cloud-config - # see https://help.ubuntu.com/community/CloudInit - - packages: [] - - mounts: - - [vdc,none,swap,sw,0,0] - runcmd: - - echo 'Instance has been configured by cloud-init.' | wall - " ] - -.. _OpenNebula: http://opennebula.org/ -.. _contextualization overview: http://opennebula.org/documentation:documentation:context_overview -.. _contextualizing VMs: http://opennebula.org/documentation:documentation:cong -.. _network configuration: http://opennebula.org/documentation:documentation:cong#network_configuration -.. _iso9660: https://en.wikipedia.org/wiki/ISO_9660 diff --git a/doc/sources/openstack/README.rst b/doc/sources/openstack/README.rst deleted file mode 100644 index 8102597e..00000000 --- a/doc/sources/openstack/README.rst +++ /dev/null @@ -1,24 +0,0 @@ -*TODO* - -Vendor Data -~~~~~~~~~~~ - -The OpenStack metadata server can be configured to serve up vendor data -which is available to all instances for consumption. OpenStack vendor -data is, generally, a JSON object. - -cloud-init will look for configuration in the ``cloud-init`` attribute -of the vendor data JSON object. cloud-init processes this configuration -using the same handlers as user data, so any formats that work for user -data should work for vendor data. - -For example, configuring the following as vendor data in OpenStack would -upgrade packages and install ``htop`` on all instances: - -.. sourcecode:: json - - {"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - htop"} - -For more general information about how cloud-init handles vendor data, -including how it can be disabled by users on instances, see -https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/vendordata.txt diff --git a/doc/sources/ovf/README b/doc/sources/ovf/README deleted file mode 100644 index e3ef12e0..00000000 --- a/doc/sources/ovf/README +++ /dev/null @@ -1,83 +0,0 @@ -This directory contains documentation and a demo of the OVF -functionality that is present in cloud-init. - -The example/ directory contains the following files: - example/ovf-env.xml - This is an example ovf environment file - to make an iso that qualifies for the ISO transport, do: - mkdir my-iso - cp environment.xml my-iso/ovf-env.xml - genisoimage -o transport.iso -r my-iso - Then, boot with that ISO attached as a CDrom -- example/ubuntu-server.ovf - Example generated by virtualbox "export" of a simple VM. - It contains a functional ProductSection also. Given answers - to each of the Properties there, a suitable OVF environment file - (ovf-env.xml) could be created. - -== Demo == -In order to easily demonstrate this functionality, simple demo is -contained here. To boot a local virtual machine in either kvm or virtual -box, follow the steps below. - -- download a suitable Ubuntu image - Visit http://cloud-images.ubuntu.com/releases and download a disk image - of Natty, Oneiric or a newer release. - - $ burl="http://cloud-images.ubuntu.com/releases/" - $ disk="ubuntu-11.10-server-cloudimg-i386-disk1" - $ wget "$burl/11.10/release/$disk.img" -O "$disk.img" - -- If you're going to use virtual box, you will need to convert the image - from qcow2 format into a virtual-box friendly VHD format. - $ qemu-img convert -O vdi "$disk.img" "ubuntu.vdi" - -- If you're using kvm, you should create a qcow delta image to store - the changes so you keep the original pristine. - $ qemu-img create -f qcow2 -b "$disk.img" "ubuntu.qcow2" - - Optionally, you could decompress the image, which will make it boot faster - but will take up more local disk space. - $ qemu-img convert -O qcow2 "$disk.img" "$disk.qcow2" - $ qemu-img create -f qcow2 -b "$disk.qcow2" ubuntu.qcow2 - -- Create an ISO file that will provide user-data to the image. - This will put the contents of 'user-data' into an ovf-env.xml file - and create an ISO file that can then be attached at boot to provide - the user data to cloud-init. - - $ ./make-iso ovf-env.xml.tmpl user-data --output ovftransport.iso - -- Boot your virtual machine - The cloud-images boot with kernel and boot progress to ttyS0. - You can change that at the grub prompt if you'd like by editing the - kernel entry. Otherwise, to see progress you'll need to switch - to the serial console. In kvm graphic mode, you do that by clicking - in the window and then pressing pressing 'ctrl-alt-3'. For information - on how to do that in virtualbox or kvm curses, see the relevant - documentation. - - KVM: - $ kvm -drive file=ubuntu.qcow2,if=virtio -cdrom ovftransport.iso \ - -m 256 -net nic -net user,hostfwd=tcp::2222-:22 - - VirtualBox: - - Launch the GUI and create a new vm with $disk.vdi and ovftransport.iso - attached. - - If you use 'NAT' networking, then forward a port (2222) to the - guests' port 22 to be able to ssh. - - Upon successful boot you will be able to log in as the 'ubuntu' user - with the password 'passw0rd' (which was set in the 'user-data' file). - - You will also be able to ssh to the instance with the provided: - $ chmod 600 ovfdemo.pem - $ ssh -i ovfdemo.pem -p 2222 ubuntu@localhost - -- Notes: - * The 'instance-id' that is set in the ovf-env.xml image needs to - be unique. If you want to run the first-boot code of cloud-init - again you will either have to remove /var/lib/cloud ('rm -Rf' is fine) - or create a new cdrom with a different instance-id. To do the - ladder, simply add the '--instance-id=' flag to the 'make-iso' - command above and start your vm with the new ISO attached. diff --git a/doc/sources/ovf/example/ovf-env.xml b/doc/sources/ovf/example/ovf-env.xml deleted file mode 100644 index 13e8f104..00000000 --- a/doc/sources/ovf/example/ovf-env.xml +++ /dev/null @@ -1,46 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?>
-<Environment xmlns="http://schemas.dmtf.org/ovf/environment/1"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:oe="http://schemas.dmtf.org/ovf/environment/1"
- xsi:schemaLocation="http://schemas.dmtf.org/ovf/environment/1 ../dsp8027.xsd"
- oe:id="WebTier">
-
- <!-- This example reference a local schema file, to validate against online schema use:
- xsi:schemaLocation="http://schemas.dmtf.org/ovf/envelope/1 http://schemas.dmtf.org/ovf/envelope/1/dsp8027_1.0.0.xsd"
- -->
-
- <!-- Information about hypervisor platform -->
- <oe:PlatformSection>
- <Kind>ESX Server</Kind>
- <Version>3.0.1</Version>
- <Vendor>VMware, Inc.</Vendor>
- <Locale>en_US</Locale>
- </oe:PlatformSection>
-
- <!--- Properties defined for this virtual machine -->
- <PropertySection>
- <!-- instance-id is required, a unique instance-id -->
- <Property oe:key="instance-id" oe:value="i-abcdefg"/>
- <!--
- seedfrom is optional, but indicates to 'seed' user-data
- and meta-data the given url. In this example, pull
- http://tinyurl.com/sm-meta-data and http://tinyurl.com/sm-user-data
- -->
- <Property oe:key="seedfrom" oe:value="http://tinyurl.com/sm-"/>
- <!--
- public-keys is a public key to add to users authorized keys
- -->
- <Property oe:key="public-keys" oe:value="ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEWC9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHbiRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJctz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== smoser@brickies"/>
- <!-- hostname: the hostname to set -->
- <Property oe:key="hostname" oe:value="ubuntuhost"/>
- <!--
- The value for user-data is to be base64 encoded.
- it will be decoded, and then processed normally as user-data.
- The following represents '#!/bin/sh\necho "hi world"'
-
- -->
- <Property oe:key="user-data" oe:value="IyEvYmluL3NoCmVjaG8gImhpIHdvcmxkIgo="/>
- <Property oe:key="password" oe:value="passw0rd"/>
- </PropertySection>
-
-</Environment>
diff --git a/doc/sources/ovf/example/ubuntu-server.ovf b/doc/sources/ovf/example/ubuntu-server.ovf deleted file mode 100644 index 846483a1..00000000 --- a/doc/sources/ovf/example/ubuntu-server.ovf +++ /dev/null @@ -1,130 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<Envelope xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> - <References> - <File ovf:href="my.vmdk" ovf:id="file1" ovf:size="2031616"/> - </References> - <DiskSection> - <Info>Virtual disk information</Info> - <Disk ovf:capacity="52428800" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#monolithicSparse"/> - </DiskSection> - <NetworkSection> - <Info>The list of logical networks</Info> - <Network ovf:name="bridged"> - <Description>The bridged network</Description> - </Network> - </NetworkSection> - <VirtualSystem ovf:id="vm"> - <Info>A virtual machine</Info> - <Name>Ubuntu</Name> - <OperatingSystemSection ovf:id="93"> - <Info>11.04 (Natty Narwhal) Server</Info> - </OperatingSystemSection> - <ProductSection> - <Info>Cloud-Init customization</Info> - <Product>11.04 (Natty Narwhal) Server</Product> - <Property ovf:key="instance-id" ovf:type="string" ovf:userConfigurable="true" ovf:value="id-ovf"> - <Label>A Unique Instance ID for this instance</Label> - <Description>Specifies the instance id. This is required and used to determine if the machine should take "first boot" actions</Description> - </Property> - <Property ovf:key="hostname" ovf:type="string" ovf:userConfigurable="true" ovf:value="ubuntuguest"> - <Description>Specifies the hostname for the appliance</Description> - </Property> - <Property ovf:key="seedfrom" ovf:type="string" ovf:userConfigurable="true"> - <Label>Url to seed instance data from</Label> - <Description>This field is optional, but indicates that the instance should 'seed' user-data and meta-data from the given url. If set to 'http://tinyurl.com/sm-' is given, meta-data will be pulled from http://tinyurl.com/sm-meta-data and user-data from http://tinyurl.com/sm-user-data. Leave this empty if you do not want to seed from a url.</Description> - </Property> - <Property ovf:key="public-keys" ovf:type="string" ovf:userConfigurable="true" ovf:value=""> - <Label>ssh public keys</Label> - <Description>This field is optional, but indicates that the instance should populate the default user's 'authorized_keys' with this value</Description> - </Property> - <Property ovf:key="user-data" ovf:type="string" ovf:userConfigurable="true" ovf:value=""> - <Label>Encoded user-data</Label> - <Description>In order to fit into a xml attribute, this value is base64 encoded . It will be decoded, and then processed normally as user-data.</Description> - <!-- The following represents '#!/bin/sh\necho "hi world"' - ovf:value="IyEvYmluL3NoCmVjaG8gImhpIHdvcmxkIgo=" - --> - </Property> - <Property ovf:key="password" ovf:type="string" ovf:userConfigurable="true" ovf:value=""> - <Label>Default User's password</Label> - <Description>If set, the default user's password will be set to this value to allow password based login. The password will be good for only a single login. If set to the string 'RANDOM' then a random password will be generated, and written to the console.</Description> - </Property> - </ProductSection> - <VirtualHardwareSection> - <Info>Virtual hardware requirements</Info> - <System> - <vssd:ElementName>Virtual Hardware Family</vssd:ElementName> - <vssd:InstanceID>0</vssd:InstanceID> - <vssd:VirtualSystemIdentifier>Ubuntu 11.04 (Natty Narwhal) Server</vssd:VirtualSystemIdentifier> - <vssd:VirtualSystemType>vmx-07 qemu-pc qemu-pc-0.13 virtualbox-2.2</vssd:VirtualSystemType> - </System> - <Item> - <rasd:AllocationUnits>hertz * 10^6</rasd:AllocationUnits> - <rasd:Description>Number of Virtual CPUs</rasd:Description> - <rasd:ElementName>1 virtual CPU(s)</rasd:ElementName> - <rasd:InstanceID>1</rasd:InstanceID> - <rasd:ResourceType>3</rasd:ResourceType> - <rasd:VirtualQuantity>1</rasd:VirtualQuantity> - </Item> - <Item> - <rasd:AllocationUnits>byte * 2^20</rasd:AllocationUnits> - <rasd:Description>Memory Size</rasd:Description> - <rasd:ElementName>256MB of memory</rasd:ElementName> - <rasd:InstanceID>2</rasd:InstanceID> - <rasd:ResourceType>4</rasd:ResourceType> - <rasd:VirtualQuantity>256</rasd:VirtualQuantity> - </Item> - <Item ovf:required="false"> - <rasd:Address>0</rasd:Address> - <rasd:Description>USB Controller</rasd:Description> - <rasd:ElementName>usb</rasd:ElementName> - <rasd:InstanceID>3</rasd:InstanceID> - <rasd:ResourceType>23</rasd:ResourceType> - </Item> - <Item> - <rasd:Address>0</rasd:Address> - <rasd:Description>SCSI Controller</rasd:Description> - <rasd:ElementName>scsiController0</rasd:ElementName> - <rasd:InstanceID>4</rasd:InstanceID> - <rasd:ResourceSubType>lsilogic</rasd:ResourceSubType> - <rasd:ResourceType>6</rasd:ResourceType> - </Item> - <Item> - <rasd:Address>1</rasd:Address> - <rasd:Description>IDE Controller</rasd:Description> - <rasd:ElementName>ideController1</rasd:ElementName> - <rasd:InstanceID>5</rasd:InstanceID> - <rasd:ResourceType>5</rasd:ResourceType> - </Item> - <Item ovf:required="false"> - <rasd:AddressOnParent>0</rasd:AddressOnParent> - <rasd:AutomaticAllocation>false</rasd:AutomaticAllocation> - <rasd:ElementName>cdrom1</rasd:ElementName> - <rasd:InstanceID>6</rasd:InstanceID> - <rasd:Parent>5</rasd:Parent> - <rasd:ResourceType>15</rasd:ResourceType> - </Item> - <Item> - <rasd:AddressOnParent>0</rasd:AddressOnParent> - <rasd:ElementName>disk1</rasd:ElementName> - <rasd:HostResource>ovf:/disk/vmdisk1</rasd:HostResource> - <rasd:InstanceID>7</rasd:InstanceID> - <rasd:Parent>4</rasd:Parent> - <rasd:ResourceType>17</rasd:ResourceType> - </Item> - <Item> - <rasd:AddressOnParent>2</rasd:AddressOnParent> - <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation> - <rasd:Connection>bridged</rasd:Connection> - <rasd:Description>ethernet adapter on "bridged"</rasd:Description> - <rasd:ElementName>ethernet0</rasd:ElementName> - <rasd:InstanceID>8</rasd:InstanceID> - <rasd:ResourceSubType>E1000</rasd:ResourceSubType> - <rasd:ResourceType>10</rasd:ResourceType> - </Item> - </VirtualHardwareSection> - <AnnotationSection ovf:required="false"> - <Info>For more information, see http://ubuntu.com</Info> - <Annotation>This is Ubuntu Server.</Annotation> - </AnnotationSection> - </VirtualSystem> -</Envelope> diff --git a/doc/sources/ovf/make-iso b/doc/sources/ovf/make-iso deleted file mode 100755 index 91d0e2e5..00000000 --- a/doc/sources/ovf/make-iso +++ /dev/null @@ -1,156 +0,0 @@ -#!/bin/bash - -VERBOSITY=0 -PROPERTIES=( instance-id hostname user-data seedfrom ) -DEFAULTS=( "i-ovfdemo00" "ovfdemo.localdomain" "" "" ) - -DEF_OUTPUT="ovftransport.iso" -TEMP_D="" - -error() { echo "$@" 1>&2; } -fail() { [ $# -eq 0 ] || error "$@"; exit 1; } - -# propvalue(name, value) -propvalue() { - local prop="" val="$2" i=0 - for prop in "${PROPERTIES[@]}"; do - if [ "$prop" = "$1" ]; then - [ $# -eq 1 ] || DEFAULTS[$i]="$2" - _RET=${DEFAULTS[$i]} - return - fi - i=$(($i+1)) - done - return -} - -Usage() { - cat <<EOF -Usage: ${0##*/} ovf-env.xml.tmpl [user-data-file] - - create an an ovf transport iso with ovf-env.xml.tmpl - as ovf-env.xml on the iso. - - if user-data-file is given, the file's contents will be base64 encoded - and stuffed inside ovf-env.xml. This will override the '--user-data' - argument. - - options: - -o | --output OUTPUT write output to OUTPUT [default: $DEF_OUTPUT] - -v | --verbose increase verbosity - -EOF - local i="" - for i in "${PROPERTIES[@]}"; do - propvalue "$i" - printf "%10s--%-17s%s\n" "" "$i" "set $i. [default: '$_RET']" - done - cat <<EOF - - Example: - $ ${0##*/} --hostname "foobar.mydomain" ovf-env.xml.tmpl user-data - -EOF -} - -bad_Usage() { Usage 1>&2; [ $# -eq 0 ] || error "$@"; exit 1; } -cleanup() { - [ -z "${TEMP_D}" -o ! -d "${TEMP_D}" ] || rm -Rf "${TEMP_D}" -} - -debug() { - local level=${1}; shift; - [ "${level}" -ge "${VERBOSITY}" ] && return - error "${@}" -} - -short_opts="ho:v" -long_opts="help,output:,verbose" -for i in "${PROPERTIES[@]}"; do - long_opts="$long_opts,$i:" -done -getopt_out=$(getopt --name "${0##*/}" \ - --options "${short_opts}" --long "${long_opts}" -- "$@") && - eval set -- "${getopt_out}" || - bad_Usage - -## <<insert default variables here>> -output="${DEF_OUTPUT}" -user_data="" - -while [ $# -ne 0 ]; do - cur=${1}; next=${2}; - case "$cur" in - -h|--help) Usage ; exit 0;; - -o|--output) output=${2}; shift;; - -v|--verbose) VERBOSITY=$((${VERBOSITY}+1));; - --) shift; break;; - --*) - for i in "${PROPERTIES[@]}" _none_; do - [ "${cur#--}" == "$i" ] || continue - [ "$i" != "user-data" ] || - next=$(echo "$next" | base64 --wrap=0) || - fail "failed to base64 encode userdata" - propvalue "$i" "$next" - break - done - [ "$i" = "_none_" ] && bad_Usage "confused by $cur" - ;; - esac - shift; -done - -[ $# -eq 1 -o $# -eq 2 ] || - bad_Usage "wrong number of arguments" - -env_tmpl="$1" -ud_file="$2" - -[ -f "$env_tmpl" ] || bad_Usage "$env_tmpl: not a file" -[ -z "$ud_file" -o -f "$ud_file" ] || - bad_Usage "$ud_file: not a file" - -TEMP_D=$(mktemp -d "${TMPDIR:-/tmp}/${0##*/}.XXXXXX") || - fail "failed to make tempdir" -trap cleanup EXIT - -mkdir "$TEMP_D/iso" && iso_d="$TEMP_D/iso" || - fail "failed to make a tempdir?" -ovf_env="$TEMP_D/iso/ovf-env.xml" - -if [ -n "$ud_file" ]; then - user_data=$(base64 --wrap=0 "$ud_file") || - fail "failed to base64 encode $ud_file. Do you have base64 installed?" - propvalue user-data "$user_data" -fi - -changes=( ) -for i in "${PROPERTIES[@]}"; do - changes[${#changes[@]}]="-e" - propvalue "$i" - changes[${#changes[@]}]="s|@@$i@@|$_RET|g" -done - -sed "${changes[@]}" "$env_tmpl" > "$ovf_env" || - fail "failed to replace string in $env_tmpl" - -if [ "${#changes[@]}" -ne 0 ]; then - cmp "$ovf_env" "$env_tmpl" >/dev/null && - fail "nothing replaced in $ovf_env. template is identical to output" -fi - -debug 1 "creating iso with: genisoimage -o tmp.iso -r iso" -( cd "$TEMP_D" && - genisoimage -V OVF-TRANSPORT -o tmp.iso -r iso 2>/dev/null ) || - fail "failed to create iso. do you have genisoimage?" - -if [ "$output" = "-" ]; then - cat "$TEMP_D/tmp.iso" -else - cp "$TEMP_D/tmp.iso" "$output" || - fail "failed to write to $output" -fi - -error "wrote iso to $output" -exit 0 -# vi: ts=4 noexpandtab diff --git a/doc/sources/ovf/ovf-env.xml.tmpl b/doc/sources/ovf/ovf-env.xml.tmpl deleted file mode 100644 index 8e255d43..00000000 --- a/doc/sources/ovf/ovf-env.xml.tmpl +++ /dev/null @@ -1,28 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?>
-<Environment xmlns="http://schemas.dmtf.org/ovf/environment/1"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:oe="http://schemas.dmtf.org/ovf/environment/1"
- xsi:schemaLocation="http://schemas.dmtf.org/ovf/environment/1 ../dsp8027.xsd"
- oe:id="WebTier">
-
- <!-- This example reference a local schema file, to validate against online schema use:
- xsi:schemaLocation="http://schemas.dmtf.org/ovf/envelope/1 http://schemas.dmtf.org/ovf/envelope/1/dsp8027_1.0.0.xsd"
- -->
-
- <!-- Information about hypervisor platform -->
- <oe:PlatformSection>
- <Kind>ESX Server</Kind>
- <Version>3.0.1</Version>
- <Vendor>VMware, Inc.</Vendor>
- <Locale>en_US</Locale>
- </oe:PlatformSection>
-
- <!--- Properties defined for this virtual machine -->
- <PropertySection>
- <Property oe:key="instance-id" oe:value="@@instance-id@@"/>
- <Property oe:key="hostname" oe:value="@@hostname@@"/>
- <Property oe:key="user-data" oe:value="@@user-data@@"/>
- <Property oe:key="seedfrom" oe:value="@@seedfrom@@"/>
- </PropertySection>
-
-</Environment>
diff --git a/doc/sources/ovf/ovfdemo.pem b/doc/sources/ovf/ovfdemo.pem deleted file mode 100644 index 5bc629c8..00000000 --- a/doc/sources/ovf/ovfdemo.pem +++ /dev/null @@ -1,27 +0,0 @@ ------BEGIN RSA PRIVATE KEY----- -MIIEpAIBAAKCAQEA1Zq/11Rky/uHdbKJewmEtDABGoSjIFyjoY04T5dFYUNwi0B6 -Km7b85Ylqmi/1KmR4Zvi++dj10XnusoWr/Zruv85hHilMZ9GozL2RD6jU/CaI+rB -QkKSaR/CdmEHBbRimq6T2E9chMhJY0jNzeexJSKVR3QeLdbRZ64H7QGTHp7Ulodu -vS9VwAWcpYbGgcM541fboFAiJOLICM1UPH4x5WDkTq/6yeElSmeiE2lHtESHhyMJ -OSDB3YZ5hw1+4bY3sR+0vZ3VQWzpn1Lwg1X3AZA8yf+ZsmMZHhTFeCglsd8jlLHk -Wudh5mJBkCuwPvRQk1gE5gSnTGti0TUqLIrNRwIDAQABAoIBAGZMrdIXxgp3VWHF -9tfpMBgH4Y9stJ98HpXxh2V+4ih53v2iDKAj5c1cPH/HmQ/lgktVmDjikct43El2 -HbV6RBATyd0q1prUWEUy1ATNJvW9hmTrOlFchrg4EK8XOwC9angAYig3oeyp65PU -O1SAwTMyw+GruARmHHYWQA9/MJF5yexrjBw00w7hnCsqjezU5YIYsXwgcz0Zw+Ix -fDJcZFXF9X3Al7H3ZILW3PpfhcVl7WzkL47TIX4oB/ab2kltaTE90SZMXKVcLvTI -6To2xJAnMUyasRfcGmvE8m0SqWqp66POAUDF2I8qu78inKH2u0rNtLQjyx5btF5K -A39bPnkCgYEA8Joba3QFrbd0zPTP/DawRtTXzdIQcNjj4XEefxBN3Cw7MlCsfgDc -xiAR703zqQ/IDkF00XrU5w7rmDga3Pv66JRzFDwvRVtGb6QV+lg7Ypd/6NI1G5AS -0Qzneer2JytEpHoTqGH/vWcXzJRH2BfaPK/vEF4qhAXBqouz2DXn3EUCgYEA40ZU -eDc4MmHOSuqoggSEDJ5NITgPbdkwOta0BmnBZ36M5vgqN8EfAZISKocLNlERDrRG -MpBlQCulq3rpU7WYkx8hGE21f1YBo+vKkffI56ptO2lAp5iLflkSOypdiVN6OELW -5SzkViohDnxKc6eshVycnNoxh6MqE6ugWSd6ahsCgYEA6t0kQwIgwPDCfYfEt2kT -LjF675lNHzs5R8pKgLKDrpcmufjySJXC7UxE9ZrcbX3QRcozpIEI7vwrko3B+1Gm -Hf87TtdpNYTh/vznz1btsVI+NCFuYheDprm4A9UOsDGWchAQvF/dayAFpVhhwVmX -WYJMFWg2jGWqJTb2Oep1CRkCgYEAqzdkk1wmPe5o1w+I+sokIM1xFcGB/iNMrkbp -QJuTVECGLcpvI6mdjjVY8ijiTX0s+ILfD2CwpnM7T8A83w9DbjJZYFHKla9ZdQBB -j024UK6Xs9ZLGvdUv06i6We1J6t3u8K+2c/EBRWf6aXBAPgkhCOM6K2H+sL1A/Sb -zA5trlkCgYArqJCk999mXQuMjNv6UTwzB0iYDjAFNgJdFmPMXlogD51r0HlGeCgD -OEyup4FdIvX1ZYOCkKyieSngmPmY/P4lZBgQbM23FMp+oUkA+FlVW+WNVoXagUrh -abatKtbZ+WZHHmgSoC8sAo5KnxM9O0R6fWlpoIhJTVoihkZYdmnpMg== ------END RSA PRIVATE KEY----- diff --git a/doc/sources/ovf/user-data b/doc/sources/ovf/user-data deleted file mode 100644 index bfac51fd..00000000 --- a/doc/sources/ovf/user-data +++ /dev/null @@ -1,7 +0,0 @@ -#cloud-config -password: passw0rd -chpasswd: { expire: False } -ssh_pwauth: True - -ssh_authorized_keys: - - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVmr/XVGTL+4d1sol7CYS0MAEahKMgXKOhjThPl0VhQ3CLQHoqbtvzliWqaL/UqZHhm+L752PXRee6yhav9mu6/zmEeKUxn0ajMvZEPqNT8Joj6sFCQpJpH8J2YQcFtGKarpPYT1yEyEljSM3N57ElIpVHdB4t1tFnrgftAZMentSWh269L1XABZylhsaBwznjV9ugUCIk4sgIzVQ8fjHlYOROr/rJ4SVKZ6ITaUe0RIeHIwk5IMHdhnmHDX7htjexH7S9ndVBbOmfUvCDVfcBkDzJ/5myYxkeFMV4KCWx3yOUseRa52HmYkGQK7A+9FCTWATmBKdMa2LRNSosis1H ubuntu@ovfdemo diff --git a/doc/sources/smartos/README.rst b/doc/sources/smartos/README.rst deleted file mode 100644 index e63f311f..00000000 --- a/doc/sources/smartos/README.rst +++ /dev/null @@ -1,149 +0,0 @@ -================== -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. |