| Highwinds Software Product Documentation: Typhoon, Twister, Tornado, Hurricane, and Cyclone | ||
|---|---|---|
| <<< Previous | Chapter 3. Typhoon, Twister, and Tornado Back End Product Documentation | Next >>> |
The following sections provide detailed system configuration information.
Configuration Tutorial Provides step-by-step instructions on setting up a basic system configuration.
Configuration File Specification The "final word" on system configuration.
Advanced Configuration Examples Provides instructions on using program-based authentication, server chaining, and virtual servers.
Highwinds has tried to make the system very easy to configure. These simple step-by-step instructions will jump-start your site configuration.
First, untar the distribution in an area with several gigabytes of disk space free. (The default history takes up 250Mb, and the overview directory can grow to be 5-10% of the spool.) You can consult the Performance and Tuning Guide later for suggestions about better ways to distribute your data among your drives.
To set up the server, you first need to tell the system which hosts are allowed to provide incoming news feeds, and which hosts are allowed to read (and possibly post) news. Using a text editor, create a feeds.conf file in the top of the install area. The file feeds.conf-EXAMPLE contains useful examples of other directives which can be used in the feeds.conf file.
For machines which feed this machine news, create a feed object which allows feeding as follows. (Comment lines begin with a '#' character and blank lines are ignored. Note that #include is not ignored.)
<Feed> # Newsfeed from feeder machine IncomingFeedName main-feed IncomingHostNames news-hub.company.com AllowFeeding True AllowReading False AllowPosting False </Feed> |
Next, tell the server where readers are allowed to connect from. You can use glob-style patterns (*.company.com) or CIDR notation in the IncomingHostNames directive.
<Feed> # Allow everyone in the company to read and post # Don't forget the dynamic-IP laptops! IncomingFeedName readers IncomingHostNames *.company.com, 10.2.3.0/24 AllowReading True AllowPosting True AllowFeeding False </Feed> |
Note: Incoming connections are matched from top to bottom, so the "news-hub.company.com" feed must come before the "*.company.com" feed.
Now, write a <typhoon|twister|tornado_be>.conf to finish configuring the system. Start by copying the <typhoon|twister|tornado_be>.conf-EXAMPLE .
Define spool objects to hold articles. So that disk usage is predictable, Typhoon, Twister, and Tornado Back End store articles in large statically-sized collections of files called spool objects. You can have up to 255 spool objects, specified in <typhoon|twister|tornado_be>.conf. Each "Spool" object must have a SpoolNumber (which must be greater than zero), a Path, and a Kilobytes directives. These directives specify a unique number, a location, and a size for each spool. We recommend placing a large "Spool" object on each disk in your system. For example, the following lines create a one gigabyte spool object that will be stored in the file /news/spool/spool1.
<Spool> SpoolNumber 1 Path /news/spool/spool1 Kilobytes 1000000 </Spool> |
The last step is to define where to send articles posted by the local users. Add a line similar to the following to your <typhoon|twister|tornado_be>.conf:
# Send local posts back to our peering machine UpstreamHostNames news-hub.company.com |
Note: You should check that the machines you list in this directive are granting your machine feed access.
You will need an active file which lists the groups you wish the server to support, each on a line by itself. If you don't have other news systems, you can obtain a prototype active file from ftp://ftp.isc.org/pub/usenet/CONFIG/active.gz or from your upstream news provider. Feel free to edit the file, changing numeric columns (high and low article number) and eliminating groups that you don't want. Save the cleaned-up file as etc/active.control.
Before starting, run tools/activeTool -create -filename etc/active. This will create the active.names, active.table and active.text file that the server uses to store group information.
At startup, the system will update the active files from your etc/active.control file.
That's all! You just set up your incoming news feed, specified which machines are allowed to read news, and created a place to store the articles. All that is left is to run the bin/start command script as root to bootstrap the system.
When you start the system for the very first time, the spools you have specified in the <typhoon|twister|tornado_be>.conf file will be created. Do not be alarmed if this takes a significant amount of time. To view the process, enable the -detailed option.
At startup, the system reads the <typhoon|twister|tornado_be>.conf and the feeds.conf files located in the top of the install area.
In both files, blank lines and lines beginning with a '#' character (except #include lines) are ignored. Entries in configuration files can be continued across multiple lines by ending the lines with the '\' character. Directive names are case-insensitive. The values "True" and "Yes", and the values "False" and "No", are case-insensitive and interchangeable.
Many directives take glob-style expressions as arguments. A glob-style expression is simply a string to be matched, where * matches any sequence of characters, ? matches any single character, [] bound a bracket expression which can be a list of possible character matches, and ! negates an expression. In addition, many directives such as IncomingHostNames take a list of glob-style expressions; the list should be separated by a comma or by space. For example, consider the following examples glob-style expressions for the Subscription directive:
The following characters are valid in each of the expressions:
Table 3-2. Glob Expressions
| Glob | Description |
|---|---|
| ! | At the beginning of a pattern, inverses its meaning. |
| * | Matches any string, including the empty string. |
| [] | Bounds a list of characters that can match a single character |
| ? | Matches any single character. |
| \ | Quotes any of the above characters. |
Any directive which accepts a group of hostnames can additionally accept a CIDR (Classless Inter-Domain Routing) address block. Two forms of the standard CIDR notation are accepted:
Example 3-6. CIDR Address / Netmask Notation
10.2.3.0/255.255.255.0 |
Note on Chaining. If you are looking to share spools with multiple servers, Tornado will work significantly better than chaining. Chaining has a number of inefficiencies and should only be used in disaster recovery scenarios.
In server chaining, one news server (the "slave") advertises and serves the articles stored on another news server (the "master"), in addition to its own articles. The user connects only to the slave server and only the slave server itself knows which articles are stored locally and which must be requested from the master. There are many situations where server chaining makes sense:
When you want to keep a large amount of old news, but cannot afford the storage space to do so for every news server you maintain
When you want to install a new news server, and have it appear full as soon as it is turned on
When you want to place an unattended news server in POP to conserve backbone bandwidth, and want to provide good news service with a small, simple server
When you want to put a high-bandwidth hierarchy on its own news server, to reduce the load on your main news server
When you want to make newsgroups which normally are only available on some other server available on yours as well, without setting up a "suck" feed
Chaining is easy to set up. There are only a few requirements:
For any newsgroups which are carried on both the master and slave servers, article numbers in those groups must be synchronized. If you are using Highwinds Software products, this is very easy. Simply refer to the XrefAction directive for details.
There should be good network connectivity between the master and the slave.
For groups that exist on both the master and the slave, the feed to the slave must contain the "whole" group. That is, it can not receive a "patchwork" of the article numbers.
On the master server, set up an incoming feed object for the slave server which allows at least 100 persistent connections, and at least 100 simultaneous connections from the slave server:
# Slave server connection <Feed> IncomingFeedName slave-reader IncomingHostNames reader-box1.company.com # No timeout! TimeOut 0 Many connections allowed from the slave. HostConnectionLimit 100 MaxIncomingNumberOfStreams 100 </Feed> |
Make sure the slave's news feed consist of numbered articles (Using the Highwinds Software products makes this easy!)
Make sure the slave server's <typhoon|twister|tornado_be>.conf has XRefAction Parse.
Create a chaining object in the slave server's <typhoon|twister|tornado_be>.conf. Here is an example Chain object; documentation of the chaining directives follows.
<Chain> Hostnames master1.company.com </Chain> |
The virtual server feature in Typhoon, Twister, and Tornado Back End allows a single news server to appear as different news systems with different newsgroups. In order to create virtual servers, the Subscription, FilterSubscription, GroupAllowFile, and GroupDenyFile directives are used. Other directives such as WelcomeMessage and connection and interface limiting directives are used to describe and enable properties of each virtual server. It can also be enabled on a per-user or per-connection basis with the use of either file or program-based authentication.
After a client connection has connected (and, optionally, has been authenticated with either file-based or program-based authentication), it will be assigned a particular subscription and filter subscription. Also, it might optionally be assigned a group allow file and group deny file as well. The combination of these four parameters define which newsgroups the client is able to read articles from, and where posts may be made. Similar to their effect on spool objects, overview cache objects, and outgoing feeds, these directives allow precise control of which newsgroups are accessible by the connection.
In order for a message to be read or posted, the subscription and group allow file (if it exists) must match at least one newsgroup that the message has been posted to. Furthermore, the filter subscription and group deny file (if it exists) must not match any newsgroups that the message has been posted to. This allows the subscription and filter subscription to specify generalized access lists using glob-style patterns, and also allows the group allow files and group deny files to specify individual newsgroups.
All of the following examples will be described using a feed object context. However, all could be applied to the case where a user has special privileges as granted by an authentication file or an authentication program.
# Virtual server which has access to everything. <Feed> IncomingHostNames 10.0.0.0/24 Subscription * FilterSubscription !* </Feed> # Virtual server which has access to everything except clari.* <Feed> IncomingHostNames 10.0.27.0/24 Subscription * FilterSubscription clari.* </Feed> # Virtual server which has access to everything except things posted # exclusively to alt.binaries.* or alt.sex.* <Feed> IncomingHostNames 10.0.51.0/24 Subscription *, !alt.binaries.*, !alt.sex.* FilterSubscription !* </Feed> # Virtual server for customer with only their internal newsgroups. <Feed> IncomingHostNames *.company.com Subscription company.internal.* FilterSubscription !* </Feed> # Virtual server without child pornography newsgroups. <Feed> IncomingHostnames *.school.edu Subscription * FilterSubscription *pedophil* GroupDenyFile ../etc/child-groups </Feed> |
../etc/child-groups contains:
alt.binaries.erotic.children alt.binaries.pictures.child.erotica.female alt.binaries.pictures.child.erotica.male alt.binaries.pictures.child.starlets alt.binaries.pictures.children alt.binaries.pictures.erotic.children alt.binaries.pictures.erotica.child alt.binaries.pictures.erotica.child.female alt.binaries.pictures.erotica.child.male alt.binaries.pictures.erotica.children alt.sex.children |
| <<< Previous | Home | Next >>> |
| Installation Guide | Up | Operations Guide |