Cloudbase Solutions Wiki

This is an old revision of the document!

---

[] - these are my comments

Short description:

 Given the increasing demand in automated configurations for 
 virtual instances at an early initialization for Windows 
  guests, the open source, Apache 2 licensed project called cloudbase-init 
  has been set out to do just that. Hence, following the 
  logical thread of the cloud-init project, which enables 
  configurations for various Linux distributions, our package 
  release helps configure Windows instances.

What can it do? ⇔ Capabilities The primary capabilities of the package consist of: -creating a user -enabling password injection -configuring static network -setting up a hostname -attaching public keys to the users for their connection to the server; the path at which they are found: C:\Users\Admin\.ssh\authorized-keys -execution of User Data scripts either from the setup[but how can you do that from the setup?] or [?maybe] in the command line, or through a file path specified in the metadata service[ ? or provider].

Which Windows distros can support it? ⇔ Availability

  So far, the Windows distributions that can support its installation 
  are [use bullets]Windows Server 2003 / 2003 R2 / 2008 / 2008 R2 / 2012 
  and Windows 7 and Windows 8. 
  The addresses at which you can get your hand on the installer are: https://www.cloudbase.it/downloads/CloudbaseInitSetup_Beta_x64.msi for the x64 version or https://www.cloudbase.it/downloads/CloudbaseInitSetup_Beta_x86.msi 
  for the x86 version .
  We have available a Windows Server 2012 R2 image on which cloudbase-init 
  is pre-installed. This image can be obtained at this address http://www.cloudbase.it/ws2012r2/ 
  and, after accepting the Microsoft Licence Agreement, one can download 
  the .iso file and the instance is good to boot . In our case, it is meant 
  to work as a hypervisor machine, having HyperV installed, as well. 
  [is the KVM image a Windows, as well?]  

Formats:

  The user data provided with the metadata service should be written in one 
  of these formats, as seen in the userdataplugins directory. 
  Note: there are a few formats which do not have an implementation 
  [?just yet? or this: given the fact that Heat can provide configurations or? 
  file/command execution based on these types, there is no need for 
  their implementation anymore]: cloudboothook, cloudconfig and multipartmixed.
  
  -Gzip Compressed File
      The userdata content is provided in gzip compression format. 
      The given file will be uncompressed and used afterwards in the 
      configuration process. [in the cloud-init we have this as well 
      "This is typically is useful because user-data is limited to 
      ~16384 [1] bytes." Is this true for all userdata?] 

  [-Mime multi-part archive -> translated as what?]   
  
  [PROVIDE EXAMPLES!] 
  
  -Part Handler File
      The part-handler is provided as a mime type "text/part-handler" 
      which will be loaded in a temporary generated file.
      In case the generated part handler file has the list_types() 
      method and the handle_part attribute [in the cloud-init it is a method, 
      as well], the PartHandlerPlugin will provide a dictionary with the
       handled parts for each type returned from the list_types() 
       [each type is a mime].
      [apparently, in the cloud-init handle-type, which I believe is 
      handle-part, is called by cloud-init outside the "plugin"]
      
  -Shell Script File
      Generally used for execution of shell scripts. A temporary file 
      is created and loaded with the user-data, then it is executed and, 
      finally, is erased from the temp directory.
  
  -Heat File
      Saves heat configurations in the "C:\\cfn" directory and executes 
      the corresponding script out of the following: command, bash, python, or powershell. 
      

?Directory layout

./cludbaseinit

  Folder where the cloudbase-init subfolders are located. 
  [Where should it be situated? Program Files?]. Also, init.py 
  is the file containing the main method, configure_host().
  

./cloudbaseinit/metadata

  In this folder are the available services for reading metadata 
  from various providers: HTTP, ConfigDrive, EC2, Maas (and such). 
  [Guess specifying what they're gonna read is in order... assuming 
  users don't know what a metadata is and what it should provide]. 
  Among the information provided are the host name, network configuration, 
  access to the administrator's password and retrieval of the user data 
  executed at early boot.

./cloudbaseinit/openstack/common

  Here we can find the utils that deal with the specifics for remote 
  data transmission, data formats and serialization. Issues that are approached 
  are custom thread creation , event handling, synchronization between 
  machines using rpc and URL retrieval.

./cloudbaseinit/osutils

  System-specific functions can be found in this directory. It aids 
  service enabligs/ disablings, user login, network communication and driver 
  type for proper installations.

./cloudbaseinit/utils/windows

  Here are the tools for accessing OS details, such as physical or 
  virtual disk properties, APIs for crypting and IP rendition [should 
  use other word], network configuration and remote access to resources. 
  The operating system interfaces viewed are POSIX and Windows. 

./cloudbaseinit/plugins [Here I think I'll explain the plugins individually…. except userdataplugins and userdata]

  This directory holds the plugins for custom configurations; 
  for the time being, there is only an implementation for Windows hosts. 
  The plugins which come to our aid are the following:

  createuser.py - creates a user in case he does not exist and 
  attaches a temporary password to the user

  extendvolumes.py - gets the list of volumes which need extending and 
  interogates the disk for available contiguous space. By default all 
  available volumes can be extended. Volumes are specified through a 
  comma separated list of volume indexes, e.g.: "1,2"

  fileexecutils.py - executes the given script according to its type

  licensing.py - plugin which activates Windows automatically

  localscripts.py - scripts are placed in a separate folder and get 
  executed once the plugin is invoked

  mtu.py - helps configure the network interfaces MTU base on the 
  values provided from the DHCP server

  networkconfig.py - configures the network adapter specified in the 
  metadata, rebooting the system if required; in case the network adapter 
  has not been specified, the first available ethernet adapter will be chosen

  ntpclient.py - helps configure the NTP client time synchronization 
  using the NTP servers provided via DHCP

  sethostname.py - takes the hostname from the metadata and truncates 
  it if the string is larger than 15 characters for Netbios compatibility

  setpassword.py - sets the password provided in the configuration. 
  If False or no password is provided a random one will be chosen.

  sshpublickeys.py - sets a user's public key if specified in the metadata

  userdata.py [I've explained some userdata functionality above- what else is there to add?]

  userdatautils.py - executes the userdata scripts according to their types

  winrmcertificateauth.py - plugin which sets the WinRM certificate mapping for the specified user

  winrmlistener.py - enables basic authentication for the WinRM HTTPS listener

./cloudbaseinit/tests [self-explanatory → should they even be specified?]

What is in the Cloud-Init Documentation:

  Datasources (Metadata) 
  ?Merging (something with MIME)

Datasources:

  The use of the two datasource types: metadata and userdata is virtual 
  machine configuration. The metadata is used to set the host name,
  password and configure the network adapters whereas the userdata consists of
  user defined scripts which are specified for execution at the cloudbase-init 
  installation.These scripts may contain regular shell commands, package 
  installation and other custom executions, unrelated to the raw operating 
  system specifications met with[another verb] in the metadata. 
  There are several ways in which you can access these datasources. In the 
  metadata_factory.py file the services are verified consecutively and the 
  first available service will be used