SENDNET ------- ---------------------------------------------- Version : 1.0 Date : Aug 28 1984 Author : J.Dutertre Address : IFP BR311, 92506 Rueil Malmaison CEDEX France Telephone : (1) 749 02 14 copyright J.Dutertre 1983,1984 ---------------------------------------------- A utility to keep a VAX network application software under control and to remotely do other things on other nodes if necessary .... 1 WARNING This is the first version of SENDNET. Even though the documentation has been refurbished for this first DECUS release, it is a first release... The author welcomes any comment. SENDNET is a system oriented utility which could be used to damage a system. IFP can not be held responsible for any eventual damage caused by SENDNET to your system. 2 INTRODUCTION It is a difficult task to keep a growing network under control. It is as difficult to keep track of the hardware as it is to manage the software. Some packages must be updated on some systems, some on others, some on all systems, SYSTARTUP and LOGIN files must be kept under control, yet it is not convenient to log onto each system to carry on the updates then clean up. Not only does it take time but it is often impossible to do it on all systems at the time one would like to do it. If one can not do it then one can forget to do it on some nodes... The main purpose of SENDNET is to have all VAXes of a network up to date. I.e, when one utility of a development node has been updated, be certain that all other VAXes, where that utility is to be updated, are updadted. Page 2 The idea is to propagate the upgrades with one single command, whether the other VAXes are up or not and whether communication lines are active or not or even go down during any given transfer. Notwithstanding what happens after a request has been sent, any new request will be done following a previous one. When updating a package, the programmer doesn't need to remember on which VAX of the network the files should be updated. This can be set to be automatic. On our site, SENDNET is included at the end of a procedure which moves files from a development directory into a working directory where it is accessed by the users. SENDNET can be used to do things remotely (like stopping and restarting DEC-NET on a remote node) SENDNET can be used to execute a command remotely ... SENDNET is open ended and operation codes can easily be added by the system manager to adapt the package to it's own needs. SENDNET has build security assuming that the network has coherent UICs. It also has the notion of master nodes from which privileged users can do drastic things anywhere in the network. SENDNET uses list of nodes contained in files in order to be able work with a subset of the entire network. 2.1 SENDNET CURRENT OPERATION CODES 1 copy 2 copy followed by purge 3 copy followed by purge then @ (watch out friend..)(*) 4 unused 5 print a file on a remote printer 6 unused 7 same than 2 but does MC INSTALL 'file'/replace (*) 8 unused 9 executes a one line command (*) 10 route files back and forth to an outside HASP system 11 route back from above .. ... 99 cleaning up of SENDNET problems on remote nodes (*) (*) means reserved to priviledge users. for code 7, the .EXE must have be installed once by SYSTEM New codes can very simply be added. Page 3 2.2 CONVENTIONS In the present text, a word in lower case characters and placed between quotes represents a variable. For example SENDNET.'localnode' represents file SENDNET.R10 on node R10. 2.3 NETWORK UIC It is supposed that the entire network is coherent as far as UICs go. DEC-NET has a UIC of [17,1] 2.4 NETWORK LOGICAL SET UP. All VAXes have the same system wide logicals available. When copying a file to a remote node, SENDNET checks that the target file uses a logical name. All SENDNET programs and procedures must reside in system wide logical IFP: Two directories are used on each VAX: NETUSER$DEMANDES for incoming and outgoing requests NETUSER$REPONSES for logical ACKs or NACKs from remote targets. Acces to both these directories is (G:REW,W:R). They are owned by DEC-NET. When copying files, sendnet assumes that the target is a logical. On our network, groups of users can use a logical GROUPE: pointing to a directory . This logical is defined on each VAX where that group has an activity. 2.5 SECURITY 2.5.1 PROTECTIONS - Whenever an update is to be done on a given node, SENDNET checks that a file SENDNET.DAT exists in the target directory. It is up to the owner of that directory to create that file. This file contains the remote UICs authorized to update the directory via SENDNET. If this file doesn't exist or if it doesn't contain the UIC of the sender, the update is aborted. Page 4 Presently, only the group is used. In a coming(?) improvement an authorization will be based on NODE:[GROUP,MEMBER] with wild cards allowed. 2.5.2 AUTHORIZATION - In addition to protection checks, some operation codes can only be used by authorized usernames and can only be sent from a master node. The authorized usernames are found in SYS$MANAGER:SENDNET.PRV, one username per line. The master nodes are initialized in program SENDNET.FOR in variable MASTERNODE. In the current version, the files containing the request are in ASCII and on top of thus, documented. This makes it very simple to a system manager to edit an artificial request and have it submitted onto another node. He therefore has the ability to do dirty tricks anywhere. In the present system, all system managers are supposed to cooperate. This situation can change as our network grows.... In order to protect the network from such problems, the files containing the requests will, in a "coming major release", be encrypted. 2.6 KEEPING TRACK OF WHAT GOES ON A line down or a VAX down is not considered as an impossibility to update. Simply, the update will automatically be done later on. When things go wrong during an update, i.e. when the procedures CAN NOT do the update, (for example an authorization file SENDNET.DAT is missing in the target directory), a MAIL is sent to a user SENDNETMANAGER which is initialized in procedure SENDNET3.COM. 2.7 TARGET VAXes ALL nodes known to SENDNET are contained in a file IFP:SENDNET.NET, one node per line. Example: R2 R10 S20 On any given node a file IFP:SENDNET.'localnode' can exist. It contains a subset of the known nodes. This list of nodes will be used Page 5 to limit the nodes accessible from that local node. Because all application softwares or files are not always implemented on all VAXes of the network, SENDNET provides various means to control the targets VAXes. Files can be used to specify subsets of the entire network. This is usefull when a package is not implemented on all nodes. These targets can be overriden by the user (programmer) but this is not normally necessary. The idea of the whole thing beeing to have everything automatic. 2.8 VAX CLUSTER Some of our VAXes are in a cluster, some are not. With VMS3.x utility files can be shared within the cluster. They are shared in read access only. When using DEC-NET, it is not possible to know if a VAX belongs or not to a cluster. The request for update is therefore sent but the actual update is only done if the utility on the target VAX has write acces to the target disk. This will probably have to be modified for VMS4. 2.9 TARGET NODES Whenever a request is sent, the following method is used to find the target nodes. Note that these rules are given in the order of priority, i.e. first rule which matches is used: All nodes which can be reached by SENDNET are contained in file IFP:SENDNET.'localnode' (or by default in file IFP:SENDNET.NET) one node per line. All other nodes are unknown. 2.9.1 CONVENTION ON EXTENSIONS - Any file which extension is a node name will only be sent to that node. We use that convention to manage LOGIN files for instance: On our development VAX we maintain LOGIN.COM which is a network wide login which then calls one of ... LOGIN.R1 which is specific to node R1 LOGIN.R2 which is specific to node R2 ..... ...... This makes life much easier as all updates to a login are edited on the same node. (If in addition you are an EMACS fanatics you can Page 6 place your entire network logins on one screen...). Because file extensions can be used for node names, these names should be less than 4 characters. This limitation will disappear with VMS4.?. whenever that comes... 2.9.2 DESTINATION NODES - A qualifier can be used to specify the destination nodes: /NODE=('node1','node2'...) only the specified nodes will be accessed. 2.9.3 DISTINATION FILE - 2.9.3.1 /NODE=WORLD - File SENDNET.'localnode' is used 2.9.3.2 /NODE=ALL - is the default. With this option, SENDNET will use a file to find the destination nodes. It looks for the following files (and uses the first one found): 'filenameroot'.NET SENDNET.NET <->SENDNET.NET recursively until directory root is reached IFP:SENDNET.'localnode' IFP:SENDNET.NET 2.9.3.3 /NOLOCAL - Qualifier /NOLOCAL can be added to /ALL or /WORLD. If this qualifier is present the local node will not be reached by the update. This is valid for /ALL and /WORLD 2.9.4 REMARK - It is clear that this principle of operation implies that, when requesting the transfer of a file, SENDNET must be used from the development directory which contains the file to send. If this is not the case, subroutine GETNOEUDCIBLE should be modified. Page 7 2.10 TARGET LOGICALS During copy operations, le target file name must contain a logical acceptable to the destination node. In the present version, no check is done on that logical. The following rules are used: - The target file name defaults to the name of the file to send. - If the target file name contains something which looks like a logical name, that logical target name is used. - If no logical name is found, the programe looks for a file SENDNET.TAR, going up the current directory tree and using the first one found. That file must contain a logical name. - If no file SENDNET.TAR is found then the target logical defaults to "GROUPE:". This is programmed in subroutine CHECKLOGICAL.FOR 3 PRINCIPLE OF OPERATION SENDNET was not written by a VAX wizzard but by a Network Manager who had a problem on hand ... and no wizzard available! No need to explain that it is a robust but unsofisticated tool. It could be improved at least 100%. If you want to do it I will be glad to use your version. I do respect wizzards... 1. a programmer uses an installed program IFP:SENDNET.EXE to create files containing requests in NETUSER$DEMANDES. There is one such file per request and per node to reach. A request is of the form NETUSER$DEMANDES:'123456789'.'targetnode' NETUSER$DEMANDES:'123456789'.DAT Where '123456789' is a unique file name computed using the date and 'targetnode' is the node to reach. (With VMS4, this file name will also contain the originating node name to make it really unique on the entire network). The first file contains what to do and all necessary information. The second file is the actual file to be transfered. Note that this file is not always present. 2. a procedure IFP:SENDNET2.COM, which should be activated by SYSTEM every n minutes (that is up to you and can vary from VAX to VAX) takes any new request and copies it onto the requested 'targetnode' as: NETUSER$DEMANDES:'123456789'.NEW When this is done, the original NETUSER$DEMANDES:'123456789'.'targetnode' is renamed Page 8 '123456789'.OLD. Procedure IFP:SENDNET3.COM, which should also be activated regularly by SYSTEM, takes any new request, opens it, does what is requested if it can (for instance copy '123456789.DAT' somewhere then purge). It copies '123456789'.NEW back on to the originating node as NETUSER$REPONSES:'123456789'.OK and cleans up the local NETUSER$DEMANDES. If it can not do it for any other reason than DEC-NET beeing down, it copies back '123456789'.NEW as NETUSER$REPONSES:'123456789'.PB and sends a MAIL to SENDNETMANAGER (see SENDNET3.COM). 3. Procedure IFP:SENDNET4.COM cleans up NETUSER$DEMANDES and NETUSER$REPONSES deleting '123456789'.*.* when '123456789'.OK is found. This procedure is called at the end of IFP:SENDNET3.COM Therefore when every thing goes well, directories NETUSER$DEMANDES and NETUSER$REPONES should automatically clean up. When things go wrong, either some NETUSER$REPONSES:*.PB appear or NETUSER$DEMANDES:'123456789'.OLD and .DAT files remain hanging. Note that procedure IFP:SENDNET5.COM can be used to clean things up. 4 CREATING REQUESTS Originally, SENDNET was a tool available to higher level procedures. It has evolved to a stand alone tool. Either SENDNET.EXE is built as a command or you must define $ SENDNET:=="$IFP:SENDNET.EXE" See the help file for additionnal information. 5 GETTING STARTED To get started use only one node of your network. 5.1 PREPARING THINGS Note: because of a file name conflict during our last change of version, SENDNET.FOR and SENDNET.LIB are found on the tape as SENDNETB.FOR and SENDNETB.LIB. Page 9 1. get the contents of the tape in WORK: 2. create NETUSER$DEMANDES and NETUSER$REPONSES [17,1] G:REW,W:R 3. create SYS$MANAGER:SENDNET.PRV one username per line 4. edit SENDNET.FOR to define your master(s) node(s) 5. compile and link using SENDNET.OLB and UTL.OLB 6. transfer SENDNET.EXE to IFP: install it /PRIV 7. transfer SENDNET.HLP in whichever HELP library your want (we avoid the system help librairies so that our things dont get mixed up with DEC's). Note that it doesn't contain any level 1. A level 1 should be added before placing the .hlp file in library. 8. edit SENDNET3.COM to fix SENDNETMANAGER to 'your node'::'yourself' 9. transfer SEND*.COM to IFP: PROT=W 10. create IFP:SENDNET.NET containing the very node you are on and only that one for testing purposes. 11. take a target directory and call it say TARGET:, make this a system wide logical. 12. create TARGET:SENDNET.DAT containing your group UIC (say 077 if you are from this group) 5.2 USING SENDNET 1. let $ SENDNET:=="$IFP:SENDNET" 2. prepare a file say TRY.COM 3. $ SENDNET/NODE='localnode' TRY.COM TARGET:TRY.COM or $ SENDNET/LOCAL TRY.COM TARGET:TRY.COM This should create files NETUSER$DEMANDES:123456789.'localnode' and the corresponding .DAT 4. @IFP:SENDNET2 to send the request this should create a file 123456789.NEW and rename file .'localnode' as .OLD 5. @IFP:SENDNET3 which will do the actual copy and clean up the directories. At that point you should be able to set SENDNET up on the entire network to suit your needs.