rjk (12/18/82)
The time has come when uucp has GOT to distribute job files into separate C, D, and X directories. It's ridiculous to have uucico timing out because of the directory search times. On top of all that, USG 5.0 uucp still has all of the old problems. Usenet has proven to be the best uucp systest ever. Is anyone out there attempting to centralize all of the fixes and enhancements to uucp? We ought to start distributing the latest uucp sources right with the netnews package. I think that 10 years of uucp Beta release is long enough. What is the concensus here? Randy King
swatt (12/20/82)
I proposed to a number of people (those who responded to Steve
McGeady's request for all known UUCP bug fixes and/or enhancements)
that we form a:
UUCP Module of the Month Club
Appended is the original letter; I never got enough response to
start the effort. Meanwhile, I have undertaken on my own to knock
off a module now and then when I have nothing better to do. I am
still interested in a joint effort as proposed in the original letter;
I would welcome any volunteers.
My own studies of UUCP indicate these things:
1) If you want to find bugs, look at ANY module for 30
minutes or so and you will find them.
2) You CANNOT just "fix" the bugs in UUCP -- the real problems
go too deep into the structure. Some very basic issues of
concurrency and naming disciplines need to be addressed.
3) Making separate subdirectories for "C." and "D." files is not
the answer, even if it does buy some performance gains. The
real answer is to impose a uniform queuing mechansim onto UUCP,
and package the functions now performed by "uuxqt" and "uucico"
as servers. This will go a LONG way toward making UUCP
portable to VMS, by the way.
4) It is possible to re-create a usable, efficient, supportable,
maintainable UUCP system that is packet- and protocol-compatible
with the present UUCP, but not by simply slapping bandaids on
the present version.
Here for example, are some problems with UUCP that need to be addressed
systematically:
1) Security. There are dozens of security holes in my version
of UUCP. Even worse, the provisions for security are NOT
explainable to mere mortals, who have to administer it. I
challenge anyone out there to explain how the specifications in
USERFILE really work. Aside from the glitches that need
fixing, a basic re-think of security needs is required.
2) Reliability. The present structure of uucico simply does not
allow it to handle errors properly. A lot of stuff is thrown
away that need not be; UUCP has no concept of "expectable"
errors.
How many people realize there is a namespace conflict in
certain "D.<mumble>" files created for export?
3) Maintainability. How many versions of UUCP are floating around?
How much of this is because a sensible set of options aren't
broken out into configuration files? How much of this is becuase
all UUCP code looks like it was written by people who don't LIKE
"C"?
======================================================================
>From swatt Thu Nov 18 18:07:08 1982
To: brl-bmd!dpk brl-bmd!guy cbosgd!mark cmcl2!salkind floyd!trb hp-pcs!peter
hplabs!kg ima!johnl ittvax!swatt mhtsa!lsc physics!gill reed!billst
seismo!stewart sun!shannon tekcad!ellis tekcrd!davec teklabs!clemc
tekmdp!grahamr tekmdp!steveg tpdcvax!bobvan ubc-vision!brent
ucla-security!lauren ucsfcgl!tef uiucdcs!essick utah-cs!lepreau
uw-beaver!jim
Subject: UUCP Module-of-the-Month Club?
Cc: swatt
I'm sure all of you are just as tired as I am of fixing UUCP bugs,
and keeping track of all the other people fixing UUCP bugs. Many
thanks to Steve Mcgeady for collecting all the known-and-fixed
glitches. I propose we form a:
UUCP Module-of-the-Month club
where each one of us undertakes to REWRITE a single UUCP module
so it conforms to standards of sanity. I will act to collect
all the re-written modules and build a totally sane UUCP system.
I won't presume to set the coding standards -- I'm sure each
of you adheres to some perfectly acceptable standard already.
However, for my benefit in putting it all together I suggest:
1) Functions in alphabetical order.
2) Access/Modification of externals at least
noted in comments.
3) Adequate notes (a README file will do fine)
on any internals aspects of module which are
either new as a result of the re-write, or
which aren't properly explained in the present
documents anyway and ought to be.
The modules in (my version) of UUCP are:
anlwrk.c getpwinfo.c pkon.c uucp.h
anyread.c gio.c prefix.c uucpdefs.c
assert.c gnamef.c sdmail.c uucpname.c
cfgets.c gnsys.c setline.c uudemon.day
chkpth.c gnxseq.c shio.c uudemon.hr
cico.c gwd.c strchr.s uudemon.wk
cntrl.c imsg.c sysacct.c uulog.c
conn.c index.c systat.c uuname.c
cpmv.c ioctl.c ub_sst.c uust.h
expfile.c lastpart.c ulockf.c uustat.c
gename.c logent.c us_crs.c uusub.c
getargs.c mailst.c us_open.c uusub.h
getcmds.c pk.h us_rrs.c uux.c
getopt.c pk.p us_sst.c uuxqt.c
getprm.c pk0.c uuclean.c versys.c
getpw.c pk1.c uucp.c xqt.c
Between all of us, this should amount to no more than a good day's work
or two apeace. I'm interested in people who will take responsibility
for understanding the workings of a given module and assuring the
correct and acceptably efficient operation of that module.
Once assembled, I would want at least the following test systems:
VAX 4.?BSD
pdp-11 non I&D
ONYX (shakes out byte-swap problems)
??? with System III.
Once tested, the system will be placed on deposit at central sites
(decvax, duke, ucbvax, etc.), and anyone who wants to get it can
do so from there.
Comments? Volunteers?
- Alan S. Watt
[decvax!]ittvax!swattber (12/21/82)
#R:we13:-31800:harpo:6300005:000:985 harpo!ber Dec 20 19:39:00 1982 My most recent disgust with a spool directory over 100KB lead to make the following simplistic modification. For each site I distribute netnews to, I remade uucp defining /usr/spool/uucp/<EACHSITE> as the spool directory. There is now a /usr/lib/uucp/<EACHSITE> containing uucico, uuxqt, uux and uuclean. Each such site has an individual password entry whose shell is /usr/lib/uucp/<EACHSITE>. Approprite mods were made to the uudemon. files. Although mail is still spooled to these sites in /usr/spool/uucp, netnews invokes the site specific uux, thus eliminating 95% of my problems. A front end uux and uucp could make it consistent, but it's not necessary in my case. Now if one of my netnews neighbors goes off the air for a week, only their spool directory becomes unmanagable, and I continue to talk to everyone else. Although this 'solution' is trivial and requires no changes to code, some of you may find it useful while you're waiting for uutopia. brian redman
rusty (12/21/82)
From: rusty (Rusty Wright) (1) i think you should enforce a more rigorous coding standard. i don't like the idea of the various models being in different coding styles. i vote for the coding standards used by the ingres project, this was posted to the net a while ago. you might be able to get a copy from ucbvax!eric. (2) always use dynamic allocation (malloc/realloc) and don't use those stupid static arrays. i just don't understand why people continue to use static arrays especially in programs that are expected to be portable and behave robustly in a variety of environments. i have a package that implements dynamic strings for operations like strcpy, strcat, etc., if you want it let me know.