Uruchamianie Composer bez korzystania z sudo (próbowano zmienić właściciela i uprawnienia)

Za każdym razem, gdy uruchamiam kompozytora (np. sudo composer install, sudo composer self-updateItp.), Muszę uruchamiać to z sudo, ponieważ właścicielem pliku jest root.

Jednak za każdym razem, gdy korzystam z kompozytora z sudo root jest właścicielem folderu dostawcy, a następnie muszę zmienić właściciela tego folderu / uprawnień z root na www-data.

Jak najlepiej to naprawić, aby nie musiałem uruchamiać sudo za każdym razem?

Zmienić właściciela /usr/local/bin/composerz root na www-data?

Czy to idealny sposób, aby sobie z tym poradzić, aby uniknąć konieczności zmiany własności i przypisywania uprawnień za każdym razem, gdy używam sudo composer install?

Edycja: uprawnienia dla kompozytora są obecnie -rwxr-xr-x. Próbowałem też zmienić właściciela /usr/local/bin/composerna www-data:www-dataz uprawnieniami ustawionymi na 775 i nadal nie mogę uruchomić kompozytora bez uruchamiania sudo.

14.04 sudo root

— jeździć wicher
źródło

Odpowiedzi:

Jeśli „wszyscy” mogą czytać i uruchamiać kompozytora, nie musisz używać sudo:

sudo chmod 755 /var/local/bin/composer

Ponieważ co najmniej raz wykonałeś już kompozytora root, katalog pamięci podręcznej kompozytorów (na użytkownika) jest teraz własnością root i dlatego nie jest zapisywalny dla zwykłego użytkownika.

sudo chown -R lamp:lamp /home/lamp/.composer

naprawi właściciela pliku.

— tkausl
źródło

Próbowałem tego i nadal nie mogę uruchomić composer self-updatebez użycia sudo. Czy muszę używać 775?

— jeździć wicherami

Samo-aktualizacja nie będzie działać z 755, ale czy to ma znaczenie? samodzielna aktualizacja to nic, co musisz wykonywać codziennie, po prostu aktualizuj ją co około 2 tygodnie (z sudo oczywiście).

— tkausl

Próbowałem composer updatei to również nie działa z tymi uprawnieniami. Nadal muszę najpierw użyć sudo. To jest błąd, który dostaję

file_put_contents(/home/lamp/.composer/cache/repo/https---packagist.org/packages.json): failed to open stream: Permission denied

— jeździć trąby powietrznej

ooh, tak, już użyłeś „sudo” do aktualizacji niektórych swoich deps, myślę, że „/home/lamp/.composer/” jest własnością root, po prostu usuń ten folder (to tylko pamięć podręczna), a następnie powinien działać bez sudo. (Lub własność zmiana: chown -R lamp:lamp /home/lamp/.composer)

— tkausl

To załatwiło sprawę, polegało na zmianie właściciela na lampę. Czy możesz zaktualizować swoją odpowiedź, a ja ją zaakceptuję? Dzięki takusl

— jeździć trąby powietrznej

Zajmowałem się tym problemem od tygodni.

Myślę, że rozwiązaniem jest uruchomienie automatycznej aktualizacji kompozytora z opcją -H

sudo -H composer self-update

Zanim to zrobisz, usuń katalogi .composer w katalogu głównym i katalog domowy użytkownika, którego chcesz uruchomić.

sudo rm -rf /root/.composer
sudo rm -rf /home/ubuntu/.composer

Uruchomienie automatycznej aktualizacji sudo kompozytora bez flagi -H spowoduje utworzenie ~ / .composer, którego właścicielem jest root, i zapobiegnie błędom uprawnień innych poleceń kompozytora.

composer config
composer install

Moim zdaniem wywołanie samodzielnej aktualizacji kompozytora sudo nie powinno tworzyć plików należących do roota w bieżącym katalogu domowym użytkowników.

Uwaga: jeśli postępujesz zgodnie z tymi instrukcjami na Ubuntu 14.04 kompozytor umieści pamięć podręczną w:

 ~/.cache/composer

Zamiast:

~/.composer/cache

Wynika to ze zmiennej środowiskowej XDG_RUNTIME_DIR zdefiniowanej w Ubuntu 14.04, ale wydaje się, że nie jest zdefiniowana w Ubuntu 12.04

Powiązana dyskusja tutaj

— Powtarzać
źródło

To nie pomaga, jeśli masz już najnowszą wersję kompozytora. $ sudo -H composer self-update $ You are already using composer version 1.3.0 (stable channel).

— Cragmonkey

@Cragmonkey - Uruchomiłem najnowszą wersję kompozytora, ale samo usunięcie ~/.composerfolderu wydaje się rozwiązać problem.

— Kod cyklonowy