Наш системный администратор установил на сервере программное приложение (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будут жестко запрограммированы в своих исполняемых файлах. Также могут быть файлы конфигурации, которые включены /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; но он управляет созданием и уничтожением этих ссылок, поэтому легче понять предполагаемую настройку системы, когда она выполняется с помощью инструмента, а не напрямую, как вы предлагаете.
Здесь я использую эту систему для управления 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
Создание ссылок /bin, хотя и правдоподобных, вероятно, будет крайне обескуражено большинством системных администраторов:
/binкаталогом. Вот пример. В дистрибутивах Red Hat, использующих RPM, если файл уже существует в /binRPM, не будет устанавливаться поверх, как вы описали, если только вы не сделаете этого, используя --replacefilesпереключатель. Так что это не совсем техническая причина. То же самое с другими каталогами. Я понимаю, что вы говорите о «владении» ОС, /binно это не так явно, как вы заявляете.
Отвечая на заданные вопросы:
Это верно?
Нет , это плохая практика.
Есть ли скрытые побочные эффекты в моем предложении?
Да, есть несколько побочных эффектов. Ваше предложение может сработать или не работать в зависимости от приложения, и может регрессировать или быть сломанным в долгосрочной перспективе.
Есть веские причины не создавать такую символическую ссылку:
Администраторы не являются «собственниками» /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:
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
/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/binnamed maven, у которого есть небольшой скрипт для выполнения двоичного файла maven, где он находится, и передачи ему любых аргументов:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Недостатком этого является необходимость делать это для каждого двоичного файла, который вы хотите «связать», но он позволяет вам вызывать эти двоичные файлы из командной строки без необходимости вносить изменения в $PATHпеременную среды.
/opt.