Компы и автомобили (Posts about Zabbix)

Zabbix agent + SElinux = hardcore...

at-hacker — Fri, 28 Jul 2017 09:14:00 GMT

Вынужден тут приобщаться к странному и алогичному миру линуксовых ОС. И поимел сегодня исключительно волнующий опыт настройки мониторинга контрольной суммы файла /etc/shadow в CentOS посредством Zabbix. Казалось бы, всё просто — файл доступен по чтению только руту, пропиши в sudoers что-то вроде: в CentOS посредством Zabbix. Казалось бы, всё просто — файл доступен по чтению только руту, пропиши в sudoers что-то вроде:

zabbix  ALL=(ALL)       NOPASSWD: /usr/bin/sha256sum /etc/shadow

, а в userparameters:

UserParameter=shadow.checksum,sudo sha256sum /etc/shadow|cut -d « » -f 1

и будет тебе щастье. Но щастья что-то не наступило... Параметр всё равно оставался в статусе «Unsupported», с мотивацией:

sh: /usr/bin/sudo: Permission denied

Разборки показали, что sudo жалуется, что у пользователя zabbix не установлен shell. Точнее, установлена оболочка / не установлен shell. Точнее, установлена оболочка /sbin/nologin. ОК, патчим . ОК, патчим sudoers::

Defaults:zabbix !requiretty
zabbix  ALL=(ALL)       NOPASSWD: /usr/bin/sha256sum /etc/shadow

Лучше стало, но не сильно: «sudo: unable to open audit system: Permission denied». «Эге!», — подумал я, «стопудово дело в SELinux». И пошёл читать ». «Эге!», — подумал я, «стопудово дело в SELinux». И пошёл читать grep AVC /var/log/audit/log. И действительно, там было понаписано всякое. Например:. И действительно, там было понаписано всякое. Например:

type=AVC msg=audit(1501160287.479:190259): avc:  denied  { execute } for  pid=21472 comm=«sh» name=«sudo» dev=«dm-0» ino=50709281 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file

И вот тут началось бесконечное порево с правкой политик SELinux для того, чтобы в конечном итоге параметр заработал. Заняло это чистого времени часа 4. Текст модуля политики разросся раза в два :-)

На каком-то этапе упёрся, так как параметр всё ещё не работал, но в /var/log/audit/audit.log никаких новых надписей о запрещённых операциях не появилось. Исследование показало, что в SELinux определённые сообщения подавляются. Чтобы это временно отключить, необходимо выполнить команду: никаких новых надписей о запрещённых операциях не появилось. Исследование показало, что в SELinux определённые сообщения подавляются. Чтобы это временно отключить, необходимо выполнить команду:

semodule -DB

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

Вообще, на CentOS 7 довольно сильно пришлось докручивать политики SELinux под zabbix-агента. Началось с того, что агент просто не запускался, так как SELinux не давал ему права на установку лимитов. Пришлось строить кастомную политику.

Потом выяснилось, что у агента нет прав на запись в каталог /tmp, а у нас вызывается скрипт мониторинга nginx, который создаёт кэш-файл в /tmp. С одной стороны, проще было бы класть временный файл куда-нибудь в каталоги самого заббикса. Но с другой — файл-то временный, и самое ему место в /, а у нас вызывается скрипт мониторинга nginx, который создаёт кэш-файл в /tmp. С одной стороны, проще было бы класть временный файл куда-нибудь в каталоги самого заббикса. Но с другой — файл-то временный, и самое ему место в /tmp..

В итоге получился вот такой модуль политики:

cat zabbix-agent.te

module zabbix-agent 1.0;

require {
        type user_tmp_t;
        type tmp_t;
        type zabbix_agent_t;
        type sudo_exec_t;
        type http_cache_port_t;
        type shadow_t;
        type devlog_t;
        type kernel_t;

        class tcp_socket { name_connect };
        class unix_dgram_socket { create connect sendto write };
        class netlink_audit_socket { create read write nlmsg_relay };
        class sock_file { write };
        class capability { sys_resource dac_override dac_read_search audit_write };
        class dir { add_name write };
        class file { create open setattr write execute execute_no_trans read };
        class process { setrlimit };
}

#============= zabbix_agent_t ==============
allow zabbix_agent_t self:process { setrlimit };
allow zabbix_agent_t tmp_t:dir { add_name write };
allow zabbix_agent_t http_cache_port_t:tcp_socket name_connect;
allow zabbix_agent_t sudo_exec_t:file { execute execute_no_trans };
allow zabbix_agent_t self:netlink_audit_socket { create read write nlmsg_relay };
allow zabbix_agent_t self:unix_dgram_socket { create connect write };
allow zabbix_agent_t kernel_t:unix_dgram_socket { sendto };
allow zabbix_agent_t self:capability { sys_resource dac_override dac_read_search audit_write };
allow zabbix_agent_t shadow_t:file { read open };
allow zabbix_agent_t devlog_t:sock_file write;

#!!!! WARNING: 'tmp_t' is a base type.
allow zabbix_agent_t tmp_t:file { create open setattr write };
allow zabbix_agent_t user_tmp_t:file open;

Там прописаны разрешения на доступ к http-порту (требуется для мониторинга nginx), доступ на запись файлов в /tmp, и использование sudo., и использование sudo.

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

checkmodule -M -m -o zabbix-agent.mod zabbix-agent.te

semodule_package -o zabbix-agent.pp -m zabbix-agent.mod

semodule -i zabbix-agent.pp

И только после этого заббикс стал нормально считать sha256 для файла /etc/shadow . .

Ребилд RAID-5

at-hacker — Thu, 07 Nov 2013 13:28:00 GMT

Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным SMART одного из дисков, стало этому диску плохеть. Диск у нас этот трудится в HP Proliant DL380 G5, в RAID-5, собранном на контроллере Compaq SmartArray P400.

Ну, винты на замену были, но диск пока вроде работает. Решили подоткнуть новый диск и пометить его как hot spare, на случай если диск из массива самозапилится, то будет подхвачен новый HS-диск. Диск подоткнули, но вот с hot spare получился облом — оказывается, этот контроллер умеет в массив вставлять HS только в момент создания. А в уже существующий массив — нет.

Так что надо менять диск. Я старательно всё забэкапил, тщательно прицелился, из какого отсека диск вынимать, запалил там лампочку-индикатор, и товарищ, находящийся на месте, диск заменил. Всё вроде понялось, спросило у меня «тут это, новый диск. Будем ребилдить массив?» Я грю — конечно, бро, надо ребилдить! И процесс пошёл. Поскольку на сервере стоит FreeBSD, а там особо никаких утилит нет, позволяющих получить кровавые подробности о состоянии массива, то удовольствоваться пришлось командой:

# camcontrol devlist
<COMPAQ RAID 5  VOLUME reco>         at scbus0 target 0 lun 0 (da0,pass0)
<TEAC DV-W28E-RW G.B1>             at scbus2 target 0 lun 0 (pass1,cd0)

Я так полагаю, что VOLUME reco должно индицировать, что volume recovering. Ну, сидим курим, ждём окончания ребилда. Час, два ждём... И тут кончается рабочий день.

В общем, на следующий день к часу дня статус массива так и не изменился. Тут-то я и насторожился. И обратился к коллективному разуму с вопросом — а нормально ли это, для 150-гигового винта в RAID-5 такое время ребилда? Коллективный разум однозначно решил, что ненормально, но посоветовал использовать утилиту sysutils/cciss_vol_status, каковую я немедленно и проинсталлировал. Утилита английским по белому сказала:

cciss_vol_status -V /dev/ciss0
Controller: Smart Array P400
Board ID: 0x3234103c
Logical drives: 1
Running firmware: 7.18
ROM firmware: 7.18
/dev/ciss0: (Smart Array P400) RAID 5 Volume 0 status: OK.
Physical drives: 7
connector 1I box 1 bay 7 HP DG146BABCF BS05P8708AUE0827 HPD6 OK
connector 1I box 1 bay 6 HP DG146ABAB4 3NM14RAG00009821Q0QZ HPDD OK
connector 1I box 1 bay 5 HP DG146BABCF BS05P86088T90827 HPD6 OK
connector 2I box 1 bay 4 HP DG146BABCF BS05P8608A890827 HPD6 OK
connector 2I box 1 bay 3 HP DG146BABCF BS05P8607UYT0826 HPD6 OK
connector 2I box 1 bay 2 HP DG146ABAB4 3NM15CQ500009822WG3Q HPDA OK
connector 2I box 1 bay 1 HP DG146BABCF BS05P8607V070826 HPD6 OK

То есть, она считает, что массив уже вполне ОК. Но это расходится с показаниями camcontrol. В общем, похоже, camcontrol не перечитал данные с контроллера. Почему-то. Пришлось ему принудительно сделать

#camcontrol rescan /dev/ciss0

Только после этого camcontrol ответил, что

<COMPAQ RAID 5  VOLUME OK>         at scbus0 target 0 lun 0 (da0,pass0)

