Perils of Running SYS$MANAGER:NETCONFIG.COM ------------------------------------------------------------------------ Frankly, I don't know how DEC let this problem by. I've called them about it, and they gave me the fix, which I am about to give you, but they still haven't corrected the problem, nor have they given warning of the problem. Anyway, when adding a new member to a VMS Cluster, one of the important steps is to configure the network for that node. This is done by the command procedure SYS$MANAGER:NETCONFIG.COM. Well if you are adding a new node to an existing cluster and configure your new node using this command procedure, all seems well until users try sending each other mail, use the PHONE utility, or even trying to copy files over the network. Next, the users come banging at your door saying they get this message about invalid login information, and they want to go back to their EUNUCHS machine, and dump VMS. You have just been bit by the "NETCONFIG DEFAULT BUG". Ouch! This page has two sections. The first section is how to do it properly, so you don't get bit in the first place. If you ever see the error message "Login information invalid on remote node." then you have already become a victim. The second section deals with fixing your cluster if you are already a victim. ------------------------------------------------------------------------ Section 1 Preventing the Problem When you run NETCONFIG.COM, it asks you questions concerning how you want your network set up. After asking you the questions, it generates another DCL command procedure that actually does the network configuration. The problem comes from running the procedure that NETCONFIG generates as it is built. In it's default form the new command procedure creates network objects and default UAF accounts for those objects, using computer generated passwords. It will change the passwords in the UAF if the accounts already exist, but it fails to tell the network databases of all the other nodes in your cluster and network neighborhood. So, to prevent the problem, DON'T LET NETCONFIG RUN THE PROCEDURE IT GENERATES. Instead let NETCONFIG.COM generate it, then you edit it to use the correct passwords, then you run the procedure. Here is how : (The letters in red indicate what you might type in as responses, click on the underlined question for a description of the question.) $@SYS$MANAGER:NETCONFIG.COM DECnet for OpenVMS network configuration procedure This procedure will help you define the parameters needed to get DECnet running on this machine. You will be shown the changes before they are executed, in case you wish to perform them manually. Clicking on the blue portion of each prompt gives you a window describing what each prompt is asking you about. What do you want your DECnet node name to be ? []: MICKEY What do you want your DECnet address to be ? []: 10.13 The network object database file is SYS$SYSROOT:[SYSEXE]NETOBJECT.DAT;1. Do you want to purge the object database ? [YES]: YES Do you want a default DECnet account ? [NO]: YES Do you want default access to the TASK object disabled ? [YES]: NO Do you want a default account for the MAIL object ? [YES]: YES Do you want a default account for the FAL object ? [NO]: YES Do you want a default account for the PHONE object ? [YES]: YES Do you want a default account for the NML object ? [YES]: YES Here are the commands necessary to setup your system. After this last line, it shows you the commands it has generated, one page at a time, and then asks you if you want to execute them. At this point DO NOT RESPOND TO THIS PROMPT! Instead leave this interactive session alone and log in again elsewhere, and set your default to SYS$MANAGER. There you will find a file called NETCONFIG.TMP. Copy this file (not rename) to a new file. I like to have the new file called NETCONFIG_nodename.COM. For example : $COPY/LOG NETCONFIG.TMP NETCONFIG_MICKEY.COM You can now return to your login session which is still running NETCONFIG.COM, and respond to the last prompt : Do you want these commands to be executed? [YES]: NO No changes have been made. Make sure you respond with a resounding NO. Because if you just press return, the bug rears it's ugly head and bites you despite your best intentions, and then you will be forced to go to section 2 of this page. Now you can edit your new file, and change all the password fields to what you use in the rest of the Cluster. If you don't know what the passwords are, go to an existing node and enter in the command : $MCR NCP SHOW KNOWN OBJECTS This command will show you the current passwords for the important objects. It is a good idea to do this command on all existing nodes and make sure they are the same on all nodes in your network (not just your cluster). If they are not the same, guess what? You have already been bitten, go to section 2, do not pass GO, do not collect $200.00. I have provided another page with an example NETCONFIG_nodename.COM file with all of the password fields colored in red. In this example, I changed all the passwords to DISNEYLAND. ------------------------------------------------------------------------ Section 2 Fixing the Problem So you already have been bitten the last time you added a member to your cluster or network, and you want to fix it before you add another node to the cluster, or you manager decides to scrap all your VMS machines for UNIX boxes. Well it is not as difficult as it may seem. Your first step is to decide what password you want for each object that is enabled. I like to use the same password for all objects. Remember, these steps must be done for all nodes in a network that you plan to have talk to one another, not just members of a cluster. The next step is to fix the User Authorization File for each network node. If you have a common one for a cluster, then you may do this once on any node of the cluster. Enter in these commands : (In all of the examples below, I use DISNEYLAND as an example password. Make sure you use the password you have selected.) $SET DEFAULT SYS$SYSTEM $MCR AUTHORIZE UAF>MODIFY DECNET/PASS=DISNEYLAND/NOPWDEXP/NOPWDLIFE UAF>MODIFY MAIL$SERVER/PASS=DISNEYLAND/NOPWDEXP/NOPWDLIFE UAF>MODIFY FAL$SERVER/PASS=DISNEYLAND/NOPWDEXP/NOPWDLIFE UAF>MODIFY NML$SERVER/PASS=DISNEYLAND/NOPWDEXP/NOPWDLIFE UAF>MODIFY PHONE$SERVER/PASS=DISNEYLAND/NOPWDEXP/NOPWDLIFE UAF>EXIT Once you have done this, you now need to make sure each node's network database is also updated. This is best done by first entering in the proper commands in a command procedure, then executing the command procedure on each node in the network. So create a file called FIXNET.COM to contain the following lines : $MCR NCP DEFINE EXECUTOR NONPRIVILEGED USER DECNET DEFINE EXECUTOR NONPRIVILEGED PASSWORD DISNEYLAND DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD DISNEYLAND DEFINE OBJECT FAL USER FAL$SERVER PASSWORD DISNEYLAND DEFINE OBJECT PHONE USER PHONE$SERVER PASSWORD DISNEYLAND DEFINE OBJECT NML USER NML$SERVER PASSWORD DISNEYLAND $EXIT Now you want to execute this command procedure on all nodes in your network. If you are in a Cluster, you might want to use the SYSMAN utility to execute it on all Cluster nodes. Just make sure the file is accessible to all nodes in the Cluster. Once this is done, you need to reboot all of your nodes to make sure everybody comes up nice and clean with their new databases. Afterwards, you should check it out by mailing to and from two nodes, try the Phone utility, and try performing DIRECTORY commands on other nodes to see if you did it right. It's also a good idea to check all of your nodes to make sure they don't have other network objects that may have to be fixed, like the MIRROR object. For more information, see the guide to Networking manual. ------------------------------------------------------------------------ If you have any questions or problems with the above procedure, please feel free to eMail me with the specifics of your problem or question. ------------------------------------------------------------------------ My Home Page | VMS Home DCL | Utilities | Management | Tips FORTRAN | Pascal eMail Questions Quiz?