Linux и FreeBSD: сравнение (Страница 8 из 8)

>Критические обновления к самой системе выходят приблизительно раз в месяц — на это всё тратиться час; на компиляцию лишь одного ядра — десять-пятнадцать минут вместе с разбором/заданием конфига.

Ну вот недавно в списке рассылки промелькнуло несколько уязвимостей ядра Linux 2.6.24, в Debian скопом закрытых одним обновлением. Я гляжу иногда в список рассылок посвященный обновлениям в стабильной ветке Debian, просто чтобы быть в курсе. Как Вы думаете, если бы у меня стояло это ядро (мне везде хватает ядра 2.6.18), сколько времени я бы потратил на компиляцию? Ответ: да мне даже конфиг ядра вспоминать бы не пришлось!

>Во FreeBSD принято: раз порт программы обновился, то программа залатана, исправлена в ней какая-либо ошибка. Списки рассылки читать необязательно, но желательно быть в курсе событий, читая верхние строчки файла /usr/ports/UPDATING для ПО (там описываются только критические причины обновления и нюансы) и соответствующий файл для исходников системы.

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

В стабильной ветке Debian любой пакет обновляется только по причине залатывания дырки. В формате конфигов или чём-либо ещё, изменения не могут произойти в ПРИНЦИПЕ. Стало быть мне не нужно при обновлении ничего читать и проверять работоспособность сервисов после обновления, обновления вообще можно производить во время моего отсутствия в автоматическом режиме (допустим нет меня - я в отпуске).

>Возможностей много == сложность растёт в геометрической прогрессии от числа этих самых фич и их комбинаций.

Не всегда так. Это зависит от взаимной зависимости компонентов. Но вообще в apt-cacher'е нет ничего сложного - это небольшой perl-скрипт. Пожалуй даже ntpd и тот на порядок сложнее.

>Ну вот, видите. Сервер (http) всё-таки нужен.

Для apt-cacher'а - не нужен. Для зеркала вместо web-сервера можно использовать nfs, samba или ftp-сервер.

>Билд-сервер — это всего лишь РОЛЬ, которую может на себя взять одна из машин в сети.

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

>А вот установка отдельного кэш-сервера и http/ftp-сервера на машину чревата куда большими заморочками по обеспечению безопасности и согласованности (доступности).

Приведите пример, чем http/ftp-сервер сложнее nfs/samba в плане безопасности? Их всех можно ограничить фаерволлом - вот вам безопасность. Согласованность - это единое зеркало, какая может быть рассогласованность? Кстати NFS далеко не безопасен, т.к. основан на протоколе UDP и поэтому подвержен спуффингу, и не имеет механизмов авторизации.

И вообще, http/ftp/nfs/samba нужны для полноценного зеркала, которое для личных целей создавать неоправданно - это опять же принцип микроскопа и гвоздей. Для личного использования внутри фирмы или дома достаточно поставить и настроить apt-cacher, он не требует ничего сверх самого себя и легко настраивается - достаточно подрихтовать под себя две строчки в конфиге.

В общем Вы мне предлагаете взамен
варианта 1. установки apt-cacher, исправления двух строчек в конфиге и настройки автоматического обновления
вариант 2. потратить деньги на железку под build-сервер, тратить деньги на электроэнергию (вместе с дополнительной мощностью кондиционирования серверного помещения), настроить этот сервер, использовать небезопасный NFS, регулярно читать UPDATING, обновлять вместе с дырявыми пакетами ещё и пакеты с обновлением версии, проверять после обновления работоспособность каждого сервиса.

Где смысл?

Понятно. Всё забыли.

Согласен. В этом вы правы. Может быть из-за этого Debian делится на стабильную, тестовую и экспериментальную ветки.

Ага. Это "+" Debian. Во FreeBSD нужно уповать на правильность автообновления (если оно запущено) и версии обновляющихся программ не слишком разнятся.

Хотя, вот обратный пример: трудно спутать ports/www/tomcat55 и ports/www/tomcat6 — это два разных порта. И команды старта у них другие. И скрипты настроек отличаются. Так что один другого обновить не сможет. И ещё, при деинсталляции, в одноимённом каталоге приложения/сервиса останутся вручную отредактированные скрипты — pkg_delete не будет удалять каталог приложения, если контрольная сумма удаляемых файлов не совпадает с той, что зарегистрирована в базе данных уст.приложений — предложит удалить вручную "остатки".

Так что небольшой промах с вашей стороны по поводу изменения конфигов. Да, это бывает, но не так часто. И всё это можно отследить на билд-машине. Конфликтующие пакеты либо не соберутся, либо не проинсталлируются на целевых машинах — останемся с тем, что есть.

Из статьи по ссылке видно, что структура каталогов у этого кэширующего сервиса отлична от принятой в Debian.
На билд-машине FreeBSD это не так — дерево пакетов соответствует тому, что может быть в локальных каталогах /usr/pors/packages/ любых машин. Так что опять ничего лишнего настраивать не надо.

Вы считаете, что httpd (Apache) на кэширующем сервере Debian не отнимает ресурсов? Я обратного мнения.

В отличие от Apache и lighthttpd, сетевая файловая система не имеет сторонних подключаемых компонентов. Грубо говоря, трояны не могут просто так внедриться в код nfs — у Apache и lighthttpd вероятность подхвата червя поболее. Следите за уязвимостями и вовремя закрывайте дырки в Web-серверах.

SAMBA — это, очевидно, из другой оперы и как-то неспортивно, то ли...

Во-первых, это всё транспортные протоколы. Причём NFS родная сетевая файловая система Unix. И считать её аналогом протоколов более высокого уровня (FTP и HTTP), а тем более SAMBA, по меньшей мере неожиданно. Данные по NFS передаются в несколько раз быстрее, чем через вышеназванные протоколы.

На это и порешили.

Ничего я вам не предлагаю. Хотите — используйте лишние сетевые сервисы у себя в сети и тяните бинарные пакеты "по-требованию". Кичитесь надёжностью залатанного ПО древнейших версий. Используйте, если есть такая необходимость.

То же самое можно делать на любой машине FreeBSD, ничего не собирая из исходников, а вытягивая свежие бинарные пакеты из репозитория, устанавливая их на неё же, одновременно тестируя работоспособность конфигурации, и выкладывая эти же пакеты на NFS-шару остальным машинам для обновления.

Отредактировано iZEN (2008-12-09 20:31:39)

iZen:

>Вы считаете, что httpd (Apache) на кэширующем сервере Debian не отнимает ресурсов? Я обратного мнения.

Ещё раз повторяю: для apt-cacher не нужен веб-сервер! И ресурсов он отнимает гораздо, ГОРАЗДО меньше, нежели билд-сервер.

>В отличие от Apache и lighthttpd, сетевая файловая система не имеет сторонних подключаемых компонентов. Грубо говоря, трояны не могут просто так внедриться в код nfs — у Apache и lighthttpd вероятность подхвата червя поболее. Следите за уязвимостями и вовремя закрывайте дырки в Web-серверах.

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

С TCP-соединениями это сделать не так просто. Тем более вероятность подхвата червя практически исключена, поскольку этот веб-сервер специализированный, а стало быть просто не имеет возможности запуска сторонних скриптов (например техника PHP-инклюдинга здесь попросту неприменима), а во-вторых - закрыт фаерволлом.

>Данные по NFS передаются в несколько раз быстрее, чем через вышеназванные протоколы.

Во-первых не в несколько раз быстрее, а процентов на 10, максимум - 20. Во-вторых - это экономия на копейках. Во FreeBSD больше времени уйдёт на перекомпиляцию, поскольку вместе с дырявыми пакетами будут обновляться и просто повысившие версию, а потом всё это хозяйство ещё будет и копироваться по сети.

Ладно, суть вообще не в этом. Я уже сказал, что вместо кэшера в Debian можно организовать зеркало и раздавать его файлы по тому же nfs.

>Хотите — используйте лишние сетевые сервисы у себя в сети.

Всего один несложный perl-скрипт, который закрыт фаерволлом так, что доступен только оттуда, где он непосредственно нужен.

>Кичитесь надёжностью залатанного ПО древнейших версий.

Работает? Не трогай.

>То же самое можно делать на любой машине FreeBSD, ничего не собирая из исходников, а вытягивая свежие бинарные пакеты из репозитория, устанавливая их на неё же, одновременно тестируя работоспособность конфигурации, и выкладывая эти же пакеты на NFS-шару остальным машинам для обновления.

Можно. Просто я привык думать о количестве необходимой работы в контексте десятка серверов. При том что сопровождение серверов - это не единственная моя обязанность.

Вообще, Вы меня сейчас порадовали, у Вас всё-таки бывают моменты, когда Вы не только говорите, но и умеете слушать

Вы уже второй раз повторяете, что рекомендованный способ установки ПО на FreeBSD - порты. Если вас не затруднит, объясните пожалуйста,  почему вы утверждаете что это так. Потому как, в хэндбуке информация такая: "FreeBSD provides two complementary technologies for installing third-party software on your system: the FreeBSD Ports Collection (for installing from source), and packages (for installing from pre-built binaries). Either method may be used to install the newest version of your favorite applications from local media or straight off the network".

connstance

>Вы уже второй раз повторяете, что рекомендованный способ установки ПО на FreeBSD - порты. Если вас не затруднит, объясните пожалуйста,  почему вы утверждаете что это так.

ЕМНИП именно это было написано в хэндбуке времён FreeBSD 5.0. Если сейчас это не так - прошу извинить. Вообще моя практика использования пакетов в своё время показала, что многие пакеты не работали как надо без пересборки, что подразумевало использование портов.

>http://vershinin.dyndns.org/doku.php?id=freebsd_on_dell1525

Автора этой статьи я знаю лично. Можно сказать, в своё время именно с его подачи мой выбор в пользу первой nix-системы склонился именно в пользу FreeBSD. О чём я ничуть не жалею - для обучения она попросту незаменима.

Ключевые слова этой статьи вот в чём:
>практически любой дистрибутив в установке по умолчанию показывал чудеса тормознутости…
А далее расписывается с чего началось использование FreeBSD - с поиска патча для драйвера сетевой карты.

В общем дальше можно и не читать. Автор даже не упомянул, были ли проблемы с железом в Linux. Но если он об этом не сказал, подразумевается, что проблем не было. Вместо того чтобы снести с уже работающей системы тормозной GNOME и поставить Fluxbox, который и был впоследствии установлен на FreeBSD, автор начинает по винтику выстраивать с нуля новую систему, подбирая патчи к ядру и драйверы. Где тут объективность?

Я, кстати, давал ему свою статью на вычитку. Он нашёл довольно много недостатков в моей статье и высказал очень ценные замечания, которые я принял и учёл. За это я ему очень благодарен.