I'm trying to setup the virtualhost option in nnrpd and am not sure I'm doing
things correctly.

The man page states:

> If you set this parameter to true, you must also set either
> pathhost or domain in the relevant access group in readers.conf to
> something different than is set in inn.conf.

So I set virtualhost to true and set pathhost to the desired value, but the
following error is logged and connections are rejected:

Jul 6 13:32:13 spool1 nnrpd[14545]: somehostname.com virtualhost needs domain
parameter (unauthenticated).

My original configuration attempt:

access "authenticated" {
virtualhost: "true"
pathhost: "news.blueworldhosting.com"
newsgroups: "*"
users: "*"
}

I added the domain parameter with the same value as pathhost and that seems to
get the desired effect, but notice in the Path headers it is adding an extra
"!", not sure if that is expected but looks out of place:

> Path: news.blueworldhosting.com!!spool1.usenet.blueworldhosting.com

Should nnrpd be happy with just the "pathhost" parameter as the man page
states, or am I missing something? I fiddled around a bit, but unless I also
set the domain parameter nnrpd wouldn't accept incoming connections.

Does the extra "!" in the Path header have some special meaning, or is this
due to some other misconfiguration on my part?

Thanks,

Jesse

Hi Jesse,

> I'm trying to setup the virtualhost option in nnrpd and am not sure I'm doing
> things correctly.
>
> The man page states:
>
>> If you set this parameter to true, you must also set either
>> pathhost or domain in the relevant access group in readers.conf to
>> something different than is set in inn.conf.
>
> So I set virtualhost to true and set pathhost to the desired value, but the
> following error is logged and connections are rejected:

Many thanks for your report! The documentation of virtualhost is indeed
wrong in the readers.conf man page. It should be:

"""
Set this parameter to true in order to make nnrpd behave as if it is
running on a server with a different name than it actually is. The "domain"
parameter then must also be set either in inn.conf or in the same access
group. All articles displayed to clients will have their Xref header field
bodies altered to appear to be from the server named in "domain", and posted
articles will use that server name in the Message-ID and Injection-Info header
field bodies.

Similarly, the Path header field bodies displayed to clients or in posted
articles will use the value of "domain" (if "pathhost" is not set in the
access group, or has the same value as in inn.conf) or "pathhost" (if
"pathhost" is set in the access group to something different than is set
in inn.conf).

At least one of the "domain" or "pathhost" parameters must be set in the
access group to something different than in inn.conf, otherwise nnrpd will
fail to start.
"""

Is it understandable enough, written this way?

> Should nnrpd be happy with just the "pathhost" parameter as the man page
> states, or am I missing something? I fiddled around a bit, but unless I also
> set the domain parameter nnrpd wouldn't accept incoming connections.

Setting "domain" is mandatory (if not already set in inn.conf).

> I added the domain parameter with the same value as pathhost and that seems to
> get the desired effect, but notice in the Path headers it is adding an extra
> "!", not sure if that is expected but looks out of place:
>
>> Path: news.blueworldhosting.com!!spool1.usenet.blueworldhosting.com
>
> Does the extra "!" in the Path header have some special meaning, or is this
> due to some other misconfiguration on my part?

It's not a misconfiguration. This is normal, and corresponds to the fact that
nnrpd considers as trusted "spool1.usenet.blueworldhosting.com" (a known value).
"!!" is a way to say that the path identity is "verified".
Note that INN does not currently implement that verification (to be done...),
and uses that syntax only in virtualhost!

FWIW, an excerpt of RFC 5537 to show you how the Path header field should
be read:

3.2.2. Path Header Field Example

Here is an example of a Path header field created by following the
rules for injecting and relaying agents.

Path: foo.isp.example!.SEEN.isp.example!foo-news
!.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example
!!old.site.example!barbaz!!baz.isp.example
!.POSTED.dialup123.baz.isp.example!not-for-mail

This article was injected by baz.isp.example as indicated by the
<diag-keyword> "POSTED". The injector has recorded that it received
the article from dialup123.baz.isp.example. "not-for-mail" is a
common <tail-entry>.

The article was relayed to the relaying agent known, at least to
old.site.example, as "barbaz". That relaying agent confirmed to its
satisfaction that "baz.isp.example" was an expected <path-identity>
for the source of the article and therefore used <diag-match> ("!")
for its <path-diagnostic>.

barbaz relayed it to old.site.example, which does not support <diag-
keyword> and therefore used the old "!" delimiter. This indicates
that the identity of "barbaz" was not verified and may have been
forged.

old.site.example relayed it to a news server using the <path-
identity> of bar.isp.example and claiming (by using the "!" <path-
diagnostic>) to have verified that it came from old.site.example.

bar.isp.example relayed it to foo-news, which, not being convinced
that it truly came from bar.isp.example, inserted the <diag-keyword>
"MISMATCH" and then stated that it received the article from the IPv6
address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that
bar.isp.example was not a correct <path-identity> for that source but
simply that the identity did not match the expectations of foo-news.)

foo-news then passed the article to foo.isp.example, which declined
to validate its <path-identity> and instead appended the <diag-
keyword> "SEEN" to indicate it knows the source of the article as
isp.example. This may be either an expected <path-identity> or the
FQDN of the system from which it received the article. Presumably,
foo.isp.example is a serving agent that then delivered the article to
a reading agent.

baz.isp.example, bar.isp.example, and foo-news folded the Path header
field.

--
Julien ÉLIE

« C'est la goutte qui fait déborder l'amphore ! » (Assurancetourix)

On Jul 6, 2022 at 6:19:34 PM CDT, "Julien ÉLIE" in
<ta55a6$1bi9i$1@news.trigofacile.com> wrote:

> Is it understandable enough, written this way?

Yes, more thorough, and gives explanation around the use of pathhost vs
domain.

> Setting "domain" is mandatory (if not already set in inn.conf).

Makes sense based on the additional explanation. I don't set "domain" in
inn.conf, and didn't quite understand how it was used in the virtualhost
context, but the updated explanation makes it clear.

> It's not a misconfiguration. This is normal, and corresponds to the fact that
> nnrpd considers as trusted "spool1.usenet.blueworldhosting.com" (a known
> value).
> "!!" is a way to say that the path identity is "verified".
> Note that INN does not currently implement that verification (to be done...),
> and uses that syntax only in virtualhost!
>
>
> FWIW, an excerpt of RFC 5537 to show you how the Path header field should
> be read:

Thank you for providing this detail. I was unaware of the
concept/implementation of verified path identities. I have an unreasonable
obsession with looking at Path headers and don't believe I've seen it used in
the wild. Does any NNTP software implement verification of Path identities?
AFAIK Diablo does not, and I would be shocked if Cyclone does (or perhaps it
does but no one uses it). The only documentation I've found for Cyclone was
extremely dated, so I have no idea how they implement most standards, but can
only observe the oddities exhibited by peers using Cyclone.

Regards,

Jesse

Hi Jesse,

>> Setting "domain" is mandatory (if not already set in inn.conf).
>
> Makes sense based on the additional explanation. I don't set "domain" in
> inn.conf, and didn't quite understand how it was used in the virtualhost
> context, but the updated explanation makes it clear.

I'm glad the explanation is satisfactory.

I've also noticed the that the "-I" flag given to nnrpd serves only when
virtualhost is set. I'll add that mention in the man page of nnrpd.
Basically, if you run "nnrpd -I MyCustomString", nnrpd will for instance
propose <ta55a6$1bi9i$1MyCustomString@news.trigofacile.com> as a
Message-ID in POST commands.

Also, Xref is altered not only in articles but also in overview data
(OVER, HDR, XPAT commands). I'll mention it.

I believe the whole behaviour of virtualhost is now described.
Thanks again for having started that discussion!

May I ask your rationale to use virtualhost? It could be interesting to
add use cases for it in the documentation.
Is it because you are running several instances of nnrpd on different
servers and you want them to appear with the same name for news readers?

>> "!!" is a way to say that the path identity is "verified".
>
> Thank you for providing this detail. I was unaware of the
> concept/implementation of verified path identities. I have an unreasonable
> obsession with looking at Path headers and don't believe I've seen it used in
> the wild. Does any NNTP software implement verification of Path identities?

I'm not aware of such NNTP software. Which does not mean there aren't
any that implemented it!

--
Julien ÉLIE

« Inside every large problem is a small problem struggling to get out. »

On Jul 7, 2022 at 12:28:27 PM CDT, "Julien ÉLIE" in
<ta753r$1d26d$1@news.trigofacile.com> wrote:

> May I ask your rationale to use virtualhost? It could be interesting to
> add use cases for it in the documentation.
> Is it because you are running several instances of nnrpd on different
> servers and you want them to appear with the same name for news readers?

I'm planning for things I want to tinker with in the future. What I will
likely end up with is something like this:

[feeder1] ------>| |--> [spool1]
| --> [xref generator] --> |
[feeder2] ------>| |--> [spool2]

Both spools will be similar, but one will be filtered with pyClean and the
other unfiltered, and perhaps a third just for binaries. This is just a
playground for me, but primarily using the virtualhost to have a single post
identity in the path (which I know can be also accomplished with
pathcluster/pathalias), and to have Xref/Path headers display (mostly)
uniformly between the spools.

I would love to resurrect NNTPSwitch to sit in front of this environment to
have a singular NNRP endpoint that can pull from multiple (dissimilar) spools
based on the group and/or authenticated username without the user knowing, but
I don't have the skills and will take some convincing of friends to help me
get the code able to compile on a modern OS.

Hi Jesse,

>> May I ask your rationale to use virtualhost? It could be interesting to
>> add use cases for it in the documentation.
>> Is it because you are running several instances of nnrpd on different
>> servers and you want them to appear with the same name for news readers?
>
> I'm planning for things I want to tinker with in the future. What I will
> likely end up with is something like this:
>
> [feeder1] ------>| |--> [spool1]
> | --> [xref generator] --> |
> [feeder2] ------>| |--> [spool2]
>
> Both spools will be similar, but one will be filtered with pyClean and the
> other unfiltered, and perhaps a third just for binaries. This is just a
> playground for me, but primarily using the virtualhost to have a single post
> identity in the path (which I know can be also accomplished with
> pathcluster/pathalias), and to have Xref/Path headers display (mostly)
> uniformly between the spools.

Thanks for your answer. An interesting project!

> I would love to resurrect NNTPSwitch to sit in front of this environment to
> have a singular NNRP endpoint that can pull from multiple (dissimilar) spools
> based on the group and/or authenticated username without the user knowing, but
> I don't have the skills and will take some convincing of friends to help me
> get the code able to compile on a modern OS.

I hope you'll manage to.
Have fun :-)

--
Julien ÉLIE

« Le carré est un triangle qui a réussi, ou une circonférence qui a mal
tourné. » (Pierre Dac)