I agree about avoiding the feature to sync config files. My typical recommendation is to use drbdlinks and put it on replicated or shared storage. In fact, I do that at home, and are doing it for a current customer.
By the way, Sean has recently revised drbdlinks to support the OCF API. (In fact, it supports all of the OCF, heartbeat-v1 and LSB APIs). http://www.tummy.com/Community/software/drbdlinks/ You can find his source control for it on github: https://github.com/linsomniac/drbdlinks Quoting Florian Haas <flor...@hastexo.com>: > On Tue, Dec 6, 2011 at 4:44 PM, Dejan Muhamedagic <de...@suse.de> wrote: >> Hi, >> >> On Tue, Dec 06, 2011 at 10:59:20AM -0400, Chris Bowlby wrote: >>> Hi Everyone, >>> >>> I would like to thank Florian, Andreas and Dejan for making >>> suggestions and pointing out some additional changed I should make. At >>> this point the following additional changes have been made: >>> >>> - A test case in the validation function for ocf_is_probe has been >>> reversed tp ! ocf_is_probe, and the "test"/"[ ]" wrappers removed to >>> ensure the validation is not occuring if the partition is not mounted or >>> under a probe. >>> - An extraneous return code has been removed from the "else" clause of >>> the probe test, to ensure the rest of the validation can finish. >>> - The call to the DHCPD daemon itself during the start phase has been >>> wrapped with the ocf_run helper function, to ensure that is somewhat >>> standardized. >>> >>> The first two changes corrected the "Failed Action... Not installed" >>> issue on the secondary node, as well as the fail-over itself. I've been >>> able to fail over to secondary and primary nodes multiple times and the >>> service follows the rest of the grouped services. >>> >>> There are a few things I'd like to add to the script, now that the main >>> issues/code changes have been addressed, and they are as follows: >>> >>> - Add a means of copying /etc/dhcpd.conf from node1 to node2...nodeX >>> from within the script. The logic behind this is as follows: >> >> I'd say that this is admin's responsibility. There are tools such >> as csync2 which can deal with that. Doing it from the RA is >> possible, but definitely very error prone and I'd be very >> reluctant to do that. Note that we have many RAs which keep >> additional configuration in a file and none if them tries to keep >> the copies of that configuration in sync itself. > > Seconded. Whatever configuration doesn't live _in_ the CIB proper, is > not Pacemaker's job to replicate. The admin gets to either sync files > manually across the nodes (csync2 greatly simplifies this; no need to > reinvent the wheel), or put the config files on storage that's > available to all cluster nodes. > > Cheers, > Florian > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
