1INNFEED.CONF(5) InterNetNews Documentation INNFEED.CONF(5)
2
6 innfeed.conf - Configuration file for innfeed
7
9 The innfeed.conf file configures to which remote peers innfeed sends
10 NNTP feeds.
11 A common entry to parameterize "news.server.com" as an outgoing feed
13 is:
14 peer news.server.com {
16 ip-name: "news.server.com"
17 }
18 If standard NNTP port 119 is not used, you may specify an alternate
20 port as follows:
21 peer news.server.com {
23 ip-name: "news.server.com"
24 port-number: 433
25 }
26 After any changes, run "inncheck" to perform basic syntax checks, and
28 reload this configuration file with the following command which makes
29 innd respawn a new instance of innfeed (assuming "innfeed!" is the name
30 of the corresponding channel feed in newsfeeds):
31 ctlinnd flush innfeed!
33
35 The configuration file innfeed.conf in pathetc is used to control the
36 innfeed(8) program. It is a fairly free-format file that consists of
37 three types of entries: key:value, peer and group. Comments are from
38 the hash character "#" to the end of the line.
39 key:value entries are a keyword and a value separated by a colon (which
41 can itself be surrounded by whitespace). For example:
42 max-connections: 10
44 A legal key starts with a letter and contains only letters, digits, and
46 the "_" and "-" characters. There are 5 different types of values:
47 integers, floating-point numbers, characters, booleans, and strings.
48 Integer and floating-point numbers are as to be expected, except that
50 exponents in floating-point numbers are not supported. A boolean value
51 is either "true" or "false" (case is not significant). A character
52 value is a single-quoted character as defined by the C-language. A
53 string value is any other sequence of characters. If the string needs
54 to contain whitespace, then it must be quoted with double quotes, and
55 uses the same format for embedding non-printing characters as normal
56 C-language string.
57 Peer entries look like:
59 peer <name> {
61 # body ...
62 }
63 The word "peer" is required. The <name> is the same as the site name
65 in INN's newsfeeds configuration file. The body of a peer entry
66 contains some number (possibly zero) of key:value entries.
67 Group entries look like:
69 group <name> {
71 # body ...
72 }
73 The word "group" is required. The <name> is any string valid as a key.
75 The body of a group entry contains any number of the three types of
76 entries. So key:value pairs can be defined inside a group, and peers
77 can be nested inside a group, and other groups can be nested inside a
78 group.
79 key:value entries that are defined outside of all peer and group
81 entries are said to be at "global scope". There are global key:value
82 entries that apply to the process as a whole (for example the location
83 of the backlog file directory), and there are global key:value entries
84 that act as defaults for peers. When innfeed looks for a specific
85 value in a peer entry (for example, the maximum number of connections
86 to set up), if the value is not defined in the peer entry, then the
87 enclosing groups are examined for the entry (starting at the closest
88 enclosing group). If there are no enclosing groups, or the enclosing
89 groups do not define the key:value, then the value at global scope is
90 used.
91 A small example could be:
93 # Global value applied to all peers that have
95 # no value of their own.
96 max-connections: 5
97 # A peer definition. "uunet" is the name used by innd
99 # in the newsfeeds configuration file.
100 peer uunet {
101 ip-name: usenet1.uu.net
102 }
103 peer vixie {
105 ip-name: gw.home.vix.com
106 max-connections: 10 # Override global value.
107 }
108 # A group of two peers which can handle more connections
110 # than normal.
111 group fast-sites {
112 max-connections: 15
113 # Another peer. The "max-connections" value from the
115 # "fast-sites" group scope is used. The "ip-name" value
116 # defaults to the peer's name.
117 peer data.ramona.vix.com {
118 }
119 peer bb.home.vix.com {
121 max-connections: 20 # He can really cook.
122 }
123 }
124 Given the above configuration file, the defined peers would have the
126 following values for the max-connections key:
127 uunet 5
129 vixie 10
130 data.ramona.vix.com 15
131 bb.home.vix.com 20
132 innfeed ignores key:value pairs it is not interested in. Some
134 configuration file values can be set via a command-line option, in
135 which case that setting overrides the settings in the file.
136 Configuration files can be included in other configuration files via
138 the syntax:
139 $INCLUDE filename
141 There is a maximum nesting depth of 10.
143 For a fuller example configuration file, see the supplied innfeed.conf.
145
147 The following listing show all the keys that apply to the process as
148 whole. These are not required (compiled-in defaults are used where
149 needed).
150 news-spool
152 This key requires a pathname value and defaults to patharticles in
153 inn.conf. It specifies where the top of the article spool is.
154 This corresponds to the -a command-line option.
155 input-file
157 This key requires a pathname value. It specifies the pathname
158 (relative to the backlog-directory value) that should be read in
159 funnel-file mode. This corresponds to giving a filename as an
160 argument on the command-line (i.e. its presence also implies that
161 funnel-file mode should be used).
162 The default is unset; innfeed then runs in channel or batch mode.
164 pid-file
166 This key requires a pathname value and defaults to innfeed.pid. It
167 specifies the pathname (relative to pathrun in inn.conf) where the
168 pid of the innfeed process should be stored. This corresponds to
169 the -p command-line option.
170 debug-level
172 This key defines the debug level for the process. Default is 0. A
173 non-zero number generates a lot of messages to stderr, or to the
174 config-defined log-file. This corresponds to the -d command-line
175 option.
176 If a file named innfeed.debug exists in the pathlog directory (as
178 set in inn.conf), then debug-level is automatically set to 1. This
179 is a cheap way of avoiding continual reloading of the newsfeeds
180 file when debugging. Note that debug messages still go to log-
181 file.
182 debug-shrinking
184 This key requires a boolean value and defaults to false (the debug
185 file is allowed to grow without bound). If set to true, this file
186 is truncated when its size reaches a certain limit. See backlog-
187 limit for more details.
188 initial-sleep
190 This key requires a positive integer. The default value is 2. It
191 defines the number of seconds to wait when innfeed (or a fork)
192 starts, before beginning to open connections to remote hosts.
193 fast-exit
195 This key requires a boolean value and defaults to false. If set to
196 true, when innfeed receives a SIGTERM or SIGQUIT signal, it will
197 close its listeners as soon as it can, even if it means dropping
198 articles.
199 use-mmap
201 This key requires a boolean value and defaults to true. When
202 innfeed is given file names to send (a fairly rare use case)
203 instead of storage API tokens, it specifies whether mmaping should
204 be used if innfeed has been built with mmap(2) support. If article
205 data on disk is not in NNTP-ready format (CR/LF at the end of each
206 line), then after mmaping, the article is read into memory and
207 fixed up, so mmaping has no positive effect (and possibly some
208 negative effect depending on your system), and so in such a case
209 this value should be "false", which corresponds to the -M command-
210 line option.
211 log-file
213 This key requires a pathname value and defaults to innfeed.log. It
214 specifies where any logging messages that could not be sent via
215 syslog(3) should go (such as those generated when a positive value
216 for debug-value is used). This corresponds to the -l command-line
217 option.
218 This pathname is relative to pathlog in inn.conf.
220 log-time-format
222 This key requires a format string suitable for strftime(3). It is
223 used for messages sent via syslog(3) and to the status-file.
224 Default value is "%a %b %d %H:%M:%S %Y".
225 backlog-directory
227 This key requires a pathname value and defaults to innfeed. It
228 specifies where the current innfeed process should store backlog
229 files. This corresponds to the -b command-line option.
230 This pathname is relative to pathspool in inn.conf.
232 backlog-highwater
234 This key requires a positive integer value and defaults to 5. It
235 specifies how many articles should be kept on the backlog file
236 queue before starting to write new entries to disk.
237 backlog-ckpt-period
239 This key requires a positive integer value and defaults to 30. It
240 specifies how many seconds elapse between checkpoints of the input
241 backlog file. Too small a number will mean frequent disk accesses;
242 too large a number will mean after a crash, innfeed will re-offer
243 more already-processed articles than necessary.
244 backlog-newfile-period
246 This key requires a positive integer value and defaults to 600. It
247 specifies how many seconds elapse before each check for externally
248 generated backlog files that are to be picked up and processed.
249 backlog-rotate-period
251 This key requires a positive integer value and defaults to 60. It
252 specifies how many seconds elapse before innfeed checks for a
253 manually created backlog file and moves the output backlog file to
254 the input backlog file.
255 dns-retry
257 This key requires a positive integer value and defaults to 900. It
258 defines the number of seconds between attempts to re-lookup host
259 information that previously failed to be resolved.
260 dns-expire
262 This key requires a positive integer value and defaults to 86400.
263 It defines the number of seconds between refreshes of name to
264 address DNS translation. This is so long-running processes do not
265 get stuck with stale data, should peer IP addresses change.
266 gen-html
268 This key requires a boolean value and defaults to false. It
269 specifies whether the status-file should be HTML-ified.
270 status-file
272 This key requires a pathname value and defaults to innfeed.status.
273 An absolute pathname can be used. It specifies the pathname
274 (relative to pathhttp when gen-html is true; otherwise, pathlog as
275 set in inn.conf) where the periodic status of the innfeed process
276 should be stored. This corresponds to the -S command-line option.
277 connection-stats
279 This key requires a boolean value and defaults to false. If the
280 value is true, then whenever the transmission statistics for a peer
281 are logged, each active connection logs its own statistics. This
282 corresponds to the -z command-line option.
283 host-queue-highwater
285 This key requires a positive integer value and defaults to 10. It
286 defines how many articles will be held internally for a peer before
287 new arrivals cause article information to be spooled to the backlog
288 file.
289 stats-period
291 This key requires a positive integer value and defaults to 600. It
292 defines how many seconds innfeed waits between generating
293 statistics on transfer rates.
294 stats-reset
296 This key requires a positive integer value and defaults to 43200.
297 It defines how many seconds innfeed waits before resetting all
298 internal transfer counters back to zero (after logging one final
299 time). This is so a innfeed process running more than a day will
300 generate "final" stats that will be picked up by logfile processing
301 scripts.
302 initial-reconnect-time
304 This key requires a positive integer value and defaults to 30. It
305 defines how many seconds to first wait before retrying to reconnect
306 after a connection failure. If the next attempt fails too, then
307 the reconnect time is approximately doubled until the connection
308 succeeds, or max-reconnect-time is reached.
309 max-reconnect-time
311 This key requires an integer value and defaults to 3600. It
312 defines the maximum number of seconds to wait between attempt to
313 reconnect to a peer. The initial value for reconnection attempts
314 is defined by initial-reconnect-time, and it is doubled after each
315 failure, up to this value.
316 stdio-fdmax
318 This key requires a non-negative integer value and defaults to 0.
319 If the value is greater than zero, then whenever a network socket
320 file descriptor is created and it has a value less than this, the
321 file descriptor will be dup'ed to bring the value up greater than
322 this. This is to leave lower numbered file descriptors free for
323 stdio. Certain systems, Sun's in particular, require this. SunOS
324 4.1.x usually requires a value of 128 and Solaris requires a value
325 of 256. The default if this is not specified, is 0.
326 Special keys for imapfeed
328 The following keys are used with imapfeed to authenticate to a remote
329 host. Several parameters may be included at global scope:
330 deliver-authname
332 The authname is who you want to authenticate as.
333 deliver-password
335 This is the appropriate password for authname.
336 deliver-username
338 The username is who you want to "act" as, that is, who is actually
339 going to be using the server.
340 deliver-realm
342 In this case, the "realm" is the realm in which the specified
343 authname is valid. Currently this is only needed by the DIGEST-MD5
344 SASL mechanism.
345 deliver-rcpt-to
347 A printf(3)-style format string for creating the envelope recipient
348 address. The pattern MUST include a single string specifier which
349 will be replaced with the newgroup (e.g. "bb+%s"). The default is
350 "+%s".
351 deliver-to-header
353 An optional printf(3)-style format string for creating a To header
354 field to be prepended to the article. The pattern MUST include a
355 single string specifier which will be replaced with the newgroup
356 (e.g. "post+%s@domain"). If not specified, the To header field
357 will not be prepended.
358
360 All the key:value pairs mentioned in this section can be specified at
361 global scope. They may also be specified inside a group or peer
362 definition. Note that when peers are added dynamically (i.e. when
363 innfeed receives an article for an unspecified peer), it will add the
364 peer site using the parameters specified at global scope.
365 Required keys
367 No keys are currently required. They all have a default value, if not
368 present in the configuration file.
369 Optional keys
371 The following keys are optional:
372 article-timeout
374 This key requires a non-negative integer value. The default value
375 is 600. If no articles need to be sent to the peer for this many
376 seconds, then the peer is considered idle and all its active
377 connections are torn down.
378 response-timeout
380 This key requires a non-negative integer value. The default value
381 is 300. It defines the maximum amount of time to wait for a
382 response from the peer after issuing a command.
383 initial-connections
385 This key requires a non-negative integer value. The default value
386 is 1. It defines the number of connections to be opened
387 immediately when setting up a peer binding. A value of 0 means no
388 connections will be created until an article needs to be sent.
389 max-connections
391 This key requires a positive integer value. The default value is 2
392 but may be increased if needed or for large feeds. It defines the
393 maximum number of connections to run in parallel to the peer. A
394 value of 0 specifies an unlimited number of maximum connections.
395 In general, use of an unlimited number of maximum connections is
396 not recommended. Do not ever set max-connections to zero with
397 dynamic-method 0 set, as this will saturate peer hosts with
398 connections.
399 close-period
401 This key requires a positive integer value and defaults to 86400.
402 It is the maximum number of seconds a connection should be kept
403 open. Some NNTP servers do not deal well with connections being
404 held open for long periods.
405 dynamic-method
407 This key requires an integer value between 0 and 3. The default
408 value is 3. It controls how connections are opened, up to the
409 maximum specified by max-connections. In general (and
410 specifically, with dynamic-method 0), a new connection is opened
411 when the current number of connections is below max-connections,
412 and an article is to be sent while no current connections are idle.
413 Without further restraint (i.e. using dynamic-method 0), in
414 practice this means that max-connections connections are
415 established while articles are being sent. Use of other dynamic-
416 method settings imposes a further limit on the amount of
417 connections opened below that specified by max-connections. This
418 limit is calculated in different ways, depending of the value of
419 dynamic-method.
420 Users should note that adding additional connections is not always
422 productive -- just because opening twice as many connections
423 results in a small percentage increase of articles accepted by the
424 remote peer, this may be at considerable resource cost both locally
425 and at the remote site, whereas the remote site might well have
426 received the extra articles sent from another peer a fraction of a
427 second later. Opening large numbers of connections is considered
428 antisocial.
429 The meanings of the various settings are:
431 0 (no method)
433 Increase of connections up to max-connections is unrestrained.
434 1 (maximize articles per second)
436 Connections are increased (up to max-connections) and decreased
437 so as to maximize the number of articles per second sent, while
438 using the fewest connections to do this.
439 2 (set target queue length)
441 Connections are increased (up to max-connections) and decreased
442 so as to keep the queue of articles to be sent within the bounds
443 set by dynamic-backlog-low and dynamic-backlog-high, while using
444 the minimum resources possible. As the queue will tend to fill
445 if the site is not keeping up, this method ensures that the
446 maximum number of articles are offered to the peer while using
447 the minimum number of connections to achieve this.
448 3 (combination)
450 This method uses a combination of methods 1 and 2 above. For
451 sites accepting a large percentage of articles, method 2 will be
452 used to ensure these sites are offered as complete a feed as
453 possible. For sites accepting a small percentage of articles,
454 method 1 is used, to minimize remote resource usage. For
455 intermediate sites, an appropriate combination is used.
456 dynamic-backlog-low
458 This key requires a floating-point value between 0 and 100. It
459 represents (as a percentage) the low water mark for the host queue.
460 If the host queue falls below this level while using dynamic-method
461 2 or 3, and if 2 or more connections are open, innfeed will attempt
462 to drop connections to the host. An Infinite Impulse Response
463 (IIR) filter is applied to the value to prevent connection flap
464 (see dynamic-filter). The default value is 20.0. This value must
465 be smaller than dynamic-backlog-high.
466 dynamic-backlog-high
468 This key requires a floating-point value between 0 and 100. It
469 represents (as a percentage) the high water mark for the host
470 queue. If the host queue rises above this level while using
471 dynamic-method 2 or 3, and if less than max-connections are open to
472 the host, innfeed will attempt to open further connections to the
473 host. An Infinite Impulse Response (IIR) filter is applied to the
474 value to prevent connection flap (see dynamic-filter). The default
475 value is 50.0. This value must be larger than dynamic-backlog-low.
476 dynamic-backlog-filter
478 This key requires a floating-point value between 0 and 1. It
479 represents the filter coefficient used by the Infinite Impulse
480 Response (IIR) filter used to implement dynamic-method 2 and 3.
481 The default value of this filter is 0.7, giving a time constant of
482 1/(1-0.7) articles. Higher values will result in slower response
483 to queue fullness changes; lower values in faster response.
484 max-queue-size
486 This key requires a positive integer value. The default value is
487 20. It defines the maximum number of articles to process at one
488 time when using streaming to transmit to a peer. Larger numbers
489 mean more memory consumed as articles usually get pulled into
490 memory (see the description of use-mmap).
491 streaming
493 This key requires a boolean value. Its default value is true. It
494 defines whether streaming commands are used to transmit articles to
495 the peers.
496 no-check-high
498 This key requires a floating-point number which must be in the
499 range [0.0, 100.0]. When running transmitting with the streaming
500 commands, innfeed attempts an optimization called "no-CHECK mode".
501 This involves not asking the peer if it wants the article, but just
502 sending it. This optimization occurs when the percentage of the
503 articles the peer has accepted gets larger than this number. If
504 this value is set to 100.0, then this effectively turns off no-
505 CHECK mode, as the percentage can never get above 100.0. If this
506 value is too small, then the number of articles the peer rejects
507 will get bigger (and your bandwidth will be wasted). The default
508 value of 95.0 usually works pretty well.
509 no-check-low
511 This key requires a floating-point number which must be in the
512 range [0.0, 100.0], and it must be smaller that the value for no-
513 check-high. When running in no-CHECK mode, as described above, if
514 the percentage of articles the remote server accepts drops below
515 this number, then the no-CHECK optimization is turned off until the
516 percentage gets above the no-check-high value again. If there is
517 small difference between this and the no-check-high value (less
518 than about 5.0), then innfeed may frequently go in and out of no-
519 CHECK mode. If the difference is too big, then it will make it
520 harder to get out of no-CHECK mode when necessary (wasting
521 bandwidth). Keeping this to between 5.0 and 10.0 less than no-
522 check-high usually works pretty well. The default value is 90.0.
523 no-check-filter
525 This is a floating-point value representing the time constant, in
526 articles, over which the CHECK/no-CHECK calculations are done. The
527 default value is 50.0, which will implement an Infinite Impulse
528 Response (IIR) filter of time constant 50. This roughly equates to
529 making a decision about the mode over the previous 50 articles. A
530 higher number will result in a slower response to changing
531 percentages of articles accepted; a lower number will result in a
532 faster response.
533 port-number
535 This key requires a positive integer value. It defines the TCP/IP
536 port number to use when connecting to the remote. Usually, port
537 number 119 is used, which is the default value.
538 force-ipv4
540 This key requires a boolean value. By default, it is set to false.
541 Setting it to true is the same as setting bindaddress6 to "none"
542 and removing bindaddress from "none" if it was set.
543 drop-deferred
545 This key requires a boolean value. By default, it is set to false.
546 When set to true, and a peer replies with code 431 or 436 (try
547 again later), innfeed just drops the article and does not try to
548 re-send it. This is useful for some peers that keep on deferring
549 articles for a long time to prevent innfeed from trying to offer
550 the same article over and over again.
551 min-queue-connection
553 This key requires a boolean value. By default, it is set to false.
554 When set to true, innfeed will attempt to use a connection with the
555 least queue size (or the first empty connection). If this key is
556 set to true, it is recommended that dynamic-method be set to 0.
557 This allows for article propagation with the least delay.
558 no-backlog
560 This key requires a boolean value. It specifies whether spooling
561 should be enabled (false, the default) or disabled (true). Note
562 that when no-backlog is set, articles reported as spooled are
563 actually silently discarded.
564 backlog-limit
566 This key requires a non-negative integer value. If the number is 0
567 (the default), then backlog files are allowed to grow without bound
568 when the peer is unable to keep up with the article flow. If this
569 number is greater than 0, then it specifies the size (in bytes) the
570 backlog file should get truncated to when the backlog file reaches
571 a certain limit. The limit depends on whether backlog-factor or
572 backlog-limit-highwater is used.
573 This parameter also applies to the debug file when debug-shrinking
575 is set to true, and has the same effect on this file as the one has
576 on backlog files.
577 backlog-factor
579 This key requires a floating-point value, which must be larger than
580 1.0. It is used in conjunction with the peer key backlog-limit.
581 If backlog-limit has a value greater than zero, then when the
582 backlog file gets larger than the value backlog-limit * backlog-
583 factor, then the backlog file will be truncated to the size
584 backlog-limit.
585 For example, if backlog-limit has a value of 1000000, and backlog-
587 factor has a value of 2.0, then when the backlog file gets to be
588 larger than 2000000 bytes in size, it will be truncated to 1000000
589 bytes. The front portion of the file is removed, and the trimming
590 happens on line boundaries, so the final size may be a bit less
591 than this number. If backlog-limit-highwater is defined too, then
592 backlog-factor takes precedence. The default value of backlog-
593 factor is 1.1.
594 This parameter also applies to the debug file when debug-shrinking
596 is set to true, and has the same effect on this file as the one has
597 on backlog files.
598 backlog-limit-highwater
600 This key requires a positive integer value that must be larger than
601 the value for backlog-limit. The default value is 0.
602 If the size of the backlog file gets larger than this value (in
604 bytes), then the backlog file will be shrunk down to the size of
605 backlog-limit. If both backlog-factor and backlog-limit-highwater
606 are defined, then the value of backlog-factor is used.
607 This parameter also applies to the debug file when debug-shrinking
609 is set to true, and has the same effect on this file as the one has
610 on backlog files.
611 backlog-feed-first
613 This key requires a boolean value. By default it is set to false.
614 When set to true, the backlog is fed before new files. This is
615 intended to enforce in-order delivery, so setting this to true when
616 initial-connections or max-connections is more than 1 is
617 inconsistent.
618 bindaddress
620 This key requires a string value. It specifies which outgoing IPv4
621 address innfeed should bind the local end of its connection to. It
622 must be an IPv4 address in dotted-quad format (nnn.nnn.nnn.nnn),
623 "any", or "none". If not set or set to "any", innfeed defaults to
624 letting the kernel choose this address. If set to "none", innfeed
625 will not use IPv4 for outgoing connections to peers in this scope
626 (i.e. it forces IPv6).
627 If not set in innfeed.conf, innfeed defaults to the value of
629 sourceaddress from inn.conf (which by default is unset).
630 bindaddress6
632 This key requires a string value. It behaves like bindaddress
633 except for outgoing IPv6 connections. It must be in numeric IPv6
634 format (note that a value containing colons must be enclosed in
635 double quotes), "any", or "none". If set to "none", innfeed will
636 not use IPv6 for outgoing connections to peers in this scope.
637 If not set in innfeed.conf, innfeed defaults to the value of
639 sourceaddress6 from inn.conf (which by default is unset).
640 username
642 This key requires a string value. If the value is defined, then
643 innfeed tries to authenticate by AUTHINFO USER and this value used
644 for user name. password must also be defined, if this key is
645 defined.
646 password
648 This key requires a string value. The value is the password used
649 for AUTHINFO PASS. username must also be defined, if this key is
650 defined.
651
653 As previously explained, the peer definitions can contain redefinitions
654 of any of the key:value pairs described in the section about global
655 peer defaults above. There is one key:value pair that is specific to a
656 peer definition.
657 ip-name
659 This key requires a word value. The word is either one of the
660 host's FQDNs, or the dotted-quad IP address of the peer for IPv4,
661 or the colon-separated IP address of the peer for IPv6. If this
662 value is not specified, then the name of the peer in the enclosing
663 peer block is taken to also be its ip-name.
664
666 If innfeed gets a SIGHUP signal, then it will reread the configuration
667 file. All values at global scope except for backlog-directory can be
668 changed (although note that bindaddress and bindaddress6 changes will
669 only affect new connections).
670 Any new peers are added and any missing peers have their connections
672 closed.
673 The log file is also reopened.
675
677 For a comprehensive example, see the sample innfeed.conf distributed
678 with INN and installed as a starting point.
679 Here are examples of how to format values:
681 eg-string: "New\tconfig\tfile\n"
683 eg-long-string: "A long string that goes
684 over multiple lines. The
685 newline is kept in the
686 string except when quoted
687 with a backslash \
688 as here."
689 eg-simple-string: A-no-quote-string
690 eg-integer: 10
691 eg-boolean: true
692 eg-char: 'a'
693 eg-ctrl-g: '\007'
694
696 Written by James Brister <brister@vix.com> for InterNetNews. Converted
697 to POD by Julien Elie.
698 Earlier versions of innfeed (up to 0.10.1) were shipped separately;
700 innfeed is now part of INN and shares the same version number. Please
701 note that the innfeed.conf format has changed dramatically since
702 version 0.9.3.
703
705 inn.conf(5), innfeed(8), newsfeeds(5).
706INN 2.7.1 2023-03-07 INNFEED.CONF(5)