Pedro posted on Sat, 01 Apr 2017 14:17:25 +1100 as excerpted: > for linux users, particularly as the headers are getting into the > gigabytes for servers with long retentions.. > > pan by default installs to /home/<username>/.pan2 > > but with this symlink command you can make any other location be that > .pan2
A symlink is one method. But pan actually checks the PAN_HOME environmental variable and uses the directory it points to as its data dir, with ~/.pan2 only being the reasonable default if $PAN_HOME wasn't set (tho it won't be in most systems). That actually makes it possible to have multiple pan instances, as I do here, by setting up wrapper scripts that set and export $PAN_HOME before starting pan itself. Here, I use that with wrapper scripts named pan.bin, pan.text, and pan.test, to setup different instances for my text and binary groups, and yet another instance for testing, that I can wipe the cache and group/ message tracking from after checking a post someone mentions on-list as causing trouble for them, for instance, without having to worry about losing my regular groups. My pan.text instance is set to never expire, so I have a more or less permanent archive of my text groups, including my ISP's newsgroups from years ago, before they killed the server, and messages from this list via gmane going back to 2002. Of course I wouldn't want to do that with binaries... But that's just the division I've chosen to use. If you want to setup separate instances for say your TV/movie groups vs. your mp3/music groups vs. your kids' kid-safe groups vs. your pron groups, or on the text side, your MS groups vs. your FLOSS groups vs. your non-computer-related groups, go right ahead. =:^) FWIW, that's just one of several lessor known "power user" tricks available with pan. Perhaps the other reasonably common one is editing the servers.xml file directly to set > 4 connections per server, something that many paid NSP accounts allow, but that is not allowed in the pan GUI due to its observance of GNKSA. Another very common one is direct editing of the SCORE file, for optimization and/or to accomplish scoring in ways the rather simplified GUI scoring interface doesn't allow. Other probably less common ones are editing the servers.xml file and renaming your newsrc files accordingly, to match the server names or whatever, instead of being the rather generic newsrc-1, newsrc-2, etc, and editing expiration to an arbitrary number of days, instead of the rather limited number of choices available in the GUI. And of course renaming the newsrc files points to direct-editing them as well. Another is editing global accels via accels.txt. There's probably others I'm not remembering ATM. Meanwhile, back to symlinks, another similar system-level method is mounts and/or bind-mounts. With PAN_HOME it's not so necessary for pan, but the same techniques can be used for other, rather less flexible, applications. What's nice about bind-mounts is that they allow you to set mount options such as readonly and noexec, at the directory or even down to the individual file level if that's what's bind-mounted, that may not be easy to enforce otherwise. Of course they /do/ require the ability to mount in the first place, something that's normally reserved for superuser/root. -- 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 https://lists.nongnu.org/mailman/listinfo/pan-users
