4 заметки с тегом

Zabbix

Zabbix agent + SElinux = hardcore...

28 июля 2017, 12:14

Вынужден тут приобщаться к странному и алогичному миру линуксовых ОС. И поимел сегодня исключительно волнующий опыт настройки мониторинга контрольной суммы файла /etc/shadow в 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. Точнее, установлена оболочка /sbin/nologin. ОК, патчим sudoers:

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

Лучше стало, но не сильно: «sudo: unable to open audit system: Permission denied». «Эге!», — подумал я, «стопудово дело в 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 определённые сообщения подавляются. Чтобы это временно отключить, необходимо выполнить команду:

# semodule -DB

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

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

Потом выяснилось, что у агента нет прав на запись в каталог /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.

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

# 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 .

CentOS   Linux   SELinux   Zabbix

Ребилд RAID-5

7 ноября 2013, 17:28

Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным 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

3 августа 2013, 23:54

При обновлении системы и и всего софта до распоследних версий столкнулся с тем, что в 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), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось.

FreeBSD   Troubleshooting   Zabbix

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

13 апреля 2012, 13:12
У нас на фре трудится система мониторинга 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 uhub2
Apr 13 12:25:11 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2
Apr 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 usbus2
Apr 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 usbus2
Apr 13 12:46:38 proxy kernel: umodem0: <Motorola Inc. Motorola Phone (L6), class 2/0, rev 1.10/0.01, addr 2> on usbus2
Apr 13 12:46:38 proxy kernel: umodem0: data interface 1, has CM over data, has no break
Apr 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 usbus2
Apr 13 12:48:01 proxy kernel: umodem0: <Motorola Communication Interface> on usbus2
Apr 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, чтобы оно автоматом грузилось при старте системы.