TCPIP$RSH_RUN.LOG file

[skulker]

Hello all,

I'm not too up on Digital TCP/IP and I have a question.

First I'm running

DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A
on a AlphaServer 4100 5/533 4MB running OpenVMS V7.2-1

This is a two node cluster with shadowed DSSI disks.

Recently changes to the business has increased the number of RSH
connects I get during a day. Nothing is wrong and I can't change
anything. It is what it is.

The TCPIP$RSH_RUN.LOG file is getting about 10000+ versions a day.
Needless to say in 3 days I have to purge and rename.

The problem is that I have monitor the system constantly for a time
when there are no connections so the file is not locked.

Is there a way I can stop the RSH process from creating the logfile?

I'd really like to either turn it off or dump to the bit bucket.

BTW - everything comes in under the same username and uses that SYS
$LOGIN directory.

Any help would be appreciated.

John Baker
Operations I&S Engineer, Collections

Thomson Reuters

[John Santos]

In article <bb9ab5a0-1afb-4f9f-8957-
039cde...@f20g2000vbl.googlegroups.com>, bak...@swbell.net says...>

I wonder if you could run something periodically (e.g. once
a day) that renames the directory that tcpip$rsh_run.log lives
in, and creates a new, empty one? It should be possible to
do this even if there are open log files in the directory.

This directory appears to be sys$sysdevice:[tcpip$rsh], at
least on the TCP/IP V5.6. I don't have any logs in any of
mine, but I think we don't use RSH much if at all. There is
a login.com in it, though, which you probably want to preserve.

So you could do something like:

$ create/dir sys$sysdevice:[tcpip$rsh_new]/owner=system
$ copy sys$sysdevice:[tcpip$rsh]login.com sys$sysdevice:[tcpip$rsh_new]
$ rename sys$sysdevice:[0,0]tcpip$rsh.dir tcpip$rsh_old.dir
$ rename sys$sysdevice:[0,0]tcpip$rsh_new.dir tcpip$rsh.dir

There is a short race condition where no rsh directory exists
between the two renames. Not sure what would happen if a new
connection occured during that interval.

You'll need bypass or system privilege to rename the directories.

You could make the directory used by the RSH server be a
search list, so it could fall back to the second translation
if the first didn't exist. (It appears to be defined by the
default directory in the UAF definition for TCPIP$RSH, so
maybe you could set that to a search list...)

Then clean up the 2nd directory after you've finished cleaning
up the 1st one.

Or a different approach would be to redefine the default directory
in the UAF each day. If a connection request arrived while the
UAF record was locked during the change-over, I think LOGINOUT
(or what ever is reading the UAF record) would handle this
okay by waiting for the lock to be released, which should be
just a few milliseconds.

Then clean up the old directories:

$ today = f$extract(0,11,f$time())
$ create/dir sys$sysdevice:[tcpip$rsh_'today']
$ copy sys$sysdevice:[tcpip$rsh_'yesterday']login.com -
sys$sysdevice:[tcpip$rsh_'today']
$ mcr authorize modify tcpip$rsh -
/default="sys$sysdevice:[tcpip$rsh_'today']"
$ ! do cleanup

Error handling, computing the appropriate value for the
symbol "yesterday", etc. left as an exercise for the reader.

--
John Santos
Evans Griffiths & Hart, Inc.

[Mike Rechtman]

Try creating a log file with version 32767
(OTOH it may stop RSH connections entirely...)

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before

[Steven Schweda]

John Santos wrote:

> I wonder if you could run something periodically (e.g. once
> a day) that renames the directory that tcpip$rsh_run.log lives
> in, and creates a new, empty one? It should be possible to
> do this even if there are open log files in the directory.

Well, it is the user's SYS$LOGIN, so that might be
annoying.

I know nothing, but unlike with some services, where some
SYS$SYSTEM:TCPIP$xxx.COM creates the log file, and so gives
you some relatively easy access to it, the RSH receiver itself
seems to be doing it for RSH. (Perhaps because it does go
into the victim's SYS$LOGIN.)

You do seem to get SYLOGIN.COM run for an RSH job, so you
might be able to put some (highly reliable!) code into that to
do some purging and version shifting.

I have an embarrassing mess which I use for pruning
SYS$SPECIFIC:[TCPIP$SMTP]TCPIP$SMTP_LOGFILE.LOG, but I can run
that from SYS$SYSTEM:TCPIP$SMTP_RECV_RUN.COM, where some fatal
slip-up is less likely to cripple the whole system.

[skulker]

Thanks to all who replied.

I have discoved this is NOT an issue.

After testing on a non-prodction system I learned that even if the log
file is 32767 the RSH commands still perform as desired. So unless I
need log files for trouble-shooting I can just leave it. I have set
the file version limit to 10 so no worries after all!

BTW - this is true for net$server.log as well.

John

[John Santos]

In article <7062643e-4504-425b-8976-ede54ae92955
@v25g2000yqk.googlegroups.com>, sms.an...@gmail.com says...>

> John Santos wrote:
>
> > I wonder if you could run something periodically (e.g. once
> > a day) that renames the directory that tcpip$rsh_run.log lives
> > in, and creates a new, empty one? It should be possible to
> > do this even if there are open log files in the directory.
>
> Well, it is the user's SYS$LOGIN, so that might be
> annoying.

Oops! I forgot we were dealing with RSH... That probably
explains why I didn't see *any* log files in my [tcpip$rsh]
directory :-P

<Emily Latella> Never mind. </Emily Latella>