Re: [webmin-devel] heartbeat authkeys

[paddy <pa...@pa...>]

On Thu, Feb 03, 2005 at 09:49:24AM +1100, Jamie Cameron wrote:
> 
> The current interface is supposed to handle that auth.cf format .. 

The problem I had is as follows:

I setup an authkeys file according to the heartbeat documentation
(GettingStarted.txt lines 350-390 in the version I have), thus:

  auth 1
  1 sha1 foo

When I went to edit_auth, it did not reflect the underlying configuration,
because it does not understand the format - It told me I was using crc.

To reiterate:

edit_auth reads "auth 1" as meaning "auth crc".  This works fine if you only use the 
numbers thus:

  1 crc
  2 sha1 pass
  3 md5 pass

But will break with other legal authkeys files.

> Basically, it will
> allow you to select one of the three modes, and comment out the ones that are not being
> used. Do you see any problem with this?

I don't pretend to see into the value of having multiple <index,cipher,pass> lines, as
I am not yet familiar with hearbeat, but the note in the sample authkeys file reads:

#       You normally only have one authentication method-id listed in this file
#
#       Put more than one to make a smooth transition when changing auth
#       methods and/or keys.

I also found this message:

  http://lists.community.tummy.com/pipermail/linux-ha-dev/1999-October/000219.html

which includes the following:

  The purpose of allowing several keys in the authkeys file is to make it possible
  to smoothly switch to a new key in a continuously running system.
  
  Assume you initially are authenticating on key 1:
  
  	You distribute out a new authkeys file to each machine which has key 1 and
  		a new key 2 both in it.  The auth statement at the top still says
  		auth 1. Go to next step when this one is done on all nodes.
  
  	You can now distribute a new authkeys file which has the same keys in it,
  		but says "auth 2" at the top.
  		Go to next step when this one is done on all nodes.
  
  	Distribute a new authkeys file which has only key 2 in it.
  		The first key is now repudiated, and is no longer valid.
  
  None of this disrupts the cluster at all.  Modify the authkeys file, and send
  heartbeat a SIGHUP.  New authkeys are in now in effect.
  
This makes sense to me, but a gui rendering of this mechanism could offer a
"change authkeys" that abstracts away the underlying mechanism. Perhaps Webmin
already does this bit, I didn't look yet. 

I imagine the diehard admin might still be able find uses for access to the 
undelying guts, but then the diehard admin knows where to find ed.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall