Архив метки: freebsd

IPFW: Изменение правила по умолчанию без пересборки ядра

Правило по умолчанию: «запретить все, что не разрешено»:

65535 deny ip from any to any

За поведение по умолчанию отвечает системная переменная net.inet.ip.fw.default_to_accept

0 — запретить все
1 — разрешить все

Изменить переменную на лету нельзя, но можно установить ее значение в файле /boot/loader.conf

root@srv: # cat /boot/loader.conf
# SET DEFAULT IPFW’S RULE TO «ALLOW ANY TO ANY»:
net.inet.ip.fw.default_to_accept=1

Потребуется перезагрузка для применения изменений.

FreeBSD: Работа с коллекцией портов

http://pro-voip.com.ua freebsd

Скачать и распаковать коллекцию портов (утилита portsnap):

portsnap fetch extract

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

1. Обновить коллекцию портов:

portsnap fetch update

2. Найти нужный порт:

cd /usr/ports
make search name=rkhunter

3. Установить нужный порт:

cd /usr/ports/security/rkhunter
make install clean

 

Вся коллекция портов находится в /usr/ports. Все приложения, описаные в коллекции портов, сгруппированы в категории (databases, deskutils, net-mgmt и т.д.).

 

Поиск

Поиск необходимого порта по имени (ищет совпадения в названии порта). Команда выполняется в директории /usr/ports:

make search name=rkhunter

Поиск порта по описанию (ищет совпадения и в названии и в описании порта, полезно, если не помнишь, как приложение называется, но помнишь хоть примерно, что оно должно делать или с чем оно связано). Команда выполняется в директории /usr/ports:

make search key=hunter

 

Описание порта

Пример, порт /usr/ports/security/rkhunter

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

  • Makefile — содержит базовые команды и настройки для сборки порта. Здесь же и указывается (в переменной MASTER_SITES=), откуда скачивать исходники (src) приложения . Исходники приложения представляют собой сжатый архив с необходимыми src-файлами для сборки и установки.
  • distinfo — содержит контрольные суммы для файлов, которые скачиваются при сборке порта. Таким образом производится проверка на целосность.
  • files — директория содержит дополнительные патчи и исправления, которые в ходе сборки приложения накладываются на разархивированные исходники.
  • pkg-descr — описание приложения
  • pkg-message — содержит сообщения, адресованое от разработчиков администратору. В нем может указываться поздравление с установкой, необходмые дальнейшие шаги после установки, рекомендации и т.д. Файл pkg-message необязателен.
  • pkg-plist — перечень файлов, которые плодит устанавливает порт в системе.
  • В процессе сборки в директории порта создается рабочая директория work.

 

Описание процесса установки приложения с порта

  1. Конфигурирование опций порта
  2. Загрузка архива с исходными файлами приложения
  3. Проверка загруженых файлов на наличие ошибок
  4. Извлечение исходных файлов с архива в рабочую директорию
  5. Наложение патчей с директории files, если такое имеются и необходимы
  6. Проверка и установка зависимостей
  7. Запуск сценария configure, если такой есть в приложении
  8. Сборка приложения из исходных файлов
  9. Установка приложения (копирование скомпилированных бинарников, файлов конфигурации и т.п. в необходимые места в файловой системе — а что это за файлы и в какие необходимые места, описано в  pkg-plist)
  10. Регистрация приложения в /var/db/pkg — да, у нас получился обыкновенный пекедж.

 

Другие команды

Команды выполняются в директории порта. «make install clean» запускает поочередно цикл команд, которые проводят через все этапы установки приложения, описаные выше. При необходимости можете запускать эти команды вручную. Например, если вам нужно только собрать, но не устанавливать приложение, используем «make build«, который выполнит с 1 по 8-й пункты (см. описание процесса выше). Если нужно только скачать исходники, используем «make fetch«.

make config
— конфигурирование порта — если есть опциональные параметры, или дополнительные модули, здесь их можно включить/исключить.

make config-recursive
— конфигурирование порта и его зависимостей. Процесс сборки бывает длительным, и зависимостей бывает много. Для того чтобы перед установкой зависимостей каждый раз процесс не прерывался и не ждал от вас решения установить те или иные параметры для зависимостей, хорошо сразу все сконфигурить и оставить приложение собираться в одиночку.

