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

Подписался…

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

Итак, краткий хитпарад рассылок от них:

«Нам нужна ваша поддержка!» (30.12.2011) — в поддержку Прохорова как конь дидата на должность Путина.
«Чемпионат России по ралли-рейдам» (22.02.12)
«Анонс показа 1ого этапа Чемпионата...» (30.03.12)
«Анонс показа 1ого этапа Чемпионата...» (01.04.12)
«Анонс показа 1ого этапа Чемпионата...» (02.04.12)

abstract: Этот пост описывает организацию системного диска на машинах в облаке и объясняет, почему именно так.

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

Мотивация

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

Вот проблемы, которые возникают в связи с этим:

• Возможность изменить размер диска и корневой файловой системы
• Возможность создать дополнительные разделы
• Возможность подключить диски от одной машине к другой
• С этого диска надо ещё и загрузиться

Наиболее примитивным решением является

Оглавление:

• Обновление консоли
• CentOS 5.8
• Исправление ошибки с подключением дисков

Консоль

После того, как мы запустили консоль прошёл почти год. За этот год хром обновился, сменил версию websockets. И консоль осталась рабочей только в Firefox и Opera, обидев заодно и пользователей Mac, у которых основным браузером является Safari (внутри Safari тот же «движок», что и в Хроме — WebKit). Плюс, консоль была не особо быстрой.

Пришло время исправить эту проблему. Компонент под названием selecon-web (это не безграмотность, это сокращение от Selectel Console) был переписан на haskell, в результате чего у нас значительно снизилось потребление процессора, а у пользователей улучшилась скорость работы консоли. Заметим, скорость фактического вывода осталась прежней (т.к. консоль это всё-таки последовательный порт, скорость вывода у него фиксированная, но ускорилось время открытия консоли и время, за которое буква с порта виртуальной машины оказывалась в браузере у клиента).

Некоторое время назад github разослал следующее письмо (привожу в выборочном цитировании):

A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts.

While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys.

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

Ну дырка и дырка. Я для себя отметил, что нужно проверить, и забыл. Сейчас делал git push и обнаружил вот такое сообщение:

ERROR: Hi amarao, it's GitHub. We're doing an SSH key audit.
Please visit github.com/settings/ssh/audit/xxxxxx
to approve this key so we know it's safe.
Fingerprint: f7:aa:27:bb:97:cc:6d:dd:32:51:ee:26:8d:ff:ac:f9
fatal: The remote end hung up unexpectedly

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

Summary: Пост рассказывает о том, что такое снапшоты в облаке, как их использовать, и как они устроены.

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

Хочу предупредить, что статья будет очень сложная. Я сначала расскажу про простые вещи — как с этим работать и какая от этого польза, а потом расскажу как это устроено внутри. И если с удобством и понятностью на «пользовательском» уровне мы, я надеюсь, справились, то вот с описанием устройства… Так сказать, мужайтесь или пропускайте.

Как использовать снапшоты?

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

Снапшот может быть выполнен в любой момент времени, на включенной или выключенной машине. В момент выполнения снапшотов дисковая активность машины слегка приостанавливается (речь идёт о чём-то порядка секунды), после чего продолжается «как ни в чём ни бывало».

Новость одной строкой:

Облако запустили

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

Ключевые изменения:

• Новая кластерная СХД
• Обновлённые шаблоны виртуальных машин на LVM, упрощающие изменение размеров диска
• Снапшоты
• Улучшенная производительность панели управления

ДЦ Берзарина — наш единственный дата-центр в Москве. Организован он аналогично остальным нашим дата-центрам — холодный коридор, откуда оборудование забирает холодный воздух, неконтролируемое по температуре пространство вокруг (горячий коридор), откуда кондиционеры забирают воздух для охлаждения (осушения чистки и т.д. — всё это и есть «кондиционирование») и выпускают обратно в холодный.


(альтернативная ссылка)

Состоит из одной очень длинной серверной, внутри которой находится длинный холодный коридор (2x40 шкафов). Этим он несколько отличается от устройства остальных ДЦ, где коридоров несколько.



На фотографии видно, как мы экономим тепло холод.

Продолжаем цикл экскурсий по Селектелу. На этот раз — дата-центр «Цветочная». Там же находятся наши офисные помещения (то есть мы).

Начнём с видео экскурсии (обратите внимание на кнопку HD сверху):

(альтернативная ссылка)

Серверная

Серверная на Цветочной имеет очень высокий потолок. Благодаря этому там находится довольно значительный объём прохладного воздуха. Наш НЗ, так сказать.

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



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

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

В этом цикле статей мы покажем как выглядят наши ДЦ.

Итак, старейший дата-центр Селектела (с которого компания, собственно, и началась), под кодовым названием »Технодом".

Видео

Небольшая видео-экскурсия:

Серверная

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

(картинки кликабельны)


Традиционно, основным форматом, использующимся для размещения серверов, являются 19" (19 дюймов), их высота измеряется в юнитах (вершках, хе-хе). Сервера плотно монтируются один над другим в специальные шкафы с вертикальными направляющими. Шкафы иногда ещё называют «стойкой». В «Технодоме» используются шкафы 42 U размером (внутренние направляющие имеют высоту 42 юнита, плюс чуть-чуть снизу, плюс чуть-чуть сверху, плюс чуть-чуть с боков на стенки и место для кабелей — то есть фактический размер шкафа больше, чем 1.8 метра в высоту и 48 сантиметров в длину). Реальная полезная нагрузка шкафа несколько меньше, так как туда ещё монтируются розетки (тоже 19"). Размеры самого шкафа: высота 2030, ширина 600 мм. Глубина шкафов разная — на выбор 620, 820 и 1020мм.

(под катом — ещё фотографии серверной, оборудования и людей)

Вступление: Ключевым элементом всех тулстеков для Xen является xenstore — сервис, позволяющий иметь «общую БД» для всех доменов на хосте. Давным-давно существует библиотека libxs для доступа к ней из приложений на Си. К ней есть биндинг на питоне (xen.lowlevel.xs), однако, у него есть очень серьёзные проблемы с многопоточной подпиской на события. Нас это не устраивало и для работы нашего сервиса memory on demand была написана библиотека pyxs, которая позволяет иметь очень комфортную работу с xenstore, многопоточные подписки и т.д.

По здравому размышлению было принято решение отдать её людям под LGPL-лицензией.

Примеры использования

Простое чтение и запись:

from pyxs import Client

xs=Client():
xs["/foobar/a"] = "baz"
print xs["/foobar/a"]

Второй важный класс — это Monitor для организации подписки на множественные изменения, ради которого всё писалось:

from pyxs import Monitor

xs=Monitor():
xs.watch("/local/domain/1")
xs.watch("/local/domain/2")
while true:
    print xs.wait()

Нас разбудит каждый раз, когда что-то поменяется в первом ИЛИ втором пути.

Сссылка на гитхабе: github.com/selectel/pyxs
Документация: pyxs.readthedocs.org

Не могу считать телефон «своим», пока у меня нет к нему рутового доступа. Без рута телефон не «мой», а «взятый в аренду» у дяди. С оответствующими правами у дяди и их отсутствием их у меня.

Итак, инструкция по получению рута на N9. Заметим, не jailbreak, т.к. эта возможность присутствует официально. Спасибо Nokia.

Теория

Рут доступен только через ssh-сервер, который появляется после установки developer tools. Слушает он на localhost и серых адресах. После получения рута настоятельно рекомендуется сменить пароль, дабы не получить неприятный сюрприз.

После этого мы чуть-чуть облегчим себе жизнь с помощью alias у встроенного шелла.

Практика

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

После ребута идём в шелл (в самом конце списка приложений появится иконка чёрная с зелёной надписью).

С первого числа мы закрываем возможность установки новых машин. Новых клиентов мы уже прекратили принимать.

Существующие виртуальные машины существующих клиентов будут обслуживаться далее без изменений. Так же просьба не делать «машины про запас» — мы прекратили приём новых клиентов не от добрых обстоятельств.

Причина — мы перешли границы рассчитанных мощностей, а переписывание архитектуры «на ходу» — ужасная практика. В связи с этим решено взять таймаут и перестать гнаться за отделом рекламы (кстати, по этой причине мы и замолкли на Хабре — надеялись чуть снизить поток приходящих). Однако, люди приходили — и доходило до смешного, в одной из долго и тщательно выписываемых компонент мы закладывались на потолок в приблизительно 10к коннектов. Тестирование/исправление (процесс preproduction) затянулся на месяц… И к моменту, когда мы выкатили эту компоненту, оказалось, что она уже «в притык» (6-9к коннектов в секунду). А ведь писали мы её несколько месяцев!

И стало очевидно, что мы просто не справляемся. Решение о прекращении приёма новых клиентов далось не сильно легко (ну вы понимаете, споры в стиле «а с чего вам зарплату платить?» и т.д.), но здравый технический смысл победил здоровую жадн устремлённость к успеху компании.

Сколько займёт переработка? Планируемый срок — около 2-3 месяцев, сколько реально потребуется — не знаю. Во-первых, потому что придётся серьёзно переделывать архитектуру, централизованные БД окончательно будут удалены; децентрализация всего и вся — задача крайне нетривиальная.

Только что пришла рассылка от winehq.org, их база данных логинов и паролей (точнее, хэшей паролей) была похищена. Особо неприятно то, что в качестве логина там использовался емейл.

Пострадали базы appdb (база совместимости с приложениями windows) и багзиллы (багтрекера). Пользователям уже высланы новые пароли.

Взлом произошёл через phpmyadmin, но пока не известно, была ли это уязвимость в phpmyadmin или использовался украденный пароль администратора.

Подробности: www.winehq.org/pipermail/wine-users/2011-October/097753.html

trivia: REST и виртуальные машины не совместимы.

Есть давний спор, в котором я участвовал несколько раз, и который пока висит не решённым. Выношу сюда существующую аргументацию, с интересом выслушаю комментарии и дополнительные аргументы.

Итак,
тезис 1: REST хорошо, *-RPC (например, XML-RPC, JSON-RPC) — плохо.
тезис 2: Т.к. REST хорошо, его нужно использовать для управления виртуальными машинами (в частности, в облаке).

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

PUT .../vm333/disk1/bootable
enable=true
PUT .../vm333/disk1/bootable
enable=false

Или даже так:

POST /vm/333/disk1/bootable
DELETE /vm333/disk1/bootable

Если мы хотим создать диск, мы говорим POST /vm333/disk2 и передаём атрибуты (вроде размера или хранилища).

Однако, это хорошо только до того момента, пока наша инфраструктура напоминает записи в БД.

А теперь простой вопрос: как в REST будет выглядеть команда перезагрузки виртуальной машины? Ведь состояние машины не меняется, как была running, так и остаётся. Очевидно, что перезагрузка не идемпотентный вызов, то есть мы должны говорить POST. Но 'POST что и куда?'. Заметим, даже shutdown/start вполне себе укладываются в POST power-state'а. Но вот ребут — который нарушает логику «имманентности» состояния объекта в БД и приводит нас в жестокий императивный мир — увы, не укладываются. Аналогичные проблемы будут при операции 'install' (запуск установки OS).
Причина тут куда более глубокая, чем просто «не очень хорошо получается». Извините за слово «онтология», но эта причина — онтологическая.

Суть проблемы

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

Не существует объективных методов оценки безопасности информационной системы. Все существующие методы могут говорить либо об опасности (так нельзя, это нельзя, тут дыра), либо говорить о соответствии системы каким-то требованиям какого-либо сертифицирующего органа… И вот тут, внимание, следите за руками, соответствие этим требованиям называют критериями безопасности. Мол, прошла сертификацию на SFOD-12, значит безопасна. Главное — иметь бумажку. А авторам этой бумажки — надуться посолиднее, чтобы авторитетом доказать, что безопаснее некуда.

Причина — в неконструктивном смысле слова «безопасность». Что такое «безопасная система»? Это система, у которой нет части функционала (например, которая НЕ даёт доступа к информации, или которая НЕ предоставляет какую-то функцию). Таким образом, безопасная система, это система, в которой КРОМЕ описанного в ТЗ нет НИКАКОГО ДРУГОГО функционала.

Если перевести на язык математики, то мы берём конечное множество функций (техническое задание), высчитываем его дополнение. Дополнение до чего? Во, вот это и есть главный вопрос, который не описывает современная информационная безопасность. Дополнение до множества, которое нам не известно, которое бесконечное (или если и конечное, то за пределами обозримой для нас границы). Мы описываем в этом бесконечном множестве отдельные типы атак, дурных конфигураций, ошибок проектирования и т.д., но это всё равно, что перечислять отрезки на множестве вещественных чисел.

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

В связи с недавним инцидентом со взломом kernel.org (подробнее) и долгими разбирательствами в этом, Линус в почтовой рассылке LKML анонсировал временный перенос репозитория разработывающейся версии ядра (в данный момент 3.1-rc5) на github: github.com/torvalds/linux

Мы обещали — мы делаем. Видео с training course, которое проходило в Санкт-Петербурге в конце июля 2011 года.

Условия от NCC: курс предназначен только для LIR, таким образом, если вы не являетесь сотрудником организации, имеющей статус Local Internet Registry, то вы не имеете права просматривать это видео.

Когда серверов мало — они очень личные. Это ТОТ сервер. А это совсем другой сервер. Подобное отношение может быть только к уникальным серверам со специфичной конфигурацией и ролю (ролями). В условиях массового использования серверов никакой личной составляющей выделить не получается, потому что если у серверов одинаковая конфигурация, то различать их очень сложно. Особо это заметно в условиях кластеров, СХД, access-level коммутаторов и хостов виртуализации.

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

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

Часто задаваемый вопрос. Большинство сайтов вешают счётчики, работающие по непонятным алгоритмам.

Однако, есть вполне достоверный метод посчитать нужное значение. Традиционно, нас не интересуют ip-адреса в США или Азии, т.к. они всё равно не будут доступны для Европы.

Есть специальные файлы статистики ripe в расширенном формате (включая как занятые, так и свободные адреса): albatross.ripe.net/delegated-extended

Дальше из этих данных простым скриптом легко считается нужное:

wget ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest  -O ripe.txt
b=0
for a in `grep avail ripe.txt |grep ipv4|cut -f 5 -d '|'`;
do 
b=$(($b+$a))
done
echo $b

Осталось 58932064 нераспределённых ipv4-адресов

по состоянию на 08.08.2011.