Re: FTPD1
Finch, Steve
Browse /etc/syslog.conf to find the location of your log file
It's pretty trivial, unless you are using FTPLOGGING
Steve
EDS
-----Original Message-----
From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On Behalf Of
Ronald Wells
Sent: Thursday, September 15, 2005 2:40 PM
To: IBMT...@VM.MARIST.EDU
Subject: Re: FTPD1
Where should syslog output be located when someone does an FTP ?? gather
it
is in HFS file somewhere..but where?
----------------------------------------------------------------------
Email Disclaimer
This E-mail contains confidential information belonging to the
sender, which may be legally privileged information. This information
is intended only for the use of the individual or entity addressed
above. If you are not the intended recipient, or an employee or
agent responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the
taking of any action in reliance on the contents of the E-mail or
attached files is strictly prohibited.
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L
McKown, John
> From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On
> Behalf Of Ronald Wells
> Sent: Thursday, September 15, 2005 1:40 PM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: FTPD1
>
>
> Where should syslog output be located when someone does an
> FTP ?? gather it
> is in HFS file somewhere..but where?
Wherever you tell it to put it. FTP does not actually write directly to
a file. It sends "syslog" messages to the syslog daemon. Note that this
is not the same thing as the z/OS SYSLOG that we are all familar with.
So, first, you must have the syslog daemon running. I do this with a
line in /etc/rc like:
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -c -u &
This starts up the daemon when OMVS is started at IPL time. This daemon
generally gets its control cards from /etc/syslog.conf. Mine looks like:
kern.* /var/log/kern.%Y-%m-%d
user.* /var/log/user.%Y-%m-%d
mail.* /var/log/mail.%Y-%m-%d
news.* /var/log/news.%Y-%m-%d
uucp.* /var/log/uucp.%Y-%m-%d
daemon.* /var/log/daemon.%Y-%m-%d
auth.* /var/log/auth.%Y-%m-%d
cron.* /var/log/cron.%Y-%m-%d
local0.* /var/log/local0.%Y-%m-%d
local1.* /var/log/local1.%Y-%m-%d
local2.* /var/log/local2.%Y-%m-%d
local3.* /var/log/local3.%Y-%m-%d
local4.* /var/log/local4.%Y-%m-%d
local5.* /var/log/local5.%Y-%m-%d
local6.* /var/log/local6.%Y-%m-%d
local7.* /var/log/local7.%Y-%m-%d
FTP puts its information out to the daemon entry. And with the above
lines, my files look like:
/var/log/daemon.2005-09-15
In which there are lines like:
Sep 15 05:57:15 LIH1/BPXROOT ,FTPD2, ftpd[50331853]: EZYFS50I
ID=FTPD100054 CONN starts Client IPaddr=10.170.9.64 hostname=UNKNOWN
Sep 15 05:57:15 LIH1/BPXROOT FTPD2 ftps[50331853]: RA0715 pass: use
__passwd() to verify the user
Sep 15 05:57:15 LIH1/FTH001 FTPD2 ftps[50331853]: EZYFS56I
ID=FTPD100054 ACCESS OK USERID=FTH001
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS60I
ID=FTPD100054 ALLOC OK Use MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS61I
ID=FTPD100054 ALLOC DDNAME=SYS00001 VOLSER=FT0006 DSORG=PS
DISP=(OLD,KEEP)
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS70I
ID=FTPD100054 DEALL OK Release MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS81I
ID=FTPD100054 TRANS MVS DSN=FTHMN.MAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS83I
ID=FTPD100054 TRANS Stru=F Mode=S Type=A Input=623 bytes
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS80I
ID=FTPD100054 TRANS Reply=250 Transfer completed successfully.
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS60I
ID=FTPD100054 ALLOC OK Use MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS61I
ID=FTPD100054 ALLOC DDNAME=SYS00002 VOLSER=FT0009 DSORG=PS
DISP=(OLD,KEEP)
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS70I
ID=FTPD100054 DEALL OK Release MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS81I
ID=FTPD100054 TRANS MVS DSN=FTHPN.PAGI200D.FILE
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS83I
ID=FTPD100054 TRANS Stru=F Mode=S Type=A Input=623 bytes
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS80I
ID=FTPD100054 TRANS Reply=250 Transfer completed successfully.
Sep 15 05:57:15 LIH1/FTH001 FTH001 ftps[50331853]: EZYFS52I
ID=FTPD100054 CONN ends Input=1246 bytes Output=0 bytes
Also, if you tell the server to, it will generate SMF records. Either
type 118 or 119 or both.
--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
andrew mcintyre
> a file. It sends "syslog" messages to the syslog daemon. Note that this
> is not the same thing as the z/OS SYSLOG that we are all familar with.
> So, first, you must have the syslog daemon running.
And instead of just having the plain vanilla OMVS syslog daemon running and
not having much functionality with it, wouldn't it be nice if you could
automate any message flowing to syslogd? Do something like page somebody? Run
a REXX? Shutdown a server? Startup a server? Send a message to a central LPAR?
REXEC to a UNIX box and run a command? SSH to a UNIX box and run a command?
Drum roll.... You can!! Instead of starting OMVS syslogd, start the one in
NetView for z/OS. Then you can have an automated response to any message that
flows to the NetView syslogd. Just use the NetView Automation Table to trap
any message or event that flows and take whatever action you want to take.
You could actually automate an entire room of UNIX severs sending their
messages to a single NetView for z/OS.
Feel free to contact me if anyone wants any further info on this.
========================================================
Andrew McIntyre - Senior I/T Specialist - certified
zSeries Software Technical Sales
SMPO (Software Migration Project Office)
TMT (Tivoli Migration Team)
404-487-2477 or tie 546-2477
andrew....@us.ibm.com
========================================================
SMPO
http://www.ibm.com/software/solutions/softwaremigration
NetView for z/OS
http://www.ibm.com/tivoli/products/netview-zos/resources/nv390-update.html
System Automation for z/OS
http://www.s390.ibm.com/sa
========================================================
McKown, John
> From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On
> Behalf Of andrew mcintyre
> Sent: Thursday, September 15, 2005 2:12 PM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: FTPD1
>
<snip>
>
> And instead of just having the plain vanilla OMVS syslog
> daemon running and
> not having much functionality with it, wouldn't it be nice if
> you could
> automate any message flowing to syslogd? Do something like
> page somebody? Run
> a REXX? Shutdown a server? Startup a server? Send a message
> to a central LPAR?
> REXEC to a UNIX box and run a command? SSH to a UNIX box and
> run a command?
>
> Drum roll.... You can!! Instead of starting OMVS syslogd,
> start the one in
> NetView for z/OS. Then you can have an automated response to
> any message that
> flows to the NetView syslogd. Just use the NetView Automation
> Table to trap
> any message or event that flows and take whatever action you
> want to take.
>
> You could actually automate an entire room of UNIX severs
> sending their
> messages to a single NetView for z/OS.
>
> Feel free to contact me if anyone wants any further info on this.
>
Nice functionality. Assuming you have/are licensed for NetView. We
don't/aren't.
--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
----------------------------------------------------------------------
McKown, John
> From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On
> Behalf Of Ronald Wells
> Sent: Thursday, September 15, 2005 2:39 PM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: FTPD1
>
>
>
> you running SYSLOGD---satrted task setup??
>
Yes, I am running SYSLOGD. It is a "started task", but, as I said, I
start it via the /etc/rc file and not with a START SYSLOGD type command.
If you want to do it that way, the manual give the following JCL:
//SYSLOGD PROC
//SYSLOGD EXEC PGM=SYSLOGD,REGION=30M,TIME=NOLIMIT,
// PARM='POSIX(ON),ALL31(ON)/ -f /etc/syslogd.conf'
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSOUT DD SYSOUT=*
//SYSERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
You need to make sure that this runs as your SUPERUSER as defined in the
BPXPRMnn member of PARMLIB. You can do this using RACF:
RDEF STARTED SYSLOGD.* UACC(NONE) +
STDATA(USER(........) GROUP(........) TRUSTED(YES) TRACE(YES))
SETROPTS RACLIST(STARTED) REFRESH
Replace the dots with the appropriate RACF user and group in the STDATA
segment.
Reference:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB251/17.7
McKown, John
> From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On
> Behalf Of Ronald Wells
> Sent: Thursday, September 15, 2005 3:41 PM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: FTPD1
>
>
> the syslog parm list...getting confused ... many many
> options..lol...to
> record....
> guess I'm just use to mvs syslog....getting everything ....
>
> gather next question is option..best fit...
> plus I gather I need something to switch these log(s) like I
> do my SMF when
> full or on a daily basis..?
>
Ah, yes. I forgot about that. With the example /etc/syslog.conf that I
posted, you should "rotate" the logs just a wee tad after midnight. I
use the cron daemon for that. However, you can use anything which can do
a UNIX "kill" command. If you prefer to use a z/OS started task, just
run, say as LOGROTAT (or in a batch job):
//STEP1 EXEC PGM=BPXBATCH,
// PARM='SH kill -HUP $(cat /etc/syslog.pid)'
//STDOUT DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDERR DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDIN DD PATH='/dev/null',
// FILEDATA=TEXT,
// PATHOPTS=(ORDONLY)
Watch out for that lower case! It is very important. You must run the
above with a userid with a UID of zero, just like you did with the
SYSLOGD started task.
If I were to use the above method, I would use a started task that is
triggered by a CA-OPS/MVS TOD rule at 1 second after midnight.
Other considerations:
1) make sure that the filesystem (HFS file) that contains /var/log has
enough space. You don't really want to run out. If you do run out, you
will definately loose information. It is even theoritically possible, if
you fill up the "root" filesystem, that other UNIX work will suffer
degradation or even fail. I strongly recommend that /var/log be in its
own HFS file which is mounted at IPL time via the BPXPRMxx member of
PARMLIB.
2) You'll want to delete these logs after some period of time. You can
either just delete them, as I do, or copy them, then delete them. I have
another cron job with cleans up /var/log. I have it set up to run at 1
a.m. it does the command:
rm $(find /var/log -mtime +3)
This finds all the files in the /var/log subdirectory which were last
modified 3 days ago or longer and removes them. Again, you can use a
z/OS started task (again with the appropriate RACF userid) like:
//STEP1 EXEC PGM=BPXBATCH,
// PARM='SH rm $(find /var/log -mtime +3)'
//STDOUT DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDERR DD PATH='/dev/console',
// FILEDATA=TEXT,
// PATHOPTS=(OCREAT,OAPPEND,OWRONLY)
//STDIN DD PATH='/dev/null',
// FILEDATA=TEXT,
// PATHOPTS=(ORDONLY)
McKown, John
> From: IBM TCP/IP List [mailto:IBMT...@VM.MARIST.EDU] On
> Behalf Of Ronald Wells
> Sent: Thursday, September 15, 2005 4:12 PM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: FTPD1
>
>
>
> _ File 600 2005-09-15 17:03 STC1 1447 ivp.syslog.log
> did a FTP and it logged what I wanted---hopefully....
> below is SYSLOG member for the SYSLOGD proc...
> any suggestion??
>
> plus>> what is LOGROTAT ... did not see that mentioned any where...??
>
> #
> *.* /tmp/ivp.syslog.log
> #
>
> Just used default example........
>
LOGROTAT is my made up name for the STC. On Linux, there is a supplied
function called "logrotate" which does what I was talking about (and
much more). But LOGROTATE is too long a name, so I shortened it. It is
just the concept of whatever it is which does the "kill -HUP" command to
cause SYSLOGD to restart its logging, which, with the previously posted
example syslog.conf, will cause SYSLOGD to change the name of the file
to which it is writing.
Now, with the above example, there is absolutely NO reason to "rotate"
the logs because SYSLOGD will just start writing to the exact same file.
But, with that example, the file will grow without limit until it fills
up the filesystem which contains /tmp/. This is not a good idea! I did
that once by mistake. Things got dicey with UNIX work until I fixed it.
Having said that, there are ways to make that work "correctly", but I
consider them to be a bit more difficult than my way (having SYSLOGD put
the date in the log file and refreshing SYSLOGD each morning around
midnight).