Интересные вещи иногда выпускает Google. Из свеженького — терминальный сервер NeatX, с открытыми исходниками под GPL.

Как известно, протокол NX создан компанией NoMachine для эффективной работы с классической системой X Windows. Этой системе свойственны большие задержки при передаче информации и неоптимальный расход полосы пропускания. Протокол NoMachine отлично решает проблему, эта тема уже обсуждалась на Хабре.

С 2004 года существует открытый и бесплатный сервер FreeNX, но он написан на адской смеси Bash, Expect и C. Компания Google рассудила, что в таком виде его тяжело будет развивать и улучшать, и решила переписать сервер. Так и появился NeatX.

NeatX написан на Питоне, с небольшими вкраплениями скриптов на Bash и единственной программкой, которая написана на C в целях производительности.

Программисты Google говорят, что в их реализации NX-сервера есть даже новый функционал, которого не было у FreeNX, но при этом не весь функционал FreeNX они решили перенять. Поучаствовать в разработке можно через гугловский список рассылки.

QoS — тема большая. Прежде чем рассказывать про тонкости настроек и различные подходы в применении правил обработки трафика, имеет смысл напомнить, что такое вообще QoS.

Quality of Service (QoS) — технология предоставления различным классам трафика различных приоритетов в обслуживании.

Во-первых, легко понять, что любая приоритезация имеет смысл только в том случае, когда возникает очередь на обслуживание. Именно там, в очереди, можно «проскользнуть» первым, используя своё право.
Очередь же образуется там, где узко (обычно такие места называются «бутылочным горлышком», bottle-neck). Типичное «горлышко» — выход в Интернет офиса, где компьютеры, подключенные к сети как минимум на скорости 100 Мбит/сек, все используют канал к провайдеру, который редко превышает 100 МБит/сек, а часто составляет мизерные 1-2-10МБит/сек. На всех.

Во-вторых, QoS не панацея: если «горлышко» уж слишком узкое, то часто переполняется физический буфер интерфейса, куда помещаются все пакеты, собирающиеся выйти через этот интерфейс. И тогда новопришедшие пакеты будут уничтожены, даже если они сверхнужные. Поэтому, если очередь на интерфейсе в среднем превышает 20% от максимального своего размера (на маршрутизаторах cisco максимальный размер очереди составляет как правило 128-256 пакетов), есть повод крепко задуматься над дизайном своей сети, проложить дополнительные маршруты или расширить полосу до провайдера.

Разберемся с составными элементами технологии

(дальше под катом, много)

Во время перекомпиляции или рестарта ASP.NET-приложения я регулярно наблюдал картину, когда процесс firefox использовал процессор не меньше, а то и больше, чем aspnet_wp. С какой, спрашивается, радости он это делает, если он просто ждет ответа от сервера? На что тратится ресурс процессора?

Ответ на этот вопрос был заметен, оказывается, невооруженным взглядом, но он настолько дурацкий, что подумать его было сложно. Процессор кушает… анимация (APNG) крутящегося индикатора загрузки! Достаточно заменить его статическим png (или анимированным gif), чтобы проблема ушла.

Злополучный файл называется loading_16.png. Я нашел его здесь: Mozilla Firefox\chrome\classic.jar\skin\classic\global\icons\, — и заменил на статическую картинку. Также он лежит в skin\classic\aero\global\icons\loading_16.png, но это, видимо, для Висты, а у меня XP. Там я его оставил.

Ура, теперь не надо обдумывать переход на другой браузер! :) Надеюсь, в 3.5 это все-таки исправят, как-то неохота повторять операцию после апдейта.

Другой вариант решения — скопировать вот это в userChrome.css (не пробовал, это информация с баг-трекера Мозиллы).

Ссылки с подробностями:
https://bugzilla.mozilla.org/show_bug.cgi?id=437829
forum.mozilla-russia.org/viewtopic.php?pid=315838#p315838

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Всем привет!
Около месяца назад я придумал антиспам-сервис (см. этот топик). Напомню, он посвящен сообщениям типа «отправь СМС». Суть — нужно указать, что просят отправить и куда, при большом количестве сообщений спамер не получит денег, так как выплаты происходят с задержкой.

Предположим у вас есть домашняя сеть (или не домашняя, а сеть небольшого офиса) с выходом в интернет через не очень скоростной канал. А пользователей — много, и каждый хочет что-то скачивать, да с максимальной скоростью. Вот тут перед нами встатет задача, как максимально эффективно распределить наш интернет-канал между пользователями так, чтобы они не мешали друг другу. В этой статье я опишу, как можно решить такую задачу с помощью Linux-сервера.

Сформулируем, что же мы хотим получить в результате:
1. Чтобы канал поровну делился между пользователями.
2. Чтобы канал зря не простаивал.
3. Чтобы онлайн-игры, ssh и telnet не «лагали» даже при полной загрузке канала, например торрентами.

Увидев на хабре топик про то, что веб-форма писем Президенту работает, тоже решил воспользоваться этой замечательной возможностью и получить официальные разъяснения по-поводу использования свободного программного обеспечения. В частности, меня интересовала законность установки операционной системы Linux во благо моего небольшого IT бизнеса.

24 февраля зашел на сайт президента Российской Федерации и отправил вопрос (текст, к сожалению, не сохранил).
26 марта получил правительственное письмо о том, что мое обращение передано в Министерство экономического развития.

И наконец сегодня, рядом с пухленьким конвертом со свежим CD Ubuntu, обнаружил в почтовом ящике

Не так давно столкнулся с проблемой (и ее решением) учитывая актуальность этой темы в последнее время, а также то, сколько людей сейчас страдают от этой беды, решил объединить информацию в одну статью. Может быть кому-то еще она будет полезной.

Начало

Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:

10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

Стал у бедного админа виснуть роутер от D-Link, модель DIR-400.
И стал админ искать пути решения проблемы.
Погуглив полчаса наткнулся на прошивку от dd-wrt.com.
Поглядел на её возможности, обрадовался, и стал искать мануалов — как же всё таки эту прошивку залить (ибо стандартный прошивальщик, ребятами из D-Link писаный, не годится).

Нашёл мануал по заливке прошивки через DBG-console. Но вот беда — мануал на виндовых юзеров рассчитан, а винды под рукой нету, только Линукс праведный…
Ну, да ладно. Разобрался админ. Детали — под катом.

Судя по количеству плюсов к посту про использование google apps в качестве сервера jabber эта тема волнует хабрапользователей. Поэтому я решил внести свои пять копеек.

В документации гугла сказано, что при настройке кастомного клиента нужно вводить в свойствах соединения сервер talk.google.com и порт. Это очень не удобно, так как надо всё время помнить эти настройки, да и затрудняет настройку клиента вашими родственниками/знакомыми, которых пугает только одно слово порт :) Почему-то в документации к google apps этого не сказано, но прописать адрес и порт, которые должны быть использовать при подключении, можно в srv записях dns, да именно там, где вы указаывали адреса для федеративных сетей.

Добавляем запись типа:

_xmpp-client._tcp.yourdomain.com. IN SRV 5 0 5222 talk.google.com.

И вауля, клиент коннектится безо всяких танцев и дополнительных настроек.

Эта статья, логическое продолжение этой и этой статей.
В третьей части цикла статей об атаках на беспроводные сети будут рассмотрены атаки на протокол, до последнего времени считавшийся достаточно безопасным — WPA.

Это продолжение предыдущей статьи, об атаках на беспроводные точки доступа с WEP-защитой.

Во второй части цикла статей о безопасности беспроводных сетей мы рассмотрим некоторые нетрадиционные атаки на WEP.

В прошлой статье о беспроводных сетях мы рассмотрели первый этап — сбор информации, или wardriving. Сейчас же, продемонстрируем несколько способов получения несанкционированного доступа к беспроводным сетям, а также рекомендации по защите от них.

Я достаточно давно и без сожалений расстался с ICQ. Воспользовавшись возможностью, поднял свой собственный Jabber-сервер, которым с успехом и пользуюсь по сей день. Однако не у всех моих сотрудников есть Jabber-аккаунт (не все даже знают, что это такое :-), что несколько затрудняет общение по работе. Для общения с остальными, для организации безопасной и независимой системы обмена сообщениями, я решил поднять корпоративный jabber-сервер. А так как у нас активно используется LDAP, то логичным показалось задействовать его для аутентификации пользователей и управления учётными записями.