OVMS 7.3-2 move the tcp/ip logfiles off the system disk (5934 Views)
Reply
Occasional Contributor
Christos Lalopoulos
Posts: 3
Registered: ‎12-22-2003
Message 1 of 6 (5,934 Views)

OVMS 7.3-2 move the tcp/ip logfiles off the system disk

Customer is asking how to move the tcp/ip logfiles off the system disk. system disk has limited disk space and the specific customer is not able to replace the disks with bigger ones.

Customer is running OVMS 7.3-2 with current patches

Honored Contributor
Hoff
Posts: 4,946
Registered: ‎01-29-2006
Message 2 of 6 (5,918 Views)

Re: OVMS 7.3-2 move the tcp/ip logfiles off the system disk

The usual path fpr this involves skimming the individiual chapters of the TCP/IP Services management manual (if that's the particular IP stack that's in use here; there are third-party IP stacks) for each of the IP services that's involved and active, and setting up the service-specific mechanisms to move or disable the logs.  There are inconsistencies here in how the individual service logs are managed and migrated.

 

For the TCP/IP Services documentation, visit http://www.hp.com/go/openvms/doc and select the management manual within the TCP/IP Services shelf.

 

There are also often settings for reducing the quantity of data logged for some of the services, which can be helpful if there are particularly large or rapidly-filling log files.

 

Alternatives to migrating the logs include periodic log management processing, zipping and archiving logs as appropriate.  There are various "nightly" batch job examples around, and it's common to use a batch job to "roll" the primary logs (security, accounting, operator and a few others) and these can be extended to manage the IP logs.  These same site-specific batch jobs also typically watch for disk usage and related triggers.

 

As a different alternative, and if this OpenVMS Alpha V7.3-2 server has disks contemporary with that version or older, then swapping out disks for larger ones is often a very cheap fix, and it moves the server forward to less-old disks.  There are used StorageWorks disks available from various sources and for comparatively little money, and there are also compatible new products available for various StorageWorks products.

 

I'd suggest acquiring an escalation path for supporting your OpenVMS customers, as well.  This would not be the first posting that the proximate customer ended up reading, for instance.

 

Occasional Contributor
Christos Lalopoulos
Posts: 3
Registered: ‎12-22-2003
Message 3 of 6 (5,915 Views)

Re: OVMS 7.3-2 move the tcp/ip logfiles off the system disk

Hi

 

Thanks for your reply.  Customer is the Greek Navy and there is no budget available to purchase any additional disks in the MSA1000 storage. I have found out how to stop the creation of the TCPIP$SSH_RUN.LOG file. Is there any other TCPIP log file whcic is created when users are login in either with telnet or SSH?

Honored Contributor
Hoff
Posts: 4,946
Registered: ‎01-29-2006
Message 4 of 6 (5,898 Views)

Re: OVMS 7.3-2 move the tcp/ip logfiles off the system disk

No money is the usual claim these days, and lately everybody's either in the same situation as Greece, or claiming to be.  (Get used to it.)  If the customer is paying enough for support and if you value them as a customer, then figure out if they're already on dinky disks and of what type, and ship them a bigger disk.   These things really are that cheap on the used market.

 

As for your question, telnet can also create logs.

 

See what services are enabled.  That's your starting point for your hunt for logs.  Or log in on the server, and have a look at which logs are active, how long each log has been around, and how big the log file is.

 

If ssh and telnet are the central issues here, then there's probably something else going on.  There's pontentially been no log roll-over performed for a while, or the systems are internet-exposed and being probed (or breached), or there's a problem with the server and its logging is chattering, etc.

 

If you're not particularly familiar with the basics of VMS and TCP/IP Services management (as could be inferred here), then I'd suggest outsourcing this support.

Honored Contributor
John Gillings
Posts: 2,994
Registered: ‎07-31-2003
Message 5 of 6 (5,897 Views)

Re: OVMS 7.3-2 move the tcp/ip logfiles off the system disk

There should be a logical name like, for example, TCPIP$ROOT, which lifts up all of TCPIP and drops it on whichever disk you want. Unfortunately TCPIP engineering steadfastly refuse to support TCPIP files off the system disk (been banging my head on that wall for nearly 2 decades).

 

In practice, you can redefine system level logical names to redirect TCPIP files. I've been doing it for a long time, with no apparent problems, but if you're stuck with strictly supported mechanisms, you may need to avoid it.

 

In your case, it should be something like:

 

$ DEFINE/SYSTEM/EXEC TCPIP$SSH_DEVICE mydisk:

 

Put this in SYLOGICALS.COM. To make the change on the fly:

 

$ @SYS$STARTUP:TCPIP$SSH_SHUTDOWN

$ DEFINE/SYSTEM/EXEC TCPIP$SSH_DEVICE mydisk:

$ @SYS$STARTUP:TCPIP$SSH_STARTUP

 

Look at other TCPIP$ logical names to work out which ones need to be changed. Look for anthing containing "SYS$SYSROOT", "SYS$SPECIFIC" or "SYS$SYSDEVICE"

 

> Customer is the Greek Navy and there is no budget available

 

If they're really stuck for cash, I'm sure we could have a whip around and scare up a few dollars to help them out. They should be good to repay it, right? ;-)

A crucible of informative mistakes
Honored Contributor
John Gillings
Posts: 2,994
Registered: ‎07-31-2003
Message 6 of 6 (5,889 Views)

Re: OVMS 7.3-2 move the tcp/ip logfiles off the system disk

>. I have found out how to stop the creation of the TCPIP$SSH_RUN.LOG file.

 

  If you just want to block the creation of a particular log files, and can't work out a "proper" way to control it, a brute force method is to create a file with version 32767

 

$ CREATE TCPIP$SSH_RUN.LOG;32767

 

This is universal.

A crucible of informative mistakes
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.