 |
|
|
|
FreeBSD-бинарная совместимость с Linux
FreeBSD-бинарная совместимость с Linux Мы с тобой одной крови – ты и я. Р. Киплинг «Маугли» Если спросить любого мало-мальски искушенного в компьютерных системах человека, какая UNIX-система на данный момент наиболее популярна, большинство, не задумываясь, ответят – Linux. Несмотря на то что, по моему мнению, в мире существует немало систем, которые по своим объективным качествам превосходят пингвина и его производные, все же любимцем публики стал именно он. Такую огромную популярность этой системы можно объяснить несколькими факторами. Linux проще в первоначальном освоении, чем многие его конкуренты. Диалектов Linux существует великое множество, и соответственно каждый алчущий избавления от засилья Microsoft может найти себе что-то наиболее близкое к представлению об идеальной системе. В отличие от поклонников BSD-систем, которые спокойно и тихо делают свое дело, пользователи Linux довольно активно пропагандируют свое увлечение как образ жизни. В то же время лицензия на компоненты и инструменты, используемые в процессе работы, намного либеральнее, чем обычная BSD-лицензия, что делает систему гораздо привлекательнее для создания проприетарного программного обеспечения. Многие большие игроки этого рынка довольно быстро осознали эти преимущества, поэтому довольно часты случаи, когда закрытое по своей сути программное обеспечение для Linux раздается гигантами индустрии бесплатно в скомпилированном специально для этой системы виде. Единственной тайной остается исходный текст таких подарков, обычно содержащий те или иные секретные ноу-хау. В то же время при использовании BSD-систем надеяться на такие жесты доброты не стоит. Такова объективная реальность, данная нам в ощущениях, и раздувать из-за этого религиозные войны не стоит. Часто обстоятельства складываются так, что свободно распространяемых аналогов закрытого обеспечения не создано и, вероятнее всего, они никогда не появятся на свет, особенно для BSD. Для меня столь необходимыми программами являются Citrix ICA Client, позволяющий работать с сервером Citrix MetaFrame и Аcrobat Reader. В то же время производителя вполне можно понять. Для осуществления квалифицированной поддержки пользователей своей программы, работающей на разных системах, нужно иметь в своем распоряжении довольно большое количество инженеров, консультантов и разработчиков. С каждой новой операционной системой список этих людей растет. Во многих случаях оплачивать такое количество высококлассных специалистов экономически невыгодно. Соответственно производитель снова вынужден сконцентрировать свое внимание на самом выгодном с его точки зрения варианте операционной системы. В данном случае комбинация системы и набора программного обеспечения, с которым клиент желает работать, будут тесно связаны между собой. Поэтому на рынке довольно часто встречается ситуация, когда заказчику приходится работать с операционной системой, с которой он ни за какие коврижки не стал бы связываться при других обстоятельствах. Идти на такие жертвы приходится только из-за того, что нужная ему программа существует только для этой и никакой другой системы. Возможно, то, о чем мы будем говорить сегодня, поможет сгладить эту неприятную зависимость и отсутствие выбора. Таким образом, наша беседа неспешно подошла к тому, что успех Linux в определенной мере полезен всем свободным UNIX-подобным системам. Сегодня мы поговорим о том, как пользователи FreeBSD могут приобщиться к плодам Linux, благополучно заимствуя у своего пингвиновидного родственника те программы, которые отсутствуют в нашей продуктовой корзине. Для этого нам потребуется всего лишь включить так называемый механизм бинарной совместимости, изначально встроенный в недра FreeBSD. А это, в свою очередь, позволит запускать и успешно эксплуатировать большинство Linux-программ без всякой переделки внутри FreeBSD. Для всех примеров, приводимых в статье, использовалась FreeBSD версии 4.9, хотя под более младшими версиями системы все вышеописанное должно работать примерно так же. Давайте предпримем небольшой экскурс в историю обсуждаемого вопроса. Началось все в середине1996 года. Только что вышла FreeBSD 2.1.5 и Linux постепенно начинал набирать популярность в пока что узких кругах своих энтузиастов. Разработчики FreeBSD довольно быстро заметили потенциал Linux и решили, что бинарная совместимость с такой перспективной системой будет весьма кстати. К тому моменту FreeBSD уже была способна запускать приложения, написанные для MS-DOS и SCO Unix. Поэтому для того чтобы работа с Linux-программами стала возможна, не пришлось открывать новые континенты и делать какие-то кардинальные изменения в коде эмулятора. К началу 1997 года система эмуляции уже была способна запускать Applixware, скомпилированный для Red Hat Linux. К тому моменту в разговорах о подсистеме, обеспечивающей совместимость с Linux, постепенно выкристаллизовался и приобрел популярность термин, которым разработчики и пользователи пытались описать то, что происходит внутри программы, запускаемой в чужеродной среде. К сожалению, на тот момент никто так и не смог предложить названия лучшего, чем «бинарная эмуляция». Как мы убедимся позднее, при подробном рассмотрении архитектуры обсуждаемой системы этот термин не имеет ничего общего с реальным положением вещей. Но об этом позвольте сказать позднее. С каждым годом количество поддерживаемых приложений росло за счет все более точной реализации Linux API. На данный момент существует мнение, выражаемое разработчиками системы, которое говорит, что 90% Linux-программ будут работать так же надежно под управлением FreeBSD, как и под крылом родной системы. Самыми известными из них являются:
Единственная проблема, которая может помешать Linux-программе спокойно жить в нашей системе, это слишком глубокое использование файловой системы /proc, так как ее реализация весьма отличается от системы к системе. Еще одной западней для Linux-программы могут стать нестандартные способы работы с устройствами. В остальном же система работает на удивление хорошо прозрачно и стабильно. Платой за такую переносимость станет потеря примерно 2% быстродействия. Хотя по странному стечению обстоятельств некоторые чужие приложения функционируют под управлением FreeBSD даже быстрее, чем под Linux, особенно часто такой эффект наблюдается при работе приложений, записывающих очень много данных на жесткие диски. Видимо, файловая система ufs в данном аспекте является лучшей альтернативой, чем ext3, стандартная для Linux. Ну что же, давайте приступим к инсталляции единственного пакета linux_base. Выполнить это немудреное действо можно несколькими способами. Первый раз это обычно предлагают сделать при первоначальной установке системы.
Если вы пропустили этот момент или ответили нет, то огорчаться не стоит. Можно выполнить инсталляцию с помощью портов. # cd /usr/ports/emulators/linux_base # make install distclean И добавить в файл /etc/rc.conf следующую строку: linux_enable= "YES" Данная строка указывает системе, что во время старта надо загружать модуль ядра linux.ko, отвечающий за нужную нам функциональность. Можно поступить по-другому. Запускаем программу /stand/sysinstall и проходим через меню «Configure –> Packages», затем необходимо выбрать, откуда будет взят пакет ftp, http, CD. Затем перейти в раздел emulators и выбрать все тот же пакет linux_base. По завершении инсталляции не забываем внести изменения в /etc/rc.conf. После перезагрузки системы можно будет запускать Linux-программы. Доказательством того, что все идет по плану, будет следующая надпись, появляющаяся после загрузки на системной консоли: «Additional ABI support: Linux». Убедиться, что модуль правильно загрузился, можно, выполнив команду kldstat. В ответ должны получить что-то вроде этого: # kldstat
В директории /usr/compat/linux появится иерархия файлов, созданная по образу и подобию нашей виртуальной Linux-системы. # ll /usr/compat/linux
Версию установленной системы можно узнать вот так: # cat /usr/compat/linux/etc/redhat-release
В случае если вам не хочется подгружать необходимый модуль, при старте системы можно жестко вкомпилировать его в ядро. Для этого нужно дописать в файл конфигурации нового ядра опцию: options LINUX И затем произвести компиляцию и установку свежесобранного ядра. Выбор используемого пути оставляю за вами, в любом случае бинарная совместимость должна работать, если вы правильно выполнили мои инструкции. Закончив с инсталляцией, давайте разберемся, как же работает эта магическая комбинация, позволяющая запускать вожделенные Linux-приложения. Многие технически продвинутые читатели будут удивлены описываемыми возможностями. И впрямь, несмотря на схожесть идеологий, две обсуждаемые системы весьма отличаются друг от друга реализацией своих внутренних API (Application Programming Interface). Давайте подробнее разберемся в этом запутанном вопросе. Практически все UNIX-подобные системы состоят из двух компонентов. Это ядро, отвечающее за работу с устройствами, системой безопасности, и системные утилиты вкупе с пользовательскими программами, которые выполняют свои задачи, опираясь на системные функции, предоставляемые ядром. К примеру, если программа желает открыть какой-либо файл, она вызывает системную функцию open и передает ей некоторое количество параметров, описывающих то действие, которое необходимо выполнить. Ядро, получив запрос, выполняет его, если он может быть осуществлен без конфликта с системой безопасности, а полученные данные возвращаются программе, создавшей запрос. Большинство ядер UNIX-систем имеют схожий набор функций, но в то же время типы данных, количество передаваемых параметров и их порядок могут довольно сильно различаться. Несмотря на то, что в обеих системах для хранения исполняемых программ используется формат ELF, все же он слегка различается. Соответственно для запуска Linux-приложения система должна корректно определить тип исполняемого файла по его магической комбинации, обычно это первые 8 байт заголовка. Затем, пользуясь абстрактным классом загрузчика «execution class loader», в котором содержится таблица всех доступных на данный момент загрузчиков, система определяет, кому нужно отдать его на выполнение. В случае если этот файл оказывается шелл-скриптом, вызывается стандартная командная оболочка или та ее разновидность, название которой записано в первой строке выполняемого скрипта. В случае если нам в лапы попался файл в формате ELF, вызывается специализированный загрузчик этого типа файлов. На данном этапе загрузчик еще не знает, какой операционной системе принадлежит полученный файл. К примеру, он может быть создан для Linux, Solaris, FreeBSD или какой-либо другой системы, также имеющей привычку хранить свои исполняемые файлы в формате ELF. Соответственно, чтобы узнать, чья это вещь, загрузчик смотрит в специальную секцию ELF-файла и ищет известную ему метку (brand), однозначно описывающую родную для приложения систему. Если это ему не удается, то процесс загрузки прерывается, а на экране появляется вот такое сообщение: $ ./имя программы
В последнее время такая ситуация встречается очень редко, но все же стоит знать, как побороть это досадное недоразумение. Нужно всего лишь вручную промаркировать исполняемый файл именем родной системы. Для Linux это будет выглядеть следующим образом. # brandelf -t Linux имя программы Ну а мы продолжим рассмотрение процесса загрузки. После того как произошло определение принадлежности файла, в случае если мы работаем с Linux-приложением, происходит следующее: загрузчик изменяет указатели в специальной структуре proc, содержащей внутри себя адреса системных функций так, чтобы вместо родных функций ядра FreeBSD управление получали специальные функции, реализующие соответствующее поведение ядра Linux. Таким образом получается, что никакой эмуляцией тут и не пахнет. Просто в момент вызова Linux-приложением тех или иных функций система жонглирует указателями, ловко обманывая программу. Процесс Linux-приложения помечается специальным флагом, позволяющим системе отличать его от обычных FreeBSD-процессов, а модуль ядра linux.ko, опираясь на вышеуказанную метку, особым образом обрабатывает сигналы с тем прицелом, чтобы у процесса полностью создалось ощущение жизни внутри родной системы. Еще одним из полезных фокусов является то, что при попытке Linux-программы выполнить другую программу, поиск файла будет сначала вестись в директориях /usr/compat/linux, а в случае если ничего подходящего не нашлось, продолжится уже в корневой файловой системе. Яркой иллюстрацией таких уловок является поведение команды uname, родной для FreeBSD и Linux. $ uname –a
$ /usr/compat/linux/bin/uname –a
Всем желающим предлагается самостоятельно найти десять отличий. Разобравшись с хитросплетениями устройства бинарной совместимости, давайте наконец-то перейдем к практическим занятиям. В качестве первого примера посмотрим на инсталляцию Citrix ICA Client. Тут все просто. Берем с сайта Citrix дистрибутив либо в формате tar.gz (Citrix_ linuxx86.tar.gz), либо в rpm (ICAClient-7.00-1.i386.rpm). Оба они равнозначны, поэтому давайте посмотрим, как их устанавливать всеми доступными способами. В случае с tar.gz нужно распаковать пакет и запустить скрипт setuwfc. Несмотря на жалобы о том, что FreeBSD не входит в список поддерживаемых систем, инсталляция проходит на ура. Все жалобы проистекают от того, что скрипт вызывает команду uname для определения типа используемой системы, а в связи с тем, что загрузчик не распознает этот скрипт как Linux ELF-файл, то и подмена вызовов системных утилит не происходит. Соответственно вместо /usr/compat/linux/bin/uname работает /usr/bin/uname, честно сообщающая, что у нас не Linux, а FreeBSD. Впрочем, эта мелкая неполадка для нас не критична. Сразу же после завершения установки мы обнаруживаем, что все нужные файлы вполне удачно проинсталлировались в /usr/lib/ICAClient/. Если же вам хочется установить программу непременно из rpm, то нужно сделать вот так: # rpm -i --dbpath /var/lib/rpm --root /usr/compat/linux --ignoreos ./ICAClient-7.00-1.i386.rpm По идее все должно пройти отлично, хотя иногда я встречал такие rpm-пакеты, которые по разным причинам вызывают падение программы rpm. В таком случае можно вручную распаковать rpm-пакет, например, с помощью mc и разложить все файлы по нужным директориям самостоятельно. После удачной установки rpm-пакета все вновь созданные файлы обычно находятся в /usr/compat/linux. После первоначальной настройки Citrix ICA Client c помощью wfcmgr программа вполне готова к употреблению. В этом можно убедиться, посмотрев на следующий снимок экрана.
Для удачной установки Acrobat Reader придется повозиться чуть больше. Распаковываем дистрибутив и запускаем скрипт INSTALL. Проблема в том, что программисты фирмы Adobe пытаются не позволить нам пользоваться их детищем под управление FreeBSD. В ответ получаем следующую надпись:
Приняв лицензионное соглашение в качестве директории для установки, подтверждаем выбор по умолчанию /usr/local/Acrobat5/.
После того как копирование файлов будет завершено, можно попытаться запустить программу и получить горькое разочарование. $ /usr/local/Acrobat5/bin/acroread
Об этой беде мы уже говорили ранее в статье. Распотрошив скрипт acroread, довольно быстро находим проблему. Так как скрипты не являются бинарными ELF-файлами, система бинарной совместимости никак не может догадаться, что по запросу на вызов утилиты uname нужно запускать не /usr/bin/uname, а /usr/compat/linux/bin/uname. Исправить положение очень легко, нужно найти все вхождения символов uname в тексте скрипта и заменить их на luname. А затем в директории /usr/bin создать жесткую ссылку с именем luname на /usr/compat/bin/uname. Перезагружаем систему. Теперь запускаем acroread и радуемся как малые дети.
Конечно, можно было бы не создавать никаких ссылок, а просто вместо uname написать /usr/compat/linux/bin/uname, но я человек ленивый и стараюсь уменьшить количество совершаемых телодвижений. К тому же данная проблема довольно типична для скриптов Linux-приложений, поэтому ссылка на luname вам пригодится скорее всего еще не один раз. Кстати, стоит отметить, что некоторые приложения могут требовать для нормального функционирования некоторые библиотеки, используемые для разработки других приложений. Ярким примером такой разновидности программ выступает ORACLE. Поэтому нам лучше поставить еще один добавочный пакет, называемый linux_devtools. # # cd /usr/ports/emulators/linux_devtools # make package Иногда несмотря на то, что приложение удачно установилось, работать оно все же не хочет по причине отсутствия некоторых библиотек. Для начала проверим, какие же именно библиотеки ему необходимы. Делать это мы будем на примере WordPerfect. # ldd xwp
Соответственно нам нужно всего лишь найти эти библиотеки на Linux-машине и скопировать их себе в систему бинарной совместимости. Лично мне пришлось сделать так всего один раз за все время работы с системой. С другой стороны, чем больше программного обеспечения вы будете устанавливать, тем больше шансов, что все необходимые библиотеки у вас уже будут находиться там, где положено. Иногда Linux-приложения, интенсивно использующие DNS, отказываются работать и выводят на экран следующие жалобы:
Все дело в том, что они пытаются использовать по умолчанию файл host.conf от FreeBSD, а нам нужно совершенно другое. Поэтому вписываем в /usr/compat/linux/etc/rc.conf следующие строки: order hosts, bind multi on И навсегда забываем о проблеме с DNS. Как вы могли убедиться, работать с интерфейсом бинарной совместимости довольно просто, а выгода от этого получается немалая. |
АНДРЕЙ БЕШКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
