search

awatson1978 / clinical-nightwatch

Ultra-easy acceptance testing for your Meteor app with Selenium and Nightwatch.
21 stars 3 forks source link

Permission issues #9

Closed guysmoilov closed 9 years ago

guysmoilov commented 9 years ago

Why in your instructions you always say to do chmod 777? Is this really necessary and recommended? I would never want to do this on files that I execute! There must be a safer way to work. Does Nightwatch run as some kind of dummy user or something? Why not just work with my own user permissions (chmod 755 or even 700)?

Also, these lines in run_nightwatch.sh don't make much sense:

TODO cd into the app dir as PWD

echo "Changing file permissions..."

Setup: changing file permissions"

mkdir -p .meteor/local/build/programs/server/assets/packages/clinical_nightwatch chmod +x .meteor/local/build/programs/server/assets/packages/clinical_nightwatch/launch_nightwatch*.sh chmod +x .meteor/local/build/programs/server/assets/packages/clinical_nightwatch/selenium/selenium-server-standalone-2.44.0.jar

You're creating a dir and immediately assuming there are files inside it? The script crashed at this point for me....

guysmoilov commented 9 years ago

OK, the script crashed because I didn't run meteor before trying to run run_nightwatch.sh for the first time, but the point is still valid. If running meteor is what's creating these files, then the mkdir above still doesn't make sense.

awatson1978 commented 9 years ago

Calm down already. The new meteor packaging system doesn't retain executable permissions, and Nightwatch is a very resource intensive package, requiring launching multiple processes and creating multiple files. The chmod solution is better than running the whole thing with sudo, which it used to do, so be thankful. We have identified a solution that can remove the script altogether, but it's still a few weeks away. If you'd like to run 755 instead of 777, feel free. I'm only documenting what works for me.

Closing because of the aggressive and confrontational tone of this issue.

guysmoilov commented 9 years ago

Sorry, didn't mean to sound aggressive, that really wasn't my intention... I do however think it's dangerous to tell people by default to do chmod 777 on executable files...

awatson1978 commented 9 years ago

Feel free to publish these kinds of packages on your own, and you'll see how best practices run up against the realities of deployments in zero time flat. Thank you for registering your concern. When you start publishing packages, feel free to follow whichever technology best practices you wish. In the meantime, you're being ungrateful when somebody has taken the time and effort to share their process for your benefit. Your concerns are duly noted.