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