Novell Storage Services

Novell Storage Services (NSS) is a powerful storage and filesystem that provides an efficient way to use all the space on your storage devices. NSS cannot be used for the OES Linux root filesystem, which contains the SLES operating system files, but it can be used for any other storage space you would like to allocate.

NSS is now one of many different filesystems offered on Linux platforms. Although every filesystem's primary goal is to provide access to disk storage, each filesystem has its own particular features. NSS is no different and offers a wide range of features not available with any other filesystem.

Some of the main features of NSS are complete integration with eDirectory, extended Access Control Lists (ACLs), rights inheritance and filtering, support for multiple name spaces, and much, much more. Many of those capabilities are only possible through an NSS feature known as a backlink.

With NSS, each file or directory is backlinked to the parent directory. This means that not only does the parent know what objects are beneath it, but the child also knows what parent directories are above it. This feature is unique to NSS and offers several powerful capabilities. One benefit of this is visible when browsing directories with varying permissions. In non-NSS filesystems, all directories are visible even if you do not have permission to enter the directory. With NSS, backlinks are used to ensure directory visibility is confined to just the directories you have access to.

Another benefit is seen when assigning permissions. To provide access to a file several levels deep in a directory tree, NSS only requires that rights be assigned at that specific file or location. There is no need to traverse the tree, either manually or automatically, and assign rights. Through backlinks, NSS automatically determines the visibility of parent directories and ensures that users are able to traverse to the location where rights have been assigned.

NSS also offers many additional capabilities over traditional Linux filesystems. This does not mean that NSS is always the best choice, but understanding the capabilities of NSS should help you to make the right filesystem choice for whatever filesystem needs you may have. NSS is particularly useful in conjunction with other OES components, such as Novell Clustering Services (NCS) and the Novell Client. NSS is a powerful addition to your OES Linux infrastructure, and an important component to understand.

The first concept with which you should become familiar in the NSS filesystem is the volume. An NSS volume is the highest level in the filesystem hierarchy, and is the structure within which directories and files are maintained. From a Linux perspective, a volume is just another term for a filesystem or formatted partition.

NOTE

OES Linux has support for both NSS and NCP volumes. All OES Linux servers (with eDirectory) will have at least one NCP volume, known as SYS. This is actually the /usr/novell/sys directory, which is served to NCP-based clients as a volume. This directory contains files used in conjunction with NCP access to the server. More information regarding NCP volumes is available later in this chapter.

OES Linux does not automatically create any NSS volumes. These volumes can be created as needed using iManager or the command-line utility nssmu.

The volume is the last link in the NSS chain. Figure 11.1 gives a high-level view of the NSS architecture.

• NSS partitions A partition is a logical organization of space on a hard disk, and represents the lowest level of organization for disk storage. Partitions prepare space on storage devices to be used in an organized and structured way by defining the ways in which the filesystem will interact with the storage devices.

• NSS storage pools NSS storage pools are created in partitioned space. A storage pool is a specified amount of space you obtain from all your storage devices. Within the storage pool, you will create the NSS volumes you need on the server. Only one storage pool can exist on a partition, but you can create an unlimited number of NSS volumes in each storage pool, thereby removing partition constraints on the number of volumes that can be created.

• NSS volumes The volumes you create from NSS storage pools are called logical volumes. As shown in Figure 11.1, they are logical volumes because the space used to create a given volume can come from a variety of storage devices. It is not contiguous space. A logical volume can be set to a specific size, or allowed to grow dynamically according to the amount of physical space assigned to the pool. This lets you add and store any size or any number of files you need without having to create other partitions. You can add any number of volumes to a storage pool as long as you have available physical space in the pool.

Figure 11.1. A high-level view of the NSS architecture.

Beyond these three NSS building blocks, you should be aware of several concepts related to the configuration and management of NSS volumes:

• NSS management You will use iManager for configuring and managing your NSS environment. It gives you the ability to control and change your server's storage characteristics from any place with an Internet connection. In addition to iManager, there are terminal-based management tools, such as nssmu, as well. These utilities must be used from terminals on the OES machine.

• Overbook your storage pool Individual logical volumes cannot exceed the size of a storage pool. However, because you can create multiple logical volumes in a single storage pool, OES Linux permits the total space allocated to logical volumes to exceed the actual pool size. This feature, called overbooking, can be an efficient way to manage your filesystem because it lets your volumes grow organically over time instead of being locked into a rigid structure that can leave space unused.

• Deactivate/activate logical volumes and storage pools You might need to temporarily prevent user access to storage pools or volumes to perform maintenance. Instead of bringing down the server, you can deactivate individual storage pools. When you deactivate a storage pool, users will not have access to any of the volumes in that pool.

• Fast error correction and data recovery Because NSS is a journaled file-system, it can quickly recover data after a filesystem crash. Instead of scanning the filesystem for corruption, NSS replays the latest set of changes to make sure they were written correctly. The filesystem either recovers the changed information or returns it to its original condition prior to the transaction.

• Immediately save data to disk The Flush Files Immediately feature saves your file data to disk immediately after you close the file instead of caching it in memory and waiting for the next disk write cycle. This prevents your data from being at risk between disk write cycles, at the cost of slower filesystem performance overall.

