Project

General

Profile

Actions

Bug #3385

closed

The file /etc/services could not be updated

Added by Dennis Cabooter about 11 years ago. Updated almost 11 years ago.

Status:
Released
Priority:
N/A
Assignee:
Matthieu CERDA
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

The file /etc/services could not be updated. Setting permissions on /etc/services is no problem. The file has the correct permissions and the immuteable bit is not set. On the CLI it's no problem to echo a string into /etc/services.

Actions #1

Updated by Jonathan CLARKE about 11 years ago

Dennis, I'm not sure I really understand what's going on here. How did you attempt to modify this file? Which Technique (and version) did you use, was it a file copy, or a file edit? And what errors did you encounter? Some logs would be useful, also.

Actions #2

Updated by Dennis Cabooter about 11 years ago

It's a file edit. In the same way I edited other files within the same directive. There are no useful errors, only "The file /etc/services could not be updated". Also in syslog on the rudder-client this is the only message that appears. "Force file contents" box is not ticked, because I just need to append some services.

Actions #3

Updated by Jonathan CLARKE about 11 years ago

  • Category set to Techniques
  • Target version set to 2.3.12

Huh, that is indeed very weird. Any chance you could send us the generated CFEngine promise file, so we can try and reproduce this here?

You should be able to find it on the node (rudder-client) where it fails, under /var/rudder/cfengine-community/inputs/checkGenericFileContent/*/*.cf.

Actions #4

Updated by Dennis Cabooter about 11 years ago

I will send the promise file tomorrow. Thanks for your update.

Actions #5

Updated by Dennis Cabooter about 11 years ago

  • File checkGenericFileContent.cf added

Hereby the CFengine promise file as you requested.

Actions #6

Updated by Jonathan CLARKE about 11 years ago

  • File deleted (checkGenericFileContent.cf)
Actions #7

Updated by Jonathan CLARKE about 11 years ago

Thanks for this Dennis. I just checked your file and it seemed to contain some sensitive data internal to your organization. As a precautionary measure, I have removed it from the bugtracker.

Could you check, and confirm that this info is public, or obfuscate it in the file, and resend?

Actions #8

Updated by Dennis Cabooter about 11 years ago

Finally I found the problem in the CFengine logs:

!! File /etc/services is bigger than the limit edit.max_file_size = 362031 > 0 bytes
File /etc/services was marked for editing but could not be opened
Actions #9

Updated by Dennis Cabooter about 11 years ago

And here is the fix:

--- /var/rudder/share/ce7836bf-d512-4282-9240-26ffec2c5b49/rules/cfengine-community/common/1.0/rudder_lib.cf.orig    2013-04-09 17:01:55.336441268 +0200
+++ /var/rudder/share/ce7836bf-d512-4282-9240-26ffec2c5b49/rules/cfengine-community/common/1.0/rudder_lib.cf    2013-04-09 17:08:37.307669649 +0200
@@ -139,14 +139,14 @@
 {
 empty_file_before_editing => "false";
 edit_backup => "timestamp";  # we want to keep a track of everything
-max_file_size => "300000";
+max_file_size => "1024000";
 }

 body edit_defaults empty_backup
 {
 empty_file_before_editing => "true";
 edit_backup => "timestamp";
-max_file_size => "300000";
+max_file_size => "1024000";
 }

@@ -337,7 +337,7 @@
 body edit_defaults rudder_empty_select(select)
 {
 empty_file_before_editing => "$(select)";
-max_file_size => "300000";
+max_file_size => "1024000";
 edit_backup => "timestamp";
 }

Actions #10

Updated by Matthieu CERDA about 11 years ago

  • Status changed from New to 8
  • Assignee set to Matthieu CERDA
  • Priority changed from N/A to 1
  • % Done changed from 0 to 20

Hello Dennis.

I agree with the fix, but may I suggest that you use the "Download from a shared folder" technique instead for big files ?

Indeed, the /etc/services file is quite big and for every file you edit on the same machine using the "Enforce a file content", you append the whole file content on a single CFEngine promise file, which can, in case of lots of big files, reach de limits of CFEngines tolerances.

Thanks for the patch anyway, it is much welcome. I'm opening a pull request with it.

Actions #11

Updated by Matthieu CERDA about 11 years ago

Oops, sorry I misunderstood what you are trying to do.

Well, OK this is a totally valid fix then, disregard what I said in #10.

Actions #12

Updated by Matthieu CERDA about 11 years ago

Checked in all the PT/Techniques, there is no side effect when modifying max_file_size. Green light.

Actions #13

Updated by Matthieu CERDA about 11 years ago

  • Status changed from 8 to Pending technical review
  • Assignee changed from Matthieu CERDA to Jonathan CLARKE
  • % Done changed from 20 to 100
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/69
Actions #14

Updated by Matthieu CERDA about 11 years ago

  • Status changed from Pending technical review to Pending release

Applied in changeset policy-templates:commit:36457b3582acec0ad5766513a484c2e60cae5de3.

Actions #15

Updated by Jonathan CLARKE about 11 years ago

Applied in changeset policy-templates:commit:72bd1a59bf8ba9f6cc2b81d0c978d51b023f1d58.

Actions #16

Updated by Jonathan CLARKE about 11 years ago

  • Assignee changed from Jonathan CLARKE to Matthieu CERDA
  • Priority changed from 1 to N/A
  • % Done changed from 100 to 0

Looks good to me, merged into 2.3.

Matthieu, can you do the merges into 2.4/2.5/2.6, because I think they will not be automatic (or at least not sufficient in automatic mode).

Actions #17

Updated by Nicolas PERRON almost 11 years ago

  • Status changed from Pending release to Released
Actions

Also available in: Atom PDF