Maps in Zabbix 1.8

Как всегда в такого рода делах, лучшее враг хорошего! Обновление из пакетов непрошло даром. )) 

Ну ничего.

После того как я обновил Zabbix  до 1.8 случилась проблема с картами (MAPS). Точнее после нажатия на кнопку добавления элемента получал тишину.

Залез в логии apache2 и нашёл ошибку:

[Mon Feb 08 13:41:39 2010] [error] [client 192.168.0.чч] File does not exist: /usr/share/zabbix/js/effects.js, referer: http://monserver.xxx.xx/zabbix/sysmap.php?sysmapid=2&sid=cffeb4533bfdf83a

[Mon Feb 08 13:41:39 2010] [error] [client 192.168.0.чч] File does not exist: /usr/share/zabbix/js/dragdrop.js, referer:http://monserver.aksi.com/zabbix/sysmap.php?sysmapid=2&sid=cffeb4533bfdf83a

Ну соответственно выход нашёлся сам собой. Скачал исходники с сайта zabbix.com распаковал и скопировал из

home/Distrib/zabbix-1.8.1/zabbix-1.8.1/frontends/php/js/scriptaculous

в

  /usr/share/zabbix/js

рестартанул сервис и вперёд!

Zabbix agent for Windows

Решил добавить ссылку с ресурса где лежат уже готовые инсталяхи агентов для Windows платфор.
Для особо ленивых, к которым я себя отношу....
http://www.suiviperf.com/zabbix/

Zabbix and LDAP

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

• Так как мой акаунт уже есть в AD, то добавлять его не будем )), конечно если такового нет то необходимо добавить согласно корпаративного стандарта;

• Опережая события скажи что надо на сервер, на котором стоит Zabbix server постивать php5-ldap, иначе будет ошибка в далнейшем и его придётся всё таки ставить.

• Сначала посмотрим установлен ли этот пакет:

dpkg --get-selections | grep -v "deinstall"

ищем там php5-ldap, если есть то переходим следующему пункту, если нет то

apt-get install php5-ldap

и переходим следующему пункту.

• Согласно документации на Zabbix сначала надо создать пользователя, а потом уже сделать ему аутентификацию через LDAP.

• Заходим в Admininstration->Users, далее создаём пользователя Create User.
• В меню создания пользователя все так же как и если бы это была локальная аутентификация, есть только одно но, Alias - это должен быть логин пользователя в AD, пароль не имеет значения (например - 1), так как далее будет использоваться только пароль из AD. И ещё, создать перванаперва акаунт с параметрами User type - ZABBIX Super Admin и Groups - Zabbix administrators. Просто после включения аутентификации через LDAP, внутреняя будет не доступна, но не надолго (но про это в конце).
  
• Далее заходим под этой учёткой с паролем который задали (1) и идём в Administation-> Authentication. Выбираем Default authentication - LDAP, LDAP Host - ваш.AD.сервер, Port - 389, Base DN - cn=Users,dc=чччч,dc=чч (где ледат пользователи), Search attribute - sAMAccountName (это конкретно для AD), Bind DN* - cn=пользователь,cn-Users,dc=чччч,dc=чч (это учётка которая будет шерстить AD, создана должна быть заранее), Bind Password* - пароль этой учётки из Bind DN*.
  
• Далее не ставим пока галочку LDAP Authentication Enable, а вводим пароль этой учётки (которую мы создали тремя рунктами ранее, кстати она должна появиться в поле Login) из AD. b нажимаем кнопку Test. Должна появиться полоска LDAP Login successful.
• Теперь вводим ещё раз пароль из учётки AD и жмакам Save.

Делам Logout и теперь уже логинимся с параметрами учётки как в AD.

А теперь про "Просто после включения аутентификации через LDAP, внутреняя будет не доступна, но не надолго". А что же будет если LDAP будет недоступен. Этот вопрос у меня всплыл сразу.... Почитав ещё раз man и поэксперементировав - вывел следующее. То что мы сделали в Administation-> Authentication относиться к GUI access - System default. Что плохо при потере доступа к LDAP.
Если зайти в Admininstration->Users и выбрать User groups, можно увитеть список всех доступных групп. в колонке GUI access указан тип доступа, нажимая на этот параметр можно изменить его для соответствующей группы (System default, Internal, Disable).
Но находясь в самой группе, нельзя сменить тип доступа для неё.
Так что выход прост, меняем группу для своей учётки на например Guest (параметр Groups) не в коем случае не меняем User type - ZABBIX Super Admin (будет закрыто меню Admininstration). Логинимся под этой учёткой и меняем пареметр GUI access для группы
Zabbix administrators на Internal. То есть оставляем себе возможность зайти если что )).

Конечно возможны разного рода реализации, с созданием ещё одной группы, что то типа Super Zabbix administrators, и переносом туда резервного акаунта и внутренней аутентификацией, но это уже дело каждого.
Вот и все!

Тут обновился до версии 1.8, но не стал замарачиваться с замарочным upgrade'ом просто экспортировал настройки все, убил версию 1.6.5 и поставил 1.8. Так вот тут выяснилась интересная штука. Аккаун admin был неприкреплён ни к одной группе. Так, что надо не забывать его занести в ту группу, которая будет аутентироваться внутренней (забиксовой) аутентификацией.

eJabber for Zabbix

У меня возникли проблемы с уведомлениями о событиях в моём Zabbix сервере. Точнее сказать отправка email'ов не работала. Своего почтового сервера нет. А на сторонний не хочет отправлять, выдаёт ошибку.
Так что я решил пойти по пути наименьшего сопротивления и поднять Jabber сервер.
Действовал по уже отлаженному механизму. Посмотрел что люди пишут про разного рода демоны и выбрал - eJabberd.
Создал Debian вертуалку на моей уже описанный XenServer "ферме" и вперёд.
Раскоментил в source.list все.
apt-get update
apt-get cache search ejabber
ejabberd - Distributed, fault-tolerant Jabber/XMPP server written in Erlang
apt-get cahce show ejabberd
Package: ejabberd
Priority: optional
Section: net
Installed-Size: 3224
Maintainer: Torsten Werner
Architecture: i386
Version: 2.0.5-1.1
Depends: adduser, erlang-nox (>= 1:13.b-dfsg1), erlang-abi-13.a, openssl, ucf, debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.3.6-6~), libexpat1 (>= 1.95.8), libpam0g (>= 0.99.7.1), libssl0.9.8 (>= 0.9.8f-5), zlib1g (>= 1:1.1.4)
Suggests: libunix-syslog-perl
Filename: pool/main/e/ejabberd/ejabberd_2.0.5-1.1_i386.deb
Size: 1164076
MD5sum: 1045daf9668273a27a0b47881055c7f8
SHA1: 50f0bfa13b148f0b683a8782506ed0781b16cf03
SHA256: 9c853773df7c6d67fc9bd00ea83b02994430f7101b8175974700be27d683b6b8
Description: Distributed, fault-tolerant Jabber/XMPP server written in Erlang
ejabberd is a distributed, fault-tolerant Jabber/XMPP server written in Erlang
Features:
- XMPP-compliant
- Web based administration
- Load balancing: can run in a cluster of machines
- Fault-tolerance: database can be replicated and stored on multiple
nodes (nodes can be added or replaced 'on the fly')
- Virtual hosting: several virtual domains can be served using single ejabberd
instance
- SSL/TLS support
- Multi-User Chat (MUC/conference)
- IRC transport
- Jabber Users Directory, based on users vCards
- Service Discovery
- Shared roster
Homepage: http://www.process-one.net/en/projects/ejabberd/

Поставил сначала сам Erlang, а потом и сам сервер.
apt-get install erlang
apt-get install ejabberd

Далее смотрим инструкцию по настройке на сайте http://www.process-one.net/en/ejabberd/docs
и вперёд править конфигурационный файл /etc/ejabberd/ejabberd.cfg, по большому счёту там надо поправить немного, я не замарачивался с сертификатами и транспортами (возможно это дело будущего). Единственное что я добавил это аутентификацию через AD.

%% Options which are set by Debconf and managed by ucf

%% Admin user
{acl, admin, {user, "ejabberd", "jabserver.чччч.чч"}}.

%% Hostname
{hosts, ["jabserver.чччч.чч"]}.

Этот пользователь (ejabberd) был предварительно создан в AD.

%%
%% Authentication using LDAP
%%
{auth_method, ldap}.
%%
%% List of LDAP servers:
{ldap_servers, ["server.чччч.чч"]}.
%%
%% Encryption of connection to LDAP servers (LDAPS):
%%{ldap_encrypt, tls}.
%%
%% Port connect to LDAP server:
{ldap_port, 389}.
%%
%% LDAP manager:
{ldap_rootdn, "cn=ejabberd,cn=Users,dc=чччч,dc=чч"}.
%%
%% Password to LDAP manager:
{ldap_password, "123456"}.
%%
%% Search base of LDAP directory:
{ldap_base, "cn=Users,dc=чччч,dc=чч"}.
%%
%% LDAP attribute that holds user ID:
{ldap_uids, [{"sAMAccountName"}]}.
%%
%% LDAP filter:
{ldap_filter, "(memberOf=cn=JABBER users,cn=Users,dc=чччч,dc=чч)"}.

предварительно закоментировав


%%{auth_method, internal}.

Могу сказать что конфигурационный файл довольно понятный и дока к серверу очень не плоха.

Ещё по настонию доки я сделал следующее

{mod_vcard_ldap,
[{ldap_vcard_map,
[{"NICKNAME", "%u", []},
{"GIVEN", "%s", ["givenName"]},
{"MIDDLE", "%s", ["initials"]},
{"FAMILY", "%s", ["sn"]},
{"FN", "%s", ["displayName"]},
{"EMAIL", "%s", ["mail"]},
{"ORGNAME", "%s", ["company"]},
{"STREET", "%s", ["streetAddres"]},
{"TITLE", "%s", ["title"]},
{"URL", "%s", ["wWWHomePage"]},
{"DESC", "%s", ["description"]},
{"TEL", "%s", ["telephoneNumber"ghbcrjh,btv cjj,of. xnj j,yjdbd ]}]},
{ldap_search_fields,
[{"User", "%u"}]},
{ldap_search_reported,
[{"Nickname", "NICKNAME"}]}
]},

Вот вообщем то и всё.

Далее создал пользователя для Zabbix сервера в AD, добавил его в группу Jabber users.
Далее через GUI Zabbix сервера (Administation -> Media types) поправил содержимое Jabber добавив пользователя котого только что создал в Jabber Identifier как имя@jabserver.чччч.чч и пароль к нему.
Практически всё, добавил себя в группу Jabber users в AD, в настройках своего пользователя на Zabbix сервере добавил media jabber как я@jabserver.чччч.чч и все в порядке.
В моём IM клиенте (Miranda) добавил свой акаунт (без шифрования). И теперь порлучаю больше удовольствия от Zabbix!

 С прискорбием сообщаю, что обновив eJabberd до 2.1.3 он перестал работать с AD, уж что я только не делал, ничего не помогало. Так что теперь ему на смену пришёл OpenFire. По нему тоже документации будь здоров!

Zabbix agent for Linux

Столкнулся с проблемой, после установки на Debian из репозитариев zabbix агента, ни как не мог его подключить к zabbix серверу. Причём при этом у меня уже работали 3 Win сервера с агентами о которых я писал выше и без нареканий. Так что решил не изобретая велосипед просто посмотреть какой там zabbix-agentd.conf и применить его на Debian. Но что то не прокатило.
Посмотрел ps -ef и увидел что агент запущен:

zabbix 6327 1 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6328 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6329 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6330 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6331 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6332 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6333 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd
zabbix 6334 6327 0 17:31 ? 00:00:00 /usr/sbin/zabbix_agentd

далее сразу на netstat -a, а там сервиса нет.
точнее он то есть но в tcp6, короче всё равно сервер агента не видит.
Методом сравнения вывода команды netstat -a на Win серверах и Linux сервере, плюс немного докумментации - решение нашлось.
В zabbix-agentd.conf на Debian надо было раскоментить строчку с:

# IP address to bind agent
# If missing, bind to all available IPs

ListenIP=Ip.на.внешнем.интерфейсе

и все срослось.
Теперь подправлю template_linux и буду наслаждаться.