Debian объявляет об официальной поддержке kFreeBSD

>Вот кстати почитал тут 4 страницы срача и не заметил ни одного упоминания такой фичи ядра FreeBSD, как netgraph.

В таком контексте это просто красивое слово.

>Очень, имхо, полезная вещь, аналогов которой в ядре Linux даже близко нет.

Что она позволяет делать, чего нельзя сделать в Linux?

Нет, я конечно знаю, что это такое, но все её фичи фактически доступны и в Linux, только они разбросаны по разным подсистемам. Всё достоинство netgraph - в её модульности и логичности, а киллерфич я в ней не наблюдаю.

> Нет, я конечно знаю, что это такое, но все её фичи фактически доступны и в Linux, только они разбросаны по разным подсистемам. > Всё достоинство netgraph - в её модульности и логичности, а киллерфич я в ней не наблюдаю.

Я про киллерфичи и не говорил. У меня нет цели доказать, что фря лучше линуха или наоборот. Я вообще считаю, что любая система должна использоваться там, где она справляется со своими задачами лучше остальных, вне зависимости от того, что это за система. Да-да, я даже считаю, что в некоторых аспектах винда предпочтительнее всего UNIX-like зоопарка. :)

И, кстати, если Вы не заметили, я не говорю - "в linux". Я говорю - "в ядре linux". Ценность нетграфа в логичности, модульности, расширяемости (причем динамической) а еще в том, что все операции выполняются в ядре, в его контексте, без переключений в userspace.

>ты вот спросил "НУ И ЧТО", ну я отвечу - преимуществом фрюшного варианта считаю только то, что действия по шейпингу делаются на одном интерфейсе в обоих направлениях (и на ин и на аут) и меньшим количеством телодвижений. Насколько я помню, то iptables шейпают только на аут, и еще там пакеты нужно сначала "манглить метками на входном интерфейсе", а потом по этим меткам делать действия на ауте второго интерфейса... хотя это было два года назад... я тогда вообще не особо силен в этих делах был.... може и был другой вариант - но по другому не выходило. Вот и получается, что на одном действии - одно дополнительное движение, за счет чего дольше держится прерывание, требуемое для обработки пакета, вот отсюда разница в производительности.

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

Так, что здается мне, что ты в этом вопросе не компетентен.

P.S. имеется в виду ограничение трафика именно средствами фаерного шейпера.

хорошая новость. Больше ядер, хороших и разных!

можно с этого места поподробнее?

>Кстати да. Недавно сервер сооружал. Выбрал FreeBSD. Буквально за 10 минут поднял зеркало на gmirror. Все так просто и удобно, чуть ли не аппаратный с лампочками!! Одна сраная команда - и все, зеркало. Правда забыл поправить fstab - на это десять минут и ушло.

>А в лялихе? mdmmm какой-то. Что там что-то нужно копировать и воссоздавать с помощью fdisk - ужас. Это ли зеркало по вашему? Зеркало - это когда сгорел винт, всунул новый, включил в массив. Все, началась синхронизация.

mdadm -C /dev/md0 -l1 -n2 /dev/hda /dev/hdb

PROF^W Всунул новый, включил в массив. Все, началась синхронизация.

Да, перед этим надо установить mdadm.

>В результате glibc сейчас практически незаменима. А при таком основном разработчике это ужас.

Вот как раз поэтому дебиановцы не так давно преехали на eglibc...

> преимуществом фрюшного варианта считаю только то, что действия по шейпингу делаются на одном интерфейсе в обоих направлениях (и на ин и на аут)

А вот считаю это скорей недостатком и непониманием темы кое-кем:

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

2. Входной трафик шейпить вообще нельзя. В принципе. Как удаленная сторона посылает - так ты и принимаешь. Хоть в очередь ставь, хоть сразу передавай, хоть отбратно отправляй - но пакет уже прошел и полосу съел :-)

> При чём, можно будет наращивать или уменьшать размер раздела офф-лайн, перемещать его с диска на диск он-лайн. И вот этого ZFS точно не может.

Я бы не был так уверен, что ZFS этого не может :-) Но вот то, что LVM значительно прощее (а значит надежней и эффективней) это факт.

> я даже считаю, что в некоторых аспектах винда предпочтительнее всего UNIX-like зоопарка.

Ну да, это извечный "аргумент" бздунов когда их ловят сидящими на винде :-)

> Я вообще считаю, что любая система должна использоваться там, где она справляется со своими задачами лучше остальных

