Итак техническая часть проекта MT9000, заключительная. Если вы не читали первую и вторую части, рекомендую ознакомиться. Что же, приступим!

Как мама учит мыть руки перед едой, так и планирование – обязательная стадия разработки любого проекта. Иначе проект может перерасти в процесс, а мне это совершенно не нужно. Без плана и определения методики разработки не делаю ничего!

Для разработки проекта в целом использован старый добрый классический инкрементный подход: тщательное планирование, проектирование, несколько этапов тестирования прототипов, релиз. Нужно заранее спланировать все критические даты и важные точки проекта. Тогда есть шанс сдать проект с минимальной задержкой.

UPD: Запущен сайт http://switchvox.ru.

О Switchvox на Хабре не написано ничего.  Или, если быть абсолютно точным, почти ничего. В 2007 году хаброжитель alizar опубликовал перевод "25 самых интересных стартапов VoIP", в которой упомянулся и Switchvox.  И в 2011 году,  две недели назад, я вскользь упомянул о Switchvox в своей статье «Обзор открытых IP АТС».  И все :-)

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

• INTERNET TELEPHONY Magazine's «Product of the Year» Award for 2005
• INTERNET TELEPHONY Magazine's 2006 Product of the Year Award
• TMC Unified Communications Product of the Year Award Switchvox SMB 3.0 — 2007
• Communications Solutions Product of the Year Switchvox SMB 3.0 — 2007
• CRN Tech Innovators Award Switchvox SMB 3.0 — 2008
• Internet Telephony West Best in Show, Best of Open Source Switchvox SMB 3.5 — 2008
• Internet Telephony Magazine Excellence Award Switchvox SMB 3.5 — 2008
• IT Expo East 2009 Best of Show, Most Innovative Product Switchvox 4.0 — 2009
• … и так далее каждый год до сегодняшнего дня (смотрите полный список наград). Буквально на прошлой неделе SwitchVox получил премию за расширенные унифицированные коммуникации -  North American SMB Unified Communications Customer Value Enhancement (источник)

Что же такое Switchvox и откуда и когда он такой взялся?  Эту историю я расскажу под лучший микс этого лета от Aurosonic (наши ребята!)… за хабркатом.

Кто не читал первую часть, ее можно найти вот здесь, а я пока публикую вторую часть, которая содержит больше технических деталей, чем первая. На очереди еще и третья, заключительная часть, она пока готовится, настолько насыщенная деталями, фотографиями прототипов и технической информацией, насколько это возможно. Надеюсь, что хабражителям вторая часть понравится не меньше, чем первая. Приступим?

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

На рынке к тому моменту (2006-2007г) уже существовали системы предотвращения протечек воды. Однако эти системы не делали самого главного – они не сообщали хозяину о произошедшей «неприятности». То есть локализовать утечку в своей квартире такие системы могут, но “выйти за рамки”, и сообщить о том, что заливают квартиру соседи сверху, такая система попросту была неспособна. Что уж говорить о других проблемах, вроде возгорания, или проникновения в квартиру постороннего лица, или о других неприятных возможностях.

Так родилась идея сделать информационное устройство, своеобразного “охранника”, который будет сообщать владельцу на телефон о каких-то событиях, происходящих в его отсутствие в квартире.

В .bashrc можно описывать функции.

К чему это я? Если вам не хватает alias, не обязательно писать однострочный скрипт.

Введение | Tor | Tarzan и MorphMix | Малозатратная атака | Малозатратная атака на Tarzan и Morphmix | Принципы построения безопасных систем (заключение)

Для успешной малозатратной атаки должны выполнятся два основных условия. Первое, вредоносный узел должен знать все другие узлы сети. Без этого рассматриваемая атака невозможна. Второе, возникающие задержки должны характеризовать объем передаваемого узлом трафика.

Исходя из результатов исследования, мы сделали следующие выводы.

Продолжаем серию полезных советов. В информации, которая приведена ниже, нет ничего нового и сенсационного, но буду раз, если кому-то пост окажется полезным.

