Drush is changing permissions on the target root (@stage) 755 to 750 and overwritting .htaccess (@stage) When I run drush rsync @dev @stage How can I prevent these two actions? As ever, I'm sure there is a documentation or discussion on these matters. I'm not clear from example.aliases.drushrc.php thanks -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com
* Tim Johnson <tim@akwebsoft.com> [121215 14:42]:
Drush is changing permissions on the target root (@stage) 755 to 750 and overwritting .htaccess (@stage) When I run drush rsync @dev @stage How can I prevent these two actions?
As ever, I'm sure there is a documentation or discussion on these matters. I'm not clear from example.aliases.drushrc.php
I have not been successful in excluding .htaccess using the alias file, but the --exclude-path command line option seems to work. I executed the following : drush -v --exclude-paths=".htaccess:robots.txt" rsync @lb.workstation @lb.hostmonster where '-v' gives me a look at what rsync is actually doing, and '--exclude-path' provides a string of file names delimited by ':' (colon) which should be ignored by drush. But drush is still changing permissions to 750 on the root directory on the remote server. This disables the site until I reset the permissions to 755. -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com
On Sat, Dec 15, 2012 at 8:47 PM, Tim Johnson wrote:
But drush is still changing permissions to 750 on the root directory on the remote server. This disables the site until I reset the permissions to 755.
DocumentRoot should never be able to be read by others. Drush is doing a good thing here. The DocumentRoot group should match that of the user id executing httpd. This would allow the httpd user to read the DocumentRoot directory with 750 permissions. -- Earnie -- https://sites.google.com/site/earnieboyd
* Earnie Boyd <earnie@users.sourceforge.net> [121217 04:24]:
On Sat, Dec 15, 2012 at 8:47 PM, Tim Johnson wrote:
But drush is still changing permissions to 750 on the root directory on the remote server. This disables the site until I reset the permissions to 755.
DocumentRoot should never be able to be read by others. Drush is doing a good thing here. The DocumentRoot group should match that of the user id executing httpd. This would allow the httpd user to read the DocumentRoot directory with 750 permissions. Thanks Ernie. I will contact the hoster for the appropriate way to handle this. cheers -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com
* Earnie Boyd <earnie@users.sourceforge.net> [121217 04:24]:
On Sat, Dec 15, 2012 at 8:47 PM, Tim Johnson wrote:
But drush is still changing permissions to 750 on the root directory on the remote server. This disables the site until I reset the permissions to 755.
DocumentRoot should never be able to be read by others. Drush is doing a good thing here. The DocumentRoot group should match that of the user id executing httpd. This would allow the httpd user to read the DocumentRoot directory with 750 permissions. According the techs at hostmonster (this is a _shared_ hosting), all site roots *must* be 755.
I also escalated my question to their upper-level techs with Ernie's statement above quoted, but have yet to get a reply. It seems that what drush is doing is simply setting the same permissions as the source site. I.E. when I push content from my workstation where permissions are 750, then drush sets the target as 750, but when I changed the permissions on the workstation to 755, drush obliging left them at 755 on the remote hostmonster server. I think my brain is going to explode.... after 17 years of web programming and 12 on *nix systems, I still feel like a flipping noob... -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com
On Mon, Dec 17, 2012 at 3:28 PM, Tim Johnson <tim@akwebsoft.com> wrote:
* Earnie Boyd <earnie@users.sourceforge.net> [121217 04:24]:
On Sat, Dec 15, 2012 at 8:47 PM, Tim Johnson wrote:
But drush is still changing permissions to 750 on the root directory on the remote server. This disables the site until I reset the permissions to 755.
DocumentRoot should never be able to be read by others. Drush is doing a good thing here. The DocumentRoot group should match that of the user id executing httpd. This would allow the httpd user to read the DocumentRoot directory with 750 permissions. According the techs at hostmonster (this is a _shared_ hosting), all site roots *must* be 755.
I also escalated my question to their upper-level techs with Ernie's statement above quoted, but have yet to get a reply.
It seems that what drush is doing is simply setting the same permissions as the source site. I.E. when I push content from my workstation where permissions are 750, then drush sets the target as 750, but when I changed the permissions on the workstation to 755, drush obliging left them at 755 on the remote hostmonster server.
I think my brain is going to explode.... after 17 years of web programming and 12 on *nix systems, I still feel like a flipping noob...
Some host companies want you to do the wrong thing. See https://my.hostmonster.com/cgi/help/594 for the suggested corrections. You're probably correct about your client and ftp. You might need to change the permissions on your client to get along with hostmonster service. -- Earnie -- https://sites.google.com/site/earnieboyd
* Earnie Boyd <earnie@users.sourceforge.net> [121218 05:12]:
Some host companies want you to do the wrong thing. See https://my.hostmonster.com/cgi/help/594 for the suggested corrections. You're probably correct about your client and ftp. You might need to change the permissions on your client to get along with hostmonster service.
Thanks Ernie. BTW: I don't see that `drush rsync` uses ftp at all - but that it uses the system rsync to tranfer files. Frankly I have never used rsync myself. I've never seen a FTP process change permissions on existing files, that I can recall. I'm still waiting to here back from the hostmonster techs. In the meantime either changing my client permissions or using ssh to reset the host permissions is a fix. cheers -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com
participants (2)
-
Earnie Boyd -
Tim Johnson