Sistem yöneticimiz sunucuya bir yazılım uygulaması (Maven) kurdu ve herkese /usr/local/maven/bin/klasörü yoluna eklemesini söyledi .
Sadece bu klasördeki birkaç programı /binklasörden (veya herkesin yolunda olduğu diğer klasörlerden) bu şekilde bağlamak daha uygun olabilir :
ln -s /usr/local/maven/bin/* /bin
Bu doğru mu? Önerimin bazı gizli yan etkileri var mı?
Yanıtlar:
Genel olarak bağlantı /usr/local/*kurmazsınız /bin, ancak bu daha çok tarihi bir pratiktir. Genel olarak, önerdiğiniz şeyi yapamamanızın birkaç "teknik" nedeni vardır.
Yürütülebilir dosyalara bağlantı yapmak /binsorunlara neden olabilir:
Muhtemelen en büyük uyarı sistemi eğer RPM, dpkg, APT, YUM, pacman, pkg_add, vb. Gibi bir paket yöneticisi tarafından yönetilen paketlere sahipseniz olacaktır. Bu durumlarda, genellikle paketin müdür işini ve bu şekilde dizinleri yönetmek /sbin, /bin, /lib, ve /usr. Bunun bir istisnası /usr/local, dosyalarınızı engelleyen bir paket yöneticisi hakkında endişelenmenize gerek kalmadan, genellikle kutuya uygun gördüğünüzde güvenli bir yer olacaktır.
Çoğu zaman için inşa edilen çalıştırılabilir dosyalarda /usr/localbu PATH çalıştırılabilir kodlarına kodlanmış olur. /usr/localBu uygulamaların kurulumunun bir parçası olarak verilen yapılandırma dosyaları da olabilir . Bu yüzden sadece çalıştırılabilir dosyalara bağlanmak, bu uygulamalarla ilgili .cfgdosyaları daha sonra bulmakta sorunlara neden olabilir . İşte böyle bir durumun bir örneği:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
.cfgDosyaları bulmak için de aynı sorun , birincil uygulamanın çalışması gereken "yardımcı" çalıştırılabilir dosyalarla da ortaya çıkabilir. Bunların da buna bağlı olması gerekir /usr/bin, bunun problemli olabileceğini bilmek ve yalnızca bağlantılı uygulamayı çalıştırmayı denediğinizde ortaya çıkması gerektiğini bilmek.
NOT: Genel olarak, bir uygulamadaki uygulamalarla bağlantı kurma eğiliminden kaçınmak en iyisidir /usr/bin.
Daha sonra, tüm kullanıcıların bu yönetimi sağlamaları yerine, yönetici $PATH, /etc/profile.ddizindeki ilgili dosyayı ekleyerek bu kutuyu herkesin üzerine kolayca ekleyebilir .
Bunun gibi bir dosya /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
Bunu, genel olarak tüm kullanıcıların kurulumlarını kirletmek yerine, yönetici olarak yaparsınız.
Dağıtımların çoğu şimdi, dışında olabilecek araçların içine girerken kullanabileceğiniz alternatives(Fedora / CentOS) veya update-alternatives(Debian / Ubuntu) adında başka bir araç sunar . Bunlar gibi araçların kullanılması tercih edilir çünkü bunlar çoğu yöneticinin "standart uygulama" olarak gördüğü şeylere daha fazla bağlı kalmaktadır ve bu nedenle sistemleri bir idareciden diğerine devretmeyi kolaylaştırmaktadır.$PATH/bin
Bu araç, bağlantı kurmada benzer bir şey yapar /bin; ancak bu bağlantıların oluşturulmasını ve imha edilmesini yönetir; bu nedenle, bir araç ile yapıldığında sistemin önerdiği kurulumu anlamak, doğrudan önerdiğiniz şekilde yapılır.
İşte bu sistemi Oracle'ın Java'sını bir kutuda yönetmek için kullanıyorum:
$ 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
Bunun etkilerini görebilirsiniz:
$ 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
Mantıklı /binolsa da, bağlantıların yapılması çoğu sistem yöneticisi tarafından büyük ölçüde cesaret kırılır:
/bindizinin sahibi olmadığına ikna olmadım . İşte bir örnek. RPM'de bir dosya zaten varsa, /binRPM'yi kullanan Red Hat dağıtımları , --replacefilesanahtarı kullanarak yapmayı bırakmadığınız sürece tanımladığınızın üzerine kurulmaz . Yani bu gerçekten teknik bir sebep değil. Diğer dizinlerle aynı. İşletim sistemi "mülkiyeti" hakkında ne söylediğinizi anlıyorum /binama belirttiğiniz kadar net değil.
Sorulan sorulara cevap vermek:
Bu doğru mu?
Hayır , kötü bir uygulamadır.
Önerim için bazı gizli yan etkiler var mı?
Evet birkaç yan etkisi var. Öneriniz, uygulamaya bağlı olarak çalışmayabilir veya çalışmayabilir ve uzun vadede gerileyebilir veya kırılabilir.
Mantıklı nedenleri vardır değil böyle sembolik bir bağlantı oluşturmak için:
Yöneticiler /binbu dizinin işletim sistemi / dağıtım geliştiricilerine ait olması nedeniyle "sahip değil" (bakınız not 1). Öte yandan /usr/local, yerel yönetici tarafından oluşturulan yazılım için geleneksel bir konumdur /opt/<packagename>ve birleşik yazılım için birdir. Bir dosya veya bağlantı oluşturursanız /bin, bir paket kurulumunun üzerine yazılması riski vardır, sizin durumunuzda mavenOS tarafından sağlanan ve yerel olarak oluşturulmuş olandan yeni oluşturulan bir regresyona yol açabilecek varsayımsal bir paket OS sürümü kaynak kodu. Örneğin, SVR4 pkgadd, debian dpkg, red hat rpmve slackware tarball'larının tümü sembolik bağlantınızın üzerine yazacaktır.
Bazı uygulamalar, yapılandırma dosyalarını, eklentileri ve benzeri kaynakları almak için çağrıldığı yere bakar. Uygulamayı sembolik bir bağlantıyla çağırırsanız, kodu izlemekte başarısız olabilir ve daha sonra /usr/binolmadığı kaynak kaynaklara bakabilir .
İçinde başka ikili dosyalar olabilir Tüm olası komutları birbirine bağlayarak komutunuzla zaten bunu dikkate aldığınızdan kaldırıldı./usr/local/maven/binve bu dizini PATH'inize eklememek onları kullanılamaz duruma getirecektir.
Maven2 sayfa PATH için bu dizini eklemek söyler (doğrusu: senin yoluna M2 ortam değişkeni ekleyin, örneğin ihracat YOLU = $ M2: $ PATH .), Senin böylece adımı kırıyorlar, farklı bir yaklaşım kullanarak desteklenmeyen gidiyor yol. Elbette, bir sistemin mavenkullanıcılarının çoğu potansiyel kullanıcı PATHise, her birini değil genel olarak dünyayı belirlemek daha mantıklı olacaktır .profile.
Not 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 Hiyerarşi 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.
Debian's'ı gösteren basit test dpkg, --force-overwriteseçenek kullanılmadığında bile mevcut bir bağlantıyı korumaz :
# 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
/binya da içine kurdu /usr/bin. Gizli veya imha edilmiş sistem ikili dosyalarının (en ünlü olanı) sorunlarının keşfedilmesi üzerine, sistem testdışı ikili dosyaları başka bir yere kurmak için en iyi uygulama aşamalı olarak benimsendi.
Eğer link vermek istiyorsanız, link etmek daha iyi olur /usr/local/bin. /opt/NAMESunucumda yerel yazılımı kurar ve ikili dosyalara bağlardım /usr/local/bin.
Önerilen iki yönteme alternatif olarak, /usr/local/binçalıştırıldığında, kodda belirttiğiniz ikili dosyayı çalıştıran bir kabuk betiği oluşturmaktır . Örneğin, maven'i bir örnek olarak kullanarak, içinde bulunduğu maven binary'ini çalıştırmak ve içine herhangi bir argüman iletmek için içinde küçük bir betiği bulunan ve /usr/local/binadlandırılmış bir kabuk betiği oluşturacağım maven:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Bu, "bağlamak" istediğiniz her ikili için bunu yapmak zorunda olmanın dezavantajıdır, ancak $PATHortam değişkeninizi doldurmanıza gerek kalmadan bu ikili komutları komut satırından çağırmanıza olanak tanır .
/opt.