Sun386i Multiple YP Domains - a Kludge Solution

[Brian Thorstad]

Sorry for the long winded discussion here, but lots of people seem to have
this problem (eg. most customers purchasing 386i's).

I am in charge of one of two Sun386i networks in my company, each in
different Yellow Pages domains.  Both networks are restricted, requiring
the administrator to configure new systems into the network before adding
them.  We are running 4.0.1.  Unfortunately, Sun does not support this
configuration (sound familiar?).  Sun apparently never considered that
multiple groups would exist on the same Ethernet.

The two most common symptoms are:

1) When a YP client boots, it invariably is answered by the "wrong
network", is given the "restricted network" message and fails its boot.
Very annoying :-(.

2) On each YP server, the rarpd process complains every 90 seconds about
other rarpd processes that should not exist (the other network).

THE PROBLEM:

The source of the problem seems to be (I think) that a booting YP client
sends out a rarp request that is frequently answered by the "wrong" rarp
daemon. (each YP server runs rarpd by default).  The answering server, in
conjunction with the new PNP (Prug-N-Pray) software assumes that the
client from the other domain is a NEW WORKSTATION that should be added to
the network.  From this point on, life for the client goes down the
tubes...

Reportedly, Sun will be fixing this (via a patch) within the next few
weeks.  Some of cannot wait for phantom fixes (this was supposed to be
fixed in 4.0.1, instead a work-around stopped working! 

SOLUTIONS (Kludge) (2):

There are two solutions to this problem.  Both are Kludges, and do not
work for diskless 386i clients.  Although, if all diskless clients are in
the same domain, solution (2) will probably work.  Sun should fix the
problem at the source, but until they get around to it, hopefully this
will help.

1) The first solution is to configure each workstation so that it does not
need YP services from someone else.  It will not make the rarp request at
boot time.  Specifically, make every workstation a YP Slave Server.  While
not the most elegant solution, the cost in diskspace is under 100K per
workstation.  Of course, updates take longer...

The drawback is that each workstation will complain every 90 seconds (into
the console and /var/adm/messages) about the other domains' rarp daemons
who should not exist.  Sample error message:

  Feb 13 07:01:40 demolab rarpd[73]: Will not allocate IP addresses.
  Feb 13 07:03:10 demolab rarpd[73]: Dynamic RARP server at 192.5.220.120
     (norman) should not exist!

2) This solution is a variant of the first but eliminates the warning
messages and allows one domain to maintain a rarp server (and thus
diskless clients).  This domain should have no changes made to it.  For
every other domain, perform the following steps.
  a) make every client a YP slave server.
  b) on every server (slave & master) modify /etc/rc.local so that 
     /usr/etc/rarpd does not run.  Only clients need rarpd for booting, so
     this should not present a major problem.

I have implemented this solution (2), and it seems to be working fine.  I
realize that some software may require rarpd to be running, and that is
why I call this a kludge solution.  But it will allow you to have multiple
domains, and have workstations boot up...

Installing new workstations will probably be more complicated.  I imagine the 
following will be necessary.
1) Configure the new workstation to the correct YP domain (SNAP)
2) kill any rarpd processes in the network
3) boot the new client, manually entering appropriate configuration
   information when it can't find it from the network (host name, time zone,
   IP address,...)
4) make the new client a YP Slave server
5) restart the killed rarpd (if necessary).

Brian Thorstad
Contel Federal Systems
(703) 359-7643
(thorstad at wooglin.scc.com)