где-то эту доку находил полтора года назад. По ней настроил свой определитель. Но прикол в том, что моя АТС дает именно АОН и для получения callerid нашел в инете платку, которая осуществляла преобразование. Жизнь показала что такая связка глючная — разрывы соединения в произвольный момент времени. Пришлось убрать и вчера отключил АОН в РТК. Такая у нас провинция.
Все же мне кажется что данное решение теряет свою актуальность, т.к. гораздо более верным будет использование новых конфигураций на управляемых формах через тонкий или веб-клиент. Хотя бы даже потому, что указанные в статье бух 2.0 и зуп 2.5 поддерживаются последний год.
Спасибо. Поправил, заказывал действительно на 10 лет. На счет первоначального срока — во первых не ожидал что вообще эта инфраструктура столько проживет, во вторых пользовался типовым скриптом build-ca.
каждой зоне соответствуют свои учетные данные, которые прописаны в /usr/local/www/ddns/.htpasswd
т.е.
клиентА парольА
клиентБ парольБ
затем клиентА авторизовавшись — обновляет зону КлиентА.домен.ру, это заложено в скрипте, если он знает учетные данные КлиентаБ, он сможет обновить зону клиентаБ, если он знает пин-код от моей карты, он сможет забрать мои деньги )
1. обновлять конечно надо, вот 11 стабильный выйдет — перееду на 10 ку :)
3. спасибо, забегался с корректировками…
5. понял, про единый ключ размышлял, надо конечно переделать на отдельный ключ для моего сервиса, так конечно будет правильней
6. я не сказал бы что это слабость, все же ориентация скрипта именно такая — что каждому пользователю — один поддомен. Пусть это будет его силой :)
1. В статье указано что сабж раворачивается на freebsd 9/3
2. Файервол трогается в принципе чтобы dns-сервер не остался в вакууме и был виден миру, собственно зачем он иначе. Про tcp/udp не указываю, обычно это значит что надо указывать ip в целом.
3. дополнил статью
4. вместо allow-update используется update-policy — в статье указано, вполне себе работает.
5. поясните пожалуйста этот момент.
6. ну это один из вариантов, он изначально вырастал из скрипта, php появился позже. Farcaller выше уже упоминал лишние сущности. Можно конечно поспорить о том что модуль php тоже по своему костыль. Здесь хорошо бы напрямую через exec вызывать nsupdate, но пока крутится и так.
Так весь код в статье. Сам php-скрипт никоим образом не трогает файлы зон, он лишь использует интерфейс взаимодействую через rndc, я полагаю что ребята-разработчики bind'а должны были позаботиться здесь о блокировках при одновременном доступе к зоне.
Время жизни записи выставлено в 120 с. Теоретически должно обновиться в две минуты, но часто вызывает проблему именно кэш самого dns-клиента на той же windows-машине. DynDNS с этим решили хитро, при установке своего клиента предлагают также использовать свои dns якобы для ускорения. Т.е. если с такой машины выйти в инет, клиент быстро обновится и благодаря прописанным родным dns-серверам мы тоже очень быстро обманемся. Вообще конечно по статистике пока еще рано что-то писать.
понятно что я не рассматривал это в контексте отказоустойчивого кластера — это обычный виртуальный сервер на 30 клиентов. Ясно что если он упадет, будет заминка у клиентов, у меня отвалится еще пара сервисов. Хотя опять же забота хостера держать мой сервер по питанию и доступу в мир. Ни в коей мере это ведь не конкуренция dyndns, но в узких кругах моей мамы — мой сервис одержал победу ;)
К сожалению совсем без sudo не получается. Не хочет у меня php из под www стартовать bash-скрипт, пришлось извернуться через обычного пользователя, о чем я поправил статью.
Не буду спорить на сколько он нормальный и качественный, не пользовал к сожалению. Свое решение позиционирую в первую очередь как решение для своей площадки. Интересно может быть тем, у кого свой dns-сервер. Кто-то может быть пользует свои почтовые сервера, кому-то может быть не нравится dropbox и он разворачивает owncloud. Считаю что всякое имеет право быть — если оно справляется со своей задачей.
т.е.
клиентА парольА
клиентБ парольБ
затем клиентА авторизовавшись — обновляет зону КлиентА.домен.ру, это заложено в скрипте, если он знает учетные данные КлиентаБ, он сможет обновить зону клиентаБ, если он знает пин-код от моей карты, он сможет забрать мои деньги )
3. спасибо, забегался с корректировками…
5. понял, про единый ключ размышлял, надо конечно переделать на отдельный ключ для моего сервиса, так конечно будет правильней
6. я не сказал бы что это слабость, все же ориентация скрипта именно такая — что каждому пользователю — один поддомен. Пусть это будет его силой :)
2. Файервол трогается в принципе чтобы dns-сервер не остался в вакууме и был виден миру, собственно зачем он иначе. Про tcp/udp не указываю, обычно это значит что надо указывать ip в целом.
3. дополнил статью
4. вместо allow-update используется update-policy — в статье указано, вполне себе работает.
5. поясните пожалуйста этот момент.
6. ну это один из вариантов, он изначально вырастал из скрипта, php появился позже. Farcaller выше уже упоминал лишние сущности. Можно конечно поспорить о том что модуль php тоже по своему костыль. Здесь хорошо бы напрямую через exec вызывать nsupdate, но пока крутится и так.
понятно что я не рассматривал это в контексте отказоустойчивого кластера — это обычный виртуальный сервер на 30 клиентов. Ясно что если он упадет, будет заминка у клиентов, у меня отвалится еще пара сервисов. Хотя опять же забота хостера держать мой сервер по питанию и доступу в мир. Ни в коей мере это ведь не конкуренция dyndns, но в узких кругах моей мамы — мой сервис одержал победу ;)