Quest Sponsor Message

Multi-CPU Security

By Shawn M. Gordon

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX. As always, I am totally open to getting input from you users of MPEX, Security/3000 or VEAudit/3000 — it helps me learn, too. Send me your tricks, and we’ll get a “3000 for 2000” cap out to you as our thanks.

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 CPUs and OS upgrades. I think we had the first 980-200, and we were one of the first to run Oracle on the 3000. We were running seven CPUs and some people needed to have access to more than one system. It became critical to have central management of the security profiles. We also wanted to make sure that any profile 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 because of the use of the BACKG background job for the push and pull processes, but it is still somewhat difficult and confusing to set up initially, so let’s talk about it this month and in the next issue. I’m going to cover this in two parts because of the depth of the topic. This month will cover how to do this for just two machines, and next month will show how to configure a greater number of 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 seamless 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 you have two machines, STAN and KYLE, whose nodenames are NODEA and NODEB. (Although it’s recommended to keep 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 explanations:

$RECEIVE CHANGE !HPJOBNAME,!HPUSER.GL @.AP

$RECEIVE ADD,CHANGE !HPJOBNAME,!HPUSER.!HPACCOUNT @.@-@.AP

$RECEIVE DELETE !HPJOBNAME,!HPUSER.!HPACCOUNT @.TEST @.DEV

Any CHANGEs to an 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 a 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.

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.