Сначала c00l][аKeP ставит убунту....
Затем он трезвонит всем про то, как он крут и у него линукс...
Потом он ниасиливает убунту...
И возвращается в винду...
Но чтобы его не зачморили другие кулхацкоры...
Он ставит фряху и начинает говорить что "фряхя лучший севрер, винда лучший десктоп, и каждому свое"...
И это все в то время, когда линуксоиды спокойно работают в линуксе на десктопе с линуксоами на серверах :-)

>Входной трафик шейпить вообще нельзя. В принципе. Как удаленная сторона посылает - так ты и принимаешь. Хоть в очередь ставь, хоть сразу передавай, хоть отбратно отправляй - но пакет уже прошел и полосу съел :-)

Но если пакетик дропнуть, следующие не будут столь настойчивы, это механизм TCP

> Но если пакетик дропнуть, следующие не будут столь настойчивы, это механизм TCP

Угу, и он прилетит повторно :-) Вообще, в такой ситуации договариваются с провайдерами, или ставят в очередь ACK на PUSH :-)

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

Не компетентен в вопросе, дружище, в первую очередь тот, кто вот так вот сразу прыгать начинает. Я бы (на твоем месте) не был бы так уверен в таких словах. Тебе может куда-то прислать чуть-чуть конфига, и вывод pftop, для того, чтоб ты уверился в том, что именно ТЫ тут заблуждаешься?

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

>Угу, и он прилетит повторно :-)

но скорость уже будет меньше, что и требуется.

>Вообще, в такой ситуации договариваются с провайдерами

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

>> При чём, можно будет наращивать или уменьшать размер раздела офф-лайн, перемещать его с диска на диск он-лайн. И вот этого ZFS точно не может.

А как насчет матчасть изучить прежде чем высказываться в таком категоричном тоне? У ZFS несколько другая модель администрирования, чем та, к которой вы привыкли.

> Я бы не был так уверен, что ZFS этого не может :-) Но вот то, что LVM значительно прощее (а значит надежней и эффективней) это факт.

Сложность в плане количества строк кода связки LVM+файловая система сравнима с ZFS (в всяком случае была в последний раз, когда я этим интересовался, а стех пор много воды могло утечь), а в плане набора возможностей тягаться с ZFS такой связке будет тяжело. Так в чем таком LVM значительно надежней и эффективней?

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

И если вы такой аплогет связки LVM+ФС, то как в этом случае тогда относиться к BTRFS, которая тоже собирается в себе избыточность реализовывать (хотя пока дальше зеркалирования и копий дело не пошло)?

>Я бы не был так уверен, что ZFS этого не может :-) Но вот то, что LVM значительно прощее (а значит надежней и эффективней) это факт.

Я о том, что ZFS не позволит использовать эти плюшки без raw-раздела. В ZFS как бы получается, что ФС намертво прибита гвоздями к LVM.

Даже FAT + LVM позволяет онлайн переместить раздел с одного винта на другой. Чем не пюшка?

> И да - если ты не знал, то перечисленные тобой костыли являются подпроектами проекта freedesktop.org, а не GNU...
разработчики коротого должны умереть в страшных муках!

для no-dashi: >А вот считаю это скорей недостатком и непониманием темы кое-кем: 1. Индивидуальные шейперы для каждого исходящего интерфейса более гибки в настройке - они дают возможность (например, на двух аплинках) сказать что по этому линку у нас в приоритете юрики-клиенты с помегабайтной таксой, а на втором "физики-безлимитчики". 2. Входной трафик шейпить вообще нельзя. В принципе. Как удаленная сторона посылает - так ты и принимаешь. Хоть в очередь ставь, хоть сразу передавай, хоть отбратно отправляй - но пакет уже прошел и полосу съел :-)

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

А вот по п.2. также согласен, но с оговоркой. уже до меня успели сказать, что следующие пакеты уже "не будут столь настойчивы" после калькуляции tcp окна :) а если УДП - то здесь согласен, вариантов, скажем так, существенно меньше (чтоб не сказать, что вообще никаких).

P.S. Вообще-то разговор как-то плавно отошел от сабжа:) Насчет того, о чем мы тут разговорились, наверное, нужно разговаривать в другом месте:)

> Кстати, мне действительно интересно, как MTU discovery работает через pf.

нормально вполне работает.

> Неужели там нужно вручную разрешать icmp-destination-unreachable? keep state для них не работает?

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

> В netfilter'е, емнип, такие пакеты проходят как RELATED.

