Ausführen von Composer ohne Verwendung von sudo (versucht, Besitzer und Berechtigungen zu ändern)

Jedes Mal, wenn ich Composer (zB sudo composer install, sudo composer self-update) starte, muss ich dies mit sudo ausführen, da der Eigentümer der Datei root ist.

Jedes Mal, wenn ich den Composer mit sudo root verwende, gehört der Vendor-Ordner und dann muss ich den Besitzer dieses Ordners / dieser Berechtigungen von root in www-data ändern.

Was ist der beste Weg, um dies zu beheben, damit ich nicht jedes Mal sudo ausführen muss?

Eigentümer von /usr/local/bin/composervon root auf www-data ändern ?

Ist dies die ideale Möglichkeit, um zu vermeiden, dass bei jeder Verwendung von sudo der Besitzer gewechselt und Berechtigungen zugewiesen werden müssen composer install?

Bearbeiten: Die Berechtigungen für den Komponisten sind derzeit -rwxr-xr-x. Und ich habe versucht , den Besitzer des Umschaltens /usr/local/bin/composerauf über www-data:www-datamit Berechtigungen auf 775, und noch kann ich nicht Komponist laufen ohne Laufen sudo.

14.04 sudo root

— reite den Wirbelwind
quelle

Antworten:

Wenn "jeder" den Komponisten lesen und ausführen darf, muss sudo nicht verwendet werden:

sudo chmod 755 /var/local/bin/composer

Da Sie composer bereits mindestens einmal als ausgeführt haben root, befindet sich das Cache-Verzeichnis composers (pro Benutzer) jetzt im Besitz von root und kann daher von Ihrem normalen Benutzer nicht mehr beschrieben werden.

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

behebt den Dateieigentümer.

— tkausl
quelle

Ich habe es versucht und kann immer noch nicht composer self-updateohne sudo laufen . Muss ich 775 verwenden?

— Fahren Sie mit dem Wirbelwind am

Selbstaktualisierung funktioniert mit 755 nicht, aber ist das wichtig? Selbstaktualisierung ist nichts, was Sie jeden Tag ausführen müssen. Aktualisieren Sie sie einfach alle 2 Wochen oder so (mit sudo natürlich).

— Tkausl

Versucht composer updateund dies funktioniert auch nicht mit diesen Berechtigungen. Ich muss immer noch zuerst sudo verwenden. Dies ist der Fehler, den ich bekomme

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

— reite den Wirbelwind am

Oh, ja, Sie haben bereits "sudo" verwendet, um einige Ihrer Deps zu aktualisieren. Ich denke, "/home/lamp/.composer/" gehört root. Löschen Sie einfach diesen Ordner (es ist nur ein Cache), dann sollte es ohne funktionieren sudo. (Oder der Besitzer wechseln: chown -R lamp:lamp /home/lamp/.composer)

— tkausl

Das war der Trick, ging mit dem Besitzerwechsel zur Lampe. Kannst du deine Antwort aktualisieren und ich akzeptiere sie? Danke takusl

— reite den Wirbelwind

Ich beschäftige mich seit Wochen mit diesem Problem.

Ich denke, die Lösung ist, Composer-Selbst-Update mit der -H auszuführen

sudo -H composer self-update

Bevor Sie dies tun, müssen Sie die Verzeichnisse .composer im Stammverzeichnis und das Ausgangsverzeichnis des Benutzers entfernen, den Sie composer ausführen möchten.

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

Wenn Sie die Selbstaktualisierung von sudo composer ohne das Flag -H ausführen, wird ~ / .composer erstellt, dessen Eigentümer root ist, und es wird verhindert, dass andere composer-Befehle Berechtigungsfehler aufweisen.

composer config
composer install

Meiner Meinung nach sollte das Aufrufen von sudo composer self-update keine Dateien im Stammverzeichnis des aktuellen Benutzers erstellen.

Beachten Sie, wenn Sie diese Anweisungen auf Ubuntu 14.04 Composer befolgen, wird der Cache in:

 ~/.cache/composer

Eher, als:

~/.composer/cache

Dies liegt an der in Ubuntu 14.04 definierten Umgebungsvariablen XDG_RUNTIME_DIR, die jedoch in Ubuntu 12.04 offenbar nicht definiert ist

Eine verwandte Diskussion hier

— Iteriere
quelle

Dies ist nicht hilfreich, wenn Sie bereits die aktuellste Version von Composer verwenden. $ sudo -H composer self-update $ You are already using composer version 1.3.0 (stable channel).

— Cragmonkey

@Cragmonkey - Ich habe die neueste Version von Composer ausgeführt, aber nur das Entfernen des ~/.composerOrdners scheint das Problem zu lösen.

— Cyclonecode