[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Sat, 27 Jun 87 00:01 EDT
From: Barry Margolin <firstname.lastname@example.org>
Date: Fri, 26 Jun 87 17:47 EDT
From: Chris Lindblad <CJL@reagan.ai.mit.edu>
Date: 26 June 1987 1056-PDT (Friday)
Sorry if this (undoubtably) has come up before.
We have two groups (call them red and blue) of machines,
each group in its own namespace. (Why not one namespace?
To protect each group against misadventures in the namespace
of the other.) The red machines need to occasionally access
the blue machines.
Simple add blue to the searchlist attribute of red's namespace
object. Catch-22. red doesn't have a namespace object for
blue. Well, add one. Gotcha! red doesn't have a host object
for blue's server. Well, add one first, blue|server. Heh heh!
red doesn't have a namespace object for blue. Sounds like zen,
if you have to ask, don't ask.
Starting off on the namespace server for the red namespace, with it currently
only knowing about the red namespace (no references to blue anywhere).
(Essentially the state right after doing the :Set Site command from a
Also, remove any references to sites in the networks blue|chaos and
red|chaos. It would also be wise to say "yes" in the
default-secondary-namespace-server field for both namespace server host
Do a (neti:find-site :blue), and answer the questions. The machine will now
know about the blue namespace.
Edit the namespace objects for the network red|chaos, and add a nickname
blue|chaos. This tells the namespace system that the chaos network mentioned
in the red namespace is the same chaos network mentioned in the blue
If you use tcp-ip, do the same for the network red|internet.
Actually, it's even easier than that, assuming you are running at least
Genera 7.0. All you have to do is
(neti:find-site :blue :link-to-old-site t)
The :link-to-old-site option causes the networks of the two sites to be
made synonyms of each other. If you do it manually, it sometimes loses
because of order dependencies; the automatic mechanism generally does it
This is most definitely the right thing to use for the chaos networks.
The keyword was added to make this easier on the Symbolics network. You
will still have to add the nickname for the Internet networks.
Add blue namespace to the search path for the red namespace.
Reboot the distribution world load on the namespace server for red, do a "Set
Site" command to the red site, and answer the questions. After the set site,
you can disk save the world.
This is all true and currently "the right thing to do". I would caution
that it is very difficult to undo this operation once it has been done.
What happens when you go through all of this, other than getting the Red
namespace server to become a secondary for Blue and vice versa, is that
you are making the network objects red|chaos and blue|chaos become EQ to
the machines in both namespaces. If you describe
chaos:*local-chaosnet*, you will see that it has a name in both
namespaces. We call this multi-homing. (Yes, I know the ARPAnet
community uses this to refer to a host with more than one interface but
we have been using to to refer to an object that lives in more than one
namespace for sometime now.) In 7.2, this has been changed so you do
not need to multi-home the network objects. You will still need to
find-site the other site but you will not merge the network objects.
Namespace can work well if configured well. Here at MIT we have 8 separate
sites, 7 different namespaces, 3 different primary servers, 2 of which
secondary serve each other, and another machine just being a secondary
namespace server. All this to service about 120 Lisp Machines around campus.
Since we are bragging about the size of our namespaces, the Symbolics
network has 10 namespaces, down from 13 (don't ask how we deleted 3
namespaces, it was not fun). I don't know how many sites, somewhere
around 16, and 9 primary servers. I won't hazard a guess as to the
total number of lispms but at SCRC alone there are about 215.