If you use drush fserver-package to update packages from a git repository, it seems to work but spits out the following errors:

WD php: sprintf(): Too few arguments in /usr/local/src/drush/includes/drush.inc on line 1269.                                                        [error]
WD php: sprintf(): Too few arguments in /usr/local/src/drush/includes/drush.inc on line 1269.                                                        [error]
WD php: chmod(): Operation not permitted in /usr/local/src/drush/includes/drush.inc on line 1164.                                                    [error]
WD php: chgrp(): Operation not permitted in /usr/local/src/drush/includes/drush.inc on line 1164.                                                    [error]

(updated project info here)

sprintf(): Too few arguments in /usr/local/src/drush/includes/drush.inc on line 1269.                                                                [warning]
sprintf(): Too few arguments in /usr/local/src/drush/includes/drush.inc on line 1269.                                                                [warning]
chmod(): Operation not permitted in /usr/local/src/drush/includes/drush.inc on line 1164.                                                            [warning]
chgrp(): Operation not permitted in /usr/local/src/drush/includes/drush.inc on line 1164.                                                            [warning]

Additionally, it complains if the URI isn't specified - but is the URI really necessary if the command is run from within a site directory?

CommentFileSizeAuthor
#5 0001-Fixing-error-notices.patch948 bytesdanepowell

Comments

danepowell’s picture

danepowell commented
Priority: Normal » Major

Actually upon further inspection, the command does NOT produce a good tarball- strangely, the tarball appears to be empty if exploded in a Windows environment (using 7zip). It unpacks just fine in Ubuntu.

danepowell’s picture

danepowell commented

Woah... if I just copy the file to my home directory and then via FTP to my Windows machine, it opens just fine. But if I download it via the web to my Windows machine and open it, the directory is empty. How weird is that? I suspect this problem must be related to these errors.

danepowell’s picture

danepowell commented
Priority: Major » Normal

Sorry for the confusion- it turns out that the tarball bug was due to caching serving up a stale version of the file. The tarball seems to be just fine, so you can ignore #1 and #2. But the original drush errors still persist.

eugenmayer’s picture

eugenmayer commented

Confirm those errors on my installation on fserver-package. Most of the work which could be affecting this is the new git-tag detection. I will need to debug this to see the stacktrace.

danepowell’s picture

danepowell commented
StatusFileSize
new 0001-Fixing-error-notices.patch948 bytes

Well half of the errors are easy to fix (see attached patch)

The other errors are due to drush trying to chmod the files/fserver folder. If drush actually created that folder (i.e. if the very first fserver release on your site was from a git or svn repo), then drush also has permissions to chmod it, so no problem. However, if the webserver created the folder (if your first release was a manual package upload), then drush will NOT have permission to edit the folder.

I'm not really sure what the solution is. For me, I was able to "chown aegir:www-data files/fserver", but obviously this won't work for everybody, as the drush user doesn't have to be 'aegir'.

danepowell’s picture

danepowell commented
Status: Active » Needs work
eugenmayer’s picture

eugenmayer commented

Good work Dane!

For the chmod isseu: I think we just should detect that this is not possible and give a meaningful error message in the console, thats it. What do you think?

danepowell’s picture

danepowell commented

I think line 392 (drush_op('chmod', $file_path, 0775);) is actually unnecessary- on a fresh install of Drupal, commenting out that line and running drush fserver-package, the fserver folder is already created with 0775 permissions. So unless there's something unique about my setup, I think that line should just be removed.

There's a comment at the top of fserver.drush.inc that I think is relevant...

<?php
/**
@TODO:
(10:38:30 AM) Adrian Rossouw: if you need drush to be able to modify the files dir
(10:38:47 AM) Adrian Rossouw: you need to add : umask(0002) to your settings.php
(10:38:53 AM) Adrian Rossouw: drupal 6.x has a crazy bug in it
(10:39:10 AM) Adrian Rossouw: that all uploaded files are 600 , owned by the web server user
(10:39:15 AM) Adrian Rossouw: so your drush script can't modify it
(10:39:20 AM) Adrian Rossouw: or change the perms, or anythin
*/
?>

... but wrong :) Like I said, it appears that files are created by default with 775, not 600... so either this 'crazy bug' has been fixed, or there's something unique about my setup.

eugenmayer’s picture

eugenmayer commented

Well we should be aware about this. This could be e.g. related to your umask for the aegir / host / script user or your default system-umask. We should verify that this bug has been fixed in D6, AFAIR it has not been

danepowell’s picture

danepowell commented

Ah yes, I just double-checked and the umask in use is 002- so in general, the permissions may not be as lenient for all users, and they might need to be set manually. Sorry about any confusion.

eugenmayer’s picture

eugenmayer commented

Ok, so our consensus would be, checking if we can change the permissions and if not, we notify the user with something like

"Failed changing permissions of folder XYZ to 755 due to wrong ownership. Please fix this using a privileged user yourself by running `chmod XYZ 755`"

What do you think?

danepowell’s picture

danepowell commented

Sounds good

bforchhammer’s picture

bforchhammer commented

Note that the command drush fserver-distro also throws the chgrp() error a bunch of times...

cyberwolf’s picture

cyberwolf commented

Subscribing.