make showconfig
— посмотреть, какие параметры выбраны.

make rmconfig
— удалить выставленные пользователем параметры, т.е. сбросить конфиг в дефолт — отмеченные изначально останутся отмечеными, отмеченные пользователем — удаляются.

make fetch
— загрузка архива с исходниками.

make fetch-recursive
— загрузка архивов с исходниками порта и зависимостей.

Откуда загрузка? — указано в Makefile в переменной MASTER_SITES=. Путей может быть несколько.
Куда загружаются исходники? — в /usr/ports/distfiles

make checksum
— проверка целосности скачаного архива с исходными файлами приложения

make extract
— извлечение скачаного архива — директории порта создается рабочий каталог work, куда и извлекаются исходники.

make patch
наложение или накладывание? Применение патчей с директории files.

make depends
— проверка зависимостей.

make configure
— если в приложении есть свой сценарий configure, он выполняется

make build
— компиляция кода.

make install
— установка приложения и регистрация его в /var/db/pkg.

make clean
— удаление рабочей директории work (архив с исходниками остается в /usr/ports/distfiles).

make distclean
— удалить архив с исходниками.

 

Источники информации

https://www.freebsd.org/doc/handbook/ports-using.html
http://freebsdguide.ru/_11/_6/

Portsnap: Обновление дерева портов FreeBSD

http://pro-voip.com.ua freebsd

portsnap — штатная утилита для обновления дерева портов в FreeBSD. Подчеркну еще раз — дерева портов, а не программ, которые были установлены с этого самого дерева. Дерево портов представляет собой набор каталогов с файлами в директории /usr/ports, уже из которых собирается и компилируется необходимое ПО. Вот portsnap как раз и занимается обновлением вот этих самых файлов.

Обновление дерева портов предшествует обновлению самой установленной программы. Т.е. если нужно обновить, например, mysql-server, то сначала обновляем дерево портов, а затем из этого дерева, обновленного, устанавливаем/переустанавливаем программу (port). Для этих целей я использую утилиту portupgrade.

Файлы и директории

  • Файл конфигурации — /etc/portsnap.conf
  • Рабочая директория — /var/db/portsnap/
  • Дерево портов — /usr/ports/

Процесс обновления

Скачиваем snapshot («снимок», сжатую копию) дерева портов. Snapshot скачивается в рабочую директорию /var/db/portsnap:
portsnap fetch

Распаковываем дерево портов — берется snapshot (по сути это набор сжатых файлов) из директории /var/db/portsnap и разворачиваем в /usr/ports:
portsnap extract

! данная команда сначала трет все старое дерево, если оно есть, а потом разворачивает новое. Это занимает определенное время, поэтому именно для обновления портов extract не используется. extract используется чаще всего при установке свежей системы.

Для обновления дерева портов используется следующая команда:
portsnap update

update, в отличие от extract, не удаляет все дерево портов, а только вносит в него необходимые изменения.

Автоматизация

Чтобы дерево портов обновлялось без вашего активного участия в этом, задействуем cron. В этом случае в /etc/crontab вместо portsnap fetch, нужно прописывать команду portsnap cron — делает она то же самое (скачивает снепшот с серверов) — но с случайной задержкой из диапазона 1 — 3600 сек.

«portsnap fetch в cron’е не работает» — мною это утверждение не проверялось, поверим на слово

portsnap update рекомендуют запускать с ключем -I — т.е. не обновлять само дерево, а обновить только индекс. Для чего? Чтобы избежать вполне возможной ситуации, когда portsnap при обновлении удаляет/изменяет исходные файлы порта, а в этот же момент кто-то собирает из этих файлов порт.

 

Monitord: Автоматический перезапуск демона

freebsd2В мире постоянно работающих систем с «слушающими» отзывчивыми демонами, бывает, случается неприятность — в силу каких-либо причин демон перестает быть отзывчивым и прекращает свою работу. В итоге получаем неработающий сервис. Неприятность может застать нас в любое время и в любом месте. И даже если предусмотрительно настроенная нами система мониторинга шлет  об этом тревожные письма и смс, побуждая к вполне закономерным действиям — сделать сервису start и разбираться, что случилось, — не всегда есть для того возможности. Банально, может не быть никаких «электронно-вычислительных машин» под рукой.

Делаем выводы с вышесказанного и решаем, что нужно «что-то», что будет следить за демонами и стартовать их автоматически, если те прикажут долго жить*. Кто-то для таких целей пишет свой скрипт и кидает его в cron, кто-то пользуется готовыми решениями, настраивая их под себя. Одним из таких решений и есть monitord — не самое лучшее, корявое, но, на мой взгляд, самое простое и лично мне подходящее.

 

Установка

На текущую дату — 07.04.2015 — порт monitord помечен как Broken:

Игнорируем этот факт и все-таки устанавливаем порт (запускаем make с ключом -D, устанавливая переменную NO_IGNORE):

 

После установки в системе появляются 3 файла:

  • /usr/local/etc/rc.d/monitord — стартовый скрипт;
  • /usr/local/sbin/monitord — бинарник;
  • /usr/local/etc/monitord.conf.sample — пример конфигурационного файла.

 

Структура конфигурационного файла

/usr/local/etc/monitord.conf.sample:

 

Одна строка в conf-файле отвечает за один сервис, и поделена на 6 столбцов:

  • user — от имени какого пользователя производить запуск;
  • options — как реагировать, если сервис потух:

auto —  запускать сервис автоматически;
alert — отсылать письмо на почту об инциденте (здесь у меня возникли проблемы, ниже опишу какие);
noauto — не запускать сервис автоматически (имеет смысл при указании этой опции вместе с опцией alert — т.е. просто для уведомлений);

опции указываются через запятую, пробелы между ними не ставим.

  • delay — задержка запуска (секунды);
  • service — имя сервиса;
  • script — скрипт запуска сервиса;
  • parameters — аргументы, передаваемые скрипту запуска.

 

Настройка и запуск

Создаем или копируем с monitord.conf.sample конфигурацинный файл monitord.conf:

Например, для мониторинга apache24, по образу и подобию добавляем строку:

Добавляем monitord в автозагрузку и запускаем:

 

Проблемы с отправкой уведомлений

При использовании опции alert необходимо предварительно указать, через что эти алерты слать. Monitord предлагает указать только email получателя и MTA, который доставит alert-письмо этому получателю:

К сожалению, править какие-то другие заголовки для отправки уведомлений нельзя. И если уже с неменяемой темой и телом пиcьма смириться можно, то критично важно было бы отредактировать адрес отправителя, потому как сам Monitord туда подставляет следующее:

monitord-notification@www, где www — это у меня имя хоста.

А мой МТА настроен на проверку адреса-отправителя и получив от monitord такое вот письмо, отказывается его дальше передавать:

sender verify fail for <monitord-notification@www>: Unrouteable address

Лично для меня это не критично, поскольку уведомлениями занимается нагиос. Alert’ы я отключаю и пользуюсь только возможностью слежки за демонами и их автоматического старта/рестарта.

SSMTP: Отправка отчетов, логов и уведомлений из FreeBSD

http://pro-voip.com.ua freebsdКогда нужно научить свой сервер отправлять почту…

Вообще-то, FreeBSD в своей базовой комплектации, если можно так выразится, имеет на борту полноценный почтовый сервер — sendmail. Предполагалось, что этим почтовиком будет пользоваться как сама операционная система, уведомляя своего администратора о результатах тестов и проверок, так и рядовые пользователи для повседневного общения. В этом случае настройка и запуск sendmail’а оправдана, если ваш сервер у вас именно «почтовый» (как минимум, обслуживает пользователей компании, например) и, что немаловажно, sendmail вы настраивать умеете.

Для «непочтового» сервера на FreeBSD, выполняющего другие задачи (например, запущен какой-нибудь web-сервер ) тратить время и разбираться в sendmail’е, когда нужны только отчеты системы, считаю нецелесообразно. (Для меня sendmail вообще темный лес и мне туда лезть страшно).

В таком случае на помощь приходит sSMTP. Это некий эмулятор sendmail’а, с помощью которого можно _только отправлять_ почту через удаленный «полноценный почтовый сервер».

Установка

Ставим с портов:

После окончания установки видим следующее сообщение — руководство к дальнейшим действиям:

Настройка

Следуем рекомендации…

1. Вместо дефолтного sendmail’а прописываем ssmtp в /etc/mail/mailer.conf:

2. Редактируем конфигурационный файл /usr/local/etc/ssmtp/ssmtp.conf:

Кто получает почту для userids < 1000 (т.е. от всех системный пользователей):
root=admin@provoip.in.ua

Через какой MTA отправлять почту (МТА здесь полноценный сервер, который реально занимается доставкой почты пользователю — ищет MX запись домена, отправляет, следит за доставкой, возвращает письмо отправителю при невозможности доставки):
mailhub=mail.pro-voip.com.ua

Можно указать порт (по умолчанию 25), например:
mailhub=mail.your.domain:2525

С какого домена будет отправлена почта:
rewriteDomain=provoip.in.ua

Полное имя хоста:
hostname=server.provoip.in.ua

Не перезаписывать заголовок From при отправке, если он явно задан (если будет указано значение «NO», в заголовке From отобразится реальный пользователь, от имени которого отсылается письмо):
FromLineOverride=YES

Другие возможности:

Использовать SSL/TLS для отправки сообщений на сервер:
UseTLS=YES

Использовать SSL/TLS сертификат to authenticate against smtp host.
UseTLSCert=YES

Использрвать этот RSA сертификат:
TLSCert=/usr/local/etc/ssmtp/ssmtp.pem

Debug

Если возникли проблемы с отправкой письма и нужно посмотреть детально, как происходит общение между ssmtp и удаленным почтовым сервером, следующей опцией можно включить debug отправки письма:

Здесь следует обратить внимание на расположение данной опции в файле конфига /usr/local/etc/ssmtp/ssmtp.conf:

  • если ее поставить в конце файла — получим в логах (/var/log/maillog) подробный вывод smtp-сесси:
  • если ее поставить в начале файла — кроме вывода smtp-сессии получим вывод парсинга по конфигу ssmtp.conf:
  • если поставить где-нибудь в середине, то процесс парсинга в логах увидим начиная с опции, которая идет за «Debug=YES».
Отправка от определенного пользователя в системе

Допустим, в системе есть пользователь user123, у которого есть почтовый ящик user123@example.com. Чтобы пользователь смог отправлять письма со своего ящика через сервер mail.pro-voip.com.ua,  отредактируем файл алиасов /usr/local/etc/ssmtp/revaliases:

— смотрим строку вконце.

Если файла revaliases, его можно создать самим 🙂 или переименовать revaliases.sample в revaliases.

Отправка сообщения от пользователя user123 с консоли будет выглядеть примерно следующим образом:

# mail -s «This is mail» -u user123 user777@gmail.com < /dev/null

FreeBSD: Custom kernel — Создаем «свое» ядро

 

1. Наличие исходников

Перед тем как создавать свое ядро, необходимо загрузить исходники системы, например, с помощью subversion. Или же загрузить исходники при установке… В общем, неважно как, но они должы появиться у вас в системе.

Проверяем директорию /usr/src — если она пустая, то исходников нет (если, конечно, вы их не переместили куда-нибудь).

В /usr/src/sys находятся поддиректории с названиями поддерживаемых системой архитектур — amd64, i386,powerpc и др. Все, что находится в определенной поддиректории, относится только к определенной архитектуре. В каждой такой поддиректории находится поддиректория conf, которая содержит GENERIC конфигурацию ядра для этой архитектуры.

 

2. Файл конфигурации ядра

 

— Если нужно урезать конфигурацию ядра:

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

 

— Если нужно расширить конфигурацию ядра:

Можно также скопировать GENERIC в свой файл и дописать нужные опции, а можно поступить следующим образом:

создать  свой файл конфигурациии ядра — например, PROVOIP — там указать только дополнительные опции и подключить к нему  файл GENERIC с помощью директивы include.

/usr/src/sys/amd64/conf/PROVOIP

 

3. Сборка и установка Custom kernel

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

Устанавливаем тоже с указанием конфигурационного файла ядра:

-эта команда скопирует новое ядро в /boot/kernel/kernel, а старое сохранит в /boot/kernel.old/kernel.

Перезагружаемся и загружаемся с новым ядром.

EXIM: Установка и настройка. Файл configure

Установка

Устанавливаем exim  с поддержкой mysql:

Добавляем в автозапуск:

Настройка

Пример конфигурационного файла exim — он называется configure — находится здесь: /usr/local/etc/exim/:

Конфигурационный файл configure логически поделен на секции:

  • Main configuration settings
  • Acl configuration
  • Routers configuration
  • Transports configuration
  • Retry configuration
  • Rewrite configuration
  • Authentication configuration
  • Configuration local_scan()

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

 


— Main configuration settings

Полное имя хоста FQDN:

primary_hostname = mail.pro-voip.com.ua

Создание 2-х списков доменов и 1 списка хостов, эти списки могут быть использованы далее в конфигурации при использовании, например, списков доступа acl:

domainlist local_domains = @
domainlist relay_to_domains =
hostlist   relay_from_hosts = localhost

domainlist local_domains = my.first.domain : my.second.domain — список локальных доменов
можно указать, как в примере, знаком @ — что будет означать “имя локального хоста” — т.е. то. что указано в primary_hostname или определено автоматически
если не собираетесь производить локальные доставки (local delivery) можно @ удалить.

domainlist relay_to_domains = — список доменов, для которых наш хост — incoming relay

hostlist   relay_from_hosts = — список хостов, для которых наш хост является исходящим рилеем, т.е. хосты из этого списка могут отправлять почту на другие хосты в инернете. Обязательно указываем localhost, чтобы наш хост смог отправлять почту, используя loopback интерфейс.


Почтовый сервер у меня будет управляться через панель Postfixadmin. Для exim’а это будет выглядеть как подключение к mysql базе postfix для извлечения оттуда полезных exim’у данных. Связка exim -> mysql (db postfix) -> postfixadmin.

— указываем хост, базу, логин и пароль для подключения; поскольку пароль указывается в открытом виде, перед опцией  mysql_servers устанавливаем настройку «hide», чтобы предотвратить его появление при выводе всех опций конфигурирования (команда exim -bP).

Теперь списки доменов я безу из базы postfixadmin  и мне не нужно каждый раз вручную править файл configure:


Следующие 2 опции:

acl_smtp_rcpt = acl_check_rcpt
acl_smtp_data = acl_check_data

определяют  Access Control Lists (ACLs) — списки контроля доступа; Списки, перечисленые в acl_smtp_rcpt проверяют получателя при входящем SMTP-коннекте(команда RCPT); если не сконфигурировать эту проверку, smtp-почта приниматься не будет. Списки в acl_smtp_data проверяют контент в сообщении. Сами списки будут описаны ниже в секции «ACL configuration».

Подключение антивируса ClamAV. Если exim собран с content-scanning расширением, мы можем проверять входящую почту на вирусы. Модификации нужно произвести в двух местах- здесь:

av_scanner = clamd:/var/run/clamav/clamd.sock

и в acl_check_data.

Порты, которые слушает exim:

daemon_smtp_ports = 25 : 587

— 25- стандартный smtp, 587 — «message submission»

Здесь указываем домен, который добавляется к неполным адресам:

qualify_domain = pro-voip.com.ua

— неполный адрес — тот, который не содержит часть «@domain_name». Например, «admin@provoip.com.ua» — полностью определенный адрес, а просто «admin» — логин — неполный адрес. По дефолту неполные адреса принимаются только от локальных пользователей, но это можно изменить опцией recipient_unqualified_hosts.

Пользователи exim:

exim_user = mailnull
exim_group = mail
never_users = root

never_users — это список пользователей, которым никогда не будет доставлена почта. Указывается параметром FIXED_NEVER_USERS при компиляции exim’а, встраивается в бинарник и не может быть изменен. По умолчанию — это “root”. Эта дефолтная настройка подразумевает, что мы не может отправить почту root’у так, как обычному пользователю. Но можно создать алиас и слать почту туда.

Производить reverse DNS lookup на все входящие ip-соединения. Здесь можно указать список ip, для которых производить данную проверку, а можно и отключить проверку, закомментировав строку с этим параметром:

host_lookup = *

По дефолту exim ожидает полностью определенных адресов на конверте, т.е. содержащий и локальную часть, и домен. Если вы хотите принимать почту с неполных email-адресов, можно в следующих параметрах указать, с каких хостов:

# sender_unqualified_hosts =
# recipient_unqualified_hosts =

при этом неполные адреса дополняются значением с qualify_domain.

«percent hack» как он работает? Это настройка, благодаря которой email-адреса вида x%y@domain локально рероутится в x@y. Если domain не находится в списке percent_hack_domains, x%y представляется как локальная часть:

# percent_hack_domains =

