Ситуация: Вы поставили zabbix и как всякий админ здорового человека тут же прикрутили его к AD. Одним прекрасным утром Вы приходите, а DC недоступен. И прекрасный мониторинг превращается в тыкву. Я наступил на грабли, когда упал один из контроллеров домена, который уже не использовался, но работал «по инерции». Восстанавливать его никто не стал, а zabbix ходил за пользователями именно на него.
Кстати, в самом низу будет хинт, как вообще избежать ситуации с телодвижениями по поводу недоступности домена.
Что же делать по пунктам:
1. Выдохнуть. Расслабить сфинктер. Всё не так уж и страшно
2. Заходим на сервер с базой данных от zabbix
3a. Если у Вас MySQL, то командуем:
admin@zabbix-db:~$ mysql -u root -pSeCuReMySQLpaSSword
mysql> update db_zabbix.config set authentication_type='0' where configid='1';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> quit;
и заходим под локальным админом (по умолчанию Admin/zabbix)
3b. Если у Вас postgresql, то командуем:
admin@zabbix-db:~$ sudo -u postgres psql -d zabbix --command="update config set authentication_type='0' where configid='1';"
Password: SeCuRepgSQLpaSSword
UPDATE 1
admin@zabbix-db:~$
и заходим под локальным админом (по умолчанию Admin/zabbix)
4. ??????
5. PROFIT!!!111одинодинадин
Но как избежать такой ситуации в дальнейшем? А лучше не допустить? Всего-то навсего внимательно посмотреть, как устроена аутентификация в zabbix. Можно поставить разные виды аутентификации для разных групп! Поэтому создаём группу, например Local admin и переносим в неё пользователя Admin, после чего ставим группе Доступ к веб-интерфейсу (GUI access) -> Внутренний (Internal).