Please enter search query.
Search <book_title>...
Virtual Business Service-Availability User's Guide
Last Published:
2019-02-01
Product(s):
InfoScale & Storage Foundation (7.4.1)
Platform: AIX,Linux,Solaris,Windows
- Overview of Virtual Business Services
- Virtualization support in Virtual Business Services
- Supported operating systems for Virtual Business Services
- Installing and configuring Virtual Business Services
- Configuring a virtual business service
- Creating virtual business services
- Editing virtual business services
- Configuring dependencies for a virtual business service
- Managing Microsoft Failover Clustering from VBS
- Virtual Business Services operations
- Starting and stopping Virtual Business Services
- Tracking VBS operations
- Logs of a virtual business service
- Virtual Business Services security
- Fault management in Virtual Business Services
- Disaster recovery in Virtual Business Services
- Upgrading Virtual Business Services
- Appendix A. Command reference
- Appendix B. Troubleshooting and recovery
- Appendix C. Known issues and limitations
- Known issues and limitations
- Known issues and limitations
Security mechanism for cluster C2
When the VBS daemon on C2 is started, it reads the contents of the configuration file on the host to determine the clusters that are allowed to communicate with C2. As VBS B consists of C2 and C3, the VBS daemon determines that C3 can communicate with C2. However, C2 is part of both VBS A and VBS B. So, it can also communicate with C1, which is part of VBS A.
Hence, the VBS daemon adds the Cluster IDs of C1, C2, and C3 to the access control file, $VBS_HOME/web/admin/.xprtlaccess
.
# cat /opt/VRTSvbs/web/admin/.xprtlaccess
<ClusterId of C1>@vbs_domain@<Name of VOM CMS>.vx:user
<ClusterId of C2>@vbs_domain@<Name of VOM CMS>.vx:user
<ClusterId of C3>@vbs_domain@<Name of VOM CMS>.vx:user
No external hosts or clusters can pretend to be one of C1, C2, or C3 because they do not have the credential.