Архив рубрики: FreeBSD

syslogd: Прием логов с удаленных хостов

Syslogd запускаю на FreeBSD 11.3

Допустим, есть сервер с адресом 10.10.10.10, на котором запущен и работает демон syslogd. Есть некий роутер cisco с адресом 192.168.15.2, с которого мы хотим получать логи на сервер.

Для этого:
1) убеждаемся, что фаервол на сервере разрешает обращения к себе на порту udp 514 (дефолтный порт syslogd)
2) Редактируем конфигурационный файл /etc/syslog.conf

[root@noc /]# cd /etc [root@noc /etc]# cp syslog.conf syslog.conf.backup [root@noc /etc]# ee syslog.conf

Добавляем в конец файла следующую конструкцию:

!* +192.168.15.2 *.* /var/log/192.168.15.2.log +*

!* — разделитель
+ — указываем ip-адрес удаленного хоста, с которого будут приходить логи.
*.* — принимаем все типы сообщений (all facilities, all levels)
+* — конец секции описания хоста
/var/log/192.168.15.2.log — путь к лог-файлу для данного удаленного хоста

3) Редактируем /etc/rc.conf, добавляем строку:

syslogd_flags="-a 192.168.15.2:* -b 10.10.10.10 -n -C"

здесь указываем флаги запуска.

-a — указываем ip-адрес хоста, с которого будем принимать логи.
Можно указать целую сеть,например -a 192.168.15.0/24:*
Флаг -a можно использовать несколько раз.
По умолчанию, syslogd принимает сообщения с src-порта 514, но зачастую оборудование в качестве порта-источника использует рандомный порт. Чтобы syslog принимал сообщения с рандомных портов, необходимо добавить маску :* после указания ip-адреса или сети.

«Почему не приходят логи с удаленного хоста cisco?» — выше ответ, добавьте :*

-b bind address (необязательно задавать)

-С — создавать log-файл, если его нет (создается с правами 0600)

-n — не резолвить ip в dns-имена

«Почему сообщения от удаленного хоста не пишутся в нужный log-файл?»:

Если не задать в rc.conf опцию -n, то syslogd будет резолвить ip-адрес в dns, используя PTR-запись на dns-сервере.
Нам это не нужно, так как во-первых: зачем нам лишние запросы в днс, во-вторых: чтобы syslogd правильно распарсил сообщения с нужного ip и положил в отдельный файл, нужно чтобы syslogd видел в сообщениях именно ip, а не PTR вида home-192-168-2-15.some-isp.com.

debug syslogd

-d — дебаг — полезная опция на этапе отладки. Если что-то не едет, добавляем этот флаг в syslogd_flags и смотрим сообщения в консоли.
При нормальной работе опцию отключаем.

Не забывайте после внесения изменений рестартовать syslogd:

[root@noc /]# service syslogd restart

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

Вот что увидим в консоли при включенном дебаге, если не укажем :* после ip-адреса — port mismatch:

received sa_len = 16 cvthname(2) len = 16 cvthname(192.168.15.2) of validation rule: 1 validate: dgram from IP 192.168.15.2, port 59635, name home-192-168-2-15.some-isp.com; rejected in rule 1 due to port mismatch.

А если не отключим резолв ip в днс, то лог будет писаться в /var/log/messages, а не в /var/log/192.168.15.2.log:

received sa_len = 16 cvthname(2)len = 16 cvthname(192.168.15.2) # of validation rule: 1 validate: dgram from IP 192.168.15.2, port 59635, name home-192-168-2-15.some-isp.com; accepted in rule 1. logmsg: pri 275, flags 0, from home-192-168-2-15.some-isp.com, msg r-generator: 000301: May 28 12:26:10 EET: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.5.5.5) Logging to FILE /var/log/messages

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: Работа с коллекцией портов

Скачать и распаковать коллекцию портов (утилита 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.

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

Конфигурирование опций порта
Загрузка архива с исходными файлами приложения
Проверка загруженых файлов на наличие ошибок
Извлечение исходных файлов с архива в рабочую директорию
Наложение патчей с директории files, если такое имеются и необходимы
Проверка и установка зависимостей
Запуск сценария configure, если такой есть в приложении
Сборка приложения из исходных файлов
Установка приложения (копирование скомпилированных бинарников, файлов конфигурации и т.п. в необходимые места в файловой системе — а что это за файлы и в какие необходимые места, описано в pkg-plist)
Регистрация приложения в /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/

SSH: Авторизация по ключам. Беспарольный доступ

генерируем ключи на локальном хосте под тем пользователем, с которого хотим иметь доступ к удаленному хосту
ssh-keygen -b 2048 -t rsa

создаются два ключа
.ssh/id_rsa (закрытый)
.ssh/id_rsa.pub (открытый)

копируем открытый ключ — содержимое файла id_rsa.pub — на удаленный хост в файл .ssh/authorized_keys;
если файла authorized_keys нет, создаем его.

ssh-keygen

-t — тип ключа — dsa или rsa;
-b — длина ключа — для rsa можно и не указывать -b 2048 — потому как это дефолтное значение;
если нужен именно беспарольный доступ по ключам — поле passphrase оставляем пустым;

ssh-keygen -b 2048 -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:

Примечание

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

Вот следующая ситуация, имеем:

Локальный хост — host.example.com, пользователь на нем — user
Удаленный хост — server.example.com, пользователь на нем — admin

Вы — пользователь user на host.example.com и хотите иметь беспарольный доступ по ключам к server.example.com под пользователем admin.

Тогда вы на host.example.com, будучи залогиненым под своим пользователем user, генерируете ключи, которые сохраняются по умолчанию (если не задать другое) в вашем домашнем каталоге в директории .ssh

/home/user/.ssh/id_rsa
/home/user/.ssh/id_rsa.pub

На удаленном хосту в домашнем каталоге пользователя admin в директории .ssh создаете файл authorized_keys и копируете в этот файл одной строкой содержимое ранее сгенерированого на локальном хосту публичного ключа

/home/admin/.ssh/authorized_keys

Все работает:

[user@host ~]$ ssh admin@server.example.com

! При этом если измените пользователя на любой из сторон — без пароля уже не зайдете.

Например, все так же будучи залогиненым под пользователем user на host.example.com, вы ввели команду su и попали в окружение root-а на своем host.example.com, и теперь пытаетесь зайти на удаленный хост

root@host:/home/user# ssh admin@server.example.com
Password for admin@server.example.com:

— и у вас спрашивают пароль, а все потому что не тот пользователь.

! Опять-таки но — если вы root, то у вас есть доступ к любым файлам на вашей системе, в том числе и доступ к закрытому ключу /home/user/.ssh/id.rsa

поэтому с roota вы можете попасть на удаленный хост по ключам, просто указав путь к ключу с помощью опции -i

root@host:/home/user# ssh -i /home/user/.ssh/id_rsa admin@server.example.com

RSYNC: Резервное копирование. Простой backup-скрипт

Режимы работы rsync

«listing«
аналог ls -l — команда rsync указывается с аргументом src, без dst:
# rsync /

«local«
локальный режим — копирование в пределах локального хоста — аналог cp:
# rsync /home/provoip/file1 /home/admin

«rsync via ssh«
копирование с/на удаленный хост используя транспорт ssh (или rsh, кто-то использует?):
# rsync /home/provoip/file1 admin@remoteserver.com:/home/admin

«rsync via daemon«
копирование с/на удаленный хост используя rsync демон (на сервере, где запущен rsync-демон, в пути ставим :: и указываем не путь к dst-директории, а модуль, модули настраиваются через конфигурационный файл rsync-демона):
# rsync /home/provoip/file1 jasmin@remoteserver.com::module1

Кусочек man rsync

Local: rsync [OPTION...] SRC... [DEST]

Access via remote shell:
Pull:  rsync [OPTION...] [USER@]HOST:SRC... [DEST]
Push:  rsync [OPTION...] SRC... [USER@]HOST:DEST

Access via rsync daemon:
Pull:  rsync [OPTION...] [USER@]HOST::SRC... [DEST]
       rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
Push:  rsync [OPTION...] SRC... [USER@]HOST::DEST
       rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST

Опции rsync

-a, —archive — режим архивирования, набор опций -rlptgoD (без -H, -A, -X)

-r, —recursive, рекурсивное копирование каталогов;
-l, —links, копирование символических ссылок «как есть», то есть rsync не будет следовать по ним, обращаясь к файлам;
-p, —perms, сохранение прав доступа к файлам;
-t, —times, сохранение времени модификации файлов;
-o, —owner, -g, —group, сохранение владельца и группы файла соответственно;
-D, эквивалентно —devices —specials;
—devices, сохранение файлов устройств (опция будет работать только для суперпользователя);
—specials, сохранение специальных файлов;

-H, —hard-links — сохранять жесткие ссылки;
-A, —acls — сохранять acl;
-X, —xattrs — сохранять расширеные атрибуты;

-R, —relative — использовать относительные пути — ну очень полезная опция

Вот с этим параметром была история. Нужно мне было сохранить на удаленном сервере две директории — /etc и /usr/local/etc. Соответственно, ввожу команду:

rsync -a /etc /usr/local/etc admin@remoteserver.com:/home/admin

и ожидаю увидеть на удаленном сервере в /home/admin две директории с конфигами… Фиг! Rsync сначала добросовестно скопировал директорию /etc, затем при копировании /usr/local/etc отбрасывает путь /usr/local, собирается копировать etc, видит, что на удаленном сервере etc уже какбы есть, поэтому просто добавляет недостающие, по его мнению, файлы c /usr/local/etc — т.е. слил все в одну директорию etc в указанном пути на удаленном сервере и с чувством выполненного долга завершил свою работу.

Для бекапа конфигов, как понимаете, такое положение вещей не подходит. Здесь мне на глаза попалась опция -R, которая была призвана решить мою проблему — на сервере теперь присутсвуют /home/admin/etc и /home/admin/usr/local/etc

-v, —verbose,  выводить имена копируемых файлов;
-q, —quiet,  не выводить не-error сообщения;
-z, —compress, включает режим сжатия, полезно при передаче больших объемов информации;
-P, —partial, —progress,  отображать прогресс при копировании;
-c, —checksum, заставляет rsync проверять файлы по контрольной сумме;
-n, —dry-run, режим тестирования, нужен для проверки, что скопирует rsync, по факту не выполняя самого копирования. Используется с -v и/или -i;
-i, —itemize-changes, показывать, какие изменения выполняются. Используется часто с -n

—delete, удалять из бэкапа файлы, которых уже нет на стороне источника. —delete отличается от —delete-after тем, что удаление производится вначале, а не на завершающей стадии процесса бэкапа.
—delete-after, работает быстрее, так как не требует лишней стадии обхода списка файлов, но требует использования опции —force для обработки таких ситуаций как удаление файла и появление диретории с тем же именем;
—delete-excluded, удалять части которые уже есть на стороне бэкапа, но появились в списке исключения;

Примечания

копирование директорий

— указание пути директории с завершающим слешем приведет к копированию только файлов с этой директории
# rsync /etc/ admin@remoteserver.com:/home/admin => результат — /home/admin/files_from_etc

— указание пути директории без завершающего слеша приведет к копированию целой директории с файлами
# rsync /etc admin@remoteserver.com:/home/admin => результат — /home/admin/etc

копирование нескольких директорий или файлов одновременно

— просто перечисляем через пробел:
# rsync /etc /home /usr admin@remoteserver.com:/home/admin

Простой скрипт резервного копирования с использованием rsync

Скрипт не идеал, но работу свою выполняет. Как работает?

запускается по cron’у каждый день, при первом запуске делает полную копию указаных директорий, после — только вносит изменения;
каждое первое чило месяца сохраняет полную копию указаных директорий в каталоге, в имени которого указана дата — yyyymmdd;
все операции выполняет от имени root’а;
доступ к удаленному серверу по ключам;
после выполнения копирования шлет уведомление на почту;
список копируемых директорий/файлов указываем в переменной BKP_LIST

rsync_backup.sh

#!/bin/sh

################################################################################
# jasmin (c) 15.07.2015
# Scriprt rsync_backup.sh backups config files
# defined in list BKP_LIST to backup server
#
# - daily backup (incremental)
# - monthly backup (full backup in folder named with date) - every 1-st day of
# the month
#
# access to backup server with ssh-keys without passwords (user - root)
################################################################################

DATE=`date +%Y%m%d`
FIRST_DAY=`date +%d`

MAILADDR=admin@pro-voip.com.ua
HOSTNAME=www.pro-voip.com.ua
DBDIR=/dbbackup
REPORT=/tmp/rsync-report.$DATE

DST_SERVER=backup-srv.pro-voip.com.ua

(

    ################################################################################
    # if it is 1-st day of the month - make new folder and define new path
    ################################################################################
 
    if [ $FIRST_DAY == 01 ]
    then
        DST_DIR=/usr/home/RSYNK/provoip/$DATE
    else
        DST_DIR=/usr/home/RSYNK/provoip
    fi
  
    ################################################################################
    # DBDIR - local directory for dumps
    # Create database dump
    ################################################################################

    if [ ! -d $DBDIR ]
    then
        mkdir -p $DBDIR
    fi

    /usr/local/bin/mysqldump -u DBUSER -pDBPASSWORD --quick DATABASE > $DBDIR/DATABASE.sql

    ################################################################################
    # BKP_LIST - list of the directories to backup
    ################################################################################

    BKP_LIST="/etc /usr/local/etc /usr/local/www $DBDIR"


    ################################################################################
    # rsync options
    # -a - archive mode (save owners, permissions etc.)
    # -R - use relative path names - it is important!
    #
    # and make report in tmp-dir
    ################################################################################

    for BKP_ENTRY in `echo $BKP_LIST`
    do
        TIME=`date +%Y.%m.%d_%H:%M:%S`
        /usr/local/bin/rsync -aR --delete $BKP_ENTRY $DST_SERVER:$DST_DIR
        if [ $? == 0 ]
        then
            echo $TIME Rsync $BKP_ENTRY [done] >> $REPORT
        else
            echo $TIME Rsync $BKP_ENTRY [error] >> $REPORT
        fi
    done

) > $REPORT 2>&1

################################################################################
# send report to admin email
# if report have errors - Status in Subject is ERRROR, other case - OK
# then remove report from tmp-dir
################################################################################

grep error $REPORT
if [ $? = 0 ]
then
    /usr/bin/mail -s "[$HOSTNAME] rsync backup ERROR" $MAILADDR < $REPORT
else
    /usr/bin/mail -s "[$HOSTNAME] rsync backup OK" $MAILADDR < $REPORT
fi

rm $REPORT

exit 0

Portsnap: Обновление дерева портов 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 при обновлении удаляет/изменяет исходные файлы порта, а в этот же момент кто-то собирает из этих файлов порт.

ee /etc/crontab

#minute hour    mday    month   wday    who     command
0       0       *       *       0       root    portsnap -I cron update

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

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

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

Установка

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

# cd /usr/ports/sysutils/monitord
# make config
===> No options to configure

# make install
===> monitord-0.4.1_3 is marked as broken: No public distfiles.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/monitord

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

# make -DNO_IGNORE install clean

...

=============================================================
Monitord requires procfs(5). Add this line to your fstab(5):
proc /proc procfs rw 0 0
=============================================================

===>&nbsp; Cleaning for monitord-0.4.1_3

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

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

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

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

############################################################################
############################################################################
##
## Monitord Configuration file
##
############################################################################
############################################################################

# You MUST set your email address and the email server to use when sending
# out notices. It will be used if you use the "alert" option below.

email = this@is.your.email.address
smtp-server = this@is.your.email.server

# When specifying options, make sure that they are comma-separated and do NOT
# have any spaces.
#
# user options delay service start script parameters

#root auto,alert 10 inetd   /usr/sbin/inetd -wW
#root auto       10 syslogd /usr/sbin/syslogd
#root auto       10 cron    /usr/sbin/cron
#root auto       20 httpd   /usr/local/etc/rc.d/apache.sh
#root auto,alert 10 sshd    /usr/local/sbin/sshd

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

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

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

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

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

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

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

# cd /usr/local/etc/
# cp monitord.conf.sample monitord.conf
# ee monitord.conf

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

root auto 10 httpd    /usr/local/sbin/apache24 start

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

# ee /etc/rc.conf

# MONITORD
monitord_enable="YES"

# /usr/local/etc/rc.d/monitord start

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

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

email = admin@provoip.in.ua
smtp-server = mx.provoip.in.ua

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

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

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

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

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

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

Когда нужно научить свой сервер отправлять почту…

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

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

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

Установка

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

# whereis ssmtp
ssmtp: /usr/ports/mail/ssmtp
# cd /usr/ports/mail/ssmtp
# make install clean

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

sSMTP has been installed successfully.

To replace sendmail with ssmtp type "make replace" or change
your /etc/mail/mailer.conf to:

sendmail    /usr/local/sbin/ssmtp
send-mail    /usr/local/sbin/ssmtp
mailq        /usr/local/sbin/ssmtp
newaliases    /usr/local/sbin/ssmtp
hoststat    /usr/bin/true
purgestat    /usr/bin/true


However, before you can use the program, you should copy the files
"revaliases.sample" and "ssmtp.conf.sample" in /usr/local/etc/ssmtp
to "revaliases" and "ssmtp.conf" respectively and edit them to suit
your needs.

Настройка

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

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

sendmail    /usr/local/sbin/ssmtp
send-mail    /usr/local/sbin/ssmtp
mailq        /usr/local/sbin/ssmtp
newaliases    /usr/local/sbin/ssmtp
hoststat    /usr/bin/true
purgestat    /usr/bin/true

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

root=admin@provoip.in.ua
mailhub=mail.pro-voip.com.ua
rewriteDomain=provoip.in.ua
hostname=server.provoip.in.ua
FromLineOverride=YES

Кто получает почту для 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 отправки письма:

Debug=YES

Здесь следует обратить внимание на расположение данной опции в файле конфига /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:

# sSMTP aliases
#
# Format: local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.

user123:user123@example.com:mail.pro-voip.com.ua

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

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

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

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

HDD: Smartmontools

! Работает с жесткими дисками, которые поддерживают технологию SMART !

smartmontools состоит из двух утилит:

smartctl — (Control and Monitor Utility for SMART Disks) — так сказать, интерактивная часть;
smartd — (SMART Disk Monitoring Daemon) — демон.

smartctl

Справка smartctl:

smartctl -h

Сканировать и вывести список дисков и их тип:

smartctl --scan

Получить информацию о диске, такую как модель, серийный номер:

smartctl -i /dev/ada0

Краткая общая информация о здоровье диска:

smartctl -H /dev/ada0

Посмотреть всю информацию об устройстве:

smartctl -x /dev/ada0

Посмотреть всю SMART-информацию:

smartctl -a /dev/ada0

Посмотреть SMART-атрибуты диска:

smartctl -A /dev/ada0

SMART-тесты

Работа с тестами самодиагностики.

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

Запуск короткого теста (длится пару минут):

smartctl -t short /dev/ada0

Запуск длинного теста (десятки минут, до часа):

smartctl -t long /dev/ada0

Отменить тест:

smartctl -X

Просмотр результата теста:

smartctl -l selftest /dev/ada0

SMART-атрибуты

# smartctl -A /dev/ada0

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       1
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       121
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       0
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   111   109   000    Old_age   Always       -       32
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

Поля атрибутов SMART

ID — идентификатор атрибута, однозначно определяет атрибут.
ATTRIBUTE_NAME — имя атрибута, расшифровка ID.
VALUE — текущее значение атрибута. Чем меньше — тем хуже. Измеряется в «попугаях». Сравнивается со значением TRESHOLD:

VALUE > TRESHOLD — диск считает, что он здоров;
VALUE < или = TRESHOLD — бьем тревогу;
VALUE не достиг уровня TRESHOLD, но упорно уменьшается — атрибут деградирует — тоже пора задуматься о замене диска.

WORST — наихудшее значение VALUE атрибута за всю жизнь диска. Измеряется в «попугаях».
TRESHOLD — пороговое (критическое) значение VALUE для атрибута. Измеряется в «попугаях».
TYPE — тип атрибута:

Pre-fail — критичный
Old_age — некритичный

WHEN_FAILED — «когда выйдет из строя»:

«FAILED_NOW» — опасно;
» — » — с атрибутом все в порядке.

RAW_VALUE — реальное значение атрибута (не в «попугаях») — в зависимости от атрибута значение:

текущее (например, температура -Temperature_Celsius);
накапливающее (какой-либо счетчик, например, Power_Cycle_Count).

VALUE вычисляется исходя из RAW_VALUE по определенным алгоритмам, которые задает производитель.

Атрибуты SMART

* жирным шрифтом выделены атрибуты, требующие особого внимания

(1) Raw_Read_Error_Rate — содержит частоту возникновения ошибок при чтении с диска по вине аппаратной части накопителя;
(3) Spin_Up_Time — содержит время разгона шпинделя диска из состояния покоя до номинальной скорости (например, от 0 до 7200 об/мин);
(4) Start_Stop_Count — полное число запусков/остановов диска;
(5) Reallocated_Sector_Ct — содержит кол-во секторов, переназначенных диском в резервную область — операция Remapping — считаются только удачные попытки. Ключевой параметр в оценке состояния диска;
(7) Seek_Error_Rate — частота появления ошибок позиционирования БМГ; указывает на проблемы в механике диска;
(9) Power_On_Hours — число часов проведенных во включенном состоянии (накапливающий);
(10) Spin_Retry_Count — число попыток старта шпинделя диска, если первая попытка была неудачной;
(11) Calibration_Retry_Count — число попыток рекалибровки накопителя — сброс состояния диска и установка головок на нулевую дорожку;
(12) Power_Cycle_Count — число полных циклов включения-отключения диска;
(192) Power-Off_Retract_Count — для разных винчестеров либо суммарное кол-во парковок БМГ в аварийных ситуациях, либо суммарное кол-во включения-выключения питания диска (в WD, Hitachi);
(193) Load_Cycle_Count — кол-во полных циклов парковки БМГ;
(194) Temperature_Celsius — температура диска;
(196) Reallocated_Event_Count — кол-во операций переназначения — Remapping — учитываются удачные и неудачные попытки;
(197) Current_Pending_Sector — текущее кол-во нестабильных секторов — кандидаты на Remapping;
(198) Offline_Uncorrectable — параметр изменяется только при offline-тестировании, которое диск запускает при простое; содержит секторы-кандидаты на Remapping;
(199) UDMA_CRC_Error_Count — кол-во ошибок при передаче по интерфейсному кабелю в режиме UltraDMA от материнской платы контроллеру диска; Причины — некачественный шлейф, плохой контакт в SATA-разъеме;
(200) Multi_Zone_Error_Rate — частота появления ошибок при записи данных;

smartd

Конфигурационный файл:

/usr/local/etc/smartd.conf

Автоматическое сканирование системы в поисках ATA и SCSI:

DEVICESCAN

может запускаться с набором нужных директив, которые будут применены ко всем найденым дискам. Например:

DEVICESCAN -I 194 -I 231 -I 9

Описание директив конфигурационного файла smartd можно найти в smartd.conf.sample и в ‘man smartd.conf’.

Многие люди предпочитают вручную указывать диски, которые хочется мониторить. Для этого необходимо закоментировать DEVICESCAN и указать диски.

Пример:

/dev/ada0 -a -o on -S on -s (S/../.././02|L/../../6/03) -I 194 -W 4,45,55 -R 5 -m admin@provoip.in.ua
/dev/ada1 -a -o on -S on -s (S/../.././02|L/../../6/03) -I 194 -W 4,45,55 -R 5 -m admin@provoip.in.ua

В данном примере указаны два жестких диска — ada0 и ada1. Используемые директивы:

-a Default: то же, что и набор директив «-H -f -t -l error -l selftest -C 197 -U 198»:

-H — мониторинг SMART Health Status, сообщает если статус FAILED;
-f — мониторинг на ошибки (FAILED) любого из используемых атрибутов (поле SMART-атрибута WHEN_FAILED);
-t — то же, что и набор директив «-p -u»:

-p рассказывать об изменениях в «Pre-fail»-атрибутах;
-u рассказывать об изменениях в «Old_age»-атрибутах;

-l error — мониторить SMART-логи error;
-l selftest — мониторить SMART-логи selftest;

-C 197 — «197» — это ID атрибута — RAW_VALUE Current_Pending_Sector — сообщать при ненулевом значении;
-U 198 — «198» — это ID атрибута — RAW_VALUE Offline_Uncorrectable — сообщать при ненулевом значении;

-o on — enable автоматические offline-тесты;
-S on — enable attribute autosave;

-s (S/../.././02|L/../../6/03) — стартовать selftest’ы, когда выполняется регулярное выражение. В данном примере заданы несколько выражений, разделенных условием «или», поэтому ставим круглые скобки.

Регулярное выражение представляет собой следующую конструкцию:
T/MM/DD/d/HH
T — тип теста — Short, Long, Conveyance или Offline, MM — месяц, DD — день, d — день недели, HH — час.
S/../.././02 — запускать короткий (S) тест каждый день после 2-х часов ночи;
L/../../6/03 — запускать длинный (L) тест каждую субботу (день недели — 6) после 3-х часов ночи.

-I 194 — игнорировать изменения атрибута 194 — Temperature_Celsius;
-W 4,45,55 — мониторинг изменения температуры на 4 градуса, 45 — informal лимит, 55 — критический лимит;
-R 5 — отследить изменения в атрибуте 5 — Reallocated_Sector_Ct;

-m admin@provoip.in.ua — отправить warning email на admin@provoip.in.ua для -H, -l error, -l selftest, и -f

Другие директивы для smartd.conf:

* взято из /usr/local/etc/smartd.conf.sample

 -d TYPE Set the device type: ata, scsi, marvell, removable, 3ware,N, hpt,L/M/N
 -T TYPE set the tolerance to one of: normal, permissive
 -o VAL Enable/disable automatic offline tests (on/off)
 -S VAL Enable/disable attribute autosave (on/off)
 -n MODE No check. MODE is one of: never, sleep, standby, idle
 -H Monitor SMART Health Status, report if failed
 -l TYPE Monitor SMART log. Type is one of: error, selftest
 -f Monitor for failure of any 'Usage' Attributes
 -m ADD Send warning email to ADD for -H, -l error, -l selftest, and -f
 -M TYPE Modify email warning behavior (see man page)
 -s REGE Start self-test when type/date matches regular expression (see man page)
 -p Report changes in 'Prefailure' Normalized Attributes
 -u Report changes in 'Usage' Normalized Attributes
 -t Equivalent to -p and -u Directives
 -r ID Also report Raw values of Attribute ID with -p, -u or -t
 -R ID Track changes in Attribute ID Raw value with -p, -u or -t
 -i ID Ignore Attribute ID for -f Directive
 -I ID Ignore Attribute ID for -p, -u or -t Directive
 -C ID Report if Current Pending Sector count non-zero
 -U ID Report if Offline Uncorrectable count non-zero
 -W D,I,C Monitor Temperature D)ifference, I)nformal limit, C)ritical limit
 -v N,ST Modifies labeling of Attribute N (see man page)
 -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198
 -F TYPE Use firmware bug workaround. Type is one of: none, samsung
 -P TYPE Drive-specific presets: use, ignore, show, showall
# Comment: text after a hash sign is ignored
# \ Line continuation character
# Attribute ID is a decimal integer 1 <= ID <= 255
# except for -C and -U, where ID = 0 turns them off.
# All but -d, -m and -M Directives are only implemented for ATA devices
#
# If the test string DEVICESCAN is the first uncommented text
# then smartd will scan for devices /dev/hd[a-l] and /dev/sd[a-z]
# DEVICESCAN may be followed by any desired Directives.

Sources:

man smartctl
man smartd.conf
http://www.ixbt.com/storage/hdd-smart-testing.shtml
http://rtfm.co.ua/s-m-a-r-t-proverka-hdd-opisanie-atributov-znachenie-atributov-utility-parametry/
http://www.wandmagic.ru/news/178.html
http://www.lexpr.ru/node/336

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

root@provoip # uname -i
GENERIC

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

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

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

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

cd /usr/src/sys/amd64/conf/
root@provoip:/usr/src/sys/amd64/conf # ls
DEFAULTS GENERIC GENERIC.hints Makefile NOTES

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

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

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

root@provoip:/usr/src/sys/amd64/conf # cp GENERIC PROVOIP

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

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

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

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

# add Generic kernel
include GENERIC

ident PROVOIP

# IPFW
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=5
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
options IPFIREWALL_NAT
options LIBALIAS

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

root@provoip # cd /usr/src

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

root@provoip:/usr/src # make buildkernel KERNKONF=PROVOIP

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

root@provoip:/usr/src # make installkernel KERNKONF=PROVOIP

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

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

root@provoip # uname -i
PROVOIP