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.
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.
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).
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 /not/ having /some/ information on this is a disservice to new
news masters.
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.
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
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.
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
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.
I agree. Also, many things are implied by common logic and it would
be waste of everybody's time to include.
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];
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.
On 7/15/22 12:02 AM, Miner wrote:No difference for me. I have no domain.
Before asking for a peering:
* administrator must register the domain and probably should pay for it [3];
The difference to me
Discuss details with Ishmel.* administrator should set up and run the MTA [4];But why
...
Discuss details with Ishmel.
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.
INN can provide stand-alone service for entirely private
groups.
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.
It used to be common logic that smoking on a plane was okay.
Russ Allbery wrote:
INN can provide stand-alone service for entirely private
groups.
I have never seen usage in this way. Companies and organizations
prefer other solutions.
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.
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
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.
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.
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.
There is reason to think about the cause of this phenomenon. The
conceptual advantages of the Usenet are undeniable.
Degradation is often the result of error. It remains to find the error
and fix before it's too late.
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
I noticed you're abusing [skip] often. There was references on
Message-ID.
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.
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
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.
Just the facts.
1. News.admin.peering FAQ does not exist or hasn't been posted in
the past few months.
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.
I can support "/must/ use a /registered/ domain name".
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.
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.
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.
There is absolutely no need to specify those in *INN* FAQ. Perhaps is some "computing 101" FAQ...
... that could probably be simplified as "FQDN", but...
... 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).
Why even that? It would be at best "MAY", if it even warrants
a mention
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...
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.
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.
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.
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.
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.
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?
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.
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.
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.
The author of the INN 2.x FAQ Russ Allbery continues to spread disinformation. I express my contempt for all organizers of
disinformation.
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".
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.
Anyway, go write your own FAQ if you don't like this one.
Russ Allbery wrote:I thought the faq was good so yeah.
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
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.)
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
Archive-name: usenet/software/inn2-faq
URL: https://www.eyrie.org/~eagle/faqs/inn.html
4.4. tradspool: could not open ... File exists
6.7. Use INN without a direct news feed
6.14. Find external feeds and set up peering
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.
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.
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 :)
- 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)
Bonjour llp,
- I'd also like to see a point for transferring a server to another machine withSuch a transfer is normally described in "6.4. Feed all articles on a
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.
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 fromI suggest that you do the change while changing your server. This
tradspool to overdb)
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.
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.
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 withSuch a transfer is normally described in "6.4. Feed all articles on a
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.
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 fromI suggest that you do the change while changing your server. This
tradspool to overdb)
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?).
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.
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?
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.
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.
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>
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)
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.
Either way, ovsqlite has been working really well for us so I see no
need to switch back even if we could.
Apologies for never getting around to reporting the issue ourselves.No problem.
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.
[...]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 areOne common pattern is that some time passes between the client
immediately blanked out. Seems like it no longer works; I shall
retest it then.
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.
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 everyThe client usually asks for new overview data since its last retrieval.
10 minutes still showed the overview data
and displayed an error message when the user tried to open the article.
Does have a fork for windows , i am very not good in linux ....
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 84:24:46 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,097 |
Messages: | 5,276,895 |