Вступление

В первую очередь надо сказать, что этот продукт уже фигурировал на ресурсах ТМ в этой статье от 2008 года. Однако по прошествии примерно 7 лет картинки потерялись и материал кажется несколько устаревшим.

Этой же публикацией я постараюсь обновить краткий мануал, раскрыть некоторые моменты, оставшиеся «за кадром», да и просто популяризовать отличное решение, которое незаслуженно страдает от недостатка внимания.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Мне нравится, когда клиент может сразу увидеть результаты моих трудов. Я могу корректировать развитие проекта согласно желаниям заказчика, что сильно спасает от недопонимания. Думаю и клиенты не против быть в курсе, куда уходит бюджет и на каком этапе их проект. Добиться этого достаточно просто, благо есть даже целая методология, называемая «Непрерывной интерграцией», позволяющая в кратчайшие сроки деплоить мелкие изменения, но как сделать, чтобы это было достаточно удобно для программиста? Ведь никому не хочется писать код, а после переключаться в контекст системы деплоя или даже использовать ssh соединение чтобы развернуть мелкие изменения на продакшене (или на dev сервере).

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

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

Материал разбит следующим образом:

1. Введение
2. Примеры сессий
3. Проверка авторизации на сервере (LOGIN, PLAIN, CRAM-MD5), Base64
4. Проверка шифрования SSL/TLS
5. Анализ почтового трафика при помощи tshark. Расшифровка SSL/TLS
6. Ссылки на материалы

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

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

Что здесь интересного?

Статья поможет разобраться с тем, как управлять произвольным количеством конфигурационных файлов некоего сервиса в SaltStack.

SaltStack (underfloor): что это и как с ним быть?

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

SaltStack (lobby): типичное применение на простом примере

Итак, предположим, у Вас есть задача автоматизировать установку, внедрение конфигурационных файлов и мониторинг их изменений, перезагрузку в случае необходимости такого популярного сервиса как nginx. Для упрощения системы, сделаем предположение что обслуживаемые сервера построены на базе Debian Wheezy. (Для всех остальных, — читаем про grains систему, — она поможет определить на какой системе мы применяем стейт и соответствующим образом поменять его поведение).
Итак:

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Как можно назвать редактор удобным, если он не умеет запускать то, что мы программируем? Особенностью описываемого мной в данной статье плагина, является возможность запуска чего угодно, будь то программный код, plantUML, LaTeX, Less и всего, что можно написать и запустить. Плагин vim-quickrun может показаться довольно запутанным и сложным, не смотря на прекрасную документацию, потому я решил коротко осветить его в этой статье, дабы вы могли быстрее начать им пользоваться.

На сегодняшний день самыми популярными дистрибутивами для тестирования на проникновение являются *nix-like дистрибутивы: Kali Linux, BlackArch Linux, Pentoo, Whonix и многие другие. Они могут использоваться как в виртуальной среде, так и в качестве live системы или вообще быть установлены в виде десктопной ОС.

Windows пользователи до недавнего времени были обделены (виртуальные машины не берем во внимание) такими сборками, пока не появилась волшебная коробочка — PentestBox.

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

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Каждый, кто начинает разрабатывать бизнес процессы в BPMN нотации, сталкивается с проблемой выбора оптимального инструмента. Даже когда этот инструмент спускается сверху (мы в нашей организации работаем только на …) или коллега советует программу (меня полностью устраивает …), очень хочется, чтобы огласили весь список, который поможет понять, что Вы сделали верный выбор, ну или, что существуют более эффективные инструменты, чем те, на которых Вы вынуждены работать.
Для разработки схем процессов в соответствии с нотацией BPMN наработано уже довольно много программ. Этот обзор – результат небольшого исследования рынка для поиска того программного продукта, которое можно будет использовать для работы. Обзор не претендует на полный анализ рынка и может быть использован для получения первичной информации. Следует иметь ввиду, что все рассматриваемые программы рассмотрены в первую очередь с точки зрения «рисования» процесса, без учета реального позиционирования этих программ на рынке. Основные возможности, которые востребованы в рамках рассматриваемого контекста и по которым оценивались программы, это:

• полнота и соответствие нотации BPMN 2.0;
• удобство разработки схем процессов в нотации BPMN 2.0 и скорость дизайна;
• возможность проверки схем и выгрузки результатов в общепринятых форматах.

Также немного затронут вопрос возможности автоматизации разработанных процессов (без учета сложности и удобства внедрения, а также полноты достижения бизнес целей).

TKGate ( tkgate.org ) — это симулятор цифровых схем на базе Verilog с открытым исходным кодом. Он работает в ОС Linux. Симулятор написан на связке C и Tk/Tcl. Автором проекта является Jeffery P. Hansen (неактивен). Сейчас разработкой занимается наш соотечественник Андрей Скворцов. На прошлой неделе после шестилетнего (!) перерыва в разработке вышла новая версия симулятора TKGate-2.0. Вот так выглядит TKGate:

• Официальный сайт проекта tkgate.org
• Репозиторий проекта на Bitbucket: bitbucket.org/starling13/tkgate/branch/2.0

Под катом более подробный разбор TKGate.

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

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

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



Однако всегда хочется лучшего. Одна из главных проблем, с которыми мы сталкиваемся при общении с владельцами зараженных сайтов, — это поиск источника заражения на стороне сервера. У Яндекса, который каждые сутки размечает тысячи сайтов как зараженные вирусом и опасные для устройств человека, есть регулярно обновляемая база вирусов. И у нашей команды появилась идея, выросшая в большой проект, – антивирус для сайтов. Так мы создали Manul, который решили выложить в open source. Это утилита, которая поможет вебмастеру понять, что произошло с сайтом и вылечить его. Под катом я расскажу подробнее о том, как он устроен и какие проблемы решает.

CTB Locker — очень хорошо продуманный и опасный вирус. Писать о нем не буду — информации об этом вирусе в интернете очень много.

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

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

Я не агитирую пользователей сообщества платить злоумышленникам (я противник этого), но, возможно, этот небольшой мануал кому-то поможет.

Далее я опишу пошагово, как платил плохим людям за расшифровку клиентских данных.

Если вы помните мой предыдущий пост, там было высказано желание разобраться, что и как можно добавить к понравившейся мне модели, чтобы DIY forever. Большое спасибо пользователям UseTi, Phmphx, lomalkin и в особенности n4k4m1sh1, которые поделились интересными идеями на эту тему в комментариях. Понятно, что для поставленных целей нужны два навыка, один из которых — монтаж печатной платы. А значит сегодня мы будем паять, с нуля.



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

Итак, тестируем «Набор Юного электронщика». Получится ли с его помощью собрать рабочие конструкции с нуля не имея предварительных навыков, как это до того у нас получилось с механической моделью?

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



Местные — это любые радиосигналы в рабочей полосе частот системы связи, попадающие на вход приёмника из местного эфира. Спутниковые системы по сравнению с нашими привычными сотовыми куда чувствительнее. Если вы орёте в ухо человеку на расстоянии 1 метра, шум листьев во дворе вас не волнует. А вот если вы стоите на расстоянии километра и шепчете, то даже при наличии у человека нужного приёмника листья будут мешать. Мощность на входе приёмника порядка минус 110 дБм, или 1х10-14Вт. Всё то же самое, только вместо листьев — наземные радиоточки, трамваи, системы зажигания автомобилей, антирадары.

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

1. Шунтовые резисторы
Шунты и шунтовые резисторы — про­стейший вариант токочувствительных элементов. Необходимо лишь помнить о температурном коэффициенте сопро­тивления (ТКС) резистора и избегать его нагрева. Напомним эмпирическое правило выбора токочувствительного резистора: его максимально допусти­мая мощность должна не менее чем в два раза превышать рабочую мощность рассеивания.

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

В топике блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто собирается открыть своё дело. Рядом с каждой — короткие пояснения, почему и зачем стоит прочесть.

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.