Nuclear Lightning's Track

Пока на больничном, есть свободное время, решил записать воспоминания про олимпиаду для Linux-администраторов — а то уже не всё помню. В этом году её честно назвали олимпиадой для Linux-администраторов, и я, будучи фряшником, хотя сомневался, всё-таки пошел попробовать. Попробовал очень даже неплохо :) Причем, что любопытно, очень даже неплохо из BSD-админов "попробовал" не только я: если во 2-й тур прошло 5 человек из 36 с канала #freebsd (shattered, dmn42, Jay, imax и ваш покорный слуга) — то в финал пробралось четверо из них. Четверо из десяти. По-моему, эти 40% на чисто линуксовой олимпиаде вполне подтверждают тезис о том, что BSDшники профессиональнее =) Причем дело не в том, что эти люди просто "случайно" оказались универсалами, знающими несколько платформ (и случайно завсегдатаями канала #freebsd). Они, как и я, еще и предпочитают эту систему, а лично я — так и вообще имел не так много опыта с другими системами. Мой опыт общения с линуксами в основном ограничивается SLES на вычислительном кластере родного политеха. И сусю эту предписывалось трогать как можно меньше (суппорт, мол, есть), и был этот кластер толком никому не нужен — увы, провинциальные реалии... так что мы большую часть времени занимались если не виндой и суппортом не умеющих писать на Си юзеров, то, кхм, саморазвитием (и отнюдь не по линуксовой части).

Но обо всём по порядку. Первые игры олимпиады — вопросы по теории, но это лишь отсев, а не что-то, способное действительно показать профессионалов в отрасли. Определяет практика, и первая практика на олимпиаде началась во втором туре. 25 октября нужно было починить, кроме мелочей, LDAP, Джумлу и Друпал (да, мне тоже было смешно), в виртуалках, доступ в которые был сделан через веб — типа консоль tmux. Видимо, специально затем, чтобы больше времени потратили — все ж к screen привыкли. Эта игра глючила и глючила, и довольно быстро вообще прекратилась, поскольку кто-то нашел дырку в реализации организаторами доступа к tmux через web — и пробрался из виртуалку и хост-машину, где еще и ответы лежали. Так что игру отменили, и я уже даже не помню, что там было.

Повторная игра 2-го тура была 27 октября, вот там уже был человеческий VNC. Правда, интерфейс "старт/стоп виртуальной машины" был сделан на вебе неудобно, впрочем, то мелочи (хотя у некоторых они вызвали большие нарекания). Итак, "физическая" консоль виртуалки по VNC, в виртуалке — Убунта. Тщательно сломанная (вообще это уровень уже даже не финала, а суперфинала прошлого года), настолько, что паникует при загрузке. И надо её починить — мониторинг снаружи проверяет сервисы этой машины, которые должны работать (ессно, пока на ней нет поднятой сети, всё горит красным). Сделать надо всё за 1 час, чем больше и раньше других сделано — тем выше место в таблице участников.

Вот тут начинается самое интересное. Я эту Ubuntu, как и вообще современный Линукс, видел вживую впервые в жизни. Камрад Jay описал чуть спустя то, что на этой игре было по заданиям. А у меня было интересное психологическое состояние, и многие из обсуждавшихся вещей меня удивили — я их не заметил, хотя и решил. Наверное, ближе всего будет описать это состояние, как "танк, рвущийся на прорыв через препятствия". Воля к победе, боевой дух, решимость, как её там еще?.. Короче, время пошло, взлетаем.
( Под катом не без сисек )
Что можно сказать по итогу — в отличие от прошлого года, по этой олимпиаде уже вполне можно судить о положении дел в отрасли, её результаты показывают уже что-то реальное — всё стало гораздо ближе к практике. На прошлой было три теоретических теста (1 тур, 2 тур, финал), пусть и разных по форме, и лишь одна игра с практикой — суперфинал. В этой — только первый тур с отсевом по теории, но вот все 3 практики были однообразные — "починить упавший сервер за 1 час".

Поскольку победителям прошлых лет запрещено участвовать в следующих олимпиадах, могу свободно высказать предположения, как можно было бы её еще улучшить. Например, в финале можно было бы не чинить сервер, а настраивать что-то с нуля. А в суперфинале — оттюнить медленно работающий сервер (привет, хайлоад). Или, там, разобраться с тем, почему в боевых условиях не работает поделие криворукого программера (это классическое бодание админов и программеров, вошедшее в байки и мемы, бывает даже в самом Яндексе). Одна беда — это требует больше времени, а в программе финального дня еще экскурсия в ДЦ Яндекса, затягивающаяся по московским пробкам... Может быть, стоило бы объединить финал и суперфинал, чтоб уместилось, но, наверное, это будет противоречить правилам, которых хочет придерживаться Яндекс...

Получил я на днях вот такую критику своей статьи "Netgraph для пользователя", в IRC (разговор сокращен):

<A_Z> Следует помнить, что в этом формате как узлы, так и хуки netgraph являются узлами изображенного графа — просто узлы netgraph изображены как прямоугольники (подписаны имя, ID, тип), а хуки netgraph — как восьмиугольники, и ребра, соединяющие узел со своими хуками, более жирные. Так сделано для большей наглядности и выделенности хуков, а также потому, что при обычном рисовании графа не получилось бы у одного ребра написать два названия (ведь ребро netgraph состоит
<A_Z> если кто-то прочитает и переварит это с первого раза, тот герой.
<A_Z> если помнить, что масло на котором мы жарим картошку является подсолнечным маслом, то можно предположить, что картошка является жареной и это потому, что мы жарили картошку
<levsha> ну может ведь и салом оказаться!
<Miha> картошка может оказаться салом!
<A_Z> Если название вызвало у Вас ассоциации из наркоманской фени. Вы правильно подумали. Netgraph действительно представляет собой краб^Wгриб
<nuclight> A_Z: конструктивные предложения есть?
<A_Z> nuclight: рассказывать? я уже говорил а) стиль изложения a-la петросян б) сложное построение предложений в) множесто неудачных аналогий и варваризма г) есть сомнения, что это для пользователей
<nuclight> A_Z: конструктивная критика направлена на то, чтобы исправить/улучшить, для чего необходимо указывать на конкретные вещи, и способы их исправления. Из чего следует, что 2 строчки никак не могут быть конструктивной критикой — ты к каждому пункту не привел даже пяток примеров, из которых можно было бы проследить тенденцию твоих субъективных впечатлений.
<nuclight> A_Z: стиль изложения — в каком месте? почему не давно изветсный прием отдыха читателя среди горы информации, напрмер? Сложное построение предложений — где? примеры, как было бы построить лучше (я вообще-то следил и слишком сложные предложения не делал)? Множество неудачных и варваризма — какие именно? в чем их неудачность и варваризм для тебя? какие были бы лучше? Есть сомнения — в чем это выражается? где следовало разжевать еще?
<nuclight> A_Z: уже сам факт того, что я тебе должен встречные вопросы задавать говорит, что это не была конструктивная критика. Литературные критики во времена оные целые эссе писали, тебе же нужно было написать от силы килобайта два, а не сорок два, как мне.
<A_Z> nuclight: вот тебе мои два килобайта

И вот текст собственно рецензии (кладу тут для истории, чтоб не потерялся):

Рецензия без запятых.

После прочтения статьи Вадима Гончарова "Netgraph для пользователя" я окунулся
в мир грибов и дисктретной математики. ( Read more... )

Со времени событий вокруг uTP прошло более 4 месяцев, разработчики uTorrent на месте не стояли, в теме на nag.ru тоже накатали уже более сорока страниц. Придумал и я принципиально новый способ ловить соединения торрентов, но обо всём по порядку.( Рабочий скрипт с демонстрацией концепта прилагается )

Краткое содержание: как отфильтровать uTP на FreeBSD в теме на Наге уже сказали, однако для случая пакетов внутри туннеля PPTP GRE решения не было, о чем здесь и будет рассказано, но сначала - предыстория.

У вас вдруг стал хуже работать Интернет?..