Вот и думай теперь, как ему после этого доверять. Придётся, видимо, в мониторинге переделывать получение данных о состоянии массива с camcontrol на cciss_vol_status :-(

Бага в zabbix 2.0

at-hacker — Sat, 03 Aug 2013 19:54:00 GMT

При обновлении системы и и всего софта до распоследних версий столкнулся с тем, что в zabbix-frontend при использовании PHP 5.5 появляется в красной рамочке надпись перед каждой таблицей с выборками из базы:

mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead [include/db.inc.php:77]

Думал, что это PHP warning (простительно после вторых суток колупания в конфигах). ПОтом дошло, что не, что-то тут нечисто. Полез искать, нашёл описание баги в багтрекере заббикса. Баг имеет статус unresolved, но там приложен некий патч (от 11.07.2013), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось. заббикса. Баг имеет статус unresolved, но там приложен некий патч (от 11.07.2013), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось.

СМС-оповещения

at-hacker — Fri, 13 Apr 2012 09:12:00 GMT

У нас на фре трудится система мониторинга Zabbix. Обо всяких критических события, типа пропадания питания или неожиданной перезагрузки серверов хотелось бы, чтобы оповещения приходили на СМС заинтересованным лицам. Выкопал я у товарища старый бесхозный мобильник Motorola L6 и вознамерился его использовать. Чтобы не искать кабель, который, как водится, может ещё и не подойти, решил его сразу по bluetooth подключить. Долго курил мануалы, прописывал ключи и включал автоматический доступ на Мотороле с компа, чтобы она не запрашивала каждый раз подверждение. Вроде заработало. Написал скрипт для автоматического запуска rfcomm_sppd, которая создавала виртуальный COM-порт через bluetooth, через который, в свою очередь, комплект smstools отправлял сообщения.

Тока вот этот виртуальный COM-порт, через который работал rfcomm_sppd, постоянно отваливался. И каждый раз требовался танец с бубном, чтобы всё это опять заработало, причём каждый раз я не мог понять, почему такие же действия две минуты назад никакого эффекта не давали. Удалось выяснить, что выключение/включение голубого зуба на телефоне позволяло в течение пары минут запустить скрипт и тогда порт появлялся. Но сегодня не помогло даже это. Руками запускаю rfcomm_sppd с нужными ключами — порт есть. Делаю то же самое скриптом — connection refused. В конце концов меня это задрало.

Я с горя взял обычный провод USB-miniUSB, оставшийся от павшего смертью храбрых внешнего HDD, и подключил им телефон к серваку с FreeBSD. Оценил обстановку в логах. Обстановка гласила:

Apr 13 12:25:11 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2Apr 13 12:25:11 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2Apr 13 12:32:57 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2 (disconnected)Apr 13 12:33:05 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2Apr 13 12:33:05 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2

Попандос, думаю — ugen2.3. Это значит, что фря устройство видит, но как с ним работать — не знает, драйвера нет. Полазил по интернетам. Рекомендуют запускать модуль ucom. Ок, пробуем:

kldload ucom

kldload: can't load ucom: No such file or directory

Нету модуля, значит. Та же петрушка с рекомендованным модулем umodem. Лезем сначала в /usr/src/sys/modules/usb/ucom, и делаем там

make

make install clean

Потом то же самое в каталоге /usr/src/sys/modules/usb/umodem

Потом грузим модули:

kldload ucom

kldload umodem

Перетыкаем кабель в телефоне, палим логи:

Apr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2Apr 13 12:46:38 proxy kernel: umodem0: <Motorola Inc. Motorola Phone (L6), class 2/0, rev 1.10/0.01, addr 2> on usbus2Apr 13 12:46:38 proxy kernel: umodem0: data interface 1, has CM over data, has no breakApr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2 (disconnected)Apr 13 12:46:38 proxy kernel: umodem0: at uhub2, port 1, addr 2 (disconnected)Apr 13 12:48:01 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2Apr 13 12:48:01 proxy kernel: umodem0: <Motorola Communication Interface> on usbus2Apr 13 12:48:01 proxy kernel: umodem0: data interface 1, has CM over data, has no break

Ну круто, umodem нашёл телефон. В системе появился порт /dev/cuaU0 (не путать с COM1, который /dev/cuau0 — разница в регистре в имени). Это и есть искомый COM-порт для коммуникации с телефоном. Прописываем его в конфиге демона smsd из комплекта smstools, и получаем щастье! И никаких хитрых процедур и скриптов запуска по голубому зубу. Остаётся только прописать загрузку этих двух модулей в /boot/loader.conf, чтобы оно автоматом грузилось при старте системы.