001/8 APNIC 2010-01 whois.apnic.net ALLOCATED
027/8 APNIC 2010-01 whois.apnic.net ALLOCATED
Как-то так. Все-таки они кончаются :)
Tuesday, January 19, 2010
Saturday, November 21, 2009
iPhone и Amarok
Дошли руки в очередной раз дома настроить синхронизацию музыки с PC на iPhone.
iTunes на любимой платформе вряд ли будет, поэтому коробку надо делать самому :)
Итак, речь пройдет про iPhone с OS версии 2.x и амарок версии 1.4.x.
Особых сложностей во всем этом нет, опишу основные шаги:
1) Поменять значение DBVersion с 4 на 2 ("старый" формат БД iTunes) в /System/Library/Lockdown/Checkpoint.xml
2) Перезагрузиться
3) В /var/mobile/Media/ сделать симлинк iPod_Control -> iTunes_Control
4) Создать директорию iTunes_Control/Device/
5) И записать в iTunes_Control/Device/SysInfo что-нибудь вроде результата выполнения
Далее, монтировать /var/mobile/Media/ по sshfs и рассказать амароку про то, что это iPod или iPhone первой модели. Работает нормально, включая передачу обложек альбомов (утверждается, что для этой фичи полезно -o workaround=rename. Без него не пробовал, с ним - работает)
iTunes на любимой платформе вряд ли будет, поэтому коробку надо делать самому :)
Итак, речь пройдет про iPhone с OS версии 2.x и амарок версии 1.4.x.
Особых сложностей во всем этом нет, опишу основные шаги:
1) Поменять значение DBVersion с 4 на 2 ("старый" формат БД iTunes) в /System/Library/Lockdown/Checkpoint.xml
2) Перезагрузиться
3) В /var/mobile/Media/ сделать симлинк iPod_Control -> iTunes_Control
4) Создать директорию iTunes_Control/Device/
5) И записать в iTunes_Control/Device/SysInfo что-нибудь вроде результата выполнения
sudo usbconfig dump_device_desc | awk '$1 ~ /iSerial/ && length($4) > 20 { print $4 }' | cut -b2-17 | xargs printf "FirewireGuid: 0x%s\n"Далее, монтировать /var/mobile/Media/ по sshfs и рассказать амароку про то, что это iPod или iPhone первой модели. Работает нормально, включая передачу обложек альбомов (утверждается, что для этой фичи полезно -o workaround=rename. Без него не пробовал, с ним - работает)
Tuesday, October 6, 2009
Sunday, October 4, 2009
IPv6 socket API
В копилку плюшек IPv6:
У bind'а есть не слишком удобная, обусловленная суровой необходимостью фича - вместо *:53 биндиться на все алиасы всех интерфейсов, что порождает массу нюансов с очередностью запуска, туннелями и прочим. В IPv6 ситуация проще: в системах, которые поддерживают RFC 3542 и RFC 3494 bind'у достаточно забиндить один сокет, после чего при отсылке UDP-пакета можно указать source-адрес, с которого он отправляется. Судя по ipv6int.net во фре данная функциональность появилась еще во времена 5.2. Удобно!
У bind'а есть не слишком удобная, обусловленная суровой необходимостью фича - вместо *:53 биндиться на все алиасы всех интерфейсов, что порождает массу нюансов с очередностью запуска, туннелями и прочим. В IPv6 ситуация проще: в системах, которые поддерживают RFC 3542 и RFC 3494 bind'у достаточно забиндить один сокет, после чего при отсылке UDP-пакета можно указать source-адрес, с которого он отправляется. Судя по ipv6int.net во фре данная функциональность появилась еще во времена 5.2. Удобно!
Monday, September 7, 2009
Monday, August 17, 2009
Замена nss_ldap
nss_ldap (равно как и pam_ldap) - хорошо. Функции свои они выполняют. Хочется же однако не хорошо, а как можно лучше, чего с ними не получается.
Собственно, вариации на тему "почему плохо" и "как лучше" - Далее...
Во-первых кроме как в позе oneshot оно неюзабельно в силу например особенности sshd закрывать открытые дескрипторы при форке процесса, а на каждый запрос - установка tcp-сессии, установка TLS, аутентификация, собственно запрос и закрытие соединение не совсем здорово.
Во-вторых - нет единой схемы, каждый из модулей, предназначенных в общем-то для того, чтобы выцепить из LDAP какие-то поля у пользователя или группы - имеет свой собственный конфиг со своими собственными дополнительными настройками, в результате чего то, что можно выцепить в рамках одного запроса к LDAP-серверу превращается в кучу дерганий его же разными модулями при логине.
В-третьих, каждой софтине, которая использует что-нибудь типа getpwent() полагается "тяжелый" довесок в виде подгрузки ldap-овских библиотек.
В-четвертых - помимо всего прочего нет кэширования.
Один из вариантов решения проблемы называется nscd и позволяет фактически решить все проблемы, кроме второго пункта.
Очень хотелось написать свой маленький кэширующий ldap-демон, однако он уже нашелся
Основные идеи как раз такие -
* все "клиенты" ходят в unix socket, формат протокола легко расширяем
* сам сервер достаточно мал и быстр, кроме того умеет кипэлайвы и кэширование
Теперь его зовут net/nss_ldapd и он нормально работает под FreeBSD (по крайней мере, на 7+).
Кроме того, текущая реализация FreeBSD nss позволяет достаточно легко добавлять новые категории без модификации кода базы. В результате большой и толстый openssh-lpk patch превращается в 3-4 строчки кода (де-факто вызов nsdispatch(3)), или же несколько больше, если сделать люкапа ключей в файлах полноценной nss-функцией и определять порядок прямо в nsswitch.conf
Попробую в ближайшее время сделать нормальный патч для lpk, заодно вылизать весь nss-код и пропихнуть его еще в openssh-portable
Собственно, вариации на тему "почему плохо" и "как лучше" - Далее...
Во-первых кроме как в позе oneshot оно неюзабельно в силу например особенности sshd закрывать открытые дескрипторы при форке процесса, а на каждый запрос - установка tcp-сессии, установка TLS, аутентификация, собственно запрос и закрытие соединение не совсем здорово.
Во-вторых - нет единой схемы, каждый из модулей, предназначенных в общем-то для того, чтобы выцепить из LDAP какие-то поля у пользователя или группы - имеет свой собственный конфиг со своими собственными дополнительными настройками, в результате чего то, что можно выцепить в рамках одного запроса к LDAP-серверу превращается в кучу дерганий его же разными модулями при логине.
В-третьих, каждой софтине, которая использует что-нибудь типа getpwent() полагается "тяжелый" довесок в виде подгрузки ldap-овских библиотек.
В-четвертых - помимо всего прочего нет кэширования.
Один из вариантов решения проблемы называется nscd и позволяет фактически решить все проблемы, кроме второго пункта.
Очень хотелось написать свой маленький кэширующий ldap-демон, однако он уже нашелся
Основные идеи как раз такие -
* все "клиенты" ходят в unix socket, формат протокола легко расширяем
* сам сервер достаточно мал и быстр, кроме того умеет кипэлайвы и кэширование
Теперь его зовут net/nss_ldapd и он нормально работает под FreeBSD (по крайней мере, на 7+).
Кроме того, текущая реализация FreeBSD nss позволяет достаточно легко добавлять новые категории без модификации кода базы. В результате большой и толстый openssh-lpk patch превращается в 3-4 строчки кода (де-факто вызов nsdispatch(3)), или же несколько больше, если сделать люкапа ключей в файлах полноценной nss-функцией и определять порядок прямо в nsswitch.conf
Попробую в ближайшее время сделать нормальный патч для lpk, заодно вылизать весь nss-код и пропихнуть его еще в openssh-portable
Monday, July 6, 2009
IPv6: DNS TLD
Оказывается, поддержка есть много где
т.е. из популярных GTLD есть почти все: .com, .net, .org, .biz, .info
Про .ru нашел только
(ц) RIPN в конце 2008.
т.е. из популярных GTLD есть почти все: .com, .net, .org, .biz, .info
Про .ru нашел только
As estimated by Andrey Romanov, if the situation favors, state-of-the-art technologies
may be implemented at the end of this year. Vladimir Molchanov, RIPN,
gave a much conservative estimate, saying that implementation of IPv6 and DNSSEC
technologies in RU zone will start next year.
(ц) RIPN в конце 2008.
Subscribe to:
Posts (Atom)
Как выяснилось, фревый ng_netflow умеет экспортировать flow'ы только в 5ю версию.
То есть, это
а) статичный набор полей и
б) поддержка только IPv4.
Необходимый нам IPv6 (и кучу других всяких вкусностей) умеет netflow версии 9. Протокол открыт, прост и позволяет передать достаточно много информации (свои поля в flow'ах, помимо большого списка стандартных полей, вообще произвольные вещи типа состояния коллектора и информации о системе). Как оказалось в процессе реализации экспорта - его абсолютно нормально умеет парсить wireshark, но не умеют ни в каком виде популярные flow-tools. Поэтому для отладки пришлось пользоваться flowd - маленьким секьюрным демоном, живущим в портах.
Несколько сложнее пришлось с собственно IPv6 - если в IPv4 длину заголовка можно посчитать на основании полей, находящихся практически в начале заголовка, то в IPv6 перед собственно upper layer header может быть (практически) произвольное количество разных extended заголовков (куда вынеслись опции фрагментации, IP, роутинга и шифрования) разной длины. "Прыжки" же по заголовкам осложняет то, что никто не обещает, что данные следующего заголовка живут в этом же mbuf (т.е. в этом же блоке памяти).
В результате: первый кое-как рабочий патч доступен для 7.2 и -current разлива этого месяца.
Добавленные control messages:
Версия экспорта: setversion { version=X }. 5я или 9я (по умолчанию)
MTU у интерфейса, куда льем netflow:
setmtu { mtu=X }. 1500 по умолчанию, на данный момент допустимо не больше 2000
Требования по настройке условий анонса шаблонов данных из RFC:
settemplateperiodic { time=X packets=Y }. Шлем шаблоны каждые X секунд или же Y пакетов. 10 минут и 500 пакетов по умолчанию
В планах допилить патч, перенести на все продакшены и попробовать пропихнуть в базу. Посмотрим, что получится.