Bsdmag 12 2011 rus by plok

В НОМЕРЕ

Дорогие читатели,

Перед вами пилотная, русская версия журнала. Разговоры о её создании велись долгое время и, наконец, она уже здесь. Открывает выпуск отчет об участии проекта FreeBSD в программе компании Google Inc. под названием Google Code-In. Зачем такая программа существует, что из себя представляет и что из этого всего получается - читайте материал от Benedict Reuschling. Мы также расскажем, как установить PC-BSD на маковскую аппаратуру сюжет от Kris Moore. Не забудем и про пользователей OpenBSD - вы увидите сами, насколько просто становится обновлять эту операционную систему, а также создавать динамические графики с помощью Cacti и Symon. Большая статья от Paul Ammann, посвященная пересборке ядра FreeBSD. Зачем такая процедура нужна, что нужно сделать по окончании сборки читайте главную тему этого выпуска. Интересную статью об использовании syslog-ng подготовил Robert Fekete. В ней изложены не только форматы системных сообщений, но и разнообразные варианты применения этого инструмента на практике. Первая часть статьи, общий цикл которой посвящен защите от взлома FreeBSD, подготовлена Robert Sommerville. С позиции зубра в IT-отрасли он расскажет о типах хакеров, на что следует ориентироваться, если вы не хотите заполучить незваных гостей и т.д. Этот материал также дополняет статья от Michael Shirk, в которой он поделится опытом по усилению защиты BSDсистем с помощью встроенных механизмов - уровней безопасности. В рубрике „Поговорим” мы затронем те мероприятия, которые проводил фонд FreeBSD в 2011 году. Какие проекты и решения были воплощены в жизнь и чего ожидать в следующем.

Редактор английской версии: Patrycja Przybyłowicz patrycja.przybylowicz@software.com.pl Авторы: Benedict Reuschling, Kris Moore, Antoine Jacoutot, Paul Ammann, Toby Richards, Robert Fekete, Robert Sommerville, Michael Shirk, Dru Lavigne Исполнительный директор: Ewa Dudzic ewa.dudzic@software.com.pl Русская редакция: ru.bsdmag@gmail.com Издатель : Software Press Sp. z o.o. SK ul. Bokserska 1, 02-682 Warszawa Poland worldwide publishing tel: 1 917 338 36 31 www.bsdmag.org Все торговые марки, задействованные в журнале, использованы для информационных целей. Права на них принадлежат соответствующим компаниям.

Наслаждайтесь чтением и, надеемся, хорошим настроением! Команда русской редакции

12/2011

В НОМЕРЕ

Что нового FreeBSD в программе 04 Участие Google Code-In Benedict Reuschling

Впервые проект FreeBSD вовлечен в программу, организованную Google Inc. для привлечения студентов к участию в open-source проектах — Google Code-In (аббревиатура GCIN).

Уголок разработчика PC-BSD на Мак 07 Устанавливаем Kris Moore

Начиная с версии PC-BSD 9.0-RC1 стала возможной простая инсталляция системы на Макинтош или же на BootCamp-раздел MacBook. В этой статье мы бегло рассмотрим как можно настроить Мак для двойной загрузки и произведем непосредственно саму установку.

ваши конфигурационные 10 Храним файлы как новенькие с помощью sysmerge (8)

Antoine Jacoutot

В прошлом, обновление конфигурационных файлов требовало запускать программу «patch» (с нужными изменениями, находящимися на странице upgradeXX. html сайта OpenBSD), которая обновила бы некоторые файлы. Часть из них администратор вообще редко изменяет. Либо же он должен был сам вручную внести требуемые изменения между старой и новой версией ... что мягко говоря, несколько утомительно. Инструмента, который облегчил бы администратору его работу при обновлении конфигурационных файлов, и сделал бы сам процесс легким и быстрым, до определенного момента не существовало. По этой причине утилита sysmerge и была создана.

How-To Подготовливаем свое собственное ядро FreeBSD

16 Paul Ammann

У компиляции собственного ядра операционной системы имеется ряд преимуществ и недостатков. Однако, новые пользователи могут столкнуться с таким вопросом — а как именно его собирать?

www.bsdmag.org

5.0: PHP, Cacti и Symon 28 OpenBSD Toby Richards

В прошедшем октябре автор рассказывал о том, как создать сервер на базе OpenBSD-Nginx-MySQL-PHP (ONMP). Теперь же вы узнаете, как установить Cacti, а также вести мониторинг системы с помощью Symon.

полезную информацию из 32 Извлекаем лог-сообщений Robert Fekete

Приложение syslog-ng – это мощный и гибкий инструмент для хранения и обработки системных сообщений, которое помогает в работе системных администраторов. В этой статье рассматриваются некоторые новые и некоторые не слишком известные возможности..

Безопасность компрометации FreeBSD 40 Анатомия (часть 1-я) Rob Sommerville

Считается, что семейство BSD более устойчиво к атакам, нежели остальные системы, однако ни один сервер или IT-продукт не застрахован от взлома. В этой статье рассматриваются лучшие методики от вторжения, и что делать, когда случилось самое неприятное.

BSD с помощью уровней 46 Укрепляем безопасности Michael Shirk

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

Поговорим от FreeBSD Foundation 50 Новости Dru Lavigne

Организация FreeBSD Foundation — это некоммерческая фирма, работающая на основании положения 501(c)(3) закона о доходах США. Её целью является поддержка проекта FreeBSD, а также построение сообщества по всему миру. Она ответственна за исполнение контрактов, лицензионных соглашений, авторских прав и других законных мер, для которых требуется наличие юридического лица.

ЧТО НОВОГО

Участие FreeBSD в программе Google Code-In Впервые проект FreeBSD вовлечен в программу, организованную Google Inc. для привлечения студентов к участию в open-source проектах — Google Code-In (аббревиатура GCIN). Вы узнаете… • что такое программа Google Code-In • какие плюсы получают открытые проекты в качестве организаций-менторов • о текущем статусе задач для проекта FreeBSD

удучи похожей на другую программу от Google — Google Summer of Code или просто GSoC — и в которой FreeBSD уже участвует на протяжении нескольких лет, в этой новой программе есть некоторые нюансы. В этой статье попытаемся объяснить различия с точки зрения участвующей организации и как выглядит рабочий процесс на сегодняшнее время.

Что из себя представляет программа Google Code-In

Программа Google Code-In предназначена для школьников в возрасте 13-17 лет, которые хотят обрести свой первый опыт в области open-source проектов. Программа была официально открыта для участников 21 ноября 2011 года и продолжится до 16 января 2012. Несмотря на то, что название программы намекает на написание программного кода, задачи, над которыми студенты будут работать, не ограчены только лишь программированием. Такие вещи, как написание документации, проведение тестов и исследований, обучение, перевод, работы в области пользовательских интерфейсов и даже операции по популяризации проектов — это те направления, от которых серьезно зависит любая open-source разработка. Каждый проект создает серию подзадач в каждой категории (если такое

О чем вы должны знать… • схожие проекты от Google, такие как Google Summer of Code

возможно), и общим числом не менее 40 подзадач, над которыми будут трудиться студенты. Количество задач будет увеличено позже, по мере их выполнения. У каждой задачи обычно есть название и цель ее выполнения (например, документ был переведен или же исправлена ошибка в коде), которая в конце фиксируется. За каждую выполненную задачу участники награждаются баллами — один балл за простую, два балла за средний уровень и четыре за наибольшую сложность. Участвующие организации принимают решения о назначении каждой задачи, и также ответственны за выделение по крайней мере одного куратора на задачу — чтобы помочь в решении какой-либо проблемы или же просто ответить на вопрос — как начать. Кураторы также принимают решения о законченности задачи, и сколько баллов набрано студентом. После завершения соревнования десять участников с наибольшим количеством баллов получают возможность съездить вместе с родителем или легальным представителем в штаб-квартиру Google в Калифорнии — город Mountain View. В отличие от программы Google Summer of Code, в рамках этого проекта финансовые выплаты не предусмотрены. Однако, есть другие способы поощрения, которые будут несомненно приятны для стороны, курирующей то или иное направление.

12/2011

Участие FreeBSD в программе Google Code-In

Почему участие в проекте Google Code-In важно для FreeBSD

Для FreeBSD существует ряд причин, почему так важно участие в программе. Во-первых, мы получаем ценный опыт от самой программы (все-таки, это первый такой случай). Программа Google CodeIn отличается от Google Summer of Code тем, что прилагается большее количество усилий со стороны кураторов для помощи юным участникам. Количество времени на назначение и выполнение задания также меньше, что определенно требует большей гибкости с нашей стороны. Мы также не знаем, насколько сами участники в курсе механизма взаимодействия с другими людьми в рамках open-source проекта. Компания Google, в частности, предупредила потенциальных кураторов, что студенты могут прибегать к излишнему использованию заглавных букв и прочему текстовому оформлению при обмене информацией, что считается не совсем правильным в интернете. К счастью, такое пока не замечено у тех, кто подписался на проекты FreeBSD. Даже наоборот, те студенты, с которыми мы вышли на контакт, не слишком-то и отличаются в стиле своего письма от постоянных членов нашего сообщества, что присутствуют на форумах FreeBSD, списках рассылок или на IRC-каналах. Конечно, успешно завершить все те задачи, что записаны в список дел — один из главных наших приоритетов от нашего участвия в качестве организации-ментора. Но кроме этого, нам было крайне интересно узнать, насколько плотно студенты знакомы с операционной системой. Другая важная цель от нашего участия в программе — это надежда, что студенты продолжат быть в нашей экосистеме и после окончания Google Code-In. Даже если они и не станут активными членами сообщества, то по крайней мере будут поддерживать связи с ним, и мы надеемся, будут рассказывать о том великолепном опыте, который они прибрели во время проведения программы. И последний, но тем не менее, важный акцент — то множество тем, что предлагается студентам, помимо чисто написания программного кода (которое, надо отметить, является стоящим занятием), привлекает к проектам разного рода людей. Которые в любом другом случае, никак бы себя не проявили. Представьте себе молодого человека, обладающего художественными навыками. Иллюстрируя некоторые черты операционной системы, либо же создавая инфографику для раскручивания проекта — это те детали, что создают неимоверное впечатление и вовлечение других людей, последние, впоследствии, начинают лучше представлять себе, о

www.bsdmag.org

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

Подготовительные мероприятия для организации-куратора

Предварительная работа по регистрации FreeBSD в качестве организации-ментора, создание wiki-страниц для разных задач и поиск кураторов была проведена Wojciech A. Koszek. Вот как я впервые услышал об этом конкурсе. Чтобы быть зарегистрированной в качестве ментора, организация должна подготовить сорок заданий для студентов на время проведения конкурса Google Code-In. Будучи заинтересованным в создании и обновлении документации к FreeBSD, я начал просматривать тот предварительный список заданий, что мы разместили на wiki-разделе. Придумывание заданий заняло немного больше времени, чем подразумевалось ранее. Нужно было подготавливать дополнительные разъяснения, т.к. за пределами проекта FreeBSD зачастую не знакомы с тем инструментарием, что мы используем (или даже незнакомы с самой операционной системой) и могут натолкнуться на непреодолимые препятствия даже с самыми простыми заданиями. Так простое задание по документированию вылилось в огромную работу из-за необходимости детального описания задачи. Но в конце концов, задание стало содержать всю необходимую информацию. Да, описание задания может быть изменено и это оказалось очень удачным для нас. Особенно, когда выясняется сколько именно времени требуется студенту для фактического выполнения — как правило, времени требуется больше, нежели обычному коммитеру. После заполнения всех сорока задач (не только одним мною) и после того, как многие опытные коммитеры

Глоссарий

GCIN — аббревиатура для конкурса Google Code-In, организованного компанией Google для активизации разработки open-source проектов GSoC — аббревиатура для конкурса Google Summer of Code, также организованного компанией Google, для развития open-source проектов, но выплачивая денежное вознаграждение за лето, проведенное за программированием

ЧТО НОВОГО

В сети • •

http://www.google-melange.com/gci/homepage/google/gci2011 http://wiki.freebsd.org/GoogleCodeIn/2011

согласились на участие в программе в качестве кураторов, мы решили, что необходимо расширить источники получения информации о нашем участии в проекте. Поэтому мы открыли канал #freebsd-soc, который обычно используется при проведении Google Summer of Code, и зарегистрировали также несколько ящиков электронной почты для связи студентов с кураторами. Мы даже создали образ в формате VirtualBox с установленной операционной системой и каталогами документации, так что студенты смогли приступить к выполнению заданий сразу, а не тратя время на установку и конфигурирование системы.

Чему мы сами научились

Пока соревнование всё еще проходит, несколько моментов мы уже можем отметить и они могут помочь нам в следующий раз. Опасения, что студенты требуют повышенного к себе внимания или же не знают правильных основ оформления электронной почты, либо же не знают сетевого этикета при общении в IRC, оказались беспочвенными. Студенты не оказались робкими, чтобы расспросить о неясных для них аспектах задач или же о тех вещах, которые для них вновинку. Те, кто отработали и завершили одно задание, с большой вероятностью возьмут похожее из того же под-проекта. Например, если кто-то знает, как составлять документ в формате DocBook SGML (формат используется во FreeBSD), очень вероятно, что следующее задание будет связано с ним же. Большинство студентов никогда раньше не сталкивалось с операционной системой FreeBSD, да и любой другой UNIX-системой, до настоящего момента. Только небольшая часть, что ранее имела какое-либо отношение к проекту FreeBSD, смогла начать сразу же над более или менее простыми заданиями. Назначить достаточное количество времени также важно, т.к. на вопросы и ответы уходит ценное время. Когда мы видели, что студенту интересно завершить задание, то мы с удовольствием увеличивали при необходимости отведенное время. Было очень отрадно видеть, как кураторам помогали многие члены своего сообщества. Это означало не только то, что эти задания имели какието отношения к их текущим разработкам, а сколько их желание и время помочь новичкам в мире FreeBSD. Надеюсь, что налаженный ритм выполнения заданий

будет соблюден (на момент написания этой статьи — 11 из 72), и сами участники будут воспринимать свои задания не как цель соревнования, но как очень ценную помощь в развитии проекта FreeBSD и его пользовательской базы.

Выводы

Участие в конкурсе Google Code-In в качестве организации-куратора было (и есть) ценным опытом, несмотря на характер работы, связанной с ней. Те плюсы, которые проявляются во многих областях, и которые обычно не удостаиваются заслуженного внимания, достаточны отрадны. Я желаю всем участвующим студентам удачи в завершении их заданий, и надеюсь увидеть после завершения конкурса во многих наших проектах на правах полноправных членов. Если у вас есть интересная идея задания для конкурса, можете смело разместить её на наших wiki-страницах, либо же свяжитесь с одним из кураторов.

Об авторе

Benedict Reuschling использует FreeBSD начиная с версии 5.2.1-RELEASE. Он тихо почитывал списки рассылок FreeBSD пока не присоединился в 2008 году, после прочтения одного сообщения, к немецкой команде по документированию FreeBSD. После получения права доступа на изменение документации, он был вовлечен и в другие аспекты вокруг проекта. Будучи студентом, он поработал в ряде частных компаний. Сейчас же наслаждается процессом обучения студентов на кафедре информационных технологий, где когда-то сам учился. Также практикует стиль Tai Chi Yang для отключения своего внутреннего процессора в свободное время.

12/2011

УГОЛОК РАЗРАБОТЧИКА

Устанавливаем PC-BSD на Мак Начиная с версии PC-BSD 9.0-RC1 стала возможной простая инсталляция системы на Макинтош или же на BootCamp-раздел MacBook. В этой статье мы бегло рассмотрим как можно настроить Мак для двойной загрузки и произведем непосредственно саму установку.

режде, чем начать процесс конфигурирования вашего Мака для двойной загрузки, вы должны убедиться, что ваш Мак работает на базе процессоров Intel, и установлена система OS X 10.5 («Леопард») или же выше. После этого необходимо будет щелкнуть на поле поиска в верхнем правом углу и набрать слово «boot». Найдите программу «Boot Camp Assistant» и запустите её (она также может быть найдена через Applications → Utilities → Boot Camp Assistant). После старта программы, нажмите на кнопку

После того, как работа по первоначальному созданию раздела закончена, нажмите на кнопку «Quit & Install Later» и вы выйдете из программы. Раздел создали. Теперь следующим шагом будет перезагрузка и загрузка с привода DVD/CD и установленного в него диска с PC-BSD. Нажмите и держите кнопку «C», чтобы загрузиться с компактдиска. Если инсталлятор PC-BSD запустился, то можете выбрать нормальную, обычную установку. Следует обратить внимание, что затем нужно будет правильно выбрать раздел BootCamp для непосредственной

Рис.1 - Запускаем BootCamp из OSX продолжить и выберите пункт «Create or remove a windows partition» После этого необходимо будет выделить дисковое пространство под ваш создаваемый PC-BSD раздел. Переместите точку разделителя для задания нужного вам размера. После этого нажмите на кнопку «Partition».

www.bsdmag.org

установки системы. На Маке с единственным диском и BootCamp-разделом, последний будет виден как «ada0p3 – linux-data». Если же вы сомневаетесь, то убедитесь, что размер выбираемого раздела совпадает с тем, что вы только что создали в программе BootCamp. Раздел выбран — можете нажать на кнопку «Next», чтобы начать установку

УСТАНАВЛИВАЕМ PC-BSD НА МАК

Рис. 2 - Создадим новый BootCamp-раздел PC-BSD. Также выбирайте нужные опции и следите за процессом установки системы PC-BSD. После завершения не забудьте нажать на кнопку «Finish», чтобы перезагрузиться. Прежде, чем появится

Может так получиться, что «Startup Manager» не видит BSD-раздел, либо вы не помните, что каждый раз при старте нужно держать клавишу «Option». Тогда стоит поставить такой загрузчик как rEFIt. Его можно свободно загрузить с сайта sourcefourge и установить взамен используемого по умолчанию. В итоге, у вас при загрузке будут показываться иконки от нескольких операционных систем — всё, что вам остается сделать — это нажать на нужную. Выберите том «BSD» и загрузите рабочий стол PC-BSD. Если впоследствии вы решите удалить раздел BootCamp с установленной PC-BSD, и вернуть диск в первоначальное состоятие, то для этого следует предпринять несколько шагов. Во-первых, запустить программу «Disk Utility» как Applications → Accessories → Disk Utility. Выбрать раздел PC-BSD / BootCamp и нажать на стирание — «Erase». В этом же экране в опции «Format» выберите значение «MS-DOS (FAT)» и нажмите на Erase. Перезапустите заново программу Boot Camp Assistant. В ней вы должны будете выполнить процесс

