Nuclear Lightning's Track
[Most Recent Entries]
[Calendar View]
[Friends]
Below are the 26 most recent journal entries recorded in
Vadim Goncharov's LiveJournal:
[ << Previous 26 ]
| Thursday, April 26th, 2012 | | 3:11 am |
IpfwNg
В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много. Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил). | | Tuesday, January 31st, 2012 | | 11:59 pm |
Управление памятью в сетевой подсистеме и ядре FreeBSD в целом
Эта статья будет полезна системным администраторам и программистам, работающим в ядре FreeBSD. Осмыслив изложенное здесь, можно понять, почему же бывает паника по kmem, что такое состояние keglim/ zoneli, как читать непонятные циферки в выводе vmstat -m / vmstat -z, и что же такое эти самые mbuf и nmbclusters. Программистам, приступающим к работе не в сетевой подсистеме, всё равно будет интересно узнать о дополнительных интерфейсах, помимо привычных malloc()/ free(), и отличиях этих стандартных функций. Поскольку эта статья — введение в комплекс связанных обширных тем, она предполагает наличие некоторых базовых понятий (например, чем виртуальная память отличается от физической), и не углубляется в некоторые специфичные вещи (типа packet secondary zone), особенно появившиеся не так давно. ( Read more... ) | | Friday, January 13th, 2012 | | 6:23 pm |
Как я играл в Яндекс.Root 2011
Пока на больничном, есть свободное время, решил записать воспоминания про олимпиаду для 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 час". Поскольку победителям прошлых лет запрещено участвовать в следующих олимпиадах, могу свободно высказать предположения, как можно было бы её еще улучшить. Например, в финале можно было бы не чинить сервер, а настраивать что-то с нуля. А в суперфинале — оттюнить медленно работающий сервер (привет, хайлоад). Или, там, разобраться с тем, почему в боевых условиях не работает поделие криворукого программера (это классическое бодание админов и программеров, вошедшее в байки и мемы, бывает даже в самом Яндексе). Одна беда — это требует больше времени, а в программе финального дня еще экскурсия в ДЦ Яндекса, затягивающаяся по московским пробкам... Может быть, стоило бы объединить финал и суперфинал, чтоб уместилось, но, наверное, это будет противоречить правилам, которых хочет придерживаться Яндекс... | | Wednesday, January 11th, 2012 | | 4:46 am |
О корректности "работает — не трогай" и понятии "так правильно"
Давно известна фраза "работает — не трогай", типа принцип хорошего админа, всё такое. Понятно, откуда она взялась — есть такие неуемные личности, которым скучно, а разбираться, как работает система, чем может грозить поломка, им не хочется (обычно в силу возраста, соответствующего жопыта еще нет). Но нередко, особенно в последнее время, вижу в сообществе и другую сторону — когда этой фразой оправдывается консервативность и нежелание идти на любые перемены. Даже если они уже назрели и нужны. То есть сей афоризм несет полезный смысл, но в буквальном виде — всё-таки неверен. Я для себя переформулировал его как "работает — не ломай" (улучшать можно, при условии, что ...), но это тоже несколько не то, отчасти из-за самоочевидности. И вот недавно в рассылке UAFUG пролетела такая цитата за авторством Michael Pigurnow: Лень — враг прогресса (c)
имхо причина всего этого в 2-х факторах:
a. Лень в самом худшем ее проявлении. Когда в принципе "Работает — не
трогай (улучшай)" забывается важная оговорочка: работает _правильно_.
Из-за чего работающее уже через тухес воспринимается как само собой
разумеющееся, что ведет к оплевыванию любых попыток переделки ЭТОГО по
правилам и по уму.
b. Благодушная беспечность: "Чрезвычайные ситуации бывают исключительно редко
и уж конечно же _не со мной_"
Вот тут всё становится на свои места, особенно если вспомнить не менее известное "make it work, make it right, make it fast" (именно в такой последовательности, и каждое следующее не раньше имеющегося предыдущего). Остается только с виду незаметный, но очень важный вопрос — а что же такое правильно? Вроде всем понятное слово, но каждый под ним понимает что-то свое, обычно интуитивно понимаемое и расплывчатое. Более того, никакого абсолютного "правильно", общего для всех и всегда, нет и быть не может. Тогда что же это? Я бы определил "правильно" как 3 компонента — цели, ценности и приоритеты. Они неразрывно связаны друг с другом. - Правильно что-то делается или нет, зависит от цели, того, что требуется получить — что правильно в одной задаче, может быть неправильным в другой.
- При той же самой цели, делать что-то можно разными способами. Как выбирается способ? Между задачами соблюдаются какие-то более-менее постоянные ценности, принципы. Например, "деньги не пахнут" или "всё надо делать качественно". Ценности для человека — это то, что значимо, к чему он неравнодушен, на что ему не похуй. То, что можно описать словами "хорошо" и "плохо", в отличие от всех остальных вещей, к которым нет ничего, кроме равнодушия. Ну типа, "писать понятный читаемый код — это хорошо", "ломать мне посреди ночи работавший сервер, который я поеду чинить — плохо". (Замечу в скобках, что речь стоит вести не о декларируемых ценностях — если человеку плевать на утверждение "уступать старушкам место в автобусе — хорошо", реальной ценности для него это не представляет. Но эти темы уже совсем-совсем оффтопик.)
- Наконец, ценности как сами не равны между собой, так и могут вступать в конфликт с целями (точнее, обычно подзадачами, целями помельче, на которые бьется исходная). Или бывает, например, нехватка ресурсов или чего-то еще — так, что всё вместе удовлетворить нельзя. В этом случае приоритеты определяют, что из целей и ценностей сейчас важнее, а что, быть может, отбросить вовсе (скажем, в соответствующей ситуации "когда моим детям жрать нечего — плохо" перекроет собой "писать нечитаемый код — плохо"). Когда говорят "в той ситуации было правильно поступить именно так" (а обычно, мол, положено не так) — ноги растут именно отсюда.
Легко видеть, что, например, при наличии ценности "рабочий плохой код лучше перспективной идеи" получим следствие "если это не работает — это неправильно" (но при определенных обстоятельствах приоритеты могут изменить вывод на прямо противоположный, скажем, на отрезке в 10 лет). Или что изо всех сил сидеть на FreeBSD 4.11 и бэкпортить патчи — неправильно, потому что трата времени админа на бэкпорты — не в целях и не в приоритетах. И, возвращаясь к исходной фразе, становится понятно, когда же "трогать" — ведь и цели, и ценности, и приоритеты могут меняться со временем. Что было правильным год назад, может уже не быть таковым сегодня (ситуация меняется). Вот тогда влезать и менять работающее — не просто можно, а нужно. P.S. Конечно, понятие правильности всё равно останется субъективным — не только от различия целей, но и от разницы в охватываемом в данной ситуации количестве ценностей и приоритетов у разных людей, учитываемых факторах (зависит от всё того же жизненного опыта). Тем не менее, осознавать свои цели, ценности и приоритеты (и общаться об этом с другими людьми, если есть такая необходимость) несколько проще, если понимать, откуда у своих представлений о "правильности" ноги растут. | | Saturday, December 31st, 2011 | | 11:54 pm |
С новым 1905 годом!
А я тут в результате http://root.yandex.ru (кстати, тема для отдельного поста — в десятке финалистов линуксовой олимпиады было четверо фряшников) из Томска переехал в Москву понаехал в Нерезиновую. Успел, наконец, разобраться со всеми тяготами и хлопотами переезда до наступления нового, по всем прогнозам тяжелого, года. Некоторые из которых проводят некоторые исторические параллели (вот Николай II — тоже взошел на престол примерно за 11 лет до первых событий). Что ж, год будет тяжелый, но пока — отдыхаем и пьем. Пять минууут, пять минуууут... С Новым 1905 годом вас всех, товарищи! | | Friday, August 5th, 2011 | | 6:59 am |
| | Wednesday, August 3rd, 2011 | | 7:14 am |
Каковы проблемы FreeBSD и пути их решения? Часть 1: Рампочта.
Три недели назад Андрей Шетухин, руководитель отдела почты Rambler, сообщил о начале миграции своего почтового кластера (порядка 500 серверов) с FreeBSD на Linux (Debian/Ubuntu), поскольку FreeBSD перестала его устраивать. Дискуссия в комментах, которых уже более полутысячи, разгорелась нешуточная. В комментах также стало известно, что аналогичный переход планирует Яндекс на своем поисковом кластере, который в данный момент работает целиком на FreeBSD, а это примерно 25000-30000 серверов, и порядка 60% мощностей Яндекса. Такая потеря — это для FreeBSD уже серьезно. С такими тенденциями система, к радости ликующих подонков, станет таки умирать. Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал " Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть. Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат: I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший. ( Read more... ) | | Wednesday, June 1st, 2011 | | 11:59 pm |
Астрологический портрет FreeBSD Гороскоп FreeBSD| | А Водолей — это вон те 2 резистора?
IT-шник, впервые увидевший натальную карту |
Давно подмечал, что у больших программных проектов, особенно операционных систем, есть нечто вроде характера — разные проекты вызывают разные ощущения. Причем сюда входит как сам проект, так и составляющее его сообщество людей. И вот как-то раз наткнулся на http://avi.alkalay.net/1991/08/linux-astral-map.html, где описывается характер Linux, правда, очень кратко. Поскольку меня больше интересует FreeBSD, я обратился к двум знакомым астрологам с просьбой описать характер родной ОС. Обычно гороскопы делают для людей, но можно сделать для чего угодно — например, для фирмы/предприятия. Собственно, эти товарищи далеки от IT, потому и делалось как для фирмы. Так как информации из гороскопа можно вытянуть очень много, а нормальный анализ всего этого — большая работа, занимающая много времени и стоящая денег, мне описали довольно кратко. При том каждого астролога я расспрашивал только о части карты, дабы не напрягать лишний раз, и свёл вместе сам. Что, однако, всё равно вылилось в большой пост, хотя и является относительно малой частью того, что вообще можно вытащить из гороскопа. Итак, гороскоп — карта положения ряда объектов на небе, как они видны в месте рождения в момент рождения. Что считать моментом рождения человека, понятно, а вот что будет таковым для программного проекта? На сайте в архивных материалах обнаружилось http://www.freebsd.org/news/1993/freebsd-coined.html — фрагмент переписки отцов-основателей. Здесь проект впервые получил имя, чем не момент рождения? Естественно, нужно проверить, тот ли самый это момент. Для человека процедура уточнения времени рождения называется ректификацией, и производится по датам крупных событий в жизни (требуется 6-10). Нужна она затем, что в роддомах время бывает записано с округлением или погрешностью, а для прогнозирования событий по некоторым методам ошибка в 4 минуты дает сдвиг на год, да и вообще за сутки всё очень сильно меняется. Мне, конечно, эту трудоемкую операцию никто забесплатно проводить не стал. Но, поскольку эти люди, будучи далекими от компьютеров вообще, очень точно описали некоторые моменты, я удовлетворился этим — по всей видимости, это и есть момент рождения. Поскольку в опенсорсе всё приходится делать самому, то и картинку натальной карты (гороскопа рождения) тоже пришлось добывать самому. Поставил ports/misc/astrolog, и получилось вот такое: ( Трактовка гороскопа следует ) | | Tuesday, April 26th, 2011 | | 4:23 am |
01:23:39
Ну что, четверть века прошла, и вот полку прибыло. С праздником! | | Wednesday, April 13th, 2011 | | 2:44 am |
50 лет
Пора выпить 50 грамм и пересмотреть "Укрощение огня". Они были первыми. ...И немедленно выпил. | | Friday, February 11th, 2011 | | 5:11 am |
"Netgraph для пользователя" и литературная критика; подходы к интерфейсам систем
Получил я на днях вот такую критику своей статьи "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... ) | | Tuesday, February 8th, 2011 | | 6:09 am |
Netgraph для пользователя: некоторые типы узлов
Как известно, инженер не должен помнить наизусть кучу формул, констант, свойств материалов, ключей командной строки и прочей информации: он должен помнить общие принципы, и уметь пользоваться справочниками, в которых и можно посмотреть нужное. А также уметь эту справочную информацию найти (знать, в какие справочники смотреть). Общие принципы netgraph были описаны в предыдущем посте, справочниками служат man-страницы и исходные тексты. Остается рассказать, какие узлы netgraph существуют (куда смотреть), и что они умеют — обзор того, что система умеет, какие задачи можно решать, что же именно можно комбинировать друг с другом. Конечно, уделить внимание всем типам узлов не получится (ведь всего их уже более 60!), но хотя бы по некоторым будет иногда и такая информация, которой нет непосредственно в справочнике. Кроме того, этот пост можно рассматривать как приложение к предыдущему (ограничения на объем поста ЖЖ не позволяют даже поставить ссылку там сюда), для понимания материала необходимо его прочитать. Возможно, здесь будут и другие дополнения к нему. ( Итак, узлы можно условно разделить на... ) | | Wednesday, January 26th, 2011 | | 8:24 pm |
26
26! Круглая дата! Столько бывает только раз в жизни! Вот и дожил наконец до эпохального. Ура! И природа со мной солидарна - сегодня 15000 день от начала эпохи: $ echo `date +%s` / 86400 | bc
15000 Пожелаю себе следования путем 26, яркого и огненного. Вперед, к вершинам и победам! | | Tuesday, January 18th, 2011 | | 4:01 am |
Netgraph для пользователя
Многие слышали о сетевой подсистеме Netgraph во FreeBSD, но далеко не все представляют себе, что же это такое, как оно работает, и зачем оно нужно — кроме того, что на нем работает mpd (известная очень производительная реализация PPP/PPTP/L2TP). Да еще по сети ходят многочисленные Howto типа "как считать Netflow на нетграфе", где приводят примеры решения конкретных задач, о самой же подсистеме рассказывая "галопом по Европам" (пишите, мол, так, "синтаксис такой-то"). Проблема в том, что вся документация по netgraph рассчитана на программистов: как маны, так и единственная достаточно подробная статья от автора подсистемы "Все о Netgraph" — в ней дается общий обзор, а за подробностями читатель отсылается в исходники. Что, разумеется, отпугивает новичков, поскольку кажется слишком сложным, а читатели, привыкшие к другим ОС, часто не понимают суть системы и зачем она нужна, если есть vtun, ipt_netflow и другие решения для типовых частных случаев. Между тем netgraph — это реализованный в ядре коммуникационный фреймворк общего назначения, и в использовании он не сложнее, чем длинная командная строка вида " prog1 | grep | sort | sed | prog2 | awk", просто для начала необходимо понять ряд вещей, о которых я и попытаюсь рассказать доступным языком. (Примечание: далее будут использованы некоторые фрагменты упоминавшейся выше статьи "All about NetGraph", и кое-где будут примечания с пометкой AANG, показывающие места, в которых та статья уже устарела)( А поскольку понять всё целиком с наскоку нельзя, запаситесь терпением ) | | Wednesday, November 3rd, 2010 | | 11:35 pm |
Мск
В связи с http://root.yandex.ru/ буду с 18 по 21 число в Москве. Желающие пересечься - велкам в комменты ;) P.S. Если по части FreeBSD/*nix, то у #freebsd@RusNet намечается коннект, соответственно, лучше на него :) | | Thursday, July 15th, 2010 | | 4:15 am |
Модификация ToS/DSCP/TTL/etc. на FreeBSD: ng_patch
Патчи, позволяющие матчить и изменять ToS/DSCP на FreeBSD, ходят в разных вариантах по сети уже лет шесть, вот очередная инкарнация, например. К сожалению, ни один из них так и не попал в базовую систему, хотя пример по ссылке, скажем, для конкретной задачи удобнее того, что описано ниже. Даже возникает подозрение, что это всё потому, что предыдущие решения были недостаточно общие :) Вот Maxim Ignatenko написал ноду ng_patch(4) - и её, наконец, закоммиттили, а недавно смержили в 8-STABLE ( r209843) и вчера - в 7-STABLE ( r210019). Работает также на 6.4, если убрать в коде CSUM_SCTP, я проверял. В настоящее время ng_patch - единственный штатный способ поменять что-то в проходящем пакете. Зато, в отличие от других решений (в том числе на других ОС), эта нода позволяет производить последовательность операций над произвольными байтами пакета, не только ToS или TTL. В мане рассмотрены примеры изменения ToS и TTL, я же расскажу чуть подробнее, с примером для DSCP. ( Read more... ) | | Wednesday, July 7th, 2010 | | 6:48 am |
| | Wednesday, March 3rd, 2010 | | 11:09 pm |
недостающий кусок к "ipfw: порядок прохождения пакетов, сложные случаи"
К посту http://nuclight.livejournal.com/124348.html в свое время не всё влезло, из-за ограничений на объем поста в ЖЖ (судя по всему 65535 в байтах, причем UTF-8, так как для разной пропорции русского текста длина переменная и непредсказуемая). Ниже идет недостающий кусок, с того места, где там прервалось. Может быть, со временем, что-нибудь еще добавится :) Итак, продолжение ( UPD2 про IPSEC в 6.x )UPD3: По состоянию на 17.09.10 выше только описание порядка IPSEC для 6.x (в других версиях уже другое), да и то, как выяснилось, неточное. Кроме того: ( UPD3 про kern/147720 и несколько таблиц при tablearg ) | | Sunday, February 28th, 2010 | | 11:59 pm |
Фильтрация uTP (Torrent UDP) внутри PPTP GRE
Краткое содержание: как отфильтровать 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... ) | | 11:21 pm |
Как работает tcpdump: ассемблер BPF; фильтрация с ng_bpf на FreeBSD
Этот пост пригодится вам не только на FreeBSD, но и на Linux и любой другой системе с BPF (для Windows есть вот такое) в случае, когда вы хотите написать приложение, отбирающее напрямую с линии пакеты по некоторому критерию, как tcpdump (ну скажем, хотите проконтролировать ARP в вашей сети по типу приложения ipguard, или еще что). Здесь идет более подробная версия куска моей презентации на RootConf 2009 (по ссылке доступны слайды и видео), где также рассматривался и упоминаемый далее Netgraph. ( Read more... ) | | Monday, April 6th, 2009 | | 12:14 am |
[RootConf] IPFW: несколько наборов правил и другие предполагаемые изменения
=== В марте, помнится, я написал в 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 апреля :) Никто не хочет впустить? :) | | Sunday, June 29th, 2008 | | 11:40 pm |
| | Friday, May 23rd, 2008 | | 3:52 pm |
ipfw: порядок прохождения пакетов, сложные случаи
Нарисовал тут давеча в RU.UNIX.BSD схему прохождения пакета через ядро и ipfw, с объяснениями, как это все стыкуется с divert, dummynet, keep-state и т.д., теория и примеры. Народу понравилось, решил опубликовать и здесь, чтоб не потерялось (ибо объяснений, как оно там все внутри, в сети не встречал — только howto-шки на что-то простое или конкретику "вот у меня наконец получилось", не дающие возможности понять и составить что-то сложное другое самому). ( Многа букав и ASCII-арта ) | | Thursday, December 6th, 2007 | | 2:26 pm |
| | Saturday, December 1st, 2007 | | 11:48 pm |
Немножко ссылок
Из процесса ежедневного рагребания ссылок нашлось интересное. http://moja-zhizn.livejournal.com/43961.html - Ленинскую Библиотеку, фактически, обрекают на уничтожение. Однако, нехорошо. http://zhurnal.lib.ru/z/zlobnyj_y/fanterrors.shtml - хороший текст (правда, многабукаф, но интересно) про типичные штампы в фантастике, как в книгах, так и в фильмах. Речь идет как об очевидных сразу вещах (как те же фильмы про хакеров), так и о не очень, которые способны многие книги загубить вообще на корню :) как космические бои, например. Рассмотрены и разнообразные экологические мифы, и даже миры фэнтези - хотя последним, на мой взгляд, автор зря побоялся уделить больше внимания (ограничившись разбором экономики, оружия и орудий по историческим параллелям), разбор физики и магии был бы весьма интересен. http://www.intuit.ru/department/os/osunix/ - хороший курс по Юниксам (наткнулся в жгучих комментах с опеннета). Отличается от других тем, что дает в большей степени философию Юниксов, нежели набор команд, более того, обосновывает это. Особенно интересны вводные лекции: Рассмотрим самый, на наш взгляд, естественный алгоритм решения любой задачи: 1. уяснить задачу; 2. выбрать самый подходящий инструмент решения (самый подходящий, а не самый знакомый!); 3. освоить этот инструмент (начиная с изучения документации). 4. придумать по возможности красивое решение; 5. зафиксировать это решение (чтобы можно было в случае чего повторить); 6. применить его.
Казалось бы, спорить не с чем, но как часто мы поступаем строго наоборот!
Желая "сэкономить время", мы нередко начинаем с того, что так и эдак применяем попавшиеся под руку инструменты (6) и даже начинаем набрасывать кое-какие сценарии или проекты решения (5). Потом мы задумываемся над тем, как же решить нашу задачу "по уму" (4), и понимаем, что инструмент нам, в сущности, незнаком, что надо изучать руководство (3). Из руководства выясняется, что инструмент нам не подходит, и приходится искать другой (2). И только тогда мы понимаем, что для этого надо разобраться, какую именно задачу мы решаем (1). Напоминает "Как правильно задавать вопросы", не правда ли? Было сравнение даже с дзен-буддизмом. Следуют рассуждения о проективных человеко-машинных системах (те же юниксы как пример) в противовес процедурным: Процедура как суррогат поступка
Процедурной мы будем называть человеко-машинную систему, доступную человеку в виде набора функций (процедур) внутри прикладной области, описываемых в терминах прикладной области и приводящих к наглядному или гарантированному изменению свойств объекта. Например, человеко-телевизор - полностью процедурная система: все задачи, которые ставит перед ней человек, описываются в терминах "программа", "громкость", "контраст" и т. п. Телевизор же (вернее, инструкция к нему) общается с пользователем на том же языке (кажется, в нем есть только один новый термин - "кнопка", все остальные, включая названия кнопок, повторяют известное пользователю). Казалось бы, чем плохи процедурные систмы, они ведь говорят с пользователем на понятном ему языке, обучение не нужно? Ну, в частности тем, что: Пользователь процедурной системы зачастую не знает, как именно он добился от нее желаемого результата и далеко не всегда может с первого раза воспроизвести свои действия. Нажимал-нажимал на кнопки - и вышло. Как? А кто ж ее знает. Здесь работает накопленный опыт общения с системой, возможно, даже некое представление об ее истинном устройстве, добытое из системы в обход предусмотренных каналов информации и оттого не поддающееся формализации. Явление это имеет название black magic (черная магия) или voodoo. И много других очень жызненных вещей. Читать, однозначно. | | Tuesday, November 13th, 2007 | | 12:51 am |
Винда, DHCP и статические маршруты в directly-attached сеть
Есть у нас в сети общаги уже долгое время две подсети, с серыми и белыми адресами, при этом бегают по одной физике. Не очень кошерная конфигурация, конечно, ну да так вышло по историческим причинам ( тяжелое детство, деревянные игрушки бедные студенты, провайдер-жмот). Суть в том, что хостам желательно бы видеть друг друга напрямую, а не нагружать роутер, который раздает им Интернет, так как у него те же 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 (по стандарту), но не будет принимать дублирующиеся маршруты - а в моем конфиге в обеих опциях маршруты как раз дублировались. Однако, экспериментов с этим все равно не проводил (и человеку по ссылке тоже не помогло, впрочем, у него это было до хотфикса). |
[ << Previous 26 ]
|