![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to install CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10no / cmd / netnews / doc|
Return to install CVS log | Up to [Research Unix] / researchv10no / cmd / netnews / doc |
1.1 root 1:
2:
3:
4:
5:
6:
7:
8:
9:
10: UUUUSSSSEEEENNNNEEEETTTT VVVVeeeerrrrssssiiiioooonnnn BBBB IIIInnnnssssttttaaaallllllllaaaattttiiiioooonnnn
11:
12:
13: Matt Glickman
14:
15: Computer Science Division
16: Department of Electrical Engineering and Computer Sciences
17: University of California
18: Berkeley, California 94720
19:
20:
21: Revised by Mark Horton
22:
23:
24:
25:
26:
27:
28: _1. _I_n_t_r_o_d_u_c_t_i_o_n
29:
30: This document is intended to help a USENET site install
31: and maintain the network news software. Please ask ques-
32: tions of the author or of Mark Horton, such questions will
33: help to point out areas that need to be addressed here.
34:
35: The overall order of things to do is:
36:
37: (a) Find somebody to link up with. You need a network con-
38: nection of some kind, for example ARPANET or UUCP. You
39: cannot get a link to Berkeley, sorry. If you must use
40: UUCP and have no connections, you must have at least a
41: dialup and preferably a dialer, and find someone wil-
42: ling to call your machine. The USENET directory may be
43: helpful in finding some other site geographically near
44: yours to hook up to.
45:
46: (b) Create a localize.sh script to make local changes to
47: the makefile and defs.h files.
48:
49: (c) Compile the software using the _m_a_k_e command.
50:
51: (d) Su and type ``make install''. This will copy the files
52: out to the right place and make directories containing
53: most of the important files. It will configure you in
54: with a connection to ucbvax via uucp links. This is
55: undoubtably wrong, so you will have to configure links
56: as needed.
57:
58: (e) After editing the configuration table, get your contact
59: at the other end of the link to add you to their sys or
60: .sys file.
61:
62:
63:
64: May 3, 1983
65:
66:
67:
68:
69:
70: - 2 -
71:
72:
73: (f) Post a message to the to._s_y_s_n_a_m_e newsgroup which should
74: be set up to go only to the site you are linked to, as
75: a test. Have the other person send a message to your
76: system using the same mechanism. If this doesn't work,
77: find the problem and fix it. (Please don't use
78: net.test unless there is no alternative. It is almost
79: always possible to use test, or to._s_y_s_n_a_m_e, or some
80: local.test group, instead of net.test.
81:
82: (g) Fill out a USENET directory form and post a copy to the
83: USENET newsgroup ``net.news.newsite.''
84:
85: (h) Post the ``etiquette'' and ``tencmdts'' files (in the
86: doc directory) to your ``general'' newsgroup with a
87: long expiration date. Running ``rnews'' separately on
88: each of these files will do.
89:
90: (i) It will probably be necessary to fix your uucp command
91: to allow rnews, and to support the -z and -n options.
92:
93: _2. _I_n_s_t_a_l_l_a_t_i_o_n
94:
95: _2._1. _C_o_n_f_i_g_u_r_a_t_i_o_n
96:
97: Local configuration of the UUUUSSSSEEEENNNNEEEETTTT version B software
98: requires you to edit a few files. Most importantly, the
99: ddddeeeeffffssss....hhhh and MMMMaaaakkkkeeeeffffiiiilllleeee files must be created from their tem-
100: plates ddddeeeeffffssss....ddddiiiisssstttt and MMMMaaaakkkkeeeeffffiiiilllleeee....****. You should create a shell
101: script called localize.sh which copies the files and makes
102: local changes to the copies. Even for a completely vanilla
103: site, some changes will be necessary. For example, your
104: script should choose between Makefile.v7 and Makefile.usg,
105: and between postnews.v7 and postnews.usg. You should
106: include the name of the local organization (MMMMYYYYOOOORRRRGGGG) and the
107: uid of the local news super user (RRRROOOOOOOOTTTTIIIIDDDD). A sample local-
108: ize shell script can be found in localize.sample. The most
109: important parameters are:
110:
111: _2._1._1. _R_O_O_T_I_D
112:
113: The numerical userid of the person who is the news
114: super user. This should not be set to 0. Normally it is
115: set to the uid of the news contact person for the site.
116:
117: _2._1._2. _N__U_M_A_S_K
118:
119: Mask for _u_m_a_s_k(_2) system call. Set to something like
120: 022 for a secure system. Unsecure systems might want 002 or
121: 000. This mask controls the mode of news files created by
122: the software. Insecure modes would allow people to edit the
123: files directly.
124:
125:
126:
127:
128:
129:
130: May 3, 1983
131:
132:
133:
134:
135:
136: - 3 -
137:
138:
139: _2._1._3. _D_F_L_T_E_X_P
140:
141: The default no. of seconds after which an article will
142: expire. 2 weeks (1209600 seconds) is the default choice.
143:
144: _2._1._4. _D_F_L_T_S_U_B
145:
146: The default subscription list. If a user does not
147: specify any list of newsgroups, this will be used. Popular
148: choices are aaaallllllll and ggggeeeennnneeeerrrraaaallll,,,,aaaallllllll....ggggeeeennnneeeerrrraaaallll.
149:
150: _2._1._5. _T_M_A_I_L
151:
152: This is the version of the Berkeley _M_a_i_l program that
153: has the -T option. If left undefined, the ----MMMM option to
154: _r_e_a_d_n_e_w_s will be disabled.
155:
156: _2._1._6. _A_D_M_S_U_B
157:
158: This newsgroup (or newsgroup list) will always be
159: selected unless the user specifies a newsgroup list that
160: doesn't include ADMSUB on the command line. That is, as
161: long as the user doesn't use the ----nnnn flag to readnews on the
162: command line, ADMSUB will always be selected. This is usu-
163: ally set to ggggeeeennnneeeerrrraaaallll. (The intent of this parameter is to
164: have certain newsgroups which users are required to sub-
165: scribe to. A typical site might require ggggeeeennnneeeerrrraaaallll.)
166:
167: _2._1._7. _P_A_G_E
168:
169: The default program for which articles will be piped to
170: for paging. This can be disabled or changed by the environ-
171: ment variable PAGER. If you have it, the Berkeley _m_o_r_e com-
172: mand should be used, since the + option allows the headers
173: to be skipped.
174:
175: _2._1._8. _I_N_E_W_S
176:
177: The full path name of the _i_n_e_w_s program for _r_e_c_n_e_w_s to
178: fork.
179:
180: _2._1._9. _F_O_L_L_O_W_U_P
181:
182: This is the command used to internally post followups.
183: It is not normally changed.
184:
185: _2._1._1_0. _R_N_E_W_S
186:
187: The name of the _r_n_e_w_s program (a link to _i_n_e_w_s) for
188: _u_u_r_e_c to fork. Normally this is /usr/bin/rnews. Wherever
189: you install it, it must be in uuuuuuuuxxxxqqqqtttt's default path, normally
190: ////bbbbiiiinnnn::::////uuuussssrrrr////bbbbiiiinnnn.
191:
192:
193:
194:
195:
196: May 3, 1983
197:
198:
199:
200:
201:
202: - 4 -
203:
204:
205: _2._1._1_1. _N_O_T_I_F_Y
206:
207: If defined, this character string will be used as a
208: user name to send mail to in the event of certain control
209: messages of interest. (Currently these are newgroup,
210: rmgroup, sendsys, and senduuname.) As distributed, mail will
211: be sent to user uuuusssseeeennnneeeetttt. It is recommended you create such a
212: mailbox (have it forwarded to yourself) if possible, since
213: this makes it easier for another site to contact the site
214: administrator for your site. If you are unable to do this
215: (e.g. you are not the super user) you should change this
216: name to yourself.
217:
218: _2._1._1_2. _D_F_T_X_M_I_T
219:
220: This is the default command to use to transmit news if
221: no explicit command is given in the 4th field of the sys
222: file. It normally includes uux with the -z option. You
223: should install this mod to uucp at once, otherwise your
224: users will start being bombarded with annoying uux comple-
225: tion messages. However, you can turn this off to get news
226: installed.
227:
228: _2._1._1_3. _U_X_M_I_T
229:
230: This is the default command used if the U flag is
231: present in the flags portion of a sys file line. In this
232: case, the 2nd %s refers to the name of a file in the news
233: spool area, not a temporary file. It can usually only be
234: used when local modifications are made to the uucp system,
235: such as the -c option to uux.
236:
237: _2._1._1_4. _D_F_T_E_D_I_T_O_R
238:
239: This is the full path name of the default editor to use
240: during followups and replies. It should be set to the most
241: popular text editor on your system. As distributed, vvvviiii is
242: used.
243:
244: _2._1._1_5. _U_U_P_R_O_G
245:
246: If this is defined, it will be used as a command to run
247: when the sssseeeennnndddduuuuuuuunnnnaaaammmmeeee control message is sent around. Other-
248: wise the command uuuuuuuunnnnaaaammmmeeee will be run. Normally, this program
249: should be placed in LIBDIR.
250:
251: _2._1._1_6. _M_A_N_U_A_L_L_Y
252:
253: If this is defined, incoming rrrrmmmmggggrrrroooouuuupppp messages will not
254: remove the subdirectories, but rather just remove the group
255: line from your active file. You should have NOTIFY on if
256: you use this. Note that on a USG system the subdirectory
257: will not be removed anyway unless you have an unsecure (mode
258: 777 directory) system. This is turned off by default to
259:
260:
261:
262: May 3, 1983
263:
264:
265:
266:
267:
268: - 5 -
269:
270:
271: protect you against accidental or malicious removal of an
272: important newsgroup.
273:
274: _2._1._1_7. _B_A_T_C_H
275:
276: If set, this is the name of a program that will be used
277: to unpack batched articles (those beginning with the charac-
278: ter `#'). Batched articles normally are files reading
279:
280: #! rnews 1234
281: article containing 1234 characters
282: #! rnews 4321
283: article containing 4321 characters
284: etc.
285:
286:
287: _2._1._1_8. _B_E_R_K_N_A_M_E
288:
289: If your site is connected into USENET over a Berknet
290: link, specify the Berknet name of your site here.
291:
292: _2._1._1_9. _L_O_C_A_L_N_A_M_E
293:
294: Most systems have a full name database on line some-
295: where, showing for each user what their full name is. Most
296: often this is in the GCOS field of /etc/passwd. If your
297: system has such a database, LOCALNAME should be left unde-
298: fined. If not, define LOCALNAME, and articles posted will
299: only receive full names from local user information speci-
300: fied in NAME or ~/.name by the user. If you have a nonstan-
301: dard GCOS format (not finger or RJE) it will be necessary to
302: make local changes to fullname.c as appropriate on your sys-
303: tem.
304:
305: _2._1._2_0. _I_N_T_E_R_N_E_T
306:
307: If your system has a mailer that understands ARPA
308: Internet syntax addresses (user@domain) turn this on, and
309: replies will use the From or Reply-To headers. Otherwise,
310: leave it disabled and replies will use the Path header.
311:
312: _2._1._2_1. _M_Y_D_O_M_A_I_N
313:
314: When generating internet addresses, this domain will be
315: appended to the local site name to form mailing address
316: domains. For example, on system ucbvax with user root, if
317: MYDOMAIN is set to ``.UUCP'', addresses generated will read
318: ``[email protected]''. If MYDOMAIN is ``.Berkeley.ARPA'',
319: the address would be ``[email protected]''. If your
320: site is in more than one domain, use your primary domain.
321: The domain always begins with a period, unless the local
322: site name contains the domain; in this case MYDOMAIN should
323: be the null string.
324:
325:
326:
327:
328: May 3, 1983
329:
330:
331:
332:
333:
334: - 6 -
335:
336:
337: _2._1._2_2. _A_U_T_O_N_E_W_N_G
338:
339: If defined, any article that comes in with an invalid
340: newsgroup will automatically cause the newsgroup to be
341: created. In the past this was enabled, but now it is dis-
342: abled to prevent typographical errors at sites running older
343: versions of news that do not prevent postings with bad
344: groups from creating newsgroups all over the network. It is
345: recommended that this be left disabled, although a new site
346: coming up without a complete active file may wish to run
347: with it enabled for a few weeks.
348:
349: _2._1._2_3. _C_H_E_A_P
350:
351: Do not chown spool files to news. Used for obscure
352: accounting reasons on some systems.
353:
354: _2._1._2_4. _O_L_D
355:
356: Define this if any of your USENET neighbors run 2.9 or
357: earlier versions of B news. It will cause all headers writ-
358: ten to contain two extra lines: Article-I.D. and Posted, for
359: upward compatibility. Once all your neighbors have con-
360: verted, you can save disk space and transmission costs by
361: turning this off.
362:
363: _2._1._2_5. _U_N_A_M_E
364:
365: Define this if the uname system call is available
366: locally, even though you are not a USG system. USG systems
367: always have uname available and ignore this setting.
368:
369: _2._1._2_6. _G_H_N_A_M_E
370:
371: Define this if the 4.2BSD gethostname system call is
372: available. If neither UNAME or GHNAME is defined, inews
373: will determine the name of the local system by reading
374: /usr/include/whoami.h.
375:
376: _2._1._2_7. _V_7_M_A_I_L
377:
378: Define this if your system uses V7 mail conventions.
379: The V7 mail convention is that a mailbox contains several
380: messages concatenated, each message beginning with a line
381: reading ``From user date'' and ending in a blank line. If
382: this is defined, articles saved will have these lines added
383: so that mail can be used to look at saved news.
384:
385: _2._1._2_8. _M_Y_O_R_G
386:
387: This should be set to the name of your organization.
388: Please keep the name short, because it will be printed,
389: along with the electronic address and full name of the
390: author of each message. 40 characters is probably a good
391:
392:
393:
394: May 3, 1983
395:
396:
397:
398:
399:
400: - 7 -
401:
402:
403: upper bound on the length. If the city and state or country
404: of your organization are not obvious, please try to include
405: them. If the organization name begins with a `/', it will
406: be taken as the name of a file. The first line in that file
407: will be used as the organization. This permits the same
408: binary to be used on many different machines. A good file
409: name would be `/usr/lib/news/organization'. For example, an
410: organization might read ``Bell Labs, Murray Hill'', or
411: ``U.C. Berkeley'' or ``MIT'' or ``Computer Corp. America,
412: Cambridge, Mass''.
413:
414: There are other parameters that may be modified in
415: ddddeeeeffffssss....hhhh, and they are described in the file.
416:
417: _2._2. _M_a_k_e_f_i_l_e
418:
419: There are also a few parameters in the MMMMaaaakkkkeeeeffffiiiilllleeee as
420: well. These are:
421:
422: _2._2._1. _N_E_W_S_U_S_R
423:
424: This is the owner (user name) of _i_n_e_w_s. If you are a
425: superuser, you should probably create a new user id (tradi-
426: tionally nnnneeeewwwwssss) and use this id. If you are not a superuser,
427: you can use your own user id. If you are able to, you
428: should create a mail alias uuuusssseeeennnneeeetttt and have mail to this
429: alias forwarded to you. This will make it easier for other
430: sites to find the right person in the presence of changing
431: jobs and out of date or nonexistent directory pages.
432: NEWSUSR and ROOTID do not need to represent the same user.
433:
434: _2._2._2. _N_E_W_S_G_R_P
435:
436: This is the group (name) to which _i_n_e_w_s belongs. The
437: same considerations as NEWSUSR apply.
438:
439: _2._2._3. _S_P_O_O_L_D_I_R
440:
441: This directory contains subdirectories in which news
442: articles will be stored. It is normally /usr/spool/news.
443:
444: Briefly, for each newsgroup (say nnnneeeetttt....ggggeeeennnneeeerrrraaaallll) there
445: will be a subdirectory /usr/spool/news/net/general contain-
446: ing articles, whose filenames are sequential numbers, e.g.
447: /usr/spool/news/net/general/1, etc.
448:
449: Each article file is in a mail-compatible format. It
450: begins with a number of header lines, followed by a blank
451: line, followed by the body of the article. The format has
452: deliberately been chosen to be compatible with the ARPANET
453: standard for mail documented in RFC 822.
454:
455: You should place news in an area of the disk with
456: enough free space to hold news you intend to keep on line.
457:
458:
459:
460: May 3, 1983
461:
462:
463:
464:
465:
466: - 8 -
467:
468:
469: The total volume of news in net.all currently runs about
470: 3MB/week. If you expirenews after the default 2 weeks, you
471: will need about 6MB of disk space (plus some extra as a
472: safety margin and to allow for increased traffic in the
473: future.) If you only receive some of the newsgroups, or
474: expire news after a different interval, these figures can be
475: adjusted accordingly. Other newsgroup classes do not add
476: much to the volume; fa.all accounts for only about
477: 80KB/week, and btl.all+bell.all are only about 450KB/week.
478:
479: _2._2._4. _L_I_B_D_I_R
480:
481: This directory will contain various system files. It
482: is normally /usr/lib/news.
483:
484: _2._2._5. _B_I_N_D_I_R
485:
486: This is the directory in which _i_n_e_w_s, _r_e_a_d_n_e_w_s, and
487: _c_h_e_c_k_n_e_w_s are to be installed. This is normally /usr/bin.
488: If you decide to set BINDIR to a local binary directory, you
489: should consider that the rrrrnnnneeeewwwwssss command must be in a direc-
490: tory that can be found by uuuuuuuuxxxxqqqqtttt, which only searches /bin
491: and /usr/bin unless you modify uuxqt.
492:
493: _3. _F_I_L_E_S
494:
495: This section lists the files in LIBDIR and comments
496: briefly what they do.
497:
498: _3._1. _a_c_t_i_v_e
499:
500: A list of active newsgroups. Automatically updated as
501: new newsgroups come in. The order here is the order news is
502: presented by rrrreeeeaaaaddddnnnneeeewwwwssss, so you can edit this file to put
503: important newsgroups first. Each line of the active file
504: contains two fields: the newsgroup name, and the highest
505: local article number (for the most recently received arti-
506: cle), separated by a space. Local article numbers begin at
507: 1 and count sequentially within the newsgroup as articles
508: are received. They do not usually correspond to local arti-
509: cle numbers on other sites. The article number is always
510: stored as a 5 digit number (with leading zeros) to allow
511: updating of the file in place.
512:
513: _3._2. _c_a_e_s_a_r
514:
515: A program to do caesar decoding of rotated text, on a
516: line by line basis. The standard input is copied to the
517: standard output, rotating each line according to a static
518: single letter frequency table. If an integer argument is
519: given (e.g. 13), every line is rotated by that argument,
520: without regard to letter frequencies. This program is
521: invoked by the ``D'' readnews command, and may also be used
522: with the ``13'' argument to encode material for posting.
523:
524:
525:
526: May 3, 1983
527:
528:
529:
530:
531:
532: - 9 -
533:
534:
535: _3._3. _h_e_l_p
536:
537: A list of commands printed when an illegal command is
538: typed to rrrreeeeaaaaddddnnnneeeewwwwssss.
539:
540: _3._4. _h_i_s_t_o_r_y
541:
542: A list of every article that has come in to your sys-
543: tem. Used to reject articles that come in for the second
544: time (presumably via a different path). This file will grow
545: but is cleaned out by the expire command.
546:
547: _3._5. _h_i_s_t_o_r_y._d_i_r,_h_i_s_t_o_r_y._p_a_g
548:
549: These two files are used on V7 systems as a hashed ver-
550: sion of history, containing the message ID's of all articles
551: in history. They are only used if -DDBM and -ldbm appear in
552: the Makefile.
553:
554: _3._6. _l_o_g
555:
556: If present, a log of articles processed and error con-
557: ditions is kept here. This file grows without limit unless
558: cleaned out periodically, the trimlib script in misc can be
559: invoked from /usr/lib/crontab daily or weekly to keep the
560: log short.
561:
562: _3._7. _n_g_f_i_l_e
563:
564: A list of newsgroups that you can legally post to
565: locally. Actually it's a pattern, so if you include aaaallllllll it
566: will allow everything. You probably want to forbid ffffaaaa....aaaallllllll
567: here. It is also possible to control what newsgroups you
568: will accept from other sites using a different mechanism -
569: see the section on the format of the ssssyyyyssss file.
570:
571: _3._8. _n_o_t_i_f_y
572:
573: If this file is present, it's contents will be taken as
574: the name of the user to notify in case of a problem. If the
575: file is empty, nobody will be notified. (This overrides the
576: NOTIFY option in defs.h.) This is useful if one person
577: administers several systems and does not want multiple
578: copies of control message notifications.
579:
580: _3._9. _r_e_c_n_e_w_s
581:
582: A program which allows you to send mail to get news
583: posted. You usually need to run sssseeeennnnddddmmmmaaaaiiiillll or ddddeeeelllliiiivvvveeeerrrrmmmmaaaaiiiillll to
584: be able to use this.
585:
586:
587:
588:
589:
590:
591:
592: May 3, 1983
593:
594:
595:
596:
597:
598: - 10 -
599:
600:
601: _3._1_0. _r_e_c_o_r_d_i_n_g
602:
603: A list of newsgroup classes and file names to display
604: recordings for. The recording feature is analogous to the
605: recordings played in some areas when you dial directory
606: assistance, trying to be annoying and make you think twice.
607: Recordings on certain newsgroups are intended to remind the
608: user of the rules for the newsgroup, or, in the case of a
609: company worried about letting proprietary information out,
610: reminding authors that anything they say is seen outside the
611: company and so proprietary information should not be
612: included.
613:
614: The file contains one line per recording. The line
615: contains two fields, separated by a space. The first field
616: is the newsgroup class (e.g. ``net.all''), the second field
617: is the name of the file containing the recorded message. If
618: the file name does not begin with a slash, it will be
619: searched for in LIBDIR. Sample recording files can be found
620: in the misc directory.
621:
622: _3._1_1. _s_e_n_d_n_e_w_s
623:
624: A program to send news internally from one computer to
625: another. Useful if you use mail links to transmit articles.
626:
627: _3._1_2. _s_e_q
628:
629: The current sequence number for your system. Used to
630: generate unique article ID's.
631:
632: _3._1_3. _s_y_s
633:
634: A list of all your neighbors, which newsgroups they
635: get, and how to send news to them. The format is documented
636: below.
637:
638: _3._1_4. _u_s_e_r_s
639:
640: A list of users that read news on your system.
641:
642: _3._1_5. _u_u_r_e_c
643:
644: A program to receive news sent by sssseeeennnnddddnnnneeeewwwwssss.
645:
646: _4. _S_e_t_t_i_n_g _U_p _L_i_n_k_s
647:
648: There are two basic types of links for exchanging news:
649: those that use mail and those that don't. The ones that use
650: mail are more indirect, yet more versatile while the ones
651: that don't are simpler. The default is without mail so that
652: is discussed first.
653:
654:
655:
656:
657:
658: May 3, 1983
659:
660:
661:
662:
663:
664: - 11 -
665:
666:
667: _4._1. _N_o_n-_m_a_i_l _L_i_n_k_s
668:
669: The basic theory behind a non-mail link is that the
670: _r_n_e_w_s program is invoked on the remote system with the arti-
671: cle being transmitted as the standard input. This is possi-
672: ble on some networks, but the most common implementation is
673: via the UUUUUUUUCCCCPPPP network. Using the _u_u_x(_1_C) command, the com-
674: mand which is forked to the shell looks like:
675: uuuuuuuuxxxx ---- ----rrrr ----zzzz rrrreeeemmmmooootttteeeessssyyyyssss!!!!rrrrnnnneeeewwwwssss <<<< aaaarrrrttttiiiicccclllleeee
676: This is the default transmission method. In order to set up
677: such a link, obviously a UUUUUUUUCCCCPPPP link with the remote system
678: must be in effect. In addition, _r_n_e_w_s must be available and
679: executable by _u_u_x_q_t on the remote machine. In most cases,
680: this means that _r_n_e_w_s must be in /usr/bin so _u_u_x can find
681: it. Also, /usr/src/cmd/uucp/uuxqt.c should be checked to
682: make sure that rnews is an allowed command.
683:
684: Other networks that allow remote execution include the
685: Berknet, BLICN (usend), many Ethernets, and the NSC hyper-
686: channel (nusend). It is important, however, that a spooling
687: mechanism be available. Otherwise, if system A tries to
688: send an article to system B via a remote execution command,
689: and B is down, the article could be lost. Spooling arranges
690: that the system will try again when B comes back up.
691:
692: _4._2. _M_a_i_l _L_i_n_k_s
693:
694: When using mail to transmit articles, two intermediary
695: programs are necessary. These are _s_e_n_d_n_e_w_s(_8) and _u_u_r_e_c(_8).
696: The idea is that when system A wants to send an article to
697: system B, the sys file on system A has an entry for system B
698: such as:
699:
700: /usr/lib/news/sendnews -a rnews@B
701:
702: which runs _s_e_n_d_n_e_w_s on the article. The -a option specifies
703: that the mail should be formatted for the arpanet. Sendnews
704: packages the article and mails it to rnews@B. Somehow, the
705: B system is expected to make sure that all mail to user
706: ``rnews'' is fed as input to the program _u_u_r_e_c. This pro-
707: gram unpackages it and invokes rnews.
708:
709: The best way to get mail to rnews fed into _u_u_r_e_c is to
710: use sendmail or delivermail, if you are on a system running
711: them. Create an alias in /usr/lib/aliases as follows:
712:
713: rnews: "|/usr/lib/news/uurec"
714:
715: and sendmail will handle it. If you do not have a facility
716: for forwarding mail to a program, you can gimmick your
717: mailer to watch for it (using _p_o_p_e_n(3S), this is easy) or,
718: if you don't want to do any programming, you can have _c_r_o_n
719: invoke uurec every hour with /usr/spool/mail/rnews as stdin.
720: This solution is messier because uurec must potentially deal
721:
722:
723:
724: May 3, 1983
725:
726:
727:
728:
729:
730: - 12 -
731:
732:
733: with multiple messages, something that has never been
734: tested.
735:
736: _5. _F_o_r_m_a_t _o_f _t_h_e _s_y_s _f_i_l_e
737:
738: To set up a link to another site, edit the ssssyyyyssss file in
739: LIBDIR. This file is similar to the L.sys file of uucp.
740: Each line contains four fields, separated by colons:
741:
742: (1) The system name of a site to which you forward news.
743: Normally all systems you have links to will be
744: included. You should also have a line for your own
745: system.
746:
747: (2) The newsgroups to be forwarded to them. This is a pat-
748: tern in the sense of a subscription. Generally, you
749: will list classes of newsgroups, that is, using ``all''
750: for everything. A typical forwarding list for a new
751: site would be
752:
753: net.all,fa.all,to.sysname
754:
755: where ssssyyyyssssnnnnaaaammmmeeee is the name of the remote system. In
756: particular, you don't want to forward aaaallllllll since local
757: newsgroups (those without dots) should not be sent.
758: For the line describing your own system, this field
759: describes the newsgroups your site will accept from
760: remote sites. Thus, if another site insists on sending
761: you a newsgroup you don't want, say nnnneeeetttt....jjjjooookkkkeeeessss, include
762: !!!!nnnneeeetttt....jjjjooookkkkeeeessss here. (You will have to add -DRESTRICT to
763: CFLAGS in your Makefile or this won't have any effect.)
764: This measure is on top of AUTONEWNG, which will nor-
765: mally prevent unknown newsgroups from being forwarded
766: if disabled. RESTRICT allows certain newsgroups never
767: to be forwarded even if recreated.
768:
769: (3) This field contains flags describing the connection.
770: An A will indicate that the other site is running an A
771: version of netnews. A B indicates a B version. Leav-
772: ing it empty defaults to B. If you are reading this
773: document, you have a B version. Some existing sites
774: run A versions. If you aren't sure, ask your contact
775: at the other site, with whom you should be talking to
776: set this up anyway. The F flag indicates that the
777: fourth field is the name of a file. The full path name
778: of a file containing the article in SPOOL will be
779: appended to this file. The L flag prevents transmis-
780: sion unless the article was created on this site. (It
781: is recommended that you feed an L link to a backbone
782: site, to ensure that your submissions will be more
783: likely to get to the entire network, even in the event
784: of a local problem. Please make sure that a mail link
785: exists too, so you can get replies.) The N flag can
786: also be included here, indicating that mail should be
787:
788:
789:
790: May 3, 1983
791:
792:
793:
794:
795:
796: - 13 -
797:
798:
799: sent using the iiiihhhhaaaavvvveeee////sssseeeennnnddddmmmmeeee protocol described below.
800: The U field arranges that the parameter to the optional
801: %s in the command field to be filled in with a per-
802: manent file name from SPOOL instead of a temporary cus-
803: tomized file name.
804:
805: (4) This field is the command to be run to send news to the
806: remote site. The article will be on the standard
807: input. Leaving this field blank means an ordinary uucp
808: link is being used, that is, the command defaults to
809:
810: uux - -r -z sysname!rnews
811:
812: The - option tells uux to expect input on stdin. The
813: -z option is nonstandard - you should add it, see the
814: minus.z* files in the uucp directory. It shuts off the
815: annoying message you would otherwise get mailed to you
816: telling you that your article was broadcast OK. To
817: avoid using the -z option, change the source or put the
818: uux command in the fourth field. The -r option tells
819: uux not to start up a daemon right away. This turns
820: out to ease the load on the system, at the expense of
821: making news be transmitted a bit slower. The news will
822: be sent when the next daemon is started, usually this
823: means the next time mail is sent to or from your sys-
824: tem. If this turns out to be unreasonably long, put a
825: line in crontab to run
826:
827: /usr/lib/uucp/uucico -r1
828:
829: every hour or so.
830:
831: Here is a sample sys file for a site ``myvax'' with
832: connections to ``yourvax'' where myvax also passes news on
833: to ``downstream''. We assume that ``myvax'' and ``down-
834: stream'' exchange a local newsgroup class lng.all as well as
835: the network wide newsgroups. News to ``downstream'' is
836: batched.
837:
838: myvax:net.all,fa.all,lng.all::
839: yourvax:net.all,fa.all::
840: downstream:net.all,fa.all,lng.all:F:/usr/spool/batch/downstream
841:
842:
843: _6. _P_o_s_t_i_n_g _M_e_t_h_o_d_s
844:
845: There are three ways to post news. The basic method is
846: to use the iiiinnnneeeewwwwssss command:
847:
848: iiiinnnneeeewwwwssss ----tttt _t_i_t_l_e ----nnnn _n_e_w_s_g_r_o_u_p_s < _b_o_d_y_f_i_l_e
849:
850: This is the primitive used by other programs, and is not
851: very suitable for humans.
852:
853:
854:
855:
856: May 3, 1983
857:
858:
859:
860:
861:
862: - 14 -
863:
864:
865: A somewhat friendlier front end is ppppoooossssttttnnnneeeewwwwssss. This pro-
866: gram will prompt you for the title, newsgroups, and distri-
867: bution, then place you in the editor. (The system default
868: EDITOR is used unless the environment variable EDITOR is
869: set, overriding the system default.) The text should be
870: typed after the blank line. The title and newsgroups are
871: available for editing at the top of the buffer. Other
872: header lines can be added, such as an expiration date or
873: distribution. When you write out the file and exit from the
874: editor, the article will be posted.
875:
876: Another method is to use mail. This can only be done
877: on systems that allow mail to a given name to be fed into an
878: arbitrary program as input. This is easily done with the
879: Berkeley delivermail or sendmail program, and not with any
880: other mailer the author is familiar with. (It may be possi-
881: ble to painfully set this up with MMDF, provided the news-
882: group name is no more than 8 characters long.) To use mail,
883: set up an alias such as the following:
884:
885: net.general: "|/usr/lib/news/recnews net.general"
886:
887: Whenever a user sends mail to nnnneeeetttt....ggggeeeennnneeeerrrraaaallll, this starts up
888: the given shell command which calls recnews with one argu-
889: ment, the name of the newsgroup. You need to create one
890: alias for each newsgroup, and to keep the list up to date as
891: new newsgroups are created. RRRReeeeccccnnnneeeewwwwssss will in turn invoke
892: iiiinnnneeeewwwwssss.
893:
894: Note that there are problems with recnews. There is no
895: way to use it to post to multiple newsgroups without creat-
896: ing separate articles (something frowned upon because it
897: forces people to read the same thing more than once.) Also,
898: there is no way to make the recording feature (to safe guard
899: proprietary information) work when recnews is used.
900:
901: _7. _V_a_r_i_o_u_s _c_o_n_s_i_d_e_r_a_t_i_o_n_s
902:
903: _7._1. _S_u_i_d _b_i_t_s
904:
905: The current intended state of affairs is that _i_n_e_w_s
906: runs suid NEWSUSR. The _r_e_a_d_n_e_w_s program does not need to be
907: suid. This makes it possible to write your own interface to
908: read news instead of using readnews. (As distributed, _i_n_e_w_s
909: is also sgid. I know of no good reason for this.)
910:
911: _7._2. _M_o_d_e_s _o_f _S_p_o_o_l _D_i_r_e_c_t_o_r_i_e_s
912:
913: All the files should be writable by NEWSUSR. However,
914: due to a glitch, you will probably have to make the SPOOLDIR
915: and its subdirectories mode 777. It could be 755 except for
916: one problem. When a new newsgroup comes in, _i_n_e_w_s will
917: attempt to _m_k_d_i_r a new subdirectory of SPOOLDIR for the
918: newsgroup. Since both inews and mkdir are suid, mkdir will
919:
920:
921:
922: May 3, 1983
923:
924:
925:
926:
927:
928: - 15 -
929:
930:
931: use the real uid instead of NEWSUSER when checking for per-
932: missions, and if the directory isn't 777 the check will
933: fail. Here are several alternatives if you don't want a 777
934: directory around:
935:
936: _7._2._1. _F_i_x _R_e_a_l _U_i_d
937:
938: If inews is always run from cron or by root, the real
939: uid can be arranged to be root or NEWSUSR. This is a poor
940: solution since it makes the local creation of new newsgroup
941: require super user permissions, and is a potential security
942: hole. If this approach is taken, care must be taken to
943: insure that the owner of the created directory is NEWSUSR.
944:
945: _7._2._2. _C_h_a_n_g_e _t_h_e _K_e_r_n_e_l
946:
947: _i_n_e_w_s will do _s_e_t_u_i_d(_g_e_t_e_u_i_d()) before it forks the
948: mkdir. If your system permits this call, there will be no
949: problem. In particular, Berkeley 4.0BSD and later systems
950: allow this. An alternative change to the kernel is to
951: automatically stack uids: when an suid program is run, set
952: the new real uid to the old effective uid.
953:
954: _7._2._3. _G_r_o_u_p_s
955:
956: You could have inews be sgid NEWSGRP and all files
957: writable by the group. This approach has been tested and
958: the problem turns out to be that the mmmmkkkkddddiiiirrrr command uses the
959: aaaacccccccceeeessssssss system call to check permissions. Since aaaacccccccceeeessssssss uses
960: the real gid, you run into the same problem.
961:
962: _7._2._4. _A_n_o_t_h_e_r _m_k_d_i_r
963:
964: You could create a version of mkdir that does less
965: checking, and put it in a directory that can only be
966: accessed by NEWSUSR (mode 700, owned by NEWSUSR). Have
967: inews fork this mkdir.
968:
969: _7._3. _E_x_p_i_r_a_t_i_o_n _d_a_t_e_s
970:
971: To get articles to expire automatically, put a line in
972: crontab to run
973:
974: ////uuuussssrrrr////lllliiiibbbb////nnnneeeewwwwssss////eeeexxxxppppiiiirrrreeee
975:
976: every night. This command deletes all expired news. The -a
977: option causes all expired news to be archived under
978: /usr/spool/oldnews.
979:
980: Sometimes news is not expired when it should be. Be
981: sure to check that expire has permissions to unlink files,
982: that it runs as a user that has a .newsrc, and that it is
983: properly suid. You can manually invoke expire with the -v
984: (verbose) option to find out what it's doing. Adding levels
985:
986:
987:
988: May 3, 1983
989:
990:
991:
992:
993:
994: - 16 -
995:
996:
997: of verbosity (e.g. -v6) will get more and more output.
998:
999: _7._4. _V_e_r_s_i_o_n _t_o _V_e_r_s_i_o_n
1000:
1001: Version B will understand incoming news in either ver-
1002: sion A or B format, automatically. Version B will generate
1003: either format, depending on the flag in the 3rd field of the
1004: sys line. Version A will not understand version B format.
1005: Thus, it is possible for two version B sites to communicate
1006: using version A format. This will work but is not a good
1007: idea, since the translation from B to A loses information
1008: (such as the expiration date) which will not be there when
1009: translated back to version B.
1010:
1011: News from versions A and 2.9 B do not conform to the
1012: USENET interchange standard. 2.10 supports the standard and
1013: will communicate with either A or 2.9 B news. A news is
1014: written (losing other header information) if A is in the
1015: flags for the system. If OLD is defined, 2.10 will write
1016: out headers with both standard (Date, Message-ID) and 2.9
1017: (Posted, Article-I.D.) lines so that either B system will
1018: properly handle the article. Incoming news is recognized by
1019: the first letter (``A'' for A news), or the lack of an ``@''
1020: in the From line (2.9). Missing fields are constructed as
1021: well as possible from the available information.
1022:
1023: _7._5. _P_r_e_s_e_n_t_a_t_i_o_n _O_r_d_e_r
1024:
1025: The order of the newsgroups listed in LIBDIR/active is
1026: the order the newsgroups will be presented in. Initially
1027: this will be directory order, but you can edit important
1028: newsgroups like general to the top.
1029:
1030: A recommended order to maintain your active file in is
1031: this:
1032:
1033: general
1034: local.general
1035: net.general
1036: net.followup
1037: local newsgroups, in alphabetical order
1038: net.all newsgroups, in alphabetical order
1039: junk
1040: fa.all, in alphabetical order
1041: test
1042: all.test
1043: to.all
1044: control
1045:
1046:
1047: _8. _C_o_n_t_r_o_l _M_e_s_s_a_g_e_s
1048:
1049: Some news systems will send you articles that are not
1050: for human consumption. They are messages to your news
1051:
1052:
1053:
1054: May 3, 1983
1055:
1056:
1057:
1058:
1059:
1060: - 17 -
1061:
1062:
1063: system called _c_o_n_t_r_o_l _m_e_s_s_a_g_e_s. Such messages contain the
1064: Control: header. Older systems use newsgroups matching
1065: aaaallllllll....aaaallllllll....ccccttttllll, and this will still work, although the Control:
1066: header is preferred. Since the newsgroup name is used for
1067: distribution only, and is not checked to ensure it's in the
1068: active file, such newsgroup names can still be used. This
1069: makes it possible to post network wide control messages with
1070: nnnneeeetttt....mmmmssssgggg....ccccttttllll (or restricted broadcast such as bbbbttttllll....mmmmssssgggg....ccccttttllll) or
1071: messages for a particular system: ttttoooo....uuuuccccbbbbvvvvaaaaxxxx....ccccttttllll. Messages
1072: are cancelled, however, with a Control: line in a message to
1073: the same newsgroup(s) as the original message.
1074:
1075: A control message contains a command and zero or more
1076: arguments (much like a UNIX program). The subject of the
1077: article contains the command and arguments. The body of the
1078: article is usually ignored, although some messages can use
1079: it for additional text information. Control messages are
1080: not stored in SPOOL, rather they are acted on and discarded
1081: at once.
1082:
1083: _8._1. _i_h_a_v_e/_s_e_n_d_m_e
1084:
1085: Two control messages are iiiihhhhaaaavvvveeee and sssseeeennnnddddmmmmeeee. These mes-
1086: sages allow two participating sites to set up a link so that
1087: one site will tell the other site it has a given article and
1088: wait for a request before it actually sends it. The normal
1089: case is to send an entire article to a system, which con-
1090: sults the history file to see if the article has already
1091: been seen, and then throws it away if it's been seen before.
1092:
1093: Note that, since most messages are short anyway,
1094: experience has indicated that for ordinary UUCP unbatched
1095: communication, all ihave/sendme does is triple the load and
1096: slow down forwarding. Hopefully future code will allow
1097: ihave's with multiple message ID's in the body, and existing
1098: code in 2.10 understands such messages, but does not gen-
1099: erate them. So we advise that you don't use ihave/sendme
1100: for now.
1101:
1102: Use of these control messages can cut down on this
1103: wasted transmission, but if you have a polled UUCP connec-
1104: tion, they can slow down receipt of news due to polling
1105: delays. It is up to each connected pair of sites whether
1106: they want to use this protocol. The choice is controlled by
1107: the N flag in the sys file. In the case of a leaf node (one
1108: with only one neighbor) there is no advantage to this proto-
1109: col. Even if both sites are able to initiate a connection
1110: (have dialers or the link is hardwired) the -r option on the
1111: uux can cause 2 hour or more delays in propagating news.
1112: Since this protocol can triple the number of messages gen-
1113: erated, you should carefully evaluate your situation when
1114: deciding whether to use it. If transmission time and phone
1115: bills dominate your costs, and you are sending news to
1116: several sites, and large article bodies dominate the costs
1117:
1118:
1119:
1120: May 3, 1983
1121:
1122:
1123:
1124:
1125:
1126: - 18 -
1127:
1128:
1129: (rather than the headers and the time spent by UUCP nego-
1130: tiating transmission) it is probably worthwhile to use
1131: ihave/sendme. If your costs are dominated by CPU load from
1132: UUCP, or if you send news to a site that cannot get it from
1133: anywhere else, you probably do not want to use this proto-
1134: col. The decision can be made independently for each site
1135: in your sys file.
1136:
1137: This pair works as follows: Site mmmmyyyyssssiiiitttteeee receives arti-
1138: cle <<<<111122223333@@@@aaaabbbbcccc....UUUUUUUUCCCCPPPP>>>>. It enters it locally and then broad-
1139: casts it to its neighbors. One of its neighbors is site
1140: yyyyoooouuuurrrrssssiiiitttteeee which has the N flag in the ssssyyyyssss file. So mysite
1141: sends an article on newsgroup to.yoursite.ctl with title
1142: ``ihave <[email protected]> mysite''. This control message has
1143: two arguments - the first (<[email protected]>) is the article ID
1144: of the article in question, the second (mysite) is the name
1145: of the site sending the article. The name of the newsgroup
1146: and the sys file control transmission of the article, nor-
1147: mally the sys file will read something like
1148:
1149: yoursite:net.all,fa.all,to.yoursite:BN:
1150:
1151: which will cause an article on to.yoursite.ctl to be
1152: transmitted.
1153:
1154: Yoursite receives the message and looks to see if it
1155: has seen it before. If it has, it throws the message away
1156: and stops. If it hasn't, it sends a message on
1157: to.mysite.ctl with title ``sendme <[email protected]> yoursite''
1158: which is transmitted to mysite. (The two arguments to
1159: sendme are the article ID requested and the site to send it
1160: to.) Then mysite gets this message and actually transmits
1161: the article to yoursite.
1162:
1163: _8._2. _n_e_w_g_r_o_u_p
1164:
1165: This message has one argument, the name of a newsgroup
1166: to be created. This allows special action to be taken
1167: locally when a new newsgroup is created. It is generated by
1168: the -C option to inews. By default, the newsgroup is added
1169: to the active file and a directory is created, and mail is
1170: sent to the local contact advising that this has happened.
1171: See the routine ``c_newgroup'' in control.c if you want
1172: something different to happen. (Note that, although the
1173: body of the message contains a brief description of the pur-
1174: pose of the group, this body is usually thrown away by
1175: existing software.)
1176:
1177: _8._3. _r_m_g_r_o_u_p
1178:
1179: This message has one argument, the name of a newsgroup
1180: to be removed. It is used for network-wide cancellation of
1181: a newsgroup. If MANUALLY is not defined, it will remove the
1182: articles, directory, and active file line for the group.
1183:
1184:
1185:
1186: May 3, 1983
1187:
1188:
1189:
1190:
1191:
1192: - 19 -
1193:
1194:
1195: There is a shell script rrrrmmmmggggrrrrpppp that does essentially the same
1196: thing as this message, but the shell script only removes the
1197: group locally. We recommend that you leave MANUALLY
1198: defined, and when you receive mail advising you of the dem-
1199: ise of the newsgroup, you run rmgrp by hand. This will
1200: prevent accidental or malicious removal of a good newsgroup.
1201:
1202: _8._4. _c_a_n_c_e_l
1203:
1204: This message cancels a given article. It takes one
1205: argument, the message ID of the article to cancel. It
1206: should be broadcast to the same newsgroup as the original
1207: article.
1208:
1209: _8._5. _s_e_n_d_s_y_s
1210:
1211: The sys file is mailed to the originator of the mes-
1212: sage. There are no arguments. This is used for making
1213: maps. Since your sys file is public information, you should
1214: not remove or change this control message.
1215:
1216: _8._6. _s_e_n_d_u_u_n_a_m_e
1217:
1218: The uuuuuuuunnnnaaaammmmeeee(1) program is run and the output is mailed
1219: to the originator of the message. There are no arguments.
1220: This is used for making uucp maps. If you do not run UUCP
1221: or have sites in your L.sys which are a secret, you may wish
1222: to edit this. Note that only the output of uuname is
1223: mailed, not the contents of L.sys (which news does not have
1224: access to anyway). If you do make a change, you should
1225: arrange that some mail still is sent out to the originator
1226: of the message, so he will know your site received it. See
1227: the code in routine c_senduuname in control.c.
1228:
1229: _8._7. _v_e_r_s_i_o_n
1230:
1231: The local version name/number of the netnews software
1232: is mailed back to the author of the control message.
1233:
1234: _8._8. _O_t_h_e_r _M_e_s_s_a_g_e_s
1235:
1236: Any unrecognized message will cause an error message to
1237: be mailed to the originator. Additional messages may be
1238: defined as time goes on, such as messages to automatically
1239: update directories or maps. You should be willing to go
1240: into the code (control.c) and add messages as they become
1241: standardized.
1242:
1243: _9. _M_a_i_n_t_e_n_a_n_c_e
1244:
1245: There are some things you should do periodically to
1246: keep your news system running smoothly. We hope to eventu-
1247: ally automate all or most of this, but right now some of it
1248: must be done by hand.
1249:
1250:
1251:
1252: May 3, 1983
1253:
1254:
1255:
1256:
1257:
1258: - 20 -
1259:
1260:
1261: The hhhhiiiissssttttoooorrrryyyy and lllloooogggg files in your LIB directory will
1262: grow. You should make sure that they are cleaned up period-
1263: ically. The LIB/expire program will remove lines from his-
1264: tory corresponding to deleted articles, but it is a good
1265: idea to check the file every few months to make sure it is
1266: not going wild. Be sure not to completely lose your history
1267: file when you clean it up, in case another neighbor tries to
1268: send you an article you recently got. (If you only get news
1269: from one site it is safe to clean it out completely.)
1270:
1271: The log file is not automatically cleaned out by any
1272: netnews software, and will grow quickly. The misc/trimlib
1273: script can be installed in LIB/trimlib, and invoked weekly
1274: from /usr/lib/crontab.
1275:
1276: You should also clean out old newsgroups that are no
1277: longer active. To remove a newsgroup net.foo, you should do
1278: the following: First, remove the subdirectory SPOOL/net/foo.
1279: Second, remove the line net.foo from your active file. (It
1280: is no longer necessary to remove the net.foo lines from
1281: people's .newsrc files, because readnews will clean them out
1282: and reorder their files.) Here is a shell script to remove
1283: newsgroups:
1284:
1285: : rmgrp newsgroup ...
1286: cd /usr/spool/news
1287: for i in $*
1288: do
1289: echo removing $i
1290: rm -rf `echo $i | sed 's:\.:/:'`
1291: cp /usr/lib/news/active /tmp/rmg$$
1292: sed /^$i /d < /tmp/rmg$$ > /usr/lib/news/active
1293: done
1294: rm /tmp/rmg$$
1295:
1296:
1297: Note that clearing up UUCP constipation is another
1298: thing you'll have to do if you have flaky hardware or phone
1299: lines. If you have more than one connection, chances are
1300: that UUCP will get clogged up when one of your neighbors
1301: goes down for more than a few hours. Various spooling
1302: schemes are being worked on to help make the news/uucp sys-
1303: tem more robust, but one thing you can and should do, if you
1304: find your /usr/spool/uucp directory getting too big, is to
1305: install a subdirectory fix to UUCP. A quick and dirty ver-
1306: sion of this is available from Duke, which traps the open,
1307: creat, link, etc. system calls at the assembly language
1308: level and maps, for example, D.fooA1234 into
1309: D.foo/D.fooA1234. Since the C. and D.local directories
1310: still get big, in practice this can still create some big
1311: directories, but the directories tend to be a factor of 5
1312: smaller, resulting in a factor of 25 improvement to speed
1313: (since a directory traversal for all files is quadratic on
1314: UNIX). Right now, UUCP is the weak link in netnews
1315:
1316:
1317:
1318: May 3, 1983
1319:
1320:
1321:
1322:
1323:
1324: - 21 -
1325:
1326:
1327: distribution, and you should certainly keep an eye on it.
1328:
1329: _1_0. _C_r_e_a_t_i_n_g _N_e_w _N_e_w_s_g_r_o_u_p_s
1330:
1331: As system news administrator, you are able to create
1332: newsgroups. To create a newsgroup, first make sure this is
1333: the right thing to do. (Normally a suggestion is first
1334: posted to net.general,net.news.group for a net newsgroup,
1335: followups are made to net.news.group, it is established if
1336: there is general interest in such a group, and a name is
1337: agreed on.) Then someone creates it by typing the command
1338:
1339: iiiinnnneeeewwwwssss ----CCCC _n_e_w_s_g_r_o_u_p
1340:
1341: This will create the directory and active entry locally. It
1342: will also prompt you for a paragraph describing the group
1343: and start up an inews to post a newgroup control message
1344: announcing the group. This control message will be sent out
1345: on net.msg.ctl and other sites may have configured their
1346: systems to do something with these messages. A human read-
1347: able announcement is not made - you can post this to
1348: net.news.group if necessary.
1349:
1350: Someone should post a first article to the new news-
1351: group immediately. If this is not done, the empty directory
1352: for the newsgroup will cause cccchhhheeeecccckkkknnnneeeewwwwssss to believe there is
1353: unread news, because each user has no .newsrc line for that
1354: newsgroup. This command creates the group network-wide. It
1355: is then possible to submit an article to the group.
1356:
1357: You must be the super user to use the -C option to
1358: inews. (That is, your uid must match ROOTID. It is recom-
1359: mended that you change ROOTID to your own uid so you don't
1360: have to su to create newsgroups.)
1361:
1362: A new site should get the active file from their neigh-
1363: bor and use the mmmmaaaakkkkeeeeaaaaccccttttiiiivvvveeee....sssshhhh shell script to create the
1364: local directory hierarchy and active file. (The local
1365: active file will have 00000 for each newsgroup, since local
1366: numbers will start at 1 for the first article received in
1367: each newsgroup.)
1368:
1369: _1_1. _C_o_n_v_e_r_s_i_o_n _f_r_o_m _A _t_o _B
1370:
1371: If you are currently running version A on your system,
1372: note that B is incompatible with A. The files are stored in
1373: a different format (headers have mail like field names now).
1374: The directory organization is different (each newsgroup has
1375: a subdirectory of its own, and the file names are numbers
1376: rather than site.id pairs). There are no bitmap, uindex, or
1377: nindex files to be trashed (which articles have been read is
1378: stored in each users .newsrc file). The user interface is
1379: slightly different (news/netnews is now called readnews,
1380: news is posted using inews, subscription is done by editing
1381:
1382:
1383:
1384: May 3, 1983
1385:
1386:
1387:
1388:
1389:
1390: - 22 -
1391:
1392:
1393: .newsrc, the sense of the -c option is reversed, news is
1394: presented in newsgroup order, the -a and -t options now
1395: probably need -x as well, and there are many minor changes).
1396:
1397: We decided not to provide a program to convert from
1398: version A to version B. Rather, the following strategy was
1399: adopted for conversion:
1400:
1401: (1) Install the new news in a different spool directory
1402: from the old one. For example, you can use
1403: /usr/spool/newnews. You can change to the standard
1404: name later if you want. Get it to work for local mes-
1405: sages.
1406:
1407: (2) Post an article to newsgroup ggggeeeennnneeeerrrraaaallll with the old news
1408: announcing the change. Make available documentation
1409: such as the accompanying paper ``How to Read the Net-
1410: work News'' to the users. This article will be the
1411: last one in the old news.
1412:
1413: (3) Chmod the old news directory to 555 to prevent any more
1414: news from being posted. (Actually, this will prevent
1415: the bitfile from being updated, so it may not be a good
1416: idea.)
1417:
1418: (4) Replace the old rnews program with the new rnews pro-
1419: gram.
1420:
1421: (5) Test it by having your neighbor send you a message.
1422:
1423: (6) Wait a reasonable period for everyone to have read the
1424: final article with the old news. Perhaps a few weeks
1425: is right.
1426:
1427: (7) Uninstall the old news.
1428:
1429: Users will have to invoke _r_e_a_d_n_e_w_s instead of _n_e_t_n_e_w_s
1430: to read news. Depending on your old method of posting, this
1431: could be changed too. (If you were using mail, it does not
1432: need to be changed.) They will also have to fix their sub-
1433: scriptions. In general, they can type
1434:
1435: netnews -s
1436:
1437: to see what they subscribe to on the old system, and then
1438: create a file in their home directory called .newsrc con-
1439: taining
1440:
1441: options -s _t_h_e_i_r _s_u_b_s_c_r_i_p_t_i_o_n
1442:
1443: The format of the subscription pattern matching is the same
1444: as in A except that ALL is replaced by all (change to lower
1445: case). Something along the lines of this could be used to
1446: automate this:
1447:
1448:
1449:
1450: May 3, 1983
1451:
1452:
1453:
1454:
1455:
1456: - 23 -
1457:
1458:
1459: (echo -n "options -s" ; netnews -s | sed s/ALL/all/) > .newsrc
1460:
1461:
1462: _1_2. _C_o_n_v_e_r_s_i_o_n _f_r_o_m _2._9 _t_o _2._1_0
1463:
1464: Conversion from 2.9 to 2.10 is not nearly as involved
1465: as an A to B conversion. The user interface does not change
1466: much, and the user .newsrc files are not affected. However,
1467: it is recommended that you do the conversion during a time
1468: when no news is received, so that incoming news will not get
1469: lost. One way to ensure this is to make /bin/rnews be a
1470: shell script which saves the article in /usr/spool/innews/$$
1471: ($$ is the process id of the particular shell and will be
1472: unique for each article).
1473:
1474: The first step to conversion is to customize the
1475: sources. In the past, you had to take a fresh distribution
1476: and edit the defs.h file and Makefile to suit local prefer-
1477: ences. If you had many local changes, or didn't record the
1478: local changes, upgrading could be annoying. 2.10 provides a
1479: mechanism to automate these changes. Create a shell script
1480: in the src directory called localize.sh. (You can use
1481: localize.sample as a template.) This shell script should
1482: copy either postnews.v7 or postnews.usg to postnews, copy
1483: defs.dist to defs.h, and copy either Makefile.v7 or
1484: Makefile.usg to Makefile. It should chmod any files that
1485: need to be changed (often Makefile and defs.h) to a writable
1486: mode. Then it should invoke eeeedddd on the files, making any
1487: necessary local changes.
1488:
1489: The next step is to compile the software, with
1490: ``make''. It may be necessary to update the localize.sh
1491: file until you are satisfied with the compilation. Note
1492: that after any change to the Makefile in localize.sh, you
1493: should run localize.sh by hand. Otherwise, although make
1494: will run it for you, it will then continue to do the make
1495: with the old Makefile.
1496:
1497: When the software is compiled, you should run the
1498: cvt.dots.sh shell script, with the lib and spool directories
1499: as parameters. This will create the new hierarchical spool
1500: directory, and a new active file in LIB/nactive. Old news
1501: will be linked into the new hierarchy while leaving links in
1502: the old hierarchy.
1503:
1504: Now you can test ./inews, ./checknews, and ./readnews,
1505: to make sure everything works. The newsgroup ``test'' is
1506: good for this.
1507:
1508: The next step is to back up the old binaries (mv
1509: /usr/bin/inews /usr/bin/oinews, etc.) and to install 2.10
1510: with ``make cp''. Move LIB/active to LIB/oactive and
1511: LIB/nactive to LIB/active. Once it is installed, any incom-
1512: ing news will be placed into the new hierarchy but not the
1513:
1514:
1515:
1516: May 3, 1983
1517:
1518:
1519:
1520:
1521:
1522: - 24 -
1523:
1524:
1525: old one. The critical time window is between running
1526: cvt.dots.sh and installing the new software - any incoming
1527: news between these two points will appear in only the old
1528: hierarchy and be lost to the new software. If any signifi-
1529: cant time elapses here, you should divert rnews into a
1530: separate spool directory as described above.
1531:
1532: Finally, test things by posting articles to to.neighbor
1533: newsgroups and watching some incoming news, and announce the
1534: change to your users.
1535:
1536:
1537:
1538:
1539:
1540:
1541:
1542:
1543:
1544:
1545:
1546:
1547:
1548:
1549:
1550:
1551:
1552:
1553:
1554:
1555:
1556:
1557:
1558:
1559:
1560:
1561:
1562:
1563:
1564:
1565:
1566:
1567:
1568:
1569:
1570:
1571:
1572:
1573:
1574:
1575:
1576:
1577:
1578:
1579:
1580:
1581:
1582: May 3, 1983
1583:
1584:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.