Как всегда начнем с предыстории. Необходимо было реализовать видеонаблюдение за помещением, естественно с нулевым бюджетом, а как иначе. В наличие имелся сервер с Linux на борту и домашняя usb web камера. За основу был взят программный пакет Motion. В принципе ничего сложного в настройке нет, правим пару строк в конфиге и вуаля. Писать было ни о чем. 

На днях обновил Ubuntu до версии 16.04.1 LTS и заодно, решено было обновить часть пакетов, в том числе Motion, и переделать систему видеонаблюдения. От usb камеры давно было решено отказаться, и ей на смену пришла дешевая IP камера (поддерживающая MJPEG поток) купленная на распродаже.

Отразим все на "бумаге"

Имеется:

• Сервер Linux Ubuntu 16.04.1 LTS
• Пакет Motion 3.2.12
• IP камера с поддержкой MJPEG

Требуется:

• Писать только видео (никаких фото и таймлапсов)
• Писать только по движению
• Оповещать об обнаружении движения
• Транслировать поток в реальном времени с сервера

В Ubuntu установка пакетов проста до безобразия

apt-get update && apt-get install motion

По завершении установки переходим в каталог с файлом конфигурации

cd /etc/motion
nano motion.conf

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

Сам Motion может работать одновременно с несколькими потоками (камерами для обывателя), неважно будь то IP камеры, USB камеры или иные устройства захвата видео. Да хоть все вперемешку. Самое главное, что если мы используем IP камеры, то они должны поддерживать MJPEG поток. Никакого RTSP (Real Time Streaming Protocol) Motion не поддерживает.

Файл конфигурации motion.conf представляет из себя набор основных настроек программы и настройки для первого потока. Все последующие потоки можно конфигурировать в файлах thread1.conf, thread2.conf ... thread9.conf (по умолчанию они отсутствуют) и подключать в конце файла motion.conf

Лично я предпочитаю основные настройки и настройки по умолчанию хранить в основном файле конфигурации, а настройки самих камер вынести во внешние файлы thread, по одному файлу на каждую камеру. Таким образом, не будет никакой путаницы если например камера №2 выйдет из строя и её понадобится заменить на не типичную камеру.

Основные настройки представлены в двух секциях

############################################################
# Daemon
############################################################

# Запуск в фоновом режиме (default: off)
daemon on

# Файл для хранения идентификатора процесса (default: not defined)
process_id_file /var/run/motion/motion.pid

############################################################
# Basic Setup Mode
############################################################

# Запускать в Setup-Mode, отключает режим демона. (default: off)
setup_mode off

# Путь до файла с логами. (default: not defined)
logfile /var/log/motion/motion.log

# Уровель лог сообщений [1..9] (EMR, ALR, CRT, ERR, WRN, NTC, INF, DBG, ALL). (default: 6 / NTC)
log_level 6

# Фильтр лог сообщений по типу (COR, STR, ENC, NET, DBL, EVT, TRK, VID, ALL). (default: ALL)
log_type all

Тут нас интересует только запуск программы в фоновом режиме, остальные настройки можно оставить без изменения.

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

###########################################################
# Capture device options
############################################################

# Videodevice to be used for capturing  (default /dev/video0)
# for FreeBSD default is /dev/bktr0
;videodevice /dev/video0

...

Закомментируем все настройки в этой секции, в этом файле они нам не нужны.

Далее большинство настроек мы оставим без изменения, а поправим только некоторые. Эти настройки будут общие для всех потоков.

Отключаем создание снимков при обнаружении движения. Можно указать один из режимов (first, best, center) и тогда мы будем получать по одному снимку на одно видео. Это может пригодиться в том случае, если вы собираетесь организовывать WEB доступ к архиву видеозаписей.

############################################################
# Image File Output
############################################################

# Output 'normal' pictures when motion is detected (default: on)
# Valid values: on, off, first, best, center
# When set to 'first', only the first picture of an event is saved.
# Picture with most motion of an event is saved when set to 'best'.
# Picture with motion nearest center of picture is saved when set to 'center'.
# Can be used as preview shot for the corresponding movie.
output_pictures off

Отключаем стриминг по умолчанию

############################################################
# Live Stream Server
############################################################

# The mini-http server listens to this port for requests (default: 0 = disabled)
stream_port 0

Отключаем встроенный web сервер

############################################################
# HTTP Based Control
############################################################

# TCP/IP port for the http server to listen on (default: 0 = disabled)
webcontrol_port 0

В самом конце основного файла конфигурации motion.conf имеется секция для подключения дополнительных потоков. По умолчанию файл motion.conf соответствовал файлу thread0.conf, но мы это доблестно исправили выше. Теперь нам необходимо включить в файл конфигурации файлы с настройками для работы с нашими камерами. Мы рассмотрим на примере конфигурации одной камеры, раскомментируем thread1.conf

##############################################################
# Thread config files - One for each camera.
# Except if only one camera - You only need this config file.
# If you have more than one camera you MUST define one thread
# config file for each camera in addition to this config file.
##############################################################

# Remember: If you have more than one camera you must have one
# thread file for each camera. E.g. 2 cameras requires 3 files:
# This motion.conf file AND thread1.conf and thread2.conf.
# Only put the options that are unique to each camera in the
# thread config files.
thread /etc/motion/thread1.conf
; thread /etc/motion/thread2.conf
; thread /etc/motion/thread3.conf
; thread /etc/motion/thread4.conf

Создадим файл thread1.conf

cd /etc/motion && touch thread1.conf && nano thread1.conf

Первым делом вам необходимо узнать:

• адрес MJPEG потока вашей камеры
• разрешение камеры (обычно для дешевых камер это 640х480)
• частоту кадров (у дешевых камер обычно не более 20)

# Разрешение картинки
width 640
height 480

# Частота кадров
framerate 20

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

# Сетевой адрес для захвата изображения с камеры (mjpeg поток)
netcam_url http://10.10.1.101/mjpeg.cgi

# Логин и пароль к видео потоку (only if required). Default: not defined
; netcam_userpass admin:password

Укажем подпись для камеры, это поможет быстро идентификации её местоположение (можно использовать символ перевода каретки)

# Подпись к камере (название камеры)
text_left CAMERA 1\nSH-21 STORAGE

Укажем путь до места хранения видео фрагментов (лучше создать каталог заранее)

# Путь до места сохранения видео\фото
target_dir /media/share/motion/cam1

Включаем детектор движения

# Количество изменившихся пикселей для триггера обнаружения движения
threshold 2000

У меня камера стоит под потолком, рядом со стеной с большим количеством окон. Ну и естественно окна смотрят на солнечную сторону, а это значит, что открывается прекрасный вид на быстро плывущие облака отбрасывающие тень на здание, а во время летней грозы помещение может освещаться завораживающими вспышка молний. И это все можно будет посмотреть на видео, если не добавить следующие параметры. Можно поэкспериментировать и добиться приемлемого результата для вас

# Не реагировать на резкое изменение яркости (0 - отключено, 0-100% от общего числа пикселей)
lightswitch 60

# Минимальное число кадров, в которых фиксируется движение для взведения триггера тревоги
minimum_motion_frames 5

Добавляем мертвую зону. Она позволит не создавать кучу мусора в папке с видео

# Количество секунд (мертвая зона) после окончания движения, в течении которых отключен детектор
event_gap 10

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

# Рисуем рамку вокруг движущегося объекта
locate_motion_mode on

# Стиль рамки вокруг движущегося объекта
locate_motion_style redbox

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

# Показывать количество изменившихся пикселей (используем для настройки threshold)
text_changes on

Включаем возможность стримить с сервера все происходящее на данной камере

# Настройки потока вещания (порт\качество\частота кадров\доступ только с 172.0.0.1\ограничение потока)
stream_port 8081
stream_quality 70
stream_maxrate 20
stream_localhost off
stream_limit 0

Можно (и нужно, если установлен stream_localhost off) требовать авторизацию при доступе к потоку с этой камеры из вне

# Требовать авторизацию для доступа к потоку вещания
stream_auth_method 1
stream_authentication admin:12345678

