CipherSpace Client Wiki - User contributions [en]

FileCabinet Setup

2018-03-02T13:04:59Z

Stoyan:

[[Category:How To‏‎]]
[[Category:UserGuide‏‎]]
This wiki explains the first steps you should take before using FileCabinet.

== Login ==

To access FileCabinet for the first time, you have received an invitation by email, which contains your username and password.

Go to [https://filecabinet.ch FileCabinet.ch]

[[File:fc_1.png|600px|border]]

And enter your username and password. The following screen appears:

[[File:fc_2.png|600px|border]]

Click on the "X" at the top-right of the pop-up window to close it. You will be able to download the desktop apps later on.

== Change Password ==

Click on the "cog wheel" icon [[File:fc_2a.png|25px|border]] at the top-right of the screen and click on "Personal":

[[File:fc_3.png|150px|border]]

The following screen appears:

[[File:fc_3a.png|600px|border]]

Under "Password", enter the password you've received in the "Current password" field, enter your chosen password in the "New password" field (you can click on the "eye" icon to see what you are typing) and click on "Change password". 
'''IMPORTANT:''' your chosen password must be at least ''8 characters long'' and contain at least ''one capital letter, one lower letter and one digit''.

When you have clicked on "Change password", the window will scroll down, to allow you to enter specific app passwords (e.g. for your desktop app). Scroll up and check if your password has been changed correctly. If there is an error, it will show it on the screen.

== Password Recovery ==

In the left menu, click on "Basic encryption module":

[[File:fc_4.png|600px|border]]

You will see the option "Enable password recovery", which is disabled per default.

If you leave this option disabled, '''make sure that you back up your password in a safe place''', because if you lose your password and you have not enabled this option, then when an administrator resets your password, '''you will lose access to all your files stored on FileCabinet.'''

If you enable this option, when an administrator resets your password, you will be able to access your files, but '''you also give an administrator the possibility to access these files as well.'''

So it is your decision wether you want to enable this option or not.

== Two-Factor Authentication ==

We recommend you enable this option, as it adds a second layer to authenticate yourself.

You will need an app on your phone (for instance Google Authenticator) to generate a token, which is then needed to log you in. Look for apps which support the TOTP (Time-based One Time Password) protocol.

Once you have the app on your phone, click on "TOTP second-factor auth":

[[File:fc_7.png|800px|border]]

And check the "Enable TOTP" box. You might get the following screen:

[[File:fc_7a.png|300px|border]]

If you do, enter your password and click on "Confirm".

You will see a screen similar as the following:

[[File:fc_8.png|500px|border]]

Set up your phone app with the information from the screen. Your app will then generate a code. Enter this code in the "Authentication code" field and click on "Verify". You will then see that the "Enable TOTP" box is checked.

Go now on "Second-factor backup codes":

[[File:fc_9.png|400px|border]]

You can use backup codes to allow you to log in instead of using your authenticator app.

Click on "Generate backup codes":

[[File:fc_10.png|400px|border]]

And save or print the generated codes. '''Please make sure you keep those code in a secure place as they can be used instead of code generated by the Second Factor Authenticator application. Also, backup codes are needed in case you no longer have access to the Authenticator application.'''

== App Passwords ==

When you connect an app (e.g. the desktop app) to FileCabinet, you need to enter some credentials in order to log in. If you want to use another password than your own, or if you are using [[#Two-Factor Authentication|two-factor authentication]], you can generate individual passwords for your apps.

[[File:fc_5.png|600px|border]]

Enter the name of your app in the field "App name" and click on "Create new app password". You will see a screen similar as this one:

[[File:fc_6.png|600px|border]]

Copy the new generated password in order to configure your app later on.

FileCabinet Setup

2018-01-03T16:12:38Z

Stoyan:

[[Category:How To‏‎]]
[[Category:UserGuide‏‎]]
This wiki explains the first steps you should take before using FileCabinet.

== Login ==

To access FileCabinet for the first time, you have received an invitation by email, which contains your username and password.

Go to [https://filecabinet.ch FileCabinet.ch]

[[File:fc_1.png|600px|border]]

And enter your username and password. The following screen appears:

[[File:fc_2.png|600px|border]]

Click on the "X" at the top-right of the pop-up window to close it. You will be able to download the desktop apps later on.

== Change Password ==

Click on the "cog wheel" icon [[File:fc_2a.png|25px|border]] at the top-right of the screen and click on "Personal":

[[File:fc_3.png|150px|border]]

The following screen appears:

[[File:fc_3a.png|600px|border]]

Under "Password", enter the password you've received in the "Current password" field, enter your chosen password in the "New password" field (you can click on the "eye" icon to see what you are typing) and click on "Change password". 
'''IMPORTANT:''' your chosen password must be at least ''8 characters long'' and contain at least ''one capital letter, one lower letter and one digit''.

When you have clicked on "Change password", the window will scroll down, to allow you to enter specific app passwords (e.g. for your desktop app). Scroll up and check if your password has been changed correctly. If there is an error, it will show it on the screen.

== Password Recovery ==

In the left menu, click on "Basic encryption module":

[[File:fc_4.png|600px|border]]

You will see the option "Enable password recovery", which is disabled per default.

If you leave this option disabled, '''make sure that you back up your password in a safe place''', because if you lose your password and you have not enabled this option, then when an administrator resets your password, '''you will lose access to all your files stored on FileCabinet.'''

If you enable this option, when an administrator resets your password, you will be able to access your files, but '''you also give an administrator the possibility to access these files as well.'''

So it is your decision wether you want to enable this option or not.

== App Passwords ==

When you connect an app (e.g. the desktop app) to FileCabinet, you need to enter some credentials in order to log in. If you want to use another password than your own, or if you are using [[#Two-Factor Authentication|two-factor authentication]], you can generate individual passwords for your apps.

[[File:fc_5.png|600px|border]]

Enter the name of your app in the field "App name" and click on "Create new app password". You will see a screen similar as this one:

[[File:fc_6.png|600px|border]]

Copy the new generated password in order to configure your app later on.

== Two-Factor Authentication ==

We recommend you enable this option, as it adds a second layer to authenticate yourself.

You will need an app on your phone (for instance Google Authenticator) to generate a token, which is then needed to log you in. Look for apps which support the TOTP (Time-based One Time Password) protocol.

Once you have the app on your phone, click on "TOTP second-factor auth":

[[File:fc_7.png|800px|border]]

And check the "Enable TOTP" box. You might get the following screen:

[[File:fc_7a.png|300px|border]]

If you do, enter your password and click on "Confirm".

You will see a screen similar as the following:

[[File:fc_8.png|500px|border]]

Set up your phone app with the information from the screen. Your app will then generate a code. Enter this code in the "Authentication code" field and click on "Verify". You will then see that the "Enable TOTP" box is checked.

Go now on "Second-factor backup codes":

[[File:fc_9.png|400px|border]]

You can use backup codes to allow you to log in instead of using your authenticator app.

Click on "Generate backup codes":

[[File:fc_10.png|400px|border]]

And save or print the generated codes.

Using PuTTY with SSH Key Pair

2017-08-17T17:19:25Z

Stoyan: Stoyan moved page PuTTY to Using PuTTY with SSH Key Pair without leaving a redirect

[[Category:How To]]
[[Category:CloudInfrastructure]]

== PuTTY ==

PuTTY is an SSH and telnet client, developed originally by Simon Tatham for the Windows platform. PuTTY is open source software that is available with source code and is developed and supported by a group of volunteers.

== Install PuTTY ==

# Go to [https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html this site] and download the MSI (Windows Installer) package for your architecture (32 or 64 bit).
# Run the installer and accept all the default values. You will need administrator rights to install the package.

== Create a SSH Key Pair ==

# Start the program "PuTTYgen" (which was installed with PuTTY previously).
#:[[File:PuTTY_Gen_1.png|500px|border]]
#: 
# Under "Parameters", for "Type of key to generate:" select RSA and in the field "Number of bits in a generated key:" put the value '4096'
#:[[File:PuTTY_Gen_2.png|500px|border]]
#: 
# Under "Actions", click on "Generate",
#:[[File:PuTTY_Gen_3.png|500px|border]]
#: 
#:then move the mouse on the blank area until the green bar is filled.
#:[[File:PuTTY_Gen_4.png|500px|border]]
#: 
#:You should get a similar screen:
#:[[File:PuTTY_Gen_5.png|500px|border]]
#: 
# Add a key passphrase in the fields "Key passphrase:" and "Confirm passphrase:".
#:[[File:PuTTY_Gen_6.png|500px|border]]
#: 
# Click on "Save private key" and give it the name "CipherSpace"
#:[[File:PuTTY_Gen_7.png|500px|border]]
#: 
# Click on "Save public key" and give it the name "CipherSpace.pub".
#:[[File:PuTTY_Gen_8.png|500px|border]]
#: 
# Send the public key ("CipherSpace.pub") to CipherSpace in order to be included in your environment.

== Create a PuTTY session ==

In order to connect to a machine via PuTTY for the first time, you need to create a session.

# Start the program "PuTTY"
#:[[File:PuTTY_Conf_1.png|500px|border]]
#: 
# Go to "Session" and enter the host name (or IP address) and the port of the machine you want to reach. The connection type is "SSH".
#:[[File:PuTTY_Conf_2.png|500px|border]]
#: 
# Optional: Go to "Connection -> Data" and enter the username for the machine you want to connect with.
#:[[File:PuTTY_Conf_3.png|500px|border]]
#: 
# Go to "Connection -> SSH -> Auth", then next to the field "Private key file for authentication:" click on the button "Browse..."
#:[[File:PuTTY_Conf_4.png|500px|border]]
#: 
#:and select the private key "CipherSpace.ppk".
#:[[File:PuTTY_Conf_5.png|500px|border]]
#: 
# Go back to "Session", then under the field "Saved Sessions" enter a name (for instance "CipherSpace VM1") and click on "Save".
#:[[File:PuTTY_Conf_6.png|500px|border]]
#: 
#:You'll be able to load this configuration for a new session.

== Connect with PuTTY ==

# Start the program "PuTTY"
#:[[File:PuTTY_Run_1.png|500px|border]]
#: 
# Go to "Session", then under the field "Saved Sessions" select the session you've created previously and click on "Load"
#:[[File:PuTTY_Run_2.png|500px|border]]
#: 
# Click on "Open"
#:[[File:PuTTY_Run_3.png|500px|border]]
#: 
# If you get the error "Network error: Connection refused",
#:[[File:PuTTY_Run_4.png|300px|border]]
#: 
#:close the window, restart PuTTY and under "Session" check that the hostname and the port are correct.
# The first time you connect to a machine, you will get the following warning:
#:[[File:PuTTY_Run_5.png|500px|border]]
#: 
#:Click on "Yes" to avoid the warning for the next sessions.
# If you get the error "Disconnected: No supported authentication methods available (server sent: publickey)",
#:[[File:PuTTY_Run_6.png|500px|border]]
#: 
#:it means you have forgotten to add your private key under "Connection -> SSH -> Auth" (see the point 4. in [[#Create a PuTTY session|this section]])

Using PuTTY with SSH Key Pair

2017-08-17T17:18:41Z

Stoyan:

CipherSpace Load Balancer

2017-08-02T14:56:08Z

Stoyan: /* HTTP only Variables */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]
== CipherSpace Load Balancer ==

The CipherSpace Load Balancer uses [http://www.haproxy.org/ HAProxy] and its configuration is defined using OpenNebula Contextualization Variables within the appliance's template.

The CipherSpace Load Balancer uses the concept of "sticky sessions", which is a mechanism to route requests from the same source to the same target (if the target is still available).

== How to use the CipherSpace Load Balancer ==

=== Download the Load Balancer from the App Market ===

# Go to "Storage" in the left menu and click on "Apps" in the drop down menu.
#:[[file:lb_1.png|150px|border]]
#:A list with all existing apps will appear.
#:[[file:lb_2.png|700px|border]]
#: 
# Select the CipherSpace Load Balancer and click on the "-> OpenNebula" button.
#:[[file:lb_3.png|700px|border]]
#:A new window will appear.
#:[[file:lb_4.png|700px|border]]
#: 
# You can rename the image ("Name") as well as the VM template name. Then select the datastore which is used for your VMs and click on "Download". A new image as well as a new template will be created.

=== Configure the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the template for the load balancer and click on "Update".
#:[[file:lb_7.png|500px|border]]
#: 
# Click on the "Network" tab
#:[[file:lb_8.png|500px|border]]
#:and select a Virtual Network for your NIC (the same network as the VMs which provide the service you would like to load balance).
#:[[file:lb_9.png|600px|border]]
#: 
#:If clients connect to your load balancer from a different network (Internet for example) you need to add another NIC and attach it to the appropriate Virtual Network.
#:[[file:lb_10.png|600px|border]]
#: 
# Click on the "Context" tab
#:[[file:lb_11.png|500px|border]]
#:and then click on the "Custom vars" section.
#:[[file:lb_12.png|600px|border]]
#: 
# In the "Custom vars" section, click on the "+" button to enter all the necessary contextualization variables and their respective values (see the section [[#Load Balancer Contextualization Variables | Load Balancer Contextualization Variables]]).
#:[[file:lb_13.png|700px|border]]
#: 
# If you have 2 NICs, you should set default gateway by adding the variable <code>GATEWAY_IFACE</code>and assign it with the number of the NIC on which requests from clients are coming. (typically <code>1</code>).
#:<code>GATEWAY_IFACE = 1</code>
#: 
# When you're done, click on "Update" to save your changes.
#:[[file:lb_14.png|700px|border]]
#: 

=== Load Balancer Contextualization Variables ===

==== Basic Configuration ====

In order to understand the contextualization variables, let's use the following example.

You have three web servers and a load balancer attached to the same virtual network. The web servers have the IP addresses <code>10.4.0.11</code>, <code>10.4.0.12</code> and <code>10.4.0.13</code> respectively. They listen to <code>http</code> traffic on port <code>8080</code>. The load balancer listens to <code>http</code> traffic on the port <code>80</code>.

In this example you only have one service (http) which needs to be balanced. 
Every contextualization variable for this service will have a name like <code>SERVICE_0_...</code>. 
If you define more services, each new service variables will start with 
<code>SERVICE_1_</code>, <code>SERVICE_2_</code>, etc..

For this particular example you will define the following variables:

* SERVICE_0_PROTO
* SERVICE_0_LISTEN_PORT
* SERVICE_0_IP_RANGE
* SERVICE_0_BACKEND_PORT

The variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. It should be used for SSL, SSH, SMTP, ...

In our example <code>SERVICE_0_PROTO</code> has the value <code>HTTP</code>

The variable <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening to. 
This variable is '''mandatory'''. If this variable isn't defined, the rest of the service definition will be ignored. 
In our example <code>SERVICE_0_LISTEN_PORT</code> has the value <code>80</code>

The variable <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of the backend servers. This variable is '''mandatory'''. 
In our example <code>SERVICE_X_IP_RANGE</code> has the value <code>10.4.0.11-10.4.0.13</code>

The variable <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the backend servers are listening to. This variable is optional. If this variable isn't defined, the value of the variable <code>SERVICE_X_LISTEN_PORT</code> will be used instead. 
In our example <code>SERVICE_X_BACKEND_PORT</code> has the value <code>8080</code>

So, our example will be configured as follows:

<pre> SERVICE_0_PROTO = HTTP
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.11-10.4.0.13
SERVICE_0_BACKEND_PORT = 8080</pre>
==== Health Checks ====

When you use the load balancer, your backend servers are periodically checked if they are available by accepting periodic TCP connections, to ensure that each server is still alive.

Every 2 seconds, each backend server will be checked and its status will be either Up or Down based on the following rules:

* A server is Up after 2 consecutive successful health checks.
* A server is Down after 3 consecutive unsuccessful health checks.

You can change the number of consecutive successful health checks using the variable <code>SERVICE_X_CHECK_RISE</code> and the number of consecutive unsuccessful health checks using the variable <code>SERVICE_X_CHECK_FALL</code>.

Let's use the example defined in the [[#Basic Configuration|Basic Configuration]] section. If you want to set the number of successful and unsuccessful checks to <code>3</code> and <code>4</code> respectively for your backend servers, you will add the following to your configuration:

<pre>SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
By default, server health check only consist in trying to establish a TCP connection. You can add a complete HTTP request after an established TCP connection by adding the following variable:

<code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>uri</code> <code>}</code>

where <code><uri></code>is the URI referenced in the HTTP requests. 
Responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

==== HTTPS Support ====

To enable HTTPS support, you need to specify the following variables like this:

<pre> SERVICE_X_PROTO = HTTP
SERVICE_X_LISTEN_PORT = 443
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem"</pre>
The variable <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the certificate, the key and the chain, all in PEM format; the file order is not important. 
For instance let's assume you are using [https://letsencrypt.org/ Let's Encrypt] certificates, you will concatenate the two files <code>privkey.pem</code> and <code>fullchain.pem</code> as follows:

* In Linux (or in MacOS via terminal): <code>cat privkey.pem fullchain.pem</code>
* In Windows (via command prompt): <code>type privkex.pem fullchain.pem</code>

Then copy the result and paste it in the <code>Value</code> field.

 If you need to redirect your HTTP traffic to HTTPS, you will assign the variable <code>SERVICE_X_REDIRECT_TO_HTTPS</code> as follows:

<pre>SERVICE_X_REDIRECT_TO_HTTPS = True</pre>
You can also define the maximum age of your HTTP Strict Transport Security (HSTS) by assigning the variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> as follows:

<pre>SERVICE_X_SSL_HSTS_MAX_AGE = 15768000 #corresponds to 6 months</pre>
The variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy maximum age in seconds. In our example 15768000 seconds correspond to approximatively 6 months.

==== All Variables ====

This sections list all available contextualization variables. Their name is composed as follows:

# ''SERVICE_X_'' (where X is a number >= 0) defines the load balancing service to be configured;
# ''Keyword'' defines the corresponding service item to be configured.

Some variables are valid for both protocols (tcp and http) and some are valid only with protocol http.

===== TCP and HTTP Variables =====

* <code>MAXCONN</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the value of the <code>maxconn</code> parameter, which sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. 
The default value is 2000. This variable isn't mandatory.
* <code>SERVICE_X_PROTO</code> <code>=</code> <code>{</code> <code>tcp|http</code> <code>}</code> defines the protocol in ''service'' number <code>X</code>. 
Default value is http. This variable isn't mandatory.
* <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening. 
Default value is Null. This variable is '''mandatory'''. 
If this variable isn't defined, the rest of the service definition will be ignored.
* <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of backend server(s). 
Default value is Null. This variable is '''mandatory'''. 
Example: <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>10.4.0.2-10.4.0.20</code> <code>}</code>
* <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines TCP port on which backend server(s) are listening. 
Default value is Null. This variable isn't mandatory. 
'''NOTE''' if the variable isn't defined, it will take the <code>SERVICE_X_LISTEN_PORT</code> value.
* <code>SERVICE_X_CHECK_RISE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive successful health checks that declare the backend server is alive. 
Default value is 2. This variable isn't mandatory.
* <code>SERVICE_X_CHECK_FALL</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive unsuccessful health checks that declare the backend server is dead. 
Default value is 3. This variable isn't mandatory.

===== HTTP only Variables =====

* <code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the URI referenced in the HTTP health-check. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the following files in PEM format: <code>certificate</code>, <code>key</code>and <code>intermediate</code>. Order is not important. Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_REDIRECT_TO_HTTPS</code> <code>=</code> <code>{</code> <code>True</code> <code>}</code> defines the presence of a 301 redirect from http to https. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy max-age in seconds. 
Default value is Null. This variable isn't mandatory.

Default Null value means that the related configuration is not applied if the variable isn't defined.

=== Start and Check the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the configured load balancer template and click on "Instantiate".
#:[[file:lb_15.png|500px|border]]
#:A new window will appear
#:[[file:lb_16.png|600px|border]]
#: 
# You can assign a name to your load balancer or leave the field empty. Click on "Instantiate" to start the instantiation.
# When the new VM is in the <code>RUNNING</code> state, click on the console icon [[file:lb_17.png|25px]] to access the VM.
# In the console you will see the login prompt and after a while you will see wether the HAProxy configuration was successful or not. If not, terminate the VM, modify the variables in the template and re-instantiate the VM.
#:[[file:lb_18.png|700px|border]]
#: 

== How to Modify the Load Balancer's Configuration. ==

Currently you cannot modify the load balancer's configuration while it is running. Also if you were to modify the HAProxy configuration within the load balancer VM, if the VM had to be terminated and re-instantiated, you would loose your modifications.

In order to minimize the downtime, you should:
# Clone the Load Balancer's Template in case you have to roll back.
# Change the configuration in the new template by adding variables, removing variables or modifying existing variables.
# Terminate the old load balancer VM
# Instantiate the new template again.

== Appendix ==

=== Dissecting HAProxy's configuration ===

HAProxy configuration consists of several sections:

* the <code>global</code> section, which sets process-wide parameters (static, cannot be modified),
* and for each defined service, a <code>proxy</code> section, which is built using the contextualization variables.

==== Global Section ====

Global section is standardized for every appliance as follows:

<pre>global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000</pre>
Parameter <code>maxconn</code> sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. For further information see [https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-maxconn this page]. This parameter can be modified using a contextualization variable.

==== Proxy Section ====

In HAProxy, the Proxy configuration for each service contains a set of sections, which can be either:

* defaults [<name>]
* frontend <name>
* backend <name>

Or:

* defaults [<name>]
* listen <name>

A <code>defaults</code> section sets default parameters for all other sections following its declaration. Those default parameters are reset by the next <code>defaults</code> section.

A <code>frontend</code> section describes a set of listening sockets accepting client connections.

A <code>backend</code> section describes a set of servers to which the proxy will connect to forward incoming connections.

A <code>listen</code> section defines a complete proxy with its frontend and backend parts combined in one section. It is generally useful for TCP-only traffic.

For the CipherSpace Load Balancer, we use only one <code>defaults</code> section, valid for all services. We also don't use the <code>listen</code> section, as it can be replaced with one <code>frontend</code>and one <code>backend</code> section.

Right now, two major proxy modes are supported: <code>tcp</code>, also known as ''layer 4'', and <code>http</code>, also known as ''layer 7''.

In '''layer 4 mode''', HAProxy simply forwards bidirectional traffic between two sides. 
In '''layer 7 mode''', HAProxy analyzes the protocol, and can interact with it by allowing, blocking, switching, adding, modifying, or removing arbitrary contents in requests or responses, based on arbitrary criteria.

===== Defaults Section =====

The <code>defaults</code> section is standardized for every appliance as follows:

<pre> defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s</pre>
===== Frontend and Backend Sections =====

The <code>frontend</code>and <code>backend</code>sections are configured using the contextualization variables defined in the section [[#all-variables|All Variables]].

Variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. This is the default mode. It should be used for SSL, SSH, SMTP, ...

When <code>SERVICE_X_PROTO</code> <code>=</code> <code>http</code>, the service is defined in <code>mode</code> <code>http</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
[...]

backend service_X_backend
mode http
balance source
[...] </pre>
When <code>SERVICE_X_PROTO</code> <code>=</code> <code>tcp</code>, the service is defined in <code>mode</code> <code>tcp</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode tcp
option tcplog
[...]

backend service_X_backend
mode tcp
balance source
[...] </pre>
Example:

In the following example, we define the following contextualization variables:

<pre> SERVICE_0_PROTO = http
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.5 - 10.4.0.10
SERVICE_0_BACKEND_PORT = 8080</pre>
Those variables generate the following complete HAProxy's configuration:

<pre> global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-R SA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AE S256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000

defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

frontend service_0
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
bind :80
default_backend service_0_backend

backend service_0_backend
mode http
balance source
server server0 10.4.0.5:8080 check
server server1 10.4.0.6:8080 check
server server2 10.4.0.7:8080 check
server server3 10.4.0.8:8080 check
server server4 10.4.0.9:8080 check
server server5 10.4.0.10:8080 check</pre>
===== Health Checks =====

When a ''server'' is defined in the ''backend'' section, it is possible to define a health check using the setting <code>check</code>. 
By default, a ''server'' is always considered available. If <code>check</code> is set, the server is available when it is accepting periodic TCP connections, to ensure that it is really able to serve requests. 
The default address and port for these tests are those of the server, and the default source is the same as the one defined in the backend. 
It is possible to change the port using the <code>port</code> parameter (currently not implemented), and the interval (currently not implemented) and timers using the <code>inter</code>, <code>rise</code> and <code>fall</code> parameters.

The <code>inter</code> default value of 2000 ms between two consecutive health checks is good enough.

<pre> rise <count></pre>
The <code>rise</code> parameter states that a server will be considered as operational after <count> consecutive successful health checks. This value defaults to 2 if unspecified.

<pre> fall <count></pre>
The <code>fall</code> parameter states that a server will be considered as dead after <count> consecutive unsuccessful health checks. This value defaults to 3 if unspecified.

The request method is defined in the backend using the <code>option</code> <code>httpchk</code>. The <code>option</code> <code>httpchk</code> enables HTTP protocol to check on the servers health.

Possible configuration are:

<pre>option httpchk <uri></pre>
Arguments are:

<code><uri></code>: is the URI referenced in the HTTP requests. It defaults to "/" which is accessible by default on almost any server, but may be changed to any other URI. Query strings are permitted.

By default, server health checks only consist in trying to establish a TCP connection. When <code>option</code> <code>httpchk</code> is specified, a complete HTTP request is sent once the TCP connection is established, and responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

The port and interval are specified in the ''server'' configuration.

This option does not necessarily require an ''HTTP backend'', it also works with plain ''TCP backend''.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_0_CHECK_URI = "/"
SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
Those variables generate the following HAProxy's configuration:

<pre>[...]
backend service_0_backend
mode http
option httpchk /
balance source
server server0 10.4.0.5:8080 check rise 3 fall 4
server server1 10.4.0.6:8080 check rise 3 fall 4
server server2 10.4.0.7:8080 check rise 3 fall 4
server server3 10.4.0.8:8080 check rise 3 fall 4
server server4 10.4.0.9:8080 check rise 3 fall 4
server server5 10.4.0.10:8080 check rise 3 fall 4</pre>
===== HTTPS Support =====

To enable https support, we need to specify in the <code>frontend</code> section the option <code>ssl</code> and the option <code>crt</code> followed by path to the file which contains certificate, privkey, intermediate certificate and dhparam.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem";
SERVICE_X_REDIRECT_TO_HTTPS = True
SERVICE_X_SSL_HSTS_MAX_AGE = 15768000</pre>
Those variables generate the following HAProxy's configuration:

<pre>frontend service_0
mode http
bind :443 ssl crt /path/to/<cert+privkey+intermediate+dhparam>
bind :80
redirect scheme https code 301 if !{ ssl_fc }

# HSTS (15768000 seconds = 6 months)
http-response set-header Strict-Transport-Security max-age=15768000</pre>
<Category:OpenNebula>

CipherSpace Load Balancer

2017-08-02T14:52:03Z

Stoyan: /* Health Checks */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]
== CipherSpace Load Balancer ==

The CipherSpace Load Balancer uses [http://www.haproxy.org/ HAProxy] and its configuration is defined using OpenNebula Contextualization Variables within the appliance's template.

The CipherSpace Load Balancer uses the concept of "sticky sessions", which is a mechanism to route requests from the same source to the same target (if the target is still available).

== How to use the CipherSpace Load Balancer ==

=== Download the Load Balancer from the App Market ===

# Go to "Storage" in the left menu and click on "Apps" in the drop down menu.
#:[[file:lb_1.png|150px|border]]
#:A list with all existing apps will appear.
#:[[file:lb_2.png|700px|border]]
#: 
# Select the CipherSpace Load Balancer and click on the "-> OpenNebula" button.
#:[[file:lb_3.png|700px|border]]
#:A new window will appear.
#:[[file:lb_4.png|700px|border]]
#: 
# You can rename the image ("Name") as well as the VM template name. Then select the datastore which is used for your VMs and click on "Download". A new image as well as a new template will be created.

=== Configure the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the template for the load balancer and click on "Update".
#:[[file:lb_7.png|500px|border]]
#: 
# Click on the "Network" tab
#:[[file:lb_8.png|500px|border]]
#:and select a Virtual Network for your NIC (the same network as the VMs which provide the service you would like to load balance).
#:[[file:lb_9.png|600px|border]]
#: 
#:If clients connect to your load balancer from a different network (Internet for example) you need to add another NIC and attach it to the appropriate Virtual Network.
#:[[file:lb_10.png|600px|border]]
#: 
# Click on the "Context" tab
#:[[file:lb_11.png|500px|border]]
#:and then click on the "Custom vars" section.
#:[[file:lb_12.png|600px|border]]
#: 
# In the "Custom vars" section, click on the "+" button to enter all the necessary contextualization variables and their respective values (see the section [[#Load Balancer Contextualization Variables | Load Balancer Contextualization Variables]]).
#:[[file:lb_13.png|700px|border]]
#: 
# If you have 2 NICs, you should set default gateway by adding the variable <code>GATEWAY_IFACE</code>and assign it with the number of the NIC on which requests from clients are coming. (typically <code>1</code>).
#:<code>GATEWAY_IFACE = 1</code>
#: 
# When you're done, click on "Update" to save your changes.
#:[[file:lb_14.png|700px|border]]
#: 

=== Load Balancer Contextualization Variables ===

==== Basic Configuration ====

In order to understand the contextualization variables, let's use the following example.

You have three web servers and a load balancer attached to the same virtual network. The web servers have the IP addresses <code>10.4.0.11</code>, <code>10.4.0.12</code> and <code>10.4.0.13</code> respectively. They listen to <code>http</code> traffic on port <code>8080</code>. The load balancer listens to <code>http</code> traffic on the port <code>80</code>.

In this example you only have one service (http) which needs to be balanced. 
Every contextualization variable for this service will have a name like <code>SERVICE_0_...</code>. 
If you define more services, each new service variables will start with 
<code>SERVICE_1_</code>, <code>SERVICE_2_</code>, etc..

For this particular example you will define the following variables:

* SERVICE_0_PROTO
* SERVICE_0_LISTEN_PORT
* SERVICE_0_IP_RANGE
* SERVICE_0_BACKEND_PORT

The variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. It should be used for SSL, SSH, SMTP, ...

In our example <code>SERVICE_0_PROTO</code> has the value <code>HTTP</code>

The variable <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening to. 
This variable is '''mandatory'''. If this variable isn't defined, the rest of the service definition will be ignored. 
In our example <code>SERVICE_0_LISTEN_PORT</code> has the value <code>80</code>

The variable <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of the backend servers. This variable is '''mandatory'''. 
In our example <code>SERVICE_X_IP_RANGE</code> has the value <code>10.4.0.11-10.4.0.13</code>

The variable <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the backend servers are listening to. This variable is optional. If this variable isn't defined, the value of the variable <code>SERVICE_X_LISTEN_PORT</code> will be used instead. 
In our example <code>SERVICE_X_BACKEND_PORT</code> has the value <code>8080</code>

So, our example will be configured as follows:

<pre> SERVICE_0_PROTO = HTTP
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.11-10.4.0.13
SERVICE_0_BACKEND_PORT = 8080</pre>
==== Health Checks ====

When you use the load balancer, your backend servers are periodically checked if they are available by accepting periodic TCP connections, to ensure that each server is still alive.

Every 2 seconds, each backend server will be checked and its status will be either Up or Down based on the following rules:

* A server is Up after 2 consecutive successful health checks.
* A server is Down after 3 consecutive unsuccessful health checks.

You can change the number of consecutive successful health checks using the variable <code>SERVICE_X_CHECK_RISE</code> and the number of consecutive unsuccessful health checks using the variable <code>SERVICE_X_CHECK_FALL</code>.

Let's use the example defined in the [[#Basic Configuration|Basic Configuration]] section. If you want to set the number of successful and unsuccessful checks to <code>3</code> and <code>4</code> respectively for your backend servers, you will add the following to your configuration:

<pre>SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
By default, server health check only consist in trying to establish a TCP connection. You can add a complete HTTP request after an established TCP connection by adding the following variable:

<code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>uri</code> <code>}</code>

where <code><uri></code>is the URI referenced in the HTTP requests. 
Responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

==== HTTPS Support ====

To enable HTTPS support, you need to specify the following variables like this:

<pre> SERVICE_X_PROTO = HTTP
SERVICE_X_LISTEN_PORT = 443
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem"</pre>
The variable <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the certificate, the key and the chain, all in PEM format; the file order is not important. 
For instance let's assume you are using [https://letsencrypt.org/ Let's Encrypt] certificates, you will concatenate the two files <code>privkey.pem</code> and <code>fullchain.pem</code> as follows:

* In Linux (or in MacOS via terminal): <code>cat privkey.pem fullchain.pem</code>
* In Windows (via command prompt): <code>type privkex.pem fullchain.pem</code>

Then copy the result and paste it in the <code>Value</code> field.

 If you need to redirect your HTTP traffic to HTTPS, you will assign the variable <code>SERVICE_X_REDIRECT_TO_HTTPS</code> as follows:

<pre>SERVICE_X_REDIRECT_TO_HTTPS = True</pre>
You can also define the maximum age of your HTTP Strict Transport Security (HSTS) by assigning the variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> as follows:

<pre>SERVICE_X_SSL_HSTS_MAX_AGE = 15768000 #corresponds to 6 months</pre>
The variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy maximum age in seconds. In our example 15768000 seconds correspond to approximatively 6 months.

==== All Variables ====

This sections list all available contextualization variables. Their name is composed as follows:

# ''SERVICE_X_'' (where X is a number >= 0) defines the load balancing service to be configured;
# ''Keyword'' defines the corresponding service item to be configured.

Some variables are valid for both protocols (tcp and http) and some are valid only with protocol http.

===== TCP and HTTP Variables =====

* <code>MAXCONN</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the value of the <code>maxconn</code> parameter, which sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. 
The default value is 2000. This variable isn't mandatory.
* <code>SERVICE_X_PROTO</code> <code>=</code> <code>{</code> <code>tcp|http</code> <code>}</code> defines the protocol in ''service'' number <code>X</code>. 
Default value is http. This variable isn't mandatory.
* <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening. 
Default value is Null. This variable is '''mandatory'''. 
If this variable isn't defined, the rest of the service definition will be ignored.
* <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of backend server(s). 
Default value is Null. This variable is '''mandatory'''. 
Example: <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>10.4.0.2-10.4.0.20</code> <code>}</code>
* <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines TCP port on which backend server(s) are listening. 
Default value is Null. This variable isn't mandatory. 
'''NOTE''' if the variable isn't defined, it will take the <code>SERVICE_X_LISTEN_PORT</code> value.
* <code>SERVICE_X_CHECK_RISE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive successful health checks that declare the backend server is alive. 
Default value is 2. This variable isn't mandatory.
* <code>SERVICE_X_CHECK_FALL</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive unsuccessful health checks that declare the backend server is dead. 
Default value is 3. This variable isn't mandatory.

===== HTTP only Variables =====

* <code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the URI referenced in the HTTP health-check. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the following files in PEM format: <code>chain</code>, <code>key</code>and <code>intermediate</code>. Order is not important. Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_REDIRECT_TO_HTTPS</code> <code>=</code> <code>{</code> <code>True</code> <code>}</code> defines the presence of a 301 redirect from http to https. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy max-age in seconds. 
Default value is Null. This variable isn't mandatory.

Default Null value means that the related configuration is not applied if the variable isn't defined.

=== Start and Check the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the configured load balancer template and click on "Instantiate".
#:[[file:lb_15.png|500px|border]]
#:A new window will appear
#:[[file:lb_16.png|600px|border]]
#: 
# You can assign a name to your load balancer or leave the field empty. Click on "Instantiate" to start the instantiation.
# When the new VM is in the <code>RUNNING</code> state, click on the console icon [[file:lb_17.png|25px]] to access the VM.
# In the console you will see the login prompt and after a while you will see wether the HAProxy configuration was successful or not. If not, terminate the VM, modify the variables in the template and re-instantiate the VM.
#:[[file:lb_18.png|700px|border]]
#: 

== How to Modify the Load Balancer's Configuration. ==

Currently you cannot modify the load balancer's configuration while it is running. Also if you were to modify the HAProxy configuration within the load balancer VM, if the VM had to be terminated and re-instantiated, you would loose your modifications.

In order to minimize the downtime, you should:
# Clone the Load Balancer's Template in case you have to roll back.
# Change the configuration in the new template by adding variables, removing variables or modifying existing variables.
# Terminate the old load balancer VM
# Instantiate the new template again.

== Appendix ==

=== Dissecting HAProxy's configuration ===

HAProxy configuration consists of several sections:

* the <code>global</code> section, which sets process-wide parameters (static, cannot be modified),
* and for each defined service, a <code>proxy</code> section, which is built using the contextualization variables.

==== Global Section ====

Global section is standardized for every appliance as follows:

<pre>global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000</pre>
Parameter <code>maxconn</code> sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. For further information see [https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-maxconn this page]. This parameter can be modified using a contextualization variable.

==== Proxy Section ====

In HAProxy, the Proxy configuration for each service contains a set of sections, which can be either:

* defaults [<name>]
* frontend <name>
* backend <name>

Or:

* defaults [<name>]
* listen <name>

A <code>defaults</code> section sets default parameters for all other sections following its declaration. Those default parameters are reset by the next <code>defaults</code> section.

A <code>frontend</code> section describes a set of listening sockets accepting client connections.

A <code>backend</code> section describes a set of servers to which the proxy will connect to forward incoming connections.

A <code>listen</code> section defines a complete proxy with its frontend and backend parts combined in one section. It is generally useful for TCP-only traffic.

For the CipherSpace Load Balancer, we use only one <code>defaults</code> section, valid for all services. We also don't use the <code>listen</code> section, as it can be replaced with one <code>frontend</code>and one <code>backend</code> section.

Right now, two major proxy modes are supported: <code>tcp</code>, also known as ''layer 4'', and <code>http</code>, also known as ''layer 7''.

In '''layer 4 mode''', HAProxy simply forwards bidirectional traffic between two sides. 
In '''layer 7 mode''', HAProxy analyzes the protocol, and can interact with it by allowing, blocking, switching, adding, modifying, or removing arbitrary contents in requests or responses, based on arbitrary criteria.

===== Defaults Section =====

The <code>defaults</code> section is standardized for every appliance as follows:

<pre> defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s</pre>
===== Frontend and Backend Sections =====

The <code>frontend</code>and <code>backend</code>sections are configured using the contextualization variables defined in the section [[#all-variables|All Variables]].

Variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. This is the default mode. It should be used for SSL, SSH, SMTP, ...

When <code>SERVICE_X_PROTO</code> <code>=</code> <code>http</code>, the service is defined in <code>mode</code> <code>http</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
[...]

backend service_X_backend
mode http
balance source
[...] </pre>
When <code>SERVICE_X_PROTO</code> <code>=</code> <code>tcp</code>, the service is defined in <code>mode</code> <code>tcp</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode tcp
option tcplog
[...]

backend service_X_backend
mode tcp
balance source
[...] </pre>
Example:

In the following example, we define the following contextualization variables:

<pre> SERVICE_0_PROTO = http
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.5 - 10.4.0.10
SERVICE_0_BACKEND_PORT = 8080</pre>
Those variables generate the following complete HAProxy's configuration:

<pre> global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-R SA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AE S256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000

defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

frontend service_0
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
bind :80
default_backend service_0_backend

backend service_0_backend
mode http
balance source
server server0 10.4.0.5:8080 check
server server1 10.4.0.6:8080 check
server server2 10.4.0.7:8080 check
server server3 10.4.0.8:8080 check
server server4 10.4.0.9:8080 check
server server5 10.4.0.10:8080 check</pre>
===== Health Checks =====

When a ''server'' is defined in the ''backend'' section, it is possible to define a health check using the setting <code>check</code>. 
By default, a ''server'' is always considered available. If <code>check</code> is set, the server is available when it is accepting periodic TCP connections, to ensure that it is really able to serve requests. 
The default address and port for these tests are those of the server, and the default source is the same as the one defined in the backend. 
It is possible to change the port using the <code>port</code> parameter (currently not implemented), and the interval (currently not implemented) and timers using the <code>inter</code>, <code>rise</code> and <code>fall</code> parameters.

The <code>inter</code> default value of 2000 ms between two consecutive health checks is good enough.

<pre> rise <count></pre>
The <code>rise</code> parameter states that a server will be considered as operational after <count> consecutive successful health checks. This value defaults to 2 if unspecified.

<pre> fall <count></pre>
The <code>fall</code> parameter states that a server will be considered as dead after <count> consecutive unsuccessful health checks. This value defaults to 3 if unspecified.

The request method is defined in the backend using the <code>option</code> <code>httpchk</code>. The <code>option</code> <code>httpchk</code> enables HTTP protocol to check on the servers health.

Possible configuration are:

<pre>option httpchk <uri></pre>
Arguments are:

<code><uri></code>: is the URI referenced in the HTTP requests. It defaults to "/" which is accessible by default on almost any server, but may be changed to any other URI. Query strings are permitted.

By default, server health checks only consist in trying to establish a TCP connection. When <code>option</code> <code>httpchk</code> is specified, a complete HTTP request is sent once the TCP connection is established, and responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

The port and interval are specified in the ''server'' configuration.

This option does not necessarily require an ''HTTP backend'', it also works with plain ''TCP backend''.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_0_CHECK_URI = "/"
SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
Those variables generate the following HAProxy's configuration:

<pre>[...]
backend service_0_backend
mode http
option httpchk /
balance source
server server0 10.4.0.5:8080 check rise 3 fall 4
server server1 10.4.0.6:8080 check rise 3 fall 4
server server2 10.4.0.7:8080 check rise 3 fall 4
server server3 10.4.0.8:8080 check rise 3 fall 4
server server4 10.4.0.9:8080 check rise 3 fall 4
server server5 10.4.0.10:8080 check rise 3 fall 4</pre>
===== HTTPS Support =====

To enable https support, we need to specify in the <code>frontend</code> section the option <code>ssl</code> and the option <code>crt</code> followed by path to the file which contains certificate, privkey, intermediate certificate and dhparam.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem";
SERVICE_X_REDIRECT_TO_HTTPS = True
SERVICE_X_SSL_HSTS_MAX_AGE = 15768000</pre>
Those variables generate the following HAProxy's configuration:

<pre>frontend service_0
mode http
bind :443 ssl crt /path/to/<cert+privkey+intermediate+dhparam>
bind :80
redirect scheme https code 301 if !{ ssl_fc }

# HSTS (15768000 seconds = 6 months)
http-response set-header Strict-Transport-Security max-age=15768000</pre>
<Category:OpenNebula>

CipherSpace Load Balancer

2017-08-02T14:45:22Z

Stoyan: /* Configure the Load Balancer */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]
== CipherSpace Load Balancer ==

The CipherSpace Load Balancer uses [http://www.haproxy.org/ HAProxy] and its configuration is defined using OpenNebula Contextualization Variables within the appliance's template.

The CipherSpace Load Balancer uses the concept of "sticky sessions", which is a mechanism to route requests from the same source to the same target (if the target is still available).

== How to use the CipherSpace Load Balancer ==

=== Download the Load Balancer from the App Market ===

# Go to "Storage" in the left menu and click on "Apps" in the drop down menu.
#:[[file:lb_1.png|150px|border]]
#:A list with all existing apps will appear.
#:[[file:lb_2.png|700px|border]]
#: 
# Select the CipherSpace Load Balancer and click on the "-> OpenNebula" button.
#:[[file:lb_3.png|700px|border]]
#:A new window will appear.
#:[[file:lb_4.png|700px|border]]
#: 
# You can rename the image ("Name") as well as the VM template name. Then select the datastore which is used for your VMs and click on "Download". A new image as well as a new template will be created.

=== Configure the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the template for the load balancer and click on "Update".
#:[[file:lb_7.png|500px|border]]
#: 
# Click on the "Network" tab
#:[[file:lb_8.png|500px|border]]
#:and select a Virtual Network for your NIC (the same network as the VMs which provide the service you would like to load balance).
#:[[file:lb_9.png|600px|border]]
#: 
#:If clients connect to your load balancer from a different network (Internet for example) you need to add another NIC and attach it to the appropriate Virtual Network.
#:[[file:lb_10.png|600px|border]]
#: 
# Click on the "Context" tab
#:[[file:lb_11.png|500px|border]]
#:and then click on the "Custom vars" section.
#:[[file:lb_12.png|600px|border]]
#: 
# In the "Custom vars" section, click on the "+" button to enter all the necessary contextualization variables and their respective values (see the section [[#Load Balancer Contextualization Variables | Load Balancer Contextualization Variables]]).
#:[[file:lb_13.png|700px|border]]
#: 
# If you have 2 NICs, you should set default gateway by adding the variable <code>GATEWAY_IFACE</code>and assign it with the number of the NIC on which requests from clients are coming. (typically <code>1</code>).
#:<code>GATEWAY_IFACE = 1</code>
#: 
# When you're done, click on "Update" to save your changes.
#:[[file:lb_14.png|700px|border]]
#: 

=== Load Balancer Contextualization Variables ===

==== Basic Configuration ====

In order to understand the contextualization variables, let's use the following example.

You have three web servers and a load balancer attached to the same virtual network. The web servers have the IP addresses <code>10.4.0.11</code>, <code>10.4.0.12</code> and <code>10.4.0.13</code> respectively. They listen to <code>http</code> traffic on port <code>8080</code>. The load balancer listens to <code>http</code> traffic on the port <code>80</code>.

In this example you only have one service (http) which needs to be balanced. 
Every contextualization variable for this service will have a name like <code>SERVICE_0_...</code>. 
If you define more services, each new service variables will start with 
<code>SERVICE_1_</code>, <code>SERVICE_2_</code>, etc..

For this particular example you will define the following variables:

* SERVICE_0_PROTO
* SERVICE_0_LISTEN_PORT
* SERVICE_0_IP_RANGE
* SERVICE_0_BACKEND_PORT

The variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. It should be used for SSL, SSH, SMTP, ...

In our example <code>SERVICE_0_PROTO</code> has the value <code>HTTP</code>

The variable <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening to. 
This variable is '''mandatory'''. If this variable isn't defined, the rest of the service definition will be ignored. 
In our example <code>SERVICE_0_LISTEN_PORT</code> has the value <code>80</code>

The variable <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of the backend servers. This variable is '''mandatory'''. 
In our example <code>SERVICE_X_IP_RANGE</code> has the value <code>10.4.0.11-10.4.0.13</code>

The variable <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the backend servers are listening to. This variable is optional. If this variable isn't defined, the value of the variable <code>SERVICE_X_LISTEN_PORT</code> will be used instead. 
In our example <code>SERVICE_X_BACKEND_PORT</code> has the value <code>8080</code>

So, our example will be configured as follows:

<pre> SERVICE_0_PROTO = HTTP
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.11-10.4.0.13
SERVICE_0_BACKEND_PORT = 8080</pre>
==== Health Checks ====

When you use the load balancer, your backend servers are periodically checked if they are available by accepting periodic TCP connections, to ensure that each server is still alive.

Every 2 seconds, each backend server will be checked and its status will be either Up or Down based on the following rules:

* A server is Up after 2 consecutive successful health checks.
* A server is Down after 3 consecutive unsuccessful health checks.

You can change the number of consecutive successful health checks using the variable <code>SERVICE_X_CHECK_RISE</code> and the number of consecutive unsuccessful health checks using the variable <code>SERVICE_X_CHECK_FALL</code>.

Let's use the example defined in the [[#Basic Configuration|Basic Configuration]] section. If you want to set the number of successful and unsuccessful checks to <code>3</code> and <code>4</code> respectively for your backend servers, you will add the following to your configuration:

<pre>SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
By default, server health check only consist in trying to establish a TCP connection. You can add a complete HTTP request after an established TCP connection by adding the following variable:

<code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code>

where <code><uri></code>is the URI referenced in the HTTP requests. 
Responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

==== HTTPS Support ====

To enable HTTPS support, you need to specify the following variables like this:

<pre> SERVICE_X_PROTO = HTTP
SERVICE_X_LISTEN_PORT = 443
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem"</pre>
The variable <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the certificate, the key and the chain, all in PEM format; the file order is not important. 
For instance let's assume you are using [https://letsencrypt.org/ Let's Encrypt] certificates, you will concatenate the two files <code>privkey.pem</code> and <code>fullchain.pem</code> as follows:

* In Linux (or in MacOS via terminal): <code>cat privkey.pem fullchain.pem</code>
* In Windows (via command prompt): <code>type privkex.pem fullchain.pem</code>

Then copy the result and paste it in the <code>Value</code> field.

 If you need to redirect your HTTP traffic to HTTPS, you will assign the variable <code>SERVICE_X_REDIRECT_TO_HTTPS</code> as follows:

<pre>SERVICE_X_REDIRECT_TO_HTTPS = True</pre>
You can also define the maximum age of your HTTP Strict Transport Security (HSTS) by assigning the variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> as follows:

<pre>SERVICE_X_SSL_HSTS_MAX_AGE = 15768000 #corresponds to 6 months</pre>
The variable <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy maximum age in seconds. In our example 15768000 seconds correspond to approximatively 6 months.

==== All Variables ====

This sections list all available contextualization variables. Their name is composed as follows:

# ''SERVICE_X_'' (where X is a number >= 0) defines the load balancing service to be configured;
# ''Keyword'' defines the corresponding service item to be configured.

Some variables are valid for both protocols (tcp and http) and some are valid only with protocol http.

===== TCP and HTTP Variables =====

* <code>MAXCONN</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the value of the <code>maxconn</code> parameter, which sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. 
The default value is 2000. This variable isn't mandatory.
* <code>SERVICE_X_PROTO</code> <code>=</code> <code>{</code> <code>tcp|http</code> <code>}</code> defines the protocol in ''service'' number <code>X</code>. 
Default value is http. This variable isn't mandatory.
* <code>SERVICE_X_LISTEN_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the TCP port the load balancer is listening. 
Default value is Null. This variable is '''mandatory'''. 
If this variable isn't defined, the rest of the service definition will be ignored.
* <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>dotted</code> <code>notation</code> <code>}</code> defines the IP addresses of backend server(s). 
Default value is Null. This variable is '''mandatory'''. 
Example: <code>SERVICE_X_IP_RANGE</code> <code>=</code> <code>{</code> <code>10.4.0.2-10.4.0.20</code> <code>}</code>
* <code>SERVICE_X_BACKEND_PORT</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines TCP port on which backend server(s) are listening. 
Default value is Null. This variable isn't mandatory. 
'''NOTE''' if the variable isn't defined, it will take the <code>SERVICE_X_LISTEN_PORT</code> value.
* <code>SERVICE_X_CHECK_RISE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive successful health checks that declare the backend server is alive. 
Default value is 2. This variable isn't mandatory.
* <code>SERVICE_X_CHECK_FALL</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the number of consecutive unsuccessful health checks that declare the backend server is dead. 
Default value is 3. This variable isn't mandatory.

===== HTTP only Variables =====

* <code>SERVICE_X_CHECK_URI</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the URI referenced in the HTTP health-check. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_OFFLOAD_CERT</code> <code>=</code> <code>{</code> <code>string</code> <code>}</code> defines the certificate chains to offload encrypted connections. 
It has to be a string which contains the following files in PEM format: <code>chain</code>, <code>key</code>and <code>intermediate</code>. Order is not important. Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_REDIRECT_TO_HTTPS</code> <code>=</code> <code>{</code> <code>True</code> <code>}</code> defines the presence of a 301 redirect from http to https. 
Default value is Null. This variable isn't mandatory.
* <code>SERVICE_X_SSL_HSTS_MAX_AGE</code> <code>=</code> <code>{</code> <code>int</code> <code>}</code> defines the HSTS policy max-age in seconds. 
Default value is Null. This variable isn't mandatory.

Default Null value means that the related configuration is not applied if the variable isn't defined.

=== Start and Check the Load Balancer ===

# Go to "Templates" in the left menu and click on "VMs" in the drop down menu.
#:[[file:lb_5.png|125px|border]]
#:A list with all existing VM templates will appear.
#:[[file:lb_6.png|500px|border]]
#: 
# Select the configured load balancer template and click on "Instantiate".
#:[[file:lb_15.png|500px|border]]
#:A new window will appear
#:[[file:lb_16.png|600px|border]]
#: 
# You can assign a name to your load balancer or leave the field empty. Click on "Instantiate" to start the instantiation.
# When the new VM is in the <code>RUNNING</code> state, click on the console icon [[file:lb_17.png|25px]] to access the VM.
# In the console you will see the login prompt and after a while you will see wether the HAProxy configuration was successful or not. If not, terminate the VM, modify the variables in the template and re-instantiate the VM.
#:[[file:lb_18.png|700px|border]]
#: 

== How to Modify the Load Balancer's Configuration. ==

Currently you cannot modify the load balancer's configuration while it is running. Also if you were to modify the HAProxy configuration within the load balancer VM, if the VM had to be terminated and re-instantiated, you would loose your modifications.

In order to minimize the downtime, you should:
# Clone the Load Balancer's Template in case you have to roll back.
# Change the configuration in the new template by adding variables, removing variables or modifying existing variables.
# Terminate the old load balancer VM
# Instantiate the new template again.

== Appendix ==

=== Dissecting HAProxy's configuration ===

HAProxy configuration consists of several sections:

* the <code>global</code> section, which sets process-wide parameters (static, cannot be modified),
* and for each defined service, a <code>proxy</code> section, which is built using the contextualization variables.

==== Global Section ====

Global section is standardized for every appliance as follows:

<pre>global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000</pre>
Parameter <code>maxconn</code> sets the maximum per-process number of concurrent connections. Proxies will stop accepting connections when this limit is reached. For further information see [https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-maxconn this page]. This parameter can be modified using a contextualization variable.

==== Proxy Section ====

In HAProxy, the Proxy configuration for each service contains a set of sections, which can be either:

* defaults [<name>]
* frontend <name>
* backend <name>

Or:

* defaults [<name>]
* listen <name>

A <code>defaults</code> section sets default parameters for all other sections following its declaration. Those default parameters are reset by the next <code>defaults</code> section.

A <code>frontend</code> section describes a set of listening sockets accepting client connections.

A <code>backend</code> section describes a set of servers to which the proxy will connect to forward incoming connections.

A <code>listen</code> section defines a complete proxy with its frontend and backend parts combined in one section. It is generally useful for TCP-only traffic.

For the CipherSpace Load Balancer, we use only one <code>defaults</code> section, valid for all services. We also don't use the <code>listen</code> section, as it can be replaced with one <code>frontend</code>and one <code>backend</code> section.

Right now, two major proxy modes are supported: <code>tcp</code>, also known as ''layer 4'', and <code>http</code>, also known as ''layer 7''.

In '''layer 4 mode''', HAProxy simply forwards bidirectional traffic between two sides. 
In '''layer 7 mode''', HAProxy analyzes the protocol, and can interact with it by allowing, blocking, switching, adding, modifying, or removing arbitrary contents in requests or responses, based on arbitrary criteria.

===== Defaults Section =====

The <code>defaults</code> section is standardized for every appliance as follows:

<pre> defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s</pre>
===== Frontend and Backend Sections =====

The <code>frontend</code>and <code>backend</code>sections are configured using the contextualization variables defined in the section [[#all-variables|All Variables]].

Variable <code>SERVICE_X_PROTO</code> defines the mode in which the service works. Possible modes are:

* '''http''': the instance will work in HTTP mode. The client request will be analyzed in depth before connecting to any server. Any request which is not RFC-compliant will be rejected. Layer 7 filtering, processing and switching will be possible.
* '''tcp''': the instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. This is the default mode. It should be used for SSL, SSH, SMTP, ...

When <code>SERVICE_X_PROTO</code> <code>=</code> <code>http</code>, the service is defined in <code>mode</code> <code>http</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
[...]

backend service_X_backend
mode http
balance source
[...] </pre>
When <code>SERVICE_X_PROTO</code> <code>=</code> <code>tcp</code>, the service is defined in <code>mode</code> <code>tcp</code> and the script generates the following configuration:

<pre> [...]
frontend service_X
mode tcp
option tcplog
[...]

backend service_X_backend
mode tcp
balance source
[...] </pre>
Example:

In the following example, we define the following contextualization variables:

<pre> SERVICE_0_PROTO = http
SERVICE_0_LISTEN_PORT = 80
SERVICE_0_IP_RANGE = 10.4.0.5 - 10.4.0.10
SERVICE_0_BACKEND_PORT = 8080</pre>
Those variables generate the following complete HAProxy's configuration:

<pre> global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
# set default parameters to the intermediate configuration
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-bind-options no-sslv3 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA84:DHE-R SA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHEECDSA-AE S256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RA-DES-CB C3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-options no-sslv3 no-tls-tickets
user haproxy
group haproxy
daemon
maxconn 2000

defaults
log global
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

frontend service_0
mode http
option httplog
option http-server-close
option forwardfor except 127.0.0.0/8
bind :80
default_backend service_0_backend

backend service_0_backend
mode http
balance source
server server0 10.4.0.5:8080 check
server server1 10.4.0.6:8080 check
server server2 10.4.0.7:8080 check
server server3 10.4.0.8:8080 check
server server4 10.4.0.9:8080 check
server server5 10.4.0.10:8080 check</pre>
===== Health Checks =====

When a ''server'' is defined in the ''backend'' section, it is possible to define a health check using the setting <code>check</code>. 
By default, a ''server'' is always considered available. If <code>check</code> is set, the server is available when it is accepting periodic TCP connections, to ensure that it is really able to serve requests. 
The default address and port for these tests are those of the server, and the default source is the same as the one defined in the backend. 
It is possible to change the port using the <code>port</code> parameter (currently not implemented), and the interval (currently not implemented) and timers using the <code>inter</code>, <code>rise</code> and <code>fall</code> parameters.

The <code>inter</code> default value of 2000 ms between two consecutive health checks is good enough.

<pre> rise <count></pre>
The <code>rise</code> parameter states that a server will be considered as operational after <count> consecutive successful health checks. This value defaults to 2 if unspecified.

<pre> fall <count></pre>
The <code>fall</code> parameter states that a server will be considered as dead after <count> consecutive unsuccessful health checks. This value defaults to 3 if unspecified.

The request method is defined in the backend using the <code>option</code> <code>httpchk</code>. The <code>option</code> <code>httpchk</code> enables HTTP protocol to check on the servers health.

Possible configuration are:

<pre>option httpchk <uri></pre>
Arguments are:

<code><uri></code>: is the URI referenced in the HTTP requests. It defaults to "/" which is accessible by default on almost any server, but may be changed to any other URI. Query strings are permitted.

By default, server health checks only consist in trying to establish a TCP connection. When <code>option</code> <code>httpchk</code> is specified, a complete HTTP request is sent once the TCP connection is established, and responses 2xx and 3xx are considered valid, while all other ones indicate a server failure, including the lack of any response.

The port and interval are specified in the ''server'' configuration.

This option does not necessarily require an ''HTTP backend'', it also works with plain ''TCP backend''.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_0_CHECK_URI = "/"
SERVICE_0_CHECK_RISE = 3
SERVICE_0_CHECK_FALL = 4</pre>
Those variables generate the following HAProxy's configuration:

<pre>[...]
backend service_0_backend
mode http
option httpchk /
balance source
server server0 10.4.0.5:8080 check rise 3 fall 4
server server1 10.4.0.6:8080 check rise 3 fall 4
server server2 10.4.0.7:8080 check rise 3 fall 4
server server3 10.4.0.8:8080 check rise 3 fall 4
server server4 10.4.0.9:8080 check rise 3 fall 4
server server5 10.4.0.10:8080 check rise 3 fall 4</pre>
===== HTTPS Support =====

To enable https support, we need to specify in the <code>frontend</code> section the option <code>ssl</code> and the option <code>crt</code> followed by path to the file which contains certificate, privkey, intermediate certificate and dhparam.

Example:

In the following example, we define the following contextualization variables:

<pre>[...]
SERVICE_X_SSL_OFFLOAD_CERT = "crt.pem + key.pem + intermediate.pem";
SERVICE_X_REDIRECT_TO_HTTPS = True
SERVICE_X_SSL_HSTS_MAX_AGE = 15768000</pre>
Those variables generate the following HAProxy's configuration:

<pre>frontend service_0
mode http
bind :443 ssl crt /path/to/<cert+privkey+intermediate+dhparam>
bind :80
redirect scheme https code 301 if !{ ssl_fc }

# HSTS (15768000 seconds = 6 months)
http-response set-header Strict-Transport-Security max-age=15768000</pre>
<Category:OpenNebula>

How To Create and Use Security Groups in OpenNebula

2017-07-27T06:48:49Z

Stoyan: /* What is a Security Group ? */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]
== What is a Security Group ? ==

A Security Group define firewall rules, which can then be applied to your VMs and/or your Virtual Networks.

== Create a new Security Group ==

#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
# Go to "Network" in the left menu and click on "Security Groups" in the drop down menu.
#:[[File:SecGp_1.png|150px]]
#: 
#:A list with all existing security groups will appear.
#:[[File:SecGp_2.png|700px]]
# Click on the "+" button to create a new Security group.

== Define a Security Group ==

A security group is defined by its name, an optional description and one or several rules.
:[[File:SecGp_3.png|600px]]

=== Create a new rule ===

To create a new rule, you must specify the following parameters:

* Traffic direction: Choose between "Inbound" and "Outbound"
* Protocol: Choose between the following values:
** TCP
** UDP
** ICMP
** IPsec
** All
* Port range: Only available with TCP or UDP. You can either select "All" or you can specify a port range. Multiple ports or port ranges are separated using a comma, and a port range is specified using a colon. Example: <code>22,53,80:90,110,1024:65535</code>
* ICMP Type: Only available with ICMP. Use the dropdown to select the desired type or you can leave it blank to allow all ICMP traffic.
* Target network: you can define wether this rule can be applied to
** any virtual network ("Any network"),
** a specific virtual network ("OpenNebula Virtual Network"),
** or a specific IP range ("Manual Network")

If you choose "Manual Network", you must specify the following values: - First IP address: the first IP of your range - Size: the number of IP adresses in your range (including the first)

When all the parameters are specified, click on "Add rule" to create the new rule.
:[[File:SecGp_4.png|700px]]

When all the rules have been defined, click on "Create" to finish the creation of the new Security Group.
:[[File:SecGp_5.png|600px]]

== Use a Security Group ==
=== Apply the group to a Virtual Network ===

After you have applied a security group to a Virtual Network, the security group rules are copied to a new VM (attached to that Network) during the instantiation process.

To apply a security group to a Virtual Network, do the following steps:

# Go to "Network" in the left menu and click on "Virtual Networks" in the drop down menu.
#:[[File:SecGp_6.png|150px]]
#: 
#:A list with all existing virtual networks will appear.
# Select the virtual network you want to apply these rules to and click on "Update"
#:[[File:SecGp_7.png|700px]]
#: 
# Go on the Security tab,
#:[[File:SecGp_8.png|700px]]
#: 
#:and click on the security group you want to add.
#:[[File:SecGp_9.png|700px]]
#: 
# Click on "Update" to save your changes.
#:[[File:SecGp_10.png|700px]]

=== Apply the group to a specific Virtual Machine ===

If you need to apply the security group only to specific VM, you can attach a security group to a VM Template NIC as follows:
# Go to "Template" in the left menu and click on "VMs" in the drop down menu.
#:[[File:SecGp_11.png|150px]]
#: 
#:A list with all existing templates will appear.
# Select the template you want to apply these rules to and click on "Update"
#:[[File:SecGp_12.png|700px]]
#: 
# Go on the Network tab
#:[[File:SecGp_13.png|700px]]
#: 
# Click on "Advanced options" and scroll down to "Security Groups"
#:[[File:SecGp_14.png|700px]]
#: 
#:and click on the security group you want to add.
#:[[File:SecGp_15.png|700px]]
#: 
# Click on "Update" to save your changes.
#:[[File:SecGp_16.png|700px]]

== Update a Security Group ==

Security Groups can be updated to edit or add new rules. These changes are propagated to all VMs in the security group, so it may take some time till the changes are applied. The particular status of a VM can be checked in the security group properties, where outdated and up-to-date VMs are listed.

To update a security group:

# Go to "Network" in the left menu and click on "Security Groups" in the drop down menu.
#:[[File:SecGp_1.png|150px]]
#: 
#:A list with all existing security groups will appear.
#:[[File:SecGp_2.png|800px]]
# Select the group you want to update and click on "Update"
#:[[File:SecGp_16.png|800px]]
# Add rules accordingly or remove existing rules by clicking on the "x" button next to the rule.
# Click "Update" to save the changes. The updated rules are then propagated to all VMs in the security group

To see the propagation status, go back to the security group list, click on the group you've just updated and click on the VMs tab.
You will see all VMs in this group and their status.

CipherSpace Virtual Router

2017-05-10T06:49:48Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]

'''CipherSpace Virtual Router''' is meant to be used as:
* Router (masquerade)
* DHCP server
* DNS server
* RADVD server
* Port forwarding server
* Bastion host for SSH tunnels
* OpenVPN server

CipherSpace Virtual Router allows using VMs which are not contextualized.

[[File:CipherSpace-VirtualRouter-Diagram.png|center]]

The virtual router image is non-persistent and takes its entire configuration from the contextualization script. Default VM size is 256MB RAM, 0.5 CPU and 1 vCPU.
You can install it from the Appmarket.

'''When using DHCP or OpenVPN make sure IP spoofing and MAC spoofing protections are turned off for the internal network.''' Otherwise it will not work.

== Virtual Router Configuration ==
Following configurations can be added in the virtual router template in "Context" menu under "Custom Vars".

The virtual router can be configured with 1 or 2 network interfaces. With 1 network interface it can be used only as '''DHCP''' or '''RADVD''' server.

* '''TEMPLATE''' - this is '''required'''. Otherwise most of the other functionality will not work. Usage:
TEMPLATE = "$TEMPLATE"

* '''PRIVNET''' - private network. For example:
PRIVNET = "$NETWORK[TEMPLATE, NETWORK=\"<private_network_name>\"]"

* '''PUBNET''' - public network. For example:
PUBNET = "$NETWORK[TEMPLATE, NETWORK=\"<public_network_name>\"]"

* '''RADVD''' - enables or disabled RADVD server. Possible values are '''YES''' and '''NO'''. For example
RADVD = "NO"

* '''DHCP''' - enables or disabled DHCP server. Possible values are '''YES''' and '''NO'''. For example
DHCP = "YES"

* '''DNS''' - list of DNS servers to use in DHCP leases. If not specified DHCP server will use VMs private network IP address. For example:
DNS = "10.1.1.1 10.2.2.2"

* '''SEARCH''' - DNS search option. For example:
SEARCH = "zh4.cipherspace.net"

* '''NTP_SERVER''' - IP of the NTP server. The DHCP server will be configured to serve the NTP parameter to its leases. For example:
NTP_SERVER = "10.0.0.10"

* '''FORWARDING''' - list of forwarding rules separated by spaces. Syntax:
[[protocol:]route_port:]destination:vm_port
'''protocol''' is not validated but it only makes sense to use '''tcp''' or '''udp'''.Default is '''tcp'''. If '''router_port''' is omitted too then port '''vm_port''' on the router will be forwarded to '''vm_port''' on the VM. For example:
FORWARDING = "udp:8888:10.0.0.10:53 8080:10.0.0.10:80 10.0.0.10:22"
{|
|style="text-align:right;"|<code lang="text">udp:8888:10.0.0.10:53</code>
|style="padding-left: 15px"|Forward UDP port 8888 on the router to port 53 on 10.0.0.10.
|-
|style="text-align:right;"|<code lang="text">8080:10.0.0.10:80</code>
|style="padding-left: 15px"|Forward TCP port 8080 on the router to port 80 on 10.0.0.10.
|-
|style="text-align:right;"|<code lang="text">10.0.0.10:22</code>
|style="padding-left: 15px"|Forward TCP port 22 the router to port 22 on 10.0.0.10.
|}

* '''ROOT_PASSWORD''' - base64 encoded '''root''' password hash. For example one can use the following command:
openssl passwd -1 | base64

* '''SSH_PUBLIC_KEY''' - single line, base64 encoded list of SSH keys to be set as '''root's authorized_keys'''. That is the '''Public key''' field in '''Context'''->'''Network & SSH'''. This is not a custom field. To generate the string you can use command like this:
cat <pub_key1> <pub_key2> ... <pub_keyN> | base64 | paste -s -d '\0' -

* '''SSHD''' - if set to YES and SSH_PUBLIC_KEY is set, then sshd will be launched. The idea is that Virtual Router VMs will not need active maintenance thus sshd does not need to be on all the time. If SSH_PUBLIC_KEY is set keys will be installed for root regardless of whether SSHD is enabled or not. That way one can login on the console and launch sshd if required. Command is:
rc-service sshd start

* '''OPENVPN''' - controls whether OpenVPN should be started or not. If OPENVPN_CA_CERT, OPENVPN_SERVER_CERT and OPENVPN_SERVER_KEY are defined openvpn is configured but it is only launched if OPENVPN is set to YES. Please note that when image is instantiated and openvpn is configured it will take '''several minutes''', depending on allocated CPU, to boot because VM is generating DH 2048 bit parameters file.
* '''OPENVPN_CA_CERT''' - single line, PEM formatted, base64 encoded, Certification Authority certificate. That is the certificate used to sign OPENVPN_SERVER_CERT and all client certificates. Use the following command to encode:
cat ca.crt | base64 | paste -s -d '\0' -

* '''OPENVPN_SERVER_CERT''' - single line, PEM formatted, base64 encoded, server certificate.

* '''OPENVPN_SERVER_KEY''' - single line, PEM formatted, base64 encoded, server key

* '''OPENVPN_TA_KEY''' - optional but '''highly recommended''', single line, PEM formatted, base64 encoded, pre-shared key to use with '''--tls-auth'''. This features adds "extra protection" to the TLS channel by requiring that incoming packets have a valid signature generated using the pre-shared key. '''Key must be set on both server and client.''' If this key is ever changed, it must be changed on all peers at the same time.

* '''OPENVPN_REVOKED''' - optional, single line, base64 encoded content of a file containing revoked certificates.

* '''OPENVPN_INT_NET''' - Network to be used for communication between the server and the clients. It has to be different from the internal OpenNebula network and client's network. Is omitted it default to 10.255.255.0. OpenVPN allows user to maintain more than one tunnel at the same time. It is good idea to use different networks especially in the same client setup. That way one can have multiple tunnels opened at the same time if destination networks don't overlap of course.

* '''OPENVPN_INT_NETMASK''' - Network mask for the network between the server and the clients. Defaults to 255.255.255.0. '''Warning:''' OpenVPN is very picky. It will complain and it will not start if netmask zeros out any bit from the network. For example: net 10.1.1.1 netmask 255.255.255.0 will not work. You need to use: net 10.1.1.0 netmask 255.255.255.0

* '''OPENVPN_MAX_CLIENTS''' - Maximum number of simultaneously connected users. It defaults to 3. Tests showed that is a good number for the default size VM.

CipherSpace Virtual Router can be used as a bastion host to build ssh tunnels. This is controlled by the following context variables:

* '''TUNNEL_USER''' - user name. '''It must not exist.''' If user exists it will not be reconfigured. That is to prevent messing up system users. User shell is set to /bin/false.

* '''TUNNEL_USER_SSH_PUBLIC_KEY''' - single line, base64 encoded, list of keys to install in '''authorized_keys''' file. Since it can can be multi-line it has to be formatted the same way as SSH_PUBLIC_KEY.

* '''TUNNEL_USER_KEY_RESTRICTIONS''' - optional string that goes before the key in authorized_keys file. Defaults to '''"no-pty,no-agent-forwarding,no-X11-forwarding,no-user-rc"'''. Even though user shell is set to /bin/false one must be careful what goes in this variable.

Contextualization of Linux VMs

2017-04-24T13:26:22Z

Stoyan: /* Custom Vars */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]

OpenNebula uses a method called contextualization to send information to the VM at boot time. Information is collected in the Template and is essential to configure the VM.

The VM template has a section called "'''Context'''" where you can automate different configuration aspects.

The Context section has 3 parts:

==='''''Configuration'''''===

[[File:Template-Configuration.png|768px]]

This is the most basic context configuration provided by OpenNebula, where you can:
* Enable '''Network''' contextualization. The VM will be configured with the information added in the network section or in [[#Custom Vars|Custom Var]] section of the template.
* Enable '''SSH''' contextualization. Ssh service will be enabled.
* Add '''SSH public keys'''. Keys will be added to USERNAME authorized_keys file ([[#Custom Vars|See custom section]]) or to root in case USERNAME is not set.
* '''START_SCRIPT''' - Script which is executed when the machine starts up. It can contain either shell script or Shebang. For example START_SCRIPT="yum upgrade".

==='''''Files'''''===

[[File:Template-Files.png|768px]]

In this section you can include files in your vm. Files can be added in OpenNebula in "Files" section in the left menu under "Images".

You can select files from the list and they will be automatically added in FILES_DS attribute.

If the file is a script you want to run at boot you can add it INIT_SCRIPTS attribute.

==='''''Custom Vars'''''===

[[File:Template-CustomVars.png|768px]]

In this section you can setup a more advanced contextualization, the attributes available are:

*'''VARIABLE''' - Variables that store values related to this virtual machine or others . The name of the variable is arbitrary (in the example, we use hostname).

* '''SET_HOSTNAME''' - This parameter value will be the hostname of the VM.

* '''DNS_HOSTNAME''' - YES to set the VM hostname to the reverse dns name (from the first IP)

* '''GATEWAY_IFACE''' - This variable can be set to the interface number you want to configure the gateway. It is useful when several networks have GATEWAY parameter and you want yo choose the one that configures it. For example to set the first interface to configure the gateway you use GATEWAY_IFACE=0

* '''DNS''' - Specific DNS server for the Virtual Machine

* '''USERNAME''' - User to be created in the guest OS. If any password attribute is defined (see below) it will change this user (defaults to root). '''Please note:''' SSH daemon on the host is configured to deny access to user '''root''' and it does not support password authentication. If you specify '''USERNAME''' such account will be created and any SSH keys you may have configured will be allowed to login as that user. If you use any of the context variables below then password will be set for the user too. If username is not root you will be able to SSH in using SSH key and you will be able to login on the VNC console but you will '''not be able escalate your privileges''' to root. If username is '''root''' or you do not use '''USERNAME''' then you will be able to login on the VNC console but you will not be able to SSH in. '''Contextualization script always creates an user ''cloudUser'' which is allowed to login SSH using the keys you have configured in the template. Also cloudUser is allowed to elevate its privileges via sudo without password. the following command will make you root without password:'''
*: sudo -s

* '''CRYPTED_PASSWORD_BASE64''' - Crypted password encoded in base64. You can use the following command:
*: openssl passwd -1 | base64

* '''CRYPTED_PASSWORD''' - Crypted password. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead. You can use the following command:
*: openssl passwd -1

* '''PASSWORD_BASE64''' - Clear text password encoded in base64. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead. Example command:
*: echo "Password" | base64

* '''PASSWORD''' - Clear text password to be set for the user USERNAME. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead.

The following attributes are automatically filled up configuring the Network section of the template:
* '''ETHx_MAC''' - Used to find the correct interface

* '''ETHx_IP''' - IPv4 address for the interface

* '''ETHx_IPV6''' - IPv6 address for the interface

* '''ETHx_NETWORK''' - Network address of the interface

* '''ETHx_MASK''' - Network mask

* '''ETHx_GATEWAY''' - Default IPv4 gateway for the interface

* '''ETHx_GATEWAY6''' - Default IPv6 gateway for the interface

* '''ETHx_MTU''' - MTU value for the interface

* '''ETHx_DNS''' - DNS for the network

These last attributes are also automatically filled up adding SSH public keys in the [[Contextualization_of_Linux_VMs#Configuration | Context Configuration Section]] of the template:
* '''SSH_PUBLIC_KEY''' - Key to be added to USERNAME authorized_keys file or root in case USERNAME is not set.

* '''EC2_PUBLIC_KEY''' - Same as SSH_PUBLIC_KEY

Contextualization of Linux VMs

2017-04-24T13:25:23Z

Stoyan: /* Custom Vars */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]

OpenNebula uses a method called contextualization to send information to the VM at boot time. Information is collected in the Template and is essential to configure the VM.

The VM template has a section called "'''Context'''" where you can automate different configuration aspects.

The Context section has 3 parts:

==='''''Configuration'''''===

[[File:Template-Configuration.png|768px]]

This is the most basic context configuration provided by OpenNebula, where you can:
* Enable '''Network''' contextualization. The VM will be configured with the information added in the network section or in [[#Custom Vars|Custom Var]] section of the template.
* Enable '''SSH''' contextualization. Ssh service will be enabled.
* Add '''SSH public keys'''. Keys will be added to USERNAME authorized_keys file ([[#Custom Vars|See custom section]]) or to root in case USERNAME is not set.
* '''START_SCRIPT''' - Script which is executed when the machine starts up. It can contain either shell script or Shebang. For example START_SCRIPT="yum upgrade".

==='''''Files'''''===

[[File:Template-Files.png|768px]]

In this section you can include files in your vm. Files can be added in OpenNebula in "Files" section in the left menu under "Images".

You can select files from the list and they will be automatically added in FILES_DS attribute.

If the file is a script you want to run at boot you can add it INIT_SCRIPTS attribute.

==='''''Custom Vars'''''===

[[File:Template-CustomVars.png|768px]]

In this section you can setup a more advanced contextualization, the attributes available are:

*'''VARIABLE''' - Variables that store values related to this virtual machine or others . The name of the variable is arbitrary (in the example, we use hostname).

* '''SET_HOSTNAME''' - This parameter value will be the hostname of the VM.

* '''DNS_HOSTNAME''' - YES to set the VM hostname to the reverse dns name (from the first IP)

* '''GATEWAY_IFACE''' - This variable can be set to the interface number you want to configure the gateway. It is useful when several networks have GATEWAY parameter and you want yo choose the one that configures it. For example to set the first interface to configure the gateway you use GATEWAY_IFACE=0

* '''DNS''' - Specific DNS server for the Virtual Machine

* '''USERNAME''' - User to be created in the guest OS. If any password attribute is defined (see below) it will change this user (defaults to root). '''Please note:''' SSH daemon on the host is configured to deny access to user '''root''' and it does not support password authentication. If you specify '''USERNAME''' such account will be created and any SSH keys you may have configured will be allowed to login as that user. If you use any of the context variables below then password will be set for the user too. If username is not root you will be able to SSH in using SSH key and you will be able to login on the VNC console but you will '''not be able escalate your privileges''' to root. If username is '''root''' or you do not use '''USERNAME''' then you will be able to login on the VNC console but you will not be able to SSH in. '''Contextualization script always creates an user ''cloudUser'' which is allowed to login SSH using the keys you have configured in the template. Also cloudUser is allowed to elevate its privileges via sudo without password. the following command will make you root without password:'''
*: sudo -s

* '''CRYPTED_PASSWORD_BASE64''' - Crypted password encoded in base64. To be set for the user USERNAME. If not defined it will change root user. You can use the following command:
*: openssl passwd -1 | base64

* '''CRYPTED_PASSWORD''' - Crypted password. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead. You can use the following command:
*: openssl passwd -1

* '''PASSWORD_BASE64''' - Clear text password encoded in base64. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead. Example command:
*: echo "Password" | base64

* '''PASSWORD''' - Clear text password to be set for the user USERNAME. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead.

The following attributes are automatically filled up configuring the Network section of the template:
* '''ETHx_MAC''' - Used to find the correct interface

* '''ETHx_IP''' - IPv4 address for the interface

* '''ETHx_IPV6''' - IPv6 address for the interface

* '''ETHx_NETWORK''' - Network address of the interface

* '''ETHx_MASK''' - Network mask

* '''ETHx_GATEWAY''' - Default IPv4 gateway for the interface

* '''ETHx_GATEWAY6''' - Default IPv6 gateway for the interface

* '''ETHx_MTU''' - MTU value for the interface

* '''ETHx_DNS''' - DNS for the network

These last attributes are also automatically filled up adding SSH public keys in the [[Contextualization_of_Linux_VMs#Configuration | Context Configuration Section]] of the template:
* '''SSH_PUBLIC_KEY''' - Key to be added to USERNAME authorized_keys file or root in case USERNAME is not set.

* '''EC2_PUBLIC_KEY''' - Same as SSH_PUBLIC_KEY

Contextualization of Linux VMs

2017-04-21T08:50:46Z

Stoyan: /* Custom Vars */

[[Category:OpenNebula]]
[[Category:How To]]
[[Category:CloudInfrastructure]]

OpenNebula uses a method called contextualization to send information to the VM at boot time. Information is collected in the Template and is essential to configure the VM.

The VM template has a section called "'''Context'''" where you can automate different configuration aspects.

The Context section has 3 parts:

==='''''Configuration'''''===

[[File:Template-Configuration.png|768px]]

This is the most basic context configuration provided by OpenNebula, where you can:
* Enable '''Network''' contextualization. The VM will be configured with the information added in the network section or in [[#Custom Vars|Custom Var]] section of the template.
* Enable '''SSH''' contextualization. Ssh service will be enabled.
* Add '''SSH public keys'''. Keys will be added to USERNAME authorized_keys file ([[#Custom Vars|See custom section]]) or to root in case USERNAME is not set.
* '''START_SCRIPT''' - Script which is executed when the machine starts up. It can contain either shell script or Shebang. For example START_SCRIPT="yum upgrade".

==='''''Files'''''===

[[File:Template-Files.png|768px]]

In this section you can include files in your vm. Files can be added in OpenNebula in "Files" section in the left menu under "Images".

You can select files from the list and they will be automatically added in FILES_DS attribute.

If the file is a script you want to run at boot you can add it INIT_SCRIPTS attribute.

==='''''Custom Vars'''''===

[[File:Template-CustomVars.png|768px]]

In this section you can setup a more advanced contextualization, the attributes available are:

*'''VARIABLE''' - Variables that store values related to this virtual machine or others . The name of the variable is arbitrary (in the example, we use hostname).

* '''SET_HOSTNAME''' - This parameter value will be the hostname of the VM.

* '''DNS_HOSTNAME''' - YES to set the VM hostname to the reverse dns name (from the first IP)

* '''GATEWAY_IFACE''' - This variable can be set to the interface number you want to configure the gateway. It is useful when several networks have GATEWAY parameter and you want yo choose the one that configures it. For example to set the first interface to configure the gateway you use GATEWAY_IFACE=0

* '''DNS''' - Specific DNS server for the Virtual Machine

* '''ETHx_MAC''' - Used to find the correct interface

* '''ETHx_IP''' - IPv4 address for the interface

* '''ETHx_IPV6''' - IPv6 address for the interface

* '''ETHx_NETWORK''' - Network address of the interface

* '''ETHx_MASK''' - Network mask

* '''ETHx_GATEWAY''' - Default IPv4 gateway for the interface

* '''ETHx_GATEWAY6''' - Default IPv6 gateway for the interface

* '''ETHx_MTU''' - MTU value for the interface

* '''ETHx_DNS''' - DNS for the network

* '''USERNAME''' - User to be created in the guest OS. If any password attribute is defined (see below) it will change this user (defaults to root). '''Please note:''' SSH daemon on the host is configured to deny access to user '''root''' and it does not support password authentication. If you specify '''USERNAME''' such account will be created and any SSH keys you may have configured will be allowed to login as that user. If you use any of the context variables below then password will be set for the user too. If username is not root you will be able to SSH in using SSH key and you will be able to login on the VNC console but you will '''not be able escalate your privileges''' to root. If username is '''root''' or you do not use '''USERNAME''' then you will be able to login on the VNC console but you will not be able to SSH in. '''Contextualization script always creates an user ''cloudUser'' which is allowed to login SSH using the keys you have configured in the template. Also cloudUser is allowed to elevate its privileges via sudo without password. the following command will make you root without password:'''
*: sudo -s

* '''CRYPTED_PASSWORD_BASE64''' - Crypted password encoded in base64. To be set for the user USERNAME. If not defined it will change root user. You can use the following command:
*: openssl passwd -1 | base64

* '''PASSWORD_BASE64''' - Password encoded in base64. To be set for the user USERNAME.

* '''CRYPTED_PASSWORD''' - Crypted password. To be set for the user USERNAME. This parameter is not recommended, use CRYPTED_PASSWORD_BASE64 instead. You can use the following command:
*: openssl passwd -1

* '''PASSWORD''' - Password to be set for the user USERNAME. This parameter is not recommended, use PASSWORD_BASE64 instead.

* '''SSH_PUBLIC_KEY''' - Key to be added to USERNAME authorized_keys file or root in case USERNAME is not set.

* '''EC2_PUBLIC_KEY''' - Same as SSH_PUBLIC_KEY

MediaWiki:Aboutsite

2017-03-28T07:36:50Z

Stoyan: Created blank page

MediaWiki:Privacy

2017-03-28T07:36:19Z

Stoyan: Created blank page

CipherSpace Client Wiki:About

2017-03-28T07:34:29Z

Stoyan:

This is the CipherSpace Client Wiki. It is a repository of information for our clients documenting the services we provide.

CipherSpace Client Wiki:About

2017-03-28T07:34:17Z

Stoyan: Blanked the page

MediaWiki:About

2017-03-28T07:33:57Z

Stoyan:

About

MediaWiki:About

2017-03-28T07:32:56Z

Stoyan: Created blank page

MediaWiki:Disclaimers

2017-03-28T07:32:28Z

Stoyan: Created blank page

OpenNebula Templates

2016-10-05T09:29:27Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
__TOC__

==Create a new Template==
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Templates” in the drop down menu.
#:[[File:Templates_menu.png|thumb|none|upright=0.5]]
#: 
#Click on the "+" button to create a new template. See below.
#Click "Create" button.
===Configure Template===
The basic procedure is as follows:
* Add a template name in "General" menu.
[[File:Template_name.png|thumb|none|upright=2]]

* In "Storage" tab, choose a storage disk. If your template requires more disks, click on "Add another disk" and select it accordingly.
[[File:Template_storage.png|thumb|none|upright=2.5]]

* In "Network" tab, select a Virtual Network, which the instantiated virtual machine(s) will be connected to. If your template requires more network interfaces, click on "Add another nic" and select it accordingly.
[[File:Template_interface.png|thumb|none|upright=2.5]]

* If a fixed ip address is required, click on "Advanced Option" button and type the fixed address in the "IP" field.
[[File:Template_adv_net_opt.png|thumb|none|upright=2.0]]

* In "Input/Output" menu, select "VNC" Graphics and tick "Generate Random Password".
[[File:Template_vnc.png|thumb|none|upright=1.5]]

* In "Context" menu, add SSH keys in the "Public Key" field and make sure that "Add SSH contextualization" and "Add Network contextualization" are ticked.
[[File:Template_context.png|thumb|none|upright=2.5]]

* In "Context" menu, you can define a root password under "Custom Vars". Add the following entries: KEY= ROOT_PASSWORD, VALUE= "password" and press "Add" button.
[[File:Template_rootpwd.png|thumb|none|upright=2.5]]

==Update a Template==
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Templates” in the drop down menu.
#:[[File:Templates_menu.png|thumb|none|upright=0.5]]
#: 
#Click on the template and press "Update" button.
#Make the necessary changes and press the green "Update" button to save.

CipherSpace Virtual Router

2016-10-05T09:26:59Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]

'''CipherSpace Virtual Router''' is based on '''OpenNebula Virtual Router''' (http://docs.opennebula.org/4.8/administration/networking/router.html) with some modifications plus OpenVPN. It is meant to be used as:
* Router (masquerade)
* DHCP server
* DNS server
* RADVD server
* Port forwarding server
* Bastion host for SSH tunnels
* OpenVPN server

CipherSpace Virtual Router allows using VMs which are not contextualized.

[[File:CipherSpace-VirtualRouter-Diagram.png|center]]

The virtual router image is non-persistent and takes its entire configuration from the contextualization script. Default VM size is 256MB RAM, 0.5 CPU and 1 vCPU.
You can install it from the Appmarket.

'''When using DHCP or OpenVPN make sure IP spoofing and MAC spoofing protections are turned off for the internal network.''' Otherwise it will not work.

== Virtual Router Configuration ==
Following configurations can be added in the virtual router template in "Context" menu under "Custom Vars".

The virtual router can be configured with 1 or 2 network interfaces. With 1 network interface it can be used only as '''DHCP''' or '''RADVD''' server.

* '''TEMPLATE''' - this is '''required'''. Otherwise most of the other functionality will not work. Usage:
TEMPLATE = "$TEMPLATE"

* '''PRIVNET''' - private network. For example:
PRIVNET = "$NETWORK[TEMPLATE, NETWORK=\"<private_network_name>\"]"

* '''PUBNET''' - public network. For example:
PUBNET = "$NETWORK[TEMPLATE, NETWORK=\"<public_network_name>\"]"

* '''RADVD''' - enables or disabled RADVD server. Possible values are '''YES''' and '''NO'''. For example
RADVD = "NO"

* '''DHCP''' - enables or disabled DHCP server. Possible values are '''YES''' and '''NO'''. For example
DHCP = "YES"

* '''DNS''' - list of DNS servers to use in DHCP leases. If not specified DHCP server will use VMs private network IP address. For example:
DNS = "10.1.1.1 10.2.2.2"

* '''SEARCH''' - DNS search option. For example:
SEARCH = "zh4.cipherspace.net"

* '''NTP_SERVER''' - IP of the NTP server. The DHCP server will be configured to serve the NTP parameter to its leases. For example:
NTP_SERVER = "10.0.0.10"

* '''FORWARDING''' - list of forwarding rules separated by spaces. Syntax:
[[protocol:]route_port:]destination:vm_port
'''protocol''' is not validated but it only makes sense to use '''tcp''' or '''udp'''.Default is '''tcp'''. If '''router_port''' is omitted too then port '''vm_port''' on the router will be forwarded to '''vm_port''' on the VM. For example:
FORWARDING = "udp:8888:10.0.0.10:53 8080:10.0.0.10:80 10.0.0.10:22"
{|
|style="text-align:right;"|<code lang="text">udp:8888:10.0.0.10:53</code>
|style="padding-left: 15px"|Forward UDP port 8888 on the router to port 53 on 10.0.0.10.
|-
|style="text-align:right;"|<code lang="text">8080:10.0.0.10:80</code>
|style="padding-left: 15px"|Forward TCP port 8080 on the router to port 80 on 10.0.0.10.
|-
|style="text-align:right;"|<code lang="text">10.0.0.10:22</code>
|style="padding-left: 15px"|Forward TCP port 22 the router to port 22 on 10.0.0.10.
|}

* '''ROOT_PASSWORD''' - base64 encoded '''root''' password hash. For example one can use the following command:
openssl passwd -1 | base64

* '''SSH_PUBLIC_KEY''' - single line, base64 encoded list of SSH keys to be set as '''root's authorized_keys'''. That is the '''Public key''' field in '''Context'''->'''Network & SSH'''. This is not a custom field. The way scripts are implemented they cannot parse parameters which contain 'new line' character. Because of that CipherSpace Virtual Router expects the value of SSH_PUBLIC_KEY to be a single base64 encoded string. That way we can pass multiple SSH keys. To generate the string you can use command like this:
cat <pub_key1> <pub_key2> ... <pub_keyN> | base64 | paste -s -d '\0' -

* '''SSHD''' - if set to YES and SSH_PUBLIC_KEY is set, then sshd will be launched. The idea is that Virtual Router VMs will not need active maintenance thus sshd does not need to be on all the time. If SSH_PUBLIC_KEY is set keys will be installed for root regardless of whether SSHD is enabled or not. That way one can login on the console and launch sshd if required. Command for Apline Linux is:
rc-service sshd start

* '''OPENVPN''' - controls whether OpenVPN should be started or not. If OPENVPN_CA_CERT, OPENVPN_SERVER_CERT and OPENVPN_SERVER_KEY are defined openvpn is configured but it is only launched if OPENVPN is set to YES. Please note that when image is instantiated and openvpn is configured it will take '''several minutes''', depending on allocated CPU, to boot because VM is generating DH 2048 bit parameters file.
* '''OPENVPN_CA_CERT''' - single line, PEM formatted, base64 encoded, Certification Authority certificate. That is the certificate used to sign OPENVPN_SERVER_CERT and all client certificates. Use the following command to encode:
cat ca.crt | base64 | paste -s -d '\0' -

* '''OPENVPN_SERVER_CERT''' - single line, PEM formatted, base64 encoded, server certificate.

* '''OPENVPN_SERVER_KEY''' - single line, PEM formatted, base64 encoded, server key

* '''OPENVPN_TA_KEY''' - optional but '''highly recommended''', single line, PEM formatted, base64 encoded, preshared key to use with '''--tls-auth'''. This features adds "extra protection" to the TLS channel by requiring that incoming packets have a valid signature generated using the PSK key. '''Key must be set on both server and client.''' If this key is ever changed, it must be changed on all peers at the same time.

* '''OPENVPN_REVOKED''' - optional, single line, base64 encoded content of a file containing revoked certificates.

* '''OPENVPN_INT_NET''' - Network to be used for communication between the server and the clients. It has to be different from the internal OpenNebula network and client's network. Is omitted it default to 10.255.255.0. It is good idea to use different networks especially in one client setup. That way one can have multiple tunnels at the same time if destination networks don't overlap of course.

* '''OPENVPN_INT_NETMASK''' - Network mask for the network between the server and the clients. Defaults to 255.255.255.0. '''Warning:''' OpenVPN is very picky. It will complain and it will not start if netmask zeros out any bit from the network. For example: net 10.1.1.1 netmask 255.255.255.0 will not work. One needs to use: net 10.1.1.0 netmask 255.255.255.0

* '''OPENVPN_MAX_CLIENTS''' - Maximum number of simultaneously connected users. It defaults to 3. Tests showed that is a good number for the default size VM.

CipherSpace Virtual Router can be used as a bastion host to build ssh tunnels. This is controlled by the following context variables:

* '''TUNNEL_USER''' - user name. '''It must not exist.''' If user exists it will not be reconfigured. That is to prevent messing up system users. User shell is set to /bin/false.

* '''TUNNEL_USER_SSH_PUBLIC_KEY''' - single line, base64 encoded, list of keys to install in '''authorized_keys''' file. Since it can can be multi-line it has to be formatted the same way as SSH_PUBLIC_KEY.

* '''TUNNEL_USER_KEY_RESTRICTIONS''' - optional string that goes before the key in authorized_keys file. Defaults to '''"no-pty,no-agent-forwarding,no-X11-forwarding,no-user-rc"'''. Even though user shell is set to /bin/false one must be careful what goes in this variable.

How To Manage OpenNebula Virtual Machines

2016-10-05T09:25:29Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
==Look at running Virtual Machines==

#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
#:A list of all instantiated virtual machines will apear. Some basic information is showed.
#:[[File:vm_list.png|thumb|none|upright=2.5]]
#: 
#:Click on a virtual machine to see all its configuration.
#:[[File:vm_detail.png|thumb|none|upright=2.5]]

==Open VNC console==
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
#Select the virtual machine you want to access and click on the "VNC" button.
#:[[File:vnc_button.png|thumb|none|upright=1]]
#: 
#:A flyout will appear with the virtual machine console. To move the console in a separate browser window or tab press [[File:expand_button.png|20px]] button.
#:[[File:vnc_view.png|thumb|none|900px]]

==Instantiate a Virtual Machine==

#Go to “Virtual Resources” in the left menu and click on “Templates” in the drop down menu.
#:[[File:Templates_menu.png|thumb|none|upright=0.5]]
#[[OpenNebula_Templates | Create or modify a template]]. This template will then be used to instantiate a virtual machine on which the operative system will be install.
#Click on the template just created and press "Instantiate" button to power on the virtual machine.
#:[[File:vm_instantiate.png|thumb|none|upright=1.2]]

==Terminate Virtual Machine Instances==
You can terminate a running instance with the following operations:
*'''shutdown''': Gracefully shuts down a running VM, sending the ACPI signal. Once the VM is shut down, the host is cleaned, and persistent disk(s) will be moved to the associated datastore. If after a given time the VM is still running (e.g. guest ignoring ACPI signals), OpenNebula will return the VM to the RUNNING state.
*'''shutdown --hard''': Same as above but the VM is immediately destroyed. Use this action instead of shutdown when the VM doesn’t have ACPI support.

If you need to terminate an instance in any state use:
*'''delete''': The VM is immediately destroyed no matter its state. Hosts are cleaned as needed but no images are moved to the repository, leaving then in error. Think of delete as "kill -9" for a process, an so it should be only used when the VM is not responding to other actions.

All the above operations free the resources used by the VM.
===Shutdown===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
#Click on the virtual machine, press the red button with the bin and click "Shutdown".
#:[[File:vm_shutdown.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be shut down, select each of them, press the red button with the bin and click "Shutdown".
#:[[File:vm_multishutdown.png|thumb|none|upright=2.5]]
===Shutdown Hard===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
#Click on the virtual machine, press the red button with the bin and click "Shutdown hard".
#:[[File:vm_shutdown_hard.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be shut down, select each of them, press the red button with the bin and click "Shutdown Hard".
#:[[File:vm_multishutdown_hard.png|thumb|none|upright=2.5]]
===Delete===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
#Click on the virtual machine, press the red button with the bin and click "Delete".
#:[[File:vm_delete.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be shut down, select each of them, press the red button with the bin and click "Delete".
#:[[File:vm_multidelete.png|thumb|none|upright=2.5]]

==Pause Virtual Machine Instances==
'''Be aware that VMs, which are in some of the states below, may still occupy resources even though they are not actually running. Those resources will be accounted for and, based on your subscription plan, can be charged to you.'''

There are two different ways to temporarily stop the execution of a VM: short and long term pauses. A short term pause keeps all the VM resources allocated to the hosts so its resume its operation in the same hosts quickly. Use the following actions:
*'''suspend''': the VM state is saved in the running Host. When a suspended VM is resumed, it is immediately deployed in the same Host by restoring its saved state.
*'''poweroff''': Gracefully powers off a running VM by sending the ACPI signal. It is similar to suspend but without saving the VM state. When the VM is resumed it will boot immediately in the same Host.
*'''poweroff --hard''': Same as above but the VM is immediately powered off. Use this action when the VM doesn’t have ACPI support.

You can also plan a long term pause. The Host resources used by the VM are freed and the Host is cleaned. Any needed disk is saved in the system datastore. The following actions are useful if you want to preserve network and storage allocations (e.g. IPs, persistent disk images):
*'''undeploy''': Gracefully shuts down a running VM, sending the ACPI signal. The Virtual Machine disks are transferred back to the system datastore. When an undeployed VM is resumed, it is be moved to the pending state, and the scheduler will choose where to re-deploy it.
*'''undeploy --hard''': Same as above but the running VM is immediately destroyed.
*'''stop''': Same as undeploy but also the VM state is saved to later resume it.

When the VM is successfully paused you can resume its execution with:

*'''resume''': Resumes the execution of VMs in the stopped, suspended, undeployed and poweroff states.
===Suspend===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the hold button and click "Suspend".
#:[[File:vm_suspend.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be suspended, select each of them, press the hold button and click "Suspend".
#:[[File:Vm_multisuspend.png|thumb|none|upright=2.5]]
===Poweroff===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the hold button and click "Poweroff".
#:[[File:vm_poweroff.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be powered off, select each of them, press the hold button and click "Poweroff".
#:[[File:Vm_multipoweroff.png|thumb|none|upright=2.5]]
===Poweroff Hard===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the hold button and click "Poweroff Hard".
#:[[File:vm_poweroff_hard.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be powered off hard, select each of them, press the hold button and click "Poweroff Hard".
#:[[File:Vm_multipoweroff_hard.png|thumb|none|upright=2.5]]
===Undeploy===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the stop button and click "Undeploy".
#:[[File:vm_undeploy.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be undeployed, select each of them, press the stop button and click "Undeploy".
#:[[File:Vm_multiundeploy.png|thumb|none|upright=2.5]]
===Undeploy Hard===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the stop button and click "Undeploy Hard".
#:[[File:vm_undeploy_hard.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be undeployed hard, select each of them, press the stop button and click "Undeploy Hard".
#:[[File:Vm_multiundeploy_hard.png|thumb|none|upright=2.5]]
===Stop===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the stop button and click "Stop".
#:[[File:vm_stop.png|thumb|none|upright=1.5]]
#:If more than one virtual machine need to be stopped, select each of them, press the stop button and click "Stop".
#:[[File:Vm_multistop.png|thumb|none|upright=2.5]]
===Resume===
#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
#Go to “Virtual Resources” in the left menu and click “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#Click on the virtual machine, press the play button to resume.
#:[[File:vm_resume.png|thumb|none|upright=1]]
#:If more than one virtual machine need to be resumed, select each of them, press the play button to resume.
#:[[File:Vm_multiresume.png|thumb|none|upright=2.5]]

How To Use OpenNebula AppMarket

2016-09-22T06:01:18Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]

1. Open OpenNebula Sunstone and [[OpenNebula_Administrative_Functions | login]].

2. Go to “AppMarket” in the left menu and click “Appliances” in the drop down menu.

A list of all available appliances will appear.
[[File:appmarket page.png|thumb|none|900px]]

Every appliance contains an image and an example template. Click on one appliance to view more details.
[[File:Appmarket_info.png|thumb|none|upright=3.0]]

3. To import an appliance, select it and click “Import” button.
[[File:appmarket select.png|thumb|none|900px]]

A flyout will appear asking for a new image and new template name. '''It is very important to change the proposed image and template names otherwise import may fail because image or a template with the same name may already exist.'''
[[File:appmarket_import.png|thumb|none|900px]]

4. Go to “Virtual Resources” in the left menu to see the image and the template just imported. '''Remember to [[How To Create OpenNebula Template | adjust]] the template to your preferences before instantiating a new virtual machine.'''
[[File:appmarket_templates.png|thumb|none|900px]]
[[File:Appmarket_images.png|thumb|none|900px]]

How To Create a New Disk Image in OpenNebula

2016-09-20T08:40:05Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
1.[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].

2. Go to “Virtual Resources” in the left menu and click on “Images” in the drop down menu.
[[File:Img_menu.png|thumb|none|upright=0.5]]

3. Click the "+" button to add a new image.

[[File:Add_img_options.png|thumb|none|upright=2.5]]

The following parameters must be specified:
* Name = "your image name"
* Type = DATABLOCK
* Tick Persistent
* Set Image Location to Empty datablock
* Size = "your required space in MB"
* FS type = qcow2

4. Open "Advanced Options".
[[File:New_img_advanced_options.png|thumb|none|upright=2]]

Fill in the following fields:
* Device Prefix = vd
* Driver = qcow2

5. Click on the "Create" button.

How To Use OpenNebula AppMarket

2016-09-20T08:39:31Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]

1. Open OpenNebula Sunstone and [[OpenNebula_Administrative_Functions | login]].

2. Go to “AppMarket” in the left menu and click “Appliances” in the drop down menu.

A list of all available appliances will appear.
[[File:appmarket page.png|thumb|none|900px]]

Every appliance contains an Image and a default Template. Click on one appliance to view more details.
[[File:Appmarket_info.png|thumb|none|upright=3.0]]

3. To import an appliance, select it and click “Import” button.
[[File:appmarket select.png|thumb|none|900px]]

A flyout will appear asking for a new Image and Template name. '''It is very important to change the proposed Image and Template names.'''
[[File:appmarket_import.png|thumb|none|900px]]

4. Go to “Virtual Resources” in the left menu to see the Image and the Template just imported. Remember to personalize the template before instantiating a new virtual machine.
[[File:appmarket_templates.png|thumb|none|900px]]
[[File:Appmarket_images.png|thumb|none|900px]]

OpenNebula Administrative Functions

2016-09-20T08:39:09Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
== Log into OpenNebula ==

As a CipherSpace vDC customer, you have received a website address as well as your username and temporary password.

Type in your browser the website address. You should see the following screen:

[[File:one_admin_log1.png|240px]]

Type in your username and password and click on “Login”:

[[File:one_admin_log2.png|240px]]

You will then arrive on the Dashboard screen, from where you will then be able to access the various OpenNebula functions.

[[File:one_admin_log3.png|border|800px]]

== Password Change ==

To change your temporary password, click on your username at the top-right of the dashboard screen:

[[File:one_admin_pwch1.png|border|240px]]

And then click on “Settings”:

[[File:one_admin_pwch2.png|border|240px]]

The Configuration screen appears:

[[File:one_admin_pwch3.png|border|600px]]

Click on “Update password”:

[[File:one_admin_pwch4.png|border|400px]]

The Update Password screen appears:

[[File:one_admin_pwch5.png|border|300px]]

Type and confirm your new password and click on “Change”. You can now log in using your new password.

== View Change ==

A vDC user has access to two different user interfaces: the “User” view and the “Cloud” view. The “User” view allows the user to access the more advanced functionalities of OpenNebula. The “Cloud” view is a simplified user interface, which allows a user to deploy virtual machines (VMs) and to monitor and manage the running VMs as well as other limited functionalities.

To change to the “Cloud” view, start from the “Configuration” Screen (see [[#Password Change|Password Change]]) and click on “Conf”:

[[File:one_admin_viewch1.png|border|600px]]

Click on “Views:” and select the “cloud” view:

[[File:one_admin_viewch2.png|border|600px]]

And then click on “Update config”. You are now in the cloud view:

[[File:one_admin_viewch3.png|border|600px]]

To go back to the “User” view, click on your username at the top-right of the screen:

[[File:one_admin_viewch4.png|border|600px]]

Then click on “Change view”:

[[File:one_admin_viewch5.png|border|450px]]

Click on “cloud”, then select “user” and finish by clicking on “Update view”. You are now back to the “User” view.

== View Quotas ==

You can see how much of your vDC is used either on the Dashboard under Quotas:

[[File:one_admin_vq1.png|border|630px]]

Or in the Configuration screen by clicking on “Quotas” and then clicking on “Group Quotas”:

[[File:one_admin_vq2.png|border|600px]]

== Accounting ==

You can see how many resources you have been using the “Accounting” function. You can access it either from the Dashboard (under the “Quotas” information) or in the Configuration screen by clicking on “Accounting”:

[[File:one_admin_acc1.png|border|600px]]

Select a time period and click on “Get Accounting”. A similar screen appears with the corresponding information.

[[File:one_admin_acc2.png|border|800px]]

By clicking on “Accounting Tables”, you can see your data in tabular form.

How To Build New OpenNebula Image Using ISO file

2016-09-20T08:38:15Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
1. You can use an existing ISO image or you can [[How_To_Upload_ISOs_On_OpenNebula | upload a new one]].

2. [[How_To_Create_OpenNebula_Datablock | Create an empty disk image where the operating system will be installed]].

3. [[OpenNebula_Templates | Create or modify a template]]. This template will then be used to instantiate a virtual machine on which the operating system will be install.

* Add the ISO image and the empty image in "Storage" menu
* Configure the boot order in the template in "OS Booting" menu, choosing the ISO image (CDROM) as first option
[[File:template_bootorder.png|thumb|none|upright=2]]

4. Click on the template just created and press "Instantiate" button to power on the virtual machine.
[[File:vm_instantiate.png|thumb|none|upright=1.2]]

5. Install the operating system.
Once the operating system is installed, [[How_To_Manage_OpenNebula_Virtual_Machines#Shutdown_a_Virtual_Machine | shutdown]] the virtual machine.

6. Go to “Virtual Resources” in the left menu, click on “Images” in the drop down menu and select the disk image on which you installed the operating system.

7. Click on the [[File:Img_changetype.png|50px]] icon next to the "type" field and modify the image type from "DATABLOCK" to "OS".
[[File:img_toos.png|thumb|none|upright=1.5]]

8. Go to “Virtual Resources” in the left menu, click on “Templates” in the drop down menu and select the template used to instantiate the virtual machine.
* Remove the uploaded ISO file in "Storage" menu
* "OS Booting" menu change "1st boot" to nothing.
[[File:Template_afterinstall.png|thumb|none|upright=2]]

Now you can use this template to instantiate a VM.

How To Upload ISOs On OpenNebula

2016-09-20T08:25:05Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]
__TOC__

==Upload an ISO using an URL==

1.[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].

2. Go to “Virtual Resources” in the left menu and click on “Images” in the drop down menu.
[[File:Img_menu.png|thumb|none|upright=0.5]]

3. Click on the "+" button to add a new image.

[[File:Add_iso_path_options.png|thumb|none|upright=2.5]]

The following parameters must be specified:
* Name = "your image name"
* Type = CDROM
* Set Image Location to "Provide a path"
* Path = "The URL of the ISO image"

4. Open "Advanced Options".
[[File:New_img_advanced_options.png|thumb|none|upright=2]]
Fill in the following fields:
* Device Prefix = vd
* Driver = qcow2

5. Click "Create" button.

==Upload a local ISO image==

1.[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].

2. Go to “Virtual Resources” in the left menu and click on “Images” in the drop down menu.
[[File:Img_menu.png|thumb|none|upright=0.5]]

3. Click on the "+" button to add a new image.
[[File:Add_iso_upload_options.png|thumb|none|upright=2.5]]
The following parameters must be specified:
* Name = "your image name"
* Type = CDROM
* Set Image Location to "Upload"
* Click "Browse.." button and select the image on your local PC

4. Open "Advanced Options".
[[File:New_img_advanced_options.png|thumb|none|upright=2]]
Fill in the following fields:
* Device Prefix = vd
* Driver = qcow2

5. Click "Create" button.

OpenNebula Attach Additional Storage To A Virtual Machine

2016-09-20T08:03:24Z

Stoyan:

[[Category:OpenNebula]]
[[Category:How To]]

#[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].
# You can attach and existing disk image or [[How To Create a New Disk Image in OpenNebula | you can create a new one.]]
# Go to “Virtual Resources” in the left menu and click on “Virtual Machines” in the drop down menu.
#:[[File:VM_menu.png|thumb|none|upright=0.5]]
#: 
# Click on the virtual machine you need to add the storage and go to "Storage" menu.
#:[[File:vm_storage_menu.png|thumb|none|upright=2.5]]
#: 
# Click on the "Attach Disk" button. A flyout will appear where you can select the image you want to attach.
#:[[File:vm_attach_disk.png|thumb|none|upright=2.5]]
#: 
# Click on "Advanced Option" and select "none" as cache option.
#:'''Warning: without that option VM cannot be live migrated. In case the server it is running on needs to be taken out for maintenance your and will have to be shutdown.'''
#:[[File:Attach_cache.png|thumb|none|upright=1.5]]
#: 
# Click on the "Attach" button to add the storage to the Virtual Machine.
#: 
# If you want to have the storage attached to the virtual machine next time it is instantiated, you must update the machine's template accordingly. See [[OpenNebula_Templates#Configure Template| Configure Template]].

How To Create OpenNebula Datablock

2016-09-20T07:47:49Z

Stoyan: Stoyan moved page How To Create OpenNebula Datablock to How To Create a New Disk Image in OpenNebula

#REDIRECT [[How To Create a New Disk Image in OpenNebula]]

How To Create a New Disk Image in OpenNebula

2016-09-20T07:47:49Z

Stoyan: Stoyan moved page How To Create OpenNebula Datablock to How To Create a New Disk Image in OpenNebula

1.[[OpenNebula_Administrative_Functions | Log into OpenNebula Sunstone]].

2. Go to “Virtual Resources” in the left menu and click on “Images” in the drop down menu.
[[File:Img_menu.png|thumb|none|upright=0.5]]

3. Click the "+" button to add a new image.

[[File:Add_img_options.png|thumb|none|upright=2.5]]

The following parameters must be specified:
* Name = "your image name"
* Type = DATABLOCK
* Tick Persistent
* Set Image Location to Empty datablock
* Size = "your required space in MB"
* FS type = qcow2

4. Open "Advanced Options".
[[File:New_img_advanced_options.png|thumb|none|upright=2]]

Fill in the following fields:
* Device Prefix = vd
* Driver = qcow2

5. Click on the "Create" button.

How To Use OpenNebula AppMarket

2016-09-20T07:25:57Z

Stoyan:

1. Open OpenNebula Sunstone and [[OpenNebula_Administrative_Functions | login]].

2. Go to “AppMarket” in the left menu and click “Appliances” in the drop down menu.

A list of all available appliances will appear.
[[File:appmarket page.png|thumb|none|900px]]

Every appliance contains an Image and a default Template. Click on one appliance to view more details.
[[File:Appmarket_info.png|thumb|none|upright=3.0]]

3. To import an appliance, select it and click “Import” button.
[[File:appmarket select.png|thumb|none|900px]]

A flyout will appear asking for a new Image and Template name. '''It is very important to change the proposed Image and Template names.'''
[[File:appmarket_import.png|thumb|none|900px]]

4. Go to “Virtual Resources” in the left menu to see the Image and the Template just imported. Remember to personalize the template before instantiating a new virtual machine.
[[File:appmarket_templates.png|thumb|none|900px]]
[[File:Appmarket_images.png|thumb|none|900px]]