¶ Logging In
Go to the Science Cloud dashboard at https://coarecloud2.asti.dost.gov.ph dashboard. Enter the User Name and temporary Password sent by the COARE Team via e-mail.
NOTE: The COARE Science Cloud is ONLY accessible when connected to the COARE VPN.
¶ Dashboard
After logging in, the page will be redirected to the OpenStack Dashboard. The default landing page is the project's quota overview and usage summary.
On the left-hand side portion of the page is the Navigation Bar containing different tabs for various operations:
- Project
- API Access - List relevant API addresses
- Compute - Manage compute resources
- Overview - Show project quota and usage
- Instances - Manage instances (virtual machines)
- Images - Manage images
- Key Pairs - Manage SSH key pairs
- Server Groups – Manage instance grouping and scheduling policies for high availability or anti-affinity
- Volumes - Manage volumes (virtual disks)
- Volumes - Manage volumes (virtual disks)
- Snapshots - Create and manage point-in-time copies of volumes
- Groups - Manage collections of volumes for replication or consistency
- Group Snapshots - Create and manage snapshots of entire volume groups
- Network - Manage network resources
- Network Topology - Show a diagram of configured networks
- Networks - Manage project networks
- Routers - Manage routers
- Security Groups - Manage inbound and outbound IP protocols (e.g., ICMP, TCP, UDP, etc.)
- Floating IPs - Manage floating (public) IP addresses
- Share
- Shares - Create, view, and manage file system shares
- Share Snapshots - Create and manage snapshots of shares
- Share Networks - Manage networks for shared file systems
- Security Services - Configure services for authentication and access control (e.g., LDAP, Kerberos)
- Share Groups - Manage groups of shares for replication or policy enforcement
- Share Group Snapshots - Create and manage snapshots of share groups
- User Messages - View messages or notifications sent to the user
- Identity
- Projects - List all projects
- Users - List all users
- Application Credentials - Manage API credentials for applications accessing OpenStack
The following options become available when selecting the user settings as discussed in the next section:
- Settings
- User Settings - Modify dashboard settings
- Change Password - Change user password
¶ Dashboard Settings
Upon successful log in, the user's dashboard settings can be accessed by navigating to the upper right corner of the dashboard, click your username (in this example, demo), then click Settings.
On the left portion of the screen, the options User Settings and Change Password will appear.
¶ User Settings
Here, the following dashboard settings can be changed: Language, Timezone, Items Per Page, and Log Lines Per Instance:
¶ Change Password
To change the user password, enter the Current password, then the New Password and Confirm new password:
We highly recommend that users change the provided temporary password upon first log in. As the description indicates, we also highly recommend that you create a strong password by using at least eight (8) characters using a combination of uppercase and lower-case letters, numbers, and symbols.
¶ Key Pair Management
Before creating any instance, it is very important to first set up key pairs as these are the way to access created instances. Key pairs are similar to SSH key pairs composed of a pair of corresponding public and private keys. Navigate to the Key Pairs section in the Dashboard by selecting Project > Compute > Key Pairs in the Navigation Bar. Two options are available: Create Key Pair and Import Key Pair.
¶ Create Key Pair
This action will generate a new SSH private key. Fill in Key Pair Name, then click Create Key Pair.
The .pem file will be downloaded automatically and its filename set to the key pair name specified above.
The page will then reload and display the list of created key pairs.
Clicking on the Key Pair Name reveals the corresponding Public Key:
It is the Public Key that will be injected into the instance upon creation later on so that it can be accessed via SSH.
The Fingerprint information for the key is important because we can use this information to verify that the downloaded Private key corresponds to the indicated Public Key. To do this, in a Linux/Unix/MacOS terminal or Windows PowerShell, use the following command:
ssh-keygen -E md5 -lf <path/to/priv/key>
For Linux/Unix/MacOS systems, the command may run into a warning saying that the private key file is unprotected, like so:
This can be easily fixed using the following command:
chmod 400 <path/to/priv/key>
Take note of the resulting MD5 fingerprint to confirm that it matches the fingerprint indicated in the Key Pairs dashboard.
¶ Import Key Pair
Another way of adding a Key Pair is to import a preexisting SSH key.
In your Linux/Unix/MacOS terminal or Windows PowerShell, create an SSH private and public key pair (skip this if you already have an existing SSH key pair and you wish to append the public key of that key pair). You may refer to the COARE HPC Basic Usage guide for instructions on generating an SSH key.
Then, go back to the Key Pairs dashboard and click the Import Key Pair button to display the Import Key Pair window:
Give this key a name, paste the public key in the Public Key box, then click the Import Key Pair button to add the key pair under your account.
¶ Image Management
A working Image is a very important requirement prior to creating instances as it is the source of the instance's operating system (OS) and its configuration during creation. Metadata information, such as account creation and SSH key injection, are also automatically handled by the image. Publicly-available images (i.e., images from the same or other projects that are set with public visibility) are listed under the Project > Compute > Images tab in the Navigation Bar. Here, preconfigured images are available for use, but users may still opt to upload their image of choice as described in the OpenStack "Get images" documentation.
¶ Create Image
CAUTION: Make sure to download images only from reliable sources to avoid possible security issues in the instances created.
To create an image for the project, go to the Project > Compute > Images tab in the Navigation Bar, then click the Create Image button to display the Create Image window:
Fill up the required fields indicated by asterisks. More information on the fields is described in the OpenStack Upload and manage images documentation.
On the next page, the image's metadata may be configured:
The OpenStack Useful image properties documentation lists some image properties and their supported values which can be used to configure the image to be created. However, please note that there may be discrepancies in the properties available in the dashboard compared to that in the online documentation. In most cases, it isn't necessary to define metadata properties to the image.
¶ Security Groups Management
Security groups control network traffic going in (ingress) and out (egress) of the instances similar to how network firewalls work. Go to the Project > Network > Security Groups tab in the Navigation Bar to manage your project's security groups.
¶ Default
The default security group contains the following network rules.
The above rules allow all outgoing (egress) network traffic to the internet (::/0 for IPv6 and 0.0.0.0/0 for IPv4) through all ports and IP protocols. For incoming (ingress) traffic, the default security group (itself) is used, but there are no ingress rules defined in the default security group. Therefore, the default security group only allows outgoing traffic to all IPv4 and IPv6 addresses, and no incoming traffic is allowed from anywhere. This is intended by design to help secure the instance from unauthorized and malicious access. However, to be able to access the instance — for example, ping (ICMP); logging in using SSH; HTTP (port 80) and HTTPS (port 443) for web server instances; etc. — ingress traffic must be allowed. Therefore, a new security group will be created.
¶ Create Security Group
To create a new security group, click the Create Security Group button.
Give it a Name and Description. For this example, the new security group will be named minimal to allow incoming traffic for SSH (port 22) and ping (ICMP). Then, click the Create Security Group button. After creation, click the Manage Rules button to configure the security group's network rules. By default, all outgoing (egress) traffic are allowed in the new minimal security group like that in the default security group.
¶ Add Rules
Click the Add Rule button to show the following window:
To allow SSH logins (via TCP port 22), select SSH under Rule, CIDR under Remote, and type in 0.0.0.0/0 under CIDR to allow incoming access from all IPv4 addresses. Click Add to add the rule. Add another SSH rule but this time set the CIDR address to ::/0 to allow incoming access from all IPv6 addresses. The CIDR addresses may be modified to allow incoming requests only from a specific IP address (e.g., 192.168.6.69 equivalent to 192.168.6.69/32) or a range of IP addresses (e.g., 192.168.6.1/24). For more information about this notation, here is a quick overview on Understanding IP Addressing and CIDR Charts.
After creating both rules, the security group will look like this:
To be able to ping instances, the ICMP rule must also be allowed for ingress traffic. Do the same steps outlined above for SSH, but use All ICMP instead of SSH under Rule. The minimal security group should now look like this after adding SSH and All ICMP ingress access from all IPv4 (0.0.0.0/0) and IPv6 (::/0) addresses:
In the future, additional IP protocols and ports (or port ranges) may need to be opened for other applications and protocols, such as, among others:
- TCP ports 80 and 443 for HTTP and HTTPS protocols, respectively, for web servers;
- TCP ports 27017–20 for MongoDB;
- UDP ports 53, 68, and 88 which are used by online games.
Additional security groups with additional rules should be created to accommodate any new ports that need to be opened in your instances.
¶ Instance Management
Instance Management allows users to create, configure, monitor, and manage virtual machine instances within the cloud environment.
¶ Create Instance
After the key pair, image, and security group are configured, the project's first instance may now be created. When creating an instance, make sure to use the least number of resources possible (e.g., virtual CPUs, memory, disk size) first which can be gradually resized later on. It is also not advisable to create instances with large root disk sizes (e.g., more than 20 GB) for storage purposes because it will be almost impossible to recover data when the instance fails and there is no instance snapshot. Instances should only contain the bare minimum disk requirement for the operating system (OS) to run smoothly. Create and attach additional volumes instead for storage purposes.
¶ From Image
The recommended way to create a new instance is from an image.
Go to the Project > Compute > Instances tab in the Navigation Bar, then click the Launch Instance button to show the Launch Instance window:
Give it an Instance Name, and keep the other settings as is (i.e., Any Availability Zone under Availability Zone, and 1 under Count). For this example, the instance name was set as demo which will also become the instance's hostname later on.
Click Next to configure the instance source:
BEFORE PROCEEDING: If the Device Name field does not appear, reload the page in the browser.
Choose the Image option under Select Boot Source, then select Yes for Create New Volume to create a new root volume for the instance. Set the Volume Size (GB) for the root volume (minimum should be 20 GB as dictated by the different flavors, to be discussed further). Set Yes for Delete Volume on Instance Delete if you want the volume to be automatically deleted when the instance is deleted. For Device Name there are two possible options: vda or sda; the default is vda, but if this results in errors later on, then you can try setting sda instead. Select the image to use from the list of available images by clicking the ⇑ button. Only one (1) image may be selected.
Click Next to configure the instance flavor:
The flavor defines the instance's virtual resources, such as CPUs (VCPUs), memory (RAM), and root disk size (Root Disk). Be mindful of your project's resource quotas. Select the flavor to use from the list of available flavors by clicking the ⇑ button. Only one (1) flavor may be selected.
Click Next to add a network to the instance:
In the networks listed, select only either int-vlan-network (for internal users, i.e., ASTI users) or ext-vlan-network (for non-ASTI users) by clicking the ⇑ button. DO NOT use either the 159-pub-network or public_v6 network as this will make the instance unreachable.
Skip the Network Ports tab and go directly to the Security Groups tab:
Here, add the minimal security group previously created by clicking the ⇑ button. Multiple security groups may be attached to a single instance.
Click Next to proceed to the Key Pair tab:
Select the appropriate key pair by clicking the ⇑ button. Only one (1) key pair may be attached per instance.
Click Next to proceed to the Configuration tab:
Add any configuration script that you may have either by pasting directly into the Customization Script box or by attaching a file under Load script from a file. One useful example of a customization script is setting the root password during instance creation which may be useful later on when logging in via the instance's console.
Select Automatic for Disk Partition; if you'd like to configure the disk partition yourself, then select Manual instead. Check the Configuration Drive box to create a special partition within the instance where metadata are stored, such as the instance name (which will be used as the instance hostname), etc.
After the Configuration tab, the next tabs may be skipped.
Click the Launch Instance button to finally create the instance which will take the page back to the Instances tab to show that the instance is being created:
After some time, if the instance creation is successful, the Status will be changed from Build to Active:
The instance log should be inspected to confirm that the SSH key pair has been successfully appended. Click the hyperlinked Instance Name, then navigate to the Log tab to show the Instance Console Log:
You can click the View Full Log button to show the entire console log. There should be lines that look like that below saying that the authorized_keys have been updated (this is already partially visible in the screenshot above):
As per the OpenStack Get images guide, the default username for Ubuntu images is ubuntu, hence the key pair was appended to /home/ubuntu/.ssh/authorized_keys. For other images, such as those preconfigured by the COARE Team, the default username is indicated in the image's description. However, the SHA256 fingerprint of the key appended to the instance as indicated in the console log does not match the actual SHA256 fingerprint of the key. Please don't worry about this discrepancy as this seems to be only a bug in the current OpenStack implementation. The right key was still injected into the instance which is apparent in the successful SSH log in to the instance as discussed further.
¶
¶ From Instance Snapshot
Create a snapshot of your instance first as discussed further down. Then, follow the steps for creating an instance from an image because instance snapshots are stored as images in OpenStack. This is a good way of creating a working back up of your instance(s) which can be recreated as another instance especially when the original instance fails beyond repair and recovery.
¶ Access the Instance
Accessing an instance after creation will depend on how the rules of its attached security group(s) is/are configured. In order to be able to access instances attached to either the int-vlan-network (192.168.7.0/24) or ext-vlan-network (192.168.14.0/23), connection to the appropriate COARE virtual private network (VPN) is required.
In the previously created instance (From Image Page), its IP address allocated under the ext-vlan-network is 192.168.15.27.
¶ Ping
To check if the instance is indeed up and running, the ping command may be used. To ping the instance, make sure that the VPN is connected, then in your local machine's terminal:
$ ping 192.168.15.27 # change IP address accordinglyThe instance will respond if the VPN is connected and if the incoming ICMP access is allowed in the instance's security groups:
However, if any of the above conditions aren't met (i.e., the VPN is not connected, incoming ICMP access is not allowed in the security groups, or both), then the instance won't be reachable:
¶ SSH
To log in to the instance via SSH, make sure that the VPN is also connected and incoming SSH access is allowed in the instance's security groups. In your local terminal:
$ ssh -i <path/to/priv/key> <username>@192.168.15.27 # change IP address accordingly
For the same test instance, this is how a successful SSH log in should look like:
The access transitioned from the local Inspiron-5584 machine with username demo to the remote test hostname with user ubuntu. To demonstrate that the machines are not the same, the ip -brief all (shortcut: ip -brief a) command was used on both the local and remote machines to determine their respective network intefaces/devices and their corresponding IP addresses. The above screenshot also indicates that the ubuntu user is an administrator account in the instance which is the default for all images. Thus, users are free to configure their instances up to the system level as they have root access to their instances, including but not limited to, creating additional accounts for other project members, installing various applications, etc.
¶ Console
In default images (i.e., images that have not yet been preconfigured), the default user is passwordless. That is why making sure that the right SSH key pair is injected into the instance is critical for access. Therefore, access via console is not yet available immediately after instance creation.
For preconfigured images, check the image description or ask the COARE Team regarding the default login credentials. For default images, a password for the default user may be set. Log in to the instance via SSH as described above (remember to connect to the appropriate VPN first), then log in as root and change the default user's password using the following commands:
ubuntu@test:~$ sudo -i
root@test:~# passwd ubuntu # default user
The same commands are applicable for other Linux distributions as well, such as CentOS, Debian, Fedora, etc. A notification will be printed when the password is successfully set:
Console access is now possible for the default user (or any other user created in the instance) after successfully setting a password. Console access is similar to a direct log in into a physical server. To do this, keep the VPN connection active as it is necessary to access the instance's Console tab. Navigate to the instance's Console tab in the dashboard:
Click the "Click here to show only console" link to get started. This will display only the console in the entire browser window. Now enter the username and password for the user you wish to log in. After successfully logging in, it will have a similar interface when logging in via SSH:
Similarly, a password may also be set for the root user to be able to log in directly via the console:
ubuntu@test:~$ sudo -i
root@test:~# passwd
¶ Backup Instance
¶ Create Instance Snapshot
An instance snapshot captures the instance's state at the time the snapshot is created. This can be easily done by either clicking the Create Snapshot button at the rightmost portion of the instances list:
Or, by clicking the Instance Name, then clicking the same Create Snapshot button at the top right portion:
After clicking the aforementioned button, the Create Snapshot window will appear where the Snapshot Name should be provided:
After creating the snapshot, the page will be redirected to the Project > Compute > Images tab in the Navigation Bar. Repeatedly click any of the headers (Owner, Name, Type, etc.) until all the images under the project are at the top of the list including the created snapshot:
In the Project > Volumes > Snapshots tab of the Navigation Bar, a volume snapshot is also saved for the instance snapshot:
¶ Other Instance Operations
Other operations may be performed on instances in the Instances dashboard:
- Associate Floating IP: Add a floating (public) IP to an instance.
- Attach Interface: Add a new interface/connection to a network.
- Detach Interface: Remove a network interface/connection.
- Edit Instance: Change the instance's name and security groups.
- Attach Volume: Add a volume as a new disk device to the instance.
- Detach Volume: Remove a volume from the instance. The volume contents are not affected.
- Update Metadata: Edit the instance's metadata.
- Edit Security Groups: Manage the security groups applied to the instance.
- Edit Port Security Groups: Manage security groups for the instance’s ports.
- Console: View the instance console (needs VPN connection).
- View Log: View the Instance Console Log.
- Rescue Instance: Boot into a rescue mode for recovery.
- Pause Instance: Puts the instance in a state similar to "Sleep" in personal computers.
- Suspend Instance: Places the instance in a state similar to "Hibernate" in personal computers.
- Shelve Instance: Shutdown the instance and store it together with associated data and resources. A snapshot is taken if the volume is not backed. Note that anything in memory of the instance (e.g., running applications, data read/write to disk, etc.) will be lost.
- Resize Instance: Change the instance's flavor.
- Lock Instance: Prevents deletion of the instance.
- Soft Reboot Instance: Attempt a graceful shutdown and reboot of the instance similar to issuing a reboot command within the instance.
- Hard Reboot Instance: Does not wait for a graceful shutdown similar to pressing and holding the power button of a physical machine until shutdown.
- Shut Off Instance: Turn off the instance.
- Rebuild Instance: Rebuild the instance from an existing image.
- Delete Instance: Delete the instance. WARNING: This operation is not recoverable once finalized.