Nebula addon context linux

OpenNebula Linux VM Contextualization

This addon provides contextualization packages for the Linux (and, other Unix-like) guest virtual machines running in the OpenNebula cloud. Based on the provided contextualization parameters, the packages prepare the networking in the running guest virt. machine, configure SSH keys, set passwords, run custom start scripts, and many others.

Latest versions can be downloaded from the release page. Check the supported OpenNebula versions for each release.

Documentation on packages installation and guest contextualization can be found in the latest stable OpenNebula Operation Guide. For beta releases, refer to the latest development documentation.

List of tested platforms only:

Platform	Versions
AlmaLinux	8
Alpine Linux	3.11, 3.12, 3.13, 3.14
ALT Linux	p9, p10, Sisyphus
Amazon Linux	2
CentOS	7, 8, 8 Stream
Debian	8, 9, 10, 11
Devuan	2
Fedora	32, 33, 34
FreeBSD	11, 12, 13
openSUSE	15, Tumbleweed
Oracle Linux	7, 8
Red Hat Enterprise Linux	7, 8
Rocky Linux	8
Springdale Linux	8
Ubuntu	14.04, 16.04, 18.04, 20.04, 21.04

(the packages might work on other versions or flavours, but those aren’t tested)

Guest Network Configuration (since 6.1.80)

The context scripts support selectable guest network management service (a component in guest OS responsible for assigning IP addresses, routes, and bringing interfaces up). Following network configuration types can be selected by setting the context variable NETCFG_TYPE (empty default fallbacks to autodetection of the most suitable one for a particular platform):

bsd for FreeBSD network configuration,
interfaces for Debian-style configuration in /etc/network/interfaces ,
netplan for Netplan with following renders set in context variable NETCFG_NETPLAN_RENDERER :
- empty or networkd for systemd-network (default),
- NetworkManager for NetworkManager
networkd for systemd-networkd,
nm for NetworkManager,
scripts for legacy Red Hat-style configuration via /etc/sysconfig/network-scripts/ifcfg-ethX files.

Interface IP address configuration method can be customized as well. Following IPv4 configuration methods are supported via NIC attribute METHOD :

empty or static for static address assignment based on context variables,
dhcp for DHCPv4,
skip to skip IPv4 configuration.

Following IPv6 configuration methods are supported via NIC attribute IP6_METHOD :

empty or static for static address assignment based on context variables,
auto for SLAAC,
dhcp for SLAAC and DHCPv6,
disable to disable IPv6 in guest,
skip to skip IPv6 configuration.

Selectable configuration types and IP configuration methods are supported only on the following platforms:

Platform	Network Type ( NETCFG_TYPE )
Alpine Linux 3.14	interfaces
ALT Linux p9, p10, Sisyphus	networkd , nm
Amazon Linux 2	scripts
Debian 9	interfaces
Debian 10, 11	interfaces , netplan , nm , networkd
Devuan 2	interfaces
Fedora 34	scripts , nm , networkd
FreeBSD 11, 12, 13	bsd
openSUSE 15, Tumbleweed	scripts
RHEL-like 7 (CentOS, Oracle Linux)	scripts
RHEL-like 8 (CentOS, Oracle/Rocky/Alma/Springdale Linux)	scripts , nm , networkd
Ubuntu 18.04, 20.04, 21.04	interfaces , netplan , nm , networkd

(other than listed platforms are not supported for using NETCFG_TYPE nor METHOD / IP6_METHOD !):

Alpine Linux: IP6_METHOD=dhcp runs DHCPv4 client instead of DHCPv6,
Debian 10: NETCFG_TYPE=netplan with networkd doesn’t configure IPv6 (only) SLAAC ( IP6_METHOD=auto ) when no IPv4 is configured,
Debian/Ubuntu: NETCFG_TYPE=netplan with NetworkManager might not configure IPv6 SLAAC ( IP6_METHOD=auto ) for hot-plugged interfaces,
Debian 10 and Ubuntu 18.04, 20.04: might trigger DHCPv6 with IP6_METHOD=auto
- on NETCFG_TYPE=netplan with networkd,
- on NETCFG_TYPE=networkd .

Build own package

Packages for each release for supported guests are available in the release page. Also, any version can be built by the scripts provided in this repository.

Linux host
Ruby >= 1.9
gem fpm >= 1.10.0
dpkg utils for deb package creation
rpm utils for rpm package creation

The script generate.sh is able to create all package types and can be configured to include more files in the package or change some of its parameters. Package type and content are configured by the env. variable TARGET , the corresponding target must be defined in target.sh . Target describes the package format, name, dependencies, and files. Files are selected by the tags. Set of required tags is defined for the target (in targets.sh ), each file has a list of corresponding tags right in its filename (divided by the regular name by 2 hashes ## , dot-separated).

Package name or version can be overridden by env. variables NAME and VERSION .

NOTE: The generator must be executed from the same directory it resides.

Check generate.sh for general package metadata and targets.sh for the list of targets and their metadata. Most of the parameters can be overriden by the appropriate environment variable.

To contribute bug patches or new features, you can use the github Pull Request model. It is assumed that code and documentation are contributed under the Apache License 2.0.

All code is located under src/ and structure follows the installation directory structure. Files for different environments/targets are picked by the tag, tags are part of the filename separated from the installation name by 2 hashes ( ## ). Tags are dot-separated.

script — non-tagged file for all targets
script##systemd — file tagged with systemd
script##systemd.rpm — file tagged with systemd and rpm

Contextualization scripts, which are executed on every boot and during the reconfiguration, are located in src/etc/one-context.d/ . Scripts are divided into following 2 parts:

local — pre-networking, prefixed with loc-
post-networking, prefixed with net-

All other scripts, which are not prefixed with loc- or net- , are executed as a first during the post-networking contextualization stage.

Licensed under the Apache License, Version 2.0 (the «License»); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an «AS IS» BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Источник

Open Cloud Contextualization¶

Prepare the Virtual Machine Image¶

Step 1. Start a VM with the OS you want to Customize¶

Supported contextualization packages are available for the OS’s described in the platform notes .

Step 2. Download Contextualization Packages to the VM¶

RHEL 6.x (CentOS 6.x)¶

RHEL 7.x (CentOS/Oracle Linux 7.x)¶

RHEL 8.x (CentOS/AlmaLinux/Oracle Linux 8.x) and Fedora 29+¶

Debian/Ubuntu/Devuan¶

OpenSUSE 15 and Tumbleweed¶

ALT Linux p9, Sisyphus¶

Alpine Linux¶

FreeBSD 11, 12¶

Windows¶

Download the MSI package into C:\ :

Or execute this command in powershell:

Step 3. Install Contextualization Packages and Dependencies¶

RHEL 6.x (CentOS 6.x)¶

RHEL 7.x (CentOS/Oracle Linux 7.x)¶

RHEL 8.x (CentOS/AlmaLinux/Oracle Linux 8.x) and Fedora 29+¶

OpenSUSE¶

ALT Linux¶

Debian/Ubuntu/Devuan¶

Alpine Linux¶

FreeBSD¶

Windows¶

Double-click on the downloaded MSI package icon in the same way you open other documents to install it.

Step 4. Run Sysprep in Windows Machines¶

Execute sysprep to prepare the OS for duplication. You can find more information at:

Step 5. Power Off the Machine and Save it¶

After these configuration is done you should power off the machine, so it is in a consistent state the next time it boots. Then you will have to save the image.

If you are using OpenNebula to prepare the image you can use the command onevm disk-saveas , for example, to save the first disk of a Virtual Machine called “centos-installation” into an image called “centos-contextualized” you can issue this command:

Using sunstone web interface you can find the option in the Virtual Machine storage tab.

Set Up the Virtual Machine Template¶

The Virtual Machine Template has a section called context where you can automate different configuration aspects. The most common attributes are network configuration, user credentials and startup scripts. These parameters can be both added using the CLI to the template or using Sunstone Template wizard. Here is an example of the context section using the CLI:

In the example we are telling OpenNebula to:

Set OneGate token and onegate information in the context
Add network configuration to the Virtual Machine
Enable login into the Virtual Machine using ssh with the value of the user’s parameter SSH_PUBLIC_KEY
On Virtual Machine boot execute the command yum install -y ntpdate

OneGate Token¶

OpenNebula has a centralized service to share data between Virtual Machines and the main daemon, useful to set monitoring information that can be gathered inside the VM and configuration data. It also lets you send scaling actions when the Virtual Machine belongs to a Service.

To do so the client installed with the contextualization packages ( onegate ) needs some information:

Token: it’s the key specific to each VM used to authenticate with the service
OneGate endpoint: the address where the OneGate daemon is reachable

To fill this information you have to specify TOKEN = «YES» in the contextualization section.

Network Configuration¶

OpenNebula does not rely on a DHCP server to configure networking in the Virtual Machines. To do this configuration it injects the network information in the contextualization section. This is done with option NETWORK = «YES» . When OpenNebula finds this option it adds the IP information for each of the network interfaces configured plus extra information that resides in the Virtual Network template, like DNS, gateway and network mask.

The parameters used from the Virtual Network template are explained in the Managing Virtual Networks section .

User Credentials¶

One of the other very important things you have to configure is user credentials to connect to the newly created Virtual Machine. For linux base images we recommend to use SSH public key authentication and using it with OpenNebula is very convenient.

The first thing the users should do its to add their SSH public key (or keys) to its OpenNebula user configuration. This can be done in the Settings section of the web interface or using the command line interface:

Then in the Virtual Machine Template we add the option:

Using this system the new Virtual Machines will be configured with the SSH public key of the user that instantiated it.

For Windows machines SSH is not available but you can use the options USERNAME and PASSWORD to create and set the password of an initial administrator.

This password is encrypted in the virtual machine and in the virtual machine template.

Execute Scripts on Boot¶

To be able to execute commands on boot, for example, to install some software, you can use the option START_SCRIPT . When this option is used a new file that contains the value of the option will be created and executed.

For Windows machines this is a PowerShell script. For linux machines this can be any scripting language as long as it is installed in the base image and the proper shebang line is set (shell scripts don’t need shebang).

In this example some commands will be executed using bash shell that will install the package ntpdate and set the time.

To add more complex scripts you can also use the option START_SCRIPT_BASE64 . This option gets a base64 encoded string that will be decoded before writing the temporary script file.

Advanced Contextualization¶

There are more options that can be set in the contextualization section. You can read about them in the Virtual Machine Definition File reference section

Источник