Re: preferred overlay/union filesystem?
Chris Angelico writes: > On Wed, May 28, 2014 at 3:21 PM, Kushal Kumaran > wrote: >> Chris Angelico writes: >> >>> On Wed, May 28, 2014 at 5:47 AM, Joe Pfeiffer wrote: Well, I don't want to keep two separate files (that's what I'm trying to get away from). It seems like the overlay filesystem would be a bit cleaner if it can work, but symbolic links elsewhere would be my second choice. >>> >>> As a variant of Kushal's suggestion of two symlinks to the same file, >>> you could have the real file in one place (preferably where it's >>> written to) and a symlink to it from the other place. >>> >> >> If I understand the situation correctly, only one of the locations will >> be accessible at any time. When the user logs in, the original files >> will be hidden under the files provided by the encrypted filesystem. >> So, both files are actually ~/.bogofilter (say), just at different >> times. So you cannot have a symlink from one location to the other. > > Ah! Gotcha. Then, yes; symlinks from both to the same destination. Not > sure what a suitable destination is, though. > > ChrisA For the moment, I have /home/acct/file, /home.unenc/acct/file, and /home.enc/acct/file. The real file is in /home.unenc/acct/file, and there are symbolic links to it from both home/acct/file and /home.enc/acct/file. When I'm not logged in, the daemon sees /home/acct/file (and hence really sees /home.unenc/acct/file); when I log in, /home.enc/acct is unencrypted and laid on top of /home/acct, so the daemon still sees /home.unenc/acct/file. Inelegant (so I'd really like to find a way for a union or overlay filesystem to do it!) but it seems to work... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1bfvju8234@snowball.wb.pfeifferfamily.net
Re: preferred overlay/union filesystem?
On Wed, May 28, 2014 at 3:21 PM, Kushal Kumaran wrote: > Chris Angelico writes: > >> On Wed, May 28, 2014 at 5:47 AM, Joe Pfeiffer wrote: >>> Well, I don't want to keep two separate files (that's what I'm trying to >>> get away from). It seems like the overlay filesystem would be a bit >>> cleaner if it can work, but symbolic links elsewhere would be my second >>> choice. >>> >> >> As a variant of Kushal's suggestion of two symlinks to the same file, >> you could have the real file in one place (preferably where it's >> written to) and a symlink to it from the other place. >> > > If I understand the situation correctly, only one of the locations will > be accessible at any time. When the user logs in, the original files > will be hidden under the files provided by the encrypted filesystem. > So, both files are actually ~/.bogofilter (say), just at different > times. So you cannot have a symlink from one location to the other. Ah! Gotcha. Then, yes; symlinks from both to the same destination. Not sure what a suitable destination is, though. ChrisA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPTjJmrM_8gmDPyU4Bxay-h=ws0hzuk1uhyfa+2qbsynk-e...@mail.gmail.com
Re: preferred overlay/union filesystem?
Chris Angelico writes: > On Wed, May 28, 2014 at 5:47 AM, Joe Pfeiffer wrote: >> Well, I don't want to keep two separate files (that's what I'm trying to >> get away from). It seems like the overlay filesystem would be a bit >> cleaner if it can work, but symbolic links elsewhere would be my second >> choice. >> > > As a variant of Kushal's suggestion of two symlinks to the same file, > you could have the real file in one place (preferably where it's > written to) and a symlink to it from the other place. > If I understand the situation correctly, only one of the locations will be accessible at any time. When the user logs in, the original files will be hidden under the files provided by the encrypted filesystem. So, both files are actually ~/.bogofilter (say), just at different times. So you cannot have a symlink from one location to the other. -- regards, kushal pgpQlTJxpU881.pgp Description: PGP signature
Re: preferred overlay/union filesystem?
On Wed, May 28, 2014 at 5:47 AM, Joe Pfeiffer wrote: > Well, I don't want to keep two separate files (that's what I'm trying to > get away from). It seems like the overlay filesystem would be a bit > cleaner if it can work, but symbolic links elsewhere would be my second > choice. > As a variant of Kushal's suggestion of two symlinks to the same file, you could have the real file in one place (preferably where it's written to) and a symlink to it from the other place. ChrisA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPTjJmp3efu9t5hfH_s2K78b_ucPenCftm9jJzrTxTGVeWY=q...@mail.gmail.com
Re: preferred overlay/union filesystem?
Steve Litt writes: > On Tue, 27 May 2014 11:27:56 +0530 > Kushal Kumaran wrote: > >> Joe Pfeiffer writes: >> >> > First, here's what I'm trying to do: >> > >> > I'm using encfs to give myself an encrypted home directory, and I'm >> > successfully mounting it automatically using pam_mount when I log >> > in. >> > >> > My email is processed by a .procmailrc file in my home directory, >> > and I'm passing the email through bogofilter. So, at present I >> > have a nearly empty home directory containing .procmailrc >> > and .bogofilter/ which is accessed when I'm not logged in, and my >> > "real" home directory which is available when I am logged in. This >> > is, of course, less than optimal since I have to keep two versions >> > of .procmailrc and .bogofilter/ in sync. >> > >> >> You could keep the two files outside your home, and create symlinks to >> them in both the unencrypted and encrypted homes. > > That sounds good to me. > > If you want to keep two separate files, it's as simple as running a > shellscript to make sure they are the same. For instance, > my .procmailrc got so big and complicated that I split it into parts. > For instance, all the trolls and irritants go into something called > badguys.rc. Mailing lists go in maillists.rc. So to filter yet another > person, I'd edit badguys.rc, run my shellscript, and it would create a > new ~/.procmailrc with everything in the right order (bad guys get > filtered out before mailing list decisions are made, etc). There's one > file called vitals.rc that rises to the top of the file, and is > reserved for anything from a person or organization I consider > absolutely essential, and I want to see it even if it would normally be > moved by other filters. My shellscript could just as easily write a > copy in two different places. Well, I don't want to keep two separate files (that's what I'm trying to get away from). It seems like the overlay filesystem would be a bit cleaner if it can work, but symbolic links elsewhere would be my second choice. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1bbnujq9zu@snowball.wb.pfeifferfamily.net
Re: preferred overlay/union filesystem?
On Tue, 27 May 2014 11:27:56 +0530
Kushal Kumaran wrote:
> Joe Pfeiffer writes:
>
> > First, here's what I'm trying to do:
> >
> > I'm using encfs to give myself an encrypted home directory, and I'm
> > successfully mounting it automatically using pam_mount when I log
> > in.
> >
> > My email is processed by a .procmailrc file in my home directory,
> > and I'm passing the email through bogofilter. So, at present I
> > have a nearly empty home directory containing .procmailrc
> > and .bogofilter/ which is accessed when I'm not logged in, and my
> > "real" home directory which is available when I am logged in. This
> > is, of course, less than optimal since I have to keep two versions
> > of .procmailrc and .bogofilter/ in sync.
> >
>
> You could keep the two files outside your home, and create symlinks to
> them in both the unencrypted and encrypted homes.
That sounds good to me.
If you want to keep two separate files, it's as simple as running a
shellscript to make sure they are the same. For instance,
my .procmailrc got so big and complicated that I split it into parts.
For instance, all the trolls and irritants go into something called
badguys.rc. Mailing lists go in maillists.rc. So to filter yet another
person, I'd edit badguys.rc, run my shellscript, and it would create a
new ~/.procmailrc with everything in the right order (bad guys get
filtered out before mailing list decisions are made, etc). There's one
file called vitals.rc that rises to the top of the file, and is
reserved for anything from a person or organization I consider
absolutely essential, and I want to see it even if it would normally be
moved by other filters. My shellscript could just as easily write a
copy in two different places.
I guess what I'm saying is that if and only if both your .procmailrc
and .bogofilter/ would benefit from such a shellscript without regard
to your two directory situation, you could make your shellscript write
both files, safe in the knowledge that they're both the same.
Otherwise, symlinks seem to me a good way to go.
Here's my shellscript, called make_pm_filters.sh:
===
#!/bin/bash
##
# Copyright (C) 2014 by Steve Litt
#
# Permission is hereby granted, free of charge, to any
# person obtaining a copy of this software and
# associated documentation files (the "Software"), to
# deal in the Software without restriction, including
# without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom
# the Software is furnished to do so, subject to the
# following conditions:
#
# The above copyright notice and this permission notice
# shall be included in all copies or substantial
# portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
# ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
# LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
# FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
# EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE
# FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
# USE OR OTHER DEALINGS IN THE SOFTWARE.
##
The Procmail resource file
Careful, gets overwritten on every run
pmrcfile=~/.procmailrc
Dir containing component files
componentdir=/d/inst/pmfilters/
Procmail resource components, ORDER IS IMPORTANT!!!
componentfiles="envvars.rc
vitals.rc
badguys.rc
maillists.rc
diag_first.rc
by_account.rc
diag_second.rc
fallthrough.rc"
function apppend(){
local fname=$1
echo >> $pmrcfile
echo >> $pmrcfile
echo >> $pmrcfile
echo "###" >> $pmrcfile
echo "# $fname" >> $pmrcfile
echo "###" >> $pmrcfile
echo >> $pmrcfile
fname=$componentdir$fname
cat $fname >> $pmrcfile
}
function makeheader(){
echo -n "# CREATED BY $0: " > $pmrcfile
echo "DO NOT EDIT BY HAND!!! #" >> $pmrcfile
echo -n "# COMPONENT FILE DIRECTORY " >> $pmrcfile
echo "IS $componentdir #" >> $pmrcfile
echo >>$pmrcfile
echo >>$pmrcfile
}
cd $componentdir
echo
echo -n "This will concat the following component "
echo "files to $pmrcfile,"
echo "in the following order ..."
echo
for f in $componentfiles; do
echo $f
done
echo
echo "Next, will test that all component files exist..."
echo
let errs=0
for f in $componentfiles; do
if ! test -f $f; then
let errs=$errs+1
echo -n "FATAL ERROR: "
echo "No file $f in directory $componentdir"
fi
done
if test $errs -gt 0; then
echo "$errs ERRORS, aborting..."
echo
exit 2
else
echo "All componentfiles accounted for, continuing..."
fi
makeheader
for f in $componentfiles; do
echo Appending component file file $f
Re: preferred overlay/union filesystem?
Joe Pfeiffer writes: > First, here's what I'm trying to do: > > I'm using encfs to give myself an encrypted home directory, and I'm > successfully mounting it automatically using pam_mount when I log in. > > My email is processed by a .procmailrc file in my home directory, and > I'm passing the email through bogofilter. So, at present I have a > nearly empty home directory containing .procmailrc and .bogofilter/ > which is accessed when I'm not logged in, and my "real" home directory > which is available when I am logged in. This is, of course, less than > optimal since I have to keep two versions of .procmailrc and > .bogofilter/ in sync. > You could keep the two files outside your home, and create symlinks to them in both the unencrypted and encrypted homes. > I'd like to have an overlay filesystem, so the unencrypted .procmailrc > and .bogofilter are still visible through a "hole" in my encrypted > filesystem. > > I've been looking through the various union and overlay filesystems > (unionfs, unionfs-fuse, aufs, overlayfs) and (1) I'm not sure which > of them are currently being developed and supported, and (2) it isn't > clear any of them actually do what I want (either I can't just overlay a > new filesystem on top of an existing one, or else the existing one has > to be read-only). > -- regards, kushal pgpAw25jAKe_s.pgp Description: PGP signature
preferred overlay/union filesystem?
First, here's what I'm trying to do: I'm using encfs to give myself an encrypted home directory, and I'm successfully mounting it automatically using pam_mount when I log in. My email is processed by a .procmailrc file in my home directory, and I'm passing the email through bogofilter. So, at present I have a nearly empty home directory containing .procmailrc and .bogofilter/ which is accessed when I'm not logged in, and my "real" home directory which is available when I am logged in. This is, of course, less than optimal since I have to keep two versions of .procmailrc and .bogofilter/ in sync. I'd like to have an overlay filesystem, so the unencrypted .procmailrc and .bogofilter are still visible through a "hole" in my encrypted filesystem. I've been looking through the various union and overlay filesystems (unionfs, unionfs-fuse, aufs, overlayfs) and (1) I'm not sure which of them are currently being developed and supported, and (2) it isn't clear any of them actually do what I want (either I can't just overlay a new filesystem on top of an existing one, or else the existing one has to be read-only). Any guidance would be appreciated! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1bppiznazx@snowball.wb.pfeifferfamily.net