точно так же, если только ты сознательно не указал stateless.

>>> При чём, можно будет наращивать или уменьшать размер раздела офф-лайн, перемещать его с диска на диск он-лайн. И вот этого ZFS точно не может.

>А как насчет матчасть изучить прежде чем высказываться в таком категоричном тоне? У ZFS несколько другая модель администрирования, чем та, к которой вы привыкли.

Я уже поправился, я имел в виду то, что в ZFS менеджер томов прибит гвоздями к ФС, а поэтому использовать некоторые плюшки ZFS совместно с raw-томом не получится.

>По мне так главное требование к ФС - чтобы она с большой надежностью возвращала мне именно те данные, которые я в нее ранее записал, а если она не может этого сделать - сообщала бы мне об этом ошибкой.

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

> А User-Mode-kFreeBSD будет? Нужно для Неткита %)

о да! это было бы здорово! и Опен бы еще...
sv75, как ты оцениваешь сложность такой работы?

> Я уже поправился, я имел в виду то, что в ZFS менеджер томов прибит гвоздями к ФС, а поэтому использовать некоторые плюшки ZFS совместно с raw-томом не получится.
блин, тут не катят линуксовая терминология. в зфс собственно фс и менеджер томов - единое целое

>> Кстати, мне действительно интересно, как MTU discovery работает через pf.

>нормально вполне работает.

>> Неужели там нужно вручную разрешать icmp-destination-unreachable? keep state для них не работает?

>в пф тоже. причем, пропускаются и менглятся все релейтед ицмп сообщения.

>> В netfilter'е, емнип, такие пакеты проходят как RELATED.

>точно так же, если только ты сознательно не указал stateless.

Спасибо за разъяснения. А то iZen нихрена вопроса не понял, за то норовит кидаться не понятными ему ссылками и цитатами из букваря.

> К тому же, емнип, PMTU discovery работает через icmp-destination-unreachable.
ICMP Type 3 Code 4, Fragmentation needed, DF set.

> Спасибо за разъяснения. А то iZen нихрена вопроса не понял, за то норовит кидаться не понятными ему ссылками и цитатами из букваря.
Изень такой Изень ж)
я еще немного сейчас поотвечаю, а то только домой заглянул...

>блин, тут не катят линуксовая терминология. в зфс собственно фс и менеджер томов - единое целое

О том и речь, что ZFS - не лучше и не хуже системы LVM+ФС, это разные вещи, каждая из них сильна в одном, но слаба в другом.

> Разрешённые типы ICMP-пакетов указываешь и разрешаешь. Вот конфиг закрытого файервола, пропускающего только пинги:

[поскипаны куски конфига]

зачем это все? ты все же прочитал бы ман, который так советуешь. а то такое ощущение, что, как большинство фрибсдшников, видел только "статьи" на опеннете.

>> например, из префиксов, полученных от определенного BGP пира...

> Лично для меня гораздо важнее списки, которые сам фаервол заполняет, выявляя досеров и портсканеров.

в pf это тоже есть ;)

> nnz, ты, видимо живешь в Раше, а я поживаю в Юкрейне, тут у нас есть такое аццкое понятие как "Уаикс" (точка обмена трафиком украинских операторов). Вот когда нужно шейпать клиентские траф РАЗДЕЛЬНО по направлениям, и нужно каким-то образом максимально быстро перестраивать списки этих направлений - вот тогда такая фича (о которой я говорил, про BGP пиров) и становится, мягко говоря, ОЧЕНЬ КСТАТИ.

кстати, а что за бгп у вас? квагга? или опенбгпд?

> ты вот спросил "НУ И ЧТО", ну я отвечу - преимуществом фрюшного варианта считаю только то, что действия по шейпингу делаются на одном интерфейсе в обоих направлениях (и на ин и на аут) и меньшим количеством телодвижений.

это все ложное чувство, возникающие в результате просмотра неверных правил файрволла и непонимание работы сети и шейпера.

> и далеко не ПФом, а IPFW, который даже per-user правила создавать умеет.
а pf что, не умеет по-твоему?

> >>pass in quick on $int_if proto udp from $ipphone1 to any tag VOIP keep state
> >Пропустить все UDP без фильтрации.

> Что значит "все"?!
> О тегированном трафике ничего не слышал?

> На, почитай: http://www.openbsd.org/faq/pf/ru/tagging.html

сам и почитай. именно, что все. tag - это поставить метку. tagged - это критерий отбора тех, что с меткой.

