Il nostro amministratore di sistema ha installato un'applicazione software (Maven) sul server e ha detto a tutti di aggiungere la /usr/local/maven/bin/cartella al loro percorso.
Penso che potrebbe essere più conveniente collegare i pochi programmi in quella cartella dalla /bincartella (o altra cartella che ognuno ha nel proprio percorso) in questo modo:
ln -s /usr/local/maven/bin/* /bin
È corretto? Ci sono alcuni effetti collaterali nascosti nel mio suggerimento?
Risposte:
In genere non collegare /usr/local/*con /bin, ma questo è più di una pratica storica. In generale, ci sono alcuni motivi "tecnici" per cui non puoi fare ciò che stai suggerendo.
Fare collegamenti a file eseguibili /binpuò causare problemi:
Probabilmente il più grande avvertimento sarebbe se il tuo sistema sta avendo pacchetti gestiti da una sorta di gestore di pacchetti come RPM, dpkg, APT, YUM, pacman, pkg_add, ecc. In questi casi, generalmente vorrai lasciare che il pacchetto direttore di fare il suo lavoro e gestire directory come /sbin, /bin, /lib, e /usr. Un'eccezione potrebbe essere quella /usr/localche in genere è un luogo sicuro da fare come meglio credi, senza doversi preoccupare che un gestore di pacchetti interferisca con i tuoi file.
Spesso i file eseguibili creati per /usr/localquesto PATH saranno codificati nei loro file eseguibili. Potrebbero inoltre essere presenti file di configurazione inclusi /usr/localcome parte dell'installazione di queste applicazioni. Quindi il collegamento solo all'eseguibile potrebbe causare problemi con queste app che trovano i .cfgfile più avanti. Ecco un esempio di un caso del genere:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
Lo stesso problema che si applica alla ricerca di .cfgfile può verificarsi anche con eseguibili "helper" che l'app primaria deve eseguire. Anche questi dovrebbero anche essere collegati /usr/bin, sapendo che questo potrebbe essere problematico e mostrarsi solo quando si è effettivamente tentato di eseguire l'app collegata.
NOTA: in generale è meglio evitare la tentazione di collegarsi ad app una tantum in /usr/bin.
Invece piuttosto che tutti gli utenti forniscano questa gestione, l'amministratore potrebbe facilmente aggiungerlo a tutti quelli presenti $PATHsulla scatola aggiungendo un file corrispondente nella /etc/profile.ddirectory.
Un file come questo /etc/profile.d/maven.sh,:
PATH=$PATH:/usr/local/maven/bin
In genere lo fai come amministratore invece di inquinare tutte le configurazioni degli utenti con questo.
La maggior parte delle distribuzioni ora fornisce un altro strumento chiamato alternatives(Fedora / CentOS) o update-alternatives(Debian / Ubuntu) che puoi anche usare per eseguire il loop degli $PATHstrumenti che potrebbero essere al di fuori di /bin. L'uso di strumenti come questi è preferibile in quanto aderiscono maggiormente a ciò che la maggior parte degli amministratori considererebbe "pratica standard" e quindi rende i sistemi più facili da passare da un amministratore all'altro.
Questo strumento fa una cosa simile nel creare collegamenti /bin; ma gestisce la creazione e la distruzione di questi collegamenti, quindi è più semplice comprendere l'impostazione prevista di un sistema quando eseguita tramite uno strumento anziché eseguita direttamente come suggerito.
Qui sto usando quel sistema per gestire Java di Oracle su una scatola:
$ 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
Puoi vedere gli effetti di questo:
$ 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
Fare collegamenti /bin, sebbene plausibili, sarebbe probabilmente altamente scoraggiato dalla maggior parte dei amministratori di sistema:
/bindirectory. Ecco un esempio Nelle distribuzioni Red Hat che utilizzano RPM se un file esiste già in /binRPM non verrà installato come descritto, a meno che non venga richiesto di farlo utilizzando l' --replacefilesopzione. Quindi non è proprio un motivo tecnico. Lo stesso con altre directory. Capisco quello che stai dicendo sul "possesso" del sistema operativo, /binma non è così chiaro come stai affermando.
Rispondere alle domande poste:
È corretto?
No , è una cattiva pratica.
Ci sono alcuni effetti collaterali nascosti nel mio suggerimento?
Sì, ci sono diversi effetti collaterali. Il tuo suggerimento potrebbe funzionare o meno a seconda dell'applicazione e potrebbe regredire o essere interrotto a lungo termine.
Ci sono ragioni ragionevoli per non creare un collegamento così simbolico:
Gli amministratori non "possiedono" /bin(vedi nota 1) poiché questa directory appartiene al sistema operativo / agli sviluppatori della distribuzione. D'altra parte /usr/localè una posizione tradizionale per il software creato dall'amministratore locale, /opt/<packagename>essendo uno per il software disaggregato. Se si crea un file o un collegamento /bin, esiste il rischio che venga sovrascritto dall'installazione di un pacchetto, nel tuo caso un mavenpacchetto ipotetico fornito dal sistema operativo, che potrebbe portare a una regressione se quello creato localmente viene creato da una versione più recente codice sorgente che la versione del sistema operativo. Ad esempio, tarball SVR4 pkgadd, debian dpkg, red-hat rpme slackware sovrascriveranno tutti in modo accecante il tuo link simbolico.
Alcune applicazioni guardano al luogo in cui vengono chiamate per recuperare file di configurazione, plugin e risorse simili. Se si chiama l'applicazione tramite un collegamento simbolico, il suo codice potrebbe non riuscire a seguirla e quindi cercare questi file di risorse in /usr/bincui non si trovano.
Potrebbero essere presenti altri file binari Rimosso quando lo prendi già in considerazione con il tuo comando collegando tutti i potenziali comandi./usr/local/maven/bine non l'aggiunta di questa directory al PATH li renderà non disponibili.
La pagina maven2 dice di aggiungere questa directory al tuo PERCORSO (precisamente: aggiungi una variabile d'ambiente M2 al tuo percorso, ad esempio esporta PERCORSO = $ M2: $ PERCORSO ), usando un approccio diverso, stai superando quel passaggio quindi stai andando in modo non supportato modo. Naturalmente, se la maggior parte degli utenti di un sistema sono potenziali mavenutenti, sarebbe più sensato impostare il valore PATHglobale anziché su ognuno .profile.
Nota 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.
Un semplice test che mostra che Debian dpkgnon conserva un collegamento esistente, anche se l' --force-overwriteopzione non è utilizzata:
# 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
/bino /usr/bin. Dopo aver scoperto i problemi dei binari di sistema nascosti o distrutti (il più famoso era test) la pratica migliore per installare binari non di sistema da qualche altra parte fu progressivamente adottata.
Se si desidera un collegamento simbolico, sarebbe meglio un collegamento simbolico /usr/local/bin. Sul mio server, ho usato per installare software locale /opt/NAMEe link simbolico ai binari /usr/local/bin.
Un'alternativa ai due metodi suggeriti è quella di creare uno script shell /usr/local/binche, quando eseguito, esegue qualunque binario specificato nello script. Ad esempio, usando maven come esempio, creerei uno script shell in /usr/local/binchiamato mavenche contiene un piccolo script all'interno per eseguire il binario maven dove si trova e passare qualsiasi argomento ad esso:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Questo ha il rovescio della medaglia di doverlo fare per ogni binario che si desidera "collegare", ma consente di chiamare quei binari dalla riga di comando senza dover creare la $PATHvariabile di ambiente.
/opt.