11-09-2011 03:19 AM
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
11-09-2011 05:22 AM
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.
11-09-2011 05:41 AM
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?
11-09-2011 12:04 PM
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.
11-09-2011 12:19 PM
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:
$ DEFINE/SYSTEM/EXEC TCPIP$SSH_DEVICE mydisk:
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? ;-)
11-09-2011 03:10 PM
>. 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.