Bug #16754
open
TLS connection error to a fresh relay - cf-serverd config not reloaded
Description
I changed a node into a relay, policy generation was triggered, I did a rudder agent run -u on relay, and then on node, on node, with rudder agent run -u, I got:
[root@agent1 vagrant]# rudder agent run -u Rudder agent 6.0.3.rc1.git202002180103 Node uuid: cfff1fe7-2d93-4a4d-814d-1614e8308aaf error: Failed to establish TLS connection: underlying network error (Connection reset by peer) error: No suitable server found R: ********************************************************************************* * rudder-agent could not get an updated configuration from the policy server. * * This can be caused by: * * * an agent key that has been changed * * * if this node is not accepted or deleted node on the Rudder root server * * * if this node has changed policy server without sending a new inventory * * Any existing configuration policy will continue to be applied without change. * ********************************************************************************* error: Rudder agent promises could not be updated. Start execution with config [0]
If I run the relay in debug (rudder server debug XXXX), then I don't get the TLS error:
[root@agent1 vagrant]# rudder agent run -u Rudder agent 6.0.3.rc1.git202002180103 Node uuid: cfff1fe7-2d93-4a4d-814d-1614e8308aaf R: ********************************************************************************* ... etc ...
If I stop debug server, then I get back the TLS error.
After some time, it disappeared - most likely, after cf-serverd was finaly able to restart.
Updated by François ARMAND about 4 years ago
Again, after accepting the node, policy generation, update policies on relay, I had to wait for a long time before having the node be recognized by relay. Before that, the node was rejected while permissions were correct.
So it seems that relay does not re-read its configuration when it should.
Actually, looking at logs, I see that server config re-read was NOT done when I started run by hand (3 times), but it was done on the next automatic agent run.
# agent run by hand at 14:07, 14:08, 14:09 (several times) => no cf-serverd anything
But:
# agent run automatically by scheduler at 14:10 Feb 19 14:10:51 localhost cf-agent[20260]: CFEngine(agent) rudder R: @@Common@@control@@rudder@@run@@0@@end@@20200219-140831-9307ba2@@2020-02-19 14:10:48+00:00##41461ab1-d007-4d15-8958-ca670fe08ee4@#End execution Feb 19 14:10:55 localhost cf-serverd[20047]: CFEngine(server) rudder Rereading policy file '/var/rudder/cfengine-community/inputs/promises.cf' Feb 19 14:10:55 localhost cf-serverd: notice: Rereading policy file '/var/rudder/cfengine-community/inputs/promises.cf' ...
Updated by Vincent MEMBRÉ about 4 years ago
- Target version changed from 6.0-1.3 to 6.0-1.4
Updated by François ARMAND about 4 years ago
- Subject changed from TLS connection error to a fresh relay to TLS connection error to a fresh relay - cf-serverd config not reloaded
So it appears that the problem is that we don't force relay to reload their configuration after an update, so `cf-serverd` waits some time before doing it.
If you do kill -1 PID_cf-serverd on the relay, node can get its updated policies immediatly.
Updated by François ARMAND almost 4 years ago
- Severity set to Minor - inconvenience | misleading | easy workaround
- User visibility set to Operational - other Techniques | Rudder settings | Plugins
- Priority changed from 0 to 31
Updated by Vincent MEMBRÉ almost 4 years ago
- Target version changed from 6.0-1.4 to 6.0-1.5
- Priority changed from 31 to 30
Updated by Vincent MEMBRÉ 9 months ago
- Target version changed from 6.0-1.5 to 7.2
- Priority changed from 30 to 0
Updated by