В конце 2008 года разработчики uTorrent собрались заменить транспортный протокол с TCP на UDP, реализовав поверх него свою прослойку под названием чTP - дескать, так будет эффективнее. Тогда же исследователь по имени Ричард Беннет заявил, что это будет полная жопа для всего Интернета - UDP менее 2% во всём трафике, он используется для приложений реального времени (игры, телефония) и для критически важного DNS, в общем, пострадают все, из-за отсутствия в нём нормального congestion control (обработки перегрузок сети). Разработчики на это ответили, что они сделают congestion control еще лучше, чем в TCP, и торрент станет даже меньше забивать каналы и мешать другим, чем сейчас. И включили по умолчанию новый протокол uTP в бета-версиях uTorrent 1.8 (правда, сначала только на прием). Время шло, обещанной жопы всея Интернета не было...
До этого февраля. Буквально в понедельник админы бывшего СССР начали спрашивать друг друга, у всех ли отмечено сильное возрастание нагрузки за последние дни. Таки да, оказалось у многих. Выяснилось, что месяц назад вышел uTorrent 2.0, у кучи народа вылезло окошко с предложением обновиться, и с начала февраля пошел рост PPS (нагрузки по пакетам в секунду), причем обратите внимание, не трафика. Много где оборудование к такому неожиданному повороту сюжета было не готово, и проблемы работы Интернета ощутили на себе все, не только "качки". Более того, не только оборудование провайдеров - у многих стали гнать домашние роутеры и ADSL-модемы (вот пост на Хабре на тему), хотя опять же человек может не связать обновление у себя uTorrent и начать обвинять провайдера.
( Read more... )

===
В марте, помнится, я написал в ipfw@ предложения по архитектурным улучшениям ipfw, как кандидат на GSoC 2008. Никто не отреагировал (многабукаф, фигли). Дальше, в конце мая в RU.UNIX.BSD разгорелся спор - народ хотел изменения "как Cisco ACLs, но лучше", однако конкретики не было, хотя со временем что-то уже вырисовалось, я поглядел на идеи для будущего из перевода рассказа о Netgraph и набросал примерный вариант, как это могло бы выглядеть. И что же? Тут же дискуссия заглохла. Стало понятно, что выносить такие вещи на публику не имеет смысла - как только доходит до дела, любители почесать языком тут же исчезают. С другой стороны, каждый раз пересказывать сначала идеи тем индивидам, которые заинтересованы и могут сделать, долго, поэтому я решил расписать это и сделать доступным на вебе, чтоб не потерялось. А может, со временем и поможет найти тех, кто заинтересован и либо сможет сделать, либо обсудить изменения планов, исходя из практических потребностей.
( Много букв для kernel-девелоперов, мало кому более интересных )
===

Этот недописанный пост изначально неспешно готовился как памятка на будущее для узкого круга лиц о том, какие изменения в ipfw хотелось бы видеть и хотелось бы сделать. Однако идеей заинтересовались во FreeBSD Foundation и согласились спонсировать разработку этих идей - правда, всё никак не сделают официальный анонс (ну и я сильно подробно не публиковал пока поэтому). Организаторам RootConf 2009 предлагаемые идеи понравились тоже, посему официально сообщаю - я буду рассказывать об этом на оной конференции, проходящей в Москве 13-14 апреля сего года. На странице http://www.rootconf.ru/papers2009/12352.html доступны тезисы, там же, как обещают, будут позже выложены и презентация с видеозаписью доклада. Данный же пост, возможно, будет позднее дописан (или написан новый) с более подробной информацией о работе - ваши комментарии и пожелания по улучшению ipfw, впрочем, можете писать уже сейчас ;)

У меня, правда, есть еще одна проблема - негде остановиться в Москве в ночь с 12 на 15 апреля :) Никто не хочет впустить? :)

Есть у нас в сети общаги уже долгое время две подсети, с серыми и белыми адресами, при этом бегают по одной физике. Не очень кошерная конфигурация, конечно, ну да так вышло по историческим причинам (тяжелое детство, деревянные игрушки бедные студенты, провайдер-жмот). Суть в том, что хостам желательно бы видеть друг друга напрямую, а не нагружать роутер, который раздает им Интернет, так как у него те же 100 Мбит на вход, если роутить подсети, будут жаловаться, что скорость низкая. Значит, каждому юзеру надо прописать себе постоянный статический маршрут на другую подсеть, тогда будет ходить как положено, напрямую, в обход роутера.

