Project

General

Profile

Actions

Bug #3052

closed

Having an error with a Directive based on Download from a shared folder using Generic Variable Definition, will lead to all the Directives using Generic Variable to be in error

Added by Nicolas PERRON over 9 years ago. Updated over 9 years ago.

Status:
Released
Priority:
1
Category:
Web - Compliance & node report
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:

Description

If several Directives are used in a Rule and there are:
  • A Directive based on Download From A Shared Folder with a source using a Generic Variable
  • Another Directive based on Download From A Shared Folder with a source using a Generic Variable but with a typo like "$(generic_variable_definiton.myvar)"

The two of them will be in error and execution of agent on the client will be about connection failed.

Actions #1

Updated by François ARMAND over 9 years ago

  • Subject changed from Having an error with a Directive based on Download from a shared folder using Generic Variable Definition, will lead to all the Directives using Generic Variable to Having an error with a Directive based on Download from a shared folder using Generic Variable Definition, will lead to all the Directives using Generic Variable to be in error
Actions #2

Updated by François ARMAND over 9 years ago

  • Category set to Web - Compliance & node report
  • Status changed from New to 2
  • Assignee set to Nicolas CHARLES
  • Target version set to 2.4.0~rc2
Actions #3

Updated by Nicolas CHARLES over 9 years ago

  • Status changed from 2 to In progress
Actions #4

Updated by Nicolas CHARLES over 9 years ago

The problem is technique/cfengine related, not reporting :
I reproduced it on a test environement, what is happening is that the server is denying further connections as the one with $() within is invalid :

rudder> Allowing 192.168.110.21 to connect without (re)checking ID
rudder> Non-verified Host ID is 192.168.110.21 (Using skipverify)
rudder> Non-verified User ID seems to be root (Using skipverify)
rudder>  -> Public key identity of host "192.168.110.21" is "MD5=f0318b7cb678e7f03a586ca784110555" 
rudder>  -> Last saw -MD5=f0318b7cb678e7f03a586ca784110555 (alias 192.168.110.21) at Thu Nov 29 12:37:06 2012
rudder> A public key was already known from 192.168.110.21/192.168.110.21 - no trust required
rudder> Adding IP 192.168.110.21 to SkipVerify - no need to check this if we have a key
rudder> The public key identity was confirmed as root@192.168.110.21
rudder>  -> Strong authentication of client 192.168.110.21/192.168.110.21 achieved
rudder>  -> Receiving session key from client (size=256)...
rudder> Filename /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2) is resolved to /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2)
rudder> Couldn't stat filename /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2) requested by host 192.168.110.21
rudder>  !!! System error for lstat: "No such file or directory" 
rudder> Access control in sync
rudder> From (host=192.168.110.21,user=root,ip=192.168.110.21)
rudder> REFUSAL of request from connecting host: (SYNCH 1354189026 STAT /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2))
rudder>  -> Accepting a connection
rudder> Denying repeated connection from "192.168.110.21" 

On the client side :

rudder>     Comment:  Enforce content of /tmp/two based on the content on the Rudder server with mtime method
rudder>     .........................................................
rudder> 
rudder>  -> Copy file /tmp/two from /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2) check
rudder> No existing connection to 192.168.110.20 is established...
rudder> Set cfengine port number to 5309 = 5309
rudder> Set connection timeout to 10
rudder>  -> Connect to 192.168.110.20 = 192.168.110.20 on port 5309
rudder>  -> Matched IP 192.168.110.20 to key MD5=e82b35316903e3400a840a83fae1d295
rudder> .....................[.h.a.i.l.].................................
rudder> Strong authentication of server=192.168.110.20 connection confirmed
rudder>  -> Public key identity of host "192.168.110.20" is "MD5=e82b35316903e3400a840a83fae1d295" 
rudder>  -> Last saw +MD5=e82b35316903e3400a840a83fae1d295 (alias 192.168.110.20) at Thu Nov 29 12:37:06 2012
rudder> Server returned error:  Unspecified server refusal (see verbose server output)
rudder> Can't stat /var/rudder/configuration-repository/shared-files/$(generic_variable_definiton.def2) in files.copyfrom promise
rudder>  ?> defining promise result class copy_file_1_failed
(snip)
rudder>  -> Handling file existence constraints on /tmp/one
rudder>  -> File permissions on /tmp/one as promised
rudder>  ?> defining promise result class copy_file_2_kept
rudder>  -> Handling file existence constraints on /tmp/one
rudder>  -> File permissions on /tmp/one as promised
rudder>  ?> defining promise result class copy_file_2_kept
rudder>  -> Copy file /tmp/one from /var/rudder/configuration-repository/shared-files/def1 check
rudder> Existing connection to 192.168.110.20 seems to be active...
rudder> Set cfengine port number to 5309 = 5309
rudder> Set connection timeout to 10
rudder>  -> Connect to 192.168.110.20 = 192.168.110.20 on port 5309
rudder>  -> Matched IP 192.168.110.20 to key MD5=e82b35316903e3400a840a83fae1d295
rudder> Couldn't send
rudder>  !!! System error for send: "Broken pipe" 
rudder> Couldn't send
rudder>  !!! System error for send: "Broken pipe" 
rudder> Couldn't send
rudder>  !!! System error for send: "Broken pipe" 
rudder> Challenge response from server 192.168.110.20/192.168.110.20 was incorrect!
rudder> I: Report relates to a promise with handle "" 
rudder> I: Made in version 'not specified' of '/var/rudder/cfengine-community/inputs/copyGitFile/1.3/copyFileFromSharedFolder.cf' near line 90
rudder> I: Comment: Enforce content of file /tmp/one based on the content on the Rudder server with mtime method

rudder>  !! Authentication dialogue with 192.168.110.20 failed
rudder> Unable to establish connection with 192.168.110.20
rudder>  ?> defining promise result class copy_file_2_failed

Actions #5

Updated by Nicolas CHARLES over 9 years ago

  • Status changed from In progress to Discussion

Having only one connection available per node is clearly limiting for the download from a shared folder technique

Adding a "allallconnects" attribute in the server promises ( http://cfengine.com/manuals/cf3-Reference#allowallconnects-in-server ) solved the issue

It would allow each node to have several connection with the server. The obvious benefit is that if there is a long copy, other agent execution cannot connect to the server to fetch new promises. Apparently, if a copy fails, the connection is released late also

The risk is that if there are a lot of agent running on a specific node, they can hammer the policy server (but I'm not sure it woul really hammer, as they would still start every 5 minutes)

Should we implement this fix in 2.3 and/or 2.4 ??

Actions #6

Updated by Nicolas CHARLES over 9 years ago

  • Assignee changed from Nicolas CHARLES to Jonathan CLARKE

Jon, can we implement this change in 2.3 and 2.4 ? It's a one line modification in the PT/Technique DistributePolicy

Actions #7

Updated by Jonathan CLARKE over 9 years ago

  • Target version changed from 2.4.0~rc2 to 2.3.10

Yes, this seems like a good fix to me. I note that we have already set the max number of connections quite high, so this shouldn't be a problem (1000).

Of course, it must be fixed in 2.3 and 2.4, since this bug affects both versions.

Actions #8

Updated by Jonathan CLARKE over 9 years ago

  • Assignee changed from Jonathan CLARKE to Nicolas CHARLES
Actions #9

Updated by Nicolas CHARLES over 9 years ago

  • Status changed from Discussion to Pending technical review
Actions #10

Updated by Jonathan CLARKE over 9 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/6

Looks good to me, merged.

Actions #11

Updated by Jonathan CLARKE over 9 years ago

  • Status changed from Released to Pending release
Actions #12

Updated by Nicolas PERRON over 9 years ago

  • Status changed from Pending release to Released
Actions

Also available in: Atom PDF