Home > Articles > Networking

  • Print
  • + Share This
  • 💬 Discuss

Native File Access

Novell Native File Access (NFA) enables Macintosh, Windows, and Unix workstations to access and store files on NetWare servers without installing the Novell client. NFA is installed by default as part of the basic OES NetWare server installation process and provides instant network access. Just plug in the network cable, start the computer, and you’ve got access to servers on your network.

NFA enables client workstations to access the OES NetWare file system using the same protocols they use internally to perform local file operations, such as copy, delete, move, save, and open. Windows workstations perform these tasks using the Common Internet File System (CIFS) protocol, Macintosh workstations use the AppleTalk Filing Protocol (AFP), and Unix/Linux computers use the Network File System (NFS) protocol. This not only eliminates the overhead of a special network client, but also enables users to perform network tasks using the same familiar tools that they use to work on their local drives.

Admin Workstation Requirements

To manage Native File Access, there must be at least one administrative workstation with the following characteristics:

  • Windows 9x running Novell client for Windows 9x version 3.21.0 or later or Windows XP/2000 Novell client for Windows XP/2000 version 4.80 or later.

  • NICI client version 1.5.7 or later—The NICI client is required to perform password administration using ConsoleOne.

NFA Client Requirements

To access NetWare servers running NFA, computers must be connected to the network and running one of the following operating systems:

  • Mac OS version 8.1 or later—Mac OS X.

  • Windows 9x, Windows NT v4, Windows XP/2000—Windows computers must be running Client for Microsoft Networks, which is a standard Windows networking component. It can be installed by choosing Add, Client from the Local Area Connection Properties page.

  • Any version of UNIX or Linux that supports NFS v2 or NFS v3.

Simple Password

Simple passwords are used to support the local Windows, Macintosh, and NFS password models, which in some cases don’t support password encryption. Thus, to prevent the eDirectory password from becoming compromised, Novell created a secondary password suitable for use in these nontraditional situations. To create a simple password for a user, complete the following steps:

  1. Launch iManager, open the eDirectory Administration link, and select Modify Object. For more information on iManager, see Chapter 4 "OES Management Tools."

  2. Click the View Objects button and browse to the object for which you want to change the Simple Password.

  3. Click the object and select Modify Object.

  4. Select the NMAS Login Methods tab and click the Simple Password link.

  5. Make the Simple Password modifications and click OK. You can create, change, or remove the simple password.

After it’s created, the simple password will be used by services such as Native File Access and LDAP authentication that cannot be integrated with the native eDirectory-based authentication option provided by OES NetWare. Simple passwords are required for these services to function, and removing the simple password may prevent them from using services that rely on it.

Configuring CIFS Access

With NFA installed and passwords configured, nothing else is necessary to enable Windows users to access the NetWare file system. They can use Windows Explorer to browse and search for files through Network Neighborhood or My Network Places. They can map network drives to their defined share point and assign it a drive letter. Because access to NetWare files is handled by CIFS, Windows users can copy, delete, move, save, and open network files as they can with any Windows-based drive resource.

You can stop and start the CIFS service on the OES NetWare server by typing CIFSSTOP at the server console or from a remote server connection. Similarly, typing CIFSSTRT starts the CIFS service on a given OES NetWare server.

Specifying Contexts in the Context Search File

A context search file enables Windows users to log in to the network without specifying their full context. The contexts listed in the context search file will be searched when no context is provided or the object cannot be found in the provided context. If user objects with the same name exist in different contexts, authentication to each user object will be attempted until one succeeds with the user-provided password.

The context search file is stored in the SYS:ETC directory of the NetWare server on which NFA is running. To modify a context search file, complete the following steps:

  1. Open the CTXS.CFG file with any text editor.

  2. Enter each context to be searched during authentication, with each context on its own line.

  3. Resave the file in the SYS:ETC directory.

  4. At the server console, enter CIFSSTOP and then CIFSSTRT to reload the CIFS service with the new context search file.

When restarted, NFA will be able to use the context search file entries you have provided.

Customizing the Network Environment for CIFS

You can use ConsoleOne to configure file access for CIFS users. For more information on ConsoleOne, see Chapter 4. Three CIFS configuration pages are available by completing the following steps:

  1. Launch ConsoleOne and browse to the appropriate OES NetWare server in the left pane.

  2. Right-click the Server object and select Properties.

  3. Click the CIFS tab and select one of the three CIFS available pages: Config, Attach, or Shares.

  4. Enter the parameters in the fields provided.

  5. Click OK to save your settings and exit.

