On Sun, Mar 20, 2016 at 4:44 AM, Matt Ruffalo <matt.ruff...@gmail.com> wrote: > Hi all- > > I'm writing a backup client for automating the synchronization of btrfs > snapshots between machines -- essentially piping the output of `btrfs > send` on my laptop/desktop to `btrfs receive` on a server. I've been > doing this manually for quite a while, and something automated would be > much more convenient. > ... > I've been using SSL for the communication between the client and server, > both in a static "control port" and a dynamic data port that is assigned > for each individual call to btrfs send | btrfs receive. In addition to > verifying the client certificates against a trusted CA, this also allows > things like selecting the backup destination based on the common name in > the client cert. > [snip details of subprocess.Popen issues]
Hmm. Any particular reason you're not using SSH here? That seems like the most obvious way to pipe the output of a command on one computer into a command on another. Instead of verifying client certificates, you'd have a set of authorized public keys, and you could prevent shell access by using your custom script as the shell of a dedicated user - so it'd be something like "btrfs send|ssh backup@server". Whenever I need to encrypt stuff, I try to let someone else do all the work :) Whatever shell is used for that user, it will get "btrfs send" piped into it, and all the authentication and encryption is completely invisible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
