Override SFTP_LOGFILE setting

Discussion of Co:Z sftp, a port of OpenSSH sftp for z/OS
Post Reply
dabills
Posts: 41
Joined: Thu May 19, 2011 9:56 am

Override SFTP_LOGFILE setting

Post by dabills »

Is there a way for a client to override the default SFTP_LOGFILE setting without having to customize the sftp-server.rc file? We have turned off SFTP logging as a defauly, but would like the capability of the client to enable so they can get the /+error.log information when needed.

There are at least two situations where the information from the /+error.log is needed in order to provide more transfer result information to the client:
1. when putting data to a GDG, the default reply does not include the G#V# information
2. when putting a file that is customized by the CZCHKCMD exit, the default reply only includes the name of the original target file instead of the customized target file changed in the CZCHKCMD exit (.ie. the CZCHKCMD exit appends a date.time.seq suffix to the original target file prior to the STOR)
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Re: Override SFTP_LOGFILE setting

Post by dovetail »

Unfortunately, the only way to override the SFTP_LOGFILE setting is by customizing the sftp-server.rc file. There is no way to dynamically change it during the session.

Also, I do not feel that it is good practice to run without a log file. It is better IMO to have these, and then perhaps have a maintenance job that cleans them up. That way, if something goes wrong, you have information to help diagnose the cause.
dabills
Posts: 41
Joined: Thu May 19, 2011 9:56 am

Re: Override SFTP_LOGFILE setting

Post by dabills »

Ok, thats what I figured. Is there an easy way to include the userid and a date/timestamp/seq# in the sftp_logfile name? We may have a condition where multiple file transfers could occur at the same time with the same userid.
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Re: Override SFTP_LOGFILE setting

Post by dovetail »

The SFTP_LOGFILE environment variable can be configured in your system or user .rc file.

If it is not set, then the <cozinst>/bin/sftp-server.sh script will configure it. If you look at this script, you will see this:

Code: Select all

# Setup a logfile if not set by the .rc profile
if [[ -z "$SFTP_LOGFILE" ]]
then
  tdir=${TMPDIR:-/tmp}
  logid=`echo $LOGNAME | tr "[:upper:]" "[:lower:]"`
  dte=`date +%j.%H%M%S`
  SFTP_LOGFILE=$tdir/sftp-server.$logid.$dte.$$.log
fi
This will configure the filename to include the userid, date (julian day, hours, min, seconds), and the Unix process id ($$) so that it will be unique. If you would like some other scheme, you could put this block of script code in your system rc script and change it to meet your needs.
dabills
Posts: 41
Joined: Thu May 19, 2011 9:56 am

Re: Override SFTP_LOGFILE setting

Post by dabills »

Thanks for the update, that works fine updating the users .rc file. In my original post I was looking to enable the sftp_logfile in order to get the following from the +error.log
1. when putting data to a GDG, the default reply does not include the G#V# information
2. when putting a file that is customized by the CZCHKCMD exit, the default reply only includes the name of the original target file instead of the customized target file changed in the CZCHKCMD exit (.ie. the CZCHKCMD exit appends a date.time.seq suffix to the original target file prior to the STOR)

I can get the fully modified file name created by CZCHKCMD by using loglevel=I, but I still cannot get the G#V# that is associated with a new GDG file. I've tried various loglevel setting and all of them only show me information from the PUT command...ie.. GDG(+1) instead of GDG.G#V# Is there anyway to get the G#V# so the remote user can see the actual dataset created? If so, how?
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Re: Override SFTP_LOGFILE setting

Post by dovetail »

Currently, the messages that we print do not use the resolved dataset name (in the case of a relative GDG reference, this resolved name would include G00V00 suffix).
We should probably change the close message to include this name, rather than the name used to open the dataset.

We will add this to a list of enhancements that we will consider for an upcoming release.

So, then the log messages would have something like this:

ZosDataset: Opening dataset KIRK.TEST.GDG(+1) for write with options: new catalog
ZosDataset: Closing dataset //KIRK.TEST.GDG.G0004V00 - 10248 bytes received, 2 records written

BTW - the current release already uses the resolved DSN when writing SMF records and to call the CZPOSTPR exit.
Post Reply