• Retain previously saved files (Snapshot) The File Snapshot feature keeps an original copy of all open files so they can be archived by your backup utility. By capturing the most recent closed copy of the file, Snapshot guarantees that you still have a solid copy of the file with which to work.

• Salvage Files This option causes deleted files to be marked as purgeable space on the pool. Deleted files can be salvaged until the purgeable space is reclaimed as free space. This can be done manually by an administrator or automatically through the Purge Delay time.

• Transaction Tracking System (TTS) Transaction Tracking System protects database applications by backing out transactions that are incomplete due to a system failure. To enable TTS for an NSS volume, select the User-level Transaction Model option in the Volume properties page of iManager.

• Review the modified file list NSS maintains a list of files that have been modified since the previous backup. To save time, your backup utility only has to review this list rather than scanning the entire filesystem for modified files.

• Enable file compression NSS supports file compression. This lets you decide whether to compress the files in your volumes for more efficient use of storage device space. When it's enabled, however, you cannot disable file compression without re-creating the volumes.

• Data shredding The data shredding feature overwrites purged disk blocks with random patterns of hexadecimal characters. This is a security option that helps prevent the use of a disk editor to attempt to recover purged files. You can require up to seven random shred patterns to be written over deleted data.

• User space restrictions From iManager, you can now limit the amount of space available to an individual user on a logical volume.

• Directory space restrictions From iManager, you can now limit the space that can be assigned to a given directory or subdirectory.

• Repair storage pools instead of individual volumes Use the repair utility ravsui to perform a verify or rebuild operation to repair the NSS systems. The verify and rebuild operations function on the pool level rather than the individual volume level. These utilities should be used only as a last resort to recover the filesystem after data corruption.

  • Verify Checks the filesystem integrity of an NSS pool by searching for inconsistent data blocks or other errors. This operation indicates whether there are problems with the filesystem.

  • Rebuild Verifies and uses the existing leaves of an object tree to rebuild all the other trees in the system.

  NOTE

  In order to perform either a verify or rebuild operation, the NSS pool must be deactivated and marked as being in a maintenance mode. This will deactivate all volumes in the pool automatically.

  
  

• RAID support NSS provides software support for RAID 0 (data striping), RAID 1 (data mirroring), and RAID 5 (data striping with parity) to give you a robust set of options for protecting your server data. You can create and manage software RAID through iManager or through the console-based NSS Management utility (nssmu).

Understanding these NSS concepts will make it easier for you to plan and manage your NSS filesystem.

Planning the Filesystem

Now that you know a little about NSS, you can start planning your OES Linux filesystem. Throughout the planning phase, keep in mind that this is not referring to the root filesystem, where your operating system and Linux applications are traditionally installed. Plan your NSS file structure around shared applications and network storage that are yet to be created. After implementing your NSS plan, you can create and configure these applications and data repositories for use by the appropriate OES component. With that in mind, consider the following tips for creating a robust, accessible, and easy-to-manage filesystem:

• NSS filesystems under Linux can be used in two distinct modesNetWare mode and Linux mode. In Linux mode, NSS volumes are accessed using local Linux user accounts. In this mode, the extended trustee capabilities of NSS are not available, and NSS behaves like any other Linux filesystem, with regard to permissions. In NetWare mode, user accounts are redirected back to eDirectory. This allows eDirectory to control permissions and enables the advanced trustee framework available with NSS. When implementing NSS volumes, you should plan your layout according to the mode the volumes will be used with. Each NSS volume should only be accessed using one of these modesnot both.

  WARNING

  Accessing an NSS volume through both eDirectory-based user accounts (such as admin) and local accounts (such as root) will result in unpredictable behavior of permissions. Data will be consistent across access methods, but eDirectory trustee assignments are much more complex than POSIX permissions and are not entirely compatible. Plan your NSS volumes to ensure that only one access method is used.

  
  

• To simplify data backup, separate your applications and data into distinct volumes. Application volumes will be relatively stable over time, so they can be backed up less frequently than a data volume in which files are changing constantly. For more information about backing up files, see the "Backing Up and Restoring Files" section later in this chapter.

• If different applications will be available to different groups of users, try to organize the applications' directory structures so that you can assign comprehensive rights in a parent directory. This can help prevent you from having to create multiple individual rights assignments at lower-level subdirectories. More information on filesystem rights is available later in this chapter.

• If you want to use file compression to compress less frequently used files, try to group those types of files into directories separate from other files that are used more often. That way you can turn on compression for the less frequently used directories and leave it turned off for the frequently used directories. For more information about file compression, see the "File Compression" section later in this chapter.

• Decide whether you want users' daily work files to reside in personal directories, in project-specific directories, or in some other type of directory structure. Encourage your users to store their files on the network so that the network backup process can back up those files regularly, and so the files can be protected by NSS security.

These tips can help you effectively plan your filesystem. In addition, you must also understand how OES Linux provides access to NSS volumes. When you understand client access methods, you may need to adjust your NSS volume layout accordingly. These issues are described in the following sections.

ACCESSING NSS VOLUMES

At their fundamental level, NSS volumes are simply formatted filesystems. However, clients can potentially access these filesystems through several different methods. These access methods are typically specific to the OES component involved, like NetDrive or iFolder, but there is one access method that was specifically designed with NSS volumes in mindNCP.

The Novell NetWare Core Protocol (NCP) has been an important client/server networking protocol in Novell networks for years. Once based on IPX, this protocol runs over IP and provides login and file access capabilities, among other services, to NetWare servers and client workstations. The most prevalent example of the power of NCP is the Novell Client.

As explained in Chapter 4, "OES Linux Clients," the Novell Client is one of the primary methods of accessing NetWare resources from a workstation. The Client performs this function through the NCP protocol. The Client uses NCP to communicate directly with eDirectory for login and authentication. It is also through NCP that such things as file-level permissions and printer access control are obtained by the Client. With OES Linux, it was important to maintain those capabilities, and also bring the additional features, like login scripts, to the Linux platform. This goal was accomplished through the NCP Server component of OES Linux.

The NCP Server is actually an integrated component of Novell eDirectory. However, its role is separate from the traditional view of eDirectory. The main purpose of the NCP Server is to provide NCP services, such as file and print, to workstations running the Novell Client. The NCP Server is therefore an important component with regard to file access.

Using the NCP Server, directories on your OES Linux server can be shared over NCP as an NCP volume. These NCP volumes on Linux then appear exactly like volumes that are available on a NetWare server. This means that a workstation running the Novell Client can access any NCP volume using just the server name and NCP volume name.

One user-accessible NCP volume is created by default with OES LinuxSYS. The directory on the local filesystem for the SYS volume is /usr/novell/sys. This directory is referred to as the mount point of the NCP volume, although no separate partition is required to be mounted there. Workstations running the Novell Client can directly access that directory by mapping a local drive through the Client to the SYS volume.

The SYS volume is important for Novell Client workstations due to the directories stored there. By default, the following two directories can be found on the SYS NCP volume:

• PUBLIC holds the Novell tools necessary to log in and map drives to NCP resources.

• LOGIN holds those files required for user access even though they are not yet logged in to the Novell environment. This includes the basic utilities necessary to help accomplish an eDirectory login.

The method used by the NCP Server for sharing a local directory as an NCP volume is the same method used to make NSS volumes available to client workstations. This is important as it means that NSS volumes must first be mounted locally, and then exported (automatically) as NCP volumes.

Because the volumes are mounted into the root filesystem, access to the volume can be granted through any possible method of accessing the local disk. This includes such things as through NFS and Samba shares. To allow for access through multiple methods, you may want to adjust the mount point of the NSS shares to match requirements imposed by other services.

NOTE

Accessing NSS volumes through traditional Linux methods, such as NFS or Samba, does not automatically put the volume into Linux mode. Whether an NSS volume is in Linux mode or NetWare mode is completely dependent on where the user account is being stored. If Samba authentication is being redirected to eDirectory, the NSS volume is still being used in NetWare mode and the advanced trustee capabilities of NSS are available.

NSS VOLUME CONSIDERATIONS

With an understanding of how clients will access the NSS volumes, it is possible to plan your volume layout. This layout should include what NSS volumes you would like to create, and possibly what directory structure should exist on that volume.

One consideration should be whether to have one volume or many. For the most part, applications should not require a dedicated volume. However, multiple volumes allow you to tune volume-wide settings for optimal performance of a specific application. Care should be taken to not overdo this, though, as too many volumes may result in unwanted administrative overhead.

It is also possible to create separate directory structures for each application or storage location. This is true for both single volume and multivolume configurations. Through a properly planned file structure, it is much easier to assign trustee rights that grant users access to what they need, but without granting them access to things they don't. For example, general-use applications can be organized in an APPS volume, each in its own subdirectory. With this configuration, rights to these applications can be easily assigned high in the directory structure where they will flow down, through inheritance, to all subdirectories. More information on filesystem rights is available later in this chapter.

If an application requires that it be installed at the root of a filesystem, NSS gives you the flexibility of installing the application where it makes sense and then creating a root drive mapping to fool the application into thinking it is operating from a root location in the filesystem. Creating a root drive mapping requires the redirector capabilities of either the Novell Client or the NetDrive Client. See Chapter 4 for more information on the Novell Client. See Chapter 12, "OES Linux File Access," for more information on NetDrive.

You can create a map root from the client, but if it is needed for a large number of users, a much better way is to include the map command in the appropriate login script. The eDirectory login script is a batch file that outlines basic operations that should be performed every time the user logs in to the network. Login script operations can include environment variables, drive mappings, program execution, and message display.

Through a login script, a map operation can be performed automatically when each user logs in, and changes to every workstation will not be necessary. For example, you can add the following command to a container login script to root map a drive for all users within the container:

 MAP ROOT X:=VOL1:APPS\ABC 

For more information about login scripts, see the online OES documentation.

If you decide to host an application from the Linux server, you should flag the application's executable files as Shareable, Read-Only (S, Ro). This allows the application to be used by multiple users simultaneously, but prevents users from inadvertently deleting or modifying it. This is an additional layer of protection beyond that provided by restricting access to the files at the directory level. More information on filesystem rights is available later in this chapter.

Working with NSS Volumes

You can create NSS storage structures as needed, both during the installation process and after the server installation is complete. Given that, it is probably a good idea to understand the technology and storage concepts a little before you start doing a lot of storage management. You can configure and manage NSS after installation with iManager or the console-based NSS Management utility (nssmu).

With NSS, you use partitions, storage pools, and logical volumes. You create logical volumes in storage pools that are composed of free space from the various storage devices in your server.

NSS uses free space from multiple storage devices. NSS allows you to mount up to 255 volumes simultaneously and store up to 8 trillion files in a single volumeup to 8TB (terabytes) in size.

The main components of the NSS filesystem were introduced at the beginning of this chapter. The following sections explain how to install, create, and work with NSS resources.

INSTALLING NSS

NSS is normally installed during the main OES Linux installation. However, NSS can be added after the main installation using YaST. The following steps document this process:

1.	Access YaST from a terminal using yast, or from a graphical environment using yast2 or the YaST launcher from the application menu.
2.	Select the System category in YaST. From within this category, locate and select the NSS module. This module will detect that the RPMs for NSS are missing and ask if you want to install them. Select Continue to install the necessary packages.
3.	At the conclusion of the software installation, SuSEconfig is executed to update the system configuration. When this completes, the configuration of the OES component will begin automatically.
4.	At the Novell Storage Services LDAP Server Configuration screen, enter the following information and click Next: Local or Remote Directory Server Select the radio button that indicates whether eDirectory is running on the local server or a remote server. Directory Server Address If a remote eDirectory server is in use, enter the IP address for this server. Admin Name with Context Enter the eDirectory administrator's credentials using fully qualified dot notation, for example, cn=admin.o=novell. Admin Password Enter the password for the administrator user. Port Details If necessary, select this button to change the configured ports for the eDirectory server you specified earlier. The default LDAP port for unencrypted communications is 389 and port 636 is used for SSL-encrypted communications.
5.	At the NSS Unique Admin Object screen, enter a fully qualified name for the NSS administrator object. Each server in the eDirectory tree must have its own NSS administrator object. After entering the name, click Next to complete the installation.
6.	In order for NSS to be active, you should restart the Linux server. If you would like to start NSS services manually, you can execute /etc/init.d/novell-nss start.

NOTE

Unlike other startup scripts, the NSS startup script (/etc/init.d/novell-nss) only accepts the start command-line parameter. This is due to the kernel module requirements of this component. If you want to completely disable NSS, you must use insserv or chkconfig to remove this service from your Linux startup process.

PARTITIONS

With NSS, you probably won't have to manage partitions directly because they are automatically created to support the storage pools you define. However, if you want to create non-NSS partitions, you can do so from YaST by following these steps:

1.	Access YaST from a terminal using yast, or from a graphical environment using yast2 or the YaST launcher from the application menu.
2.	Select the System category in YaST, and select the Partitioner module.
3.	At the Expert Partitioner page, you can create a new partition by clicking the Create button.
4.	Select the device on which the partition should be created, and designate the partition as a primary or extended partition. At the Create Partition page, specify at least the following information (see Figure 11.2): Size Adjust the partition size by designating the appropriate start and end cylinders. The start cylinder is not normally adjusted, and the end cylinder can be determined automatically be entering sizes in the format of +2.7GB (for a 2.7-Gigabyte volume). Mount Point Select or enter the directory that will be used as the mount point for this partition. Format Select Format to automatically format the new partition with the designated filesystem type. Possible options are EXT2/3, FAT, JFS, Reiser, XFS. If this partition should be an encrypted filesystem, select the Encrypt FileSystem check box. Figure 11.2. Creating non-NSS partitions using YaST.

NSS leverages the Enterprise Volume Management System (EVMS) to bring NSS support to Linux. As such, common EVMS utilities such as evmsgui can be used to create and manage NSS partitions. This also allows traditional Linux filesystem utilities, such as mkfs and mount, to format and mount NSS volumes. Linux gurus may find the traditional utilities more favorable, but iManager is generally a more user-friendly way of working with NSS.

iManager automatically creates NSS partitions when NSS pools and volumes are created. This significantly reduces the complexity of managing disk partitions. For more information on low-level management of NSS partitions, see the online OES Linux documentation.

STORAGE POOLS

A storage pool is a specific amount of space you obtain from one or more storage devices in your server. OES Linux has integrated the partition-creation process into the process for creating storage pools. NSS storage pools provide the flexibility of NSS. They can be created to span one or multiple partitions on the hardware side, and can be divided into one or multiple logical volumes on the user side.

After a pool is created, you can add storage devices to your server and then expand the pool to include the space available on the new storage device. To create a new storage pool, complete the following steps:

1.	Launch iManager, open the Storage link, and select Pools in the Navigation frame.
2.	At the Pool Management page, specify the server with which you want to work. This will bring up the storage pool information for that server, as shown in Figure 11.3. Figure 11.3. Managing storage pools from iManager.
3.	Click New to create a new storage pool.
4.	Specify the name of the storage pool and click Next. Make sure to follow the naming conventions as outlined.
5.	At the Select Device and Space page, choose the storage device(s) from which the new storage pool will get its space, specify the amount of space for each device, and then click Finish. Check Activate on Creation if you want the pool to be available as soon as it is created.

