Einige Anwendungen, wie z. B. Netbean und JDK, werden oft automatisch installiert /usr/local
und ich führe sie als normaler Benutzer (nicht als Root) aus.
Aber eine andere Anwendung extrahiert einfach tar.gz
die Datei und führt sie aus. Als normaler Benutzer kann ich den Befehl nicht verwenden, um von Verzeichnis zu Verzeichnis cp
zu kopieren , ich muss den Root-Benutzer (Befehl) verwenden .Download
/usr/local
su
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/local
und 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 $PATH
es funktioniert. Ihr Beispiel des JDK mag in dieser Hinsicht verwirrend sein, aber ein normales Tarball, in das Sie ./configure
ausführbare make install
Dateien /usr/local/bin
, Bibliotheken /usr/local/lib
und verschiedene Dinge wie Dokumentation irgendwo in ablegen, /usr/local/share
ist ein Tarball. Dies sind die entsprechenden Pfade, und Sie müssen demselben Muster folgen. Mit anderen Worten, es /usr/local
funktioniert 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