для себя применения этой штуки пока не найдено.

Когда exim не может ни доставить письмо пользователю, ни вернуть отправителю, он замораживает «freezes» доставку и оставляет в очереди до тех пор, как указано в следующих опциях.

Эта опция размораживает замороженные bounce messages через 2 дня, пробует 1 раз отправить и игнорирует ошибки отправки:

ignore_bounce_errors_after = 2d

Эта опция удаляет замороженные сообщения, которым уже неделя:

timeout_frozen_after = 7d

По умолчанию, сообщения в очереди на отправку содержатся в spool-директории, зачастую это /var/spool/exim. Exim, конечно, работает лучше, если очередя короткие, но это не всегда возможно. Если раскомментировать следующую опцию, сообщения в очереди поделятся на 62 субдиректории  0,1… A, B, … a, b, … z. Зачем это нужно? Exim может обработать по одной субдиректории в один момент, вместо целой /var/spool/exim. Это может быть полезно при больших очередях:

# split_spool_directory = true

 Ограничение максимального размера письма:

message_size_limit = 50M

Логируем всё:

log_selector = +all


— ACL configuration

begin acl

— помечаем начало секции конфигурирования списков доступа acl.

Любой acl начинается с указания имени, затем идет список правил, а затем действие по умолчнаию.

Следующий acl производит проверку получателя:

acl_check_rcpt: — имя acl

Далее — набор правил:

Принять, если источник — локальный SMTP:

accept hosts = :
               control = dkim_disable_verify

Добавим пару строк конфига для проверки hello:

Сообщения, адресование локальным доменам (local_domains) и имеющие запрещенные символы в локальной части адреса — @ или % или ! или / или | или точки подряд, —  не отправляются, а отправителю отсылается сообщение «Restricted characters in address»:

deny message = Restricted characters in address
            domains = +local_domains
            local_parts = ^[.] : ^.*[@%!/|]

Следующее правило похожее, но применяетя ко всем остальным доменам:

deny message = Restricted characters in address
            domains = !+local_domains
            local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./ 

Включаем проверку адреса отправителя:

require verify = sender

— этот оператор требует проверки адреса отправителя перед тем как проганять адрес получателя через acl. Проверка состоит из попытки зароутить адрес отправителя (по дефолту проверяется только домен).

Принимаем почту от хостов, перечисленных в списке relay_from_hosts, т.е. от хостов, для которых наш сервер является исходящим рилеем:

accept hosts = +relay_from_hosts
               control = submission
               control = dkim_disable_verify

Принимаем почту от всех аутентифицированных пользователей с любого хоста:

accept authenticated = *
               control = submission
               control = dkim_disable_verify


При такой конфигурации последних двух правил возникла следующая проблема при отправке писем — некорректные заголовки:

Как полечить? — отключаем submission:


 Для всех остальных рилей закрыт:

require message = relay not permitted
                 domains = +local_domains : +relay_to_domains

Включаем проверку адреса получателя:

require verify = recipient

Подключаем black-листы:

Действие по умолчанию после прохождения всех проверок:

accept

ACl для проверки самого сообщения (сканируем антивирусом ClamAV):

acl_check_data:

accept


Routers configuration

параметры в этой секции определяют, как будут обрабатываться адреса.

Роутеры — это модули exim’а, принимающие решения о том, куда будут пересылаться сообщения.

Порядок расположения роутеров важен!!!

begin routers

— начало секции конфигурирования роутеров.

С помощью этого роутера exim маршрутизирует адреса, которые не находятся в локальных доменах, используя DNS lookup:

dnslookup:
driver = dnslookup
domains = ! +local_domains
transport = remote_smtp
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
no_more

domains — список доменов, к которым будет применяться роутер

dnslookup (имя роутера) и driver = dnslookup (имя драйвера) совпадают

dnslookup-роутер запрашивает у DNS MX-запись домена. MX-запись возвращает ip-адрес хоста, которому exim перенаправит письмо. Для обработки адреса этим роутером, адрес не должен находиться в локальных доменах ( ! +local_domains), домен не должен резолвится в адреса 0.0.0.0 : 127.0.0.0/8 (exim считает, что для таких доменов просто нет DNS-записи). Если DNS lookup терпит неудачу, считается, что адрес немаршрутизируемый (unrouteable).

no_more — если dnslookup потерпел неудачу, адрес последующим роутерам на обработку не передается.

Следующий роутер — system_aliases — используется для обработки алиасов локальных доменов (алиасы описаны в файле /etc/aliases):

system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
user = mailnull
group = mail
file_transport = address_file
pipe_transport = address_pipe

Роутер просматривает  локальную часть адреса и, если находит ее в файле /etc/aliases, передает управление драйверу redirect для дальнейшей маршрутизации на соответствующие адреса. Если адресов нет (data пустое), адрес переходит в обработку следующему роутеру.


Опять-таки, список алиасов доменов беру с базы postfix и передаю на обработку драйверу redirect:

Пользователями, их ящиками заведует dovecot:

 


 

Самый сложный роутер в дефолтной конфигурации (пока еще неясно до конца, что он делает):

userforward:
driver = redirect
check_local_user
# local_part_suffix = +* : -*
# local_part_suffix_optional
file = $home/.forward
# allow_filter
no_verify
no_expn
check_ancestor
file_transport = address_file
pipe_transport = address_pipe
reply_transport = address_reply
condition = ${if exists{$home/.forward} {yes} {no} }

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

Последний роутер — доставка в ящики локальных пользователей:

localuser:
driver = accept
check_local_user
# local_part_suffix = +* : -*
# local_part_suffix_optional
transport = local_delivery
cannot_route_message = Unknown user


Transports configuration

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

 begin transports

— начало секции описания транспортов.

Транспорт для доставки сообчений через smtp-соединение:

remote_smtp:
    driver = smtp

Транспорт для локальной доставки:

local_delivery:
driver = appendfile
file = /var/mail/$local_part
delivery_date_add
envelope_to_add
return_path_add
group = mail
user = $local_part
mode = 0660
no_mode_fail_narrower

 продолжение следует…

03 — Сервер на флешке. Jails

1. Обновляем коллекцию портов:

2. Обновляем дерево исходных кодов:

3. Добавляем опции в /etc/make.conf:

4. Собираем мир:

5. Редактируем конфиг ezjail.conf:

6. Создаем basejail в ezjail-admin:

7. Разворачиваем шаблоны для jail:

8. Разворачиваем дерево портов в basejail:

9. Создаем jail в ezjail предварительно зацепив IP алиасом:

10. Запускаем джейлы:

 

02 — Сервер на флешке. ZFS

Размечаем дисковое пространство и создаем зеркало ZFS

Я использую для этого формат размещения таблицы разделов GUID Partition Table (GPT).

Для разметки с использованием GPT применяется утилита gpart.

1. Убираем старую схему разметки:

2. Создадим схему GPT на диске:

3. Создаем партиции с ZFS:

4. Создаем zpool mirror:

5. Создаем файловые системы:

01 — Сервер на флешке. NanoBSD

NanoBSD. Начало

NanoBSD — утилита для создания образа FreeBSD для последующего его использования на Flash-картах памяти.

Вкратце, как этим пользоваться.

nanobsd — это скрипт nanobsd.sh, находится здесь: /usr/src/tools/tools/nanobsd/. С помощью этого скрипта и дополнительных файлов кастомизации (или без них) создается образ FreeBSD, который потом заливаем с помощью dd (или pv) на флешку.

После этих манипуляций флешка делится на 3 части по умолчанию:

  • образ NanoBSD #1
  • образ NanoBSD #2
  • партиция конфигурационных файлов, которая монтируется в /cfg директорию.

Эти партиции монтируются в режиме read-only при загрузке системы, с /cfg копируются конфигурационные файлы в /etc, затем /cfg отмонтируется.

/etc и /var директории — это md — (malloc) диски памяти — виртуальные диски в оперативной памяти.

Если в процессе работы необходимо сделать изменения в конфигурационных файлах директории /etc, эти изменения будут работать ровно до перезагрузки сервера, поскольку изменения затрутся файлами из директории /cfg. Чтобы сохранить изменения, нужно смонтировать директорию в режиме read-write, скопировать измененные файлы туда и отмонтировать /cfg. Чтобы автоматизировать данные  действия существует скриптик «wr«.

Минимальный набор команд для создания образа:

Custom configuration file

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

Конфигурационный файл состоит из конфигурационных опций, являющимися переменными по умолчанию.

Наиболее важные следующие:

  • NANO_NAME=MS_9.2.CLANG — Имя, которое вы присваиваете сборке NanoBSD. Это имя NanoBSD использует для присвоения имен рабочим каталогам и файлу образа диска.
  • NANO_SRC=/usr/src — Местоположение дерева исходного кода, который NanoBSD использует для создания образов дисков. Если вам требуется указать другое местоположение, измените этот параметр.
  • NANO_TOOLS=tools/tools/nanobsd — Сценарии и файлы NanoBSD считаются частью исходного кода FreeBSD. Это означает, что при обновлении исходников файлы NanoBSD, естественно, также обновятся. Если вы внесете какие-либо изменения в файлы NanoBSD, они затрутся. При изменении базовых компонентов NanoBSD желательно скопировать каталог NanoBSD куда-нибудь за пределы дерева исходного кода.
  • CONF_BUILD=’ ‘ — Любые параметры, определенные здесь, будут использованы на этапе make buildworld. Полный список параметров, допустимых в вашей версии FreeBSD, вы найдете на странице руководства src.conf(5).
  • CONF_INSTALL=’ ‘ — Любые параметры, определенные здесь, будут использованы на этапе make installworld. Полный список допустимых параметров вы также найдете на странице руководства src.conf(5).
  • CONF_WORLD=’ ‘ — Значение этого параметра используется как ключи в ходе всего процесса сборки.
  • NANO_KERNEL=GENERIC — если захотите собрать нестандартное ядро для своего образа NanoBSDкажите его здесь. Это должно быть имя файла в каталоге /usr/src/sys/i386/conf.
  • NANO_DRIVE=da0 — Нужно указать имя файла устройства, соответствующего flash-диску. Чтобы узнать это, можно загрузить целевое устройство и посмотреть, под каким именем оно видит эту карту.
  • NANO_MEDIASIZE=15665140 — Емкость вашего flash-диска в 512-байтовых секторах.
  • NANO_IMAGES=2 — NanoBSD позволяет создать несколько образов операционной системы на одном flash-диске. Это может упростить обновление, но требует в два раза больше пространства. Поскольку в наши дни flash-диски достаточно емки и способны вместить практически любой образ FreeBSD, который вы можете собрать, можно и не изменять это значение.
  • NANO_CONFSIZE=204800 — Дополнительно NanoBSD создает дисковый участок для хранения конфигурационных файлов, как показано ниже. Данный параметр определяет размер этого участка в 512-байтовых секторах. 204800 секторов эквивалентно 100 МБ.
  • NANO_RAM_ETCSIZE=204800 — Объем дискового пространства в 512-байтовых секторах, выделяемого для каталога /etc.
  • NANO_RAM_TMPVARSIZE=204800 — Объем дискового пространства, выделяемого для каталогов /var и /tmp.
  • NANO_SECTS=63; NANO_HEADS=255 — Здесь определяется геометрия используемого flash-диска.
  • NANO_BOOTLOADER=»boot/boot0″

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

Пример конфигурационного файла nanobsd.conf.custom:

Каталог сборки NanoBSD

Для сборки NanoBSD используется подкаталог каталога /usr/obj, имя которого задано параметром NANO_NAME. NanoBSD использует файлы, имена которых начинаются с _., как маркеры, протоколы и временные каталоги. Несмотря на лаконизм сообщений, наблюдаемых в процессе сборки, в действительности NanoBSD не скрывает вывод используемых команд, просто он перенаправляется в другие файлы (_.bk — лог процесса сборки ядра, _.bw — лог процесса сборки мира etc).

Лог создается для каждого действия, выполненного скриптом — например, про установку порта ftp/wget можно узнать из файла _.cust.add_port_ftp_wget.

_.disk.full — полученый образ системы.

Если после завершения работы скрипта вы не увидите в папке /usr/obj/имя_образа образа _.disk.full, значит процесс сборки потерпел неудачу. Причину нужно искать в логах.

 

Некоторые моменты

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

В nanobsd.sh есть пара ключей, которые могут упростить нам жизнь, пропуская ресурсоемкие задачи:

  • -k — пропустить процесс сбоки ядра
  • -w — пропустить процесс сбоки мира
  • -b — пропустить процесс сбоки и ядра, и мира

 

Спасибо следующим сайтам за предоставленную информацию:

http://freebsd.org
http://freebsdguide.ru