Is there a good way to configure TCPIP Services on a second system disk that is available but not the active system disk? Not a cluster configuration; we're using an alternate system disk to stage a new server; it is fully config'd but we will need to do a reconfig of TCPIP on the 'other' system disk (which will have conflicting addresses) before booting it.

Our alternative is to unplug the LAN cable, boot the second disk, run through the reconfigs, then shut down, recable, and boot. Hoping there's a better options.

Thanks
Rich

In article <7ad59ba8-a715-4527-8922-a97c6dee44een@googlegroups.com>,
Rich Jordan <jordan@ccs4vms.com> writes:

> Is there a good way to configure TCPIP Services on a second system disk
> that is available but not the active system disk? Not a cluster
> configuration; we're using an alternate system disk to stage a new
> server; it is fully config'd but we will need to do a reconfig of TCPIP
> on the 'other' system disk (which will have conflicting addresses)
> before booting it.

Perhaps not a good way in that, IIRC, there is not just one logical name
one needs to redefine or whatever, but it does seem to be possible.

I like to keep stuff which is common to the cluster off the system disk.
You can use a similar approach.

$! my own definitions
$!
$ CLUSTER_DEF := DEFINE/SYSTEM/EXECUTIVE_MODE/NOLOG
$ CLUSTER_DEF CLUSTER_DISK DISK$USER:
$ CLUSTER_DEF CLUSTER_SYSTEM CLUSTER_DISK:[SYSTEM.EXE]
$ CLUSTER_DEF CLUSTER_MANAGER CLUSTER_DISK:[SYSTEM.MANAGER]
$ CLUSTER_DEF CLUSTER_LIBRARY CLUSTER_DISK:[SYSTEM.LIBRARY]
$ CLUSTER_DEF CLUSTER_STARTUP CLUSTER_DISK:[SYSTEM.STARTUP]
$ CLUSTER_DEF CLUSTER_TCPIP_SMTP CLUSTER_DISK:[SYSTEM.TCPIP_SMTP]
$!
$!
$! definitions of common files (see SYS$MANAGER:SYLOGICALS.TEMPLATE)
$!
$ CLUSTER_DEF SYSUAF CLUSTER_SYSTEM:SYSUAF.DAT
$ CLUSTER_DEF SYSUAFALT CLUSTER_SYSTEM:SYSUAFALT.DAT
$ CLUSTER_DEF SYSALF CLUSTER_SYSTEM:SYSALF.DAT
$ CLUSTER_DEF RIGHTSLIST CLUSTER_SYSTEM:RIGHTSLIST.DAT
$ CLUSTER_DEF NETPROXY CLUSTER_SYSTEM:NETPROXY.DAT
$ CLUSTER_DEF NET$PROXY CLUSTER_SYSTEM:NET$PROXY.DAT
$ CLUSTER_DEF NETOBJECT CLUSTER_SYSTEM:NETOBJECT.DAT
$ CLUSTER_DEF NETNODE_REMOTE CLUSTER_SYSTEM:NETNODE_REMOTE.DAT
$ CLUSTER_DEF LMF$LICENSE CLUSTER_SYSTEM:LMF$LICENSE.LDB
$ CLUSTER_DEF VMSMAIL_PROFILE CLUSTER_SYSTEM:VMSMAIL_PROFILE.DATA
$ CLUSTER_DEF VMS$OBJECTS CLUSTER_SYSTEM:VMS$OBJECTS.DAT
$ CLUSTER_DEF VMS$AUDIT_SERVER CLUSTER_MANAGER:VMS$AUDIT_SERVER.DAT
$ CLUSTER_DEF VMS$PASSWORD_HISTORY CLUSTER_SYSTEM:VMS$PASSWORD_HISTORY.DATA
$ CLUSTER_DEF VMS$PASSWORD_DICTIONARY CLUSTER_LIBRARY:VMS$PASSWORD_DICTIONARY.DATA
$ CLUSTER_DEF NETNODE_UPDATE CLUSTER_MANAGER:NETNODE_UPDATE.COM
$ CLUSTER_DEF VMS$PASSWORD_POLICY CLUSTER_LIBRARY:VMS$PASSWORD_POLICY.EXE
$ CLUSTER_DEF LAN$NODE_DATABASE CLUSTER_SYSTEM:LAN$NODE_DATABASE.DAT
$ CLUSTER_DEF VMS$CLASS_SCHEDULE CLUSTER_SYSTEM:VMS$CLASS_SCHEDULE.DATA
$ CLUSTER_DEF QMAN$MASTER CLUSTER_SYSTEM
$! QMAN$MASTER.DAT
$! SYS$QUEUE_MANAGER.QMAN$QUEUES
$! SYS$QUEUE_MANAGER.QMAN$JOURNAL
$ CLUSTER_DEF TCPIP$CONFIGURATION CLUSTER_SYSTEM:TCPIP$CONFIGURATION.DAT
$ CLUSTER_DEF TCPIP$BOOTP CLUSTER_SYSTEM:TCPIP$BOOTP.DAT
$ CLUSTER_DEF TCPIP$HOST CLUSTER_SYSTEM:TCPIP$HOST.DAT
$ CLUSTER_DEF TCPIP$NETWORK CLUSTER_SYSTEM:TCPIP$NETWORK.DAT
$ CLUSTER_DEF TCPIP$PROXY CLUSTER_SYSTEM:TCPIP$PROXY.DAT
$ CLUSTER_DEF TCPIP$ROUTE CLUSTER_SYSTEM:TCPIP$ROUTE.DAT
$ CLUSTER_DEF TCPIP$SERVICE CLUSTER_SYSTEM:TCPIP$SERVICE.DAT
$ CLUSTER_DEF TCPIP$PRINTCAP CLUSTER_SYSTEM:TCPIP$PRINTCAP.DAT
$ CLUSTER_DEF OPC$OPA0_ENABLE TRUE
$ CLUSTER_DEF OPC$LOGFILE_ENABLE TRUE
$ CLUSTER_DEF OPC$ALLOW_INBOUND TRUE
$ CLUSTER_DEF OPC$ALLOW_OUTBOUND TRUE
$ CLUSTER_DEF OPC$LOGFILE_NAME -
CLUSTER_MANAGER:OPERATOR_'NODENAME'.LOG
$ CLUSTER_DEF MAIL$SYSTEM_FLAGS 55 ! was 23---bit 5 means retry UAF
$ CLUSTER_DEF TCPIP$SMTP_COMMON SYS$SPECIFIC:[TCPIP$SMTP],-
CLUSTER_TCPIP_SMTP

On 2022-02-02 23:16:15 +0000, Rich Jordan said:

> Is there a good way to configure TCPIP Services on a second system disk
> that is available but not the active system disk? Not a cluster
> configuration; we're using an alternate system disk to stage a new
> server; it is fully config'd but we will need to do a reconfig of TCPIP
> on the 'other' system disk (which will have conflicting addresses)
> before booting it.
> Our alternative is to unplug the LAN cable, boot the second disk, run
> through the reconfigs, then shut down, recable, and boot. Hoping
> there's a better options.

If this is an HPE Integrity Itanium server, configure and use the iLO.
That's how I've been deploying, as it allows easy access into the
target network and into the target server and with a minimal path
established through the target network firewall.

Configure the iLO up for your current source LAN configuration to start
with. Get IP and the rest of the server configured, apps installed, and
the rest. Networking options here include using DHCP on both source and
target network, or using DHCP with an assignment based on the iLO MAC
address source or target network, or acquiring a static address and
details for both the source and target networks, and re-setting the
static address, subnet, and router address as the last step before
packaging and shipping the server for deployment on the target network.
DHCP MAC is probably the easiest and probably also the least
error-prone approach, if you have access to that on both source and
target network.

For this or future deployments, TCP/IP Services can also be configured
to use DHCP with caveats, though it's currently far too stupid to be
all that useful with hosting without manual configuration help
pre-deployment.

What you're doing here is basically the same sequence as setting up
what will be a hosted server.

For anybody doing multiple deployments, TCP/IP Services and the OpenVMS
startup are in need of an overhaul. TCP/IP Services needs to be
platform-integrated and automatically started and with DHCP enabled and
with at least the ssh server and a keypair-key enabled for user SYSTEM,
unless somebody has previously gone through the rest of the TCP/IP
Services configuration process post-installation. Because not all
hosted installations are going to have an iLO- or DRAC-like or IPMI
path. The current UI is piecemeal and archaic and less than easily
automated, unfortunately.

--
Pure Personal Opinion | HoffmanLabs LLC