Many legacy Novell NetWare customers are familiar with the built-in NetWare FTP and it’s ability to be configured such that as users log in, they can:

  1. Be placed into their user directory (whether local or remote).
  2. Change directories to that of another local or remote server (as long as rights were granted).

The reason this worked so flawlessly was due to Novell NetWare’s built-in NCP client which created the remote connections for these user directories and remote servers.

In Linux, however, this functionality is not available. Well, almost.

The purpose of this document is to outline the combination of existing technologies within linux to provide this same basic functionality. This is meant as a proof-of-concept and example, rather than a cookie-cutter drop-in to any specific environment.

This same configuration can also be used for other remote-access services, such as SSH.


Diagram 1

Click to view.

Diagram 1 shows the setup used for this scenario. There are five machines being used:

  1. FTPSERVER – A server-class machine running SuSE Linux Enterprise Server 10 (SLES10).
  2. OESLX – A server-class machine running Novell Open Enterprise Server (linux) with Support Pack 2 applied.
  3. OESNW – A server-class machine running Novell Open Enterprise Server (NetWare) with Support Pack 6 applied.
  4. RHEL4U4 – A server-class machine running RedHat Enterprise Linux ES Version 4 with Update 4 applied.
  5. SLED10 – A workstation-class machine running SuSE Linux Enterprise Desktop 10 (SLED10).

The solid lines in the diagram represent the file exchange protocols being used between the various machines. All file exchange traffic is considered bidirectional, implying two-way communication for both file reads and writes. The dashed lines represent the protocols over which authentication and/or file ownership mapping takes place. The OES servers’ eDirectory is the central and only identity store used.

Servers OESLX, OESNW, and RHEL4U4 are exporting their users’ home directories via NFS.

Both servers OESLX and OESNW have the replicated eDirectory database and answer FTPSERVER’s queries for user authentication and information via LDAP. RHEL4U4 is also querying these two servers via LDAP. For the purposes of this example, six users have been created in eDirectory. They are:


All users have been LUM enabled in eDirectory upon creation so they have the appropriate Unix Profile attributes: UID, GID, and home directory.

The eDirectory tree used, for reasons of simplicity, is flat in structure. It contains a single organization (O=novell) where the OES servers and all user objects reside.

Please note that the network infrastructure used to connect the machines is not shown and should be irrelevant as long as all the involved protocols can pass freely between the machines. In this test scenario, only the four servers were on the same IP subnet. For security purposes, the FTPSERVER is the only device attached to both the ‘private’ server subnet and the ‘public’ workstation subnet. In this manner, the FTPSERVER can be appropriately secured via firewall ACL rules and/or application profiling. The introduction of routers, firewalls, etc. into the network infrastructure may necessitate individual adaptation to allow this setup to function. As NFS is particular about host name resolution, DNS has been configured and is running on the FTPSERVER.

Conventions Used in This Document

%word_or_phrase – This syntax is used when the information required is variable. The percent sign (%) and the word or phrase that follow should be replaced with an actual value. The word or phrase shown will describe the value needed.

command — Command strings are italicized.


  1. The three servers, OESLX, OESNW, and RHEL4U4 are installed and functional.
  2. An NFS export of the users’ home directories is created on each server using their native NFS utilities. This export should be specifically allowed Read-Write access to the FTPSERVER.
  3. All users are LUM-enabled. Only default system users (root, etc.,) exist on FTPSERVER and RHEL4U4.
  4. Novell Open Enterprise Server group(s) exists and is/are LUM enabled.
  5. All servers need to be able to resolve host names either through hosts files or DNS.
  6. The OpenLDAP client should be installed on the FTPSERVER
  7. Your favorite FTP server daemon should be installed and functional on the FTPSERVER.
  8. The automount daemon is installed and configured to start upon boot on the FTPSERVER.

Installation and Configuration Steps Used to Utilize SuSE Linux Enterprise Server as an FTP Gateway

Note: There are optional concerns that may be very important to some environments. Please be sure to read the Operational Considerations section before implementation.

The first step in configuring SLES as an FTP gateway is to configure and verify LDAP functionality on the FTPSERVER. If pam_ldap and nss_ldap packages are not already installed, install them. Configuring LDAP is quite simple if using the YaST2 LDAP widget (diagram 2). The address(es) of the LDAP server(s) and base DN are required for the basic configuration.

Diagram 2

Click to view.

However, the YaST2 widget doesn’t make all of the changes needed for full functionality. Additional changes outlined in Novell Technical Information Document #3000394 are required, particularly the binddn and bindpw parameters. Please refer to the Specific Examples section below for details.

For simplicity, it is suggested that TLS not be required for simple binds with password. This can either be turned off in iManager | LDAP | LDAP Options, or on linux specified on the command line as ‘ldapconfig -s “Require TLS for Simple Binds with Password:no”‘ (case sensitive).

