TCPIP$CONFIGURATION
Phillip Helbig---undress to reply
default?
Jose Baars
undress to reply) wrote:
> Has anyone defined TCPIP$CONFIGURATION to anything other than the
> default?
Yes. To a directory on a common non-system disk in a cluster,
as the cluster has no common system disk.
Phillip Helbig---undress to reply
<5baea568-47d7-4b1c...@h22g2000vbr.googlegroups.com>,
Jose Baars <peut...@googlemail.com> writes:
Right, that's what I'm looking for. OK, you've done it. Presumably
everything works OK. Of course, one would move
SYS$SYSTEM:TCPIP$CONFIGURATION.DAT to the location pointed to by the
logical name.
Does one have to move any other files?
Does one have to restart TCPIP?
Does one have to do anything else?
Jose Baars
undress to reply) wrote:
> Does one have to move any other files?
>
> Does one have to restart TCPIP?
>
> Does one have to do anything else?
Yes, it has worked like this since 2003.
We have moved the following TCP/IP
related files and set the logicals,
previous to a reboot.
TCPIP$CONFIGURATION.DAT
TCPIP$HOST.DAT
TCPIP$PRINTCAP.DAT
TCPIP$NETWORK.DAT
TCPIP$PROXY.DAT
TCPIP$ROUTE.DAT
TCPIP$SERVICE.DAT
I'm not sure if this list is comprehensive,
and some of the services, like BIND and
NTP do not respond well or at all to changes
in logicals.
TCPIP$HOST.DAT is particularly interesting,
as this will make any 'set host ddd/addr=' changes
visible on the whole cluster.
If you don't reboot, you probably want
to restart TCP/IP, to be sure consistency
is maintained.
I never even tried to change this 'on the fly',
as I didn't find it very interesting to see it
fail.
You have to mount the disk and set the logicals
before tcpip$startup runs, we do this in
sylogicals.com.
Good luck!
Phillip Helbig---undress to reply
<846f4c8f-3f83-43d5...@j3g2000vbp.googlegroups.com>, Jose
Baars <peut...@googlemail.com> writes:
> On Dec 8, 2:11 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> undress to reply) wrote:
>
> > Does one have to move any other files?
> >
> > Does one have to restart TCPIP?
> >
> > Does one have to do anything else?
>
> Yes, it has worked like this since 2003.
OK, good to know.
> We have moved the following TCP/IP
> related files and set the logicals,
> previous to a reboot.
>
> TCPIP$CONFIGURATION.DAT
> TCPIP$HOST.DAT
> TCPIP$PRINTCAP.DAT
> TCPIP$NETWORK.DAT
> TCPIP$PROXY.DAT
> TCPIP$ROUTE.DAT
> TCPIP$SERVICE.DAT
OK. I don't see TCPIP$PRINTCAP nor SYS$SYSTEM:TCPIP$PRINTCAP.DAT (so
that's consistent), but the other logical names (pointing to the default
locations) and files are there. (I haven't set up any TCPIP printers,
so this is probably OK.)
> I'm not sure if this list is comprehensive,
OK, I'll check the docs. On my system:
$ dir sys$system:TCPIP$*.dat
Directory SYS$COMMON:[SYSEXE]
TCPIP$BOOTP.DAT;1 TCPIP$CONFIGURATION.DAT;1 TCPIP$HOST.DAT;1
TCPIP$NETWORK.DAT;1 TCPIP$PROXY.DAT;1 TCPIP$ROUTE.DAT;1 TCPIP$SERVICE.DAT;1
Total of 7 files.
So that looks like all of them.
> and some of the services, like BIND and
> NTP do not respond well or at all to changes
> in logicals.
I'm not using either of those.
> TCPIP$HOST.DAT is particularly interesting,
> as this will make any 'set host ddd/addr=' changes
> visible on the whole cluster.
OK, but why is this "interesting"?
> If you don't reboot, you probably want
> to restart TCP/IP, to be sure consistency
> is maintained.
OK.
> I never even tried to change this 'on the fly',
> as I didn't find it very interesting to see it
> fail.
Indeed.
> You have to mount the disk and set the logicals
> before tcpip$startup runs, we do this in
> sylogicals.com.
OK.
Phillip Helbig---undress to reply
<846f4c8f-3f83-43d5...@j3g2000vbp.googlegroups.com>, Jose
Baars <peut...@googlemail.com> writes:
> Yes, it has worked like this since 2003.
Surely someone else must be using this feature as well?!
Jose Baars
undress to reply) wrote:
> > TCPIP$HOST.DAT is particularly interesting,
> > as this will make any 'set host ddd/addr=' changes
> > visible on the whole cluster.
>
> OK, but why is this "interesting"?
"Interesting" is a poor choice of words, sorry.
What I meant was: the benefits are obvious.
You can add hosts on one node, and they are
immediately available on the other nodes,
without having to use sysman or any other way
to duplicate the hosts on the other nodes
of the cluster. Inconsistencies in the local
host database are non-existent.
Phillip Helbig---undress to reply
<b7f93008-7293-494c...@p8g2000vbs.googlegroups.com>, Jose
Baars <peut...@googlemail.com> writes:
> On Dec 8, 7:13=A0pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> undress to reply) wrote:
> > > TCPIP$HOST.DAT is particularly interesting,
> > > as this will make any 'set host ddd/addr=3D' changes
> > > visible on the whole cluster.
> >
> > OK, but why is this "interesting"?
>
> "Interesting" is a poor choice of words, sorry.
> What I meant was: the benefits are obvious.
> You can add hosts on one node, and they are
> immediately available on the other nodes,
> without having to use sysman or any other way
> to duplicate the hosts on the other nodes
> of the cluster. Inconsistencies in the local
> host database are non-existent.
Right. I originally became interested in this stuff in the context of
cloning system disks, but it seems quite useful in its own right, much
as SYSUAF etc.
Jose Baars
undress to reply) wrote:
> Right. I originally became interested in this stuff in the context of
> cloning system disks, but it seems quite useful in its own right, much
> as SYSUAF etc.
Yes, it is all part of the recommendations for setting up multi-site
clusters. I do not think we are the only ones using it.
bart...@gmail.com
undress to reply) wrote:
> In article
> <846f4c8f-3f83-43d5-bc4d-54623531d...@j3g2000vbp.googlegroups.com>, Jose
>
> Baars <peutba...@googlemail.com> writes:
> > Yes, it has worked like this since 2003.
>
> Surely someone else must be using this feature as well?!
I used this feature as well. Frankly, I didn't think much of it. It is
what you expect from any OpenVMS component. However, many components
of TCP/IP Services for OpenVMS have things like SYS$SYSDEVICE and SYS
$SPECIFIC hard coded.
To simplify the TCP/IP configuration maintenance for multiple clusters
I used the technique that I described in my article in OpenVMS
Technical Journal V13.
Regards,
Bart
Phillip Helbig---undress to reply
<e3138991-ff6d-4149...@m35g2000vbn.googlegroups.com>,
"Bart...@gmail.com" <bart...@gmail.com> writes:
> > > Yes, it has worked like this since 2003.
> >
> > Surely someone else must be using this feature as well?!
>
> I used this feature as well. Frankly, I didn't think much of it. It is
> what you expect from any OpenVMS component.
So far, so good; maybe I, too, should have expected it.
> However, many components
> of TCP/IP Services for OpenVMS have things like SYS$SYSDEVICE and SYS
> $SPECIFIC hard coded.
If log files, LOGIN.COM etc goes to SYS$SYSDEVICE or SYS$SPECIFIC, I
guess that's OK. For log files, having them separated by node might
make sense, and for LOGIN.COM one can always include as the last (and
perhaps only) line a call to a common LOGIN.COM on a common, non-system
disk.
> To simplify the TCP/IP configuration maintenance for multiple clusters
> I used the technique that I described in my article in OpenVMS
> Technical Journal V13.
OK; I'll check it out.
bart...@gmail.com
undress to reply) wrote:
> In article
OpenVMS TJ V14 contains an updated version of my article.
Bart
Phillip Helbig---undress to reply
worry about different versions of TCPIP, different architectures etc?
bart...@gmail.com
undress to reply) wrote:
> Assuming one has common TCPIP$* files in a cluster, does one have to
> worry about different versions of TCPIP, different architectures etc?
AFAIK, no. The last change in configuration files was in the V5.0 ->
V5.1 timeframe. And that change is supposed to be handled
automatically. Have a look at SYS$MANAGER:TCPIP$V51_CONVERSION.COM for
what was changed.
Bart
Phillip Helbig---undress to reply
<f20fa79e-19e3-4429...@q18g2000vbm.googlegroups.com>,
"Bart...@gmail.com" <bart...@gmail.com> writes:
> On Dec 11, 8:46 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
> undress to reply) wrote:
> > Assuming one has common TCPIP$* files in a cluster, does one have to
> > worry about different versions of TCPIP, different architectures etc?
>
> AFAIK, no. The last change in configuration files was in the V5.0 ->
> V5.1 timeframe.
OK.
> And that change is supposed to be handled
> automatically. Have a look at SYS$MANAGER:TCPIP$V51_CONVERSION.COM for
> what was changed.
Even if it is handled automatically, couldn't there be a problem with a
rolling upgrade in a cluster?
Jose Baars
> rolling upgrade in a cluster?
Yes, that is not impossible, although probably caused by a bug rather
than by design.
Which is why we also make sure the common files are copied back
to the system-specific system disk (not on a very regular basis, to
avoid
proliferation of errors) and have a switch in sylogicals that allows
us
to revert to system-specific copies if horrible things happen.
More importantly: we test upgrades on a test cluster.