.RM75 .center ;SENDNET .center ;------- .S4 .lm 5 .literal ----------------------------------------------- Version : 2.0 Date : May 19 1985 Author : J.Dutertre Address : IFP BP311, 92506 Rueil Malmaison CEDEX France Telephone : (1) 749 02 14 copyright J.Dutertre 1983,1984,1985 ----------------------------------------------- .end literal .S4 A utility to keep a VAX network application software under control and to remotely do other things on other nodes if necessary .... .HL1 WARNING This is the second version of SENDNET. .BR;Even though the documentation has been refurbished for this first DECUS release, it is a first release... .BR;The author welcomes any comment. .S1;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. .HL1 INTRODUCTION It is a difficult task to keep a growing network under control. .br;It is as difficult to keep track of the hardware as it is to manage the software. .BR;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 at the time one wishes to do it, then one can forget and some nodes might lag behind. .S1;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. .br;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. .br;Notwithstanding what happens after a request has been sent, any new request will be done following a previous one. .S1;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. .s1;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. .S1;SENDNET can be used to do things remotely (like stopping and restarting DEC-NET on a remote node) .S1;SENDNET can be used to execute a command remotely ... .S1;SENDNET is open ended and operation codes can easily be added by the system manager to adapt the package to it's own needs. .S1;SENDNET has build in 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. .S1;SENDNET uses list of nodes contained in files in order to be able work with a subset of the entire network. .S1;SENDNET was adapted to VMS4.x but refurbishing should be done for UICs. .S1;SENDNET understands the specificity of cluster and can manage more than one cluster. .HL2 SENDNET CURRENT OPERATION CODES .literal 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 (*) .end literal .s1;(*) means reserved to priviledge users. .s1;for code 7, the .EXE must have be installed once by SYSTEM .S1;New codes can very simply be added. .HL2 CONVENTIONS In the present text, a word in lower case characters and placed between quotes represents a variable. .br;For example SENDNET.'localnode' represents file SENDNET.R10 on node R10. .HL2 NETWORK UIC It is supposed that the entire network is coherent as far as UICs go. .S1 DEC-NET has a UIC of [17,1] .HL2 NETWORK LOGICAL SET UP. All VAXes have the same system wide logicals available. .S1 When copying a file to a remote node, SENDNET checks that the target file uses a logical name. .S1 All SENDNET programs and procedures must reside in system wide logical IFP: .S1 Two directories are used on each VAX: .S1 NETUSER$DEMANDES for incoming and outgoing requests .S1 NETUSER$REPONSES for "ACKing" or "NACKing" files from remote targets. .S1 Acces to both these directories is (G:REW,W:R). They are owned by DEC-NET. .S1 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. .HL2 SECURITY .HL3 PROTECTIONS .S1;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. .S1;If this file doesn't exist or if it doesn't contain the UIC of the sender, the update is aborted. .s1;Presently, only the group is used. In a coming(?) improvement an authorization will be based on NODE:[GROUP,MEMBER] with wild cards allowed. However, this need to take VMS4 into account and has not been done in this version because lack of time and because it work as it is. Could be improved though... .HL3 AUTHORIZATION .s1;In addition to protection checks, some operation codes can only be used by authorized usernames and can only be sent from a master node. .S1 The authorized usernames are found in SYS$MANAGER:SENDNET.PRV, one username per line. .S1 The master nodes are initialized in program SENDNET.FOR in variable MASTER_NODE. .S1;In the current version, the files containing the request are in ASCII and on top of this, documented.... .br;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.... .br;In order to protect the network from such problems, the files containing the requests will, in a "coming major release", be encrypted. .HL2 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. .S1 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 SENDNET_MANAGER which is initialized in procedure SENDNET3.COM. .HL2 TARGET VAXes ALL nodes known to SENDNET are contained in a file IFP:SENDNET.NET, one node per line. .S1;Example: .s1;R2 .br;R8/C1 .br;R9/C1 .br;R10/C1 .br;S20 .br;B20/CLUST .br;B21/CLUST .s1 In this example, seven nodes are defined together with two clusters. Nodes R8 and R9 belong to cluster C1 and nodes B20 and B21 belong to cluster CLUST. The names given to clusters are only used by sendnet and have nothing to do with DEC's numbering or naming conventions. .S1;Node names however must also be DEC-NET node names. .S1;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 to limit the nodes accessible from that local node. .S1;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. .s1;Files can be used to specify subsets of the entire network. This is usefull when a package is not implemented on all nodes. .S1 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. .HL2 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: .S1;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. .HL3 CONVENTION ON EXTENSIONS .S1;Any file which extension is a node name will only be sent to that node. .br;We use that convention to manage LOGIN files for instance: .s1;On our development VAX we maintain .literal 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 ..... ...... .end literal 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 place your entire network logins on one screen...you might need a large screen though). .S1 SENDNET will use file extensions for node names. Thanks to VMS4, this nodes can now be more than 3 caracter long. .HL3 DESTINATION NODES .S1;Qualifier can be used to specify the destination nodes: .literal /NODE=('node1','node2'...) only the specified nodes will be accessed. /CLUSTER the nodes belonging to the same cluster will be reached. .end literal .HL3 DISTINATION FILE .HL4 /NODE=WORLD .BR;File SENDNET.'localnode' is used .HL4 /NODE=ALL .BR;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): .S1 .BR;'filenameroot'.NET .BR;SENDNET.NET .BR;<->SENDNET.NET recursively until directory root is reached .BR;IFP:SENDNET.'localnode' .BR;IFP:SENDNET.NET .HL4 /NOLOCAL .BR;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 .HL4 /WIDE By default only one node per cluster will be reached. This is usually the case as utilities are shared by all nodes of a cluster. This corresponds to the /NOWIDE option. .S1;To force requests on all nodes, use /WIDE .HL3 REMARK .S1;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 GET_NOEUD_CIBLE should be modified. .HL2 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. .br;The following rules are used: .s1;- The target file name defaults to the name of the file to send. .S1;- If the target file name contains something which looks like a logical name, that logical target name is used. .S1;- 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. .S1;- If no file SENDNET.TAR is found then the target logical defaults to "GROUPE:". This is programmed in subroutine CHECK_LOGICAL.FOR .HL1 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! .br;No need to explain that it is a robust but unsofisticated tool. .br;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... .list .le;a programmer uses an installed program IFP:SENDNET.EXE to create files containing requests in NETUSER$DEMANDES. .br;There is one such file per request and per node to reach. .S1;A request is of the form .s1;NETUSER$DEMANDES:'123456789'.'targetnode' .BR;NETUSER$DEMANDES:'123456789'.DAT .s1;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). .br;The first file contains what to do and all necessary information. .br;The second file is the actual file to be transfered. Note that this file is not always present. .le;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: .S1;NETUSER$DEMANDES:'123456789'.NEW .s1;When this is done, the original NETUSER$DEMANDES:'123456789'.'targetnode' is renamed '123456789'.OLD. .S1;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). .BR;It copies '123456789'.NEW back on to the originating node as NETUSER$REPONSES:'123456789'.OK and cleans up the local NETUSER$DEMANDES. .S1;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 SENDNET_MANAGER (see SENDNET3.COM). .le;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 .S1;Therefore when every thing goes well, directories NETUSER$DEMANDES and NETUSER$REPONES should automatically clean up. .S1;When things go wrong, either some NETUSER$REPONSES:*.PB appear or NETUSER$DEMANDES:'123456789'.OLD and .DAT files remain hanging. .s1;Note that procedure IFP:SENDNET5.COM can be used to clean things up. .END LIST .HL1 CREATING REQUESTS Originally, SENDNET was a tool available to higher level procedures. It has evolved to a stand alone tool. .s1;Either SENDNET.EXE is built as a command or you must define .s1;$ SENDNET:=="$IFP:SENDNET.EXE" .S1;See the help file for additionnal information. .HL1 GETTING STARTED Unfortunatly, this section has not been check to well. You might find some errors. Remarks or improved version would be appreciated. .s1;To get started use only one node of your network. .hl2 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. .list .le;get the contents of the tape in WORK: .le;create NETUSER$DEMANDES and NETUSER$REPONSES [17,1] G:REW,W:R .le;create SYS$MANAGER:SENDNET.PRV one username per line .le;edit SENDNET.FOR to define your master(s) node(s) .le;compile and link using SENDNET.OLB and UTL.OLB .le;transfer SENDNET.EXE to IFP: install it /PRIV .le;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. .le;edit SENDNET3.COM to fix SENDNET_MANAGER to 'your node'::'yourself' .le;transfer SEND*.COM to IFP: PROT=W .le;create IFP:SENDNET.NET containing the very node you are on and only that one for testing purposes. .le;take a target directory and call it say TARGET:, make this a system wide logical. .le;create TARGET:SENDNET.DAT containing your group UIC (say 077 if you are from this group) .end list .HL2 USING SENDNET .list .le;let $ SENDNET:=="$IFP:SENDNET" .le;prepare a file say TRY.COM .le;$ SENDNET/NODE='localnode' TRY.COM TARGET:TRY.COM or .br;$ SENDNET/LOCAL TRY.COM TARGET:TRY.COM .br;This should create files NETUSER$DEMANDES:123456789.'localnode' and the corresponding .DAT .le;@IFP:SENDNET2 to send the request .br;this should create a file 123456789.NEW and rename file .'localnode' as .OLD .le;@IFP:SENDNET3 which will do the actual copy and clean up the directories. .end list At that point you should be able to set SENDNET up on the entire network to suit your needs.