OpenVMS TCPIP unattended configuration

[Andreas Vollmer]

Hello,
For an OpenVMS upgrade to OVMS V7.-2 with TCPIP V5.4 of approx. 180 OpenVMS AlphaServers I would like to automate (via DCL scripts) as much tasks as I could.
How to do a TCPIP configuration without using the menu?
Who can help me? Which commands to use.
Assume the new created system disk is a "virgin". So no TCPIP*.DAT files exists.
I am interested in how to create the DAT files or will these auto created when issueing the first configuration command such:
TCPIP SET CONFIGURATION INTERFACE WE0 /NETWORK_MASK=255.255.0.0.
The TCPIP docu does not explicit refering to an unattended installation option and how to do it.
Your feedback is very much appreciated.

[Andreas Vollmer]

Andreas: Correction: the OS version is OpenVMS V7.3-2

Sorry for the confusion

[Martin P.J. Zinser]

Hello Andreas,

Assuming the 180 systems are setup to be similar (or at least there are big subsets that are similar), I would configure one master system fully, then clone the disk (e.g. shadow copy, SA backup).
With this disk boot the other systems, change system names/network addresses and off you go.

Another way to share much of the configuration is obviously a cluster with shared files ;-)

Greetings, Martin

[Mike Naime]

You have to type in the information at some point, and we have decided that doing it interactively when we create the OS root takes less time than trying to make scripts to do it automatically.

If this is a new system that does not have an active TCPIP interface, and you only have console access to the disk, you are not going to be able to copy/FTP your script there anyways! You could possibly Copy/Paste from one windows session into another session.

Pro - You think that it takes less time???
CON - If you are not watching, you will never catch any problems!

We also clone new roots. I have a DS20 dedicated to this that is called CLONE1. This see's all of the HSG's that I might want to clone an OS pack too. So while I have file cabinets full of licenses, we use the same licenses on almost all of our systems.

After a BACKUP/IMAGE of the OS pack. I have about an hours work (Including re-boots) to set the Node Name, Decnet Parameters, IP parameters, Timezone... Etc.

When you change the node name, it whipes out the IP configuration. Running through @TCPIP$CONFIG will allow you to setup the TCPIP parameters fairly easily. This may be the command script that you are looking for.

What I do (Condensed)
Edit Modparams.dat (Change node and decnet)
Set cluster parameters. (SYSMAN)
Autogen re-boot.
@net$configure
@utc$time_setup
mcr decnet_register
@tcpip$config
Re-boot.
(IF network is connected)
Setup mail.
Setup NTP.

Overall, about an hours work per root. 4-node cluster = 4 hours.

[Andreas Vollmer]

Hello Martin,
Hello Mike,

Thanks a lot for your feedback.
Yes, cloning of the system disk we have in mind by using a prepared master disk.
But the mentioned 180 servers are distributed in several countries within Europe. For sure these systems are productive. On the D-Day we have only a very limited maintenance window and therefore, additional we will switch from DECnet Phase 4 to DECnet Plus.
We would like to gather the current network settings and transfer these over to the new system disk.
Yesterday I found out there is a "semi" silient installation mode for TCPIP.
By providing two parameters, P1 & P2, when calling TCPIP$CONFIGURE.COM => "SERVER" "ENABLE". This surpresses the sometimes nasty menu and the interactive answering are really reduced. I used the word "semi" because there are still some
interactive questions issued be the procedure.
But the DB files are created! The next step is to configure the all node specific parts via the CLI instead by using the gathered network information.
I have to do some more tests. As soon I have more information I will provide more information.

On one hand you are right if you question the effort to reduce the manual intervention but this task will be repeated with the next OpenVMS release again...
Also we would like to update as much as possible systems at the same day. 1 hour per system just for the OS is too much. We must also upgrade ORACLE RDB and our own written application etc...

So far, thanks a lot for the hints and any more suggestions are welcome.
Let me know if you are interested in my findings.

[Martin P.J. Zinser]

Hello Andreas,

actually we do run kinda-sorta a similar network, the only difference being that we do not have Rdb out in the field, but only at our main datacenter.

One thing we found useful is to separate OpenVMS and application upgrades. There are two main reasons for this:

1.)It makes trouble shooting much easier. If you do run into an issue after D-day, it can be either VMS (+ layered products), Rdb, or you own application, plus all kinds of interactions between them. This makes for a "fun" excercise at trouble shooting in a production environment. Taking out the OS upgrade at least does reduce the complexitiy considerably. And yes, I am convinced you do dilligent testing (I know we do ;-), but unless you have mathematically proven your application is correct (few people do) there is always a chance of trouble.

2.)It allows you to stagger the OS introduction, avoiding an (OS) D-day alltogether, giving an additional safety margin (The application changes in our case also on a specific release weekend).

All the best,

Martin

[Mike Naime]

From your description, I am assuming that you are making a new OS pack for each node/cluster that you are maintaining and replacing the OS pack in your SAN cabinets. Why don't you boot these disks against a standalone Alpha so that you can check all of these settings ahead of time? This one hour of configuration per system does not necessarily have to occur on the D-DAY. You might realistically have 300-400 hours of prep time to make all of your OS packs ready to go. This includes installing the new spindles into the SAN cabinets, Creating the units, Cloning the OS, Configuring the OS, verifying that EVERYTHING is correct, and then labeling and removing it from your SAN cabinet. Realistically, this is at least a 2-hour procedure for a one root OS pack. This way you could say without a shadow of doubt that everything was indead ready for Downtime-Day. Shutdown one OS pack, and boot from the other.

What are your back-out procedures? and how much time is alloted for them? Or is that not part of managements planning. (Nothing ever goes wrong, or is delayed. Correct!)

It sounds like you have a much smaller maintenance window than should realistically be allowed for the maintenance tasks that you are performing. I know that Oracle Upgrades to a Live production cluster can mean up to 24 hours of downtime depending on the size of the DB. In comparison, my VMS upgrade is miniscule.


You have me beat on sheer number of Alphaservers. I have 156 with about 20 more on order. But mine are all in one data center!

Our clients allow for the quarterly/yearly maintenance activities that we require. We ask for a 4 hour window for a VMS Upgrade, OS Patches, Firmware, Layered Products, Oracle re-link, Time/Timezone, Re-boots and checks. This also allows us time to backout the changes if they do not work.

We used to do VMS upgrades in a 2 hour downtime window*, but then NOTHING can go wrong, and delays in shutting down the app/OS can send you over your 2 hour window.

* VMS Upgrade portion depends on the speed of the Alpha performing the upgrade.


What are you doing about Printer queues, UAF files, NTP, Mail/SMTP, ...Etc. All stuff that is potentially on the OS pack? Too me, there is just too much that could go wrong with so little time to do it in.


Are all of your Alphaservers the same hardware type? I.E. ES40's? or do you have a mixture. If you build this OS disk on a DS20, and then you move it to an ES40, you may need to perform an Autogen re-boot agains an ES40 prior to adding the OS pack to your production ES40. Otherwise your Alphavmspar files may get you.


Martin brings up a very good point about seperating your downtime work. If you really want to prove that there are no application bombs waiting to explode in your face, a full re-boot is required. This can add up to an hours time onto any maintenance window. (How long do your systems take to fully boot?) But it does prove if your maintenance messed it up or not.


Personally, I think that you are being setup for failure with your current implementation plan. There is too much that could go wrong with not enought time to do it in!

[Mike Naime]

After further thought on this subject.... Have you considered the following:

(Repeat this for each cluster/OS pack)
Take a backup of your current OS pack. Restore the backup to a new disk.
VMS Upgrade the disk.
Apply any OS patches.
You now have a disk that is possibly*** ready to be placed into your existing cluster.

*** The Autogen re-boot will perform changes based on the hardware that is present at the time. If you have similar hardware, use this.

Note: Any changes that have been made after the time of the backup will be lost. (UAF, Printers... Etc)


The only way to fully avoid any loss of data is to perform the VMS upgrade during a downtime window. Make sure that your management knows the risks that they take by attempting to do the VMS upgrade offline.

I would not be too surprised if you find that you need to run Autogen and re-boot as a final step in your procedure. Or to fix your systems if you don't.

[Andreas Vollmer]

Hello Again,

Again many thanks for your feedback.
No, the mentioned servers are not in ONE datacenter and the system are not clustered nor we do use a SAN for them, just standard Ultra3-SCSI disks (MA)...
Each system is a DS10 with 1GB or 2GB memory and these have all the sam configuration. We are using hostbased volume shadowing (HVS).
On the D-Day we will dismount one shadowset member and this will be untouched (for sure we run before backup!).
If something goes wrong we can always reboot from that preserved shadowset member and continue the production.

Your agruments are correct referring to the fact if doing to much at the same time the risk is increasing that all could go wrong.
I will consider this.

Yes, considering the LPR/LPD print queues are also important to move.
The UAF settings are quite standardised...

We keep in touch.
BR
Andreas

[Martin P.J. Zinser]

Hello Andreas,

how about the old suggestion of moving your config files actually off the system disk? A short $show log tcpip* shows that all kinds of config files are actually referenced by logical names. So how about this: Prepare the config files for the systems before the rollout, ship them to the systems in the field (diskspace should not be a problem in this case ;-). Add an appropriate sylogicals to your master disk and you should be able to run this excercise with only one installation, that is the same for all systems.

Greetings, Martin