9.2 Data Access Requirements for a DST Shadow Volume Pair

All user and administration access to data is intended to be through the merged view of DST shadow volume pair. Users should never have direct access to the secondary volume. Consider the guidelines in this section when planning how to provide access to the merged view of data in the DST shadow volume.

9.2.1 Administrator Access

Administrators should manage files, directories, and authorization via the merged view of the DST shadow volume pair. Ensure that you use tools that support the merged view, such as the NCP client and tools described in Section 6.0, Management Tools for DST.

File system access rights are based on the Novell Trustee Model just as they are for a single NSS volume. You must connect to the share on the primary volume by using the Novell Client or similar NCP client tools, and then set permissions while working in the merged view of the data. The permissions for data on both locations are saved on the primary volume. Dynamic Storage Technology uses those permissions to control access to data stored on the secondary volume. The XML file that contains trustees and trustee rights settings is copied to the secondary volume.

All users (except the root user) of the DST volume pair must have User objects defined in eDirectory. NSS volumes by design are not visible to any locally defined user except the root user when accessing files natively from the server. The root user of the server is the only local user who has direct access to the Linux file structure view of the two volumes.

Some management tasks are performed as the root user; they require direct access to the secondary volume:

9.2.2 User Access and Authorization

All user file access to data on the DST volume pair is done via the merged view. Users connect to a share on the primary volume to see the merged view. Users should not be allowed to connect directly to the primary volume or secondary volume.

File system access rights are based on the Novell Trustee Model just as they are for a single NSS volume. Trustees and trustee rights are set from the merged view of the DST shadow volume pair. DST enforces those settings whether the file resides on the primary volume or secondary volume.

All users (except the root user) of the DST volume pair must have User objects defined in eDirectory. For information about configuring eDirectory users, see the NetIQ eDirectory 8.8 SP8 Administration Guide.

9.2.3 File Access Protocols

A merged user view of the file system is available for both NCP and CIFS users. The CIFS access can be set up by using Novell CIFS or using Novell Samba, but OES does not support using both of these CIFS user access solutions on the same server. In this guide, Novell Samba access is referred to as SMB/CIFS. NCP Server is required to be installed and running even if all users access data via Novell CIFS or Novell Samba.

This section describes the requirements and guidelines for file access protocols:

Performance for File Access Protocols

Using DST affects the file access performance, depending on the file access protocol being used, as shown in Table 9-1.

Table 9-1 Performance for File Access Protocols Used with DST Volumes

User Access

Aggregate Performance

Novell Client users

Performance is reduced by less than 10%.

Novell CIFS users

Performance is reduced by about 25%.

SMB/CIFS users (requires Novell Samba, FUSE, ShadowFS, and Linux-enabling of users with Linux User Management)

Performance is reduced by up to 48%.

Cross-Protocol File Locking

When users access the files via multiple protocols, you should enable the NCP Server Cross-Protocol File Locks option to protect against data corruption. For information, see Configuring Cross-Protocol File Locks for NCP Server in the OES 11 SP3: NCP Server for Linux Administration Guide.

NCP

The DST Shadow Volumes engine supports file access for NCP users. Users access data via an NCP share on the primary storage location, by using the Novell Client or other NCP clients. For information about configuring NCP Server for the OES 11 SP3 server, see the OES 11 SP3: NCP Server for Linux Administration Guide.

Novell Client: See the following resources for the latest release of the Novell Client, which provides NCP access for users on Linux and Windows clients:

Only NCP client versions that are configured to receive broadcast messages are eligible to receive the duplicate file conflict messages. For information, see Section 7.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts.

NetStorage: NetStorage for Linux has limited use for accessing files on shadow volumes. NetStorage presents a merged view of the data, and the user can see, read, and write files. However, certain management functions (such as getting file properties, setting trustees, and salvaging files) work only if the files are on the primary volume. The user will find that the commands work for some files but not others because they are not aware of where the file is physically stored. For information about using NetStorage, see OES 11 SP3: NetStorage Administration Guide for Linux.

Novell CIFS

Novell CIFS supports using NSS volumes in a DST shadow volume configuration. It supports the following DST features:

  • Merged View: Novell CIFS works with NCP Server to provide a merged view of the two NSS volumes. CIFS users can access data on both volumes via a Novell CIFS share on the primary NSS volume.

  • Duplicate Files: CIFS can handle duplicate files, but it does not support the broadcast message notification via NCP. It shows the instance of the file on the primary volume to users. The administrator or user can rename the file so that the secondary instance of the file is again visible. The user can then determine which instance to delete.

    If the global policy is set to hide duplicate files, CIFS moves the files on the secondary volume to the /._DUPLICATE_FILES folder where the administrator can access them for recovery, if necessary.

  • Global DST Policies: When users access or modify files, CIFS honors the global DST policies for moving files from the secondary volume to the primary volume.

