User story #2213
closedPT distributePolicy: LDAP password synchronization
Added by Matthieu CERDA almost 13 years ago. Updated over 9 years ago.
Description
PT distributePolicy: LDAP password synchronization
Updated by Matthieu CERDA almost 13 years ago
- Status changed from In progress to Pending technical review
- % Done changed from 0 to 100
Applied in changeset commit:dfbc43eb61e2af8cb9a1d7d99e9119a7510436cc.
Updated by Jonathan CLARKE almost 13 years ago
- Status changed from Pending technical review to 2
- % Done changed from 100 to 90
- Your use of result classes (from classes if_else and kept_if_else) is dangerous. Classes defined this way are global, but your bundle is re used, so several executions will cause interference! You should parameter the class names with something like canonify process name.
- 644 id not a secure permission for files containing passwords. Please use 600 or 640 instead.
Updated by Matthieu CERDA almost 13 years ago
- Status changed from 2 to Discussion
Well, I do not see where an interference might be possible, I am only injecting the same variables the restart bundle uses with another parameter forcing the restart, could you please describe a complete use case ?
About the permissions, I totally agree but I copied the permissions that are already in place afterthe installation. I am afraid to break Rudder with access denied/permissions errors with Apache, slapd ...
Updated by Jonathan CLARKE almost 13 years ago
Matthieu CERDA wrote:
Well, I do not see where an interference might be possible, I am only injecting the same variables the restart bundle uses with another parameter forcing the restart, could you please describe a complete use case ?
Sure. This is not related to variables, but to classes. In each CFEngine run, you call the generic_process_check_process bundle 4 times (once for slapd, once for jetty, etc). Each time, the bundle checks a process, and may try and restart it. It then sets one of the classes process_restart_ok or process_restart_error, which is then used for reporting in that same bundle. Classes defined as the result of a promise, like these ones (from a classes body), are global.
This means that the first time you call the bundle, for slapd, if there is an error restarting the process, the class "process_restart_error" will be defined, and reporting will say "result_error...etc...The slapd process couldn't be restarted". However, when the bundle is next called, for jetty, this class will still be defined, causing the reporting to say "result_error...etc...The jetty process couldn't be restarted", even if the jetty process is fine and other reports for it are printed. And so on...
About the permissions, I totally agree but I copied the permissions that are already in place afterthe installation. I am afraid to break Rudder with access denied/permissions errors with Apache, slapd ...
I understand. But if this is the case, it should be considered a bug! Now is the time to find out, while 2.4 is still in alpha stage. Please test with 600.
Updated by Matthieu CERDA almost 13 years ago
About the permissions, please see #2211, I proposed a solution.
About the restart classes, I'm OK with that. I will address this as soon as a compromise is found about file permissions.
Updated by Matthieu CERDA almost 13 years ago
- Status changed from Discussion to Pending technical review
- % Done changed from 90 to 100
Applied in changeset commit:a9715466d26a03faadd9f93eebbe214d6b2286a8.
Updated by Jonathan CLARKE almost 13 years ago
- Status changed from Pending technical review to 10
This looks great.
Updated by Jonathan CLARKE almost 13 years ago
- Status changed from 10 to Released
Updated by Benoît PECCATTE over 9 years ago
- Project changed from 24 to Rudder
- Category changed from Policy Templates to Techniques