Inside VESOFT #15 (multi-cpu security)
by
Shawn Gordon
Many moons ago I was the System Manager at L.A.Gear. This is back when they had money and were very cutting edge with HP. We were the first in line for all the latest, biggest CPU’s and OS upgrades. I think we had the first 980-200, and we were one of the first to run Oracle on the 3000. As part of this we were running 7 CPU’s and some people needed to have access to more than one system. It became critical that we could have central management of the security profiles and to also make sure that any changes made by the end user to their profile would be propagated across the relevant machines.
In those days it seemed that I was the first to do almost anything, and the network security feature of Security/3000 was no exception. Since then the feature has gotten a bit easier by using the BACKG background job for the push and pull processes, but it is still a bit difficult and confusing to set up initially, so let’s talk about it this month. I’m going to cover this in two parts because of the size, this month will cover just 2 machines, and next month will cover how to configure ‘n’ machines.
There are a large number of issues you have to take into account. A simple example is if you want to have Security/3000 “trust” logons from systems where you have already logged on successfully. This has the advantage of making multi-cpu logons easier and more seemless for the user, you can put remote logons into a menu for example. This can be managed entirely within the SECURCON.DATA.VESOFT file by setting an exclusion set to the $VEPROFILE option using the $NO-VEPASS option. You will also want to identify each system by setting $SYS-NAME in the SECURCON file to the name of the system, you can then use this name on other systems to reference.
Let’s consider a simple example: let’s say that you have two machines, STAN and KYLE, whose nodenames are NODEA and NODEB. (Although it’s recommend keeping the NODE name the same as the $SYS-NAME, this example will use different names in order to be complete.) You want to have all the additions, changes, and deletions on STAN (NODEA) automatically reflected on KYLE (NODEB). What should you do?
1. You must tell SECURITY on system STAN that you want to send all the
SECURITY user profile change information to system KYLE.
2. You must tell SECURITY on system KYLE that you want to receive the
information from system STAN.
3. You must tell SECURITY on system KYLE exactly which changes from STAN
you want reflected on KYLE.
4. You must start the NETRECV task executing under the BACKG job on system
KYLE, to receive update notifications from STAN and implement them on KYLE.
First, configure system STAN to send profile information to KYLE. You would
do this by adding the following lines to your SECURCON.DATA.VESOFT file:
$SYS-NAME "STAN" $NET-SEND KYLE
Note that the $SYS-NAME keyword indicates the name of the LOCAL system (in this case, STAN), and the $NET-SEND line indicates the name of the REMOTE
system that will receive profile updates (in this case, only system KYLE will be receiving changes). The “system names” don’t need to be your actual node names or DSLINE device names, but I think it makes it more convenient. In reality they are the names which SECURITY uses to identify your machines.
Second, configure system KYLE to pull (receive) profile change information from system STAN. You will need to build a file called NETRECV.DATA.VESOFT on system KYLE. For our example, the file contains the following line:
$FROM-SYS NODEA STAN
This means: “pull (receive) SECURITY user profile information from the system called STAN using the node name (or DS/3000 device name) NODEA to log on to the remote system”.
While you’re doing this, you should also make sure that your SECURCON.DATA.VESOFT file on the receiving system (in this example, system KYLE) contains an appropriate $SYS-NAME line, e.g.
$SYS-NAME "KYLE"
Third, after building the NETRECV.DATA.VESOFT file shown above, you should build one more file on system KYLE — this one should be called
STAN.NETRECV.VESOFT, and it will tell SECURITY exactly what it should do with the user profile information it gets from system STAN.
Again, referring to the example we are building, we want to maintain exactly identical profiles, so we need to set up the STAN.NETRECV.VESOFT file as follows:
$RECEIVE @ !HPJOBNAME,!HPUSER.!HPACCOUNT @.@
Note that you can specify more than one remote userset for a $RECEIVE keyword, the general format of which is:
$RECEIVE operations localuserset remoteuserset [remoteusersets]
Here are some examples and their explanation:
$RECEIVE CHANGE !HPJOBNAME,!HPUSER.GL @.AP
$RECEIVE ADD,CHANGE !HPJOBNAME,!HPUSER.!HPACCOUNT @.@-@.AP
$RECEIVE DELETE !HPJOBNAME,!HPUSER.!HPACCOUNT @.TEST @.DEV
* Any CHANGEs to any AP account user on system STAN are to be reflected on
system KYLE as changes to a user with the same job/session name and user
name but in the GL account. The important point here is that the third
parameter indicates which remote user IDs are to be monitored, while the
second shows which user IDs on the local system they correspond to. In
this case, you would need the same MPE accounting structure on system KYLE
in the GL account as you do on system STAN in the AP account.
* Any ADDitions or CHANGEs to any user on system STAN except for those in
the AP account (@.@-@.AP) are to be reflected on system KYLE as additions
or changes to the same user ID. The "!HPJOBNAME,!HPUSER.!HPACCOUNT"
merely tells SECURITY to keep the same user ID.
* Any DELETEs of users in the TEST or DEV accounts on system STAN are to be reflected on system KYLE.
In this case, additions of new users to the AP account on system STAN are not automatically reflected on system KYLE; similarly, deletions of users on system STAN are not automatically reflected on system KYLE except in the DEV and TEST accounts. This is intentional — often you want to maintain somewhat different configurations on two systems, with some users existing on one but not on the other.
I think that is about all I can squeeze into this month. We’ll cover more in our next installment.