On Mar 22, 2023 at 6:54:40 AM CDT, "Eli" <eliistheman@gmail.com> wrote:

> On 22 Mar 2023 at 07:47:21 CET, "Julien ÉLIE"
> <iulius@nom-de-mon-site.com.invalid> wrote:
>
>> Hi Eli,
>>
>>> Transfer to server failed (436): Can't store article
>>>
>>> I'll keep looking for a cause.
>>
>> As it seems you are using the tradspool storage system, could you please
>> try:
>> scanspool -n -v
>>
>> Though probably not related to overview, could you also try:
>> tdx-util -A
>> (if you're using tradindexed)
>
> Since these commands take quite a long time, I will wait with this until all
> pullnews sessions are done and let you know.
>
> Something else:
> How can I reset a newsgroup that has already been fully downloaded so that
> pullnews starts downloading all posts again?
>
> Can this be done by:
> 1) 'ctlinnd rmgroup newgroup'
> 2) 'ctlinnd newgroupgroup'
>
> or is there a better way?
>
> Thank again and apologies for all my questions.

If you've already made a full pass over the group with pullnews and want to
make another full pass, I think the easiest is to modify the pullnews.marks
counts for that group and set to 1. That should cause pullnews to start from
the beginning.

Hi Eli,

> Something else:
> How can I reset a newsgroup that has already been fully downloaded so that
> pullnews starts downloading all posts again?
>
> Can this be done by:
> 1) 'ctlinnd rmgroup newgroup'
> 2) 'ctlinnd newgroupgroup'
>
> or is there a better way?

+1 for Jesse's way.

I have a question about these ctlinnd rmgroup/newgroup commands. Do you
happen to have already used them to "reset" a newsgroup?
It would explain the "Can't store" errors if you also did not purge the
tradspool files in <pathspool> for some newsgroups. Files named with
article numbers "1", "2", "3", etc. will still be present in your spool.
If you recreate a newsgroup with ctlinnd rmgroup/newgroup, it just
recreate it in the active file, without wiping the spool. Article
numbering is reset to 1, and INN will try to store articles in already
existing "1", "2", etc. files.

--
Julien ÉLIE

« Il ne faut jamais parler sèchement à un Numide. » (Astérix)

On 22 Mar 2023 at 16:23:25 CET, "Jesse Rehmer"
<jesse.rehmer@blueworldhosting.com> wrote:

> On Mar 22, 2023 at 6:54:40 AM CDT, "Eli" <eliistheman@gmail.com> wrote:
>
>> On 22 Mar 2023 at 07:47:21 CET, "Julien ÉLIE"
>> <iulius@nom-de-mon-site.com.invalid> wrote:
>>
>>> Hi Eli,
>>>
>>>> Transfer to server failed (436): Can't store article
>>>>
>>>> I'll keep looking for a cause.
>>>
>>> As it seems you are using the tradspool storage system, could you please
>>> try:
>>> scanspool -n -v
>>>
>>> Though probably not related to overview, could you also try:
>>> tdx-util -A
>>> (if you're using tradindexed)
>>
>> Since these commands take quite a long time, I will wait with this until all
>> pullnews sessions are done and let you know.
>>
>> Something else:
>> How can I reset a newsgroup that has already been fully downloaded so that
>> pullnews starts downloading all posts again?
>>
>> Can this be done by:
>> 1) 'ctlinnd rmgroup newgroup'
>> 2) 'ctlinnd newgroupgroup'
>>
>> or is there a better way?
>>
>> Thank again and apologies for all my questions.
>
> If you've already made a full pass over the group with pullnews and want to
> make another full pass, I think the easiest is to modify the pullnews.marks
> counts for that group and set to 1. That should cause pullnews to start from
> the beginning.

Hi Jesse,

That's what I thought at first too, but this prevents all existing files in
the spool from being downloaded again and all messages are treated as
'-- not downloading already existing message'.

