Bug #2642
closedError message in initial promises about non-existant share for node should be clearer
Description
When a node (its uuid is db78b5ab-387a-418a-88a6-481ad71fc34c) send his inventory to the Rudder server for the first time, it displays an error about it's promises directory. This is normal, since it doesn't exist yet, but can be alarming for the user:
rudder> Couldn't resolve filename /var/rudder/share/db78b5ab-387a-418a-88a6-481ad71fc34c/rules/cfengine-community from host 192.168.42.81 rudder> !!! System error for lstat: "No such file or directory" rudder> Couldn't stat filename /var/rudder/share/db78b5ab-387a-418a-88a6-481ad71fc34c requested by host 192.168.42.81 rudder> !!! System error for lstat: "No such file or directory" rudder> Access control in sync rudder> From (host=192.168.42.81,user=root,ip=192.168.42.81) rudder> REFUSAL of request from connecting host: (SYNCH 1341836740 STAT /var/rudder/share/db78b5ab-387a-418a-88a6-481ad71fc34c/rules/cfengine-community)
We should change, or add, the error message to say something like "This error is happenning because this node has not yet been accepted by the Rudder server. Visit the web interface to accept it."
Updated by Jonathan CLARKE over 12 years ago
- Status changed from New to Discussion
- Assignee changed from Nicolas CHARLES to Vincent MEMBRÉ
Vincent MEMBRÉ wrote:
When a node (its uuid is db78b5ab-387a-418a-88a6-481ad71fc34c) send his inventory to the Rudder server for the first time, i got an error
[...]
Should it not be created before ?
No. This is expected behaviour.
Let me explain: initial promises are for bootstrapping a node. They basically do 2 things:- Make an inventory of the node and send it to the server. This allows the administrator to "accept" the node in the web UI.
- Try and get it's own promises, from the directory on the server /var/rudder/share/<node's UUID>.
When you accept a node, the Rudder server creates /var/rudder/share/<node's UUID> and populates it with the node's promises. So, until you've accepted a node in the Rudder UI, it is normal that this directory does not exist.
However, clearly, this error should be explained, so that others don't think that it's a problem the same way you do.
Can you please confirm that once you accept the node in the web UI this error disappears?
Updated by Vincent MEMBRÉ over 12 years ago
Yes that error disappeared once i accepted that node, thanks for the explanation,
I was confused as i thought this explained why my inventory was not send to the server, but obviously it's not related.
I think you're right, the error message should be more explicit maybe like "/var/rudder/share/uuid not found : node has not been accepted yet"
Updated by Jonathan CLARKE over 12 years ago
- Subject changed from inventory not accepted by Rudder Server to Error message in initial promises about non-existant share for node should be clearer
- Description updated (diff)
- Status changed from Discussion to 2
- Assignee deleted (
Vincent MEMBRÉ)
Updated the ticket to be about changing this error message.
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 50 to 2.4.0~beta3
Updated by Nicolas PERRON over 12 years ago
- Target version changed from 2.4.0~beta3 to 2.4.0~beta4
This is not a blocking issue so I moved it to the next run
Updated by Jonathan CLARKE about 12 years ago
- Target version changed from 2.4.0~beta4 to 2.4.0~rc1
Updated by Jonathan CLARKE about 12 years ago
- Assignee changed from Nicolas PERRON to Jonathan CLARKE
Updated by Jonathan CLARKE about 12 years ago
- Target version changed from 2.4.0~rc1 to 2.4.0~rc2
Updated by Nicolas PERRON about 12 years ago
- Target version changed from 2.4.0~rc2 to 2.4.0~rc1
Updated by Nicolas PERRON about 12 years ago
- Target version changed from 2.4.0~rc1 to 2.4.0~rc2
Updated by François ARMAND almost 12 years ago
- Assignee changed from Jonathan CLARKE to Nicolas CHARLES
NCH, could you take a look to that one ?
Updated by Nicolas CHARLES almost 12 years ago
- Priority changed from 2 to 4
There is no easy way to distinguish between a Server not repsonding (down, or wrong IP), and the path not existing (node not yet accepted)
So the only relevant thing I could do for this RC would be to add a message at the end saying that it was impossible to fetch the promises, and the most likely reason is that the Node has not yet been accepted within Rudder, or that the Rudder server is unreacheable
Updated by Jonathan CLARKE almost 12 years ago
Nicolas CHARLES wrote:
There is no easy way to distinguish between a Server not repsonding (down, or wrong IP), and the path not existing (node not yet accepted)
So the only relevant thing I could do for this RC would be to add a message at the end saying that it was impossible to fetch the promises, and the most likely reason is that the Node has not yet been accepted within Rudder, or that the Rudder server is unreacheable
This would be a good start; Please make the report human readable and very obvious, something like this:
********************************************************************************* * rudder-agent could not get an updated configuration from the policy server. * * This can be caused by a network issue, an unavailable server, or if this * * node has not yet been accepted in the Rudder web interface. * * Any existing configuration policy will continue to be applied without change. * *********************************************************************************
Updated by Nicolas CHARLES almost 12 years ago
- Status changed from 2 to In progress
Updated by Nicolas CHARLES almost 12 years ago
Originally, this ticket targets only the initial promises, but the message seems to state that an existing configuration could exist, hence for non-initial promises also
Jon, could you clarify please if it has to be also implemented within the common technique ?
Updated by Jonathan CLARKE almost 12 years ago
Nicolas CHARLES wrote:
Originally, this ticket targets only the initial promises, but the message seems to state that an existing configuration could exist, hence for non-initial promises also
Jon, could you clarify please if it has to be also implemented within the common technique ?
Right, we need two different messages. I was just giving an example, but here are the exact ones to use:
Initial promises :
********************************************************************************* * rudder-agent could not get an updated configuration from the policy server. * * This can be caused by a network issue, an unavailable server, or if this * * node has not yet been accepted in the Rudder root server. * *********************************************************************************
Technique common :
********************************************************************************* * rudder-agent could not get an updated configuration from the policy server. * * This can be caused by a network issue, an unavailable server, or if this * * node was deleted from the Rudder root server. * * Any existing configuration policy will continue to be applied without change. * *********************************************************************************
Updated by Nicolas CHARLES almost 12 years ago
- Status changed from In progress to Pending technical review
The pull request is here : https://github.com/Normation/rudder-techniques/pull/7
Updated by Nicolas CHARLES almost 12 years ago
- Assignee changed from Nicolas CHARLES to Jonathan CLARKE
Updated by Jonathan CLARKE almost 12 years ago
- Status changed from Pending technical review to Released
Nicolas CHARLES wrote:
The pull request is here : https://github.com/Normation/rudder-techniques/pull/7
Looks fine to me, merged.
Updated by Jonathan CLARKE almost 12 years ago
- Status changed from Released to Pending release
Updated by Jonathan CLARKE almost 12 years ago
- Assignee deleted (
Jonathan CLARKE)
Updated by Jonathan CLARKE almost 12 years ago
- Status changed from Pending release to Released