Installieren Sie die Anwendung unter /usr/local

Installieren Sie die Anwendung unter /usr/local

Einige Anwendungen, wie z. B. Netbean und JDK, werden oft automatisch installiert /usr/localund ich führe sie als normaler Benutzer (nicht als Root) aus.

Aber eine andere Anwendung extrahiert einfach tar.gzdie Datei und führt sie aus. Als normaler Benutzer kann ich den Befehl nicht verwenden, um von Verzeichnis zu Verzeichnis cpzu kopieren , ich muss den Root-Benutzer (Befehl) verwenden .Download/usr/localsu

Da ich dieses Verzeichnis jedoch als Root-Benutzer kopiere, gehört es Root, sodass ich es nicht als normaler Benutzer ausführen kann. Das bereitet mir Kopfschmerzen. Wie kann ich es als normaler Benutzer ausführen, wie die anderen Anwendungen, die ich oben aufliste? Oder gibt es eine andere Möglichkeit, es zu installieren?

Antwort1

/usr/localund seine Unterverzeichnisse ( bin, lib, share, usw.) sollten (und sind wahrscheinlich auch) Root-Eigentümer sein und auf 755 gesetzt sein, damit jeder dort Dinge ausführen kann.

Wenn du etwas entpackt und hineinkopiert hast, dann kann es an den Berechtigungen der einzelnen Binärdateien liegen, die ebenfalls auf 755 stehen sollten, um eine allgemeine Nutzung zu ermöglichen.

Denken Sie daran, wie $PATHes funktioniert. Ihr Beispiel des JDK mag in dieser Hinsicht verwirrend sein, aber ein normales Tarball, in das Sie ./configureausführbare make installDateien /usr/local/bin, Bibliotheken /usr/local/libund verschiedene Dinge wie Dokumentation irgendwo in ablegen, /usr/local/shareist ein Tarball. Dies sind die entsprechenden Pfade, und Sie müssen demselben Muster folgen. Mit anderen Worten, es /usr/localfunktioniert nicht, Dinge einfach irgendwo in (z. B. ein einzelnes Verzeichnis für das Paket) oder in Unterverzeichnisse von bin/ abzulegen.

Antwort2

Es gibt zwei potenzielle Probleme, über die Sie stolpern könnten.

Erstes Problem - Ausführungsberechtigungen für Verzeichnisse

Die Berechtigungen für eines der Verzeichnisse, die Sie nach /usr/local kopiert haben, sind möglicherweise nicht richtig eingestellt. Die Berechtigungen für die Verzeichnisse müssen so sein, dass andere Benutzer als Root die Programme/Skripte aus diesen Verzeichnissen ausführen können.

Die Berechtigungen für das Verzeichnis müssen möglicherweise so festgelegt werden, dass „andere“ Benutzer Anwendungen aus diesem Verzeichnis ausführen können.

Zum Beispiel

# don't have permissions on directory
root$ cd /usr/local
$ ls -ld somedir
drwxr-x--- 2 root root 4096 Apr 25 13:27 somedir

# have permissions on the script
root$ ls -l somedir/testscript.bash 
-rwxr-xr-x 1 root root 23 Apr 25 13:27 somedir/testscript.bash

In diesem Szenario wird anderen Benutzern der Zugriff auf das Skript zwar verweigert, obwohl sie über die Berechtigung zum Lesen und Ausführen des Skripts verfügen. Grund dafür ist die Tatsache, dass sie für das Verzeichnis, in dem sich das Skript befindet, weder Lese- noch Ausführungsberechtigung haben.

Durch Ändern der Berechtigungen für das Verzeichnis erhalten sie Zugriff auf:

 user$ ls -ld somedir/
 drwxr-xr-x 2 root root 4096 Apr 25 13:27 somedir/

 user$ somedir/testscript.bash 
 hi

Das gesamte Problem kann behoben werden, indem die Berechtigungen im Verzeichnis geändert werden, das aus der TAR.GZ-Datei entpackt wird. Suchen Sie dazu alle Verzeichnisse mit Skripten und führen Sie den Befehl chmod +rx <dir>für diese Verzeichnisse aus.

Zweites Problem - Ausführungsberechtigungen für Dateien

Die Berechtigungen für die Dateien aus der .tar.gz-Datei wurden möglicherweise nicht zuvor festgelegt, sodass Anwendungen oder Skripte im Archiv ohne diese Berechtigungen entpackt wurden. chmod +x <script>Dieses Problem wird einfach für Dateien behoben, die dieses spezielle Problem aufweisen.

### For example
user$ ls -ld somedir
drwxr-xr-x 2 root root 4096 Apr 25 13:27 somedir/

user$ ls -l somedir/testscript.bash 
-rw-r--r-- 1 root root 23 Apr 25 13:27 somedir/testscript.bash

user$ somedir/testscript.bash
bash: somedir/testscript.bash: Permission denied

verwandte Informationen