Local UI

The Local UI is provided by a web server that is running locally on the Nerve Device. Compared to the Management System, the Local UI covers features that only concern the node itself.
The Local UI gives access to the following features:

• Network configuration
• Node registration and password management
• Workload management
• Local workload deployment
• Local workload repository
• Management of remote connections
• Nerve Data Services access

Connecting to the Local UI

Connecting to the Local UI depends on the Nerve Device. Refer to the table below on how to reach the Local UI for each Nerve Device. Make sure to connect a workstation to the physical port of the Nerve Device associated with host access and configure the network adapter of the workstation. The IP address has to be in the same range as the IP address of the host access interface with a 255.255.255.0 subnet mask.

Once a connection is established, log in with the credentials for the Local UI as described in User Accounts to reach the Local UI dashboard.

Local UI dashboard

The dashboard of the Local UI is the default screen after the log in. Usage statistics of the Nerve Device are displayed in the window with more options in the menu on the left side.

System metrics

The graphs in the Local UI dashboard show available resources of the Nerve Device and their usage over time. The y-axis displays percentages and the x-axis is updated every 10 seconds, showing a time span of 5 minutes. The percentages displayed are always in relation to the maximum of the available resource:

Local network configuration

From the Local UI, the Ethernet ports of the Nerve Device can be configured. Select Network configuration in the navigation on the left to reach this menu. The example below is of the MFN 100. The page is specific to the Nerve Device. The number and names of interfaces may differ.

Item	Description
DHCP	The IP address of the port will be assigned by the DHCP server. If an IP address has been assigned, it will be displayed here.
Static	By selecting Static, the IP address of the port needs to be manually defined. Enter the IP address and subnet mask under IP and NETMASK to set a static IP address. For the WAN interface, the GATEWAY, the preferred DNS as well as two alternative DNS can also be set.
Unconfigured	If Unconfigured is checked, the port is disabled for the host but can still be used for virtual machines with bridged interfaces.

Proxy settings

Network configuration settings can be extended with the possibility to specify proxy settings. In case a proxy server is present in the company network, these settings can be used to enable communication between the node and the Management System. The proxy settings define an HTTP/S proxy for the node with the possibility to specify credentials if they are requested, as well as exceptions. Note that the proxy settings affect the internal communication of the node towards the Management System, and the connections covered by the proxy settings are only those related to:

• the management of workloads on the node
• logs sent from the node to the Management System
• data transmitted from the Data Services Gateway
• the Debian Advanced Package Tool (APT)

Potential connections generated by workloads on the node do not use the node proxy settings.

Expand Network configuration > Proxy to reach the proxy settings.

Select Save to apply the configuration. To undo the proxy settings, uncheck Enable proxy settings and select Save.

Node configuration

The first part of registering a node in the Management System is performed in the Local UI. Node details and information required for registering a node in the Management System are configured under Node configuration.

1. Select Node configuration in the navigation on the left.

2. Enter the following information:

   Item	Description
   Protocol	WebSocket Secure protocol (wss) is used for the registration of the node, meaning that port 443 will be used for communication between the node and the Management System.
   Cloud URL	Enter the URL of the Management System without the protocol, e.g example.nerve.cloud. The URL font color will turn to green if the URL is correct and the node can reach the Management System. If the URL font color turns to red, check the URL for errors and whether network access is established.
   Timezone	This setting is optional. Select a location from the list to have the time zone of the node displayed in the Management System. Note that changing the time zone requires a node reboot for the time zone to be applied.
   Serial number	Enter a serial number with a minimum of 12 characters. Note that this serial number can be freely defined. It is required for node registration in the Management System and serves as a means of identification. Entering the serial number that is printed on the Nerve Device is not required but recommended.

3. Select Save.

   

Additional menu available on this page are listed below.

Offboarding a node from the Management System

A node can be offboarded from the specified Management System by selecting the offboard button next to the Management System URL.

First, a warning message will be displayed. When you affirm the action by pressing "Yes", the node is being offboarded from the Management System. The respective node information, including the defined remote connections, will be removed from the Management System.

All user data will be removed from the node, except for the installed license. Workloads will be undeployed, docker volumes and virtual machine disks will be removed, Codesys workloads, remanent variables, and 3^rd party licenses will be removed. All user accounts will be removed as well, and the default admin account will be reactivated.

Make sure to have the default credentials at hand before performing this action, as the current user will be logged out, and the only possibility to login again is with the credentials of the default admin user.

Changing the affiliated Management System

The affiliated Management System can be changed by changing the Cloud URL. This will trigger the actions described in Offboarding a node, followed by onboarding the node to the provided Management System cloud URL.

Make sure that the cloud URL font is displayed in green before selecting the "Save" button. A warning message will be displayed. When you affirm the action by pressing "Yes", the node is being offboarded from the Management System. A new message will appear displaying the new secure ID.

This new secure ID is required when adding the node in the new Management System. Refer to Adding a node on how to add nodes to the Management System.

Changing the affiliated Management System

Changing the affiliated Management System works in a similar manner like registering a node for the first time at a Management System.

Workload management

Deployed workloads can be controlled in the Local UI. Select Workload management in the navigation menu on the left-hand side for an overview of all deployed workloads. Then, select a workload to reach the interface for controlling workloads running on the Nerve Device. If there is a large number of workloads deployed, filter the list by name or by type. Enter a search query under Search by name to filter the list by name. Select All, VM, Codesys and Docker from the drop-down menu to filter workloads by type.

Note that CODESYS workloads can only be controlled in the Local UI, as operation of a CODESYS workload may have an impact on machine operation and therefore should not be controlled remotely. Virtual Machine workloads and Docker workloads can also be controlled in the Management System. Therefore, the screenshot and description below focuses on CODESYS workload specifics only. Refer to Workload control for general information on workload control.

All changes performed in the Local UI are reflected in the Management System.

Replacing the version of a deployed workload in the Local UI

Versions of deployed CODESYS and Docker workloads can be replaced by other versions through the workload control screen. Replacing the workload version is a quick way to deploy a new version of the same workload. However, note that the new workload version needs to be exported first when replacing a workload version through the Local UI. Refer to Exporting a workload for more information on how to export a workload version in the Management System.

1. Select Workload management in the navigation on the left.

2. Select the tile of a workload with multiple versions.

   

3. Select Replace version.

   

4. Select the plus icon to open the file browser.

5. Select the exported workload version update in TAR format.

6. Select Open to add the exported workload update.

   

7. Select Save.

This starts the replacement of the workload version. Once the deployment of the new version is completed, the Local UI will return to the workload management screen and display a green success message in the upper-right corner.

Local workload deployment

Workloads that have been provisioned in the Management System can be exported and then deployed directly through the Local UI. Refer to the workloads chapter on how to export a workload before following the instructions below.

1. Export a workload in the Management System.
2. Switch to the Local UI.
3. Select Workload management in the navigation on the left side.

4. Select the plus tile in the middle.

   

5. Select the plus symbol to open the file browser.

6. Add the TAR file containing the exported workload.

7. Select Save to deploy the workload.

   

Setting a local repository

If desired, the required files for deploying workloads can be stored in a local repository that does not require internet connection. In doing so, the workload image files for deployment are taken from a user defined repository instead of the workload repository in the Management System.
Refer to Exporting a Workload for information on how to obtain the workload images. Also note that every workload needs to be provisioned in the Management System once before the image files can be transferred to a local repository.

A web server that services static files is required. Popular web servers like Nginx or Apache HTTP Server can be used, as well as a Network-attached storage (NAS) device. Recommended are:

• the NodeJS http-server for Linux
• the built-in Internet Information Services (IIS) for Windows

The IIS for Windows needs to be activated first in newer versions of Windows like Windows 8 and Windows 10.

1. Open the Control Panel
2. Navigate to Control Panel > Programs > Programs and Features.
3. Select Turn Windows features on or off
4. Tick the checkbox next to Internet Information Services.
   Note that ticking the checkbox will only enable the components required to publish a web site. Expand the folder to select other needed features.
   
5. Select OK.

With this the IIS can be used on a Windows machine. Take the following steps to enable the hosting of the workload images. The steps below are not carried out in detail as they are only serving as a guideline.

1. Remove all files from the document root. The default location of the document root is C:\inetpub\wwwroot.
2. Copy the TAR files of the workloads that have been exported from the Management System to the document root.
3. Enable directory listing.
4. Test the web server by opening http://localhost in a web browser.
5. Test if a computer can be reached from another computer in the network.

For more information, refer to the IIS documentation. Follow the instructions below to enable a local repository for a node:

1. Select Local Repository in the navigation on the left.

2. Enter the following information:

   Item	Description
   Protocol	Select the protocol for communication with the local repository: http or https.
   Repository URL	Enter the URL through which the web server hosting the workload images can be accessed.
   Username	If login credentials have been defined for the web server, enter the username for accessing the web server hosting the workload images.
   Password	If login credentials have been defined for the web server, enter the password for accessing the web server hosting the workload images.

3. Select Create to finish the setup.

   

If a local repository is defined in the Local UI, the Management System will look for the workload images in the local repository first when a workload is deployed to this node. If the workload image is not present in the local repository, the workload repository in the Management System will be used instead. To revert back to using the repository of the Management System, select Local Repository in the navigation on the left and select Delete.

Managing remote connections

The behavior of nodes for remote connections is defined by the local settings and by the remote connection configuration in the Management System. Refer to Remote connections for more information.

Approval of remote connection settings

Three options are available:

• Approval of connection set in Management System to approve the remote connection as defined in the Management System
• Always allow remote connections to automatically approve all remote connection requests. This setting is only valid when Local acknowledgment is set to Yes in the remote connection configuration in the Management System.
• Request approval for every connection made to this node to force approval of all remote connection in the Local UI, independently of the settings in the Management System

Approving a remote connection

Local approval for remote connections can be configured in the Management System. Set Local acknowledgment to Yes when configuring a remote connection. When set to Yes, every remote connection has to be approved in the Local UI before it can be established. If approval for an incoming remote connection is pending, a notification bubble appears next to Remote connections in the navigation on the left.

1. Select Remote connections in the navigation on the left.
2. Search for incoming remote connections under Pending Approval.

3. Select Approve on the right for the remote connection that shall be established.

   

Once approved, the open connection will be displayed under Remote links below. Shown are the name of the remote connection and the user that is currently using the remote connection. If the same remote connection is used by multiple users, multiple entries of the same remote connection are shown with different users.