[pve-devel] [PATCH 1/2] This patch refactors ZFS's LUN management code, removing the existing LunCmds implementations, in favor of a single lun management infraestructure which just invokes a 'management helper' (which can be either an script or a nat
Daniel Hunsaker
danhunsaker at gmail.com
Wed Mar 19 06:48:45 CET 2014
> > > AFAIK ssh does not allow to pass environment variables to remote
hosts?
> > So I guess
> > > it is better to pass all arguments on the command line?
> > Yes and no. While ssh doesn't pass the local environment to the remote
> > system, you can include the env var assignments as part of the ssh
command
> > line, just as you would when executing such a command locally. Indeed,
> > that's what this patch does.
>
> Ah, OK. Thanks for explaining that.
Any time.
I do have a related concern, though. We might run into a problem (using
either the env-var approach *or* the args-only approach) with command line
lengths under certain LUN drivers. These limits vary from shell to shell,
and aren't even guaranteed to be the same for a given shell on different
host systems (Linux vs BSD vs Solaris vs Cygwin, etc). If we do encounter
such troubles, an alternate approach will be required.
All I can propose at the moment is the construction of a temporary wrapper
script, which would set up the environment before calling the actual driver
script/binary, and would be copied (via scp, sftp, rsync+ssh, or so) to the
remote host, then executed via ssh. This wrapper could then be deleted
from the remote system, or perhaps preserved for later reuse as long as the
various driver parameters remain the same (we already make use of hashes
for determining these kinds of things elsewhere).
Of course, it's entirely possible (and even likely) that command line
lengths will never become an issue, so my concern may be unwarranted. But
in case the concern is valid, I thought I'd propose a potential solution,
if for no other reason than to find out if anyone else can think of
something better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20140318/a87b86a4/attachment.htm>
More information about the pve-devel
mailing list