Bug #3385
closedThe file /etc/services could not be updated
Added by Dennis Cabooter over 11 years ago. Updated over 11 years ago.
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.
Updated by Jonathan CLARKE over 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.
Updated by Dennis Cabooter over 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.
Updated by Jonathan CLARKE over 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.
Updated by Dennis Cabooter over 11 years ago
I will send the promise file tomorrow. Thanks for your update.
Updated by Dennis Cabooter over 11 years ago
- File checkGenericFileContent.cf added
Hereby the CFengine promise file as you requested.
Updated by Jonathan CLARKE over 11 years ago
- File deleted (
checkGenericFileContent.cf)
Updated by Jonathan CLARKE over 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?
Updated by Dennis Cabooter over 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
Updated by Dennis Cabooter over 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"; }
Updated by Matthieu CERDA over 11 years ago
- Status changed from New to 8
- Assignee set to Matthieu CERDA
- Priority changed from N/A to 1 (highest)
- % 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.
Updated by Matthieu CERDA over 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.
Updated by Matthieu CERDA over 11 years ago
Checked in all the PT/Techniques, there is no side effect when modifying max_file_size. Green light.
Updated by Matthieu CERDA over 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
Technical review to be done. => https://github.com/Normation/rudder-techniques/pull/69
Updated by Matthieu CERDA over 11 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset policy-templates:commit:36457b3582acec0ad5766513a484c2e60cae5de3.
Updated by Jonathan CLARKE over 11 years ago
Applied in changeset policy-templates:commit:72bd1a59bf8ba9f6cc2b81d0c978d51b023f1d58.
Updated by Jonathan CLARKE over 11 years ago
- Assignee changed from Jonathan CLARKE to Matthieu CERDA
- Priority changed from 1 (highest) 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).
Updated by Nicolas PERRON over 11 years ago
- Status changed from Pending release to Released