C news on a 3B1/7300 (or B news with mdbm)

[roger at marque.mu.edu]

In article <22541 at ditka.UUCP> kls at ditka.UUCP (Karl Swartz) writes:
>A few weeks ago there was a brief discussion of C news on the
>AT&T 3B1/7300.  Unfortunately I was busy at the time and those
>messages expired before I got to them.  Last weekend I spent a
>number of hours trying to get it working and mostly ended up
>with a deep hatred for the awful configuration script.  Could
>someone tell me how to get C news up on one of these machines,
>if it's doable?  (Post if you think the information will be of
>general interest though given the recent discussion I suspect
>e-mail would be best.)
>
>If C news isn't feasible, what about B news with mdbm?  I have
>been running 2.11.8 with the hashed history files but wanted
>to get some extra speed and so tried to use the mdbm posted by
>Dave Ihnat, upgrading to 2.11.14 in the process, now that the
>lost inode bug is fixed in the kernel.  Unfortunately expire
>keeps exploding and then everything goes to hell with messages
>about history.dir and history.map not being linked.  Having
>already wasted quite a few hours on C news I really didn't feel
>like a long debugging session so I reverted to the old, slow,
>2.11.8 and hashing.
>
>Any and all suggestions will be greatly appreciated.
>
>-- 
>Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
>1-408/223-1308			 |INet	zygot!ditka!kls at apple.com
>"I never let my schooling get in |BIX	kswartz
>the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148

Well, this is fairly fresh in my mind, as I just updated Cnews because of a 
recently posted patch.

I have been running this for several months now.  I have had difficulties
getting various verions to go.  The current "versiom" 
(at patchdate 12-Mar-1990) went together without much of a hassel, and 
I built it with gcc 1.37.1.  If you use gcc, be sure that you also 
compile the dbm stuff with it or you will create incompatabilities.
(I.E. - Use the same compiler/options for dbz.o that you use for Cnews.)
I used "dbz" from the "contrib" stuff.

There are several scripts (Cnews uses shell scripts a LOT), that will
fail if the "stock" KSH is used to run them.  Noteable is "inews".
This will cause news posting to fail.  I suspect that the problem lies
in a rather windy "egrep" line used to find the relevant newsgroup in
the active file.  I have not bothered to fix this yet, it just easy to
re-post the "dead.article" by saying "sh inews -h <dead.article"
which succeeds, or going in using "sh".  Besides which I don't post
much from my news machine which is "booth".  Note that I am posting
from "marque". (Their "ksh" works correctly, although they call it "sh".)

I built the "lastest" cnews on system "boother" and used the following
as my config defaults (from file "build.def" created during the "build"
pass):

	newsuid		"news"
	newsgid		"news"
	binuid		"news"
	bingid		"news"
	binsrc		"yes"
	mess		"no"
	unmess		"no"
	newsarts	"/usr/spool/news"
	newsctl		"/usr/lib/news"
	newsbin		"/usr/lib/newsbin"
	newsumask	"002"
	newsmaster	"roger"
	newsconfig 	"/usr/lib/news/bin/config"
	chown		"/bin/chowm"
	chboth		"no"
	chgrp		"/bin/chgrp"
	unixkind	"usg"
	addrsize	"big"
	dbmopt		"-ldbm"

Here I have compiled "dbz.o" from the "contrib" directory, and then used
"ar ruv libdbm.a dbz.o" to create the dbm archive, which I placed in
/lib for the scripts to find.

	faststdio	"no"

(Should play with this sometime in the future.  Last time I tried it I
had problems...)

	storeval	"yes"
	faststrchr	"yes"
	sete		"no"

Very important! The stock setuid(setgid()) will fail!

	ranlib		"no"
	symdef		"yes"
	cc		"gcc"

"cc" for the stock Unic-PC compiler.

	copts		"-O -fpcc-struct-return -traditional"

The "-fpcc-srtuct-return" and "-traditional" options are "gcc" specific 
and cause to to behave more like the stock "cc" on the Unix-PC.
(Okay that is somewhat of a simplification but so what.)  If you use
stock "cc" (or "ccc", "shcc" or what ever), these should be left out.

	ldopts		"-s -shlib"

The "-shlib" option is specific to a modified loader I use for both "gcc"
and "cc".  This option triggers the loader to use the shared libraries.
It is avaliable on "cheops.cis.ohio-state.edu" in the att7300 archive
as file "ld-fed.cpio.Z" (I think thats it...).  Anyway, this option should
be left out if you don't use that program.

	postlibs	""
	hostname	"no"
	uname		"yes"
	uucptype	"hdb"

HoneyDanBer here, if you don't use that then use the approprate answer,
probably "sub".

	dftype		"sysv"
	dfdirs		"no"

I have a c program that was posted some time ago for this.  I think 
re-posting it might be in order if a lot of folks will be trying to
bring up Cnews.  In any event, if you do not have this particular
"spacefor.c" program, I would recommend initally bring up Cnews
by telling build not to use "spacefor" (I.E. - use the "null" answer).
None of the supplied versions will work without extensive troubleshooting.
Get Cnews running first, the hunt up a working "spacefor" and re-build 
Cnews with it.

	archive		"no"

(for future exploration - but "no" for now.)

	spacelow	"no"
	nfsgroup	"no"
	server		"newsie"

(Hey I didn't know about this one!  must be a default.)

	manpages	"/usr/man"
	manmess		"no"
	rbin		"/bin"
	doui		"no"
	bin		"/bin"
	atok		"no"
	postdefltdist	""
	paranoid	"no"
	whoami		"boother"

System "boother" talks to system "booth" which talks to system "introl"
which talks to "marque".  "boother" is used to compile and test the 
software, which will eventually run on "booth" where I usually read
"news" and receive mail, etc.

	mailname	"boother.uucp"
	organization	"Private System"
	postdefltgroup	""
	newspath	"/bin:/usr/bin"
	fake		" fsync.o mkdir.o symlink.o"
	fakehdrs	" ../include/string.h ../include/timeb.h"
----------------------------------------------------------------

Remember - BE SURE not to allow the the system to do setuid(getuid()).
This will be okay if:
	sete		"no"
(as above)

You should be ready to run "doit.root" su-ed to the "root" owner.

You should then run "doit.bin" as the news owner.  Make sure that ALL
the files are owned by this account, as well as the directories, etc.

Now I run this as "nohup sh doit.bin -i &", to ensure that "sh" runs it
rather than "ksh".  The "-i" prevents the actual installation of Cnews
on the system.  I prefer to do a few verifications before I do this!
Also, if you are currently running B-news, and you have used the same
directories for your news stuff, Cnews will overwrite much of the
B-news stuff.  This will then usually render B-news inoperative, and
if the Cnews version does not work properly, you will be OFF THE AIR!
This also makes the update difficult, as it is then hard to tell
which files belong to which news version.  I made a cpio archive of
"/usr/lib/news" just in case, and when I was ready to install Cnews,
I cleaned out much of "/usr/lib/news" first.  Some stuff you want to
keep around, such as the "active" and "sys" files.

Of course, if you do it this way, you must completely re-run the
script without the "-i" to install it, and this does take quite a
while, but not as long as the first pass.

The verification passes which I use are already built into Cnews.
All you do is cd to "relay" and run "make r" to perform a test of
these programs.  If that is okay, cd to "expire" and do a "make r"
there.  If there were any problems with the "dbm/dbz" stuff, they
will also show up here.

Once this is done (and you have completed the install by re-running
without the "-i" option), you run "doit.news" as the news owner.
(In all cases with these scripts, I use "sh" to run them.)

Once that has completed successfully, you now need to "su" to root
again and run the final "(sh) again.root".

If all is well at this point, you should run 
"/usr/lib/newsbin/expire/mkhistory" as the news owner, in order to 
re-create the history files with the newer database stuff.

If you have gotten this far, then you have installed a running
Cnews.  Now the real problems begin as you try to administer a
news system... :-)

						- Roger