или в sa > mo посмотри

логи или в gui?

трейсов по этому МО нету

@dvolodin смотрю все трейсы, они все одинаковые.

@dvolodin http://pastie.org/10895231

а тип ошибки-то какой?

а тип ошибки-то какой?

ха

нашел

короче, оно у тебя не может скомпилировать код классификатора интерфейсоы

@dvolodin в списке содержаться несколько vlan id

поменял немного скрипт, теперь у апдейта крыша едет и ругается на эти изменения...

@dvolodin в списке содержаться несколько vlan id

выключил этот классификатор и сразу же дискавери отработал как надо

погоди

попробуй с последним моим патчем

он дожен будет тебе ругнуться, что не удалось скомпилировать правила раскраски

А вообще -- тебе нам не vc filter надо

а value

или тогда не eq а in

или тогда не eq а in

я хотел универсально сделать, т.к. есть контроллеры, которым список vlan ается, а есть которым только 1 vlan

Просто 2 придется классификатора сделать скорее или логическое or как-то

не

замени eq на in

должно работать

ну так заработает, да

так

ищу JS-программиста

чтобы как раз такие вот проверки пилить в морде

если есть на примете кто - сдавайте мне тепленьким

@dvolodin

Почему он eq не принимает нормально?

eq с value работает

in - с vc fliter

вот, спасибо

in с value работает?

нет

жаль

было бы еще удобно добавить выбор между строк or/and, а то только and получается

прошу прощения, при синхронизации коллекций получил дублирование ключа в монге: Tried to save duplicate unique keys (E11000 duplicate key error collection: noc.noc.objectmodels index: name_1 dup key: { : "Juniper | MX | PWR-MX480-2520-AC-S" }) Удалить эту запись в монге и пересинхронизировать? Как поступить?

прошу прощения, при синхронизации коллекций получил дублирование ключа в монге: Tried to save duplicate unique keys (E11000 duplicate key error collection: noc.noc.objectmodels index: name_1 dup key: { : "Juniper | MX | PWR-MX480-2520-AC-S" }) Удалить эту запись в монге и пересинхронизировать? Как поступить?

У тебя откуда эта моделька?

hg status

прошу прощения, при синхронизации коллекций получил дублирование ключа в монге: Tried to save duplicate unique keys (E11000 duplicate key error collection: noc.noc.objectmodels index: name_1 dup key: { : "Juniper | MX | PWR-MX480-2520-AC-S" }) Удалить эту запись в монге и пересинхронизировать? Как поступить?

Вообще да, надо сравнить их и удалить старую. изменения лучше закоммитить и оформить пулреквест

Сегодня сделал пул из башни и затем деплой, и вывалилось вот это

root@urannocnode1:/opt/noc# hg status ? static/img/uran-logo-16x16.ico ? static/img/uran-logo-34x24.gif root@urannocnode1:/opt/noc#

То есть у меня эта именно модель не использовалась

прошу прощения, при синхронизации коллекций получил дублирование ключа в монге: Tried to save duplicate unique keys (E11000 duplicate key error collection: noc.noc.objectmodels index: name_1 dup key: { : "Juniper | MX | PWR-MX480-2520-AC-S" }) Удалить эту запись в монге и пересинхронизировать? Как поступить?

Я так понимаю инсталяция eval?

Да

Точнее, отличная от prod?

Да

Если нет никаких собственных изменений - лучше выбрать prod

Есть, вернее еще не перенесены из старого НОК, так что будут, так что жить придется с eval

Можно сравнить модельки и удалить старую, пересинхронгизировать бд и сделать деплой еще раз

Если нет никаких собственных изменений - лучше выбрать prod

Не стоит

Ибо потащатся куски инфраструктуры которая всем не нужна

Подскажите, что надо сделать что-бы в карточке устройства отображался статкс портов (тот же Zyxel) ? В скриптах get_int_status отрабатывает нормально в ручном режиме

статус

в periodic discovery включить interface status

есть такое..

Короче это диверсия какая-то :) Дубликатов оказалось штук 10 все объекты Джунипера, EX-ы и запчасти к MX-480

Вычистил все старые и синхронизировался Но откуда такое прилетело счастье - не знаю

Вычистил все старые и синхронизировался Но откуда такое прилетело счастье - не знаю

старые откуда были?

ХЗ. Значит с каким-то пулом получил или в результате миграции, скорее второе... В старом НОК-е ведь эти объхекты вроде есть

ХЗ. Значит с каким-то пулом получил или в результате миграции, скорее второе... В старом НОК-е ведь эти объхекты вроде есть

Скорее со старым ноком

100%

Их при миграции не затащили в новый нок, вот и заново делали

скорее всего притащил в базе

а local не забрал

механизм синхронизации, похоже, нужно доработать

Ага, понятно. Спасибо за консультацию!

убрать нафиг эти манифесты

а результат импорта в базу залить

с путями и суммами

ждем тушенку, много трейсов, фиксить надо

тушенка вроде начала писаться

А для чего нужен Profile Check Rule ?

автоматом определяет профиль железки

первый раз и при замене

очень полезная вещь

так

./noc script .... --beef=<файл или каталог>

пишет тушенку

./noc beef view <файл> -- просмотр

./noc beef test <файл> -- тестовый прогон

пока в тушенку пишет cli и snmp.get

?

теперь надо подумать, как нам эту тушенку в одном месте собирать

может сарзу делать анонимизацию какую то ?

нет

их просто скрыть надо

например все адреса в конфиге заменять на последовательно растущие 192.168.0.0/24

чтобы в паблике не светилось

не надо

тесты будут недостоверными

в любом случае я когда тебе кидал тушенку из домры так и делал

формально, конечно, можно сделать ./noc beef anonymize <....>

но там нужно менять ip

маки