Pull to refresh
274
0
Георгий Шуклин @amarao

Забанен за упоминание войны. Больше не на хабре.

Send message

Forensic system administration

Reading time 13 min
Views 17K
Среди всех служебных обязанностей системного администратора, самой интересной, сложной и продуктивной, на мой взгляд, является детективная работа по мотивам случившегося «инцидента». При этом, в отличие от реальной криминологии, системный администратор сам себе одновременно и детектив, и эксперт по вещественным доказательствам.

Я сейчас исключаю из рассмотрения инциденты с осмысленным злым умыслом, это отдельный топик. Речь про стихийные проблемы (сервер упал/завис, виртуальная машина начала тормозить а потом перестала, приложение потеряло 100500 транзакций и считает, что всё хорошо).

Суть происшествия


Иногда она тривиальная («самопроизвольно перезагрузился сервер», или «упал самолёт»). Иногда она крайне трудная для объяснения («клиенты жалуются что у не получается поменять регион», при этом все сотрудники с клиентскими аккаунтами регион поменять могут). Чаще всего, чем дальше от системного администратора источник жалобы, тем более размытой становится жалоба: «клиент говорит, что после заказа в интернет-магазине плюшевого медведя он не может поменять регион на IE7 при использовании LTE-коннекта через USB-модем, а ещё он получает 500ую ошибку при попытке отменить операцию и нажатии „назад“).

Ещё более сложным является случай, когда несколько проблем сливаются вместе: „сервер внезапно перезагрузился, а на другом сервере был таймаут работы с базой данных, а клиенты в это время писали, что у них не грузятся картинки“. Сколько тут проблем? Одна, две, три, а может и больше? Какие из проблем надо молча объединить (база данных и отсутствие картинок), а какие надо учитывать раздельно? А если в этот момент ещё придёт жалоба, что пользователь не может залогиниться в систему — это обычное „забыл пароль“ или тоже симптом? А если таких пользователей два? Или кто-то мимоходом говорит, „что-то у меня почта не проходит“?

Подсознательно в момент начала проблем, каждая новая жалоба тут же объединяется с существующими (и может завести не туда), плюс резко увеличивает стресс из-за того, что приходится думать не о трёх симптомах, а о восьми, например. А в голове хорошо только семь удерживаются. Но в то же время в моей практике бывало так, что пришедший „новый“ симптом с лёгкостью приводил к сути проблемы и её устранению…… за вычетом того, что серьёзная проблема (с которой всё началось) не имеет никакого отношения к радостно и быстро починенной ерунде. А время потрачено.

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

То есть журнал (в sticky notes) выглядит так:
  • Мониторинг сработал на srv1 (22:05)
  • (имя) сказал про проблемы с почтой (22:07)
  • Не могу залогиниться на srv12 (22:08)/refused — Зашёл 22:16, dmesg чисто, аптайм большой
  • Не могу залогиниться на srv13 (22:10) (timeout) — отвалился офисный wifi (22:11)
  • Не открывается панель (22:12)
  • Саппорт пишет, что клиент жалуется, что ничего не работает, 22:15

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

Вторым аспектом проблемы является доказательство существования проблемы. Самая ненавистная фраза, которой не удаётся избежать:

У меня всё работает


После того, как Энийские Авиалинии пожаловались производителю на то, что самолёты иногда падают, разработчик проверил, что самолёты взлетают/садятся и закрыл тикет с 'Unable to reproduce'. Сотрудники поддержки Энийских Авиалиний продолжают собирать статистику по падению самолётов и пытаются научиться воспроизводить падение в лабораторных условиях.

Читать дальше →
Total votes 29: ↑26 and ↓3 +23
Comments 6

Админские байки: в погоне за фрагментацией туннелей в оверлейной сети

Reading time 10 min
Views 21K

Лирическое вступление


Когда администраторы сталкиваются с неожиданной проблемой (раньше работало, и, вдруг, после обновления, перестало), у них существует два возможных алгоритма поведения: fight or flight. То есть либо разбиратся в проблеме до победного конца, либо убежать от проблемы не вникая в её суть. В контексте обновления ПО — откатиться назад.

