tip: getting pan to run off another location other than /home

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

tip: getting pan to run off another location other than /home

Pedro
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


ln -s <newlocation> <oldlocationtosubstitute>

eg

ln -s  <newlocation>/.pan /home/<username/.pan2

you might have to do a chown -R <username> <newlocation> for the
newlocation if you dont have permissions there.

that won''t survive a reboot, so put that into startup applications too
if you want to.

also if you want to install pan in a location that is encapsulated with
veracrypt, or the old (disadvised) truecrypt you can use the symlink to
that location and have it all encrypted.

things in <> are your options to put in. location is a folder.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tip: getting pan to run off another location other than /home

Jim Henderson-4
On Sat, 01 Apr 2017 14:17:25 +1100, Pedro wrote:

> 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
>
>
> ln -s <newlocation> <oldlocationtosubstitute>
>
> eg
>
> ln -s  <newlocation>/.pan /home/<username/.pan2
>
> you might have to do a chown -R <username> <newlocation> for the
> newlocation if you dont have permissions there.
>
> that won''t survive a reboot, so put that into startup applications too
> if you want to.
>
> also if you want to install pan in a location that is encapsulated with
> veracrypt, or the old (disadvised) truecrypt you can use the symlink to
> that location and have it all encrypted.
>
> things in <> are your options to put in. location is a folder.

I do something similar to this - I use encfs to store my Pan data in a
folder that's synced between multiple machines using Dropbox.  When I
start pan, I use a script that uses zenity to prompt for the encfs
password, and it mounts the encrypted directory in ~/.pan2.  When I exit,
it unmounts the directory.

While the script does leave the password visible in the 'ps' output, for
my use, that's "good enough" - if someone had access to my system, they
could use a sniffer to look at the unencrypted NNTP connection my servers
use to grab the credentials - what I'm protecting against is compromise
of the Dropbox folder, not a compromise of my systems).

Jim

--
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tip: getting pan to run off another location other than /home

Duncan-42
In reply to this post by Pedro
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Loading...