10.3 Avoiding Common Implementation Problems

This section presents a few pointers for avoiding common implementation problems.

Keep in mind that the list of issues presented here is not comprehensive. Rather, it simply outlines some of the more common problems reported by network administrators. To ensure successful service implementations, you should always follow the instructions in the documentation for the services you are implementing.

The various service sections of this guide touch on common implementation tips as well. But again, there is no substitute for following the documentation prepared by the teams responsible for building and maintaining the service components.

The following components have implementation caveats:

10.3.1 Novell iFolder 2 (OES Linux)

You will want to be aware of the following when using Novell iFolder® 2 on OES Linux.

Novell iFolder 2 on Linux Requires a Dedicated IP Address

When you install Novell iFolder 2 on Linux, the installation program checks to see whether there are other Web services running on the server.

If there are no other services, you have the option to install Novell iFolder as either

  • A standalone Novell iFolder server, meaning that you don’t plan to add other Web applications to the server in the future.

    or

  • a Novell iFolder server running with other Web applications, meaning that you might choose to add other Web applications later.

If there are other services running, you do not have the option to install Novell iFolder in standalone mode.

Adding Other Web Services to a Standalone Novell iFolder Server

If you have installed a standalone Novell iFolder server and later decide to install other Web applications on the same server, you must reconfigure the Novell iFolder installation after adding the other Web services.

The simplest way to do this is using YaST:

  1. Start YaST.

    If you installed Novell iFolder without KDE (the default), run YaST in text mode by entering yast at a shell prompt:

  2. Select Network Services > iFolder 2.x.

  3. Answer Yes to the warning that Novell iFolder is already installed.

  4. Tab to the Admin Password field and type the eDirectory Admin password, then go to the next screen by tabbing to Next and pressing Enter.

  5. Select the iFolder 2.x and Other Web Applications Will Run on This Server option.

  6. In the iFolder 2.x Server IP Address field, type a unique IP address that is on the same subnet as the primary IP address specified for the server.

  7. Type the same netmask as specified for the primary IP address.

  8. Type a hostname for the IP address assigned in Step 6.

  9. Click Next twice.

    The new iFolder configuration is written to the system configuration files.

Adding a Novell iFolder Server to an Existing OES Linux Server

If you have installed an OES Linux server Web applications, such as NetStorage, and later decide to install Novell iFolder on the same server, you must specify the unique IP address information and hostname that Novell iFolder requires as you add the service.

The simplest way to do this is using YaST:

  1. Start YaST.

    If you installed Novell iFolder without KDE (the default), run YaST in text mode by entering yast at a shell prompt:

  2. Select Network Services > iFolder 2.x.

  3. Tab to the Admin Password field and type the eDirectory Admin password, then go to the next screen by tabbing to Next and pressing Enter.

  4. Select the iFolder 2.x and Other Web Applications Will Run on This Server option.

  5. In the iFolder 2.x Server IP Address field, type a unique IP address that is on the same subnet as the primary IP address specified for the server when it was installed.

  6. Type the same netmask as specified for the primary IP address.

  7. Type a hostname for the IP address assigned in Step 6.

  8. Do not change the User Data Path.

  9. Click Next twice.

    The Novell iFolder configuration is written to the system configuration files.

10.3.2 iManager 2.5

iManager 2.5 has the following implementation caveats.

Be Sure to Run the iManager Configuration Wizard

In Installing RBS in the Novell iManager 2.5 Administration Guide , you are instructed to run the iManager Configuration Wizard before using iManager.

When iManager is installed in connection with OES, various roles and tasks are configured, as shown in Figure 10-1.

These roles and tasks are available to all the users you create until you run the configuration wizard. After that, the roles and tasks are available only to the Admin user and other users or groups you specifically designate.

Figure 10-1 iManager Roles and Tasks

For more information on iManager, see the Novell iManager 2.5 Administration Guide .

10.3.3 iPrint

iPrint has the following implementation caveats.

iManager Plug-Ins Are Platform-Specific

The iManager plug-ins are different for each server platform. Therefore, if you have both OES Linux and OES NetWare servers running iPrint services, you need two instances of iManager to manage iPrint—one on each platform.

No Cluster Failover between Platforms

Clustered iPrint services can only fail over to the same OES platform (Linux or NetWare).

iPrint on OES Linux

You should be aware of the following when using iPrint on OES Linux.

