В рамках постепенного перетягивания инфраструктуры на dual-stack захотелось приучить к IPv6 openfire. И, как обычно, возникли нюансы:
diablo-jdk собрано без IPv6 и вообще только для семерки. Есть росто java/jdk16, он с  ipv6 собирается и как-то работает. Вдохновившись успешной сборкой, поменял дьяблу на обычный jdk, перезапустил openfire и лишился 90% контактов в жаббере :)
Дальнейшее обследование показало, что
* openfire использует некий com.sun.jndi.dns  для ресолва SRV записей
* ресолвить через jndi.dns адреса ему не удается. Вообще
* при неудаче ресолве openfire пытается ресолвить уже A(A{3})? через системный ресолвер
* этот com.sun.jndi.dns использует v4-mapped адреса и ipv6 сокеты для хождения в сервера
* есть замечательный kern/127057, посвященный предыдущему пункту
* в довершении, этот же com.sun.jndi.dns? приходит в ужас от нативных v6-адресов в resolv.conf

Все, круг замкнулся. Дьяблу обратно ставить уже не хотелось, финт ушами с нативными v6 серверами не прошел, контакты в сервер обратно не лезли.

В общем, пришлось кое-как починить этот самый kern/127057, не уверен что правильно, наверняка - не полностью, но по крайней мере ресолвер теперь работает.

В общем, лишение человека средств IM местами творит чудеса :)

Какое-то время назад выяснил, что домашний firefox игнорирует наличие ipv6-коннективити и на dualstack-сайты ходит через IPv4. Крутилки в ff вида network.dns.disableIPv6 были выставлены в false, тем не менее - запросы ресолвер упорно отсылал для AF_INET.
Попробовал chrome - тот повел себя абсолютно аналогично, после чего предположение про крутилки где-то внутри операционной системе стало самым реальным. Раскопки исходников firefox показали, что местный ресолвер использует getaddrinfo(3) (на тех платформах, где он есть) с указанием AF_UNSPEC в качестве запрашиваемой family. Небольшая програмка фактически из мана подтвердила предположение про то, что ресолвер возвращает результат с AF_INET первым. Далее, в исходниках libc обнаружилась функция reorder(), вытаскивающая некие политики реодинга из ядра по net.inet6.ip6.addrctlpolicy. Через какое-то время нашлось ip6addrclt(8), с загружнной политикой предпочтения ipv4 (::ffff:0.0.0.0/96 prec 50). Предпочтение было выкинуто и все заработало как и планировалось. А можно было просто перезагрузиться после указания ipv6_enable="YES", судя по /etc/rc.d/ip6addrctl.

Написал письмо в cctld.ru - говорят, что поддержка IPv6 glue фактически есть. Тем не менее, из-за согласований в различных инстанциях (IANA, например) и прочей организаторской работы - ориентировочные сроки - конец 2010 года. Уже неплохо, впрочем

001/8 APNIC 2010-01 whois.apnic.net ALLOCATED
027/8 APNIC 2010-01 whois.apnic.net ALLOCATED

Как-то так. Все-таки они кончаются :)

Дошли руки в очередной раз дома настроить синхронизацию музыки с 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 что-нибудь вроде результата выполнения

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. Без него не пробовал, с ним - работает)

Не поднимайте роут-рефлекторов в пятницу, это чревато испорченным понедельником

В копилку плюшек IPv6:

У bind'а есть не слишком удобная, обусловленная суровой необходимостью фича - вместо *:53 биндиться на все алиасы всех интерфейсов, что порождает массу нюансов с очередностью запуска, туннелями и прочим. В IPv6 ситуация проще: в системах, которые поддерживают RFC 3542 и RFC 3494 bind'у достаточно забиндить один сокет, после чего при отсылке UDP-пакета можно указать source-адрес, с которого он отправляется. Судя по ipv6int.net во фре данная функциональность появилась еще во времена 5.2. Удобно!

В продолжении эпопеи о переходе на IPv6:
( Читать... )

nss_ldap (равно как и pam_ldap) - хорошо. Функции свои они выполняют. Хочется же однако не хорошо, а как можно лучше, чего с ними не получается.
Собственно, вариации на тему "почему плохо" и "как лучше" - ( Далее... )

Оказывается, поддержка есть много где
т.е. из популярных 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.