Расскажу-ка я вам сказку о DHCP option 119
Жил да был юзер в корпоративной сети. И было у него помимо Windows laptop'а некоторое количество Linux и Mac машин.
Жил он не тужил пока коллеги не начали присылать ссылки типа http://somelocalserver12345/somefile.bin
И озадачился тогда этот юзер, почему ссылки работают на Windows но не работают на Linux/Mac.
Беглым поиском было обнаруженно что у Windows есть спрятанные настройки "Primary DNS suffix: europe.corp.example.com" и "DNS suffix search list: europe.corp.example.com, fi.example.com, corp.example.com, example.com".
Естественно для Linux/Mac машин от великого корпоративного DHCP сервера приходило только DNS Domain = "fi.example.com". Юзер конечно расстроился, но поскольку был "умным" написал в поддержку и попросил включить на DHCP сервере опцию domain-search (option 119). Поддержка оказалась обычной, виндовой, и в итоге впала в ступор на несколько дней, приведя в качестве отмастки "у нас тут вот в таком windows диалоге управления DHCP сервером такой опции нет". После пары дней препирательства запрос был проэскалирован до инженеров которые знали чуть больше и знали как обойти стандартные окошки. В итоге, при помощи этих инженеров герой нашей сказки договорился в реальном времени опробовать и потестировать изменения на стороне сервера и как оно скажется на клиенте.
Инженер начал прописывать. Вариант как в описанно в руководстве по Windows DHCP сервер "просто пропишите строку разделенную запятыми" естественно не подошел. Windows посылало строки как есть, разделенных нулевым байтом. Linux/Mac отказывались принимать такое непотребство и тупо игнорировали эти значения. Второй вариант был опробован с разными разделителями: пробел, точка с запятой и т.д. Аналогичный результат. Еще был опробован вариант Array of Strings. Надо ли упоминать что оно не заработало тоже ?
В это время, наш юзер который наблюдал эти попытки впихнуть невпихуемое в Windows DHCP server, нашел в сети статейку в которой описывалось что для Windows хоть в доке и написанно о строке, надо на самом деле прописывать значение опции в виде соответсвующем RFC3397... причем в шестнадцатиричной форме и причем по-байтно.
Дурное дело не хитрое - был написан простенький скриптик:
#!/usr/bin/env python -tt
import sys
hl = []
for d in sys.argv[1:]:
for p in d.split("."):
hl.extend(["0x%02x" % len(p)] + [ "0x"+c.encode("hex") for c in p ])
hl.append("0x00")
print ",".join(hl)
На выходе из него получалось нечто такое:
0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00
Всё вот это бедному инженеру приходилось прописывать в окошке найстройки Windows DHCP server. Причем сделать copy&paste было нельзя. оно жадало чтобы каждый байтик был введен отдельно...
Но скоро сказка сказывается да не скоро дело делается. Вбили, пробуем - работает... Кажется...
Тесты показывают что Mac и Linux теряют значение DNS Domain если в ответе DHCP сервера присутсвует DNS domain-search.
Меняем строку, прописываем.
0x02,0x66,0x69,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00
Пробуем - получаем забавные результаты в /etc/resolv.conf:
MacOS 10.7 (вроде как все хорошо):
domain - отсутсвует.
search fi.example.com europe.corp.example.com corp.example.com example.com
CentOS6/RHEL6:
domain - отсутвует
search fi.example.com. europe.corp.example.com. corp.example.com. example.com.
Debian (stable/testing):
domain fi.example.com
search fi.example.com. europe.corp.example.com. corp.example.com. example.com.
OpenSuSE 11.4/12.1:
domain - отсутвует
search fi.example.com europe.corp.example.com corp.example.com example.com
Ubuntu 11.04:
domain fi.example.com
search fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com.
Ubuntu 12.04:
domain - отсутвует
search fi.example.com europe.corp.example.com corp.example.com example.com
Fedora 15 (какая была под рукой, local.org домен пришел из /etc/sysconfig/network:HOSTNAME=fvm.local.org):
domain fi.example.com
search fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com. local.org
Результат называется - "найдите 10 отличий".
Мораль сей басни такова: будьте осторожны со своими желаниями. Инженеры третьего уровня поддержки могут их исполнить побайтно вбивая продиктованную вами строчку. Но не факт что рельзультат будет вменяемым, поскольку в рядах dhcp клиентов разброд и шатания.
На последок "one more thing" ®: для Cisco так же надо эту опцию прописывать байтиками, хотя и в своем формате. Но там хоть есть copy&paste.
print "Cisco: " + "".join([(".%s" % (x[2:]) if i and not i % 2 else x[2:]) for i, x in enumerate(hl)])
Жил он не тужил пока коллеги не начали присылать ссылки типа http://somelocalserver12345/somefile.bin
И озадачился тогда этот юзер, почему ссылки работают на Windows но не работают на Linux/Mac.
Беглым поиском было обнаруженно что у Windows есть спрятанные настройки "Primary DNS suffix: europe.corp.example.com" и "DNS suffix search list: europe.corp.example.com, fi.example.com, corp.example.com, example.com".
Естественно для Linux/Mac машин от великого корпоративного DHCP сервера приходило только DNS Domain = "fi.example.com". Юзер конечно расстроился, но поскольку был "умным" написал в поддержку и попросил включить на DHCP сервере опцию domain-search (option 119). Поддержка оказалась обычной, виндовой, и в итоге впала в ступор на несколько дней, приведя в качестве отмастки "у нас тут вот в таком windows диалоге управления DHCP сервером такой опции нет". После пары дней препирательства запрос был проэскалирован до инженеров которые знали чуть больше и знали как обойти стандартные окошки. В итоге, при помощи этих инженеров герой нашей сказки договорился в реальном времени опробовать и потестировать изменения на стороне сервера и как оно скажется на клиенте.
Инженер начал прописывать. Вариант как в описанно в руководстве по Windows DHCP сервер "просто пропишите строку разделенную запятыми" естественно не подошел. Windows посылало строки как есть, разделенных нулевым байтом. Linux/Mac отказывались принимать такое непотребство и тупо игнорировали эти значения. Второй вариант был опробован с разными разделителями: пробел, точка с запятой и т.д. Аналогичный результат. Еще был опробован вариант Array of Strings. Надо ли упоминать что оно не заработало тоже ?
В это время, наш юзер который наблюдал эти попытки впихнуть невпихуемое в Windows DHCP server, нашел в сети статейку в которой описывалось что для Windows хоть в доке и написанно о строке, надо на самом деле прописывать значение опции в виде соответсвующем RFC3397... причем в шестнадцатиричной форме и причем по-байтно.
Дурное дело не хитрое - был написан простенький скриптик:
#!/usr/bin/env python -tt
import sys
hl = []
for d in sys.argv[1:]:
for p in d.split("."):
hl.extend(["0x%02x" % len(p)] + [ "0x"+c.encode("hex") for c in p ])
hl.append("0x00")
print ",".join(hl)
На выходе из него получалось нечто такое:
0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00
Всё вот это бедному инженеру приходилось прописывать в окошке найстройки Windows DHCP server. Причем сделать copy&paste было нельзя. оно жадало чтобы каждый байтик был введен отдельно...
Но скоро сказка сказывается да не скоро дело делается. Вбили, пробуем - работает... Кажется...
Тесты показывают что Mac и Linux теряют значение DNS Domain если в ответе DHCP сервера присутсвует DNS domain-search.
Меняем строку, прописываем.
0x02,0x66,0x69,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x06,0x65,0x75,0x72,0x6f,0x70,0x65,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x04,0x63,0x6f,0x72,0x70,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00,0x07,0x65,0x78,0x61,0x6d,0x70,0x6c,0x65,0x03,0x63,0x6f,0x6d,0x00
Пробуем - получаем забавные результаты в /etc/resolv.conf:
MacOS 10.7 (вроде как все хорошо):
domain - отсутсвует.
search fi.example.com europe.corp.example.com corp.example.com example.com
CentOS6/RHEL6:
domain - отсутвует
search fi.example.com. europe.corp.example.com. corp.example.com. example.com.
Debian (stable/testing):
domain fi.example.com
search fi.example.com. europe.corp.example.com. corp.example.com. example.com.
OpenSuSE 11.4/12.1:
domain - отсутвует
search fi.example.com europe.corp.example.com corp.example.com example.com
Ubuntu 11.04:
domain fi.example.com
search fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com.
Ubuntu 12.04:
domain - отсутвует
search fi.example.com europe.corp.example.com corp.example.com example.com
Fedora 15 (какая была под рукой, local.org домен пришел из /etc/sysconfig/network:HOSTNAME=fvm.local.org):
domain fi.example.com
search fi.example.com fi.example.com. europe.corp.example.com. corp.example.com. example.com. local.org
Результат называется - "найдите 10 отличий".
Мораль сей басни такова: будьте осторожны со своими желаниями. Инженеры третьего уровня поддержки могут их исполнить побайтно вбивая продиктованную вами строчку. Но не факт что рельзультат будет вменяемым, поскольку в рядах dhcp клиентов разброд и шатания.
На последок "one more thing" ®: для Cisco так же надо эту опцию прописывать байтиками, хотя и в своем формате. Но там хоть есть copy&paste.
print "Cisco: " + "".join([(".%s" % (x[2:]) if i and not i % 2 else x[2:]) for i, x in enumerate(hl)])