Hi,

One of my peers brought something to my attention that they think is not
correct about my configuration. They have provided enough information
to make me think I need to change something.

Before I make changes, I want to better understand what various INN
options are and how they will impact my servers.

First, I have two news servers, one is -- what I call -- my public
transit server (with a small spool) that peers with all my peers and the
other is my private archive server (with a much larger spool) and only
peers with my transit server.

I've been using "tnetconsulting.net" as the entry in the Path header
thinking that it is a superset of <host>.tnetconsulting.net or
<host>.<subdomain>.tnetconsulting.net. It seems as if this is probably
the incorrect value to be using.

My peer has suggested either "pathalias" or "pathcluster" with a value
of "tnetconsulting.net".

My two news servers perform different roles and I would never consider
them to be any form of cluster with each other. So I think that
"pathcluster" is a non-starter.

Will someone please help me understand what my two servers should be
doing and how pathalias might influence how they interact with each
other and the rest of Usenet?

Please and thank you.

N.B. I've not named the peer in question out of courtesy. I have no
objection to them naming themselves.

--
Grant. . . .
unix || die

On Mar 19, 2023 at 9:01:31 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

> Hi,
>
> One of my peers brought something to my attention that they think is not
> correct about my configuration. They have provided enough information
> to make me think I need to change something.
>
> Before I make changes, I want to better understand what various INN
> options are and how they will impact my servers.
>
> First, I have two news servers, one is -- what I call -- my public
> transit server (with a small spool) that peers with all my peers and the
> other is my private archive server (with a much larger spool) and only
> peers with my transit server.
>
> I've been using "tnetconsulting.net" as the entry in the Path header
> thinking that it is a superset of <host>.tnetconsulting.net or
> <host>.<subdomain>.tnetconsulting.net. It seems as if this is probably
> the incorrect value to be using.
>
> My peer has suggested either "pathalias" or "pathcluster" with a value
> of "tnetconsulting.net".
>
> My two news servers perform different roles and I would never consider
> them to be any form of cluster with each other. So I think that
> "pathcluster" is a non-starter.
>
> Will someone please help me understand what my two servers should be
> doing and how pathalias might influence how they interact with each
> other and the rest of Usenet?
>
> Please and thank you.
>
> N.B. I've not named the peer in question out of courtesy. I have no
> objection to them naming themselves.

Hehe - the peer in question is me. To shed further light on why Grant is
asking, I noticed Grant's issue when I switched to Diablo which does Path
matching diagnostics and I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
ha.home.tnetconsulting.net!not-for-mail

I had a similar configuration as Grant and told him I was using "pathalias
usenet.blueworldhosting.com" with INN.

I think this is a good discussion as I think based on stuff I've seen here
that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

Cheers,

Jesse

On 3/19/23 8:08 PM, Jesse Rehmer wrote:
> Hehe - the peer in question is me.

;-)

> To shed further light on why Grant is asking, I noticed Grant's issue
> when I switched to Diablo which does Path matching diagnostics and
> I noticed this in messages coming from his site:
>
> Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
> blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
> ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
> ha.home.tnetconsulting.net!not-for-mail
>
> I had a similar configuration as Grant and told him I was using "pathalias
> usenet.blueworldhosting.com" with INN.

I suspect that I'm going to end up using pathalias as you suggested.

I'm hoping to learn and understand better what should be happening, why
it should be happening, and how I'm (accidentally) going against that now.

> I think this is a good discussion as I think based on stuff I've seen here
> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

:-)

--
Grant. . . .
unix || die

On Mar 19, 2023 at 9:18:53 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

> On 3/19/23 8:08 PM, Jesse Rehmer wrote:
>> Hehe - the peer in question is me.
>
> ;-)
>
>> To shed further light on why Grant is asking, I noticed Grant's issue
>> when I switched to Diablo which does Path matching diagnostics and
>> I noticed this in messages coming from his site:
>>
>> Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
>> blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
>> ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
>> ha.home.tnetconsulting.net!not-for-mail
>>
>> I had a similar configuration as Grant and told him I was using "pathalias
>> usenet.blueworldhosting.com" with INN.
>
> I suspect that I'm going to end up using pathalias as you suggested.
>
> I'm hoping to learn and understand better what should be happening, why
> it should be happening, and how I'm (accidentally) going against that now.
>
>> I think this is a good discussion as I think based on stuff I've seen here
>> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.
>
> :-)

To piggy onto this, and something I would like to further understand, is the
proper 'technically expected' usage of pathalias vs pathcluster.

I understand the two basically differ whether they append or preprend the
element, but I'm not certain which is correct to use in which scenarios.

As I explained to Grant via e-mail, in my experience it didn't seem to matter
the ordering of the Path elements so much, but more that the Path I've told my
peers to expect appears somewhere in the Path header of articles I offer to
them.

On 3/19/23 8:27 PM, Jesse Rehmer wrote:
> To piggy onto this, and something I would like to further understand,
> is the proper 'technically expected' usage of pathalias vs pathcluster.

+1

> I understand the two basically differ whether they append or preprend
> the element, but I'm not certain which is correct to use in which
> scenarios.

I'm trying to think about how peers might behave depending on the
ordering of ":<host>.<domain>.<tld>:<domain>.<tld>:" vs
":<domain>.<tld>:<host>.<domain>.<tld>:".

My guess below is predicated on the host being "<host>.<domain>.<tld>"
and the pathalias being "<domain>.<tld>":

I can see how having ":<host>.<domain>.<tld>:<domain>.<tld>:"
(pathalias) would cause a peer to not feed to any server (in a
multi-server configuration) if it was configured to exclude
":<domain>.<tld>:".

Hence why in a clustered set of multiple servers, one would likely want
the ":<domain>.<tld>:" to come later (to the left of) than the
":<host>.<domain>.<tld>:".

> As I explained to Grant via e-mail, in my experience it didn't seem
> to matter the ordering of the Path elements so much, but more that
> the Path I've told my peers to expect appears somewhere in the Path
> header of articles I offer to them.

:-)

--
Grant. . . .
unix || die

Hi Jesse and Grant,

>> To piggy onto this, and something I would like to further understand,
>> is the proper 'technically expected' usage of pathalias vs pathcluster.
>
> +1

Path: pathcluster!!pathhost!!pathalias!...

From inn.conf documentation:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to the
Path header field body.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

This way, you tell your peers that they should expect "pathcluster" as
the last and unique name for your outgoing feeds.
And "pathalias" is used to add another name in the Path (for instance in
the case we recently discussed to add a specific server name so that
articles are not fed to this news server by others).

> Hence why in a clustered set of multiple servers, one would likely want
> the ":<domain>.<tld>:" to come later (to the left of) than the
> ":<host>.<domain>.<tld>:".

So that the leftmost path entry is unique for all your outgoing feeds.

>> As I explained to Grant via e-mail, in my experience it didn't seem to
>> matter the ordering of the Path elements so much, but more that the
>> Path I've told my peers to expect appears somewhere in the Path header
>> of articles I offer to them.

For article propagation, yes, it does not matter. But for path
diagnostics, it matters :-)
The peer should correctly parameterize the expected name(s) at the
leftmost side of the Path header field. This is done with the alias
parameter in dnewsfeeds, and probably with the (future) pathmatch
parameter in incoming.conf for INN, which can contain a wildmat pattern.

--
Julien ÉLIE

« Give laugh to all but smile to one,
Give cheeks to all but lips to one,
Give love to all but Heart to one,
Let everybody love you
But you love one. »

Hi Jesse,

> I noticed Grant's issue when I switched to Diablo which does Path
> matching diagnostics and I noticed this in messages coming from his site:
>
> Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
> blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
> ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
> ha.home.tnetconsulting.net!not-for-mail

FWIW, the standardized syntax is "!.MISMATCH.45.33.28.24", in coherence
with "!.POSTED.alpha.home.tnetconsulting.net". The diagnostic is
followed with a value.

> I had a similar configuration as Grant and told him I was using "pathalias
> usenet.blueworldhosting.com" with INN.
>
> I think this is a good discussion as I think based on stuff I've seen here
> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

According to Diablo's changelog:

Diablo V1.12

Added Path: name checking. If the first element of the Path:
received by an article does not match any 'alias' statements
for the incoming connection, the IP address is prepended
to the path: with .MISMATCH appended.

>>> NOTE <<< you should grep through newly created spool
directories every so often looking for .MISMATCH in the spool
files to locate incoming feeds with improperly configured
'alias's (in dnewsfeeds). When I turned this feature on,
I found that four of my 80+ feeds were misconfigured.

I would then suggest to update the alias parameter in dnewsfeeds to
match the one of Grant's server.

--
Julien ÉLIE

« When a newly married couple smiles, everyone knows why. When a ten-
year married couple smiles, everyone wonders why. »

On Mar 20, 2023 at 1:26:23 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse,
>
>> I noticed Grant's issue when I switched to Diablo which does Path
>> matching diagnostics and I noticed this in messages coming from his site:
>>
>> Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
>> blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
>> ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
>> ha.home.tnetconsulting.net!not-for-mail
>
> FWIW, the standardized syntax is "!.MISMATCH.45.33.28.24", in coherence
> with "!.POSTED.alpha.home.tnetconsulting.net". The diagnostic is
> followed with a value.
>
>
>> I had a similar configuration as Grant and told him I was using "pathalias
>> usenet.blueworldhosting.com" with INN.
>>
>> I think this is a good discussion as I think based on stuff I've seen here
>> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.
>
> According to Diablo's changelog:
>
> Diablo V1.12
>
> Added Path: name checking. If the first element of the Path:
> received by an article does not match any 'alias' statements
> for the incoming connection, the IP address is prepended
> to the path: with .MISMATCH appended.
>
>>>> NOTE <<< you should grep through newly created spool> directories
>>>> every so often looking for .MISMATCH in the spool
> files to locate incoming feeds with improperly configured
> 'alias's (in dnewsfeeds). When I turned this feature on,
> I found that four of my 80+ feeds were misconfigured.

So the Diablo syntax is backwards?

Hi Jesse,

> So the Diablo syntax is backwards?
For the "!45.33.28.24.MISMATCH" path diagnostic?
It was implemented before the final version of the RFC standardizing it.
The expected standardized one is "!.MISMATCH.45.33.28.24".

It may be worthwhile fixing it in a patch... If Miquel wishes to add it
to its waiting-to-be-merged list of patches.
I also reported a few years ago that Diablo's answer to LISTGROUP
command was not the right one, but unfortunately there's no longer any
active development for Diablo.

--
Julien ÉLIE

« Avez-vous remarqué qu'à table les mets que l'on vous sert vous mettent
les mots à la bouche ? » (Raymond Devos)

On Mar 20, 2023 at 2:20:06 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse,
>
>> So the Diablo syntax is backwards?
> For the "!45.33.28.24.MISMATCH" path diagnostic?
> It was implemented before the final version of the RFC standardizing it.
> The expected standardized one is "!.MISMATCH.45.33.28.24".
>
> It may be worthwhile fixing it in a patch... If Miquel wishes to add it
> to its waiting-to-be-merged list of patches.
> I also reported a few years ago that Diablo's answer to LISTGROUP
> command was not the right one, but unfortunately there's no longer any
> active development for Diablo.

Given the large number of profitable commercial entities using Diablo, I am
quite certain that development has occurred, but is not being shared with the
rest of us.

Not a developer, but looking at the source, the only place I see any reference
to MISMATCH is here in util/diablo.c:

/*
* check first path element against aliases
* in dnewsfeeds file.
*/
if (PathElmMatches(HLabel, p, bytes, &idx) < 0) {
sprintf(ipfail, "%s.MISMATCH!", PeerIpName);
if (ReportedNoMatch == 0) {
ReportedNoMatch = 1;
logit(LOG_NOTICE, "%-20s Path element fails to
match aliases: %*.*s in %s",
HName, idx, idx, p, msgid);
}
} else {
strcpy(ipfail, "");
}

Hi Jesse,

> Given the large number of profitable commercial entities using Diablo, I am
> quite certain that development has occurred, but is not being shared with the
> rest of us.

:-(

> sprintf(ipfail, "%s.MISMATCH!", PeerIpName);

This line should just be changed to:

sprintf(ipfail, ".MISMATCH.%s!", PeerIpName);

It will then correctly write
"usenet.blueworldhosting.com!.MISMATCH.45.33.28.24!tncsrv06.tnetconsulting.net".

--
Julien ÉLIE

« Aue, aue, aues esse aues ? »

On Mar 20, 2023 at 3:37:07 PM CDT, "Julien ÉLIE"
<iulius@nom-de-mon-site.com.invalid> wrote:

> Hi Jesse,
>
>> Given the large number of profitable commercial entities using Diablo, I am
>> quite certain that development has occurred, but is not being shared with the
>> rest of us.
>
> :-(

It's annoying and a damn shame. I am absolutely in love with the decentralized
architecture of Diablo, and would like to make further use of it via central
article numbering, multiple decentralized spools, etc., but the lack of
information that is easy to find and lack of community to help point me in the
right direction makes it very frustrating.

Once upon a time I stumbled on a great presentation given by someone from a
major provider back in the day, maybe it was XSNews, that had slides showing
their architecture and some configuration tidbits, but I didn't archive it and
can no longer find it. :-(

>> sprintf(ipfail, "%s.MISMATCH!", PeerIpName);
>
> This line should just be changed to:
>
> sprintf(ipfail, ".MISMATCH.%s!", PeerIpName);
>
> It will then correctly write
> "usenet.blueworldhosting.com!.MISMATCH.45.33.28.24!tncsrv06.tnetconsulting.n
> et".

Thanks for confirming. I thought it was that simple, but I'm generally
completely lost in C. I've recompiled and have confirmed the proper format of
the MISMATCH element.

Now if only there were somewhere USEFUL to submit patches. ;-)

On 3/20/23 12:26 PM, Julien ÉLIE wrote:
> Hi Jesse and Grant,

Hi,

> Path: pathcluster!!pathhost!!pathalias!...

Thank you for clarifying that.

> From inn.conf documentation:
>
> pathalias
> The main purpose of this parameter is to configure all news servers
> within a particular organization to add a common identity string to the
> Path header field body.
>
> pathcluster
> The main purpose of this parameter is to make several news servers
> appear as one server.
>
>
> This way, you tell your peers that they should expect "pathcluster" as
> the last and unique name for your outgoing feeds.

Is "pathcluster" a place holder in your statement or are you suggesting
that I use "pathcluster"/

> And "pathalias" is used to add another name in the Path (for instance in
> the case we recently discussed to add a specific server name so that
> articles are not fed to this news server by others).

Since my multiple servers are not pretending to be one server I think I
should use "pathalias". Correct?

> So that the leftmost path entry is unique for all your outgoing feeds.

ACK

--
Grant. . . .
unix || die

On Mar 20, 2023 at 4:18:51 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

> On 3/20/23 12:26 PM, Julien ÉLIE wrote:
>> Hi Jesse and Grant,
>
> Hi,
>
>> Path: pathcluster!!pathhost!!pathalias!...
>
> Thank you for clarifying that.
>
>> From inn.conf documentation:
>>
>> pathalias
>> The main purpose of this parameter is to configure all news servers
>> within a particular organization to add a common identity string to the
>> Path header field body.
>>
>> pathcluster
>> The main purpose of this parameter is to make several news servers
>> appear as one server.
>>
>>
>> This way, you tell your peers that they should expect "pathcluster" as
>> the last and unique name for your outgoing feeds.
>
> Is "pathcluster" a place holder in your statement or are you suggesting
> that I use "pathcluster"/
>
>> And "pathalias" is used to add another name in the Path (for instance in
>> the case we recently discussed to add a specific server name so that
>> articles are not fed to this news server by others).
>
> Since my multiple servers are not pretending to be one server I think I
> should use "pathalias". Correct?
>
>> So that the leftmost path entry is unique for all your outgoing feeds.
>
> ACK

After reading Julien's explanation, I believe you want to use pathcluster on
your feeder machine so that the "tnetconsulting.net" element is the
first/left-most element in the path when you pass the article to a peer.

On Mar 20, 2023 at 4:27:57 PM CDT, "Jesse Rehmer"
<jesse.rehmer@blueworldhosting.com> wrote:

> On Mar 20, 2023 at 4:18:51 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
> wrote:
>
>> On 3/20/23 12:26 PM, Julien ÉLIE wrote:
>>> Hi Jesse and Grant,
>>
>> Hi,
>>
>>> Path: pathcluster!!pathhost!!pathalias!...
>>
>> Thank you for clarifying that.
>>
>>> From inn.conf documentation:
>>>
>>> pathalias
>>> The main purpose of this parameter is to configure all news servers
>>> within a particular organization to add a common identity string to the
>>> Path header field body.
>>>
>>> pathcluster
>>> The main purpose of this parameter is to make several news servers
>>> appear as one server.
>>>
>>>
>>> This way, you tell your peers that they should expect "pathcluster" as
>>> the last and unique name for your outgoing feeds.
>>
>> Is "pathcluster" a place holder in your statement or are you suggesting
>> that I use "pathcluster"/
>>
>>> And "pathalias" is used to add another name in the Path (for instance in
>>> the case we recently discussed to add a specific server name so that
>>> articles are not fed to this news server by others).
>>
>> Since my multiple servers are not pretending to be one server I think I
>> should use "pathalias". Correct?
>>
>>> So that the leftmost path entry is unique for all your outgoing feeds.
>>
>> ACK
>
> After reading Julien's explanation, I believe you want to use pathcluster on
> your feeder machine so that the "tnetconsulting.net" element is the
> first/left-most element in the path when you pass the article to a peer.

I also fixed my Diablo configuration. The ordering of the '-c' (Common path)
and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had
them in the wrong order, and thus technically causing a MISMATCH from my end.
:-)

Now usenet.blueworldhosting.com should always appear as the final Path element
when handing articles to peers.

Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!

Hi Jesse,

> I also fixed my Diablo configuration. The ordering of the '-c' (Common path)
> and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had
> them in the wrong order

I am reassured that INN isn't the only news server with trapdoors in its
configuration :-)

> Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!

It will normally be in the 2.7.2 release; we do not necessarily need a
major release for this change. Not before the end of this year though.

Meanwhile, if you have any suggestions, here is what I had in mind.
A new "pathmatch" parameter in incoming.conf expects a wildmat pattern
and has no default value.
If the leftmost path identity of an incoming article from a peer matches
the pattern value of that parameter (in incoming.conf) when set or, when
unset, equals the label of the peer, then a double "!!" will be
prepended to the Path header field to show it has been successfully
verified.
If the leftmost path identity does not match the pattern, when set,
"!.MISMATCH." is prepended along with the peer IP, and a notice log is
written to say there's a path mismatch (the log is written only once
*per connection* from the peer, and will be reported in Usenet daily
reports as unknown lines near the beginning of the report).

In all other cases, "!.SEEN." with the peer IP is added, without any
notice log.

There's a special case to deal with: articles coming from a local Unix
domain socket (like connections to innd by rnews or nnrpd). I would
suggest "!.SEEN.localhost" for them (except of course when the path
identity corresponds to nnrpd's "!.POSTED", in which case we do not add
a path diagnostic).
I don't think "!!" or "!.MISMATCH." is suitable for these articles as
the path identity may be different than the real one of the remote peer,
and I do not see any way to ensure that (when processing rnews batches
coming from an external source, UUCP, etc. we no longer know the source).

This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. It will therefore not
surprise him, and won't introduce spurious "!.MISMATCH." in the wild.

I would also suggest a new "pathdiag" parameter, set to true by default,
that can be used at global scope and also per peer, to disable the
feature. Maybe a "pathdomainsocketdiag" parameter would also be useful
to configure the same thing for local Unix domain sockets (they do not
have a peer configuration in incoming.conf).

Any thoughts about that or other suggestions?

--
Julien ÉLIE

« Il n'y a que le premier pas qui coûte. » (Mme du Deffand)

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

> Hi Jesse,
>
>> I also fixed my Diablo configuration. The ordering of the '-c' (Common path)
>> and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had
>> them in the wrong order
>
> I am reassured that INN isn't the only news server with trapdoors in its
> configuration :-)

Don't adopt Diablo. ;-)

>
>> Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!
>
> It will normally be in the 2.7.2 release; we do not necessarily need a
> major release for this change. Not before the end of this year though.

Gotcha, I thought I had read somewhere that the path diagnostic wasn't going
to be until 2.8.0.

> Meanwhile, if you have any suggestions, here is what I had in mind.
> A new "pathmatch" parameter in incoming.conf expects a wildmat pattern
> and has no default value.
> If the leftmost path identity of an incoming article from a peer matches
> the pattern value of that parameter (in incoming.conf) when set or, when
> unset, equals the label of the peer, then a double "!!" will be
> prepended to the Path header field to show it has been successfully
> verified.
> If the leftmost path identity does not match the pattern, when set,
> "!.MISMATCH." is prepended along with the peer IP, and a notice log is
> written to say there's a path mismatch (the log is written only once
> *per connection* from the peer, and will be reported in Usenet daily
> reports as unknown lines near the beginning of the report).

This is more or less equivalent to the behavior of Diablo's "alias" parameter
in dnewsfeeds that accepts wildmat patterns, though it doesn't implement the
verified !! portion.

> In all other cases, "!.SEEN." with the peer IP is added, without any
> notice log.

Can you explain further what "other cases" this would be applicable to?

> There's a special case to deal with: articles coming from a local Unix
> domain socket (like connections to innd by rnews or nnrpd). I would
> suggest "!.SEEN.localhost" for them (except of course when the path
> identity corresponds to nnrpd's "!.POSTED", in which case we do not add
> a path diagnostic).
> I don't think "!!" or "!.MISMATCH." is suitable for these articles as
> the path identity may be different than the real one of the remote peer,
> and I do not see any way to ensure that (when processing rnews batches
> coming from an external source, UUCP, etc. we no longer know the source).

I'd have to really think more about this, but can see where this might get a
little ugly.

> This proposal permits not generating a "!.MISMATCH." if the admin does
> not set an explicit "pathmatch" entry for a peer. It will therefore not
> surprise him, and won't introduce spurious "!.MISMATCH." in the wild.

Nothing that I'm aware of rejects based on MISMATCH at this time, so would it
be so bad to have the behavior on by default as is with Diablo? Might
encourage more operators to properly tweak their configurations.

I can see both sides, but have no opinionated weight to throw in either
direction besides the statement above.

> I would also suggest a new "pathdiag" parameter, set to true by default,
> that can be used at global scope and also per peer, to disable the
> feature. Maybe a "pathdomainsocketdiag" parameter would also be useful
> to configure the same thing for local Unix domain sockets (they do not
> have a peer configuration in incoming.conf).
>
> Any thoughts about that or other suggestions?

Sounds reasonable. If pathdiag is enabled by default and you do not add any
pathmatch statements to incoming.conf, is the behavior for path
diagnostic/matching basically the same as it is now?

On 3/20/23 3:27 PM, Jesse Rehmer wrote:
> After reading Julien's explanation, I believe you want to use
> pathcluster on your feeder machine so that the "tnetconsulting.net"
> element is the first/left-most element in the path when you pass the
> article to a peer.

I'm unconvinced.

On 3/20/23 12:26 PM, Julien ÉLIE wrote:
> pathalias
> The main purpose of this parameter is to configure all news servers
> within a particular organization to add a common identity string to
> the Path header field body.

This sounds like what I was intending to do by having peers use
tnetconsulting.net in their excludes in their newsfeeds file.

> pathcluster
> The main purpose of this parameter is to make several news servers
> appear as one server.

My two servers are decidedly different and in no way or shape trying to
appear as one (logical) server.

The more reading that I do, the more that I think I want a pathalias set
to tnetconsulting.net.

This makes me think that articles from my servers would be something
like the following:

Path:
....:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsulting.net:...

I would then continue asking peers to exclude :tnetconsulting.net: from
their feeds to me.

--
Grant. . . .
unix || die

On 3/20/23 12:26 PM, Julien ÉLIE wrote:
> Hi Jesse and Grant,

Hi Julien,

> Path: pathcluster!!pathhost!!pathalias!...

For my mental sanity I'm going to find & replace some terms:

pathcluster = logical-cluster
pathhost = physical-host
pathalias = organization

Thus the Path: header would (or could) look like this:

Path: ...:logical-cluster:physical-host:organization:...

I can see value in excluding articles for a logical-cluster in a feed to
any machine in that logical-cluster. But don't necessarily exclude
based on physical-host or even organization. -- There could be cases
where different logical-clusters within the organization would want
articles from other clusters in the organization; e.g. if the
logical-clusters are in geographically diverse locations and don't
interconnect with each other; then logical-cluster1 would (potentially)
want articles from logical-cluster2 made up of different physical-hosts
in the same organization.

> From inn.conf documentation:
>
> pathalias
> The main purpose of this parameter is to configure all news servers
> within a particular organization to add a common identity string to the
> Path header field body.
>
> pathcluster
> The main purpose of this parameter is to make several news servers
> appear as one server.

To me there must be a reason for the difference in pathalias and
pathcluster. If not, why would they exist?

I feel like there is some minutia that is /explicitly/ for the
difference between multiple unrelated news servers in an organization
and multiple interrelated news servers in a cluster.

> This way, you tell your peers that they should expect "pathcluster" as
> the last and unique name for your outgoing feeds.

I obviously still have doubts.

--
Grant. . . .
unix || die

On Mar 20, 2023 at 6:15:17 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

> On 3/20/23 3:27 PM, Jesse Rehmer wrote:
>> After reading Julien's explanation, I believe you want to use
>> pathcluster on your feeder machine so that the "tnetconsulting.net"
>> element is the first/left-most element in the path when you pass the
>> article to a peer.
>
> I'm unconvinced.
>
> On 3/20/23 12:26 PM, Julien ÉLIE wrote:
>> pathalias
>> The main purpose of this parameter is to configure all news servers
>> within a particular organization to add a common identity string to
>> the Path header field body.
>
> This sounds like what I was intending to do by having peers use
> tnetconsulting.net in their excludes in their newsfeeds file.
>
>> pathcluster
>> The main purpose of this parameter is to make several news servers
>> appear as one server.
>
> My two servers are decidedly different and in no way or shape trying to
> appear as one (logical) server.
>
> The more reading that I do, the more that I think I want a pathalias set
> to tnetconsulting.net.
>
> This makes me think that articles from my servers would be something
> like the following:
>
> Path:
> ...:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsult
> ing.net:...
>
> I would then continue asking peers to exclude :tnetconsulting.net: from
> their feeds to me.

That is the same MISMATCH I see in your articles today. You want your Path to
look like this:

Path:
tnetconsulting.net!tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.n
et:...

If tncsrv09.home.tnetconsulting.net is our peering server, that's where you
want to set pathcluster.

On Mar 20, 2023 at 6:28:48 PM CDT, "Jesse Rehmer"
<jesse.rehmer@blueworldhosting.com> wrote:

> On Mar 20, 2023 at 6:15:17 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
> wrote:
>
>> On 3/20/23 3:27 PM, Jesse Rehmer wrote:
>>> After reading Julien's explanation, I believe you want to use
>>> pathcluster on your feeder machine so that the "tnetconsulting.net"
>>> element is the first/left-most element in the path when you pass the
>>> article to a peer.
>>
>> I'm unconvinced.
>>
>> On 3/20/23 12:26 PM, Julien ÉLIE wrote:
>>> pathalias
>>> The main purpose of this parameter is to configure all news servers
>>> within a particular organization to add a common identity string to
>>> the Path header field body.
>>
>> This sounds like what I was intending to do by having peers use
>> tnetconsulting.net in their excludes in their newsfeeds file.
>>
>>> pathcluster
>>> The main purpose of this parameter is to make several news servers
>>> appear as one server.
>>
>> My two servers are decidedly different and in no way or shape trying to
>> appear as one (logical) server.
>>
>> The more reading that I do, the more that I think I want a pathalias set
>> to tnetconsulting.net.
>>
>> This makes me think that articles from my servers would be something
>> like the following:
>>
>> Path:
>> ...:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsult
>> ing.net:...
>>
>> I would then continue asking peers to exclude :tnetconsulting.net: from
>> their feeds to me.
>
> That is the same MISMATCH I see in your articles today. You want your Path to
> look like this:
>
> Path:
> tnetconsulting.net!tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.n
> et:...
>
> If tncsrv09.home.tnetconsulting.net is our peering server, that's where you
> want to set pathcluster.

I should have looked at your headers before replying, I see its
tncsrv06.tnetconsulting.net that is your peering box. So that's where you want
pathcluster set to tnetconsulting.

Your current path from my view:

Path:
usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!.MISMATCH.45.
33.28.24!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED
..alpha.home.tnetconsulting.net!not-for-mail

What you'd have if you set pathcluster to tnetconsulting.net on
tncsrv06.tnetconsulting.net is this:

Path:
usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tnetconsultin
g.net!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.al
pha.home.tnetconsulting.net!not-for-mail

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> To me there must be a reason for the difference in pathalias and
> pathcluster. If not, why would they exist?

pathalias is when there's some other Path entry that you want to add to
the Path of every article passing through your servers for some reason,
maybe because you used to have some other Path entry and you have peers
that are configured to not send you articles that have already passed
through that entity and you can't get them to update to your current Path
entry for some reason.

pathcluster is the name that you are using to identify yourself to peers
and the Path entry they should expect to see from you, in the cases where
that doesn't match the main Path entry for this box. (The most common
case where that happens is when you have multiple servers that you want to
present as a "united front" to the outside world and identify as the same
virtual server, but you still want distinct Path entries so those servers
can feed each other.)

Both of these are for somewhat unusual edge cases, so it's hard to explain
briefly the circumstances under which you might use them. pathcluster is
probably the more common case: you have a mess of internal servers with
complicated hostnames and Path entries and whatnot, but you want the
outside world to treat that all as an implementation detail and think of
you as simple, single identity in the Path header. The most common case
for pathalias is when you've changed your Path identity for some reason,
you want that to be your new lead entry, but you have peers hanging on to
an old configuration to determine what articles they send you.

> I feel like there is some minutia that is /explicitly/ for the
> difference between multiple unrelated news servers in an organization
> and multiple interrelated news servers in a cluster.

No, neither of these are for the case of unrelated news servers. If you
have unrelated news servers, just use different Path entries for them and
don't set either pathalias or pathcluster. Both of these settings are
only for *related* servers.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 3/20/23 5:33 PM, Jesse Rehmer wrote:
> I should have looked at your headers before replying, I see its
> tncsrv06.tnetconsulting.net that is your peering box.

Correct.

> So that's where you want pathcluster set to tnetconsulting.

I believe that I want to set /pathalias/ and have you exclude
tnetconsulting.net (the organization).

One of the reasons that I'm stuck on /pathalias/ and /organization/ is
that the server at the name will likely change to something other than
tncsrv06... at some point in the future.

My current understanding is that /if/ 1) I set a /pathalias/
"tnetconsulting.net" and 2) you exclude "tnetconsulting.net", then the
hostname of the actual back end server that you're peering doesn't
matter. I can change it as part of upgrading / replacing the system.

N.B. this is predicated on the software & configuration wanting the
exclude and the pathalias / path / pathcluster to match. -- I'm not
aware of any need to match the exclude / path to the hostname that
you're connecting to / accepting connections from.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> I believe that I want to set /pathalias/ and have you exclude
> tnetconsulting.net (the organization).

This will mean that every message from your server will still be marked as
not matching your true Path identity.

> One of the reasons that I'm stuck on /pathalias/ and /organization/ is
> that the server at the name will likely change to something other than
> tncsrv06... at some point in the future.

If you expect the name of the server to change, you want to use
pathcluster, *not* pathalias. pathalias puts the common name in the wrong
place for Path verification and will then require your peers to update the
expected Path entry when the name of the server changes.

> My current understanding is that /if/ 1) I set a /pathalias/
> "tnetconsulting.net" and 2) you exclude "tnetconsulting.net", then the
> hostname of the actual back end server that you're peering doesn't
> matter.

This is correct for deciding what messages to send you (in that case, both
pathalias and pathcluster are equivalent), but *not* for Path
verification.

> N.B. this is predicated on the software & configuration wanting the
> exclude and the pathalias / path / pathcluster to match. -- I'm not
> aware of any need to match the exclude / path to the hostname that
> you're connecting to / accepting connections from.

Indeed, they do not need to match, that's just the default behavior. For
example, I never configure my news servers that way. I always use
newsfeeds entries like:

example/news.example.org:*:Ap,Tm:innfeed!

(very simplified) so that I have explicit control over what Path entry to
exclude from the feed and have shorter peer names in logs, disk files,
etc.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 3/20/23 7:25 PM, Russ Allbery wrote:
> This is correct for deciding what messages to send you (in that case, both
> pathalias and pathcluster are equivalent), but*not* for Path
> verification.

Okay....

Where can I find out more about how path verification is supposed to
function.

It is becoming evident that I'm thinking about things incorrectly and I
need to read more documentation.

--
Grant. . . .
unix || die