Uploading Print Drivers for iPrint

From a Linux workstation running iManager, only the From System button works to upload drivers through a Mozilla-based browser. This means that the following will not work:

  • Uploading Windows drivers from Linux

  • Uploading from Konqueror or other non-Mozilla-based browsers

Uploading Might Require a CUPS Administrator Credential

A PPD is the Linux equivalent of a printer driver on Windows.

There are two versions of the iPrint client: high-security and low security. By default, end users and administrators install the high-security client when using the iPrint Printer List Web page.

This means that administrators are prompted for a CUPS administrator credential when uploading PPDs. However, the prompt doesn’t specify that a CUPS administrator credential is needed and the root user credential does not work.

iPrint Disables Printing on the Server

iPrint uses CUPS to render print jobs before sending the print job to the Print Manager. For performance and scalability, printing from the server itself is disabled during the OES installation of iPrint.

iPrint Client for Linux Doesn't Install Automatically

Users who are used to installing the Windows iPrint client expect to choose an Open option and have the client install automatically. However, installing the client on Linux workstations requires saving the RPM package and then installing it manually if a package manager is not already installed and configured as it is in Novell Linux Desktop. For more information, see Linux: iPrint Client in the OES iPrint Administration Guide for Linux .

10.3.4 NCP Server (OES Linux)

NSS file attributes and NCP™ services tend to get mixed together in the minds of NetWare administrators. It is important to remember that file and directory attributes are supported and enforced by the file system that underlies an NCP volume, not by the NCP server.

For example, even though Rename Inhibit attribute appears to be settable in the NCP client interface, if the underlying file system is traditional Linux (Reiser, etc.) there is no support for the attribute and it cannot be set.

Some administrators assume they can provide NSS attribute support by copying or migrating files, directories, and metadata from an NSS volume to a defined NCP volume on a traditional Linux partition. However, this doesn’t work, because NSS file attributes are only supported on NSS volumes.

10.3.5 NSS (OES Linux)

NSS on Linux has the following implementation caveats.

Only EVMS Is Supported

For this release, NSS recognizes only drives that are managed by EVMS. If your hard drive is managed by Linux Volume Management, it cannot be managed by EVMS and NSS does not recognize it.

For example, administrators are sometimes stumped when trying to create NSS pools and partitions on a drive using the Novell Storage Services™ Management Utility (NSSMU), because the utility doesn’t recognize the drive.

If you experience this problem, use the YaST Partitioner to delete everything from the drive. You might then need to reboot the machine for NSSMU to recognize the drive.

User Quota Enforcement Always Requires Linux-Enabled Users

If you use User Quotas to limit the amount of disk space available to network users, you must ensure that users are enabled for Linux access using the iManager Linux User Management (LUM) plug-in.

This requirement extends to access through services that don’t require LUM for general access, such as Web-based services like NetStorage and NCP clients accessing NCP/NSS volumes.

Background Information

The basic reason for this requirement is that NSS requires LUM to map file ownership between POSIX* and eDirectory. If users are not enabled for Linux access, directories and files that they create on NSS volumes are actually owned by the root user and not counted against any quotas you have set for them. For more information, see Enforcing File Ownership and User Space Restrictions in the Novell Storage Services File System Administration Guide for OES .

Moving an NSS Volume from NetWare to OES Linux

Some organizations are moving drives that contain NSS volumes from NetWare servers to OES Linux servers. The process is very straightforward and completely reliable, provided you follow the instructions in the Coexistence and Migration Issues section in the Novell Storage Services File System Administration Guide for OES .

The key point to remember is that you must enable volume users for Linux access before activating the moved volume for user access. For details, see the information in Access Control Issues for NSS on OES Linux in the Novell Storage Services File System Administration Guide for OES .

Setting User Quotas On Volumes that Are Being Used

Users who are not enabled for Linux access can work on NSS volumes through NCP clients and Web-based file services, such as NetStorage and iFolder. However, files created by these users are not counted against User Quotas because the system can’t map file ownership between POSIX and eDirectory, so all newly created files are owned by the root user.

If you have created an NSS volume on an OES Linux server or moved a volume from NetWare to OES Linux, and you didn’t enable volume users for Linux prior to allowing volume access, you can set quotas by following the instructions in Configuring User Space Quotas for Users Who Were Not Initially Enabled for Linux Access (Linux) in the Novell Storage Services File System Administration Guide for OES