OES pure-ftpd logins or file system actions fail if setting: EnableRemoteHomeDirectory yes

  • 7017161
  • 15-Jan-2016
  • 04-Jan-2017

Environment

Novell Open Enterprise Server 11 (OES 11) Linux
Novell Open Enterprise Server 2015 (OES 2015) Linux

Situation

OES FTP (novell-oes-pure-ftpd) has been installed.  In /etc/pure-ftpd/pure-ftpd.conf, the "remote_server" feature is turned on (set to "yes") to allow sessions to reach other NCP servers / volumes in the tree.
 
All features and functions are working except for:
EnableRemoteHomeDirectory  yes
 
Without that setting, users can login, and can even CD to remote servers and paths, including to their NCP home directories.  However, with that setting enabled, their FTP session either ends immediately after entering a password, or they get to a different home directory (the general pure-ftpd default home directory, or their personal posix home directory, instead of their personal NCP home).

The user's environment in eDirectory is verified to have a valid NCP home directory server_volume and path set, and that server and volume are up and operating correctly.

Errors seen *might* include:

At a command-line FTP client, some users reported seeing:
Connection closed by remote host.
 
In /var/log/message at the FTP server machine:
 
Either no message indicating failure at all or

[ERROR] Failed to perform LDAP search to get the list of remote servers accessible. Error: Can't contact LDAP server <-1>
 
In an unconfirmed variation of this case, it was reported that login succeeded but subsequent file system actions on a Novell NSS volume returned the error:
[ERROR] Can't open that file: Operation not permitted 
 
 

Resolution

The EnableRemoteHomeDirectory feature (which allows users to start their FTP sessions in their NCP home directory, even if it is on a different server) makes direct use of LDAP in a way that no other features in OES FTP do. So if the problem only occurs with that setting, the problem usually lies in one of two things:

1. Determining the LDAP server to query. The command used by pure-ftpd to learn which LDAP server to query is:

/opt/novell/eDirectory/bin/ndsconfig get n4u.server.interfaces | grep n4u.server.interfaces | sed s/[a-zA-Z0-9.]*=//g | sed s/@[a-zA-Z0-9,.]*//g

Test the above command manually. It should return just an IP address. Usually, it is an IP address bound to the local machine. Without all the piping to grep and sed, it will return extra detail, but would still be informative to human eyes. The rest is to strip it down to just the IP address.

If it does not return an IP address (or returns an incorrect address), then something is wrong with the nds configuration, and EnableRemoteHomeDirectory will not work until that is corrected. Normally, the value in question is stored in /etc/opt/novell/eDirectory/conf/nds.conf, as part of the setting:

n4u.server.interfaces=10.1.2.3@524

Correct the IP address in that setting and perform: server ndsd restart

NOTE:  Another customer has reported that for some functions of OES FTP, they also had to insure that the correct IP address was included in these two interface settings:

http.server.interfaces=10.1.2.3@8028
https.server.interfaces=10.1.2.3@8030

2. If an IP address is returned by the command in #1, and it is a valid IP address for a LDAP server, then possibly something is wrong with the LDAP server itself, or with the ability to form secure (SSL) connections to it. At a shell on OES Server itself (where the FTP service resides), it may be helpful to use "ldapsearch" (see "man ldapsearch") to send queries to that IP address. Pure-ftpd will use secure ldap for this query, so in troubleshooting it may be beneficial to try it both ways (sldap and ldap). If only secure ldap fails, then this might be a ssl certificate issue. If these secure ldap queries about users cannot be made, then "EnableRemoteHomeDirectory" will not work for that user.

Additional Information

In a normal, fresh install of OES, all the interface settings discussed above are normally already set with correct IP addresses.  The cases discussed here have been when migrations have been performed, for example from NetWare (or older OES) to newer OES.