Configuring Edge

Configuring the network

Configuring the network enables you to access the Edge appliance using the domain name. If there are any changes in the network configuration due to an update or changes in the network protocols, you must reconfigure the network of your Edge appliance as described below. After reconfiguring the network, you must update the IP mapping for the domain name with the new IP address in the DNS servers, if you have added an entry in the DNS servers. If you are using an alias, you must update the IP address in the hosts file of your operating system.

Configuring the network using the UI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Network in the navigator.

   The current network configuration for the Edge appliance appears.

4. Click Edit to reconfigure the network.

5. Provide the new IP address for you network. For example, 192.168.66.10

6. Provide the Netmask IP for your network. For example, 255.255.255.0

7. Provide the Gateway IP for your network. For example, 192.168.66.1

8. Provide the DNS for your network. For example, 8.8.8.8

   For DNS, do not use the IP addresses 10.96.0.10 and 127.0.0.1.

9. Provide the Address range CIDR. For example, 172.18.0.0/16

   The CIDR suffix must be between 0 and 27 inclusive. The default value is 172.16.0.0/15.

   The Address range CIDR must not overlap with the reserved IP addresses. See Reserved IP addresses.

   Info

   If the IP address of the Edge appliance overlaps with the Edge appliance’s address range, then you must update the Address range CIDR.

Configuring the network using the REST APIs

To configure the network using the REST APIs, see the /edge/configuration/network API in the Cumulocity Edge OpenAPI Specification.

Troubleshooting the network CIDR

The network CIDR fails in the following scenarios:

1. The network CIDR unavailable on boot time.

   Description: The default network CIDR range is not available in the network. If the network range is already utilized, the network CIDR does not start properly and the Kubernetes cluster startup fails.

2. Invalid network CIDR provided during IP change.

   Description: You tried to change the network CIDR of the properly running Edge appliance, but the range is not available in the network.

To troubleshoot these scenarios:

1. Configure the Edge appliance’s network and gateway to a different network range. Configuring the Edge appliance to a different network disconnects the Edge appliance from the existing network.
2. Configure the network CIDR to a new non-conflicting value.
3. Configure the Edge appliance’s network and gateway back to the network range.

Configuring the hostname

The default hostname of the Edge appliance is iot-edge-server. You can define a unique hostname for your Edge appliance as required. A unique hostname ensures seamless communication within the network, avoids any hostname conflicts with other network devices and improves the security of your Edge device.

Configuring the hostname using the UI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Hostname in the navigator.

4. Click Edit to change the hostname.

5. Provide the new hostname and click Save.

Configuring the hostname using the REST APIs

To configure the hostname using the REST APIs, see the /edge/configuration/hostname API in the Cumulocity Edge OpenAPI Specification.

Configuring the time synchronization

For many use cases, and especially when using Apama, the time inside the Edge appliance must be synchronized with the network. Time synchronization helps in logging events accurately and compare the data from multiple devices.

By default, the chrony service is responsible for time synchronization with the host operating system. For Hyper-V, the chronyd service is disabled by default for accurate time synchronization.

Once the time synchronization is enabled, you can specify the NTP servers and the interval to trigger the time synchronization.

Configuring the time synchronization using the UI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Time synchronization in the navigator.

4. Use the toggle button to enable the time synchronization.

5. Click Edit to specify the NTP servers and the interval to trigger the time synchronization.

Configuring the time synchronization using the REST APIs

To configure the time synchronization using the REST APIs, see the /edge/configuration/time-sync API in the Cumulocity Edge OpenAPI Specification.

Configuring the microservice hosting feature

Microservices are server-side applications which may be used to extend the Edge platform with customer-specific functionality. For more information, see Microservice SDK. When you enable or disable the microservice feature, the Device simulator microservice also gets enabled or disabled. To use the Device simulator, add the Simulator permission. For more information, see Global roles.

For more information about Device simulator, see Working with simulators.