Откатиться после неудачного апгрейда — это, можно сказать, печальная best practice. Существуют целые руководства как готовиться к откату, как их проводить, и что делать, если откатиться не удалось. Целая индустрия трусливого поведения.

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

Завязка драмы


Облако «Instant Servers» Webzillа. Рутинное обновление хоста nova-compute. Новый live image (у нас используется PXE-загрузка), отработавший шеф. Всё хорошо. Внезапно, жалоба от клиента: «одна из виртуалок странно работает, вроде работает, но как начинается реальная нагрузка, так всё замирает». Инстансы клиента переносим на другую ноду, проблема клиента решена. Начинается наша проблема. Запускаем инстанс на этой ноде. Картинка: логин по ssh на Cirros успешен, на Ubuntu — зависает. ssh -v показывает, что всё останавливается на этапе «debug1: SSH2_MSG_KEXINIT sent».

Все возможные внешние методы отладки работают — метаданные получаются, DHCP-аренда инстансом обновляется. Возникает подозрение, что инстанс не получает опцию DHCP с MTU. Tcpdump показывает, что опция отправляется, но не известно, принимает ли её инстанс.

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

Если это проблема с MTU, то у нас есть внезапный помощник. Это IPv6. При том, что «белые» IPv6 мы не выделяем (извините, оно пока что не production-ready в openstack), link-local IPv6 работают.
Читать дальше →
Total votes 40: ↑39 and ↓1 +38
Comments 35

Для чего используют TOR?

Reading time 6 min
Views 72K

Вступление


Я не буду разводить параноидальные сказки о том, что NSA и ФСБ за всеми следит. Просто примем за базовый тезис, что tor и i2p — «наше всё». К сожалению, в контексте TORа часто можно слышать только про silkroad и детскую порнографию. Мол, рассадник, раскачивающий и покушающийся.

Я управляю несколькими tor-exit node'ами и i2p маршрутизаторами. Чтобы избежать вопросов, мой работодатель к ним не имеет никакого отношения: все эти ноды — исключительно за мой счёт, в свободное от работы время. Самой старой из них уже почти год, самой молодой — примерно 4 месяца. За это время я не получил ни одного abuse report'а (я сам работаю в хостинговом бизнесе, так что хорошо представляю себе процесс реакции на «абузу» — она в первую очередь пересылается клиенту).

Не смотря на отсутствие abuse'ов, вопрос оставался: для чего люди используют TOR?

Контроль над exit node'ой позволяет посмотреть на проходящий трафик. Понятно, что мы исключаем весь шифрованный трафик (TLS, SSH), а так же весь трафик на .onion узлы. Однако, среди остального мы можем посмотреть на примерное распределение ресурсов по популярности.

Забегая вперёд, слегка упрощённый ответ на вопрос статьи:


(более подробная табличка — в конце статьи)

Методология измерения

Читать дальше →
Total votes 58: ↑54 and ↓4 +50
Comments 178

Обработка логов с учётом предыдущих сообщений в logstash/elasticsearch

Reading time 4 min
Views 8.9K
Про отлов ядерных MCE (machine check error) и прочей гадости с помощью netconsole я писал недавно. Крайне полезная вещь. Одна проблема: throttling на CPU из-за локального перегрева (длительной нагрузки) фиксируется как MCE. Случается бэкап — и админам приходит страшное сообщение об MCE, которое на практике означает «чуть-чуть перегрелось» и точно не требует внимания к себе в 3 часа ночи.

Смехотворность проблемы ещё тем, что Linux фиксирует MCE после того, как throttling закончился. То есть режим 'normal', но вместо этого оно превращается MCE. Выглядит это так:
CPU0: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature above threshold, cpu clock throttled (total events = 40997)
CPU4: Core temperature/speed normal
CPU0: Core temperature/speed normal
mce: [Hardware Error]: Machine check events logged

При этом мы точно хотим реагировать на нормальные MCE. Что делать?

В рамках logstash обработка сообщений предполагается stateless. Видишь сообщение — реагируешь. Внедрять же ради одного типа сообщений более сложную систему — оверкилл.

Казалось бы, есть фильтр (не путать с output) elasticsearch, который позволяет делать запросы. К сожалению, он не умеет делать 'if'ы, то есть remove_tag и add_tag будут отрабатывать вне зависимости от того, удался поиск или нет.

Грустно.
Читать дальше →
Total votes 10: ↑10 and ↓0 +10
Comments 7

Обработка сообщений ядра

Reading time 9 min
Views 17K

Предисловие


Страшная сказочка:
EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
CMCI storm detected: switching to poll mode
page allocation failure: order:1, mode:0x4020
invalid opcode: 0000 [#1] SMP

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

Часть из этих сообщений в примерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».
Читать дальше →
Total votes 30: ↑29 and ↓1 +28
Comments 13

Не используйте "!!" в баше

Reading time 1 min
Views 19K
Каждый раз, когда неофит открывает для себя возможности баша и решает про это написать, он обязательно всем рассказывает про удобный метод «повторить команду» с использованием "!!".

Типа так:
$ touch /test
touch: cannot touch ‘/test’: Permission denied
$ sudo !!
sudo touch /test

Типа, хэппи-энд.

Я никогда такого не использовал, но не задумывался, «почему». Просто мне не нравилась эта идея.

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

echo NO ROOT PLEASE
 echo do it with sudo
sudo !!

(просто скопипастите это пример в шелл)
объяснение
Total votes 69: ↑33 and ↓36 -3
Comments 77

network manager + автоматизация http-логина в wifi

Reading time 2 min
Views 17K
Пост будет коротким, но очень полезным.

abstract: Есть масса wifi-хот-спотов, которые просят сделать какую-нибудь глупость при подключении. Ввести пароль в http-форме, поставить чекбокс «согласен с продажей почки в обмен на интернет» и т. д.

Это задалбывает, особенно, если из wifi периодически выкидывает. В посте предлагается простое решение для автоматизации логина с помощью хуков Network Manager.

Подготовка


Нам надо понять куда кого как посылать, чтобы оно заработало. Ставим firebug или любой другой похожий плагин. Включаем, идём в вкладку 'net', включаем persistent (это важно), логинимся.

Получаем вот такое:



Находим POST (если их несколько — методом перебора и комбинирования), выбираем copy as curl, сохраняем куда-нибудь на будущее.

Дальше находим uuid нашего коннекта — в файле /etc/NetworkManager/system-connections/our_wifi.

Пишем скрипт (всё ниже — от рута) в каталоге /etc/NetworkManager/dispatcher.d/, например, /etc/NetworkManager/dispatcher.d/02-our_wifi-auto
Читать дальше →
Total votes 32: ↑27 and ↓5 +22
Comments 29

SSD + raid0 — не всё так просто

Reading time 6 min
Views 135K

Вступление


Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:

По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом SSD и упёрся в свой собственный потолок по производительности.

После того, как аппаратный рейд выкинули и на его место поставили HBA, а диски собрали в raid0 с помощью linux-raid (его часто называют 'mdadm' по названию утилиты командной строки), ситуация улучшилась. Но не прошла полностью -цифры возросли, но всё ещё были ниже рассчётных. При этом ключевым параметром были не IOPS'ы, а многопоточная линейная запись (то есть большие куски данных, записываемых в случайные места).

Ситуация для меня была необычной — я никогда не гонялся за чистым bandwidth рейдов. IOPS'ы — наше всё. А тут — надо многомногомного в секунду и побольше.

Адские графики


Я начал с определения baseline, то есть производительности единичного диска. Делал я это, скорее, для очистки совести.

Вот график линейного чтения с одной SSD.



Увидев результат я реально взвился. Потому что это очень сильно напоминало ухищрения, на которые идут производители дешёвых USB-флешек. Они помещают быструю память в районы размещения FAT (таблицы) в FAT32 (файловой системе) и более медленную — в район хранения данных. Это позволяет чуть-чуть выиграть по производительности при работе с мелкими операциями с метаданными, при этом предполагая, что пользователи, копирующие большие файлы во-первых готовы подождать, а во вторых сами операции будут происходить крупными блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584
Читать дальше →
Total votes 132: ↑129 and ↓3 +126
Comments 89

По поводу появления 8 и 10Тб жёстких дисков

Reading time 3 min
Views 57K
Новость: начались поставки 8Тб жёстких дисков, анонсированы 10Тб жёсткие диски с «черепичной» системой записи (shingled magnetic recording), которая обещает увеличение объёмов путём снижения скорости случайного доступа (подробности).

Комментарий


SSD почти полностью сожрали всё в диапазоне десятков/сотен гигабайт. HDD используется только как сверхдешёвая заглушка, и я не понимаю, почему ни один ушлый китаец не догадался сделать SD-кардридер с mSATA-интерфейсом. Для low-end'а (лишь бы загрузиться) этого хватит за глаза и за уши, а стоить будет дешевле. Если же человеку это «медленно», то очевидно, что SSD его спасёт. По мере продвижения за 300-400Гб картинка становится экономически непривлекательной для многих сегментов (1Tb стоит €50 за HDD против €350 за самую дешёвую SSD). Но все понимают, что выход на бюджетный терабайт для SSD — вопрос времени. Хотя потребности в месте растут (игры/кино всё больших разрешений), в то же самое время область потребностей сокращается (зачем качать, когда можно смотреть в онлайне), то есть десктопный рынок можно считать потерянным.

Но, кроме него есть и другие рынки.

HDD, кроме low-end'а, продолжают жить:
  1. Из-за совершенно сумашедшего парка серверов, которые живут много больше, чем диски. Диски надо менять.
  2. Из-за гигантских объёмов за разумные деньги
  3. Из-за лучшей производительности на устоявшуюся линейную запись.

Вот последний фактор определяет уникальную нишу для HDD — они лучше подходят для линейной записи. У SSD с этим много хуже — если на SSD постоянно писать большими блоками, то housekeeep'инг перестаёт справляться (особенно, если запись циклическая внутри файла, типа серверов видеонаблюдения), кеш забивается, и SSD деградирует до уровня WD Green'ов или даже хуже. При этом стоят они дороже, износ на запись у них множится на write amplification (когда диск забит данными, SSD приходится перемещать несколько блоков, чтобы записать один), чем дешевле SSD, тем у неё обычно хуже ресурс (а в отличие от бытового «ой, моя SSD'ка изнашивается» потенциальный износ SSD на сервере видеонаблюдения — вполне объективный вопрос).
Читать дальше →
Total votes 98: ↑75 and ↓23 +52
Comments 124

Маленькая админская история: как поймать OOM

Reading time 5 min
Views 30K
Админская загадка: На сервере произошло три oom kill'а, а мониторинг сказал только про два. Почему?

Конфигурация

Для мониторинга всего у нас настроена связка ganglia-shinken-logstash-elasticsearch-kibana. Полное описание довольно обширно, так что ограничусь только частью, имеющей отношение к проблеме.

В logstash присылаются логи со всех серверов. Он складывает их в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.

Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.

Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а.

[517935.914380] ntpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[517935.914730] Call Trace:
[517935.914807]  [<ffffffff816e14ce>] dump_header+0x83/0xbb
[517935.914877]  [<ffffffff816e155b>] oom_kill_process.part.6+0x55/0x2cf
...
с финальным торжествующим: 
[517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child
[517935.951203] Killed process 4550 (apache2) total-vm:2610268kB, anon-rss:2012696kB, file-rss:3928kB


Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…

Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
forensic system administration
Total votes 54: ↑48 and ↓6 +42
Comments 19

Современный бэк-офис IT-компании

Reading time 11 min
Views 53K
В одной из дискуссий недавно, я перечислил основные системы, делающие работу ИТ-компании цивилизованной. Список получился весьма обширный, и я решил оформить его как самостоятельную статью.

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

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

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:


Читать дальше →
Total votes 56: ↑50 and ↓6 +44
Comments 29

JSON pipes в шелле

Reading time 4 min
Views 23K
Чем больше я пишу однострочники в шелле, тем больше я прихожу к двум важным идеям:
  1. Это очень мощное средство для «непосредственного программирования», то есть указания компьютеру, что делать.
  2. Большая часть однострочника посвящена grep/awk/cut/tr, которые каким-то образом выковыривают и приводят в человеческий вид вывод предыдущих утилит.

При том, что модель pipe'ов восхитительна, совершенно грязные хаки по отлову нужных полей в выводе во втором пункте («а вот тут мы можем выделить нужное нам по характерной запятой с помощью awk -F, '{print $2}'...) делают процедуру спорной по удовольствию, и уж точно нечитаемой.

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

При этом есть враждебная и не очень хорошо написанная среда — powershell (винды). В которых взяли хорошую идею (пайпы передают не текст, а объекты), но испортили её двумя вещами:
  1. Неэргономичной консолью виндов (Shift-PgUp где, а? говорят, Ctrl-PdUp в новых версиях)
  2. предложением пойти и выучить .net для того, чтобы нормально с методами работать.
  3. Отсутствием под большинство операционных систем


Хочется иметь объекты в пайпе в тёплом ламповом линуксовом шелле. С hand-candy (мало печатать), eye-candy (приятно смотреть) и общей эргономичностью процесса использования. Ещё хочется иметь возможность сочетать „новый подход“ со старым, то есть обычным текстовым pipe'ом.

Идея


Надо написать набор инструментов, которые позволят в pipe-style оперировать с структурированными данными. Очевидным выбором является XML JSON.
Нам нужно:
  1. Утилиты, которые примут типовые форматы на вход и сконвертируют их в json.
  2. Утилиты, которые позволят в pipe'е манипулировать с json'ом.
  3. Утилиты, которые приведут json в „обычный“ формат.

В этом случае человек не будет видеть json на экране, но будет иметь возможность работать с ним.

Для затравки


(для понимания я буду писать длинные имена утилит, в реальной жизни это будут короткие сокращения, то есть не json-get-object, а что-то типа jgo или jg)

Выводит только файлы, для которых file сумел определить тип:
ls -la | ls2json | json-filter 'filename' --exec 'file {} >/dev/null' | json-print

Выкачивает с некоторого сайта токен для авторизации, выковыривает его из json'а и выставляет в переменные среды окружения, после чего скачивает список и отфильтровав по регэкспу поле „автор“ выкачивает все url'ы:
curl mysite/api.json | env `json-get-to-env X-AUTH-TOKEN`;curl -H X-AUTH-TOKEN $X-AUTH-TOKEN mysite/api/list.json | json-filter --field 'author' --rmatch 'R.{1,2}dal\d*' | json-get --field 'url' | xargs wget

Парсит вывод find -ls, сортирует по полю size, вырезает из массива элементы с 10 по 20, выводит их в csv.
find . -ls | ls2josn | json-sort --field 'size' | json-slice [10:20] | json2csv
Читать дальше →
Total votes 64: ↑58 and ↓6 +52
Comments 133

DoS уязвимость в Open vSwitch

Reading time 9 min
Views 9.4K
Спойлер: Open vSwitch версий меньше 1.11 уязвим перед атакой вида «flow flood», позволяющей злоумышленнику прервать работу сети отправкой относительно небольшого потока пакетов в адрес любой виртуальной машины. Версии 1.11 и старше проблеме не подвержены. Большинство серверов с OVS до сих пор используют OVS 1.4 или 1.9 (LTS-версии). Администраторам таких систем настоятельно рекомендуется обновить систему на более новую версию OVS.

Лирика: Прошло уже больше полутора лет с момента, когда я впервые сумел воспроизвести эту проблему. В рассылке OVS на жалобу сказали, что «в следующих версиях исправят» — и исправили, пол-года спустя. Однако, это исправление не коснулось LTS-версии, а значит, большинство систем, использующих OVS, всё так же уязвимо. Я пытался несколько раз связаться с Citrix'ом (т.к. он использует самую уязвимую версию OVS в составе Xen Server — в тот момент это был мой основной продукт для эксплуатации), но никакой внятной реакции не последовало. Сейчас у администраторов есть возможность устранить проблему малой кровью, так что я решил опубликовать описание очень простой в воспроизведении и крайне запутанной и в диагностике проблемы — проблеме «flow congestion», она же «flow flood attack», она же «странная неведомая фигня, из-за которой всё работает странно». Раньше в комментариях и в рассылках про эту проблему я уже несколько раз писал, но у меня ни разу не хватало пороху полностью описать проблему на русском языке так, чтобы суть проблемы была понятна обычному айтишнику. Исправляюсь.

Следующая строчка hping3 -i u10 virtual.machine.i.p нарушает работоспособность хоста виртуализации, где запущена виртуальная машина. И не только хоста виртуализации — любую систему, работающую на Open vSwitch версий меньше 1.11. Я делаю особый упор на версиях 1.4.3 и 1.9, потому что они являются LTS-версиями и используются чаще всего.

Более суровая версия того же вызова, на этот раз с нарушением правил пользования сетью: hping3 --flood --rand-source virtual.machine.i.p. Соотношение исходящего трафика (~10-60Мбит/с) и (потенциальной) пропускной способности интерфейса жертвы (2x10G, соотношение по доступной полосе атакующий/атакуемый порядка 1:300-1:1000) позволяет говорить именно про уязвимость, а не про традиционную DoS атаку флудом, забивающем каналы аплинков до нерабочего состояния.

Симптомы со стороны хоста виртуализации: неожиданные задержки при открытии соединений, рост потребления CPU процессом ovs-vswitchd до 100%, потеря пакетов для новых или малоактивных сессий. Если используется OVS 1.4, то процесс ovs-vswitchd не только съедает свои 100% CPU, но и начинает подъедать память и делает это со скоростью до 20 мегабайт в минуту, пока к нему не приходит добрый дедушка OOM и не проводит воспитательную беседу.
Читать дальше →
Total votes 29: ↑24 and ↓5 +19
Comments 27

И объял меня systemd до глубин дистрибутива моего

Reading time 1 min
Views 36K
Оно случилось: Debian начал переход на systemd.

Для системных администраторов это выглядит вот так:
localhost# apt-get update;apt-get upgrade
...
The following packages have unmet dependencies:
 systemd-sysv : Breaks: sysvinit-core but 2.88dsf-53 is installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     sysvinit-core               

Accept this solution? [Y/n/q/?]


Что это означает? Это означает прохождение рубежа в постепенной миграции на systemd, решение о котором было принято чуть ранее, замена sysv-init на systemd. Пакет sysvinit-core содержит в себе /sbin/init, и его заменяют на другой /sbin/init из состава systemd.

Кто-то видит в происходящем шаг в светлое будущее, где все будут счастливы и почти не надо будет умирать, кто-то видит акт трагичного и смиренного принятия роковой судьбы, тёмной длани Рэдхэта, простирающейся на все дистрибутивы вокруг и устраняющий Фатальный Недостаток других систем запуска, кто-то просто со стоическим отчаянием ждёт ещё больше и больше Поттеринга (Л. Поттеринг — автор systemd, он же автор pulseaudio, он же автор неповторимого стиля изложения новых идей, при которых для старого образа жизни и мышления не остаётся места).

Читать дальше →
Total votes 60: ↑49 and ↓11 +38
Comments 176

Борьба с избыточным логированием в Openstack

Reading time 5 min
Views 8.5K
Содержание: Душераздирающая скорость роста auth.log на хостах с neutron-plugin-openvswitch-agent. Анализ причин, метод устранения. Немного про работу sudo, PAM и его сессии.



О чём пойдёт речь? Openstack — платформа для построения облаков. Neutron — название его подсистемы отвечающей за сеть, модной хипстерской вебдванольной, cчитающейся более совершенной и функциональной, чем первая попытка под названием nova-networking. openvswitch-plugin — это плагин к neutron, реализующий его функциональность при помощи Open vSwitch — программного коммутатора, позволяющего делать умные штуки, вроде GRE-туннелей, бондинга и мирроринга портов, наложение правил на порт внутри виртуального коммутатора в стиле iptables и т.д.

neutron-openvswitch-plugin-agent — одна из компонент этого плагина, работающая на всех хостах, которые имеют хоть какое-то реальное отношение к передаче сетевого трафика виртуалок. Иными словами, это все compute-узлы (там, где работают виртуалки), networking-узлы (которые делают «интернет» для виртуалок). Из списка выпадают только сервера API и прочие служебные сервера. С учётом, что большая часть облака состоит из compute + networking, можно, слегка огрубляя, говорить, что этот neutron-openvswitch-plugin-agent установлен на всех хостах. Logstash — система централизованной сборки логов, Elasticsearch — база данных для работы с этими логами.

Для своевременной реакции на проблемы ПО, все логи всех приложений должны собираться и анализироваться системой мониторинга. Подробнее про это у нас уже было написано. Однако, даже хорошего может быть слишком много. Быстро обнаружилось, что большая часть собираемого с хостов — нелепые сообщения следующего вида:
Читать дальше →
Total votes 22: ↑19 and ↓3 +16
Comments 15

Изолирование приложения с IP-адресом из VPN другой страны на примере Steam

Reading time 7 min
Views 67K
Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

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

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces


Традиционно, приложение, запускающееся даже с правами пользователя, имеет полный доступ в сеть. Оно может использовать любой сетевой адрес, существующий в системе для отправки пакетов.

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

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

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Читать дальше →
Total votes 111: ↑105 and ↓6 +99
Comments 84

США отдаёт контроль над корневой зоной DNS

Reading time 3 min
Views 55K

В эту пятницу на сайте неприметного американского ведомства появилось сообщение, что оно планирует отдать управление над корневой зоной DNS. Другими словами, США перестанет контролировать всю систему доменных имён, отдавая управление сообществу.

Техническая часть

В DNS рекурсивное определение имени начинается с точки в конце доменного имени. Чаще всего её пропускают, но, на самом деле вместо www.grani.ru следует писать www.grani.ru. — именно так, с точкой. Когда клиент просит рекурсивный DNS сервер сказать, какой IP адрес у www, процесс начинается с определения авторитетных серверов для зоны ru. И начинается он с запроса в зону ".", сервера которых отвечают, что у зоны RU есть несколько авторитетных серверов, и дальше процесс рекурсивно продолжается, пока мы не узнаем, что A-запись для www указывает на 46.226.110.151, после чего браузер идёт по этому адресу и выясняет, что Роскомнадзор… Впрочем, пост не о цензуре.

За корневую зону отвечают корневые сервера. У них 13 IP-адресов — это максимальное количество, которое можно уложить в один ответ DNS по UDP. Самих серверов больше (используется мультикастинг, балансировка нагрузки посредством DNAT'а и другие технологии), но адресов у них — 13. Адреса корневых серверов намертво «прибиты гвоздями» в конфигах практических любых DNS-серверов. И даже DNS-сервера, которые не поддерживают рекурсию, обычно отвечают списком корневых серверов (если мы не знаем корневых серверов и не знаем с чего начать процесс рекурсивного определения имени, то любой DNS-сервер нам укажет именно на них).

Именно в корневой зоне регистрируются TLD (top level domains), такие как .ru, .com, .jp, .info и т.д.

На этом техническая часть заканчивается и начинается политическая.

Политическая часть

DPI, великий китайский файрвол, малый русский файрвол — это всё ерунда. Кто контролирует корневую зону, контролирует весь интернет. Если из DNS удалить зону .no, то ни один норвежский сайт не будет открываться по имени. Точнее, перестанет открываться через некоторое время, как только протухнут кеши у ресолверов.

Исторически, с момента разрешения использования Интернета для коммерческой деятельности, корневая зона находилась в формальном подчинении NTIA (полное название: U.S. Commerce Department’s National Telecommunications and Information Administration — американский аналог Роскомнадзора, правда, без функций цензуры). В ходе развития Интернета, была создана некоммерческая организация ICANN, которая занималась отношениями с регистраторами национальных доменов, созданием новых TLD и т.д. С нею был заключен договор — и ICANN выступала и в качестве IANA (верхнего распределяющего IP-адреса), она же управляла корневой зоной. Техническая же работа была поручена Verisign. Но формальный контроль оставался у США.
Читать дальше →
Total votes 115: ↑105 and ↓10 +95
Comments 70

Сервис анонимной аренды хостинга с i2p-доступом

Reading time 4 min
Views 20K
(внимание: сервиса нет, есть только идея)

Во время публикации информации в обход цензуры, возникает проблема: как опубликовать информацию без раскрытия своей личности и данных, ведущих к раскрытию личности? IP адрес можно считать достаточной информацией для выяснения личности обратившегося к серверу. С учётом, что все хостеры обычно вполне кооперируются с тоталитарными правительствами, процесс установления владельца/автора того или иного сайта не представляет проблем. Наивные обещания компаний «не раскрывать данные клиентов» требуют очень высокого доверия, кроме того, не всегда могут быть исполнены (lavabit тому примером).

Ниже предлагается техническое решение, исключающее фактор высокого доверия (защиту от шпионажа) и предполагающая умеренное доверие (не скроются с деньгами).

Коммерческая компания покупает услуги хостинга (VDS, dedicated server и т.д.), конфигурирует там i2p роутер плюс ssh-сервер, работающий через i2p, и отдаёт реквизиты своему клиенту, который заказывает и оплачивает услуги только через i2p. Оплата происходит любой криптовалютой (пока условимся, что bitcoin), всё взаимодействие происходит через i2p сеть.

Описание со стороны компании


Компания имеет сайт в i2p, принимает биткоины. При поступлении оплаты компания заказывает услугу у указанного поставщика (в обычном интернете), настраивает i2p, отдаёт реквизиты клиенту. По запросу клиента сервер перезагружается/переустанавливается, так же возможна пересылка почты с саппортом. В самом продвинутом варианте — API для управления.

Описание со стороны клиента


Зайдя на i2p сайт клиент заказывает хостинг «в интернете», получает доступ на свой сервер через i2p, где размещает нужную информацию.

Описание со стороны тоталитарного режима


В интернете есть сайт. Сайт находится на сервере. Сервер принадлежит хостеру, был заказан компанией-посредником, после чего продан анониму за биткоины, у которых в истории фигурируют несколько миксеров и операции внутри i2p-сети. Можно изъять сервер, можно наказать компанию (если она находится в юрисдикции тоталитарного режима), найти автора по логам, записанному трафику и посредством ханипотов не получается.

Доверие серверу

Читать дальше →
Total votes 44: ↑36 and ↓8 +28
Comments 41

Ubuntu переходит на systemd

Reading time 1 min
Views 18K
После известного голосования, Майкл Шаттлворт согласился с тем, чтобы в убунту был systemd вместо upstart. (В 14.04 будет upstart, а дальше произойдёт переход на systemd).

Источник: www.markshuttleworth.com/archives/1316
Total votes 102: ↑43 and ↓59 -16
Comments 22

Рассуждения о Software Defined Storage: что не так с IO?

Reading time 9 min
Views 18K
Abstract: О новом тренде — software defined strorge и главной родовой травме блочных устройств — обещании бесконечной надёжности.

Лирика


На горизонте новый buzzword: Software defined $thing. Мы уже имеем состоявшийся и сформировавшийся круг всего, относящегося к software defined networks (SDN), пришла очередь и storage (SDS). Видимо, дальше у нас будет software defined computing или ещё что-то подобное, потом резко всполошатся и подтянутся HP/VMWare и предложат (private) «software defined enterprise», который будет означать всё тоже, что было, но ещё моднее и актуальнее.

Впрочем, рассказ не про баззворды. За каждым таким странным названием (grid, elastic, cloud) стоит дальнейшее развитие технологий — построение дальнейших слоёв взаимодействия компонент (эм… взаимодействия участников взаимодействия, иначе не скажешь), основным мотивом которых является уход от гранулированности компьютерной системы, так, чтобы вся терминология, вся предметная область ушла от «межпроцессного взаимодействия» и стала автономной. В более-менее приличном виде мы это (в виде уже свершившегося факта) мы видим в волшебном мире javascript работе www, когда нас никаким образом не волнуют сервера, на которых крутятся задачи — всё общение происходит на уровне между браузером (с учётом его интимных подробностей DOM, JS и т.д.) и абстракцией, под названием URI, которой не важно — один это сервер или сотни разных.

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

Перед рассказом про SDS, посмотрим на уже состоявшееся: SDN (software defined network).
Читать дальше →
Total votes 61: ↑49 and ↓12 +37
Comments 96

Information

Rating
Does not participate
Registered
Activity