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

Настороженно отношусь к непрофильным топикам, но решил написать этот по следующим причинам:

• У жонглирования есть своя теория — стройная и математически привлекательная!
• Мы живем не только работой. Жонглирование — отличное развлечение и разминка после долгого сидения за компом.
• В пятницу приятно немного расслабиться и почитать не очень серьезные статьи. К тому же, будет чем заняться на выходные, особенно если у вас не было определенных планов.

Теория

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

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

Жизнь мальчиков с математическими способностями в атомных городах была предопределена — школа с пятерками по алгебре и геометрии, мех-мат столичного университета, возвращение в систему, квартира через год, кандидатская степень в 40 лет, ВАЗ 2103 к пятидесяти годам, звание доктора, гараж, шесть соток, четыре квадратных метра.

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



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

Баста карапузики, кончилися танцы.

В предыдущей части мы детально рассмотрели «читерские» приёмы обхода «защит» (скрытие SSID, MAC-фильтрация) и защит (WPS) беспроводных сетей. И хотя работает это в половине случаев, а иногда и чаще — когда-то игры заканчиваются и приходится браться за тяжёлую артиллерию. Вот тут-то между вашей личной жизнью и взломщиком и оказывается самое слабое звено: пароль от WPA-сети.

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

К концу статьи вы поймёте, почему ленивый 20-значный пароль из букв a-z на пару солнц более стоек, чем зубодробительный 8-значный, даже использующий все 256 значений диапазона.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

На хабре часто публикуют статьи о самоорганизации — нам всем хочется меньше прокрастинировать, и делать больше полезного. Но что если делать полезное мешает дичайшая усталость? Никакая организация задач усталость не уберет.

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

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

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

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

Часть вторая

Прелюдия

Сегодня я расскажу вам как я создавал бюджетное отказоустойчивое iSCSI хранилище из двух серверов на базе Linux для обслуживания нужд кластера VMWare vSphere. Были похожие статьи (например), но мой подход несколько отличается, да и решения (тот же heartbeat и iscsitarget), используемые там, уже устарели.

Статья предназначена для достаточно опытных администраторов, не боящихся фразы «патчить и компилировать ядро», хотя какие-то части можно было упростить и обойтись вовсе без компиляции, но я напишу как делал сам. Некоторые простые вещи я буду пропускать, чтобы не раздувать материал. Цель этой статьи скорее показать общие принципы, а не расписать всё по шагам.

Вводные

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

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

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

В качестве софта было выбрано:

• Debian Wheezy + LTS ядро 3.10
• iSCSI-таргет SCST
• DRBD для репликации
• Pacemaker для управления ресурсами кластера и мониторинга
• Подсистема ядра DM-Crypt для шифрования (инструкции AES-NI в процессоре нам очень помогут)

В итоге, в недолгих муках была рождена такая несложная схема:

Нам понадобится всего лишь несколько минут для того что бы поднять распределенную файловую систему Ceph FS

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

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

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

На последней DEFCON был продемонстрирован взлом протокола аутентификации MS-CHAPv2 (давно пора). В результате многие СМИ разразились информацией о том, что «тысячи VPN и WPA2-утройств находятся в опасности». Рассмотрим, насколько это утверждение верно для Wi-Fi сети реализующей WPA2.
Скандалы? Интриги? Расследования?

Захотелось поделится с хабросообществом парой способов провести инвентаризацию техники быстро и без особых усилий. Сподвигла меня вот эта статья, но как сторонник UNIX-way я расскажу способы сделать всё то же самое и даже больше без необходимости окружать себя гомогенной сетью из одинаковых рабочих станций или привязки к одной технологии.

Что мы хотим?

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

Если вы испытываете нехватку физических портов на оборудовании сети передачи данных, в то время как перед вами встала острая необходимость завести второго интернет-провайдера или вывести часть серверов в ДМЗ используя оборудование Cisco Systems, тогда эта статья должна помочь с решением многим начинающим системным администраторам, а также тем, кто недавно приступил к работе с сетями передачи данных и с оборудованием Cisco в частности. Речь пойдет об архитекторе под названием Router-on-a-Stick.

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

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

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Несколько дней назад вышел из строя один из жестких дисков на бюджетном массиве из 16х1ТБ дисков. Уровень массива: RAID 6. Ситуация осложнилась тем, что (как оказалось) ранее также встал кулер на видеокарте этого же сервера, что не было заранее подмечено, и после замены HDD, в результате изменения режима охлаждения корпуса — это стало проявляться в виде зависаний во время синхронизации, что само по себе очень неприятно. Вылилось это в то, что массив перестал автособираться, и были помечены как сбойные еще несколько дисков, и пришлось уже разбираться с ним по-серьёзному, курить вики, мануалы и форумы (форумы — самое полезное, поскольку описывают опыт конкретных людей в конкретных ситуациях).

В настоящее время, во многих российских провайдерах уделяется очень мало внимания DNS серверам. Тем не менее это очень важная составляющая услуг доступа в интернет.
Инженерам по телематике и инфраструктурным сервисам, а так-же их боссам посвящается.

Выполнение перечисленных правил может помочь вам минимизировать жалобы ваших пользователей на DNS:

На рисунке представлена типичная схема подключения небольших офисов к интернету.
Если основной канал выхода в интернет (ISP1) и резервный (ISP2), на который переключаются в случае проблем с основным каналом.
Переключение обычно проводится сменой шлюза по умолчанию на роутере.

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

Я расскажу как сделать сервисы доступными по обоим внешним адресам одновременно, средствами ipfw и natd.

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

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

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

1. Это приведёт с излишнему разрастанию статьи
2. Маны и гугл никто не отменял
3. Пункт 2 очень полезен для развития специалиста

Итак, как повысить безопасность и надёжность сервера (да и рабочей станции) на базе линукс?