muff.kiev.ua

Top - интерактивный мониторинг

muff — Mon, 17 Jun 2019 15:16:05 +0000

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

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

Рассмотрим верхнюю часть вывода утилиты, тоесть, общую информацию о системе.

Использование процессорного времени (CPU):

user - (User CPU time) время, затраченное на работу процессов пользователей.
nice - (Nice CPU time) время, затраченное на работу процессов с измененным приоритетом.
system - (System CPU time) время, затраченное на работу процессов ядра системы.
interrupt - время, затраченное на работу обработку прерываний.
idle - простой процессора.

Использования памяти - значения расписаны в статье о структуре виртуальной памяти.

Следующее значение - load average. Это один из важных параметров, поэтому детально его рассмотрим.

Данные load average выводятся в трёх временных интервалах - данные за 1 минуту, за 5 минут и за 15 минут. Эти числа отображают число блокирующих процессов в очереди на исполнение за определенный временной интервал. В данном случае, блокирующий процесс - это процесс, который ожидает ресурсов для продолжения работы. Как правило, происходит ожидание таких ресурсов, как центральный процессор, дисковая подсистема или сетевая подсистема. Высокие значения показателей load average говорят о том, что система не справляется с нагрузкой. Но как узнать какое значение load average является нормальным? Всё зависит от количества ядер.

Рассмотрим ситуацию, когда у нас CPU с одним ядром, отталкиваясь от значений load average во временных интервалах за 5 и 15 минут.

Load average	Состояние системы
< 0.7	Все в порядке. Система практически не нагружена
0.7 - 1	Система нагружена. Следует найти и определить причину нагрузки системы для избежании проблем в дальнейшем.
1-5	Система сильно нагружена. Необходимо в срочном порядке определить причину высокой нагрузки и устранить ее.
> 5	Система критически нагружена. Сервер может подвисать и работать очень медленно, при обработке запросов "торможения", доступ к серверу затруднён.

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

Также, стоит обратить внимание на тот факт, что максимальная производительность системы достигается при load average > 1, тоесть, в отдельных случаях есть смысл держать load average повыше, чтобы более эффективно нагрузить "железо", в ущерб времени обработки отдельного запроса.

Еще один важный аспект. При load average больше 5, работа системы расценивается как неустойчивая. Некоторые демоны прекращают приём новых запросов при высоких уровнях загрузки (например Sendmail прекращает приём запросов при load average равным или больше 12). Если загрузка достигает 20-30, то скорей всего система окажется в ситуации, называемой "спираль смерти", т.е. новые процессы создаются быстрее, чем система может их выполнить. "Death Spiral" - один из редких случаев, когда может понадобится перезагрузить сервер.

Обратите внимание на отображениее load average в мультипроцессорных системах. В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.

Продолжим изучение утилиты top. В нижней части вывода, мы можем получить следующую информацию о процессах.

PID - идентификатор процесса.
USERNAME - пользователь, от которого запущен процесс.
THR - количество потоков, запущенных процессом.
PRI - текущий приоритет процесса.
NICE - приоритет, выставленный командой nice.
SIZE - полный размер процесса (данные, стек и т. д.)
RES - размер процесса в оперативной памяти.
STATE - текущее состояние процесса: "START", "RUN", "SLEEP", "STOP", "ZOMB", "WAIT" или "LOCK". Текущая нагрузка отображается только в состояниях "START" и "RUN".
C - номер процессора, на котором идет выполнение (только на SMP системах).
TIME - время использования процессора (в секундах).
WCPU - усредненное значение использования CPU.
COMMAND - команда, запустившая процесс.

При использовании утилиты top, поддерживаются ключи, для работы в интерактивном режиме, которые сортируют, фильтруют или видоизменяют вывод. Рассмотрим некоторые из них

a - показать абсолютные пути запущенных процессов.
С - переключение между режимами отображения "raw cpu" и "weighted cpu".
H - включает/выключает отображение потоков.
h - отображение окна справки.
i - скрыть/отобразить отображение простаивающих процессов.
j - скрыть/отобразить jail ID.
J - отображение процессов только указанного jail.
k - уничтожить процесс (запрашивает PID процесса).
m - переключение между режимами отображения нагрузки (процессор, память) и загрузки системы ввода-вывода.
n - изменить число отображаемых процессов (предлагается ввести число).
o - сортировка по столбцам pri, size, res, cpu, time, thr.
P - показывать статистику загрузки по каждому процессору отдельно (для SMP систем).
r - изменить приоритет процесса.
S - показать/скрыть системные процессы (по умолчанию они скрыты).
s - установить время обновления вывода информации (в секундах).
t - скрыть/отобразить процесс top.
u - отфильтровать по имени пользователя (запрос на имя пользователя).
[Пробел] - немедленно обновить содержимое экрана

Полезные мелочи при использовании top.

FreeBSD - виртуальная память

muff — Mon, 17 Jun 2019 15:02:48 +0000

Active - память которая используется в данный момент
Inactive - память, которая была освобождена, но до сих пор в кэше, так как он может быть использована снова. Если требуется больше свободной памяти, эта память может быть очищена и перейти во Free. Эта память не очищается до того момента, пока в этом не возникнет необходимость, чтобы сохранить старые данные на случай, если они понадобятся снова.
Wired - память, которую использует ядро. Эта память не может быть выгружена в Swap.
Cache - память, которая использовалась под кеш и может быть освобождена в любой момент.
Buffers - память, которая отдана под дисковый кеш.
Free - память которая полностью свободна и готова к использованию. Inactive, Cache и Buffers могут стать частью Free после полного освобождения.
Res - чистая оперативная память, которую потребляет процесс
Size - полная память (Res + shared-библиотеки (*.so) + стек + shared-memory + swap), которую потребляет процесс.
Shared - часть памяти, которая может использоваться одновременно несколькими процессами.
Laundry - содержит грязные страницы памяти, прошедшие один раз через неактивную очередь (или память в очереди на "освобождения от грязи").

FreeBSD - изменение зарезервированного обьема дискового пространства

muff — Wed, 11 Jul 2018 14:48:56 +0000

Собирая очередной програмнный RAID5 на FreeBSD, решил обратить внимание сообщества на следующий момент:

# df -h

Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0a    446G    4,4G    405G     1%    /
devfs               1,0K    1,0K      0B   100%    /dev
/dev/raid5/raid5     13T    8,0K     12T     0%    /raid5

"Пропал" терабайт доступного дискового пространства... Как это возможно?

Дело в том, что часть каждого раздела UFS (по умолчанию 8%) зарезервировано для использования операционной системой и пользователем root. Утилита df не учитывает это при подсчёте значения в колонке Capacity, так что оно может превышать 100%. Обратите внимание, что колонка Blocks всегда больше, чем сумма значений в колонках Used и Avail, обычно на 8%.

В моем случае, поскольку раздел довольно большой, потеря дискового пространства довольно существенная, поэтому изменим размер зарезервированного пространства до 2% (260GB должно быть более чем достаточно...)

Отмонтируем раздел:

# umount /dev/raid5/raid5

С помощью утилиты tunefs изменим размер зарезервированного дискового пространства:

# tunefs -m 2 /dev/raid5/raid5
tunefs: minimum percentage of free space changes from 8% to 2%
tunefs: should optimize for space with minfree < 8%

Монтируем раздел:

# mount -t ufs /dev/raid5/raid5 /raid5

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

# df -h

Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0a    446G    4,4G    405G     1%    /
devfs               1,0K    1,0K      0B   100%    /dev
/dev/raid5/raid5     13T    8,0K     13T     0%    /raid5

Поскольку в даном выводе размер зарезервированного пространства не подсчитать, ознакомимся с выводом утилиты df без ключа -h:

# df

Filesystem         1K-blocks    Used       Avail Capacity  Mounted on
/dev/mirror/gm0a   467188468 4627044   425186348     1%    /
devfs                      1       1           0   100%    /dev
/dev/raid5/raid5 14191346200       8 13907519268     0%    /raid5

Посчитаем процентное соотношение:

13907519268 х 100 / 14191346200 = 97,99

Получается 98% доступно... Все сходится.

Также стоит обратить внимание еще на такой момент. При уменьшении зарезервированного дисткового пространства до 5% и ниже, FFS отключает алгоритм оптимизации выделения свободных блоков, что приводит к росту фрагментации, росту затрат дискового пространства при расположении файлов (из-за неоптимального расположения, части блоков остаются не занятыми, если файл не занимает его целиком) и, теоретически, к снижению скорости чтения. Здесь стоит подумать и выбирать: оставить зарезервированное пространство, либо отказываться от него и иметь возможность заюзать лишние гигабайты, и получить выше перечисленные проблемы.

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

Nslookup - not found (FreBSD11)

muff — Tue, 26 Jun 2018 11:34:12 +0000

Как оказалось, в FreeBSD 11 отсутствует утилита nslookup, которая ранее присутствувала в базовой системе (в FreeBSD 10.3 даная утилита еще присутствует) ... При попытке использования утилиты получаем ошибку:

# /usr/local/bin/nslookup -q=MX gmail.com
/usr/local/bin/nslookup: not found

Либо, же, если коректно настроены локации, получаем ошибку на кириллице:

# /usr/local/bin/nslookup -q=MX gmail.com
/usr/local/bin/nslookup: Команда не найдена.

Исправить ситуацию можно установкой порта bind-tools:

# cd /usr/ports/dns/bind-tools && make install clean && rehash

По завершению установки, проверяем работоспособность утилиты:

# /usr/local/bin/nslookup -q=MX gmail.com

Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
gmail.com       mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.

Authoritative answers can be found from:

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

NConf - Cannot open main configuration file

muff — Mon, 18 Jun 2018 20:11:32 +0000

По материалах статьи "Nagios 3.x + NConf - настройка системы мониторинга Nagios 3.x и утилиты конфигурирования NConf"...

Используя NConf в новых инсталяциях, либо же обновив на рабочем сервере Perl до версии 5.24 или выше, получаем такуо ошибку:

Reading configuration data...
Error: Cannot open main configuration file '/usr/local/www/nconf/temp/test/Default_collector.cfg' for reading!
Error processing main config file!


Error
Deployment not possible due to errors in configuration.

Скриншот даной ошибки:

Исправить ее можно следующим образом.

В файле /usr/local/www/nconf/bin/lib/NConf/ExportNagios.pm необходимо найти следующий блок (начало - строка № 1273):

foreach my $def_srv_deps_param (keys(%{$srv->[2]})){
unless($def_srv_deps_param && %{$srv->[2]}->{$def_srv_deps_param}){next}
$fattr = $def_srv_deps_param;
$fval  = %{$srv->[2]}->{$def_srv_deps_param};

И заменить следующим блоком:

foreach my $def_srv_deps_param (keys(%{$srv->[2]})){
unless($def_srv_deps_param && ${$srv->[2]}->{$def_srv_deps_param}){next}
$fattr = $def_srv_deps_param;
$fval = ${$srv->[2]}->{$def_srv_deps_param};

После внесения этих изменений NConf коректно генерирует файлы конфигурации.

GRAID5 - програмный RAID 5

muff — Sat, 27 Jan 2018 01:29:27 +0000

В одном из проектов необходимо было реализовать небольшое хранилище с минимальным резервированием (для хранения бекапов). Решение - построение програмного RAID5 на FreeBSD. Рассматривать и сравнивать типы RAID не будем, рассмотрим только реализацию даной задачи.

Итак, диски присутствующие в системе:

# sysctl kern.disks
kern.disks: ada0 aacd3 aacd2 aacd1 aacd0

ada0 - диск, на который установлена система (FreeBSD 11.1 amd64)
aacd3 aacd2 aacd1 aacd0 - диски, подключенные через SAS-контроллер, именно из них и будем собирать RAID5.

FreeBSD поддерживает организацию RAID5 двумя менеджерами дискового пространства: VINUM и GEOM. Остановимся на реализации с помощью GEOM.

Чтобы задействовать функционал GEOM RAID5, необходимо выполнить установку порта graid5. Стоит отметить, что для сборки graid5 требуется наличие исходных текстов, поэтому предварительно оновим src:

# svnlite checkout svn://svn.freebsd.org/base/releng/11.1/ /usr/src

После этого выполним установку graid5:

# cd /usr/ports/sysutils/graid5 && make install clean && rehash

Создадим директорию, куда в дальнейшем будем монтировать наш RAID5:

# mkdir /raid5

Создаем сам массив:

# graid5 label -v -s 256k raid5 /dev/aacd0 /dev/aacd1 /dev/aacd2 /dev/aacd3
Metadata value stored on /dev/aacd0.
Metadata value stored on /dev/aacd1.
Metadata value stored on /dev/aacd2.
Metadata value stored on /dev/aacd3.
Wasting 1046528 bytes (>=0GiB).
Done.

256k - задаем значение Stripe Size (размер блока данных, записываемый на каждый диск RAID-массива в каждый stripe, тоесть мы будем записывать/читать данные блоками по 256k)
raid5 - указываем название массива
/dev/aacd0 ... /dev/aacd3 - перечисляем устройства, которые добавляем в массив

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

# newfs /dev/raid5/raid5

Примонтируем созданный раздел к ранее созданной нами директории:

# mount -t ufs /dev/raid5/raid5 /raid5

Также добавим запись в fstab, чтобы раздел монтировался при загрузке системы:

# echo '/dev/raid5/raid5 /raid5 ufs rw 2 2' >> /etc/fstab

И добавим загрузку модуля geom_raid5.ko при старте системы:

# echo 'geom_raid5_load="YES"' >> /boot/loader.conf

На этом все...

Проверяем статус массива:

# graid5 status

       Name          Status  Components
raid5/raid5  REBUILDING HOT  aacd0 (115764101120 / 2% (p:192))
                             aacd1 (115764101120 / 2% (p:192))
                             aacd2 (115764101120 / 2% (p:192))
                             aacd3 (115764101120 / 2% (p:192))

Идет пересборка... По завершению пересборки статус массива изменится на COMPLETE:

# graid5 status

       Name         Status  Components
raid5/raid5  COMPLETE CALM  aacd0
                            aacd1
                            aacd2
                            aacd3

Перезагружаем систему, чтобы убедиться, что после старта массив запустится в штатном режиме:

# reboot

После перезагрузки массив работает в штатноме режиме, все в порядке. На этом настройка завершена.

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

# graid5 insert raid5 /dev/aacd3

raid5 - название нашего массива
/dev/aacd3 - диск, который мы заменили

Ну и фактический результат проверки скорости записи/чтения на массив, выполненый с помощью утилиты dd.

Проверяем скорость записи:

# dd if=/dev/zero of=/raid5/test_file.zero bs=100M count=100
100+0 records in
100+0 records out
10485760000 bytes transferred in 101.761061 secs (103042951 bytes/sec)

Проверяем скорость чтения:

# dd if=/raid5/test_file.zero of=/dev/null
20480000+0 records in
20480000+0 records out
10485760000 bytes transferred in 23.882999 secs (439047037 bytes/sec)

FreeBSD - как работает система портов

muff — Tue, 03 Oct 2017 15:24:04 +0000

Используя FreeBSD, софт я устанавливаю именно из системы портов. Дерево портов расположено в каталоге /usr/ports
В каталоге портов, кроме самого дерева портов, находятся следующие файлы:

CHANGES - перечислены изменения, произведенные в инфраструктуре "портов" FreeBSD
COPYRIGHT - содержит информацию о лицензировании для коллекции "портов" в целом
GIDs - содержит перечень всех числовых групповых идентификаторов (GID), используемых программным обеспечением в коллекции "портов" (чтобы избежать путаницы и порты не использовали одну и туже учетную запись для разных целей)
KNOBS - содержит перечень всех параметров настройки, доступных в коллекции "портов"
LEGAL - содержит список всех правовых ограничений в программном обеспечении, включенном в коллекцию "портов"
MOVED - содержит список "портов", которые были перемещены из одной категории в другую
Makefile - содержит высокоуровневые инструкции для всей коллекции "портов" в целом
каталог Mk - содержит подробные низкоуровневые инструкции для всей коллекции "портов" в целом
README - содержит описание верхнего уровня организации коллекции "портов"
каталог Templates - содержит заготовки файлов, используемые другими разделами коллекции портов
каталог Tools - содержит программы, сценарии и другие средства автоматизации, которые в основном используются разработчиками "портов"
UIDs - содержит перечень всех числовых идентификаторов пользователей (UID), используемых программным обеспечением в коллекции "портов"
UPDATING - содержит примечания, используемые при обновлении программного обеспечения
каталог distfiles - содержит исходный код программного обеспечения, устанавливаемого из "портов"
INDEX-x - содержит список всех "портов" в алфавитном порядке

Для загрузки, а также поддержания дерева портов в актуальном состоянии используется утилита portsnap.

Поиск определенного порта можно выполнить несколькими способами.

Если полностью известно имя порта, можно воспользоваться коммандой whereis:

# whereis apache24
apache24: /usr/ports/www/apache24

Более расширенный поиск по портам можно выполнить, находясь в каталоге /usr/ports:

# cd /usr/ports

# make search name=apache24

# make search key=apache24

Отличие между этими коммандами в том, что name ищет вхождение только в названии порта, а key - в именах портов, комментариях, описаниях и зависимостях.

Можно собрать в один html-файл список всех установленных портов с зависимостями и т.д., ссылки на справочные материалы, etc. Для этого нужно выполнить в каталоге /usr/ports такую комманду:

# make readmes

Чтобы установить определенный порт, мы выполняем в его каталоге комманду make install clean. Однако не все так просто. FreeBSD после этой комманды выполняет последовательно следующие этапы:

make config - задание или изменение текущих настроек
make fetch - после настройки "порта" система отыскивает предопределенный список сайтов Интернета, откуда можно получить исходный код и выполняет его загрузку
make checksum - подтверждает, что цифровая подпись файла distfile соответствует подписи из файла distinfo "порта"
make extract - разворачивает и извлекает скачанный код
make patch - накладывает на исходный код в рабочем каталоге все патчи, имеющиеся в составе "порта"
make depends - проверяется зависимость "порта" от любых других программ
make configure - проверяет необходимость запуска сценария configure. Это отдельный этап, отличный от make config
make build - происходит компиляция проверенного, извлеченного и исправленного программного кода
make install - устанавливается программа, а ее наличие регистрируется в /var/db/pkg

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

make showconfig — показать текущие опции сборки порта
make rmconfig — удалить все текущие настройки для порта
make showconfig-recursive — показать настройки для текущего порта и всех зависимостей
make config-recursive — задать настройки для текущего порта и всех зависимостей
make rmconfig-recursive — удалить настройки для текущего порта и всех зависимостей
make config-conditional — пропустить задание опций для портов, у которых уже были заданы требуемые опции
make print-index — удобный для чтения индекс
make deinstall - удаление порта
make reinstall - выполняет повторную установку порта
make clean - очистка собранного порта
make distclean - удалит ненужные distfiles текущего "порта" вместе со всеми зависимостями.

Force10 - управление только с разрешенных IP

muff — Mon, 25 Sep 2017 20:52:45 +0000

По просьбе знакомого, решил разобраться, почему коммутатор Force10 S4810 только через нескольких попыток "разрешает" подключиться по telnet или ssh для управления. После подключения никаких "залипаний" и задержек в работе комутатора не замечалось...

Просматривая логи, обнаруживаем много вхождений ошибочной авторизации с разных IP-адресов. Тоесть, проблема в следующем... Force10 S4810 - это L3 (Layer3) коммутатор, который поддерживает маршрутизацию и IP-интерфейсы соответственно. В даном случае на коммутаторе присутствуют маршрутизируемые IP-адреса, доступные из сети Internet. Соответственно, имеем банальный brute force из бот-нетов, которые "долбят" комутатор своими подключениями, занимая все свободные VTY (VirtualTeletYpe - виртуальный интерфейс, который обеспечивает удаленный доступ к устройству). В этой модели коммутатора их десять.

Решением вопроса будет ограничение доступа к VTY коммутатора только с разрешенных IP-адресов. Сделать это не так и сложно.

Подключаемся к коммутатору через telnet или ssh.

Переходим в режим конфигурирования:

S4810# configure terminal

Создаем access-list с разрешенными IP-адресами/сетями. Не забываем, что в ACL политика по умолчанию - запретить все, тоесть в конце любого ACL есть невидимое правило "deny ip any any". Соответвенно, достаточно добавить в access-list IP-адреса, с которых мы будем подключаться, а все остальные будут блокироваться:

S4810(conf)# ip access-list standard VTY_ACCESS
S4810(config-std-nacl)# remark 0 Deny access to switch
S4810(config-std-nacl)# seq 10 permit 10.227.206.0/24
S4810(config-std-nacl)# seq 15 permit 10.209.139.0/24
S4810(config-std-nacl)# seq 20 permit 10.229.67.0/23
S4810(config-std-nacl)# seq 25 permit 10.168.207.0/23
S4810(config-std-nacl)# seq 30 permit 10.105.41.0/24
S4810(config-std-nacl)# exit

После создания access-list необходимо "наложить" его на VTY:

S4810(conf)# line vty 0 9
S4810(config-line-vty)# access-class VTY_ACCESS
S4810(config-line-vty)# exit

Выходим из режима конфигурации и сохраняем изменения:

S4810(conf)# exit
S4810# write memory

MySQL - установка timezone

muff — Sat, 19 Aug 2017 21:28:02 +0000

При установке MySQL не заполняет таблицы time_zone. Этих таблиц в MySQL несколько:

time_zone
time_zone_leap_second
time_zone_name
time_zone_transition
time_zone_transition_type

Соответственно, данные о символьных временных зонах недоступны. Тоесть, если отпрвить MySQL комманду

SET GLOBAL time_zone = "Europe/Kiev";

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

Эту ошибку довольно легко исправить... Заполнить таблицы временных зон MySQL можно следующей коммандой:

# mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

Nagios - проверка времени работы системы (System Uptime)

muff — Wed, 16 Aug 2017 23:04:03 +0000

Имея в распоряжении настроенную связку Nagios + Nconf, продолжим развивать тему мониторинга разнообразных параметров. Будем мониторить время работы системы с момента загрузки системы. Чтобы "ребуты" оборудования не проходили для нас незаметно...

Проверку будем выполнять с используя расширение check_snmp. Синтаксис использования check_snmp следующий:

Usage:
check_snmp -H <ip_address> -o <OID> [-w warn_range] [-c crit_range]
[-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e retries]
[-l label] [-u units] [-p port-number] [-d delimiter] [-D output-delimiter]
[-m miblist] [-P snmp version] [-N context] [-L seclevel] [-U secname]
[-a authproto] [-A authpasswd] [-x privproto] [-X privpasswd] [-4|6]

Будем использовать следующие переменные:

10.50.10.50 - IP-адрес оборудования
public - SNMP community
2c - версия SNMP

Используя SNMP, состояние порта можно получить через OID sysUpTime.0. Пример такого запроса и ответа:

# snmpwalk -v 2c -c public 10.50.10.50 sysUpTime.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (4043391272) 467 days, 23:38:32.72

Теперь получим эту же информацию, используя check_snmp:

# /usr/local/libexec/nagios/check_snmp -H 10.50.10.50 -o sysUpTime.0 -P 2c -C public
SNMP OK - Timeticks: (4043420333) 467 days, 23:43:23.33 |

Последний штрих - укажем в комманде проверки дополнительные ключи, чтобы ограничить временные рамки, согласно которых получаем статус CRITICAL и WARNING. Если UpTime оборудования меньше 3 часов - статус CRITICAL, если UpTime меньше суток - статус WARNING. Итак:

3 часа - это 10800 секунд
24 часа - это 86400 секунд

SNMP возвращает нам значение sysUpTime.0, в формате timeticks. Timetick - это 0.01 секунды. Соответственно, необходимо перевести наше время в секундах в формат timeticks. Для этого умножаем время в секундах на 100, и получаем значение в timeticks.

Тестируем работоспособность комманды проверки:

# /usr/local/libexec/nagios/check_snmp -H 10.50.10.50 -o sysUpTime.0 -P 2c -C public -c 1080000:0 -w 8640000:0
SNMP CRITICAL - *290700* | DISMAN-EVENT-MIB::sysUpTimeInstance=290700;8640000:0;1080000:0;8640000;1080000;
# /usr/local/libexec/nagios/check_snmp -H 10.50.10.50 -o sysUpTime.0 -P 2c -C public -c 1080000:0 -w 8640000:0

SNMP WARNING - *8179000* | DISMAN-EVENT-MIB::sysUpTimeInstance=8179000;8640000:0;1080000:0;8640000;1080000;
# /usr/local/libexec/nagios/check_snmp -H 10.50.10.50 -o sysUpTime.0 -P 2c -C public -c 1080000:0 -w 8640000:0

SNMP OK - 4049137283 | DISMAN-EVENT-MIB::sysUpTimeInstance=4049137283;8640000:0;1080000:0;8640000;1080000;

Теперь, используя эту информацию, создадим в Nconf новую "Checkcommand" - "check_snmp_uptime".

Для этого в меню "Additional Items", пункт "Checkcommands" жмем кнопку "Add" и заполняем форму следующим образом:

check command name	check_snmp_uptime
default service name
check command line	$USER1$/check_snmp -H $HOSTADDRESS$ -o sysUpTime.0 -P $ARG1$ -C $ARG2$ -c $ARG3$ -w $ARG4$
default command params	!2c!public!1080000:0!8640000:0
params description	ARG1=SNMP version,ARG2=SNMP community,ARG3=Warn level,ARG4=Critical Level
amount of params	4

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

Результаты наших усилий:

Ftpd - запуск штатного FTP-сервера

muff — Sat, 01 Apr 2017 01:18:45 +0000

Иногда бывают ситуации, когда необходимо быстро поднять FTP-сервер, а громоздкие решения, такие как Proftpd и Pure-ftpd - излишни. Попробуем разобраться со штатным FTP-сервером, который идет вместе с FreeBSD - ftpd.

Создадим системного пользователя, домашним каталогом которого укажем директорию, куда необходимо попадать FTP-пользователю:

# pw useradd -n ftpuser1 -g ftp -c FTP\ user -d /ftp -s /bin/sh

где

ftpuser1 - имя пользователя
/ftp - домашний каталог

Создадим домашний каталог и установим владельцем даного каталога созданного пользователя:

# mkdir /ftp
# chown ftpuser1:ftp /ftp

Установим пароль для пользователя:

# passwd ftpuser1

Добавим в rc.conf запись о старте FTP-демона вместе со стартом системы:

# echo '# FTP Server' >> /etc/rc.conf

# echo 'ftpd_enable="YES"' >> /etc/rc.conf

Запустим FTP-сервер:

# sh /etc/rc.d/ftpd start

Вот и все... FTP-сервер готов. Обратите внимание, что не всем системным пользователям разрешен FTP-доступ. Список пользователей, которым запрещен FTP-доступ перечислен в файле /etc/ftpusers.

Подключаемся, проверяем, тестируем, etc.

Ну и финальный штрих... Если данный системный пользователь создавался только для работы по FTP, стоит запретить ему подключение по ssh:

# echo 'DenyUsers ftpuser1' >> /etc/ssh/sshd_config

# sh /etc/rc.d/sshd restart

Juniper mx80 - обновление ПО

muff — Wed, 25 Jan 2017 01:00:06 +0000

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

Итак, исходные данные: маршрутизатор Juniper серии MX, версия ПО 12.3R3.4:

> show version
Hostname: jun.domain.com
Model: mx80-t
JUNOS Base OS boot [12.3R3.4]
JUNOS Base OS Software Suite [12.3R3.4]
JUNOS Kernel Software Suite [12.3R3.4]
JUNOS Crypto Software Suite [12.3R3.4]
JUNOS Packet Forwarding Engine Support (MX80) [12.3R3.4]
JUNOS Online Documentation [12.3R3.4]
JUNOS Routing Software Suite [12.3R3.4]

На момент обновления ПО, рекомендуемая версия ПО была 13.3R8.7. Именно до такой версии и будем обновляться. Для обновления имеем следующий файл ПО: jinstall-ppc-13.3R8.7-domestic-signed.tgz. Попробуем разобраться, какое именно ПО имеем в своем распоряжении. Итак, JUNOS бывает трех типов, которые отличаются лицензией:

JUNOS Canada and U.S. (более известная как "domestic version") - ранее не предназначалась для экспорта в другие страны кроме США и Канады, но в настоящее время, в рамках контракта на поддержку, эту редакцию можно получить по дополнительному запросу в службу поддержки. Единственным условием использования является соглашение о том, что полученная копия не будет использована на территории стран из определенного списка, публикуемого государственным департаментом США.
JUNOS Worldwide (более известная как "export version" или "limited version" - поставляется вместе с оборудованием Juniper Networks. Лицензия данной редакции позволяет использовать JUNOS в любой стране, но имеет существенные ограничения на применение криптографических алгоритмов (например, отсутствует поддержка SSH).
JUNOS-FIPS — редакция, соответствующая федеральным стандартам обработки информации США.

Буквы в названии релиза имеют следующие значения:

R - релиз в котором исправлены ошибки
F - релиз в который добавлен новый функционал

Теперь несколько слов о архитектуре MX-сов... На борту имеется два имеют 2 NAND Flash (основная и резервная соответственно), которые монтируются как da0 и da1. По умолчанию, порядок загрузки маршрутизатора следующий: USB -> Nand0 -> Nand1. Если маршрутизатор не может загрузить ядро с носителя, он переходит к следующему и тд. Порядок загрузки можно изменить. Актуальный порядок загрузки можно просмотреть, выполнив в shell комманду sysctl machdep.bootdevs:

% sysctl machdep.bootdevs
machdep.bootdevs: usb,nand-flash0,nand-flash1

Если по определенным причинам Juniper загрузился с резервной NAND Flash, во время загрузки отобразится следующее сообщение: "Junos booted from alternate media". Устранить даную проблему можно попытаться простой перезагрузкой маршрутизатора и проверкой, с какой флешки загрузился маршрутизатор в даный момент. Для этого пригодятся следующие комманды shell:

sysctl machdep.currbootdev - текущий носитель, с которого загрузился маршрутизатор
sysctl machdep.bootdevs - текущий порядок загрузки маршрутизатора

Если маршрутизатор повторно загрузился с резервного носителя, необходимо в CLI выполнить комманду request system snapshot, которая скопирует активный NAND Flash на альтернативный.

Если все ok, приступаем к процедуре обновления.

Предварительно делаем snapshot рабочей системы на альтернативный носитель:

> request system snapshot

Чистим систему от "мусора" и ненужных файлов (можно предварительно просмотреть список удаляемых файлов, воспользовавшись коммандой request system storage cleanup dry-run). Если этого не сделать, возможна ситуация, когда не флеше не хватит свободного места для коректного обновления.

> request system storage cleanup

После чистки системы, загружаем любым доступным (SFTP, SCP, fetch, etc) на маршрутизатор образ JunOS в формате tgz (в моем частном случае, это jinstall-ppc-13.3R8.7-domestic-signed.tgz) и размещаем его в каталог /var/tmp.

После загрузки проверяем целостность файла, получив его контрольную сумму и сравнив с оригиналом:

> file checksum md5 /var/tmp/jinstall-ppc-13.3R8.7-domestic-signed.tgz
MD5 (/var/tmp/jinstall-ppc-13.3R8.7-domestic-signed.tgz) = bd9d4960243c26445d23a38a782a2336

Если контрольные суммы совпадают, даем комманду обновления:

> request system software add /var/tmp/jinstall-ppc-13.3R8.7-domestic-signed.tgz force no-validate reboot

Процедура обновления занимает около 5 минут, по завершению которой, маршрутизатор выполняет перезагрузку и грузится уже с новой версией ПО. Проверяем версию ПО после обновления:

> show version
Hostname: jun.domain.com
Model: mx80-t
Junos: 13.3R8.7
JUNOS Base OS boot [13.3R8.7]
JUNOS Base OS Software Suite [13.3R8.7]
JUNOS Kernel Software Suite [13.3R8.7]
JUNOS Crypto Software Suite [13.3R8.7]
JUNOS Packet Forwarding Engine Support (MX80) [13.3R8.7]
JUNOS Online Documentation [13.3R8.7]
JUNOS Services Application Level Gateways [13.3R8.7]
JUNOS Services Jflow Container package [13.3R8.7]
JUNOS Services Stateful Firewall [13.3R8.7]
JUNOS Services NAT [13.3R8.7]
JUNOS Services RPM [13.3R8.7]
JUNOS Services Crypto [13.3R8.7]
JUNOS Services SSL [13.3R8.7]
JUNOS Services IPSec [13.3R8.7]
JUNOS Routing Software Suite [13.3R8.7]

Работаем неделю-вторую на новом ПО. Если все в порядке и не появились сбои в работе, выполняем копирование активного NAND Flash на альтернативный:

> request system snapshot

P.S. Можно побаловаться незадокументированой функцией и вместе с просмотром информации о версии ПО развлечься прочтением хайку:

> show version and haiku
Hostname: jun.domain.com
Model: mx80-t
Junos: 13.3R8.7
JUNOS Base OS boot [13.3R8.7]
JUNOS Base OS Software Suite [13.3R8.7]
JUNOS Kernel Software Suite [13.3R8.7]
JUNOS Crypto Software Suite [13.3R8.7]
JUNOS Packet Forwarding Engine Support (MX80) [13.3R8.7]
JUNOS Online Documentation [13.3R8.7]
JUNOS Services Application Level Gateways [13.3R8.7]
JUNOS Services Jflow Container package [13.3R8.7]
JUNOS Services Stateful Firewall [13.3R8.7]
JUNOS Services NAT [13.3R8.7]
JUNOS Services RPM [13.3R8.7]
JUNOS Services Crypto [13.3R8.7]
JUNOS Services SSL [13.3R8.7]
JUNOS Services IPSec [13.3R8.7]
JUNOS Routing Software Suite [13.3R8.7]

No icons; no mouse
No drop down menus or fonts
CLIs are cool

NoDeny - недоступность определенного года

muff — Tue, 03 Jan 2017 18:23:06 +0000

При работе с NoDeny версий 49.x и 50.x иногда возникает проблема с ограничениями на выбор доступных дат. В исходном коде по умолчанию разрешена работа в промежутке дат 2004...2010 года, что на данный момент уже неактуально. В некоторых случаях, после внесения изменений все равно, со временем, можно "упереться" в данное ограничение. Например, как в следующем случае:

"На дворе" уже 2017 год, а в админке мы ограничены 2016-тым годом. Тоесть, когда-то уже изменялся доступный диапазон, но и он со временем стал неактуальный.

Решением даной проблемы будет внесение следующих правок в файл payshow.pl, который находится в каталоге /usr/local/nodeny/web. Редактируем строку номер 772, которая в моем случае имеет следующее значение:

$h1.="<option value=$_>".($_+1900).'</option>' foreach (108..116);

Даной строкой имеем значения 2008-2016 (добавляя 1900).

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

$h1.="<option value=$_>".($_+1900).'</option>' foreach ($year_now-5..$year_now);

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

Также изменения необходимо внести в файл calls.pl. Необходимо внести изменения в строку 666. Предыдущее значение:

$hyear.="<option value=$_>".($_+1900)."</option>" for (108..116);

Редактируем до следующего состояния:

$hyear.="<option value=$_>".($_+1900)."</option>" for ($year_now-5..$year_now);

Dovecot - настройка ACL доступа для IMAP (доступ только на чтение)

muff — Fri, 19 Aug 2016 15:59:38 +0000

Довольно часто, при работе с почтой, используется протокол IMAP (Interim Mail Access Protocol). Удобность этого протокола заключается в синхронизации, в отличии от протокола POP3 (Post Office Protocol - Version 3).

Однако, если доступ ящику имеет несколько человек (например менеджеры компании), то могут возникнуть проблемы, как случайные, так и умышленные. Самая частая: удаление сообщений на одном клиенте влечёт за собой синхронное удаление на всех активных клиентах (в том числе и на сервере).

Попытаемся избежать возможных неприятностей, если есть вероятность даной ситуации... Отталкиваемся от того, что в качестве MDA (Mail delivery agent) используем Dovecot. Воспользуемся возможностями плагина ACL (Access Control Lists).

Для подключения плагина необходимо внести изменения в конфигурационный файл dovecot.conf. Изменения касаются следующих пунктов файла конфигурации:

protocol imap
protocol lda
plugin

Даные пункты необходимо будет отредактировать до следующего состояния (или дополнить, в случае необходимости):

protocol imap {
# список плагинов (сепаратор - пробел)
mail_plugins = acl imap_acl
}

protocol lda {
# список плагинов (сепаратор - пробел)
mail_plugins = acl
}

plugin {
acl = vfile
}

Чтобы изменения вступили в силу, необходимо перезапустить dovecot:

# sh /usr/local/etc/rc.d/dovecot restart

Плагин активирован... Следующий шаг - создание acl для ящика, права которого необходимо изменить. Для этого необходимо в корневом каталоге этого ящика создать файл dovecot-acl. Тоесть, если путь к ящику /var/exim/domain/user, то путь к acl будет /var/exim/domain/user/dovecot-acl.

Синтаксис файла dovecot-acl следующий:

<identifier> <ACLs> [:<named ACLs>]

Тоесть, чтобы разрешить доступ к ящику только на чтение, достаточно создать файл dovecot-acl следующего содержания:

owner lr

Пример многострочного файла dovecot-acl:

owner lrwstipekxa
anyone lr

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

Таблица идентификаторов

group-override=group name
user=user name
owner
group=group name
authenticated
anyone (или anonymous, что равнозначно anyone)

Таблица флагов

l	lookup	Ящик виден в списке
r	read	Ящик может быть открыт на чтение
w	write	Флаги и ключевые слова сообщения могут быть изменены, за исключением «Просмотрено» и «Удалено»
s	write-seen	Флаг сообщения «Просмотрено» (\Seen) может быть изменён
t	write-deleted	Флаг сообщения «Удалён» (\Deleted) может быть изменён
i	insert	Сообщения могут быть записаны или скопированы в ящик
p	post	Сообщения могут быть размещены через LDA, например через Sieve
e	expunge	Сообщения могут быть исключены
k	create	Ящики могут быть созданы или переименованы под управлением этого ящика (переименование требует прав на удаление)
x	delete	Ящик может быть удалён
a	admin	Административные права на ящик (изменение списков ACL)

Примечание: Кроме файла dovecot-acl, в каталоге может находится кэш-файл dovecot-acl-list, его нужно удалить после внесения изменений в файле dovecot-acl.

Проверяем работоспособность правил... Для ящика разрешен доступ только на чтение. При попытке удалить письмо (используя web-интерфейс Roundсube), получаем ошибку:

Ioncube - установка ionCube Loader на FreeBSD

muff — Sat, 02 Jul 2016 18:14:34 +0000

ionCube — это популярный способ шифрования php-файлов. ionCube был создан в 2002 как инструмент для защиты программного обеспечения (написанном на PHP) от просмотра, изменения или запуска на компьютерах, без требуемой лицензии. Сама технология кодирования выросла из проекта PHP Accelerator и изначально запускалась в составе сервиса, в котором PHP-скрипты загружались, раскодировались и возвращались обратно в командную оболочку.

Попробуем установить ionCube на сервере под управлением FreeBSD. Исходные данные следующие:

# uname -srm
FreeBSD 10.3-RELEASE amd64
# php -v
PHP 5.5.37 (cli) (built: Jun 30 2016 01:19:54)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Виполним установку ionCube из системы портов:

# cd /usr/ports/devel/ioncube && make install clean && rehash

После установки порта получаем инструкции, которые необходимо выполнить:

Edit /usr/local/etc/php.ini or /usr/local/etc/php/extensions.ini
and add this three lines:

--------------------------------------------------------------------------------
[Zend]
zend_extension="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader.so"
zend_extension_ts="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader_ts.so"
--------------------------------------------------------------------------------

NOTE: If you have any Zend Extension already installed - you need put this before
existing zend_extension lines.

Добавим в php.ini следующие строки:

[Zend]
zend_extension="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader.so"
zend_extension_ts="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader_ts.so"

ВАЖНО! Если уже установлены какие-либо Zend Extension, то необходимо добавить эти строки ДО присутствующих строк zend_extension!

Проверяем, подгрузился ли модуль:

# php -v
Failed loading /usr/local/lib/php/20121212-zts/ioncube/ioncube_loader.so: /usr/local/lib/php/20121212-zts/ioncube/ioncube_loader.so: Undefined symbol "executor_globals"
PHP 5.5.37 (cli) (built: Jun 30 2016 01:19:54)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Ошибка! Решаем ее следующим образом. Удаляем строку:

zend_extension="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader.so"

А zend_extension_ts изменим в zend_extension. Тоесть, после всех редактирований php.ini получаем следующие добавленные строки:

[Zend]
zend_extension="/usr/local/lib/php/20121212-zts/ioncube/ioncube_loader_ts.so"

Проверяем:

# php -v
PHP 5.5.37 (cli) (built: Jun 30 2016 01:19:54)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
with the ionCube PHP Loader v5.0.21, Copyright (c) 2002-2016, by ionCube Ltd.

Все в порядке, ionCube PHP Loader подгружен. Ну и последний штрих... Чтобы модуль был доступен веб-серверу Apache, его необходимо будет перезапустить:

# sh /usr/local/etc/rc.d/apache24 restart