For additional information about Volumes, see the following subsections:
The commands listed in Volume Operations can be called to manipulate both NSS logical volumes and traditional NetWare volumes.
NSS logical volumes reside inside of NSS storage pools. Instead of being assigned to occupy an exact amount of physical space, they are assigned a maximum quota size. This size can be a specific amount, or it may be limited by the size of the available space in the NSS storage pool. An NSS logical volume can grow to be as big as its assigned quota, but it occupies only as much physical space in the NSS storage pool as is needed to store the current data that is owned by the volume.
NSS logical volumes can be in one of the following states:
deactive — Indicates that the volume is not currently activated or is not currently available for use.
active — Indicates that the volume is currently activated and is available for use by the File System Services (64-Bit).
mounted — Indicates that the volume is currently activated and is also mounted by the traditional NetWare file system. A volume in this state can be accessed by the traditional NetWare file system APIs and NCPs and the 64-Bit File System Services functions.
NOTE:The XML commands do not report a dismounted state. If an NSS logical volume is active but not currently mounted, it is in the "active" state.
Traditional NetWare volumes exist in, and are managed by, the traditional NetWare file system. Traditional volumes directly consume physical partitions or portions of physical partitions. These volumes can be in only a mounted or dismounted state and cannot be accessed using the 64-Bit File System Services functions. However, they can be accessed using the traditional file system APIs and NCPs (see the documentation for NetWare Core Protocols).
Encrypted Volume Support (EVS) is available in NetWare 6.5 SP2 and later.
EVS provides a mechanism to store user data in an encrypted form on NSS volumes while continuing to use most applications, NLMs, and backup utilities that currently work with NSS.
The basic feature set and internal operations of EVS is as follows:
Any NSS volume (with the exception of the sys volume) can be designated an encrypted volume at the time it is created. The encrypted volume attribute remains with the volume throughout its existence. A volume cannot be later converted to be an unencrypted volume once it is designated as encrypted. The encryption functionality must be designated at the time it is created.
Currently, only NSSMU version 3.20, build 940 or later can be used to encrypt a volume. At volume creation time, NSS prompts you to designate the volume as encrypted. If encryption is selected, NSS prompts you for a password and accepts the designation. Passwords can be any character string 16 characters or less in length.
When a password is detected, NSS consults with the NICI libraries to generate a 128-bit AES key that remains associated with the volume. The password is then used to wrap the key and other volume-specific cryptographic information into 128-byte packages that are persistently stored in two locations in NSS. The primary location is in the volume data block. The second location is in the volume locator beast. One the password is used to wrap the cryptographic data, the password is deleted from memory; and the volume is marked with the encrypted attribute (which is part of the volume-specific persistent data).
When a volume is activated, its persistent data is loaded from the volume data block. If the volume has the encrypted attributed, a memory list of volume names and keys is consulted to see if this volume has a known key. If the key is present, it's used. If the key is not present, the list of volumes and passwords is consulted. If a password is available, it is used to unwrap the key from the persistent data and the new key is added to the volume and key list.
Once the encrypted volume is activated, all encryption operations are transparent to file system applications that call file I/O functions. Data that is written to files is held in cache until the time that the data is normally written. At the time the data is physically written, the data is encrypted to a temporary write buffer, which is then delivered to the lower-level zlss function. After the data is written, the buffer is returned to an available list and the clear-text data remains in the cache. During reads, the cache is consulted to determine if a requested block is already in memory. If it is in memory, the clear-text data is transferred. If the requested block is not in cache, a physical read request is made, with the read being directed to a temporary buffer. After the read completion (but before control is returned to the calling function), the encrypted data in the temporary buffer is decrypted into a cache buffer, and the temporary buffer is assigned back to an available list. The read then proceeds as usual, and the clear-text data is made available to all future requestors.
To see new XML tags and volume attributes that were added to accommodate EVS, see
Because direct I/O to an encrypted volume bypasses the encryption engine and potentially allows a mix of encrypted and non-encrypted data on the same volume, you should avoid it.
Encrypted volumes increment the media major version number when a volume is created, so that encrypted volumes cannot be activated by releases prior to NetWare 6.5 SP2. The volume cannot be rolled back from SP2 to SP1. If you attempt such a rollback, the volume fails to activate and you won't be able to repair the pool. To effectively rollback an encrypted volume, the system administrator must move the user data off the encrypted volume. For example, by backing up a volume to volume copy.
If you archive files from an encrypted volume to a unencrypted volume, those files are stored in an non-encrypted state. If you want files to be archived in an encrypted state, the destination path for your archive manager must be on an encrypted volume.
When testing an encrypted volume, use all the tests available for testing any other volume. Encryption should be transparent above the physical read/write layer of zlss, so applications should run without any changes. All the rules of rights, trustees, ownership, sharing, visibility, locking, transactions, restrictions, etc., remain the same. The only noticeable difference between encrypted and non-encrypted volumes during run time is that encrypted volumes run slower.
You can manipulate EVS using nssmu.nlm and iManager. You can also use console command lines to display a volume's status and to activate or mount and deactivate or dismount encrypted volumes. Some example console command contexts follow:
MYSERVER:NSS /activate=MYVOLUME:volPasswordXYZZY MYSERVER:NSS /volumeActivate=MYVOLUME:volPasswordXYZZY MYSERVER:NSS /activate=MYVOLUME
The last console command is followed by a prompt to enter an encrypted volume password.
If an encrypted volume has been activated after the server is brought up, no further passwords are required.
Note that it is not permissible to activate encrypted volumes using ALL as the volume name.
The status of an encrypted volume can be displayed using the following console command:
NSS /volumes