Domanda

HomeBrew per le mie esigenze di porta (sembra un po 'più “pulito” rispetto MacPorts).

I può installare senza sudoing (che è grande), ma il collega passo uomo sembra richiedere esso (/usr/local/share/man/man3 è di proprietà di root).
Un I TROVATO suggerisce I ricorsivamente chown /usr/local facendo

sudo chown -R `whoami` /usr/local

Questa funzione è sicura ... o è una cattiva idea ™?

Inoltre:? Sono le mie autorizzazioni corrette

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis
È stato utile?

Soluzione

Di solito è meglio tenere i permessi più possibile rigorose circa. Mantenere /usr/local di proprietà di mezzi root che elabora solo che corrono come root / sudo (o chiedere utente admin tramite la finestra di dialogo di autorizzazione di Apple) può scrivere a questa zona. Così, un download processo deve chiederà una password prima di corrompere i file lì.

Ma, come si dice, rende l'aggiunta di nuovi programmi più difficile.

Io sono OK con sudo di marcia, come si installa cose meno spesso di quanto loro esecuzione, ma si deve la fiducia che il processo di compilazione non cambia nulla dovrebbe.

Se si vuole evitare sudo vorrei installare Homebrew in ~/usr/local e modificare il vostro percorso, manpath ecc per includere le directory sotto là.

Un modo migliore è quello di creare un altro utente-diciamo, homebrew e creare una directory di proprietà di quell'utente. Poi, l'installazione non utilizzando sudo -U homebrew. Altri utenti avranno il vantaggio di non essere in grado di sovrascrivere qualsiasi altro file, in quanto non sono in esecuzione come root e altri programmi non possono influenzare homebrew. (Faccio notare che il Homebrew FAQ suggerisce questo nuovo utente, se ci si trova in un "ambiente multiutente ". direi che qualsiasi macchina Unix compreso MacOS è un ambiente multi-utente)

Tuttavia, come il wiki Homebrew dice che le ricette non trovano tutti i casi di /usr/local e sostituirli con la directory scelta Ho il sospetto che siamo bloccati con /usr/local.

Altri suggerimenti

Io uso Homebrew troppo e può confermare che è totalmente sicuro. Citando il href="https://docs.brew.sh/FAQ#why-does-homebrew-prefer-i-install-to-usrlocal" rel="nofollow noreferrer"> pagina installazione Homebrew FAQ :

Fatevi un favore e scegliere /usr/local

  1. E 'più facile
    /usr/local/bin è già nella tua PATH.

  2. E 'più facile
    Tonnellate di script di build rompono se le loro dipendenze non si trovano in / usr o / usr / local. Possiamo risolvere questo problema per le formule Homebrew (anche se non lo facciamo sempre di prova per esso), ma vi accorgerete che molti RubyGems e script di installazione Python pausa che è qualcosa al di fuori del nostro controllo.

  3. E 'sicuro
    Apple ha conformazione a POSIX e lasciato questa directory per noi. Il che significa che non esiste una directory /usr/local di default, quindi non c'è bisogno di preoccuparsi di rovinare gli strumenti esistenti.

Se si prevede di installare le gemme che dipendono birre quindi risparmiare un po 'di fastidio e l'installazione di /usr/local!

Non è banale dire gemma di guardare nella directory non-standard per le intestazioni e dylibs. Se si sceglie /usr/local, tutto “funziona!”

mi limiterò a aggiungere che fare le cose come root è una pessima idea , quindi chowning /usr/local non sembra solo ragionevole per me (non è una directory di sistema su OSX), ma sano di mente .

I tuoi autorizzazioni non sono corretti (ancora). Basta eseguire il comando che hai elencato e si sta andando bene.

Se avete altri problemi ricordano, il brew doctor può aiutare!

Se stai usando Homebrew, si dovrebbe dare il permesso di scrittura al gruppo specifico (sia admin o staff), in modo che i file possono essere condivisi tra gli utenti che si trovano in quel gruppo.

Ad esempio:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Quindi assegnare gli utenti che dovrebbero avere accesso ai comandi brew a quel gruppo (controllare i gruppi tramite: id -Gn).

Poi, quando si lavora con brew, non correre con sudo.

Quando si continua ad avere qualche problema di autorizzazione, brew doctor eseguire per risolvere il problema.

Per quel che vale, /usr/local non è considerata una cartella "sistema" da OS X, e su un nuovo Snow Leopard installare tale cartella è vuota.

Ogni roba radice di proprietà in quella cartella è il risultato di sudo make install su altri software, o dare la password dopo aver fatto doppio clic su un .pkg che vuole scaricare roba nel /usr/local.

Possedere /usr/local ha "lavorato per me" su 2 macchine per oltre un anno.

Un punto è che se avete installato MySQL (se non utilizzano Homebrew) e Chown suoi file, allora probabilmente non sarà in grado di vedere più (i suoi database in modo che avrebbe dovuto chown di nuovo a qualunque utente di MySQL è in esecuzione come.)

Come in Homebrew 1.0.0:

Homebrew non ha più bisogno di avere la proprietà di / usr / local. Se desideri è possibile restituire / usr / local per la sua proprietà di default con: sudo chown root: wheel / usr / local

Credo che sia bene per gli utenti di avere permessi di scrittura per /usr/local - dopo tutto, questo significa che non si sta usando sudo su ogni script di build. Non mi piace l'idea di un utente ordinario possedere /usr/local. Preferirei avere radice (o simile) proprio /usr/local, ma cambiare i permessi in modo che gli utenti (o almeno alcuni gruppo privilegiato) possono scrivere ad esso. Che sembra l'approccio concettualmente corretto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a apple.stackexchange
scroll top