Одной из важных технологий любой серьезной системы мониторинга сетей является метод обнаружения связей сетевых элементов на 2-м и 3-м уровне модели OSI.



С точки зрения алгоритмов эта задача является одной из самых интересных встреченных нами во время разработки нашей системы.

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

Относительно недавно я опубликовал небольшую статью «Курс молодого бойца. Практический курс по Cisco Packet Tracer». Там я рассказал об опыте создания обучающего курса для внутренних нужд организации. Основная цель курса — быстрая подготовка специалиста к «полевым работам». Уроки параллельно публиковались на YouTube в свободном доступе. Сам проект получил название NetSkills. После публикации на канал YouTube добавилось больше 2-х тысяч подписчиков. Я получил отличный фидбэк (такой, что еле справился) и стимул довести дело до конца.



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

Привет, Хабр!

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

И о том, как порой тяжело найти что-то одновременно простое, функциональное и надежное?
Когда первый раз настраиваешь динамическую маршрутизацию, тебе кажется, что ты близок к правде и пониманию того, как устроены сети. Но стоит новичку взглянуть на рабочий конфиг серьезной операторской сети, как становится понятно, что мир не заканчивается командой «network».

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

Но не все так страшно! Уделите внимание литературе, спросите про шишки более мудрых камрадов, и дзен станет ближе.

Вашему вниманию я предлагаю последний выпуск про IS-IS!

В этом выпуске:

• Ешь, пей в аду. Пиши сценарий к IS-IS.
• Почему OSPF сильнее Супермена?
• Что будет в OSPFv4?*
• Overload bit и iSPF — сложнее объяснить, чем сделать.
• BFD. Молниеносный убийца вашего CPU.
• Почему Горден Фримен радуется, когда вы настраиваете dampening?
• Алгоритм экспоненциального откладывания или история про жадного ребенка.
• Сходимость и циферки!
• Как несчастный IGP ждал LDP. Жалко я не вспомнил Хатико.

*понятия не имею, но расскажу.



Под катом нет текстовой статьи. Только ссылки на литературу и источники. Также вы можете проголосовать за тему следующего выпуска или выбрать её самостоятельно.

Как вы можете знать, некоторые производители роутеров включают в свою продукцию возможность использовать подключенные в роутер USB-устройства через TCP/IP, используя ПО KCodes NetUSB и свой собственный протокол. Технология позволяет подключать любые типы устройств: принтеры, флешки, веб-камеры, клавиатуры, звуковые карты, т.к. просто инкапсулирует USB в IP.

Специалисты из SEC Consult обнаружили вопиющую уязвимость на всех роутерах, поддерживающих данную технологию — переполнение буфера на стеке в режиме ядра, которое может привести к удаленному выполнению кода.

Модуль ядра NetUSB.ko, который прослушивает порт 20005, даже если в роутер не подключено ни одного USB-устройства, для аутентификации использует шифрование AES со статическим ключом (который, конечно же, есть и в ПК-клиенте), что уже позволяет злоумышленнику удаленно воспользоваться подключенным USB-устройством. Однако, главная уязвимость заключается в фиксированном размере буфера для имени компьютера в функции run_init_sbus(), принимающего не более 64 символов. Переполнение этого буфера и приводит к переполнению стека в ядре

Ныне FreePBX — крайне популярная обертка к Asterisk, который не менее популярен как телефонный цифровой сервер. Отдельный плюс таких систем — возможность развернуть на недорогих vds-серверах (я клиентам разворачиваю на vds стоимостью 299р/месяц, 2Гб ОЗУ, 2,8 GHZ процессор, 20Гб место на диске). Такая система запросто обслуживает 10-20 одновременных звонков, пишет аудио, позволяет внедрять телефонную часть бизнес-процесса в остальную логику (взаимодействие с crm, звонки с сайта/браузера, автоинформаторы на основе данных в субд, выяснение поисковых данных по номеру о звонящем за доли секунд, даже распознавание и синтезация речи!).

Все бы хорошо, но при «обильных» обзвонах через полмесяца заканчивается место на диске. Те самые 20Гб улетают у некоторых клиентов за неделю! А хостер, к сожалению, не предоставляет fuse на тарифах OpenVZ, который крайне необходим для работы «реалтайм — сетевых файловых систем», вроде ftpfs.

Ниже изложу мой комплекс мер по борьбе с проблемой. Работать будем с каталогом /var/spool/asterisk/monitor, где лежат .wav файлы, заботливо разложенные asterisk по каталогам: год, месяц и день.

64-битные ошибки достаточно тяжело обнаружить, так как они сродни бомбе замедленного действия: могут дать о себе знать далеко не сразу. Статический анализатор PVS-Studio облегчает задачу поиска и исправления подобных ошибок. Однако в этом направлении были сделаны ещё несколько шагов: недавно были более внимательно пересмотрены 64-битные диагностики, вследствие чего их распределение по уровням важности изменилось. Речь в данной статье пойдёт об этих изменениях, а также о том, как это повлияло на работу с инструментом и на поиск ошибок. Примеры 64-битных ошибок из реальных приложений прилагаются.

О чём статья?

Для начала хотелось бы внести конкретики по содержанию. В статье раскрываются следующие темы:

1. Изменения в анализаторе PVS-Studio, затрагивающие поиск 64-битных ошибок;
2. Обзор 64-битных ошибок первого уровня, найденных анализатором PVS-Studio, и краткие комментарии к ним;
3. Сравнение эффективности в поиске наиболее важных ошибок средствами PVS-Studio и Microsoft Visual Studio 2013.

Первый пункт говорит сам за себя: в нём будут рассмотрены основные изменения PVS-Studio, касающиеся анализа 64-битных ошибок, а также то, как они отразятся на работе с инструментом.

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