The following parameter fields appear on the CIFS Config Page:

  • Server Name—Server Name enables you to specify a name, as it will appear in Network Neighborhood, for the CIFS server. It can be a maximum of 15 characters long and must be different from the actual NetWare server name.

  • Comment—Comment enables you to provide a description of the server resource for CIFS users that will be available when viewing resource details in Network Neighborhood.

  • WINS Address—WINS Address specifies the address of the WINS server that should be used to locate the Primary Domain Controller (PDC). This is necessary if the PDC is on a different IP subnet than the NetWare server running NFA.

  • Unicode—Unicode enables international character support.

  • OpLocks (Opportunistic Locking)—Oplocks improves file access performance using the CIFS protocol.

  • Authentication Mode—Authentication Mode specifies the authentication method used to authenticate CIFS users.

    • Domain—If the users are members of a Windows domain, you can have the Windows domain controller perform the authentication. In this instance, the domain and workstation username and password must match.

    • Local—If the users are members of a Windows workgroup, you can have the NFA server perform the authentication. In this instance, the NetWare and workstation username and password must match.

  • Authentication Workgroup NameAuthentication Workgroup Name specifies the name of the Windows domain, or workgroup, to which the NFA server will belong.

  • Primary Domain Controller Name—Primary Domain Controller Name specifies the name of the PDC server and is necessary only if the PDC is on a different subnet. This option will override WINS or DNS.

  • Primary Domain Controller Address—Primary Domain Controller Address specifies the static IP address of the PDC server and is necessary only if the PDC is on a different subnet. This option will override WINS or DNS.

The Attach page enables you to specify the IP addresses to which you want to bind the CIFS protocol. By default, CIFS will be bound to all IP addresses on the NetWare server on which NFA is running.

The Shares page enables you to specify volumes or directories as Windows share points that will be directly accessible from Network Neighborhood. If no share points are defined, all mounted volumes will be listed by default:

  • Name—Name specifies a name for the share point, as it will be seen in Network Neighborhood.

  • Path—Path specifies the full path to the share point. This will appear as the root, or starting point, for the share. The path must end with a backslash (\).

  • Comment—Comment enables you to provide a description of the share point for CIFS users that will be available when viewing resource details in Network Neighborhood.

  • Maximum Number of Connections—Maximum Number of Connections specifies the maximum number of simultaneous connections allowed to the share point.

Configuring AFP Access

With NFA installed and passwords configured, nothing else is necessary to allow Mac users to access the NetWare file system. They can use Chooser or the Go menu to access network files and even create aliases. Because access to NetWare files is handled by AFP, Mac users can copy, delete, move, save, and open network files as they can with any local drive resource.

You can stop and start the AFP service on the OES NetWare server by typing AFPSTOP at the server console or from a remote server connection. Similarly, typing AFPSTRT starts the AFP service on a given OES NetWare server.

Context Search Files

If the user object for Mac users is not in the same container as the server they are trying to access, a context search file enables them to log in to the network without specifying their full context. The contexts listed in the context search file will be searched when no context is provided or the object cannot be found in the provided context. This is important because the Mac allows 31 characters for the username. If the full eDirectory context and username is longer than this, you must use a search list so users can access the NetWare server.

If user objects with the same name exist in different contexts, the first one in the context search list will be used. For this reason, it is advisable to have globally unique usernames when using this type of service.

The context search file is stored in the SYS:ETC directory of the NetWare server on which NFA is running. To modify a context search file, complete the following steps:

  1. Open the CTXS.CFG file with any text editor.

  2. Enter each context to be searched during authentication, with each context on its own line.

  3. Resave the file in the SYS:ETC directory.

When restarted, NFA will be able to use the context search file entries you have provided.

Renaming Volumes

You can also rename NetWare volumes so that they appear with a different name in the Mac Chooser. To rename a volume for Mac users, complete the following steps:

  1. Create a file named AFPVOL.CFG in the SYS:ETC directory of the NetWare server on which NFA is running.

  2. For each volume you want to rename, enter the current name of the volume and, in quotes, the new Mac name of the volume. For example:

  3. prv-serv1.sys "SYS volume"
  4. Save the file.

Mac users will access the NetWare volume through the name you have specified, rather than the formal name syntax typically used to denote NetWare volumes.

Accessing Files from a Mac

Mac users use the Chooser to access files and directories as needed. They can also create an alias on the desktop that will be maintained after rebooting:

  1. In Mac OS 8 or 9, click the Apple menu and select Chooser, AppleTalk, Server IP Address. In Mac OS X, click Go, Connect to Server.

  2. Specify the IP address or DNS name of the NetWare server and click Connect.

  3. When prompted, specify a valid eDirectory username and password, and then click Connect.

  4. Select a volume to be mounted on the desktop. You now have access to the files on the specified volume. However, these settings are not saved after rebooting the Mac. If you want to create a perpetual link to the volume, you can create an alias.

When these steps are completed, Mac users will have access to files and directories on a NetWare volume.

Configuring NFS Access

Native NFS file access requires a few more steps before a Unix/Linux client can use it. There are several terms you should be familiar with if you have not worked with NFS previously and are implementing NFA for NFS:

  • NFS server—NFS server software is installed as part of the NFA installation. It enables NFS clients to access a NetWare file system as if it were a local directory on the Unix/Linux workstation. Any client that supports the NFS protocol can also access NetWare files using the NFS server.

  • File system export—Before Unix/Linux users can access the NetWare file system it must be made available to the NFS client. This process is called exporting the file system. During the export, you can define who should access the information and how it is accessed.

  • File system mount—After the NetWare file system has been exported, an NFS client can import it into its local file system. When imported, the specified portion of the NetWare file system will be available as though it were part of the local Unix/Linux file system.

  • Network Information Service (NIS)—NFA also permits a NetWare server to function as an NIS server. This is not required for native file access but is a useful additional service for Unix/Linux clients. NIS is a widely used "Yellow Pages" for the Unix/Linux environment. Similar to eDirectory, NIS servers act as central repositories for common information about users, groups, and hosts that reside on the network. With NIS server software loaded, eDirectory can function as a NIS repository and can respond to NIS requests from any NIS client.

NFA's NFS support is installed and started as part of the OES NetWare installation. You can stop and start the NFS service from the server console by typing NFSSTOP. Similarly, typing NFSSTART starts the NFS service on a given OES NetWare server. You can also stop and start the NFS server from iManager by clicking the NFS link under File Protocols. This will open the management page for the NFS server. For more information on iManager, see Chapter 4.

When NFA is installed, it extends the eDirectory schema to support new NFS objects. There are four new objects that you will see after installing NFA for NFS:

  • NFSAdmin—The NFSAdmin object is a group object installed at the eDirectory tree root that gives you access to the exported file structures that will be made available to NFS users.

  • NFAUUser—The NFAUUser object is installed in the server context and is used to provide a link between NetWare and the root user on a Unix/Linux client. This link is used internally for managing data flow between the two systems.

  • NFAUWorld—The NFAUWorld group object is installed in the server context and provides Unix rights to other Unix users when they access an exported NFS path. To do this, the effective rights of the NFAUWorld object are converted into Unix rwx rights. Restrict the effective rights of the NFAUWorld object to prevent these NFS users from getting too much access to the NetWare file system.

  • NISSERV_<servername>—The NIS server object is installed in the server context for those who might want to use Novell eDirectory as an NIS data repository. It is not used for NFS file access. For more information on NIS services, see the NetWare online documentation.

To export part of the OES NetWare file system for use by NFS clients, complete the following steps:

  1. Launch iManager and log in as a user with administrative rights. iManager provides a gadget for managing NFS connections. For more information on iManager, see Chapter 4.

  2. In the left pane, expand the File Protocols link and select NFS.

  3. Specify, or browse to, the server running NFS services. Click the Export button to open the Export Options screen (see Figure 3.11).

  4. In the Path field, enter the path to be exported. Use forward slashes (/) to separate directories. For example, to export the DATA: volume, you enter /data.

  5. In the Access Control field, specify either Independent or NetWare mode. Independent mode means that NetWare and NFS rights will be managed separately. NetWare mode means that rights will be managed from NetWare and mapped to NFS accordingly. For more information on access control modes, see the OES online documentation.

  6. Use Global Permissions to specify those permissions that will be granted to all trusted hostnames.

  7. Figure 3.11 Creating an NFS export from iManager.

  8. In the Trusted Host and Access Permission table, specify the NFS host that you want to make a trusted host for the exported path. Then specify the rights granted to the export host:

    • Deny—Deny prevents access to the host.

    • RO(Default) RO grants read-only access to the host.

    • RW—RW grants read-write access to the host.

    • Root—Root grants root, or supervisory, access to the host.

    • Anonymous—Anonymous grants generic access to the exported directory through the Unix user NOBODY and group NOGROUP.

  9. Click the plus symbol (+) next to the hostname to add the host to the trusted host list. This updates the etc/exports file on the server and refreshes the NFS server. When you specify access permissions, the default permissions given in the All row are unchecked.

After it’s created, the newly exported directory will show up in the Exported Paths list on the NFS Server Administration screen. By selecting an exported path from the Exported Paths list, you can see the current path configuration and modify that configuration by clicking Edit.

Mounting an Exported Directory

After an OES NetWare directory has been exported for NFS clients, it is imported into a remote file system for access. Unix systems use the mount command to accomplish this. To mount an exported directory on a Unix/Linux system, complete the following steps:

  1. Use the mkdir command to create a directory that will hold the OES NetWare NFS export—for example: mkdir NWOESFiles.

  2. Use the mount command to link the new directory to the OES NetWare export—for example: mount <server identifier>:/data/linux /NWOESFiles.

For more information on the Unix/Linux mount command, refer to your system’s man pages.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus