Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

Зачастую начинающий IT специалист, перед которым впервые встают задачи развёртывания и/или поддержки каких либо сервисов, не знает с чего начать. Испытываемые им трудности - следствие того, что такой специалист еще не введен в соответствующий теме круг понятий. Автор не раз сталкивался с ситуацией, когда отсутствие нескольких грамотных фраз объяснения в начале знакомства с темой выливались в долгое время изучения нужного и не нужного, а процесс изучения темы сильно затягивался

В настоящей обзорной статье автор предложит читателю вводные понятия по части сервисов, с которыми он сталкивался на протяжении своей деятельности в качестве специалиста IT. Статья не претендует на полноту и законченность, но ожидается, что она будет полезна начинающим IT специалистам, планирующим использовать UNIX сервисы в своей работе

Изначально планируется охватить обзором следующие UNIX сервисы - почтовый сервер Sendmail, почтовый сервер Exim, прокси сервер Squid, веб сервер Apache, сетевой фильтр Netfilter, сервер каталогов OpenLDAP, файловый сервер Samba, сервер DNS Bind, сервер DHCP, СУБД MySQL и PostgreeSQL. Возможно статья получит продолжение для каких либо еще сервисов или даже промышленых IT систем - если сложится, то будут реализованы также запланированые введения в Lotus и Oracle

Ожидается, что квалификация читателя будет соответствовать уровню начинающего системного администратора, т.к. такие вещи, как адресация протокола TCP/IP, MAC адреса сетевых карт, начальная установка UNIX/Linux, навыки редактирования конфигурационных файлов UNIX сервисов и т.п. в настоящей статье описывать не планируется. Цель данной статьи не в том, чтобы детально описать конфигурирование сервисов, но в том, чтобы обеспечить начальное вхождение в круг понятий и обозначить отдельные ключевые моменты, важные для понимания функционирования, конфигурирования и поддержки затрагиваемых сервисов. Также в отдельных случаях будут приведены ссылки на заслуживаюшие внимания информационные ресурсы

Обзор ряда других сервисов проведён непосредственно в посвящённых сервисам статьях цикла "UNIX/Linux. Введение в круг понятий"

Почтовые сервера

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

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

В общем случае сервис электронной почты состоит из пары независимых сервисов, один из которых обеспечивает доставку электронной корреспонденции в электронный почтовый ящик адресата, хранящийся на соответствующем сервере (обычно этим занимается Mail Transfer Agent, MTA, обеспечивающий доставку почты адресату по сетевому протоколу SMTP), а другой сервис предоставляет пользователю, а точнее его клиентской программе, доступ к содержимому своего электронного почтового ящика (обычно такой доступ предоставляется по сетевому протоколу IMAP или POP3). В процессе также участвует программа, установленная на компьютере пользователя (либо альтернатива в виде WEB интерфейса), предназначенная для создания электронных писем и их передачи соответствующему сервису SMTP для дальнейшей доставки адресату, а также предоставляющая пользователю доступ к письмам, пришедшим в его серверный почтовый ящик (причем в зависимости от реализации письма могут как выгружаться на компьютер пользователя, так и хранится только на сервере)

Наиболее известными UNIX вариантами MTA являются Sendmail, Exim и Postfix. Все эти сервисы обеспечивают схожую функциональность и за десятилетия зарекомендовали себя как надежные и гибкие продукты, способные работать под серьёзной промышленной нагрузкой. Автор имеет опыт работы с Sendmail и Exim, работавших под нагрузкой в сотню тысяч сообщений в сутки. Также за счет возможности подключения модулей расширения все эти продукты достаточно просто реализуют антивирусную защиту и многоуровневую разноплановую защиту от рекламных рассылок (спама). Выбор конкретного продукта из этих трех может быть обусловлен по большей части какими второстепенными причинами

Продуктами, обеспечивающими доступ к серверному почтовому ящику, в общем случае являются IMAP/POP3 сервера, такие как Dovecot, CyrusIMAP, более простые реализации - pop3d, imapd, а также множество других. Если вы не планируете организовывать публичный почтовый сервис с сотнями тысяч учетных записей, то Dovecot может быть хорошим выбором

