Environment
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 2
Novell Open Enterprise Server 2 (OES 2) Linux Support Pack 3
Situation
An OES 2 SP2 or SP3 machine is running LUM-enabled pure-ftpd. Login attempts through pure-ftpd are failing. Alternatively, login may be succeeding but odd failures begin to occur later.
While there can be many reasons an authentication might fail, for the issue specifically being described in this document some unique symptoms will be present:
- When an command-line FTP client fails to login, it may show a message indicating that the service is unavailable or that the session has been disconnected, rather than seeing a typical "authentication failed" message.
- On the FTP server host, the /var/log/messages file may show a messages logged by pure-ftpd which indicates that a "general protection RIP" or a "segmentation" fault or RIP occurred.
If the problem does not fit these unique symptoms, then this document is probably not applicable. Instead, see KB 3503915.
Resolution
Updates are available which should correct this issue. If the OS is updated to SLES 10 SP4, and then OES 2 SP3 has current maintenance applied (as of late 2012), then this issue will usually be solved. However, depending on the order these updates were applied, there could be more to do. [Also, if SLES 10 SP3 is still in use, and moving to SP4 is not an immediate option, see the "Additional Information" section for more options and background information.]
If the system is already updated (both SLES 10 SP4 and OES 2 SP3 current maintenance) but the problem still occurs, then it may be necessary to execute this script:
/opt/novell/pure-ftpd/novell-pure-ftpd-config.sh
Then restart pure-ftpd with:
rcpure-ftpd restart
If the problem still persists, see the Additional Information section for further clues and options.
Additional Information
If the resolution section above does not solve the problem, or if SLES 10 SP3 must remain in place, the following information may be helpful in troubleshooting / solving this issue.
In many cases this problem occurs if the OpenLDAP client has been enabled, and is having a conflict with Novell's LDAP libraries in NAM (Novell Account Management). There have been cases, however, even without OpenLDAP, where pure-ftpd was experiencing the same type of general protection RIP.
As such, there is more than one way to attempt to resolve this problem. It is strongly recommended to read through this entire section before choosing which way to proceed. Solution #1 is no longer the favored solution, and may not solve this is all cases. However, it may allow some administrators to correct this problem without having to apply any updates or PTFs. Hence it is still offerred here.
Solution #1:
This method involves disabling the OpenLDAP client, then re-running the LUM configuration. A reboot is also required. This corrects most situations, but as noted above, in at least one case is was not enough to prevent the general protection RIP.
NOTE for Clusters where the FTP service is cluster enabled: This procedure may need to be performed on multiple or all cluster nodes, depending on how many nodes experience this problem.
1. In Yast, Network Services, LDAP Client, make sure to set "Don't use LDAP." If this is a change, click "Finish". If is it already set this way, 'abort' or 'cancel'.
2. In Yast, on the left side select "Open Enterprise Server", then on the right click "OES Install and Configuration". Under "OES Services" click to highlight "Novell Linux User Management (LUM)". Don't change it's check mark to another symbol, just highlight that line. Click "Accept".
3. Wait for the list of various services to populate and display the reconfigure status. This will likely take around 20 seconds. Then under "Linux User Management" click on the word "disabled" in "Reconfigure is disabled". That will change to "enabled".
4. Now click on "Linux User Management" (the heading). Enter the admin password when prompted (and click OK). This brings up the first LUM configuration screen. Typically nothing here needs to be changed. Normally at least the first 3 lines are populated. In some cases, the second the third lines are not configured, so it's recommended in those cases to enter:
a. the "Unix Config Context." This is the location of the "Unix Config" object in eDirectory. There is typically only 1 per tree, and it is usually in the same context as the admin user.
b. the "Unix Workstation Context. This is the location of the Unix Workstation object for this particular OES Server, and is usually in the same context as the normal NCP server object of this machine.
Then click NEXT.
5. Now a LUM configuration screen will come up which shows which services to LUM-enable. Sometimes nothing needs to be changed here. However, at a minimum the "ftp" box should be checked. If there are other services shown which need to be able to authenticate against eDirectory, check those boxes as well. Click NEXT.
6. This returns to the Novell OES configuration screen. Click NEXT. This will rewrite LUM configuration settings. Once it says "Installation Completed" click FINISH. A screen may come up for "Novell Customer Center Configuration" at this point. Click "Configure Later", and then "NEXT".
7. Close Yast.
8. Reboot the machine.
Solution #2
This method involves removing some preload configuration of pure-ftpd (which is responsible for the problem), and applying a PTF (patched) pam package in order to compensate for the configuration which has been removed. The PTF is for SLES 10 SP3, and is not expected to be become part of public maintenance until SLES 10 SP4.
A. Edit /etc/init.d/pure-ftpd and add a "#" to comment out the line at or near the top, i.e.:
#export LD_PRELOAD=/opt/novell/eDirectory/lib64/libldapsdk.so
NOTE: On a system with cluster-enabled FTP, this script may not actually be in charge of starting pure-ftpd. Check the cluster resource start script in order to identify which method is in use. In some cases, /usr/sbin/pure-config.pl is starting pure-ftpd, so that would be the script to modify. In that case, five lines forming an "if - elseif" sequence take care of preloading the library in question, so those should be made into comments.
B. This step should be performed only if SLES 10 SP4 is not present on the system. If SLES 10 SP3 is still in use:
Download the pam PTF for your system.
For x86 (32 bit), go to:
and download
pam-0.99.6.3-28.18.39.1301.2.PTF.574018.i586.rpm
For x86_64 architecture, go to:
and download
pam-0.99.6.3-28.18.39.1301.2.PTF.574018.x86_64.rpm
and also go to:
and download
pam-32bit-0.99.6.3-28.18.39.1301.2.PTF.574018.x86_64.rpm
Update to these new package(s) with:
rpm -Uhv <package_name>
NOTE: There is also the possibility that SLES 10 SP3 online updates has already put a slightly *newer* version of pam in place which does not have the fix present in this PTF. So it may be necessary to force this lower version in place with:
rpm -Uhv --force <package_name>
C. Restart pure-ftpd. On a stand-alone system, this is typically done with : rcpure-ftpd restart
On a cluster where FTP is cluster-enabled, check the cluster stop and start script for the stop and start methods which has been established. Or just offline and online the cluster resource which unloads / loads pure-ftpd.
NOTE: Under some conditions involving certain older packages being installed or reinstalled, this problem could come back after it is already solved. If that occurs, repeat items A and B. Also consider moving to SLES 10 SP4 and then the latest OES 2 SP3 online updates, in order to eliminate this risk.