verification of cluster password

[Peter Zeiszler]

Hi,

I have a cluster that was built about 5 years ago. I want to add another node into the cluster but do not remember the cluster password. I have an idea of what it is but would like to verify the password prior to me adding the node. Getting a cluster reboot of the current cluster would be a stretch until the christmas downtime window (assuming I get one this year) which would be about 1.5 months past the date the new member should be added.

Is there any tool that is around to verify the cluster password?

[Steven Schweda]

> Is there any tool [...]

I know of none.

The usual method is to steal a copy of
SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT
from a cluster member, and copy it to the new
node. It works, and it's normally pretty
easy to do

[Hoff]

It'd likely be feasible to find a password sequence that hashes into the same current value given how fast that processing is these days (and if you're really interested), though copying CLUSTER_AUTHORIZE around is way easier.

There's a write-up (including the cluster password) for adding or removing nodes from a cluster here:

http://64.223.189.234/node/169

[John Gillings]

Peter,

Copying the cluster authorize data base is simple and reliable.

That said, for the future, I recommend using some kind of simple method to generate the cluster password from the cluster name, or the foundation node name.

Realistically, the cluster password is no longer necessary for security. Long gone are the days when a hostile OpenVMS node on the same LAN might be a security threat by joining the cluster.

Maybe it's not a good idea to advertise the mechanism explicitly, but having it derivable and documented somewhere would avoid the issue you're facing here. For example, I think I used to use the SCSSYSTEMID of the foundation node as the cluster number, and some combination of he node name and ID for the password.

[Wim Van den Wyngaert]

I have no cluster to test this but based upon cluster_config.com I see that the pwd is set by
$ sysman
set env/clu
con set clu /group=xx/password=yy

Doing this requires a cluster reboot afterwards but then you know the password.

Wim

[Robert Gezelter]

Peter,

I concur with Steve, Hoff, and John: Copy the cluster authorization file from the running system ([Smile] after first checking SYS$SYSROOT to confirm the correct disk and root).

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Peter,
let me add another voice to the choir:
copying SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT is simple and reliable.
Note, that if you have a common system disk, it IS there already, so you have no need to do even that.

hth

Poost.

Have one on me.

jpe

[Wim Van den Wyngaert]

"Long gone are the days when a hostile OpenVMS node on the same LAN might be a security threat by joining the cluster."

Wouldn't count on that. Someone once did a setup with a default password over here and he hung the production cluster because the node was of the same group number as an existing cluster. I was in holiday at the time and have no details of it (was 2002).

Any PC hooked up the network could be running a alpha emulator. So, I would make sure the password is not too simple, and include the group number in it as a protection.

fwiw

Wim

[Martin Vorlaender]

>>>
"Long gone are the days when a hostile OpenVMS node on the same LAN might be a security threat by joining the cluster."

Wouldn't count on that. Someone once did a setup with a default password over here and he hung the production cluster because the node was of the same group number as an existing cluster.
<<<

I wouldn't count on that either. At a customer's site, a production system halted because some node tried to join the LAVC cluster with the wrong password. The cluster generated a message in the system error log every two seconds - until the system disk had 0 blocks free.

cu,
Martin

[Peter Zeiszler]

In this config it would be a new node joining an existing cluster and would be sharing the system disk. So I couldn't just do the copy.

I think I remember what the password was set to. There are a few possibilities, depending on which "standard" I used. :D

Unfortunately I can't find my original documents with the password. I can find my original console outputs as I created the cluster (but of course, the password isn't listed).

Guess I try to schedule a cluster reboot to reset the password or just guess and try to make the node join the cluster and if it can't get the reset/reboot scheduled.

[Steven Schweda]

> [...] and would be sharing the system disk.
> So I couldn't just do the copy.

Why not? Wouldn't that make it easier?

[Peter Zeiszler]

It would be adding a new sysroot to the current system disk. Think it requires the cluster group and cluster password for that operation.

[Hoff]

>>> In this config it would be a new node joining an existing cluster and would be sharing the system disk. So I couldn't just do the copy.

You need do nothing here to change or reset the password. Add the root, and off you go. If you're offered a way to change it, bypass or ignore it.

Worst case, snapshot CLUSTER_AUTHORIZE around the process, then replace it after any changes are made when adding the node and before the new node boots.

[Jan van den Ende · Accepted solution]

Peter,

if you are sharing the ssytem disk, you are all set to go!

This is one problem that is not a problem at all :-)

Remember, to ADD a node, you start executing Cluster_config --- from a running cluster node---. So the cluster-autotize is just available.
Just add the node, no fuzz about cluster password, and "Thunderbirds are GO"


Proost.

Have one on me.

jpe

[Peter Zeiszler]

Well I will know once they give me a green light to merge the node to cluster. Waiting on the project approval and then I have to get network involved, disks setup to migrate, etc. Unfortunately the paperwork approvals could take me right up to the date of when they wanted it done.

Either way - I will try to update to let everyone know if I had to put in or not. Lets hope for not needed.

Btw - I was familiar with the copy around of the cluster_authorization.dat file. Did that on other clusters where they wanted seperate system disks to be able to play with patch levels.

[Robert Gezelter]

Peter,

If you are sharing the system disk, you can do the creation of the [SYSnnnn] directory tree manually. I have done it that way many times.

-Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Peter,

I can confirm, that if you add another node to a shared system disk with LAN being used as cluster interconnect, that CLUSTER_CONFIG will NOT ask for the cluster group number and password (just checked a session logfile of a previous installation).

Volker.

[Jan van den Ende]

Peter,

I can confirm Bob Gezelter (as always, pretty hard to trap him on mistakes :-) ).
Adding an extra root by hand really IS pretty simple (provided you intend to build a pretty much homogeneous cluster), and after doing it a few times, may even be quicker than CLUSTER_CONFIG. However, CLUSTER_CONFIG _IS_ the safer option!
It _IS_ quite easy to miss one or two SYS$SPECIFIC essentials.

hth

Proost.

Have one on me.

jpe

[Peter Zeiszler]

I used to create the sysroot manually at an old job. Can't find my notes on it. Had to be careful because we also use Multinet and had to create those links. Was at that job we found the cluster limit was set at 96 (and a work around beyond that but DEC wouldn't support it).