My question is therefore how you can completely reset a newsgroup so that
everything is downloaded again.

This in particular for the newsgroup 'news.lists.filters'. This group contains
the references to the 'spam' messages that NoCem then deletes. I want to reset
this newsgroup 'news.lists.filters' so that all messages are checked locally
again and in case of spam removed.

But besides this newsgroup I also want to reset other newsgroups.
I hope this is possible.

On 22 Mar 2023 at 19:38:07 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>> Something else:
>> How can I reset a newsgroup that has already been fully downloaded so that
>> pullnews starts downloading all posts again?
>>
>> Can this be done by:
>> 1) 'ctlinnd rmgroup newgroup'
>> 2) 'ctlinnd newgroupgroup'
>>
>> or is there a better way?
>
> +1 for Jesse's way.
>
> I have a question about these ctlinnd rmgroup/newgroup commands. Do you
> happen to have already used them to "reset" a newsgroup?
> It would explain the "Can't store" errors if you also did not purge the
> tradspool files in <pathspool> for some newsgroups. Files named with
> article numbers "1", "2", "3", etc. will still be present in your spool.
> If you recreate a newsgroup with ctlinnd rmgroup/newgroup, it just
> recreate it in the active file, without wiping the spool. Article
> numbering is reset to 1, and INN will try to store articles in already
> existing "1", "2", etc. files.

Hi Julien,

No, unfortunately I didn't.
I have not deleted or reset anything at all.
The problem still occurs intermittently and I don't understand why.

Hi Eli,

>> If you've already made a full pass over the group with pullnews and want to
>> make another full pass, I think the easiest is to modify the pullnews.marks
>> counts for that group and set to 1. That should cause pullnews to start from
>> the beginning.
>
> That's what I thought at first too, but this prevents all existing files in
> the spool from being downloaded again and all messages are treated as
> '-- not downloading already existing message'.
>
> My question is therefore how you can completely reset a newsgroup so that
> everything is downloaded again.

Ah yes, that's a bit tricky as what you want is to remove all traces of
articles in spool, overview and history.

The proper method would be to:

- ctlinnd rmgroup xxx
- remove the <pathspool>/articles/.../xxx directory of the group
- set /remember/ to 0 in expire.ctl
- run the expireover and expire process (for instance via news.daily
called with the same parameters as in crontab, plus "notdaily")
- undo the change in expire.ctl (/remember/ set to 11)
- ctlinnd newgroup xxx
- reset the last downloaded article in pullnews.marks for this group
- deactivate Perl and Python filters, and set the artcutoff to 0
- run pullnews
- reactivate the filters, and artcutoff to 10

I think INN will happily accept to be refed of these articles.

> This in particular for the newsgroup 'news.lists.filters'. This group contains
> the references to the 'spam' messages that NoCem then deletes. I want to reset
> this newsgroup 'news.lists.filters' so that all messages are checked locally
> again and in case of spam removed.

As for NoCeM, you can directly refeed your notices to perl-nocem without
resetting anything.

perl-nocem expects storage tokens on its standard input.
Example:

echo '@020162BEB132016300000000000000000000@' | perl-nocem

As you're running tradindexed overview, I would suggest to have a look
at the output of:

tdx-util -g -n news.lists.filters

It dumps the overview data of this newsgroup. The last field is a
storage token.
You could replay NoCeM notices with these information :)

--
Julien ÉLIE

« Ta remise sur pied lui a fait perdre la tête ! » (Astérix)

On Mar 22, 2023 at 4:16:46 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

>> This in particular for the newsgroup 'news.lists.filters'. This group contains
>> the references to the 'spam' messages that NoCem then deletes. I want to reset
>> this newsgroup 'news.lists.filters' so that all messages are checked locally
>> again and in case of spam removed.
>
> As for NoCeM, you can directly refeed your notices to perl-nocem without
> resetting anything.
>
> perl-nocem expects storage tokens on its standard input.
> Example:
>
> echo '@020162BEB132016300000000000000000000@' | perl-nocem
>
> As you're running tradindexed overview, I would suggest to have a look
> at the output of:
>
> tdx-util -g -n news.lists.filters
>
> It dumps the overview data of this newsgroup. The last field is a
> storage token.
> You could replay NoCeM notices with these information :)

Very nice, this is valuable to me as well. I know I will be doing this when I
am done gathering articles from all other the place. :-)

On 22 Mar 2023 at 22:16:46 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

Hey Julien,

> Hi Eli,
>
>> That's what I thought at first too, but this prevents all existing files in
>> the spool from being downloaded again and all messages are treated as
>> '-- not downloading already existing message'.
>>
>> My question is therefore how you can completely reset a newsgroup so that
>> everything is downloaded again.
>
> Ah yes, that's a bit tricky as what you want is to remove all traces of
> articles in spool, overview and history.
>
> The proper method would be to:
>
> - ctlinnd rmgroup xxx
> - remove the <pathspool>/articles/.../xxx directory of the group
> - set /remember/ to 0 in expire.ctl
> - run the expireover and expire process (for instance via news.daily
> called with the same parameters as in crontab, plus "notdaily")
> - undo the change in expire.ctl (/remember/ set to 11)
> - ctlinnd newgroup xxx
> - reset the last downloaded article in pullnews.marks for this group
> - deactivate Perl and Python filters, and set the artcutoff to 0
> - run pullnews
> - reactivate the filters, and artcutoff to 10
>
>
> I think INN will happily accept to be refed of these articles.
>
>
>> This in particular for the newsgroup 'news.lists.filters'. This group contains
>> the references to the 'spam' messages that NoCem then deletes. I want to reset
>> this newsgroup 'news.lists.filters' so that all messages are checked locally
>> again and in case of spam removed.
>
> As for NoCeM, you can directly refeed your notices to perl-nocem without
> resetting anything.
>
> perl-nocem expects storage tokens on its standard input.
> Example:
>
> echo '@020162BEB132016300000000000000000000@' | perl-nocem
>
> As you're running tradindexed overview, I would suggest to have a look
> at the output of:
>
> tdx-util -g -n news.lists.filters
>
> It dumps the overview data of this newsgroup. The last field is a
> storage token.
> You could replay NoCeM notices with these information :)

Ah cool :)

Exactly what I needed.
Thanks so much.

Another question, is it possible to limit the maximum number of connections
per authenticated user? I know this is possible for peers, but can this also
be set up for authenticated users? Maybe a setting in readers.conf or nnrpd
that I'm overlooking?

Hi Eli,

> Another question, is it possible to limit the maximum number of connections
> per authenticated user? I know this is possible for peers, but can this also
> be set up for authenticated users? Maybe a setting in readers.conf or nnrpd
> that I'm overlooking?

Unfortunately, the response is no. There's no native way of limiting
users' connections.
You may want to write a custom authentication hook (perl_auth or
python_auth in readers.conf) that would do the job by accounting how
many connections are open by a given user, and deny access if it exceeds
the limit. I am not aware of existing scripts to do that :-(

It could be worthwhile having though, as you're not the first one to ask
(but nobody wrote or shared what he came up with).

--
Julien ÉLIE

« Ta remise sur pied lui a fait perdre la tête ! » (Astérix)

On 21 Mar 2023 at 20:18:32 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>>> In some newsgroups I get the following error while using pullnews:
>>>
>>> DEBUGGING 560 Post 436: Msg: <Can't store article>
>>>
>>> Then pullnews quits.
>>> Can this be avoided as it is very annoying.
>
> Do you happen to have other logs in <pathlog>/news.err or news.notice?
> It would be useful to understand why innd did not manage to store the
> article provided by pullnews. It is an unusual error. Do all the
> newsgroups match an entry in storage.conf?

Hi Julien,

I probably found the problem.
The errlog gives the following error:

==
innd: tradspool: could not symlink
/usr/local/news/spool/articles/alabama/politics/11365 to
/usr/local/news/spool/articles/alt/2600/414/78: Not a directory
==

/usr/local/news/spool/articles/alt/2600/414 is a file, but for some reason
INND wants to create a folder in that path with the same name as the file
name.

Any ideas how this is possible and how to fix?

Hi Eli,

> I probably found the problem.
> The errlog gives the following error:
>
> ==
> innd: tradspool: could not symlink
> /usr/local/news/spool/articles/alabama/politics/11365 to
> /usr/local/news/spool/articles/alt/2600/414/78: Not a directory
> ==
>
> /usr/local/news/spool/articles/alt/2600/414 is a file, but for some reason
> INND wants to create a folder in that path with the same name as the file
> name.
>
> Any ideas how this is possible and how to fix?

Ah, OK, I understand.
The article I tested last day was posted to a newsgroup named
"alt.2600.414". It did not produce any error on my news server because
I do not have a newsgroup named alt.2600.

When you are using tradspool, there's a conflict between the 414th
article in the newsgroup alt.2600 and any article in the newsgroup
alt.2600.414.
It is how the tradspool storage method works.

Such newsgroups should not be used. FYI, an excerpt of the naming
convention of newsgroups:

A <component> SHOULD NOT consist solely of digits and SHOULD NOT
contain uppercase letters. Such <component>s MAY be used only to
refer to existing groups that do not conform to this naming scheme,
but MUST NOT be used otherwise.

NOTE: All-digit <component>s conflict with one widely used storage
scheme for articles. Mixed-case groups cause confusion between
systems with case-sensitive matching and systems with case-
insensitive matching of <newsgroup-name>s.

How to fix it?
Well, you can't with your current storage method.
You would have to switch to another method (to set in storage.conf) like
CNFS, timecaf or timehash. All these three methods will be able to
store articles for such groups.
You could keep tradspool for all the newsgroups except for the
problematic ones if you want (you would have to explicitly list them in
storage.conf).

--
Julien ÉLIE

« Nous autres communistes, nous avons une position claire : nous n'avons
jamais changé, nous ne changerons jamais et nous sommes pour le
changement. » (Georges Marchais)

On Mar 22, 2023 at 4:49:55 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>> Another question, is it possible to limit the maximum number of connections
>> per authenticated user? I know this is possible for peers, but can this also
>> be set up for authenticated users? Maybe a setting in readers.conf or nnrpd
>> that I'm overlooking?
>
> Unfortunately, the response is no. There's no native way of limiting
> users' connections.
> You may want to write a custom authentication hook (perl_auth or
> python_auth in readers.conf) that would do the job by accounting how
> many connections are open by a given user, and deny access if it exceeds
> the limit. I am not aware of existing scripts to do that :-(
>
> It could be worthwhile having though, as you're not the first one to ask
> (but nobody wrote or shared what he came up with).

It's pretty simple to run nnrpd via other utilities that will do the limiting
for you, though, most UNIX/Linux systems have at least two or three tools to
accomplish more or less the same thing.

That said, it would be nice to have that ability directly in nnrpd.

Hi Jesse,

>> Unfortunately, the response is no. There's no native way of limiting
>> users' connections.
>
> It's pretty simple to run nnrpd via other utilities that will do the limiting
> for you, though, most UNIX/Linux systems have at least two or three tools to
> accomplish more or less the same thing.
>
> That said, it would be nice to have that ability directly in nnrpd.

Ah yes, exactly. That's the reason why this was never implemented in
INN. It's not seen as a priority at all, and it's also not trivial to do.

Issue #23
"nnrpd currently has no way of limiting connections per IP address other
than using the custom auth hooks. In its daemon mode, it could in
theory keep track of this and support throttling. It's probably not
worth trying to support this when invoked via inetd, since at that point
one could just use xinetd and its built-in support for things like this.

When started from innd, this is a bit harder. innd has some basic rate
limiting stuff, but nothing for tracking number of simultaneous
connections over time. It may be fine to say that if you want to use
this feature, you need to have nnrpd be invoked separately, not run from
innd."

So the answer is to use something like "per_source = 5" in xinetd.conf
and start nnrpd by xinetd.

--
Julien ÉLIE

« Nous autres communistes, nous avons une position claire : nous n'avons
jamais changé, nous ne changerons jamais et nous sommes pour le
changement. » (Georges Marchais)

On 3/22/23 3:49 PM, Julien ÉLIE wrote:
> There's no native way of limiting users' connections.

It's not per user in that you could have multiple users per IP, but I'd
think seriously about doing this at the firewall such that each IP can
only have a limited number of connections.

--
Grant. . . .
unix || die

On 22 Mar 2023 at 23:24:07 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Eli,
>
>> Any ideas how this is possible and how to fix?
>
> Ah, OK, I understand.
> The article I tested last day was posted to a newsgroup named
> "alt.2600.414". It did not produce any error on my news server because
> I do not have a newsgroup named alt.2600.

Hi Julien,

Removing "alt.2600.414" fixed it :D
Thanks Julien.

On 22 Mar 2023 at 23:35:44 CET, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Ah yes, exactly. That's the reason why this was never implemented in
> INN. It's not seen as a priority at all, and it's also not trivial to do.
>
> Issue #23
> "nnrpd currently has no way of limiting connections per IP address other
> than using the custom auth hooks. In its daemon mode, it could in
> theory keep track of this and support throttling. It's probably not
> worth trying to support this when invoked via inetd, since at that point
> one could just use xinetd and its built-in support for things like this.
>
> When started from innd, this is a bit harder. innd has some basic rate
> limiting stuff, but nothing for tracking number of simultaneous
> connections over time. It may be fine to say that if you want to use
> this feature, you need to have nnrpd be invoked separately, not run from
> innd."
>
>
> So the answer is to use something like "per_source = 5" in xinetd.conf
> and start nnrpd by xinetd.

This makes it possible to limit the number of sessions per IP, but not per
authenticated user account.

1) xinitd starts nnrpd and after this the authentication takes place.
2) nntpd sends the login data to perl_auth, which consults the database for
authorization, as well as checking whether the user has already reached his
maximum connections.

So point 2 is where the problem lies.

Each time the authorization is successful, a 'session' record can be added to
the database. The number of records determines how many sessions are running
for this user.

But as soon as a session disconnects, the record must be removed from the
database. However, nnrpd does not know that the session has been disconnected.
Only xinitd knows this, but it doesn't have the user data, nor can it access
the database.

Perhaps something can be done with the xinitd PID, but even then this will
have to be passed to the perl_auth script.

So here's the problem I can't solve.
Do you have a suggestion?

On 23 Mar 2023 at 10:55:52 CET, "Eli" <eliistheman@gmail.com> wrote:

> 2) nntpd sends the login data to perl_auth, which consults the database for

Of course I meant nnrpd here.

Second question:
Starting nnrpd by xinetd on port 119 requires a second IP (since innd is
already bound to 119).
But how does this affect peers? Do they connect to the IP of innd or nnrpd?

Hi Eli,

> 2) nnrpd sends the login data to perl_auth, which consults the database for
> authorization, as well as checking whether the user has already reached his
> maximum connections.
>
> So point 2 is where the problem lies.
>
> Each time the authorization is successful, a 'session' record can be added to
> the database. The number of records determines how many sessions are running
> for this user.
>
> But as soon as a session disconnects, the record must be removed from the
> database. However, nnrpd does not know that the session has been disconnected.
> Only xinitd knows this, but it doesn't have the user data, nor can it access
> the database.
>
> Perhaps something can be done with the xinitd PID, but even then this will
> have to be passed to the perl_auth script.
>
> Do you have a suggestion?
> So here's the problem I can't solve.
That problem is probably why nobody has still written yet the requested
feature either natively in nnrpd or in a perl_auth script...

