Troubleshooting - Adaptive Applications - BlueCat Gateway - 21.2

You can see a list of Docker volumes created on a BDDS by running the following command:

docker volume ls

You can see the location of a Docker volume by running the following command:

docker volume inspect <volume_name>

For example, to view the volume location of Distributed DDNS, run the following command:

docker volume inspect ddns_config

You can list the directory of the log files by running the following command:

docker exec distributed_ddns ls /var/log/distributed_ddns/

You can also see the contents of a log file by running the following command:

docker exec distributed_ddns tail -f /var/log/distributed_ddns/receiver.log

You can list the directory of the configuration files by running the following command:

docker exec distributed_ddns ls /ddns/ddns_service/etc/

You can also see the contents of the DDNS service configuration file by running the following command:

docker exec distributed_ddns cat /ddns/ddns_service/etc/ddns.yaml

You can list the directory of the Anycast configuration files by running the following command:

docker exec distributed_ddns ls /etc/quagga/

You can also see the contents of the Anycast service configuration file by running the following command:

• BGP service configuration file:

  docker exec distributed_ddns cat /etc/quagga/bgpd.conf

• OSPF service configuration file:

  docker exec distributed_ddns cat /etc/quagga/ospfd.conf

• OSPFv3 service configuration file:

  docker exec distributed_ddns cat /etc/quagga/ospf6d.conf

You can list the directory of the configuration files by running the following command:

docker exec distributed_ddns ls /etc/rabbitmq/

You can also see the contents of the queue service configuration file by running the following command:

docker exec distributed_ddns cat /etc/rabbitmq/rabbitmq.conf

You can list the directory of the log files by running the following command:

docker exec distributed_ddns ls /var/log/rabbitmq/

You can list the directory of the configuration files by running the following command:

docker exec <node_name> ls /daemon_run/

You can list the directory of the log files by running the following command:

docker exec <node_name> ls /daemon_run/

You can list the directory of the configuration files by running the following command:

docker exec <node_name> ls /etc/mysql/

You can retrieve the log files by running the following command:

docker logs -f <node_name>

To resolve this issue, disable dnsmasq:

1. Log in to the console of the Distributed DDNS service node.
2. Edit the /etc/NetworkManager/NetworkManager.conf file.
3. Comment out the following line:

   #dns=dnsmasq

4. Reboot the service node using the following command:

   reboot

Once the proxy service node has rebooted and come back up, the DNS server might be set automatically by DHCP. Verify the configuration using the following command:

cat /etc/resolv.conf

If your TSIG Key list could not be loaded in the Distributed DDNS Application Node, check the BlueCat Gateway log files for the following message:

ERROR - Couldn't get tsigs from BAM. Make sure you configured information to initialize connection to database !!!. Details: FATAL: no pg_hba.conf entry for host "192.168.56.106", user "bcreadonly", database "proteusdb", SSL on
FATAL: no pg_hba.conf entry for host "192.168.56.106", user "bcreadonly", database "proteusdb", SSL off

If the DNS server fails to process the update, check the Distributed DDNS log files for the following message:

2019-09-22 23:26:55,220 DEBUG: Response from DNS: <Message id=39580 opCode=5 rCode=9 maxSize=0 flags=answer queries=[Query('56.168.192.in-addr.arpa', 6, 1)] additional=[<RR name=key-example-com type=TSIG class="ANY" ttl=0s auth=False>]>
2019-09-22 23:26:55,221 ERROR: 56118 Update failed by server: verified = 0, rCode = 9. No retry

If these messages exist, verify the following information:

• Check if Distributed DDNS and DNS server are using the same key name. For example, check if the key name is not assigned to an "update-policy" of the zone or is assigned but not deployed to the DNS server.
• Check if the secret, algorithm, and key length are the same for that key name.
• Verify that the time on the Distributed DDNS and DNS server does not differ by more than 5 minutes.

If the Distributed DDNS Service Node fails to process the update, check the Distributed DDNS log files for the following message:

"Failed permission: Update is not allowed or denied explicitly"

If the messages exist, check the Distributed DDNS workflow configuration to see if there are any permissions configured for the updated zone. The update is denied in the following cases:

• No permissions are configured. In this case, all DDNS updates are denied.
• No permissions are configured that explicitly allow the resource record to be updated.
• Permissions are configured that explicitly deny the resource record from being updated.