User equivalence problem
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 4 of 4

Thread: User equivalence problem

  1. #1
    Join Date
    Dec 2001
    Posts
    337

    User equivalence problem

    Hi all,
    O/S: RHEL 4 64 bit
    db: 10.2.0.3 2 node RAC (64 bit) with ASM

    We have a working RAC solution however I cannot get Database control to work for it, after much investigation i found that user equiv is not set up correctly (i think) even though RAC is working. Below is a test:

    Code:
    On node2:
    
    [oracle@mgdb2 proc]$ ssh mgdb1 "date;hostname"
    Wed May 21 14:31:21 BST 2008
    mgdb1.mps
    [oracle@mgdb2 proc]$ ssh mgdb2 "date;hostname"
    oracle@mgdb2's password:
    
    On node 1:
    [oracle@mgdb1 ~]$ ssh mgdb2 "date;hostname"
    Wed May 21 14:35:36 BST 2008
    mgdb2.mps
    [oracle@mgdb1 ~]$ ssh mgdb1 "date;hostname"
    Wed May 21 14:35:40 BST 2008
    mgdb1.mps
    [oracle@mgdb1 ~]$
    Hence, as can be seen node 2 cannot authenticate itself (as its asking for the password). To further prove my point:

    Code:
    [oracle@mgdb2 proc]$ cluvfy comp nodecon -n all -verbose
    
    Verifying node connectivity
    
    WARNING:
    User equivalence is not set for nodes:
            mgdb2
    Verification will proceed with nodes:
            mgdb1
    
    Checking node connectivity...
    
    
    Interface information for node "mgdb1"
      Interface Name                  IP Address                      Subnet
      ------------------------------  ------------------------------  ----------------
      bond0                           xxx.xxx.xxx.xxx                    xxx.xxx.xxx.xxx
      bond0                           xxx.xxx.xxx.xxx                    xxx.xxx.xxx.xxx
      bond1                           xxx.xxx.xxx.xxx                    xxx.xxx.xxx.xxx
    
    
    Check: Node connectivity of subnet "xxx.xxx.xxx.xxx"
      Source                          Destination                     Connected?
      ------------------------------  ------------------------------  --------------
      mgdb1:bond0                     mgdb1:bond0                     yes
    Result: Node connectivity check passed for subnet "xxx.xxx.xxx.xxx" with node(s) mgdb
    
    Check: Node connectivity of subnet "xxx.xxx.xxx.xxx"
    Result: Node connectivity check passed for subnet "xxx.xxx.xxx.xxx" with node(s) mgd
    
    Suitable interfaces for the private interconnect on subnet "xxx.xxx.xxx.xxx":
    mgdb1 bond0:xxx.xxx.xxx.xxxbond0:xxx.xxx.xxx.xxx
    
    Suitable interfaces for the private interconnect on subnet "xxx.xxx.xxx.xxx":
    mgdb1 bond1:xxx.xxx.xxx.xxx
    ERROR:
    Could not find a suitable set of interfaces for VIPs.
    
    Result: Node connectivity check failed.
    
    
    Verification of node connectivity was unsuccessful on all the nodes.

    On thing i must mention here is that the application only uses node 2. When firing up Dbconsole I can see 'no targets found' hence we can set nothing useful. Does the above mean we have to re-config ssh? or is there any other suitable method? I would also like to mention user/group names are the same on both nodes.

    Thanks in advance,
    Chucks

  2. #2
    Join Date
    Jul 2002
    Location
    Lake Worth, FL
    Posts
    1,458

    Talking

    You do need to re-config SSH and make sure ALL file system directories are the same and have same permissions on all nodes.
    "The person who says it cannot be done should not interrupt the person doing it." --Chinese Proverb

  3. #3
    Join Date
    Dec 2001
    Posts
    337
    Hi,

    As this is a live production db we will have to oraganise downtime to do this. Is this a big job and is there a chance the db wont come back up?

    I have also noticed authorized_keys on node 1 file size is double that of the one on node 2. Would i be able to copy this (seeing that connections work from node1) onto node2 (replacing the one on node 2) and make it work that way?

  4. #4
    Join Date
    Jul 2002
    Location
    Lake Worth, FL
    Posts
    1,458

    Cool

    No need for down time, the problem may be only the authorized-keys/known-hosts files.

    Yes, you may copy the working authorized-keys over, just make sure node 1 key is included in the file.

    PS: Also make sure the permissions for that file are: -rw-------
    "The person who says it cannot be done should not interrupt the person doing it." --Chinese Proverb

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width