Closed jasperf closed 7 years ago
➤ Executing task deploy:writable
[larastud.io] > ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1
[larastud.io] < www-data
[larastud.io] > cd /var/www/larastud.io/releases/3 && (mkdir -p bootstrap/cache storage storage/app storage/app/public storage/framework storage/framework/cache storage/framework/sessions storage/framework/views storage/logs)
[larastud.io] > cd /var/www/larastud.io/releases/3 && (chmod 2>&1; true)
[larastud.io] < chmod:
[larastud.io] < missing operand
[larastud.io] < Try 'chmod --help' for more information.
[larastud.io] > cd /var/www/larastud.io/releases/3 && (if hash setfacl 2>/dev/null; then echo 'true'; fi)
[larastud.io] < true
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p bootstrap/cache | grep "^user:www-data:.*w" | wc -l)
[larastud.io] > cd /var/www/larastud.io/releases/3 && (setfacl -RL -m u:"www-data":rwX -m u:`whoami`:rwX bootstrap/cache)
[larastud.io] > cd /var/www/larastud.io/releases/3 && (setfacl -dRL -m u:"www-data":rwX -m u:`whoami`:rwX bootstrap/cache)
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/app | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/app/public | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/framework | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/framework/cache | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/framework/sessions | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/framework/views | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
[larastud.io] > cd /var/www/larastud.io/releases/3 && (getfacl -p storage/logs | grep "^user:www-data:.*w" | wc -l)
[larastud.io] < 1
• done on [larastud.io]
Permission set by setfacl setfacl -RL -m u:"www-data":rwX -m u:
whoami:rwX bootstrap/cache
Check you setup.
Setting the project directory at 2750
I thought that may do the trick. But the storage directory for example was still 777
. Then I checked man setfacl. setfacl -RL' means to logically and recursively granting user
www-datarwX, user
whoami` (web)rwX for bootstrap/cache . X is only for directory execution. Nothing on the group or the third digit is mentioned here. Then I did a
getfacl larastud.io/
# file: larastud.io/
# owner: web
# group: www-data
# flags: -s-
user::rwx
group::r-x
other::r-x
and saw that other has r-x
. Well with 2755 for the folder that is correct. But it does not have rwx..
Then I checked the umask for web and:
web@larastudio:/var/www$ umask
0002
That is the standard umask for Ubuntu so that should be fine to and would mean directories will be 775 and files 664. And so that does not explain things.
Also realized Storage is only 777
when we are talking the symlink. The directory was 2775
. However, files were still mostly 775 as well and that is still too much. And so still an issue. Perhaps I need an extra permissions task to settle this if there is no cleaner way.
Use can use chown of chmod mode as well. Setfacl applies only to ACL and not affects unix rights
When I use set('writable_mode', 'chmod');
the directories that are part of the laravel recipe are made 755:
➤ Executing task deploy:writable
[larastud.io] > cd /var/www/larastud.io/releases/2 && (mkdir -p bootstrap/cache storage storage/app storage/app/public storage/framework storage/framework/cache storage/framework/sessions storage/framework/views storage/logs)
[larastud.io] > cd /var/www/larastud.io/releases/2 && ( chmod -R 0755 bootstrap/cache storage storage/app storage/app/public storage/framework storage/framework/cache storage/framework/sessions storage/framework/views storage/logs)
• done on [larastud.io]
And other directories seem to get 775 and that is correct based on umask 0002. But some files still seem to get 775 as well:
web@larastudio:/var/www/larastud.io/current$ stat -c "%a %n" *
2775 app
775 artisan
2775 bootstrap
775 composer.json
664 composer.lock
2775 config
2775 database
664 deploy.php
775 package.json
775 phpunit.xml
2775 public
775 readme.md
2775 resources
2775 routes
775 server.php
777 storage
2775 tests
2775 vendor
775 webpack.mix.js
Not all, some. Why is server.php 775 for example. .
Where no commands for chmod server.php
Never mind. Seemed that local files had permissions that were too high too due to the way they were stored cloning Laravel from Github. Once I fixed the directory and file permissions locally using:
jasper@~/webdesign/larastud.io $ find . -type f -print0 | xargs -0 chmod 664
jasper@~/webdesign/larastud.io $ find . -type d -print0 | xargs -0 chmod 775
and the doing a dep deploy
with the lines:
set('writable_mode', 'chmod');
set('writable_chmod_mode', '0775');
all was well. When I did not have set('writable_chmod_mode', '0775');
I had write permission issues for /var/www/larastud.io/current/storage/framework/views
as these files there are www-data
generated and not web
.
Thank you very much for this awesome deployment tool @antonmedv . Appreciate all your work and answering my questions.
P.S. When I did a standard acl setup later on as I still had issues such as
chmod: changing permissions of 'storage/framework/sessions/IyTfM4q89CLShKGlxd
dR1J0onQunSkshN7s7oHjY': Operation not permitted
as they are 644 www-data:www-data generated by Laravel all worked with standard writable_mode
as well. Even after second deployment.
Description
When I deploy I get writable directories as 777 and even files as package.json as 755 which is rather odd. I mean, it should be 775 max for directories and 664 for files. Must be related to my setup with webroot files owner web (deployer user as well and non sudo user) and group www-data and www-data running nginx and such. But I am not sure yet how to remedy this.
Steps to reproduce
Run dep deploy from project directory on local MacBook.
Content of
deploy.php
Output log