[DRBD-user] bug with shared-secret value parsing ?

[Jérôme Augé]

Hi,

It seems there is a bug in the parsing of the value of the `shared-secret'
parameter : if the shared-secret starts with a numerical character, it will
make "drbdadm adjust" fail on any later adjustment with the error message :
"<shared_secret_value> it not a valid number".

I have an OpenFiler cluster running DRBD 8.0.2, and another cluster running
8.0.4.

I initially configured their shared-secret value with the output of
`/proc/sys/kernelk/random/uuid'. Now, whenever I do a "drbdadm adjust all"
it complains that my shared-secret value "is not a valid number" :

# drbdadm adjust all
35a8e289b8f02a315e1fa4827ec0e83f is not a valid number

Here is the corresponding net {} section :

net {
    cram-hmac-alg "sha1";
    shared-secret "35a8e289b8f02a315e1fa4827ec0e83f";
    after-sb-0pri disconnect;
    after-sb-1pri disconnect;
    after-sb-2pri disconnect;
    rr-conflict disconnect;
}

I changed the shared-secret to something shorter (e.g. "foo"), rebooted the
machine, and after trying longer strings without error, I finally reverted
to my original UUID strings but changed the first character from `3[...]' to
`a[...]' and now the drbdadm adjust does not complains that the value is not
a valid number.

So, it seems that if you set your shared-secret value with a string that
begins with a number, then any subsequent drbdadm adjust will fail, leaving
you with the only solution of rebooting the machine to take new parameters
(even a new shared-secret) into account.

Regards,
Jérôme Augé
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070821/b9c6fba1/attachment.htm>