If you want to use the microservice hosting feature, ensure that you do not use these IP ranges in your local network where the Edge virtual machines are configured. When you enable the microservice hosting feature, the Kubernetes system reserves these IP ranges on the Edge instances.

• 10.96.0.0/12

Enabling the microservice hosting feature takes about 10 to 15 minutes to complete.

Enabling or disabling the microservice hosting feature using the UI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Microservices in the navigator.

4. Use the toggle button to enable the microservice hosting feature.

To deploy a microservice, in the Administration application, navigate to Ecosystem > Microservices, and click Add microservice.

Upload the ZIP file for your microservice application. For more information about deploying a microservice, see Deploying the “Hello world” microservice.

After you have enabled the microservice hosting feature, ensure that the microservices are active and healthy before using them. For more information, see Microservice runtime.

Before disabling the microservice hosting feature, you should unsubscribe from all the microservices that have been uploaded. You can also delete the microservice if you are not planning to enable again and subscribe to the same microservice. For more information about developing and hosting a microservice, see Microservices SDK.

Enabling or disabling the microservice hosting feature using the REST APIs

To enable or disable the microservice hosting feature using the REST APIs, see the /edge/configuration/microservices API in the Cumulocity Edge OpenAPI Specification.

Deploying microservices with a lower manifest version

A microservice specifies an API version in the microservice manifest. Depending on this API version, the microservice runs with all or only a restricted set of Linux kernel capabilities. More precisely, all capabilities are granted to microservices with API version 1 whereas only the capability CAP_NET_BIND_SERVICE is granted to microservices with API version 2. For more information, see Microservice migration to API Version 2.

By default, only the Management tenant can upload and subscribe to the microservices with API version 1. To improve the security of the Edge appliance, the minimum API version has been configured to API version 2. Due to the minimum API version configuration, you cannot upload and subscribe to a microservice with API version 1 in the “edge” tenant.

To upload and subscribe to a microservice with API version 1 in the “edge” tenant:

1. Log in to the Management tenant.
2. Enable the microservice hosting feature, if not already enabled.
3. Go to Tenants > Subtenants and click the “edge” tenant.
4. Go to Applications and subscribe to the Feature-privileged-microservice-hosting application from the Available applications.
   Info

   It might take up to ten minutes until the “edge” tenant is able to upload and subscribe to privileged microservices.
5. Log in to the “edge” tenant and upload a microservice with API version 1.

Configuring security

Configuring security using the UI

The Edge appliance is security hardened by default. Furthermore, you can apply specific security configurations to enhance the security of your Edge appliance.

To apply the security configuration, follow the steps below:

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Security in the navigator.

4. Click Download configuration to download a sample JSON syntax for the current configuration. You can use the same JSON file in the POST operation using the REST API.

5. Click Edit configuration to edit the configuration.

   You can either import a JSON file to prefill the values or enter the values manually.