Рис. 3 - Задаем размер для раздела логотип с яблоком, удерживайте на клавиатуре кнопку «Option». Так вы вызовете встроенный маковский «Startup Manager». В нем вы можете выбрать ваш BSD-раздел и запустить новую систему.

удаления раздела и восстановления оригинального размера для тома OS X.

В сети • •

PC-BSD Installation Guide: http://wiki.pcbsd.org/index.php/Installing_PC-BSD rEFIt Homepage: http://refit.sourceforge.net

12/2011

Рис. 4 - Экран завершения программы BootCamp

Рис. 5 - Удаляем BootCamp-раздел

Об авторе

Kris Moore - создатель и ведущий разработчик проекта PC-BSD. Он живет с женой и своими четырьмя детьми в East Tennessee (США), и наслаждается созданием индивидуальных операционных систем, а также играми в свое (ограниченное) свободное время.

www.bsdmag.org

УГОЛОК РАЗРАБОТЧИКА

OpenBSD — храним вашу конфигурацию как новенькую с помощью sysmerge (8) «Я только что обновился до новой версии ... что теперь?» Вы узнаете… • об истории sysmerge (8) и внутренней кухне • о практике использования sysmerge

отличие от большинства Linux-дистрибутивов, и немного напоминая другие BSD системы, OpenBSD не построена на основе коллекции портов. Наоборот, она поставляется как нечто целое, предоставляя целую Операционную Систему путем распаковки из серии tgz-архивов. Такой вариант является очень простым в плане обновления (в большинстве случаев, это просто распаковка из нужных сетов). Однако, такое обновление хорошо работает для бинарных файлов, библиотек и man-страниц ... но не для конфигурационных компонентов (например, сетов etcXX.tgz и xetcXX.tgz), т.к. вполне очевидно, что распаковка архивов с новыми конфигурациями просто затрет рабочие текущие. В прошлом, обновление конфигурационных файлов требовало запускать программу «patch» (с нужной информацией, размещенной на странице upgradeXX.html сайта OpenBSD) и которая обновила бы некоторые файлы, к которым администратор вообще редко прикасается, либо же он должен быть вручную произвести требуемые изменения между старой и новой версией ... что мягко говоря, несколько утомительно. Инструмента, который облегчил бы администратору его работу при обновлении конфигурационных файлов, и сделал бы сам процесс легким и быстрым,

О чем вы должны знать… • механизм обновления в OpenBSD • работа с командным интерпретатором bash

до определенного момента не существовало. По этой причине утилита sysmerge и была создана. Обратите внимание, что sysmerge работает только с базовой системой, и не прикасается к сторонним файлам, таким как размещенным в портах (ports) и пакетах (packages).

В прошлом

Когда sysmerge был впервые представлен, несколько людей уже использовало пакет mergemaster (портированный из FreeBSD) в качестве инструмента для обновления файлов в каталогах /etc и /var (некоторые конфигурационные файлы для chroot сервисов, таких как named или httpd, хранятся в /var). Эта утилита работала замечательно, за исключанием нескольких замечаний: она предназначалась для FreeBSD (это понятно), имела целую кучу опций, была на самом деле очень большим скриптом и не была частью базовой системы. Поэтому было решено, что вместо использования mergemaster, лучше написать этому инструменту замену, которая бы работала аналогичным образом, но удовлетворяла бы нашим требованиям и желаниям. Утилита sysmerge была изначально добавлена в релиз версии 4.4 (около 3,5 лет назад). И в то время представляла собой сильно упрощенную версию

12/2011

OpenBSD - храним конфигурацию как новенькую с помощью sysmerge

mergemaster, способную только запускать diff над файлами, и показывать интерфейс взаимодействия пользователя sdiff, если файлы различались. Сегодня, мы всё еще используем некоторые важные части от mergemaster, такие как механизмы сравнения diff и compare. А также задействовали некоторые идеи от таких утилит из NetBSD как etcupdate, или etc-update из Gentoo.

Настоящее

На момент написания этой статьи, sysmerge занимает ровно 714 строк (mergemaster была примерно в 2 раза больше). Обе утилиты используют примерно одни и те же функции, однако mergemaster допускает, что многие из них опциональны. Мы же, в то время, предпочитаем, чтобы sysmerge был насколько можно более простым, без этого безумного количества параметров. Программа sysmerge производит всю свою работу в каталоге WKRDIR, который по умолчанию указывает на /var/tmp/sysmerge.XXXXXXXXXX. Все новые файлы устанавливаются сначала в TMPDIR/temproot, а архивные копии рабочих файлов помещаются в TMPDIR/temproot. Системные сообщения можно прочитать в лог-файле WRKDIR/ sysmerge.log. Все параметры к утилите можно найти в ее документации, поэтому поговорим только о самых распространных вариантах ее использования. Есть три способа запуска sysmerge: вообще без параметров (режим по умолчанию), в режиме пакетной обработки (-b), или же в полноценном режиме замены (-d). Хотя пакетная обработка (batch) может быть скомбинирована с режимом полной замены (diff), как мы в дальнейшем убедимся, такой вариант не имеет большого смысла. Сравнение производится между текущими, рабочими

файлами, которые установлены в системе, и теми, что мы называем референсными (находящимся в сетах (x)etcXX, или же в директории с исходными текстами OpenBSD от нового релиза). Итак, каждый из режимов будет запущен при наличии референсных файлов. Ключ -s используется для указания пути к файлу etcXX.tgz, либо же к дереву исходных текстов OpenBSD (обычно размещается в /usr/src). Ключ -x используется для указания пути к файлу xetcXX.tgz. Эти ключи необязательны: sysmerge по умолчанию будет использовать /usr/src (т.е. запустится как `sysmerge /usr/src`). Далее запускаются проверки на целостность, чтобы убедиться, что владельцы и разрешения файлов на рабочие и/или обновленные файлы и ссылки совпадают с референсными. В конце процедуры запускается утилита mtree — для проверки, что нет пропавших директорий и что на них выставлены нужные права. Обратите внимание, что из-за специфики следующих файлов, они всегде будут исключены из процесса сравнения: • • • • • •