Setting up Novell CIFS for use with a DST shadow volume is similar to setting up CIFS for an NSS volume. You create the CIFS share on the primary volume, but not on the secondary volume. Enable the cross-protocol file locking parameter for NCP Server on the DST server.

Novell CIFS features should work as expected, including cross-protocol file locking. The key difference is that users access the merged view of data in both volumes via the CIFS share on the primary NSS volume. The users do not know that the data is stored on two different volumes.

For information, see the following:

Consider the following requirements when configuring Novell CIFS for use with DST volumes:

  • Novell CIFS supports only NSS volumes on Linux. Thus, Novell CIFS can be used only with DST volumes built on NSS volumes.

  • CIFS users access a merged view of the DST shadow volume by using a Novell CIFS share on the primary volume. Create a CIFS share on the Primary volume only; delete the share on the secondary (or do not give users rights to access the secondary share).

  • Novell CIFS users don't see broadcast messages if the Broadcast Messages for Duplicate Files Conflicts feature is enabled for Duplicate Files errors. This DST option works only for Novell Client users as described in Section 7.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts. If you have only Novell CIFS users and no NCP users, you might as well disable the broadcasting option.

  • If you use Novell CIFS with a DST volume in a cluster, you need to add the Novell CIFS lines in the load/unload scripts for the DST cluster resource. The differences are described in Section 15.0, Configuring DST Shadow Volume Pairs with Novell Cluster Services.

  • You cannot configure Novell CIFS and the SMB/CIFS setup on the same server. This limitation is derived from the requirement that Novell Samba and Novell CIFS cannot be installed on the same server, and is unrelated to DST.

Novell Samba with ShadowFS and FUSE

Novell Samba is supported for providing SMB/CIFS user access to shadow volumes. This Samba version is the standard Linux Samba that has been integrated with eDirectory. For information, see the OES 11 SP3: Novell Samba Administration Guide.

In order for SMB/CIFS users to see a merged view of the shadow volume, you must also set up ShadowFS (Shadow File System) and FUSE (File System in Userspace). See Section 13.0, Using ShadowFS to Provide a Merged View for Novell Samba Users for installation and configuration requirements.

SMB/CIFS users must be Linux-enabled users of the OES 11 SP3 server. The Linux Samba service must also be LUM enabled. For information, see the OES 11 SP3: Novell Linux User Management Administration Guide.

Enable the cross-protocol file locking parameter for NCP Server. For information, see Configuring Cross-Protocol File Locks for NCP Server in the OES 11 SP3: NCP Server for Linux Administration Guide.

Novell AFP (Not Supported)

Novell AFP (Apple Filing Protocol) does not support DST shadow volumes. AFP users are able to see only the data that is on the primary volume. Do not create AFP shares on the primary or secondary volumes that are used in a DST shadow volume.

Other Linux Protocols (Supported and Not Supported)

Supported Linux file access protocols include SSH and Novell FTP (Pure-FTPd). You must use ShadowFS and FUSE on the system to provide a merged view for SSH and FTP users. In addition, the eDirectory users and the native Linux service must be enabled with Linux User Management (LUM). ShadowFS must be running in order for the users to access the data.

IMPORTANT:This configuration works best when you use only NCP for normal user access, or if you must allow CIFS access, you use Novell Samba instead of Novell CIFS.

User access to shadow volumes via all other native Linux protocols (such as HTTP, NFS, and others) is not supported.

9.2.4 ShadowFS and FUSE

The Shadow File System (ShadowFS) works with FUSE (File System in Userspace) to provide a merged view of the shadow volume tree for eDirectory users of native Linux file access protocols, including Novell Samba (SMB/CIFS) and supported Linux file access protocols, such as SSH and Novell FTP (Pure-FTPd). ShadowFS requires that eDirectory users and the native Linux service be enabled with Linux User Management (LUM). ShadowFS must be running in order for the SMB/CIFS users to access the data.

When ShadowFS is running, it automatically creates a shadow file system directory for each of the shadow volumes, not just the ones where you plan to allow SMB/CIFS access. SMB/CIFS users see only those volumes where they have file system trustee rights.

ShadowFS requires FUSE (File System in Userspace) to be installed and running. For information, see Section 13.0, Using ShadowFS to Provide a Merged View for Novell Samba Users.