puppet-homebrew always changes permissions to 755 on a ton of unrelated Homebrew files

[zbentley]

Sorry for the issue dump. This is the last one, I promise :)

Every time I run puppet with class { homebrew: ...} somewhere, even if Homebrew is already installed, I get a ton of output like:

Notice: /Stage[main]/Homebrew::Install/File[/usr/local/Homebrew/.git/objects/69/db3754c4d5bc95d2c02c86299de29e1cd4b460]/mode: mode changed '0444' to '0775'

Whatever perms fixup is being done here probably doesn't need to be run every single time Puppet runs; just at initial bootstrap.

Also, some of the things being manipulated should probably not be: git internal files etc. should probably not be executable.

If the goal of the perms fixup inside the homebrew::install class is to get ownership correct, it might be better to manage owner/group, rather than perms, and trust the Homebrew installer to get those right. I don't really know if that's what's being done, though.

Thanks!

[jordigg]

This is related to #44 and needs more work.
The point on changing permissions was to make brew work on a multi-user environment allowing all users of a same group to install brew/cask packages.
Puppet changes permissions and checks they are "correct" on every run. Permission on those files are changes by another process back to it's "default" single-user setting so puppet does that action on every single run. The output is big because does it for every single file and folder individually rather than just running a command like chmod -R. I need to give it another look and try to fix it.
Brew was moved a few weeks ago to a new folder which is not shared anymore with other tools which cause lots of permission issues.

[zbentley]

If that's correct behavior, then I'm fine with it; especially if it's likely to be fixed in homebrew core at some point.

However, the reams of output are really hard to handle. Would it be possible to replace the puppet file management of permissions with an exec/chmod -R? It's technically less "correct", but is a lot more usable.

There are other hacks possible as well; a "single user mode" class parameter could be added to homebrew::install that prevents the chmodding, but that seems kind of pointless if this is just a temporary issue.

[jordigg]

Moving to chmod -R would help with the output and would make the puppet runs faster since it won't be doing a one-by-one command but a single one instead.
I'll test that with the new version now that is on a "isolated" folder and see if we can handle multi-user in a better way.

[TheKevJames]

Thanks for looking into this @jordigg . I think another option would be to fine-tune the files we manage a bit more; clearly we don't need to chmod the .git folder, for example. Can we figure out exactly which files in /usr/local/Homebrew need group permissions and then only manage those?

Overall, I do prefer using file to doing an exec with chmod -R, if we can get this to work with a smaller file pool.

[jordigg]

I also need to find why files are reverted to it's original/default chmod 644. I think brew does that and need to know why.
If we want to enable multi-user via groups we need the correct permissions. Right now the module and brew fight each other so on my environment I have all machines modifying permissions on 3k to 4k files on each run (every 30 mins). This is not ideal at all...

[TheKevJames]

Agreed. I assume this is a git thing; since brew's update process is to basically run git reset --hard HEAD && git pull, any permissions changes to tracked files would be lost. Basically, we should only change permissions on untracked files.

Maybe we could parse /usr/local/Homebrew/.gitignore to see which files to modify?

[TheKevJames]

On second thought, have we verified that group permissions are even necessary to run brew as a different user? There have been many brew changes since the article I based the original chmod off of was written.

[jordigg]

This should be fixed with #64

[TheKevJames]

Fixed in #64

[zbentley]

Confirmed fixed. Thanks so much!