After creating the pool, you will be returned to the Pool Management page, from which you can perform various configuration tasks on storage pools and view the characteristics of pools that have been created. Configuration options include the following:

• New Allows you to create new storage pools, as described previously.

• Delete Allows you to delete an existing storage pool.

• Rename Allows you to rename an existing storage pool.

• Activate Makes a pool, and all volumes associated with that pool, available for use.

• Deactivate Removes a pool, and all volumes associated with that pool, from service. Users cannot access data on an inactive pool. This might be done so that you can perform maintenance on the pool or its associated volumes.

• Increase Size Allows you to add space to a storage pool.

• Snapshot This pool-level feature is not available on Linux-based NSS pools.

• Update eDirectory If you have modified or renamed a storage pool, use this option to update the eDirectory pool object with the new information and characteristics.

• (Conditional) Deleted Volumes If you have deleted volumes from a storage pool, you can use this option to salvage or purge those deleted volumes.

• (Conditional) Offline This pool-level feature is not available on Linux-based NSS pools.

These options give you granular control over the management and performance of the storage pools on your OES Linux server.

LOGICAL VOLUMES

After a storage pool has been created, you are ready for NSS logical volumes. NSS volumes can be set to a specific size or set to grow dynamically within the storage pool according to the amount of storage space that is needed over time. When set to grow dynamically, NSS volumes can automatically take advantage of new storage devices when their space is added to their associated storage pool.

After you've created the volume, you must mount it before network users can access it. To create and mount a new NSS volume, complete the following steps:

1.	Launch iManager, open the Storage link, and select Volumes in the Navigation frame.
2.	At the Volume Management page, specify the server with which you want to work. This will bring up the volume information for that server, as shown in Figure 11.4. Figure 11.4. Managing server volumes from iManager.
3.	Click New to create a new volume.
4.	Specify the name of the volume and click Next. Be sure to follow the naming conventions as outlined.
5.	At the Select a Pool and Volume Quota page, provide the required information and click Next. The required information includes: Storage Pool Check the box next to the storage pool from which the volume will be created. You can also click the New Pool button to create a new storage pool for this volume. Doing this will drop you into step 4 of the storage pool creation process, discussed previously. Allow Volume Quota to Grow to Pool Size If you don't want to specify a volume quota, check this box to let the volume grow dynamically to fit the available pool space.
6.	At the Attribute Information page, make your desired selections and click Finish. The selections you can make include: Backup This option marks the volume data for backup, similar to setting the Archive bit on a file or directory. Compression Turns data compression on for this volume. Compression will use volume space much more efficiently at the cost of read performance. If volume data is not used constantly, compression can be a good idea. Data Shredding Instructs NSS to overwrite deleted data with random characters to prevent recovery with disk reader software. Specify how many overwrite passes to make (17). Directory Quotas Sets a limit on the amount of space that any directory can occupy. This might be useful for restricting the size of application, log, or user directories you don't want to grow beyond a certain point. Flush Files Immediately Instructs NSS to write data to disk immediately upon file close, rather than waiting for the next write cycle. Migration Enables support for near-line storage, such as optical subsystems. Migration creates a lookup key in the volume's File Allocation Table (FAT) that describes how to retrieve the data from the near-line storage system. Modified File List Displays a list of files modified since the last backup cycle. This is useful for archive utilities, so they don't have to scan the entire volume for changed files. Salvage Instructs NSS to keep deleted files until the space is needed for new data, so they can be recovered if necessary. Snapshot - file level Instructs NSS to keep a copy of the last closed version of each open file in this volume. That way, archive utilities can save the copy to provide some protection in the event of data loss. User Space Quotas Allows you to set usage limits for individual eDirectory users. When a quota is reached, users will be unable to save any more files until they have made space for them by removing other files. User-Level Transaction Model Enables Novell's Transaction Tracking System (TTS) for the volume. This helps protect databases from corruption that might occur if a failure happens during a database transaction. With TTS turned on, an incomplete transaction is completely backed out and restored to its original state prior to the transaction. TTS protects data by making a copy of the original data before it is overwritten by new data. Then, if a failure of some component occurs in the middle of the transaction, TTS restores the data to its original condition and discards the incomplete transaction. On Creation This section allows you to specify whether to activate and/or mount the new volume upon creation. Activating a volume is what makes it available for use. Mounting a volume associates that volume with a directory on the OES root filesystem. If you select to mount the volume, you must also identify a directory used as a mount point.

After the volume has been created, you will be returned to the Volume Management page, from which you can perform various configuration tasks on existing volumes and view the characteristics of volumes that have been created. Configuration options include the following:

• New Allows you to create new volumes, as described previously.

• Delete Allows you to delete an existing volume. All data on a deleted volume is removed, but salvage and purge options for deleted volumes are available at the storage pool level.

• Rename Allows you to rename an existing volume.

• Activate Makes a volume available for mounting and use by the server.

• Deactivate Makes a volume temporarily unavailable for use by the server. A volume cannot be mounted while it is deactivated.

• Mount Makes a volume available for use by network users, who can then access the volumes through any of the access methods supported by OES Linux.

• Dismount Makes a volume temporarily unavailable for use by network users.

• Properties This option lets you make changes to volume attributes, as defined when the volume was created. Volume attributes were discussed previously, during the volume creation process.

• User Quotas If you have enabled the User Space Restrictions attribute on a volume, use this option to set those space restrictions. This is often useful for limiting the amount of space available to users' home directories.

• Update eDirectory If you have modified or renamed a volume, use this option to update the eDirectory volume object with the new information and characteristics.

These volume configuration options give you granular control over the management and performance of the NSS volumes on your OES Linux servers.

Console-Based NSS Management Utilities

Traditional NSS management utilities are console-level tools written for the NetWare platform. With NSS now available on Linux, these same tools have been brought over to the OES Linux platform. The two main console tools for NSS are the NSS Management Utility and the NSS Console.

NSS MANAGEMENT UTILITY (nssmu)

The NSS Management Utility, or nssmu, is the primary tool for creating NSS pools and volumes from the command line. This utility also has the ability to enable RAID configurations and manage storage devices and partitions. iManager offers the same general features of nssmu and is the preferred tool for managing NSS.

The NSS Management Utility is installed to the /sbin directory and can be executed by entering nssmu via a terminal by an administrative user. For more information on nssmu, see the man page for nssmu (man 8 nssmu) or view the online OES Linux documentation.

NSS CONSOLE (nsscon)

The NSS Console, nsscon, was created to make the NetWare NSS console commands available on Linux. These commands are used to both manage the available NSS resources and tune the many NSS configuration parameters. The NSS Console will also act as a running log of NSS activity and can be used in troubleshooting NSS problems.

The NSS Console is installed to the /sbin directory and can be executed by entering nsscon via a terminal by an administrative user. After nsscon is started, you are presented with the nsscon prompt, which is the name of the server followed by a greater-than (>) sign. All commands entered at this prompt must be in the following format:

 nss <PARAMETER> 

NSS pools and volumes can be displayed using the following syntax:

 nss pools nss volumes 

NSS parameters can also be adjusted by locating the specific parameter and configuring a new value using the following syntax:

 nss /AllocAheadBlks=30 

To view a list of the most commonly used NSS configurable parameters, execute the following command:

 nss help 

All nsscon parameters are case insensitive and can be abbreviated as long as there is no ambiguity in the parameter name. Also, parameters can be set on system startup by adding the parameter setting to the NSS configuration file: /opt/novell/nss/conf/nssstart.cfg.

To exit the NSS Console, enter exit at the nsscon prompt. For more information on the NSS Console, see the online OES Linux documentation.

OTHER NSS CONSOLE UTILITIES

The NSS Management Utility and Console are not the only command-line tools for NSS with OES Linux. Table 11.1 lists the remaining console-based utilities used with NSS. More information regarding these utilities is available through the online OES Linux documentation.

Table 11.1. Console-Based NSS Utilities

COMMAND	DESCRIPTION
nss	Used to list, activate, and deactivate NSS pools.
nssmu	NSS Management Utility used to create and delete NSS partitions, pools, and volumes. Can also be used to enable RAID configurations.
nsscon	NSS Console used to adjust tuning parameters of NSS.
nssscan	Maintenance utility used to scan or restore an NSS pool.
nssmount	Used to mount NSS volumes.
nssupdate	Used to update eDirectory information for NSS pools.
ravsui	The Rebuild And Verify Simple User Interface utility is used to perform maintenance on NSS pools.
ravview	The Rebuild And Verify Viewer utility is used to view report files generated through maintenance procedures with ravsui.

Repairing NSS Pools

When a problem occurs in the NSS environment, repairs are made at the storage pool level rather than at the volume level. There are two basic types of repair operations for NSS pools:

• Verify This operation checks the filesystem integrity for an NSS pool by searching for inconsistent data blocks or other errors. This process will indicate if there are problems with the filesystem.

• Rebuild This operation actually makes repairs to the NSS storage pool should they prove necessary.

NOTE

The rebuild process should be a last resort and is seldom necessary. The NSS filesystem is journaled, meaning that it keeps a log of disk activities while they are executing. When a disk crash or other problem occurs, NSS automatically rolls the filesystem state back to a known good state and then re-executes the operations in the journal to bring the system back up to date.

Verify and rebuild operations can only be performed on deactivated pools that are designated as being in a maintenance mode. Pools can easily be deactivated through iManager (using the Storage, Pools page), but the nsscon utility must be used to designate a pool in maintenance mode. The nsscon utility can also be used to deactivate a pool. As such, it may be easier to perform both operations directly through nsscon. To deactivate and mark a pool in maintenance mode using nsscon, perform the following steps:

1.	From a terminal on the OES machine, launch nsscon.
2.	From the nsscon command prompt, enter nss pools to retrieve a listing of all NSS pools.
3.	Using a pool name located in step 2, deactivate the pool by entering nss /PoolDeactivate=<POOL_NAME> at the nsscon prompt.
4.	To mark the pool as being in a maintenance mode, enter nss /PoolMaintenance=<POOL_NAME> at the nsscon prompt.
5.	While the pool is in maintenance mode, perform the verify or rebuild operation using ravsui. (This is explained in more detail following these steps.)
6.	To reactivate the pool, enter nss /PoolActivate=<POOL_NAME> at the nsscon prompt.
7.	When the pool is reactivated, you can activate and mount volumes through iManager, or by entering nss /VolumeActivate=<VOLUME_NAME> at the nsscon prompt. To view a list of volumes through nsscon, enter nss volumes.

As previously mentioned, NSS maintenance can only be performed while the pool is in maintenance mode. After setting maintenance mode on a pool, you can execute a verify operation, which is a read-only assessment of the storage pool, by typing the following command at a server console:

 ravsui verify <NSS_POOL_NAME> 

Should it become necessary, you can perform a rebuild by entering the following command at the server console:

 ravsui rebuild <NSS_POOL_NAME> 

The rebuild operation verifies and accounts for all data blocks in the storage pool. If there are any errors, the errors appear on the screen and are also recorded in rebuild log files. The verify operation also records log files of the operation. All ravsui log files are written to the /var/opt/novell/log/nss/rav directory. However, these logs are written in XML format and are not intended to be directly viewed. To view these log files properly, use the ravview utility.

The ravview utility is used to view both verify and rebuild log files. However, the utility must be told what type of log file is being viewed. This is accomplished with the following startup switches:

 ravview rtf <REBUILD_LOG_FILE> ravview vbf <VERIFY_REPORT_FILE> 

The most recent log files corresponding to a specific pool can also be viewed by using the following syntax:

 ravview rtfn <POOL_NAME> ravview vbfn <POOL_NAME> 

After reviewing log files and completing any rebuild or verify operations, remember to reactivate and mount the pool and volume(s). Users will be unable to access data until this final step is completed.

NOTE

For more information on ravsui, ravview, and other NSS command-line functions, see the utility help screen (help) and OES Linux online documentation.

Saving Disk Space

OES Linux offers a few simple features to help you to conserve disk space if it becomes an issue:

• NSS file compression, which compresses less frequently used files, has been shown to conserve up to 63% of your hard disk space. However, your specific experience will vary depending on the types of files being stored on the server.

• Restricting users' disk space enables you to decide how much room user data can consume on a given volume.

• Purging files from NSS volumes lets you free up disk space by removing files that have been deleted but are still retained in a salvageable state. (You can also salvage deleted files, instead of purging them, but of course that doesn't free up any disk space.)

Although none of these is a replacement for adding disk space to your server, they can help you keep things running smoothly while you prepare to upgrade your hardware.

FILE COMPRESSION

File compression typically can save up to 63% of the server's hard disk space by compressing unused files. Compressed files are automatically decompressed when a user accesses them, so the user doesn't necessarily know that the files were compressed.

Volumes are automatically enabled to support compression if you enable that attribute when the volume is created. You can also enable support for compression after the fact by modifying a volume's properties with iManager.

After compression is enabled on a volume, it cannot be disabled, except by deleting and re-creating the volume. However, through proper management of volume compression, it is possible to nearly prevent files from being compressed.

By default, when a volume is created with compression turned on, files and directories are compressed automatically after they've been untouched for 14 days.

You can change several aspects of file compression, however, such as how long the files wait before being compressed, the time of day the compression activity occurs, and which files never get compressed. To control file compression, you can use two directory attributes and several nsscon commands.

To specify compression for specific volumes or directories, you can assign them the following attributes with the Novell Client. To do this, access the NSS volume through the Novell client, and view the properties of the volume or directory using the right-click menu. Select the NetWare Info tab and modify the following attributes:

• Don't Compress Instructs NSS to never compress the directory, even if compression is turned on for a parent directory.

• Immediate Compress Instructs NSS to compress the directory immediately, without waiting the standard inactivity period.

The nsscon commands that affect file compression let you control compression characteristics for all enabled volumes on the server. You can set options such as when compression happens, how many files can be compressed at the same time, how many times a file must be accessed before it is decompressed, and so on. You must use nsscon to view and change these parameters.

NOTE

Remember that if you change a compression parameter using nsscon, the change affects all files and directories in all volumes on the server that have been enabled for compression.

To change the compression parameters, complete the following steps:

1.	From a terminal on the OES machine, launch nsscon.
2.	Modify any of the NSS parameters by entering the following at the nsscon prompt: nss <Parameter>=<Value> NSS parameters are not case sensitive. To view a complete list of parameters, use nss ? at the nsscon prompt. All parameters, as well as their current settings, are displayed on the screen. Compression-related parameters are as follows: /CompressionDailyCheckStopHour=HOUR Specifies the hour when the file compressor stops searching volumes for files that need to be compressed. If this value is the same as the Compression Daily Check Starting Hour value, the search starts at the specified starting hour and goes until all compressible files have been found. The default is 6 (6:00 a.m.). Values range from 0 (midnight) to 23 (11:00 p.m.). /CompressionDailyCheckStartingHour=HOUR Specifies the hour when the file compressor begins searching volumes for files that need to be compressed. The default is 0 (midnight). Values range from 0 to 23 (11:00 p.m.). /MinimumCompressionPercentageGain=NUMBER Specifies the minimum percentage that a file must be able to be compressed in order to remain compressed. The default is 20. Values range from 0 to 50. /(No)EnableFileCompression When this option is set to On (/EnableFileCompression), file compression is allowed to occur on volumes that are enabled for compression. If this option is set to Off (/NoEnableFileCompression), file compression won't occur, even though the volume is still enabled for compression. The default is On. /MaximumConcurrentCompressions=NUMBER Specifies how many volumes can compress files at the same time. Increasing this value can slow down server performance during compression times. The default is 2. Values range from 1 to 8. /ConvertCompressedToUncompressedOption=NUMBER Specifies how a compressed file is stored after it has been accessed. The default is 1. Values range from 0 = always leave the file compressed; 1 = leave the file compressed after the first access within the time frame defined by the Days Untouched Before Compression parameter, and then leave the file uncompressed after the second access; 2 = change the file to uncompressed after the first access. /DecompressPercentDiskSpaceFreeToAllowCommit=NUMBER Specifies the percentage of free disk space that is required on a volume before committing an uncompressed file to disk. This helps you avoid running out of disk space by uncompressing files. The default is 10. Values range from 0 to 75. /DecompressFreeSpaceWarningInterval=TIME Specifies the interval between warnings when the volume doesn't have enough disk space for uncompressed files. The default is 31 min 18.5 sec. Values range from 0 sec (which turns off warnings) to 29 days 15 hours, 50 min 3.8 sec. /DeletedFilesCompressionOption=NUMBER Specifies how the server handles deleted files. The default is 1. Values range from 0 = don't compress deleted files; 1 = compress deleted files during the next day's search; 2 = compress deleted files immediately. /DaysUntouchedBeforeCompression=DAYS Specifies how many days a file or directory must remain untouched before being compressed. The default is 14. Values range from 0 to 100000. Setting this value to 100000 effectively disables file compression.
3.	When finished, enter Exit to quit the nsscon utility.

These configuration parameters give you robust control over the compression process. However, you should always remember that enabling compression can lead to slower filesystem performance due to the processor-intensive nature of file compression/decompression.

RESTRICTING USERS' DISK SPACE

You can restrict how much disk space a user can fill up on a particular volume. This can help prevent individual users from using an excessive amount of disk space. NSS volumes let you enable/disable this support through the User Space Restrictions attribute.

To set space restrictions, open the Volumes page in iManager (in the Storage group). Click User Quotas to open a page from which you can select users and assign them a maximum amount of disk space they can use on a given volume (see Figure 11.5). You can also see how existing restrictions have been set and how much space each user has available in their quota.

Figure 11.5. Using iManager to set and view user volume quotas.

PURGING AND SALVAGING FILES

When files are deleted from an NSS volume, they are not actually removed from the server's hard disk. Instead, they are retained in a salvageable state. Deleted files are usually stored in the same directory from which they were originally deleted. If the directory itself was also deleted, the deleted directory must be salvaged prior to gaining access to any deleted files within that directory.

EXCEPTIONS TO THE SALVAGEABLE STATE

Deleted files are maintained in this salvageable state unless one of the following occurs:

• The file is salvaged, restoring it to its original form.

• The server runs out of free space on the disk and begins to overwrite files that have been deleted for a specified period of time. The oldest deleted files are overwritten first. A configurable NSS parameter defines the amount of time a file must remain deleted before it can be overwritten.

• The administrator or user purges the file. (When purged, a file is completely removed from the disk and cannot be recovered.) You can purge files with the Novell Client and ConsoleOne.

• The Immediate Purge attribute can be set at the file, directory, or volume level to prevent files from being salvaged. You can set this attribute with the Novell Client and ConsoleOne.

• The administrator sets the NSS parameter /ImmediatePurgeOfDeletedFiles. All volumes on that server will immediately purge deleted files. (The default for this parameter is Off. To disable immediate purge, set the NSS parameter /NoImmediatePurgeOfDeleteFiles.)

If any one of these events occurs, the file is no longer salvageable.

PURGING AND SALVAGING FILES

You, or any user, can use the Novell client utilities to either purge or salvage a deleted file or directory. To do so, right-click the red N in the system tray, select NetWare Utilities, and choose either Salvage or Purge.

You can also use ConsoleOne to salvage and purge files by completing the following steps:

1.	Launch ConsoleOne and browse to the directory containing the files or directories you want to salvage or purge.
2.	From the View menu, select Deleted File View.
3.	In the View window (right side), select a file or directory.
4.	Click either the Salvage or Purge button on the ConsoleOne toolbar, as shown in Figure 11.6. Figure 11.6. Using ConsoleOne to salvage or purge deleted files.
5.	If you salvage files from an existing directory, the files are restored to that directory. In order to salvage files from a deleted directory, the deleted directory itself must first be salvaged. After the directory has been salvaged, additional deleted files within that directory can be salvaged.

This provides both users and administrators with a tool for recovering deleted files.

NOTE

If you have data shredding enabled, it will occur when a file is purged, not when it is deleted. If you have very sensitive materials on which you want to use data shredding, it might be a good idea to enable the Immediate Purge attribute for the file or directory where such data is stored.