<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: ftpd connection aborts by server in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652068#M587995</link>
    <description>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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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).</description>
    <pubDate>Wed, 01 May 2002 20:38:04 GMT</pubDate>
    <dc:creator>James Drenter</dc:creator>
    <dc:date>2002-05-01T20:38:04Z</dc:date>
    <item>
      <title>ftpd connection aborts by server</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652066#M587993</link>
      <description>Hi network wizards,&lt;BR /&gt;&lt;BR /&gt;I set up a special ftp account with chroot() bound to a certain filesystem.&lt;BR /&gt;&lt;BR /&gt;This works all as desired for up and downloads to/from chroot's /pub.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;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.&lt;BR /&gt;Often he receives a "connection closed by remote host" message when issuing a DIR, GET, PUT.&lt;BR /&gt;Sometimes though it works at extremely low transfer rates (&amp;lt;= 2 Kbps).&lt;BR /&gt;&lt;BR /&gt;From the involved relaying over so many hops with the amount of "wrapping" etc. I would blame the connection for the poor performance.&lt;BR /&gt;&lt;BR /&gt;On the other hand the client claims (as always) it's the server side (the only part over which I can have some influence).&lt;BR /&gt;&lt;BR /&gt;What further deteriorates things is that there is a very heavy load on the server's  machine which serves ftpd through inetd.&lt;BR /&gt;So one could maybe also suspect that inetd has too many tcp servers to spawn for too many client requests.&lt;BR /&gt;&lt;BR /&gt;There are (I would say) too many servers spawned by inetd.&lt;BR /&gt;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.&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;When I parse inetd.conf for tcp services I get this, of which over 90% are servers of their DBMS:&lt;BR /&gt;&lt;BR /&gt;$ perl -ane '$s++ if (/^[^#]/ &amp;amp;&amp;amp; !/^\s+$/ &amp;amp;&amp;amp; $F[2] eq "tcp");END{printf "%4u tcp services\n",$s}' /etc/inetd.conf&lt;BR /&gt;&lt;BR /&gt;Always when an ftpd connection gets broken the daemon writes these strange lines into syslog.log:&lt;BR /&gt;&lt;BR /&gt;# grep _module /var/adm/syslog/syslog.log|tail -2&lt;BR /&gt;Jan 24 15:13:48 saturn ftpd[20642]: open_module: stat(/usr/lib/security/libpam_u&lt;BR /&gt;nix.1) failed: No such file or directory&lt;BR /&gt;Jan 24 15:13:48 saturn ftpd[20642]: load_modules: can not open module /usr/lib/s&lt;BR /&gt;ecurity/libpam_unix.1&lt;BR /&gt;&lt;BR /&gt;The stat() syscall is wrong since the "pluggable auth. module" file mentioned exists.&lt;BR /&gt;(btw are perms for others too lenient, should it really be world readable?)&lt;BR /&gt;I never deliberately tampered with any PAM stuff :-{&lt;BR /&gt;&lt;BR /&gt;# ll /usr/lib/security/libpam_unix.1 &lt;BR /&gt;-r-xr-xr-x   1 root       sys         184320 May 14  1998 /usr/lib/security/libp&lt;BR /&gt;am_unix.1&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Ralph</description>
      <pubDate>Thu, 24 Jan 2002 15:07:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652066#M587993</guid>
      <dc:creator>Ralph Grothe</dc:creator>
      <dc:date>2002-01-24T15:07:35Z</dc:date>
    </item>
    <item>
      <title>Re: ftpd connection aborts by server</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652067#M587994</link>
      <description>Sorry for the horrible Perl line.&lt;BR /&gt;Actually it has been a copy and paste misshap.&lt;BR /&gt;This was what I meant to post :&lt;BR /&gt;&lt;BR /&gt; 129 tcp services&lt;BR /&gt;&lt;BR /&gt;Things get too cluttered in the tiny texarea field  ;-)&lt;BR /&gt;&lt;BR /&gt;ITRC maintainers, where is the possibility for interspersed markup (e.g. &lt;PRE&gt; tags)?&lt;/PRE&gt;</description>
      <pubDate>Thu, 24 Jan 2002 15:13:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652067#M587994</guid>
      <dc:creator>Ralph Grothe</dc:creator>
      <dc:date>2002-01-24T15:13:54Z</dc:date>
    </item>
    <item>
      <title>Re: ftpd connection aborts by server</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652068#M587995</link>
      <description>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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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).</description>
      <pubDate>Wed, 01 May 2002 20:38:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ftpd-connection-aborts-by-server/m-p/2652068#M587995</guid>
      <dc:creator>James Drenter</dc:creator>
      <dc:date>2002-05-01T20:38:04Z</dc:date>
    </item>
  </channel>
</rss>

