Он якобы свои тестовые серверы каждые 15 минут создаёт и удаляет

для того, что бы оценить удобство не нужно создавать каждые 15 минут сервера. Достаточно иногда время от времени поднимать тестовые виртуалки, которым было бы достаточно указывать только hostname при установке, не заморачиваясь остальной конфигурацией, не вспоминая, какой dns сервер и где работает - в одном офисе, vpn или дома. Что в этом плохого? Ничего. Что в этом сложного? Только отсутствие стандартного и изкоробочного механизма. Когда-то dhcp считали «ненужным» - ведь почему бы руками не разруливать конфликты ip, записывая список бумажке.

Вопрос не в ненужности dhcp (который нужен), а в конкретном dd-wrt и восстановлении после сбоя. Сохраняйте текущий файл lease'ов dhcp и файл зоны DNS и подсовывайте его соотв. программе после поднятие раутера. В чем проблема?

В чем проблема?

не хранить (постоянно) информацию об именах клиентов на dns-сервере, а динамически ее собирать с клиентов dhcp-сервера и подсовывать dns-серверу

dd-wrt — dnsmasq — /tmp/dnsmasq.leases тут всё

файл простой, создайте его и подсуньте dnsmasq'y

Update: У меня получилось

nslookup kuku1
Server:    10.0.0.138
Address 1: 10.0.0.138 DD-WRT

Name:      kuku1
Address 1: 10.0.0.88 kuku1

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

Из этого следует простая политика: если я делаю надолго то несложно внести изменения в конфигурацию dhcp и dns, а если просто что либо пробую то не стоит беспокоиться о перебоях такого рода. Но естественно это сугубо субъективная точка зрения.

А чтобы не разруливать самому следует переходить на ipv6.

Снова:

1) Хранение leases на стороне роутера бесполезно, так как подохший роутер заменяют посторонние люди. 2) /tmp/ - это RAM роутера = энергозависимая память.

Снова:
Просканируйте сеть, создайте файлы и подсуньте dnsmasq'y на новом раутере.

задача поставлена достаточно четко, но вместо помощи ОПу решить её, множество комментаторов начинают обсуждать ненужность такой задачи. Классика.

Сделай dhcp.leases статичным на роутере. Ну чтобы хранился например в /etc а не /tmp, тогда он переживёт перезагрузку и роутер будет знать кому что было выдано до неё.

Сервер не тестовый. Просто RAM и CPU у него достаточно для поднятия нескольких тестовых виртуалок. Кстати, тестирую виртуалки не только я, так что нужны они не только мне.

Четко поставлена говоришь?

" Интересует решение на стороне КЛИЕНТА " — dhcp-client release/renew

задача решена.

Ах потом было 100500 уточнений? Кого это волнует?

Просканируйте сеть, создайте файлы

впринципе, может выйти рабочее решение. Но по какому протоколу опрашивать сеть? Может есть какие-то расширения dhcp, в которых клиент будет сообщать о своем имени из /etc/hostname?

До боли напоминает:

«Эй, посмотри на меня - делай как я, делай как Я!» (с)

А то что «как ты» в ТЗ не укладывается - пофиг. Главное что оно как-то работает.

Какие ОС? Для винды "nmblookup -A $IP", для линукса ХЗ "ssh $IP hostname"

100500 уточнений? Кого это волнует?

уточнения эти относятся только к способам реализации, а не исходной задачи. Задача не меняется, только более формализуется, это нормальное явление, сбор требований и аналитика называется.

nDNS может не публиковать сервис, а просто уведомлять, что «доступен workstation с таким IP и таким hostname». Делает это по протоколу zeroconf. Просто я не хочу ставить самбу исключительно для того, чтобы хостнейм светился в локалку.

Со стороны клиента все еще? Уже нет. Теперь кто-то, например сам раутер при поднятии опросит сеть и построит себе файлы для dnsmasq

Какие ОС?

Всякие разные пингвинообразные. Никаких форточек или страшных изысков типа колибри/реактось.

Ничего роутер себе не просит. Клиент просто бродкастит имя и адрес. ВСЁ. Роутер сам это подхватит и закэширует. Когда у него спросят имя (если это в среде mDNS кому-то ещё будет надо) - он найдёт в своём кэше нужную запись.

линукса ХЗ «ssh $IP hostname»

да, костыли) костыли мы все горазды городить. Собственно сыр-бор весь в том, что бы обменявшись мнениями и опросив опытных людей выяснить наиболее стандартный способ.

Вариант с «ssh $IP hostname» + скрипт для генерации dhcpd.leases. мной принимается. Кстати:

Most DHCP clients will send their hostname in the host-name option. If a client sends its hostname in this way, the hostname is recorded on the lease with a client-hostname statement. This is not required by the protocol, however, so many specialized DHCP clients do not send a host-name option.

значит не все так плохо, должно работать изкоробки, но почему то не работает, надо понять почему и кто некорректно не обрабатывает client-hostname statement

Клиент просто бродкастит имя и адрес

Постоянно?

Со стороны клиента все еще?

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

По крону, раз в 5 минут, например. Или бОльший кастыль - скрипт: если мой hostname не резолвится - кидаю бродкаст. Новое тестирование через 5 минут.

dhcp-client releas/renew — уже было?

dnsmasq при этом выдаст тот же ip, т.к. изначально он выдает не первый свободный адрес, а использует МАС как хеш при выборе из свободных адресов.

Ну так посылайте с каждого клиента инфу на самый постоянный сервер и он уже закинет файлы конфигурации dnsmasq'a на раутер в случае его (раутера) перезагрузки.

/thread с моей точки зрения проблема решена

Ты уже нашёл приемлимый ДЛЯ СЕБЯ способ решения проблемы. Даже не один способ. Но все эти способы не подходят к КОНКРЕТНО МОЙ СИТУАЦИИ. Если для тебя тред закрыт - будь добр не мешай искать рабочее ДЛЯ МЕНЯ решение.

dhcp-client releas/renew — уже было?

Было. Сервисы, требующие постоянного поддержания соединения сходят с ума при кратковременном отключении сети (которое вызывается renew).