/etc/*.db — файлы баз данных passwd и login. conf создаются соответствующими утилитами /etc/mail/*.db — файл БД sendmail создается из плоского текстового файла с помощью makemap /etc/passwd — генерируется с помощью pwd_ mkdb из файла master.passwd /etc/motd – трогать этот файл нет смысла /etc/myname – FQDN-имя машины, переписывать не надо /var/db/locate.database — файл БД для locate,

Листинг 1. Сравнение использования sysmerge и mergemaster Usage: mergemaster [-scrvhpCP] [-a|[-iFU]] [--run-updates=always|never] [-m /path] [-t /path] [-d] [-u N] [-w N] [-A arch] [-D /path] usage: sysmerge [-bd] [-s [src | etcXX.tgz]] [-x xetcXX.tgz]

www.bsdmag.org

УГОЛОК РАЗРАБОТЧИКА

• • •

генерируется с помощью locate.updatedb /var/db/sysmerge/{etc,src,xetc}sum – контрольные суммы, создаваемые sysmerge /var/games/tetris.scores — переписывать рекорды не нужно ;-) /var/mail/root — письмо для root об окончании процесса установки

•

без дополнительных вопросов, если следующие критерии соблюдены: a) различаются только CVS Id; b) текущий файл отличается от нового, но на самом деле один и тот же [*]; c) файл бинарный Отсутствующие пользователи и/или группы будут добавлены в систему.

Некоторые файлы и/или директории могут быть добавлены в «игнорируемый» список. Добавляя строку в файл /etc/sysmerge.ignore мы тем самым говорим sysmerge пропустить его из процесса сравнения. Может быть удобно при некоторых установках. Хороший кандидат на пример — файл /etc/pf.conf.

[*] это может быть сделано с помощью контрольной суммы; текущие файлы хранят свои в файлах /var/db/sysmerge/{etc,src,xetc}sum, а новые референсные файлы хранят в рабочей директории WRKDIR; в оригинале идея была заимствована из mergemaster.

Когда следующие файлы установлены и/или обновлены sysmerge, то вызывается их управляющая утилита, чтобы значения в плоских файлах и в этих базах совпадали:

Если решение невозможно принять автоматически, то sysmerge предложит администратору интерфейс sdiff, где можно будет произвести замену вручную (sdiff также может быть пропущен, чтобы позволить человеку лично «слепить» нужные файлы позднее — это верно для всех режимов работы).

• • • • •

/dev/MAKEDEV — MAKEDEV(8) /etc/login.conf — cap_mkdb (только если /etc/ login.conf.db уже существует) /etc/mail/access, genericstable, mailertable, virtusertable — makemap(8) /etc/mail/aliases — newaliases /etc/master.passwd — pwd_mkdb

Запускаем в режиме по-умолчанию

Это тот режим, в котором большинство людей обычно и запускает программу. В нем sysmerge проводит массу работ, чтобы произвести обновление без лишнего дергания администратора. • •

• •

Файлы, с одинаковым CVS Id будут пропущены при сравнении (т.е. добавлены в «игнорируемый» список). Будет произведена специальная проверка конфигурационных файлов sendmail, потому что в них содержится дата и директория сборки. А это означает, что они всегда будут отличаться от текущих, установленных в данной системе. Поэтому sysmerge включит их тоже в список пропуска, пока не доказано, что они реально и по существу отличаются. Пропавшие файлы и ссылки будут автоматически восстановлены. Существующие файлы, что отличаются от новых референсных, будут автоматически обновлены

Запускаем в пакетном режиме

В этом режиме sysmerge будет вести себя также, как и в стандартном, однако интерактивное взаимодействие (т.е. sdiff) будет отключено. Администратор сможет произвести необходимые изменения в файлах позже, а найти их в директории TEMPROOT. Такой режим, в частности, удобен, когда нужно произвести массовые обновления на множестве машин в автоматическом режиме.

Запускаем в режиме полноценной замены

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

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

Подразумевается, что sysmerge будут запускать после каждого обновления системы; от релиза X.Y до релиза X.Z или от одного снэпшота системы до другого. Очень важно предоставить утилите соответствующий набор обновлений, в зависимости

12/2011)

OpenBSD - храним конфигурацию как новенькую с помощью sysmerge

от метода обновления: обновление было сделано за счет компиляции из исходных текстов → запустите sysmerge с параметром /usr/src обновление было осуществлено с использованием сетов (bsd.rd) → запускайте sysmerge с параметрами, затрагивающими наборы (x)etcXX Другими словами, после обновления вашей системы от версии OpenBSD 4.9 до 5.0, вы должны перезагрузить машину, получить пакеты (x)etc50.tgz с любого зеркала и затем:

Листинг 2. Типичный вывод от команды sysmerge # sysmerge -s etc50.tgz -x xetc50.tgz ===> Populating temporary root under /var/tmp/sysmerge. PLMRVMNTiT/temproot ===> Starting comparison ===> Updating /etc/changelist ===> Updating /etc/login.conf ===> Updating /etc/moduli ===> Updating /etc/netstart ===> Updating /etc/protocols ===> Updating /etc/rc ===> Updating /etc/rc.conf ===> Updating /etc/rc.d/amd ===> Updating /etc/rc.d/ftpd ===> Updating /etc/rc.d/identd ===> Updating /etc/rc.d/ldapd ===> Updating /etc/rc.d/mopd ===> Updating /etc/rc.d/ntpd ===> Updating /etc/rc.d/rarpd ===> Updating /etc/rc.d/rc.subr ===> Updating /etc/rc.d/smtpd ===> Updating /etc/rc.d/ypbind ===> Updating /etc/rc.d/ypldap ===> Updating /etc/rc.d/ypserv ===> Updating /etc/services ===> Updating /etc/ypldap.conf ===> Updating /etc/X11/app-defaults/XTerm ===> Updating /etc/X11/xdm/Xaccess ===> Updating /etc/X11/xdm/Xresources ===> Updating /etc/X11/xdm/Xsession ===> Updating /etc/X11/xdm/Xstartup ===> Updating /etc/X11/xdm/xdm-config ===> Comparison complete ===> Checking directory hierarchy permissions (running mtree(8)) ===> Output log available at /var/tmp/sysmerge.PLMRVMNTiT/sysmerge.log *** WARNING: some new/updated file(s) may require a reboot

www.bsdmag.org

$ sudo sysmerge -s /path/to/etc50.tgz -x /path/to/xetc50.tgz

Конечно, нужно будет произвести работу только над xetc50.tgz, если X пакеты уже установлены на машине. Над этими референсными пакетами sysmerge может работать и по сети. $ sudo sysmerge -s http://ftp.fr.openbsd.org/pub/OpenBSD/5.0/ i386/etc50.tgz

Пример обновления

Теперь давайте посмотрим на типичный пример обновления из реального мира, где мы запустим sysmerge после того, как обновили машину с релиза 5.0 до 5.0-current. Мы также будем работать с наборами etc50.tgz и xetc50.tgz, загруженными из директории snapshots с одного из зеркал OpenBSD. Достаточно просто, т.к. никакого ручного слияния не потребовалось :-) Иногда, как в этом примере, sysmerge будет вас предупреждать о том, что требуется перезагрузка. Это может произойти из-за того, что /dev/MAKEDEV и/или /etc/login.conf были обновлены. Причина — после запуска MAKEDEV сбрасываются некоторые разрешения на некоторые TTY, которые могут привести к странному поведению работающей системы. Когда же модифицируется login.conf, то бывает проще перезапустить машину, чтобы лишний раз убедиться, что все процессы получили свои новые лимиты. Теперь же давайте обратим внимание на логфайл (достаточно удобно иметь его под рукой, когда sysmerge находится в пакетном режиме и когда консольный вывод по какой-то причине не доступен). Вот кусочек примерного лог-файла, в котором записываются какие действия были сделаны утилитой sysmerge. Он также содержит название директории, где находятся резервные копии файлов. Не исключена ситуация, когда по ошибке переписали нужный файл — вы найдете его рабочий оригинал именно здесь. С этого момента, процедура обновления завершена и вы теперь обладатель совершенно новой и с сияющей конфигурацией системой.

УГОЛОК РАЗРАБОТЧИКА

На будущее

Несмотря на то, что sysmerge полностью функциональна, ее развитие не остановлено. Есть в проекте некоторые улучшения, которые позволят еще немного снизить уровень интерактивности. Одно из таких направлений — это возможность задействаования 3-х уровневого измения файлов, используя старые конфигурации, новые и установленные текущие. Это позволило бы произвести автоматические обновления над локально измененными файлами. Но поднимает новые вопросы, т.к. мы хотим быть уверенными, что ни локальные изменения, ни текущее поведение соответствующих приложений от этого не изменится. На текущий момент рабочего кода нет, а есть только мысли и голая концепция. Другой идеей, которая была сначала частично реализована, а потом заблокирована, это интеграция

sysmerge напрямую с установщиком OpenBSD. Это позволило бы администратору изменить конфигурационные файлы сразу же после обновления, без ухода на лишнюю перезагрузку. Такое улучшение было успешно протестировано, но в конце концов от него пришлось отказаться, т.к. на некоторых архитектурах были ошибки с отображением информации через последовательный порт. Надеюсь, эти ошибки будут вскоре проработаны и такая возможность с инсталлятором будет возвращена снова в строй. В общем и целом, я очень ряд текущим состоянием дел с sysmerge — этим маленьким, однако очень удобным инструментом. Поэтому рассчитываю, что старые аксакалы, что привыкли использовать свои собственные скрипты по обновлению, в перспективе перейдут на работу именно с ним.

Листинг 3. Содержимое лог-файла от команды sysmerge ===> Automatically installed file(s) /etc/changelist /etc/login.conf /etc/moduli /etc/netstart /etc/protocols /etc/rc /etc/rc.conf /etc/rc.d/amd /etc/rc.d/ftpd /etc/rc.d/identd /etc/rc.d/ldapd /etc/rc.d/mopd /etc/rc.d/ntpd /etc/rc.d/rarpd /etc/rc.d/rc.subr /etc/rc.d/smtpd /etc/rc.d/ypbind /etc/rc.d/ypldap /etc/rc.d/ypserv /etc/services /etc/ypldap.conf /etc/X11/app-defaults/XTerm /etc/X11/xdm/Xaccess /etc/X11/xdm/Xresources /etc/X11/xdm/Xsession /etc/X11/xdm/Xstartup /etc/X11/xdm/xdm-config ===> Backup of replaced file(s) can be found under /var/tmp/sysmerge.PLMRVMNTiT/backups

Об авторе

Antoine Jacoutot является разработчиком OpenBSD и живет в Париже, Франция. На его счету находится разработка более 300 пакетов, он также написал утилиту sysmerge, а еще был частью команды, написавшей подсистему OpenBSD rc.d. Сегодня он разработчик GNOME и также член GNOME Foundation. Использует OpenBSD практически для всех своих дел.

12/2011

<<TOP>>

www.bsdmag.org

HOW-TO

Подготавливаем свое собственное ядро FreeBSD У компиляции собственного ядра операционной системы имеется ряд преимуществ и недостатков. Однако, новые пользователи могут столкнуться с таким вопросом — а как именно его собирать? Вы узнаете… О чем вы должны знать… • Зачем приходится собирать собственное ядро • Базовые принципы работы операционной • Как собирать ядро FreeBSD системы FreeBSD • Как создавать конфигурационный файл в формате BSD • Как производить настройку ядра FreeBSD • Как добавить модуль ядра • Краткие заметки по поводу загружаемых модулей FreeBSD

ля ответа на этот вопрос вы должны помнить — сборка подразумевает не только ввод пары команд. В этой статье я объясню все нюансы, которые обычно возникают при сборке ядра FreeBSD.

Зачем конфигурировать ядро?

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

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

12/2011

Подготавливаем свое собственное ядро FreeBSD

драйверов). Код драйвера не может быть обособленно разработан и склеен с ядром как пластилин — он должен быть интегрирован со структурой данных ядра и системных таблиц. На некоторых системах такая процедура может потребовать определенных работ по ревизии текущей версии ядра, т.е. изменения конфигурационного файла для ядра и дальнейшая пересборка последнего с нуля. На других же системах может быть достаточным только запуск программы сборки самого модуля.

Файлы, необходимые для построения BSD-ядра, хранятся в директории /usr/src/sys, которая обычно представлавляет из себя символическую ссылку на директорию /sys. Далее по тексту, я буду использовать имя SYS в качестве обозначения этой директории и чтобы подчеркнуть то факт, что неважно, где именно она находится. Если вы не можете найти директорию для компиляции для вашей машины, то обратитесь к справке на сайте дистрибутива операционной системы.

В системе может быть заложена возможность концепции подгружаемого модуля устройства, т.е. такая организация кода, когда модуль подгружается в системное пространство ядра во время его работы. Аналог из человеческой области может выглядеть так — вы производите операцию на мозге оператора, когда последний, не прерывая своей деятельности, управляет каким-либо сложным станком.

Вот список файлов, выдаваемых по команде ls -F для директории SYS на FreeBSD-машине: Директория i386 содержит модули, специфичные для этой архитектуры.

Сама сборка ядра не сложна — трудности могут возникнуть, когда вы внесете некорректные параметры.

Собираем ядро FreeBSD

Хотя примеры, которые приводятся в этой статье относятся больше к FreeBSD, аналогичный процесс конфигурирования ядра NetBSD также похож. Проект же OpenBSD разместил свою аргументацию за и против пересборки ядра. Вместо приведения их здесь, я приведу адрес сайта OpenBSD — http://www.openbsd.org/faq/faq5.html#Why У BSD-ядер есть имя, которое будет использоваться во время процесса конфигурирования. В качестве имени может выступать любое слово или словосочение, но следует иметь ввиду, что имя должно носить осмысленный характер, говорящей о системе или системах, на которых данное ядро будет работать. Если предполагается использовать на какой-либо одной машине, то в качестве имени ядра удобно будет взять название хоста. Чтобы построить ядро FreeBSD, вам, в первую очередь, нужно создать конфигурационный файл, в котором должны быть перечислены параметры нового ядра. Затем нужно будет запустить команду config, чтобы создать директорию для создаваемых объектов и модулей ядра. Название директории будет таким же, что и у названия конфигурационного файла, и там же будет храниться сам созданный файл ядра.

www.bsdmag.org

Другой важный каталог в структуре директории SYS — это SYS/arch/conf, где хранятся конфигурационные файлы ядер; каждый файл предназначен для своего конкретного ядра. В этой статье я буду подразумевать, что вы используете архитектуру Intel 386, хотя FreeBSD поддерживает и ряд других, таких как amd64, ia64, powerpc, sparc64. Команда config будет зачитывать содержимое конфигурационного файла из каталога SYS/arch/conf и создаст соответствующую директорию SYS/compile/KERNEL_NAME. Например, для только что установленной системы, будет использоваться базовое ядро под названием GENERIC. Для него же файл конфигурации будет называться SYS/i386/conf/GENERIC, а сам каталог сборки ядра, соответственно SYS/compile/GENERIC. Остальные подкаталоги в SYS содержат различные

Листинг 1. Содержимое директории SYS # ls -F

Makefile ddb/ amd64/ dev/ arm/

fs/

libkern/ netnatm/ rpc/

mips/

netncp/

security/

modules/ netsmb/ sparc64/

boot/

gdb/

net/

cam/

gnu/

netatalk/ nfsserver/

bsm/

geom/

nfs/

sun4v/

net80211/ nfsclient/

sys/

tools/

cddl/

i386/

netgraph/ nlm/

ufs/

conf/

isa/

netinet6/ pc98/

x86/

compat/ ia64/ contrib/ kern/ crypto/

netinet/ opencrypto/ vm/ netipsec/ pci/

kgssapi/ netipx/ xen/

xdr/

powerpc/

HOW-TO

сетевых карт, которые, в свою очередь, продаются под десятком разных наименований. Очень часто, единственным способом выяснения деталей является личное открывание корпуса и визуальный осмотр изделия. Если вы знаете название драйвера устройства, то вы можете заглянуть в справку, т.е. в man-страницы. К сожалению, во FreeBSD содержится очень мало информации, какие точно устройства поддерживаются данным драйвером.

Листинг 2. Директория i386 # ls -F i386

Makefile compile/ ibcs2/

linux/

bios/

svr4/

acpica/

conf/

i386/

xbox/

include/ pci/

isa/

xen/

части ядра, из которых впоследствии будет собран единый бинарный файл. Конкретные названия файлов и директорий разнятся от одной BSD-системы к другой.

Рецепты от шефа при подготовке ядра

Следующий список отражает восемь необходимых шагов для создания ядра. Мы далее рассмотрим все из них в соответствующих разделах этой статьи. • • • • • • • •

Аудит системного оборудования Создание и редактирование файла конфигурации в SYS/i386/conf Запуск программы config из директории conf Запуск make depend в каталоге компиляции ядра Сборка ядра командой make Резервное копирование старого ядра и установка нового Тестирование и отладка нового ядра Документирование изменений

Аудит системного оборудования

Прежде, чем вы начнете проводить работы по конфигурированию, вам нужно выяснить, а для каких устройств нужны поддержка и драйверы? Начните с перечисления устройств, из которых составлена машина — составьте список, включая: • • • •

Жесткие диски, CD/DVD-устройства контроллеры Сетевые карты Специализированное оборудование Клавиатура и мышь

их

Аудит системы может быть достаточно изматывающей задачей в мире персональных компьютеров. Зачастую, производители техники просто выдают вам товар и не говорят точно, что же находится внутри — например, такое описание как «сетевая карта» не достаточно. Существует сотня

Также помните, что стандартное ядро системы системы тоже пишет об оборудовании при старте. Его вывод может быть отличной подмогой при составлении списка необходимых драйверов, которые следует включить в образ ядра. Просмотреть эти сообщения ядра можно с помощью команды dmesg. Для дополнительной справки воспользуйтесь также файлом SYS/i386/conf/LINT.

Создаем файл конфигурации в SYS/i386/conf

Раз вы уже знаете, для какого оборудования стоит включать поддержку, то стоит подготовить этот список в формате, который понимает команда config. Для этого вам нужно будет создать конфигурационный файл в директории SYS/i386/conf. Имя файла может быть любым, но с достаточно понятным названием. Так, чтобы даже кто-либо сторонний смог бы ответить для чего каждое ядро предназначено. Не создавайте файл с нуля. Вместо этого рекомендуется брать конфигурацию для GENERIC и удалять ненужные части. В случае, если вы застряли над каким-то параметром и не можете определить его назначение исходя из этой статьи, то обратитесь к документации команды config. Справочные manстраницы также могут быть хорошим источником информации и обычно приводят параметры ядра. Как раз то, что именно вам и нужно. Например, справка для драйвера de(4) начинается с параметра SYNOPSIS

device de

Это именно та строка, которую вам нужно вставить в конфигурационный файл, чтобы этот модуль был скомпилирован (конечно, такой метод достаточно оригинален, т.к. вам нужно заранее знать название драйвера, прежде чем вы получите по нему справку; в любом случае вы можете вызвать справку и как man -k).

12/2011

Подготавливаем свое собственное ядро FreeBSD

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

Запускаем команду config

Вы должны перейти в каталог SYS/i386/conf перед запуском команды config, т.к. она ожидает найти конфигурационный файл в текущей директории. Самые простые варианты этой команды в качестве единственного аргумента берут название конфигурационного файла. Более модные поддерживают целый ряд дополнительных опций. Чтобы создать компиляционный каталог для ядра, описанного файлом SYS/i386/conf/EXAMPLE, мы должны действовать следующим образом:

# cd SYS/i386/conf # config EXAMPLE

Если команда config выдает ошибки, то вы должны вернуться и отредактировать конфигурацию. В противном случае, если об ошибках сообщено не было, то можете считать, что по крайней мере конфигурация синтаксически составлена правильно и можно переходить к следующему шагу.

Запускаем команду make depend

После того, как config отработала, вам необходимо будет зайти в директорию компиляции нового ядра (cd ../../compile/EXAMPLE) и запустить команду ls. Вы увидите множество и множество файлов. Не беспокойтесь об их содержимом — команда config знает, что именно создавать. Теперь запускайте команду make depend из этой директории. Она проинициализирует файловые зависимости, которые затем потребуются команде make. Не пугайтесь, что на экран будет выведено множество сообщений.

Сборка ядра

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

www.bsdmag.org

# make |& tee ERRS.LOG

Знак & за вертикальной черточкой означает, что как сообщения об ошибках, так и обычные сообщения будут перенаправлены в один файл. Пользователи с оболочкой bash должны использовать следующую конструкцию

# make 2>&1 | tee ERRS.LOG

Если появляется ошибка во время компиляции, то первым надо подозревать конфигурационный файл. В случае, когда видите сообщения, что отсутствуют какие-то файлы или какие-либо процедуры, то скорее всего вы что-то забыли внести в конфигурацию. Если же появляются синтаксические ошибки, то виноват либо конфигурационный файл, либо система. Хотя систему подозревать нужно в самую последнюю очередь.

Устанавливаем новое ядро

Перед загрузкой с новым ядром убедитесь, что вы можете вернуться в систему, если ядро не сработает. Никогда не перезаписывайте старое ядро новым, т.к. в фатальном случае вам не с чего будет загружаться. Обычно, ядра хранятся как /vmunix, но каждая операционная система в наши времена старается называть их по-своему. В частности, для FreeBSD характерно именование ядра как /kernel. Вам следует сохранить старое ядро путем переименовывания /kernel в, например, /kernel.works. Все системы предоставляют ту или иную возможность загрузить старое ядро при тестировании нового. Это можно сделать с помощью загрузчика, однако это уже тема для другой статьи. Файл /kernel может быть жесткой ссылкой на другой файл, поэтому вы можете просто сделать ссылку на ваше новое ядро заместо копирования. Если же ядро не называется как /kernel, и вы не сделали ссылку, то вполне вероятно, что системный загрузчик будет испытывать определенную трудность, пытаясь найти его.

Тестируем новое ядро

Система с новым ядром стартует успешно, поэтому, скорее всего, вас можно поздравить. Однако, несколько проверок не помешает. Запустите команду ls по крайней мере в одной директории каждого примонтированного раздела. Успешный запуск будет

HOW-TO

означать, что файловая система работает нормально. Попробуйте также запустить команду ping на другую машину, чтобы убедиться, что вы видите вашу сеть и сетевая карта работает без нареканий.

Документирование

Прежде, чем вы умоете руки после этого долгого процесса с ядром, вернитесь к файлу SYS/i386/conf/KERNEL_NAME и расставьте комментарии так, чтобы вернувшись к нему через шесть месяцев или даже год, вы смогли вспомнить, что именно вы делали.

использование только одного параметра в каждой строке. В таком случае, применимо использовать столько строк, сколько используется параметров. Порядок, в котором идут контрольные фразы, обычно не важен. В таблице 1 отображен обычный порядок следования: Таблица 1. Ключевые слова, используемые в конфигурационных файлах BSD Ключевое слово

Назначение

machine

Выставляет тип машины

cpu

Выставляет тип процессора

ident

Устанавливает имя ядра

maxusers

Устанавливается размер таблицы ядра

options

Выставляет различные опции для встроенных модулей

config

Назначает области для корня и файла подкачки

Создание конфигурационного файла (в каталоге SYS/i386/conf) является самой сложной частью при сборке ядра. Остальная часть процесса — просто механические действия.

controller

Определяется дисковый или ленточному контроллеру

disk

Определеяется диск, подключенный к контроллеру

Конфигурационный файл — это список контрольных фраз, по одной на строку. Любая строка, начинающаяся с символа табуляции будет считаться продолжением предыдущей. Подстрока между символом # и концом строки считается комментарием. Пустые строки — игнорируются. Ключевые слова должны быть разделены пробелами, в любых других ситуациях (кроме этой и уже описанной выше с табуляцией как продолжением предыдущей строки) они и табуляция будут проигнорированы.

tape

Определяется ленточное устройство, подключенное к контроллеру

device

Определяются устройства, без контроллеров

pseudo-device

Определяются псевдоустройства

У вас достаточно свободного места? Тогда сохраните директорию SYS/compile/KERNEL_NAME на будущее. Она вам может потребоваться для ускорения следующего процесса пересборки. В противном случае, просто удалите ее; всё, что там есть, может быть сгенерировано заново командой config.

Создаем файл конфигурации

Целые значения чисел могут быть приведены в шестнадцатиричной, восьмиричной и десятичной формах. Восьмиричные числа обозначаются начальным нулем, а шестнадцатиричные — символами 0x в начале. Подстрока должна быть заковычена, если она содержит числа, используемые в качестве текстового значения. Контрольная фраза начинается с ключевого слова, которое будет означать, как интерпретировать всю последующую строку. После этого слова идут параметры. Для некоторых ключевых слов можно задавать несколько параметров, разделенных пробелом или запятой. Но хорошим тоном является

Параметр maxusers

С помощью ключевого слова maxusers выставляются размеры нескольких важных системных таблиц. Как намекает само имя параметра, аргументом к нему является максимальное количество пользователей, которых система одновременно может обслужить (хотя многие версии UNIX не слишком-то строго и соблюдают такое ограничение). Если вы хотите осуществлять сами заданный контроль, то значение для количества N одновременных пользователей должно быть N+1. В случае, когда настраиваете сервер для NFS-подключений, то значение также должно быть N+1 для N клиентских машин. Для каждого фрейм-буферного подключения (где будет запускаться оконное окружение) следует добавлять цифру 8.

12/2011

Подготавливаем свое собственное ядро FreeBSD

Число в maxusers влияет и на ряд других параметров ядра, таких как максимальное число процессов, количество в таблице файлового размещения, количество буферов на каждый терминал ввода/ вывода. Самый важный из них — это максимальное количество процессов в системе. Вот формула, что используется для такого подсчета:

Максимальное кол-во процессов = 20 + 16 * maxusers

Это количество включает в себя те 18 (или около того) процессов, которые запускаются в самом начале системы.

будет записать строку как:

options

В этом примере выставляется значение в 64 мегабайта. Самые часто применяемые опции приведены ниже. Значения назначить им нельзя. Для полного списка всех опций, смотрите документацию на продукт. •

Параметр options

С помощью директивы options выставляются переменные для C-препроцессора во время компиляции ядра. Существует два различных способа использования данной директивы. В первом случае токены определяются, но значения им не назначаются. В таком случае, токен просто включает или не включает конструкции препроцессора #ifdef и #ifndef. Если же директиве назначен параметр, то соответствующий символ препроцессора будет определен и сама опция включена. Например, для включения в ядро поддержки NFS используется следующая строка

options

NFS

Заметьте, что во FreeBSD любая строка, содержащая как буквы, так и числа, должна быть в двойных кавычках. Так, файловая система ISO-9660 включается в ядро с помощью строки

options

“CD9660”

Во втором случае, директива options не только определяет какую-либо переменную, но и выставляет ей определенное значение. Код ядра рассматривает эту переменную в качестве константы, а C-препроцессор подставляет нужное значение во все вхождения по ходу кода. Такие переменные задаются как:

options

symbol=“value”

Например, для изменения опции MAXDSIZ (она оределяет максимальное количество виртуальной памяти, которое может быть выделено сегменту данных на каждый единичный процесс), вам нужно

www.bsdmag.org

MAXDSIZ=“(64*1024*1024)”

•

• •

INET – эта опция включает поддержку сети. Распространие сетевых технологий настолько широкое сейчас, что не включив эту опцию, вы сделаете неработоспособным и массу зависимых от сети приложений. Будучи включенной она также потребует и включения псевдо-устройство закольцовывания (pseudo-device loop). Опция INET включает только программную поддержку сети. Аппаратная поддержка для сети также включается в конфигурационном файле, но чуть ниже. FFS – эта опция позволяет монтировать локальные диски к машине. Обычно по умолчанию она должна быть включена, кроме случаев, когда ядро проектируется с минимальным размером. Например, для бездискового клиента или встраиваемой системы поддержка FFS обычно исключается, чтобы максимально уменьшить размер. NFS – эта опция включает в ядре поддержку NFS. Нужна как для клиента, так и для серверной части. GATEWAY – пригодится для машин, где используется несколько сетевых интерфейсов и которые предназначены для маршрутизации трафика. Эта опция не слишком сильно вляет на использование памяти — просто увеличивает размер некоторых буферов в ядре для работы с сетевым трафиком и управления им, когда один из интерфейсов перестает функционировать.

Параметр config

Ключевое слово config определяет местоположение корневого раздела на системных дисках. Корневой раздел — это самый важный компонент файловой системы. Он содержит корневой каталог (/) и несколько дургих важных файлов и поддиректорий. Информация о том, какие файловые системы можно и нужно монтировать, хранится в файле /etc/fstab,

HOW-TO

но ядро не знает о существовании этого файла, пока корневой раздел не будет примонтирован.

загрузочный CD/DVD/USB диск, который будет знать о ней и при своей загрузке использовать ее.

Для старта всей файловой системы, нужна информация о дисковом разделе, на котором хранится корень. Такая информация может быть либо вкомпилирована в ядро, либо передана системным загрузчиком непосредственно ядру перед стартом. Ситуация с разделом подкачки несколько иная, т.к. она врядли будет активизирована, прежде чем необходимые скрипты /etc/rc* отработают и запустят команду swapon.

Аппаратные устройства

Конфигурационная строка будет выглядеть в виде

config kernel_name root on partition

Параметр kernel_name выставляет имя, под которым ядро будет именоваться. Ядра во FreeBSD обычно называются как kernel, иногда они именуются так, чтобы можно было понять на каком дисковом разделе они будут потом хранится (например, название может быть таким — dakernel). Параметр partition определяет на каком разделе будет размещена корневая файловая система. Обычно для IDE-дисков это значение wd0, а для SCSI — da0. Вот конкретный пример:

config kernel root on wd0

Возможность создать несколько различных вариантов ядер крайне полезна в случае планирования разного рода отказов. Так, наличие альтернативного корневого раздела со своим собственным ядром может послужить спасительным средством для восстановления главного раздела. Если же этот альтернативный раздел находится на том же самом диске и/или контроллере, что и разрушенный, то прежде чем перезагрузить систему, убедитесь — это не проблема в аппаратном обеспечении. Иначе можете разрушить и это альтернативное решение. На некоторых системах существует возможность загружаться с CD/DVD или с USB-дисков. Ядро, помещенное на эти носители, может автоматически загружаться и управлять дальнейшим процессом запуска. Если у вас есть альтернативная корневая файловая система, то стоит подготовить новый

Синтаксис для определения различных устройство достаточно запутан, а сами необходимые параметры, от которых зависит работа машины, разнятся от одной машины к другой. В разделе 4 man-страниц BSD рассматривается работа устройств. Поэтому там можно поискать и пример части конфигурационного файла. Будем следовать следующей инструкции — я привожу общий синтаксис, а так как вы, как я полагаю, составляете свою собственную конфигурацию на основе стандартной, то мне не придется рассказывать во всех деталях все нюансы какого-либо нестандартного устройства. Основная форма объявления устройства выглядит так:

device-type device-name at connection-info port address [device-class] irq interrupt

Параметры в квадратных скобках применимы не ко всем устройствам. Тип устройства, что вы объявляете, фигурирует под ключевым словом device-type. Некоторые типы устройств, такие как controller и disk имеют свои специальные обозначения. Остальные же объявляются ключевым словом device. Стандартное имя для устройства (или точнее, имя драйвера устройства) — это device-name, за которым следует его логический номер. Например, имя первого IDE-контроллера wdc0. По мере вашего продвижения по файлу конфигурации, вы можете консультироваться с секцией 4 справки, чтобы узнать более точно значение конкретного параметра. Заметьте, что логический номер устройства не имеет никакого отношения к аппаратной нумерации этого устройства. С помощью параметра connection-info ядру передается информация, где искать это устройство и что это за тип устройства. Для дискового и ленточного накопителя эта информация является именем контроллера. Для самих контроллеров и устройств это обычно название шины или название контроллера шины. Например, следующие строки определяют

12/2011

Подготавливаем свое собственное ядро FreeBSD

системную ISA-шину, IDE-контроллер, который присодинен к шине, а затем IDE-диск, что присодинен уже к IDE-контроллеру:

PCI-шины:

controller

isa0

Спасибо концепции PCI — нам не нужно перечислять многочисленные детали.

controller

wd0 at wdc0 drive 0

controller

wdc0 at isa? port “IO_WD1” bio irq 14

Обычно бывает достаточно вставить информацию, что устройство присоединено к определенноиу типу контроллера, без уточнения, к какому именно. Например, расположение IDE-контроллера wdc0, упомянутое выше, не конкретизируется (isa0 или isa1), т.к. мы вставляем шаблон isa?. Параметр address, который является аргументом для ключевого слова port, раскрывает расположение регистров команд и статуса данного устройства в адресном пространстве шины или платы, к которой оно (устройство) подключено. Для контроллеров и устройств, подключенных непосредственно к шине, обычно заполняют этот параметр. Каждый тип устройств имеет свое определенное количество адресов, что участвуют в адресном пространстве шины. Значения нужны только для устройств ISA и EISA. Драйверы для PCI-устройств могут определять нужный адрес динамически. Параметр interrupt нужен для назначения IRQ конкретному устройству. Опять же, этот параметр больше нужен ISA- и EISA-устройствам, т.к. PCIустройства получают автоматически нужное прерывание с помощью своего драйвера. Для некоторых устройств нужно выставлять ключевое слово device-class. Этот параметр, в основном, применяется в сетевых устройствах и некоторых контроллерах. Чтобы узнать, нужен ли какому-либо устройству этот параметр или нет, посмотрите в документацию. Вот как могут выглядеть строки конфигурации для сетевой ISA-карты NE2000:

device ed0 at isa? port 0x360 net irq 10

Эта строка размещает устройство ed0 на шине ISA с адресом ввода-вывода 0x360. Оно будет использовать 10-е прерывание. Обычным явлением бывает пропуск некоторых аргументов. Вот, например, как выглядит объявление для другой сетевой карты, на этот раз для

www.bsdmag.org

device de0

Самый лучший способо организовать ваши объявления устройств — это увязать их с соответствующими устройствами. Если у вас есть контроллер, то расположите привязанные к нему устройства рядом. Например, у вас есть IDEконтроллер. Внесите строки с объявлением вашего IDE-диска и привода CDROM прямо за объявлением контроллера. Таким образом, будет проще визуально отслеживать зависимости.

Клавиатура в качестве pseudo-device

В теории, драйверы для псевдо-устройств работают как обычные драйверы устройств. С единственным только отличием — у них нет реальной аппаратуры, с которой они взаимодействуют. Я говорю «в теории», т.к. некоторые опции ядра, которые как хамелеоны «прикидываются» псевдо-устройствами, на самом деле вообще не являются драйверами. По крайней мере с точки зрения пользователя. Синтаксис строки для псевдо-устройства выглядит так

pseudo-device

device-name number-of-instances

device-name — это имя псевдо-устройства, а number-of-instances — произвольное число, показывающее сколько таких воображаемых устройств должно быть организовано драйвером. Как правило, многие не используют этот числовой параметр. Существует ограниченное количество псевдоустройств. Однако большая часть из них обязательно должна быть активирована для правильного функционирования операционной системы. Так, на некоторых машинах должны быть активированы несколько псевдо-устройств, что обеспечивают работу: оконной системы, дополнительного клавиатурного ввода или дополнительных мониторов. Советую обратиться к документации по операционной системе, чтобы определить, какие из них вам действительно нужны. Либо просто включите все псевдо-устройства в базовую конфигурацию ядра.

HOW-TO

Некоторые общепринятые псевдо-устройства: •

•

pty – псевдо-терминалы (PTY). В своей работе они похожи на обычные аппаратные терминалы, но подключаются не к серверу, как последние, а присоединены к UNIX-процессу. PTY используются такими программами как ssh, xterm, telnet и rlogin. Также могут быть использованы некоторыми стандартными утилитами (например, шелл-скриптами) для обработки информации ввода. loop – драйвер закольцовывания симулирует поведение сетевого интерфейса для локального хоста. Позволяет задействовать сетевое программное обеспечение на машинах, не подключенных в сеть. Также предоставляет возможность отсылать сетевые пакеты себе же на машину. Подразумевается, что опцию INET вы уже включили.

Пример конфигурационного файла

Давайте рассмотрим пример конфигурационного файла для ядра, который мы назовем как EXAMPLE:

machine “i386”

cpu

“I386_CPU”

cpu

“I586_CPU”

cpu

EXAMPLE

options

INET

options

FFS

options . . .

# Internet: TCP/IP

“CD9660” # ISO 9660 CD-ROM filesystem NFS

# (FFS) Local filesystem # Network filesystem

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

controller isa0

controller eisa0

controller pnp0 controller pci0

В этих строчках определяется поддержка различных шин, которые ядро должно распознавать: ISA, EISA и PCI. Во второй строке включается поддержка Plugand-Play для ISA-устройств (pnp0).

controller

atkbdc0 at isa? port IO_KBD tty

device

psm0

maxusers 32

options

“I686_CPU”

config kernel root on wd0

Для корневого раздела используется первый IDEдиск.

Первые несколько строк определяют, что мы создаем ядро для машин на базе Intel-процессоров. И это ядро также должно поддерживать перечисленные семейства линейки x86. В этой же секции также назначается имя для ядра — EXAMPLE. Строка maxusers выставляет внутренние таблицы таким образом, чтобы была обеспечена одновременная работа 32 пользователям и 532 одновременно-работающим процессам.

“I486_CPU”

ident

TCP/IP, поддержка файловой системы ISO-9660 (используемой на CD-носителях), а также файловой системы FFS и сетевой файловой системы NFS.

device device

atkbd0

at isa? tty irq 1

vga0

at isa? port ? conflicts

at isa? tty irq 12

# splash screen/screen saver pseudo-device splash

# syscons is the default console driver, resembling a device

SCO console

sc0

at isa? tty

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

# Floppy devices

controller fdc0

at isa? port “IO_FD1” bio irq 6

disk

# IDE controller and disks

disk

fd0

drq 2

fd1

controller disk disk disk disk

at fdc0 drive 1

wdc0

wd0 wd1

controller

at fdc0 drive 0

at wdc0 drive 1

wdc1

wd2

wd3

at isa? port “IO_WD1” bio irq 14

at wdc0 drive 0

at isa? port “IO_WD2” bio irq 15

at wdc1 drive 0

at wdc1 drive 1

В этой же секции я задаю контроллеры и диски для моей тестовой системы: контроллер флоппидисковода, два привода флоппи-дисков (несмотря на то, что только один используется, резервирование их

12/2011

Подготавливаем свое собственное ядро FreeBSD

двоих не помешает) и два IDE-контроллера со своими соответствующими дисками.

options

ATAPI

options

ATAPI_STATIC # Don’t do it as an LKM

device

IDE bus

acd0

# Enable ATAPI support for

# IDE CD-ROM

Во FreeBSD мне нужно включать эти специальные параметры, чтобы IDE-устройства могли работать. Хотя поддержку для этого режима можно оформить и в виде подгружаемых модулей ядра (Loadable Kernel Module или LKM далее по тексту), но в случае использования IDE-диска в качестве корневого раздела, поддержка должна присутствовать в ядре в виде статического кода. Иначе система не сможет распознать корневой диск во время процесса загрузки.

pseudo-device

loop

pseudo-device

bpf 4

pseudo-device

ether

# Network loopback

# Ethernet support

# Berkeley packet filter

Из этих псевдо-устройств только look обязательно. Вообще-то, следует включать все псевдо-устройства в конфигурации GENERIC. Очевидно, что псевдоустройство ether необходимо для Ethernet-карт. А bpf требуется для работы tcpdump и для DHCP-клиентов, поэтому включаем оба параметра. Вполне возможно, что вы захотите исключить параметр bpf — чтобы люди не занимались сканированием сети (с локальной машины). Однако без него, вы сами останетесь с носом и не сможете выявить сетевые проблемы, когда это понадобится.

Настраиваем FreeBSD ядро

Стандартное ядро GENERIC не оптимизировано для быстродействия, которое вам, скорее всего, может потребоваться при работе высоконагруженного вебсервера. Приведу ряд предложений для построения ядра к такому серверу. До определенной степени, вы сами можете динамически управлять ядром FreeBSD с помощью команды sysctl, которая предоставляет интерфейс доступа ко многим внутренним структурам ядра. Эта команда очень мощная, но и достаточно опасная. Запустив её как sysctl -a вы сможете получить список переменных, которые, в идеале, вы также можете поменять. Почти все параметры из таблицы

www.bsdmag.org

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

Значение по умолчанию

Расшифровка

kern.maxfiles

3912

Максимальное кол-во открытых файлов

kern.maxproc

1956

Максимальное колво процессов

kern.maxfilesperproc

3520

Максимальное кол-во открытых файлов на процесс

kern.maxprocperuid

1760

Максимальное кол-во процессов на uid

kern.ipc.nmbclusters

8768

Максимальное кол-во сетевых буферов

kern.ipc.maxsockets

8768

Максимальное кол-во доступных сокетов

kern.ipc.somaxconn

128

Максимальное колво одновременно открытых сокетов

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

HOW-TO

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

maxusers 256

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

options

NMBCLUSTERS=17536

В этой строке я увеличиваю количество сетевых буферов

options

CHILD_MAX=1024

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

options

OPEN_MAX=1024

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

Добавляем драйвер устройства

Чтобы добавить новый драйвер устройства на FreeBSD машину, нужно добавить его описание в пару конфигурационных файлов, а также в код ядра, чтобы учесть все зависимости. Такая процедура не для слабонервных! В качестве примера я буду использовать мою FreeBSD машину, хотя все BSD-системы (включая NetBSD и OpenBSD) построены одинаково. Единственное, что размещение файлов может различаться. Я добавлю устройство «snarf» (псевдо-устройство) в мою машину. Первое, мне надо скопировать исходные файлы в нужный каталог:

# cp ~ammann/snarf.c /sys/pci/snarf.c

Т.к., мое устройство — это PCI-устройство, то я располагаю его в директории SYS/pci вместе с другими PCI-драйверами. Если ваше устройство не подпадает под эту категорию, то вам нужно положить его в новую директорию и отредактировать SYS/i386/ conf/files.i386. В моем же случае, категория драйвера уже определена, поэтому он будет автоматически скомпилирован и слинкован с ядром. Далее, я добавляю опредение устройства в конфигурационный файл. Я вставляю такую строчку в мой файл конфигурации EXAMPLE:

device snf0 # Snarf — мое сетевое псевдо-устройство

Эта строка инструктирует программу config, чтобы она включила файлы драйвера в состав ядро. Т.к. у сетевых устройств нет мажорных и минорных чисел, то передавать ядру их значения не нужно. Если бы это был драйвер блочного или символьного устройства, тогда бы мне пришлось выставить их значения в коде. Чтобы указать ядру, какой мажорный номер использовать, отредактируйте файл SYS/i386/conf/ majors.i386 и добавьте нужное значение. Какое значение является «нужным», зависит от устройства. Обращайтесь к документации написания драйверов.

В сети

Глава 9 в настольной книге FreeBSD: http://www.freebsd.org/doc/handbook/kernelconfig.html

12/2011

Подготавливаем свое собственное ядро FreeBSD

Следующие шаги включают: • • •

Запуск команды config и сборка нового ядра Копирование старого ядра в безопасное место и установка нового ядра Перезагрузка и тестирование нового ядра

Эти шаги уже были рассмотрены чуть ранее. И, наконец, нам нужно создать файлы устройств и протестировать уже само устройство.

Файлы устройств

Так принято, что файлы устройств располагаются в директории /dev. На больших системах, особенно на тех, что работают в сетевой инфраструктуре, и на которых задействовано множество псевдотерминалов, может быть сотня таких файлов. Файлы устройств создаются с помощью команды mknod, синтаксис у которой следующий:

mknod имя тип мажор минор

где имя — это название создаваемого устройства, тип — латинская буква c для символьного устройства, буква b — для блочного. А мажор и минор – мажорное и минорное число для устройства. Если вы создаете файл устройства, который будет задействован драйвером, уже находящимся в ядре, то найдите в man-страницах нужные числа (во FreeBSD обычно секция 4).

Подгружаемые модули ядра во FreeBSD

Во FreeBSD используются команды modload, modstat и modunload для управления модулями ядра. Эти команды, соответственно, загружают, показывают статус и выгружают конкретный модуль. Каждая утилита производит ряд операций ввода-вывода над файловым дескриптором модуля в /dev. По умолчанию, модули ядра FreeBSD живут в каталоге /modules. Если что-либо обзывается модулем и оно может быть загружено в ядро, то оно будет находиться именно здесь. Любой из модулей из этого каталога может быть подгружен в ядро FreeBSD упомянутой выше утилитой.

Об авторе

Paul Ammann живет в штате Коннектикут и недавно стал поклонником FreeBSD.

www.bsdmag.org

HOW-TO

OpenBSD 5.0: PHP, Cacti и Symon В прошедшем октябре я уже писал о том, как создать сервер на базе OpenBSD-Nginx-MySQL-PHP (ONMP). Обновление с OpenBSD 4.9 до OpenBSD 5.0 было трудным. Вы узнаете… • О новых изменениях в PHP для OpenBSD 5.0 • Как построить простой Caci сервер • Как вести мониторинг вашего OpenBSDсервера с помощью Symon

ричиной тому – в OpenBSD 5.0 изменились имена и размещение файлов, ответственных за работу PHP. В 5-й версии OpenBSD поставляются пакеты как PHP 5.2, так и PHP 5.3. Произошла замена как имен файлов и директорий, так и бинарных файлов. Теперь всё, что относится к PHP называется как “...php-5.2...”, и “...php-5.3...”. Также было изменено размещение конфигурационных файлов, теперь они находятся не в /var/www/conf, а в /etc. Вот некоторые наглядные примеры (замените 5.2 на 5.3 в случае, если используете эту версию — у меня именно версия 5.3): /usr/local/bin/php теперь стал /usr/local/bin/php-5.3

/usr/local/bin/php-fastcgi теперь стал /usr/local/bin/phpfastcgi-5.3

/var/www/conf/php.ini переместили и называют как /etc/php5.3.ini

Теперь, когда в OpenBSD поддерживаются обе версии PHP 5.2 и 5.3, нам правильнее будет устанавливать пакет от интерпретатора в интерактивном режиме (иначе пакетный менеджер pkg_add сообщит нам о неверных именах в зависимых от PHP пакетах). Вот как следует оформлять запуск php-fastcgi-5.3 в вашем файле /etc/rc.local: chroot -g nobody -u nobody / env -i PHP_FCGI_CHILDREN=5 \ PHP_FCGI_MAX_REQUESTS=1000 \

/usr/local/bin/php-fastcgi-5.3 -q -c /etc -b 127.0.0.1:9000 &

О чем вы должны знать… • Работе в командной строке OpenBSD • Разница между Apache и Nginx • Основные понятия о принципе работы SNMP

if [ -x /usr/local/bin/php-fastcgi-5.3 ]; then chroot -g nobody -u nobody / \

env -i PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000 \

/usr/local/bin/php-fastcgi-5.3 -q -c /etc -b fi

127.0.0.1:9000 &

И, наконец, в поставке OpenBSD 5.0 присутствует пакет Nginx 1.0.8. Если вы следуете за моей статьей об ONMP из октябрьского выпуска, то можете забыть об компиляции Nginx из исходных текстов — готовый пакет уже есть. Новое размещение HTML-файлов в Nginx — каталог /var/nginx/html/, а его конфигурационные файлы теперь в директории /etc/nginx/. Для более точной информации, как построить ONMP 5.0 сервер, посмотрите на мои записки по адресу: http://toby.org.org/wordpress/index.php/getting-started/ openbsd-5-0/

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

12/2011

OpenBSD 5.0: PHP, Cacti и Symon

SNMP, RRDTool и PHP-GD: # pkg_add -i net-snmp php-snmp rrdtool php-gd

# cp /etc/php-5.3.sample/snmp.ini /etc/php-5.3 # cp /etc/php-5.3.sample/gd.ini /etc/php-5.3

Теперь добавьте следующую строку в ваш файл /etc/rc.local, чтобы мы могли получить SNMP-данные от нашего сервера (для построения загруженности CPU, памяти, дискового пространства и т.д.): if [ -x /usr/local/sbin/snmpd ]; then /etc/rc.d/snmpd start fi

Теперь выполните инструкции с сайта http://cacti.net, чтобы правильно установить Cacti. В OpenBSD нет такого пакета, поэтому вам придется взять исходный текст на сайте и самостоятельно его собрать. Я не ставлю своей целью переписывать документацию к этому пакету, а просто приведу ряд отличий, которые характерны для операционной системы OpenBSD. Во-первых, в документации не говорится, где хранить файлы. Я полагаю, что вы уже в курсе, где располагается ваш главный каталог для HTMLфайлов. Поэтому, проделайте следующие операции: # tar xvfz cacti-0.8.7h.tar.gz

# mv cacti-0.8.7h /var/nginx/html/cacti

Также документация к Cacti утверждает, что следующая строка должна быть добавлена в планировщик crontab. Но она ... НЕПРАВИЛЬНАЯ: */5 * * * * cactiuser php /var/nginx/html/cacti/poller.php

