ftpd connection aborts by server

[Ralph Grothe]

Hi network wizards,

I set up a special ftp account with chroot() bound to a certain filesystem.

This works all as desired for up and downloads to/from chroot's /pub.

The problem is, this seems to work only favourable for me (or someone else) while establishing an ftp session from within our LAN or MAN.
When our client, for whom the ftp account was meant, makes connections by notebook over GPRS mobile phone via GPRS backbone into MAN (IPSec tunneled) through several relays/firewalls he only can establish data transfers occasionally.
Often he receives a "connection closed by remote host" message when issuing a DIR, GET, PUT.
Sometimes though it works at extremely low transfer rates (<= 2 Kbps).

From the involved relaying over so many hops with the amount of "wrapping" etc. I would blame the connection for the poor performance.

On the other hand the client claims (as always) it's the server side (the only part over which I can have some influence).

What further deteriorates things is that there is a very heavy load on the server's machine which serves ftpd through inetd.
So one could maybe also suspect that inetd has too many tcp servers to spawn for too many client requests.

There are (I would say) too many servers spawned by inetd.
I guess it was easier for the programmers who wrote the DBMS client software to have their servers started by inetd rather than bullet proofing stand alone servers.
I cannot even say wether these are forking, threading, or multiplexing, blocking or non-blocking servers, because they never have provided us (the Unix admins) with information of what has been installed.

When I parse inetd.conf for tcp services I get this, of which over 90% are servers of their DBMS:

$ perl -ane '$s++ if (/^[^#]/ && !/^\s+$/ && $F[2] eq "tcp");END{printf "%4u tcp services\n",$s}' /etc/inetd.conf

Always when an ftpd connection gets broken the daemon writes these strange lines into syslog.log:

# grep _module /var/adm/syslog/syslog.log|tail -2
Jan 24 15:13:48 saturn ftpd[20642]: open_module: stat(/usr/lib/security/libpam_u
nix.1) failed: No such file or directory
Jan 24 15:13:48 saturn ftpd[20642]: load_modules: can not open module /usr/lib/s
ecurity/libpam_unix.1

The stat() syscall is wrong since the "pluggable auth. module" file mentioned exists.
(btw are perms for others too lenient, should it really be world readable?)
I never deliberately tampered with any PAM stuff :-{

# ll /usr/lib/security/libpam_unix.1
-r-xr-xr-x 1 root sys 184320 May 14 1998 /usr/lib/security/libp
am_unix.1

Regards
Ralph

[Ralph Grothe]

Sorry for the horrible Perl line.
Actually it has been a copy and paste misshap.
This was what I meant to post :

129 tcp services

Things get too cluttered in the tiny texarea field ;-)

ITRC maintainers, where is the possibility for interspersed markup (e.g.

 tags)?

[James Drenter]

This error messages about the PAM module not being found are actually correct. The problem is caused by the ftpd doing a "chroot" to the user's home directory. Apparently, PAM in HP-UX 11i (I don't know about 11.00) doesn't maintain its internal link with the module library (libpam_unix.1) between calls. So after the account is set up and chroot'd, the PAM calls to release to credentials and close the session fail.

I should mention that although I work for HP, I have nothing to do with FTP or support. But you should be able to test this easily enough by creating the directory structure (usr/lib/security) in the user's account and copying the libpam_unix.1 library there. The error messages should stop for that user.

There really is no other viable work-around, short of a fix to PAM itself that would maintain module opens between calls (at least optionally).