Please enter search query.
Search <book_title>...
Virtual Business Services - Availability User's Guide
Last Published:
2024-12-04
Product(s):
InfoScale & Storage Foundation (8.0.2)
Platform: Windows,Solaris,Linux,AIX
- Overview of Virtual Business Services
- VMware virtualization support prerequisites for Veritas InfoScale Operations Manager 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 VIOM CMS>.vx:user
<ClusterId of C2>@vbs_domain@<Name of VIOM CMS>.vx:user
<ClusterId of C3>@vbs_domain@<Name of VIOM 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.