| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4202.1 | How to merge PATHWORKS trees | CPEEDY::VATNE | Peter Vatne, PATHWORKS for UNIX Server Engineering | Wed Mar 12 1997 11:58 | 34 |
| > I have a customer who has merged to clusters each containing 2 nodes
> each to make it a 4 node cluster. Before the merge each cluster had
> pathworks V5.0deco3 running on each cluster. So now there is 2
> pwrk$root's on the cluster. The customer is now having problems with
> pathworks hanging. I believe you should only have 1 pathworks root
> in a cluster.
You are correct in your belief.
> My question is, Can you simply run pwrk$config on 1 node and point
> it to the other nodes root and will the two roots merge or will
> one be overwritten(and if so which one). Or if not what is the
> best way of making 1 root from the 2 original roots.
If you run PWRK$CONFIG and point it to the other node's PWRK$ROOT, it
will warn you that a PATHWORKS tree already exists there, and will ask
you if you want to delete the old tree first. This will work, but it
was meant to handle the case of a previously interrupted tree move.
The first question is: are there any files in the PATHWORKS tree that
the customer wants to preserve? (Most of the time, the answer is no.)
The only time the answer would be yes is if the customer is using RIPL,
or the customer has stored user files under the USERS share, or the
customer has created their own shares somewhere under the PATHWORKS tree.
If there are files to preserve, the customer should use BACKUP to transfer
the files from one of the trees to the other. This is not easy. I
recommend you look at PWRK$COMMON_CONFIG.COM to see the commands I used.
If there are no files to preserve, just skip this step.
Finally, I would just delete by hand the tree that the customer doesn't
want, and then re-run PWRK$CONFIG on the two nodes that were using that
tree. The PWRK$CONFIG procedure should find the one remaining tree, and
begin to use that tree to store the server configuration information.
|
| 4202.2 | Merging Pwrk$root's | SIOG::S_DONNELLY | | Thu Mar 13 1997 11:50 | 10 |
|
Peter
Thanks for the response. Just one thing I am unclear about. Will
any shares that were set up with the root that is deleted have to
be reset up again when that node is added to the other root.
Thanks
Sean
|
| 4202.3 | Yes, I forgot about that | CPEEDY::VATNE | Peter Vatne, PATHWORKS for UNIX Server Engineering | Thu Mar 13 1997 20:24 | 9 |
| > Thanks for the response. Just one thing I am unclear about. Will
> any shares that were set up with the root that is deleted have to
> be reset up again when that node is added to the other root.
Yes, you will have to re-setup all the shares from the deleted root.
Actually, that brings up an interesting question: were the two
clusters part of the same domain? If not, you'll have to re-add
the users and groups from the deleted root as well.
|
| 4202.4 | It's not as simple as you might hope | VMSNET::P_NUNEZ | | Fri Mar 14 1997 09:14 | 37 |
|
>Actually, that brings up an interesting question: were the two clusters
>part of the same domain? If not, you'll have to re-add the users and
>groups from the deleted root as well.
Which means you'll have to re-do permissions. Actually you're
permissions are going to be an issue regardless as the internal UIDs on
one system (the one that will be using the other cluster's accounts
database) are no longer going to be valid. And since it's these
internal UIDs which are used in the ACLs which map LANMAN permissions,
you're invalidating security on any resource whose permissions were set
based on the accounts database which is going away. In fact, you could
be giving users that are already defined in the cluster accounts
database that will be used after the merge access to resources you
don't want them to have. An example, we're going to merge CLUSTER2
with CLUSTER1, using CLUSTER1's accounts database:
CLUSTER1 | CLUSTER2
-----------------------------------------------------------------------
USERNAME SMITH w/internal UID of 2 | USERNAME JONES w/internal UID 2
Jones has been granted RWCXDAP access to resource on
CLUSTER2/DISK$USER1:[JONES]
When you merge the accounts (no matter how you do so), user JONES is no
longer going to have in internal UID of 2 (you can't control what UID
is assigned to an account). But the ACL on jones' login directory -
DISK$USER1:[JONES] - is giving full access to the user whose internal
UID is 2 - SMITH now has full access to (at minimum) all the files in
Jones' root directory. Obviously, any other resource JONES had access
to on CLUSTER2, SMITH will now have that access (and JONES will have
none).
This also applies to shares on FAT volumes.
Paul
|
| 4202.5 | | CPEEDY::wells.lkg.dec.com::wells | Phil Wells | Fri Mar 14 1997 11:41 | 12 |
| > based on the accounts database which is going away. In fact, you could
> be giving users that are already defined in the cluster accounts
> database that will be used after the merge access to resources you
> don't want them to have. An example, we're going to merge CLUSTER2
This would be true if LMUID were simply a monotonically increasing value, but
we forsaw this problem and also include a VMS timestamp into the LMUID. I
think it's virtually impossible for two users to get mixed up in the way that
you describe.
The base point though is still valid - you will need to address permission to
files for the newly created users.
|