jdc@naucse.cse.nau.edu (John Campbell) (09/05/90)
Ok, we're stupid--or at least ignorant. I'm trying to bring up 3 machines
(apollo 4500's) in our Engineering department. Already we have 4 machines
(3 3500's and 1 10000) running in our Chemistry department. One of the
3500's has a disk and two ethernet boards. The DN10000 has a disk and
all the 4500's have disks. It all looks something like this:
EGR CHM
Res Ind Cap Hyd----Nit---Oxy---Car
| | | |
+-----+-----+-----------------------------------+
Where Hyd (//hydrogen) with two ethernet boards was to be a "gateway".
Now, for reasons that I think I almost agree with, the EGR folks don't
want the CHM folks completely in charge of their registry. In other
words, the person maintaining the CHM machines is a CHM prof and the
EGR profs aren't happy thinking that their master registry is located
on "his" machines.
So my job is to try to keep the machines on the network together but
isolate certain services from each other. Especially registry
services. So far I've just snipped the line connecting the three
and have been bringing up Res, Ind, Cap without worrying about this
larger issue yet.
My experiments to date are not very hopeful. First it seems that
any RGYD running anywhere on the network causes the global registry
to be used. Is this right? In other words, I considered not having
rgyd running on Res, Ind, or Cap and using /com/cpt to keep the
registry data tree's up to date. I knew I'd have to isolate the net
and then run rgyd for edrgy to work as discussed in the last part of
chapter 4 of Managing BSD System Software.
BUT, that plan doesn't look like it's going to work. I'm not sure yet,
but I believe if I hook the network back up I'll have a problem with
the fact that rgyd is running on either Car or Hyd. Also, someone
mentioned I could isolate dds packets from the internet at Hyd using
RTSVC. Looking at RTSVC, however, doesn't make it clear how to shut
off dds and keep ip packets.
I'm about to wade into "Managing NCS Software" as that seems to give
an overview of some of these issues. At first glance, however, it isn't
clear how to run separate glbd's or mark services (objects?) for one
net or set of machines and not another.
Any hope? Any help? I'm more than a little confused...
Thanks.
--
John Campbell jdc@naucse.cse.nau.edu
CAMPBELL@NAUVAX.bitnet
unix? Sure send me a dozen, all different colors.kerr@tron.UUCP (Dave Kerr) (09/06/90)
In article <2490@naucse.cse.nau.edu> jdc@naucse.cse.nau.edu (John Campbell) writes: >It all looks something like this: > > EGR CHM >Res Ind Cap Hyd----Nit---Oxy---Car > | | | | > +-----+-----+-----------------------------------+ > >Where Hyd (//hydrogen) with two ethernet boards was to be a "gateway". > >Now, for reasons that I think I almost agree with, the EGR folks don't >want the CHM folks completely in charge of their registry. In other >words, the person maintaining the CHM machines is a CHM prof and the >EGR profs aren't happy thinking that their master registry is located >on "his" machines. > My understanding is that at sr10.2 you can have a configuration file for the glbd, (glb.txt?) that can be used to specify what nodes should be listened to to register the ncs services. So you could configure it so that the rgyd's running on each network would only be able to register themselves with the master on each network. Also you can create accounts in the registry and give certain people ownership over certain accounts. So you could make all the %.chemistry accounts owned by the prof, and all the %.eng owned by somebody else. -- Dave Kerr (301) 765-4453 (WIN)765-4453 tron::kerr Internal WEC vax mail kerr@tron.bwi.wec.com from an Internet site kerr@tron.UUCP from a smart uucp mailer
mk@apollo.HP.COM (Mike Kong) (09/06/90)
In article <2490@naucse.cse.nau.edu> jdc@naucse.cse.nau.edu (John Campbell) writes: >... It all looks something like this: > > EGR CHM >Res Ind Cap Hyd----Nit---Oxy---Car > | | | | > +-----+-----+-----------------------------------+ > >Where Hyd (//hydrogen) with two ethernet boards was to be a "gateway". > >... So my job is to try to keep the machines on the network together >but isolate certain services from each other. Especially registry >services. You can do this by partitioning the internet into two Location Broker "cells", one containing the EGR hosts and one containing the CHM hosts. LB cells have disjoint GLB databases, and since hosts locate registry servers via LB lookup, LB cells also have disjoint registry databases. In each cell, at least one host must run glbd and at least one host must run rgyd. At your site, it should suffice to have one EGR host running both glbd and rgyd and one CHM host running both glbd and rgyd. Hosts in the EGR cell will use only the EGR glbd and locate only the EGR rgyd, whereas hosts in the CHM cell will use only the CHM glbd and locate only the CHM rgyd. In a network or internet that is partitioned into cells, each cell uses a different GLB object identifier. There is a default GLB object id; at your site, presumably, every host is currently using this default, so the entire internet is one cell. The default GLB object id can be overridden for any host by an /etc/ncs/glb_obj.txt file containing an alternate GLB object id; at your site, run /etc/ncs/uuid_gen once to generate a glb_obj.txt file on one of the EGR hosts, then copy this file to the other EGR hosts. Hosts without a glb_obj.txt file use the default GLB object id; at your site, the CHM hosts do not need glb_obj.txt files. Cell configurations are determined by the presence and contents of glb_obj.txt files. Cells need not correspond in any way to physical or logical network topology. Support for cells was introduced at SR10.2, I think, so hosts in the "alternate" cell must be at SR10.2 or a later release. For details, see sections 4.6 and 5.3 of Managing NCS Software. Once you've set up the LB cells, create a new registry in the "alternate" cell. Mike Kong mk@apollo.hp.com
wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (09/06/90)
In article <2490@naucse.cse.nau.edu jdc@naucse.cse.nau.edu (John Campbell) writes: Ok, we're stupid--or at least ignorant. I'm trying to bring up 3 machines (apollo 4500's) in our Engineering department. Already we have 4 machines (3 3500's and 1 10000) running in our Chemistry department. One of the 3500's has a disk and two ethernet boards. The DN10000 has a disk and all the 4500's have disks. It all looks something like this: EGR CHM Res Ind Cap Hyd----Nit---Oxy---Car | | | | +-----+-----+-----------------------------------+ Where Hyd (//hydrogen) with two ethernet boards was to be a "gateway". So my job is to try to keep the machines on the network together but isolate certain services from each other. Especially registry services. So far I've just snipped the line connecting the three and have been bringing up Res, Ind, Cap without worrying about this larger issue yet. BUT, that plan doesn't look like it's going to work. I'm not sure yet, but I believe if I hook the network back up I'll have a problem with the fact that rgyd is running on either Car or Hyd. Also, someone mentioned I could isolate dds packets from the internet at Hyd using RTSVC. Looking at RTSVC, however, doesn't make it clear how to shut off dds and keep ip packets. I'm about to wade into "Managing NCS Software" as that seems to give an overview of some of these issues. At first glance, however, it isn't clear how to run separate glbd's or mark services (objects?) for one net or set of machines and not another. Well it's like you say, the answer is in the NCS manual, somewhere around chapter 5 and the description of the files in chapter 7. But what it boils down to is creating the file - /etc/ncs/glb_site.txt which tells very one of your stations where it can find it glbd. (And hence your rgyd) - /etc/ncs/glb_obj.txt which specified the unique uid for the glb service to be used. ( /etc/ncs/uuid_gen /etc/ncs/glb_obj.txt would do the job ) - The next step is to distribute these two items to all the stations you want to 'control' From now on you can run all of your NCS services local. Succes, Willem Jan Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands