Linux vs. bsd: что использовать?

BSD и развитие Интернета

Следующий важный этап нашей экскурсии по развитию операционной системы Unix переносит нас в 1974 год на противоположное побережье от Bell Labs, где ученые в области компьютерных наук Калифорнийского университета в Беркли решили попробовать установить на свои системы Unix. Они и их студенты сочли Unix подходящим вариантом для своих исследований и начали совершенствовать ОС, расширяя её функционал путем добавления всевозможных новых системных вызовов и утилит.

Эволюция BSD (сокр. от англ. «Berkeley Software Distribution») была плавной и последовательной: от набора небольших улучшений до чего-то совершенно нового. Студенты, некоторые из которых позже стали лидерами в области вычислительной техники, добавляли в систему различные улучшения. Одним из таких крупных улучшений стал редактор vi, ежедневно применяемый в своей работе многими пользователями Unix, а теперь и пользователями Linux. Билл Джой, который в студенческие годы изобрел редактор vi во время своей ранней работы над системой Unix в Беркли, организовал в 1977 году первый выпуск своего редактора под маркой «Berkeley Software Distribution». Позже Джой (вместе с другими сооснователями) создал компанию Sun Microsystems, которая позволила Unix взять на себя крупномасштабные вычисления.

Beastie — талисман BSD

Применяя Unix для тяжелых, связанных с сетями вычислений, разработчики BSD обнаружили отсутствие многих необходимых системных вызовов. В результате чего они добавили в систему новые системные функции, а также библиотечные вызовы (которые выполняются в пространстве пользователя, а не в пространстве ядре). Связь между Bell Labs и BSD стала двунаправленной, поскольку разработчики Unix позаимствовали свои любимые системные и библиотечные вызовы из BSD.

Сетевой стек был самым важным вкладом BSD в этом деле. История гласит, что BBN Technologies создали Интернет в рамках сотрудничества с оборонным агентством ARPA (позже DARPA). Но когда Интернет стал мейнстримом, в нем использовались стеки протоколов, сетевые службы и инструменты, созданные проектом BSD.

Компания AT&T, которой принадлежала Bell Labs, неплохо зарабатывала на лицензировании Unix.

Примечание: Кстати, официальное название Unix, в соответствии с зарегистрированным товарным знаком, пишется большими буквами — UNIX.

Как уже ранее упоминалось, к системе прилагались её исходные коды. Но в Беркли сделали нечто гораздо более радикальное: они выпустили свой собственный код под лицензией, которая разрешала пользователям вносить изменения и делать всё, что они захотят, включая продажу системы с внесенными в нее изменениями. Лицензия BSD была одной из первых свободных лицензий на программное обеспечение с открытым исходным кодом. И она до сих пор применяется многими проектами.

Популярность BSD обуславливалась бесплатным распространением системы, а не каким-либо её техническим превосходством над Unix от Bell Labs. Как я уже упоминал, AT&T не испытывала никаких угрызений совести по поводу включения наработок BSD в Unix. Сегодня код BSD выглядит устаревшим и в некоторых моментах немного пугающим, но операционная система и её утилиты были очень популярны в то время. В конце 1970-х и начале 1980-х годов, до того, как персональные компьютеры стали коммерчески доступны, большой популярностью пользовались VAX и миникомпьютеры с BSD.

BSD также послужила толчком к прорыву, который привел Unix в коммерческое русло: основанию Sun Microsystems. Билл Джой и его коллеги воспользовались разрешительной лицензией BSD для продажи компьютеров с их собственной доработанной версией операционной системы BSD, называемой SunOS. Рабочие станции и серверы мини-компьютеров Sun Microsystems уничтожили поколение других компаний, производящих мини-компьютеры, и начали устанавливать стандарты для современных вычислений и сетей — всё на основе SunOS, что, конечно же, подразумевало использование BSD.

Использование FreeBSD и Linux

Интересно, что и FreeBSD, и Linux лежат в основе множества других открытых и проприетарных систем, а также используются на различных устройствах.

Например, FreeBSD легла в основу следующих продуктов:

• FreeNAS — операционная система для сетевого хранилища.
• pfSense — дистрибутив межсетевого экрана.
• m0n0wal — дистрибутив встроенного межсетевого экрана.
• Darwin — ядро систем macOS, iOS.
• Junos — операционная система для сетевого оборудования от Juniper Networks.
• Isilon Systems’ OneFS — операционная система для сетевого хранилища от Dell EMC.
• Netflix Open Connect appliances — стриминговые серверы.
• Игровые консоли PlayStation 3, PlayStation 4, PlayStation Vita от Sony Computer Entertainment.
• и др.

На основе ядра Linux созданы:

• Android — операционная система для мобильных устройств (Google).
• Tizen — операционная система для мобильных устройств (Samsung).
• VMware ESXi — гипервизор.
• ChromeOS — операционная система для ноутбука Chromebook.
• ОС для одноплатных компьютеров Cotton Candy и Raspberry Pi.
• ОС для сетевого оборудования Linksys.
• и др.

BSD — это UNIX?

И действительно, операционная
система UNIX никогда не представляла собой программное обеспечение,
имеющее открытый исходный код, в связи с чем BSD определенно нельзя
будет назвать системой UNIX, хотя бы потому, что графический интерфейс
операционных систем является разным. Однако в то же время компания,
которая разрабатывала UNIX, активно пользовалась чужими разработками, и в
частности это относится к программному обеспечению, которое
разрабатывалось организацией CSRG.

Первоначально дистрибутивы BSD,
а также графический интерфейс операционных систем представлял собой
комплексы пользовательских программ, и такая ситуация продолжалась ровно
до тех пор, пока компания не заключила контракт с DARPA, подчиненным
Министерству обороны США. Цель данного контракта – это обновление
различных коммуникационных протоколов, на которых поддерживалась
компьютерная сеть агентства.

В течение 80-х годов сформировалось
несколько компаний, занимающихся производством рабочих станций, при этом
стоит отметить, что многие из них приобретали лицензии на использование
UNIX вместо того, чтобы пробовать разрабатывать с нуля собственное
программное обеспечение. В частности, стоит выделить компанию Sun,
которая поступила таким образом и решила на основе версии 4.2BSD в
конечном итоге выпустить собственную операционку, которая называлась
SunOSTM. Когда же компания AT&T, занимающаяся разработкой UNIX, в
конечном итоге решила заняться коммерческой продаже собственной
операционной системы, появилась довольно аскетичная реализация — System
III, за которой с течением времени последовал также выход системы System
V.

4.4. Какие существуют варианты BSD?

В отличие от многочисленных дистрибутивов Linux, в мире существует лишь четыре
крупных BSD проекта с открытыми исходными кодами. Каждый из них поддерживает своё
собственное дерево исходников и своё собственное ядро. На практике однако оказывается,
что пользовательские части (userland) различных BSD отличаются гораздо меньше, чем у
разных дистрибутивов Linux.

Цели каждого из проектов не поддаются чёткой формулировке. Различия между ними весьма
субъективны. В основном,

• проект FreeBSD нацелен на повышение производительности и простоту в использовании
  конечными пользователями. FreeBSD очень ценят в среде Web-хостеров. Эта ОС работает
  на нескольких аппаратных платформах, в том числе системах на базе процессоров
  i386″ (»ПК»), системах, построенных на 64-разрядных
  процессорах AMD, системах UltraSPARC╝, системах,
  работающие на базе процессоров Alpha компании Compaq, а также системах, построенные по
  спецификациям NEC PC-98. Число пользователей FreeBSD значительно превышает число
  пользователей других проектов.

• проект NetBSD ставит целью максимальную мобильность (или переносимость) кода: девиз
  »конечно NetBSD работает на этом». NetBSD поддерживает машины от крошечных
  палмтопов до огромных серверов и использовалась NASA в космических миссиях. Это хороший
  выбор для старой не-Intel╝ аппаратуры.

• проект OpenBSD нацелен на безопасность и »чистоту» кода. С помощью комбинирования
  концепций открытых исходников и скрупулёзного анализа кода проект демонстрирует
  чудеса корректности работы системы. В силу названных причин совершенно естественно, что
  OpenBSD выбирают организации, для которых очень важна защита информации, например
  банки, фондовые биржи и различные департаменты правительства США. Также как и NetBSD,
  проект поддерживает целый ряд аппаратных платформ.

• Целью DragonFlyBSD является достижение высокой производительности и масштабируемости
  в любой ситуации—как для одиночных однопроцессорных, так и крупных кластерных систем.
  DragonFlyBSD ставит перед собой несколько долгосрочных технических задач, но основной
  упор делается на создание инфраструктуры для работы с SMP, которая была бы проста для
  понимания, поддержки и ведения в ней разработок.

Следует упомянуть ещё две операционных системы BSD UNIX, которые не предоставляют публичного доступа к своим исходным
кодам. Это BSD/OS компании BSDI и Mac═OS╝ X компании
Apple.

3.1. Установка и настройка Linux

Первый шаг описывает нормальную установку Linux. Вы должны на жестком диске
оставить место для FreeBSD. Не создавайте в Linux раздел подкачки, но если
Вы очень хотите сделать его, то разместите его туда, куда затем установите
FreeBSD. Таким образом, потом Вы сможете удалить этот раздел и использовать
место для установки FreeBSD.

Когда Вы установите Linux, необходимо пересобрать ядро. Прочитайте The
Linux Kernel HOWTO, если еще никогда этого не делали. Вы должны ответить
«y» на UFS filesystem support (read only) и BSD disklabel (FreeBSD
partition tables) support:

UFS filesystem support (read only) (CONFIG_UFS_FS) [N/y/m/?] y
BSD disklabel (FreeBSD partition tables) support (CONFIG_BSD_DISKLABEL) [N/y/?]
(NEW) y

8.2. Авторские права

Авторские права на русский перевод этого текста принадлежат 2000 SWSoft Pte Ltd.
Все права зарезервированы.

Этот документ является частью проекта Linux HOWTO.

Авторские права на документы Linux HOWTO принадлежат их авторам, если явно
не указано иное. Документы Linux HOWTO, а также их переводы, могут
быть воспроизведены и распространены полностью или частично на любом
носителе, физическом или электронном, при условии сохранения этой заметки об
авторских правах на всех копиях. Коммерческое распространение разрешается и
поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о
таких дистрибутивах.

Все переводы и производные работы, выполненные по документам Linux HOWTO,
должны сопровождаться этой заметкой об авторских правах. Это делается в
целях предотвращения случаев наложения дополнительных ограничений на
распространение документов HOWTO. Исключения могут составить случаи
получения специального разрешения у координатора Linux HOWTO, с которым
можно связаться по адресу приведенному ниже.

Мы бы хотели распространить эту информацию по всем возможным каналам. Но
при этом сохранить авторские права и быть уведомленными о всех планах
распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь
к координатору проекта Linux HOWTO по электронной почте:
или к координатору русского
перевода Linux HOWTO компании SWSoft Pte Ltd. по адресу

Спор вокруг систем инициализации в Linux

System V init (или просто «SysV») — это система инициализации, которая существует со времен операционной системы System V, которая была выпущена в 1983 году. SysV оставалась системой инициализации в течение почти трех десятилетий (за некоторыми исключениями). Многие IT-специалисты и программисты в силу своей привычки не хотели отказываться от SysV, да и к тому же она была очень простой для понимания.

Проблема с SysV заключалась в том, что в её основе лежали концепции, существовавшие много лет назад. SysV не хватало возможности нативно обрабатывать многие вещи, такие как: обнаружение съемных носителей, корректное обнаружение аппаратного обеспечения и загрузка встроенного ПО, загрузка различных модулей и пр. Кроме того, при использовании данной системы, инициализация процессов происходит последовательно, т.е. одна задача запускается только после успешного завершения предыдущей. Часто это приводило к задержке и длительному времени загрузки. Задачи, подобные монтированию файловых систем, выполняются один раз во время загрузки, после чего «забываются». Но такого подхода недостаточно для автоматизированного управления сервисами, требующими к себе постоянного внимания.

