Openvms FTP Server Log File

[Steven Schweda]

> [...] without dropping one user session.
> [...]

I'd need to check, but I believe that a
disable+enable cycle on the TCPIP FTP server
doesn't kill an open session. (As I recall,
that procedure was ineffective at stopping
one of those "administrato" attacks, and the
individual FTP session process had to be
whacked independently.)

[Imker]

Thanks all.

The informations provided were highly helpfull.


I'll post a link to this over on SU.

[Jess Goodman]

I did some tests, and apparently DISABLE SERVICE FTP does nothing at all, other than allow you to then enter an ENABLE SERVICE FTP command. You are correct in that this sequence of commands will not disconnect users.

The ENABLE SERVICE FTP command does open up a new TCPIP$FTP_RUN.LOG file, because that command attempts to run a new ftp listener process, and this log file is that process's SYS$OUTPUT.

The problem is that if you did not run TCPIP$FTP_SHUTDOWN.COM, or use STOP/ID-, then the old ftp listener process is still running, and the "new" log file is quickly closed, ending with this:

%SYSTEM-F-DUPLNAM, duplicate name
%TCPIP-E-FTP_BIND, cannot bind the address to the socket
$ !
$ ! completed ftp server execution
$ !
$ exit:
$ exit $status .or. %x10000000
SYSTEM job terminated at 21-APR-2011 06:45:03.99

The old process will still be logging new connections, user names, and disconnections to the old version of TCPIP$FTP_RUN.LOG, assuming that you specified P1 with TCPIP$FTP_STARTUP.COM.

If you first stop the current ftp listener process before you start up a new one, then the new version of the log file will be active - but all current ftp users get disconnected.

The HG FTP software writes to an activity log file that is separate from the SYS$OUTPUT of the listener process. By default the listener logs connections and disconnections in it, but you can configure the software so that all directory listings, file transfers, CWD commands, etc. are also logged to this file.

To be clear, this thread is a discussion about a system-wide ftp log file, not the user-specific log files found is the ftp user's home directory.

[Steven Schweda]

> The problem is [...]

Hmmm. Now that you stir the old memories,
this sounds familiar. Everything's
complicated. (Especially with lame
software.)

[Hoff]

>I did some tests, and apparently DISABLE SERVICE FTP does nothing at all, other than allow you to then enter an ENABLE SERVICE FTP command. You are correct in that this sequence of commands will not disconnect users.

True.

The ftp server passes off incoming ftp connections to connection-specific server processes, and which is one of the reasons why the connection server processes can be configured with timeouts via logical name.

AFAIK, there's also no central controlled shutdown mechanism for those ftp server processes. They just get nuked when some lower-level piece shuts down, or they time out and exit.

The timeout gets those server processes to vaporize after some site-determined time interval, and to then allow those logs to be accessed for deletion or otherwise managed. But that's not a synchronous shutdown, it's a case where you shut off the ftp server, and then wait for those individual servers to timeout.

I'd certainly like to see centralized and particularly distributed logging for VMS, but that's not likely to be implemented given the corresponding need to modify all the logging clients around to use that logging. The existing logging mess is just too baked into the VMS environment.