Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
NEWSFEEDS(5)		  InterNetNews Documentation		  NEWSFEEDS(5)

NAME
       newsfeeds - Determine where Usenet articles are sent

DESCRIPTION
       The file	pathetc/newsfeeds specifies how	incoming articles should be
       distributed to other programs and files on the server.  It is parsed by
       the InterNetNews	server innd(8) when it starts up, or when directed to
       by ctlinnd(8).  innd doesn't send articles to remote sites itself, so
       newsfeeds doesn't directly determine which remote news servers articles
       are sent	to.  Instead, it specifies what	batch files should be created
       or which	programs should	be run (and what information should be sent to
       them), and then this information	is used	by programs like innxmit(8)
       and innfeed(8) to feed articles to remote sites.

       The newsfeeds file isn't	used solely to set up feeding accepted
       articles	to remote sites	but also to pass them (or bits of information
       about them) to any local	programs or files that want that data.	For
       example,	controlchan(8),	a daemon that processes	incoming control
       messages, runs out of newsfeeds,	as could a news	to mail	gateway.

       The file	is interpreted as a set	of lines, parsed according to the
       following rules:	 If a line ends	with a backslash, the backslash, the
       newline,	and any	whitespace at the start	of the next line is deleted.
       This is repeated	until the entire "logical" line	is collected.  If the
       logical line is blank or	starts with a number sign ("#"), it is
       ignored.

       All other lines are interpreted as feed entries.	 An entry should
       consist of four colon-separated fields; two of the fields may have
       optional	sub-fields, marked off by a slash.  Fields or sub-fields that
       take multiple parameters	should be separated by a comma.	 Extra
       whitespace can cause problems and should	be avoided.  Except for	the
       site names, case	is significant.	 The format of an entry	is:

	   sitename[/exclude,exclude,...]\
	       :pattern,pattern...[/distribution,distribution...]\
	       :flag,flag...\
	       :parameter

       Each field is described below.

       The sitename is the name	of the site to which a news article can	be
       sent.  It is used for writing log entries and for determining if	an
       article should be forwarded to a	site.  (A "site" is the	generic	term
       for some	destination of newsfeed	data; it often corresponds to a	remote
       news peer, but doesn't have to.	For example, a local archiving program
       run from	newsfeeds is also a "site".)  If sitename already appears in
       the article's Path: header, then	the article will not be	sent to	the
       site.  The name is usually whatever the remote site uses	to identify
       itself in the Path: header, but can be almost any word.

       Be careful, though, to avoid having the sitename	accidentally match a
       Path: header entry unintentionally.  For	this reason, special local
       entries (such as	archivers or gateways) should probably end with	an
       exclamation point to make sure that they	do not have the	same name as
       any real	site.  For example, "gateway" is an obvious name for the local
       entry that forwards articles out	to a mailing list.  If a site with the
       name "gateway" posts an article,	when the local site receives the
       article it will see the name in the Path	and not	send the article to
       its own "gateway" entry.	 Since "gateway!" can't	appear as an
       individual Path:	entry since "!"	is a delimiter in the Path: header,
       that would be a better thing to use for sitename.

       (Another	way to avoid this problem is with the "Ap" flag; see the
       description below.)

       If an entry has an exclusion sub-field, the article will	not be sent to
       that site if any	of exclude appear in the Path: header.	(It's
       sometimes convenient to have the	sitename be an abbreviated form	of the
       name of the remote site,	since all the sitenames	to which an article is
       sent are	written	to the log and using shorter sitenames can therefore
       improve performance for large servers.  In this case, the Path: header
       entries of those	sites should be	given as exclude entries and the "Ap"
       flag used so that the abbreviated sitename doesn't accidentally match
       some other Path:	header entry.)

       The same	sitename can be	used more than once and	the appropriate	action
       will be taken for each entry that should	receive	the article, but this
       is recommended only for program feeds to	avoid confusion.  Case is not
       significant in site names.

       The comma-separated pattern specifies which groups to send to the site;
       it is interpreted to build a "subscription list"	for the	site.  The
       default subscription is to get all groups carried by the	server.	 It is
       a uwildmat(3) pattern supporting	poison ("@") wildcards;	see the
       uwildmat(3) man page for	full details on	the pattern matching language.
       pattern will be matched against every newsgroup carried by the server
       and all newsgroups that match will be added to the subscription list
       for the site.

       Normally, a given article (or information about it) is sent to a	site
       if any of the newsgroups	to which the article was posted	are in that
       site's subscription list.  If a newsgroup matches a "@" pattern in
       pattern,	then not only is it not	added to the subscription list,	but
       any articles crossposted	to that	newsgroup also will not	be sent	to
       that site even if other newsgroups to which it was crossposted are in
       that site's subscription	list.  This is called a	poison pattern
       (because	matching groups	are "poisoned").

       For example, to receive all comp.* groups, but only comp.sources.unix
       within the sources newsgroups, the following pattern can	be used:

	   comp.*,!comp.sources.*,comp.sources.unix

       Note that the trailing ".*" is required;	the pattern has	to match the
       whole newsgroup name.  "comp.sources.*" could be	written
       "comp.sources*" and would exclude the newsgroup comp.sources (if	it
       exists) as well as the groups in	the comp.sources.* hierarchy, but note
       that this would also exclude a newsgroup	named comp.sources-only
       (whereas	the above pattern would	add that group to the site
       subscription list since it matches "comp.*" and none of the other
       patterns).

       For another example, to feed alt.* and misc.* to	a given	site but not
       any articles posted to alt.binaries.warez (even if they're also
       crossposted to other alt.* or misc.* groups), the following pattern can
       be used:

	   alt.*,@alt.binaries.warez,misc.*

       Note, however, that if you reversed the "alt.*" and
       "@alt.binaries.warez" entries, this pattern would be equivalent to
       "alt.*,misc.*", since the last matching pattern determines whether a
       given newsgroup matches and the poison logic only applies if the	poison
       entry is	the last matching entry.

       Control messages	follow slightly	different propagation rules than
       normal articles;	see innd(8) for	the details.  Note that	most
       subscriptions should have "!junk,!control,!control.*" in	their pattern
       list due	to those propagation rules (and	since "junk" is	a special
       internal	newsgroup; see wanttrash in inn.conf(5)	for more details on
       what it's used for) and that the	best way to keep control messages
       local to	a site is with a distribution.

       A subscription can be further modified by specifying distributions that
       the site	should or should not receive.  The default is to send all
       articles	to all sites that subscribe to any of the groups where it has
       been posted, but	if an article has a Distribution: header and any
       distributions are specified, then they are checked according to the
       following rules:

       1.  If the Distribution:	header matches any of the values in the	sub-
	   field, the article is sent.

       2.  If a	distribution starts with an exclamation	point, and it matches
	   the Distribution: header, the article is not	sent.

       3.  If the Distribution:	header does not	match any distribution in the
	   site's entry	and no negations were used, the	article	is not sent.

       4.  If the Distribution:	header does not	match any distribution in the
	   site's entry	and any	distribution started with an exclamation
	   point, the article is sent.

       If an article has more than one distribution specified, then each one
       is handled according according to the above rules.  If any of the
       specified distributions indicate	that the article should	be sent, it
       is; if none do, it is not sent.	In other words,	the rules are used as
       a logical or.

       It is almost definitely a mistake to have a single feed that specifies
       distributions that start	with an	exclamation point along	with some that
       don't.

       Distributions are text words, not patterns; entries like	"*" or "all"
       have no special meaning.

       The flag	field is described in "FLAG VALUES".  The interpretation of
       the parameter field depends on the type of feed and is explained	in
       more detail in "FEED TYPES".  It	can be omitted for some	types of
       feeds.

       The site	named "ME" is special.	There must be exactly one such entry,
       and it should be	the first entry	in the file.  If the "ME" entry	has an
       exclusion sub-field, incoming articles are rejected completely if any
       of the names specified in that exclusion	sub-field appear in their
       Path: headers.  If the "ME" entry has a subscription list, that list is
       prepended to the	subscription list of all other entries.	 For example,
       "*,!control,!control.*,!junk,!foo.*" could be used to set the default
       subscription list for all other feeds so	that local postings are	not
       propagated unless "foo.*" explicitly appears in the site's subscription
       list.  This feature tends to be somewhat	confusing since	the default
       subscription is prepended and can be overridden by other	patterns.

       If the "ME" entry has a distribution sub-field, only articles that
       match that distribution list are	accepted and all other articles	with a
       distribution are	rejected.  A common use	for this is to put something
       like "/!local" in the "ME" entry	to reject local	postings from other
       misconfigured sites.  The distribution sub-field	of "ME"	has no effect
       on the acceptance or rejection of articles that do not have a
       Distribution header field.

       An empty	"ME" entry is possible,	in which case no exclusion patterns
       will be defined.

       Finally,	it is also possible to set variables in	newsfeeds and use them
       later in	the file.  A line starting with	"$" sets a variable.  For
       example:

	   $LOCALGROUPS=local.*,example.*

       This sets the variable "LOCALGROUPS" to "local.*,example.*".  This
       variable	can later be used elsewhere in the file, such as in a site
       entry like:

	   news.example.com:$LOCALGROUPS:Tf,Wnm:

       which is	then completely	equivalent to:

	   news.example.com:local.*,example.*:Tf,Wnm:

       Variables aren't	solely simple substitution.  If	either "!" or "@"
       immediately preceds the variable	and the	value of the variable contains
       commas, that character will be duplicated before	each comma.  This
       somewhat	odd-sounding behavior is designed to make it easier to use
       variables to construct feed patterns.  The utility becomes more obvious
       when you	observe	that the line:

	   news.example.net:*,@$LOCALGROUPS:Tf,Wnm:

       is therefore equivalent to:

	   news.example.net:*,@local.*,@example.*:Tf,Wnm:

       which (as explained below) excludes all of the groups in	$LOCALGROUPS
       from the	feed to	that site.

FLAG VALUES
       The flags parameter specifies miscellaneous parameters, including the
       type of feed, what information should be	sent to	it, and	various
       limitations on what articles should be sent to a	site.  They may	be
       specified in any	order and should be separated by commas.  Flags	that
       take values should have the value immediately after the flag letter
       with no whitespace.  The	valid flags are:

       < size
	   An article will only	be sent	to this	site if	it is less than	size
	   bytes long.	The default is no limit.

       > size
	   An article will only	be sent	to this	site if	it is greater than
	   size	bytes long.  The default is no limit.

       A checks
	   An article will only	be sent	to this	site if	it meets the
	   requirements	specified in checks, which should be chosen from the
	   following set.  checks can be multiple letters if appropriate.
	   Note	that this flag is not effective	on funnel targets; it has to
	   be used on every funnel entry (for instance,	Af is not effective on
	   the innfeed!	funnel target and therefore has	to be specified	on
	   every funnelled news	site).

	   c  Exclude all kinds	of control messages.

	   C  Only send	control	messages, not regular articles.

	   d  Only send	articles with a	Distribution: header.  Combined	with a
	      particular distribution value in the distribution	part of	the
	      site entry, this can be used to limit articles sent to a site to
	      just those with a	particuliar distribution.

	   e  Only send	articles where every newsgroup listed in the
	      Newsgroups: header exists	in the active file.

	   f  Don't send articles rejected by filters.	This is	only useful
	      when dontrejectfiltered is set to	true in	inn.conf.  With	that
	      variable set, this lets one accept all articles but not
	      propagate	filtered ones to some sites.

	   j  Propagate	articles according to their Newsgroups:	header.	 This
	      is only useful when wanttrash is set to true in inn.conf.	 With
	      that variable set, articles accepted and filed in	"junk" (due to
	      wanttrash) are fed to peers based	on their subscription pattern
	      applied to the Newsgroups: header	as though they were accepted
	      and all those groups were	locally	carried.  Otherwise, they are
	      propagated to sites that receive the "junk" newsgroup.

	      This variable is useful if you want to run INN with a minimal
	      active file and propagate	all posts.

	   o  Only send	articles for which overview data was stored.

	   O  Send articles to this site that don't have an Injection-Info: or
	      X-Trace: header, even if the "O" flag is also given.

	   p  Only check the exclusions	against	the Path: header of articles;
	      don't check the site name.  This is useful if your site names
	      aren't the same as the Path: entries added by those remote
	      sites, or	for program feeds where	the site name is arbitrary and
	      unrelated	to the Path: header.

	   If both "c" and "C" are given, the last specified one takes
	   precedence.

       B high/low
	   If a	site is	being fed by a file, channel, or exploder (see below),
	   the server will normally start trying to write the information as
	   soon	as possible.  Providing	a buffer may give better system
	   performance and help	smooth out overall load	if a large batch of
	   news	comes in.  The value of	the this flag should be	two numbers
	   separated by	a slash.  high specifies the point at which the	server
	   can start draining the feed's I/O buffer, and low specifies when to
	   stop	writing	and begin buffering again; the units are bytes.	 The
	   default is to do no buffering, sending output as soon as it is
	   possible to do so.

       C count
	   If this flag	is specified, an article will only be sent to this
	   site	if the number of groups	it is posted to, plus the square of
	   the number of groups	followups would	appear in, is no more than
	   count.  30 is a good	value for this flag, allowing for instance:

	   o  crossposts to only 5 groups when followups aren't	set;

	   o  crossposts to up to 26 groups when followups are set to two
	      groups;

	   o  crossposts to up to 29 groups when followups are set to a	single
	      group;

	   o  crossposts to up to 30 groups when followups are set to poster.

	   Note	that if	an article does	not contain a Followup-To: header
	   field, the number of	groups followups would appear in is the	number
	   of groups it	is posted to.

       F name
	   Specifies the name of the file that should be used if it's
	   necessary to	begin spooling for the site (see below).  If name is
	   not an absolute path, it is taken to	be relative to pathoutgoing in
	   inn.conf.  If name is a directory, the file togo in that directory
	   will	be used	as the file name.

       G count
	   If this flag	is specified, an article will only be sent to this
	   site	if it is posted	to no more than	count newsgroups.  This	has
	   the problem of filtering out	many FAQs, as well as newsgroup
	   creation postings and similar administrative	announcements.	Either
	   the C flag or the U flag is a better	solution.

       H count
	   If this flag	is specified, an article will only be sent to this
	   site	if it has count	or fewer sites in its Path: line.  This	flag
	   should only be used as a rough guide	because	of the loose
	   interpretation of the Path: header; some sites put the poster's
	   name	in the header, and some	sites that might logically be
	   considered to be one	hop become two because they put	the posting
	   workstation's name in the header.  The default value	for count if
	   not specified is one.  (Also	see the	O flag,	which is sometimes
	   more	appropriate for	some uses of this flag.)

       I size
	   The flag specifies the size of the internal buffer for a file feed.
	   If there are	more file feeds	than allowed by	the system, they will
	   be buffered internally in least-recently-used order.	 If the
	   internal buffer grows bigger	then size bytes, however, the data
	   will	be written out to the appropriate file.	 The default value is
	   16 KB.

       N status
	   Restricts the articles sent to this site to those in	newsgroups
	   with	the moderation status given by status.	If status is "m", only
	   articles in moderated groups	are sent; if status is "u", only
	   articles in unmoderated groups are sent.

       O originator
	   If this flag	is specified, an article will only be sent to this
	   site	if it contains an Injection-Info: header (or an	X-Trace:
	   header if no	Injection-Info:	header is found) and the first field
	   of this header matches originator.  originator is a uwildmat(3)
	   expression without commas or	a list of such expressions, separated
	   by "/".  The	article	is never sent if the first character of	the
	   pattern begins with "@" and the rest	of the pattern matches.	 One
	   use of this flag is to restrict the feed to locally generated posts
	   by using an originator pattern that matches the Injection-Info:
	   header added	by the local server.

       P priority
	   The nice priority that this channel or program feed should receive.
	   This	should be a positive number between 0 and 20 and is the
	   priority that the new process will run with.	 This flag can be used
	   to raise the	priority to normal if you're using the nicekids
	   parameter in	inn.conf.

       Q hashfeed
	   Specifies the hashfeed match	expression for this site.  It must be
	   in the form "value/mod" or "start-end/mod".	The Message-ID of the
	   article is hashed using MD5,	which results in a 128-bit hash.  The
	   lowest 32 bits are then taken by default as the hashfeed value
	   (which is an	integer).  If the hashfeed value modulus "mod" plus
	   one equals "value" or is between "start" and	"end", the article
	   will	be fed to this site.  All these	numbers	must be	integers.

	   It is a deterministic way to	control	the flow of articles and to
	   split a feed.  For instance:

	       Q1/2	 Feeds about 50% of all	articles to this site.
	       Q2/2	 Feeds the other 50% of	all articles.

	   Another example with	three sites:

	       Q1-3/10	 Feeds about 30% of all	articles.
	       Q4-5/10	 Feeds about 20% of all	articles.
	       Q6-10/10	 Feeds about 50% of all	articles.

	   If this flag	is specified multiple times, the contents will be
	   logically "OR"ed together (just one match is	needed).

	   You can use an extended syntax of the form "value/mod_offset" or
	   "start-end/mod_offset".  As MD5 generates a 128-bit return value,
	   it is possible to specify from which	byte-offset the	32-bit integer
	   used	by hashfeed starts.  The default value for "offset" is "_0"
	   and thirteen	overlapping values from	"_0" to	"_12" can be used.
	   Only	up to four totally independent values exist:  "_0", "_4", "_8"
	   and "_12".

	   Therefore, it allows	to a generate a	second level of	deterministic
	   distribution.  Indeed, if a news server is fed "Q1/2", it can go on
	   splitting thanks to "Q1-3/9_4" for instance.	 Up to four levels of
	   deterministic distribution can be used.

	   The algorithm is compatible with the	one used by Diablo 5.1 and up.
	   If you want to use the legacy quickhashing method used by Diablo
	   before 5.1, you can put an "@" sign just after the Q	flag (for
	   instance "Q@1-3/10",	but the	distribution of	the messages is	not
	   perfect with	this legacy method whose use is	discouraged and	for
	   which offsets cannot	be used).

       S size
	   If the amount of data queued	for the	site gets to be	larger than
	   size	bytes, the server will switch to spooling, appending to	a file
	   specified by	the F flag, or pathoutgoing/sitename if	F is not
	   specified.  Spooling	usually	happens	only for channel or exploder
	   feeds, when the spawned program isn't keeping up with its input.

       T type
	   This	flag specifies the type	of feed	for this site.	type should be
	   a letter chosen from	the following set:

	       c	Channel
	       f	File
	       l	Log entry only
	       m	Funnel (multiple entries feed into one)
	       p	Program
	       x	Exploder

	   Each	feed is	described below	in "FEED TYPES".  The default is Tf,
	   for a file feed.

       U count
	   If this flag	is specified, an article will only be sent to this
	   site	if followups to	this article would be posted to	no more	than
	   count newsgroups.  (Also see	C for a	more complex way of handling
	   this.)

       W items
	   For a file, channel,	or exploder feed, this flag controls what
	   information will be sent to this site.  For a program feed, only
	   the asterisk	("*") has any effect.  items should be chosen from the
	   following set:

	   b  Size of the article (in wire format, meaning with	CRLF at	the
	      end of each line,	periods	doubled	at the beginning of lines, and
	      ending in	a line with a single period) in	bytes.

	   e  The time the article will	expire as seconds since	epoch if it
	      has an Expires: header, 0	otherwise.

	   f  The storage API token of the article (the	same as	"n").  The
	      article can be retrieved given the storage API token by using
	      sm(8).

	   g  The newsgroup the	article	is in; if cross-posted,	then the first
	      of the groups to which the article was posted that this site
	      gets.  (The difference from "G" is that this sends the newsgroup
	      to which the article was posted even if it is a control
	      message.)

	   h  The history hash key of the article (derived from	the message
	      ID).

	   m  The message ID of	the article.

	   n  The storage API token of the article.  The article can be
	      retrieved	given the storage API token by using sm(8).

	   p  The time the article was posted a	seconds	since epoch.

	   s  The site that fed	the article to the server.  This is taken from
	      either the Path: header or the IP	address	of the sending site
	      depending	on the value of	logipaddr in inn.conf.	If logipaddr
	      is true and the IP address is 0.0.0.0 (meaning that the article
	      was fed from localhost by	a program like rnews(8)), the Path:
	      header value will	be sent	instead.

	   t  The time the article was received	as seconds since epoch.

	   *  The names	of the appropriate funnel entries, or all sites	that
	      get the article (see below for more details).

	   D  The value	of the Distribution: header of the article, or "?" if
	      there is no such header in the article.

	   G  Where the	article	is stored.  If the newsgroup is	crossposted,
	      this is generally	the first of the groups	to which it was	posted
	      that this	site receives; however,	control	messages are filed in
	      control or control.*  (which is the difference between this item
	      and "g").

	   H  All of the headers, followed by a	blank line.  The Xref header
	      will already be present, and a Bytes header containing the
	      article's	size in	bytes as in the	"b" item will be added to the
	      headers.	If used, this should be	the only item in the list.

	   N  The value	of the Newsgroups: header.

	   P  The value	of the Path: header.

	   O  Overview data for	the article.

	   R  Information needed for replication (the Xref header without the
	      site name).

	   More	than one letter	can be given.  If multiple items are
	   specified, they will	be written in the order	specified separated by
	   spaces.  ("H" should	be the only item if given, but if it's not a
	   newline will	be sent	before the beginning of	the headers.)  The
	   default is Wn.

	   The "H" and "O" items are intended for use by programs that create
	   news	overview databases or require similar information.  WnteO is
	   the flag to generate	input needed by	the overchan(8)	program.

	   The asterisk	("*") has special meaning.  Normally it	expands	to a
	   space-separated list	of all sites that received the current
	   article.  If, however, this site is a target	of a funnel feed (in
	   other words,	if it is named by other	sites which have the Tm	flag),
	   then	the asterisk expands to	the names of the funnel	feeds that
	   received the	article.  Similarly, if	the site is a program feed, an
	   asterisk in the parameter field will	be expanded into the list of
	   funnel feeds	that received the article.  A program feed cannot get
	   the site list unless	it is the target of other Tm feeds.

FEED TYPES
       innd provides four basic	types of feeds:	 log, file, program, and
       channel.	 An exploder is	a special type of channel.  In addition,
       several entries can feed	into the same feed; these are funnel feeds,
       which refer to an entry that is one of the other	types.	Funnel feeds
       are partially described above with the description of the W* flag.  A
       funnel feed gets	every article that would be sent to any	of the feeds
       that funnel into	it and normally	include	the W* flag in their flags so
       that the	program	processing that	feed knows which sites received	which
       articles.  The most common funnel feed is innfeed(8).

       Note that the term "feed" is technically	a misnomer, since the server
       doesn't transfer	articles itself	and only writes	data to	a file,
       program,	or log telling another program to transfer the articles.

       The simplest feed is a log feed (Tl).  Other than a mention in the news
       log file, pathlog/news, no data is written out.	This is	equivalent to
       a Tf entry writing to /dev/null,	except that no file is ever opened.
       Flushing	a log feed does	nothing.

       A file feed (Tf)	is the next simplest type of feed.  When the site
       should receive an article, the specified	data is	written	out to the
       file named by the parameter field.  If parameter	is not an absolute
       path, it	is taken to be relative	to pathoutgoing	in inn.conf.  If
       parameter is not	given, it defaults to pathoutgoing/sitename.  The file
       name should be unique (two file feeds should not	ever point to the same
       file).

       File feeds are designed for use by external programs that periodically
       process the written data.  To cooperate with innd properly, such
       external	programs should	first rename the batch file and	then send a
       flush command for that site to innd using ctlinnd(8).  innd will	then
       write out any buffered data, close the file, and	reopen it (under the
       original	name), and the program can process the data in the renamed
       file at its leisure.  File feeds	are most frequently used in
       combination with	nntpsend(8).

       A program feed (Tp) spawns a given program for every article that the
       site receives.  The parameter field must	be the command line to
       execute,	and should contain one instance	of %s, which will be replaced
       by the storage API token	of the article (the actual article can be
       retrieved by the	program	using sm(8)).  The program will	not receive
       anything	on standard input (unlike earlier versions of INN, where the
       article is sent to the program on stdin), and standard output and error
       from the	program	will be	set to the error log (pathlog/errlog).	innd
       will try	to avoid spawning a shell if the command has no	shell meta-
       characters; this	feature	can be defeated	if necessary for some reason
       by appending a semi-colon to the	end of the command.  The full path
       name of the program to be run must be specified unless the command will
       be run by the shell (and	it is strongly recommended that	the full path
       name always be specified	regardless).

       If a program feed is the	target of a funnel, and	if W* appears in the
       flags of	the site, a single asterisk may	be present in the parameter
       and will	be replaced by a space-separated list of names of the sites
       feeding into the	funnel which received the relevant article.  If	the
       site is not the target of a funnel, or if the W*	flag is	not used, the
       asterisk	has no special meaning.

       Flushing	a program feed does nothing.

       For a channel (Tc) or exploder (Tx) feed, the parameter field again
       names the process to start.  As with program feeds, the full path to
       the program must	be specified.  However,	rather than spawning the
       program for every article, it is	spawned	once and then whenever the
       site receives an	article, the data specified by the site	flags is
       written to the standard input of	the spawned program.  Standard output
       and error are set as with program feeds.	 If the	process	exits, it will
       be restarted automatically.  If the process cannot be started, the
       server will spool input to a file named pathoutgoing/sitename and will
       try to start the	process	again later.

       When a channel or exploder feed is flushed, the server closes its end
       of the pipe to the program's standard input.  Any pending data that has
       not been	written	will be	spooled; see the description of	the S flag
       above.  The server will then spawn a new	instance of the	program.  No
       signal is sent to the program; it is up to the program handling a
       channel or exploder feed	to notice end of file on its standard input
       and exit	appropriately.

       Exploders are a special type of channel feed.  In addition to the
       channel feed behavior described above, exploders	can also be sent
       command lines.  These lines start with an exclamation point and their
       interpretation is up to the exploder.  The following commands are
       generated automatically by the server:

	   !newgroup group
	   !rmgroup group
	   !flush
	   !flush site

       These commands are sent whenever	the ctlinnd(8) command of the same
       name is received	by the server.	In addition, the ctlinnd(8) "send"
       command can be used to send an arbitrary	command	line to	an exploder.
       The primary exploder is buffchan(8).

       Finally,	Tm feeds are the input to a funnel.  The parameter field of
       the site	should name the	site handling articles for all of the funnel
       inputs.

EXAMPLES
       The syntax of the newsfeeds file	is so complex because you can specify
       a staggering variety of feeds.  INN is capable of interacting with a
       wide variety of programs	that do	various	things with news articles.
       Far and away the	most common two	entries	in newsfeeds, however, are
       file feeds for nntpsend(8) and funnel feeds for innfeed(8).

       The former look like this:

	   feed.example.com:*,!control,!control.*,!junk:Tf,Wnm:

       which generates a file named pathoutgoing/feed.example.com containing
       one line	per article consisting of the storage API token, a space, and
       the message ID.

       The latter look like this:

	   feed.example.com:*,!control,!control.*,!junk:Tm:innfeed!

       Very similar, except that this is the input to a	funnel feed named
       "innfeed!".  One	could also write this as:

	   example/feed.example.com:*,!control,!control.*,!junk:Ap,Tm:innfeed!

       (note the Ap so that articles that contain just "example" in the	Path:
       header will still be sent), which is completely equivalent except that
       this will be logged in pathlog/news as going to the site	"example"
       rather than "feed.example.com".

       The typical feed	entry for innfeed(8) is	a good example of a channel
       feed that's the target of various funnel	feeds (make sure the path to
       innfeed is properly set):

	   innfeed!:!*:Tc,Wnm*:<pathbin	in inn.conf>/innfeed -y

       Note that the pattern for this feed is just "!*"	so that	it won't
       receive any articles directly.  The feed	should only receive those
       articles	that would go to one of	the funnel feeds that are feeding into
       it.  innfeed(8) will receive one	line per article on its	standard input
       containing the storage API token, the message ID, and a space-separated
       list of sites that should receive that article.

       Here's a	more esoteric example of a channel feed:

	   watcher!:*:Tc,Wbnm\
	       :exec awk '$1 > 1000000 { print "BIG", $2, $3 }'	> /dev/console

       This receives the byte size of each article along with the storage API
       token and message ID, and prints	to the console a line for every
       article that's over a million bytes.  This is actually rather a strange
       way to write this since INN can do the size check itself; the following
       is equivalent:

	   watcher!:*:Tc,>1000000,Wbnm\
	       :exec awk '{ print "BIG", $2, $3}' > /dev/console

       Here's a	cute, really simple news to mail gateway that also serves as
       an example of a fairly fancy program feed:

	   mailer!:!*:W*,Tp\
	       :sm %s |	innmail	-s "News article" *

       Remember	that %s	is replaced by the storage API token, so this
       retrieves the article and pipes it into innmail (which is safer than
       programs	like Mail(1) because it	doesn't	parse the body for tilde
       commands) with a	given subject line.  Note the use of "*" in the
       command line and	W* in the flags; this entry is designed	to be used as
       the target of funnel feeds such as:

	   peter@example.com:news.software.nntp:Tm:mailer!
	   sue@example.com:news.admin.misc:Tm:mailer!

       Suppose that the	server receives	an article crossposted between
       news.admin.misc and news.software.nntp.	The server will	notice that
       the article should be sent to the site "peter@example.com" and the site
       "bob@example.com", both of which	funnel into "mailer!", so it will look
       at the "mailer!"	site and end up	executing the command line:

	   sm @...@ | innmail -s "News article"	peter@example.com sue@example.com

       which will mail the article to both Peter and Sue.

       Finally,	another	very useful example of a channel feed:	the standard
       entry for controlchan(8).  Make sure its	path is	properly set.

	   controlchan!\
	       :!*,control,control.*,!control.cancel/!collabra-internal\
	       :AC,Tc,Wnsm:<pathbin in inn.conf>/controlchan

       This program only wants information about articles posted to a control
       newsgroup other than control.cancel, which due to the sorting of
       control messages	described in innd(8) will send it all control messages
       except for cancel messages.  In this case, we also exclude any article
       with a distribution of "collabra-internal".  controlchan	gets the
       storage API token, the name of the sending site (for processing old-
       style ihave and sendme control messages,	be sure	to read	about
       logipaddr in controlchan(8)), and the message ID	for each article.

       For many	other examples,	including examples of the special "ME" site
       entry, see the example newsfeeds	file distributed with INN.  Also see
       the install documentation that comes with INN for information about
       setting up the standard newsfeeds entries used by most sites.

HISTORY
       Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews.
       Reformatted and rewritten in POD	by Russ	Allbery	<eagle@eyrie.org>.

       $Id: newsfeeds.pod 10061	2016-09-04 12:48:39Z iulius $

SEE ALSO
       active(5), buffchan(8), controlchan(8), ctlinnd(8), inn.conf(5),
       innd(8),	innfeed(8), innxmit(8),	nntpsend(8), uwildmat(3).

INN 2.6.1			  2016-10-07			  NEWSFEEDS(5)

NAME | DESCRIPTION | FLAG VALUES | FEED TYPES | EXAMPLES | HISTORY | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=newsfeeds&sektion=5&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help