[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: Pan on windows?
[Pan-users] Re: Pan on windows?
Fri, 8 Apr 2011 21:51:54 +0000 (UTC)
Pan/0.134 (Wait for Me; GIT 9383aac branch-testing)
Sapient Fridge posted on Fri, 08 Apr 2011 12:52:04 +0100 as excerpted:
>> There's no way of automatically downloading all bodies, unfortunately
> OK, thanks for that. I was wondering if it was a feature I'd missed or
> whether it just wasn't there.
Another point I had intended to mention with that but forgot.
Pan has nzb functionality now, and indeed, uses it for its own tasks
file. There are command-line options to pass pan an nzb, so it can
download it, to keep pan "no-gui" so it doesn't popup when it's being
called for a background task, and to automatically download headers (but
unfortunately none to auto-download bodies, apart from a pre-filled nzb,
So while pan doesn't have auto-download-bodies as a general feature, if
there happen to be nzbs available, it can auto-download the messages they
Second additional point.
If you need full auto-download, consider installing a news server (like
leaf-node) locally. You can then configure it for the groups you want,
have it do the more or less constant syncing with the server including
bodies, and configure pan to pull only from it.
In that sort of config, you'd naturally want pan to have a tiny cache
again, the 10 MB default should be fine, since having both pan and the
local news server keep copies isn't necessary.
While it would be possible to use pan's multi-server capacities to sync
against both a local server and one or more remote servers, that's likely
to cause various issues. Instead, for local server groups, run pan
against only the local server and have the local server sync against the
There is an issue with that, however, if you sync the local server to
multiple remotes. Unless you make special peering arrangements with the
providers, you probably do NOT want the local server serving as a peer-
point between the remote servers, since then, any posts on one but not on
the other will likely pass thru you to the one missing them. If those
posts are spam (or malware or KP or copyright challenged or...), it'll
look to the one you supplied them to, to be coming from you, since they're
only expecting a normal client, not a full peer.
The answer to that is to configure the local server not to upload. But
that has issues of its own if you want to be able to post, since pan's
only syncing with the local server and now it's configured not to upload.
There are two answers to /that/. First, especially for binaries which pan
doesn't handle posting of anyway, the suggestion has always been to use
something like newspost, which would be configured to use one of the
remote servers directly, thus bypassing the local server for binary
posting just as it bypasses pan.
Second, when pan starts, it examines the PAN_HOME environmental variable
to see what data dir it should use -- ~/.pan2 is only the default if
PAN_HOME is unset. I use this fact here along with three stub-scripts
that set PAN_HOME appropriately, to run three independent pan instances
(binary, text, and test, as I'm configured, but they can be whatever you
want), each with its own separate data dir and thus settings, cache, etc.
The same idea can be used with the local-server case to run one pan
instance, presumably configured for your binary groups, that only points
at the local server, that you don't post to, and a second independent pan
instance, presumably configured for text groups, that points at the
various remote servers, with pan set to post to a particular one for each
group just as it normally does. Since pan only posts text anyway, this
allows you to post text to the desired remote servers using the posting
instance, without letting the local server peer or post between remotes
for the groups for which it's configured, and use the usual separate
binary poster for posting binaries, since pan has never handled that
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman