Admin sys kami memasang aplikasi perangkat lunak (Maven) di server dan menyuruh semua orang untuk menambahkan /usr/local/maven/bin/folder ke jalur mereka.
Saya pikir akan lebih mudah untuk hanya menautkan beberapa program di folder itu dari /binfolder (atau folder lain yang dimiliki semua orang), seperti ini:
ln -s /usr/local/maven/bin/* /bin
Apakah ini benar? Apakah ada beberapa efek samping tersembunyi pada saran saya?
Jawaban:
Anda biasanya tidak menghubungkan /usr/local/*dengan /bin, tapi ini lebih dari praktek sejarah. Secara umum, ada beberapa alasan "teknis" mengapa Anda tidak dapat melakukan apa yang Anda sarankan.
Membuat tautan ke file executable /bindapat menyebabkan masalah:
Mungkin peringatan terbesar adalah jika sistem Anda memiliki paket yang dikelola oleh semacam manajer paket seperti RPM, dpkg, APT, YUM, pacman, pkg_add, dll. Dalam kasus ini, Anda biasanya ingin membiarkan paket tersebut manajer melakukan tugasnya dan mengelola direktori seperti /sbin, /bin, /lib, dan /usr. Satu pengecualian adalah tempat /usr/localyang biasanya aman untuk dilakukan sesuai keinginan Anda, tanpa harus khawatir tentang manajer paket yang mengganggu file Anda.
Sering kali executable yang dibangun untuk /usr/localmemiliki PATH ini dikodekan ke dalam executable mereka. Mungkin juga ada file konfigurasi yang disertakan /usr/localsebagai bagian dari instalasi aplikasi ini. Jadi menautkan hanya ke yang dapat dieksekusi dapat menyebabkan masalah dengan aplikasi ini menemukan .cfgfile di kemudian hari. Berikut ini contoh kasusnya:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
Masalah yang sama yang berlaku untuk menemukan .cfgfile juga dapat terjadi dengan executable "pembantu" yang harus dijalankan aplikasi utama. Ini juga perlu dihubungkan /usr/bin, mengetahui ini mungkin bermasalah dan hanya muncul ketika Anda benar-benar berusaha untuk mengeksekusi aplikasi tertaut.
CATATAN: secara umum yang terbaik adalah menghindari godaan untuk menautkan ke satu aplikasi dalam /usr/bin.
Alih-alih memiliki semua pengguna menyediakan manajemen ini, admin bisa dengan mudah menambahkan ini ke semua orang $PATHdi kotak dengan menambahkan file yang sesuai di /etc/profile.ddirektori.
File seperti ini /etc/profile.d/maven.sh,:
PATH=$PATH:/usr/local/maven/bin
Anda biasanya melakukan ini sebagai admin alih-alih mencemari semua pengaturan pengguna dengan ini.
Kebanyakan distro sekarang menyediakan alat lain yang disebut alternatives(Fedora / CentOS) atau update-alternatives(Debian / Ubuntu) yang juga dapat Anda gunakan untuk mengulang ke $PATHalat yang mungkin berada di luar /bin. Menggunakan alat seperti ini lebih disukai karena ini lebih mengacu pada apa yang oleh sebagian besar admin akan dianggap sebagai "praktik standar" dan dengan demikian membuat sistem lebih mudah untuk diserahkan dari satu admin ke admin lainnya.
Alat ini melakukan hal serupa dalam membuat tautan di /bin; tetapi mengelola pembuatan dan penghancuran tautan-tautan ini, sehingga lebih mudah untuk memahami pengaturan yang dimaksudkan sistem ketika dilakukan melalui alat vs. dilakukan secara langsung seperti yang Anda sarankan.
Di sini saya menggunakan sistem itu untuk mengelola Java Oracle pada sebuah kotak:
$ 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
Anda dapat melihat efek dari ini:
$ 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
Membuat tautan /bin, meskipun masuk akal, kemungkinan besar akan sangat tidak disukai oleh sebagian besar sysadmin:
/bindirektori. Ini sebuah contoh. Pada distro Red Hat yang menggunakan RPM jika file yang sudah ada di /binRPM tidak akan menginstal di atas seperti yang telah Anda jelaskan, kecuali coxed melakukannya menggunakan --replacefilessaklar. Jadi itu bukan alasan teknis. Sama dengan direktori lain. Saya mengerti apa yang Anda katakan tentang OS "memiliki" /bintetapi tidak sejelas yang Anda katakan .
Menjawab pertanyaan yang diajukan:
Apakah ini benar?
Tidak , ini adalah praktik yang buruk.
Apakah ada beberapa efek samping tersembunyi pada saran saya?
Ya ada beberapa efek samping. Saran Anda mungkin berfungsi atau tidak, tergantung pada aplikasi, dan mungkin mundur atau rusak dalam jangka panjang.
Ada alasan masuk akal untuk tidak membuat tautan simbolis seperti itu:
Administrator tidak "memiliki" /bin(lihat catatan 1) karena direktori ini milik pengembang sistem operasi / distribusi. Di sisi lain /usr/localadalah lokasi tradisional untuk perangkat lunak yang dibangun oleh administrator lokal, /opt/<packagename>menjadi satu untuk perangkat lunak yang tidak diikat. Jika Anda membuat file atau tautan /bin, ada risiko ditimpa oleh instalasi paket, dalam kasus Anda mavenpaket hipotetis yang disediakan oleh OS, yang mungkin mengarah pada regresi jika yang dibangun secara lokal dibuat dari yang lebih baru. kode sumber bahwa versi OS. Sebagai contoh, tarbal SVR4 pkgadd, debian dpkg, red-hat, rpmdan slackware semuanya akan secara tidak sengaja menimpa tautan simbolik Anda.
Beberapa aplikasi memang melihat ke tempat mereka dipanggil untuk mengambil file konfigurasi, plugin dan sumber daya serupa. Jika Anda memanggil aplikasi dengan tautan simbolis, kodenya mungkin gagal mengikutinya dan kemudian mencari file sumber daya ini di sekitar /usr/bintempat mereka tidak.
Mungkin ada binari lain di Dihapus karena Anda sudah memperhitungkannya dengan perintah Anda dengan menautkan semua perintah potensial./usr/local/maven/bindalamnya dan tidak menambahkan direktori ini ke PATH Anda akan membuatnya tidak tersedia.
The halaman maven2 mengatakan untuk menambahkan direktori ini ke PATH anda (tepatnya: Tambah variabel lingkungan M2 untuk jalan Anda, misalnya export PATH = $ M2: $ PATH .), Dengan menggunakan pendekatan yang berbeda, Anda melanggar langkah yang begitu akan yang tidak didukung cara. Tentu saja, jika sebagian besar pengguna sistem adalah mavenpengguna potensial , akan lebih masuk akal untuk mengatur PATHglobal daripada pada masing-masing dan setiap .profile.
Catatan 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.
Standar Hirarki Debian / Filesystem
/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.
Tes sederhana yang menunjukkan Debian's dpkgtidak menyimpan tautan yang ada, meskipun --force-overwriteopsi tidak digunakan:
# 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
/binatau /usr/bin. Setelah menemukan masalah biner sistem tersembunyi atau terganggu (yang paling terkenal adalah test) praktik terbaik untuk menginstal biner non sistem di tempat lain secara progresif diadopsi.
Jika Anda ingin symlink, akan lebih baik symlink ke /usr/local/bin. Di server saya, saya biasa menginstal perangkat lunak lokal ke /opt/NAMEdan symlink binari ke /usr/local/bin.
Alternatif dari dua metode yang disarankan adalah membuat skrip shell /usr/local/bin, ketika dijalankan, mengeksekusi biner apa pun yang Anda tentukan dalam skrip. Sebagai contoh, menggunakan maven sebagai contoh, saya akan membuat skrip shell dengan /usr/local/binnama mavenyang memiliki skrip kecil di dalamnya untuk mengeksekusi biner maven di mana ia berada dan meneruskan argumen apa pun kepadanya:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Ini memiliki kelemahan karena harus melakukan ini untuk setiap biner yang ingin Anda "tautkan", tetapi ini memungkinkan Anda untuk memanggil binari-binari tersebut dari baris perintah tanpa perlu membersihkan $PATHvariabel lingkungan Anda .
/opt.