Клиентских программ существеут множество, наиболее известными из них являются Thunderbird, Shylpheed, KDEMail, OperaMail, Microsoft Outlook, TheBAT. Все они обеспечивают схожую функциональность, а различия в нюансах помогут подобрать нужное именно вам приложение. Например Thunderbird и OperaMail работают одинаково на UNIX/Linux и MS Windows, что позволяет довольно безболезненно переводить почтовый функционал на UNIX/Linux платформу, Shylpheed является очень "легким" (малотребовательным к ресурсам) приложением, но работает только под UNIX и т.д.

Основой построения корпоративного сервера является именно MTA, поэтому дальше в обзоре мы остановимся на особенностях MTA подробнее

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

Sendmail - старейшина в мире UNIX MTA, наиболее распространенный продукт. Он создавался Эриком Олманом как монолитный почтовый маршрутизатор, имеющий множество вариантов конфигурирования, обработки (переписывания) адресов и множество вариантов подключения транспортных модулей. Это обусловило его реализацию - один бинарник и сложный конфигурационный файл на своем "псевдоязыке", фактически описывающем все правила обработки писем. Сложность конфигурационного "псевдоязыка" - следствие потрясающей гибкости продукта. Гибкости, которая востребована в типовых современных почтовых системах хорошо, если на 10 процентов. Именно вследствии невостребованности реализуемого Sendmail маршрутизационного функционала Exim и Postfix могут создавать ему конкуренцию

Нужно сказать, что сложности конфигурирования Sendmail действительно нетривиален - в конце 90х автор проводил модернизации конфигурации вручную на "псевдоязыке" для целей организации маршрутизационных карт связки UUCP и Sendmail и знает от этом не понаслышке. Но эта сложность сильно сглаживаются наличием предустановленных конфигурационных шаблонов для различных подсистем, компонуемых с помощью отдельной программы - препроцессора m4 и снабженных детальной документацией. Фактическое конфигурирование Sendmail сводится к созданию простого конфигурационного файла из десятка - двух директив препроцессору m4, и последующего получения конечного конфигурационного файла Sendmail запуском простой команды

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

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

Exim - реализация MTA от Мичиганского технологического университета, которая разрабатывалась как замена Sendmail для работы на нагруженных системах. Разработчикам явно удалось создать надежный, наглядно конфигурируемый сервис с большим количеством дополнительных опций конфигурирования, явно нелишних при разработке сложных конфигураций и интеграции с Exim дополнительной функциональности, реализуемой сторонними модулями, СУБД, серверами каталогов и т.п. Отказавшись от излишней для более - менее типового SMTP сервера функциональности, создатели привнесли в свой продукт дополнительную функциональность, востребованную в современных системах, и сумели сделать эту функциональность легко и наглядно конфигурируемой. Также нужно сказать, что Exim обладает детальнейшим пакетом документации, имеется также и неофициальный русский перевод, что может способствовать в выборе именно этого MTA

Конфигурационный файл Exim состоит из нескольких последовательных разделов - общих переменных, раздела конфигурирования списков доступа ACL, раздела конфигурирования маршрутизаторов, раздела конфигурирования транспортных модулей, раздела конфигурирования аутентификации и дополнительных параметров

Раздел общих переменных позволяет настроить значения таймаутов, путей к файлам журналов и опции журналирования, сконфигурировать подключение антивирусных и антиспам пакетов через встроенные коннекторы Exim, а также указать для всех или только части фаз SMTP и не SMTP сессий привязанные к ним списки доступа ACL. Под фазами SMTP сессий понимаются рукопожатие, определение отправителя, получателя/ей, аутентификации, передача заголовков письма, передача тела письма и т.д.

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

Таким образом ACL позволяют реализовать гибкие ограничения входящей корреспонденции, в том числе реализованные подключаемыми модулями сторонней разработки. Например у автора есть антиспам механизм, реализующий модифицированную технологию "серых списков" на СУБД PostgreeSQL и подключаемый в ACL как сторонний модуль

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

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

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

Секция аутентификации и дополнительных параметров позволяет сконфигурировать аутентификационные механизмы под конкретную ситуацию - например, аутентификация через PAM модули или хранение учетных записей в СУБД

В целом Exim является хорошим выбором как для маголо, так и для крупного проекта, если вы не ограничены историческим "наследием" и поднимаете проект с нуля, или имеете задачу перестроить вашу почтовую систему

Postfix - еще один вариант почтового сервиса, разрабатываемом также на замену Sendmail. Здесь во главу угла была положена безопастность системы, реализованная посредством модульной архитектупы и спула почтовых очередей, последовательно обрабатываемых модулями. Фактически передачи данных от модуля к модулю не производится, вместо этого модули принимают письма либо от SMTP коннектора, либо (в большинстве случаев) из файлов почтовой очереди, и после обработки укладывают их другую почтовую очередь либо передают модулям конечной доставки. Управляет всем координирующий модуль Postfix. По замыслу разработчиков такая архитектура должна обеспечить (и обеспечивает) повышенную безопастность, правда, за счет некой громоздкости реализации. Автор слышал, что новая архитектура Sendmail будет походить на архитектуру Postfix как более выигрышную

Опыт автора при работе с Postfix закончился в 2003 году, поэтому привести свежую информацию по этому продукту он не может. Однако последователи хвалят этот продукт. На время знакомства автора с Postfix последний еще не имел некоторых востребованных опций, таких, как встроенная проверка существования отправителя, дополнительные модули подключались не сказать стобы просто - через дополнительные продукты типа Amavis. Этот продукт довольно широко распространен, имеет своих последователей, неплохую архитектуру и претензии на безопасную реализацию. Он не имеет заявленной и доступной автору статистики об использовании на крупных публичных серверах и хостингах (в отличие от Exim и Sendmail), и автор не имеет опыта работы с ним в промышленных решениях под нагрузкой, поэтому отдает этому продукту должное, но не может рекомендовать его для промышленного использования

Что касается POP3/IMAP, то здесь хорошим выбором может являться Dovecot, реализующий различные варианты работы, поддерживающий различные варианты реализации локальных почтовых ящиков, авторизации, поддержку TLS и SSL и т.п. Существуют также очень простые реализации POP3/IMAP серверов, такие, как pop3d и imapd, а также монструозные вароианты типа CyrusIMAP, поддерживающих расширенную функциональность

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

Прокси сервера

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

Фактическим стандартом кэширующего прокси сервера в UNIX является Squid, обеспечивающий различные варианты авторизации пользователей, сбор деталнейшей статистики, кэширование контента, возможности гибкой настройки полосы пропускания для отдельных пользователей и целых групп, создание многоуровневой иерархии прокси серверов и многое другое. До недавнего времени узким местом этого прокси сервера была нереализованная штатно антивирусная защита, конфигурируемая сторонними решениями типа включения в цепочку прокси havp или или использования специально написанных редиректоров с предварительной проверкой контента, однако с выходом версии 3.0, поддерживающей стандартный ICAP интерфейс ситуация должна измениться в лучшую сторону

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

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

Для того, чтобы разрешить вашей локальной сети ходить в Интернет через ваш прокси сервер вам потребуется создать в конфигурационном файле новый список доступа, в который вы можете включить отдельные ip адреса или всю вашу локальную подсеть, разрешить использовать прокси сервер клиентам, попадающим в этот список и перегрузить конфигурацию сервера (либо остановить и стартовать прокси сервер, либо сказать kill -HUP id_процесса_squid). В этом случае браузеры на компьютерах вашей локальной сети смогут обращаться к прокси серверу и получать от него запрошенный контент. Это может быть тем, что вы хотите, а может и не быть. Возможно вы хотите разрешить доступ не любому пользователю, имеющему физический доступ к компьютерам вашей локальной сети, но только определенной группе, или же хотите по разному сконфигурировать предоставление доступа разным группам пользователей, или же вам необходимо собирать статистику не по ip адресам, а по реальным физическим лицам. В этом случае вам потребуется настроить авторизацию по имени пользователя и паролю, для чего вы можете выбрать одну из поддерживаемых прокси сервером SQUID схем авторизации и добавить соответствующие опции в ваш конфигурационный файл. Например, можно сконфигурировать авторизацию через MSActiveDirectory, или через выделенный список учетных записей, или через учетные записи пользователей UNIX на сервере или в вашем каталоге LDAP. Эти варианты конфигурации описаны многими статьями, доступными в Интернет, в том числе на русском языке

Т.к. канал в Интернет обычно не бесконечно быстрый, часто встает задача обеспечить доступ в Интернет разным группам сотрудников с разным приоритетом и допустимой скоростью. В SQUID встроена функциональность "дырявых вёдер" (официально опция называется пулы задержки - delay-pools). Эта опция позволяет гибко и эффективно настраивать ширину канала как отдельному пользователю, так и группам пользователей. Логика работы этого механизма в том, что отдельные пользователи и/или группы пользователей выделяются в отдельные именованные списки доступа (ACL), и этим именованым ACL назначаются свои "дырявые ведра". Понятие ведро включает в себя объём ведра (в байтах) и величину отверстия в дне (в байтах в единицу времени). До тех пор, пока запросы пользователя или всей группы не превысят объем ведра (в байтах), ответы отдаются пользователю или группе без какой либо задержки. Но стоит суммарно полученным для пользователя ответам из Интернет сравняться с объемом "дырявого ведра", ответы начинают отдаваться пользователю на ограниченной скорости, равной величине отверстия в дне (в байтах в единицу времени). Грамотно группируя пользователей в отдельные ACL и настраивая им параметры "дырявого ведра", можно довольно эффективно разграничивать ширину канала для разных видов запросов. Например объём дырявого ведра в 100 килобайт вполне подходит для скачивания обычного Интернет контента пользователями без ограничений, т.к. отдельно запрашиваемые страницы и картинки обычно не превышают этого размера и отдаются на максимальной скорости, но при попытке качать что то действительно большое, например фильм, ограничение в 100 килобайт исчерпывается очень быстро и вступает в действие "величина отверстия в дне", т.е. ограничение в ширине канала, которое можно выставить, скажем, в 2 Кб/сек, что не запретит пользователю скачивать фильм, но позволит другим пользователям эффективно использовать большую часть ширины канала для нормальной работы

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

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

Веб сервер Apache

WEB сервер Apache является мировым лидером среди WEB серверов по результатам различных исследований. Он предоставляет разнообразнейший функционал, возможности гибкого конфигурирования, создания множества виртуальных сайтов на одной физической машине, различные методы авторизации, организации интерактивных интерфейсов (CGI и т.п.), SSL шифрование и многое, многое другое

В общем случае Apache слушает указанные адреса и порты и, при обращении на них по протоколу HTTP (например из пользовательского браузера) возвращает содержимое соответствующих html страниц, либо хранящихся на сервере в виде файлов, либо формируемых динамически на основании поступивших запросов. Перед отдачей клиенту данные проходят мо многочисленным промежуточным модулям - фильтрам, конфигурируемым под конкретные задачи и проводящим дополнительную обработку отдаваемых данных

Очень удобной является возможность динамически формировать данные ответов, используя спецификации CGI или PHP включения. Эта технология позволяет создавать надежные качественные решения, в т.ч. пользовательские интерфейсы к данным СУБД. Причем такие решения могут быть относительно низкобюджетными и не требовать установки специальной клинетской части (так называемый тонкий клиент). Однако это отдельная большая тема, которая не будет обсуждаться здесь детально

И если вы приобретаете готовый функциональный сайт, и если создаете его сами, в какой то мере владея навыками создания WEB сайтов, вы найдете UNIX и Apache идеальной платформой для его размещения и последующего наращивания функционала и масштабируемости

Сетевой фильтр Netfilter

Сетевой фильтр (файервол) - механизм, позволяющий запретить или разрешить прохождение определенных видов траффика через железку, на которой он установлен. Это типовое техническое решения является одним из ключевых механизмов защиты от несанкционированного вторжения в локальную сеть. В случае Linux встроенный в ядро сетевой фильтр называется Netfilter. Он управляется утилитой под названием iptables и имеет очень широкую функциональность. Кроме непосредственно фильтрации траффика по заданным разнообразным условиям от обеспечивает сетевую трансляцию в разных вариантах, маркировку траффики, переписывание адресов, механизмы сбора статистики о проходящем траффике, механизмы отбора пакетов по заданным условиям и многое другое

Основой работы с сетевым фильтром являются понятия о протоколах стэка TCP/IP, ip и MAC адресах, портах, сетевой адресации и маршрутизации, и т.п. Знакомство с этими понятиями является следствием понимания стэка TCP/IP, и предполагается, что читатель знаком с этими понятиями. Если это не так, читать обзорный раздел по сетевому фильтру Netfilter бессмысленно, и читателю предлагается для начала познакомиться с TCP/IP, обратившись к поиску в Интренет. Ресурсы по этой теме, в том числе русскоязычные, есть

Траффик, проходящий через сетевой фильтр, обрабатывается по правилам, конфигурируемым утилитой iptables и хранящимся в таблицах правил до выключения компьютера. Таблицы правил сгруппированы в иерархии mangle, nat и filter и правила выбираются из таблиц в последовательности расположения иерархий. Существуют предустановленные таблицы, например для INPUT, OUTPUT и FORWARD для иерархии filter, которые отвечают за фильтрацию соответственно входящего в хост траффика, исходящего и транзитного (маршрутизируемого). Для иерархии nat предустановленными таблицами правил являются PREROUTING, POSTROUTING и OUTPUT, отвечающие за переписывание адресов входящего маршрутизируемого траффика, исходящего маршрутизируемого ртраффика и локально генерируемого исходящего траффика соответственно. Кроме того, администратор может создать свои таблицы, для более наглядной группировки правил, и предусмотреть правило в одной из предустановленных таблиц для перенаправления определенного вида траффика во вновь созданную таблицу. Типичным примером может являться выделение интересующей администратора группы адресов для обработки траффика с учетом портов по единым правилам для исключения дублирования правил и упрощения конфигурации. Таким образом существование иерархически расположенных групп таблиц, связанных с определенными видами траффика, и содержащих последовательно обрабатываемые конфигурационные правила сетевого фильтра, а также доступные виды правил - это ключевые понятия темы устройства сетевого фильтра

Правила в таблицах могут содержать модификаторы, определяюще подмножество обрабатываемого каждым конкретным правилом траффика, а также содержат целевое действие для траффика, разрешенного к обработке данным правилом, например - разрешить прохождение пакетов (-j ACCEPT), запретить (-j DROP), переписать адрес определенным образом (-j DNAT, -j SNAM, -j MASQUERADE), отразить статистику по пакету (-j LOG, -j ULOG), передать для дальнейшей обработки в выбранную именованную таблицу правил (-j имя_таблицы) и т.д.

Если иерархия filter предназначена для фильтрации траффика, то иерархия nat предназначена для реализации механизмов распространенного механизма сетевой трансляции - переписывания адресов отправителя или получателя. Этит механизм позволяет спрятать за одним реальным IP адресом, выданным вашей организации, целую локальную сеть, разрешив обращение с компьютеров локальной сети в Интернет или же, наоборот, пробросить приходящий на ваш сервер запрос, например из Интернета, на какой нибудь сервер внутри локальной сети (например, выделенный почтовый или WEB сервер). Таблицы оставшейся иерархии mangle крайне редко используются в типовых задачах практического сетевого администрирования и рассматриваться здесь не будут

Создатели сетевого фильтра netfilter предлагают документацию, детально расписывающую логику работы и предоставляющую примеры конфигурирования. Существует также русскоязычный перевод, который однозначно рекомендуется к прочтению для понимания сути работы, расположен он по адресу http://www.opennet.ru/docs/RUS/iptables/. Также в Ннтернет доступно множество материалов, в том числе русскоязычных, по решению отдельных задач на netfilter

Еще можно добавить, что в netfilter встроено несколько методов сбора отчетности о проходящем траффике, в том числе поставляемый разработчиками Netfilter модуль ulogd, доступный по адресу http://www.netfilter.org и позволяющего собирать требуемую статистическую информацию и сохранять ее в различных хранилищах, например в файлах файловой системы, в таблицах нескольких распространенных OpenSource СУБД и т.п. По мнению автора метод сбора статистики от разработчика с использованием СУБД является предпочтительным, а практический опыт подтверждает высокую гибкость конфигурирования и удобство обработки собираемой статистики

Сервер каталогов OpenLDAP

Базовые понятия сервера каталогов LDAP несколько обособлены от других UNIX сервисов, что обуславливает сложность начального вхождения в тему. В общем случае каталог - это централизованное хранилище данных, доступных многим клиентам. Хороший пример таких данный - учетные записи пользователей или групп, каждая из которых является фактически объектом с набором атрибутов-значений. Например учетная запись пользователя может содержать отдельные атрибуты для храниния логина, имени, фамилии, домашнего каталога, командной оболочки и т.д. Каталог можно воспринимать как разновидность нереляционной базы данных, в которой объекты различных типов хранятся в виде иерархического дерева

Сервер OpenLDAP при загрузке загружает файлы схем, содержащие описания именованых атрибутов с указанием типа из предустановленного перечня, а также содерхащих описание классов - именованых групп из части описанных ранее атрибутов. Фактически каждый класс может быть объявлен как образующий (SUB) или вспомогательный (AUX), а атрибуты могут быть объявлены обязательными либо необязательными, а также многострочными или однострочными. Атрибуты и классы - базовые понятия о хранении информации в объектах каталога

Еще одним важным понятием является собственно иерархия объектов, наиболее часто реализуемая в OpenLDAP последовательностью атрибутов типа directory component (dc), organization (o) и organization unit (ou). Из этих элементов обычно формируется корневое имя каталога, а также формируюется последующая иерархия каталога. Наиболее часто используются схемы построения иерархии по DNS имени, или же по имени организации и подразделений. Примером первого варианта может служить корневое имя dc=ourorbits,dc=org и контейнер для учетных записей пользователей ou=People,dc=ourorbits,dc=org. Примером второго варианта является корневое имя o=mycompany и иерархический контейнер ou=it,o=mycompany

Получив данные о поддерживаемых атрибутах и классах из файлов схем, а также данные о разграничении доступа, корневом имени каталога и методе хранения данных, сервер OpenLDAP готов принимать запросы на создание объектов, а также запросы на выборку данных об объектах из каталога. Наполнение каталога происходит методом отправки запросов на создание объектов, содержащих подмножество описанных в файлах схем образующих и, возможно, вспомогательных классов, и, в том числе, значений всех или некоторых атрибутов этих классов. Запросы могут описываться в обычных текстовых файлах по описанному в документации синтаксису и скармливаться идущим в составе сервера OpenLDAP утилитам ladpadd, ldapmodify, ldapsearch и другим

Каждый объект в каталоге определяется уникальным именем (distinguished name - DN), состоящим из последовательно расположенных идентифицирующего атрибута объекта (обычно это обязательный атрибут образующего (SUB) класса объекта, его называют также относительным уникальным именем, relative distinguished name, RDN), иерархического пути от корня и корневого имени каталога. Для того, чтобы объект с неким DN мог располагаться не в корне, а в глубине сформированной иерархии, должны быть созданы отдельные объекты со своими RDN, формирующими такую иерархию своим существованием. Примером может служить уникальное имя учетной записи пользователя uid=zerot,ou=People,dc=ourorbits,dc=org, где uid - обязательный атрибут образующего (SUB) класса объекта, ou=People - иерархический путь от корневого имени, существующий в силу предварительного создания объекта Organizational Unit с RDN атрибутом ou=People, а dc=ourorbits,dc=org - корневое имя каталога. Уникальное имя и иерархия - также основные понятия

Здесь важно понимать, что иерархия формируемся из атрибутов, описанных в файлах схем, путем простого последовательного (от корневого имени) создания в каталоге объектов, содержащих классы с соответствующими атрибутами, выбранными в качестве RDN. Формально DN описавается как последовательность разделенных запятой пар имя_атрибута=значение, отсортированных СПРАВА НАЛЕВО от корня через ветви (иерархию) к идентифицирующему атрибуту конкретного объекта. В общем случае также нужно помимать, что выбор RDN атрибута может быть достаточно произвольным. Например, автор успешно строил и эксплуатировал каталоги, у которых в качестве RDN для учетных записей групп использовались как атрибут common name (cn, используется по умолчанию), так и атрибут gid, в то же время для учетных записей пользователей использовался атрибут uid (по умолчанию) или common name (cn)

Атрибуты созданных объектов могут модифицироваться запросами на модификацию, а запросы на выборку позволяют при наличии соответствующих полномочий получить значения атрибутов для запрошенных объектов. Именно эту функциональность реализуют иерархические каталоги E-Directory от Novell, Active Directory от Microsoft, Oracle Internet Directory от Oracle и другие, являющиеся по сути каталогами LDAP с дополнительным функционалом

В заключение можно сказать, что в настоящее время в Интернет появилось много русскоязычной информации по посторению каталога LDAP и настройке OpenLDAP в частности

Файловый (и не только) сервер Samba

Это один из самых больших и значимых проектов сообщества, реализующий функциональность файлового сервера, сервера печати и контроллера домена Windows NT4, что позволяет выстраивать серверную часть сетевой инфраструктуры на UNIX/Linux вместо продуктов MSWindows. Кроме этого Samba реализует функционал клиента, что позволяет подключать UNIX/Linux машины к файловым серверам MS Windows. В результате появляется возможность строить смешанные сети. Классическим примером является построение серверной инфраструктуры целиком на UNIX/Linux, а части клиентских рабочих мест на MS Windows, например, по причинам привязки к разработанному исключительно для Windows клиентскому ПО. Еще одной реализованной возможностью является возможность построения авторизации всех UNIX и Windows клиентов из единого источника, которым могут быть как многочисленные реализации хранилища учетных записей в UNIX (например в файлах, в каталоге LDAP, на сервере Kerberos и т.д.), так и хранилища MS Windows - каталог контроллера Windows NT4 или Active Directory. Новая активно разрабатываемая версия Samba v.4 претендует на полную реализацию функционала контроллера домена на Active Directory

В Интернет существует действительно много документации по конфигурированию и использованию Samba версий 2 и 3, в том числе и русскоязычной. Однако некоторые вводные момнеты стоит отметить особо. Фактически стартующий сервер Samba v.3.x подхватывает из конфигурационного файла информацию о том, какие каталоги UNIX и с какими правами требуется отдать в сеть и нужно ли предоставлять также доступ к принтерам. Многочисленные конфигурационные опции (их более ста) позволяют настроить множество параметров, в том числе параметры храниния учетных записей, авторизации, переписывания прав, имен владельцев и групп, используемые кодировки и многое другое

Для каждого разделяемого каталога можно настроить дополнительные параметры, такие, как аудит деятельности пользователей, автоматическая антивирусная проверка, удобная сетевая "корзина", предустановленные маски создания файлов и каталогов и многие другие надстройки. Относительным минусом является довольно громоздкая реализация различных прав на отдельные подкаталоги внутри одного разделяемого каталога, реализуемая расширенными атрибутами доступа файловой системы UNIХ (например, ext3). Это вполне типовая задача для крупного бизнеса является экзотической для малого и среднего бизнеса, но она решаема

В целом это очень удачный, гибкий и надежный продукт, с успехом заменяющий файловые сервера, построенные на основе Novell Netware и Microsoft Windows. Одна из успешных историй перевода промышленных файловых серверов на Samba отражает реальный опыт автора и доступна по адресу http://www.ourorbits.org/itview/articles/nwtolinux.shtml

СУБД PostgreeSQL (аналог Oracle SE)

Реляционные СУБД - это отдельное направление в IT. Методы хранения и обработки данных повсеместно реализуются комплексными решениями - реляционными системами управления базами данных, постоянно совершенствуемыми для достижения большего быстродействия, скорости отклика, количества одновременных обращений и т.п. Современные СУБД - сложные технические решения, требующие наличия специальных занинй, но дающих взамен большую гибкость в работе с разнообразными данными

Бессменным лидером сегмента является корпорация Oracle с одноименной БД

Обзор ряда других сервисов проведён непосредственно в посвящённых сервисам статьях цикла "UNIX/Linux. Введение в круг понятий"