Телефон и e-mail, указанные в аттестате, нужны не всегда, но иногда без них никак: например, при получении кода активации и кода разблокировки IP, подтверждения транзакций по SMS…
Как изменить данные, указанные в аттестате?

Работая у крупнейшего провайдера РФ столкнулся с ситуацией, что происходит обращение абонента о проблемах в недалеком прошлом, т.е. вчера все было плохо, а сейчас заработало. Что делать в этом случае? Есть варианты использовать системы мониторинга, которые будут собирать ключевые параметры всех абонентских линий и хранить их некоторое время, и оператор ТП легко сможет получить доступ к этим данным для решения подобных ситуаций. Также, имея эти данные, можно давать автоматическую экспертную оценку по каждой абонентской линии, и при желании, на xDSL, автоматически подбирать наиболее подходящий профиль. Используя эти же данные, можно выявлять дефектные линии или линии с неудовлетворительными параметрами и устранять возможные проблемы абонентов еще до их обращения в ТП.
С первого взгляда задача не сложная, но когда количество оборудование легко перешагивает тысячи узлов доступа, а количество абонентских портов может исчисляться десятками тысяч появляются некоторые особенности настройки и запуска подобной системы, с максимальной автоматизацией всего.
Если интересно, добро пожаловать под кат

Вступление

Продолжу цикл статей на тему «Apache 2.x под наблюдением. Мониторинг загрузки системы веб-сервером». Опять же под рассмотрением остается известный ранее[2] модуль Apache — mod_performance. На время написания этой статьи на сайте модуля[1] была выложена для доступа новая версия модуля — 0.2. Дальнейшее повествование в статье будет по принципу «Вопрос-Ответ».

В процессе создания своей радиостанции поток идей дошел до ведения эфиров через веб-интерфейс. Сначала пытался найти готовые решения, но в рунете почти ничего не нашел. Начал продумывать способ реализации и чудом наткнулся на статью в английской версии Википедии про Airtime (до 18 января 2011 г. – Campcaster) от Sourcefabric.

Возможности Airtime:

• Создание эфирной сетки и плейлистов через веб-интерфейс ;
• Загрузка музыки через браузер (поддержка drag and drop);
• Регистрация ведущих, которые имеют доступ к админке и могут управлять эфирами;
• Создание виджетов с расписанием эфиров и треков для сторонних сайтов;
• Возможность записывать эфиры для повторной трансляции;
• Несколько вариантов трансляции аудиопотока.

Минимальные системные требования, описанные в официальной инструкции: 1Ghz процессор и 512Mb оперативной памяти.

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

Интересно? Добро пожаловать под кат.

Данное руководство ориентировано на виртуальные серверы (VDS/VPS), доступ к которым осуществляется по VNC через интернет. Это задает основные приоритеты — экономное использования ресурсов сервера и работа по недостаточно быстрому каналу. В качестве базовой системы, на которую выполняется установка, используется минимальная инсталляция Ubuntu 9.10. С небольшими изменениями это руководство применимо к другим дистрибутивам Linux и операционным системам семейства Unix, а также для настройки VNC на обычных выделенных серверах и на серверах в локальной сети.

* Способы организации работы VNC-серверов
** Встроенный VNC-сервер в эмуляторах аппаратного обеспечение (Xen/HVM, VMWare, Qemu)
** VNC-сервер, привязанный к работающему X-серверу (GNOME vino)
** VNC-сервер с встроенным X-сервером
*** VNC-сервер, запускаемый вручную
*** VNC-сервер, запускаемый в режиме демона
*** VNC-сервер, запускаемый через inetd
* Выбор VNC-сервера
* Тюнинг сервера
** Тюнинг десктопа
** Опции VNC-сервера

Отладочная демоборда, установленная в WishBoard

