currently,
drush rsync @site1 @site2
can only be made to work if the target alias' specified 'remote-user' has ssh access rights at the remote-host.
once connected, 'drush rsync' saves the files/dirs to the remote-host's filesystem as uid:gid of the ssh-logged-in user.
i want the files/dirs at remote-host saved as a *different* uid:gid (e.g., wwwrun:www) that does/will NOT have ssh access rights.
doable with git + hooks.
also doable by 'ssh root@ "chown -R wwwrun:www ', after the rsync step. clumsy.
with out-of-the-box '(drush) rsync' it's not immediately apparent that can be done.
it *can* be done if rsync*d config is used (from my OP @
http://drupal.stackexchange.com/questions/24898/can-i-drush-rsync-with-chown-destination-additional-command-or-in-config):
rtfm'ing @ `man rsync`
USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION
then @siteB
mkdir -p /path/to/target
chown -R wwwrun:www /path/to/target
vi /etc/rsyncd.conf
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
hosts deny = *
use chroot = no
[siteB]
path = /path/to/target
hosts allow = *
comment = COMMENTS
uid = wwwrun
gid = www
read only = no
list = yes
and @local
whoami
locuse
ls -al ~/SourceDir
total 240K
drwxrwxrwx 2 locuse users 4.0K Mar 8 10:42 ./
drwxr-xr-x 27 locuse users 4.0K Mar 8 10:41 ../
-rw-r--r-- 1 locuse users 5.2K Mar 8 10:43 file1.txt
-rw-r--r-- 1 locuse users 2.8K Mar 8 10:43 file2.txt
rsync -av --rsh=ssh ~/SourceDir/ root@siteB.loc::SiteB
then checking, @ remote,
ls -al /path/to/target
total 240K
drwxrwxrwx 2 root root 4.0K Mar 8 10:42 ./
drwxr-xr-x 27 wwwrun www 4.0K Mar 8 10:41 ../
-rw-r--r-- 1 wwwrun www 5.2K Mar 8 10:43 file1.txt
-rw-r--r-- 1 wwwrun www 2.8K Mar 8 10:43 file2.txt
ends up with exactly the end-state i'm after.
it'd be useful to add alias definition support to 'drush rsync to allow some other option to specify append text to the target site'.
in concept,
$aliases['siteB'] = array(
'remote-host' => 'siteB.loc',
'remote-user' => 'root',
'root' => '/path/to/target',
...
'command-specific' => array(
...
'rsync' => array (
'mode' => 'rlptDz',
'bin-args' => '-av --rsh=ssh',
'target-append' => '::SiteB'
),
),
allowing a simple invoke of
drush rsync @siteA @siteB
might be a start to do what's intended.
Comment | File | Size | Author |
---|---|---|---|
#3 | rsyncd-modules.patch | 4.12 KB | greg.1.anderson |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedOthers can comment more deeply, but I wil lsay that drush rsync isn't designed to solve everyone's needs. This looks like an edge case to. Feel free to write own drush command that solves your needs. Note that you can use parts like drush sql-dump, sql-query --input-file, and so on.
Comment #2
locuse CreditAttribution: locuse commentediiuc, 'drush rsync' is a deployment convenience tool. nothing it does can't be done with more trouble/effort at the command line using git/rsync/etc directly.
usually, one deploys to a website docroot. that sure seems like a frequent use-case, not an edge-case.
that docroot is required to be under the webserver's uid:gid.
infrequently, if ever, is it wise to provide remote ssh access to the webuser.
without this capability, 'drush rsync' currently drops the files as uid:gid *other* than that which they need to be.
that requires a subsequent *manual* change of ownership.
imo, that hardly qualifies as a convenience ...
all that's being asked for is for drush NOT to limit rsync's capaibilities, and to use what's provided -- namely the already existing rsyncd-capabilities.
Comment #3
greg.1.anderson CreditAttribution: greg.1.anderson commentedIf you don't want to limit rsync's capabilities, then you can call rsync directly. `drush dd` can be used to evaluate paths for you. The limitations in #2 are not severe; as I said on stackexchange, you can set up a user to sync with, and the uid will be set correctly.
That said, it doesn't seem too unreasonable to me to include support for rsync modules. Here's a simple patch to start things off. I am unlikely to push this to completion, but with help (testing and unit tests), maybe it could go in.
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commentedOh, 'bin-args' are not needed; just do this:
Also, guidance is needed on what the correct syntax is when there is both a module name and a path. The rsync manual was unclear on this point.
Comment #5
locuse CreditAttribution: locuse commentedlooking at your patch, what'd be the intended behavior for the case where,
is overridden by a command line of
drush rsync @siteA @siteB --rsh=ssh --module-name=siteB
?
i *think* that's getting addressed @
but i'm not entirely clear.
the function i'd assume is that if module-name is !empty, is defined @remote's rsyncd.conf, and is a valid filesystem path @remote, then it'd completely override any specification of "'root' =>" in the aliases file?
EDIT:
i'm blind as a bat, sorry.
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe way I implemented it was
rsync /soure/path user@remote::modulename:/path
, but I don't know if that's right. If some other syntax is needed, it would not be hard to adjust.Comment #7
locuse CreditAttribution: locuse commentedaccording to the 'rsyncd.conf' man page,
http://linux.die.net/man/5/rsyncd.conf
Module Parameters
path
This parameter specifies the directory in the daemon's filesystem to make available in this module. You must specify this parameter for each module in CWrsyncd.conf.
note the "must specify". i.e., if a module is defined in 'rsyncd.conf', then, iiuc, it must have a 'path=/full/file/system/path' spec.
if that's specified, valid and used, then, i believe
should be used.
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe patch in #3 will work per #7 for remote rsync args
@site
(without a path), and will break if you use@site:/path
. The later should cause drush to generate an error rather than the current behavior, which should cause rsync to generate an error.Comment #9
greg.1.anderson CreditAttribution: greg.1.anderson commentedSince rsync modules require one module per path, I'm not sure this is a great Drush feature. You configure your system to rsync code from local to live by setting a module name in target-command-specific, and sync %files from live to local by setting a module name in source-command-specific, but it would be awkward to do anything more general-purpose than this.
Clever patches that elegantly support rsync modules are welcome, but I'm not going to work on this further.
Comment #10
locuse CreditAttribution: locuse commentedthe patch worked; i was going to share the results. but, since supporting the frequent use-case within the 'drush' wrapper is not something this group is, apparently, interested in, we're relegated to the underlying tools.
in that case, i honestly don't see any reason to use/workaround drush as a complicating, additional layer.
i'll stick with git and rsyncd.
thanks.