Re: [webmin-devel] heartbeat authkeys

Ah, I see what you mean now - ny code was assuming a certain ordering
for the options. The next release of Webmin will fix this ..

 - Jamie

paddy wrote ..
> 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
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> -
> Forwarded by the Webmin development list at [email protected]
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
-
Forwarded by the Webmin development list at [email protected]
To remove yourself from this list, go to
http://lists.sourceforge.net/lists/listinfo/webadmin-devel