Closed TheKevJames closed 8 years ago
Just curious, what was the original reason for recurse => true,
in there? It seems like the formula should decide what perms its own files have... adding or removing execute permissions for packages themselves feels like it could mess with their own functionality... I even caught a crazy edge case with this module where 'watchman' (from facebook's tap) was creating a socket file in /usr/local/var/run, which caused a puppet error while trying to apply those perms (ignore => 'sock',
fixed that fine though).
My initial impression is that this should only manage perms for folders above what packages might deploy, but maybe I'm missing some context, since it looks like you used to have it that way. Glad to see you're looking at this!!
@kpete The recurse true was set to match this suggestions (http://blog.strug.de/2012/06/my-homebrew-multi-user-setup/) among others on how to make it work on a multi-user system. Happy to help correct the needed permissions. @TheKevJames how are you doing on this?
@kpete The recurse true was set to match this suggestions (http://blog.strug.de/2012/06/my-homebrew-multi-user-setup/) among others on how to make it work on a multi-user system. Happy to help correct the needed permissions.
Ahh that makes sense. I'll see if I end up with a situation where the package itself breaks from it, (not just puppet). Thanks!
@jordigg for the most part, I'm blocked on #53 -- the long test cycles and random timeouts have been making this difficult to work on. I think I'll need to look into #53 first, but I've been way too busy lately. Hopefully I'll have some time over the weekend to look into this.
@jordigg The recursive permissions seem to break logrotate. The default config file placed by the formula is in /usr/local/etc/logrotate.conf, and if logrotate is run as root (necessary to be able to rotate logs owned by root) then it returns: Ignoring /usr/local/etc/logrotate.conf because the file owner is wrong (should be root or user with uid 0).
That makes sense. We should be able to limit the effect of the recurse to a few folders that are really owned by brew. Want to check if it's possible to leave the chmod intact and just rely on the group to allow those members to manage brew in a multi-user environment. I'll finish first with #52 and then work on this.
The change to make the repo location /usr/local/Homebrew in brew 1.0 should help this a lot: https://github.com/Homebrew/install/pull/60/commits/2182f13944db40c11a52ef2b5c9d57b8ea7be384
I'm happy to take a look at this too if time permits. Thanks!
If homebrew is contained on it's own folder is going to make things easier for everyone. Will check if it's already available and how it effects multi-user setup.
As @kpete remarked, homebrew now installs to /usr/local/Homebrew
so this issue was easily solved in #58 . Thanks @kpete and @jordigg for the comments!
For brevity, we currently set 0755 on all of
/usr/local
. This "works" but causes some files to be marked as modified in brew's git status. Those files should be marked with the correct permissions (0644, probably).Big output of
git status
in/usr/local
attached: