#[SOLVED] question: `brew install [package]` fails in default config, is this expected?

1 messages · Page 1 of 1 (latest)

echo dew
#

what's the output of ls -al /home/linuxbrew/.linuxbrew?

echo dew
#

yeah so this is the cause of the issue. Currently the way secureblue sets up homebrew, it hard-codes that it's owned by UID 1000, that is, the first ordinary (non-system) user created on the system

#

you can change the ownership to your main login user by running this command:

run0 -i chown -R user:user /home/linuxbrew

(replacing user with your username)

#

but this will then break the brew auto-update services since those assume UID 1000 as well

#

so to fix that, you'd need to add systemd overrides to the systemd user units brew-update.service, brew-update.timer, brew-upgrade.service, and brew-upgrade.timer changing ConditionUser=1000 to ConditionUser=user (again, replacing user with your username)

#

and yes, this situation with hardcoding UID 1000 is not ideal

#

Royal and I have discussed switching to using my "brew-proxy" approach to homebrew and we'll probably do that after Fedora 44 releases—this will mean that the homebrew installation is owned by a dedicated "linuxbrew" system user and any user can request to run brew commands but will be asked to authenticate for certain commands

#

(this will work better on multi-user setups as well)

echo dew
#

having different parts of the homebrew installation owned by different users is a Bad Idea and would probably break more things lol

#

I think it would probably be simpler to change the UID of your existing user, which you can do with the usermod command... you'd need to free up UID 1000 first though, so change the UID of admin first (maybe to 1002, if that's free) and then the UID of user

#

just make sure that you have some account in the wheel group at all times—if you were to delete the admin account without making another wheel-group user first, you'd have no way to get a root shell and would be locked out of the system

#

which you could fix by mounting the filesystem from a live USB and manually editing /etc/passwd, but it'd still be a nuisance to fix

rich sandal
#

[SOLVED] question: brew install [package] fails in default config, is this expected?

echo dew
#

the ISO installer is going to change with the F44 release so I think we should wait until then to make changes to the install instructions

#

also brew is the only thing hardcoded to UID 1000 so once we change that, it won't actually matter which order the user creates the accounts in

onyx hatch
echo dew
#

(the implementation is done but it'll need to be reviewed and tested first)

onyx hatch
#

(sorry if this is a stupid question lol)

echo dew
#

it's a reasonable question, and yes, there will be a migration service that will change ownership and permissions in the background to ensure the transition is basically seamless for existing users

onyx hatch
echo dew
#

I believe the installation is created with 755 permissions, but the default umask is 027, so additional files and directories created later by the user will be created with 750 (for directories) or 640 (for non-executable files) permissions

#

the migration service will fix up all these permissions

#

as you've probably noticed if you tried to use homebrew on a multi-user system, the current setup very much is not designed to work with multiple users

onyx hatch
echo dew
#

lol yeah part of the motivation for brew-proxy was me trying to figure out how to allow multiple users to manage a brew installation in a sensible way, and coming to the conclusion that having the installation owned by a dedicated system user was the best way

onyx hatch
echo dew
#

what do you want the permissions to be?

onyx hatch
#

do i just do the command above for all of the directories i messed up on?

echo dew
#

chown is for changing ownership, not permissions