Наш адміністратор sys встановив на сервер програмне забезпечення (Maven) і сказав усім додати /usr/local/maven/bin/папку на свій шлях.
Я думаю, що було б зручніше просто зв'язати декілька програм у цій папці з /binпапки (або іншої папки, яку кожен має на своєму шляху) так:
ln -s /usr/local/maven/bin/* /bin
Це правильно? Чи є якісь приховані побічні ефекти на мою пропозицію?
Відповіді:
Ви зазвичай не пов'язують /usr/local/*з /bin, але це більше історичної практики. Загалом, є кілька "технічних" причин, чому ви не можете робити те, що пропонуєте.
Створення посилань на виконувані файли /binможе спричинити проблеми:
Напевно, найбільшим застереженням буде, якщо у вас система має пакети, якими керує якийсь менеджер пакунків, такий як RPM, dpkg, APT, YUM, pacman, pkg_add тощо. У цих випадках, як правило, ви хочете відпустити пакет менеджер робити свою роботу і керувати каталогами , таких як /sbin, /bin, /lib, і /usr. Один виняток /usr/local- це, як правило, безпечне місце робити так, як ви вважаєте за потрібне на коробці, не турбуючись про те, що менеджер пакунків втручається у ваші файли.
Часто для файлів, розроблених для разів /usr/local, цей PATH буде важко кодований у своїх виконуваних файлах. Можуть також бути файли конфігурації, які включені /usr/localдо складу інсталяції цих додатків. Таким чином, посилання на лише виконуваний файл може спричинити проблеми із пошуку цих .cfgфайлів пізніше. Ось приклад такого випадку:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
Та ж проблема, яка стосується пошуку .cfgфайлів, може виникнути і з «помічниками» виконуваних файлів, які потрібно запустити основним додатком. Вони також повинні бути пов’язані /usr/bin, знаючи, що це може бути проблематичним і з'являтися лише тоді, коли ви насправді намагалися виконати пов’язане додаток.
ПРИМІТКА: загалом найкраще уникати спокуси зв’язатись із одноразовими програмами в /usr/bin.
Замість того, щоб усі користувачі забезпечували це управління, адміністратор міг би легко додати це до всіх $PATHу вікні, додавши відповідний файл у /etc/profile.dкаталог.
Такий файл, як цей /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
Як правило, ви робите це як адміністратор, а не забруднюєте всі налаштування користувачів цим.
Більшість дистрибутивів тепер надають інший інструмент під назвою alternatives(Fedora / CentOS) або update-alternatives(Debian / Ubuntu), який ви також можете використовувати для переходу до $PATHінструментів, які можуть знаходитися поза /bin. Використання таких інструментів є кращим, оскільки вони більше дотримуються того, що більшість адміністраторів вважають "стандартною практикою", і таким чином спрощує передачу систем від одного адміністратора до іншого.
Цей інструмент робить подібну дію при створенні посилань /bin; але він керує створенням та знищенням цих посилань, тому легше зрозуміти передбачувану установку системи, якщо це зроблено за допомогою інструменту проти зробленого безпосередньо, як ви пропонуєте.
Ось я використовую цю систему для управління Java Oracle на коробці:
$ 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
Ви можете побачити наслідки цього:
$ 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
Здійснення зв’язків /bin, хоч і правдоподібне, можливо, буде сильно відштовхувати більшість системних адміністраторів:
/binкаталогом. Ось приклад. На дистрибутивах Red Hat, які використовують RPM, якщо файл вже існує в /binRPM, він не встановлюватиметься так, як ви описали, якщо тільки це не буде зроблено за допомогою --replacefilesперемикача. Тож це насправді не технічна причина. Те саме з іншими каталогами. Я розумію, що ви говорите про "володіння" ОС, /binале це не так прямо, як ви заявляєте.
Відповідаючи на поставлені запитання:
Це правильно?
Ні , це погана практика.
Чи є якісь приховані побічні ефекти на мою пропозицію?
Так , є кілька побічних ефектів. Ваша пропозиція може працювати або не залежати від програми та може регресувати або порушуватися в довгостроковій перспективі.
Вагомих причин немає створювати таке символічне посилання:
Адміністратори не є "власниками" /bin(див. Примітку 1), оскільки цей каталог належить розробникам операційної системи / дистрибуції. З іншого боку /usr/local, це традиційне місце для програмного забезпечення, побудованого місцевим адміністратором, яке /opt/<packagename>є для нерозподіленого програмного забезпечення. Якщо ви створюєте файл або посилання в /bin, існує ризик його перезаписати встановлення пакету, у вашому випадку гіпотетичний mavenпакет, наданий ОС, що може призвести до регресії, якщо створений локально створений з новіших вихідний код, що версія ОС. Наприклад, SVR4 pkgadd, debian dpkg, red-hat rpmта slackware tarballs всі сліпо переписують ваше символічне посилання.
Деякі програми шукають місце, куди вони викликаються, щоб отримати конфігураційні файли, плагіни та подібні ресурси. Якщо ви називаєте програму символічним посиланням, її код може не виконати її, а потім шукайте ці файли ресурсів /usr/binтам, де їх немає.
Можуть бути інші бінарні файли, Видалено, оскільки ви вже враховуєте це своєю командою, з'єднавши всі потенційні команди./usr/local/maven/binі якщо додавання цього каталогу у ваш PATH зробить їх недоступними.
Сторінка maven2 говорить про те, щоб додати цей каталог до вашої PATH (саме: Додати змінну середовища M2 на ваш шлях, наприклад, експортувати PATH = $ M2: $ PATH .), Використовуючи інший підхід, ви порушуєте цей крок, тому не буде підтримуватися шлях. Звичайно, якщо більшість користувачів системи є потенційними mavenкористувачами, було б більше сенсу встановлювати PATHглобально, а не кожного та кожного.profile .
Примітка 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
/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 dpkgне зберігає існуюче посилання, навіть якщо --force-overwriteпараметр не використовується:
# 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
/binабо /usr/bin. Виявивши проблеми прихованих або спотворених системних бінарних файлів (найвідомішим було це test), найкраща практика встановлення несистемних бінарних файлів десь ще була поступово прийнята.
Якщо ви хочете передати символьне посилання, краще було б це зробити /usr/local/bin. На моєму сервері я встановлював місцеве програмне забезпечення в /opt/NAMEі символізував бінарні файли /usr/local/bin.
Альтернативою двом запропонованим методам є створення скрипту оболонки, /usr/local/binякий при виконанні виконує будь-який двійковий код, який ви вказали в сценарії. Наприклад, використовуючи maven в якості прикладу, я створив би скрипт оболонки в /usr/local/bincall, mavenякий має невеликий скрипт всередині, щоб виконати бінарний файл maven, де він знаходиться, і передати йому будь-які аргументи:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Це має і менший бік, як це робити для кожного бінарного файлу, на який ви хочете "зв’язати", але це дозволяє викликати ці бінарні файли з командного рядка, не потребуючи вимкнення $PATHзмінної вашого середовища.
/opt.