                             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?
