More on Multi-CPU
By Shawn M. Gordon
Inside VESOFT covers tips and
techniques you can use with VESOFTs 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 well get a 3000 for 2000 cap out
to you as our thanks.
The two-machine configuration described last month is actually a minimal version of a ring topology, where changes are passed from the first machine to the second, the second machine to the third, and so on until the last machine in the chain transmits data to the first machine.
For example, lets rename last months system KYLE to system KENNY and add the new system CARTMAN to the chain. Using a ring analogy, the network now looks like this:
As you can see, you can put as many
of these nodes between STAN and KENNY as you want. In
actual practice, however, you are not likely to add more than a dozen
nodes in this manner especially since you will run out of
names from South Park. After that point, it may be easier to define a
star or wheel type network, in which one machine is considered the
hub and all other machines are spokes.
Changes made on any spoke are only sent to the hub, and the hub is
then responsible for forwarding the changes to the other spokes. This
is actually the method I prefer, since it plans ahead.
reason this works is because you can specify more than one $NET-SEND
in your SECURCON.DATA.VESOFT file to indicate that user profile
change information should be transmitted to several computers. For
Similarly, you can specify more than one $FROM-SYS in your
hubs NETRECV.DATA.VESOFT file, indicating that information
should be received from several computers.
you have many machines, you might want to set up a pair of files in
the group NETRECV.VESOFT that contains a list of machine names and
DSLINE node names. You can then refer to these lists of machines in
$NET-SEND and $FROM-SYS keywords. For example, you might build a file
called SPOKENS.NETRECV.VESOFT (for SPOKE NameS) that contains the
line: STAN CARTMAN KENNY
you build SPOKEDS.NETRECV.VESOFT (SPOKE DSlines) which contains:
file CHANGES.NETRECV (on the hub) would be used for ALL the nodes
listed in SPOKEDS. Each spoke machine (STAN, CARTMAN and
KENNY) should have $NET-SEND HUB in their SECURCON file and $FROM-SYS
HUB in their NETRECV file. Therefore, a change on system STAN will be
sent to the hub system, which in turn will be received from the hub
by CARTMAN and KENNY.
that if your system names are the same as their DSLINE node names,
then the same file can be used for both the SECURCON $NET-SEND and
NETRECV $FROM-SYS keywords. Given how convoluted this can get, I
strongly recommend keeping it as simple as possible and reusing the
a user is changed, it usually wouldnt make sense to transmit
the entire user profile, including the terminal restrictions,
time-of-day restrictions, day-of-week restrictions, and menu file.
This is because these things are typically quite different on
different systems. Youd almost certainly want to have different
menu files on different systems; the terminals are configured as
different LDEVs, and the normal working days and times might be
only the user name and password information (including password
history, last change date, etc.) actually get sent from one system to
another. Now, what if you want to impose terminal, time-of-day or
day-of-week restrictions on users who might perhaps get
automatically added as a result of an addition on another system? The
$FORBID keyword lets you impose restrictions on entire usersets, not
just individual user profiles, so in your SECURCON file you could
$FORBID NOT BETWEEN(CLOCK,9AM,5PM) Bad
will impose a time-of-day restriction on all the users in the AP
account. These restrictions will be enforced even though the users
wont have specific time-of-day restrictions in their user
Pushing is another method of maintaining security profiles on
multiple systems. Normally, a SECURITY user profile on system STAN
gets moved to system KYLE by a NETRECV task running under the BACKG
job on KYLE which keeps a remote session logged on to STAN.
if you dont want to keep this session permanently logged on?
Security 3000 lets you indicate that data is to be pushed
across the network, i.e., have the data transfer be done by the
computer on which the changes were initially done rather than
pulled. Lets see how its done.
the following discussion, system STAN is the system on
which the SECURITY user profiles were changed; system
KYLE is the system you wish to forward those changes to.
Instead of having a $FROM-SYS nodename sysname line in your
NETRECV.DATA.VESOFT file on system KYLE, you should have a
$FROM-SYS-PUSHED nodename sysname line. This tells the NETRECV task
on KYLE that the data from STAN will be pushed by STAN, and
doesnt need to be pulled by KYLE.
There are two different ways that you can have system STAN push data
to system KYLE: immediately or intermittently.
you add to your NETRECV.DATA.VESOFT file on system STAN a line that
says $PUSH-IMMEDIATE KYLE, the NETRECV task on STAN will do a :REMOTE
HELLO to KYLE, transmit the change, and do a :REMOTE BYE every time a
change is made on STAN.
you add a line that says $PUSH-INTERMITTENT KYLE, the changes will
only be pushed when you do a %SEC NETPUSH command (either online or
using the NETPUSH task under the BACKG job). BACKG allows you to
schedule the NETPUSH task to run once a day at a given time (1 AM, by
default) so that it transmits all the changes to all the systems
specified in the $PUSH-INTERMITTENT commands. If you find that you
want to send the data to the other machines immediately, you can just
do a %SEC NETPUSH online.
will however need to keep the NETRECV task running on system KYLE;
the main difference is it never logs onto system STAN. In addition,
you must either run the NETRECV task on system STAN (for
$PUSH-IMMEDIATE) or the NETPUSH task (for $PUSH-INTERMITTENT) to
transmit the data to system KYLE. (A third alternative is to manually
issue a %SEC NETPUSH command, which is what the NETPUSH task does
once a day.) The NETRECV task on system KYLE then updates the
SECURITY user profile.
large network model is much more complex. Imagine a network of
systems scattered across the country. Using X.25, each one can
connect with every other one, but they shouldnt be continually
connected. Instead, what we will do is have each system dial in to a
master or hub system every time a profile is
changed. Then, once a night, the hub will send all of the
changes made to it during the day to each of the slave or
this plan, the hub will always have the current SECURITY
configuration of all of the spokes, and each
spoke will be updated with changes from all the other
spokes at the end of the day. A user who changes his
password on a spoke will be able to use his new password
on the hub virtually immediately, and on other
spokes starting tomorrow.
is going to be a little confusing, so do your best to follow along:
system HUB, add the following:
each SPOKE system (SPOKE01, SPOKE02, ...), add the following:
all systems (HUB and SPOKEs),
%SEC BACKG STARTJOB (If its not already
system HUB only:
%SEC BACKG START,NETPUSH
NETRECV task on the HUB merely waits for a SPOKE to send a change,
which it then posts to the SECURITY user profiles on the HUB.
NETRECV task on each SPOKE does two things. It sends changes to the
HUB throughout the day (by logging onto the HUB, sending the change,
and then logging off). At night, when NETPUSH on the HUB sends the
changes to the spokes, NETRECV on each spoke posts the changes to the
SECURITY user profiles.
if you havent slipped into a coma reading all that, you are
certainly now a master at network security.
Shawn Gordon, whose S.M. Gordon
& Associates firm supplies HP 3000 utilities, has worked with
3000s since 1983.
Copyright The 3000 NewsWire. All rights reserved.