И тут вступает в дело человеческий фактор. Как заставить их прописать? Они ж бестолковые. Желательно бы автоматизировать. Но тут напарываемся на свойства винды. ICMP-редиректы она не принимает (от роутера, который знает, что физическая-то подсеть та же), указание маршрута на интерфейс без указания шлюза (который должен быть адресом этой же машины) она не понимает... Маздай, одним словом. В DHCP есть опция статических маршрутов, но они в ней считаются поклассово - это тогда, как более 10 лет используется CIDR, то есть для нынешних условий неприменимо.

После поисков обнаружилась такая замечательная штука, как RFC 3442, описывающий DHCP-опцию раздачи classless-маршрутов, как раз то, что нужно, даже случай другой подсети на той же физике предусмотрен. Но - его не поддерживает не то что винда, а и другие DHCP-клиенты не всех версий... В результате на сайте сети была просто вывешена динамически генерируемая инструкция, выполнить строчку вида route -p add 172.18.46.0 mask 255.255.255.0 82.117.64.2, где адресом шлюза является адрес самой машины. Инструкцию выполняли, но, конечно, не все и не всегда. Например, забывали выполнить после переустановки винды. Или просто "ниасиливали". Нагрузка на роутер от непрописавших возросла, и на нем это дело было прикрыто файрволом, в надежде, что когда перестанет работать, таки соизволят наконец прочитать инструкцию (в которой увеличилось количество выделений большими буквами и жирным шрифтом). Но толку...

Затем, после дальнейших поисков, было обнаружено, что виндовый DHCP-клиент, начиная с XP, поддерживает приватную опцию за нумером 249, отвечающую ровно за это же и имеющую абсолютно тот же формат, что и опция с кодом 121 из RFC 3442 (зачем они сменили номер, непонятно). Ну, с тем лишь отличием, что RFC предписывает игнорировать опцию routers и указывать маршрут по умолчанию внутри этой нововведенной опции, а опция от MS задает дополнительные к routers маршруты. Итак, Гугль в конце концов подсказал страничку http://scott.yang.id.au/2003/04/getting-stuck-with-dhcpd/ с вот таким примером для конфига DHCP (в котором эта опция тоже не поддерживается, но можно описывать их свои любые, какие хочется):

# MS routes: adds extras to supplement routers option
option ms-classless-static-routes code 249 = array of integer 8;
# RFC3442 routes: overrides routers option
option rfc3442-classless-static-routes code 121 = array of integer 8;
option routers 172.22.0.1;
option ms-classless-static-routes 24, 172, 22, 99, 172, 22, 0, 1 ;
option rfc3442-classless-static-routes 24, 172, 22, 99, 172, 22, 0, 1, 0, 172, 22, 0, 1 ;

Всё бы нормально, но это маршрут, указывающий на сеть, находящуюся за настоящим маршрутизатором. Популярный случай, но у нас несколько другая ситуация, сеть-то должна быть доступна напрямую. RFC 3442 в этом случае говорит, что надо указать в качестве адреса шлюза 0.0.0.0, и клиент должен понять, что это маршрут на интерфейс. Пробуем указать option ms-classless-static-routes 24, 172, 18, 46, 0, 0, 0, 0; ...и наблюдаем, как винда радостно кладет на это большой и толстый болт. Ага, думаем мы, не лыком шиты, чай, винда тупая, просто применяет сеть, маску и шлюз как в команде route. То есть, если указать адрес шлюза, должно подействовать. Пробуем option ms-classless-static-routes 24, 172, 18, 46, 82, 117, 46, 2; - ага, сожрала!

Здесь самое время почесать репу - это, значит, придется для каждого клиента в dhcpd.conf описывать индивидуальную натсройку?! Ладно здесь, когда адреса описаны статически (привязка к MAC-адресу), потеряется только изящность указания адреса в единой точке (DNS) и избыточность конфига - а если у кого-то адреса раздаются динамически, что тогда?..

После загрузочной кружки чая с шоколадом в голову приходит мысль перечитать dhcp-eval(5). Вдумчивое укуривание им и dhcp-options(5) рожает идею генерировать эту опцию для каждого клиента на ходу из его адреса. Немного правки, и возникает конструкция:

option ms-classless-static-routes = concat (24, 82, 117, 64, leased-address);