>>Я бы не был так уверен, что ZFS этого не может :-) Но вот то, что LVM значительно прощее (а значит надежней и эффективней) это факт.

>Я о том, что ZFS не позволит использовать эти плюшки без raw-раздела. В ZFS как бы получается, что ФС намертво прибита гвоздями к LVM.

Мысль насчет raw-раздела поясните, пожалуйста.

В ZFS уровни абстракции проведены несколько по-другому. К тому же, особо страждущим никто не мешает засунуть под ZFS еще и LVM, было бы зачем только.

> Даже FAT + LVM позволяет онлайн переместить раздел с одного винта на другой. Чем не пюшка?

zpool replace <poolname> <old disk> <new disk>

Учите матчасть!

>zpool replace <poolname> <old disk> <new disk>

>Учите матчасть!

Ну и где здесь FAT?

>>А как насчет матчасть изучить прежде чем высказываться в таком категоричном тоне? У ZFS несколько другая модель администрирования, чем та, к которой вы привыкли.

> Я уже поправился, я имел в виду то, что в ZFS менеджер томов прибит гвоздями к ФС, а поэтому использовать некоторые плюшки ZFS совместно с raw-томом не получится.

Мысль насчет raw-тома по-прежнему остается неясна.

>>По мне так главное требование к ФС - чтобы она с большой надежностью возвращала мне именно те данные, которые я в нее ранее записал, а если она не может этого сделать - сообщала бы мне об этом ошибкой.

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

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

А насчет ресурсов и прочего - о порте ZFS (и OpenSolaris) на ARM слышали? А о ReadZilla и LogZilla? Спросите у Гугля ;-)

> GNU до сих пор - недоделка
С такой аргументацией вы напоминаете Мужика-2, который вещал о том, что KDE неполноценный, потому что в нем нет писалки дисков, а K3b не входит в KDE и потому не считается.
Цель проекта GNU -- получить полностью свободную полнофункциональную ОС, а не сделать свою реализацию всего входящего в состав ОС.

>> и далеко не ПФом, а IPFW, который даже per-user правила создавать умеет.
>а pf что, не умеет по-твоему?

то что делается десятком правил на ipfw, в pf вырастает в портянку по четыре правила на клиента :(
соотвтственно производительность и управляемость такого решения довольно сомнительна

tablearg и mask-и рулят в этом случае :)

хм, может я чего-то не понял. о чем идет речь? каков юзкейс, так сказать?

>>zpool replace <poolname> <old disk> <new disk>

>Ну и где здесь FAT?

Сударь, не вы ли утверждали, что "даже FAT+LVM позволяет онлайн переместить раздел с одного винта на другой.", подразумевая при этом, по всей видимости, что в ZFS такой плюшки нет?

Если вы, конечно, подразумевали совсем не то, и это я за вас додумал, то простите великодушно, и поясните таки, что вы имели ввиду. И мысль про raw-том или raw-раздел тоже поясните, пожалуйста.

>Мысль насчет raw-раздела поясните, пожалуйста.

Пожалуйста. Размечаем диск LVM'ом, создаём том, но НЕ форматируем его. Туда засовываем ораклиную базу. Профит - не тратим производительность компьютера на поддержание не нужного слоя "файловая система и один большой файл на ней, в котором находится база данных", а размещаем базу данных прямо в разделе. Зато получаем при этом возможность он-лайн перемещать его с диска на диск.

это по задачу:
у вас тыща клиентов которых нужно нарезать на пяток тарифов
в ipfw это в простейшем случае:
1. десять правил настройки pipe
2. десять правил засовывания клиентов в pipe
3. одна или две таблички вида ip/mask N-pipe

всё ;]

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

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

>А насчет ресурсов и прочего - о порте ZFS (и OpenSolaris) на ARM слышали? А о ReadZilla и LogZilla? Спросите у Гугля ;-)

Насколько мне не изменяет мой склероз, для порта OpenSolaris на ARM была сделана соответствующая усечённая версия ZFS, которая по сути ZFS не является.

> это по задачу:
> у вас тыща клиентов которых нужно нарезать на пяток тарифов
> в ipfw это в простейшем случае:
> 1. десять правил настройки pipe
> 2. десять правил засовывания клиентов в pipe
> 3. одна или две таблички вида ip/mask N-pipe

> всё ;]


если я правильно понял задачу, то в пф это будет не больше правил.
1. для каждого тарифа табличка с айпишками клиентов на этом тарифе.
2. для каждого тарифа правило-классификатор в какую очередь альтекью пихать. соответственно, описания всех нужных очередей.
3. все?
таблички заполняем из файлов, вручную, скриптом из базы данных, от демона дхцп, как угодно - при этом все работает очень быстро (просмотр таблицы - это быстро), правил всего ничего.

>Сударь, не вы ли утверждали, что "даже FAT+LVM позволяет онлайн переместить раздел с одного винта на другой.", подразумевая при этом, по всей видимости, что в ZFS такой плюшки нет?

Нет плюшки в том смыле, что из ZFS нельзя вырвать собственно саму FS и вставить вместо неё FAT.

Я со вчерашнего дня пытаюсь донести мысль о том, что LVM не привязана к конкретной файловой системе, а потому сама является плюшкой для любой файловой системы.

ZFS в отрыве от той реализации файловой системе, что в ней есть, не существует - в этом её не недостаток, а разность с LVM.

Я же говорю, напрямую ZFS с LVM+(одна какая-то FS) сравнивать не имеет смысла. Преимущества LVM тут в том, что она именно предоставляет выбор конкретной ФС, а не навязывает её.

>Не компетентен в вопросе, дружище, в первую очередь тот, кто вот так вот сразу прыгать начинает. Я бы (на твоем месте) не был бы так уверен в таких словах. Тебе может куда-то прислать чуть-чуть конфига, и вывод pftop, для того, чтоб ты уверился в том, что именно ТЫ тут заблуждаешься?

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

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

Да, что ты говоришь. Перечитай еще раз свой пост, или ты как та собака все понимает, но (правильно)сказать не может.

>>Мысль насчет raw-раздела поясните, пожалуйста.

>Пожалуйста. Размечаем диск LVM'ом, создаём том, но НЕ форматируем его. Туда засовываем ораклиную базу. Профит - не тратим производительность компьютера на поддержание не нужного слоя "файловая система и один большой файл на ней, в котором находится база данных", а размещаем базу данных прямо в разделе. Зато получаем при этом возможность он-лайн перемещать его с диска на диск.

Спасибо. Это хороший пример. Однако, помимо профита есть и лоссы. Например, необходимость резервировать для снапшотов место заранее, и стоит зарезервировать чуть меньше, чем понадобится - и привет. Никогда с такими сюрпризами не сталкивались? Ничего, у вас еще все впереди ;-)

>2. для каждого тарифа правило-классификатор в какую очередь альтекью пихать. соответственно, описания всех нужных очередей.

а как это будет выглядить? концептик покажите :-)
и какая версия pf для него нужна

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

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

Это вам не глобальные опции монтирования.

> Какова важность целостности для хранения продуктов компиляции, если их можно перекомпилировать?

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

> Какова важность целостности при хранении очереди почтового сервера? Дойдёт повреждённое письмо, ну и ладно

А что если ошибка в этом поврежденном письме окажется незамеченной? Скажем, какая-нибудь сумма возрастет или уменьшится в старшем разряде?

> - каналы связи могут внести точно такую-же ошибку и в любом случае людям придётся связываться друг с другом и просить отправить письмо ещё раз.

Это в том случае, если ошибка окажется замеченной. А если нет - последствия могут наступить гораздо позже, и быть гораздо тяжелее, чем могли бы.

Плюс, ZFS дает возможность не только обнаруживать, но и исправлять ошибки...

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

>в принципе, отсутствие готового "шаблонизатора", что актуально для мелких и средних провов, - это единственная серьезная претензия к пф с моей стороны

ну вот собственно и договрились

особенности реализации естественно мне не нужны как и сам pf, у меня свои велосипеды ;]

меня просто не оставляла надежда, что в pf есть какаяти хитрая штука для этого случая, но она такая секретная, что об ней некто не знает(естественно я внимательно изучал документацию pf на этот счёт) и теперь я спокоен и не буду дергаться и плохо спать :]

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

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

>А что если ошибка в этом поврежденном письме окажется незамеченной? Скажем, какая-нибудь сумма возрастет или уменьшится в старшем разряде?

А что, сейчас от этого кто-нибудь застрахован? Гораздо выше вероятность, что кто-то похакает почтовый сервер и отправит нужное ему письмо с поддельными заголовками и телом письма. См. мой ответ выше, начиная со слов "Ой, боюсь-боюсь!"

Я вас понял, но не нужно переоценивать важность контроля целостности. Это неуловимый Джо, которого никто не видел, и который нафиг никому не сдался.

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