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.
   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 menus are 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.

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.

When the node is 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, 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

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.

   

Volumes

The Volumes menu provides a list of all available Docker volumes on the node. The definition of the Docker volumes takes place during the provisioning of a Docker workload via the Management System (for more information refer to Provisioning a Docker workload).

The list contains the following information:

• Volume name given during provisioning the Docker workload,
• The memory Size of the Docker volume.
• The Workload version to which the Docker volume is assigned to.

Actions	Items and Description
Delete	Select the garbage can icon to delete volumes from the node which are not assigned to a Docker workload version. Note that you cannot delete Docker volumes from the node, when they are assigned to a Docker workload version. This is indicated by a gray garbage can icon .
Import	To import data to a Docker volume, proceed as follows: Select the blue import icon . Choose the ZIP file you want to import and confirm it with OK. During the import, the import icon turns orange. When the import is successful the icon turns blue again. If a problem occurs during the import, the icon turns red and a notification with a description of the problem appears.
Export	To export data from a Docker volume, select the blue export icon . During the export, the icon turns orange. When the export is successful the icon turns blue. After the export is finished the file is provided to your browser for download. If a problem occurs during the export, the icon turns red and a notification with a description of the problem appears.

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.

Audit logs for nodes

Audit logs are a systematic and chronological record of events, activities, or transactions within a node. The node logs auditable events in both online and offline state.

Audit logs can also be viewed for the Management System.

These logs capture a wide range of information, including who performed an action, what the action was, when it occurred, and the outcome of the action. As such, they are a distinct security capability, providing forensics capability and traceability about past actions, and are crucial for several purposes, such as security, compliance, troubleshooting, and performance monitoring.

Access the audit logs for the node

The audit logs for the nodes are presented in an OpenSearch dashboard.

Access to the OpenSearch dashboard within the Local UI

In case the node is offline (the node is not connected to the Management system) you can view the audit logs for the node via the Local UI.

1. Connect to the designated nerve device via the local UI - API (refer to Connecting to the Local UI)
2. Open the Node configuration.
3. Select Audit logs.

Access to the OpenSearch dashboard within the Management System

1. Navigate in the Management System to the node tree.
2. Select the node for which the audit logs are needed.
3. Select the tab Logs.

4. Select TRIGGERED FROM THE MANAGEMENT SYSTEM or TRIGGERED FROM THE NODE.

   An OpenSearch Dashboard window for MS Audit logs or Node Audit logs will open in a new browser tab, showing relevant log entries for the selected node. See the logging page of the Management system for more details.

   Note

   If the node is offline, audit logs can be downloaded in ZIP format via an API endpoint available on the node. For more information about the OpenAPI specification under audit Logs, refer to the Nerve Node API

Select › to inspect a log entry to show the full range of all fields. The fields contain the following information:

Event ID code

The Event ID code is an eight-digit number, with every two digits signifying an aspect of the event. Its meaning is generated left to right, meaning that the first digit's pair determines the possible value of the second digit pair and so on. The digits stand for the following:

Take a look at the tables below for possible digits. Keep in mind that the Event ID code is constructed the following way: NN XX YY ZZ.

Refer to the tables below for a list of sources that signify the first two digits NN.

Refer to the table below for a list of Objects XX and Categories YY.

Refer to the tables below for a list of action that signify the last two digits ZZ.

Access control (200101ZZ)

The following table shows the events that are logged according to the access control actions.

Reboot (200102ZZ)

The following table shows the events that are logged according to the reboot actions.

Networks (200103ZZ)

The following table shows the events that are logged according to the networks actions.

Proxy settings (200104ZZ)

The following table shows the events that are logged according to the proxy settings actions.

Node configuration (200105ZZ)

The following table shows the events that are logged according to the node configuration actions.

Workloads deployment (200201ZZ)

The following table shows the events that are logged according to the workloads deployment actions.

Workload control (200202ZZ)

The following table shows the events that are logged according to the workloads control actions.

Remote connections management (200301ZZ)

The following table shows the events that are logged according to the remote connection management actions. For more information about remote connections refer to Remote connections.

User management (200401ZZ)

The following table shows the events that are logged according to the user management actions.

DNA (200501ZZ)

The following table shows the events that are logged according to the DNA actions.

Local repository (200601ZZ)

The following table shows the events that are logged according to the Local repository actions.

Docker resources volumes (200701ZZ)

The following table shows the events that are logged according to the Docker resources volumes actions.

Docker resources images (200702ZZ)

The following table shows the events that are logged according to the Docker resources images actions.