unx42.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<FONT SIZE=3><B>Where Will You Get Your News?</B>

<BR></FONT></A></CENTER></H4>

<P>Some organizations use USENET for internal communications&#151;for instance, a corporate BBS&#151;and don't need or want to connect to USENET. However, if you want a USENET connection, you'll have to find one or more hosts willing to exchange news with 

you. Note that they are doing you a big favor&#151;a full news feed consumes a lot of CPU cycles, network bandwidth, and staff time. However, the spirit of USENET is altruistic, and you may find a host willing to supply you with a news feed for free. In 
turn, you may someday be asked to supply a feed to someone else.

<BR></P>

<P>Finding a host willing to give you a news feed is easier if you're already on USENET, but if you were, you wouldn't need one. Your Internet service provider may be able to give you contact information, and as mentioned above, many service providers 
supply newsfeeds either as part of their basic service or at additional cost. Personal contacts with other system administrators who are already connected to USENET may help, even if they can't supply you a feed themselves. The &quot;how to join 
USENET&quot; FAQ mentioned previously contains other good ideas for finding a news feed.

<BR></P>

<P>It's a good idea to try to find a news feed that is topographically close on your network. If your site is in Indiana you don't want a transatlantic feed from Finland, even if you manage to find a host there willing to do it.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I27" NAME="I27">

<FONT SIZE=3><B>Site Policies</B>

<BR></FONT></A></CENTER></H4>

<P>Your users' USENET articles reflect on your site, and new users often make mistakes. Unfortunately, the kinds of mistakes you can make on a world-wide network are the really bad ones. You should develop organizational USENET access policies and educate 

your users on proper USENET etiquette.

<BR></P>

<P>Policy questions tend toward the ethical and legal. For instance, if you carry the alt hierarchy, what will be your site's response when someone creates the newsgroup alt.child-molesting.advocacy? This is not beyond the pale of what you may expect in 
the alt hierarchy, and even within the traditional hierarchies where newsgroups are voted into existence you may find newsgroups your site may not wish to carry. What will you do when you receive a letter from [e-mail], whining that one of your 

users is polluting his favorite newsgroup with &quot;inappropriate&quot; (in his opinion) postings. Do you want to get involved in USENET squabbles like that?

<BR></P>

<P>What will you do when you get 2,843 letters complaining that one of your users posted a pyramid-scheme come-on to 300 different newsgroups? Shoot him? Or maybe wish you'd done a more careful job of setting policy in the first place?

<BR></P>

<P>And what will you do when someone complains that the postings in alt.binaries.pictures.erotica.blondes are a form of sexual harassment and demands that the newsgroup be removed? Will you put yourself in the position of censor and drop that newsgroup, or 

drop the entire alt hierarchy to avoid having to judge the worth of a single newsgroup?

<BR></P>

<P>If you put yourself in the position of picking and choosing newsgroups, you will find that while it may be completely obvious to you that comp.risks has merit and alt.spam doesn't, your users may disagree, vehemently. If you propose to locally delete 
alt.spam to conserve computing resources, some users will refer to their right to free speech and accuse you of censorship and fascism. (Are you sure you wanted this job?)

<BR></P>

<P>Most news administrators don't want to be censors or arbiters of taste. Therefore, answers to policy questions should be worked out in advance, codified as site policy, and signed off on by management. You need to hammer away at your boss until you get 

a written policy telling you what you should and should not do with respect to news administration, and you need to do this before you join USENET. As implied above, such a policy should provide for user education and set bounds for proper user behavior.

<BR></P>

<P>Without taking a position on the merits of alt.spam, USENET access is not one of the fundamental rights enumerated in the United States Constitution. It's more like a driver's license&#151;if you're willing to follow your site's rules, you can drive, 
and if you're not, you can't. It's management's job to provide those rules, with guidance from you.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I28" NAME="I28">

<FONT SIZE=3><B>Expiration Policies</B>

<BR></FONT></A></CENTER></H4>

<P>News system software is flexible enough to selectively purge old articles. In other words, if your site doesn't care much about the alt hierarchy but considers the comp hierarchy to be important, it can retain comp articles longer than alt articles. 
From the proceeding discussion, you can see that this might be contentious. If Joe thinks that alt.spam is the greatest thing since indoor plumbing, he will cry foul if you expire spam articles in one day but retain comp articles for seven. You can see 
that article expiration is not just a technical issue but a policy issue and should be covered in the same written policies mentioned previously.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I29" NAME="I29">

<FONT SIZE=3><B>Automatic Response to newgroup/rmgroup Control Messages</B>

<BR></FONT></A></CENTER></H4>

<P>Newsgroups are created and removed by special news articles called control messages. Anyone bright enough to understand RFCs 1036 and 977 can easily forge control messages to create and remove newsgroups. (That is, just about anyone.) This is a 
particular problem in the alt hierarchy, which for some reason attracts people with too much time on their hands, who enjoy creating newsgroups such as alt.swedish-chef.bork.bork.bork. The alt hierarchy also is used by people who don't want to go to the 
trouble of creating a new newsgroup through a USENET-wide vote, or who (usually correctly) guess that their hare-brained proposal wouldn't pass even the fairly easy USENET newsgroup creation process.

<BR></P>

<P>Another problem, somewhat less frequent, occurs when a novice news administrator posts newgroup messages with incorrect distributions and floods the net with requests to create his local groups.

<BR></P>

<P>You can configure your news system software to create and delete groups automatically upon receiving control messages, or to send e-mail to the news administrator saying that the group should be created or removed. If you like living dangerously, you 
can enable automatic creation and deletion, but most people don't. You don't want someone to delete all your newsgroups just to see if he can, and you don't want two or three hundred created because a news system administrator made a distribution mistake. 

Many sites allow automatic creation but do deletions manually. More cautious sites create and delete all groups by hand, and only if they have reason to believe the control message is valid. I recommend the latter approach. The only disadvantage is that 
you may miss the first few articles posted to a new newsgroup if you don't stay on top of things.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I30" NAME="I30">

<FONT SIZE=4><B>The ABCs of News-Transport Software</B>

<BR></FONT></A></CENTER></H3>

<P>USENET began with A-news, a prototype news-transport system that was killed by its own success and was supplanted by B-news. B-news sufficed for quite a while but became another victim of USENET growth and was supplanted by C-news, a much more efficient 

system written by Henry Spencer and Geoff Collyer of the University of Toronto. C-news was followed by INN (InterNetworkNews), written by Rich Salz of the Open Software Foundation, who apparently hadn't heard of the letter &quot;D.&quot;

<BR></P>

<P>Depending on your site's requirements, either C-news or INN make good news-transport systems, but this chapter has space for only one, INN. You may also want to consider C-news, which is fairly easy to install and will work well for most sites, but if 
you do you're on your own. Note too that if you install C-news and your site plans to use NNTP, you'll also have to obtain and install the NNTP &quot;reference implementation,&quot; available by anonymous ftp from the host ftp.uu.net in the directory 
~ftp/networking/news/nntp. This isn't necessary for INN, which has a slightly modified version of NNTP built in.

<BR></P>

<P>INN is the news-transport system of choice for Internet sites that use NNTP to exchange news and provide newsreaders and news-posting services. It was designed specifically for efficiency in an Internet/NNTP environment, for hosts with many news feeds 
and lots of NNTP client newsreaders. Although its installation isn't as automated as C-news, it's not all that difficult, and it's well-documented. The following sections give an overview of how to build and install INN.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I31" NAME="I31">

<FONT SIZE=3><B>Getting Your Hands on the Sources</B>

<BR></FONT></A></CENTER></H4>

<P>The latest version of INN available as this book goes to press is included on the UNIX Unleashed CD-ROM. This version is called INN 1.4sec. It was released on December 22, 1993, so it's had some time to mature. The sec stands for security&#151;the 
1.4sec release corrects a security problem in INN 1.4. If you like to live on the bleeding edge (as opposed to the cutting edge), you can look for a later release of INN on the host ftp.uu.net in the directory ~ftp/networking/news/nntp/inn. See Chapter 41, 

&quot;Mail Administration,&quot; for more detailed instructions on obtaining software through ftp.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I32" NAME="I32">

<FONT SIZE=4><B>An INN Distribution Roadmap</B>

<BR></FONT></A></CENTER></H3>

<P>Most of the important directories and programs in the INN distribution are summarized in the list below. Some are covered in more detail in the sections &quot;Configuring INN&#151;The config.data File,&quot; &quot;Building INN,&quot; and &quot;Site 
Configuration.&quot;

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>

<BR>BUILD

<BR></P>

<TD>

<P>

<BR>A shell script for building and installing INN.

<BR></P>

<TR>

<TD>

<P>

<BR>Install.ms.*

<BR></P>

<TD>

<P>

<BR>The nroff sources to INN's installation documentation.

<BR></P>

<TR>

<TD>

<P>

<BR>README

<BR></P>

<TD>

<P>

<BR>What you might think. Read it.

<BR></P>

<TR>

<TD>

<P>

<BR>backends

<BR></P>

<TD>

<P>

<BR>Programs for transferring news to your USENET neighbors.

<BR></P>

<TR>

<TD>

<P>

<BR>config

<BR></P>

<TD>

<P>

<BR>Contains the file config.dist, with which you create config.data. Config.data controls the compilation of the rest of INN.

<BR></P>

<TR>

<TD>

<P>

<BR>dbz

<BR></P>

<TD>

<P>

<BR>Sources for the database routines used by INN. dbz is a faster version of the dbm database programs included with many versions of UNIX.

<BR></P>

<TR>

<TD>

<P>

<BR>doc

<BR></P>

<TD>

<P>

<BR>INN's manual pages.

<BR></P>

<TR>

<TD>

<P>

<BR>expire

<BR></P>

<TD>

<P>

<BR>Contains programs that handle news expiration, or the purging of articles from your news spool. They also selectively purge old Message-IDs from the history file so it doesn't grow boundlessly.

<BR></P>

<TR>

<TD>

<P>

<BR>frontends

<BR></P>

<TD>

<P>

<BR>Contains programs that control innd's operation or offer it news articles

<BR></P>

<TR>

<TD>

<P>

<BR>include

<BR></P>

<TD>

<P>

<BR>C language header files for the INN programs.

<BR></P>

<TR>

<TD>

<P>

<BR>innd

<BR></P>