Bug#424066: [Linux-HA] Re: Bug#424066: /etc/init.d/heartbeat stop causes duplicate takeover attempt on remaining node
On 2007-05-16T13:22:02, Simon Horman <[EMAIL PROTECTED]> wrote: Indeed, that's normal. v1 configurations will start the resources on take-over, and doesn't have enough memory to know it already has them. As "start" must succeed if already started, no harm should come from this for correct resource agents. NOTABUG. Sincerely, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418210: [Linux-ha-dev] Fwd: Bug#418210: heartbeat-2: /etc/ha.d/authkeys should not determine which nodes are in the cluster
On 2007-04-08T02:01:45, Simon Horman <[EMAIL PROTECTED]> wrote: > [ Reposting as I sent it to linux-ha-devel instead of > linux-ha-devel the first time around ] > > This seems to be a bit of an easy trap to fall into. > Are there any fixes floating around? I was thinking > that perhaps a cluster id of some sort would be a good > idea. But I'm not sure. It's only used as authorisation when "autojoin" is enabled. That is the whole point of the autojoin method. Users should not run distinct clusters on the same network media. (ie, the same subnets + port when using bcast, nor the same mcast address + port.) When autojoin is not enabled, this will cause a bunch of errors. If they have distinct shared secrets, they'll bail at the authentication step. If they have _both_ the same key _and_ the same media _plus_ autojoin enabled, they'll merge into one big cluster. Sincerely, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
On 2006-06-08T08:47:41, Alan Robertson <[EMAIL PROTECTED]> wrote: > >There may be files in there which aren't owned by our package though, or > >modified. > Huh? > > I just meant make individual symlinks for a individual binaries. NOT a > symlink for the entire directory. Ahhh. Ok. I thought you wanted to symlink the entire resource.d directory out of there ;-) Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
On 2006-06-08T07:15:01, Alan Robertson <[EMAIL PROTECTED]> wrote: > >>>Unfortunately heartbeat (for fairly broken reasons IMHO) really > >>>needs those files there. > >>Could we symlink 'em somewhere? > >Yes, I think that is a good solution (short of rearanging the > >resource paths completely). I can do this fairly easily in the Debian > >packaging and intend to do so shortly. Do you want me to shoe-horn this > >into the relevant Makefile.am, or just leave it as a Debian thing? > Please fix it everywhere, if you don't mind. > > Thanks Horms!! Of course, special attention needs to be paid to upgrading to (and possibly, back off from) a version with that change. Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
On 2006-06-08T08:21:38, Alan Robertson <[EMAIL PROTECTED]> wrote: > >>Please fix it everywhere, if you don't mind. > >> > >>Thanks Horms!! > >Of course, special attention needs to be paid to upgrading to (and > >possibly, back off from) a version with that change. > > I'm pretty sure that RPM handles that kind of thing correctly... There may be files in there which aren't owned by our package though, or modified. Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309906: [Linux-ha-dev] Re: Bug#309906: heartbeat: LVM resource script does not work with LVM2
On 2005-07-19T00:04:41, Horms <[EMAIL PROTECTED]> wrote: > For reference, here is a version of the patch that applies > (and hopefully works) with the CVS HEAD branch. Looks OK. Alan, could we get the code review process to be a at-least-two-pairs of eyes system? It's difficult to handle changes while you're traveling ;-) Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