Once LDAP is configured, a nifty test is completed by running the following command(s): ‘ldapsearch -D cn=%user,o=%org -w %password -b o=%basecontext -x cn=%ldapusername’ then ‘id %ldapusername’.

The next step is to configure pam for the FTP daemon. The installation of your favorite FTP daemon should have created a configuration file in /etc/pam.d/. This file should be modified to include additional account, password, and session types. Please refer to the Specific Examples section for details. Novell CoolSolution #14511 is also a great resource for additional information, should the need arise.

Finally, the automount daemon needs to be configured to mount both the user’s home directories as well as the /net subdirectory. Maybe a little explanation would be warranted? From the man pages for automount, “The automount program is used to configure a mount point for autofs, the inlined Linux automounter. automount works by taking a base mount-point and map file, and using these (combined with other options) to automatically mount filesystems within the base mount-point when they are accessed in any way. The filesystems are then autounmounted after a period of inactivity.”

To configure the automounter, the /etc/auto.master file should be edited and the /net line uncommented. An additional line for /home should also be added. With the autofs4 package, the /etc/ script is built and ready to use without modifications. The /etc/auto.home file should be created manually. This file is probably the one which will require most of the specific configuration based on your environment. For simplicity in our example, we’ve created a flat file with each user’s home server and directory. However, because this can be built with quite a bit of logic, much of it can be scripted to pull this information from LDAP. I.e., if a Default Server is specified in eDir, this is an attribute which can be queried for in LDAP and therefore could be built into the logic. Again, for guidance, please refer to the Specific Examples section as well as the autofs man pages.

Additionally, in our example, we’ve used a RedHat Enterprise Linux ES 4 server as data space. The configuration of this server is a combination of the LDAP configuration as specified above for FTPSERVER and the NFS export. The LDAP configuration can be done through the native system-config-authentication, or by simply copying the /etc/ldap.conf from FTPSERVER. The NFS configuration can be done through the native system-config-nfs.

Operational Considerations

Although fairly simple, the configuration of SuSE Linux Enterprise Server as an FTP Gateway does include some operational considerations.

  • If exporting NSS volumes from OESLX, these exports require the no_root_squash and fsid=%randomfrom1-254 parameters. Furthermore, at the writing of this document, NSS and NFS do have known interoperability issues. Engineering is working on these issues, and are expected to be resolved soon.
  • When accessed through NFS, exports from OESNW might not show appropriate ownership initially. This depends on whether the NetWare owners of the directories were set appropriately before the file system was exported, and whether the NetWare user-owner already had a Unix Profile at that time. This will be especially important for user home directories. If appropriate ownership is not set, it will be handy to chown (from an NFS client with root user access) the directories to %username:%lumgroup. This ownership can also be set from the NetWare side, in the NFS attributes accessed through NetStorage. In fact, if the NetWare NFS export is configured to use NetWare mode instead of the default Independent mode, NetStorage will have to be used to make this kind of change, as chown from an NFS client is disallowed in NetWare mode.

Specific Examples

The following are examples which may be used as guidance in configuring the various services required for this proof-of-concept.

The important bits from /etc/ldap.conf on FTPSERVER:

host oeslx oesnw
base o=users
ldap_version 3
binddn cn=ldapuser,o=users
bindpw novell
port 389
pam_password nds
ssl no (start_tls also works)
nss_map_attribute uniqueMember member
pam_filter objectclass=posixAccount
nss_base_passwd o=users
nss_base_shadow o=users
nss_base_group o=users

/etc/pam.d/pure-ftpd on FTPSERVER (additions are italicized):

auth       required item=user sense=deny file=/etc/ftpusers onerr=succeed
auth       sufficient
auth       include      common-auth
auth       required
account    sufficient
account    include      common-account
password   include      common-password
session    optional

/etc/auto.master on FTPSERVER (modifications are italicized):

# $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/smb   /etc/auto.smb
#/misc  /etc/auto.misc
/net    /etc/
/home   /etc/auto.home

/etc/auto.home on FTPSERVER:

oeslxuser1      -fstype=nfs,rw,nosuid,soft      oeslx:/home/&
oeslxuser2      -fstype=nfs,rw,nosuid,soft      oeslx:/home/&
oesnwuser1      -fstype=nfs,rw,nosuid,soft      oesnw:/home/&
oesnwuser2      -fstype=nfs,rw,nosuid,soft      oesnw:/home/&
rheluser1       -fstype=nfs,rw,nosuid,soft      rhel4u4:/home/&
rheluser2       -fstype=nfs,rw,nosuid,soft      rhel4u4:/home/& 

Additional Information

Although the information provided therein is basic and meant as guidance, you can find additional autofs information at the following links:

(Visited 1 times, 1 visits today)

Category: Uncategorized
This entry was posted Thursday, 5 April, 2007 at 3:53 pm
You can follow any responses to this entry via RSS.

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet