The G-Series Micro is designed to provide a low-cost “gateway” option to the new Cloud Drive service. The machine will come with 2 Professional licenses.
Specs:
Intel Celeron (J3455)
2GB DDR RAM
Dual Gb NICs
HDMI and mini DP monitor outs
1 TB 2.5inch HDD
4 USB Ports
Palm size form factor
Ubuntu 16.04
Includes the standard exacqVision Linux image comparable to Z, S, A and LC Series machines.
Key Differentiators
Low storage capacity
Small Form Factor
Fan-less, quiet
Additional Documentation
Quick Start Guide coming soon…
Other information
This machine should be troubleshot similar to any machine with the standard exacqVision Linux image. Like the LC, the Operating System will reside on the spinning Hard Drive. If the drive is replaced, the machine will need to be re-imaged.
To better address the root of customer questions about Web Service security without creating more confusion.
Change
Engineering has requested that Support Technicians refrain from explaining the new Web Service as “having a ‘Go’ Web Front End”. Rather, let the customer know that the new Web Server is “Custom”, or “written in-house”. As comparison, it’s unnecessary to offer that ESM is primarily written in Python, or that the Client uses C++ and wxWidgets. For detailed information on why this is necessary, and what customers are really asking, see below.
Customers who have been receiving security compliance scans are accustomed to needing to update their Web Service to get the latest security fixes. Since version 2.4.0, the open-source Apache has been used by the exacqVision Web Service. Apache is widely used around the world, and is (along with every other major Web Server) a common target of malicious attack. This necessitated a process of “ever-updating” to make sure the customer is not vulnerable to the latest threats.
Beginning in Web Service version 9.0, the Apache HTTP Server was removed in favor of using a custom, in-house built Web Server. This was not simply to achieve “security through obscurity”, rather we now have much more control over what changes are made to our Web Server, as well as the ability to optimize the functionality with our product. This has led to great gains in the speed of Web Service functions.
Customers are now asking what the new Web Server is and what kind of implication this has to the Security of the Web Service. In trying to understand the change, many Support Technicians are in the habit of explaining the new Web Service as “having a ‘Go’ Web Front End”. This is because the new Web Server is written in the Go Programming Language. However, it’s unnecessary to offer what Language the software is written in. Engineering has requested that we refrain from offering that it’s written in “Go” since this will inevitably lead to further un-needed questions.
What customers are really asking is: “What effect does this change have on maintaining a secure Web Service?” The answer is: “It depends.”
Normally, customers’ concerns regarding Web Service security are raised by a PCI Compliance Scan as required by the ‘Payment Card Industry Data Security Standard’. Since Apache versions are closely monitored in these scans, and the exacqVision Web Service required user interaction to update the embedded Apache, our software commonly showed as problematic on these scans. Since all PCI scans are different, customers should re-run these scans after updating to 9.0 to see if they still show vulnerabilities. If any are found, customers are encouraged to setup their own web service gateway and enforce custom security policies as required by their company’s requirements. Instructions can be found in KB 47080. Customization of the exacqVision Web Server security policies will be limited, but not impossible. If many customers are reporting the same issue, this will need to be escalated to the Engineering team for consideration.
Eliminating false positive ‘Offline’ drive status in Linux
Change
Because of the way Linux handles how processes can trigger other sub-processes, certain features would fail if the ‘core’ process was utilizing more than 50% of its available memory. In exacqVision 9.2 and earlier, ‘smartctl’ commands could be blocked resulting in the drive status ‘Offline’. This was misleading since the drive was not actually offline, rather, the status was unknown since the ‘smartctl’ command to get the status was blocked due to limited resources.
Beginning in 9.4, this scenario is detected and the drive status results in ‘Poll Error’. This status does not mean that a drive is failing, only that the status is unknown. Likely, the system is still able to write to the disk. It may be worth troubleshooting what is causing the high RAM usage.
As per SCN – 00000008 – Privileged exacqd process, these sub-processes are moving to ‘exacqd’ and will no longer be triggered by ‘core’. It is highly unlikely that ‘exacqd’ will ever be in a high RAM usage state. Therefore, the ‘Poll Error’ is expected to go away with exacqVision 9.8, when all sub-processes will be triggered by ‘exacqd’.
SysMgmtPI Warning Self-test command failed: SysMgmtPI Warning Failed to start process /usr/local/exacq/server/smartctl –scan SysMgmtPI Warning Failed to scan disks with smartctl SysMgmtPI Verbose Disk /dev/sd? overall health assessment :
The same cause which results in the false positive ‘Offline’ drive status (or ‘Poll Error’) could also result in any of the following sub-processes to fail as well:
Feature
Windows Binaries
Linux Binaries
Network Configuration
netconfig.ps1 teaming.ps1
netconfig.sh
Remote Updates
curl.exe update.ps1
curl update.sh
Auto Export (to CD/DVD)
dvd+rw-mediainfo.exe wodim.exe
dvdrwtools wodim
Notifications (Email)
curl.exe
curl
Archiving/Extended
curl.exe
curl parted mount
DHCP Server
opendhcpserver.exe
opendhcpd dhcpconfig.sh
IP Camera Detection
mDNSResponder.exe
mdnsd
Extended Drives
iscsiprep.ps1
iscsiprep.py mkbadst_config.sh
Disk Monitoring
evselftest.exe smartctl.exe
evselftest smartctl
Disk Prep
driveprep.ps1
driveprep.sh rmfs.sh
Failover
failover.ps1
failover.sh
Hardware Monitoring
sysinfo.ps1
lshw
Time/Date/Timezone/NTP
tzutil.exe w32time
ntpd ntpdate
LDAP Queries
curl.exe
curl
All sub-processes are expected to be moved to ‘exacqd’ in 9.8.
CyberProtection requirement that software not run with elevated privileges by default.
Change
Traditionally, one process runs when the exacqVision Server Service starts: ‘core’ (Linux) or ‘core.exe’ (Windows). Beginning in 9.6, tasks that require activating a binary or script will be moving (over time) to the new ‘exacqd’ (Linux) or ‘exacqd.exe’ (Windows) process. This includes executables packaged with the Server installer, as well as OS-level programs.
The following binaries will be executed by exacqd in 9.6 (others will move in upcoming releases):
On Service start, the exacqd process will start first, which will then start core. Additionally, exacqd will restart core if it crashes. These two processes will communicate with each other through a protected pipe (IPC). The user experience should be exactly the same after upgrading.
One improvement due to this change is that the exacqVision Server start/stop is now significantly faster.
Eventually, the ‘core’ process will be able to run without elevated privileges. In problem scenarios, ‘exacqd’ will be able to restart ‘core’, but ‘core’ cannot restart ‘exacqd’. While unlikely, if the ‘exacqd’ process dies, the Server logs will show:
exacqd ipc pipe disconnected sleeping for one minute to allow active watchdogs to expire...
To assist in troubleshooting when drives are rejected for recording.
Change
Traditionally, the File Plugin (PSFPI) has logged ‘could not get record volume’ if no drives were found with space available. However, there are several scenarios that could lead to this result. Beginning in 9.6, the plugin will now provide additional logging to help understand the cause.
Here are some examples of the new log messages and their meanings:
PSFPI Warning 2 of 3 volumes are eligible for recording
This indicates the amount of drives checked for recording eligibility.
PSFPI Warning 2 bookmarks using 4.38GB
This shows how many files are bookmarked and cannot be deleted.
PSFPI Warning system has “At Least” rule configured for 30 days
This indicates if a system wide ‘At Least’ expiration rule is in place and for how long that video cannot be deleted.
PSFPI Warning stream 4720384 has “At Least” rule configured for 7 days PSFPI Warning stream 4720896 has “At Least” rule configured for 30 days
These indicate if per-device ‘At Least’ expiration rules are in place.
If drives are rejected for recording, the reason is indicated by the following:
PSFPI Warning volume C:\ rejected for recording: disabled
Drive has been manually disabled (un-checked) on the ‘Drive” tab.
PSFPI Warning volume D:\ rejected for recording: alarmed
Drive is currently in an alarmed state.
PSFPI Warning volume /mnt/edvr/2 rejected for recording: insufficient space: 1 GB wanted, 0GB available (reduced space from config slider: 30GB
This indicates that storage space is insufficient because files that cannot be deleted are consuming all available space; including space reserved by the ‘Video Space’ slider.
Once recording starts again, a log message will indicate which drive is now eligible.
PSFPI Verbose volume S:\ is now eligible for recording
Ever since the Server version 5.8, the Update plugin allowed Support to upgrade and downgrade the Server version using the ‘Update’ tab.
Prior to 9.4, the Linux installers were not digitally signed. Beginning in 9.6, the Update plugin will require the installers to be digitally signed before completing the installation process. If you attempt to downgrade beyond 9.4, the Client will display the following failed ‘Update Status’:
With exacqVision Client 9.4 and lower: -22
With exacqVision Client 9.6 and higher: Installer not signed
As a workaround, the software can be downgraded to 9.4 (which does not enforce signing for installers), then downgraded to whatever version is necessary.
Additionally, the un-signed installers can be run manually from within the Server’s Operating System.
With the increase of remote cameras, and as systems become large and more interconnected, it has become increasingly necessary to secure the video stream using SSL.
Change
Several of the IP camera plugins have supported HTTPS connections since 8.4 (Axis/Illustra3), 8.6 (Dahua/HikVision), 8.8 (Samsung) and 9.0 (Acti). However, this only secured the configuration connection and not the RTSP video stream.
Beginning in 9.6, the Axis and Samsung plugins will support a secure connection for both the configuration and the video stream. This will be accomplished by tunneling the RTSP traffic through HTTPS.
Some older cameras have the ability to connect over HTTPS, but are not able to stream video securely. Customers may experience problems after updating to 9.6 if they are using the ‘HTTPS Required’ protocol option.
HTTP – This will cause the camera to connect insecurely over port 80.
HTTPS If Available – This will attempt to connect using SSL. If it fails, HTTP is used.
HTTPS Required – This will force the IP plugin to connect using SSL and fail if the camera is not configured to use SSL. Additionally, if the camera supports HTTPS for configuration, the plugin will request a secure video stream as well.
Beginning with 9.6, the Axis and Samsung plugins will support overrides that force a specific streaming type.
#transport=udp Insecure over UDP
#transport=tcp Insecure over TCP
#transport=rtsph Insecure tunneled over HTTP
#transport=rtsphs Secure tunneled over HTTPS
Additionally, the port used for tunneling can be specified with:
tunnelport={1025-65535}
For instance, to connect to a camera at 192.168.1.1 which supports a secure configuration connection, but not a secure video stream, and specify 5544 as the tunnel port, use the following as the ‘Hostname/IP Address’ on the ‘Add IP cameras’ page:
2021-03 – updated to reflect built-in plugin features
Change
The “exacqVision RTSP Server” was available as a side integration beginning in March of 2018. As of the 19.12 release, these functions have moved into a built-in plugin called ‘rtspserverpi’. The old Integration installers remain available for Windows (64-bit), Linux (32 and 64-bit), and Linux ARM, but most customers will be using the built-in plugin.
The exacqVision Client’s configuration file (edvrclient.ini) will no longer be used. Historically, this file was saved in the local User’s home directory, and was encrypted to hide the saved credentials.
The new XML will be formatted according to evCLI standards and saved in the following locations:
After upgrading, the new workflow for the Client when launched will be the following:
If not found, the Client will generate a per user unique 256bit AES GCM encryption key file (edvrclient.xdk)
Saved alongside the new XML in the above locations.
Machine specific, will not work if transferred to another machine.
If no XML is found, the legacy .INI config file will be loaded and the XML will be saved in the new location. Only the password elements will be encrypted. Everything else will be standard text and editable.
The legacy .INI file will remain intact for downgrade support, but will no longer update as you make changes to the Client.
If the decryption fails, all config elements will be loaded, Systems will attempt to connect, but will result in a failed login state.
If no legacy .INI or .XML is found, the Client defaults will be loaded and saved to a new XML.
Every 30 seconds, the Client will check for changes and re-save the XML, (no longer needs to be closed to save the current view).
evCLI documentation is now included in the install directory: evCLI.pdf
Other information
Old encrypted INI:
New XML with only the passwords encrypted:
This new XML can be modified and re-saved as an .XDV file to launch the Client with specified settings. However, a copied encryption key will not work on another system.
To accommodate customers that want to deploy an XML or XDV with credentials, a new CLI element has been created: PasswordType
By default this will be set to 3 (MachineSpecific), but this can be edited to 0 (Plaintext) and a password can be typed into the XML. For example, the following line:
