Novell Open Enterprise Server 11 (OES 11) Linux
DISCLAIMER: This document discusses a condition which is not fully understood by the author. It is offered because it can help resolve a problem, even without full understanding of all the factors involved. Apologies are offered for vagueness or lack of clarity which might be present.
Novell FTP (pure-ftpd which has been expanded with additional features for Novell OES servers) contains a feature known as "remote server" which allows an FTP session to CD to (or otherwise specify) paths which exist on other servers in the tree. These paths specify NCP servers and volumes are typically referenced with syntax in the form //serverName/volumeName/directoryPath. Novell FTP will interpret that path and then will use the Novell NCP Client For Linux to do an NCP login to the specified server, map to the volume in question, and give the FTP session access to that location, according to the Novell trustee rights of the user.
Sometimes such attempts (to reach a remote server) fail, with the FTP server giving the error:
550 Can't change directory to //serverName: No such file or directory
There can be various causes for such failures, but this TID is not intended to cover all possibilities. It only covers one possible cause -- confusion about the server name.
A host on a IP network can be known by different names. There can be one host name known in the local /etc/hosts file. There could be another name in a DNS database. There could be additional aliases in both those locations. Additionally, the name by which a NCP server is known in eDirectory could be different as well.
The author of this TID does not have full knowledge of all the procedures which Novell FTP (or other code) may use to take the name specified and turn it into a valid login and volume mapping. So he cannot say what situations involving multiple names might always work or always fail. But he has witnesses various failures due to naming confusion and therefore gives the following recommendations:
1. It is best if the server name as known to eDirectory be the same as the server name as known to the DNS database or in local /etc/hosts files. If all sources are in agreement, then naming confusion will probably not occur.
2. If there are extra names by which a hosts is known - -for example, if DNS contains an A record or CNAME with a different name than what is known in eDirectory, or if the local /etc/hosts file contains an different or unexpected name for a remotes server -- then naming confusion could result. It may not always be possible to reach the remote NCP server by using one of these different names. For example, consider a server which has NCP server name "NameABC", for which the domain's DNS has an entry "NameXYZ". Novell FTP may be able to reach that server as //NameABC but may fail to reach is at //NameXYZ, even though it can be proved than the server hosting Novell FTP can resolve both names to an IP address. Case should be taken, however, not to assume that there is a hard-and-fast rule stating that any and all names which do not match the eDirectory name would fail.
3. In most cases, substituting the desired IP address (i.e. //10.1.1.2/vol/path) is expected to work, but that might even fail in some cases. One case (not fully investigated to a solid conclusion) involving clustering, virtual IP addresses, and extra aliases / CNAMES, has been seen to lead to enough naming confusion that even submitting an IP address failed. It may have been a question of cluster node address vs virtual resource address.
4. People facing this type of issue may want to try (in a command-line FTP session) CDing to a server by the various different names and/or IP addresses which are assigned to the system in question, and see which ones work and which ones fail. If they all fail, naming confusion may not be involved. If only some fail, naming confusion is likely.
5. It may help resolve naming confusion to add an entry to the /etc/hosts file of the server where pure-ftpd itself is running. For example, if accessing a remote server by "Name1" is failing, then adding an entry for Name1 to /etc/hosts could correct the failure. However, this may not always be the case. It has been seen in tests of various environments, that adding a new entry to /etc/hosts, for some new (previously unused) name, sometimes did but sometimes did not allow the remote server to be accessed by that new name.
5. Overall, if a remote server can be reached by some names and not others, then the best recommendation is that the NCP server name should match a hosts entry in the FTP server's local /etc/hosts file, and FTP sessions should use that same name to reference the remote server.