MySQL: group_concat - ограничение и как его преодолеть

 В небезызвестной OCS-NG Inventory, по крайней мере до версии 2.1.2 включительно, есть таблица AccountInfo, в которой хранятся различные дополнительные параметры оборудования, которые можно менять в разделе Administrative Data

Но есть у нее недостаток: MySQL не поддерживает косвенную адресацию (обратиться в полю по имени, которое находится в переменной или является результатом выражения), а поля в этой таблице имеют вид FIELDS_NNN, где NNN - номер поля, поэтому для обращения, скажем, к полю "Владелец компа" надо делать лишний селект, чтобы узнать, в каком из FIELDS-ов этот владелец хранится. И не просто селект, а еще и при каждом обращении к этому полю, чтобы при изменении его номера не пришлось перелопачивать весь скрипт.

Групповая обработка файлов с похожими именами

Сервер OCS Inventory позволяет сохранять полученные от клиентов данные в виде отдельных файлов с расширением .ocs. Это может быть полезно для анализа истории изменений конфигурации. Но вот незадача: файлы плодятся гораздо быстрее кроликов и вскоре отведенный под них каталог забит файлами с именами вида "КОМП-дата-время-номер.ocs",  например, "computer017-2014-11-02-09-17-1.ocs", где "дата" и "время" - дата и время создания записи об этом компе. То есть, имена файлов с информацией об одном компьютере отличаются только полем "номер", причем в первом файле из серии это поле отсутствует.
Надо бы как-то навести порядок и хранить историю в архивах, поскольку нужна она только человеку - сама OCS хранит ее в БД MySQL.

Возникает задача: как упаковать файлы истории в отдельный для каждого клиента архив?

OCS-NG Inventory 2.x: продолжаем миграцию. Параметры подсетей.

Посредством лома и какой-то матери перенес данные из таблиц версии 1.х в таблицы версии 2.х. После удаления созданной по шаблону accountinfo_config, нормально отработала конверсия старых данных accountinfo в новый формат (вот и пригодится рассмотренный чуть ранее view).
Пошел проверять настройки подсетей, вроде всё выглядит гладко:



Однако... Однако при проверке вылезло:


вот те раз! А где ж ID 120000, который прекрасно виден в предыдущей таблице? А нету!

OCS-NG Inventory 2.x: нормальный доступ к новому формату ACCOUNTINFO

abstract: convenient human-readable access to ACCOUNTINFO table from OCS-NG Inventory 2.x
keywords: ACCOUNTINFO, ACCOUNTINFO_CONFIG, FIELDS_###

Я долго бился над одной совершенно дурацкой проблемой: в OCS Inventory версий 1.х таблица с дополнительной "административной" информацией была одна - ACCOUNTINFO - и имела довольно простой формат: каждый столбец таблицы представлял собой одно поле административной информации и делать выборку было не просто, а очень просто.
В версиях 2.х это изменилось: теперь все добавленные пользователем поля имеют имена вида FIELDS_XXX, где XXX - какое-то число, соответствующее порядковому номеру, каким по счёту добавлялось это поле. Описания же полей хранятся в таблице ACCOUNTINFO_CONFIG, причем прямой связи между ними нет:

От частного к общему или наоборот?

Писал сегодня SQL-запрос. Надо среди прочего выбрать из базы инвентаризации производителя и модель материнки. Надо сказать, что в этом деле у производителей полный разнобой. Кто-то оставляет эти поля незаполненными - "to be filled by OEM" или "system name/system manufacturer", другие, как например HP, вместо модели материнки вписывают модель самого компа, российский Kraftway в половине машин пишет, что производитель - Kraftway, а материнка - GEG, а в другой половине (та же модель!), что материнка - MSI-такая-то. Но в обоих случаях компы собраны на одной и той же материнке.

И надо мне обработать собранные данные (OCS Inventory по-прежнему рулит) для формирования одного отчета. Приходится анализировать содержимое полей на наличие ахинеи и в особо тяжелых случаях заменять ересь на что-то вроде "вписать вручную".

Вот и сейчас как раз допиливал кусок, отвечающий за разборку этих данных. Если производитель или модель - ахинея, то заменяю их для простоты дальнейшей обработки словом "NO".
И при составлении смешанного поля "модель-производителя" анализирую комбинации типа "если производитель NO и модель NO то "ввести вручную"", "если NO и не NO, то скомпоновать так-то" ну и т.д. Всего 4 комбинации.
Анализ случаев с особо трудными производителями (тот же Kraftway: mfg:"AWARD_", mdl:"MS-7676") вставил после этой проверки и долго не мог понять, почему же, несмотря на правильность регекспа, пресловутая материнка от MSI не появляется в смешанном поле.

Моя ошибка была в том, что я пошел от общего к частному, тогда как надо было идти наоборот. Перечислил частные случаи, комбинации производителей и моделей, до общих и всё заработало.

Мораль: проверяй условия от частного - к общему! И только так.

OCS: битва за линукс продолжается

Я как-то не обращал внимания, а тут выяснил, что в репозиториях Ubuntu 10.10 есть более-менее свежий агент для OCS-NG. Ради эксперимента установил его дома и попробовал "настучать" на самого себя на сервер, установленный на работе.
Установка и настройка агента прошли нормально, но при первом же запуске вылезли грабли:

$sudo ocsinventory-agent -i -debug -s http://ocsinvent.eao.drsk.ru
[debug] Ocsinventory unified agent for UNIX, Linux and MacOSX 1.1.2
[debug] Log system initialised (Stderr)
[debug] --scan-homedirs missing. Don't scan user directories
[debug] Accountinfo file: /var/lib/ocsinventory-agent/http:__ocsinvent.eao.drsk.ru/ocsinv.adm
[debug] Turns CompatibilityLayer on for /etc/ocsinventory/modules.conf
[debug] OCS Agent initialised
[debug] Calling handlers : `start_handler'
[debug] Compress::Zlib is available.
[debug] sending XML
[debug] Calling handlers : `prolog_writers'
[debug] sending:
<REQUEST>
  <DEVICEID>dt-spa-2010-10-14-23-36-28</DEVICEID>
  <QUERY>PROLOG</QUERY>

</REQUEST>
[error] Deflating problem

Неприятно, да?
Вылечилось до смешного просто:

OLD /etc/ocsinventory/ocsinventory-agent.cfg

server=http://ocsinvent.eao.drsk.ru

NEW /etc/ocsinventory/ocsinventory-agent.cfg

server=http://ocsinvent.eao.drsk.ru/ocsinventory

Как там пел Владимир Семёнович, "смешно, не правда ли, смешно?"

(немного дополнительной информации для англоговорящих, которые будут пользоваться поисковиками)

abstract: solution for "Deflating problem" of OCS-NG Unified Unix Agent.
Status: solved

OCS-NG: битва с сервисом

Решил потихоньку переводить системы под windows с запуска инвентаризации из логин-скрипта в режим сервиса. На одной машине получилось, на другой получилось... на третьей или четвертой грабли: ничего не происходит кроме добавления в системный журнал трех сообщений:

1. ERROR: Can't get private profile string for service option auth_user
2. ERROR: Can't get private profile string for service option auth_pwd
3. Service started successfully with parameters FREQ: 24, OLD_FREQ: 24, TTO_WAIT: 41247.

Гуглинг принес не очень много результатов, но они того стоили. Я внимательно изучил вот эту ветку форума и у меня заработало. Надеюсь.

Итак, в каталоге установки агента OCS-NG, создается файл SERVICE.INI. В нем должны быть как минимум следующие параметры:

[OCS_SERVICE]
PROLOG_FREQ=24
Server=url сервера ocs-ng без префикса http[s]://
Pnum=80
;если используется прокси, то выставить =0
NoProxy=1
;если используется прокси, то убрать параметр /NP
;нет, я не знаю, зачем всё вышеупомянутое продублировано
;в строке Miscellaneous, спрашивайте у авторов.
Miscellaneous= /SERVER:cнова_адрес_вашего_сервера /PNUM:80 /NP /DEBUG

auth_user=none

auth_pwd=none

Если доступ к серверу осуществляется через прокси, то надо добавить еще и параметры:

proxy_host=none
proxy_port=none
proxy_user=none
proxy_pwd=none

не забыв заменить  "none" на соответствующие значения.
В принципе, если последние четыре параметра будут в файле, ничего страшного не произойдет. Но моя проблема была в том, что у меня не было двух, выделенных красным: как только их добавил, служба нормально запустилась...

OCS-NG: битва с агентом за линукс

Как и многие другие, я наступил на такие вот грабли:

[debug] Calling handlers : `prolog_writers'
[error] Deflating problem

при запуске агента под линуксом. Сервер 1.0.2 с патчем от Denis Linvinus работает под Windows 2003 server, и виндовые агенты работают превосходно.

Агент у меня был 1.0.1. Все необходимые модули для PERL были. Вылечилось, к моему удивлению, простой установкой из исходников агента 1.3.2. Теперь буду проверять, как себя поведет виндовый агент этой же версии, да, может быть, обновлю на всех машинах, да еще и в режим сервиса воткну.

Попутно наткнулся на некую разработку на базе OCS: FusionInventory. Подробно о ней пока сказать нечего, но судя по описаловке на офсайте, должна быть немного удобнее в работе. Отпишусь, когда (и если) проверю.

Немного об OCS-NG

Работаю с версией 1.02. Обнаружил такую вот бяку...

Есть таблица ocsweb.accountinfo. В ней хранятся тэги и административная информация, которая вносится через соответствующий пункт в административных настройках системы, по сути - дополнительные поля, не вошедшие ни в одну из многочисленных дополнительных таблиц этой системы.

Оказалось очень удобно работать с системой через OpenOffice Base. MS Query нервно курит в сторонке. Пока я просто добавлял поля в описании таблицы через Base или phpmyadmin, всё было в порядке. Когда проиндексировал некоторые свои поля, чтобы связать их со своими же справочными таблицами (например, в accountinfo храню только ID-ы сканеров и ИБП, а в соответствующих справочниках - модели, чтобы нормализовать БД), тоже без проблем.

Но стоило мне описать внешние (foreign) ключи, то бишь на уровне сервера прописать связь accountinfo с моими справочниками, как начались странности: через веб-интерфейс стало невозможно править эту административную информацию. То есть, submit вроде выполняется, а толку - ноль. Успел уже испугаться, а не снес ли я что ненароком, но оказалось всё просто: если прописаны foreign ключи и их restrain-ы, то OCS с ними не справляется, но и ошибку не показывает. В принципе, логично - разработчики ж не предполагали такой засады с моей стороны :)

Нервов, однако, мне это стоило немалых.