Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Test Git repository for INN (Julien ?LIE)
2. Re: Build system changes (Julien ?LIE)
3. Re: Removing obsolete control messages in INN 2.7 (Julien ?LIE)
4. Re: Removing obsolete control messages in INN 2.7 (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Nov 2021 21:57:46 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Test Git repository for INN
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
> Probably over the holidays I'm going to do some cleanup of my server that
> was hosting Trac and the Subversion repository. Is there anything left
> there that still needs to be moved before it can be safely shut down?
> (I'll keep an archive just in case.)
I believe both Trac and the Subversion repository can be closed. Their
contents have been moved.
Thanks for having provided these facilities to the INN project all these
years!
Seems like the migration to Github was a useful move. I am under the
impression we have a regain of activity, and it is easier for people to
contribute to the project via the issue and PR facilities.
A great thing done!
--
Julien ?LIE
??Le vrai danger, ce n'est pas quand les ordinateurs penseront comme les
hommes, c'est quand les hommes penseront comme les ordinateurs.??
------------------------------
Message: 2
Date: Wed, 24 Nov 2021 22:21:21 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
> I made some progress on this but then I got distracted by work and other
> things, so I haven't been able to get to it for the past two weeks. I am
> going to pick it up again, and should have time in the next month and a
> half to finish it. (Hopefully sooner than that, of course.)
Ack, good luck!
>> - Remove or fix installation of signcontrol #28
>> => couldn't signcontrol just be moved to the "contrib" directory then? It
>> will no longer be installed by default and overwritten during a "make
>> update"
>
> I see that you did this and I agree with that
In fact, that was only at the stage of a comment in #28 for a future
action, and still had not moved it to contrib.
> but also we could just drop
> it from the INN distribution entirely. It's available via the pgpcontrol
> distribution also from ISC if anyone wants it, and I think the number of
> INN users who need to issue control messages is very small. The number
> who both need that and who benefit from having it included in INN may be
> zero.
I totally agree.
I've now committed the removal.
--
Julien ?LIE
??Le vrai danger, ce n'est pas quand les ordinateurs penseront comme les
hommes, c'est quand les hommes penseront comme les ordinateurs.??
------------------------------
Message: 3
Date: Wed, 24 Nov 2021 23:23:03 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Removing obsolete control messages in INN 2.7
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> - remove control/modules/{sendsys,senduuname,version}.pl;
>
>> - remove the "doifarg" keyword from controlchan and control.ctl
>> documentation (it is only used for these 3 kinds of control messages);
>
>> - but keep the recognition of the sendsys, senduuname and version control
>> messages in inncheck and scanlogs (because they are still referenced in
>> control.ctl) as well as filter_innd.py in the example of a regexp for
>> obsolete control articles.
>
> Sounds good to me. I can't imagine us ever wanting to support those
> control messages.
Sure! Now removed from the INN distribution.
>> There is a common man page for send-ihave (ihave control messages) and
>> send-nntp (usual articles). I suggest to:
>
>> - remove the send-nntp script, and mention in NEWS that nntpsend or
>> innfeed should be used instead;
>
> I agree, I don't understand why that script exists when nntpsend exists.
> nntpsend feels like a more sophisticated version of send-nntp.
OK, I'll remove send-nntp. As the current man page is for both
send-nntp and send-ihave, I'll adapt it to only keep send-ihave for INN
2.7.0.
>> - keep the send-ihave script as well as control/modules/{ihave,sendme}.pl
>> as the ihave and sendme control messages are not obsolete. Though I
>> would be half-tempted to also drop them... Even the documentation says
>> "the author of this manpage is unsure as to how [send-ihave] actually
>> works or used to work". Indeed, it is not clear how ihave batch files are
>> generated... (no examples)
>
> My recollection is that this stuff is all intended for UUCP feeds. The
> idea is that you tell your UUCP peers what articles you have available via
> ihave control messages, you respond with a sendme control message for the
> articles that you want, and the sendme controlchan module creates a batch
> file to send to that site via UUCP.
What remains unclear is how the ihave control messages are generated first.
Hmm, after digging a bit, I found out a very old documentation from Rich
in the INN 1.5.1 install guide:
https://github.com/InterNetNews/inn/blob/1.5.1/Install.ms.2
It will need a bit of testing to verify if ihave still works this way
with current versions, and then redocument it with full samples of
newsfeeds entries and crontab.
FWIW, here is the excerpt from INN 1.5.1:
"""
you must create two entries in your newsfeeds file. The first should be
named remote.ihave. Make this a "Tf,Wm" feed that contains the
remote's subscription list. This entry results in a a file that
accumulates the Message-ID's of all articles that remote might want.
The other entry should be named remote. This should be a "Tf,Wn" feed
that only subscribes to the "to.remote" newsgroup. (Actually, if you
feed some groups as a standard feed, you can put them on the remote
entry, rather then the remote.ihave entry.)
The next step is to have the "ihave" control messages sent out.
To do this, review the send-ihave script and make sure it is invoked as
needed (usually out of cron). It splits the batchfile from the
remote.ihave newsfeeds entry and posts "ihave" control messages into
the "to.remote" newsgroup. These messages will get queued for the
remote entry.
The next step is to send out any articles queued for the remote
entry. Treat this as a standard UUCP feed, invoking send-uucp or
sendbatch as appropriate, typically a few minutes after send-ihave runs.
When the remote site receives the "ihave" message it will filter
it and send back a "sendme" message whose body is the list of desired
Message-ID's. When innd processes this message it will invoke the
appropriate control script, /usr/local/news/bin/control/sendme. This
script will call grephistory to turn the list into a list of files
appended to the batchfile for remote. Examine this script (the filename
should probably match the filename in the remote newsfeeds entry) and
send the batch to the remote site (using batcher, often called by send-
uucp or sendbatch).
"""
> I have no idea if any UUCP site is still using ihave/sendme control
> messages to control the feed, rather than simply sending everything.
> Obviously, this mechanism was more important when UUCP was done via
> long-distance telephone calls and modems, where you wanted to minimize the
> amount of time the line had to stay connected.
Seems like it could still be useful to support ihave/sendme. There are
still discussions about UUCP (and more recent NNCP) on the web, though
NNCP documentation I found speaks of a full exchanges of rnews batches.
UUCP sometimes mentions ihave/sendme.
--
Julien ?LIE
??A man who is not married is incomplete; a man who is married is
finished.??
------------------------------
Message: 4
Date: Wed, 24 Nov 2021 14:37:33 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Removing obsolete control messages in INN 2.7
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Hi Russ,
>> My recollection is that this stuff is all intended for UUCP feeds. The
>> idea is that you tell your UUCP peers what articles you have available
>> via ihave control messages, you respond with a sendme control message
>> for the articles that you want, and the sendme controlchan module
>> creates a batch file to send to that site via UUCP.
> What remains unclear is how the ihave control messages are generated
> first.
send-ihave is the script that generates the ihave control message. Note
this bit, buried down in the bottom of the script:
## Write out the batchfile as a control message, in clumps.
export SITE PERMESSAGE BATCHFILE
while test -s ${BATCHFILE} ; do
(
echo Newsgroups: to.${SITE}
echo Control: ihave `innconfval pathhost`
echo Subject: cmsg ihave `innconfval pathhost`
echo ''
${SED} -e ${PERMESSAGE}q <${BATCHFILE}
) | ${INEWS} -h
${SED} -e "1,${PERMESSAGE}d" <${BATCHFILE} >${BATCHFILE}.tmp
mv ${BATCHFILE}.tmp ${BATCHFILE}
done
Essentially, it transforms the batch for a site into an ihave control
message and posts it to the to.* newsgroup for that peer.
There is obviously no signing on those messages, and I'm not sure if INN
safely restricts who can send to the relevant to.* group and only honors
control messages in that group correctly, which would be necessary. It
might! I have to admit that I have never used any of the UUCP support.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 135, Issue 7
*******************************************
