Unser Systemadministrator installierte eine Softwareanwendung (Maven) auf dem Server und forderte alle auf, den /usr/local/maven/bin/Ordner ihrem Pfad hinzuzufügen .
Ich denke, es könnte bequemer sein, nur die wenigen Programme in diesem Ordner aus dem /binOrdner (oder einem anderen Ordner, den jeder im Pfad hat) wie folgt zu verknüpfen :
ln -s /usr/local/maven/bin/* /bin
Ist das richtig? Gibt es einige versteckte Nebenwirkungen für meinen Vorschlag?
Antworten:
Sie verknüpfen im Allgemeinen nicht /usr/local/*mit /bin, aber dies ist eher eine historische Praxis. Im Allgemeinen gibt es einige "technische" Gründe, warum Sie nicht das tun können, was Sie vorschlagen.
Das Herstellen von Links zu ausführbaren Dateien in /binkann zu Problemen führen:
Wahrscheinlich ist die größte Einschränkung, wenn Ihr System Pakete von einer Art Paket-Manager wie RPM, dpkg, APT, YUM, pacman, pkg_add usw. verwalten lässt. In diesen Fällen möchten Sie das Paket im Allgemeinen zulassen Manager seine Arbeit tun und zu verwalten Verzeichnisse wie /sbin, /bin, /lib, und /usr. Eine Ausnahme wäre, dass /usr/localdies in der Regel ein sicherer Ort ist, an dem Sie tun können, was Sie für richtig halten, ohne sich Sorgen machen zu müssen, dass ein Paketmanager Ihre Dateien stört.
Oft /usr/localist dieser Pfad für ausführbare Dateien in ihren ausführbaren Dateien fest programmiert. Möglicherweise sind auch Konfigurationsdateien im /usr/localRahmen der Installation dieser Anwendungen enthalten. Wenn Sie also nur auf die ausführbare Datei verlinken, kann dies zu Problemen führen, wenn diese Apps die .cfgDateien später finden. Hier ist ein Beispiel für einen solchen Fall:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
Dasselbe Problem, das beim Suchen von .cfgDateien auftritt , kann auch bei ausführbaren Hilfsprogrammen auftreten, die von der primären App ausgeführt werden müssen. Auch diese müssen verknüpft werden /usr/bin, da dies möglicherweise problematisch ist und nur angezeigt wird, wenn Sie tatsächlich versucht haben, die verknüpfte App auszuführen.
HINWEIS: Im Allgemeinen ist es am besten, die Versuchung zu vermeiden, eine Verknüpfung zu einmaligen Apps in zu erstellen /usr/bin.
Wenn dann nicht alle Benutzer diese Verwaltung bereitstellen, kann der Administrator dies ganz einfach jedem $PATHauf der Box hinzufügen, indem er eine entsprechende Datei in das /etc/profile.dVerzeichnis einfügt.
Eine Datei wie diese /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
Sie tun dies in der Regel als Administrator, anstatt alle Setups der Benutzer damit zu belasten.
Die meisten Distributionen bieten jetzt ein anderes Tool namens alternatives(Fedora / CentOS) oder update-alternatives(Debian / Ubuntu) an, mit dem Sie auch die $PATHTools aufrufen können, die sich möglicherweise außerhalb des befinden /bin. Die Verwendung von Tools wie diesen ist vorzuziehen, da diese eher dem entsprechen, was die meisten Administratoren als "Standardübung" betrachten, und so die Weitergabe der Systeme von einem Administrator an einen anderen erleichtern.
Dieses Tool führt eine ähnliche Aktion aus, indem es Verknüpfungen herstellt /bin. Aber es verwaltet die Erstellung und Zerstörung dieser Links, so dass es einfacher ist, die beabsichtigte Einrichtung eines Systems zu verstehen, wenn dies mit einem Tool durchgeführt wird, oder direkt, wie Sie es vorschlagen.
Hier verwende ich dieses System, um Oracle Java auf einer Box zu verwalten:
$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb 5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb 5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb 5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb 5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb 5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb 5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
Sie können die Auswirkungen sehen:
$ type java
java is /usr/bin/java
$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
Die /binmeisten Systemadministratoren würden davon abraten, Verknüpfungen herzustellen, obwohl dies plausibel ist:
/binVerzeichnis nicht besitzen . Hier ist ein Beispiel. Auf Red Hat-Distributionen, die RPM verwenden, wenn eine Datei bereits in /binRPM vorhanden ist, wird die Installation nicht wie oben beschrieben ausgeführt, es sei denn, Sie müssen den --replacefilesSwitch verwenden , um dies zu tun . Das ist also nicht wirklich ein technischer Grund. Gleiches gilt für andere Verzeichnisse. Ich verstehe, was Sie über das "Besitzen" des Betriebssystems sagen, /binaber es ist nicht so eindeutig, wie Sie sagen.
Beantwortung der gestellten Fragen:
Ist das richtig?
Nein , es ist eine schlechte Praxis.
Gibt es einige versteckte Nebenwirkungen bei meinem Vorschlag?
Ja, es gibt mehrere Nebenwirkungen. Ihr Vorschlag kann je nach Anwendung funktionieren oder auch nicht und kann sich auf lange Sicht zurückbilden oder gebrochen werden.
Es gibt vernünftige Gründe , eine solche symbolische Verknüpfung nicht zu erstellen:
Administratoren "besitzen" nicht /bin(siehe Hinweis 1), da dieses Verzeichnis den Entwicklern von Betriebssystemen / Distributionen gehört. Auf der anderen Seite /usr/localhandelt es sich um einen traditionellen Speicherort für Software, die vom lokalen Administrator erstellt wurde, /opt/<packagename>und für entbündelte Software. Wenn Sie eine Datei oder einen Link erstellen /bin, besteht die Gefahr, dass diese durch eine Paketinstallation überschrieben wird, in Ihrem Fall durch ein mavenvom Betriebssystem bereitgestelltes hypothetisches Paket, was zu einer Regression führen kann, wenn das lokal erstellte Paket aus einer neueren Version erstellt wird Quellcode, der die OS-Version. Zum Beispiel überschreiben SVR4- pkgadd, Debian- dpkg, Red-Hat- rpmund Slackware-Tarballs blind Ihren symbolischen Link.
Einige Anwendungen suchen den Ort, an dem sie aufgerufen werden, um Konfigurationsdateien, Plugins und ähnliche Ressourcen abzurufen. Wenn Sie die Anwendung über eine symbolische Verknüpfung aufrufen, folgt ihr Code möglicherweise nicht und sucht dann nach diesen Ressourcendateien, /usr/binwo sie sich nicht befinden.
Möglicherweise befinden sich andere Binärdateien in Wurde entfernt, da Sie dies bei Ihrem Befehl bereits berücksichtigt haben, indem Sie alle potenziellen Befehle verknüpfen./usr/local/maven/binIhrem PATH. Wenn Sie dieses Verzeichnis nicht zu Ihrem PATH hinzufügen, sind sie nicht verfügbar.
Die Seite maven2 fordert Sie auf, dieses Verzeichnis zu Ihrem PATH hinzuzufügen (genau: Fügen Sie M2-Umgebungsvariable zu Ihrem Pfad hinzu, z. B. export PATH = $ M2: $ PATH .). Wenn Sie einen anderen Ansatz verwenden, brechen Sie diesen Schritt ab und werden nicht unterstützt Weg. Wenn die meisten Benutzer eines Systems potenzielle mavenBenutzer sind, ist es natürlich sinnvoller, das PATHglobal festzulegen, als bei jedem einzelnen .profile.
Anmerkung 1:
The /bin directory usually doesn't receive modification
after installation. If it does, it's usually in the form
of package upgrades that we provide.
Debian / Filesystem Hierarchy Standard
/bin/
Essential command executable (binaries) for all users (e.g., cat, ls, cp)
(especially files required to boot or rescue the system)
...
/opt/
Add-on application software packages
Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
Same as for top-level hierarchy
/usr/bin
Platform-dependent, user-invoked executables. These are
commands users expect to be run as part of their normal
$PATH. For executables that are different on a 64-bit
system than on a 32-bit system, a wrapper that selects
the appropriate executable is placed here. See
isaexec(3C). An approved installation location for bun-
dled Solaris software. The analogous location for add-on
system software or for applications is
/opt/packagename/bin.
Ein einfacher Test, der zeigt, dass Debian dpkgkeinen bestehenden Link beibehält, auch wenn die --force-overwriteOption nicht verwendet wird:
# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May 7 2009 /usr/bin/banner
/binoder installiert /usr/bin. Nach dem Erkennen der Probleme mit versteckten oder zerstörten System-Binärdateien (die bekannteste war test) wurde die bewährte Methode, nicht-System-Binärdateien an einer anderen Stelle zu installieren, schrittweise übernommen.
Wenn Sie einen Symlink erstellen möchten, ist es besser, einen Symlink zu erstellen /usr/local/bin. Auf meinem Server habe ich lokale Software installiert /opt/NAMEund die Binärdateien mit diesen verknüpft /usr/local/bin.
Eine Alternative zu den beiden vorgeschlagenen Methoden besteht darin, ein Shell-Skript zu erstellen /usr/local/bin, das bei der Ausführung die im Skript angegebene Binärdatei ausführt. Zum Beispiel würde ich am Beispiel von maven ein Shell-Skript /usr/local/binnamens erstellen maven, das ein kleines Skript enthält, um die maven-Binärdatei dort auszuführen, wo sie sich befindet, und alle Argumente an sie weiterzuleiten:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Dies hat den Nachteil, dass Sie dies für jede Binärdatei tun müssen, die Sie "verknüpfen" möchten, aber Sie können diese Binärdateien von der Befehlszeile aus aufrufen, ohne Ihre $PATHUmgebungsvariable durcheinander bringen zu müssen.
/opt.