• INN 2.x FAQ

    From harry@21:1/5 to All on Sun Aug 8 15:24:30 2021
    Thanks, Russ.
    Spent all day looking for this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sat Jan 22 12:01:52 2022
    Hi all,

    Following recent discussions here, I've added a reference to the news.admin.peering newsgroup in the FAQ:


    6. How Do I...
    6.14. Find external feeds and set up peering >
    You can ask for an external feed in the news.admin.peering newsgroup.
    Several news administrators will certainly respond and gracefully provide
    you with a news feed. And why not keep subscribed to this newsgroup to
    help others find a news feed once you get yours?

    You then have to parameter the NNTP feed in incoming.conf, newsfeeds and innfeed.conf (assuming you'll use innfeed, the most common way to feed articles). Follow the examples in the man pages of these configuration files.


    Do not hesitate to make suggestions of new questions (with the
    appropriate answer if you already know it) or additions to existing answers.

    --
    Julien ÉLIE

    « Moi, je n'ai pas goûté le sel de cette plaisanterie. » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Russ Allbery on Thu Jul 14 10:38:29 2022
    Russ Allbery wrote:

    Subject: 6.14. Find external feeds and set up peering

    After the discussion in group news.admin.peering, it became clear
    that chapter 6.14 of the INN 2.x FAQ need to be updated with the
    following conditions:

    * administrator must have an account on "reliable email service" [1];
    * administrator should assist the third party in achieving
    commercial interests [2].

    It probably makes sense to write a definition of "reliable email
    service" and list them.

    References:
    1. Message-ID: <tamep7$2r8ph$1@news.mixmin.net>
    2. Message-ID: <tamtot$12n$1@txtcon.i2p>
    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Miner on Thu Jul 14 07:45:59 2022
    Miner <invalid@invalid.invalid> writes:

    After the discussion in group news.admin.peering, it became clear that chapter 6.14 of the INN 2.x FAQ need to be updated with the following conditions:

    * administrator must have an account on "reliable email service" [1];
    * administrator should assist the third party in achieving
    commercial interests [2].

    It probably makes sense to write a definition of "reliable email
    service" and list them.

    Some people may have those requirements, some people may not. I don't
    think the INN FAQ is the place to get into specifics about what peering policies other people may have.

    I certainly completely disagree with the second point and that is not part
    of any peering policy that I have (if anything, the exact opposite; I
    generally don't peer with commercial sites).

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Russ Allbery on Thu Jul 14 10:52:37 2022
    On 7/14/22 8:45 AM, Russ Allbery wrote:
    Some people may have those requirements, some people may not.

    I'll copy & paste a comment I made about this in the news.admin.peering newsgroup.

    I consider the desire ~> requirement for valid email address as one of
    network operations. As in server administrators need a reliable way to
    get a hold of each other to communicate about repairing the network when
    the network is down. Or out of bands if you will.

    I don't think the INN FAQ is the place to get into specifics about
    what peering policies other people may have.

    I think that it's probably worth while for one of the INN documents, if
    not the FAQ, to mention what is likely needed to establish peering
    connections.

    Lest we end up with documentation on how to stand up a server that's an
    island with no information on how to build bridges to / from that island.

    I think /not/ having /some/ information on this is a disservice to new
    news masters.

    I certainly completely disagree with the second point and that is
    not part of any peering policy that I have (if anything, the exact
    opposite; I generally don't peer with commercial sites).

    I wonder if that's old verbiage meant to discourage de-peering with a
    peer in the event that a previously non-commercial peer tries to turn commercial. I feel like the spirit of RFC "SHOULD" / "SHOULDN'T" vs
    "MUST" / "CAN'T" comes to mind.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.K.@21:1/5 to All on Thu Jul 14 11:52:41 2022
    On 7/14/22 05:38, Miner wrote:

    <snip>

    It appears you may be interested in Bitmessage. It is similar to having
    usenet and mixmaster rolled into one.

    https://bitmessage.org

    Bitmessage is a anonymous, peer-to-peer messaging protocol that allows
    for public and private chans and direct private messages. Chans are
    similar to newsgroups. It is completely decentralized and totally
    uncensorable. It has support for Tor and Tor hidden services built-in.

    Additionally, Bitmessage supports broadcasts and decentralized mailing
    lists.

    Messages are encrypted and signed with the algorithms used by Bitcoin.
    It also employs dandelion mix routing for privacy. A QT interface is
    available with the standard reference implementation.

    --

    G.K.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Grant Taylor on Thu Jul 14 10:26:03 2022
    Grant Taylor <gtaylor@tnetconsulting.net> writes:

    I think that it's probably worth while for one of the INN documents, if
    not the FAQ, to mention what is likely needed to establish peering connections.

    I think this would fall into a similar category as the separate hierarchy administration FAQ that I maintain (badly, or at least slowly). It's a
    bit outside the scope of INN as a piece of software, which is perfectly
    happy to be used to exchange news among a private set of peers who
    communicate only via carrier pigeon.

    The nice thing about a general FAQ on being a good public Usenet news
    admin is that anyone can write it and maintain it and it doesn't need to
    be tied to a specific piece of news software. :)

    I think /not/ having /some/ information on this is a disservice to new
    news masters.

    I would be happy to review and offer suggestions on any document you chose
    to start!

    I get the impression that the original message was mostly a continuation
    of some argument in news.admin.peering by other means, though, which to me
    is another reason for the INN FAQ to stay out of it.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to G.K. on Thu Jul 14 18:36:44 2022
    G.K. wrote:

    On 7/14/22 05:38, Miner wrote:

    <snip>

    It appears you may be interested in Bitmessage. It is similar
    to having usenet and mixmaster rolled into one.

    Bitmessage causes an little justified load on CPU. Gretta Tunberg
    probably denounces this. :-)

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Miner on Fri Jul 15 06:02:15 2022
    Get new additions to the FAQ.

    Before asking for a peering:
    * administrator must register the domain and probably should pay
    for it [3];
    * administrator should set up and run the MTA [4];

    References:
    3. Message-ID: <taq3dh$34539$1@news.mixmin.net>
    4. Message-ID: <tapl1i$3369a$1@news.mixmin.net>

    Miner wrote:

    Russ Allbery wrote:

    Subject: 6.14. Find external feeds and set up peering

    After the discussion in group news.admin.peering, it became clear
    that chapter 6.14 of the INN 2.x FAQ need to be updated with the
    following conditions:

    * administrator must have an account on "reliable email service" [1];
    * administrator should assist the third party in achieving
    commercial interests [2].

    It probably makes sense to write a definition of "reliable email
    service" and list them.

    References:
    1. Message-ID: <tamep7$2r8ph$1@news.mixmin.net>
    2. Message-ID: <tamtot$12n$1@txtcon.i2p>
    --
    Miner


    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Fri Jul 15 13:06:00 2022
    Thus spake Russ Allbery <eagle@eyrie.org>

    I get the impression that the original message was mostly a continuation
    of some argument in news.admin.peering by other means, though, which to me
    is another reason for the INN FAQ to stay out of it.

    +1

    --
    Too many ingredients in the soup, no room for a spoon http://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matija Nalis@21:1/5 to Ray Banana on Fri Jul 15 13:23:45 2022
    On Fri, 15 Jul 2022 13:06:00 +0200, Ray Banana <rayban@raybanana.net> wrote:
    Thus spake Russ Allbery <eagle@eyrie.org>

    I get the impression that the original message was mostly a continuation
    of some argument in news.admin.peering by other means, though, which to me >> is another reason for the INN FAQ to stay out of it.

    +1

    I agree. Also, many things are implied by common logic and it would be waste of everybody's time to include. e.g.

    - to contact other people, one should have some common agreed medium for contact.
    These days e-mail is usually implied, in times past it was postal adress, in a century it might be facebook account
    or some other horrible distopian stuff.
    - in order to peer over network, one needs functional network connectivity of some kind
    - to edit config files, one should know how to use some available editor, etc.

    There is absolutely no need to specify those in *INN* FAQ. Perhaps is some "computing 101" FAQ...

    --
    Opinions above are GNU-copylefted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Matija Nalis on Fri Jul 15 13:50:49 2022
    Matija Nalis wrote:

    On Fri, 15 Jul 2022 13:06:00 +0200, Ray Banana <rayban@raybanana.net> wrote:
    Thus spake Russ Allbery <eagle@eyrie.org>

    I get the impression that the original message was mostly a
    continuation of some argument in news.admin.peering by other
    means, though, which to me is another reason for the INN FAQ
    to stay out of it.

    +1

    I agree. Also, many things are implied by common logic and it
    would be waste of everybody's time to include. e.g.

    Administrator must have comprehensive information before setting
    up the service. Lack of information turns into wasted time.

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Matija Nalis on Fri Jul 15 12:04:20 2022
    On 7/15/22 5:23 AM, Matija Nalis wrote:
    I agree. Also, many things are implied by common logic and it would
    be waste of everybody's time to include.

    I disagree.

    1st "common logic" is both regionally and chronologically dependent. It
    used to be common logic that smoking on a plane was okay.

    2nd given the above, I find it's better to clarify things, even if
    believed to be common logic, so that people that are in a different
    region or different time (years later) have a frame of reference from
    the document that no longer exists for them.

    Perhaps some of these things don't need to be /in/ the INN FAQ itself.
    But I do think it would be good to have a pointer in the INN FAQ
    referencing some of these things. E.g.

    Q: What do I do now that my INN server is up and running?
    A: See the Peering FAQ document for more details.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Miner on Fri Jul 15 12:15:35 2022
    On 7/15/22 12:02 AM, Miner wrote:
    Before asking for a peering:
    * administrator must register the domain and probably should pay for it
    [3];

    I can't support "/must/ register a domain name". I see zero problems
    with using a hostname in an existing domain name.

    I can support "/must/ use a /registered/ domain name".

    The difference to me has to do with if a new news master needs to
    register a new domain for their own use or not.

    * administrator should set up and run the MTA [4];

    I question if the news master really /should/ set up and run an MTA. I completely agree that an email address MUST be serviceable. But why
    does there need to be an MTA on news.example.net when example.net
    already has a fully functional MTA stack? What's more is why can't news.example.net use news-example-net@<$FREE_EMAIL_PROVIDER>?

    I agree that using an email address in the same (parent) domain is
    preferred. But I don't think that preference even qualifies as a SHOULD.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Grant Taylor on Fri Jul 15 11:25:28 2022
    Grant Taylor <gtaylor@tnetconsulting.net> writes:

    I can't support "/must/ register a domain name". I see zero problems with using a hostname in an existing domain name.

    I can support "/must/ use a /registered/ domain name".

    The difference to me has to do with if a new news master needs to register
    a new domain for their own use or not.

    I feel like this thread is assuming the very specific and narrow context
    of wanting to peer with other random people one doesn't already know, on
    the public Internet or on some privacy-preserving overlay of it, carrying generally-distributed Usenet groups. In other words, that's a news.admin.peering FAQ addressing the specific social context of that
    group, but not really taking into account the broader news.software.nntp
    world.

    Nothing wrong with that! But this is why I don't think the INN FAQ is the place for it apart from a pointer (which I'd be happy to add once such a document existed).

    Just to say this for the record: none of INN nor news.software.nntp nor
    netnews are limited to this configuration. It works with IP addresses
    with no DNS. It works on private networks. INN can provide stand-alone service for entirely private groups. Netnews as a protocol is a much
    bigger world than public peering of Usenet groups.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Grant Taylor on Fri Jul 15 20:12:42 2022
    Grant Taylor wrote:

    On 7/15/22 12:02 AM, Miner wrote:
    Before asking for a peering:
    * administrator must register the domain and probably should pay for it [3];

    The difference to me
    No difference for me. I have no domain.

    * administrator should set up and run the MTA [4];
    But why
    Discuss details with Ishmel.

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Russ Allbery on Fri Jul 15 13:44:37 2022
    On 7/15/22 12:25 PM, Russ Allbery wrote:
    ...

    ACKs all around and well said Russ.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Miner on Fri Jul 15 14:29:39 2022
    On 7/15/22 2:12 PM, Miner wrote:
    Discuss details with Ishmel.

    Who and where?

    I don't see Ishmel listed as a sender in this thread.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Russ Allbery on Sat Jul 16 11:40:25 2022
    Russ Allbery wrote:

    In other words, that's a news.admin.peering FAQ addressing the
    specific social context of that group, but not really taking
    into account the broader news.software.nntp world.

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been posted in
    the past few months.
    2. INN 2.x FAQ does not cover an important aspect of usage. The
    lack of complete information caused a waste of time.

    Therefore, the inaction of the author of the INN 2.x FAQ from now
    on can be regarded as disinformation. Probably with the aim of
    making attractive a little popular software product or, in other
    words, fossil of ancient times.

    INN can provide stand-alone service for entirely private
    groups.

    I have never seen usage in this way. Companies and organizations
    prefer other solutions.
    Norton Commander also provide something. However, no one is using
    it.

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Grant Taylor on Sat Jul 16 12:02:26 2022
    Grant Taylor wrote:

    On 7/15/22 2:12 PM, Miner wrote:
    Discuss details with Ishmel.

    Who and where?
    I don't see Ishmel listed as a sender in this thread.

    I noticed you're abusing [skip] often. There was references on
    Message-ID.

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ishmel Rowe Dent@21:1/5 to Grant Taylor on Sat Jul 16 06:19:19 2022
    On 7/15/22 13:04, Grant Taylor wrote:
    It used to be common logic that smoking on a plane was okay.

    Prude.

    --

    Ishmel Rowe Dent

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ishmel Rowe Dent@21:1/5 to Miner on Sat Jul 16 09:47:32 2022
    On 7/16/22 06:40, Miner wrote:
    Russ Allbery wrote:

    <snip>

    INN can provide stand-alone service for entirely private
    groups.

    I have never seen usage in this way. Companies and organizations
    prefer other solutions.

    YGBSM. You can't seem to set up a peering without a mountain of friction
    and now you're pretending to be an expert on Usenet software proliferation.

    I am subscribed to several private NNTP servers that don't peer with
    Usenet. There are thousands of private NNTP servers in active use
    world-wide. Nobody acts as toxic as you on any of the servers I
    subscribe to, and many of them are using opsec to hide their identities.
    If they want to peer, they know that email and domain name is standard.

    There are many such servers. There are also special-purpose NNTP feed forwarding servers such as gmane.io and gwene.io that don't peer with
    the larger Usenet hierarchies. You're just a crank troll and you've
    proven it repeatedly. I smell rodent.

    STFU and peer with someone by giving them a email address and domain
    name, or just go away and run a private server and be happy in your
    anonymous pedo-pirate-carder-tweaker-opsec bubble. I think you are a
    crank and your wank disgusts me.

    Really dude, it's time to stop this nonsense and grow up. Your trolling
    smells of Kerman the German wank.

    --

    Ishmel Rowe Dent

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Miner on Sat Jul 16 10:32:56 2022
    Miner <invalid@invalid.invalid> writes:

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been posted in
    the past few months.
    2. INN 2.x FAQ does not cover an important aspect of usage. The
    lack of complete information caused a waste of time.

    Therefore, the inaction of the author of the INN 2.x FAQ from now
    on can be regarded as disinformation. Probably with the aim of
    making attractive a little popular software product or, in other
    words, fossil of ancient times.

    Oh, you're adorable. It's been about twenty years since this sort of
    thing has worked on me, but nice try! A very honest attempt to capture
    the spirit of 1990s Usenet.

    This fossil of ancient times has learned one of the lessons that fossils
    learn, which is that if you're doing something as a hobby, you should do
    it however makes you happy and not care too much about what anyone else
    thinks about what you're doing. Life is too short to argue about your
    hobbies. If someone doesn't like what you're doing, they can go do
    something else.

    INN can provide stand-alone service for entirely private groups.

    I have never seen usage in this way.

    Yes, I'm not surprised. Nonetheless, if you pay attention, people talk
    about it from time to time in this very group.

    Like all uses of INN and Usenet in general, it's gone down over time as
    people have mostly switched to other protocols and other software stacks.

    Companies and organizations prefer other solutions. Norton Commander
    also provide something. However, no one is using it.

    I hate to break this to you, but "no one is using it" is true about Usenet
    and netnews *in general*. We are a very small backwater with a very
    obscure hobby.

    And not only is that fine, it's often a nice place to be. We're part of
    the world's diversity. It would be boring and oppressive if everyone was
    using the popular thing.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Ishmel Rowe Dent on Sat Jul 16 17:24:01 2022
    Ishmel Rowe Dent wrote:

    On 7/16/22 06:40, Miner wrote:
    Russ Allbery wrote:

    <snip>

    INN can provide stand-alone service for entirely private
    groups.

    I have never seen usage in this way. Companies and
    organizations prefer other solutions.

    YGBSM. You can't seem to set up a peering without a mountain of
    friction and now you're pretending to be an expert on Usenet
    software proliferation.

    Instead of commenting the facts, you generate unclaimed thoughts
    in abundance.

    As it became known, the peering requires many conditions. The
    conditions remained unknown at the stage of setting up the
    service. This was the result of misinformation (or is it better
    to say disinformation?) in the FAQ. Now let me improve FAQ. No
    thanks needed.

    I am subscribed to several private NNTP servers that don't peer
    with Usenet. There are thousands of private NNTP servers in
    active use world-wide. Nobody acts as toxic as you on any of
    the servers I subscribe to, and many of them

    I announced the InterNetNews to potential users. They called the
    InterNetNews "petrified shit of mammoth". For the common good
    ongoing testing of its toxicity. :-)

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Russ Allbery on Sat Jul 16 20:08:01 2022
    Russ Allbery wrote:

    Miner <invalid@invalid.invalid> writes:

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been
    posted in the past few months.
    2. INN 2.x FAQ does not cover an important aspect of usage.
    The lack of complete information caused a waste of time.

    Therefore, the inaction of the author of the INN 2.x FAQ from
    now on can be regarded as disinformation. Probably with the
    aim of making attractive a little popular software product
    or, in other words, fossil of ancient times.

    This fossil of ancient times has learned one of the lessons
    that fossils learn, which is that if you're doing something as
    a hobby, you should do it however makes you happy and not care
    too much about what anyone else thinks about what you're doing.
    Life is too short to argue about your hobbies. If someone
    doesn't like what you're doing, they can go do something else.

    I can't be happy when the result of my efforts is very different
    from the expected. My expectations were based on the content of
    the FAQ.

    INN can provide stand-alone service for entirely private groups.

    I have never seen usage in this way.

    Yes, I'm not surprised. Nonetheless, if you pay attention,
    people talk about it from time to time in this very group.

    Like all uses of INN and Usenet in general, it's gone down over
    time as people have mostly switched to other protocols and
    other software stacks.

    There is reason to think about the cause of this phenomenon. The
    conceptual advantages of the Usenet are undeniable.

    Companies and organizations prefer other solutions. Norton
    Commander also provide something. However, no one is using
    it.

    I hate to break this to you, but "no one is using it" is true
    about Usenet and netnews *in general*. We are a very small
    backwater with a very obscure hobby.

    Degradation is often the result of error. It remains to find the
    error and fix before it's too late.

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Miner on Sat Jul 16 15:14:28 2022
    Miner <invalid@invalid.invalid> writes:

    I can't be happy when the result of my efforts is very different from
    the expected. My expectations were based on the content of the FAQ.

    You've got a point that the answer to that question expressed rather more certainty about getting a feed than may be warranted. I've reworded it a
    bit:

    One way to find peers is to ask for an external feed in the
    news.admin.peering newsgroup. Some news administrators read that
    group and may be willing to peer. It's common for news administrators
    to have different criteria for peering (specific hierarchies,
    geographic or network proximity, spam filtering, no binaries,
    binaries, specific network protocols; the variation is endless), so
    finding someone with matching goals may require some patience and
    possibly some configuration changes. And why not keep subscribed to
    this newsgroup to help others find a news feed once you get yours?

    There is reason to think about the cause of this phenomenon. The
    conceptual advantages of the Usenet are undeniable.

    Usenet has an incredibly clunky, awkward, and insecure mechanism for moderation, which is a fatal flaw at any level of popularity much higher
    than its current level and which (combined with the constant problem of
    finding enough people to do the moderation) is a lot of the reason why
    Usenet only has its current level of popularity. General-distribution newsgroups only survive the lack of moderation tools because this is a
    niche hobby with a tiny community, which means it's relatively rare that someone will actively try to break it for everyone else.

    Back when it was far more popular, other people routinely tried to break
    it for everyone else and, due to the inherent insecurities in the
    protocol, mostly succeeded.

    Even with that small community, there is absolutely no way that I would
    legally risk running a Usenet server that accepted binaries given the
    utter lack of tools or support for keeping child sexual abuse material off
    of Usenet. Other people obviously make different decisions and, well,
    good luck to them, I guess.

    Degradation is often the result of error. It remains to find the error
    and fix before it's too late.

    Have fun! I'm just going to be over here doing my thing. :)

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sun Jul 17 00:23:51 2022
    Hi Russ,

    You've got a point that the answer to that question expressed rather more certainty about getting a feed than may be warranted.

    Yup, agreed, my mistake. Re-reading the previous wording, I indeed was
    too much optimistic; of course nothing is ever guaranteed.


    I've reworded it a bit

    You did well, thanks.
    You proved not to be a fossil :-)

    Both you and Grant have always proven to be reliable, pro-active and
    helpful to others!

    --
    Julien ÉLIE

    « C'est comme chercher une aiguille dans du foin en bottes ! »
    (Jolitorax)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Miner on Sat Jul 16 17:37:59 2022
    On 7/16/22 6:02 AM, Miner wrote:
    I noticed you're abusing [skip] often. There was references on
    Message-ID.

    I think the messages that you're referring to didn't make it to my news
    server.

    I now see only two messages from Ishmel on this thread.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sn!pe@21:1/5 to Grant Taylor on Sun Jul 17 00:57:30 2022
    Grant Taylor <gtaylor@tnetconsulting.net> wrote:

    On 7/16/22 6:02 AM, Miner wrote:
    I noticed you're abusing [skip] often. There was references on
    Message-ID.

    I think the messages that you're referring to didn't make it to my news server.

    I now see only two messages from Ishmel on this thread.


    PMFJI. It's the same on E-S.

    [relurk]

    --
    ^^ My pet rock Gordon just is.

    ~ Slava Ukraini ~

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Russ Allbery on Sun Jul 17 09:18:17 2022
    Russ Allbery wrote:

    You've got a point that the answer to that question expressed
    rather more certainty about getting a feed than may be
    warranted. I've reworded it a bit:

    for news administrators to have different criteria for
    peering (specific hierarchies, geographic or network
    proximity, spam filtering, no binaries, binaries, specific
    network protocols; the variation is endless), so finding

    Several criteria are missing: reveal a information (what
    exactly?), promoting the commercial interests of a third party,
    having an external IP address, buying a domain, setting up
    additional software.

    String "the variation is endless" need to be updated with
    "including the insane".

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Miner on Mon Jul 18 09:41:41 2022
    Miner <invalid@invalid.invalid> writes:
    Russ Allbery wrote:

    You've got a point that the answer to that question expressed
    rather more certainty about getting a feed than may be
    warranted. I've reworded it a bit:

    for news administrators to have different criteria for
    peering (specific hierarchies, geographic or network
    proximity, spam filtering, no binaries, binaries, specific
    network protocols; the variation is endless), so finding

    Several criteria are missing: reveal a information (what
    exactly?), promoting the commercial interests of a third party,
    having an external IP address, buying a domain, setting up
    additional software.

    I would add “don’t be high-maintenance” as a general rule.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Hochstein@21:1/5 to Miner on Mon Jul 18 22:16:19 2022
    Miner schrieb:

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been posted in
    the past few months.

    No problem. Create it, post it. Otherwise you'll cause a waste of time,
    and your inaction could be regarded as disinformation. We wouldn't want
    that, would we?

    -thh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matija Nalis@21:1/5 to Grant Taylor on Tue Jul 19 00:57:17 2022
    On Fri, 15 Jul 2022 12:15:35 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    On 7/15/22 12:02 AM, Miner wrote:
    Before asking for a peering:
    * administrator must register the domain and probably should pay for it

    I can't support "/must/ register a domain name". I see zero problems
    with using a hostname in an existing domain name.

    ... that could probably be simplified as "FQDN", but...

    I can support "/must/ use a /registered/ domain name".

    ... why do you see that as a "MUST", though?
    Which part of news peering *cannot possibly work* without valid public domain name?

    It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD" (or even "MAY", depending).

    I agree that using an email address in the same (parent) domain is
    preferred. But I don't think that preference even qualifies as a SHOULD.

    Why even that? It would be at best "MAY", if it even warrants a mention (it does not, IMHO - it is pointless policy minutia, like requiring that email addresses must always be in form "firstname.lastname@company.tld" or some such)

    --
    Opinions above are GNU-copylefted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matija Nalis@21:1/5 to Grant Taylor on Tue Jul 19 00:38:49 2022
    On Fri, 15 Jul 2022 12:04:20 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    On 7/15/22 5:23 AM, Matija Nalis wrote:
    I agree. Also, many things are implied by common logic and it would
    be waste of everybody's time to include.

    1st "common logic" is both regionally and chronologically dependent. It
    used to be common logic that smoking on a plane was okay.

    And it was okay back then, wasn't it? That is exactly my point.
    Things change, and things are often different in different regions.

    For example, back when I was still admining public news servers, e-mail was not required for peering in this region. Instead, XMPP and IRC were often alternatives, even preferred by some. At least in my region...

    2nd given the above, I find it's better to clarify things, even if
    believed to be common logic, so that people that are in a different
    region or different time (years later) have a frame of reference from
    the document that no longer exists for them.

    Sure. It would probably need to cover lots of regions (and maybe historical information, as it would need to be kept up-to-date), or would need to be very open-ended/vague, lest it possibly lead to more confusion than it solves.
    It is likely much harder than it looks on first sight.

    Even things like language and peering places used differ wildly.
    (e.g. do high percentage of Chinese newsadmins choose to find peers by posting in English on news.admin.peering? Neither did most newsadmins in .hr;
    yet peer they did - and some still do. Not all news servers even carry Big8!)

    While some peering requests on news.admin.peering and elsewhere might gain
    much more traction because they have made popular choices, this does not
    _per se_ invalidate the other (more quirky) peering requests.

    There were several issues raised, none of which IMHO have *definite* answer, only some *recommendations* iff one wants to get more exposure (which is not to be taken as implied, either [1]):

    - "you need to buy a domain / have a working domain name to peer" (not true at all)

    - "you need a working e-mail / MTA to peer" (not true, see above about my experiences
    with other communication methods, as well as recent threads in news.admin.peering,
    I still prefer XMPP to this day for things I care about - it is faster, and things
    tend to actually reach intended recipient much more reliably than e-mail, which is
    IME getting borderline useless these days due to spam and antispam issues).
    It might impact your access to moderated groups, though (in addition to
    getting less potential peers)

    - "you need public IP address to peer" (not true; e.g. I started my peerings via
    UUCP on private SLIP dial-up links back in the day. In fact, *lack* of always-on
    internet connectivity and public IP addresses was main factor of interest in
    setting up my own news server initially. It would still work today, provided you
    find interested peers). There was also interesting discussion of privacy TCP/IP
    layers lately in news.admin.peering, for example.

    - "you must not be commercial news server" (not true either; although it would
    *also reduce* the size of group of peers that are interested in your request - just
    like the other *suggestions* mentioned above)

    - "your peering request must have all of the following information (XXXXX, email, ...)
    and be posted at news.admin.peering" (not true either, see above)

    It would be less problematic if all of "need" / "must" / "should" etc. in such potential FAQ were replaced with "In order to enhance your chances of finding many peers, you might want to consider" (or similar) phrase.


    Perhaps some of these things don't need to be /in/ the INN FAQ itself.
    But I do think it would be good to have a pointer in the INN FAQ
    referencing some of these things. E.g.

    Q: What do I do now that my INN server is up and running?
    A: See the Peering FAQ document for more details.

    I agree it should be _kept out_ of *INN* FAQ, and have said as much.

    Note that "Peering FAQ" would likely only offer help on News peering; while the OP seemed to me to have much wider range of general computing issues.
    That's why I originally suggested:

    There is absolutely no need to specify those in *INN* FAQ. Perhaps is some "computing 101" FAQ...

    [1] e.g. only peering proposal I considered lately was quite esoteric (which is
    why it piqued my interest, in fact).

    --
    Opinions above are GNU-copylefted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Matija Nalis on Mon Jul 18 17:44:28 2022
    On 7/18/22 4:57 PM, Matija Nalis wrote:
    ... that could probably be simplified as "FQDN", but...

    My concern is that FQDNs can be locally / privately resolved.

    I take the spirit of the requirement to be that whatever name is used
    can be externally / publicly resolved.

    ... why do you see that as a "MUST", though?

    I was restating the previous comment with a modification. E.g.

    s#register a#use a /registered/#

    Which part of news peering *cannot possibly work* without valid public
    domain name?

    I agree that it can. I was seeking what I could support, even if I
    thought it was a bit of an over reach.

    It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD"
    (or even "MAY", depending).

    I like should better than must. But I was focusing on a different part
    of the statement.

    Why even that? It would be at best "MAY", if it even warrants
    a mention

    How about refactoring / simplifying from email to an out of band
    communications method that both peers are happy with?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Matija Nalis on Mon Jul 18 17:38:15 2022
    On 7/18/22 4:38 PM, Matija Nalis wrote:
    And it was okay back then, wasn't it? That is exactly my point.
    Things change, and things are often different in different regions.

    I feel like we're talking past each other.

    I'm saying that things should be documented, even if they are common
    logic to some people. Because they may not be common logic to everyone
    now or at some point in the future. Hence the value in documenting what
    is common logic so that there is no doubt in another location or another
    time.

    Said another way, simply writing the common logic removes any ambiguity.

    For example, back when I was still admining public news servers, e-mail
    was not required for peering in this region. Instead, XMPP and IRC were
    often alternatives, even preferred by some. At least in my region...

    That sounds like an example of a good thing to document that was
    probably common knowledge to you / those around you but not as common to others.

    Sure. It would probably need to cover lots of regions (and maybe
    historical information, as it would need to be kept up-to-date),
    or would need to be very open-ended/vague, lest it possibly lead
    to more confusion than it solves. It is likely much harder than it
    looks on first sight.

    I think we're talking about two different things. I'm talking about a
    subset of what I think you are talking about. I'm specifically talking
    about people documenting what they are doing / using / expecting in a
    way that will remove ambiguity for others later.

    A corollary: I've heard / read multiple times / places that scientists
    are unable to build rocket engines using plans from the '70s & '80s,
    despite having full blue prints, /because/ the knowledge of /how/ to do
    some things was lost because it wasn't documented. Either for
    intellectual property / trade secret reasons or simply because everybody thought it was common knowledge, thus they didn't need to document /how/
    they did things. Instead they only documented /what/ they did.

    I hope that makes sense.

    Even things like language and peering places used differ wildly.

    Sure. Hence why providing some background on what some consider to be
    common knowledge will help those that are translating the languages and
    having to deduce things.

    (e.g. do high percentage of Chinese newsadmins choose to find peers by posting in English on news.admin.peering? Neither did most newsadmins
    in .hr; yet peer they did - and some still do. Not all news servers
    even carry Big8!)

    While some peering requests on news.admin.peering and elsewhere might
    gain much more traction because they have made popular choices, this
    does not _per se_ invalidate the other (more quirky) peering requests.

    Agreed.

    It would be less problematic if all of "need" / "must" / "should"
    etc. in such potential FAQ were replaced with "In order to enhance
    your chances of finding many peers, you might want to consider"
    (or similar) phrase.

    I believe that most of the SHOULD / MUST / et al. are borrowing from RFC standards and meanings therein.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matija Nalis@21:1/5 to Grant Taylor on Wed Jul 20 00:27:35 2022
    On Mon, 18 Jul 2022 17:38:15 -0600, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    On 7/18/22 4:38 PM, Matija Nalis wrote:
    Even things like language and peering places used differ wildly.

    Sure. Hence why providing some background on what some consider to be
    common knowledge will help those that are translating the languages and having to deduce things.

    Yes, there I agree with you.
    Documenting current (and even historical) state is good.

    I was more targeting the angle that *extra care* should be taken so that resulting document does not end up being US/EU-English-region-centric
    (or even more narrow: Big8-centric).

    Which it quite probable result, if it would be created by collecting input from Big-8 news.* groups only; even if some of cross-polination of newsadmins from few
    different countries who roam here (mostly western EU and US, it looks to me). Thus my comment about it being hard to document things correctly without introducing such strong bias.

    It would be less problematic if all of "need" / "must" / "should"
    etc. in such potential FAQ were replaced with "In order to enhance
    your chances of finding many peers, you might want to consider"
    (or similar) phrase.

    Ah, I was refering to common conversentional style as was used my own bullet points that were above that paragraph and might end up in such document
    (e.g. "you need public IP address to peer" etc.)

    I believe that most of the SHOULD / MUST / et al. are borrowing from RFC standards and meanings therein.

    Agreed - and they should be in all uppercase then. I doubt there would be much (or any) of MUST, mostly "MAY" and perhaps a few "SHOULD". "NEED" is not BCP14, but is AFAICT common in conversational style used in such documents.

    Which part of news peering *cannot possibly work* without valid public
    domain name?
    It looks to me to be (in RFC2119/BCP14 sense) *at most* "SHOULD"
    (or even "MAY", depending).

    I like should better than must. But I was focusing on a different part
    of the statement.

    Oh, OK then. I was confused by MUST part, as it clearly is not a "MUST".

    Why even that? It would be at best "MAY", if it even warrants a mention

    How about refactoring / simplifying from email to an out of band >communications method that both peers are happy with?

    Yes, that sound like a good idea to me. Few popular examples of such OOB might then be mentioned in parenthesis ("e.g. email or various instant messaging") to give some context to the user, without sounding too prescriptive.


    --
    Opinions above are GNU-copylefted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Thomas Hochstein on Wed Jul 20 09:20:01 2022
    Thomas Hochstein wrote:

    Miner schrieb:

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been
    posted in the past few months.

    No problem. Create it, post it.

    rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1069@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <desd.20220719225404.1070@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1071@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1072@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Newsmaster XeNET@21:1/5 to All on Wed Jul 20 13:26:03 2022
    Am 20.07.2022 um 11:20 schrieb Miner:
    Thomas Hochstein wrote:

    Miner schrieb:

    Just the facts.
    1. News.admin.peering FAQ does not exist or hasn't been
    posted in the past few months.

    No problem. Create it, post it.

    rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1069@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <desd.20220719225404.1070@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1071@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.
    rejecting[*] <dcomm.20220719225404.1072@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.

    KI seems to made great progress the last years. :)

    With best regards
    MM


    --
    Diese E-Mail wurde von AVG auf Viren geprüft.
    http://www.avg.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Hochstein@21:1/5 to Miner on Wed Jul 20 19:52:43 2022
    Miner schrieb:

    Thomas Hochstein wrote:
    Miner schrieb:
    1. News.admin.peering FAQ does not exist or hasn't been
    posted in the past few months.

    No problem. Create it, post it.

    rejecting[*] <defa.20220719213012.1068@scatha.ancalagon.de> 439 [*] Insolent or mentally retarded.

    Yep, that's what I thought.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Miner on Fri Aug 19 09:05:36 2022
    Miner <invalid@invalid.invalid> writes:

    The author of the INN 2.x FAQ Russ Allbery continues to spread disinformation. I express my contempt for all organizers of
    disinformation.

    In case anyone was wondering, this followed apparently the same person
    trying to harass me in direct email about not wording the FAQ answer in
    the way that they'd prefer. I'm not really sure what they expected the
    outcome to be.

    This is not the weirdest hill that I've seen someone try to die on, but it certainly has flashback early 2000s Usenet kook energy.

    Anyway, go write your own FAQ if you don't like this one. I'm not going
    to change it further for your weird obsession.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miner@21:1/5 to Miner on Fri Aug 19 15:21:29 2022
    The author of the INN 2.x FAQ Russ Allbery continues to spread
    disinformation. I express my contempt for all organizers of
    disinformation.

    Miner wrote:

    Russ Allbery wrote:

    You've got a point that the answer to that question expressed
    rather more certainty about getting a feed than may be
    warranted. I've reworded it a bit:

    for news administrators to have different criteria for
    peering (specific hierarchies, geographic or network
    proximity, spam filtering, no binaries, binaries, specific
    network protocols; the variation is endless), so finding

    Several criteria are missing: reveal a information (what
    exactly?), promoting the commercial interests of a third party,
    having an external IP address, buying a domain, setting up
    additional software.

    String "the variation is endless" need to be updated with
    "including the insane".

    --
    Miner

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Hochstein@21:1/5 to Russ Allbery on Sun Aug 21 22:46:58 2022
    Russ Allbery wrote:

    In case anyone was wondering, this followed apparently the same person
    trying to harass me in direct email about not wording the FAQ answer in
    the way that they'd prefer.

    Who would have thought that?

    Anyway, go write your own FAQ if you don't like this one.

    I fear that makes you "Insolent or mentally retarded." ...

    -thh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From seth@home.sethhurst.com@21:1/5 to Thomas Hochstein on Wed Aug 24 07:39:25 2022
    Thomas Hochstein <thh@thh.name> wrote:
    Russ Allbery wrote:

    In case anyone was wondering, this followed apparently the same person
    trying to harass me in direct email about not wording the FAQ answer in
    the way that they'd prefer.

    Who would have thought that?

    Anyway, go write your own FAQ if you don't like this one.

    I fear that makes you "Insolent or mentally retarded." ...

    -thh
    I thought the faq was good so yeah.
    go pound sand.
    Don't let those people get you down.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Tue Feb 21 13:39:17 2023
    Hi all,

    Subject: 6.6. Change the domain used for message IDs

    By default, any message identifier generated by INN will use the fully qualified domain name of the local system for the right-hand side of
    message IDs. In some cases, this isn't desirable for various reasons
    (the server may have an internal name that doesn't make sense on Usenet
    at large, or one may not want to expose the name of the server).

    INN still does not have a dedicated parameter to change the right-hand
    side of message identifiers. While waiting for it, there's a trick
    involving a special use of the domain: parameter (normally meant to be
    use only for what is related to DNS).

    In INN 2.7.1 and later, you can use an explicit domain: key in an access stanza of readers.conf to use its value as the right-hand side of message identifiers. (Even though domain: is set in inn.conf, note that this parameter also needs being present in readers.conf so as to trigger the expected behaviour).

    In INN 2.3.3 and later, you can set virtualhost: to true in an access
    stanza of readers.conf and then set domain: in the same stanza, and all
    posts coming from connections to which that access stanza applies will
    use that domain to generate message IDs. So if you need to change the
    domain used to generate message IDs for every local post from your
    server, just add virtualhost: and domain: keys to every access stanza
    in readers.conf. (Yes, this is really overkill for this option.)

    I hope it will fit users' need in INN 2.7.1 (it is difficult to do
    better without introducing a backwards-incompatible change). The
    dedicated "servername" parameter is scheduled for INN 2.8.0.


    Do not hesitate to ask for additions in the FAQ if you see uncovered
    useful subjects.

    --
    Julien ÉLIE

    « The best preparation for tomorrow is to do today's work superbly
    well. » (William Osler)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rek2 hispagatos@21:1/5 to Russ Allbery on Sat Jul 22 04:43:19 2023
    On 2023-07-21, Russ Allbery <eagle@eyrie.org> wrote:
    Last-modified: 2023-04-17
    Posted-by: postfaq 1.17 (Perl 5.28.1)
    Archive-name: usenet/software/inn2-faq
    URL: https://www.eyrie.org/~eagle/faqs/inn.html
    Posting-frequency: monthly

    This FAQ is intended to answer frequently asked questions concerning the current versions of INN (INN 2.x and later) seen on news.software.nntp.
    It should be referred to in preference to the old INN FAQ, which only documents versions up to 1.7. It mostly covers INN 2.3 and later; earlier


    Thanks for the update!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Wed Dec 27 00:29:07 2023
    Hi all,

    Archive-name: usenet/software/inn2-faq
    URL: https://www.eyrie.org/~eagle/faqs/inn.html

    For the recall, contributions are welcome to update the document. Do
    not hesitate to send modifications, or new questions to add to the FAQ.

    Nigel also recently asked for more interaction and search features with
    the use of wikis. If people want to contribute to existing wikis or installation guides, do not hesitate to do so likewise!

    http://www.dodin.org/wiki/pmwiki.php?n=Doc.ConfigurerINN-2021

    https://th-h.de/net/usenet/servers/inn/overview/ (in German)


    https://web.archive.org/web/20230901182332/https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html
    (in French, to be revived)



    In the next posting of the FAQ:


    4.4. tradspool: could not open ... File exists

    scanspool will be mentioned as a useful program to run.


    6.7. Use INN without a direct news feed

    pullnews will be referenced as a possible program to use (only suck and
    newsx were mentioned).


    6.14. Find external feeds and set up peering

    A sentence about importing old articles will be added, pointing to the
    manual page of pullnews which explains how to do that, as well as how
    not to propagate these pulled articled to external feeds.

    --
    Julien ÉLIE

    « If you lie to the compiler, it will get its revenge. » (Henry Spencer)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nigel Reed@21:1/5 to iulius@nom-de-mon-site.com.invalid on Wed Dec 27 14:01:37 2023
    On Wed, 27 Dec 2023 00:29:07 +0100
    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

    Hi all,

    Archive-name: usenet/software/inn2-faq
    URL: https://www.eyrie.org/~eagle/faqs/inn.html

    For the recall, contributions are welcome to update the document. Do
    not hesitate to send modifications, or new questions to add to the
    FAQ.

    Nigel also recently asked for more interaction and search features
    with the use of wikis. If people want to contribute to existing
    wikis or installation guides, do not hesitate to do so likewise!

    http://www.dodin.org/wiki/pmwiki.php?n=Doc.ConfigurerINN-2021

    https://th-h.de/net/usenet/servers/inn/overview/ (in German)


    https://web.archive.org/web/20230901182332/https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html
    (in French, to be revived)



    In the next posting of the FAQ:


    4.4. tradspool: could not open ... File exists

    scanspool will be mentioned as a useful program to run.


    6.7. Use INN without a direct news feed

    pullnews will be referenced as a possible program to use (only suck
    and newsx were mentioned).


    6.14. Find external feeds and set up peering

    A sentence about importing old articles will be added, pointing to
    the manual page of pullnews which explains how to do that, as well as
    how not to propagate these pulled articled to external feeds.


    Thanks for the additions. I don't want to appear like a complete noob,
    but I perform operations on the usenet server so rarely that it's not
    something I keep in the front of my mind. I should probably keep better
    notes for myself.

    --
    End Of The Line BBS - Plano, TX
    telnet endofthelinebbs.com 23

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Wed Dec 27 21:25:06 2023
    Hi Nigel,

    Thanks for the additions. I don't want to appear like a complete noob

    Far be it from me to have that thought. There was no offense in my
    article and did not intend to make you feel like that. You already know
    many things about INN and Usenet!

    My message was just to ask for ideas of questions to add to the FAQ or
    more examples in manual pages.


    but I perform operations on the usenet server so rarely that it's not something I keep in the front of my mind.

    That's naturally fine.


    I should probably keep better notes for myself.

    ... or write them into a wiki for other people to take benefit of them.
    Maybe Grant and other people here could even complete with their own
    notes gathered year after year :)

    --
    Julien ÉLIE

    « Quae longo tempore extenuentur corpora, lente reficere oportet. »
    (Hippocrate)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From llp@21:1/5 to All on Wed Dec 27 23:13:22 2023
    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> composa la prose suivante:

    Hi all,

    Archive-name: usenet/software/inn2-faq
    URL: https://www.eyrie.org/~eagle/faqs/inn.html

    For the recall, contributions are welcome to update the document. Do
    not hesitate to send modifications, or new questions to add to the FAQ.

    Nigel also recently asked for more interaction and search features with
    the use of wikis. If people want to contribute to existing wikis or >installation guides, do not hesitate to do so likewise!

    http://www.dodin.org/wiki/pmwiki.php?n=Doc.ConfigurerINN-2021

    https://th-h.de/net/usenet/servers/inn/overview/ (in German)


    https://web.archive.org/web/20230901182332/https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html
    (in French, to be revived)



    In the next posting of the FAQ:


    4.4. tradspool: could not open ... File exists

    scanspool will be mentioned as a useful program to run.


    6.7. Use INN without a direct news feed

    pullnews will be referenced as a possible program to use (only suck and
    newsx were mentioned).


    6.14. Find external feeds and set up peering

    A sentence about importing old articles will be added, pointing to the
    manual page of pullnews which explains how to do that, as well as how
    not to propagate these pulled articled to external feeds.

    Oh yes, a clear manual for importing one or more article be nice.
    I've already done it for the entire "fr" hierarchie with "suck" and
    your help for inn2 configuration ;-)


    - I'd also like to see a point for transferring a server to another machine with
    the least possible hassle for users (no renumbering of items or other hassles). I have an ulterior motive: I'm going to change server soon.

    - The same question when changing storage method (I plan to switch from tradspool to overdb)

    Thank's for your job, here, and on the french hierarchie.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nigel Reed@21:1/5 to iulius@nom-de-mon-site.com.invalid on Wed Dec 27 16:45:08 2023
    On Wed, 27 Dec 2023 21:25:06 +0100
    Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

    I should probably keep better notes for myself.

    ... or write them into a wiki for other people to take benefit of
    them. Maybe Grant and other people here could even complete with
    their own notes gathered year after year :)

    Maybe I'll wait for them to do it first and then I can add my tiny bits
    :)



    --
    End Of The Line BBS - Plano, TX
    telnet endofthelinebbs.com 23

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Thu Dec 28 08:28:19 2023
    Bonjour llp,

    - I'd also like to see a point for transferring a server to another machine with
    the least possible hassle for users (no renumbering of items or other hassles).
    I have an ulterior motive: I'm going to change server soon.

    Such a transfer is normally described in "6.4. Feed all articles on a
    server to another server" of the FAQ.
    I wish you the best for your upcoming change of server.


    - The same question when changing storage method (I plan to switch from tradspool to overdb)

    I suggest that you do the change while changing your server. This way,
    there's no forced rebuild to do as your new server will recreate
    overview data when receiving articles. You just have to configure it
    with the wanted overview storage method in the ovmethod parameter of
    inn.conf.

    --
    Julien ÉLIE

    « Donner un sens plus pur aux mots de la tribu. » (Stéphane Mallarmé)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Thu Dec 28 11:50:15 2023
    Thus spake Julien ÉLIE <iulius@nom-de-mon-site.com.invalid>

    Just two remarks to avoid some issues that can lead to problems and
    unpalnned outages of the server:

    Bonjour llp,
    - I'd also like to see a point for transferring a server to another machine with
    the least possible hassle for users (no renumbering of items or other hassles).
    I have an ulterior motive: I'm going to change server soon.
    Such a transfer is normally described in "6.4. Feed all articles on a
    server to another server" of the FAQ.
    I wish you the best for your upcoming change of server.

    Always use xrefslave: true on the target server during the transfer to
    keep the article numbers the same as on the source server to avoid
    coofusing your clients after you switch to the new server.


    - The same question when changing storage method (I plan to switch from
    tradspool to overdb)
    I suggest that you do the change while changing your server. This
    way, there's no forced rebuild to do as your new server will recreate overview data when receiving articles. You just have to configure it
    with the wanted overview storage method in the ovmethod parameter of inn.conf.

    I strongly recommend not to use ovdb (Berkeley DB) as it can cause database corruption after a crash and the rebuild is painfully slow. It can also
    create absurdly large database files if you have large gaps in your
    article numbers which directly affects the memory use of your nnrpd
    processes.

    It also lacks utilities like tdx-util or ovsqlite-util. Depending on the number of clients it also requires tweaking the DB_CONFIG to improve
    performance. I used ovdb for almost 2 years and eventually went back to tradindexed after the Linux kernel bug that killed servers in full
    flight at midnight on New Years Day 2012 and completey destroyed my
    overview database.

    I'm currently testing a migration to ovsqlite and so far it looks much
    more reliable than ovdb.

    --
    Пу́тін — хуйло́
    https://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Kempe@21:1/5 to All on Thu Dec 28 16:52:33 2023
    Den 2023-12-26 skrev Julien ÉLIE <iulius@nom-de-mon-site.com.invalid>:
    Hi all,

    Archive-name: usenet/software/inn2-faq
    URL: https://www.eyrie.org/~eagle/faqs/inn.html

    For the recall, contributions are welcome to update the document. Do
    not hesitate to send modifications, or new questions to add to the FAQ.


    I don't know if this is something that belongs in the FAQ, but, I
    think, a year or so back, we had the issue that our INN process on
    FreeBSD suddenly became unresponsive and started consuming 100 % CPU.
    After debugging, it turned out that we hit the max number of fds
    select() could handle. Switching overview method to ovsqlite solved
    the problem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From llp@21:1/5 to All on Thu Dec 28 23:07:53 2023
    Ray Banana <rayban@raybanana.net> composa la prose suivante:

    Thus spake Julien ÉLIE <iulius@nom-de-mon-site.com.invalid>

    Just two remarks to avoid some issues that can lead to problems and
    unpalnned outages of the server:

    Bonjour llp,
    - I'd also like to see a point for transferring a server to another machine with
    the least possible hassle for users (no renumbering of items or other hassles).
    I have an ulterior motive: I'm going to change server soon.
    Such a transfer is normally described in "6.4. Feed all articles on a
    server to another server" of the FAQ.
    I wish you the best for your upcoming change of server.

    Always use xrefslave: true on the target server during the transfer to
    keep the article numbers the same as on the source server to avoid
    coofusing your clients after you switch to the new server.

    Ok.

    - The same question when changing storage method (I plan to switch from
    tradspool to overdb)
    I suggest that you do the change while changing your server. This
    way, there's no forced rebuild to do as your new server will recreate
    overview data when receiving articles. You just have to configure it
    with the wanted overview storage method in the ovmethod parameter of
    inn.conf.

    I strongly recommend not to use ovdb (Berkeley DB) as it can cause database >corruption after a crash and the rebuild is painfully slow. It can also >create absurdly large database files if you have large gaps in your
    article numbers which directly affects the memory use of your nnrpd >processes.

    It also lacks utilities like tdx-util or ovsqlite-util. Depending on the number
    of clients it also requires tweaking the DB_CONFIG to improve
    performance. I used ovdb for almost 2 years and eventually went back to >tradindexed after the Linux kernel bug that killed servers in full
    flight at midnight on New Years Day 2012 and completey destroyed my
    overview database.

    I'm currently testing a migration to ovsqlite and so far it looks much
    more reliable than ovdb.

    Good to know, i'll try ovsqlite.
    The aim is to have an "up-to-date" overview even if messages are deleted during the day (I don't know if I'm making myself clear?).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Sun Jan 7 23:03:52 2024
    Bonsoir llp,

    Good to know, i'll try ovsqlite.
    The aim is to have an "up-to-date" overview even if messages are deleted during
    the day (I don't know if I'm making myself clear?).

    When using tradindexed (your current overview method if I understand
    well), the contents of the returned overview data is updated as soon as
    a message is cancelled or removed by a NoCeM notice.
    Do you currently have a different behaviour?

    --
    Julien ÉLIE

    « Il buvait toutes mes paroles, et comme je parlais beaucoup, à un
    moment, je le vois qui titubait… » (Raymond Devos)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Sun Jan 7 23:11:30 2024
    Hi Andreas,

    I don't know if this is something that belongs in the FAQ, but, I
    think, a year or so back, we had the issue that our INN process on
    FreeBSD suddenly became unresponsive and started consuming 100 % CPU.
    After debugging, it turned out that we hit the max number of fds
    select() could handle. Switching overview method to ovsqlite solved
    the problem.

    Interesting to know. Did you change the overcachesize setting in
    inn.conf? (The default value is 128.)

    This issue is probably fixed in the upcoming 2.7.2 release (in a few
    months) as I recently added checks in innd not to open more file
    descriptors than the size of FD_SET. I bet the 100 % CPU consumption is related to that problem (channels may have been wrongly marked at a
    wrong state).
    From the changelog: "innd no longer malfunctions nor throttles when the maximum number of file descriptors supported by the system is reached.
    If needing to use more file descriptors than the default system limit, a
    new LARGE_FD_SETSIZE option can be set at build time. See the
    documentation for rlimitnofile in inn.conf for more information. Thanks
    to Jesse Rehmer for the bug report."

    --
    Julien ÉLIE

    « XXII ! Voilà les Romains ! » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From llp@21:1/5 to All on Sun Jan 7 23:30:35 2024
    Il se trouve que Julien LIE a formul :
    Bonsoir llp,

    Good to know, i'll try ovsqlite.
    The aim is to have an "up-to-date" overview even if messages are deleted
    during
    the day (I don't know if I'm making myself clear?).

    When using tradindexed (your current overview method
    if I understand well),

    Absolutely.

    the contents of the returned overview data is updated as soon
    as a message is cancelled or removed by a NoCeM notice.
    Do you currently have a different behaviour?

    When I read the list of new messages on a group, the message headers
    are loaded, but when I ask for the message body, this is of course not available and my news reader (mesnews) marks the message as deleted.

    This is why I wanted to switch to ovsqlite.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Mon Jan 8 00:07:52 2024
    Bonsoir llp,

    the contents of the returned overview data is updated as soon
    as a message is cancelled or removed by a NoCeM notice.
    Do you currently have a different behaviour?

    When I read the list of new messages on a group, the message headers
    are loaded, but when I ask for the message body, this is of course not available and my news reader (mesnews) marks the message as deleted.

    Strange. When an article is cancelled, its entry is normally
    immediately blanked out in the tradindexed index file of the
    corresponding newsgroup(s). Overview data for cancelled articles should
    not be returned to news clients


    This is why I wanted to switch to ovsqlite.

    I hope you'll have a better experience with ovsqlite, though I do not understand why tradindexed returns cancelled articles in overview data.

    --
    Julien ÉLIE

    « Life is short… so eat dessert first! »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From llp@21:1/5 to All on Mon Jan 8 00:41:48 2024
    Dans son message prcdent, Julien LIE a crit :
    Bonsoir llp,

    the contents of the returned overview data is updated as soon
    as a message is cancelled or removed by a NoCeM notice.
    Do you currently have a different behaviour?

    When I read the list of new messages on a group, the message headers
    are loaded, but when I ask for the message body, this is of course not
    available and my news reader (mesnews) marks the message as deleted.

    Strange. When an article is cancelled, its entry is normally immediately blanked out in the tradindexed index file of the corresponding newsgroup(s). Overview data for cancelled articles should not be returned to news clients

    Does the inn2 version matter for this?
    I use version 2.6.4

    This is why I wanted to switch to ovsqlite.

    I hope you'll have a better experience with ovsqlite, though I do not understand why tradindexed returns cancelled articles in overview data.

    Is it the same problem ?
    <news:8m8r7nmoop.fsf@raybanana.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Mon Jan 8 20:54:40 2024
    Bonsoir llp,

    When an article is cancelled, its entry is normally
    immediately blanked out in the tradindexed index file of the
    corresponding newsgroup(s). Overview data for cancelled articles
    should not be returned to news clients

    Does the inn2 version matter for this?
    I use version 2.6.4

    The version does not matter.


    This is why I wanted to switch to ovsqlite.

    I hope you'll have a better experience with ovsqlite, though I do not
    understand why tradindexed returns cancelled articles in overview data.

    Is it the same problem ?
    <news:8m8r7nmoop.fsf@raybanana.net>

    I don't know what the underlying problem was in that other thread. I
    thought from past experience that the overview data for cancelled
    articles was no longer returned to news clients when using tradindexed,
    but Wolfgang indeed said the run of expireover was needed.
    I must have been wrong then.

    Looking at the code, overview entries of cancelled articles are
    immediately blanked out. Seems like it no longer works; I shall retest
    it then.

    --
    Julien ÉLIE

    « Sol lucet omnibus. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Kempe@21:1/5 to All on Tue Jan 9 16:10:05 2024
    Den 2024-01-07 skrev Julien ÉLIE <iulius@nom-de-mon-site.com.invalid>:
    Hi Andreas,

    I don't know if this is something that belongs in the FAQ, but, I
    think, a year or so back, we had the issue that our INN process on
    FreeBSD suddenly became unresponsive and started consuming 100 % CPU.
    After debugging, it turned out that we hit the max number of fds
    select() could handle. Switching overview method to ovsqlite solved
    the problem.

    Interesting to know. Did you change the overcachesize setting in
    inn.conf? (The default value is 128.)


    Checking our current configuration, it is set to 1024. I don't think
    we have touched that setting since the server was installed so that's
    probably the value it had when we were having issues.

    This issue is probably fixed in the upcoming 2.7.2 release (in a few
    months)

    That's good to hear! Apologies for never getting around to reporting
    the issue ourselves.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Kempe@21:1/5 to All on Tue Jan 9 16:19:18 2024
    Den 2024-01-09 skrev Andreas Kempe <kempe@lysator.liu.se>:
    Den 2024-01-07 skrev Julien ÉLIE <iulius@nom-de-mon-site.com.invalid>:
    Hi Andreas,

    I don't know if this is something that belongs in the FAQ, but, I
    think, a year or so back, we had the issue that our INN process on
    FreeBSD suddenly became unresponsive and started consuming 100 % CPU.
    After debugging, it turned out that we hit the max number of fds
    select() could handle. Switching overview method to ovsqlite solved
    the problem.

    Interesting to know. Did you change the overcachesize setting in
    inn.conf? (The default value is 128.)


    Checking our current configuration, it is set to 1024. I don't think
    we have touched that setting since the server was installed so that's probably the value it had when we were having issues.


    Checking the man page for inn.conf, it's coming back to me and you're
    probably spot on with your assesment that overcachesize is what caused
    the issue. 1024 fds is the default limit for select() on FreeBSD,
    something we didn't realise at the time so we only checked the maximum
    allowed open files limit. We bumped the setting because, back then,
    the server was on storage that was really slow when it came to opening
    files.

    Either way, ovsqlite has been working really well for us so I see no
    need to switch back even if we could.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Tue Jan 9 19:38:47 2024
    Hi Andreas,

    Checking the man page for inn.conf, it's coming back to me and you're probably spot on with your assesment that overcachesize is what caused
    the issue. 1024 fds is the default limit for select() on FreeBSD,
    something we didn't realise at the time so we only checked the maximum allowed open files limit.

    OK, thanks for your confirmation.
    I am therefore pretty confident that the sanity-check fix in INN 2.7.2
    solves your 100 % CPU problem.

    Suppose you have 1000 open cache tradindexed slots, 24 fds used for innd channels, and overcachesize set to 1024, then:
    - more cache slots can be opened (up to 1024 slots, and therefore fd
    number 1048, which is fine as there's no select() on these fds);
    - if for whatever reason innd wants to create a new channel, then it
    won't create it, refuse the connection, and log a warning ("SERVER file descriptor 1049 too high in CHANcreate (see rlimitnofile in inn.conf)").
    It won't become unresponsive, and the show goes on.

    Let's just hope the news admin will one day catch these warnings. But
    at least innd won't do weird things.



    Thanks to your message, I note that the description of rlimitnofile does
    not mention overcachesize, and the description of overcachesize does not mention rlimitnofile. As they are somehow linked, I'll add a sentence
    in both of them to mention the other one :)

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



    Either way, ovsqlite has been working really well for us so I see no
    need to switch back even if we could.

    ovsqlite is indeed an efficient and reliable overview method. Thanks
    again to Bo Lindbergh for having written it!



    Apologies for never getting around to reporting the issue ourselves.
    No problem.
    Thanks for mentioning it now, as it permits improving the wording of the rlimitnofile and overcachesize descriptions.

    --
    Julien ÉLIE

    « O fortunatos nimium, sua si bona norint, agricolas. » (Virgile)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jakob Bohm@21:1/5 to All on Wed Jan 24 06:19:55 2024
    On 2024-01-08 20:54, Julien ÉLIE wrote:
    Bonsoir llp,

    When an article is cancelled, its entry is normally immediately
    blanked out in the tradindexed index file of the corresponding
    newsgroup(s). Overview data for cancelled articles should not be
    returned to news clients

    ...


    This is why I wanted to switch to ovsqlite.

    I hope you'll have a better experience with ovsqlite, though I do not
    understand why tradindexed returns cancelled articles in overview data.

    Is it the same problem ?
    <news:8m8r7nmoop.fsf@raybanana.net>

    I don't know what the underlying problem was in that other thread.  I thought from past experience that the overview data for cancelled
    articles was no longer returned to news clients when using tradindexed,
    but Wolfgang indeed said the run of expireover was needed.
    I must have been wrong then.

    Looking at the code, overview entries of cancelled articles are
    immediately blanked out.  Seems like it no longer works; I shall retest
    it then.


    One common pattern is that some time passes between the client
    retrieving the headers (often as an automated background task) and the
    same client retrieving the article (often postponed to the moment the
    user views the article offered by the cleint user interface).

    The problem here is that if a spam article is removed between those two
    network activities, the user is presented with an error message rather
    than protected from seeing the spam. And often times, the ability to
    make the client actively test for this has the negative side effect of
    deleting old articles from the client's local message archive as soon as upstream fails to retain them, thus users wanting retention of
    previously read non-spam turn off those options and suffer from the half-blanked messages in their user interface.

    It would be better for client software implementation and use if NNTP
    servers could return a result "this article deliberately cancelled, not
    just expired" and this was sufficiently standardized for client software
    to honour it without corrupting local archives.


    Enjoy

    Jakob
    --
    Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
    Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
    This public discussion message is non-binding and may contain errors.
    WiseMo - Remote Service Management for PCs, Phones and Embedded

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Wed Jan 24 10:20:22 2024
    Thus spake Jakob Bohm <jb-usenet@wisemo.invalid>


    I thought from past experience that the overview data for cancelled
    articles was no longer returned to news clients when using
    tradindexed, but Wolfgang indeed said the run of expireover was
    needed.
    [...]
    Looking at the code, overview entries of cancelled articles are
    immediately blanked out.  Seems like it no longer works; I shall
    retest it then.
    One common pattern is that some time passes between the client
    retrieving the headers (often as an automated background task) and the
    same client retrieving the article (often postponed to the moment the
    user views the article offered by the cleint user interface).
    The problem here is that if a spam article is removed between those two network activities, the user is presented with an error message rather
    than protected from seeing the spam. And often times, the ability to
    make the client actively test for this has the negative side effect of deleting old articles from the client's local message archive as soon as upstream fails to retain them, thus users wanting retention of
    previously read non-spam turn off those options and suffer from the half-blanked messages in their user interface.

    After more testing I can confirm Jakob's explanation. Immediately after
    locally cancelling articles, the overview data for the article had been
    removed from tradindexed and sqlite overview databases. Clients
    configured to automatically retrieve new overview data every 10 minutes
    still showed the overview data and displayed an error message when the
    user tried to open the article.

    --
    Пу́тін — хуйло́
    https://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Wed Jan 24 20:48:53 2024
    Hi Jacob, Wolfgang,

    One common pattern is that some time passes between the client
    retrieving the headers (often as an automated background task) and the
    same client retrieving the article (often postponed to the moment the
    user views the article offered by the cleint user interface).
    The problem here is that if a spam article is removed between those two
    network activities, the user is presented with an error message rather
    than protected from seeing the spam.

    The client asks for article 42, and the server responds that this
    article number does not exist at the time he asks. I am not under the impression that the news client needs giving an error message. For a
    better user experience, it should just go on and silently skip the
    article (and records that in the logs, if any).


    And often times, the ability to
    make the client actively test for this has the negative side effect of
    deleting old articles from the client's local message archive as soon as
    upstream fails to retain them

    I do not understand why a news client needs retrieving again an old
    article (sending an ARTICLE command to the server) when it already has
    it in its local message archive. Why not just display the already
    downloaded article?
    Besides, even if it does that, it doesn't have to delete it from its
    local message archive.


    thus users wanting retention of
    previously read non-spam turn off those options and suffer from the
    half-blanked messages in their user interface.

    This indeed is not very user-friendly. There should be an option to
    prevent already downloaded old messages to be deleted.


    After more testing I can confirm Jakob's explanation. Immediately after locally cancelling articles, the overview data for the article had been removed from tradindexed and sqlite overview databases.

    Yes, that's normal. Cancelled articles should not be returned to news
    clients (and therefore should not appear in the overview database).


    Clients configured to automatically retrieve new overview data every
    10 minutes still showed the overview data
    The client usually asks for new overview data since its last retrieval.
    If an article is cancelled but its overview data has already been
    downloaded by the previous automatical retrieval, yes I believe it still
    shows up.


    and displayed an error message when the user tried to open the article.

    If it had been configured by the user to show an error message, then it
    is normal. I do not believe the client should explicitly return an
    error. Retrieving an article by its number after having downloaded the overview data is a common case, and the article may not be available. I
    think the client should just skip it if it had not already downloaded
    the article, and of course do not delete it if it had already downloaded
    it and has it in its local archive.

    --
    Julien ÉLIE

    « Passion is inversely proportional to the amount of real information
    available. » (Benford's law)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to floffy@gallaxial.com on Sun Mar 24 10:11:14 2024
    "floffy@gallaxial.com" <floffy@gallaxial.com> writes:

    Does have a fork for windows , i am very not good in linux ....

    People have gotten INN working with Cygwin in the past, but it's been
    quite a while and it probably doesn't work any more. INN is very heavily POSIX-based and would require substantial amounts of care and feeding to
    get it to work on Windows, and my experience in the past with keeping such
    a port of UNIX software working over time has not been positive. It tends
    to be very intrusive in the source code.

    The more interesting question now is whether INN would work on the Windows Subsystem for Linux (WSL). That's much more likely, since WSL is
    essentially a virtual Ubuntu system. This may still be too Linux-y for
    your needs, but it would be much more likely to work than trying to run
    INN as a native Windows application.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)