Помню счастливые студенческие годы, когда было море свободного времени. Золотые времена, когда на скучной паре можно было писать программу или читать полезную книгу. Или сидеть с паяльником или в глубокой отладке сутки на пролёт, без сна.
Эти прекрасные времена безумного творчества закончились тогда, когда я получил диплом и устроился на работу на полный рабочий день. Тогда закончился славный фриланс и начались суровые будни. У меня возникло стойкое ощущение, что у меня кто-то украл из жизни 11 часов ( два часа дороги, час обед и 8 часов работы). Самое печальное было в том, что на работе я выматывался на столько, что ни о каких ночных бдениях даже мыслить не приходилось: пришёл, поужинал и лёг спать, иначе завтра овощ. В конце, концов, такое положение вещей меня перестало устраивать, и я начал думать, что же делать.
В своём хобби – занятиях электроникой, я в основном делаю устройства на микроконтроллерах. Сборка отладочной схемы, как правило, идёт достаточно быстро, львиную долю времени занимает написание и отладка программы для контроллера. А на работе у меня присутствует такой ресурс как время (например обед) и быстрый Интернет. По сему родилась гениальная по своей простоте идея удалённой отладки, и не только программ, но и железа.

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

Первая часть тут.

Судя по тому, насколько популярен блог DIY, многие из нас любят изобретать. Наверное, каждый встречал человека, который способен сутками что-нибудь паять, программировать, отлаживать, не замечая ничего вокруг. Вот совсем свежие примеры.

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

Речь пойдет про устройства NetPing. Эта российская разработка периодически упоминается на хабре, но детального рассказа я не встречал. Пусть эта статья будет продолжением серии «Оборудование российского производства». Мне достался самый универсальный прибор линейки – UniPing RS-232. Основная сфера его применения – удаленный мониторинг и управление множеством устройств в квартире, доме, офисе. Конечно, давно существует понятие «умный дом», но, как правило, это преподносится как вариант для состоятельных людей, хотя получают они черный ящик с жестко заданным, пусть и большим, набором функций. Однако, можно ведь все собрать и запрограммировать самому!

Классическая схема инициализации System V, на которой базировались дистрибутивы RedHat Enterprise Linux до шестой версии, была привычной и довольно простой для понимания: init описывал весь процесс загрузки в своем конфигурационном файле "/etc/inittab", откуда вызывались другие программы и скрипты на определенном этапе запуска.
В RHEL 6 ситуация поменялась: на смену System V пришел Upstart, что несколько изменило процедуру конфигурации процесса загрузки операционной системы. Upstart, который изначально разрабатывался для Ubuntu, довольно неплохо вписался и в RedHat системы, заменив собой только часть привычной схемы запуска.
Тем не менее, изменения существенные и мало документированные, поэтому в этой статье я постараюсь внести ясность в новую схему загрузки, и что она привнесла.

Доброго времени суток, уважаемые хабровчане!

На хабре много статей, про то настройку тех или иных кусочков домашнего сервера. Хотелось бы поделиться еще одним вариантом построения домашней сети, нацеленной на сисадмина или разработчика. На этот раз на базе ESXi.

Кого заинтересовало — добро пожаловать под кат.

Совсем недавно понадобилось настроить очередной веб-сервер. Как раз в это время у меня было весеннее обострение PowerShell. В общем, в качестве небольшой разминки, я решил настроить веб-сервер без RDP.

После запуска в Скалакси новой системы хранения, мы выполнили миграцию на нее всех пользовательских данных со старой системы и решили сравнить скорость новой системы с существующими решениями на рынке. Под катом тест производительности систем хранения следующих облачных провайдеров: Amazon, Rackspace, Terremark, Скалакси, Селектел, Clodo.

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

Ну а теперь подробнее.

Недавно побывал на конференции на тему “Построение беспроводных сетей”. Не смотря на то, что довольно длительный период работаю администратором, мне не каждый день приходится разворачивать беспроводные сети. Спешу с вами поделиться некоторыми нюансами. Всех заинтересованных приглашаю под кат.