6. Specify the following parameters:

   Configuration	Category	Parameter	Description
   Operating system	SELinux	SELinux mode	SELinux secures the operating system from unprivileged actions of confined users. When enabled, SELinux has two modes: permissive and enforcing. permissive: In the permissive mode, SELinux policy is not enforced. The system remains operational and SELinux does not deny any operations but only logs AVC messages, which can be then used for troubleshooting, debugging, and SELinux policy improvements. Each AVC is logged only once in this case. enforcing: In the enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. Important In the enforcing mode, you cannot access the Edge appliance remotely through VNC. Default value: permissive
   	SSH	SSH enabled	Enables or disables the SSH functionality of the Edge appliance. By default, the SSH functionality is enabled. Changing the value to false disables the SSH functionality. When disabled, you will not be able to SSH into the Edge appliance, locally or remotely. Default value: True
   	Session inactivity	Login sessions inactivity timeout (seconds)	The idle duration before a user session is terminated. When configured, the user session terminates after the specified idle duration. Default value: 600 seconds Minimum value: 0
   	Linux Auditing System	Audit logging enabled	The Linux Auditing System helps system administrators create an audit trail, a log for every action on the server. You can track the security-relevant events, record the events in a log file, and detect misuse or unauthorized activities by inspecting the audit log files. Enables or disables Linux Auditing System. A value of true enables and creates an audit log file at /var/log/audit/audit.log. Enabling auditing system increases the consumption of disk space. You can configure the operating system to transfer the audit logs to a centralized logging server by configuring Audisp remote logging server. Important Once enabled, you cannot disable the auditing system configuration. Default value: False
   	Remote logging	Audisp remote logging server	The centralized logging server to transfer the audit logs to. When configured, the operating system audit logs are transferred to the specified centralized logging server.
   		Server	The IP address or the hostname of the destination server.
   		Port	The port on the destination server.
   	Remote logging	Rsyslog remote logging server	The centralized logging server to transfer the local logs to. When configured, the local logs are transferred to the specified centralized logging server.
   		Server	The IP address or the hostname of the destination server.
   		Port	The port on the destination server.
   		Protocol	The protocol (TCP or UDP) used to transfer the logs.
   	Login banner	Login banner	The login banner for your Edge appliance.
   Kubernetes	Audit policy		Kubernetes audit policy defines the rules about what events should be recorded and what data they should include.
   		Level	The audit level controls what Kubernetes event data is recorded. When configured, the Kubernetes event data is logged to the specified level. Logging more data increases the consumption of disk space. None - do not log events. Metadata - log request metadata (requesting user, timestamp, resource, verb, and so on) but not request or response body. Request - log event metadata and request body but not response body. This does not apply for non-resource requests. RequestResponse - log event metadata, request and response bodies. This does not apply for non-resource requests. Default value: None
   		Maximum age (days)	The maximum number of days to retain the old Kubernetes audit log files. A high value has more impact on the disk space. Default value: 30 days Minimum value: 0
   		Maximum numbers of log files to retain	The maximum number of Kubernetes audit log files to retain. Setting a value of 0 indicates that there is no restriction on the number of files to retain. A high value has more impact on the disk space. Default value: 10 files Minimum value: 0
   		Maximum size (megabytes)	The maximum size in megabytes of the Kubernetes audit log file before it gets rotated. A high value has more impact on the disk space. Default value: 100 MB Minimum value: 0

7. Click Save.

Configuring security using the REST APIs

To configure security using the REST APIs, see the /edge/configuration/security API in the Cumulocity Edge OpenAPI Specification.

Changing the domain name

A key feature of Edge is the ability to operate the platform using a custom domain name. This means that you can configure the Edge appliance to serve you using a domain name of choice, for example *.iot.mycompany.com rather than the default URL of Edge. In addition, you can create subtenants using your domain. These will use <subtenantName>.iot.mycompany.com as their host names.

Changing the domain name using the GUI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Domain/Certificate in the navigator.

   Review the domain name and the SSL certificate.

4. Click Edit below Domain name to edit the domain name.

5. Provide the new domain name.

   If the existing license and SSL certificate files are compatible with the new domain name, you do not have to upload the license and certificate files.

   Click Update.

6. If the existing license is not compatible with the new domain name, provide the license file for the new domain name.

   If the existing license is compatible with the new domain name, you do not have to upload the license file.

7. If the existing certificate is not compatible with the new domain name, provide the SSL certificate and key files. If you do not have an SSL certificate, select Generate self signed SSL certificate.

   If the existing certificate is compatible with the new domain name, you do not have to upload the SSL certificate and key files.

8. Click Save.

Changing the domain name using the REST APIs

To change the domain name using the REST APIs, see the /edge/configuration/domain API in the Cumulocity Edge OpenAPI Specification.

License and certificate compatibility

The example below describes a scenario where an existing license or certificate is compatible with the new domain name:

• If you have a license for the domain myown.iot.com, you can change the domain to myown.iot.com and any single level subdomain, for example sub.myown.iot.com

• If you have a certificate for the domain myown.iot.com, then you can only set the domain to myown.iot.com. If you have a wildcard certificate like *.myown.iot.com, then you must set the domain name to any single level subdomain of myown.iot.com, that is sub.myown.iot.com, but not myown.iot.com itself.