> Starting nnrpd by xinetd on port 119 requires a second IP (since
> innd is already bound to 119). But how does this affect peers? Do
> they connect to the IP of innd or nnrpd?

If you set up nnrpd as a daemon listening to port 119 (unencrypted) and
another nnrpd as a daemon listening to port 563 (TLS), news admins
usually set up innd to listen to port 433 (also called the NNSP port,
for Network News Streaming Protocol). Then you tell your peers to feed
you on that port.

--
Julien ÉLIE

« Quand je raconterai mon odyssée, personne ne me croira ! » (Astérix)

On 3/23/23 3:55 AM, Eli wrote:
> 1) xinitd starts nnrpd and after this the authentication takes place.

Does (x)inetd need to start nnrpd /directly/? Or could it start a
script which in turn starts nnrpd as well as calling something to clean
up sessions after nnrpd exists?

Especially if there could be some form of information that would
correlate the IP & port tuple with the session. I'd think it would be
relatively easy to detect that the TCP connection for a given IP & port
tuple no longer exists (either completely gone or closing / TIME_WAIT
type thing) and subsequently remove the session from the list.

--
Grant. . . .
unix || die

If I am correct, as an admin it is possible to cancel a message posted locally
by a user by means of the 'canlockadmin' secret in inn-secrets.conf.

However, it is not clear to me how to cancel these messages as admin.
Is 'gencancel' the right and only tool for this?

Can someone point me in the right direction please.

Thank you.

Hello,

Once you have edited the inn-secrets.conf file
(https://www.eyrie.org/~eagle/software/inn/docs/inn-secrets.conf.html)
and the "cancels" group, each article posted on your server will have :

- One (or more) Cancel-Lock added by the server (if the client used by
the user does not support CL/CK). This allows the user to cancel his own
articles.

- One (or more) Cancel-Locks added by your server (if you have defined
canlockadmin). This CL is used by the administrator to cancel all
articles posted on his server.

To do this, you actually need to use Gencancel to generate the correct
Cancel-key (Gencancel use the admin secret) that will match one hash of
the Cancel-Lock of the article to cancel.

https://www.eyrie.org/~eagle/software/inn/docs/gencancel.html

For me, Gencancel is the only tool to do the job but as I am not an INN
expert, maybe Julien or Russ can give you more information (even if I
think the documentation is well enough written.

Have nice day.
Franck

On 6 Apr 2023 at 17:55:24 CEST, "Franck" <franck@email.invalid> wrote:

> Hello,
>
> Once you have edited the inn-secrets.conf file
> (<https://www.eyrie.org/~eagle/software/inn/docs/inn-secrets.conf.html>)
> and the "cancels" group, each article posted on your server will have :
>
> ...
>
> For me, Gencancel is the only tool to do the job but as I am not an INN
> expert, maybe Julien or Russ can give you more information (even if I
> think the documentation is well enough written.
>
> Have nice day.
> Franck

Thanks for the answer.

However, for some reason it's not working as expected.

I've set the secret for 'canlockadmin' in inn-secrets.conf.

In readers.conf (just in case):

auth "localhost" {
hosts: "localhost, 127.0.0.1, ::1, stdin"
default: "<localhost>"
}

access "localhost" {
users: "<localhost>"
newsgroups: "*"
access: RPA
addcanlockuser: none
}

The following command works as expected and returns a full cancellation
header:
su news -s /bin/sh -c "/usr/local/news/bin/gencancel -n '<newsgroup>'
'<msg-id>'" | su news -s /bin/sh -c "/usr/local/news/bin/inews -h -P -D"

However, when using the above command without the -D gives:
inews: warning: What server?
inews: article will be spooled

And a file named 'dead.article' is writing into the home dir of user 'news'.

Any ideas what goes wrong?

Hi Eli,

>> For me, Gencancel is the only tool to do the job

That's right Franck :)
Eli, is there something unclear in the gencancel documentation that
should be improved? If that's the case, what should be written and where?

> su news -s /bin/sh -c "/usr/local/news/bin/gencancel -n '<newsgroup>'
> '<msg-id>'" | su news -s /bin/sh -c "/usr/local/news/bin/inews -h -P -D"
>
> However, when using the above command without the -D gives:
> inews: warning: What server?
> inews: article will be spooled >
> Any ideas what goes wrong?

inews tries to connect to the server set in the "server" parameter in
inn.conf. I guess this parameter is unset.

I'll add the name of the parameter in the inews manual page. It
currently just mentions "inews sends the article to the local news
server as specified in inn.conf".

And inews is not listed in the names of the programs for which the
"server" parameter is used in inn.conf... Also added.

--
Julien ÉLIE

« Traversez la rivière en foule, le crocodile ne vous mangera pas. »
(proverbe malgache)

> Eli, is there something unclear in the gencancel documentation that
> should be improved?  If that's the case, what should be written and where?

FWIW, I suggest in gencancel, these additions surrounded with "*" to try
to make it clearer:

If INN was built with Cancel-Lock support, gencancel will generate the
right *admin* Cancel-Key header field to use in order to authenticate
cancels.

[...]

In case you only need the *admin* Cancel-Key hashes, you can use the -k
flag.

[...]

Instead of outputting a whole cancel control message, gencancel will
just output the body of the *admin* Cancel-Key header field.

[...]

To only retrieve the *admin* Cancel-Key hashes associated to the given
Message-ID:

[...]

If it all looks good, then inject it into the news system (without
giving -D to inews):

gencancel '<mid@news>' | inews -h -P

*Note that inews sends the message to the server specified in the server
parameter in inn.conf.*

I hope it would have made your life easier!

--
Julien ÉLIE

« Quand on demande aux gens d'observer le silence, au lieu de l'observer
comme on observe une éclipse de lune, ils l'écoutent ! » (Raymond
Devos)

On 6 Apr 2023 at 21:00:09 CEST, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> inews tries to connect to the server set in the "server" parameter in
> inn.conf. I guess this parameter is unset.
>
> I'll add the name of the parameter in the inews manual page. It
> currently just mentions "inews sends the article to the local news
> server as specified in inn.conf".
>
> And inews is not listed in the names of the programs for which the
> "server" parameter is used in inn.conf... Also added.

Hi Julien,

Thank you for answering.
It was the 'server' setting indeed.

I'm getting close, but now inews is trying to connect using the
IPv6 address of the server, instead of IPv4.
I'll have to figure out how to make a workaround for this, especially since
I'm using xinetd for nnrpd.

I have created an IPv6 -> IPv4 proxy in xinetd. That works, but then INN
reports that I don't have permission to cancel messages :(

Hi Eli,

> It was the 'server' setting indeed.
>
> I'm getting close, but now inews is trying to connect using the
> IPv6 address of the server, instead of IPv4.

Did you try to just put the IPv4 address of your server in the "server"
setting? (instead of its hostname)
It will maybe work (I have not tested).

> I'll have to figure out how to make a workaround for this, especially since
> I'm using xinetd for nnrpd.

In your readers.conf file, you mentioned:

auth "localhost" {
hosts: "localhost, 127.0.0.1, ::1, stdin"
default: "<localhost>"
}

Maybe you should also add the DNS (and IP) of your server?

--
Julien ÉLIE

« Quand on demande aux gens d'observer le silence, au lieu de l'observer
comme on observe une éclipse de lune, ils l'écoutent ! » (Raymond
Devos)