Symptoms
- The agent is sending data, but the dashboard remains empty
- The agent is sending data, but an asset of interest is not listed
- The server is reachable, but the web browser returns an error
- The CodeLogic Server is not running
Solutions
General Solutions
If the system has multiple interfaces, such as the public and private addresses of a cloud instance, verify that port 80 or port 443 (http or https) is not being filtered by a firewall.
Search for the Asset of Interest
The number of assets displayed in the GUI is limited to prevent it from becoming unwieldy.
Adjust the Agent Parameters
The batchSize parameter sets the maximum number of objects that will be sent to the CodeLogic Server.
"batchSize": 750,
If a directory path has been specified as the starting point for a scan, the depth parameter sets the maximum level of subdirectories to scan.
depth: 4
Check the CodeLogic Server Status
Systemd reports the status of the CodeLogic Server. In the example below, active (exited) is the correct status because the docker containers have been downloaded and started.
[abacio@fedora32server16gb ~]$ systemctl is-active codelogic
active
Verify that the CodeLogic Server Containers are Running
The CodeLogic Server is comprised of several containers. All of the containers should have a status of Up.
docker ps --format 'table {{.Names}}\t{{.Status}}'
Sample output that shows all of the containers are running
$ docker ps --format 'table {{.Names}}\t{{.Status}}'
NAMES STATUS
capeui Up 5 days
capeui-server Up 5 days
neo4cape-service Up 5 days (healthy)
fusionauth Up 5 days
neo4j Up 5 days
mongodb Up 5 days
postgres Up 5 days
nginx Up 5 days
codelogic_autoheal_1 Up 5 days (healthy)
Verify the Server Host Resolution
A networking problem may result in a timeout while trying to connect to the GUI. The root cause may be that the localhost or server name is not being resolved correctly. If you see messages, like those below, try using the IP address in the browser. If that works, verify that /etc/hosts is correct and that any certificates are valid.
For example, try http://192.168.1.87/codelogic/ui instead of http://"name_of_your_codelogic_server"/codelogic/ui.
Valid URLs are similar to: https://staging-server.company.com or https://192.168.1.54
docker logs capeui
docker logs capeui-server
docker logs nginx
Sample output showing the GUI awaiting a connection
$ docker logs capeui
INFO: Accepting connections at http://localhost:5000
Sample outputs showing that the host cannot be found
$ docker logs capeui-server
…
no access token cookie defined
{"exception":{"message":"request to http://ub18codelogicserver.local/oauth2/token failed, reason: getaddrinfo ENOTFOUND ub18codelogicserver.local","type":"system","errno":"ENOTFOUND","code":"ENOTFOUND"}}
in error
$ docker logs nginx
…
2020/12/03 16:58:02 [error] 26#26: *8 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.87, server: localhost, request: "GET /codelogic/middleware/api/auth/callback?code=1myBZ1hHULxJpBaXyezM-W0ba3J0glZVCmNLO2taO4A&locale=en_US&userState=Authenticated HTTP/1.1", upstream: "http://172.18.0.9:7000/api/auth/callback?code=1myBZ1hHULxJpBaXyezM-W0ba3J0glZVCmNLO2taO4A&locale=en_US&userState=Authenticated", host: "ub18codelogicserver.local", referrer: "http://ub18codelogicserver.local/oauth2/authorize?client_id=7fd32680-700e-4bfc-9ac0-bb7e17f63b70&redirect_uri=http://ub18codelogicserver.local/codelogic/middleware/api/auth/callback&response_type=code&scope=openid%20email"
…