Customize the initial setup for your Virtual Machine
Why automate the initial setup?
Automating the initial setup saves time and effort, eliminates manual tasks, reduces errors, ensures consistency, enables scalability, and allows you to focus on more valuable tasks. This is where the User Data field in the Virtual Machine setup page can assist you. By using the User Data field, you can:
- Set a password for a VM
- Create a user
- Configure groups
- Add an SSH key
- Add repositories and Install packages
- Write files
- Configure network interfaces
You can access and use the User Data field in three ways:
From the customer portal
By default, the User Data field is disabled for new Virtual Machines (VMs). Enable it by switching on the toggle and adding your User Data content in the textbox.
From Gcore’s API
To add the User Data field when creating a new VM via Gcore API, provide your User Data content in base64
format via user_data
in the payload request.
Let’s say you want to add the User Data field as below:
First, you must encode this content in base64
format. You can use the base64
command line tool to do so.
The encoded base64
result should look similar to this:
Then, make an API request with the user_data
field provided in the payload to create a new VM:
From Terraform
A new Virtual Machine with the User Data field setup can also be created using Terraform. Encode your User Data field value to base64
format first, then provide the encoded value to the user_data
field in the Terraform definition file as below:
The User Data field features were built based on cloud-init
, an industry-standard multi-distribution method for cross-platform cloud VM initialization.
What is cloud-init?
Cloud-init
is an industry-standard software for automating the initialization of cloud Virtual Machines. You can use cloud-init
to perform a number of initial tasks when your VM is booted for the first time, such as installing packages, running a shell script, or configuring the network interfaces.
Cloud-init
supports all major Linux distributions:
- Alpine Linux
- ArchLinux
- Debian
- DragonFlyBSD
- Fedora
- FreeBSD
- Gentoo Linux
- NetBSD
- OpenBSD
- Photon OS
- RHEL/CentOS/AlmaLinux/Rocky Linux/EuroLinux
- SLES/openSUSE
- Ubuntu
It uses a YAML-based syntax, allowing the desired setup to be easily represented.
Set a password for a Virtual Machine
By default, Gcore Virtual Machine does not allow SSH authentication using username and password alone; only machines with a matching SSH key are allowed to access the VM.
To override this default configuration, set ssh_pwauth: True
in the User Data field. Below is an example configuration of how to set your Virtual Machine to be accessible using a default username and password.
-
The
password
field sets the password value for your Virtual Machine’s default username. Depending on the VM image, the username may vary. For example, if you create a Virtual Machine using the Ubuntu distro, your default username will beubuntu
-
With the
chpasswd: { expire: False }
configuration, you do not need to change the password of your default user after you access the VM -
ssh_pwauth: True
allows your Virtual Machine to be accessible using a username and password -
The
power_state
block option tellscloud-init
to wait 30 seconds for thecloud-init
process to finish before shutting down the system
After the Virtual Machine is up and running, you can access the VM using the ssh command below:
Provide your password value; you should now be able to access the Virtual Machine.
Create a user
With the User data field, you can create a new user in the Virtual Machine.
Let’s say you want to create a user called guest
with the same password as the first user. Here’s the example of a cloud-init
script for creating this guest
user:
Description of configuration parameters:
-
sudo
: Gives superuser rights to the guest user by setting the valueALL=(ALL) NOPASSWD:ALL
. -
passwd
: Provides an encrypted value of your password according to the SHA-512 encryption method. To generate the SHA-512 encrypted value, you can use themkpasswd
command line tool:
-
groups
: Lists all groups theguest
user will belong to. In this configuration, the user will be automatically added to theusers
andadmin
groups. If you want to add the user to other groups, first make sure that these groups exist. -
lock_passwd
: When set tofalse
, this value allows you to access the Virtual Machine with a username and password. -
shell
: When set tobin/bash
, this value defines the default shell asbash
for theguest
user.
After you configure user data, wait a few minutes for your Virtual Machine to launch and use the guest
user to access the VM:
1. Run the following command: ssh guest@your_instance_ip
.
2. Type guest
and press Enter.
You should now be able to log in to your guest user account.
Info
To check for the groups that the guest
user belongs to, run the command groups
. You should see the users
and admin
groups listed, indicating that the guest
user belongs to the users
and admin
groups.
Enable root user
When creating a Virtual Machine, you can enable user access to the root by adding the following line to the User data field:
For details on how to enable user access to root after creating a Virtual Machine, read our guide.
Configure user groups
You can also configure user groups, such as creating a new one. For example, you can create a new user group called regular-users
by adding the below line to the User Data field:
After your VM is ready, access it via ssh and run the following command to list all user groups in the system:
The regular-users
group should be displayed at the bottom of the result.
Add an SSH key
There are times when you want your new Virtual Machine to be accessible from other machines. For example, some of your colleagues may also want to use your VM, or you might want to set up a cluster of Virtual Machines to create an Apache Hadoop or Apache Spark cluster. To do so, you need to add the public SSH keys of other machines to the User Data field.
Below is an example of how to add a public SSH key of another machine to the new Virtual Machine:
Once the Virtual Machine is up and running, you can view the content of authorized_keys
by running the below command:
You should see the configured ssh-rsa key listed in the result. The other machines should also be able to access this Virtual Machine via SSH.
Add repositories and install packages
When using the Virtual Machine, the default installed packages are usually not sufficient for you to perform your tasks. For example, if you’re a software engineer, you need to use docker to build the application image, or use nmap
and traceroute
to debug your application network.
Adding the below configuration into your User Data field helps you install the docker
, nmap
, and traceroute
tools when the VM boots up.
With packages that are available in the default VM repository like nmap
and traceroute
, you only need to include them in the packages
block. However, with packages that are not available in the default instance repository— like docker-ce
and docker-ce-cli
—you need to add the Docker repository first using apt sources
.
After installing, restart the Virtual Machine so that these packages are added to the system path. Including the power_state
block at the end of the User Data field is helpful because it allows you to use these tools as soon as the Virtual Machine is ready.
Write files
Sometimes it may be helpful to have existing files for usage after the Virtual Machine is ready. For example, you could have a YAML file that contains example scripts for working with Docker. Using the feature below, you can create a file named useful-docker-script.yaml
in the /root
directory.
Access the Virtual Machine once it is available, and run the following command to check whether the new file useful-docker-script.yaml
has been created:
You should see a result similar to the below:
Run the following command to view the content of the file useful-docker-script.yaml
.
You should see a similar output to this:
Configure network interfaces
You can also configure network interfaces using the User Data field. For example, you can add a static IP address to your Virtual Machine network interface. Having a static IP address offers benefits such as:
- Allowing you to host a web server using the static IP
- Allowing other Virtual Machines access to your VM reliably using the static IP
When your Virtual Machine is created, cloud-init
will generate a new file named 50-cloud-init.yaml
in the /etc/netplan
directory and create a new network interface based on that file. To add a static IP address to the network interface, you need to create another file in the /etc/netplan
other than 50-cloud-init.yaml
. When cloud-init
creates the network interface, it will try to merge the content of these two configuration files. As a result, the static IP address will be added to the network interface. Below is an example content of the 50-cloud-init.yaml
file.
To add a static IP to the enp3s0
network interface, you can add the below content to the User Data field.
Cloud-init
will execute two steps based on this configuration.
-
First,
cloud-init
will create a new file named00-add-static-ip.yaml
in/etc/netplan
with instructions to add static IP addresses for both IPv4 (192.170.1.25) and IPv6 (2020:1::1.) The permission of the file is 0644, which means it is readable by any user and writable bycloud-init
. -
When the Virtual Machine is rebooted (using the
power_state
block configuration),cloud-init
will try to merge the network configuration for both00-add-static-ip.yaml
and50-cloud-init.yaml
files so that you can add static IP addresses to theenp3s0
network interface.
Access the Virtual Machine once it is ready, and run the following command:
You should see something similar to this:
Notice in the enp3s0 interface, the static IP address for IPv4 is 192.170.1.25
and for IPv6 it is 2020:1::1
.
Check Cloud-Init logs for errors
If you encounter any issues with cloud-init
, you can check the logs to identify the problem. There are two main log files on your instances.
Cloud-init log
The cloud-init
log is located at /var/log/cloud-init.log
and contains detailed information about the cloud-init
process, including any errors that occur.
To view the cloud-init
log, run the following command:
You should see the log output similar to this:
Cloud-init output log
The cloud-init-output
log is located at /var/log/cloud-init-output.log
and contains the output of the scripts the cloud-init
process runs.
To view the cloud-init-output
log, run the following command:
You should see the log output similar to this: