Добавление к пути против ссылки из / bin

Наш системный администратор установил на сервере программное приложение (Maven) и сказал всем добавить /usr/local/maven/bin/папку в свой путь.

Я думаю, что было бы удобнее просто связать несколько программ в этой папке из /binпапки (или другой папки, которая есть у каждого на своем пути) следующим образом:

ln -s /usr/local/maven/bin/* /bin

Это верно? Есть ли скрытые побочные эффекты в моем предложении?

По ссылкам

Вы обычно не связываетесь /usr/local/*с /bin, но это больше историческая практика. В общем, есть несколько «технических» причин, по которым вы не можете делать то, что предлагаете.

Создание ссылок на исполняемые файлы в /binможет вызвать проблемы:

1. Вероятно, самым большим предупреждением будет то, что в вашей системе есть пакеты, управляемые каким-либо менеджером пакетов, таким как RPM, dpkg, APT, YUM, pacman, pkg_add и т. Д. В этих случаях вам, как правило, нужно разрешить пакет менеджер делать свою работу и управлять каталогами , таких как /sbin, /bin, /lib, и /usr. Единственным исключением будет то, /usr/localчто обычно это безопасное место, которое вы можете сделать по своему усмотрению, без необходимости беспокоиться о том, что менеджер пакетов может помешать работе ваших файлов.

2. Часто исполняемые файлы, созданные для, /usr/localбудут жестко запрограммированы в своих исполняемых файлах. Также могут быть файлы конфигурации, которые включены /usr/localкак часть установки этих приложений. Так что ссылка только на исполняемый файл может вызвать проблемы с этими приложениями, которые находят .cfgфайлы позже. Вот пример такого случая:

   $ strings /usr/local/bin/wit | grep '/usr/local'
   /usr/local/share/wit
   /usr/local/share/wit/
   

3. Та же проблема, что и при поиске .cfgфайлов, может возникать и с исполняемыми файлами-помощниками, которые должны запускаться основным приложением. С ними тоже нужно будет связать /usr/bin, зная, что это может быть проблематично и появиться только тогда, когда вы действительно попытаетесь запустить связанное приложение.

ПРИМЕЧАНИЕ: в общем, лучше избегать соблазна связать одно приложение с другим /usr/bin.

/etc/profile.d

Вместо этого, чтобы все пользователи обеспечивали это управление, администратор мог бы очень легко добавить это к каждому $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; но он управляет созданием и уничтожением этих ссылок, поэтому легче понять предполагаемую настройку системы, когда она выполняется с помощью инструмента, а не напрямую, как вы предлагаете.

Здесь я использую эту систему для управления Oracle Java на коробке:

$ 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

Мои 0,02 доллара

Создание ссылок /bin, хотя и правдоподобных, вероятно, будет крайне обескуражено большинством системных администраторов:

1. Будет осуждено, потому что это рассматривается как пользовательский и может привести к путанице, если другой администратор должен поднять флажок
2. Может привести к повреждению системы в будущем в результате этой «хрупкой» настройки.

Отвечая на заданные вопросы:

Это верно?

Нет , это плохая практика.

Есть ли скрытые побочные эффекты в моем предложении?

Да, есть несколько побочных эффектов. Ваше предложение может сработать или не работать в зависимости от приложения, и может регрессировать или быть сломанным в долгосрочной перспективе.

Есть веские причины не создавать такую ​​символическую ссылку:

• Администраторы не являются «собственниками» /bin(см. Примечание 1), поскольку этот каталог принадлежит разработчикам операционной системы / дистрибутива. С другой стороны /usr/local, это традиционное расположение для программного обеспечения, созданного локальным администратором, /opt/<packagename>а также для разрозненного программного обеспечения. Если вы создаете файл или ссылку /bin, существует риск, что он будет перезаписан установкой пакета, в вашем случае - гипотетическим mavenпакетом, предоставленным операционной системой, что может привести к регрессии, если созданный локально создан из более новой версии. Исходный код этой версии ОС. Например, тарболы SVR4 pkgadd, debian dpkg, red-hat rpmи slackware слепо перезаписывают вашу символическую ссылку.

• Некоторые приложения обращаются к месту, где они вызываются, для получения файлов конфигурации, плагинов и подобных ресурсов. Если вы вызываете приложение по символической ссылке, его код может не следовать за ним, а затем искать эти файлы ресурсов /usr/binтам, где их нет.

• Там могут быть другие двоичные файлы, /usr/local/maven/binи если вы не добавите этот каталог в PATH, они будут недоступны. Удалено, поскольку вы уже учли это в своей команде, связав все потенциальные команды.

• Страница maven2 говорит добавить этот каталог в вашу PATH (точнее: добавить переменную среды M2 к вашему пути, например, экспортировать PATH = $ M2: $ PATH .), Используя другой подход, вы нарушаете этот шаг, поэтому переходите на неподдерживаемый путь. Конечно, если большинство пользователей системы являются потенциальными mavenпользователями, было бы более разумно установить PATHглобально, а не на всех и каждого .profile.

Примечание 1:

Документация Slackware:

   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

/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

Документация Solaris:

/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

Если вы хотите использовать символическую ссылку, было бы лучше использовать символическую ссылку /usr/local/bin. На моем сервере я использовал для установки локального программного обеспечения /opt/NAMEи ссылки на двоичные файлы /usr/local/bin.

Альтернативой двум предлагаемым методам является создание сценария оболочки, в /usr/local/binкотором при выполнении исполняется любой двоичный файл, указанный в сценарии. Например, используя maven в качестве примера, я бы создал сценарий оболочки в /usr/local/binnamed maven, у которого есть небольшой скрипт для выполнения двоичного файла maven, где он находится, и передачи ему любых аргументов:

#!/bin/sh
exec /usr/local/maven/bin/maven "$@"

Недостатком этого является необходимость делать это для каждого двоичного файла, который вы хотите «связать», но он позволяет вам вызывать эти двоичные файлы из командной строки без необходимости вносить изменения в $PATHпеременную среды.