Дано: полное отсутствие интернета и виднеющийся WiFi hot-spot, в котором предлагают ввести логин-пароль. Или 3G, в котором нет интернета (потому что закончились деньги), но есть страничка провайдера с предложением дать оных денег.
Задача: получить интернет (легальным?) методом посредством туннелирования его через DNS.
Решение: linux+ iodine + routing + NAT + squid, и всё это под управлением network manager'а.
В статье: описание организации DNS туннеля посредсредством программы iodine, нюансы организации маршрутизации через образовавшийся туннель, самописный помощник для iodine и network manager.

Лирика: Занесла меня судьба на славный остров Кипр, кой славен своим П/пафосом, фраппэ и таким интернетом, после которого российские опсосы начинают выглядеть ангелами во плоти. В частности, попытка подключиться к интернетам закончилась ожиданием, что местный провайдер (Сyta) смилостивится, таки закончит пить оный фраппэ и дотянет до меня поганый ADSL 4Мб/768кбит всего-навсего за €151 (подключение) + €40 в месяц (за 4 мегабита! >_<). Ожидание тянулось и тянулось (как бы уже третья неделя пошла), а рядом был славный PrimeTel, который предлагал за €4/час (172р/час) осчастливить меня интернетом прямо тут и сейчас через едва видный WiFi. Я бы даже и согласился, но видна точка доступа была только на балконе, а в квартире связь была нестабильной и часто терялась. Так что оставалось одно решение (помимо взлома WEP-сети соседей, что уж совсем уголовщина) — это злоупотребить сервисом DNS, который безвозмездно, то есть даром, предоставляет PrimeTel для своих незарегистрировавшихся подлюченцев.

Те, кому интересно «howto» — решение далее по тексту, а пока что начнём с теории процесса.

Abstract: Рассказ про некоторые возможности IPv6 на примере конфигурации сложной домашней IPv6-сети. Включает в себя описания мультикаста, подробности настройки и отладки router advertisement, stateless DHCP и т.д. Описано для linux-системы. Помимо самой конфигурации мы внимательно обсудим некоторые понятия IPv6 в теоретическом плане, а так же некоторые приёмы при работе с IPv6.

Зачем IPv6?

Вполне понятный вопрос: почему я ношусь с IPv6 сейчас, когда от него сейчас нет практически никакой пользы?

Сейчас с IPv6 можно возиться совершенно безопасно, без каких-либо негативных последствий. Можно мирно разбираться в граблях и особенностях, иметь его неработающим месяцами и nobody cares. Я не планирую в свои старшие годы становиться зашоренным коболистом-консерватором, который всю жизнь писал кобол и больше ничего, и все новинки для него «чушь и ерунда». А вот мой досточтимый воображаемый конкурент, когда IPv6 станет продакт-реальностью, будет либо мне не конкурентом, либо мучительно и в состоянии дистресса разбираться с DAD, RA, temporary dynamic addresses и прочими странными вещами, которым посвящено 30+ RFC. А что IPv6 станет основным протоколом ещё при моей жизни — это очевидно, так как альтернатив нет (даже если бы они были, их внедрение — это количество усилий бОльшее, чем завершение внедрения IPv6, то есть любая альтернатива всегда будет отставать). И что адреса таки заканчиваются видно, по тому, как процесс управления ими перешёл во вторую стадию — стадию вторичного рынка. Когда свободные резервы спекуляций и хомячаяния адресов закончится, начнётся этап суровой консолидации — то есть выкидывание всего неважного с адресов, перенос всех «на один адрес» и т.д. Примерно в это время IPv6 начнёт использоваться для реальной работы.

Впрочем, рассказ не про будущее IPv6, а про практику работы с ним. В Санкт-Петербурге есть такой провайдер — Tierа. И я их домашний пользователь. Это один из немногих провайдеров, или, может быть, единственный в городе, кто предоставляет IPv6 домашним пользователям. Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального (то есть в четыре миллиарда раз больше адресов, чем всего IPv4 адресов быть может — и всё это в одни руки). Я попробую не просто описать «как настроить IPv6», но разобрать базовые понятия протокола на практических примерах с теоретическими вставками.

Структура сети:

(Оригиналы картинок: github.com/amarao/dia_schemes)

• 1, 2, 3 — устройства в локальной сети, работают по WiFi
• 4 — WiFi-роутер, принужденный к работе в роле access point (bridge), то есть коммутатора между WiFi и LAN
• 5 — eth3 сетевой интерфейс, который раздаёт интернет в локальной сети
• 6 — мой домашний компьютер (основной) — desunote.ru, который раздачей интернета и занимается, то есть работает маршрутизатором
• 7 — eth2, интерфейс подключения к сети Tiera

Если у статьи в Википедии есть версии на других языках, то этот список показывается в боковом меню (интервики-ссылки). Имя языка в этом списке записывается на самом этом языке (в англоязычной литературе используется термин «autonym»).

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

Первоначально эта проблема решалась с помощью системных шрифтов, доступных на устройстве читателя. Если шрифта не было, пользователь вместо названия языка видел набор квадратиков (▯▯▯▯▯▯▯▯▯, ▯▯▯ — ▯▯▯▯▯ ▯ ▯▯▯▯▯ ▯▯▯▯▯▯▯▯). Такие квадратики часто называют «тофу». Для решения этой проблемы (не только для списка языков, но и для показа в самих статьях) было создано расширение MediaWiki Universal Language Selector (ULS), которое предоставляло набор шрифтов для показа всех языков, использующихся на странице.

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

Краткий список того, что нужно контролировать на хосте виртуализации под управлением Xen'а. На полноценное «почитать» не тянет, но тем, кто с Зеном работает, будет полезно. Дополнения и уточнения приветствуются.

В заметке идёт о мониторинге именно хоста, а не запущенных на нём виртуальных машин или их сервисов.

Итак, начнём с простого:

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

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

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

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

Начнём с потребительских свойств.

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

Наше ядро — это адаптированное под debian/ubuntu/arch-linux ядро из OpenSUSE, в настоящий момент это 3.7-xen.



За счёт организации автоматической пересборки и публикации и тестирования, ядро обновляется вслед за обновлениями в OpenSUSE, в том числе переход на более новые версии. Для selectel-testing это будет происходить всегда автоматически (то есть выйдет новая OpenSUSE с новым ядром, автоматически обновится номер версии и тут), для selectel-stable (то, что потом будет у всех клиентов и что мы анонсируем отдельно) переход между мажорами будет проверяться вручную, минорные исправления (security fixes, исправление критических ошибок) будет публиковаться автоматически.

Кого это касается? Пользователей Debian, Ubuntu, Arch Linux. У пользователей CentOS используется штатное ядро, у пользователей OpenSUSE это ядро в комплекте «из коробки».

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

Новость: Магистральный провайдер RETN, не смотря на то, что он магистральный, осуществляет фильтрацию трафика посредством DPI. Поскольку оператор он магистральный, и, в частности, занимается доставкой зарубежного трафика, то на выходе мы имеем цензуру для многих провайдеров, в том числе и тех, кто чхать хотел на всякие «запретные списки», но имеют RETN в аплинках.

DPI — совокупное название технологий, при которых оборудование «залезает» во внутрь трафика, то есть реагирует не только на заголовки пакетов разного уровня, но и на содержимое.

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

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

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

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

Abstract: Рассказ про устройство Интернета, как «сети сетей» в виде текста для чтения, без двоичной системы счисления и нюансов BGP. Большая часть расказа будет не про процесс общения ноутбука с точкой доступа, а о том, что происходит после того, как данные пройдут «шлюз по умолчанию». Предупреждаю, букв много.

Вступление

Маленький провокативный вброс: ни один из читателей этой статьи к Интернету не подключен. Все подключены к сети своего провайдера, и не более. Подключение к Интернету дорогое, его сложно делать, вам потребуется очень крутое оборудование, несколько договоров с несколькими операторами связи и квалифицированные сотрудники. Простому домашнему пользователю это никак и никогда не светит. Не говоря уже о том, что в Интернете может быть не больше 4 миллиардов подключившихся (а до недавнего времени было даже «не более 65536») [1]. Даже если весь Интернет перейдёт на ipv6, это число не поменяется.

Вот число подключившихся к Интернету [2]:

По оси Y — число в штуках. Штуках, штуках. И вас в этом числе не посчитали.

Почему?

Дело в том, что Internet — это, если переводить буквально, «межсетье». Сеть Сетей. И участниками Интернета являются не пользователи (их компьютеры, планшеты, микроволновки с wifi и т.д.), а сети. Сети и только сети участвуют в работе Интернета. Интернет — это то, что связывает разные сети между друг другом.

Начнём с источников:

• Проект развития мультисервисных сетей в России на ближайшие годы, усилиями Минкомсвязи: minsvyaz.ru/ru/discussions/index.php?id=41
• Разбор и обсуждение оного с эвфимизмами в отношении существующих телекомов: www.kipchatov.ru/blog/?p=1151 (очень рекомендуется к прочтению)

Для скучающего читателя выписываю самую жаренную часть.

По планам минкомсвязи ожидается изменение провайдерского рынка — все операторы делятся на «федеральных операторов связи» и плебейских просто операторов связи.

При этом:

«просто операторам связи» запрещается трансграничная передача данных. Этим должны, будут и могут заниматься только федеральные операторы связи.

Самим федеральным операторам связи ставится в обязательство присутствовать на всей территории страны, причём год от года требования по присутствию увеличиваются — к 2014 это города с 100к населения, а к 2018 — с 8к (да-да, в каждый заполярный город оптику). Таким образом стать ФОС сможет только Очень Очень Очень толстый оператор. И у него будет монополия на иностранный трафик.

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

Abstract: использование cgroups для ограничения прожорливости компилятора по процессору и диску.

Лирика

Дано:
программист 1шт,
ноутбук с ноутбучным диском на 5200 rpm — 1шт,
исходных файлов на хаскеле 300 шт
Файлы coffee-script (будущий JS) — 300 шт
время компиляции — 40 минут.

Задача: компилировать в бэкграунде не ставя всю систему в состояние «ад и погибель». Можно даже ценой увеличения времени сборки до 50-60 минут.

Решение?

cgroups

Краткий пересказ статьи с Wired (извините, на перевод силы духа не хватило):

Google, в нарушение правил о нейтральности сети, которые он отстаивал несколько лет назад, для своего «Google Fiber» (1Гб/с по оптике каждому домохозяйству), настаивает на соблюдении следующих правил пользования сетью:

• Запрещается использовать предоставляемый интернет для запуска любых серверов (ssh, rdp на домашнюю машину, веб-камеру смотреть за дитём и т.д.);
• Запрещается использовать p2p (торренты, btsync, etc);
• Запрещается раздавать интернет кому-либо кроме своего домохозяйства и небольшого числа гостей;
• Запрещается осуществление любых коммерческих сервисов с использованием Интернета.

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

Вот аргументы, которые прозвучали:

• Если что-то пойдёт не так, что в будни сотрудники компании-клиента будут на рабочем месте и суммарный даунтайм будет меньше.
• Даунтайм в выходные для сервисов, ориентированных на 5-дневную рабочую неделю предпочтительнее, так как больше времени на восстановление
• Ночью в выходные активность пользователей сайтов выше, чем на буднях
• Работы, проводимые ночью в выходные заставляют отвлекаться сотрудников компании-клиента в их выходные дни

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

Голосовать можно тут, а можно на vk.com: vk.com/selectelgroup?w=wall-11462611_1147

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

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

Однако, это вызывает вполне понятные опасения. А что это они (а служба поддержки круглосуточная, то есть «они» — это не два и не пять человек) на консоль моего сервера смотрят без спросу? А если у меня там пароль или какая другая информация, которую я не хочу разглашать?

Оригинал в корпоративном блоге Селектела

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

В таких ситуациях лучше всего работают технические средства.

Думаю, эта картинка объяснит больше, чем все последующие слова:

Краткое содержание:

• Новости облака Селектел:
  
  1. IPv6 во всех шаблонах включен по умолчанию. Все новые машины устанавливаются с настройками IPv6 и сразу после установки доступны по своему IPv6 адресу.
  2. В списке шаблонов доступна openSUSE 12.3 с ядром Linux 3.7-xen
• Рассказ про практические проблемы, с которыми мы столкнулись при эксплуатации IPv6.

С openSUSE всё понятно, так что обсудим последствия IPv6.



Оригинал статьи в корпоративном блоге Селектел.

IPv6 для облачных серверов

Для всех виртуальных машин в пулах Санкт-Петербург (1) и Санкт-Петербург (2) при установке новых виртуальных машин и переустановке существующих поддержка IPv6 включается по умолчанию (и является предпочтительным протоколом для исходящих соединений). IPv4, разумеется, остаётся и работает. Раньше мы IPv6 выдавали, но по умолчанию не включали.

