Basic troubleshooting and common issues if a user cannot login to OES FTP

The document is intended to be a list of troubleshooting steps and common issues to investigate when a user cannot login to OES FTP.  It is not intended to explain in full detail every concept it brings up.  A reasonable background in OES, eDirectory, and LUM (Linux User Management) is assumed.  See OES online documentation for additional help with these other topics, if needed.

 

OES FTP uses a pure-ftpd package that has been enhanced with extra features and custom configuration, to authenticate eDirectory users.  Therefore, most of this information will not apply to a "plain" SLES pure-ftpd package.

1.  Make sure the proper version of pure-ftpd is in use.  To quickly see which pure-ftpd package is installed, it is best to use this particular syntax:

 

rpm -qa | grep pure-ftpd

 

On OES 11 SP1 or newer, the package should be called "novell-oes-pure-ftpd".  If it appears as merely "pure-ftpd" then this is the basic package from the SLES repository, not the OES enhanced package from the OES repository.

 

On OES 11 SP0 or older (including OES 2, OES 1) the package for OES FTP actually comes from the underlying SLES installation, and will merely be called "pure-ftpd".  This can lead to problems if a non-SLES repository has been added to the machine's configuration.  For example, if an openSUSE repository has been added and then a general update is run on the system, it is possible to end up with pure-ftpd package which is much newer, but has not been enhanced for OES.  On those older OES versions, the pure-ftpd package should never report a major version higher than 1.0.22-x.  You can also use Yast2 (the GUI tool) Software --> Software Management --> Search (on pure-ftpd) to examine the different versions (see "Versions" tab) of pure-ftpd that your systems sees available, to check which repositories they are from, and make sure the installed version is from the right repository.

 

2.  Make sure pure-ftpd has been started with it's correct init script.  This can be done with "rcpure-ftpd restart".  If someone has executed the binary directly with a "pure-ftpd" command, then this would execute the binary directly (found at /usr/sbin/pure-ftpd), which (oddly enough) causes it to skip all it's configuration, and it will not be using pam (and therefore it will not be capable of logging into eDirectory).  The proper init script insures that the config file gets read and used when executing pure-ftpd.  Without that, the chances of working correctly are virtually 0.

 

3.  Is the user in question present in eDirectory?  OES FTP supplies a customized /etc/pam.d/pure-ftpd which is configured to authenticate users against eDirectory only.  Local user accounts will not be able to login.

 

4.  If a username is present both in eDirectory and in /etc/passwd (or other repository), this might cause login failures or other problems.  It can be helpful to check the output of "getent passwd | grep <username>" (where you replace <username> with the actual edir user name) for more than one entry for the username.

 

5.  The eDirectory user account must be "LUM Enabled".  This can be accomplished in iManager.  The OES machine where OES FTP runs should be one of the workstations the LUM-enabled user is associated with.

 

6.  If the eDirectory user has recently been modified, the NAM (Novell Account Management) cache may need to be flushed so the new information can be learned.  This can be accomplished with:   namconfig cache_refresh

 

7.  Normally, during install of OES, various services can be enabled for LUM.  If OES is having trouble authenticating eDirectory users, this process may need to be redone.  Steps:

 

a.  Run yast2, select Open Enterprise Server --> OES Install and Configuration

b.  Scroll through the patterns.  Highlight "Novell Linux User Management".  Its box should already be checked, but if not, go ahead and check it.  Then click "Accept".

c.  The "Novell Open Enterprise Server Configuration" list will come up.  Wait a minute or two for it to fully load and for it to populate whether each service shows "reconfigure is disabled".

d.  Under "Linux User Management" click the word "disabled.  The list will rebuild and that service should now say, "Reconfigure is Enabled."  Then click the heading "Linux User Management."

e.  Login as the Admin user, as prompted.

f.  The "Linux User Management Configuration" screen will appear.  Normally the first 4 settings are already populated.  The rest are optional for our purposes.  Click "Next".

g.  A list of services which can be LUM-enabled appears.  Make sure "ftp" and "su" are selected.  (NOTE:  Technically, su does not have to be LUM-enabled for OES FTP.  However, it is very useful to help troubleshoot authentication problems, and will be needed for a later test in this document.)  Click "Next".

h.  The system will do some work and then return to the earlier configuration screen.  Click "Next".

i.  The system will do further work for "Saving Linux User Management Configuration."  This could take a few minutes.

j.  The "Installation Completed" screen will appear.  Click "Finish".

 

8.  Based on step 7, FTP and su should both be LUM-enabled.  Test FTP again.  If login still fails, do the following for comparison:

 

a.  id <username>

where <username> is replaced with the user name in question.

This should successfully retrieve the user information.  The UID and GID should match what is configured in the user's "Linux Profile" tab in eDirectory.  If this step fails, then something deeper is not working (maybe with LUM or specifically with that user)and that issue must be fixed before FTP can be expected to successfully use LUM.  Or if wrong information is retrieved, see items 4, 5, and 6 above.

 

b.  This step can only be expected to work if "su" has been LUM-enabled, as discussed in #7 above.

As a non-root user, give the command:  su <username>

where <username> is replaced with the user name in question.

As long as you are *not* root when you execute this, it should prompt you for a password.  Once you enter the correct password, it should successfully switch to that user. (Check with "id" before and after.)  If you cannot successfully password-authenticate with "su", then the login problem is likely not in FTP, but in something deeper.  (Broken account, wrong password, LUM or eDirectory failure, pam problems, etc.)

 

9.  Check /etc/pure-ftpd/pure-ftpd.conf.  Make sure "AnonymousOnly no" is set.  If set to "yes", regular users will not be able to login properly (but could even be forced in as anonymous regardless of which username was supplied).

 

10.  Check the contents of /etc/pam.d/pure-ftpd.  This file governs how pam will accomplish the authentication.  For OES FTP, it should look like this:

 

 

11.  Per a standard pam configuration for most FTP servers, a user must have a valid shell for pam to approve it.  (This is checked by the "pam_shells" module listed in #10.)  Check your user within "getent passwd" and verify it has a valid shell there.  It's usually the last item on the passwd line.

 

12.  The user's numeric UID must be greater than or equal to the "MinUID" set in /etc/pure-ftpd/pure-ftpd.conf.

 

13.  The username must *not* be present in /etc/ftpusers.   (This is checked by the pam_listfile module in #10.)

 

14.  If /etc/pure-ftpd/pure-ftpd.conf has set "remote_server  yes", then there are actually two (2) authentications happening for an FTP login.  First, a normal Linux login is done through pam -- so it may include a LUM/eDir login, depending on the pam configuration.  Once that succeeds, a nwlogin is done.  This is the NCP client login.  The NCP client is used by the remote_server feature.  To test whether it is nwlogin that is failing (rather than the normal Linux login), set "remote_server  no" and restart ftp (rcpure-ftpd restart).  If login works in this condition, then the nwlogin portion is the likely culprit.

 

15.  If the remote_server feature is needed, but item #13 indicates nwlogin is the likely culprit, it may be informative to manually attempt a nwlogin to see if it returns errors.  The best approach to this is:

 

a.  Look at a failed ftp login attempt in /var/log/messages.  If the process got far enough to try a nwlogin, there should be a log message like this:

 

   i.  su to the user in question.

   ii.  execute the nwlogin as identified in the log message, taking care to replace the "PWD" with the actual password of the user.  Also, do *not* include the <UID: 601> tag.  It is not part of the command.

 

If nwlogin fails, this must be resolved before FTP can use the remote_server feature for that user.

 

16.  If  'remote_server yes' is being used, then the SSL certificate for the OES LDAP Server must be valid.  Usually this will be the "ssl certificate dns" of the ldap server object, for the server where novell-oes-pure-ftpd is running.  But in rare cases, the OES LDAP server might be a separate machine.  To check what LDAP server is being used by the OES FTP server, go to a command line on the OES FTP machine and give the command: