Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/elabit/rcc-offline

A Docker compose setup to demonstrate how rccremote works
https://github.com/elabit/rcc-offline

Last synced: 2 days ago
JSON representation

A Docker compose setup to demonstrate how rccremote works

Awesome Lists containing this project

README

        

# rcc Offline Demo Setup

Scenario for the problem: The execution of Robot Framework tests with Robotmk requires the test client to be connected to the Internet if the underlying Python/nodejs environment is to be built with RCC.
This is often not permitted for security reasons and the test clients are completely cut off from the Internet.

This repository serves to demonstrate two ways to circumvent this problem:

- rccremote
- hololib.zip
- combination of both

**Proof of concept**: All strategies presented here are for demonstration purposes only.

## Preparation

`docker compose up --build -d `

Open two terminals for both rccremote and rcc.

- Server: `docker exec -it server bash`
- Client: `docker exec -it client bash`
- Clientuser: `docker exec -it clientuser bash`

tmuxp:

- Open the multipane session: `tmuxp load /data/tmuxp.yaml`
- Pane focus:
- `Ctrl-a, Cursor`
- `Ctrl-a, q + Number`
- Toggle fullscreen: `Ctrl-a, z`

To cleanup the docker compose setup, run: `docker compose down --volumes`

---

## Mode 1: rccremote

With `rccremote`, a host (server) can provide the holotrees (environments) available on it to other hosts (clients).
This example shows how an environment is built on the server and then made available via `rccremote`.
The same environment can be obtained on the client with a considerable time advantage via rccremote instead of building it from scratch.

### server

```
cd data
bash rccremote_server.sh
```

This

- enables the "shared holotree" feature (required for rccremote to work properly)
- builds a RCC environment (and downloads the installation sources fwith Playwright and starts then `rccremote`, listening on port 4653.

([This](https://github.com/robocorp/prebuilt-env-docker/blob/master/importer/nginx.conf) is a demo setup which uses nginx to serve rccremote via HTTPS)

### client

#### Creating the environment

```
cd data
bash rccremote_client.sh
```

This

- sets the environment variable `RCC_REMOTE_ORIGIN` to the address `http://server:4653`
- build the playwright env similar to the other container; but this time, it fetches all sources from the rccremote server.

#### Using the environment

Both commands on server and client should have printed the list of environments; their "Blueprint" should be the same.
Now its time to prove that the environment can be used on the client:

```
bash run_robot.sh
```

This starts the Playwright based RF suite in the newly created RCC environment, obtained from server.

---

## Mode 2: hololib.zip

This approach represents an even more secure alternative to rccremote.
Another way to set up RCC environments quickly and efficiently is to import a file.
First, the environment is built on a reference machine and then exported into a `hololib.zip` file.
The ZIP file must be transferred to the clients (copying/syncing) and can be imported there.
In this way, it is possible to transfer RCC environments to hosts that are located in completely isolated network areas.

### Preparation

`docker compose up --build -d `

Again, open two terminals for both rccremote and rcc.

- Server: `docker exec -it server bash`
- Client: `docker exec -it client bash`

### server

```
cd data
bash hololib_export.sh
```

This
- builds the environment
- exports the environment into a file `env.zip`

### client

#### Importing the catalog

```
cd data
bash hololib_import.sh
```

This imports the RCC catalog from the ZIP file.
From the catalog, the client can now create holotrees from (next step)

#### Using the environment

```
bash run_robot.sh
```

This starts the Playwright based RF suite. RCC will first create a new hololib from the catalog (just takes some seconds), and then starts the test.

---

## Mode 3: Combination of rccremote + hololib.zip

The two approaches presented above each have a disadvantage:

- **rccremote**: Clients in isolated network areas may not be allowed to connect to hosts that can access the Internet.
- **hololib.zip**: no centralized solution, high manual effort

To solve both disadvantages, the third mode is a combination of both:

- The rccremote server is located **in the same network** as the clients; it also does not need a internet connection.
- The environments are built on a dedicated (development) machine which has internet access. (That's where the environments can also be checked/scanned against security). Finally, they are exported into ZIP files.
- The ZIP files are copied/synced and imported on the rccremote server.
- rccremote can serve the environments for the clients.

Advantages:
- Central provision of RCC catalogs
- Clean separation of network areas
- Can be automated

---

# Securing rccremote with nginx

Create a custom certificate and save the certificate + key in the certs directory:

```
mkdir certs
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout certs/server.key -out certs/server.crt
```

Start the compose setup.

## Client1

rcc ht shared -e
rcc ht init
cd /data/minimal7
rcc ht vars
rccremote -hostname 0.0.0.0 -debug -trace

## Client2

export RCC_REMOTE_ORIGIN=https://nginx:443

cd /data/minimal7
rcc ht vars

Verify that rcc denies to fetch from rccremote ("hostname verification failed").

Now import the custom RCC profile which disables SSL certificate verfication:

rcc config import -f rccremote-insecure.yaml

Check whether profile is ready to activate:

rcc config switch

Activate profile:

rcc config switch -p rccremote-insecure

Verify changed settings `config-active-profile` and `config-ssl-verify`:

rcc config diag

Fetching from rccremote should work now:

rcc ht vars