Project

General

Profile

Actions

Bug #16754

open

TLS connection error to a fresh relay - cf-serverd config not reloaded

Added by François ARMAND over 4 years ago. Updated about 1 year ago.

Status:
New
Priority:
N/A
Assignee:
-
Target version:
Severity:
Minor - inconvenience | misleading | easy workaround
UX impact:
User visibility:
Operational - other Techniques | Rudder settings | Plugins
Effort required:
Priority:
0
Name check:
To do
Fix check:
To do
Regression:

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.

Actions #1

Updated by François ARMAND over 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'
...

Actions #2

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 6.0-1.3 to 6.0-1.4
Actions #3

Updated by François ARMAND over 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.

Actions #4

Updated by François ARMAND over 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
Actions #5

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 6.0-1.4 to 6.0-1.5
  • Priority changed from 31 to 30
Actions #6

Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 6.0-1.5 to 7.2
  • Priority changed from 30 to 0
Actions #7

Updated by Alexis Mousset about 1 year ago

  • Target version changed from 7.2 to 7.3
Actions

Also available in: Atom PDF