Skip to content
Snippets Groups Projects
Verified Commit aece484a authored by Josef Němec's avatar Josef Němec
Browse files

fix + new comments

parent 75646e3c
No related branches found
No related tags found
1 merge request!45Fix based on Ondrej Jakl comments
Pipeline #273826 passed with warnings
Stage: test
Stage: build_img
Stage: build
Stage: deploy
Stage: after_test
Hide whitespace changes
Inline Side-by-side
topics/compute/openstack/docs/getting-started/creating-first-infrastructure.md
+ 9
− 1
View file @ aece484a
......@@ -178,6 +178,8 @@ your virtual machine via SSH from your local terminal.
=== "Personal project"
For personal project select personal-project-network-subnet from network `147-251-115-pers-proj-net`.
Here is more information on available networks in [Brno](../technical-reference/brno-site/networking.md#ipv4-personal-floating-ips)
and [Ostrava](../technical-reference/ostrava-site/networking.md#floating-ip-networks).
!!! example
......@@ -234,6 +236,9 @@ At this point, you want to [Allocate IP Address](../how-to-guides/managing-float
and [Assign IP Address](../how-to-guides/managing-floating-ips.md#assigning-ip-address).
You don't have to care about the other sections unless you need them.
Possible IP address pools are described separately for [Brno](../technical-reference/brno-site/networking.md)
and [Ostrava](../technical-reference/ostrava-site/networking.md).
For group projects, always select the same network as used in
[Router gateway](../how-to-guides/create-router.md#router-creation).
......@@ -241,7 +246,10 @@ For group projects, always select the same network as used in
Login using your SSH key as selected in Key pair above.
Connect to the instance using **ssh system@floating-ip**, where `system` refers to the image OS (ubuntu, debian, centos) and `floating-ip` is the one associated.
Connect to the instance using **ssh username@floating-ip**.
- `username` differs based on the selected image ("ubuntu", "debian", "centos", "almalinux"). The username topic is also discussed in [FAQ](../additional-information/faq.md).
- `floating-ip` is the one previously associated.
More information about login options is described on the [Accessing Instances](../how-to-guides/accessing-instances.md) page.
......
topics/compute/openstack/docs/how-to-guides/accessing-instances.md
+ 13
− 13
View file @ aece484a
......@@ -6,7 +6,7 @@ search:
---
# Accessing Instances
This page provides instructions on how to access virtual instances in OpenStack. Instances are virtual machines running on a cloud infrastructure. Whether you're an administrator or end user, this page will guide you through accessing and interacting with your instances on OpenStack.
This page provides instructions on how to access virtual instances in OpenStack. Instances are virtual machines running on a cloud infrastructure. Whether you are an administrator or end user, this page will guide you through accessing and interacting with your instances on OpenStack.
## Prerequisites
Before you can access instances running on OpenStack, you should have met the following prerequisites:
......@@ -17,10 +17,10 @@ Before you can access instances running on OpenStack, you should have met the fo
- [Created Virtual machine](../getting-started/creating-first-infrastructure.md#create-virtual-machine-instance): You should have created a virtual machine instance in OpenStack that you want to access.
- [Associated Floating IP](../how-to-guides/managing-floating-ips.md): If you plan to access instances from outside the OpenStack environment, you should have associated a floating IP with your instance.
If you're unsure about any of these prerequisites, please refer to the relevant documentation page for more information.
If you are unsure about any of these prerequisites, please refer to the relevant documentation page for more information.
## Access Methods
There are several different methods that you can use to access instances running on OpenStack. Here's a brief overview of each method and their benefits and limitations:
There are several different methods that you can use to access instances running on OpenStack. Here is a brief overview of each method and their benefits and limitations:
- **SSH**: Secure Shell (SSH) is a command-line interface that allows you to remotely connect to a virtual machine instance running on OpenStack. SSH provides secure access to your instances and is a popular choice for Linux-based instances. However, SSH can be difficult to set up for novice users, and it may not be the best option for users who require a graphical interface.
- **Remote desktop**: Remote desktop allows you to access your instances through a graphical interface, similar to what you might see on your local machine. OpenStack supports several remote desktop protocols, including Remote Desktop Protocol (RDP) for Windows-based instances and Virtual Network Computing (VNC) for Linux-based instances. Remote desktop is user-friendly and provides a familiar interface for users. However, remote desktop may not be as secure as SSH, and it may be slower than other access methods, especially when accessing instances over the internet.
......@@ -28,7 +28,7 @@ There are several different methods that you can use to access instances running
Consult the relevant documentation for each access method for more detailed instructions on how to set up and use each method.
## Connecting To Instances
## Connecting to Instances
To connect to instances running on OpenStack, you can use one of the available access methods, such as SSH, remote desktop, or VNC. Here are step-by-step instructions on how to connect to your instances using each method:
=== "Linux"
......@@ -56,9 +56,9 @@ To connect to instances running on OpenStack, you can use one of the available a
### PuTTY
- Open [PuTTY](https://www.putty.org/) and enter the IP address of your instance in the "Host Name" field.
- Select `SSH` as the connection type.
- Go to `Connection -> SSH -> Auth` and browse to the private key file.
- Go to `Connection -> SSH -> Auth -> Credentials` and browse to the private key file.
- Click `Open` to start the connection.
- Enter your username when prompted.
- Enter your username when prompted, username topic is discussed in [FAQ](../additional-information/faq.md).
For more detailed instructions on how to connect using PuTTY, consult the relevant documentation for your operating system.
### Remote desktop
......@@ -71,15 +71,15 @@ To connect to instances running on OpenStack, you can use one of the available a
For more detailed instructions on how to connect using remote desktop, consult the relevant documentation for your operating system.
## Troubleshooting
- **Verify network connectivity**: If you're unable to access instances, first make sure that you have network connectivity to the OpenStack environment. Check your network connection and ensure that your IP address is in the correct range. You should also ensure that any firewalls or security groups are configured to allow access to the instances.
- **Verify credentials**: If you're unable to authenticate when attempting to access instances, verify that you are using the correct username and password or SSH key pair. You may also need to check that your credentials have the appropriate permissions to access the instances.
- **Check instance status**: If you're unable to connect to an instance, check its status in the OpenStack dashboard. If the instance is not in an ACTIVE state, there may be an issue with its configuration or the underlying infrastructure. Try rebooting the instance or creating a new instance with similar configurations.
- **Check logs**: If you're still unable to connect to an instance, check the logs for any errors or warnings. The OpenStack console log and the instance's system log can provide useful information on what might be causing the issue.
- **Check FAQ**: If you approach an issue when connecting to our infrastructure, make sure to first check FAQ before contacting support.
- **Contact support**: If you're unable to resolve the issue on your own, contact your OpenStack support team for further assistance. Be sure to provide as much information as possible, including error messages and steps you've already taken to troubleshoot the issue.
- **Verify network connectivity**: If you are unable to access instances, first make sure that you have network connectivity to the OpenStack environment. Check your network connection and ensure that your IP address is in the correct range. You should also ensure that any firewalls or security groups are configured to allow access to the instances.
- **Verify credentials**: If you are unable to authenticate when attempting to access instances, verify that you are using the correct username and password or SSH key pair. You may also need to check that your credentials have the appropriate permissions to access the instances.
- **Check instance status**: If you are unable to connect to an instance, check its status in the OpenStack dashboard. If the instance is not in an ACTIVE state, there may be an issue with its configuration or the underlying infrastructure. Try rebooting the instance or creating a new instance with similar configurations.
- **Check logs**: If you are still unable to connect to an instance, check the logs for any errors or warnings. The OpenStack console log and the instance's system log can provide useful information on what might be causing the issue.
- [**Check FAQ**](../technical-reference/brno-site/faq.md): If you approach an issue when connecting to our infrastructure, make sure to first check FAQ before contacting support.
- **Contact support**: If you are unable to resolve the issue on your own, contact your OpenStack support team for further assistance. Be sure to provide as much information as possible, including error messages and steps you have already taken to troubleshoot the issue.
## Security Considerations
- **Use ssh keys**: When accessing instances, it is important to use SSH keys. Avoid using keys that are easy to guess or brute force.
- **Use SSH keys**: When accessing instances, it is important to use SSH keys. Avoid using keys that are easy to guess or brute force.
- **Restrict network access**: To minimize the risk of unauthorized access, it is recommended to restrict network access to only the necessary ports and protocols needed to access the instances. Security groups can be used to control inbound and outbound traffic to instances.
- **Limit user access**: Only users who need to access instances should have the necessary credentials to do so. It is important to restrict user access to only the instances they need to work on and remove access when it is no longer needed.
- **Monitor access logs**: Monitoring access logs can help detect and prevent unauthorized access. OpenStack provides logs that track user access and activity within the environment, and users should review these logs on a regular basis.
......
topics/compute/openstack/docs/technical-reference/brno-site/faq.md
+ 41
− 41
View file @ aece484a
......@@ -89,56 +89,56 @@ hide:
* connect to cloud infrastructure via single public facing jump/bastion node (using [sshuttle](https://github.com/sshuttle/sshuttle#readme) or [ssh ProxyJump](https://www.jeffgeerling.com/blog/2022/using-ansible-playbook-ssh-bastion-jump-host) or eventually [ssh ProxyCommand](https://blog.ruanbekker.com/blog/2020/10/26/use-a-ssh-jump-host-with-ansible/))
* use OpenStack API to watch whether VM is ACTIVE
* relax public IP try-connect loop timing
* relax public IP try-connect loop timing
* configure SSH client to [reuse connection for instance with `-o ControlMaster=auto -o ControlPersist=60s`](https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing)
!!! example
!!! example
As an example, consider a group of virtual machines, where at least one has access to the internet using an IPv4 or IPv6 public address, and they are connected by an internal network (e.g. 10.0.0.0/24).
As an example, consider a group of virtual machines, where at least one has access to the internet using an IPv4 or IPv6 public address, and they are connected by an internal network (e. g. 10.0.0.0/24).
To access the first VM with a public address `<public-ip-jump>`:
To access the first VM with a public address `<public-ip-jump>`:
* Wait for the machine to enter ACTIVE state via Openstack API: `openstack server show <openstack-server-id> -f json | jq -r .status`.
* After VM is in ACTIVE state try to open connection to SSH port with timeout of approx. 5 seconds and period of at least 30 seconds.
* Wait for the machine to enter ACTIVE state via Openstack API: `openstack server show <openstack-server-id> -f json | jq -r .status`.
* After VM is in ACTIVE state try to open connection to SSH port with timeout of approx. 5 seconds and period of at least 30 seconds.
To access other VMs on the same cloud internal network (once SSH connection to 1st is established):
To access other VMs on the same cloud internal network (once SSH connection to 1st is established):
* The recommended method is to create an SSH VPN using sshuttle with `sshuttle -r user@<public-ip-jump> 10.0.0.0/24`
* Address all internal virtual servers with their internal address (CIDR 10.0.0.0/24) and use the 1st (jump/bastion) machine with the public address as an SSH proxy.
* Follow the same steps to connect – first wait for ACTIVE state and then try a port connection.
* The recommended method is to create an SSH VPN using sshuttle with `sshuttle -r user@<public-ip-jump> 10.0.0.0/24`
* Address all internal virtual servers with their internal address (CIDR 10.0.0.0/24) and use the 1st (jump/bastion) machine with the public address as an SSH proxy.
* Follow the same steps to connect – first wait for ACTIVE state and then try a port connection.
## How to check, whether you are blocked
## How to check, whether you are blocked
Run the following bash script from the machine, where you believe you got blocked (A), and also from another one located in another IP network segment (B, for instance VM in other cloud):
Run the following bash script from the machine, where you believe you got blocked (A), and also from another one located in another IP network segment (B, for instance VM in other cloud):
```sh
# Test Cloud Accessibility for a linux or Windows WSDL 2 environments
# BASH function requires following tools to be installed:
# ip, host tracepath traceroute ping, curl, ncat, timeout, bash
# Execution example: test_cloud_access 178.128.250.99 22
function test_cloud_access() {
local basion_vm_public_ip="$1"
local basion_vm_public_port="${2:-22}"
local cloud_identity_host=${3:-identity.cloud.muni.cz}
local timeout=60
set -x
cmds=("ip a" "ip -4 r l" "ip -6 r l")
for i_cmd in "${cmds[@]}"; do
${i_cmd}; echo "ecode:$?";
done
for i_cmd in host tracepath traceroute ping ; do
timeout --signal=2 ${timeout} ${i_cmd} "${cloud_identity_host}"
echo "ecode:$?"
done
timeout --signal=2 ${timeout} curl -v "https://${cloud_identity_host}"
echo "ecode:$?"
timeout --signal=2 ${timeout} ncat -z "${basion_vm_public_ip}" "${basion_vm_public_port}"
echo "ecode:$?"
set +x
}
```
```sh
# Test Cloud Accessibility for a linux or Windows WSDL 2 environments
# BASH function requires following tools to be installed:
# ip, host tracepath traceroute ping, curl, ncat, timeout, bash
# Execution example: test_cloud_access 178.128.250.99 22
function test_cloud_access() {
local basion_vm_public_ip="$1"
local basion_vm_public_port="${2:-22}"
local cloud_identity_host=${3:-identity.cloud.muni.cz}
local timeout=60
set -x
cmds=("ip a" "ip -4 r l" "ip -6 r l")
for i_cmd in "${cmds[@]}"; do
${i_cmd}; echo "ecode:$?";
done
for i_cmd in host tracepath traceroute ping ; do
timeout --signal=2 ${timeout} ${i_cmd} "${cloud_identity_host}"
echo "ecode:$?"
done
timeout --signal=2 ${timeout} curl -v "https://${cloud_identity_host}"
echo "ecode:$?"
timeout --signal=2 ${timeout} ncat -z "${basion_vm_public_ip}" "${basion_vm_public_port}"
echo "ecode:$?"
set +x
}
```
## How to report network issue and get unblocked
## How to report network issue and get unblocked
If you are suspecting, that Your virtual machines are blocked, You should contact support by sending an email to the address cloud@metacentrum.cz. To make things easier and resolve the issue faster, it is important to add the outputs of the bash function `test_cloud_access()` above, ran from both VMs (A and B).
If you are suspecting, that Your virtual machines are blocked, You should contact support by sending an email to the address cloud@metacentrum.cz. To make things easier and resolve the issue faster, it is important to add the outputs of the bash function `test_cloud_access()` above, ran from both VMs (A and B).
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment