Резолвер переезжал в 2014-2015, а на какой FreeBSD он был раньше — никто уж и не помнит. Зоны переезжали в 2015-2016, а для варианта с хранением данных в SQL (+ веб-интерфейс) как раз задним умом и подумали о PowerDNS, но даже если б вовремя придумали такой вариант — не факт, что заморочились бы. Текстовые файлы — не такой уж плохой вариант, особенно когда что-нибудь сломается или пойдет не так…
Мы после миграции с feebsd/bind на linux/unbound настолько впечатлились результатами (справедливости ради стоит сказать, что feebsd/bind были виноваты не сами по себе, а способ, которым все это было собрано и запущено), что зоны (больше 100 прямых и раз в десять больше обратных) мигрировали на ПО от того же производителя (nsd) — и результатами остались ничуть не менее довольны.
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Довольно давно (больше 5 лет назад, а с предыдущими попытками и больше) исходя именно из эстетических соображений (собрать себе необходимый но достаточный минимум по функциональности и дизайну) я прошел похожий путь подъема солнца вручную (не с LFS конечно, а с Sisyphus — включая сборку, развешивание багов или допиливание некоторых пакетов в нем же) — но еще я выкроил время на то, чтобы описать процедуру не словами, а кодом/конфигурацией (благо удобные инструменты имелись).
Результатом пользуюсь (на серверах, десктопах и бездисковых станциях) до сих пор, пересобирая образы как минимум при выходе каждого стабильного бранча, но иногда и чаще.
Androzic забыт более чем заслуженно, автор в личной переписке сказал буквально следующее: «когда количество нареканий, что Андрозик не может прочитать карты, превысило определённый порог, я решил окончательно отказаться от его поддержки». Меня отсутствие поддержки не смущало до тех пор, пока на моем новом устройстве Androzic тоже не прочел ozfx3. Нужен был мне именно растр (а точнее ГГЦ), поэтому я взял себя в руки и наконец научился изготавливать растровые топографические карты в съедобном для OsmAnd виде с помощью mobac.sourceforge.net (ничего сверхъестественного там нет, самым сложным было добавить интересные мне слои вместо штатных — но это прекрасно документировано и есть примеры)
Пару лет назад было прям очень нужно и выбрали http://www.unigone.com/en/asn1-solutions/asn1compiler/ как самое в тестах адекватное решение (ничего подходящего свободного не нашлось), но потом проект все равно провалился :)
В любом случае спасибо, может еще кому это пригодится. Нам правда актуальнее были не аннотации, а генерация бинов по существующей схеме.
А что в принципе такого умеет collectd и не умеет nagios (давайте исключим разные плагины для сбора разных специфичных метрик)? Я бы разделил средства мониторинга на универсальные (zabbix, nagios со всеми ответвлениями, netxms и т.д. — они пытаются подгрести под себя все, включая инвентаризацию, чем собственно и хороши) и специализированные (а уж среди них сбор/визуализация метрик в духе collectd — кажется самое популярное направление, обработка логов наверное на втором месте). В этом смысле collectd никак не дополняет nagios, он представляет подмножество его возможностей, но при этом позволяет избежать избыточной сложности и снизить требования у ресурсам на мониторинг. Визуально результаты тоже, конечно, отличаются — но это уже по части «нефункциональных требований»
Спасибо за Netdata — любопытная система, очень многое действительно работает из коробки, кастомизируется судя по документации тоже неплохо — надо будет попробовать.
Незаслуженно пропущен NetXMS. У каких-нибудь других систем мониторинга есть дерево объектов в духе первой картинки из https://habrahabr.ru/post/190360/?
Вообще из систем мониторинга нового поколения есть что-то для мониторинга+инвентаризации с разделением объектов мониторинга на группы (возможно вложенные и пересекающиеся)?
Это если вас не заломает вытягивать и раскладывать зависимости руками, иначе частичное зеркало maven (например, средствами nginx proxy_pass и proxy_store) тоже вполне себе вариант.
Я обычно использую его примерно так, чтоб утрамбовать внутрь все внешние зависимости. Если зависимостей нет, как в твоем случае, то все еще проще. может быть достаточно чего-нибудь в таком духе.
Да, была мысль использовать БД и забыть о master/slave и *XFR — но решили пойти более простым классическим путем. Файлы зон лежат в git, не забыть после редактирования исправить сериал и сказать nsd-control reload — не такая уж сверхъестественная задача. Не забыть о git commit можно уже и крону поручить, если самому лень.
Уже некоторое время спустя пришла мысль, что можно было бы использовать powerdns c БД в качестве мастера (а по сути в качестве веб-редактора зон), а несколько экземпляров nsd — в качестве слейвов (и их уже выставили бы наружу). Но не сложилось, а когда еще сложится — может и никогда…
О выборе дистрибутива linux могу сказать одно — удобно, когда майнтейнер nsd ты сам, а с майнтейнером unbound нет никаких разногласий по поводу упаковки :)
Результатом пользуюсь (на серверах, десктопах и бездисковых станциях) до сих пор, пересобирая образы как минимум при выходе каждого стабильного бранча, но иногда и чаще.
В любом случае спасибо, может еще кому это пригодится. Нам правда актуальнее были не аннотации, а генерация бинов по существующей схеме.
Вообще из систем мониторинга нового поколения есть что-то для мониторинга+инвентаризации с разделением объектов мониторинга на группы (возможно вложенные и пересекающиеся)?
Это если вас не заломает вытягивать и раскладывать зависимости руками, иначе частичное зеркало maven (например, средствами nginx proxy_pass и proxy_store) тоже вполне себе вариант.
Официальную документацию, как и всегдаНет, лучше ничего про ivy не читать, почитай лучше про Gradle, можно даже на Хабре :)