Updating the SSL certificate

You must always have a valid SSL certificate for your domain name that is configured. If the validity of the certificate expires or if you have changed your domain name, you must upload or generate a new SSL certificate. You can upload the certificate using the GUI and REST APIs.

Updating the SSL certificate using the GUI

1. Log in to the Management tenant using the Edge administrator credentials created during the installation.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Switch to the Administration application using the application switcher at the right of the top bar .

3. Click Edge > Domain/Certificate in the navigator.

   Review the domain name and the SSL certificate.

4. Click Edit below SSL Certificate to upload the new SSL certificate file and the key file.

5. Provide the new SSL certificate file and the SSL certificate key file.

   If you do not have an SSL certificate, select Generate self-signed certificate to generate one.

6. Click Save.

Updating the SSL certificate using the REST APIs

To update the SSL certificate using the REST APIs, see the /edge/configuration/certificate API in the Cumulocity Edge OpenAPI Specification.

Configuring remote connectivity

For information about connecting your Edge appliance to the cloud tenant, see Connecting Edge to the cloud.

Configuring Karaf

To enhance the performance and resource allocation for Karaf, you can change the environment variables for Karaf (such as JAVA_MAX_MEM and the microservice proxy variables like MICROSERVICE_RUNTIME_PROXY_HTTP_HOST, MICROSERVICE_RUNTIME_PROXY_HTTP_PORT). To do so, you must update the file /usr/share/cumulocity-core-karaf/bin/setenv.:

1. Log in to the Edge appliance.

2. Open the file /usr/share/cumulocity-core-karaf/bin/setenv.

3. Edit the parameters. If the parameter you want to change is present in the file, update its value; otherwise, add a new line: export <PARAMETER_NAME>=<VALUE> at the end of the file.

After changing the file, restart the cumulocity-core-karaf service:

sudo service cumulocity-core-karaf stop

and

service cumulocity-core-karaf start

Increasing the system performance

If the system performance is slow, you must increase the memory. Stop the Edge appliance and increase the memory of the Edge appliance using the hypervisor.

Increasing the memory of the Edge appliance must be followed by increasing the memory of the JVM. To increase the memory of the JVM, edit the value of the JAVA_MAX_MEM parameter as desired by following the steps described above. The default value of this parameter is 2048 MB.

Changing log level for Karaf

This section describes how to change the log level for Edge specific applications in the back-end. It does not explain how to change log settings for standard components like databases or other operating system related services.

The log level for Karaf is defined in the following file.

/usr/share/cumulocity-core-karaf/etc/org.ops4j.pax.logging.cfg

The file has the following structure:

# Root logger
log4j.rootLogger=INFO,out,osgi:*
log4j.throwableRenderer=org.apache.log4j.OsgiThrowableRenderer

# Error appender
log4j.appender.out=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.out.rollingPolicy=org.apache.log4j.rolling.FixedWindowRollingPolicy
log4j.appender.out.rollingPolicy.maxIndex=10
log4j.appender.out.triggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy
log4j.appender.out.triggeringPolicy.MaxFileSize=104857600
log4j.appender.out.rollingPolicy.FileNamePattern=${karaf.data}/log/error-%i.log.gz
log4j.appender.out.rollingPolicy.ActiveFileName=${karaf.data}/log/error.log
log4j.appender.out.layout=org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern=%d{yyyy-MM-dd} %d{HH:mm:ss}  | %-5.5p | %-16.16t | %-32.32c{1} | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n
log4j.appender.out.append=true

# CXF request and response info:
# * ERROR - none
# * INFO - just headers (default)
# * DEBUG - whole, with payloads
log4j.additivity.com.cumulocity.rest.interceptors=false
log4j.logger.com.cumulocity.rest.interceptors=INFO,access

