Рабочие будни

Думаю в жизни каждого человека наступает такой день. День когда начинаешь осознавать что надо что то менять. Менять в себе. Надо становиться более добрым. Гнать этот негатив поганой метлой. С этого момента, я не буду писать негатива. Это моё решение. Историю делают люди. Я не буду больше пачкать и так не чистые листы истории.

Спасибо Евгению Бабину за реализацию.

С помощью того же TreeWalk DNS о котором я писал можно легко открыть доступ к живому журналу.   Те кто уже работает с  TreeWalk DNS могут дописать несколько строк в конфигурацию и свободно пользоваться ЖЖ.

Ну что, начнём?

Все действия  будем производить в папке C:\WINDOWS\system32\dns\etc

Файлы JJ.conf и jjtoys.conf можете скачать в конце поста и выложить в указанную папку.

В файл named.conf в самом низу допишем:

zone «livejournal.com» {
type master;
file «jj.conf»;
};

zone «lj-toys.com» {
type master;
file «jjtoys.conf»;
};
Идём в службы и перезапускаем TWDNS

Всё готово. Не правда ли просто?

Файлы jj.conf и jjtoys.conf берём тут jj.zip (345)jjtoys.zip (283)

Обнаружил в сети — онлайн js деобфускатор. Ему можно скормить неразборчивый javascript код (например модуль адсенса) и на выходе получить отформатированный вариант. http://code.gosu.pl/dl/JsDecoder/demo/JsDecoder.html
Очень даже неплохо получается.

Чуть ли не каждый день запускаются Казахстанские стартапы. Какие только усилия не прилагаются для удержания трафика в кольце Казахтелекома, что бы снизить нагрузку на внешние каналы. А ведь никто и не подумал о поднятии windows update service (WSUS) на Казахтелекомовской площадке. Это же не сложно, сервис разок стянул бы все обновления, а ваши покорные клиенты уже с него бы забирали. Думаю, что большая часть клиентов работает на Windows, и экономия трафика была бы существенная.

А может Казахтелеком просто боится выставить в общий доступ систему Windows Server или у него нет денег для легализации её? Насчёт последнего сомневаюсь, думаю можно купить под это дело легальную ОС. Тогда, что мешает сделать?

Чуть ли не каждый 3-й приход с поисковиков на мой блог с запросом «DNS казахтелеком». Проблемы с DNS серверами у мегалайна реально существуют. Часть проблем из-за того, что сам DNS глючит, часть из-за внешних модемов, которые пытаются переслать запрос на DNS сервер мегалайна и не дожидаясь от него ответа выдают Non-existent domain.
Дабы поставить точку в этом деле и прекратить мучения, рекомендую поднять DNS сервер у себя на компьютере и забыть про эти проблемы.
Советы будут для пользователей Windows, для unix like систем можно поставить любой доступный сервер, благо их там немало.
Стандартный Windows DNS сервер поставляется только в комплекте с серверными версиями ОС. Нам же не имеет смысла ставить серверную ОС ради такого функционала. Бегло погуглив был найден бесплатный TreeWalk DNS. Взять его можно тут http://ntcanuck.com/downloads.htm
Как пишет автор, вы нуждаетесь в TreeWalk DNS если:

• Ваши DNS-сервера тупят или не работают
• Хотите правильное разрешение (резольвинг) веб-сайтов
• Хотите посмотреть или отладить DNS маршрутизацию
• Хотите выборочно сконфигурировать DNS настройки и сервера
• Хотите быстрее повторить посещение сайта через кэш
• И т.д.

Х.м. прям какой то рекламный пост вышел, в общем системные требования на сайте автора.
Всё что от вас требуется это скачать, установить и перезагрузить компьютер. Те, кто не желает перегружаться может запустить сервис twdns руками. DNS адрес на сетевых картах он меняет на себя автоматически.
Больше вы не зависите от провайдерских DNS серверов, данный сервер обращается напрямую к корневым серверам DNS и находит нужные вам адреса. Единственный недостаток это чуть большее количество трафика при определении адресов, но это ни что по сравнению с тем когда оно вообще не работает.

UPD Hoster.kz советует попробовать следующие DNS сервера:
Зарубежные: ns-kz.ripe.net,auth00.ns.uu.net
Российские: ns.ru.net — 193.124.22.65, ns.spb.su — 193.124.83.69
Казахстанские: ns.nursat.net, ns.nic.kz, ns.ricc.kz

При создании любого сайта перед разработчиком всегда встаёт вопрос, брать готовую CMS или написать своё. Даже если вы являетесь сильным программистом и вам брезгливо использовать готовое, аргументируя это тем, что там полно дыр и прочего ненужного кода, я с вами не соглашусь. Зачем изобретать то, что уже изобрели? Зачем тратить силы и время на то, что можно выполнить гораздо быстрее? Зачем привязывать заказчика для последующей поддержки именно к вам, потому что в вашем коде новому исполнителю не захочется разбираться. Он в итоге снесёт всё подчистую и натянет оформление на готовую CMS. А за что тогда мы платили в прошлый раз?

Что (как минимум) получит заказчик при реализации его проекта нестандартными методами:

1. Относительно долгие сроки создания

• Привязка к конкретному исполнителю, что выльется в итоге в копеечку
• Дороговизна проекта будет зависеть от поставленного функционала (бэкапы, импорт/экспорт и т.д.)
• Проблемы с переносом на другой хостинг, потому что неизвестно какие требования у данной поделки
• Через полгода вы будете с завистью смотреть на сайты конкурентов и завидовать их функционалу
• Уже через год вы поймёте, что без дополнительного вливания огромного бабла, вам никто не будет править код и латать дыры, из-за того что исполнитель уже забыл что он там делал или неизвестно куда свалил
• Каким бы гением не был исполнитель, он всё равно допустит ошибки. Потому как на тестирование особо времени нет, да и надо ли оно ему?

Список можно продолжать бесконечно. Лично для себя я выбор сделал. Проще и быстрее разобраться в функционале WordPress или Drupal и дописать то чего не хватает заказчику. Проблем с обновлениями нет. Заказчику же не придётся платить за разработку того, что уже работает. Найти нового неприхотливого исполнителя для дальнейшей поддержки тоже труда не составит.

Хочу сказать, что это не относится к крупным компаниям у которых есть свой уже оплаченный ИТ отдел. Силами отдела возможно написание именно того функционала, который требуется. Но опять же при постоянной ротации кадров, а это происходит в любой команде, сложно будет производить поддержку и разбираться в том, что написано до тебя.

А теперь правда о том, почему ЖЖ не работает в Казахстане.
Берём для примера 2 адреса img.livejournal.com и eblaput.livejournal.com
Проверяем пингом:

Обмен пакетами с img.livejournal.com [208.93.0.129] по 32 байт:
Ответ от 208.93.0.129: число байт=32 время=390мс TTL=236

Обмен пакетами с tema.livejournal.com [208.93.0.128] по 32 байт:
Превышен интервал ожидания для запроса.

Занятно, адреса рядом, а ведут себя по разному. Под бан попадает всего один адрес, на котором и находятся все дневники пользователей.
Делаем трассировку маршрута до обоих и сравниваем (некоторые промежуточные хопы упустим, что бы не гадить в посте):
Трассировка маршрута к tema.livejournal.com [208.93.0.128]
11 181 ms 80.77.96.98
15 325 ms 67.14.24.21
25 343 ms 65.121.112.210
26 * Превышен интервал ожидания для запроса.
27 * Превышен интервал ожидания для запроса.
28 * Превышен интервал ожидания для запроса.

Трассировка маршрута к img.livejournal.com [208.93.0.129]
11 181 ms 80.77.96.98
15 326 ms 67.14.24.21
18 353 ms 65.121.112.210
19 354 ms 208.93.0.129

Вот оно как оказывается. Пакеты проходят по всему пути и банятся на последнем адресе. Странно да? Причём тут Казахстан, если пакеты теряются далеко за пределами РК? А вот сейчас и поясню, как можно сделать из простого бана, такой хитрый рисунок.
Для этого достаточно банить пакеты с сервера ЖЖ (пакеты с адресом отправителя 208.93.0.128). Если бы в РК банили исходящий трафик (запросы от клиента до ЖЖ), то пакет не ушел бы дальше головного роутера КТ. А так получается что при трассировке пакет уходит наружу с TTL равным 1. Доходит до первого узла и возвращается к нам же но не с адресом ЖЖ, а адресом узла до которого хватило TTL. Далее TTL прибавляется на 1 и продолжается до тех пор пока не достигнет конечного адреса. Т.е. весь маршрут пакета нам виден, но как только пакет достигает адреса ЖЖ то при возврате тупо банится на головном роутере Казахтелекома.
Всё просто как оказалось и в тоже время кто бы мог подумать :)