STARTING:

To start it, go to the main contextcubed directory (or where you put the cloudinit file) and type the follow command:
./cloudinit start
To stop, you should use the same command using 'stop' instead of 'start'
./cloudinit stop

CLOUDCONFIG.XML

All the configuration of the system is specified at a file called cloudconfig.xml in the main system root. Here is its description:

user-data-config-file: write here all the specs the user will need to connect to the manager (roles, clustername, contextmanager ...). Note the clustername and the contextmanager tags are mandatory.

context-manager-username: the username to connect to the manager.
context-manager-password: the username password to connect to the manager.

client-root:  user cloud temporary dir (place where the scripts will be downloaded from the context manager)

client-scripts-directories: add here all the directories you want to be retrieved. You should inform only the relative path (/common, /foo). For the roles directory, you should explicit use the name 'roles' for the role directory.(<dir-name> roles <dir-name>)

<optional>
bypass-directories:  add here directories/files which you want not to be retrieved from the manager. For sub-directories use /main-dir/sub-dir (ex: /roles/foo). You can add as many directories you want. Note This also works for files, since you inform the full path of the file (/common/something/foo.txt). Do not use foo/* syntax for directories, simply uses foo/

<optional>
remote-attempts: Number of attempts if any error has occurred when trying to retrieve files from the context manager. Default: 3
sleep-time: Time to wait between the attempts.(should be informed in seconds).  Default: 15

FIRSTBOOTS

If you want a script to be executed only once, you have a option to add the firstboot directory inside any one of the client directories listed on the config.xml file. For example, if you want a firstboot script to be executed inside a client specific role, you just need to create a firstboot directory there and add the script.

Ex: /common/firstboot/S21blabla
    /roles/mysql/firstboot/S77blabla
    /roles/apache/firstboot/S88blabla

Note everything inside a firstboot directory will be considered 'firstboot'. This means you can have subdirectories inside a firstboot directory.

Ex: /roles/mysql/firstboot/S77blabla
    /roles/mysql/firstboot/fix/S44fix_for_something

The control of the firstboot files is registered in a file called firstboot_scripts.yaml .There you will find all the firstboot scripts already executed and the path from where they were. Note you can change the status of a firstboot script from executed to not_executed again. This will allow that firstboot to be executed again on the next boot (This is fully responsability of the client).

Notes:
 - There will be only retrieved from the manager scripts from directories listed on the cloudconfig.xml file. Also will be retrieved only firstboot scripts which were not executed yet.
 - The system will only try to executed scripts which follow the standard specification for run-level scripts (S/K 1-99) like S1execute_me, K99finalize_me. On the startup process will be executed only scripts beginning by S (following their number runlevel order). On the other hand only scripts beginning by K will be executed on the shutdown process.
 - You can find a log for everything which is being retrieved/executed at /var/log/cft/contextcubed/contextcubed.log
 - When downloading larges files from the manager, if something happened which caused the loss of the connection, the system will try to re-connect after a amount of time specified on the cloudconfig.xml file and begin to download from the point which the connection was lost. If after a amount of attempts (also specified on the config.xml file) the system could not reconnect, it will leave the boot process.