Yet another FusionInventory/GLPI experience

Crank / Wed 09 March 2016 / admin :: shell, gui, scripts,

В сети достаточно много информации о том, что такое GLPI и FusionInventory, зачем они нужны, а так же о том, как это добро конфижить и ставить [1]. Миллионы мух не могут ошибаться, поэтому я тоже приму участие во всеобщей вакханалии (этот абзац, я, конечно, потом перепишу).

Установку буду делать руками. Зависимости лучше удовлетворить через менеджер пакетов, но вот развёртку самих систем делать неудобно по ряду причин.

Установка и настройка GLPI‐сервера

Своевременные обновления GLPI делают систему более секьюрной. Это, в общем‐то основа безопасности. Очень сильный аргумент в поддержку варианта с использованием менеджера пакетов Ubuntu Server, однако против него говорит достаточно медленная реакция маинтайнеров Ubuntu на обновления и не очень прозрачная процедура автоматического конфигурирования и установки GLPI из пакета.

1. Развёртка сервера

Директория, в которую удобно поместить актуальные версии пакетов:

$ mkdir manual-installed.packages
$ cd manual-installed.packages

На сайте GLPI есть раздел «Downloads», откуда можно взять последнюю (стабильную) версию GLPI. На момент написания заметки, это была 0.90.1:

$ wget https://github.com/glpi-project/glpi/releases/download/0.90.1/glpi-0.90.1.tar.gz

К нему сразу возьмём плагин подходящей версии FusionInventory:

$ wget https://github.com/fusioninventory/fusioninventory-for-glpi/releases/download/glpi090%2B1.1/fusioninventory-for-glpi_0.90.1.1.tar.gz

Распакуем glpi:

$ tar xvpf glpi-0.90.1.tar.gz

Я не уверен, но, по‐моему, в Ubuntu контент подобного рода должен располагаться в /srv. Если, однако вы будете ставить glpi из пакета, то он будет помещён в /usr/share/glpi (там ему и место). Я — традиционалист‐фундаменталист POSIX, и поэтому помещу его в /usr/local/share, где ему самое место по канону.

# mv glpi /usr/local/share
# chown root www-data /usr/local/share/glpi -R

Далее, нужно сконфижить хост на Apache. Я не собираюсь держать на этой машине более одного хоста, так что обойдусь алиасом на дефолтном хосте. Только, из гигиенических соображений, оберну его в <IfDefined>. Внутри <VirtualHost *:80>:

<IfDefine GLPI_SERVER>
    Alias "/" "/usr/local/share/glpi/"
    <Directory "/usr/local/share/glpi/">
        Options Indexes FollowSymlinks MultiViews
        AllowOverride None
        <IfVersion < 2.4 >
            Order allow,deny
            Allow from all
        </IfVersion>
        <IfVersion >= 2.4 >
            Require all granted
        </IfVersion>
    </Directory>
    # NOTE: since I've installed GLPI from sources and I prefer not to use
    # .htaccess file, I need to disable web-access from here. (Crank)
    <Directory "/usr/local/share/glpi/files/">
        Allow from None
        Deny from all
    </Directory>
</IfDefine>

Спецификация аргументов командной строки для запуска Apache в Ubuntu делается в переменной APACHE_ARGUMENTS, в файле /etc/apache2/envvars. Добавил в неё -D GLPI_SERVER.

В случае (очень желательном), если на сервере будет использоваться SSL‐сертификат, потребуется несколько дополнительных телодвижений, и добавятся строчки указывающие на файл с ключём и сертификатом. Хорошим тоном будет так же настроить редирект с «/» на виртуальном хосте *:80 ведущий на *:443. Я так же использую <IfModule !ssl_module> для определения, подхватился ли модуль SSL в своих конфигах.

Далее нужно сконфигурировать MySQL‐базу данных для glpi. Создание схемы и таблиц GLPI сделает сам, от администратора, однако, потребуется предоставить установщику реквизиты учётки для администрирования.

mysql> CREATE DATABASE glpi;
mysql> CREATE USER 'glpi'@'localhost' IDENTIFIED BY '...';
mysql> GRANT ALL PRIVELEGES ON glpi.* TO 'glpi'@'localhost';

Этих действий должно хватить теперь для выполнения автоматизированной установки GLPI на хост — в браузере должно быть возможно зайти на / целевого сервера (согласно алиасу из конфига), и там инициировать процедуру. Необходимо, однако, удовлетворить процедуру самодиагностики, что должно иметь место, если никто ничего не напутал с ключами. Обратите внимание, что GLPI хочет уметь писать в некоторые директории (e.g. glpi/files, glpi/config), и ему это должно быть позволено. С этой целью при распаковке нужно сохранить POSIX-разрешения ключом p, и выставить корректного владельца chown'ом.

После установки можно залогиниться в GLPI, используя дефолтные учётки — glpi/glpi для администратора, tech/tech для техника и т.д.

Здесь, рекомендуется как можно быстрее удалить glpi/install/install.php и поменять пароли дефолтных учёток, и этой рекомендации стоит последовать по понятным причинам.

Чтобы два раза не вставать, самое время распаковать код с FusionInventory-плагином:

$ tar xvpf ./fusioninventory-for-glpi_0.90.1.1.tar.gz
# mv ./fusioninventory /usr/local/share/glpi/plugins/
# chown -R root:www-data /usr/local/share/glpi/plugins/fusioninventory/

И включить / установить его в панели Setup / Plugins web-интерфейса GLPI (установка просто конфигурирует плагин и окружение, «включение» же подгружает его модуль). После этого в интерфейсе GLPI появятся возможности конфигурации интеграции с агентами FusionInventory. Прежде всего, нужно обнаружить новую вкладку «Fusioninventory» в Administration / Entities / Root entity, и указать там «Service URL» — адрес самого сервиса GLPI. У меня это будет просто имя хоста, поскольку в Apache алиас прописан на корень — «/». Учётку для аутентификации агентов FusionInventory создаст сам (можно посмотреть на неё через администраторскую панель).

2. Конфигурирование LDAP SSO

LDAP в мире решений Signle-Sign On, если кто не в курсе, стал стандартом де‐факто. В нашей организации из него сделали за несколько лет чёртовы джунгли, но даже будучи предельно забардаченым, LDAP остаётся довольно удобным решением для организации SSO. Конечно, GLPI поддерживает аутентификацию через LDAP, и даже прямо из коробки (другим подобным вариантом является упрещённый механизм аутентификации через сервер SMTP).

Во вкладке Setup / Authentication вам должен быть доступен пункт меню «LDAP directories» (если нет, то нужно вкатить на сервер зависимости ActiveDirectory).

Чтобы добавить сервер ActiveDirectory, нужно войти в этот пункт и нажать «+». Я упоминаю об этом на случай, если вы не знакомы с логикой организации интерфейсов в GLPI, который придерживается философии предельного соответствия своих UI логике SQL‐запросов (пагины, впрочем, постоянно от этой логики отступают). Все пункты меню, окна и вкладки отображают результат пост‐обработки SQL‐запроса SELECT, и по существу просто графически отображают соответствующую SQL‐таблицу. Вверху такой вкладки обычно есть виджет‐кнопка «+», позволяющая добавлять новый элемент в эту таблицу.

Для людей (вроде меня) не знакомых с логикой организации LDAP‐запросов, полезно иметь небольшую шпаргалку о том, как заполнять эти поля.

o BaseDN — имя домена AD. Для, например, домена qcrypt.org это будет строка dc=qcrypt,dc=org (избегайте пробелов!). o RootDN — учётка для подключения. Для SSO полезно иметь бесправного пользователя для подключения к серверу LDAP и сверки реквизитов. По‐хорошему это может быть full-qualified name в виде «cn=login-services,ou=dummies,dc=qcrypt,dc=org», но GLPI может использовать и просто cn «login-services». o Password — пароль для учётки RootDN. o Login field — в нашей организации семантику уникального имени пользователя для логина имеет samaccountname. Если вас гложат сомнения, полезно проконсультироваться с каталогом через какую‐нибудь LDAP‐админку.

& Кстати говоря, хорошим способом протестировать фильтр запоросов является следующий & способ: в админской утилите Windows®™ «Active Directory Users and Computers» можно & организовать кастомный поисковый запрос: ПКМ на объекте домена в дереве слева, & «Find», там выбрать «Custom search» («пользовательский запрос»). & На всякий случай напомню, — чтобы узреть доменный ActiveDirectory и протестировать & аутентификацию учётки (пусть и бесправной), можно воспользоваться штатным adsiedit.

Отдельно хотелось бы остановиться на поле «Connection filter»… Хотлось бы, но не могу поскольку в неё нужно вкладывать фильтр учёток в нотации LDAP‐запросов. Что‐то вроде (&(objectClass=user)(ObjectCategory=person))(!(userAccountControl:1.2.840.113556.1.4.803:=2))) [2, 3] может очень хорошо ограничить круг доверенных лиц для входа. Некоторую беглую информацию легко найти в интернете — стандарт RFC 2254. В нашем отделе было принято решение ограничить пока круг доверенных лиц администраторами из отдела и мат. ответственными подразделений. Фильтр в этом случае имеет следующий вид:

(& (objectClass=user)
   (ObjectCategory=Person)
   (|(memberof=cn=glpi_admin,ou=ph-dep,ou=Groups,dc=qcrypt,dc=org)
     (memberof=cn=ph_dep_acc_ofic,ou=ph-dep,ou=Groups,dc=qcrypt,dc=org)))

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

3. Groups Bulk Import

Импортировать группы из LDAP‐каталога можно в Administration / Groups, LDAP directory link. Правда, BaseDN, возможно, придётся изменить, поскольку он некоторым образом используется при импорте групп — группы будут вычитываться из поля memberof всех пользователей подходящих критерию LDAP‐аутентификации. Другими словами, таким образом будут показаны только непустые группы, в которых есть пользователи соответствующие фильтру поиска пользователей и размещённые по пути BaseDN.

4. Ассоциирование GLPI-профилей и LDAP‐групп

Профили в GLPI — способ организации полномочий, который впору бы было ожидать от того что называется здесь «Группы». Тем не менее какого‐то очевидного способа непосредственно связать «Группы» GLPI и его «Профили» я не нашёл.

Тем не менее, в GLPI есть очень гибкий механизм «Правил» (Rules), которые позволяют выполнять некоторые действия автоматически. Среди прочего, они могут быть использованы и для автоматического присваивания профиля пользователю при [следующей] аутентификации.

Последовательность действий тут неочевидна, поэтому запишу шпаргалку и тут:

В меню Administration / Rules отыскать «Authorization assignemnt rules».
Жмакнуть «+» для добавления правила. По умолчанию в таблице уже присутствует root-правило для аутентификации через LDAP, которое создаёт пользователя при первом входе по LDAP‐реквизитам.
«Name» — имя правила в таблице. Например «Delegate administrative permissions» или «Delegate Accountable Officer profile to person». Непустое поле «Description» создаст маленький значок «i» с tooltip'ом содержащим текст этого поля. Удобно и практично. «Active» лучше не выставлять до тех пор, пока правило не будет отлажено. «Logical operator» будет применён для всех «критериев» перечисленных в правиле как способ конкатенации.
Во вкладке «Criteria» нужно добавить критерии валидации сущностей к которым применяется правило. Для указанной задачи я использовал два критерия — наличие (LDAP) User ID (is «*») и присутствие целевой группы в LDAP‐поле «MemberOf» (contains «cn=ph_dep_acc_ofic,ou=ph-dep,ou=Groups,dc=qcrypt,dc=org»). Тут важно иметь в виду, что механизм Rules применяет содержимое критериев как регулярные выражения для полей, поэтому всюду нужно указывать их, а не условия в нотации LDAP.
Во вкладке «Action» установить действие в «Profiles» «Asign» «Admin»/«Accountable Officer».
Потестировав правила на реальном содержимом учёток (кнопочка «Test»), убедившись, что критерии работают так как надо, правило нужно активировать в «Rule» — выставить «Active».

Тут же нужно позаботиться, чтобы админы и accountable officer'ы лишённые соответствующих полномочий в LDAP выставлялись на мороз и в GLPI.

5. Ограничение rogue requests

Вообще, страничка «Security» FusionInventory весьма благоразумно советует «to restrict access to the plugin location on your GLPI server». Говорит, правда, что делается это «typically using HTTP authentication», хотя каких‐то описанных способов заставить клиент проходить аутентификацию на точке входа в сети я не нашёл.

Есть, однако, несколько искусственная возможность сконфигурировать прокси на сомое себя — FusionInventory из коробки умеет ходить через прокси. В принципе, попытака закрыть HTTP‐аутентификацией директорию plugins/fusioninventory не указывая прокси‐адрес вовсе, а только реквизиты для аутентификации делают своё дело.

Установка агента: Windows

В нашей организации довольно обширный парк машин (несколько тысяч), и, конечно, вещи вроде «установим политику по развёртке клиентов сразу всем» положат сеть крепко и всерьёз — FusionInventory генерирует поначалу довольно много трафика. Это полезно иметь в виду тем, кто будет сам создавать доменные политики для развёртки клиентских агентов.

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

Установщик FusionInventory принимает аргументы командной строки, в которых можно указать адрес сервера, настройки прокси, сконфигурировать features агента и т.д. Эти аргументы можно специфицировать exe‐установщику в формате GNU («--»), или windows («/»), либо прописать в реестре/конфиге уже после установки. Прежде всего, вам понадобится указать точку входа на сервере, которая в параметрах названа почему‐то «server». Установленный FusionInventory имеет точку входа по пути plugins/fusioninventory/, в чём легко убедиться, вбив путь в адресную строку и увидев судорожный скриптовый редирект на страницу 404 (OCSInventory в аналогичной ситуации более честно выдаёт «400 Bad Request»).

[1] Тут хороший манул по тому же самому, с картинками, но для старых версий GLPI.

[2] Ещё одна история успеха.

[3] Не уверен, что относится к теме, но набрёл на информацию по LDAP Numeric Rules.