Зачем это нужно? Честно сказать, сейчас львиная доля Интернета работает на ipv4. Отдельные островки живого IPv6 есть в Азии, плюс несколько крупных сайтов (таких, как google.com, vk.com, facebook.com) отвечают по IPv6. Домашние пользователи в России практически все работают только по IPv4.
Вот более-менее актуальная информация о том, у кого из провайдеров России есть IPv6: version6.ru/isp

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

Что означает появление IPv6 с практической точки зрения для конкретно взятого облачного сервера?

Рассказываю забавную идею, которая была сформулирована у нас сегодня на работе.

Представим себе бота, который занимается майнингом биткоинов, предоставляет какие-то простенькие услуги через WWW (например, генерирует псевдоосмысленный текст за очень малые деньги на бирже копирайтеров).

И пусть этот бот имеет простую программу:
1) Часть выручки переводить на свой лицевой счёт (аккаунт, с которого этот бот запущен в облаке)
2) Как только наберётся достаточно средств, посредством антиге*а и списка известных облачных провайдеров регистрировать новый аккаунт и запускать там свою копию.

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

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

В рамках концепции «on demand self-service», которая более-менее общепринята для облаков, это всё, что нужно для саморазмножающейся конструкции.

Новость одной строкой: Для MoD появился новый параметр, позволяющий более точно контролировать поведение сервера при включении. Называется он start_memory.

Когда облачный сервер закончил загрузку и технология Memory on Demand включена, то память регулируется в зависимости от объёма занятой памяти. Однако, эта технология завязана на агент, работающий внутри виртуальной машины, который отсылает информацию о текущем использовании памяти mod-серверу (за пределами виртуальной машины). Таким образом, отреагировать на нехватку оперативной памяти система сможет только после запуска mod-агента (он стартует вместе с остальными сервисами при загрузке облачного сервера). В некоторых же случаях есть необходимость сразу начинать с «высокого старта», то есть с самого начала выделять значительный объём памяти.

По умолчанию это значение выставляется в значение static_min, то есть в минимальный объём. Теперь это значение можно менять в явном виде.

Можно выделить три стратегии использования:

Новость одним абзацем: rescue initrd (специальный комплект из ядра и initrd) теперь автоматически конфигурируется на ipv4/ipv6 адреса, назначенные облачному серверу и автоматически же запускает ssh-сервер после загрузки.

Как это устроено?

Обычно загрузка виртуальной машины выглядит так: с загрузочного диска виртуальной машины (с его загрузочного раздела) читается grub.cfg/grub.lst, из него выбирается ядро и initrd. Domain builder (специальное приложение, которое создаёт домен при старте виртуальной машины, кладёт туда ядро/initrd, фомирует start page с настройками и добавляет памяти) это ядро загружает и запускает домен.

Дальше ядро уже загружается как в обычном сервере — запускается скрипт инициализации в initrd, который подготавливает корневую файловую систему, делает туда pivot_root (переключение корневого каталога) и запускается уже настоящий init, который читает inittab, запускает систему инициализации system-v или upstart, systemd, кому уж что больше нравится.

С некоторыми задержками, но мы запускаем новый пул на новых процессорах. Старые процессоры Xeon L5520, новые — Xeon E5-2630.


Вот мнение Intel о том, как различаются процессоры: http://ark.intel.com/compare/64593,40201
Ключевые позиции:

• Удвоение размера кеша
• Полуторакратный рост числа операций с системной шиной в секунду
• Поддержка дополнительных инструкций процессора AVX
• 68% рост скорости работы оперативной памяти

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

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

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

Итак, три самые ненавистные вещи для пользователей: изменения, неожиданности, разрыв контекста.

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

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

Изменения

Компьютеры позволяют менять интерфейс (напоминаю, речь про интерфейс для решения задачи) очень быстро и легко. Появление новых функций ставит программиста/разработчика интерфейса/etc перед проблемой логического переупорядочивания элементов. Например, было три функции в top level, теперь их стало семь, давайте разделим их на две логические группы (3 и 4) — всё ок, никакого хаоса.
С точки зрения пользователя: раньше было три логические функции, теперь они куда-то исчезли, на их месте появились два меню, причём одно действие в первом меню, а оставшиеся два во втором. Ад, ужас, погибель, проклятье программисту.

Новость одной строкой: мы реализовали возможность установки облачного сервера с автоматическим добавлением root в authorized_keys указанного при установке публичного ssh-ключа.



Минимальный метод использования — выбрать ключ при установке/переустановке:

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