• work ? networking Импортозамещаемся. Если раньше у меня был ActiveDirectory, и я нагло использовал его как каталог сервисов, то теперь у меня ни какого LDAP или другого централизованного каталога не будет, а дискаверинг делать надо.
    В dns никто не пустит, потому все варианты dns-sd / mDNS в отвал сразу.
    SSDP / UPnP — не то чтобы меня поддергивало от HTTPU, с применением XML...
    SLP или накостылить самопальный udp multicast?
    Што делоц? Пойду читать мануалы всего подряд.

Replies (36)

  • @alex0b, avahi ёба
  • @L29Ah, Он сам мультикастит это всё.
  • @L29Ah, Avahi, a free-software (LGPL) implementation of mDNS/DNS-SD . И кажется я зря сразу выкинул mDNS/DNS-SD, надо больше букв почитать. Спасибо.
  • @alex0b, Какое-то странное замещение методом отрубания головы. А логины и пароли в текстовом файле будут теперь храниться?
  • @vt, Почти. В переди будет поставлен IdentityServer а за ним будет либо базка, либо AD / LDAP (если он таки есть у заказчика собственный), и руглярно оба варианта одновременно. Заказчики без AD вполне были, но мы без него не работали. Приходилось тащить с собой на горбу.
  • @alex0b, дискаверинг делать надо
    так делай!

    github.com
  • @Ilya-S-Zharskiy, так я и опенлдап мог бы поднять, тем более что в астралюлюпсе он есть коробочный. тем более, что это монга какая-то со своим тихушным api. openldap хотя бы протокол известный людям имеет, клиентов под разное. в общем, я ищу децентраллизованное с минимальными зависимостями решение.
    углубившись понял, что avahi тоже идет в топку, потому как он на базе (mDNS), что, пишут, несовместимо с dns нормального человека. я не могу навязывать такое решение.
    пока смотрю на slp
  • @alex0b, так там и bind есть коробочный, в чем проблема вообще
  • @alex0b, Хуй знает, у нас в офисе и dns, и mdns работают. По mdns автоподсасываются принтеры кроссплатформенно.
  • @vt, проблема в том, что я не расберипи под кроватку запихиваю, которую я заплою как хочу в единственном экземпляре в свою сеть, которую только я контролирую.
    комлекс многомашинный, разворачивается у кучи разных заказчиков в разных сетях, с разными вариантами поставки, одновременно и порознь. в одной конторе одна политика, в другой другая. но самое страшное не это, а то что обслуживающий персонал везде разной подготовки — и недостаточноквалифицированного очень много. предусмотреть все варианты физически невозможно. а админить это все отсюда я не хочу, тем более что не имею ни навыков ни опыта.
    потому единственное возможный путь решения это:
    1. ни за что никогда не добавлять новый компонент
    2. если добавил, он не должен торчать вне комлекса
    3. если торчит, он не должен админиться и настраиваться
    4. если его админишь ты — то тебе пиздец в прямом смысле
  • @alex0b, Ну вот, dns и bind — самое простое решение! Оно просто работает
  • @L29Ah, по идее ваше не должно быть проблемы, сами протоколы по себе независимы. как я могу понять корявые буквы в документациях, проблемы dns + mdns следует читать как "нельзя поднимать бинд и авахид на одной машине". но с другой стороны. я не могу вот так взять и сказать, ребята на наших серверах никогда не будет bind, потому что я забил. завтра придут и скажут надо. и вот тогда, когда кто-то скажет надо — он и будет это админить. но не я.
  • @alex0b, нельзя поднимать бинд и авахид на одной машинеЯ разрешаю.
  • @vt, за 8 лет софта у них в продакшене они не могут читать документацию, они не могут научиться давать права доступа. не могут читать логи и не могут решать проблемы со своим барахлом, не говоря уже про наше хотя у них есть службы и для первого и для второго. потому нет, ничего не работает нигде
  • @alex0b, Ну а щас ты хочешь на коленке написать аналог dns и надеешься что он будет лучше работать без твоей помощи?
  • @vt, почему днс? днс я не замещаю и не хочу. multicast dns мне совсем не нравится, оно там само как-то конфигурируется в зоне .local которую само и поддерживает. при этом днс мне не нужен, считаем что он есть, внешний. из всего mdns мне были бы интересны только srv записи, но так как там никаких квалификаторов и атрибутов не допилить (или я не стал читать как это делать), то мне это совсем неинтересно. меня в этом отношении больше ldap устраивал, но я не могу заставить его менять внешний, а тащить не хочу.
    в любом случае все перечисленные в /0 протоколы и технологии децентрализованные и никакой демон в общем случае не нужен на сервере, придуманные для дискавернга сервисов или его умеют, срут мультикаст пакетами, отличие только в групповом адресе/порте и содержимом. в содержимом или dns-пакет или другое текстовое гавно. самый легкий и понятный из них slp, при том что единственный который имеет RFC.
    и топик я запил именно потому, что я не хочу рядом велосипедить еще один.
    да, в случае когда я втащу в свой компонент реализацию, например, slp — мой компонент не будет работать без моей поддержки, но он и раньше не мог. а использование стандартного протокола дает мне возможность не пилить адаптеров под весь спектр интегрируемых с нами сторонних решений.
  • @alex0b, Эмммм, в dns-sd как раз каждый мульткастит свои srv-записи. И local там необязательно, можно задать свой домен, чтоб ни с кем не перепутать, то есть конфликтов с dns, если кто-то поднимет .local зону, тоже не будет. И клиентов dns-sd как собак, а с slp все сложнее.
  • @vt, да, я читал по диагонали. ты рекомендуешь по опыту использования или сравнив технологии?
  • @alex0b, Я в первую очередь рекомендую dns, во вторую очередь dns-sd, в третью уже все остальное :)
  • @vt, ну я не просто так спросил. у меня вполне практические вопросы
    1. как правило комплекс в продакшене разворачивается в 2-3 ипостасях (боевой, тестинг и девелоп — для местных автоматизаторов. мы называем такую ипостась — "домен комплекса", но чтобы не смешивать термины — я не буду этого тут делать). разумеется, они не должны пересекаться. при этом клиентский арм может захотеть и увидеть всех, чтобы выбрать новую ипостась и переподключиться к ней и сосать сервисы только ее.
    в одном адресном пространстве это делается дополнительным квалификатором — именем ипостаси
    разносить по разным мультикаст-группам — не факт что разрешено, но и клиенту в общем случае не известен перечень этих групп.
    в dns-sd / mdns среде можно попробовать разводить по разным зонам, но имена заранее клиенту не известны. если только такие днс не имеют возможность получить списком все зоны. но что-то я сомневаюсь. а в запросе предать я не увидел как, костылить не ок.
    2. у нас есть, скажем вебсервисы в т.ч. которые по мимо сервер:порт имеют путь, я не вижу способа сделать это через dns. докостыливать через каталог именно вебсервисов неохота.
  • @alex0b, В одной зоне все можно сделать, srv-записями типа _service-devel._tcp и _service-staging._tcp. А пути к хттп-сервисам написать в TXT-записи.
  • @vt, " _service-staging" — я это и называл "костылить", там и длина приличная и кириллица должна быть везде. да, должна. и самое главное — смертный не знает всего списка этих зон, он произвольно именуется и количество разное.
  • @alex0b, Это не костылить, SRV-записи для этого и предназначены. Смертному естественно это показывать совершенно не нужно, нужно иметь табличку с соответствием имен сервисов и человекочитаемых имен, в которых уже вот и будет кириллица.
  • @vt, Костылить — это в имя сервиса втыкать имя ипостаси. Костылить — это юзать txt записи для анонса вебсервисов и всем говорить, что это взрослый дискаверинг. Зачем подгибать под это днс-сд, если другие протоколы объективнее лучше подходят? Если костылить от остальных прятать, то нет никакой радости и профита от использования стандарта
  • @alex0b, Каждый принтер анонсит урлы своих админ-страниц в TXT
    Каждый жаббер-сервер анонсит урл http-подключения в TXT :)
  • @alex0b, другие протоколы объективнее лучшеКакие? Читать записи из днс можно любым утюгом. А где брать какой-то там slp-клиент — неизвестно, ну кроме как писать его самому и потом дебажить годами.
  • @alex0b, алсо — каждый верификатор владельца домена просит прописать в днс вообще рандомные гуиды, а ты слово devel прописать боишься :)
  • @alex0b, а еще сейчас модно прописывать в днс публичные ключи шифрования! В общем, в днс пихают все подряд, не надо стесняться!
  • @vt, бинд нинужен
  • @Ilya-S-Zharskiy, Ну unbound, какая разница, если Microsoft DNS ему запретили
  • @L29Ah, я не разрешаю поднимать бинд
  • @vt, так и говори, ёпта!
  • @Ilya-S-Zharskiy, Так unbound в его коробке может отсутствовать
  • @alex0b, зона .local тоже НИНУЖНА

    ХЗ кто вас учил, где и когда
    но не делайте так!
  • @Ilya-S-Zharskiy, Зона .local не нужна, ибо она забита за mDNS
  • @Ilya-S-Zharskiy, никто меня этому не учил. я совсем не админ, не сетевик и не девопс и все такое. но наши в эту сторону не думают. они вообще не всегда думают. но это другая история. к слову, у нас в интранете, все в зоне локал. да. несколько доменов.