Project

General

Profile

Actions
Copy link

Bug #2793

closed

accepted nodes can't access their promises even if they are generated

Added by Vincent MEMBRÉ over 12 years ago. Updated about 12 years ago.

Status:
Rejected
Priority:
3
Assignee:
Jonathan CLARKE
Category:
System techniques
Target version:
2.4.0~rc1
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

Actions
Copy link
 #1

Updated by Vincent MEMBRÉ over 12 years ago

  • Assignee changed from Jonathan CLARKE to Nicolas CHARLES
Actions
Copy link
 #2

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
Actions
Copy link
 #3

Updated by Jonathan CLARKE about 12 years ago

  • Target version changed from 2.4.0~beta5 to 2.4.0~rc1
Actions
Copy link
 #4

Updated by Jonathan CLARKE about 12 years ago

  • Priority changed from 2 to 4
Actions
Copy link
 #5

Updated by Jonathan CLARKE about 12 years ago

  • Target version changed from 2.4.0~rc1 to 2.4.0~rc2
Actions
Copy link
 #6

Updated by Jonathan CLARKE about 12 years ago

  • Priority changed from 4 to 3
Actions
Copy link
 #7

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:

Am I right ?

Actions
Copy link
 #8

Updated by Vincent MEMBRÉ about 12 years ago

You are almost right

Pending nodes can't access their directory, but the others can

It was only Beta3 when that bug appears

Actions
Copy link
 #9

Updated by Nicolas PERRON about 12 years ago

Ok, then should we consider this bug as rejected ? Jon ?

Actions
Copy link
 #10

Updated by Nicolas PERRON about 12 years ago

  • Target version changed from 2.4.0~rc2 to 2.4.0~rc1
Actions
Copy link
 #11

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.

Actions
Copy link
 #12

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
Copy link

Also available in: Atom PDF