Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
Сообщение от opennews (??) on 27-Окт-17, 22:46
Консорциум ISC опубликовал (https://www.isc.org/blogs/kea-1-3-released-take-it-for-a-spin/) релиз DHCP-сервера Kea 1.3.0 (http://kea.isc.org),  идущего на смену классическому ISC DHCP. Исходные тексты проекта распространяются под лицензией Mozilla Public License (MPL) 2.0 (https://www.opennet.ru/opennews/art.shtml?num=32726), вместо ранее применяемой для ISC DHCP лицензии ISC License. DHCP-сервер Kea основан на технологиях BIND 10 и построен (https://www.opennet.ru/opennews/art.shtml?num=36235) с использованием модульной архитектуры, подразумевающей разбиение функциональности на разные процессы-обработчики. Продукт включает в себя полнофункциональную реализацию сервера с поддержкой протоколов DHCPv4 и DHCPv6, способную заменить собой ISC DHCP. В Kea встроены средства динамического обновления DNS-зон (Dynamic DNS), поддерживаются механизмы обнаружения серверов, назначения адресов, обновления и переподключения, обслуживания информационных запросов, резервирования адресов для хостов и PXE-загрузки. В реализации DHCPv6  дополнительно предусмотрена возможность делегирования префиксов. Для взаимодействия с внешними приложениями предоставляется специальный API. Возможно обновление конфигурации на лету без перезапуска сервера. Информация о выделенных адресах и параметрах клиентов может храниться в разных типах хранилищ - в настоящее время предоставляются бэкенды для хранения в файлах CSV, СУБД MySQL,  Apache Cassandra и PostgreSQL. Параметры резервирования хостов могут быть заданы в файле конфигурации в формате JSON или в виде таблицы в MySQL. В состав входит инструмент perfdhcp для измерения производительности сервера DHCP и компоненты для сбора статистики. Kea демонстрирует неплохую производительность, например, при использовании бэкеда MySQL сервер может выполнить 1000 присвоений адресов в секунду (около 4000 пакетов в секунду), а при использовании бэкенда memfile производительность достигает 7500 присвоений в секунду. Новые возможности Kea 1.3: -  Добавлена функциональность общих сетей (Shared networks), дающая возможность группировать вместе несколько подсетей. Клиенту в таких общих сетях динамически назначается адрес из любой подсети, входящей в группу.  При необходимости можно назначать типовые параметры для общей сети, которые могут быть переопределены для отдельных подсетей, классов клиентов или хостов. -  Завершена реализация REST Web API для управления конфигурацией, доступного через HTTPS. Сняты ограничения на максимальный размер запросов и ответов через  REST API, что позволяет применять его для управления крупными конфигурациями; -  Представлены новые библиотеки для интеграции с Kea: -  Библиотека с REST-интерфейсом для управления выделением IP-адресов (lease), позволяющая запрашивать данные о присвоениях адресов, добавлять привязки и изменять установленные связи. -  Библиотека для управления подсетями через  REST API, дающая возможность добавлять, удалять и изменять подсети без перезагрузки полной конфигурации. -  Новый обработчик (hook) command_processed, через который можно подключать внешние библиотеки для переопределения обработчиков определённых команд; -  Добавлено множество мелких возможностей, которые позволили достигнуть паритета в функциональности с ISC DHCP и упростили миграцию с ISC DHCP  на Kea. Например, появилась поддержка опций  21 DHCPv4 и 10 DHCPv6, а также улучшена поддержка специфичных для вендоров опций  DHCPv4 с кодом 43. Добавлена возможность определения опций с привязкой к пулам адресов DHCPv4. Реализовано условное выражение "ifelse"; -  Из путей дальнейшего развития Kea отмечается создание средств для обеспечения отказоустойчивости и создание  экосистемы из внешних скриптов, дополнений, модулей интеграции и интерфейсов. Из недавно появившихся дополнений упоминается скрипт для генерации читаемого списка активных привязок (lease), обработчик Run Script для вызова внешних скриптов для любых доступных hook-ов, набор unit-файлов для systemd. URL: https://www.isc.org/blogs/kea-1-3-released-take-it-for-a-spin/ Новость: https://www.opennet.ru/opennews/art.shtml?num=47461
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
Сообщение от Аноним (??) on 27-Окт-17, 22:46
> а при использовании бэкенда memfile производительность достигает 7500 присвоений в секунду. А с /dev/null наверное ещё быстрее?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от Andrew Kolchoogin (ok) on 27-Окт-17, 23:11
	> А с /dev/null наверное ещё быстрее? Такого бэкенда нет, а напрасно. У Циски в виде 'no ip dhcp conflict-logging', например, есть.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от rshadow (ok) on 28-Окт-17, 00:02
	Честно говоря - не впечатляет. Это уровень какой-то поделки 10 летней давности. Даже учитывая специфику задачи, нормальный асинхронный сервер на сях должен сотни тысяч запросов в секунду держать. Не говоря уж о том что всякие там nginx-сы да nosql-лы миллионы держат.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от Джон Ленин on 28-Окт-17, 23:11
	Ты же понимаешь, что автоматическая конфигурация DHCP зиждется на основе мультикаст-спама, и после присвоения клиент держит конфиг заданный пользовательским Lease-Time, или пытается автоматически перенастроиться после разрыва (если биллинг рвёт соединение раз в сутки). И вот нафига сервер должен позволять слишком частый спам, если речь идёт о задаче "настроилось - и просто работает потом"
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	30. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от Аноним (??) on 30-Окт-17, 10:35
	dhcp-relay? Не, не слышал
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

2. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–4 +/–
Сообщение от letsmac (ok) on 27-Окт-17, 23:06
>> В настоящее время предоставляются бэкенды для хранения в файлах CSV, СУБД MySQL, Apache Cassandra и PostgreSQL Сам функционал приятен - но нафиг не нужен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+5 +/–
	Сообщение от Аноним (??) on 28-Окт-17, 06:45
	Ну и дурак, можно триггерами и вставными функциями все реализовать прямиком из СУБД
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	15. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–2 +/–
	Сообщение от ram_scan on 28-Окт-17, 14:51
	Не всякий бэкенд поддерживает такие плюшки, а те что поддерживают все по разному. Нахрена такой геморрой с "тут играем тут не играем тут рыбу заворачивали" ?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	16. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+1 +/–
	Сообщение от Аноним (??) on 28-Окт-17, 15:58
	SQL бекенд для хранения mac->ip привязок и прочих параметров -- самое оно для ISP.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	17. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от letsmac (ok) on 28-Окт-17, 21:28
	> SQL бекенд для хранения mac->ip привязок и прочих параметров -- самое оно > для ISP. Для таких привязок BDB  или любого key-value индексированного за глаза хватит. Зачем там слон или мускул? Для увеличения кода и памяти?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	31. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от fi (ok) on 30-Окт-17, 16:11
	see: http://www.sauron-dns.jyu.fi/features.shtml теперь удобно более не генерировать .txt :)))
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

5. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+5 +/–
Сообщение от qsdg (ok) on 28-Окт-17, 05:15
> ... в файле конфигурации в формате JSON JSON -- худший формат для конфигов, нельзя комментарии писать, что для конфигов критично. Взяли бы YAML, ну.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+1 +/–
	Сообщение от Аноним (??) on 28-Окт-17, 07:17
	{"comment":"json iz da wurst format"}
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–2 +/–
	Сообщение от Анонним on 28-Окт-17, 12:54
	Не стандартизирован → не поддерживается консольными редакторами (типа vim) → неудобен → бесполезен.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–2 +/–
	Сообщение от Анонним on 28-Окт-17, 12:55
	> Не стандартизирован → не поддерживается консольными редакторами (типа vim) → > неудобен → бесполезен. Не сам JSON конечно, а формат комментариев.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от username (??) on 28-Окт-17, 13:01
	Это ты типа пошутил так? Понятно что можно закосить под комментарии но это не тоже самое.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	41. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от KonstantinB (ok) on 31-Окт-17, 22:23
	JSON вообще изначально задумывался как формат обмена данными между программами, а не что-то, что пишут руками (как конфиги). Если очень хочется, вполне можно расширить JSON комментариями вида // и научить этому парсер JSON-конфигов. Я так пару раз делал, нормально. IDEA даже понимает - подсвечивает комментарии (и выдает предупреждение, что нестандартненько). Но вообще лучше YAML, да.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	44. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от PnD (??) on 02-Ноя-17, 11:56
	Для человекочитаемого — лучше TML (развитие грамматик вида "ключ = значение"). (xml, json, yaml) — для сериализации.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	46. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от adorne on 07-Ноя-17, 20:24
	То-то я и задрался писать конфиг руками, всё на свете проклял с этими скобками, кавычками и запятыми.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

8. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
Сообщение от mumu (ok) on 28-Окт-17, 09:48
Я эту картинку уже лет 6 наблюдаю. А Kea как нигде не было, так и нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от mumu (ok) on 28-Окт-17, 09:53
	А, там же дата есть. Ну ок, 4.5 года.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от rshadow (ok) on 28-Окт-17, 11:02
	Логично. Нужно же дать что-нибудь интересное чтобы народ потянулся. А их архитектурные решения мало кого волнуют.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	22. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+1 +/–
	Сообщение от P.Galloway (ok) on 29-Окт-17, 14:00
	> Я эту картинку уже лет 6 наблюдаю. А Kea как нигде не > было, так и нет. Ну у них в первых релизах (и даже первые неск. лет) - функционал уж сильно малый был, и много чего, что нужно в повседневной работе, не было (сейчас плохо помню, но, ЕМНИП, "изкаропки" не было fallback между двумя dhcp-серверами, что-то с поддержкой некоторых опций DHCP, не было dyn. update DNS и чего-то ещё связанное с особенностями работы с ним разными клиентами), из-за чего в малых сетях у меня его использовать, в принципе бы, не получилось (про большие думать страшно - там бы был показательный забег по граблям достойный SO).
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+4 +/–
Сообщение от Аноним (??) on 28-Окт-17, 11:13
>набор unit-файлов для systemd Поттер не одобряет, нужно только полное встраивание systemd-kead :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от Евгений Ваганович on 29-Окт-17, 00:04
	одобряю!
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+2 +/–
Сообщение от СОВА on 29-Окт-17, 01:54
Смотрел их код. Хотел привязать postgresql. Ужасно. Все завязано на mysql. Привязать фишки постгреса с полями inet и mac невозможно. Ip хранят как число. Рассматривали в качестве перехода на ipv6. Сейчас в качестве dhcp с БД мне кажется гораздо лучше работает freeradius. Но он практически не поддерживает ipv6.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от P.Galloway (ok) on 29-Окт-17, 13:51
	Patches are welcome. А если серьёзно - плохо, но, возможно, в будущих релизах подтянут. Кроме связки с БД у вас с использованием никаких проблем не наблюдалось? Или толком посмотреть в работе, из-за куцей интеграции с БД, не получилось?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от angra (ok) on 29-Окт-17, 19:58
	> Ip хранят как число А как что его хранить надо? Вроде самый естественный и рациональный способ.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от P.Galloway (ok) on 29-Окт-17, 21:59
	Кэп мягко намекает, что IPv4 адрес это массив из 4 октетов, который не совсем есть таки число (что собственно не мешает перегнать его в число и даже обратно). Возможно, что товарищ выше, именно это и подразумевал, что адреса хранятся в виде массивов октетов и для чтения и обработки человеком, мягко говоря, неудобны (ну нельзя взять и посадить "обезъяну" и дать ей задание вбивать при подключении новых абонентов машинное представление адреса, переводя его из человеческого в уме), и, что требуется написать пару функций перевода человеческого представления в "нормальное" и наоборот, я, право, не смотрел внимательно как там у Kea дела сейчас, т.к. знакомился с проектом "в целях общего развития" во времена ещё BIND10 (тогда много чего ещё не было). Сам проект был с хорошим намеченным roadmap, но кол-во багофич, на первых порах, было просто ужасающим, как я понимаю, проекту попросту не хватило финансирования и исправлять это никто не спешит, т.к. уже есть isc-dhcp и другие, и их функционал устраивает большую часть потребителей - зачем вкладываться в что-то непонятное, которое ещё и использовать пока нельзя? Спасибо хоть, что есть гранты, благодаря которым проект ещё не помер окончательно.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от angra (ok) on 29-Окт-17, 22:42
	> Кэп мягко намекает, что IPv4 адрес это массив из 4 октетов, который  не совсем есть таки число (что собственно не мешает перегнать его  в число и даже обратно). И чем же он не число? На всякий случай напоминаю, что с точки зрения собственно IP протокола это единое поле из 32 бит, то бишь обычный unsigned integer, а не массив из четырех октетов, которым придан мистический смысл. > для чтения и обработки человеком, мягко говоря, неудобны (ну нельзя взять и посадить "обезъяну" и дать ей задание вбивать при подключении новых абонентов машинное представление адреса, переводя его из человеческого в уме) Условная "обезьяна" напрямую работает с полями в БД, минуя интерфейс? Вылезайте из криокамеры, сейчас 2017-й, а не 1987-й, когда SQL позиционировался как язык для оператора, а не для кода. Лазить в БД ручками "обезьяны" не будут.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от P.Galloway (ok) on 30-Окт-17, 01:17
	> И чем же он не число? На всякий случай напоминаю, что с > точки зрения собственно IP протокола это единое поле из 32 бит, > то бишь обычный unsigned integer, а не массив из четырех октетов, > которым придан мистический смысл. Из-за долгой истории и legacy в протоколе нет понятий байт, integer и прочих - они есть в конкретных реализациях, в протоколе есть octet, сетевой байт и сетевой бит (bit, бит, обычно его "сетевитость" на словах и в литературе опускается, причём в IP он всегда двоичный, в отличии от <нужное_подставить> , подчёркиваю). Конечное оборудование на уровне "мозгов" может хранить ip-адреса как числа/буквы/whatever_else, не говоря о людях, битвы остроконечников с тупоконечниками вам в пример, и сейчас мы имеем, например, 3-4 "человеческих" способа записи mac-адресов, хотя на взаимодействии железок это не отражается, способы записи масок - туда же, а вывод какого-нибудь сетевого калькулятора, у неподготовленного человека, вызывает ассоциации с мониторами из фильма "The Matrix". Способы полной и краткой записи IPv6, надеюсь приводить как пример не надо (ЕМНИП, в нём 16 октетов и, естественно, железка, при формировании пакета, будет забивать поле целиком). По идее, в базе Kea должно храниться что-то близкое к массиву октетов, что на большинстве современных платформ успешно интерпретируется как число, причём, на некоторых, из-за BE/LE, один и тот же адрес может храниться ну очень по-разному или даже соответствовать разным числам. unsigned integer ли оно или что-то ещё, конкретно будет зависеть от реализации C/CPP (или другого языка) для конечной платформы. Надеюсь, что мой полуграмотный пассаж (я более чем уверен, что до "взрослого адекватного сетевика", мне ещё расти и расти) немого прояснит разницу между числом и ip-адресом. > Условная "обезьяна" напрямую работает с полями в БД, минуя интерфейс? Вылезайте из > криокамеры, сейчас 2017-й, а не 1987-й, когда SQL позиционировался как язык > для оператора, а не для кода. Лазить в БД ручками "обезьяны" > не будут. Сложно додумывать за автора первоначального поста, но, вестимо, из-за этой или похожей причины Kea не вписался в их инфраструктуру, а конвертация и минимальная доработка инструмента под себя - не барское дело. Но тут был скорее толстый троллинг (про числа в полях базы), а я с вашим аргументом про оператора более чем согласен (что и пытался изобразить с некой иронией, простите).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+1 +/–
	Сообщение от angra (ok) on 30-Окт-17, 09:49
	Вам так хочется поговорить за историю и протоколы? Ну давайте поговорим. Начнем с открытия IEN2 от далекого 1977 года и увидим там следующее: Addresses are variable length strings of 4 bit chunks prefixed by a     length.  As address chunks are processed they are removed from their     position at the head of the address chunk string and placed at the     end of the string.  This chunk by chunk circular shifting of the     address allows each node in the hop by hop processing of a message     to examine the part of the address it consumes with out knowing how     much address preceeds or follows that part. Никаких октетов или современного поля на 32 бита. Позже спецификация изменялась. В IEN41, который впервые говорит о IPv4, адреса по прежнему не имеют фиксированной длины, но уже их длина выражается в количестве октетов, а не тетрад. В IEN44 об октетах не говорится, там идет разбиение на 8 bit сетку и 24 bit хост. В IEN54 адреса описываются "fixed length of 4 octets (32bits)", причем по прежнему первый октет это сетка, а три следующий это хост. Наконец в rfc791 идет просто поле 32 bits, которое в зависимости от старших бит представляет собой одно из четырех возможных разбиений на сетку и хост, опять таки битовое разбиение, никаких октетов: Address Formats:       High Order Bits   Format                           Class       ---------------   -------------------------------  -----             0            7 bits of net, 24 bits of host    a             10          14 bits of net, 16 bits of host    b             110         21 bits of net,  8 bits of host    c             111         escape to extended addressing mode Ну и уже значительно позже серия RFC определила произвольное бесклассовое разбиение этих 32 бит на сетку и хост. Там само собой тоже никаких октетов. Как легко заметить, массивы из 4 октетов нигде не фигурировали. А теперь после ностальгических воспоминаний давайте вернемся к изначальному вопросу "как хранить ip в базе?". Какие есть рациональные альтернативы числу, не привязанные к конкретной СУБД?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	33. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от P.Galloway (ok) on 30-Окт-17, 18:18
	> А теперь после ностальгических воспоминаний давайте вернемся к изначальному вопросу "как > хранить ip в базе?". Какие есть рациональные альтернативы числу, не привязанные > к конкретной СУБД? Логично предположить, что 4 двоичных байт (или же 32 двоичных же бита), а число это или нет - будет зависеть от базы/ОС_хоста/etc. Но с вашей позицией я, в целом, согласен, т.к. на большинстве, если не на всех, современных платформ это и будет числом.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	27. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от P.Galloway (ok) on 30-Окт-17, 09:16
	> И чем же он не число? На всякий случай напоминаю, что с > точки зрения собственно IP протокола это единое поле из 32 бит, > то бишь обычный unsigned integer, а не массив из четырех октетов, > которым придан мистический смысл. Из-за долгой истории и legacy в протоколе нет понятий байт, integer и прочих - они есть в конкретных реализациях, в протоколе есть octet, сетевой байт и сетевой бит (bit, бит, обычно его "сетевитость" на словах и в литературе опускается, причём в IP он всегда двоичный, в отличии от <нужное_подставить> , подчёркиваю). Конечное оборудование на уровне "мозгов" может хранить ip-адреса как числа/буквы/whatever_else, не говоря о людях, битвы остроконечников с тупоконечниками вам в пример, и сейчас мы имеем, например, 3-4 "человеческих" способа записи mac-адресов, хотя на взаимодействии железок это не отражается, способы записи масок - туда же, а вывод какого-нибудь сетевого калькулятора, у неподготовленного человека, вызывает ассоциации с мониторами из фильма "The Matrix". Способы полной и краткой записи IPv6, надеюсь приводить как пример не надо (ЕМНИП, в нём 16 октетов и, естественно, железка, при формировании пакета, будет забивать поле целиком). По идее, в базе Kea должно храниться что-то близкое к массиву октетов, что на большинстве современных платформ успешно интерпретируется как число, причём, на некоторых, из-за BE/LE, один и тот же адрес может храниться ну очень по-разному или даже соответствовать разным числам. unsigned integer ли оно или что-то ещё, конкретно будет зависеть от реализации C/CPP (или другого языка) для конечной платформы. Надеюсь, что мой полуграмотный пассаж (я более чем уверен, что до "взрослого адекватного сетевика", мне ещё расти и расти) немого прояснит разницу между числом и ip-адресом. > Условная "обезьяна" напрямую работает с полями в БД, минуя интерфейс? Вылезайте из > криокамеры, сейчас 2017-й, а не 1987-й, когда SQL позиционировался как язык > для оператора, а не для кода. Лазить в БД ручками "обезьяны" > не будут. Сложно додумывать за автора первоначального поста, но, вестимо, из-за этой или похожей причины Kea не вписался в их инфраструктуру, а конвертация и минимальная доработка инструмента под себя - не барское дело. Но тут был скорее толстый троллинг (про числа в полях базы), а я с вашим аргументом про оператора более чем согласен (что и пытался изобразить с некой иронией, простите).
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	32. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+1 +/–
	Сообщение от fi (ok) on 30-Окт-17, 16:18
	>> Ip хранят как число > А как что его хранить надо? Вроде самый естественный и рациональный способ. в Pg есть свой удобный тип для ip, естественно с поиском и сортировками.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от P.Galloway (ok) on 30-Окт-17, 18:25
	> в Pg есть свой удобный тип для ip, естественно с поиском и > сортировками. И ничто не мешает допилить Kea, или, что проще - ваш экземпляр БД, чтобы он хранил значения в нужном вам формате, а возвращал DHCP-серверу "число".
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	35. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от angra (ok) on 30-Окт-17, 19:15
	Может кого-то удивит, но поиск и сортировка работают и для ip в виде числа. Но число, в отличии от специфичного для pg типа, есть во всех БД, что позволяет работать с ними более унифицировано, а не писать костыли для каждой.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	37. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от fi (ok) on 31-Окт-17, 11:34
	> Может кого-то удивит, но поиск и сортировка работают и для ip в > виде числа. Но число, в отличии от специфичного для pg типа, > есть во всех БД, что позволяет работать с ними более унифицировано, > а не писать костыли для каждой. Может кого-то удивит, но…  текст тоже представлен в виде чисел, но нам как-то привычней использовать char или text для него. И вот вам пример условия: contains: inet '192.168.1/24' >> inet '192.168.1.5' ну ка сколько вам нужно накатать кода в mysql??? то что другие базы более отсталые в этом плане не делает их лучше. ))))
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	38. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–2 +/–
	Сообщение от angra (ok) on 31-Окт-17, 13:28
	> Может кого-то удивит, но…  текст тоже представлен в виде чисел, но нам как-то привычней использовать char или text для него Нет, не представлен. Чтобы ты хоть чуть-чуть понял, попробуй сказать каким числом представлено все это предложение. > ну ка сколько вам нужно накатать кода в mysql??? Страницу, нет, не меньше двух!!! Ну или как то так: 3232235781 between 3232235776 and 3232236031 >то что другие базы более отсталые в этом плане не делает их лучше. )))) Чудо, ты больше хеловорда писало хоть что-то? Судя по гениальным выводам - нет.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	39. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от fi (ok) on 31-Окт-17, 14:09
	>> Может кого-то удивит, но…  текст тоже представлен в виде чисел, но нам как-то привычней использовать char или text для него > Нет, не представлен. Чтобы ты хоть чуть-чуть понял, попробуй сказать каким числом > представлено все это предложение. Да без проблем: d0bfd0bed0bfd180d0bed0b1d183d0b920d181d0bad0b0d0b7d0b0d182d18c20d0bad0b0d0bad0b8d0bc20d187d0b8d181d0bbd0bed0bc20d0bfd180d0b5d0b4d181d182d0b0d0b2d0bbd0b5d0bdd0be20d0b2d181d0b520d18dd182d0be20d0bfd180d0b5d0b4d0bbd0bed0b6d0b5d0bdd0b8d0b52e0a - а самому слабо было??? >> ну ка сколько вам нужно накатать кода в mysql??? > 3232235781 between 3232235776 and 3232236031 Упс! это где же тут "192.168.1/24" ??? или ты прямо в голове преобразовал??? Точно не ошибся, сделал обратное преобразование для проверки?  А как насчет IPv6 - смогешь??? тупо отрицать удобства работы с IP в привычной нотации
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от angra (ok) on 31-Окт-17, 17:20
	> Да без проблем: Про число ты так и не понял. Ну ладно, начнешь писать код, поймешь. > Упс! это где же тут "192.168.1/24" ??? или ты прямо в голове преобразовал??? Точно не ошибся, сделал обратное преобразование для проверки? Еще раз повторю, работа оператора напрямую с SQL в современном мире не предполагается. А коду программы удобней и быстрее работать с числовым представлением. Преобразование между "человеческим" и числовым форматом элементарно и оформляется в виде пары функций. Кстати, для этого примера я и написал подобную функцию прямо в консоли браузера, преобразовывать в голове - это для тех, кто не умеет писать код. > А как насчет IPv6 - смогешь??? Да. > тупо отрицать удобства работы с IP в привычной нотации Оно тебе как непрограммисту удобней. А для программиста тупо отрицать преимущество единого кода для работы с разными СУБД. Но этого тебе пока понять не дано. Некоторые вещи требуют личного набивания шишек для понимания.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	43. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
	Сообщение от fi (ok) on 01-Ноя-17, 10:45
	>> тупо отрицать удобства работы с IP в привычной нотации > Оно тебе как непрограммисту удобней. мериешься членом?  банально и неверно >> А как насчет IPv6 - смогешь??? > Да. ты 32бита не осилил распарсить в SQL, куда тебе 128 запихивать в bigint ))))) а мне сейчас 256 бит уже мало ))))) такие задачи
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	45. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от PnD (??) on 02-Ноя-17, 12:07
	Ну и пусть хранят (хорошо, что не строку). Повесьте вьюху с приведением типов и оперируйте ей. Это же ж постгря!
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

29. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
Сообщение от Аноним (??) on 30-Окт-17, 09:58
Порт под MacOS естественно назвать iKea ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	–1 +/–
Сообщение от Daemon (??) on 30-Окт-17, 22:19
Давно отказались от "чистого" dhcp. Только "псевдостатика", только хардкор! И хоть знаешь кому звюздюлей давать после очередного взлома сервака "студентами-практикантами"...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Консорциум ISC представил DHCP-сервер Kea 1.3 "	+/–
	Сообщение от Аноним (??) on 01-Ноя-17, 06:16
	Студни мак не научились подменять? Это что, швейное пту?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема