# Bridge Installation for Linux This document outlines the process for installing and configuring the OvalEdge Bridge Client on RHEL-based operating systems. The Bridge component enables secure connectivity between the OvalEdge cloud-hosted server and client data sources, whether hosted on-premise or in any public cloud environment. OvalEdge’s cloud offering allows customers to utilize the platform as a hosted service without directly connecting to client data sources. This is achieved through the OvalEdge Bridge component, which enables secure communication between cloud and on-premise environments without modifying firewall rules. The client component of the Bridge is installed within the client infrastructure, requiring only the whitelisting of the client’s IP address and port. ## Purpose of the document The purpose of this document is to outline the detailed procedure for installing, configuring, and validating the OvalEdge Bridge Client on RHEL-based systems, including prerequisites, system setup, connectivity validation, installation, and service management. ## Prerequisites ### Installation Files The following files must be available before starting the Bridge Client installation:
File NameDescription
Bridge Secure Connectivity Pack (.zip)Contains certificates and configuration files required for secure communication between the Bridge Client and Bridge Server.
Bridge Client Installer (.jar)Required to execute the Bridge Client installation process.
Bridge Component File (.nar)Must be placed in the NiFi lib folder after installation to enable communication with the OvalEdge SaaS platform.
{% hint style="warning" %} Before proceeding with the installation of the Bridge-Client, please ensure the OvalEdge App is up and running. {% endhint %} {% hint style="info" %} The OvalEdge GCS team provides these files via a secure channel (email) and must be copied to the Bridge Client VM before installation. {% endhint %} ### Recommended Hardware | Hardware | Configuration | | -------- | ------------- | | RAM | 32 GB | | SSD | 250 GB | | vCPU | 8 | ### Recommended Software | Software | Version | | -------- | ------- | | OS | RHEL | | Open JDK | 17.0 | ### Whitelisting Ports
Port TypePortPurpose
Inbound9443Required for NiFi UI configuration changes
Outbound9443Communication from Bridge Client to Bridge Server
{% hint style="info" %} * The Bridge Client IP must be whitelisted in all connector data sources. * Ensure outbound traffic on port 9443 is allowed to the Bridge Server. * Get a confirmation from GCS that the Bridge-Client IP is whitelisted in the Bridge-Server hosted in AWS. {% endhint %} ## OvalEdge Bridge Architecture and Communication Model The Bridge works in a Pull Model where the Bridge client will be Polling (Checks for any commands that are stored at the Bridge Server, issued from the OE Platform, eg, establishing a connection to the dataSource) to execute, waiting in the queue (A queue is a Flow File that holds the data to be transmitted through Bridge) every 5 seconds. The pull time can be configured, and the Bridge client pulls commands from the Bridge Server and transmits the metadata to the OE Platform for processing, securely over the whitelisted secure ports. The Bridge is owned by OE, except for the client VM on which it is deployed in the client Data Center (OE provides all software components). OE provides and maintains the bridge component. The Bridge Server is hosted along with the OE Platform and interacts with it. Users perform actions like crawling and profiling data sources and the Bridge Client Pools for the commands, and securely execute the same connection to the client data Sources over TLS 1.2 (Transport Layer Security) and SSL. The Bridge Component, offered as part of the SaaS, reduces communication pain points with client data sources, whether hosted on a VM (provided by the client) or on-premises. ### Bridge Components
ComponentDescription
Bridge ServerHosted on the OvalEdge SaaS AWS environment and interacts directly with the OvalEdge platform.
Bridge ClientInstalled on the client’s infrastructure (cloud or on-premise) and communicates securely with the Bridge Server.
{% hint style="warning" %} * The Bridge is owned and maintained by OvalEdge. * The client provides the VM and network configurations within their environment. * All communications are encrypted using TLS 1.2 and SSL protocols. {% endhint %} ### Deployment Scenarios
EnvironmentBridge Server LocationBridge Client LocationCommunication Requirement
Cloud-based SourcesOvalEdge SaaS AWS ServerPublic cloud VM (provided by client)The Client VM IP address must be whitelisted to communicate securely with the Bridge Server hosted on the SaaS VM.
On-Premise SourcesOvalEdge SaaS AWS ServerOn-prem VM (provided by client)The Client VM IP address must be whitelisted to communicate securely with the Bridge Server hosted on the SaaS VM.
## Installation Steps 1. Setting up the VM 2. Configure system settings in the OvalEdge application 3. Proceeding with Bridge Client Installation ### 1. Setting up the VM #### Install Open JDK version 17 * Run the following commands for RHEL OS: ``` $ sudo yum update $ sudo dnf install java-17-openjdk-devel -y ``` * Run the following command for Ubuntu OS: ``` $ sudo apt-get update $ sudo apt-get install openjdk-17-jdk -y ``` * Verify Installation: ``` $ java -version ``` **Output**:
* Identify Public IP: ``` $ curl ifconfig.me ``` {% hint style="warning" %} Share the static public or NAT IP of the VM with the OvalEdge team (GCS). The IP will be whitelisted on the OvalEdge SaaS system to allow traffic between the Bridge Client and Bridge Server. {% endhint %} * On the customer’s network, make sure that outbound traffic is permitted to the bridge server IP (which will be shared by the OvalEdge team) on port 9443 * Verify Connectivity: ``` $ curl -v telnet://:9443 ```
* The bridge\_server\_domain will be provided by the OvalEdge team. * For the OvalEdge application to crawl data from the customer's data sources, the VM running the bridge client must be able to connect to them. The customer must ensure that the Bridge client VM is allowed to access the data sources. {% hint style="warning" %} * Ensure the Bridge Client VM has network access to all required data sources. * Only required ports on the data sources should be opened for traffic from the Bridge Client VM. * Service accounts should have read-only access. {% endhint %} ### 2. Configure System Settings in the OvalEdge application OvalEdge team must perform the following validations (bridge settings) before initiating the Bridge Client installation. * Navigate to **Administration** >**system settings** > **system path ovaledge:temppath=/mnt/tmp/**
* Navigate to **Administration** > **System Settings** > **Bridge**. * Review the Bridge configuration values listed below.\ If any configuration value differs from the required configuration, update the value according to the standard configuration provided below. | ovaledge.bridge.mode | true | | ---------------------------- | ---------------------------------------------------- | | ovaledge.bridgesoftware.path | /mnt/BridgeSoftware/ | | bridge.type | nifi | | bridge.server.host | \ | | bridge.nifiversion | nifi-1.28.1 |
### 3. Proceeding with Bridge Client Installation * Deploy a RHEL machine that serves as a mediator between the Bridge Server and data connectors. * Navigate to **Administration** > **Connectors** and click **Manage Bridge**.
* Click "**+"** to add the Bridge. * Enter the public IP address of the Bridge Client machine in the Bridge IP Address field
* A pop-up displays the Bridge ID, Security Code, and download links for the Bridge Secure Connectivity Pack and Bridge Installation Software.
* Download the file and copy the security code to the Bridge Client VM. {% hint style="info" %} Download and copy the Bridge Secure Connectivity Pack ( zip file) to the bridge client VM. Note the Security Code displayed during the Bridge Installation process. {% endhint %} * Note the Security Code in the format: ``` BRIDGExxxxxxxxxxxxxxx ``` * Click on the **Ok** button, and the new bridge is created and displayed on the Bridge page.
* Download the Bridge Installation Software file shared by the OvalEdge GCS Team via email and move it to the bridge client VM. {% hint style="info" %} The installation file size is approximately 700 MB. {% endhint %} ## Install and Register the Bridge ### Installation Steps 1. Create three folders: 1. bridge\_artifacts 2. bridge\_client 3. temp
2. Copy the **Bridge Secure Connectivity Pack** (zip file) and **ovaledge-bridge-client-installer.jar** into the bridge\_artifacts folder. 3. Run the installation: ``` $ java -jar path_to_jar.jar ```
4. Upon running the JAR file, press "**1**" and "**Enter**" to confirm your choice. Please follow this step for any future confirmations of this nature.
5. When prompted, select the installation path for the Bridge Client. 1. The default installation path is **/usr/local/ovaledge\_bridge**. 2. Enter the path of the folder created earlier, named **bridge\_client**.
6. Press "1" and "Enter" to confirm your choice
7. Enter the Security Code noted during the bridge creation process in the OvalEdge application.
8. Provide the same IP Address used when adding the bridge IP details in the OvalEdge application under the M/C IP Address field.
9. Enter a suitable Bridge Name to identify the Bridge Client.
10. Provide the Bridge Server URL shared by the OvalEdge team.
11. For the Certificates Path, enter the location of the Bridge Secure Connectivity Pack (ZIP file) copied earlier to the VM.
12. For the Bridge Temp Path, enter the location of the temp path on the VM
13. Enter the required User Name and Email Address, then press 1 and Enter to confirm. {% hint style="info" %} The user details are mandatory and must be entered without spaces. {% endhint %} This information is recorded for reference purposes to identify the individual who performed the Bridge (NiFi) setup on the VM.
14. For NIFI service creation, enter the service name.
15. For the Is askEdgi option, specify whether the askEdgi feature should be enabled. 1. Enter **true** to enable askEdgi. 2. Enter **False** to proceed without enabling askEdgi.
16. Press “1” again and Enter to proceed.
17. Press “1” again and Enter to proceed.
18. Confirm the action by entering Y and pressing Enter.
19. When prompted, provide the configuration file path enclosed in square brackets, for example: ``` [/home/ec2-user/bridge/auto-install.xml] ```
20. Wait for the installation to complete. A message stating “Installation was successful” will appear.
21. After successful installation, verify that the message “Bridge software installed successfully” is displayed. 22. Copy the **oe-bridge-bundle-nar-\.nar** file to the NiFi lib folder. 23. If any third-party JAR files are provided by the OvalEdge team, copy the JAR files to the appropriate NiFi library directory along with the Bridge NAR file. 24. Restart the NiFi service from the NiFi bin folder using the command: ``` $ ./nifi.sh restart ``` 25. After restarting, check the NiFi logs to confirm that the service has started correctly. 26. Verify the bridge status from the OvalEdge application UI. 1. The bridge status should display as green, indicating successful installation and connectivity.
27. Add the **bridge.temppath** in the application Bridge settings. 1. Navigate to **Administration** > **System Settings**> **Bridge**
28. Provide the path that was created in the Bridge Client VM during the Bridge installation process. ## Running Bridge as a Service OvalEdge offers Bridge functionality as part of its cloud offering, allowing customers to use the platform as a hosted service without connecting to client data sources. Bridge installation on a client machine is managed manually via commands, which causes a server outage when the machine stops. To overcome this, OvalEdge is providing Bridge-as-a-Service on the client's machine. ### Bridge as a Service Benefits The Bridge Component is deployed as a Service. The installation of the Bridge Component, which is server-hosted on SaaS and client-hosted on client cloud or on-prem, runs as a service to avoid manual intervention. Exposing the Bridge as a service ensures that, if a VM is brought back, the Bridge components (Server and client, respectively) start without manual Intervention. This ensures that the Bridge component's availability meets an SLA (Service Level Agreement) of 99.999%. ### Steps to Configure Bridge as a Service 1. Before creating NiFi as a service, stop the running NiFi instance 2. Navigate to the NiFi bin folder. ``` $ sh nifi.sh stop ``` 3. Become the root user. 4. Navigate to: ``` cd /etc/systemd/system ``` 5. Create a new service file: ``` vim nifi.service ``` 6. Insert the following content: ``` [Unit] Description=Apache NiFi After=network.target [Service] Type=forking ExecStart=/nifi-1.28.1/bin/nifi.sh start ExecStop=/nifi-1.28.1/bin/nifi.sh stop User= Group= UMask=0007 [Install] WantedBy=multi-user.target ``` {% hint style="info" %} * ExecStart: Path to NiFi bin/nifi.sh file. * ExecStop: Path to NiFi bin/nifi.sh file. * User: VM username. * Group: VM group name. {% endhint %} ## Service Management Commands | Action | Command | | -------------- | ----------------------------- | | Reload Service | systemctl daemon-reload | | Start Service | systemctl start nifi.service | | Enable Service | systemctl enable nifi.service | | Check Status | systemctl status nifi.service | ## Troubleshooting * If an error occurs while starting the NiFi service, execute the following: ``` $ chmod +x /home/ec2-user/bridge_client/nifi-1.25.0/bin/*.sh $ sudo dnf install policycoreutils-python-utils $ sudo semanage fcontext -a -t bin_t "/home/ec2-user/bridge/nifi-1.25.0/bin(/.*)?" $ sudo restorecon -Rv /home/ec2-user/bridge/nifi-1.25.0/bin ``` * After running these commands, attempt to restart the NiFi service again. *** Copyright © 2025, OvalEdge LLC, Peachtree Corners GA USA