Nuclear Lightning&#39;s Track

для NAT64 libalias бы переписать.
ну и загрузка всех правил скопом must have.

From:

> ну и загрузка всех правил скопом must have.

Да, разумеется. Хотя технически это скорее будет загрузка кусками в некий буфер в ядре и потом его атомарная активация.

> для NAT64 libalias бы переписать.

А вот это нафиг не надо и вредно, libalias пора закопать (вот в треде ниже мнение Глеба приводят, конкретно к этой теме я согласен). Чтобы там такое сделать, нужно столько переделать, что проще переписать. К тому же дает знать о себе наследие ориентированности на юзерленд и архитектурная ошибка в виде мешания partially specified links (для редиректов и проч.) в общую кучу с обычными соединениями, из-за чего нельзя применить более эффективную хэш-функцию, и (в том числе поэтому) вообще параллелить его - та еще проблема...

From:

http://nuclight.livejournal.com/130012.html?thread=815836#t815836

From:

> ну и загрузка всех правил скопом must have.

Есть давным давно, ещё в 4.x было. ipfw sets.

From:

Это не то. Я про типа такого: ipfw -f

From:

И это есть.

From:

Я смотрю на какой то другой ipfw?
Вообще-то sets - это альтернативные наборы правил, которые можно *включать* и *отключать* по желанию.
Но загрузка в них происходит все так-же - по одному правилу.

Такая загрузка - это ужасно не удобно.

From:

> Я смотрю на какой то другой ipfw?

Просто надо внимательно читать man ipfw.

ipfw [-cfnNqS] [-p preproc [preproc-flags]] pathname
...
     To ease configuration, rules can be put into a file which is processed
     using ipfw as shown in the last synopsis line.  An absolute pathname must
     be used.  The file will be read line by line and applied as arguments to
     the ipfw utility.

From:

Это я читал. Это издевательство, которое ничем не лучше шел скрипта со строчками ipfw add ...

Попытаюсь быть экстрасенсом: ты предлагаешь это загружать в некий сет и при успехе делать swap с активным?

А почему эту возможность не добавить нативно? Что бы ipfw загружал правила в память, репортил ошибки, либо, если их нет, загружал опкоды уже в ядро?

From:

> Это я читал. Это издевательство, которое ничем не лучше шел скрипта со строчками ipfw add ...

Тогда я не понял, что должно быть твоём "ipfw -f file"

> Попытаюсь быть экстрасенсом: ты предлагаешь это загружать в некий сет и при успехе делать swap с активным?

Разве это не очевидно?

> А почему эту возможность не добавить нативно? Что бы ipfw загружал правила в память, репортил ошибки, либо, если их нет, загружал опкоды уже в ядро?

Не вижу разницы с существующим сейчас функционалом: в файл пишем команды добавления в set 1, затем swap.

From:

Ну в принципе, можно и левое ухо чесать правой ногой. Цель будет достигнута.

From:

Ничего хитровывернутого в описанной процедуре нет, всё весьма прямолинейно. В своём враппере над ipfw я вовсю использовал именно эту процедуру ещё на 4.11.

From:

Ключевое выражение "в своем враппере". Хорошо бы, что бы это было у всех.

From:

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

From:

Нет, этот путь уже не является правильным. Весь проект затеян для того, чтобы приподнять уровень, который слишком уж низкоуровневой (машкоды в наше время уже были бы совсем пиздец). Тем более, он и в низкоуровневой-то части lacks many needed features, которые не позволяют и обертки вменяемые писать.

From:

"lacks many needed features" - разве что в stateful части, потому что в stateless нет проблем писать вменяемые обертки, я неоднократно писал.

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

демагогия

From:

nuclight.livejournal.com - Date: 2012-05-10 09:38 pm (UTC) - Expand

(no subject)

From:

dadv.livejournal.com - Date: 2012-05-11 01:37 am (UTC) - Expand

From:

denis-sotchenko.livejournal.com

да, плюсую NAT64

а правила скопом загружаются без проблем - ipfw /path/to/rules
причём, в отличие от отдельных вызовов ipfw add, грузятся практически мгновенно.

From:

Что бы это было без проблем, надо по крайней мере две команды: проверить ipfw -n /path/to/file и уже непосредственно загрузка. И не дай бог забыть первую. Причем гадкий ipfw остановится на правиле с ошибкой, а не проигнорирует ее (с сообщением конечно), что (по закону подлости) как правило приведет к потере машины с радаров. В этом случае скрипт с загрузкой по одному правилу может быть предпочтительней. Только тут есть другая засада - если правил очень много, можно этого не заметить. В общем, при любом раскладе, нужно что-то городить (Женя например, ниже привел пример с сетами).

From:

Кому лениво писать set N в списке правил, могут пропатчить /sbin/ipfw, добавив новый ключ -S N, который бы по задавал новый дефолт для set (вместо нуля) для правил без set N и использовать ipfw -S 1 -f /path/to/ruleset && ipfw set swap

From:

> могут пропатчить

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

From:

> Это не должно быть "пропатчить", это должно быть "из коробки".

А из коробки есть set N в каждом правиле.

> Тем более там внутри каша, к тому же еще и недокументировано ничего.

ipfw sets документированы ещё с 4.x. Или ты про отсутствие комментариев в коде? :-)

From:

Ну написано же, в чем проблема. Иди и прочитай. Если не доходит, иди освой lex и yacc, сравни с имеющимися решениями, тогда дойдет.

From:

Там написано: ниасилил и не хочу, хочу "до основанья, а затем".

From: