Subject: [Q] Problem with datestamps and ftpwho util

From: [email-masked] (Greg A. Lato)
Date: Mon, 29 Jan 1996 15:08:33 -0600

I am running wu-ftpd v2.4 on an IBM RS/6000 running AIX v3.2.  I am now
experiencing the following problems (neither of these were occuring when I
first installed the ftpd but started about 4 months ago):

1.  Problem with wu-ftpd's datestamps.

When the ftpd writes a error entry out to the syslogd, it includes a
date/time stamp with the error.  The ftpd also date/time stamps transfers
to the xferlog, and can place the date automatically in the logon message
(using the %T specifier).  My problem is that the time that is being
reported in the error log file, the xferlog, and the login message is six
hours (exactly) ahead of what the system time really is (as reported from
date run from the command line).

Does someone know what the reson for this time difference is?  More
importantly, how to fix this problem?

2.  Problem with ftpwho utility.

Ftpd comes with a utility (ftpwho) that tells you how many users from each
service class are logged on at the time of execution.  When I run this
utility as a standard user, it reports that no one is currently logged in.
However, when I run this utility as the user root, it correctly reports how
many people are logged in.

Where does this utility get the information that it uses to tell how many
people are logged in?  I figure that all I should need to do is make this
file (I assume it is a file) readable by everyone.  It must have
acidentally gotten it's protection changed in the past.

3.  Strage behavior from error reporting through syslogd.

I have also notice some strange behavior that has peaked my curiosity.  It
seems that ftpd is writing a large (what seems like an unusual number) of
error messages to syslogd.  When I log onto the ftp server (as user
anonymous or as a registered user) and do an "ls", the following message is
written to syslogd:

        Jan 29 21:00:02 ollie ftpd[18944]: setsockopt (IP_TOS): Not owner
        Jan 29 21:00:40 ollie ftpd[15131]: setsockopt (IP_TOS): Not owner

This message doesn't seem to be written to the log file when a user does a
file transfer or a directory change, only on an "ls".

The following is the configuration for syslogd:

# "all facilities, at the warning level and higher, go to Log file."
*.warning       /var/adm/syslog

Any ideas as to why this is happening?

4.  Processes not dying correctly.

While doing some testing for the last two questions, I noticed that ftpwho
(run as root) reported two users logged in (one anonymous and one service
class).  When I did a ps ax, I got two processes for these two users.
However, when I took a look at the wtmp file (using last), it reported that
both of the users had logged off.

I am not sure if this is strange behavior or not (is would appear as such
to me).  I am also not sure if this behavior has to do with a
misconfiguration of the ftpd or of the machine itself (not getting around
to killing the processes correctly).

Does anyone have any ideas on what is causing this and why?

--- (end of questions) ---

Thanks to everyone for their help and time in advance.  Sorry about all the
questions (found the last two as I wrote up the first two).

Greg

+--------------------------------------------------------------------------+
 Greg A. Lato
  CWIS Administrator                    WWW:   http://www.uwec.edu/~latoga/
  Computing and Networking Services     email: [email-masked]
  University of Wisconsin-Eau Claire           [email-masked] (personal)
  Eau Claire, WI USA 54702-4004         Phone: (715) 836-3058
                                   -----
             "Graduating May 1996, But Looking for a Job Now."

---

From: [email-masked] (Stan Barber)
Date: 29 Jan 1996 21:43:48 GMT

>importantly, how to fix this problem?

The most frequent cause on most systems is that the information used by
the OS to determine the timezone it is in is not duplicated in the
chroot-ed file system from the regular file system. On BSD/OS, this means
copying /etc/localtime to the same location in the chrooted file system(s)
(e.g. ~ftp/etc/localtime). This is not a bug in ftpd, per se. Perhaps in
a future release of ftpd, we can carry around such inforamtion internally
in such a fashion that the time/date stamps won't have to depend on these
external files.

>acidentally gotten it's protection changed in the past.

The file/directory that keeps this information may be protected from being
read by normal users. On BSD/OS, this file is usually in /var/run. I don't
remember where it is on AIX, since I don't have one of those readily available
to me to work with.

>Any ideas as to why this is happening?

These errors indicate that AIX does not allow an unpriviledged process to
set these options. The errors are benign.

>Does anyone have any ideas on what is causing this and why?

This has been reported as a bug in some versions of wu-ftpd. I am told
that it may still be present in the current beta, but I am still trying to
gather adequate information to reproduce it and kill it.

-- 
Stan   | Academ Consulting Services        |internet: [email-masked]
Olan   | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

---

From: "Jonathan F. Carpenter" <[email-masked]>
Date: Wed, 31 Jan 1996 13:56:03 -0500 (EST)

In article <[email-masked]> [email-masked] (Stan Barber) writes:

>set these options. The errors are benign.

I'm having the same problem on our RS-6000, running wu-ftpd 2.4.  
Is there anyway I can prevent these errors from occurring?  Not only
does the message show up in the syslog, but it also will appear on any
terminal logged on as root, which can be a little annoying.
Where the error is being generated is here (in ftpd.c):

#ifdef IPTOS_THROUGHPUT
    on = IPTOS_THROUGHPUT;
    if (setsockopt(s, IPPROTO_IP, IP_TOS, (char *) &on, sizeof(int)) < 0)
          syslog(LOG_WARNING, "setsockopt (IP_TOS): %m");
#endif

Can I just comment it out (since the function seems to be not working 
anyway, but does not seem to cause any problems) to prevent the error?  
Or, how can I make the process privileged?

Are other people running RS/6000s having this same problem?

Thanks,

Jon Carpenter
[email-masked]