ПРАВИЛЬНАЯ:

> /dev/null 2>&1

*/5 * * * * /usr/sbin/chroot -u cactiuser / /usr/local/ bin/php-5.3 \

/var/nginx/html/cacti/poller.php > /dev/null 2>&1

После установки Cacti, остаются еще 2 файла, в которые также нужно внести изменения. По умолчанию, Cacti будет пытаться поменять настройки памяти, используемые для PHP. В OpenBSD используется механизм безопасности Suhosin для PHP. И онто как раз и не позволит это сделать. При обычных настройках и конфигурации, с этим нет проблем, но в случае, если у вас установлена система контроля

www.bsdmag.org

доступа, такая как OSSEC, то очень вероятно, что вы сами будете заблокированы вашим же сервером. Закомментируйте следующую строку в файлах /var/nginx/html/cacti/cmd.php и /var/nginx/html/cacti/poller.php (поиск по ключевому слову «512» приведет вас к нужному фрагменту): ini_set(“memory_limit”, “512M”);

Операционной системе OpenBSD также не нравится, как Cacti проверяет локальный хост на доступность через SNMP. Я обнаружил, что настроив Cacti на использование UDP Ping вместо SNMP, в опросе «Ping method» для локального хоста, Cacti позволяет корректно строить графики. Эту опцию вы можете найти в секции веб-администрирования Cacti. Вот самый простой пример файла /etc/snmpd.conf, чтобы хотя бы начать работу. Он может не быть безопасным в плане SNMP, но в конце-концов, мы же только слушаем адрес 127.0.0.1! 127.0.0.1 Sweet 127.0.0.1! listen on 127.0.0.1

read-only community public system services 74

В версии PHP 5.3 ужесточились требования к функциям, работащим со временем. Пока не включите переменную «date.timezone» в конфигурации /etc/php-5.3.ini, будут сыпаться ошибки. Раскомментируйте следующую строку и выставьте вашу родную временную зону. ;date.timezone =

Более подробная информация о временных зонах PHP дана на сайте: http://www.php.net/manual/en/datetime.configuration.php

На данном шаге мы добавили несколько PHP модулей, поменяли пару конфигурационных файлов. Давайте перезапустим демонов: /etc/rc.d/nginx restart /etc/rc.d/snmpd restart kill -9 `pgrep php`

chroot -g nobody -u nobody / \

env -i PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000 \ /usr/local/bin/php-fastcgi-5.3 -q -c /etc -b 127.0.0.1:9000 &

HOW-TO

В сети • •

http://monkey.org/openbsd/archive/misc/0502/msg00164.html http://wpd.home.xs4all.nl/symon/

Cacti комплектуется только графиками для вашего локального хоста. Прочитав документацию Cacti до конца, вы сможете узнать, как добавить новые источники данных и новые графики. И в финале вдруг выясните, что графики загруженности CPU/RAM не работают. Чем больше я углублялся в проблему, тем более сложным казалось решение. Я окончательно сдался, когда увидел следующее сообщение [1] от OpenBSD-разработчика Hans Insulander, в котором он обзывает net-snmp «самым ужасным куском кода, который я когда-либо видел». Далее, в последующем сообщении от Aaron Glenn, заявлено следующее — «SNMP использует ASN.1, поэтому никакое переписывание кода не поможет проблеме безопасности». Очевидно, что разработчики OpenBSD не собираются активно поддерживать SNMP на уровне операционной системы из-за единственного решения на текущий момент. Обратимся к Symon [2]. также как и Cacti, назначение Symon — строить графики. Однако главная его цель — отображать графики именно локального хоста. Чтобы поставить этот пакет, нам потребуются 3 его компонента: Symon, Symux и Syweb. Установка этих модулей из пакетов OpenBSD происходит почти без дополнительных ухищрений. Первое, установите сами пакеты:

Затем выполните следующие команды: # mkdir /var/nginx/symon/rrds/localhost # chown -R nobody /var/nginx/symon

# /usr/local/share/symon/c_smrrds.sh all

Отредактируйте файл /var/nginx/html/syweb/setup. inc. Закомментируйте блок “OpenBSD, Apache chrooted”. Обратите особое внимание на то, где находятся символы «/*» и «*/». Это начало и конец комментариев. /* running OpenBSD, apache chrooted:

$symon[‘rrdtool_path’]=’/bin/rrdtool’; $symon[‘cache_dir’]=’/symon/cache’; $symon[‘host_tree’]=’/symon/rrds’; $symon[‘layout_dir’]=’/symon’; */

Создадим новый блок для nginx: /* running OpenBSD, nginx not chrooted: */

$symon[‘rrdtool_path’]=’/usr/local/bin/rrdtool’; $symon[‘cache_dir’]=’/var/nginx/symon/cache’; $symon[‘host_tree’]=’/var/nginx/symon/rrds’; $symon[‘layout_dir’]=’/var/nginx/symon’;

Запускаем Symux и Symon: # /usr/local/libexec/symux # /usr/local/libexec/symon

Добавляем их в файл /etc/rc.local

# pkg_add -i symon syweb

if [ -x /usr/local/libexec/symux ]; then

Сам файл конфигурации /etc/symon.conf правилен. Оставим, в том виде, в котором он поставляется.

Но добавим следующую строку в /etc/symux.conf как раз перед последней закрывающей фигурной скобкой: datadir “/var/nginx/html/symon/rrds/localhost”

echo -n ‘ symux’; /usr/local/libexec/symux

if [ -x /usr/local/libexec/symon ]; then

echo -n ‘ symon’; /usr/local/libexec/symon fi

И проверяем волшебные новые графики по адресам: http://youserver/cacti и http://yourserver/syweb!

После установки пакетов symon и syweb нужно будет переместить некоторые каталоги, чтобы они соответствовали конфигурации nginx. Об авторе # mv /var/nginx/symon /var/nginx

# mv /var/nginx/html/syweb /var/nginx/html

Toby Richards работает сетевым администратором с 1997 года. Каждая статья, что выходит из-под его пера, отражает новый проект, сделанный на основе *BSD.

12/2011

HOW-TO

Извлекаем полезную информацию из лог-сообщений Приложение syslog-ng – это мощный и гибкий инструмент для хранения и обработки системных сообщений, которое помогает в работе системных администраторов. В этой статье рассматриваются некоторые новые и некоторые не слишком известные возможности. Вы узнаете… • О модели системных сообщений, что формируются в syslog • О важности метаданных • Как обрабатывать и сопоставлять логсообщения с помощью syslog-ng

риложения обычно посылают свой информационный вывод системному демону, который трансформирует их в расположение, где хранятся все системные события — это либо логфайлы на локальной машине (обычно в каталоге /var/log/), либо пересылает на удаленный сервер. Большая часть операционных систем UNIX и Linux задействуют для этих целей системный демон под названием syslogd. Он же к полученным сообщениям добавляет мета-информацию (названную как заголовок для syslog), такую как дату и время, когда сообщение получено, а также имя или адрес хоста, где сообщение было создано. Проект syslog-ng является популярным альтернативным демоном по управлению системными сообщениями, который получил такую известность за способность и надежную доставку сообщений, их фильтрацию и сортировку. За последние годы он получил также такой функционал как: прямое перенаправление событий в SQL-базы, передача сообщений по шифрованному TLS-каналу, а также возможность модифицировать сами логсообщения. Приняв во внимание, что syslog-ng может обрабатывать события на базе трафаретов, его следует рассматривать также как и высокоскоростное аналитическое средство, работающее в реальном времени.

О чем вы должны знать… • Основах системных событий

Форматы стандартного системного сообщения

Системные сообщения обычно бывают в одном из двух форматов: в формате RFC3164 (иногда также называемом как BSD-сообщение или классическое системное сообщение) или в более новом — RFC5424. Основные характеристики обоих форматов приведены ниже.

RFC3164

Сообщение в формате RFC3164 состоит из следующих частей: ■ PRI ■ HEADER ■ MSG Общая длина сообщения не может быть длиннее 1024 байтов. Следующая строка может быть примером для такого собщения: <133>Feb 25 14:09:07 webserver syslogd: restart

Сообщение должно быть в соответствии со стандартом: <приоритет>время_дата имя_хоста приложение: текст_сообщения. Часть

сообщения

PRI

(также

называемое

как

12/2011

Извлекаем полезную информацию из лог-сообщений

приоритетное число) представляет собой службу и срочность поступившего сообщения. Службой является часть системы, что послало данное сообщение, а срочность показывает его важность. Число вычисляется как номер службы, помноженный на 8, и добавлением числа срочности. Часть HEADER (заголовок) содержит дату и время, а также имя хоста (без доменного имени), либо IP-адрес устройства. Поле, показывающее время в целом, приводится без зональной информации. Заключительная часть — MSG — содержит имя программы или процесса, что сгенерировало данное сообщение, а также сам текст сообщения. Обычно идет в формате: имя_программы [PID]: текст сообщения.

RFC5424

Главное улучшение этого формата заключается в том, что дата и время даются в формате ISODATE, а это означает, что присутствует также и зональная временная информация. Второе важное дополнение — включена новая структура данных (Structured Data или просто SDATA), в которой может храниться произвольная мета-информация о сообщении или же хосте. Например, когда поступает информация о файлах, демон syslog-ng может также включать в сообщение сведения о самом файле, такие как путь до него, его имя и размер. К сожалению, формат RFC5424 пока не сильно распространен.

Сила модели событий в программе syslog-ng

Внутренняя архитектура syslog-ng такова, что приложение преобразовывает каждое сообщение в пары имя-значение, называемые как свойства. Каждая часть входящего сообщения становится свойством. Например, имя отсылающего хоста, название отслылающего приложения, сам текст сообщения и когда оно было послано, а также время его получения. Поля в структуре данных SDATA из сообщения формата RFC5424 также автоматически преобразовываются в свойства. Другие метаданные, например, теги или служебные поля, могут быть вручную добавлены в сообщения. Однако, syslog-ng может и сам извлекать данные из текста с помощью парсеров (подробнее о них чуть позже). Плюсом такого похода является гибкость, т.к. теперь все сообщения не нужно кидать в один общий системный журнал событий, а распределить и по другим журналам. Как пример, в журнал SNMPсообщений, или в журнал системного аудита.

www.bsdmag.org

Основные принципы работы syslog-ng Приложение syslog-ng может принимать сообщения разных типов и от различных источников, включая файлы, сокеты, или даже удаленные хосты. Оно читает входящие сообщения и перенаправляет их в нужном направлении. Такими направлениями, где будут храниться системные сообщения, могут быть: файлы, сокеты, другие хосты в сети, таблицы в базах данных, либо внешние приложения. Источники и назначения — это независимые объекты. С помощью внутренней логики определяется, какая именно трансформация будет произведена над сообщением, прежде чем оно попадет от источника к своей цели. Схема трансформации (log path) состоит из одного или нескольких источников и одного или нескольких назначений; сообщения приходящие от источника рассылаются по всем назначениям, указанным в схеме. Схема трансформации может включать и фильтры. Это, как правило, правила, по которым отбираются определенные сообщения. Например, выбираются только те сообщения, отсылаемые каким-либо заданным приложением. Если в схеме есть фильтры, то syslog-ng будет рассылать по нужным назначениям только соответствующие фильтрам. Другими элементами, могущими участвовать в работе, являются парсеры и модификаторы по шаблону. Парсеры разбивают сообщения в удобную форму, для последюущей удобной их обработки. Модификаторы же изменяют сообщения путем добавления, замены или удаления некоторых частей оригинального сообщений.

А если быть более точным, то syslog-ng хранит следующие данные о каждом сообщении: • временные метки: время, в какое syslog-ng получил входящее сообщение, а также время, затраченное на его обработку (если включено); • служба/приоритет: значения, которые отражают системную службу (kern, user, daemon, и т.д.) и приоритет сообщения (обычно называемым в

HOW-TO

•

• •

RFC как сложность), могут быть как в числовом, так и в текстовом виде; теги: произвольные метки, добавляемые к телу сообщения. Например, syslog-ng автоматически добавляет идентификатор источника к каждому сообщению, полученному от этого источника; свойства: любая другая мета-информация, добавляемые или извлекаемая из сообщения. Выглядят как пара: имя-значение. SDATA: подмассив свойств, т.е. данные, полученные в части SDATA от сообщения в формате RFC5424.

Вы можете свободно изменить большую часть свойств с помощью правил модификации, чтобы выставить значение какого-либо свойства, или же найти через регулярное выражение определенную строку и заменить ее на нужную. Однако же, некоторые свойства находятся в состоянии «только для чтения», особенно те, что отвечают за дату и время.

destination d_file {

Пример: Как перенаправить мета-данные на логсервер Чтобы перенаправить имя лог-файла на сервер с журналами syslog-ng, установите поле .SDATA в сообщениях от клиента. Имя исходного журнала доступны в свойстве $FILE_NAME rewrite r_setfilename { set(“$FILE_NAME” value(“.SDATA. file@18374.4.name”));

На серверной стороне создайте нужное назначение, которое будет использовать свойство выше в своем файловом шаблоне. destination d_test {

file( “/var/log/apache2/${.SDATA. file@18372.4.name}” create_dirs(yes) ); };

Почему мета-информация может быть полезна

Мета-данные полезны по нескольким причинам. Они предоставляют дополнительную информацию о сообщении, позволяя более точно классифицировать его, а также содержат информацию об окружении, в котором событие возникло. Свойства сообщения позволяют вам настроить систему с такой сортировкой, которая больше всего вам нужна. Вы можете использовать шаблоны, которые учитывают нужные свойства по всей внутренней архитектуре syslog-ng. В шаблонные свойства автоматически вписываются нужные значения по мере обработки сообщения. Т.е., когда вы включаете свойство HOST для файла назначений, размещаемый на центральном журнальном узле, то syslog-ng отсортирует входящие сообщения от каждого хоста по этому признаку. Пример: задействуем свойства в шаблонах destination d_file {

file(“/var/log/$YEAR.$MONTH.$DAY/$HOST. log”); };

Чтобы создать отдельный файл для каждого приложения, просто добавьте свойство $PROGRAM в шаблон:

file(“/var/log/$YEAR.$MONTH.$DAY/$HOST /$PROGRAM.log”); };

Вы также можете задействовать шаблоны для полного переписывания или реструктуризации сообщения. Например, для корректировки тех сообщений, что не удовлетворяют стандарту на системные события. Для изменения формата даты на нужный, либо же для лучшей интеграции с другими приложениями, что будут обрабатывать эти системные журналы. Пример: применяем нужный формат в сообщениях destination d_file { file(“/var/log/messages” template(“$ISODATE $HOST $MSGHDR$MSG\n”); };

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

примере производится выборка с приоритетом 4 или выше:

12/2011 (пилот)

Извлекаем полезную информацию из лог-сообщений

filter f_level {“$LEVEL_NUM” > “5”};

А в этом фильтре производится сравнение по имени хоста, например, по начальной строчке myhost, так, чтобы попадались myhost-1, myhost-2 и т.д. filter f_wildcard {host(“myhost*” type(glob));};

Однако полностью возможности мета-данных и свойств могут быть раскрыты при задействовании парсеров. Чтобы они сегментировали тело сообщения в нужные свойства и характеристики. В качестве примера, приведем следующий сценарий. Вам нужно выделить имя пользователя и название хоста из сообщений входа и выхода пользователей из системы, названия тех команд, что выполнялись через sudo и т.п. Выделив такие сведения, вы можете разместить их в базе данных, чтобы потом, с помощью нужных запросов, проводить наглядный аудит — кто, где и когда. Поэтому в случае, если один из серверов будет недоступен, вы сможете запустить отчет и увидеть, кто пользовался данным сервером. Пример: Начиная с версии syslog-ng 3.3 (в редакции Open Source) можно хранить сообщения и их свойства в базе MongoDB. Из которой уже сгенерировать нужный вам отчет с помощью JasperReports.

Парсим лог-сообщения

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

соответствующие имена. Таким образом могут быть обработаны лог-сообщения от веб-сервера Apache и перенаправлены в разные файлы, в зависимости от имени пользователя, запросившего тот или иной веб-ресурс. Заметьте, вы можете задействовать парсеры над любым полем собщения, а не только над текстовым. Вы также можете отдельно выделить имена хостов в структурированную базу, как мы уже показали с myhost-1 и myhost-2. Пример: парсим сообщения от Apache Следующий парсер обрабатывает лог-файл от вебсервера Apache и разделяет на несколько полей. Обычно такие логи веб-сервера представляют строку параметров, разделенных пробелами. 192.168.1.1 - - [31/Dec/2007:00:17:10 +0100] “GET /cgi-bin/example. cgi HTTP/1.1” 200 2708 “-” “curl/7.15.5 (i4 86-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5” 2 example.balabit

Парсер, что обрабатывает их, в syslog-ng будет выглядеть так: см. Листинг 1. Другим мощным средством будет обработка с помощью базы трафаретов. Т.к. такая техника немного сложнее, то рассмотрим её подробно в следующей секции. Текущая версия, которая в настоящее время находится в разработке (syslog-ng 3.4), обзавелась инструментом обработки полей сообщений и в формате JSON.

База трафаретов syslog-ng

Приложение syslog-ng может сравнивать содержимое входящих сообщений с предопределенным трафаретом. Таким образом, syslog-ng способен

Листинг 1. Парсим сообщения от Apache с помощью csv-parser parser p_apache { csv-parser(columns(“APACHE.CLIENT_IP”, “APACHE.IDENT_NAME”, “APACHE.USER_NAME”, “APACHE.TIMESTAMP”, “APACHE.REQUEST_URL”, “APACHE.REQUEST_STATUS”, “APACHE.CONTENT_LENGTH”, “APACHE.REFERER”, “APACHE.USER_AGENT”, “APACHE.PROCESS_TIME”, “APACHE.SERVER_NAME”) flags(escape-double-char,strip-whitespace) delimiters(“ “) quote-pairs(‘””[]’) ); };

www.bsdmag.org

HOW-TO

идентифицировать конкретное сообщение, классифицировать и назначить ему необходимые мета-поля (например, тип события «безопасность», «аппаратная ошибка»), а также «вытащить» нужные данные из распознанного сообщения. База трафаретов в syslog-ng использует в работе базисные деревья (Radix trees), т.к. этот метод достаточно быстрый и хорошо масштабируется. Скорость обработки практически не зависит от общего количества трафаретов в базе, а зависит только от длины сообщения и количества «похожих» трафаретов. По сравнению с традиционными решениями по обработке сообщений, которые основаны на регулярных выражениях, трафареты в syslog-ng просты в написании, понимании и последующей эксплуатации. Сравним: Сообщение приходящее от OpenSSH-сервера: Accepted password for joe from 10.50.0.247 port 42156 ssh2

Его эквивалент в базе трафаретов syslog-ng: Accepted @QSTRING:auth_method: @ for @QSTRING:username: @ from \ @IPv4:client_addr: @ port @NUMBER:port:@ @QSTRING:protocol_version: @

Как видите, трафарет в syslog-ng использует типизацию данных для определения значения, что ожидается в логе, например, строка в кавычках (QSTRING), число, IP-адрес. Совпадающие значения могут быть получены из лога и использованы в качестве свойств. В приведенном выше примере, такие свойства включают метод авторизации, имя пользователя, IP-адрес клиента. Эти же свойства могут быть использованы и фильтрах, и в шаблонах. Если вы храните сообщения и их свойства в базе данных, то становится очень просто составить запрос, какие пользователи заходили на ваш сервер и с каких адресов. База трафаретов в syslog-ng — это XML файл, в котором хранятся сами трафареты и различная метаинформация о них. Трафареты являются просто примерами сообщений, по которым происходит идентификация входящих логов. Мета-данные могут включать описание, произвольные поля, класс сообщения (который просто является специальным типом тега), и любая другая информация со свойствами, которая добавляется к сообщениям, попавшим под трафарет. Пример:

База

трафаретов,

содержащая

Листинг 2. База трафаретов для единичного сообщения <patterndb version=’4’ pub_date=’2010-10-17’>

<rules>

<pattern>Accepted @QSTRING:SSH.AUTH_METHOD: @

for@QSTRING:SSH_USERNAME: @from\ @QSTRING:SSH_CLIENT_ADDRESS: @port @NUMBER:SSH_PORT_NUMBER:@ ssh2</pattern>

</patterns>

</rules>

</rule>

</ruleset>

</patterndb>

12/2011

Извлекаем полезную информацию из лог-сообщений

единственный трафарет (Листинг 2) Следующая база содержит правило для SSH соединений вида: Accepted password for sampleuser from 10.50.0.247 port 42156 ssh2

Такая мета-информация может быть использована, к примеру, для разметки важных сообщений, а затем их фильтрации по тегу. Вы также можете сгенерировать специальные служебные сообщения, которые будут высылаться системой при поступлении нужного входящего сообщения.

Срабатываем по приходящему событию, а также внешние действия

С помощью трафаретной базы syslog-ng можно автоматически генерировать новые сообщения о том, что обнаружено подходящее входящее логсообщение. Сгенерированные сообщения могут быть сконфигурированы внутри правил базы трафаретов и, в идеале, на каждое входящее сообщение можно назначить свой собственный класс служебного сообщения. Такое, конечно же, бывает очень редким событием, но в некоторых случаях это обязательное условие. Пример: генерируем новое сообщение (Листинг 3) Данный пример, будучи вставлен в базу трафаретов, генерирует сообщение, когда любое входящее сообщение подпадает под соответствующее правило. Рассылка уведомлений непосредственно из syslog-ng на данный момент не реализована, однако достаточно просто организовать передачу

Листинг 3. Определяем действие в базе трафаретов <actions> <action> <message> <values> <value name=”MESSAGE”>Лог-сообщение от $HOST попало под правило $.classifier.rule_id</value> </values> </message> </action> </actions>

www.bsdmag.org

сгенерированного сообщения внешнему скрипту, который уже сам перешлет нужному адресату по электронной почте или протоколу SNMP. В следующей версии (3.4) такая функция доставки через электронную почту посредством самого движка syslog-ng будет реализована. Сообщения могут быть отправлены и в случае обнаружения коррелирующих сообщений. Более подробно в следующей секции.

Корреляция системных сообщений

Обнаружение коррелирующих сообщений — один из основополагающих принципов в анализе сообщений, т.к. сообщения обладают свойством беспорядочности, и очень часто важная информация о событиях поступает в разных логах. Например, почтовая служба Postfix любит заносить адреса отправителя и адресата в разные сообщения. А сервер OpenSSH, в случае неудачной попытки захода на машину, высылает в первом письме сам факт неудачной входа и с разъяснением этой ошибки в следующем. Но в большинстве случаев важны вместе как события, так и разъяснения к ним. Имея возможность собирать информацию о событиях как о событиях, а не в виде сообщений, позволят намного облегчить жизнь системному администратору. Корреляция сообщений в syslog-ng основана на успешной идентификации лог-сообщений трафаретной базой syslog-ng. Вы можете расширить правила, описывающие трафареты, новыми, которые будут учитывать корреляцию совпадающих сообщений. Такая процедура корреляции означает сборку сообщений в группы, названные контекстом. Который состоит из серии сообщений, связанных между собой по какому-либо признаку. Например, контекстом могут быть сообщения от одной SSH-сессии. Сообщения могут добавляться к контексту по мере их обработки. Контекст можно задать используя простые статические строки, либо с помощью макросов и динамических значений. Например, вы можете сгруппировать сообщения присланные одним и тем же хостом ($HOST), приложением ($HOST$APPALICATION), или процессом ($HOST$PROGRAM$PID). Сообщения, принадлежащие одному и тому же контексту, коррелируют и могут потом быть обработаны рядом способов. Можно включить

HOW-TO

Листинг 4. Консолидируем информацию в одном сообщении <pattern>Accepted @QSTRING:SSH.AUTH_METHOD: @ for@QSTRING:SSH_USERNAME: @from @QSTRING:SSH_CLIENT_ADDRESS: @port@NUMBER:SSH_PORT_NUMBER:@ ssh2</pattern> <pattern>pam_unix(sshd:session): session closed for user @ESTRING:SSH_USERNAME: @</pattern> <value name=”MESSAGE”>SSH-сессия для пользователя $SSH_USERNAME с ${SSH_CLIENT_ADDRESS}@1 закрыта. Она длилась с ${DATE}@1 по $DATE.</value>

информацию, содержащуюся в предыдущем сообщении контекста, в сообщения, следующие за ним. К примеру, если почтовая служба отсылает серию разных лог-сообщений для каждого получателя письма (как делает Posftix), то можно «прилепить» все адреса реципиентов к одному первоначальному. Другим вариантом является генерация абсолютно нового сообщения, в котором будет храниться вся важная информация, что пришла в одном контексте. Примером для такой ситуации может быть информация о времени захода и выхода с сервера (либо время тайм-аута) авторизованных сессий для протоколов SSH/telnet. Чтобы убедиться, что в рамках контекста обрабатываются только связанные события, можно назначить особое значение — время на обработку контекста, т.е. как долго контекстная обработка должна длиться. Если достигнут тайм-аут, то контекст закрывается. Он также может быть закрыт явно, если поступило последнее сообщение в рамках контекста. Если обрабатывается информация о соединениях, то сообщение с уведомлением о закрытии соединения и вызовет закрытие контекста. Когда механизм корреляции сообщений используется вместе со срабатывающим механизмом, то вы можете обращаться к полям и значениям предыдущих сообщений контекста. Следующие трафареты генерируют коррелированное сообщение, где включена информация от обоих лог-сообщений в контексте - конструкция может быть использована для поиска совпадающих сообщений от OpenSSH, а далее следует действие. Для обработки уже собранных сообщений, syslog-ng также умеет работать и с лог-файлами. В этом случае, для расчета времени между сессиями, будет использоваться время, записанное внутри сообщений, а не системное время.

Где найти syslog-ng

Открытая редакция (Open Source Edition) syslog-ng доступна в портах и коллекции пакетов FreeBSD. Порт раньше присутствовал в секции sysutils/syslog-ng3, но в связи с удалением версии 1.X, он был переименован в syslog-ng. Для минимизации внешних зависимостей, в пакете присутствует только ограниченное количество функций. Для задействования всех тех возможностей, что перечислены в сегодняшней статье, установите версию syslog-ng 3.3 из обновленной ветки портов. Исходный текст также может быть найден на странице проекта — http://www.balabit.com/network-security/syslog-ng/. Если возникли какие-либо проблемы, или же у вас есть ценные комментарии, присоединяйтесь к списку рассылки: https://lists.balabit.hu/mailman/listinfo/ syslog-ng/.

Об авторе

Robert Fekete является инженером по документированию в компании BalaBit (Венгрия), которая занимается разработкой syslog-ng и других продуктов сетевой безопасности. Он также является приверженцем открытых продуктов и любит писать о свободном ПО по мере возможности.

12/2011

<<TOP>>

www.bsdmag.org

БЕЗОПАСНОСТЬ

Анатомия компрометации FreeBSD (часть 1-я) Считается, что семейство BSD более устойчиво к атакам, нежели остальные системы, однако ни один сервер или IT-продукт не застрахован от взлома. В этой статье мы рассмотрим лучшие методики от вторжения, и что делать, когда случилось самое неприятное. Вы узнаете… • Как запланировать стратегию безопасности

меня долгоиграющая любовь с интернетом. Будучи немного IT-динозавром, который сохранился со времен 1200-бодовых модемов, выделенных линий и операционной системы CP/M, я могу припомнить, что с безопасностью в начале 1980-х была намного проще. В те времена, если ваша компания была достаточно финансово успешна, то у нее была своя корпоративная сеть. Она была очень затратным делом, строго эксплуатировалась, поэтому никаких возможностей для неправильного поведения не было. Может быть только оставался маневр для так называемых хакеров в «белых шляпах», которые не стремились скомпрометировать систему ради финансовой выгоды, коммерческих секретов или ради глупых шуток. В то время, цель была другой — максимально исследовать новый (в то время) мир, поэтому-то и никаких зловредных наружений не было. А если и появлялись, то их можно было быстро вычислить, т.к. обычно производились отдельными умельцами. Теперь же перемотайте в 2011 год и мы обнаружим: многочисленные бот-неты, сетевые сканеры, вирусы с всякой вредоносной ерундой, социальный инжиниринг и т.д. Более того, технология шагнула к нам в офисы, дома и машины. Атаки теперь проводятся на глобальной уровне — страна против страны — и каждый с интернет-подключением теперь может достаточно быстро загрузить инструкцию, как взломать ту или иную систему. Пока правительства вяло реагируют на такие угрозы и неэффективно

О чем вы должны знать… • О навыках администрирования BSD систем

работают на юридическом поле, вы, как системный администратор, находитесь на первой линии огня. К сожалению, громких процессов очень мало, и случаются только, если жертва нападения или сам хакер широко известен. Оставим интернет в стороне, и глянем на компьютерную безопасность, которая меня всегда очень сильно удивляла. Особенно в организациях. Там умудряются по какой-то причине обходиться без громких инцидентов. Возьмите, к примеру, большие кабинеты офисов (особенно это принято в IT), где пароли клеят на мониторы и клавиатуры, и они обычно самые простые. Также их любят хранить в незакодированной форме внутри текстовых файлов — это самые распространенные примеры, но глупость коллег иногда просто вызывающая. Рассылка почтой незашифрованной клиентской базы — это еще один пример. И я также часто наблюдаю, как технические операторы службы поддержки (и даже плохо спроектированные системы) рассылают вместо с почтой и некоторые служебные поля. Кроме риска атаки вида «человек-в-середине-цепочки», что случится после того, как какой-нибудь Ваня или Вася сохранит такое письмо на рабочий стол? Любый, кто имеет доступ на его машину, может узнать как скомпрометировать и чужую систему. Поэтому проблема заключается не только в применении лучшей защитной технологии, но также и в обучении

12/2011

Анатомия компрометации FreeBSD (часть 1-я)

пользователей правильной работе.

Насколько вы защищены?

Я всегда говорил, что единственный способ 100% защитить сервер от вторжения, это залить его бетоном и отправить на дно океана. Может выгдялеть слишком экстремально, но высказывалось как-то предположение, что даже OpenBSD было скомпрометировано (см. статью в Register, табл. 3). Существует слишком много векторов атак, различных багов и других замечательных путей заставить сегодняшние сложные приложения выполнять те задачи, для которых они вообще не проектировались. Я частно использую telnet для проверки веб-серверов или, например, для отсылки тестовых электронных писем, но те современные диагностические утилиты, что не были доступны 30 лет назад, дают фантастическую фору для «черных» хакеров. Возьмем, к примеру, эксплойты вида 0day. «Черный» хакер Петя обнаруживает недокументированную дырку в программе X. Он сообщает об этом друзьям , но просит их не рассказывать больше никому и не публиковать сей факт. Если системные администраторы, где работает программа, не обнаружат никакой странной активности вокруг их систем, и нет процесса, который такую активность может засечь, то Петя с друзьями могут остаться незамеченными. Только когда атака становится более явной и принимает угрожающий вид, тогда исследователь, связанный с безопасностью, начинает задумываться. Или же кто-то написал об аналогичной атаке и оригинальный разработчик программы X может тогда эту уязвимость устранить. Все зависит от масштаба проблемы и риска — если атаки проводятся часто, то кто-нибудь заметит аномальность и, в случае серьезных повреждений, вопросы будут заданы сразу же. Но что происходит, когда Петя не говорит об уязвимости и использует ее время от времени? Шансы обнаружения малы, обзор проблемы узок, а сам разработчик и соответствующие эксперты даже не в курсе проблемы. Пока Петя не выпустил информацию в широкий доступ, уязвимость так и будет использоваться втихомолку. До момента, пока не достигнута точка кипения, проблема диагностирована, проанализирована и уязвимость устранена, а упомянутый Петя достаточно умен, чтобы не атаковать специально расставленную ловушку с этой уязвимостью.

www.bsdmag.org

Таблица 1. 10 заповедей системного администратора 10 заповедей администратора безопасности Паранойя важна. Доказательства, основанные на паранойе, даже лучше. Журналируйте всё, включая контрольные суммы. Ваш противник может быть ближе, нежели вы думаете. Храните конфиденциальную информацию в секретном месте. Шифруйте, защищайте паролями и разрешайте другим доступ только в случае, если им это действительно нужно. Используйте сложные пароли и регулярно их меняйте. Не встраивайте пароли в скрипты. Производите часто обновление системы. Запускайте нужные службы, только если они очень-очень нужны. Потом же, не забывайте их защищать. Регулярное архивирование не должно быть по желанию — оно обязательно. Пробуйте взломать свои собственные системы. Вы будете удивлены обнаруженным. Не будьте удовлетворены результатом. Не думайте, что и другие такие же сознательные, как и вы. Расскажите им о вашей позиции. Если вас атаковали — не паникуйте. Будьте методичны и сохраните улики. Если не уверены в собственных силах, или же инцидент достаточно серьезен, то пригласите профессионалов, прежде чем наломаете дров и не оставите ни следа. Не пытайтесь претворить аналогичное действие над вашим врагом — вы поставите под вопрос официальное расследование и, возможно, подставите себя. Вы не одни. Большинство людей за «добрых» парней, нежели за «плохих».

На самом деле это реальная проблема со «многими неизвестными». Хорошие системы управления могут снизить риск, но никогда не уберут его полностью. Как и банковская система, наша IT-инфраструктура очень сильно основана на доверии. Конечно, мы можем придумать белые списки для наших серверов, так, что только наши уважаемые заказчики могли бы заходить на них. Но даже такое решение не будет практичным, т.к. достаточно просто будет заменить IP- и MACадреса. Частные сети находят свое применение, но в интернет-эпоху каждый хочет быть оставаться подключенным к сети. И аббревиатура WWW не расшифровывается как «всемирная паутина» (World Wide Web), в реальности она означает «дикий, дикий запад» (Wild Wild West).

Знайте своего врага

«В искусстве войны» Сунь Цзы сказано — «Знайте своего врага». И системный администратор должен воспитать в себе такое военное отношение, как будто

БЕЗОПАСНОСТЬ

бы у него есть нечто ценное, и которое не нужно терять. Во-первых, самая очевидная часть уязвимости — это ваши пользователи. Строгая политика по применению ресурсов, которая официально поддержана и закреплена на самом верхнем уровне — хорошая отправная точка. Большая проблема при это может быть в сохранении баланса. Слишком запретительная и к IT будут относиться как к инструменту подавления. Слишком мягкая? Тогда к ней будут относиться как бумажке, на которую можно наплевать. Хорошим пунктом в ней может быть позиция по конфиденциальности и безопасности данных, т.к. многие страны сейчас иемют в своем законодательстве необходимые пункты по защите данных и электронной коммерции. Существует ряд коммерческих продуктов против потери данных, но те, кто хорошо понимает UNIX, ценят силу Таблица 2. 10 заповедей хакера Хакер в черной шляпе — 10 заповедей Скрывайте ваши следы. Никогда не показывайте свой собственный IP-адрес. Очищайте все места, где может храниться история ваших посещений. Старайтесь заполучить привилегии суперпользователя. Если они у вас есть, то весь мир у ваших ног и вы можете еще лучше спрятаться. Не высвечивайте. Максимальное использование ресурсов сервера просто раскрывает вас. Вы не хотите, чтобы ваша жертва обратила внимание на вас, поэтому не берите много. Ни один из серверов защищен на 100%, но некоторые защищены слабее. Опробуйте силы сначала на простых мишенях — чем больше распространена уязвимость, тем меньше шансов быть раскрытым. Никому не доверяйте. Хвастаться вашим умением — это замечательно. Пока кто-нибудь не захочет вами заинтересоваться. Если вы взламываете, то можете огорчить людей. Некоторые из них в достаточной власти, чтобы наказать вас — учитывайте риски. Знайте, как программировать. Если вы не понимаете C, ассемблер и что такое указатели, то вы просто любитель. Улучшайте социальные навыки. Один из действенных способов взлома — социальный инжиниринг. А это требует владение навыком управления другими людьми. Будьте в курсе технологий. Новые уязвимости появляются каждый день, т.к. технологичская сфера увеличивается. Существует мало экспертов в безопасности и много некудышных программистов. Физический доступ к машинам почти всегда дает вам преимущество (например, позволяет расставить кейлоггеры), однако риски здесь выше.

собственных скриптов. Будучи частью общей политики безопасности, любая конфиденциальная информация должна быть помечена как таковая. И будет довольно просто организовать сервер электронной почты, который такие прикрепления заводил бы в очередь, с последующей их проверкой. Если всё нормально, то сообщение пропускается. Идя далее по такому сценарию, электронная почта может быть сканирована на наличие ключевых слов и значений, и направлена в специальную очередь при совпадении. Единственной проблемой здесь может быть, что найдутся те, кто захочет обойти систему. Решения для этого может быть таким — использовать безопасный шлюз, куда файлы сгружаются и проверяются, а затем забираются заказчиком. Интересным и распространным явлением является передача паролей и логинов устно по телефону или через факс. Но это уже проблема другого отдела. Большинство же «домашних» уязвимостей созданы по ошибке (если честно, когда последний раз вы по ошибке отослали не тому адресату какой-либо важное письмо?) и хорошей практикой будет попытаться минимизировать потери. Конфиденциальные документы на расшаренных ресурсах обычная практика, но используя специальные процедуры (например, только веб-мастер может загружать на сервер документы) можно риски снизить. Также важен хороший файрволл, и несколько проксисерверов, которые умеют работать с HTTP- и FTPтрафиком. Сканирование электронной почты на наличие вредоносных программ (включая ссылки и прикрепления) работает определенно хорошо, будучи централизировано. Следующий момент — преднамеренное причинение ущерба персоналом. Я знаю, что документы и приложения могут быть специально удалены или украдены, или не туда направлены. Либо же наносится ущерб самой аппаратуре. Коллега моей жены стал саботировать систему, когда ему отказали в повышении. Поэтому это хороший фундамент, где руководство и IT-сотрудники могут найти общий язык — когда существует риск в работе организации. Дело Коли находится в папке на увольнение? Убедитесь, что его профиль и права на систему заблокированы, прежде чем он пойдет на встречу с отделом кадров. И наконец, существует просто беспечность. Большие открытые офисные пространства и широкие TFT-экраны просто радость для подсматривающих. А

12/2011

Анатомия компрометации FreeBSD (часть 1-я)

также схемы локальной сети с IP-адресами на столе и паролями, прилепленными к мониторам. Если вы всех доверяете у себя в компании — это просто замечательно, но чем больше людей работает, тем сложнее становится доверять каждому. Однажды меня чуть физически не избил один менеджер, когда я отказался ему дать администраторские пароли на несколько серверов, несмотря на то, что ему был предложен неограниченный доступ к нужным ему ресурсам, но под его личной учетной записью. Это не прошло даром, и в конце обнаружилось, что он скачивает пиратский софт с каких-то странных мест. Давайте людям доступ к системам только предварительно выяснив «зачем иименно?», и если есть подозрение отвечайте отказом. Если действительно потребуется, уточняйте с более старшим менеджером, но по умолчанию, решение должно быть таким. Следующая категория относится к «внешнему миру». Существуют разные типы хакеров с самыми различными намерениями (см. Таблицу 4). Я разбил их на различные категории, т.к. для разных атак нужны свои инструменты, уровни компрометации и т.п. В действительности же, есть только «хорошие парни» и «плохие парни», однако я пытаюсь сказать здесь следующее — степень нежелательности всех атак находится под тем или иным вопросом, однако самое важное — степень серьезности атаки. С «детскими» атаками проще работать (конечно, при условии, что не были заменены пароли и данные не стерли), в то время как с тяжелыми и серьезными атаками на вашу организацию, устроенную конкурентом или политической силой, с целью вытащить секреты, будет подпадать под совершенно другую категорию. Кому-то придется переустанавливать сервер, другим

же потребуется вовлечь специальные структуры и провести полный аудит. Грустно это признавать, но для индивидуального предпринимателя или малого бизнеса в этом вопросе нет практически никакой пользы от спецслужб. Вот представьте себе картину — вы приходите в милицию заявить о том, что вы пострадали от вируса типа «Мелисса». Обратят ли на вас внимание? А если вы большая компания, или связана политически с какой-то партией, или же являетесь правительственным агенством — шансы быть услышанным вырастают в разы (см. инцидент с EDF Greenpeace в Табл.3). Большинство организаций относятся к попыткам взлома как — «Это не наша проблема». Совсем недавно пришло подложное письмо от одного крупного банка — я заинтересовался, а сам поддельный сайт, на который ссылается письмо, всё еще работает? К моему удивлению, оказалось, что да. Будучи примерным сетевым гражданином, я обратился в службу поддержки банка. На что мне ответили, что у них нет специалиста по безопасности, работающего по выходным. Интернет-провайдеры и интернет-бизнесы — также отдельная история. Я уже забыл количество моих обращений к ним по поводу спама и вредоносных электронных писем идущих с их адресов. Обычный их ответ — «И что?». Поэтому здесь больше поднимается не аспект безопасности, а больше вопрос репутации компании.

Адаптируемся к ментальному подходу «Администратор, нацеленный на безопасность»

Я привел 10 заповедей как для стороны администраторов, так и для хакеров (см. Табл. 1 и Табл. 2), т.к. важно знать, как думает другая сторона.

Таблица 3. Ссылки Название

Сайт

ФБР поместило бэкдор в OpenBSD

http://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim

На фирму EDF наложен штраф за взламывание http://www.ft.com/cms/s/0/78f3b452-0c70-11e1-8ac6-00144feabdc0.html компьютеров Greenpeace Подмена шелл-оболочки после взлома

http://www.madirish.net/node/237

MUH

http://muh.sourceforge.net/

Process faker

http://packetstormsecurity.org/search/files/?q=process%20faker

Metasploit framework

http://metasploit.com

Wireshark

http://www.wireshark.org

Nmap

http://nmap.org

Backtrack Linux

http://www.backtrack-linux.org

www.bsdmag.org

БЕЗОПАСНОСТЬ

Самим большим врагом является собственное самодовольство. Как я это выяснил с одной своей старой системой на базе FreeBSD 6.1, и которая была взломана. Она была подключена к интернету и были проведены длительные мероприятия по защите ее с помощью файрвола, программ по проникновению, прежде чем она была сдана в реальную эксплуатацию. Т.к. сервер достаточно старый и использовался больше как прокси и шлюз для почты, я решил не обновлять его вручную, а дождаться выхода FreeBSD 8 и заодно обновить «железо». Внутренний голос говорил мне, что я напрашиваюсь на неприятности, особенно при использовании стандартного Apache 1.3, но на нем никакие сайты не размещались, кроме стандартной страницы. Я также был загипнотизирован мантрой «Пока работает — не трожь», т.к. бесперебойная работа сервера была важна. Я также знал, что моя почтовая подсистема находится в безопасном состоянии (отправка и получение почты непосредственно провайдеру, на конкретный IP-адрес), и имеется только один непривилегированный аккаунт к SSH, к тому же последний слушал на нестандартном порту, а

у аккаунта был сложный пароль. Сервер периодически сканировался на наличие руткитов и т.п., а сам IPадрес, выданный провайдером, был динамическим. Я проверял те запросы, что отправляются на вебсервер, запрашивая несуществующие страницы, но выяснял со всей дотошностью из-за ограниченности во времени, и потому, что не было видно явно заданного образца в таких запросах. С прицелом на будущее, мне надо было добавить скрипты в систему, которые автоматически блокировали бы те IP-адреса, что запрашивают несуществующие страницы. Несколько недель назад я начал испытывать проблемы с моим широкополосным подключением, и через некоторое роутер совсем перестал работать. Он был выдан моим провайдером, поэтому я не мог его обновить. В итоге я заменил его на резервный и проверяя его работу, через команду netstat обнаружил незапланированный трафик на IRC-сервер в Венгрии. Т.к. мои родные были подключены к интернету, то я не особенно этим озаботился. Но потом проверил внутреннюю сеть и ... соединение было установлено не

Таблица 4. Причины, из-за которых взламывают Тип хакера

Стиль поведения (Modus Operandi)

Этический хакер в «белой шляпе»

Входит в системы просто для развлечения/обучения. Разрушений не наносит. Системный администратор и автор программы уведомляется в частном порядке о найденной уязвимости. Может рассказать об эксплойте в широкой печати, если видит, что к угрозе относятся спустя пальцы.

«Детский» атакующий

Скачивает эксплойты из сети и запускает их над публичными или частными серверами. Действует ради самоутверждения, и не заботится о рисках своего обнаружения (например, о раскрытии IP-адреса) и рисках атакуемых систем. Обычно атаки выглядят как DoS — Denial of Service (т.к. перегружает сервер пустыми запросами).

Обычные хакеры и спамеры

Потенциально связаны с преступным миром. Хотят заполучить максимальное количество машин, насколько это возможно, т.к. их быстро раскрывают. Используют многовекторную атаку, начиная с вредоносного письма и заканчивая подменой сайтов и их компрометация. Заинтересованы во многих деяниях — от сбора адресов электронной почты и номеров кредиток, до атак типа DoS. Большинство атак может быть ограничено за счет общей концепции безопасности, не связанной с эксплойтами вида 0day.

Ворующие трафик

Используют системы в качестве устройств для атак вида «человек-в-середине». Либо же для прикрытия незаконной деятельности. Количество увеличивается за счет развития беспроводной сети WiFi / Bluetooth. Сетевой эквивалент телефонного фрикинга.

Хакер в «черной шляпе»

Хочет получить доступ к специфическим коммерческим или личным секретам, паролям, чтобы умышленно нанести вред системе / данным. Отслеживает определенную жертву. Профессиональный уровень эксплойта, будет задействовать любой или все возможные векторы атак для получения преимущества (например, вредоносные письма / кейлоггеры / социальный инжиниринг / скрыток наблюдение / сетевые сниферы / телефонная прослушка и т.д.). Не нужно путать с обычными хакерами, которые работают на объем — здесь целенаправленная атака. Пример — червь Stuxnet.

12/2011

Анатомия компрометации FreeBSD (часть 1-я)

оттуда. Изолировав сервер, я проверил на наличие все необычные процессы командами ps и top. Оказалось, что всё пусто. Моим следующим шагом был запуск tcpdump и выяснилось любопытное. Трафик был только исходящим, уходил раз в минуту. Зацепку дала команда lsof, т.к. оказались неизвестные открытые файлы в директории /tmp, с правами www-data. А у меня на сервере не было какой-либо страницы, что писала бы файлы. Действительно, оказалось, что было проведено muh-инфицирование и активность скрыта с помощью Process Faker. Хакер запустил процесс, который запускал IRC-сервер с правами веб-сервера. А для надежности, поместил запуск этого процесса в crontab, чтобы при перезагрузке машины ничего не изменилось. В виду того, что владелец файлов был www-data, стало ясно, что Apache — это слабое звено в цепочке. А сам доступ был получен через порт 80, возможно через POST-команду и подмену шеллоболочки. В целом, крайне запутанный хак. К счастью, судя по логам, хакеру не удалось удачно подключиться к IRC-серверу, и никакие данные не потерялись. Удаление записи из crontab, а также файлов из /tmp, разрешило проблему — сервер нормально работает. Apache же я отключил до перехода на новую систему.

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

В конце этого анализа, и чтобы подчеркнуть 4-ю заповедь (Табл. 1) — процитирую Catherine Aird. «Если вы не можете быть хорошим примером, тогда вам придется выступать серьезным предупреждением для остальных». Надеюсь, мой опыт окажется полезным для всех.

В следующих выпусках

Мы рассмотрим на эффективные стратегии по улучшению безопасности, а также на сами инструменты, включая сниферы пакетов и сканеры портов, ловушки, а также на правила файрвола, которые помогут ограничить атаки на Apache. Мы также рассмотрим некоторые инструменты проверки на уязвимость, на проникновение и попробуем воссоздать muh-атаку на тестовый сервер. Посмотрите на Табл. 3, в которой перечислены более-менее известные утилиты.

Специальная справка

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

www.bsdmag.org

Об авторе

Rob Sommerville неравнодушно относился к технологиям с детства. Ярый сторонник открытых систем с середины восьмидесятых, он проработал во многих корпоративных секторах, включая финансовый, автомобильный, авиаиндустрии, правительственный и СМИ. Был во множестве ролей - начиная от технической службы поддержки, системного администратора, разработчика и заканчивая системным интегратором и IT-менеджером. Вышел из мира CP/M и газоразрядных ламп, однако хранит паяльник под рукой, на всякий случай.

БЕЗОПАСНОСТЬ

Укрепляем BSD с помощью уровней безопасности По умолчанию, серверы BSD являются более защищенными, нежели другие операционные системы. Но они, однако, требуют небольших изменений, чтобы быть переведенными в промышленную эксплуатацию. Вы узнаете… • Как настраивать уровень безопасности на операционных системах класса BSD. • Как использовать chflags для разблокирования конфигурации системы и лог-файлов.

ровни безопасности — это один из тех инструментов, что может быть использован для поддержания состояния системы на должной отметке. В этой статье раскрывается как сконфигурировать уровни безопасности посредством securelevel для OpenBSD, FreeBSD, NetBSD и DragonFlyBSD. Назначение функции уровня безопасности заключается в ограничении возможностей ядра, в зависимости от выбираемого уровня. По умолчанию, полная функциональность во все BSD-ядра включена, включая возможность производить изменения на этапе старта системы. Изменения проводятся в соответствии с настройками в файле rc.conf. Уровень безопасности может быть повышен в работающей системе, но понизить получится только из однопользовательского режима, либо перезагрузившись. Во FreeBSD, очевидно, опция REGRESSION вкомпилирована в ядро, так, чтобы можно было задействовать значение sysctl для понижения уровня безопасности. Настройки этого уровня совпадают практически для всего семейства BSD. В Листинге 1 приведены начальные значения для каждой операционной системы: FreeBSD 8.2, OpenBSD 5.0, NetBSD 5.1, DragonFlyBSD 2.10. Самой отличительной системой является Open-

О чем вы должны знать… • Об основные приемах при работе в командной строке BSD. • Основах работы sysctl.

BSD, в которой уровень безопасности по умолчанию равен 1. Другие же три системы находятся по умолчанию в незащищенном режиме. В OpenBSD и NetBSD применяются одинаковые настройки, также как и в паре FreeBSD / DragonFlyBSD. На уровне со значением -1, все устройства/файлы/память можно читать и писать в них. Как указывается в man-справке, эти настройки во FreeBSD, NetBSD и DragonFlyBSD должны быть изменены на нужные. Файловые свойства могут быть усилены с помощью утилиты

Листинг 1. Следующие значения используются при старте каждой системы. FreeBSD 8.2

kern.securelevel: -1 OpenBSD 5.0

kern.securelevel=1 NetBSD 5.1

kern.securelevel = -1 DragonFlyBSD 2.10

kern.securelevel: -1

12/2011

Укрепляем BSD с помощью уровней безопасности

Листинг 2. Следующие значения используются при старте каждой системы. Следующие команды применяются в семействе систем BSD для выставления флагов sappnd и schg (соответственно, «system append-only» и «system immutable»). Обратите внимание, как на этом фоне выделяется OpenBSD — она не позволяет изменить эти флаги, т.к. по умолчанию находится на первом безопасном уровне. Выставляем флаги schg и sappnd в системах FreeBSD, NetBSD и DragonFlyBSD

freebsd# ls

freebsd# chflags nosappnd test.log freebsd# rm -rf test.log freebsd# ls freebsd#

test.conf

freebsd# chflags schg test.conf

Работаем с флагами schg и sappnd в OpenBSD

total 2

# ls

freebsd# ls -lo

-rw-r----- 1 root wheel schg 22 Nov 16 12:00 test. conf

freebd# rm -rf test.conf

rm: test.conf: Operation not permitted freebsd# chflags noschg test.conf

freebsd# rm -rf test.conf

test.conf

# chflags schg test.conf # ls -lo total 4

-rw-r--r-- 1 root wheel schg 11 Nov 16 11:23 test. conf

freebsd# ls

# rm -rf test.conf

freebsd# echo “LogEntry: Test” >> test.log

# chflags noschg test.conf

freebsd#

freebsd# wc -l test.log 1 test.log

freebsd# chflags sappnd test.log freebsd# ls -lo total 2

-rw-r--r-- 1 root wheel sappnd 15 Nov 16 12:24 test.

log

freebsd# echo “LogEntry: Test” >> test.log freebsd# wc -l test.log 2 test.log

freebsd# rm -rf test.log

rm: test.log: Operation not permitted

chflags, как проиллюстрировано в Листинге 2. Уровень безопасности может быть повышен за счет обновления с помощью утилиты sysctl значения для переменной kern.securelevel, как показано в Листинге 3. Вывод команды chflags для систем For FreeBSD, NetBSD и DragonFlyBSD, которые находятся на первом уровне безопасности, аналогичен ситуации с OpenBSD, т.е. когда она уже находится на стандартном для нее первом уровне. Применение флага schg для конфигурационных файлов, позволяет заблокировать их изменение, и тем самым сохранить целостность

www.bsdmag.org

rm: test.conf: Operation not permitted

chflags: test.conf: Operation not permitted # echo “LogEntry: Test” >> test.log

# wc -l test.log 1 test.log

# chflags sappnd test.log # echo “LogEntry: Test” >> test.log

# wc -l test.log 2 test.log

# rm -rf test.log rm: test.log: Operation not permitted

# chflags nosappnd test.log chflags: test.log: Operation not permitted

системы. Такую же операцию можно произвести и над лог-файлами. Во FreeBSD и DragonFlyBSD можно ограничить загрузку и выгрузку из памяти модулей ядра. Это повлияет на работу утилит kldload и kldunload. Другой важной стороной является то, как реализованы уровны безопасности внутри jailконтейнеров FreeBSD. Контейнер внутри может использовать более высокое значение, даже если сам хост использует более низкое. Данная особенность позволяет хосту искусно манипулировать нужными файлами даже находящими внутри jail-контейнера.

БЕЗОПАСНОСТЬ

В сети • • • • • • • • • •

FreeBSD man page for securelevel: http://www.freebsd.org/cgi/man.cgi?query=security&sektion=7&apropos=0&manpath=FreeBSD+8.2-RELEASE FreeBSD Handbook warning on securelevels: http://www.freebsd.org/doc/en/books/faq/security.html#SECURELEVEL OpenBSD man page for securelevel: http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel&sektion=7 NetBSD man page for securelevel: http://netbsd.gw.com/cgi-bin/man-cgi?secmodel_securelevel+9+NetBSD-current DragonFlyBSD man page for securelevel: http://leaf.dragonflybsd.org/cgi/web-man?command=securelevel&section=ANY

Другой отличительной особенностью в операционных системах семейства BSD является максимальный уровень безопасности. Во FreeBSD и DragonFlyBSD используется максимальное значение 3, что по функционалу равно второму уровню в OpenBSD и NetBSD. Разница заключается в разном формате работы с сетевыми настройками, которые используются в OpenBSD и NetBSD на уровне 2, но не используются во FreeBSD/DragonFlyBSD. Для последних, этот фунционал располагается в третьем уровне. Второй уровень безопасности препятствует переводу времени часов назад, или же увеличению более, чем на одну секунду вперед. Такая настройка, будучи применена вместе с флагом sappnd, позволяет вести лог-файлы не только в полной сохранности, но и быть абсолютно точными с тем временем, когда туда добавлялись новые записи событий. На третьем уровне безопасности (равному уровня 2 в отношении OpenBSD/NetBSD) уже правила файрвола нельзя будет изменить. Системный уровень нужно будет понизить, презде чем внести изменения в операционную систему. Примерный вывод команд для OpenBSD приведен в Листинге 4. Хотя эти функции действительно очень помогают заблокировать операционную систему на модификацию, они должны быть хорошо изучены и поняты прежде, чем вы отправите систему в реальную эксплуатацию. В книге по FreeBSD в разделе, посвященном безопасности, отмечается, что системные файлы перед загрузкой должны быть защищены — тогда применение различных уровней безопасности будет эффективным. Если же атакующий способен запустить какой-либо свой код, прежде чем уровень выставлен, то защиту можно будет обойти. Помимо этого, надо учитывать, что для обновления системы придется или же переходить

в однопользовательский режим, либо выводить ее полностью из работы. Как и любой другой инструмент безопасности, настройка уровня безопасности само по себе не является решением. Он просто предоставляет механизм поддерживания целостности работающей операционной системы. Существует ряд других, более гибких, вариантов ограничения доступа к файлам. Например, контрольные листы доступа (access control lists — ACL) и мандатный контроль доступа (mandatory access controls — MAC). Задействуя все доступные инструменты в BSD-системах, можно содержать серверы в крайне защищенном состоянии, и на протяжении всего срока эксплуатации держать в том виде, в котором они были настроены в самом начале.

Об авторе

Michael Shirk — фанатик BSD, который работает с OpenBSD и FreeBSD более 6 лет. Он работает в сообществе безопасности и занимается поддержкой открытых продуктов по безопасности, которые работают на операционных системах семейства BSD.

12/2011

ПОГОВОРИМ

Новости от FreeBSD Foundation Организация FreeBSD Foundation — это некоммерческая фирма, работающая на основании положения 501(c)(3) закона о доходах США. Её цель — поддержка проекта FreeBSD, а также построение сообщества по всему миру. Она ответственна за исполнение контрактов, лицензионных соглашений, авторских прав и других законных мер, для которых требуется наличие юридического лица.

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

Конференции, спонсорство для поездок и стенды на конференциях

В 2011 году Фонд спонсировал следующие BSD конференции: • AsiaBSDCon, проводилась в Токио (Япония) с 17 по 20 марта

• • • •

BSDCan и саммит разработчиков, проводился в Оттаве (Канада) с 11 по 14 мая KyivBSD, проводилась в Киеве (Украина) 24 сентября EuroBSDCon и саммит разработчков, проводился в Маарсене (Нидерланды) с 6 по 9 октября Саммит поставщиков FreeBSD, проводился в Санта-Кларе (США) с 3 по 4 ноября

В дополнение к указанных конференциям, Фонд оплатил разработчикам проезд на следующие мероприятия: FOSDEM: один разработчик BSDCan: 6 разработчиков EuroBSDCon: 6 разработчкиов GSoC Mentor Summit: один разработчик

12/2011

Новости от FreeBSD Foundation

Каждый спонсируемый, по окончании поездки, предоставляет отчет. В котором отражает, какую информацию он получил от поездки. Эти отчеты доступны на блоге Фонда: http://freebsdfoundation.blogspot.com/. Дирекция FreeBSD Foundation также на добровольных началах участвует в работе стендов FreeBSD, места для которых выделяют организаторы выставок. Посещая эти мероприятия, можно обменяться ценными идеями по дальнейшему развитию проекта, а также оплатить работу Фонда. По крайнем мере один директор присутствовал в стендовой работе на конференциях: FOSDEM — Брюссель (Бельгия), с 5 по 6 февраля SCALE — Лос-Анджелес (США), 26 февраля AsiaBSDCon — Токио (Япония), с 17 по 20 марта Indiana LinuxFest — Индианаполис (США), 26 марта FlourishConf — Чикаго (США), 2 апреля BSDCan — Оттава (Канада), с 13 по 14 мая SouthEast LinuxFest — Спартанбург (США), 11 июня Ohio LinuxFest — Коламбус (США), 10 сентября EuroBSDCon — Маарсен (Нидерланды), с 8 по 9 октября LISA — Бостон (США), с 7 по 8 декабря На следующий, 2012 год, запланировано участие представителей Фонда в следующих стендах: SCALE — Лос-Анджелес (США), 21 января NorthEast LinuxFest — Вустер (США), 17 марта Indiana LinuxFest — Индианаполис (США), 14 апреля BSDCan — Оттава (Канада), с 11 по 12 мая Также ожидается, что стенды FreeBSD будут организованы и на других конференциях, которые посещались в 2011 году, сразу после назначения конкретных дат и расположений.

Финансируемые проекты разработчиков

В 2011 году Фонд запланировал потратить 125 тыс. долларов для финансирования работ. Работы на 85 тыс. долларов уже завершены, а еще 2 дополнительных проекта рассматриваются для назначения им остатка бюджета этого года. Следующие проекты достигли финала:

Поддержка IPv6 во FreeBSD и PC-BSD

Bjoern Zeeb — обладатель награды Itojun Service Award, выданную ему за работу по открытой реализации IPv6, был удостоин гранта для улучшения

www.bsdmag.org

поддержки IPv6 в FreeBSD и PC-BSD. Этот проект был совместно профинансирован с компанией iXsystems — корпоративным спонсором проекта PC-BSD. Оригинальная разработка во FreeBSD по поддержке IPv6 (на базе кода проекта KAME) впервые появилась в версии FreeBSD 4.0 и распространена во многих коммерческих продуктах, основанных на кодовой базе FreeBSD. Перед началом проекта этого года, реализация IPv6 в стандартном коде ядра FreeBSD была опциональной. Однако, она также требовала наличия IPv4. Те прикладные программы, которые декларировались как годные к «IPv6» и работали поверх двойного стека, могли, на самом деле, некорректно работать с протоколом IPv6. Благодаря этому проекту в ядро FreeBSD и PC-BSD добавлена раздельная поддержка протоколов. И теперь эти системы можно рассматривать как идеальную площадку для тестирования как открытых, так и закрытых IPv6-программных продуктов. Проект был завершен в свой срок, поэтому и FreeBSD, и PC-BSD смогли принять участие в мероприятии — Всемирный день IPv6, 8 июня. Доступны к загрузке версии систем с поддержкой только IPv6: FreeBSD (http://www.freebsd.org/ipv6/) и (http://pcbsd.org/IPv6).

Проект по ресурсным контейнерам

Edward Napierala был удостоин гранта для реализации контейнеров и простого механизма ограничения ресурсов в jail. В отличие от зон в Solaris, jail-реализация во FreeBSD не обеспечивает ограничение по ресурсам. Как результат, пользователям часто приходится заменять jail на другой механизм виртуализации. В рамках этого проекта была создана единая, унифицированная структура для контроля над использованием ресурсов. Которую использовали далее, реализовав ограничения для каждого jail-контейнера. В будущем, эту же конструкцию можно будет задействовать для более умного механизма ограничения ресурсов — Hierarchical Resource Limits. Либо же для развития механизмов, аналогичных AIX WLM (AIX Workload Manager). Их можно будет использовать для обеспечения более точного распределения ресурсов как в административных, так и в биллинговых целях.

Реализация поддержки GEM, KMS и DRI для драйверов Intel

Константин Белоусов был награжден грантом для реализации поддержки GEM, KMS и DRI для видео-

ПОГОВОРИМ

драйверов Intel. Этот проект был также проспонсирован и компанией iXsystems. В ходе проекта был написан код для GEM, был портирован код KMS и написаны новые DRI-драйверы для графических устройств от Intel, включая самое свежее поколение интегрированных карт — Sandy Bridge. После окончания этапа полного тестирования, код будет включен в основную ветку и позволит запускаться открытым видео-драйверам Intel (c интегрированным 3D-ускорением) на платформе FreeBSD. Тем самым, расширяя спектр аппаратного обеспечения, пригодного для настольного применения. Тестовые сборки PC-BSD, где будет использоваться разработанный код, ожидаются в самом конце первого квартала 2012 года.

Проект по разработке алгоритмов синхронизации времени

Julien Ridoux и Darryl Veitch из университета Мельбурна были награждены грантом на реализацию поддержки серии алгоритмов по синхронизации времени. Протокол NTP был годами опорной точкой для быстрой синхронизации времени в компьютерах. Однако, сервис ntpd начал проявлять ограничения, которые случаются из-за своей характерной природы отложенного (feed-back) взаимодействия с ядром. Наоборот, опережающий подход (feed-forward), кажется по своей сути более надежным механизмом и позволяет достичь почти идеальную производительность. Этот проект расширил систему управления временем во FreeBSD для работы с сервисами времени, функционирующими по опережающему принципу. Теперь оба механизма могут работать на одной и той же системе, а сами пользователи выбрать, какой сервис сихронизации времени для них более удобен. Этот новый опережающий механизм предоствляет несколько новых функций: быстрое проставление временных меток, новый счетчик времени для измерения интервалов с GPS-точностью. Чрезвычайно высокая надежность, возможность запустить часы без сетевого подключения основываясь только на хранимых временных метках, более точное измерение времени для использования в виртуальных машинах, а также для их горячей миграции.

Реализация API для xlocale.

David Chisnall получил грант на создание API для xlocale, что позволит произвести портирование libc++. В составе FreeBSD всегда была своя стандартная C-библиотека, но в качестве замены использовался GNU-аналог — libstdc++ . Библиотека libc++ является альтернативным решением, разработанное как часть проекта LLVM и которое лицензируется под двумя лицензиями: UIUC и MIT. Эта библиотека зависит от другой низкоуровневой ABI-библиотеки C++. Реализация последней была написана для PathScale и впоследствии оплачена фондами FreeBSD и NetBSD, чтобы она стала открытой. Другая зависимость — это стандартная C-библиотека. libc++ была написана компанией Apple и использует множество не-портированных расширений, необходимых для нужд локализации, и известных как xlocale. С помощью данного проекта были дописаны отсутствующие API в стандартную C-библиотеку FreeBSD. Теперь, когда проект завершен, стало возможным собрать libc++ и на FreeBSD.

DIFFUSE

Центру для изучения интернет-архитектур Университета имени Суинбурна (Swinburne University of Technology’s Centre for Advanced Internet Architectures) был присужден грант для написания DIFFUSE во FreeBSD. DIFFUSE (Distributed Firewall and Flow-shaper Using Statistical Evidence — распределенный файрвол и шейпер с использованием статистических данных) — это расширение к подсистеме ipfw, которое позволяет файрволу классифицировать трафик, используя статистические свойства трафика. И, в дальнейшем, создать сетевые правила для определенного типа трафика по всей распределенной сети взаимодействующих узлов. DIFFUSE использует технику машинного обучения для эффективной и надежной классификации трафика, в основе которого лежит изучение уникальных статистических свойств трафика, в добавление к уже традиционной проверке заголовков пакетов или их содержимого. DIFFUSE позволяет также произвести классификацию трафика по одному какому-либо месту (например, в ядре или центре сети), а произвести требуемый шейпинг и дифференцирование в другом месте (т.е. на границах сети).

12/2011

Новости от FreeBSD Foundation

Проект позволил вставить прототип DIFFUSE во FreeBSD, что в дальнейшем, очевидно, увеличит её востребованность при построении сетевой инфраструктуры. Для технологии DIFFUSE есть применение у интернет-провайдеров, при широкополосном коллективном доступе и при развертывании больших корпоративных сетей.

Проект с пятью новыми TCP-алгоритмами

Grenville Armitage был награжден грантом для реализации пяти новых контрольных алгоритмов передачи данных. До этой работы, в TCP-стеке FreeBSD не было простого механизма для добавления новых TCP-алгоритмов. С помощью этого проекта достигнуты следующие улучшения: Модульный каркас для контрольных протоколов; Добавлены каркасы Khelp (Kernel Helper) и Hhook (Helper Hook); Начальная интеграция Khelp/Hhook со стеком TCP.; Модуль Khelp под названием ERTT (Enhanced Round Trip Time) Khelp для TCP-алгоритмов с задержкой; Модулизированные реализации TCP-алгоритмов с потерями: NewReno, CUBIC и HTCP; Модулизированные реализации TCP-алгоритмов на основе задержек: Vegas, “HD” и “CHD”. Технический отчет о сравнительной эффективности работы TCP до и после включения в ядро FreeBSD разработанных каркасов и алгоритма NewReno (http:// caia.swin.edu.au/reports/110228A/CAIA-TR-110228A. pdf). Каждый разработанный алгоритм выполнен в качестве подгружаемого модуля ядра. Алгоритмы могут выбраны исходя из сетевых/программных характеристик и в зависимости от требований данной конкретной хост-машины. Модульный каркас обеспечивает разработчикам гибкость при создании новых алгоритмов, выводя TCP-стек FreeBSD на передний край передовых разработок в этой области, при сохранении зарекомендованной стабильности сетевого стека.

Другие проекты

Кроме проектам по написанию кода, Фонд договорился об неисключительных правах на библиотеку libcxxrt C++ от компании PathScale. Это программное обеспечение является разработкой ABI-интерфейса C++ для платформы Itanium, а сейчас используемого на операционных системах семейства BSD для платформы x86. libcxxrt будет доступна под упрощенной лицензией BSD (2-clause

www.bsdmag.org

BSD license). Эта реализация — полная замена GNUбиблиотеки libsupc++ для платформ, где используется ABI C++ для Itanium, включая платформы i386 и x8664. И заменит части стека C++, которые ранее были доступны только под GPL. Библиотека предоставляет реализации динамических функций C++, включая динамическое приведение, обработка исключений, потоко-безопасные статические инициализаторы. Включение ее в систему продолжит текущий тренд по замене компонент и инструментария GNU на код, лицензируемый под чистыми лицензиями BSD.

Фонду нужна ваша помощь!

Фонд FreeBSD полностью поддерживается за счет пожертвований. И мы благодарны за ту поддержку, что мы получаем от множества частных лиц и организаций, что ценят FreeBSD. К 1-му декабря текущего года Фонд уже собрал 181 тыс. долларов из запланированных 400 тыс. Вы можете помочь нам собрать нужную сумму до конца декабря, сделав свой вклад. Более подробно процесс оплаты описан на странице http://www.freebsdfoundation.org/donate/ Помогая нам в этом деле, вы делаете реальным дальнейшее развитие FreeBSD, покупку требуемого аппаратного обеспечения для поддержания инфраструктуры проекта, а также поддерживаете проведение большего количества конференций, связанных с темой FreeBSD.

Об авторе

Dru Lavigne — автор книг BSD Hacks, The Best of FreeBSD Basics и The Definitive Guide to PC-BSD. В качестве директора по развитию в проекте PC-BSD, она руководит работой команды по документированию, помогает новым пользователям, оказывает содействие в поиске и исправлении ошибок, работает с сообществом для выяснения потребностей. Она бывший редактор журнала Open Source Business Resource — бесплатного ежемесячного издания, посвященному open source и коммерциализации продуктов на его основе. Она также является основателем и председателем совета BSD Certification Group Inc., некоммерческой организации, миссия которой — создание единого стандарта для сертификации системных администраторов BSD систем. Кроме этого, Dru Lavigne является членом совета FreeBSD Foundation [EOF]

В следующем выпуске: • Продолжение серии по безопасности • Высоконагруженные веб-серверы • OSPFv6 • и многое другое!