[sf-lug] New Open Source Software Proposal

[Alex Kleider]

What language would you use to build this tool?
alex

a_kleider at yahoo.com


--- On Tue, 3/16/10, David Hinkle <hinkle at cipafilter.com> wrote:

> From: David Hinkle <hinkle at cipafilter.com>
> Subject: Re: [sf-lug] New Open Source Software Proposal
> To: "David Rosenstrauch" <darose at darose.net>, "sf-lug at linuxmafia.com" <sf-lug at linuxmafia.com>
> Date: Tuesday, March 16, 2010, 9:47 AM
> I would totally build the
> functionality into the tool to download subdirectories,
> specific files, and to produce a file listing.
> 
> David
> 
> -----Original Message-----
> From: sf-lug-bounces at linuxmafia.com
> [mailto:sf-lug-bounces at linuxmafia.com]
> On Behalf Of David Rosenstrauch
> Sent: Tuesday, March 16, 2010 9:37 AM
> To: sf-lug at linuxmafia.com
> Subject: Re: [sf-lug] New Open Source Software Proposal
> 
> On 03/15/2010 06:36 PM, Alex Kleider wrote:
> > My suggestion is to use enc-fs on the local (to be
> backed up) machine
> > so an encrypted version of the backup source is
> already available.
> > Then when it comes time to do backup, use the
> encrypted version and
> > send it over to the destination directory. The one
> 'gotcha' that I
> > see is that to reconstitute, one needs not only the
> encrypted file
> > and the passphrase, but also the ".encfs5" control
> file at the top
> > level of the raw encfs filesystem.  I don't know
> if rsync transfers
> > hidden files but you wouldn't want to be left without
> it.
> > http://www.arg0.net/encfsintro
> >
> > Using this approach, nothing 'new' needs to be
> written.
> >
> > alex
> 
> There's actually a few gotchas with that:
> 
> * It requires 2 rsync steps.  It should be possible to
> do this all in one.
> 
> * The .encfs5 file is needed, as you cited.
> 
> 
> And, most importantly:
> 
> * When you need to recover file(s), there's no way to
> browse the remote 
> file system and selectively download specific files (since
> all the file 
> names are scrambled).  So you'd have to do a *full*
> "reverse rsync", 
> downloading *all* the encrypted files - which could
> potentially take 
> many hours - in order to recover any files, no matter how
> small.
> 
> That last one seems like a dealbreaker to me, making this
> approach 
> unworkable.
> 
> 
> I think there's really only 2 solutions here, then: 
> either 1) the 
> encfs+sshfs approach I mentioned (which suffers from the
> restriction of 
> no hard links, and therefore can't do multiple generations
> of backups), 
> or 2) the approach that David suggested in his
> proposal.  Note however, 
> that David's proposal would also suffer from the "no way to
> 
> browse/download" issue, unless he worked around it by
> either a) building 
> such functionality into the tool, or b) implementing the
> tool as a fuse 
> filesystem.
> 
> DR
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>