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

Пятница, 13-е?

Утром перегрузил рабочий комп (сервер 2003, лицензионка) после установки обновлений. Перестал запускаться mysql, который поддерживает OCS-NG. Именно как служба: из командной строки запускается и работает нормально.
Играюсь с параметрами службы, рву волосы на голове - вылетает с криком "got signal 11".
Перезагрузка.
Фиг там.
Удаление службы.
Перезагрузка.
Пересоздание службы.
Фиг там.
Перезагрузка.
Фиг там.
Меняю в реестре командную строку службы с

D:\xampp\mysql\bin\mysqld-nt --defaults-file=D:\xampp\mysql\bin\my.cnf mysql

на

D:\xampp\mysql\bin\mysqld-nt --defaults-file=D:\xampp\mysql\bin\my.cnf

Уже не вылетает, а долго-долго запускается и тихо умирает.

Возвращаю обратно:

D:\xampp\mysql\bin\mysqld-nt --defaults-file=D:\xampp\mysql\bin\my.cnf mysql

Заработало.
И что это было? Неужто день недели и число так повлияли?

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

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

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

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

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

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

А у вас есть аварийный план на случай зомбопокалипсиса?

Есть очень интересная бесплатная система учета СВТ и связанных с ней ресурсов - SpiceWorks. (на самом деле это не только учет компьютеров, а довольно мощная система мониторинга сети и т.п.) Локальный сервер, точнее - его веб-интерфейс, тесно интегрирован с "домашним" сервером разработчиков, поэтому в одном окне браузера мы можем как обслуживать свои инвентарные списки, так и участвовать в работе сообщества (SpiceWorks community).
Среди прочего, в сообществе огромный форум со множеством направлений и тематик. Было бы странно, не окажись там уголка (а скорее всего - далеко не одного), где усталые компьютерщики могли бы отвести душу и расслабится. Один из таких форумов называется Water Cooler (охладитель воды). В этой группе попалась ссылка на статью в разделе "how-tos" ("советы как что-то сделать"). Меня несколько удивило название совета и я прочел его.
Как говорится, рыдалЪ: Ensure your DR Plan is ready for a Zombie Apocolypse^* - Убедитесь, что в вашем плане восстановления после аварии предусмотрен и случай зомбопокалипсиса.

(a little tongue in cheek humor on a serious subject)
Disaster Recovery Planning is one of the most important tasks that we as admins perform, and we need to plan for all problems. When was the last time you watched a zombie flick and there weren't computer problems. Do you want to be one of the admins who blows your uptime metrics because all you care about is tasty brains or would you rather be able to proudly announce "I survived a zombie apocolypse and I still have five nines of uptime?"

(немного смеха по серьезному поводу)

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


Под катом - английский оригинал, позже постараюсь сделать перевод.