Архив рубрики: 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/

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

http://pro-voip.com.ua freebsdгенерируем ключи на локальном хосте под тем пользователем, с которого хотим иметь доступ к удаленному хосту
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 оставляем пустым;

 

Примечание

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

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

Локальный хост — 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.example.com, вы ввели команду su и попали в окружение root-а на своем host.example.com, и теперь пытаетесь зайти на удаленный хост

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

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

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

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

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

Режимы работы 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

 

 

Опции 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

 

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

HDD: Smartmontools

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

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

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

 

smartctl

Справка smartctl:

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

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

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

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

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

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

 

SMART-тесты

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

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

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

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

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

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

 

SMART-атрибуты

Поля атрибутов 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

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

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

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

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

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

Пример:

В данном примере указаны два жестких диска — 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

 

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 — Создаем «свое» ядро

 

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.

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

TFTP: Запуск tftpd через inetd

tftp — (trivial file transfer protocol)- простой протокол передачи файлов; используется при загрузке бездисковых систем, для загрузки обновлений и конфигураций в сетевые устройства; для своей работы использует udp. tftp-сервер слушает порт 69.
tftpd — реализация tftp-сервера на Unix-хостах.
inetd — интернет «super-server» — используется для вызова других демонов. inetd слушает запросы на соединения по определенным портам (которые в свою очередь соответствуют определенным сервисам). Сервисы, которые обслуживает inetd, задаются в файле конфигурации /etc/inetd.conf.

Настройка

В файле /etc/inetd.conf раскомментируем следующую строку:

Опции tftpd:

  • -l — включаем логирование с использованием syslog. Прим., логирование LOG_FTP сообщений должно быть включено в настройках syslog — файл syslog.conf: «ftp.info /var/log/xferlog»;
  • -s /tftpboot — задаем директорию для хранения файлов, доступных извне по tftp;
  • -w — по умолчанию, запись в директорию tftp запрещена, но мне нужно скидывать файлы конфигурации по tftp на сервер, поэтому запись разрешаем этой опцией:

Возможная невнимательность: не дописывайте опции после -s и перед /tftpboot, потому как «-s /tftpboot» неделима.   
… tftpd -l -s -w /tftpboot … работать не будет.

Создаем директорию tftp-сервера:

Запуск

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

Стартуем и проверяем: