Re: [leafnode-list] Fetchnews: Falling back and regrouping.

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Michael O'Quinn schrieb am Donnerstag, den 28. März 2002:

> No, it's a Seagate Barracuda ST380021A.  I've heard of tons of problem 
> with IBM drives, but I have several and personally I've never had any 
> trouble.  Just lucky I suppose.

While this is not an advocacy list, it seems, IBM ATA drives up to and
including the DPTA series were fine, and the DTLA-3050xx were also
reliable, but not the DTLA-3070xx. Not sure of newer drives, I need more
figures to state on them.

> Well yeah, I like it too.  It's a much cleaner architecture than LILO, and
> it's really a lot easier to use.  I just didn't happen to want to learn
> that much about it at that point in time.  Particularly not with my
> incoming mail server down...

Certainly.

> IMHO it is from a security and reliability standpoint.  What just happened
> to me is a case in point.  The mail server needs to be 100% available or
> mail will bounce.  (Unless a backup mail forwarder is in place, which I
> don't have.)  

A machine can always fail, so you always need a backup of each of your
components if you need 100% availability.

> Also, both mail (sendmail in particular) and news (INN) have historically
> had many security issues, some big enough to drive a truck through.

There are good alternatives, at least for sendmail, which are secure. I
like Postfix. Other people like Exim (which I don't like). I don't like
qmail any more. I used it for some time, but it's always given me one or
another headache.

> > It's omitted by the current implementation, because the state is
> > generated on the fly as interesting.groups is iterated over. When should
> > leafnode expire information for unwanted groups from SERVERNAME? We
> > don't want it to fill up with information for groups which someone hit
> > accidentally.
> 
> Why not?  It's not THAT much of a performance hit to maintain them
> forever.  You could add a command line switch to fetchnews to to clean out
> the cruft, that way the user could have it both ways.

I still fail to see why the current scheme is a problem ("bug").

> > The plan is: "don't even fetch articles you must expire right away." So,
> > if groupexpire for a particular group is 7 days, implicitly assume
> > maxage = 7 days.
> 
> No, this is completely wrong.  
> 
> "Implicitly assume" is a euphemism for "Undocumented Behavior."

Documenting that is not an issue for me.

> If the user wants maxage, let them set maxage.  If people are requesting 
> the ability to set it on a per-group basis, then do that.  But please 
> don't set one parameter based upon another just because you think it makes 
> sense to solve one problem.  It will almost always generate 10 more.

Can you already see any? What's wrong with not fetching articles we'd
expire right away?

> Will SERVERNAME include the group currently being fetched at the time of 
> the crash?

If we crash while we are fetching from that group, probably not.
However, depending on the actual implementation I'll choose,
checkpointing and "pick the last" may come for free, but I'm not
convinced we will run into this often and checking all articles for a
particular group will not hurt too much.

> Well, the whole point here is that I was having to expire articles before
> they expired from the downstream server.  Since the message-id's are no
> longer available on the leafnode end of things, what you just said breaks.

That's why I want to derive a per-group maxage from the group expire.
Newsreaders that keep a Message-ID history will not fetch articles that
are older than the oldest entry of their history file either. Say, if
they keep the Message-IDs for 21 days, they'll reject all articles older
than that, "maxage = 21" in leafnode speak.

> Well, I still think it's a VERY bad idea to assume that groupexpire = 
> WhatEver should imply maxage = WhatEver.  Just think of the bug reports 
> this is likely to generate...

People will hardly notice, unless they read the docs. =:-> Seriously,
though, this behaviour will be documented and at the moment, I start to
think that I should merge maxage and expire in leafnode, they describe
the same thing actually "I don't want articles older than N days."

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list