В третьем разделе осуществляется сравнение в эффективности поиска этих ошибок статическим анализатором PVS-Studio и средствами среды Microsoft Visual Studio 2013. Причём, в случае Visual Studio, для поиска ошибок использовались как компилятор, так и статический анализатор.

Не стоит забывать, что здесь выписаны только некоторые ошибки. В реальном проекте их наверняка будет куда больше и они будут более разнообразными. В конце статьи предложны ссылки, которые более полно познакомят вас с миром 64-битных ошибок.

Добрый день уважаемые читатели сего сайта.
Сегодня я хотел бы рассказать может быть о странном способе управления очередями в asterisk.
Итак.

Дано:
1. сервер asterisk1.8.32.3
2. sip клиенты(35 номеров). Нумерация двухзначная. Первый номер 11, последний 46.
3. Очереди звонков. При поступлении звонка на городской номер, проговаривается меню и предлагается нажать на цифры от 1 до 4. при нажатии звонок перебрасывается в очередь 1,2,3 или 4 соответственно.

Обсуждение статьи "Не совсем крутой Ruby" зашло достаточно далеко: недостатки и достоинства Ruby между делом перетекали в обсуждение недостатков и достоинств Python. Не сильно удивило то, что передача self в качестве первого аргумента метода класса, некоторым хабравчанам кажется лишней. Ну что ж, не хотите явного self, будет вам неявный this! Под катом, немного магии на чистом Python.

Рассуждая о функциональном программировании, люди часто начинают выдавать кучу «функциональных» характеристик. Неизменяемые данные, функции первого класса и оптимизация хвостовой рекурсии. Это свойства языка, помогающие писать функциональные программы. Они упоминают мапирование, каррирование и использование функций высшего порядка. Это приёмы программирования, использующиеся для написания функционального кода. Они упоминают распараллеливание, ленивые вычисления и детерменизм. Это преимущества функциональных программ.

Забейте. Функциональный код отличается одним свойством: отсутствием побочных эффектов. Он не полагается на данные вне текущей функции, и не меняет данные, находящиеся вне функции. Все остальные «свойства» можно вывести из этого.

Нефункциональная функция:

a = 0
def increment1():
    global a
    a += 1

Функциональная функция:

def increment2(a):
    return a + 1

Вместо проходов по списку используйте map и reduce

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

Что ж, ближе к делу. Есть такая широко известная в узких кругах программа под названием «Govorilka». Как объясняет её автор, это ничто иное, как «программа для чтения текстов голосом». По сути, так оно и есть. При помощи неё было озвучено множество популярных и не очень видео, рапространившихся по всей сети. Программа имеет консольную версию под названием «Govorilka_cp», которую удобно вызывать из своих собственных приложений, что, собственно, я и сделал в одном из своих проектов.

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

Учитывая, что говорилка не обновлялась уже несколько лет, а сам автор оставил вот такое «послание» на своём сайте



, я понял, что надеяться мне не на кого, и решать проблему придётся самому.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

Шифруем всё подряд

Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.

Компания Mikrotik давно выпускает весьма гибкие и недорогие устройства маршрутизации под общим названием Mikrotik Routerboard. Несмотря на обширную линейку этих устройств, их объединяет единая операционная система – Mikrotik RouterOS. Настройка роутеров Mikrotik для работы с 3CX Phone System совсем не так сложна, как может показаться на первый взгляд. Рассмотрим настройку на примере Wi-Fi роутера RB2011UiAS-2HnD-IN. Данный роутер отлично подойдет для организации доступа в сеть Интернет для небольшой и средней компании.

Внимание! Различные модели Mikrotik могут иметь разные предустановки. В частности, модели для SMB сегмента предустановлены таким образом, чтобы с минимальными настройками обеспечить выход в Интернет через первый порт роутера Eth1. Мы воспользуемся этим преимуществом.

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

Итак, весь тернистый путь компиляции и оптимизации нашего приложения можно разбить на 7 шагов. Пошагали!

Продолжая серию статей о новшествах в С#7, акцентирую внимание на, пожалуй, главных нововведениях — Pattern matching и Record type(Примерный перевод «регистрируемые типы»). Эти функционалы дополняют друг друга, поэтому лучше рассказывать о них вместе.

Привет!

Довелось мне на днях столкнуться с такой напастью как p7s файл и, как вследствие этого, с Cryptographic Message Syntax (CMS). На хабре нашлась интересная статья описывающая структуру CMS данных, но в ней к сожалению нет примера, позволяющего наглядно продемонстрировать CMS на практике. Я хочу немного дополнить ту статью и разобрать внутренности файла цифровой подписи p7s.

Требования

В данной статье мы рассмотрим задачи переноса сложных объектов между процессами и машинами. В наших системах было много мест, где требовалось перемещать большое кол-во бизнес объектов различной структуры, например:

• самозацикленные графы объектов (деревья с back-references)
• массивы структур (value types)
• классы/структуры с readonly полями
• инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
• большое кол-во инстансов типов, специализированных для конкретной задачи

Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

• скорость сериализации/десериализации
• объём объектов в сериализированном виде
• возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

Хочется немного рассказать про оптимизацию С/C++ программ, ибо в интернете довольно мало информации. В посте будут объяснения некоторых оптимизаций на примере задачи, которую мне дали решить в институте (задача реализована на С++11, объяснение дается только для 64 битных систем).
В первую очередь статья писалась, чтобы больше узнать про оптимизацию, советы по которой, я надеюсь, вы оставите в комментариях.

Вчера обнаружил, что WoSign дает бесплатно сертификат, теперь уже на 3 года.

Я бы хотел обсудить подводные камни, которые наиболее часто встречаются при работе с фичей async/await в C#, а также написать про то, как их можно обойти.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.