На что нас посылает нахуй уже dhcpd. С невнятной синтаксической ошибкой 117 exceeds max (255) for precision. Рытье в исходниках и манах приводит к озарению: я дебил у dhcpd разная трактовка numeric-expressions и data-expressions. То бишь, надо преобразовать форматы его встроенными функциями. И в конечном счете получаем несколько громоздкую, но работающую конструкцию:

...
# Define option codes and types for later use in subnet declarations
option ms-classless-static-routes code 249 = array of integer 8;
option rfc3442-classless-static-routes code 121 = array of integer 8;
# Classless routing:
# RFC3442 provides way to store classless routes in option 121 with
# format of 1 byte masklen, 0 to 4 bytes of destination network (rounding
# up mask bits to next byte), and 4 bytes of router address, e.g.
# 128.93.40.0/17 -> 1.2.3.4 will be bytes 17 128 93 40 1 2 3 4;
# then any number of routes in the same format. MS routes (XP+)
# are using the same format, but option code 249. Also, RFC3442
# routes require including default route (masklen 0 then IP of router)
# which overrides routers option, and MS routes don't need to
# include default route, they still use routers option.
# When destination net is directly attached to client's interface,
# as in our case below, RFC3442 requires using gate IP 0.0.0.0,
# but Windows client do not understand it, they want their own IP as
# gate IP, so we must generate this option for them from "leased-address". 

shared-network AVTF.NET {

subnet 172.18.46.0 netmask 255.255.255.0 {
        option routers 172.18.46.1;
        option broadcast-address 172.18.46.255;
        option domain-name-servers 172.18.46.1;

        option ms-classless-static-routes = concat(encode-int(24,  8),
                                                   encode-int(82,  8),
                                                   encode-int(117, 8),
                                                   encode-int(64,  8),
                                                   leased-address);
        option rfc3442-classless-static-routes 24, 82, 117, 64, 0, 0, 0, 0,
                                                0, 172, 18, 46, 1;

и т.д.

Жаль, это не работает для Windows 2000 (да и в Висте, судя по ссылкам во время поиска в гугле, в этом что-то поломали), но для большинства XPёвых машин в сети теперь будет всё нормально :)

UPDATE: Сообщили, что за прошедшие сутки с момента включения этих опций наблюдались проблемы у некоторых юзеров - Виста не может получить адрес. В инете нашлось по теме http://users.livejournal.com/_pacak_/48017.html и http://support.microsoft.com/default.aspx/kb/928233. Блядский Мелкософт. Поймаю живую Висту, поэкспериментирую, а пока что отключил опцию (странно, оно же раньше получало, в статье-то речь про другое)...

UPD2: Была найдена также ссылка http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1383260&SiteID=17 и вышедший с тех пор хотфикс http://support.microsoft.com/kb/933340/ (должен был войти в Vista SP1). По ссылке сообщается, что Виста понимает как опцию 249, так и опцию 121 (по стандарту), но не будет принимать дублирующиеся маршруты - а в моем конфиге в обеих опциях маршруты как раз дублировались. Однако, экспериментов с этим все равно не проводил (и человеку по ссылке тоже не помогло, впрочем, у него это было до хотфикса).

http://www.livejournal.com/users/to_the_future/142843.html (via hrenov_drummer)
(правда есть слухи, что это фэйк)

Довелось мне тут намедни побывать по своим делам в районном военкомате.

Пока ждал своей очереди, наслаждаясь окружающим евроремонтом, подошли две мамы со справками о том, что дети попаданию в армию в этот сезон не подлежат по форме номер 26. Очередь затягивалась и они быстро нашли общие темы для разговора: "Да эта армия, кому она сейчас нужна?", "Армия должна быть профессиональной", "В армии ребенка погубят", ну и так далее, на полтора часа газетных тезисов, тяжелых вздохов и поддакиваний.

На фразе "вы на этих военных посмотрите - они же все тупые!", открылась соседняя дверь и из нее вышли капитан и сержант. Сержант держал под мышкой... Циску 1760. Мамы замолчали, восторженно любуясь на наглядное пособие и стараясь по выражениям лиц определить уровень армейской тупости. А военные возились с ключом от двери и разговаривали.
( Read more... )