В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.

Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.

В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.

Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?

systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.

В результате systemd становится самостоятельной платформой, и её повсеместное распространение непреднамеренно препятствует разработке программного обеспечения, которое является переносимым и совместимым с операционными системами, не поддерживающими systemd. Но действительно ли всё так печально? Конечно, нет. Прежде всего, это проект с открытым исходным кодом, и у людей есть выбор: использовать его или нет. Пользователи и разработчики могут извлечь выгоду из наличия нескольких конкурирующих систем инициализации, и нет вины systemd в том, что основные дистрибутивы переключились на нее из-за её плюсов.

Модульный сетевой стек Netgraph

Самое ощутимое отличие сетевой подсистемы FreeBSD от таковой в Linux — альтернативный сетевой стек Netgraph. Как и GEOM, Netgraph представляет собой фреймворк, позволяющий строить очень гибкие конфигурации обработки информации, но в этот раз не запросов ввода-вывода, а сетевых пакетов.

В терминологии Netgraph каждый обработчик пакетов называется узлом, принадлежащим определенному типу. У узла есть вход и выход (называемые хуками). Проходя через узлы, пакет может видоизменяться, инкапсулироваться в другой пакет и так далее.

FreeBSD поддерживает десятки различных типов узлов, вот только часть из них:

• ng_ether — предназначен для представления сетевой карты в виде узла;
• ng_iface — предоставляет псевдоинтерфейс для определенного стека протоколов. Используется, например, для создания PPTP VPN с помощью MPD;
• ng_ipfw — используется для интеграции ipfw и Netgraph;
• ng_nat — одна из многочисленных реализаций NAT во FreeBSD;
• ng_netflow — поддержка NetFlow; одно из наиболее распространенных применений Netgraph;
• ng_one2many — реализация дублирования пакетов. Поддерживает три алгоритма передачи: Round Robin (использующийся по умолчанию), «доставка всем» и Failover — пакет отправляется на первый «живой» хук.
  Также есть статистика;
• ng_pipe — простейший шейпер трафика;
• ng_tag — управление тегами mbuf (теги используются для «навешивания» служебной информации на пакет внутри ядра);
• ng_tee — аналог утилиты tee. Пакеты, проходящие через этот узел (помимо того, что идут, куда шли), могут заворачиваться и на другой.

Пример зеркалирования пакетов с помощью Netgraph (как входящих, так и исходящих):

Разберем, что делает каждая команда. Первая загружает модуль ядра, отвечающий за представление сетевой карты в виде узла Netgraph (в моем случае карты назывались em0 и em1 и узлы Netgraph именовались соответственно). У данного типа есть три хука: lower, upper и orphans. На первый поступают исходящие со стороны системы пакеты, на второй, соответственно, попадающие с физического уровня. На третий поступают некорректные пакеты, и в нашем примере он не используется.

Следующая команда создает узел типа tee и одновременно соединяет хук lower узла em0 с хуком left вновь созданного узла, который пока еще никак не именуется.

Остановимся на типе tee подробнее. Узлы данного типа обладают четырьмя хуками: left, right, left2right и right2left. Основная его задача заключается в том, чтобы создавать «разрыв» между двумя хуками, которые обычно соединены в одном узле, и встраиваться в этот «разрыв», позволяя затем перехватывать все, что проходит через препарируемый узел.

Таким образом, третья команда устраняет созданный нами же «разрыв» между двумя хуками, позволяя пакетам идти как обычно. Первый аргумент команды ngctl connect — узел, который подключается. Второй — узел (точнее, относительный или абсолютный путь), к которому подключается первый узел. Третий аргумент — хук первого узла, четвертый — хук второго.

Четвертая команда именует ранее созданный узел.

Пятая создает узел типа one2many (который может действовать и в обратном направлении — то есть many2one), подключая хук one к хуку lower узла интерфейса, на который мы будем зеркалировать.

Шестая команда необходима для корректной работы зеркалирования — без нее система будет дублировать отдельные пакеты.

Седьмая команда подключает many1 к хуку left2right, через который проходят все входящие пакеты, поскольку они идут от хука lower узла em0 (к которому подключен хук left узла типа tee) к хуку upper (к которому, соответственно, подключен хук right).

Восьмая команда делает то же самое с исходящим трафиком, подключая many2 к right2left.

Две команды в совокупности направляют два потока через узел типа one2many на хук one, подсоединенный к узлу em1 посредством хука lower, с которого пакеты и покидают систему.

Последняя команда активирует сетевой интерфейс.

4.3. Версии BSD

FreeBSD, NetBSD и OpenBSD предоставляет миру три различных варианта системы. Как и в
Linux, версиям присваиваются номера, например 1.4.1 или 3.5. В добавок, номер версии
имеет суффикс — обозначение варианта, которое указывает на цели той или иной
версии.

1. Версия для разработчиков носит название CURRENT. FreeBSD
   присваивает ей и номер, например FreeBSD 5.0-CURRENT. NetBSD использует чуть-чуть
   другую схему наименований и добавляет к номеру однобуквенный суффикс, обозначающий
   изменения во внутренних интерфейсах. Пример: NetBSD 1.4.3G. OpenBSD не нумерует
   разрабатываемую версию (»OpenBSD-current»). Все новые разработки производятся
   именно на этой »ветке» (branch) системы.

2. Через определённые интервалы от 3 до 6 месяцев проект выпускает версию RELEASE, которая распространяется на CD-ROM и доступна для скачивания с
   серверов FTP. Примерами таких версий могут служить OpenBSD 2.6-RELEASE и NetBSD
   1.4-RELEASE. Этот вариант предназначен для конечных пользователей. NetBSD также
   предоставляет так называемые исправленные
   релизы (patch releases), обозначаемые третьей цифрой в номере, например
   NetBSD 1.4.2.

3. По мере обнаружения ошибок в версии RELEASE необходимые исправления вносятся в
   дерево CVS. Получающаяся система в проекте FreeBSD носит название STABLE, а в NetBSD и OpenBSD продолжает называться RELEASE. Некоторые
   мелкие улучшения тоже иногда вносятся в эту версию после продолжительного периода
   тестирования в CURRENT.

GEOM и управление дисками

GEOM — фреймворк для работы с блочными устройствами. Представляет собой нечто вроде системы модульной обработки запросов ввода-вывода на пути от диска к ФС и обратно. Один модуль (экземпляр класса в терминологии GEOM) может отвечать за разбивку диска на разделы, другой за шифрование раздела, третий за организацию RAID и так далее.

Все эти модули (экземпляры классов) можно объединять для создания самых разных конфигураций, не ограниченных какими-либо рамками. Например, создать RAID-массив из диска, раздела и зашифрованного раздела, подключенного по сети.

Некоторые из доступных классов:

• geom_ccd — concatenated disk — предназначен для создания массивов дисков. Поддерживается объединение и зеркалирование;
• geom_concat — также предназначен для объединения дисков;
  geom_eli — шифрование. Поддерживает несколько алгоритмов шифрования, два независимых ключа, аппаратное ускорение;
• geom_gate — поддержка хранения по сети. Для его использования необходимо наличие FreeBSD на устройстве, накопитель которого расшаривается;
• geom_journal — поддержка журналирования (только для UFS2);
• geom_mirror — очередная реализация зеркалирования;
• geom_raid — позволяет подключать некоторые реализации «аппаратного» RAID, поддерживаемого во многих материнских платах начального уровня.

Посмотрим, как включить шифрование с помощью geli (требуется чистый или неиспользуемый жесткий диск):

Чтобы устройство подключалось во время загрузки, нужно добавить строку в файл /etc/rc.conf:

И изменить /etc/fstab. Пароль будет запрошен при загрузке.

Создание шифрованного контейнера на жестком диске