В принципе этого уже достаточно для организации работы системы и на этом этапе можно сохранить файл. Но в моем случае требуется организовать внешнюю систему оповещения. Благо Motion умеет вызывать внешние программы и передавать им различные параметры. 

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

При вызове внешнего скрипта ему можно передать следующие параметры

%Y = year
%m = month
%d = date
%H = hour
%M = minute
%S = second,

%v = event
%q = frame number
%t = thread (camera) number
%D = changed pixels
%N = noise level

%i and %J = width and height of motion area
%K and %L = X and Y coordinates of motion center

%C = value defined by text_event
%f = filename with full path
%n = number indicating filetype

# Both %f and %n are only defined for on_picture_save,
# on_movie_start and on_movie_end
# Quotation marks round string are allowed.

Добавим строку вызова внешнего исполняемого файла с передачей ему параметрами - номер камеры и координаты центра начала движения

# При обнаружении движения запускать внешний скрипт
on_event_start /etc/motion/zone_alarm.sh %t %K %L

Содержимое zone_alarm.sh

#!/bin/bash

CAM="$1"
X="$2"
Y="$3"

if (("$CAM" == "1"))
then
        if (("$X" < "320" && "$Y" < "240"))
        then
                beep -f 4000 -l 200 -n -f 4000 -l 200 -n -f 4000 -l 200 -n -f 4000 -l 200 -n -f 4000 -l 200
        fi
fi

В данном случае происходит звуковое оповещение на самом сервере с помощью утилиты beep, по умолчанию её может и не быть

apt-get install beep

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

Необходимо разрешить Motion работать в режиме демона, для этого правим файл /etc/default/motion

# set to 'yes' to enable the motion daemon
start_motion_daemon=yes

Проверяем работу

/etc/init.d/motion start

Что мы имеем на выходе

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

crontab -e

И добавим запись, которая будет выполняться ежедневно в 23:30 и искать файлы формата .avi в указанном нами каталоге и если найденный файл существует более 14 суток, то он удаляется. Естественно если камера стоит в проходном месте, то стоит уменьшить время жизни видео.

30 23 * * * find /media/share/motion/ -name '*.avi' -mtime +14 -exec rm {} \;

На этом настройка завершена.

PS: в файле motion.conf можно найти еще очень много интересных параметров!

Сегодня пойдет речь о том, как переправлять данные с MQTT брокера в базу данных MySQL. Транспортировать будем как сами адреса, так и значения всех топиков, на которые оформлена подписка. Данную задачу нельзя назвать распространенной, но все же, она имеет место быть и может пригодиться в том случае, если данные востребованы в системах не способных работать с MQTT протоколом самостоятельно или брокер находится в изолированной системе, а данные востребованы, например, в GUI за её приделами.

Для осуществления задуманного нам потребуется самостоятельный процесс, который сыграет роль транспортного узла между MQTT брокером и базой данный MySQL. А значит, его придется где-то держать. В моем случае, это сервер под управлением операционной системой Linux Ubuntu 16.04.3 и дальнейшее описание будет под неё, но для других ОС действия аналогичные.

Сам демон будет написан на Python и для его работы нам потребуется:

1. python3
2. python-pip
3. python-dev
4. libmysqlclient-dev
5. библиотека paho-mqtt для python https://pypi.python.org/pypi/paho-mqtt
6. библиотека mysqlclient для python https://github.com/PyMySQL/mysqlclient-python

Но начнем мы, в первую очередь, с подготовки базы данных.

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

mysql -uroot -p

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

mysql> source /media/mqttMySqlClient.sql

После этого будет получен следующий результат:

1. Создана база (схема) с именем mqtt
2. Пользователь с именем mqtt-agent и паролем p@$$w0rd имеющий возможность подключаться с внешних адресов
3. Пользователю будут назначены ограниченные права (только EXECUTE) в этой схеме
4. Будет добавлена процедура update_topic, на которую ляжет задача добавления и обновления данных
5. Будет добавлена функция get_topic для упрощения поиска данных

На тот случай, если Вы захотите внести изменения или создать все ручками, рассмотрим содержимое sql файла.

Если схема mqtt не существует, она будет создана

CREATE DATABASE IF NOT EXISTS `mqtt`;

Аналогичным образом будет создан пользователь mqtt-agent. Если необходимо конкретизировать, с какого адреса будет производиться подключение под этим пользователем, то замените % на доменное имя или ip адрес хоста. Если планируется использовать демона на том же сервере где установлен MySQL, замените % на localhost. Также разрешено не более 2 активных подключений, измените это значение на необходимое Вам.

CREATE USER IF NOT EXISTS 'mqtt-agent'@'%' IDENTIFIED BY 'p@$$w0rd' WITH MAX_USER_CONNECTIONS 2;

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

GRANT EXECUTE ON `mqtt`.* TO 'mqtt-agent'@'%';

Переходим к работе с самой схемой

USE `mqtt`;

Будет создана таблица topics со следующей структурой.

• md5 - содержит уникальный одноименный хеш полученный из полного адреса топика. Именно по этому ключу и будет производиться поиск данных. Почему именно по нему, а не по самому имени? Дело в том, что md5 хеш имеет фиксированную, заранее известную, длину, что нельзя сказать о имени топика. Именно это ограничение не позволит сделать имя топика первичным ключом и явно идентифицировать данные в таблице.
• time - содержит UNIX время добавления/обновления данных по конкретному топику (по умолчанию GMT+0)
• topic - адрес топика. В контексте, упомянутого ранее, поля md5, не несет для нас никакой смысловой нагрузки.
• value - данные опубликованные в топике.

DROP TABLE IF EXISTS `topics`;
CREATE TABLE `topics` (
  `md5` varchar(32) NOT NULL,
  `time` bigint(20) DEFAULT NULL,
  `topic` text,
  `value` text,
  PRIMARY KEY (`md5`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Теперь необходимо создать хранимые процедуры и функции, но сделать это будет невозможно из-за присутствие в их синтаксисе разделителя совпадающего с концом данных в sql запросе - ";" Чтобы избежать этот неловкий момент, изменяем разделить на произвольный.

DELIMITER $$

Создает процедуру update_topic. Она принимает в качестве входных параметров два значения, адрес топика и опубликованные данные. Оба параметра являются текстовыми. Процедура, вычисляет md5 хеш из адреса топика и уже по нему производит поиск записи в таблице. Если запись не будет найдена, она будет создана, в противном случае данные в поле value будут обновлены. Данная процедура должна ускорить работу демона и избавить его от задержек, которые были бы неминуемы при выполнении этих же запросов на стороне клиента.

DROP PROCEDURE IF EXISTS `update_topic`$$
CREATE DEFINER=CURRENT_USER() PROCEDURE `update_topic`(topic text, value text)
BEGIN
	declare nMD5 varchar(32) default md5(topic);
	declare NUM bit;
	declare uTime bigint(20) default UNIX_TIMESTAMP();

	SELECT COUNT(t.md5) INTO NUM FROM topics t WHERE t.md5 = nMD5;
	if NUM <> 1 then
		INSERT INTO topics VALUES(nMD5, uTime, topic, value);
	else
		UPDATE topics t SET t.time = uTime, t.value = value WHERE t.md5 = nMD5;
	end if;
END$$

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

DROP FUNCTION IF EXISTS `get_topic`$$
CREATE DEFINER=CURRENT_USER() FUNCTION `get_topic` (topic text)
RETURNS text
BEGIN
	declare hMD5 varchar(32) default md5(topic);
	declare topicValue text;
	SELECT t.value INTO topicValue FROM topics t WHERE t.md5 = hMD5;
RETURN topicValue;
END$$

И в завершении всего, будет восстановлено стандартное значение разделителя.

DELIMITER ;

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

Переходим к демону

В первую очередь устанавливаем необходимые пакеты.

sudo apt-get install python3 python-pip python-dev libmysqlclient-dev

Устанавливаем недостающие библиотеки для Python

pip install paho-mqtt mysqlclient

Добавим пользователя из-под которого будет запускаться демон

sudo useradd --shell /usr/sbin/nologin --system mqtt-agent

Выставляем все необходимые права (каталог /media как пример)

sudo chown mqtt-agent:mqtt-agent /media/mqttMySqlClient.py
sudo chmod 0700 /media/mqttMySqlClient.py

Добавляем демона в автозагрузку через планировщик задач и от имени созданного пользователя

sudo crontab -u mqtt-agent -e

Добавляем в конец следующую запись

@reboot /media/mqttMySqlClient.py start

Запускаем демона от имени все того же пользователя

sudo -u mqtt-agent /media/mqttMySqlClient.py start

Это основное, что требуется сделать на сервере для организации работы демона.

Переходим к разбору настроек программы

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

""" Настройки MQTT """
mqtt_server = "mqtt.it4it.club"
mqtt_port = 1883
mqtt_login = ""
mqtt_password = ""
mqtt_client_id = "mqttMySqlClient"

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

""" Список топиков для подписки """
subscribe = {
    '$SYS/#',
    '#',
}

Список топиков для подписки указывается через запятую и в кавычках.

""" Настройки MySQL """
mysql_host = "127.0.0.1"
mysql_port = 3306
mysql_user = "mqtt-agent"
mysql_passwd = "p@$$w0rd"
mysql_schema = "mqtt"
mysql_log_file = "/var/log/mqttMySqlClient.log"

Настройки подключения с MySQL серверу также не должны вызывать вопросов.

""" Настройки общие """
pid_file = "/tmp/mqttMySqlClient.pid"

Последний параметр указывает на размещение .pid файла демона.

Команды управления классические

• start - запуск в режиме демона
• stop - остановка в режиме демона
• restart - перезапуск в режиме демона
• window - запуск в оконном режиме, также позволяет запускать процесс в операционных системах Windows

После запуска, демон пытается установить связь с MQTT брокером и пока это не произойдет, связь с MySQL сервером устанавливаться не будет. Если во время работы, связь с брокером будет потеряна то в принудительном порядке, будет разорвано соединение с базой данных. Таким образом, по активным сессиям MySQL сервера можно судить о наличии связи у демона с брокером. Во время простоя, а в нашем случае, это отсутствие потока данных от брокера, для проверки связи с сервером базы данных будет использована процедура эмуляции ping для MySQL сервера. Она представляет из себя простую арифметическую задачу на сложение не приводящей к работе с данными в базе. Операция выполняется крайне быстро и её удачное выполнение сигнализирует клиенту о наличии связи с базой, а базе об активности клиента. В связи с этим, периодическая активность клиента при отсутствие данных от брокера, является показателем нормальной работы.

И на последок

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

select mqtt.get_topic('$SYS/broker/version');

В ответ мы получим

+---------------------------------------+
| mqtt.get_topic('$SYS/broker/version') |
+---------------------------------------+
| mosquitto version 1.4.8               |
+---------------------------------------+
1 row in set (0,00 sec)

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

Файлы проекта: 

PS: Это тестовая версия демона и возможно она будет претерпевать некоторые изменения.

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

Выбираем самый короткий путь, логинимся на сервере под пользователем root

Создаем сертификат сроком на 100 лет. Почему на такой долгий? Да потому, что через год никто не вспомнит о том, что его надо пересоздать, да и важность ресурса далеко не банковского уровня.

openssl req -x509 -nodes -days 36500 -newkey rsa:1024 -keyout /etc/ssl/private/apache.key -out /etc/ssl/certs/apache.pem

Таким образом, сертификат стандарта X509 и сроком на 100 лет будет записан в файл /etc/ssl/private/apache.key, а его 1024 битный ключ в файл /etc/ssl/certs/apache.pem

В процессе создания сертификата будут сыпаться различные вопросы от утилиты, можно пропускать все (прожимаем <ENTER>), кроме имени домена для которого этот сертификат и предназначается. Отметим, что пароль к сертификату запрашиваться не будет, об этом мы позаботились с помощью параметра -nodes. Да и пароль нам и не нужен, в противном случае его придется вводить при каждом запуске Apache.

Теперь необходимо поправить ssl профиль для Apache.

nano /etc/apache2/sites-available/default-ssl.conf

Нам необходимо отключить поддержку SSLv2 и SSLv3 из-за проблем с безопасностью. Добавляем, а если он уже есть, то правим следующий параметр

SSLProtocol all -SSLv2 -SSLv3

Указываем откуда подтянуть сертификат с ключом и сохраняем профиль

SSLCertificateFile /etc/ssl/certs/apache.pem
SSLCertificateKeyFile /etc/ssl/private/apache.key

Выбираемся обратно в консоль и подключаем модуль SSL к Apache, а заодно подключаем наш обновленный профиль

a2enmod ssl
a2ensite default-ssl.conf

Финалом торжества станет перезапуск сервера

/etc/init.d/apache2 restart

Если понадобится принудительно перенаправлять потребителей трафика с http на https протокол, то самым простым способом будет использование mod_rewrite

a2enmod rewrite
/etc/init.d/apache2 restart

После идем в нужный каталог Apache и создаем там конфигурационный файл .htaccess со следующим содержимым

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Если не отрабатывает ни одно из правил, описанных в .htaccess, то вероятнее всего, в конфигурации Apache стоит запрет на его чтение. Идем в файл конфигурации

nano /etc/apache2/apache2.conf

Ищем описание настроек безопасности для корневого каталога Вашего web сервера

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

И разрешаем всем описанным в фале .htaccess директивам отмену ранее установленных правил доступа

AllowOverride All

И снова перезапускаем Apache.

Не забудьте обновить сертификат после окончания срока его действия, если здоровье еще будет позволять. 

В Linux имеются два замечательных файла, названия которых говорят сами за себя:

1. /etc/hosts.allow
2. /etc/hosts.deny

Синтаксис файлов:

<служба или ALL>: <IP, имя хоста или подсеть>

Я использую демона tftpd для организации TFTP сервера.

Идем в /etc/hosts.allow и добавляем в конец файла секцию описывающую каким хостам разрешено работать с демоном:

# ---------------------------------------------------------------------------
# TFTP
# ---------------------------------------------------------------------------

# router 1
in.tftpd: 10.10.10.1
# router 2
in.tftpd: 10.10.10.2
# router 3
in.tftpd: 10.10.10.3
# router 4
in.tftpd: 10.10.10.4

Теперь идем в /etc/hosts.deny и добавляем секцию в которой красуется короткая и лаконичная запись "ты кто такой давай до свидания":

# ---------------------------------------------------------------------------
# TFTP
# ---------------------------------------------------------------------------

in.tftpd: ALL

Естественно Вы можете указать любую службу: smtp, http, mysqld, sshd ...

Spawn

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

Добавим логирование событий чтобы знать о всех неудачных попытках подключения к TFTP серверу. Модифицируем /etc/hosts.deny

# ---------------------------------------------------------------------------
# TFTP
# ---------------------------------------------------------------------------

in.tftpd: ALL : spawn /bin/echo $(/bin/date +"%%d-%%m-%%y %%T") отказано в доступе %h>>/var/log/tftp.access.log

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

1. %a  Адрес клиента
2. %A  Адрес сервера
3. %c  Информация о клиенте: user@host, user@address, имя хоста или просто адрес
4. %d  Имя демона/процесса
5. %h  Имя хоста клиента или адрес, если имя хоста недоступно
6. %H  Имя хоста сервера или адрес, если имя хоста недоступно
7. %n  Имя хоста клиента (либо 'unknown' или 'paranoid')
8. %N  Имя хоста сервера (либо 'unknown' или 'paranoid')
9. %p  Идентификатор процесса (PID)
10. %s  Информация о сервере: daemon@host, daemon@address или просто имя демона
11. %u  Имя пользователя клиента (или 'unknown')
12. %%  Одиночный символ '%'

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

Полученный в итоге файл можно скормить Zabbix'у и сигнализировать при его изменении администратору сервера!

В моем случае SNMP протокол используется для мониторинга различного оборудования Ubuntu Server'ом. 

В Debian установка выглядит весьма тривиально

sudo apt-get install snmp

Если необходим еще и демон, то

sudo apt-get install snmp snmpd

В пакет snmp также входит всем известная утилита snmpwalk

файлы конфигурации (из названия понятно за что отвечает каждый из них)

1. /etc/snmp/snmp.conf
2. /etc/snmp/snmpd.conf
3. /etc/snmp/snmptrapd.conf

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

snmpwalk -v 2c -c public 127.0.0.1 iso.3.6.1.2.1.1.3.0

Если заглянуть в snmp.conf, то там красуется печальный, но вполне обоснованный заголовок

# As the snmp packages come without MIB files due to license reasons, loading
# of MIBs is disabled by default. If you added the MIBs you can reenable
# loading them by commenting out the following line.

Что нам требуется, то и загружаем самостоятельно в каталог /usr/share/mibs, с последующим занесением имени базы в данный файл.

Можно установить дополнительный пакет который, по нашему требованию, будет закачивать различные MIB'ы.

 sudo apt-get install snmp-mibs-downloader

Для обновления списка баз используем

 sudo /usr/bin/download-mibs

Выглядит это следующим образом

Downloading documents and extracting MIB files.
This will take some minutes.

In case this process fails, it can always be repeated later by executing
/usr/bin/download-mibs again.

RFC1155-SMI: 119 lines.
RFC1213-MIB: 2613 lines.
NOTE: SMUX: ignored.
SMUX-MIB: 158 lines.
CLNS-MIB: 1294 lines.
RFC1381-MIB: 1007 lines.
RFC1382-MIB: 2627 lines.
RFC1414-MIB: 131 lines.
SNMPv2-PARTY-MIB: 1410 lines.
SNMPv2-M2M-MIB: 807 lines.
MIOX25-MIB: 708 lines.
PPP-LCP-MIB: 764 lines.
PPP-SEC-MIB: 289 lines.
PPP-IP-NCP-MIB: 203 lines.
PPP-BRIDGE-NCP-MIB: 429 lines.
FDDI-SMT73-MIB: 2126 lines.
TOKEN-RING-RMON-MIB: 2302 lines.
SOURCE-ROUTING-MIB: 450 lines.
DECNET-PHIV-MIB: 3030 lines.
DSA-MIB: 642 lines.
DPI20-MIB: 47 lines.
IBM-6611-APPN-MIB: 5112 lines.
DNS-SERVER-MIB: 1078 lines.
DNS-RESOLVER-MIB: 1196 lines.
UPS-MIB: 1899 lines.
CHARACTER-MIB: 646 lines.
RS-232-MIB: 788 lines.
PARALLEL-MIB: 286 lines.
SNA-NAU-MIB: 2765 lines.
SIP-MIB: 1099 lines.
Modem-MIB: 1340 lines.
...

 

После данной процедуры каталог /usr/share/mibs будет под завязку полон.

В файле конфигурации можно указать какие MIB'ы использовать просто перечислив их

 

mibs :SNMPv2-MIB:IP-MIB:IF-MIB:UPS-MIB

или для использования всех, указать

mibs :ALL

 

Теперь можно использовать иерархическое пространство в запросах. 

snmpwalk -v 2c -c public 127.0.0.1 SNMPv2-MIB::sysUpTime.0

На мой взгляд, в каталоге /usr/share/mibs стоит держать только те MIB'ы которые необходимы для работы. Можно создавать собственные базы или использовать те, что предоставляет изготовитель используемого Вами оборудования.

Что касается демона snmpd, то по умолчанию он обслуживает только кольцевой ip со стандартным community public. Раскомментируем следующую строку для доступа через любой сетевой интерфейс или укажем явно необходимый адрес.

agentAddress udp:161,udp6:[::1]:161

Для изменения/добавления community смотрим в ветку ACCESS CONTROL.

Формат записи

[[rocommunity[6]]|[rwcommunity[6]] [community name] [source [OID | -V VIEW [CONTEXT]]]

1. rocommunity - доступ на чтение
2. rwcommunity - полный доступ

rocommunity secret1 192.168.1.10
rwcommunity secret2 192.168.1.10
rocommunity secret3 192.168.1.11 .1.3.6.1.2.1.1.3.0

Все изменения применяются только после перезапуска демона

service snmpd restart

Подробное описание можно найти тут http://www.net-snmp.org/docs/man/snmpd.conf.html

PS: об остальных возможностях поговорим позже.