[news.software.b] How we do it

mb@ttidca.UUCP (02/23/87)

In article <185@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes:
>In an effort to test NFS, widen news availability, and save some disk space
>(our Super-Eagles are dying), I have set up some of our local machines
>to share news across NFS.
>......
>Anyway, I have a system that now works except for one thing that bothers
>me: postings made on a sharing machine update /usr/spool/news and
>/usr/new/lib/news/active. Since I use HIDDENNET, I can't set it up so
>that the main feed just doesn't forward the news.
>
>Is there any way for me to change it so that inews doesn't update the
>active file? 

I did something similar when we first came up under 4.2 with NFS:

1) /usr/spool/news resides on our main machine.  It is mounted by all
   other machines.

2) /usr/lib/news resides on our main machine.  It is mounted on all
   other machines as "/usr/lib/glob.news"

3) Our main machine additionally has the these directories:
	/usr/lib/sun.news, /usr/lib/vax.news
   We also had a /usr/lib/pyr.news before we got rid of our second
   Pyramid. (The main machine is our original pyramid).

   These directories, which are mounted on /usr/lib/news on the appropriate
   machine types, contain symbolic links to control-files in
   /usr/lib/glob.news.  They also contain machine specific binaries
   with the major exception of inews.  Inews instead is a shell script
   that uses rsh to invoke inews on the main machine.  

With this approach, all of the remote mounts can be read only and
soft.  We dont bother with soft mounts though, since I added a local
hack that lets remote accesses to a machine that is down return
immediately with EHOSTDOWN in errno.

-----

On a side note:  has anyone solved the deadlock problem that occurs
when chtable is filled for accesses to a machine that is down?

I've got an idea for a solution, but testing it would require
standalone time for two machines, and it is hard to get project
managers on just one machine to agree to scheduled downtime.

- Michael Bloom