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, anyway). 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 describe. 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 others. 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 anyway. -- 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