# Access appender
log4j.appender.access=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.access.rollingPolicy=org.apache.log4j.rolling.FixedWindowRollingPolicy
log4j.appender.access.rollingPolicy.maxIndex=10
log4j.appender.access.triggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy
log4j.appender.access.triggeringPolicy.MaxFileSize=262144000
log4j.appender.access.rollingPolicy.FileNamePattern=${karaf.data}/log/access-%i.log.gz
log4j.appender.access.rollingPolicy.ActiveFileName=${karaf.data}/log/access.log
log4j.appender.access.layout=org.apache.log4j.PatternLayout
log4j.appender.access.layout.ConversionPattern=%d{yyyy-MM-dd} %d{HH:mm:ss}  | %-5.5p | %-16.16t | %-32.32c{1} | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n
log4j.appender.access.append=true

# Error response info:
# * INFO - just error message (default)
# * DEGUB - full stack trace
log4j.logger.com.cumulocity.rest.mediatypes=INFO

Change the following entries to adjust the log levels:

log4j.rootLogger=INFO,out,osgi:*

log4j.logger.com.cumulocity.rest.interceptors=INFO,access

log4j.logger.com.cumulocity.rest.mediatypes=INFO

Adjust the log levels by changing the level attribute according to the following values. The levels are inclusive - meaning a given level will also include all “lower” log levels, for example, when you set the level to WARN you will also get ERROR events.

Save the file. It is re-read by the application every few minutes so you do not have to restart the Java process.

Configuring OPCUA

Updating the memory and CPU limit for OPC UA

The memory limit for OPC UA container is set to 2048 MB and the CPU limit is set to 256 as default values. For most use cases, these values are sufficient. You can change the values as per your requirements.

CTRL_DOCKER_OPTIONS="--memory 2048m --cpu-shares 256"

You can specify the CPU limit in --cpu-shares or --cpus.

• --cpu-shares specifies the share or percentage of the host machine’s CPU cycles allocated. For example, --cpu-shares 256 allocates a quarter of total CPUs available.
• --cpus specifies how much of the available CPU resources the OPC UA container can use. For example, --cpus 2 allocates two CPUs out of the available CPUs from the host machine.

For more information about CPU limits, see Docker documentation.

To change the memory and CPU limit:

1. Log in to the Edge appliance.
2. Open the files:
   • /etc/init.d/opcua-device-gateway
   • /etc/init.d/opcua-mgmt-service
3. Edit the parameter CTRL_DOCKER_OPTIONS to the required values.
4. Restart the OPC UA services:

• sudo service opcua-mgmt-service restart
• sudo service opcua-device-gateway restart

Configuring Apama

Updating the memory and CPU limit for Apama

The memory limit for Apama container is set to 2048 MB and the CPU limit is set to 256 as default values. For most use cases, these values are sufficient. You can change the values as per your requirements.

CTRL_DOCKER_OPTIONS="--memory 2048m --cpu-shares 256"

You can specify the CPU limit in --cpu-shares or --cpus.

• --cpu-shares specifies the share or percentage of the host machine’s CPU cycles allocated. For example, --cpu-shares 256 allocates a quarter of total CPUs available.
• --cpus specifies how much of the available CPU resources the Apama container can use. For example, --cpus 2 allocates two CPUs out of the available CPUs from the host machine.

For more information about CPU limits, see Docker documentation.

To change the memory and CPU limit:

1. Log in to the Edge appliance.
2. Open the file “/etc/init.d/apama”.
3. Edit the parameter CTRL_DOCKER_OPTIONS to the required values.
4. Restart the Apama service:

• sudo service apama restart
  Important

  Since the changes to this file are overwritten when the Edge appliance is updated, you must reapply the changes to this file after the update process.

Configuring the email server

Configuring an email server enables you to receive email notifications about events, alarms, and also to reset your password. In case you forget the password, the Edge appliance mails you the password reset link to reset your password.

To configure the “reset password” template and email server settings, perform the following steps:

1. Log into the Management tenant using https://<tenant-domain>/apps/administration/index.html#/configuration.

   • Username: management/<Edge admin username>
   • Password: password provided during the installation

2. Update the email server details and templates as mentioned in Password reset and Email server.