Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
Нет, не рассматривал, потому как все клиентские данные по любому в MySQL. Но, думаю, таковой тоже не будет. Будет максимум двухсторонний конвертер LDAP <-> dhcpd.conf/dhcpd.leases.
Моё предположение строится на том, что dhcpd НЕ читает эти файлы во время работы. При старте он их считывает, парсит и потом хранит данные в памяти в своих собственных структурах (как я понял в случае 4.x они активно задействовали хеши для уменьшения времени отклика, с этим же связана «непредсказуемость» порядка выдачи адресов), а в dhcpd.leases только дописывает «чтоб не забыть».
Следовательно, без переделки внутренней структуры работы с объектами, то есть создания прослойки, которая будет получать и сохранять актуальное состояние объектов либо посредством запросов к LDAP, либо в своих собственных структур данных, всё остальное не имеет смысла. Процесс dhcpd просто не узнает, что что-то изменилось до рестарта, а прочесть и распарсить 2 родных файла — всяко быстрее нескольких сотен запросов к LDAP/SQL/etc.
Моё предположение строится на том, что dhcpd НЕ читает эти файлы во время работы. При старте он их считывает, парсит и потом хранит данные в памяти в своих собственных структурах (как я понял в случае 4.x они активно задействовали хеши для уменьшения времени отклика, с этим же связана «непредсказуемость» порядка выдачи адресов), а в dhcpd.leases только дописывает «чтоб не забыть».
Следовательно, без переделки внутренней структуры работы с объектами, то есть создания прослойки, которая будет получать и сохранять актуальное состояние объектов либо посредством запросов к LDAP, либо в своих собственных структур данных, всё остальное не имеет смысла. Процесс dhcpd просто не узнает, что что-то изменилось до рестарта, а прочесть и распарсить 2 родных файла — всяко быстрее нескольких сотен запросов к LDAP/SQL/etc.
НЛО прилетело и опубликовало эту надпись здесь
Вобще-то существует заплатка на ISC DHCP для работы с LDAP и в т.ч. динамических запросов — перезагружать надо только после добавления подсети.
У меня аботает вплоть до версии 3.0.7. Посмотреть можно здесь: bugs.gentoo.org/show_bug.cgi?id=160979
У меня аботает вплоть до версии 3.0.7. Посмотреть можно здесь: bugs.gentoo.org/show_bug.cgi?id=160979
Я рассматривал вариант связки DHCPD+LDAP. Впечатление одно — это злое**чий п**дец.
Привязка эта сделана в виде говноскрипта, который выдирает инфу из LDAP, генерирует конфиг, запускает сервер с временным конфигом. Соответственно, в LDAP хранится абсолютно неудобоваримая для человека структура (зато скрипт работает, ага), никакого подхвата конфигурации на лету. Я бросил это занятие, едва начав.
Мы в конце концов сделали связку dnsmasq+LDAP в качестве DHCP-сервера. На текущий момент оно умеет таскать оттуда только статические лизы (кстати, сохраняя статические лизы в файл для лиз, в отличие от), из-за отсутствия кеширования изменения в LDAP моментально отражаются на работе сервера. Работает очень стабильно, но про открытость кода патча ничего не могу сказать.
Привязка эта сделана в виде говноскрипта, который выдирает инфу из LDAP, генерирует конфиг, запускает сервер с временным конфигом. Соответственно, в LDAP хранится абсолютно неудобоваримая для человека структура (зато скрипт работает, ага), никакого подхвата конфигурации на лету. Я бросил это занятие, едва начав.
Мы в конце концов сделали связку dnsmasq+LDAP в качестве DHCP-сервера. На текущий момент оно умеет таскать оттуда только статические лизы (кстати, сохраняя статические лизы в файл для лиз, в отличие от), из-за отсутствия кеширования изменения в LDAP моментально отражаются на работе сервера. Работает очень стабильно, но про открытость кода патча ничего не могу сказать.
полезная статья, ставлю плюс и в закладки.
Долго мучился с ISC DHCPD, в результате перешёл на dnsmasq, довольный как слон. Плюсы:
1. настраивается всё, что может прийти в голову
2. умеет перегружать конфиги по сигналу
3. статические привязки хранятся не в основном конфиге, а в отдельном файле очень просто формата, местонахождение которого указывается в конфиге. Парсить такой файл — одно удовольствие, если есть на то необходимость.
4. дополнительные атрибуты записываются в конфиге просто и понятно. Например, мне нужно было отдавать пользователям маршрут на подсеть. По умолчанию маршруты настраиваются только на отдельный хост. Как выглядит настройка этого атрибута в isc и dnsmasq: www.ezgr.net/blog/2009/03/diffusing-classless-routes-in-isc-dhcpd-and-dnsmasq/
5. в leases пишутся все выдачи, как динамические, так и статические
6. и многое другое, чего я уже не помню. Пару лет назад dnsmasq меня совсем не впечатлил, а теперь — прекрасный продукт.
При этом у меня не было необходимости удалять лизы раньше времени и отдавать адреса по option 82, поэтому не знаю, как dnsmasq с этим справляется.
1. настраивается всё, что может прийти в голову
2. умеет перегружать конфиги по сигналу
3. статические привязки хранятся не в основном конфиге, а в отдельном файле очень просто формата, местонахождение которого указывается в конфиге. Парсить такой файл — одно удовольствие, если есть на то необходимость.
4. дополнительные атрибуты записываются в конфиге просто и понятно. Например, мне нужно было отдавать пользователям маршрут на подсеть. По умолчанию маршруты настраиваются только на отдельный хост. Как выглядит настройка этого атрибута в isc и dnsmasq: www.ezgr.net/blog/2009/03/diffusing-classless-routes-in-isc-dhcpd-and-dnsmasq/
5. в leases пишутся все выдачи, как динамические, так и статические
6. и многое другое, чего я уже не помню. Пару лет назад dnsmasq меня совсем не впечатлил, а теперь — прекрасный продукт.
При этом у меня не было необходимости удалять лизы раньше времени и отдавать адреса по option 82, поэтому не знаю, как dnsmasq с этим справляется.
Почитал сколько проблем у вашего ISC DHCPD. Не стоит в таком случае заменить его на более адекватное средство, в чём его главное преимущество над другими решениями?
В данном случае это была «данность» — он уже был установлен и использовался. Хотя, по сути isc dhcpd — это стандарт de facto, для Unix систем на протяжении многих лет.
Синтаксис конфига тот же что у bind'a. Ставится в качестве DHCP сервера по умолчанию большинством дистрибутивов, имеется масса документации и примеров, море функционала, гибкая конфигурация, которая довольно легко скриптуется. Запроссы можно классифицировать и давать разные варианты ответов практически по любым критериям, вплоть до анализа содержимого пакетов и всяких дополнительных vendor-specific полей. Группы и классы объектов, условия применения настроек к объектам и их группам на базе довольно гибких критериев. И всё это не раз пройдено и придумано массой людей, надо только хорошо поискать или почитать документацию. Мне кажется это близко к самой сути open-source системы: можно всё, если готов поискать или подумать как это сделать. :)
В общем-то, на мой взгляд, его единственный серьёзный недостаток — это отсутствие полноценного real-time управления (но в этом направлении уже ведётся какая-то работа — API+omshell). К тому же в комплекте с поддержкой failover механизма перезапуск одного dhcpd перестаёт быть проблемой для пользователей. Просто «некрасивенько как-то» рестартить его «по мелочам». Впрочем это тоже происходит быстро.
Несколько расстраивает также отсутствие GUI/Web интерфейса, но, при обдуманном внедрении, прекрасно управляется и без всякого GUI (на моей памяти это первый раз когда понадобилось приделать что-то такое), либо не так уж сложно прикручивается к имеющимся системам учёта клиентов — конфиг несложно сгенерить, leases легко парсятся и перезаписывать файл целиком не надо — достаточно дописать изменения в конец. Да, надо немного повозиться, зато не надо платить за лицензии и получаешь огромную гибкость и систему проверенную годами. ;)
Что касается других проектов — кроме dnsmasq ничего более-менее доведённого до ума из open-source я не нашёл, возможно плохо искал… Dnasmasq отпугнул меня ощущением нераспространённости: минималистичный сайт, странное доменное имя, минимум документации, мало информации в google. Либо это продукт, который на столько идеален и интуитивно понятен, что не нуждается в поддержке, документировании, обсуждении, либо, если таки нуждается, будет заведомо сложнее найти решение. Я предположил второй вариант и отложил dnsmasq в «стратегический резерв».
Синтаксис конфига тот же что у bind'a. Ставится в качестве DHCP сервера по умолчанию большинством дистрибутивов, имеется масса документации и примеров, море функционала, гибкая конфигурация, которая довольно легко скриптуется. Запроссы можно классифицировать и давать разные варианты ответов практически по любым критериям, вплоть до анализа содержимого пакетов и всяких дополнительных vendor-specific полей. Группы и классы объектов, условия применения настроек к объектам и их группам на базе довольно гибких критериев. И всё это не раз пройдено и придумано массой людей, надо только хорошо поискать или почитать документацию. Мне кажется это близко к самой сути open-source системы: можно всё, если готов поискать или подумать как это сделать. :)
В общем-то, на мой взгляд, его единственный серьёзный недостаток — это отсутствие полноценного real-time управления (но в этом направлении уже ведётся какая-то работа — API+omshell). К тому же в комплекте с поддержкой failover механизма перезапуск одного dhcpd перестаёт быть проблемой для пользователей. Просто «некрасивенько как-то» рестартить его «по мелочам». Впрочем это тоже происходит быстро.
Несколько расстраивает также отсутствие GUI/Web интерфейса, но, при обдуманном внедрении, прекрасно управляется и без всякого GUI (на моей памяти это первый раз когда понадобилось приделать что-то такое), либо не так уж сложно прикручивается к имеющимся системам учёта клиентов — конфиг несложно сгенерить, leases легко парсятся и перезаписывать файл целиком не надо — достаточно дописать изменения в конец. Да, надо немного повозиться, зато не надо платить за лицензии и получаешь огромную гибкость и систему проверенную годами. ;)
Что касается других проектов — кроме dnsmasq ничего более-менее доведённого до ума из open-source я не нашёл, возможно плохо искал… Dnasmasq отпугнул меня ощущением нераспространённости: минималистичный сайт, странное доменное имя, минимум документации, мало информации в google. Либо это продукт, который на столько идеален и интуитивно понятен, что не нуждается в поддержке, документировании, обсуждении, либо, если таки нуждается, будет заведомо сложнее найти решение. Я предположил второй вариант и отложил dnsmasq в «стратегический резерв».
По пункту 4: есть способ вызова скрипта при действиях commit, release, expiry, причём он появился ещё в 3 версии, пример использования:
on commit {
set macAddress = binary-to-ascii(16,8,":", substring(hardware,1,7));
set ipAddress = binary-to-ascii(10,8,".",leased-address);
set leaseTime = binary-to-ascii (10,32,"",encode-int (lease-time,32));
set eventAction = «commit»;
if ( exists host-name ){
execute("/opt/scripts/dhcpd_evt.sh", eventAction, macAddress, ipAddress, leaseTime, concat("\"", option host-name, "\""));
}
else {
execute("/opt/scripts/dhcpd_evt.sh", eventAction, macAddress, ipAddress, leaseTime);
}
unset macAddress;
unset ipAddress;
unset eventAction;
}
В итоге вызывается:
/opt/scripts/dhcpd_evt.sh commit 0:1c:bf:ac:6:4b 192.168.0.16 86400 «dsvaio7»
в котором обрабатываем действие
Остальные по аналогии и работают как для прописанных в конфиге, так и для динамических.
У меня таким способом через внешний скрипт реализовано обновление DNS записей в базе PowerDNS.
on commit {
set macAddress = binary-to-ascii(16,8,":", substring(hardware,1,7));
set ipAddress = binary-to-ascii(10,8,".",leased-address);
set leaseTime = binary-to-ascii (10,32,"",encode-int (lease-time,32));
set eventAction = «commit»;
if ( exists host-name ){
execute("/opt/scripts/dhcpd_evt.sh", eventAction, macAddress, ipAddress, leaseTime, concat("\"", option host-name, "\""));
}
else {
execute("/opt/scripts/dhcpd_evt.sh", eventAction, macAddress, ipAddress, leaseTime);
}
unset macAddress;
unset ipAddress;
unset eventAction;
}
В итоге вызывается:
/opt/scripts/dhcpd_evt.sh commit 0:1c:bf:ac:6:4b 192.168.0.16 86400 «dsvaio7»
в котором обрабатываем действие
Остальные по аналогии и работают как для прописанных в конфиге, так и для динамических.
У меня таким способом через внешний скрипт реализовано обновление DNS записей в базе PowerDNS.
проблема с перезагрузкой конфигов решается использованием openldap (dhcpd-server-ldap как то так пакет назывался)
Да, вы правы, но к сожалению пришлось отказаться от этой идеи:
— поддержка версия 4.x в стадии experimental, не хотелось рисковать. Может быть для 3-й это было бы решением.
— гонять данные из MySQL (а клиентские данные в mysql) в LDAP и обратно — реализуется ничуть не быстрее и не проще чем работа с файлами напрямую, так зачем добавлять ещё одно звено
— dhcpd-server-ldap — это сторонний патч, а следовательно, если понадобится срочно обновить сервер из-за критических ошибок — могут быть проблеммы.
— поддержка версия 4.x в стадии experimental, не хотелось рисковать. Может быть для 3-й это было бы решением.
— гонять данные из MySQL (а клиентские данные в mysql) в LDAP и обратно — реализуется ничуть не быстрее и не проще чем работа с файлами напрямую, так зачем добавлять ещё одно звено
— dhcpd-server-ldap — это сторонний патч, а следовательно, если понадобится срочно обновить сервер из-за критических ошибок — могут быть проблеммы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление ISC DHCPd 4.x из скриптов