GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages
SEND-IHAVE(8) InterNetNews Documentation SEND-IHAVE(8)

send-ihave - Send ihave control messages to remote sites

send-ihave [-d] sitename[:hostname] [sitename[:hostname] ...]

Using send-ihave is discouraged; the ihave and sendme control messages implement a predecessor of the NNTP protocol, and are now largely obsolete on the Internet but still see use in conjunction with some transport protocols such as UUCP.

In case you really need using ihave and sendme control messages, and follow these instructions to set them up, please inform the INN maintainers of any documentation improvements that would have made the installation easier, notably missing or unclear steps.

The basic idea behind the ihave and sendme control messages is that you tell your UUCP peers what articles you have available via ihave control messages, and you respond with a sendme control message for the articles that you want.

send-ihave processes the batch files written by innd to send ihave control messages to remote NNTP sites. The sites to be fed are specified by giving "sitename:hostname" pairs on the command line. The sitename is the label the site has in the newsfeeds file, without its ".ihave" suffix. The hostname is the real hostname of the remote site, a FQDN (Fully Qualified Domain Name). Normally, the sitename and the hostname are the same, and as such don't have to be specified as "sitename:hostname" pairs but just as "sitename".

send-ihave encapsulates Message-IDs in an ihave control message and uses inews to send the control message to a "to.hostname" pseudo-newsgroup.

The batch file generated by send-ihave for a given site is named sitename.ihave in the pathoutgoing directory. To prevent batch file corruption, shlock(1) is used ensure these files are not processed by two running instances in parallel.

For instance, to generate ihave control messages for news.server.com when receiving articles in the comp.* hierarchy, just add the following line in your newsfeeds file (and reload it):

    news.server.com.ihave:comp.*:Tf,Wm:

(Note that if you send "*" to "news.server.com", you should add "@to,@to.*" to the end of the newsgroup pattern so that the ihave control message generated by send-ihave isn't, itself, included in the list of articles in an ihave control message. You may also want to add that pattern to the end of any entry processing control articles, like controlchan, or being fed a "*" pattern.)

Then, periodically run out of cron(8) the following command:

    send-ihave news.server.com

send-ihave will then post to the "to.news.server.com" pseudo-newsgroup an ihave control article containing a list of Message-IDs. Several control articles may be posted, each one containing up to 1000 Message-IDs.

Make sure the "to.news.server.com" pseudo-newsgroup exists on your server (or the "to" pseudo-newsgroup if mergetogroups is set to true in inn.conf), and that ihave control articles are not filtered (the default Cleanfeed configuration rejects them). These control articles will be filed in the "control" pseudo-newsgroup (or "control.ihave" if it exists), or "to" if mergetogroups is set to true.

You now have to propagate them with any method you want to the remote server. You probably already had one set up, in which case you only have to add the "to.news.server.com" newsgroup in the list of groups to feed it. (See how send-uucp(8) works to set up a UUCP feed.)

Besides sending ihave control messages, your news server needs processing the sendme control messages it receives from remote peers. You have to add a "sendme" entry in control.ctl.local with a doit action to allow the processing of these messages matching a given From address. controlchan will then generate a batch file named pathname.work in pathoutgoing, containing a list of storage tokens (pathname is taken from the Path header field body or the IP address of the remote peer, depending on the value of logipaddr in inn.conf). Finally, you'll have to set up batcher(8) or send-uucp(8) to send the news batches to your remote peers.

Similarly, your news server needs processing the ihave control messages it receives from remote peers. This step is the easiest to do. Just add an "ihave" entry in control.ctl.local like the one you added for "sendme". controlchan will process these ihave control messages, and generate a sendme control article for each article present in the ihave control message but not in your local news server. These sendme control articles are posted to the "to.pathname" pseudo-newsgroup, and will be propagated as described before. (Note that there may be two different "to" groups to create because the sitename used in newsfeeds may not be the same as pathname.)

Beware that the ihave and sendme control messages are not signed. You should enforce restrictions on who can send articles to "to.*" groups, either via readers.conf or special rules in filter hooks, and on the "ihave" and "sendme" lines in control.ctl.local.

-d
The -d flag causes send-ihave to send output to stdout rather than the send-ihave.log log file in pathlog.

Rewritten into POD by Julien Elie.

batcher(8), controlchan(8), control.ctl(5), inews(1), newsfeeds(5), send-uucp(8).
2022-02-19 INN 2.7.0

Search for    or go to Top of page |  Section 8 |  Main Index

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.