Policy Updates issues include:
- You get an error when running "rudder agent update", or it is really slow
- The compliance tab of a node says it is sending reports with on old Configuration Id
How to fix it?
- You should begin by checking network connectivity to the destination port on the policy server from the node (for example with nc -v IP_OR_HOST 5309)
- If you notice that "rudder agent update" seems very slow each time you run it, it may be a DNS resolution issue. The server tries a reverse resolution on the IP of the host, and is probably timeouting, which explains the long execution time. Make sure the server can resolve it (for example by adding it to the /etc/hosts of the server) and the update duration should be normal. You can get a list of unresolvable IPs with "rudder agent health".
- If you see the error: Failed to establish TLS connection: socket closed message, it probably means that your host is not in the allowed networks and get refused just after connection. Add a subnet containing its IP to the allowed networks and it should be able to connect.
- If >4.0 nodes try to connect to a <4.0 server, you may face communication issues, particularly if those nodes are behind a NAT. The supported upgrade path to 4.0+ is to upgrade the server first to avoid those issues.
- If a node you just added cannot update its promises, check that policy generation has finished successfully. If it is good, this may be an issue while reloading cf-serverd configuration (the policies server). You can check if this is the case by restarting it manually with "service rudder-agent restart" on the policy server.
- If the node has been cloned from another Rudder node, ensure it has a different UUID and key. If not, run rudder agent reinit to make it seen like a new node.
- If the node has change its IP or policy server (and sent an inventory to report the changes), the policy regeneration is currently not automatically triggered, and you have to force it.
Customer support service by UserEcho