[EdgeView 2 V2.7
Vida Hubbert
To run EdgeView client script, the docker is required on user's laptop. The EdgeView client program is started in a script with 'docker run'. For an example of the client script, see EdgeView Client Script. The EdgeView commands are checked against EdgeView Policies to be allowed to run on devices.
When the EdgeView is started based on the configuration on the controller, it can be a single instance or multiple instance session. The multi-instance case is used when there is a need for multiple users to access the device or applications at the same time. For the multi-instance session, the user needs to supply the 'instance ID' when issuing EdgeView command, for example with the above 'edgeview.sh' script, an instance number is needed:
It will display the access list for running ACL and also configured ACL of the EVE device. To see a subset on iptables, use the filter string. The filter string can be 'raw', 'filter', 'nat' or 'mangle'.
The 'addhost' command adds one entry of specified hostname to IP address mapping into the EdgeView container's '/etc/hosts' for. This can be useful if there is no DNS entry for the hostname and the user knows the static mapping. An example:
If the command is issued without the '/', it will display all the user (or DomU) applications running on the device. For each application, it displays the App number, UUID, network bridge information, status in terms of boot time, CPU and memory, it also displays the VNC and App log settings.
if the '/' is supplied in the command, it will display the specific user application with more detail information. The 'app-string>' is a subset of the App name string regardless of cases. For example, if the app name is 'cluster-k3s-2-agent1', one can use 'app/agent' to query. Besides the above information, it gets more networking information from the application. It will try to ping the App IP address to see if it is 'Up', it will get the DHCP info of the application, and iptable rules related to the application.
This display can be used for troubleshooting network port issues when there is a configuration change. It displays the list of port configurations of the interfaces, and the current index in the list. When the EVE device can not connect to the controller, it will try to connect to the controller with a different port configuration on this list periodically.
The 'flow' command displays the content of the Linux Conntrack table. It contains the detailed network 5-tuple information for EVE device and user applications current network endpoints information. One can use filters to search for specific IP addresses or port numbers for display.
The mDNS is a multicast protocol for auto discovery of services. It will send queries over all the 'UP' interfaces on the device to discover the service being advertised. By default it sends out for 'workstation._tcp' service which is a well-known mDNS service supported.
The EVE 'local datastore' implementation for App is based on the mDNS to bind the domain name with '.local'. This 'mdns' command can be used to query on the bridge where the App is located and to see if it replies with the service for datastore image download.
The 'ping' command if without any option, it will try to ping '8.8.8.8' and the controller of the EVE device from each of the interfaces. It can take a domain name or IP address option to send out the ICMP packets. It can be used on internal IP addresses such as App interface IP address, or on external servers to see if the device can reach it.
The 'showcerts' command displays remote server or peer TLS certificates. It can optionally take the server side URL and also the proxy setting for proxy IP address and port. If no option is given, the showcerts finds the controller URL in '/config/server' file for the URL part. If the management port has proxy configuration, the 'showcerts' uses the proxy IP and port when querying the controller site.
The bellow example displays the 'showcerts' without option, the server url is 'zedcloud.local.zededa.net', and the proxy is '31.198.61.228:3128'. The certificates from the peer are belong to the server or the controller, not to the proxy server. This may help the toubleshooting to determine if the proxy is a passthrough or a MiTM type.
The 'speed' command uses the 'speedtest' utility to measure the download and upload speed of the device. The outbound interface name can be supplied to run the speed test over that port. An example of the output:
The user can also supply more 'tcpdump' options such as port number or host IP address using e.g. 'port 53' or 'host 10.10.10.10' to capture the IP packets with those filters. The command will return the results either it times out or it has captured the maximum of 100 packets. The default timeout is 60 seconds. The user can specify the timeout in the range of (1, 120) seconds by '-time '.
The 'trace' command uses the 'traceroute' utility of Linux and returns the hop-by-hop result if available. It uses two-queries per hop (useful in ECMP) and it is limited to a maximum of 10 hops. The option can be an IP address or domain name.
The 'url' command is for the statistics of different services to the controller and data-stores. The services include 'zedagent', 'zedrouter', 'loguploader', etc. This stats is kept from the device reboot time. The command also displays the management interface traffic send and receive stats. An example of a subset of output:
This example here is the part for EVE 'zedagent' service send/receive from different URLs for downloading device configure and upload device info messages. The stats contains the send and receive payload bytes, and number of messages (in 'SendMsg'). The 'TLS resume' indicates among all the TLS message exchanges, how many have the 'TLS resumption' (defined in RFC-5247). The stats has also the total round-trip time it spends on all those messages with that URL.
The 'wireless' command displays the 'wlan' and 'wwan' interfaces (if they exist on the EVE device) relation information, such as 'wpa_supplicant.conf' file content, the port configuration for the wireless interfaces and status.
The 'configitem' is user supplied configuration for the EVE device, for example to change the default logging on device from 'info' into 'debug'. This 'configitem' command will display all the available items and also highlight the changed values in color (if the terminal supports that). It has the global items and EVE agent specific items if changed. An example of changed 'debug.enable.usb' item in part of the output:
The option can take a '-line ', and this is similar to Linux 'head' and 'tail' utility to only display the number of lines from the file depending on whether the is a positive or negative value. For example to tail the last 5 lines of the current device log:
On EVE devices, it needs to be configured with datastore(s) for image downloading. The EVE image datastore is by default configured. The application image datastore is dynamically configured on the EVE device depending on the applications.
The 'download' command displays (only if the device is currently downloading image(s)) the configuration for download, and the status of downloading or progress. It also displays the download statistics since the last reboot.
The 'newlog' command displays the device logging statistics since the last reboot, and also it displays the logging zip file directory for 'devUpload', 'appUpload' and 'keepSentQueue' for the number of files in directory and time range of the files.
The 'tar' command generates a tar file from the directory on a remote device with the given path. It will deposit the tar file in the mounted directory on the user's laptop for downloading files. This command allows the directory with data up to 512 MBytes. Certain directories may have user sensitive data and can not be tarred, e.g. '/persist/vault', '/persist/clear' and '/run/domainmgr/cloudinit'. The files with file name ends with '.key.pem' and '.key' will not be included in the tar file.
The 'log' command is used to search for log entries for the device and applications. Even though the logs are normally uploaded to the controller side, the users of the enterprise may not have the capability to search in the cloud. The application logs depending on the setting, it can be configured not to upload, then the only way to view them is through this 'log search' in EdgeView if needed.
Another way to study the log entries from the EVE device is to upload the log files onto the user's laptop. Since the user may not know what to search and wants to save the complete log entries during the time frame for more careful examination now or later. Because there is no search string needed, EdgeView reserves the string 'copy-logfiles' for this purpose. The command 'log/copy-logfiles' is used to upload log entries onto the user's laptop. The time range format is the same as log searches described above, except that the maximum range is 30 minutes.
The files will be uploaded onto the user's EdgeView container directory '/download', and when using the 'docker run' for EdgeView, it needs to mount the volume from your local directory onto the docker's '/download'.
In this example, since the user does not use time option, by default it is now to 30 minutes before. It creates a directory under the '/download' with the timestamp of current time in 'yyyymmddhhmmss' format. there are 6 device log gzip files, and 6 app files (belong to the same app). It is then decompressed to the gzip files and merged into text files with JSON format for each log entry inside. There will only be one device log file, there can be zero or more application log files with the app UUID in the filename. The text log files keep the strict time order of the log entries from the earliest to the latest.
The 'pub' commands are meant for users who have extensive EVE internal knowledge. EVE-OS has many services, e.g. 'zedagent', 'zedrouter', etc. Each service publishes some configuration or status for other services to consume or to subscribe. All those publications reflect the current state of EVE operation. When troubleshooting a problem, sometimes one needs to know what a service is publishing to see if it is correct. The majority of the publications are in the directory '/run//'. A service can publish one or more types of data, which are located in its subdirectories.
795a8134c1