Actions
Bug #2793
closed
accepted nodes can't access their promises even if they are generated
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:
Description
After a migration from 2.3 to 2.4, some accepted nodes can't access their promises directory (/var/rudder/share/nodeid)
but that directory has been created, and promises (common and rules) are generated for that node
the ssh keys are right both on server and node and node hostname is in /etc/host for the corresponding ip
cf-served tells me that :
rudder> Accepting connection from "192.168.42.14" rudder> New connection...(from 192.168.42.14:sd 4) rudder> Spawning new thread... rudder> Allowing 192.168.42.14 to connect without (re)checking ID rudder> Non-verified Host ID is 192.168.42.14 (Using skipverify) rudder> Non-verified User ID seems to be root (Using skipverify) rudder> -> Public key identity of host "192.168.42.14" is "MD5=2bc2e64dcac1e00d06a225db13f3fe48" rudder> -> Last saw -MD5=2bc2e64dcac1e00d06a225db13f3fe48 (alias 192.168.42.14) at Thu Aug 9 11:47:15 2012 rudder> A public key was already known from 192.168.42.14/192.168.42.14 - no trust required rudder> Adding IP 192.168.42.14 to SkipVerify - no need to check this if we have a key rudder> The public key identity was confirmed as root@192.168.42.14 rudder> -> Strong authentication of client 192.168.42.14/192.168.42.14 achieved rudder> -> Receiving session key from client (size=256)... rudder> Filename /var/rudder/share/ab19dd83-b441-4d6e-aed9-35b05ad011ce/rules/cfengine-community is resolved to /var/rudder/share/ab19dd83-b441-4d6e-aed9-35b05ad011ce/rules/cfengine-community rudder> Host 192.168.42.14 denied access to /var/rudder/share/ab19dd83-b441-4d6e-aed9-35b05ad011ce/rules/cfengine-community rudder> Access control in sync rudder> From (host=192.168.42.14,user=root,ip=192.168.42.14) rudder> REFUSAL of request from connecting host: (SYNCH 1344505572 STAT /var/rudder/share/ab19dd83-b441-4d6e-aed9-35b05ad011ce/rules/cfengine-community) rudder> -> Accepting a connection rudder> Denying repeated connection from "192.168.42.14"I have that problem for 2 nodes (over 6);
- one was a pending node in 2.3 migrated and accepted in 2.4
- the other was a fresh 2.4 node
relaunching cf-served fixed that problem
Updated by Vincent MEMBRÉ over 12 years ago
- Assignee changed from Jonathan CLARKE to Nicolas CHARLES
Updated by Jonathan CLARKE about 12 years ago
- Assignee changed from Nicolas CHARLES to Nicolas PERRON
- Target version changed from 2.4.0~beta4 to 2.4.0~beta5
Updated by Jonathan CLARKE about 12 years ago
- Target version changed from 2.4.0~beta5 to 2.4.0~rc1
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
- Status changed from New to Discussion
Sorry, but I can't reproduce this bug.
If I understand well, for testing we should do this:
- Have a Rudder 2.3.8 server (http://www.rudder-project.org/apt-2.3/) on a server
- Have a Rudder 2.3.8 agent (http://www.rudder-project.org/apt-2.3/) on a node
- Use Rudder agent on the node to send inventory to the server
- On the server, upgrade to Rudder 2.4 (http://www.rudder-project.org/apt-2.4/) when the node is pending
- On the node, upgrade to Rudder 2.4 (http://www.rudder-project.org/apt-2.4/)
- Accept the node into Rudder Webapp
- Use Rudder agent on the node to contact the server (cf-agent -KI -b update)
- Be in front of the problem.
Am I right ?
Updated by Vincent MEMBRÉ about 12 years ago
You are almost right
- Have a Rudder 2.3.8 server (http://www.rudder-project.org/apt-2.3/) on a server
- Have some Rudder 2.3.8 agents (http://www.rudder-project.org/apt-2.3/) on a node
- Use Rudder agent on the node to send inventory to the server
- Accept some nodes (not all), apply directive on some of them
- Wait for reports
- On the server, upgrade to Rudder 2.4 (http://www.rudder-project.org/apt-2.4-nightly/) with some pending nodes and some accepted nodes
- On the nodes, upgrade to Rudder 2.4 (http://www.rudder-project.org/apt-2.4-nightly/)
- Accept the other nodes into Rudder Webapp
- Use Rudder agent on the node to contact the server (cf-agent -KI -b update)
- Be in front of the problem.
Pending nodes can't access their directory, but the others can
It was only Beta3 when that bug appears
Updated by Nicolas PERRON about 12 years ago
Ok, then should we consider this bug as rejected ? Jon ?
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
- Assignee changed from Nicolas PERRON to Jonathan CLARKE
Jon, should we reject this bug ? I don't know what to do with this one.
Updated by Nicolas CHARLES about 12 years ago
- Status changed from Discussion to Rejected
Since this bug happened only in beta 3, I'm rejecting it
Actions