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.

CommentFileSizeAuthor
#3 rsyncd-modules.patch4.12 KBgreg.1.anderson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

Others 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.

locuse’s picture

iiuc, '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.

greg.1.anderson’s picture

Status: Active » Needs review
FileSize
4.12 KB

If 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.

greg.1.anderson’s picture

Oh, 'bin-args' are not needed; just do this:

'command-specific' => array(
			'rsync' => array (
				'mode' => 'rlptDz',
				'rsh'      => 'ssh',
				'module-name' => 'SiteB'
			),
		),

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.

locuse’s picture

looking at your patch, what'd be the intended behavior for the case where,

vi aliases.drushrc.php
	...
	$aliases['siteB'] = array(
		'remote-host' => 'siteB.loc',
		'remote-user' => 'root',
		'root'   => '/path/to/default/root',
		...
	);

is overridden by a command line of

drush rsync @siteA @siteB --rsh=ssh --module-name=siteB

?

i *think* that's getting addressed @

+  if ((empty($module_name_option)) && (empty($path) || (!drush_is_absolute_path($path, "LOCAL")))) {
     $path = $drupal_root . $path;

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:

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.

i'm blind as a bat, sorry.

greg.1.anderson’s picture

The 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.

locuse’s picture

according 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

-   rsync /source/path user@remote::modulename:/path
+   rsync /source/path user@remote::modulename

should be used.

greg.1.anderson’s picture

The 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.

greg.1.anderson’s picture

Status: Needs review » Needs work

Since 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.

locuse’s picture

Status: Needs work » Closed (won't fix)

the 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.