Луиджи Риццо (Luigi Rizzo) сообщил (http://lists.freebsd.org/pipermail/freebsd-ipfw/2009-June/00...) в списке рассылки freebsd-ipfw о том, что им совместно с Мартой Карбоне (Marta Carbone) было выполнено портирование пакетного фильтра ipfw и системы для ограничения пропускной способности dummynet на платформу Linux. Для загрузки доступны (http://info.iet.unipi.it/~luigi/dummynet/) как исходные тексты, так и готовые модули для Linux ядра 2.6.28, Ubuntu 9.04 и дистрибутива OpenWRT (для Broadcom BCM947xx/953xx ASUS WL-500g Premium).
Марта Карбоне - участница программы Google SoC 2009 работающая (http://socghop.appspot.com/student_project/show/google/gsoc2...) под руководством Luigi Rizzo над улучшениями в ipfw и dummynet.
URL: http://lists.freebsd.org/pipermail/freebsd-ipfw/2009-June/00...
Новость: http://www.opennet.ru/opennews/art.shtml?num=22266
а зачем ? им делать нечего ?
Затем, что ipfw - мощнейший инструмент (хотя его гибкость вызывает сложность в понимании и использовании). Например, один divert очень ценен, т.к. позволяет обработку пакетов в user-space.
> Например, один divert очень ценен, т.к. позволяет обработку пакетов в user-space.iptables ... -j QUEUE или NFQUEUE
Это, конечно, не отменяет преимуществ ipfw, просто для справки :)
> Затем, что ipfw - мощнейший инструментВы с айпитаблесами не попутали?Они могут почти все, но синтаксис чем-то напоминает язык программирования брэйнфак :)
>Вы с айпитаблесами не попутали?Они могут почти все, но синтаксис чем-то напоминает язык программирования брэйнфак :)Синтаксис может быть и не очень приятен, зато семантика гораздо лучше, чем у ipfw.
И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет iptables+iproute2+tc?
>Синтаксис может быть и не очень приятен, зато семантика гораздо лучше, чем
>у ipfw.Ну, привыкнуть можно.А если влом - ну так можно скопипастить :) или генератором правил, блин, сгенерить.Не понимаю я их проблем (кроме нежелания осваивать тулзень).
>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет
>iptables+iproute2+tc?Я что-то не думаю что они это осилят... впрочем ждемс.Так как любопытно.Не, не то чтобы я супер-спец по айпитаблесам, но что им + упомянутой связкой можно изобразить - я как минимум видел в роутерных прошивках.Вполне себе прилично получается вроде - я вот так сходу не смог придумать чего бы мне захотелось но не изображалось бы данной связкой :).Может у бздунов больше фантазии?
>
>Я что-то не думаю что они это осилят... впрочем ждемс.Так как любопытно.Не,
>не то чтобы я супер-спец по айпитаблесам, но что им +
>упомянутой связкой можно изобразить - я как минимум видел в роутерных
>прошивках.Вполне себе прилично получается вроде - я вот так сходу не
>смог придумать чего бы мне захотелось но не изображалось бы данной
>связкой :).Может у бздунов больше фантазии?У User294 очередлой линупсячий понос наступил...
Пример из жизни - Изобразите на iptables + tc аналог правил:
ipfw pipe 2000 config bw 5000Kbit/s queue 10Kbytes
ipfw pipe 2001 config bw 5000Kbit/s queue 10Kbytes
ipfw add 2000 pipe 2000 ip from any to any in via vlan99
ipfw add 2001 pipe 2001 ip from any to any out via vlan99особое внимание обращаю на то что тут используется ограничение _входящего_ трафика с привязкой к vlan.
Оцените количество правил которое вам потребуется для реализации тойже функциональности в tc, в связке tc + iptables?
как только уложитесь в 4 читаемых правила, а не 10-12 - покажите результат.
Добавляем правила огранечения по меткам. Далее средствами iptables ставим эти метки.
А теперь покажите мне в ipfw организовать хеш-фильтры http://www.opennet.ru/docs/RUS/LARTC/x1661.html
>Добавляем правила огранечения по меткам. Далее средствами iptables ставим эти метки.
>А теперь покажите мне в ipfw организовать хеш-фильтры http://www.opennet.ru/docs/RUS/LARTC/x1661.htmlipfw add pipe tablearg all from table(1) to any
и/или
ipfw pipe 1 config ... mask 0x00000fff (динамические пайпы)
>ipfw add pipe tablearg all from table(1) to any
>
>
>ipfw pipe 1 config ... mask 0x00000fff (динамические пайпы)А теперь вложенные хеш-фильтры. И да еще как мне там дисциплины крутить? Использовать altq? :]
>Пример из жизни - Изобразите на iptables + tc аналог правил:
>ipfw pipe 2000 config bw 5000Kbit/s queue 10Kbytes
>ipfw pipe 2001 config bw 5000Kbit/s queue 10Kbytes
>ipfw add 2000 pipe 2000 ip from any to any in via vlan99
>ipfw add 2001 pipe 2001 ip from any to any out via vlan99tc qdisc add dev eth1 root handle 1: htb default 10
tc class add dev eth1 parent 1: classid 1:10 htb rate 5mbit burst 15k
tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:10
iptables -A PREROUTING -t mangle -i eth1 -j MARK --set-mark 1>особое внимание обращаю на то что тут используется ограничение _входящего_ трафика ...
Про входящий трафик вам уже все разеснили
>как только уложитесь в 4 читаемых правила, а не 10-12 - покажите
>результат.Как только велосипед сможет покрыть возможности и комфорт автомобиля, тогда и покажем как с помощью tc можно в то же количество строк можно описать то, что умеет делать dummynet.
Более богатые функции предполагают более трудное их использование.
>> Более богатые функции предполагают более трудное их использование.можешь как-то аргументировать?
>>> Более богатые функции предполагают более трудное их использование.
>
>можешь как-то аргументировать?Больше функций - больше рычагов управления ими. Примеры: мотоцикл - легковой автомобиль - самолёт - вертолёт, лопата - экскаватор, музыкальный проигрыватель - пульт ди-джея радиостанции - синтезатор - компьютер. Я думал не нужно объяснять очевидное. Или ты из тех, кто считает компьютер бытовым прибором вроде пылесоса? Или ты пилотируешь Боинг имея водительские права категории B?
>>>> Более богатые функции предполагают более трудное их использование.
>>
>>можешь как-то аргументировать?
>
>Больше функций - больше рычагов управления ими. Примеры: мотоцикл - легковой автомобиль
>- самолёт - вертолёт, лопата - экскаватор, музыкальный проигрыватель - пульт
>ди-джея радиостанции - синтезатор - компьютер. Я думал не нужно объяснять
>очевидное. Или ты из тех, кто считает компьютер бытовым прибором вроде
>пылесоса? Или ты пилотируешь Боинг имея водительские права категории B?летать на автомобиле сложнее чем на самолёте, любитель метафор :)
>летать на автомобиле сложнее чем на самолёте, любитель метафор :)Про айпитаблесы он все правильно говорит.Геморройны в управлении.Но умеют дофига всего.И - да, управлять автомобилем труднее чем велосипедом.Для езды на велике не надо экзамены сдавать - сел и поехал.
Я не совсем понимаю как вы предлагаете сравнивать пакетый фильтр с связкой пакетный фильтр + управление роутингом + шейпер ? Странное сравние - теплого с мягким.
Может вы перепутали и имели ввиду ipfw+dummynet с iptables+tc? Так опять же не коректное сравние.
tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход).
В этом ключе iptables+tc - правильнее сравнивать с ipfw + altq (да да, dummynet это не единственный шейпер с которым в связке может использоваться ipfw).
Но судя по всему вы не разбираетесь в вопросе - поэтому приводить вам аргументы не стоит.
Разбиритесь сначала что вы хотите сравнить - а потом поговорим.
>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего
>трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход).Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только на исходящем трафике и безразници где это в фряшном dummynet или линуксовый iproute.
Да да именно для вас tc входит в состав пакета iproute.
>>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего
>>трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход).
>
>Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только
>на исходящем трафике и безразници где это в фряшном dummynet или
>линуксовый iproute.Еще один, не знающий, как работает TCP. Ситуация: домашний сервер, который NAT для еще двух машин. Нужно распределить поток так, чтобы сервер не отжирал бесконтрольно полосу, не оставляя ничего домашним машинам, и чтоб они его и друг друга тоже. Как? С только исходящими фильтрами - это невозможно, сервер будет неучтен. Но вполне очевидно, что входящий шейпер на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера.
>Да да именно для вас tc входит в состав пакета iproute.
Представьте себе, он в курсе, и даже знает, как он устроен внутри :)
>Еще один, не знающий, как работает TCP.Будьте любезны не тыкать мне. Правила хорошего тона в общении еще не кто не отменял.
Как работает TCP я и без вас знаю>Как? С только исходящими фильтрами -
>это невозможно, сервер будет неучтен.И после этого вы меня будете учить :-)
>Но вполне очевидно, что входящий шейпер
>на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается
>еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера.ВОТ ЭТО УЖ ВООБЩЕ НИ КАК НЕ ОЧЕВИДНО - про входящий трафик я уже писал ниже.
Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет.
>>Еще один, не знающий, как работает TCP.
>
>Будьте любезны не тыкать мне. Правила хорошего тона в общении еще не
>кто не отменял.Я вам пока еще не тыкал, и вообще веду себя более корректно, чем ваш уровень знаний этого заслуживает.
>Как работает TCP я и без вас знаю
Что, правда? И про SACK, и про congestion control знаете? И как работают алгоритмы RED/GRED, тоже знаете? А ведь там та же основа.
>>Как? С только исходящими фильтрами -
>>это невозможно, сервер будет неучтен.
>
>И после этого вы меня будете учить :-)ОК, расскажите же мне, как пошейпить пришедший самому серверу (т.е. его собственный IP) на eth0 входящий трафик, если исходящие фильтры висят только на смотрящем во внутреннюю сеть к клиентам eth1 ? А на сервере запущен торрент-клиент, который хорошо так кушает канал, если не пошейпить :)
>>Но вполне очевидно, что входящий шейпер
>>на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается
>>еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера.
>
>ВОТ ЭТО УЖ ВООБЩЕ НИ КАК НЕ ОЧЕВИДНО - про входящий трафик
>я уже писал ниже.Бред вы писали. Я щас вам эту очевидную схемку нарисую, раз уж сами не можете додуматься, пусть у сервера адрес 1.2.3.4:
[канал к провайдеру]-----[eth0]-----[сам сервер]----[eth1]-----[внутренние машины]
Здесь входящий трафик, который и надо шейпить, идет слева направо, с исходящими фильтрами возможно шейпить лишь на eth1, но там не будет трафика, предназначенного к 1.2.3.4, только к внутренним. А на eth0 идет сумма трафика, для 1.2.3.4 и для внутренних машин, вот его-то в целом и надо балансировать. И вот та самая ОЧЕВИДНАЯ замена:
[провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины]
Видно, что если поставить ПЕРЕД сервером еще один роутер, исходящие фильтры на eth1 этого другого роутера будут ПЕРЕД eth0 нашего качающего сервера, и будут включать в себя ВЕСЬ трафик, потому что этот виртуальный роутер не будет иметь трафика, предназначенного для себя.
И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить входящие шейпящие фильтры на eth0 сервера, т.е. в направлении слева направо, т.е. просто вклиниться в этот поток внутри eth0 - ибо зачем нам ставить еще один роутер для такой простой задачи, dummynet ведь умеет.
Я достаточно понятно разжевал?
>Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет.
Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно лишь направление. По схеме выше видно, что случаи эквивалентны, он выровняет и в случае резки на входе того роутера.
>И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить
>входящие шейпящие фильтры на eth0 сервера, т.е. в направлении слева направо,
>т.е. просто вклиниться в этот поток внутри eth0 - ибо зачем
>нам ставить еще один роутер для такой простой задачи, dummynet ведь
>умеет.согласен
а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)
>согласен
>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные пакеты потерялись. Что дальше?
А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию.
>>согласен
>>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)
>
>Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные
>пакеты потерялись. Что дальше?Что есть флуд на входящем канале - конкретнее.
>
>А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а
>потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию.Телепат ?
Кто тебе сказал, что не буду шейпить в обе стороны ?
Еще как буду.
>Кто тебе сказал, что не буду шейпить в обе стороны ?как?
пример выше - фикция. виртуальный роутер - уже внутри сети. с таким же успехом шейпится исходящий трафик для внутренних машин.
только лишняя нагрузка на роутер.
поставьте там хоть 1000 машин - это никак не повлияет на тот единственный входящий интерфейс.
а там пришло 10 пакетов - обработай, 100 - тоже обработай, 1000 - тоже,... система перестала справляться. :-D
>>>согласен
>>>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)
>>
>>Ну зашейпил ты входящий канал, а там 99% флуда. Буфер переполнился, полезные
>>пакеты потерялись. Что дальше?
>
>Что есть флуд на входящем канале - конкретнее.Ну например у тебя NAT-роутер. Изнутри наружу установлено несколько соединений. А тут бац - и кто-то снаружи заливает на 25 закрытый на NAT-шлюзе TCP-порт кучу говна. Это говно переполняет входной буффер и в результате в общей массе говна начинают растворяться полезные пакеты, связанные с сессиями, установленными изнутри.
>>А если будешь шейпить исходящий трафик, то сначала ты отфильтруешь флуд, а
>>потом уже положишь в буфер и будешь потихоньку отдавать полезную информацию.
>
>Телепат ?
>Кто тебе сказал, что не буду шейпить в обе стороны ?
>Еще как буду.Смысл не в этом, а в том что у тебя во входном буфере флуд будет вытеснять полезные пакеты. А если ты будешь шейпить только на исходящем интерфейсе, то в буфер отдачи попадёт только полезная информация, а говно зарежется фаерволлом ещё до попадания в буфер.
>>Что есть флуд на входящем канале - конкретнее.
>
>Ну например у тебя NAT-роутер. Изнутри наружу установлено несколько соединений. А тут
>бац - и кто-то снаружи заливает на 25 закрытый на NAT-шлюзе
>TCP-порт кучу говна. Это говно переполняет входной буффер и в результате
>в общей массе говна начинают растворяться полезные пакеты, связанные с сессиями,
>установленными изнутри.Эмммм.
А ты firewall/nat вообще настраивал хоть раз в жизни ?
Потому как если настраивал, тогда бы знал что залить на закрытый TCP-порт кучу не получится.
Вообщем даже если нет никакого firewall, то тоже не получится :)Можно за-DDOS-ить роутер.
Но если тебя начнут DDOS-ить, то никакой шейпер тебе не поможет.
>>Телепат ?
>>Кто тебе сказал, что не буду шейпить в обе стороны ?
>>Еще как буду.
>
>Смысл не в этом, а в том что у тебя во входном
>буфере флуд будет вытеснять полезные пакеты. А если ты будешь шейпить
>только на исходящем интерфейсе, то в буфер отдачи попадёт только полезная
>информация, а говно зарежется фаерволлом ещё до попадания в буфер.Ты то ли прикалываешься, то ли просто не знаешь о чем говоришь.
Ну с чего ты взял, что у меня только шейпер и нет firewall ?
Сначала firewall отбросит весь мусор.
Потом что останется, пойдет через один или несколько шейперов.
>Потому как если настраивал, тогда бы знал что залить на закрытый TCP-порт
>кучу не получится.Да что вы говорите?А я всю жизнь думал что сначала вам по вашему каналу пакеты все-таки прилетят.А потом вы сможете их грохнуть на вашем файрволе если вдруг захотите, на основании каких-вам-там-удобно критериев.Как и отполисовать при передаче дальше, если вам это надо.Проблемка у вас будет ровно одна - эти пакетики канал идущий к вам уже заняли под себя на некое время.Потенциально обломав или затормозив например прохождение более полезных пакетов, если вдруг этого добра приехало слишком много.
Какие пакетики на закрытый TCP-порт ?
Да еще чтобы траффика было много ?
Если это не DDOS-атака, то пакеты прилетят только SYN, а они мелкие и канал забить ими очень трудно.
Если SYN-пакетов много, то это уже DDOS-атака и вообще ничего не поможет.
>Какие пакетики на закрытый TCP-порт ?Обычные.С технической точки зрения - всем глубоко похрену что там шлется в вашу сторону.Поэтому - в вашу сторону можно выстрелить как бы любые пакеты, включая любой набор пактов из протокола TCP и они до вас долетят.И в принципе ну никто не обязывает ремоту с ножом к горлу выплевывать эти пакеты в вас по общепринятым правилам - можно в вас кидать что угодно.Можно даже в правила RFC впихнуться если слать SYN пакеты оптом, допустим(хотя можно и любые иные).О том что это были пакеты на порт который у вас порт закрыт (или что эти пакеты не соответствуют установленной TCP сессии) знает только стек протоколов вашей операционки (ну или там ваш файрвол, etc).И вот когда оно выгребет эти пакетики из канала (канал ессно будет озадачен передачей этих пакетов энное время) - стэк протоколов сможет увидеть что да, пакет был на закрытый порт(или вообще не соответствует никакой TCP сессии), прибить гада!Ну и далее - или нифига (можно тихо убить пакет на закрытый порт файрволом) или отлуп RST пакетом (стандартное дефолтное действо) для информирования ремоты о этом факте или там еще чего (практикуются враки файрволом по ICMP о недоступности хоста, сети, ... например).Проблема при этом ровно одна - если пакеты вам шлют, вы их будете получать.И тощую соску от прова до вас они собой займут.Плевав на вашу недо-полисовку.А после прохождения по медленной соске вы их конечно же сможете разгрести, понять что это было на закрытый порт и даже если хотите - прибить, да.А вам от этого станет легче?Канал то уже был ими засран ими некое время а трафф мог вылезти за рамки желаемой полисовки:P.Возможно - в ущерб более полезным входящим пакетам если такого хлама - много.На полисовку оно покладет с прибором - пришлют не "сколько вы просили" а "столько сколько захотели" и вы с этой вашей недо-полисовкой ничего с этим поделать не сможете.Т.е. полисовка по сути идет лесом.
>Да еще чтобы траффика было много ?
Элементарно, Ватсон.Просто тупо шлем вам пакеты до упора.Наплевав на ваши RST пакеты (а также молчанку, враки файрвола что хост или сеть недоступна и прочая).И вы их будете получать.И выгребать.И, черт возьми, сколько пошлют и сколько из этого пролезет - столько и выгребете.А у вас варианты есть?Вы, конечно, можете потом убить гумно.А толку то?Ну да, ваша 100 мбит локалка будет чистой.Зато 10Мбит соска в интернет будет засрана пакетами.Много ли вы выиграли сэкономив в 100 мбит локалке 10Мбит?Да нихрена вы не выиграли - проблемы (например, барахловая работа VoIP и прочая) у вас будут от забитости вашей соски в интернет, а вовсе не... :)
>Если это не DDOS-атака, то пакеты прилетят только SYN, а они мелкие
В общем случае можно слать в вас любые пакеты.Можно и крупные.Или много мелких.То что они на закрытый порт или не соответствуют никакой TCP сессии - только вы и ваше добро и знаете.И то - только *после* того как вы их получите.Да, можно из мстительно прибить.А толку?Свое место в тощем канале они уже заняли.Возможно вместо более ценных входящих пакетов (e.g. VoIP).И фиг вы чего с этим сделаете, мистер тормоз.Вот пров может подыграть, отполисовав со своей стороны трафф до пихания в вашу узкую соску и даже приоретизировав некие пакеты в ущерб иным пакетам.Вот только для прова это будет полисовка *исходящего* траффика в вашу сторону.Прикиньте? :).С вашей стороны вы не сможете настолько же гарантированно и полноценно изобразить шейпинг и приоретизацию того что валится на вход, как максимум только некий эрзац с вагоном допущений и ничего не гарантирующий по большому счету.
>и канал забить ими очень трудно.
Не вижу проблем.В конечном итоге - можно слать любые пакеты.Все-равно о том что они были на закрытый порт или не соответствовали никакой TCP сессии знаете только вы.И то - вы узнаете это только после :))) того как они заняли собой вашу тощую соску :)
>Если SYN-пакетов много, то это уже DDOS-атака
DDoS подразумевает распределенную атаку.В данном случае никакой распределенности нафиг не надо.Надо всего-то не сильно тощий канал который сможет в сумме выбить траффик в вашем канале за пределы вашей желаемой полисовки.После чего скорее всего начнутся потери входящих пакетов, рост латентности и прочая радость.И как бы если пров не подыграет - пакеты, допустим, VoIP будут теряться наравне с пакетами флуда.И если меня без вопросов устроит что вы отбросили 50% флуда, вас очень врядли устроит что заодно отбросилось и 50% VoIP пакетов летящих к вам.Провадет со своей стороны мог бы подыграть отполисовав трафф до пихания в вашу соску - у него каналов больше и забить из намного труднее чем одну хилую соску к клиенту.Для прова это как раз и будет полисовка *исходящего* (в вашу сторону) траффа из его сравнительно быстрой сети в сравнительно медленный канал.Так же как вы можете полисовать обратный траффик.И вот такая полисовка - относительно честная.В том плане что как максимум можно закосить под иной тип пакетов.Но если накладывается допустим некий лимит на общий бандвиз траффа, этот лимит обойти не выйдет.
>и вообще ничего не поможет.
Ну вообще-то полисовка траффика провом до некоторой степени могла бы помочь.Например, те же VoIP пакеты пров может пихать в вашу соску первым делом а остальное - как выйдет.При необходимости отбрасывая лишки, etc.Да, это возможно вызовет некоторые трудности для конектящихся к вашему серверу клиентов.Но тем не менее, ему и так и сяк попа а вот критичный сервис который более приоритетный (e.g. VoIP) при этом выживет и будет работать даже, если отполисовать правильно и каналов провайдера хватило(а у него они как правило намного толще и их больше).
ЗЫ вроде бы все в пределах обычной человечьей логики и понимания того как летают пакеты и где узкие места.
ЗЗЫ а вы что, никогда не видели например утилитки генераторов пакетов которые просто шлют то что им сказали слать, глубоко наплевав на любые ответы ремоты?Тоже мне, сетевики фиговы :D
Всё-таки вам очень тяжело объяснить очевидное.Хорошо, попробуем описать ситуацию вот так.
Есть внешний толстый канал в 100 мегабит/с. Есть 1000 клиентов, каждый может принимать со скоростью 100 килобит/с. Представим что у роутера на входе стоит буфер в 10 мегабайт. Представим что клиенты слушают радио или гоняют у себя IP-телефонию.
И тут кто-то резко вливает в канал 10 мегабайт мусора, адресованному одному из клиентов. Входной буфер на роутере переполнился и все дальнейшие пакеты будут отбрасываться, не смотря на то, что они адресованы и другим клиентам тоже.
Что будет делать роутер? Медленно отдавать эти 10 мегабайт одному клиенту со скоростью 100 килобит/с. Входной буфер роутера будет опустошаться в течение (1000000*8/100000=) 800 секунд. В это время все остальные клиенты встанут колом, поскольку входной буфер роутера всё это время будет медленно-медленно опустошаться, а новые пакеты для остальных клиентов принимать практически не будут.
Теперь, если у вас есть немного логики, представьте если роутер будет заниматься шейпингом на исходящих интерфейсах. Эти 10 влитых неизвестно кем мегабайт попадут в буфер отдачи только одного из клиентов, пострадает только он, остальные после небольшого лага будут продолжать нормально работать. Ситуация хоть немножко прояснилась?
Да, действительно, очень тяжело объяснять очевидное, когда собеседник имеет очень бредовые представления о работе роутеров и шейперов.Вот эта ваша ситуация: один входной буфер на 10 Мегабайт и несколько выходных, по буферу на каждого клиента - не имеет НИКАКОГО отношения к реальности.
Входной буфер маршрутизатора обычно имеет емкость в несколько десятков пакетов (на фре по умолчанию net.inet.ip.intr_queue_maxlen=50), сетевуха тоже много их держать не может, т.е. по факту он принимает их со скоростью среды.
Любые буфера бОльших размеров появляются, только если вы вводите шейпер. Однако цель шейпера - как раз избежать ситуации "один забил всех", поэтому, если мы вешаем по буферу на клиента, шейпер тут же их сортирует, в какой отправить, в результате избыток пакетов того клиента просто будет дропнут, как только не влезет в его буфер, буфера остальных - не пострадают.
Еще раз, другими словами: описанного вами входного большого буфера НЕ СУЩЕСТВУЕТ, и если мы вешаем шейпер на вход, в данном случае dummynet в ipfw, он их тут же на входе ровно точно так же рассортирует по буферам клиентов, все счастливы.
>Еще раз, другими словами: описанного вами входного большого буфера НЕ СУЩЕСТВУЕТ, и
>если мы вешаем шейпер на вход, в данном случае dummynet в
>ipfw, он их тут же на входе ровно точно так же
>рассортирует по буферам клиентов, все счастливы.Как же он рассортирует пакеты по выходным буферам, если решение о том, по какому маршруту пойдёт пакет, ещё не принято? А если он всё-таки рассортирует, то вы не находите что это уже не входной буфер, а выходные?
Тогда объясните мне в чём отличие таких входных буферов в ipfw от выходных буферов в tc? В чём тогда вообще соль так рьяно отстаиваемого подхода на шейпинге пакетов на входе?
>Тогда объясните мне в чём отличие таких входных буферов в ipfw от
>выходных буферов в tc? В чём тогда вообще соль так рьяно
>отстаиваемого подхода на шейпинге пакетов на входе?Уважаемый www2, можно я обьясню :D
Видите ли в чем дело, просто nuclight уже осознал что был не прав. А заевить это общественности после своих надменных постов слабо. Вот он бошку и дурит всем, своими постами.
дык и нельзя.
объем входящего трафика всё равно этим не ограничешь. сколько из вне пришло, столько пришло. вывалели из вне 100Mb/s пакетов, так вывалили - разгребай дальше сам. :-D
хоть 20 виртуальных роутеров эмулируй. это внутреннее дело внутренней сети с внутренними виртуальными роутерами.но хоть как-то рулить (нагрузку уже внутри своей сети) этот способ подходит.
будет работать до тех пор, пока входящий трафик не будет стремиться к 100% нагрузки входящего интерфейса. а дальше - резкое увеличение нагрузки на эти "роутеры", потери пакетов и т.д.другой вопрос - а напуркуа ограничивать что-либо, если нагрузка позволяет? в 21 веке унлим всё-таки! :-D
>а то некоторые тут уверяют, что шейпить входящий траффик нельзя :)Картина маслом: я шлю вам SYN пакеты (или какие угодо иные пакеты долетающие до вас, не принципиально) на всю толщину вашего канала.На ваши потуги изобразить что-то там средствами TCP - кладу хрен.Внимание, вопрос: много ли будет толку с вашего недо-шейпинга?Канал у вас засрется, мои пакеты будут валиться вам на вход по сравнительно узкому каналу без какой-либо приоретизации - наравне с полезными для вас, сильно уронив их скорость доставки и, возможно, вызвав солидные потери.Это не шейпинг, это так, эрзац.
Мде...Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и был прав, а когда бОлшая часть трафа составляют tcp-сессии то проблем нет.
Когда у тебя весь канал забит флудом то тебе не то что шейпер не поможет, тебе ничего не поможет кроме как помощь провайдера.
И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил.
Прекращай свои интелектуальные способности на весь инет демонстрировать.
больша часть "трафа" - http и иже с ним.
толку что он tcp. соединение устанавливается и рвётся.
в любом случае, всё что Вы можете - это пропускать его в локалку или нет (в этот момент он уже припёрся и находиться в буфере), а также пропускать ответ или нет, или медленно пропускать.
входящий же пакеты сваляться к Вам на той скоросте передающей среды - см. "Физический уровень" http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
>И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил.входящий, багородный дон, входящий. речь только о нём.
кстати, очень заметно, кто ниасилил.
>Прекращай свои интелектуальные способности на весь инет демонстрировать.вот именно.
>больша часть "трафа" - http и иже с ним.
>толку что он tcp. соединение устанавливается и рвётся.[...]
>>Прекращай свои интелектуальные способности на весь инет демонстрировать.
>
>вот именно.Действительно, прекращайте. С понятием "slow start" в tcp вы явно не знакомы, если, по вашему, быстро закрываемые сессии невозможно шейпить. Ну-ну. Сходите, что ли, Стивенса почитайте, хотя бы.
когда ж ты угомонишься то?
ну пролетел ты, с кем не бывает? :-D
>Действительно, прекращайте. С понятием "slow start" в tcp вы явно не знакомы,Есть одна проблема - все это допускает что все ремотные юзеры белые, пушистые и делают ровно то что вы им скажете.Т.е. все это очень эфемерно и негарантированно.Работает только с конкретными типами траффика, просто обходится и нифига по большому счету не гарантирует.Т.е. завалить вам допустим работу VoIP невзирая на якобы шейпинг и якобы приоретизацию - не вопрос.Т.е. честной полисовки на вход с приемной стороны тощей соски в общем то не получается.Получается некое подобие как максимум.Без реальных гарантий качества сервиса и с рядом ограничений и допушений.
>Благородный дон, если бы весь трафик состоял из атак то может быть ты бы и был прав, а
>когда бОлшая часть трафа составляют tcp-сессии то проблем нет.Проблем нет ... ровно до тех пор пока удача улыбается вам лицом.А если повернется попой (траффик окажется "не тот" или кто-то будет гавнюком и не будет с той стороны провода кооперативен с вашими потугами что-то этакое изобразить) - проблемы у вас будут.Посему это именно недо-шейпинг.Шейпинг исходящего траффа в узкий канал дает кой-какие гарантии и приоритеты там не липовые а реальные - наиболее приоритетные пакеты первыми полетят в медленный канал, остальные подождут, а при нужде и выкинутся в нужном количестве.Сие позволяет достичь какой-то предсказуемости и гарантий и там пофиг - UDP, TCP, ICMP или что там еще - не принципиально.В отличие от довольно халтурных потуг что-то там поиметь довольно левыми методами требущие весьма вольных допущений о природе траффа и кооперативности ремотных систем насчет потуг это регулировать.Эрзац - получается.А вот честно и гарантированно как с исходящим - фиг!Только если кто-то с другой стороны канала зашейпит и отполисует ДО впихивания это в медленный канал к вам.А после - уже поздно что-то там полисовать в общем случае.
>Когда у тебя весь канал забит флудом то тебе не то что шейпер не поможет,
>тебе ничего не поможет кроме как помощь провайдера.У провайдера как правило суммарная емкость каналов на порядки превышает скорость типового канала до пользователя.Посему грамотный шейпинг и полисовка с той стороны канала может в принципе решить эту проблему - путем отстрела или придерживания "неправильных" пакетов в пользу "правильных".Чем собственно и занимаются при шейпинге и полисовке траффа по нормальному.При этом в нормальном исполнении (2 железки с обоих сторон медленного канала честно шейпят и полисуют свое исходящее направление) все будет так как надо.С какими-никакими предсказуемыми параметрами и возможностью что-то гарантировать и реально доставить одни пакеты, частично пожертвовав другими.С одной стороны - не получится нормально.Получится эрзац который никому ничего не гарантирует по большому счету.И если в вас прилетит 5 мегов левых пакетов в 20 мбит канал - может так получиться что вы пару секунд будете левак выгребать а только потом "приоритетные" VoIP пакетики получите.А вот реальное время ждать вас разумеется при этом не станет.
> И не надо говорить что шейпить tcp-трафик невозможно только потому что ты это не осилил.
Ха-ха, мне нравится такая аргументация :).Ну, знаете, если я пришлю вам эн мегабит SYN пакетов (или любых иных пакетов протокола TCP) - это тоже с формальной точки зрения TCP траффик.А вот отполисовать его вы обломаетесь если я буду некооперативен на этот счет и положу на ваши потуги болт.А, собственно, что мне запретит просто кидать в вашу сторону пакеты?Отказаться от их получения вы в общем случае не сможете.Канал оно займет точно так же как и любой иной траффик, не факт что менее приоритетно чем нужные вам пакеты(если пров не подыграет с его стороны).Полисовка получается весьма лажовая.А теперь вы пробуете сделать то же самое с честной полисовкой исходящего траффа и понимаете разницу :).При этом более приоритетные пакеты (например VoIP) будут отправлены раньше.А общая скорость потока может быть реально огранчена - отбросом "лишнего", если его продолжают валить быстрее чем разрешено :)
> Прекращай свои интелектуальные способности на весь инет демонстрировать.
Так это... а конструктивные аргументы будут? :D
>Мде...
>
>Благородный дон, если бы весь трафик состоял из атак то может быть
>ты бы и был прав, а когда бОлшая часть трафа составляют
>tcp-сессии то проблем нет.
>
>Когда у тебя весь канал забит флудом то тебе не то что
>шейпер не поможет, тебе ничего не поможет кроме как помощь провайдера.И пров тоже не поможет :) потомукак его канал тоже флудом забит :)
>И пров тоже не поможет :) потомукак его канал тоже флудом забит
>:)Забить прововские каналы флудом труднее чем одну тощую соску.Которую обычно и хотят отполисовать потому что в нее то все и упирается.
А я что где-то говорил, что нельзя за-DDOS-ить роутер ?
>А я что где-то говорил, что нельзя за-DDOS-ить роутер ?Это строго говоря не ддос (сие не обязано быть распределенной атакой, ни даже syn-пакетами), просто кому-то достаточно проявить некооперативность насчет ваших потуг, наплевав на ваши попытки уменьшить скорость потока такими методами.При этом поток вылезет за заданные рамки и вы тем более не можете контролировать - чего вам нужнее а что можно отбрость.Так что в случае чего - voip и прочая будут терять пакеты точно так же как и остальное.Если пров не поможет полисовкой со своей стороны канала.Это не DDoS.Это элементаное покладание на лажовую полисовку которая зависит от кооперативности ремоты на этот счет.И вылезти за заданные вами пределы по зубам даже единичной ремоте если у нее канал толстый.И какой толк от задачи пределов если они только в идеальных условиях работают?
Попадается некооперативная ремота - полисовка идет лесом.С честной полисовкой (исходящий трафф в узкий канал) сие проблемой как бы не является (более приоритетные пакеты все-равно пролетят раньше а остальное - как получится, отбрасываясь по мере необходимости и общая скорость потока может оставаться не выше заданной, с некими гарантиями на этот счет, которые не идут лесом и при потугах флудерасов и прочая).
>Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно
>лишь направление.Вот только блаародный дон упускает несколько моментов...
1) В природе есть не только TCP.
2) Предполагается что ремота кооперативна и соблюдает правила игры.Что как-то не гарантированно.Мало чтоли ли malicious фруктов на свете и прочих неожиданностей?
3) По большому счету от ВАС нихрена не зависит в каком порядке в вашу сторону выдавит пакеты провайдер в вашу соску (как максимум, можно например договориться с провайдером насчет приоретизации определенного траффа в вашу сторону, etc).Поэтому ситуация когда вам пришлют сначала 5 мегов гумна а только потом VoIP пакеты которые вы так ждали - вашим шейпингом не исключается нифига.С соответствующими последствиями для латентности VoIP, разумеется.Т.к. сначала вы будете получать по тощей соске 5 мегов гумна а только потом - "приоритетные" с вашей точки зрения пакеты.При том соска обычно сильно тоньше чем LAN и время профуканное на вот это будет на порядки больше чем время которое вы там выиграете отприоретизировав пакеты выплюнутые в сторону LAN.Итого?Идея шейпить траффик на вход может и красива.Но достаточно своеобразно работает в типовой ситуации, когда на вход относительно тощая (по сравнению с скоростью LAN) соска вносящая основные задержки, а после шейпящего девайса - скоростная LAN.Шейпить пакеты на прием было бы намного эффективнее в совсем другом месте.Как правило нихрена вам не подконтрольном - с другой стороны соски, только это уже на совести провайдера, а вы по этому поводу сделать в общем то мало что можете.Разве что с провайдером договориться.А то что с той стороны канала соблюдают правила игры - не гарантированно.Могут например начать вдувать вам N мегабит syn-пакетов в одностороннем порядке.Не ожидая от вас ответ.И толку от вашего шейпинга при этом?Вот шейпинг и правильная приоретизация с другой стороны тощей соски могла бы иной раз и поменять картину, да (если каналов провайдера хватит а вашей тощей соски уже нет).Только это не с вашей стороны тощей соски рулится...
>>Ну да. Но TCP абсолютно пофиг, где именно его резать, ему важно
>>лишь направление.
>
>Вот только блаародный дон упускает несколько моментов...
>1) В природе есть не только TCP.Ну и? :) Протоколы/приложения, которым не пофиг, организуют свои собственные механизмы congestion control. А которые нет, тех либо мало в общей доле, либо для них организуются специальные политики шейпинга.
>2) Предполагается что ремота кооперативна и соблюдает правила игры.Что как-то не гарантированно.Мало
>чтоли ли malicious фруктов на свете и прочих неожиданностей?Ыыы. Идите-ка почитайте RFC. Если ремота не будет в таких вопросах кооперативна, у неё просто самой ничего не будет работать. Если же идут атаки - это вообще совершенно отдельный случай, который в этом разговоре - как собаке пятая нога.
>3) По большому счету от ВАС нихрена не зависит в каком порядке
Я не стал этот бред цитировать, уже разобрал его в комменте про буфер размером в 10 мегабайт.
>Итого?Идея шейпить траффик на вход может и красива.Но достаточно своеобразно работает в
>типовой ситуации, когда на вход относительно тощая (по сравнению с скоростьюОчень странно, почему же у меня всё прекрасно работает? :)
>А то что с той стороны канала соблюдают правила игры - не
>гарантированно.Могут например начать вдувать вам N мегабит syn-пакетов в одностороннем порядке.Не
>ожидая от вас ответ.И толку от вашего шейпинга при этом?Вот шейпингМолодой человек, вы путаете две совершенно разные ситуации - шейпинг, рассчитанный на _нормальную_ работу, и DoS/DDoS-атаку. Если вам полностью засрали входящий канал - вам ТОЧНО ТАК ЖЕ не поможет и шейпинг на исходящем интерфейсе. А весь разговор ведётся как раз про разницу входящего и исходящего.
>Ну и? :) Протоколы/приложения, которым не пофиг, организуют свои собственные
>механизмы congestion control.Допустим есть VoIP.Как правило - UDP.Ему не пофиг латентность и потери пакетов.И его логично приоретизировать.На исходящее - фигня вопрос.А вот на вход с вашим недо-шейпингом ничего не выйдет.
>А которые нет, тех либо мало в общей доле,
Зато важные штуки бывают, типа VoIP например.
> либо для них организуются специальные политики шейпинга.
А зашейпьте-ка с вашей стороны банальный ping -f присланый снаружи в ваш тощий канал?Вот и посмотрим как ваш кульный шейпер на вход отработает, хе-хе ;).Что?Он будет выгребать столько сколько отправят или сколько пропихает канал?И даже возможно полезные пакеты (e.g. VoIP) просрутся или задержатся?Ну так какой же это тогда шейпинг и полисовка?Это так, фигня какая-то :)
>Ыыы. Идите-ка почитайте RFC. Если ремота не будет в таких вопросах кооперативна,
>у неё просто самой ничего не будет работать.И что?А кто сказал что ремоту это вообще смущает?Если ремота скажем поставила цель испортить вам компот - это ремоте похрену.А интернет как бы уже давно не детская площадка для игры в песочек, там и поднасрать могут запросто.А также возможны разные веселые методы покладания на вашу недо-полисовку.Например, завернуть все TCP конекции в openvpn гуляющий по UDP.Далее ваша полисовка на вход немножко отправится лесом т.к. с точки зрения полисовщика будут удп-пакеты, которым не больно то окна потвикаешь и SACKов у них как бы нет, а то что там внутрях - кто ж его знает? :).С честной полисовкой так не катит.Как максимум можно проапгрейдить свой класс траффика.Но, например, вылезти за глобальный лимит скорости шейпера - проблематично.Посему нормальный шейпинг - именно вот так.На *исходящее* направление.
А так - допустим я хочу вам завалить VoIP.И введу ping -f на своей машине с толстым каналом.Вас устроит что у вас начнут гробиться VoIP пакеты в пользу бесполезного ICMP флуда оптом который займет канал на равных с VoIP если с той стороны канала не подыграют?Ну и були толку с вашей "полисовки" если она от одной команды выходит за лимиты и начинают теряться полезные пакеты?
>Если же идут атаки
Это не атаки.А просто целенаправленное забивание на халтурно сделаную полисовку работающую с левыми допущениями. См. например пример с openvpn - так можно некисло проапгрейдить себе скорость скачки у таких тупорылых полисовщиков которые с чего-то вдруг возомнили что можно нормально шейпить скорость с приемного конца медленной соски :)
>- это вообще совершенно отдельный случай, который в этом разговоре
>- как собаке пятая нога.Ну я вам вон выше нарисовал менее атакерский случай - просто апгрейд скорости скачки путем юзания openvpn до своего хоста например :).При этом даже не требуется класть хрен на RFC, если уж вас это так смущает :).По сути - это просто нахальный абузеж вашей халтуры в полисовке.Называть это атаками - жирновато.Любой дятел с ping -f и более толстым чем у вас каналом - хакиръ чтоли?!Ха-ха-ха, ну тогда в мире миллионы "хакеров" :)
>Очень странно, почему же у меня всё прекрасно работает? :)
ИМХО по одной причине - работает ровно до тех пор пока эту полисовку не попытаются обойти а траффик соответствует тому что ожидается.Т.е. профиль траффа соответствует тому что вы ожидаете и никто не пытается испортить вам компот.А для серьезных и ответственных применений, как то например корпоративщикам VoIP приоретизировать - вот так вота опаньки будет.Для локалки в сельпо - сойдет и так, в допущении что все вокруг идиоты а вы один такой умный а потому никто и никогда не будет абузить вашу халтуру в полисовке.
И кстати нарваться на атаку - говно вопрос.Это не вы там торрент упоминали?Ну так вот, JFYI есть вагон фирм которые торренты и прочих очень не любят.Поэтому встречаются очень разные выкрутасы.Отдельные уроды узрев вас с вашим торентом шлют в вашу сторону все что угодно в надежде создать проблемы.Встречал и несколько случаев откровенного наглого флуда в мою сторону.Пару раз умудрялись в хлам засрать 10Мбит канал в интернет например (я это пролечивал сменой айпи, у прова каналы толстые... :D).
>Молодой человек, вы путаете две совершенно разные ситуации - шейпинг, рассчитанный на
>_нормальную_ работу, и DoS/DDoS-атаку.Нет, я просто различаю *нормальный* шейпинг, который не вылезет за глобальные лимиты даже при наглежке и попытках выкрутасов равно как будет честно пытаться пихать более приоритетные пакеты нежели менее приоритетные и всякую халтуру которая работает только если ей подыгрывают с другой стороны, с вагоном оговорок и допущений, и которая легко вылезает за заданные лимиты как только траффик становится "не тот" и которая не может честно приоретизировать важные пакеты при нужде частично отбросив менее важные.
>Если вам полностью засрали входящий канал - вам ТОЧНО ТАК ЖЕ
>не поможет и шейпинг на исходящем интерфейсе.А вот и нет.В типичном случае суммарная мощность каналов провайдера на несколько порядков больше чем тощая соска идущая от провайдера к клиенту.Поэтому если железка со стороны провайдера применит шейпинг и полисовку ее исходящего интерфейса (который с той стороны медленного канала с которого вы данные выгребаете) - все будет оки-доки.Грубо говоря, допустим у прова несколько 1Гбит каналов, засрать их нелегко.К вам соска 10 Мбит.Вам шлют вам 20 мбит флуда.Канал 10 мбит очевидно сам по себе засрется в хлам.А вот если железка у прова первыми выдавит в канал VoIP пакеты а остальное - как получится - VoIP будет без проблем летать и дальше.А остальное (включая и флуд) - как получится, ну не влезет половина флуда в канал и отправится прововской железкой в /dev/null, и чего? Ну и некоторые иные критичные типы траффика можно точно так же выделить.Равно как и более жестко заполисовать некие типы флуда.Скажем на случай козлов с ping -f можно (ессно с провайдерской стороны медленной соски) нарулить политику которая ограничивает скорость ICMP пакетов, а что сверх того - в трэш.В итоге если некто на 50 мбит канале введет в вашу сторону ping -f а у прова на железке полися что в вашу сторону не более 1 Мбит ICMP а остальное в треш - в вашем канале будет 1Мбит ICMP.Еще 49Мбит отлетят в /dev/null.Если это был все тот же 10Мбит канал, у вас останется 9Мбит свободного бандвиза и никаких проблем как бы не будет :).Единственная "проблема" что пров спускает 49 Мбит траффа вникуда.До тех пор пока его каналы не переполнены - это всем похрену.
>А весь разговор ведётся как раз про разницу входящего и исходящего.
Ну так разница в полисовке входящего и исходящего - есть.Исходящий можно честно и жестко полисовать без вольных допущений.Входящий - черта с два пополисуешь по нормальному с приемной стороны медленной соски.С прововской стороны - да, можно.Но это, пардон, провайдер может сделать с его стороны соски.А вовсе не вы... и для него это будет опять же честный шейпинг ИСХОДЯЩИХ (в вашу сторону) пакетов.
Если кто настолько дуб и еще не понял - IP так устроен что пытается доставить все пакеты которые в вас кидают вам.Сие не было сделано в рассчете на malicious use или полисовку.И нынче данное свойство немного икается, потому что не все в мире белые и пушистые а стандартных методов отказаться от получения траффика "от вон той ремоты" в IP попросту нет.Так что если кто-то вам шлет 100 мбит говна и никто (типа провайдера с более толстыми каналами) вам не поможет в фильтровке и полисовке (а по дефолту все обычно именно так) - вы будете выгребать 100 Мбит говна.Или сколько там из этого осилите :)
Блин модераторы зачем пост зарезали там не так много матов было :-)Для особо упрямых и непонятливых типа nuclight'ов, _umka_'ов, а так же осторожных и иже с ними.
>ОК, расскажите же мне, как пошейпить пришедший самому серверу (т.е. его собственный IP) на
>eth0 входящий трафик, если исходящие фильтры висят только на смотрящем во внутреннюю сеть к
>клиентам eth1 ? А на сервере запущен торрент-клиент, который хорошо так кушает канал, если не
>пошейпить :)1. Повешать фильтр на eth0 на исходящие из LAN сегмента
2. Фильтр на тот же eth0 от самого сервера
3. Убить торрент клиент на сервереА TCP по скорости сам все подгонит
>[оверквотинг удален]
>[провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины]
>
>Видно, что если поставить ПЕРЕД сервером еще один роутер, исходящие фильтры на eth1 этого
>другого роутера будут ПЕРЕД eth0 нашего качающего сервера, и будут включать в себя ВЕСЬ
>трафик, потому что этот виртуальный роутер не будет иметь трафика, предназначенного для себя.
>
>И теперь, очевидно то, что эти две схемы ЭКВИВАЛЕНТНЫ тому, чтобы повесить входящие шейпящие
>фильтры на eth0 сервера, т.е. в направлении слева направо, т.е. просто вклиниться в этот поток
>внутри eth0 - ибо зачем нам ставить еще один роутер для такой простой задачи, dummynet ведь
>умеет.Единственное чего вы добьетесь если поставите фильтр на входящий с eth0, так это балансировку сегмента - [eth1]-----[внутренние машины], но ни как не - [канал к провайдеру]-----[eth0].
Если пров послал тебе в общей сложности 3 Мбайта в секунду, то ты эти 3 мега и получешь на своей сетевке, то есть канал свой ты на это количество трафика в еденицу времени уже забил и ни чего ты с этим уже не зделаешь.Люди ну подумайте головой как вы можете огроничивать то что от вас не зависит.
nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в этом вопросе палишся же.
>nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в
>этом вопросе палишся же.Ну не понимает чувак что в общем случае ремота не обязана быть кооперативной и играть строго по придуманным правилам.А итог?Простой и всем известный ping -f с достаточно толстого канала (достаточного для забития канала недругу) скорее всего банально похоронит VoIP у додиков с такой "полисовкой" - приведя к большим потерям и задержкам входящих VoIP пакетов.Гули толку с такой недоношенной "полисовки", если любой дятел может на нее положить 1 командой болт?Вот если пров начнет полисовать *исходящие* (в медленный канал юзера) пакеты ICMP допустим по правилу "не более 20 кбит а остальное в треш" - канал у юзера забьется лишь на 20 кбит.А остальное отлетит в /dev/null и не будет представлять для юзера да и всех остальных никаких проблем до тех пор пока намного более мощные каналы прова способны справиться с данной нагрузкой (зафлудить провайдера - более другая задача чем зафлудить додика на тощем канале, а?).
>1. Повешать фильтр на eth0 на исходящие из LAN сегмента
>2. Фильтр на тот же eth0 от самого сервераАга, то есть вы предлагаете шейпить ответные ACK'и от клиента к отправителю. Загвоздка в том, что вы не сможете описать все такие ситуации в терминах просто шейпинга трафика - бывают ретрансмиты, количество ответного трафика от приложения клиента тоже непредсказуемо, и т.д. Этот вариант в теории рабочий, но на практике будет работать плохо. Шейпинг прямого трафика гораздо адекватнее.
>3. Убить торрент клиент на сервере
То есть, вы расписываетесь в том, что не сможете справиться с такой ситуацией лишь исходящими филтрами :) Что и требовалось показать.
>А TCP по скорости сам все подгонит
Он это и при входящем шейпинге подгонит точно так же.
>>[провайдер]--[eth0]--[другой роутер]--[eth1]--[eth0]--[сам сервер]--[eth1]-[внутренние машины]
>>
>Единственное чего вы добьетесь если поставите фильтр на входящий с eth0, так
>это балансировку сегмента - [eth1]-----[внутренние машины], но ни как не -
>[канал к провайдеру]-----[eth0].Ваша проблема в том, что вы мыслите не в тех терминах. Мы балансируем сегмент [сам сервер]--[eth1]--[внутренние машины], а не сегмент [сам сервер]--[eth1]-[внутренние машины], который только и можно зашейпить исходящими. А на сегмент [канал к провайдеру]-----[eth0] мы не влияем, повлиять не можем, но это и не надо - он эквивалентен участку [аплинк провайдера]--[провайдер], на который нам тоже наплевать.
>Если пров послал тебе в общей сложности 3 Мбайта в секунду, то
>ты эти 3 мега и получешь на своей сетевке, то есть
>канал свой ты на это количество трафика в еденицу времени уже
>забил и ни чего ты с этим уже не зделаешь.Ну и что? Головой-то думать кто будет? Шейпинг, в отличие от полисинга, оперирует не только текущим моментом, когда оно пришло, и ничего не сделаешь - но и будущим. На которое уже можно повлиять.
>Люди ну подумайте головой как вы можете огроничивать то что от вас
>не зависит.Ага-ага. По этим словам, шейпинг вообще невозможен - как мы можем повлиять на то, с какой скоростью сервер где-то в инете отдает клиенту трафик, он же от нас не зависит!
>nuclight вот ты вот рисуешся знаниями SACK, congestion control, RED/GRED, а в
>этом вопросе палишся же.Это просто у вас в голове каша, и как оно всё работает, в полную картину не укладывается. Проблема-то не у меня - у меня вон шейпинг входящих прекрасно работает :)
>Загвоздка в том, что вы не сможете описать все такие ситуации
>в терминах просто шейпинга трафика - бывают ретрансмиты, количество ответного трафика
>от приложения клиента тоже непредсказуемо, и т.д. Этот вариант в теории
>рабочий, но на практике будет работать плохо. Шейпинг прямого трафика гораздо
>адекватнее.Я конечно не такой умный как ....
Но вот в связке iptables+iproute(tc), у меня больше шансов чем ...>То есть, вы расписываетесь в том, что не сможете справиться с такой
>ситуацией лишь исходящими филтрами :) Что и требовалось показать.Вот после этого я уж не сколько не удивлюсь, если вдруг вы окажетесь латентным виндузятником, который в добавок еще и сидит под рутом.
Торрент клиент на сервере - не нужно оно там.
>Ваша проблема в том, что вы мыслите не в тех терминах. Мы
>балансируем сегмент [сам сервер]--[eth1]--[внутренние машины], а не сегмент [сам сервер]--[eth1]-[внутренние машины],
>который только и можно зашейпить исходящими. А на сегмент [канал к
>провайдеру]-----[eth0] мы не влияем, повлиять не можем, но это и не
>надо - он эквивалентен участку [аплинк провайдера]--[провайдер], на который нам тоже
>наплевать.Бред, слов нет.
>Ну и что? Головой-то думать кто будет? Шейпинг, в отличие от полисинга,
>оперирует не только текущим моментом, когда оно пришло, и ничего не
>сделаешь - но и будущим. На которое уже можно повлиять.Чего чего, сами то поняли че сказали это вы в сетевом контексте эту охинею несете, ужас.
>Это просто у вас в голове каша, и как оно всё работает,
>в полную картину не укладывается. Проблема-то не у меня - у
>меня вон шейпинг входящих прекрасно работает :)А позвольте узнать на выходе то же шейпите?
"Единственный способ контролировать вход это грамотно резать выход, а TCP сам выровняет." чушь какая, где вы этому начитались? Советую книгу протокол TCP/IP for Linux.
>чушь какая, где вы этому начитались? Советую книгу протокол TCP/IP for
>Linux.А что вас поразило, то, что мы косвено можем контролировать вход балансируя выход или то, что "TCP сам выровняет".
А литературу мне советовать не нужно, был тут один уже начитаный. Возмите лубую угодную вам техническую литературу по TCP/IP стеку и укажите мне где сказано обратное(страница, параграф)
Если это будет авторитетный источник, я с радостью с вами соглашусь чесслово.
Вы уж тогда определитесь косвенно или единственный способ. В любой книге написано, если вы намекаете на то что без запроса нет и ответа, то могу привести несколько примеров, начиная с впн клиентов, кончая почтовиком. Когда выход ну ни как на вход не влияет, а наоборот. Или вот например отшейпите вы выход пакетики от пользователя на запрос фаила все равно пройдут рано или поздно, входящий вы не контролируете следовательно канал в итоге ляжет при совершенно ни каком исходящем трафике. Собственно к этому и относилось мое "Чушь какая", куча ситуация когда выход не повлияет на вход. Да и в ТСП не предусмотрено "сам выравняет" , посему и рекомендую, лучшую на мой взгляд, книгу по этому протоколу, написана легко, понятно, с примерами, и сразу кучу вещей становяться понятными и прозрачными, даже если вы спец по сетевым протоколам все равно рекомендую, есть на русском языке.
>если вы намекаете на то что без запроса нет и ответа,
>то могу привести несколько примеров, начиная с впн клиентов, кончая почтовиком.Это вы о чем, мы с вами говорим совершенно о разных вещах, не поленитесь перечетайте еще раз топик.
>Да и в ТСП не предусмотрено
>"сам выравняет" , посему и рекомендую, лучшую на мой взгляд, книгуЯ бы вам посоветовал перечитать рекоминдованную вами книгу еще раз да повнимательней.
Вы меня конечно извените за прямоту, но я просил афторитетный источник коим вы не являетесь.
>Еще один, не знающий, как работает TCP. Ситуация: домашний сервер, который NAT
>для еще двух машин. Нужно распределить поток так, чтобы сервер не
>отжирал бесконтрольно полосу, не оставляя ничего домашним машинам, и чтоб они
>его и друг друга тоже. Как? С только исходящими фильтрами -
>это невозможноПерестаньте гнать пургу и ознакомьтесь со схемой iptables. Ознакомьтесь с понятием mangle на цепочках OUTPUT и FORWARD. Даже если на сервере настроен NAT (а точнее PAT), цепочки mangle работают с пакетами ДО того, как они попадут в NAT. Итог - трафик сервера можно обрабатывать наравне с трафиком от клиентов и никто никому мешать не будет.
>сервер будет неучтен. Но вполне очевидно, что входящий шейпер
>на входе внешнего интерфейса сервера эквивалентен конфигурации, когда перед сервером включается
>еще один роутер, на котором конфигурируется исходящий шейпер в сторону сервера.Проблема в том, что при попадании трафика на входной интерфейс ты не сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее по какому каналу они пойдёт дальше (если это роутер), а соответственно, не можешь сделать вывод до какой скорости какие пакеты урезать.
>Перестаньте гнать пургу и ознакомьтесь со схемой iptables. Ознакомьтесь с понятием mangle
>на цепочках OUTPUT и FORWARD. Даже если на сервере настроен NAT
>(а точнее PAT), цепочки mangle работают с пакетами ДО того, как
>они попадут в NAT. Итог - трафик сервера можно обрабатывать наравне
>с трафиком от клиентов и никто никому мешать не будет.
>Причем здесь iptables, mangle, OUTPUT, FORWARD?
Речь идет про ipfw.>Проблема в том, что при попадании трафика на входной интерфейс ты не
>сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее
>по какому каналу они пойдёт дальше (если это роутер), а соответственно,
>не можешь сделать вывод до какой скорости какие пакеты урезать.С ipfw сделаю это элементарно! :-)))
>>Проблема в том, что при попадании трафика на входной интерфейс ты не сможешь отрезать оттуда заведомо бесполезные пакеты и не можешь сказать заранее по какому каналу они пойдёт дальше (если это роутер), а соответственно, не можешь сделать вывод до какой скорости какие пакеты урезать.
>С ipfw сделаю это элементарно! :-))обратно отправишь? типа - никого нет дома, заберите назад? :-D
в любом случае, примешь, обработаешь, сделаешь вывод - что с ними делать дальше (дроп, режект, форвард,....) - и уже потом допать, режектить, раздавать кому и с какой скоростью.
>обратно отправишь? типа - никого нет дома, заберите назад? :-DПожалуется в ООН наверное - "вон та нехорошая ремота наплевала на мои тщетные потуги снизить скорость траффика от нее, поэтому моя полисовка траффика пошла лесом и вышла за заданные лимиты!"
>>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает только для исходящего
>>трафика (не надо мне рассказывать о ingress фильтрах - которые делаются через задний проход).
> Уважаемый _umka_, мне кажется вы че то напутали, шейпинг имеет смысл только
> на исходящем трафике и безразници где это в фряшном dummynet или
> линуксовый iproute.
> Да да именно для вас tc входит в состав пакета iproute.Если машина - только роутер, и всё - то да.
Но ipfw может защищать и регулировать саму машину.Например, на ваш сервер нападают DDOS-атакой TCP-SYN на 22й порт. Машина в трауре, и Вы даже ничего не можете с эти сделать, т.к. Ваши попытки попасть на 22й порт пропадают в туче аналогичных.
шейпинг входящего дает нам решение:
ipfw pipe 99 config delay 1000 queue 1 mask src-ip 0xFFFFFFFF buckets 1024
ipfw add 100 pipe 99 tcp from any to me 22 setupВ результате до обработки доберется не более 1 TCP-SYN пакета от каждого атакующего в секунду, и чтобы завалить ваш сервер понадобится не один, а тысяча атакующих.
>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает
>только для исходящего трафика (не надо мне рассказывать о ingress фильтрах
>- которые делаются через задний проход).Шейпер можно ставить только на исходящий трафик. Любые вещи мы повесили фильтр на входящий трафик эмулируются через добавление фильтра на тот интерфейс который является исходящим.
Учите теорию.
>Шейпер можно ставить только на исходящий трафик.Бред.
Шейпер нужен там, где необходимо резать канал на полосы пропускания с соответствующей политикой занятия полос: пользователи либо равномерно делят всю полосу пропускания канала, либо каждый имеют фиксированные полосы пропускания от общей полосы канала.
>Бред.
>Шейпер нужен там, где необходимо резать канал на полосы пропускания с соответствующей
>политикой занятия полос: пользователи либо равномерно делят всю полосу пропускания канала,
>либо каждый имеют фиксированные полосы пропускания от общей полосы канала.Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ трафик и не как ни входящий, при любых условиях. Представь ты поставил pipe на вход с сетевухи и, что - порежешь ты его тока после того как карточка получит свои N байт трафика, а эти N байт уже забили твою полосу на N kbit/s.
Блин где вас тока берут с умкой.
>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ
>трафик и не как ни входящий, при любых условиях. Представь ты
>поставил pipe на вход с сетевухи и, что - порежешь ты
>его тока после того как карточка получит свои N байт трафика,
>а эти N байт уже забили твою полосу на N kbit/s.Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK пакетов и манипулирования размером окна. UDP действительно не порежешь.
>>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ
>>трафик и не как ни входящий, при любых условиях. Представь ты
>>поставил pipe на вход с сетевухи и, что - порежешь ты
>>его тока после того как карточка получит свои N байт трафика,
>>а эти N байт уже забили твою полосу на N kbit/s.
>
>Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK
>пакетов и манипулирования размером окна. UDP действительно не порежешь.А как это сделать с помощью tc и pipe в dummynet?
>Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK
>пакетов и манипулирования размером окна.При условии что ремота - кооперативна, а не просто срет в ваш адрес пакетами, поклав болт на эти ваши потуги :).Что довольно-таки вольное и мягкое ограничение.Да, оно работает до некоторой степени.Но в конечном итоге - ГАРАНТИЙ как бы ноль.Реально эффективно воздействовать на это может провайдер, шейпя с своей стороны канала исходящий (в вашу сторону) траффик.При этом можно честно приоретизнуть пакеты.В отличие от ваших полудохлых и читерских потуг это делать.Т.е. нормальный подход - если есть сравнительно тощий канал являющийся узким местом и быстрые сети с обоих его сторон (наиболее типовая ситуация ИМХО) - надо с обоих сторон шейпить исходящий трафф.Шейпить входящий ... "поздно пить боржоми когда почки отказали".Вы его уже получили пардон, а значит свое место в узком канале оно уже съело.И пофиг, зашейпите вы это дальше или нет.
>Типичное заблуждение, входящий TCP трафик очень хорошо шейпится за счет удерживания ACK пакетов и манипулирования размером окна. UDP действительно не порежешь.т.е. другими словами, тотже эффект - шейпим исходящий трафик для внутренней сети и исходящий же для внешней. :-D
угу. притормозить это дело слегка могём. любым способом. держим в буферах на сколько хватит. и принимаем всё новые и новые соединения. :-Dя всегда как-то (по простоте душевной, не иначе) думал, что управление трафиком, балансировка - нужны прежде всего для нагруженных сетей.
а ограничевать просто так, назлу мерзкому юзверю... мне не понять. :-D
>я всегда как-то (по простоте душевной, не иначе) думал, что управление трафиком,
>балансировка - нужны прежде всего для нагруженных сетей.
>а ограничевать просто так, назлу мерзкому юзверю... мне не понять. :-DА если он шакал, не дал админу пароль на торрент?
хреновый админ тогда однако.
у Вас же в бзде дерэйс есть. там даже пароли на ssh ловить можно.
http://www.sunhelp.ru/archives/92-DTrace_vhodJawie_ssh_toZhe...
или я ещё нету?
>Блин да скоко вам обьеснять мы можем контролировать шейпером тока НАШ ИСХОДЯЩИЙ
>трафик и не как ни входящий, при любых условиях. Представь ты
>поставил pipe на вход с сетевухи и, что - порежешь ты
>его тока после того как карточка получит свои N байт трафика,
>а эти N байт уже забили твою полосу на N kbit/s.
>
>Блин где вас тока берут с умкой.Элементарно! Режешь сразу после ната.
>Элементарно! Режешь сразу после ната.Ха-ха, вы снаала получаете пакеты а потом можете их прибить, отполисовать и прочая.Вот только если проблема была в том что входящего направления канала не хватает и хочется полисовать и приоретизировать его - толку с всего этого ровно ноль.Пакеты уже прилетели и уже заняли на некое время канал под себя - в общем случае уже поздно что-то по этому поводу делать :D
Поясняю в случае исходящего трафика у вас есть бак с краниками и соотвественно вы можете крутить с какой скоростью из него льется. В случае входящего трафика бак с краниками находится на другой стороне. С какой скоростью вам их отправили с той скоростью вы их и получите. Для регулировки входящего трафика для клиента используется бак с краниками на том интерфейсе который является входящим для клиента и исходящим для вас. Учите матчать.
Ну что же, если вы использовали такую аналогию, то сами подставились, я не виноват :) буду разжевывать и бить в ней же :)--[бак провайдера]---[краник1]---[бак роутера]--[краник2]--[бак клиента]
Представили систему баков и краников, да?
Так вот, если провайдер шейпит на исходе своего бака, он подкручивает краник1, если мы на своем исходе, мы крутим краник2, но если мы на своем входе - видно, что краник1 находится на той же самой трубе между провайдером и нами, она едина! И если мы будем шейпить на входе у себя, мы крутим кран на той же трубе, где находится краник1, не имеет значения, в каком месте трубы между двумя баками находится кран - труба без разрывов, вода несжимаема.
Да, эта аналогия не вполне точна по отношению к сетям, но вы, во-первых, сами с ней подставились (так что возражения не принимаются), во-вторых, мысль об эквивалентности шейпа на входящем нас и исходящем аплинка хорошо показывает.
>Ну что же, если вы использовали такую аналогию, то сами подставились, я
>не виноват :) буду разжевывать и бить в ней же :)Аналогия не верна и всё дальнейшее - чушь. Это ещё могло бы подойти для описания управления потоком трафика в сети Frame Relay, где приёмник и передатчик могут говорить друг другу о своей максимальной скорости приёма данных. Но для IP-сетей это в общем случае не верно. В IP-сетях роутер не может подкручивать краник провайдера, а потому использование шейпинга на входном потоке данных - чушь, которая нужна лишь упёртым "ценителям" ipfw и dummynet.
>В IP-сетях роутер не может подкручивать краник провайдера, а потому использование
>шейпинга на входном потоке данных - чушь, которая нужна лишь упёртым
>"ценителям" ipfw и dummynet.И что характерно у этих упёртых получается. Как ни странно входящие шейперы работают даже на Чукотке при морозе.
Да, они не помогут при перегрузке канала. Да есть ещё нюансы. Но в целом работают и гораздо эффективнее чем мифическое придерживание ACKов.
Если бы принимающая сторона никак не могла влиять на скорость передающей, то любой ответ сервера с широким каналом ложил бы сети конечных провайдеров.
>на своем входе - видно, что краник1 находится на той же
>самой трубе между провайдером и нами, она едина! И если мы
>будем шейпить на входе у себя, мы крутим кран на той
>же трубе, где находится краник1, не имеет значения, в каком месте
>трубы между двумя баками находится кран - труба без разрывов, вода
>несжимаема.Вы забыли одну вещь. Краник 1 находится у провайдера, а не у вас крутить вы его не можете.
Вы можете крутить только второй краник.>Да, эта аналогия не вполне точна по отношению к сетям, но вы,
>во-первых, сами с ней подставились (так что возражения не принимаются), во-вторых,
>мысль об эквивалентности шейпа на входящем нас и исходящем аплинка хорошо
>показывает.Для IP сетей у вас должно быть две трубы одна на прием вторая на отдачу. На той трубе что на отдачу кран вы можете крутить, а на той что получаете нет.
>Шейпер можно ставить только на исходящий трафик. Любые вещи мы повесили фильтр
>на входящий трафик эмулируются через добавление фильтра на тот интерфейс который
>является исходящим.
>Учите теорию.Да-дад, идите учите :) Ситуация наоборот верна, любой исходящий можно заменить входящим трафиком, а описаннное выше нет - ибо между входящим и исходящим интерфейсами есть вычет трафика, предназначенного самому роутящему хосту. См. http://www.opennet.ru/openforum/vsluhforumID3/56111.html#61
>[оверквотинг удален]
>не коректное сравние.
>tc хоть и умеет разные дисциплины обслуживания у шейпера - но работает
>только для исходящего трафика (не надо мне рассказывать о ingress фильтрах
>- которые делаются через задний проход).
>В этом ключе iptables+tc - правильнее сравнивать с ipfw + altq (да
>да, dummynet это не единственный шейпер с которым в связке может
>использоваться ipfw).
>Но судя по всему вы не разбираетесь в вопросе - поэтому приводить
>вам аргументы не стоит.
>Разбиритесь сначала что вы хотите сравнить - а потом поговорим.На самом деле Вы сами предложили написать "тоже самое, но на связке ipt+tc"(c)
Вам написали. А теперь вы что-то вопите про то что "как можно сравнивать".
Это выглядит, как минимум, смешно. Потому как складывается впечатление очередного религиозного бзди-фанатика. Или очень толстого тролля. Или связки бзди-фан+
толстый толль.
Например, tablearg, несколько разных тегов на пакете одновременно, OR-блоки внутри одного правила.Да, чего нет в ipfw, что есть в ipt, можете мне не рассказывать, я с обоими знаком.
>Например, tablearg, несколько разных тегов на пакете одновременно, OR-блоки внутри одного правила.
>
>
>Да, чего нет в ipfw, что есть в ipt, можете мне не
>рассказывать, я с обоими знаком.А что есть IPT ?
http://en.wikipedia.org/wiki/IPT
>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет
>iptables+iproute2+tc?Навскидку (только ipfw, как просили):
- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде tablearg;
- ruleset-ы (которые включаются/выключаются атомарной операцией);
- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место цепочки, а не строго в начало/конец, и проделать это несколько раз)
- из последнего вытекает skipto;
- Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у iptables). Хотя было очень давно, и сейчас, возможно, с этим дела обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество правил потребовалось сугубо из-за отсутствия таблиц адресов;
- Указание вероятности срабатывания правила (хотя, может, уже тоже научились => под вопросом).
>- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место
>цепочки, а не строго в начало/конец, и проделать это несколько раз)Ну, вообще-то оно нынче уже умеет указывать номер правила в подцепочке:
-I, --insert chain [rulenum] rule-specification>- из последнего вытекает skipto;
>- Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у
>iptables). Хотя было очень давно, и сейчас, возможно, с этим дела
>обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего
>занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество
>правил потребовалось сугубо из-за отсутствия таблиц адресов;Ну, вообще-то она линейная, логарифмическая - это для адреса в таблице. А что, в линуксах когда-то оно было именно экспоненциальным, даже не квадратичным? Ужос, это ж как так надо код писать... линейным было бы вполне естественно сразу.
>>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет
>>iptables+iproute2+tc?
>
>Навскидку (только ipfw, как просили):
>
>- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде
>tablearg;Таблицы адресов присутствуют уже с полгода.
>- ruleset-ы (которые включаются/выключаются атомарной операцией);
Этого не помню, возможно и нет.
>- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место
>цепочки, а не строго в начало/конец, и проделать это несколько раз)Весьма и весьма давно, года эдак 4 назад как минимум умеем:
-I, --insert chain [rulenum] rule-specification
>
>- из последнего вытекает skipto;
>- Логарифмическая зависимость времени добавления правила от числа правил (против экспонециальной у iptables). Хотя было очень давно, и сейчас, возможно, с этим дела
>обстоят лучше. На 3-м Debian-е при примерно 20000 правил добавление следующего
>занимало 15 секунд при загрузке машины в ~50 попугаев. Такое количество
>правил потребовалось сугубо из-за отсутствия таблиц адресов;
>- Указание вероятности срабатывания правила (хотя, может, уже тоже научились => под вопросом).Давным-давно есть.
Из всего этого напрашивается вывод что Вы не очень хорошо знаете ipt, хотя и не страдаете болезнью господ Умки с иЗеном.
>>- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде
>>tablearg;
>
>Таблицы адресов присутствуют уже с полгода.А чем таблицы адресов отличаются от ipset?
>>>- Таблицы адресов (а не таблицы правил) с чудным дополнением в виде
>>>tablearg;
>>
>>Таблицы адресов присутствуют уже с полгода.
>
> А чем таблицы адресов отличаются от ipset?Отсутствием tablearg. Опять же, не исключаю, что уже сделали. Правда, с трудом представляю себе, как аналог tablearg уживется с синтаксисом iptables.
>Таблицы адресов присутствуют уже с полгода....skip
>Из всего этого напрашивается вывод что Вы не очень хорошо знаете ipt,
>хотя и не страдаете болезнью господ Умки с иЗеном.Да, видимо, отстал от жизни.
>>- прямое добавление/удаление правил (попробуйте в iptables вставить/удалить правило в произвольное место
>>цепочки, а не строго в начало/конец, и проделать это несколько раз)
>
>Весьма и весьма давно, года эдак 4 назад как минимум умеем:
>-I, --insert chain [rulenum] rule-specificationЭто не то. Во-первых, не может быть нескольких правил под одним и тем же номером (хотя, в теории, при такой необходимости их можно вынести в отдельную цепочку). Во-вторых, добавление правила сдвигает всю нумерацию.
>>
>>- из последнего вытекает skipto;...аналогов которого я так же не наблюдаю.
>И вообще, может быть кто-нибудь назовёт те преимущества ipfw, которые не умеет
>iptables+iproute2+tc?Вы сам его привели "iptables+iproute2+tc" вместо 1го файла с приятным и понятным синтаксисом
>Вы сам его привели "iptables+iproute2+tc" вместо 1го файла с приятным и понятным
>синтаксисомЯсно, преимуществ нет.
нужное дело делают. это не зоопарк, а расширение возможностей. выбор каждый сделает по предпочтениям. отсутствие желания расширять знания -- это личные умственные проблемы проблемы. учитывая сколько хорошего софта заточено под ipfw -- этот проект прекрасная возможность использовать его на линухах. ИМХО.
Лучшеб IMQ уже в ядро внесли совместными усилиями. А так без IMQ согласен вещь очень хорошую сделали. Умеет ограничивать входящий и исходящий траф. И самое главное умеет с таблицами работать(ipfw table), чего не умеет iptables.
Лучше бы PF портировали...
>Лучше бы PF портировали...что это мешает сделать лично вам?
он занят писательством комментариев
> а зачем ? им делать нечего ?ipfw проще в настройке, например, минимальный файрволл настраивается в четыре наглядных строки:
ipfw flush
ipfw add check-state
ipfw add allow all from me to any out keep-state
ipfw add deny all from any to anyВ ipfw умеет работать с таблицами IP-адресов. Для iptables есть ipset,
но большинство дистрибутивных ядер пока собираются без него.Но основное преимущество - это (IMHO!) простота настройки dummynet'a
по сравнению с LARTC для массового шейпирования.
> В ipfw умеет работать с таблицами IP-адресов.Забавно. А если iptables этого не умеет, то почему жк он так называется? :-)
>> В ipfw умеет работать с таблицами IP-адресов.
>
>Забавно. А если iptables этого не умеет, то почему жк он так
>называется? :-)Потому что он умеет работать с таблицами правил
да куча уже упрощающих "настройщиков" для iptables. в бубунте вот ufw. типа:
ufw deny proto tcp from 2001:db8::/32 to any port 25
ufw allow proto tcp from any to any port 80,443,8080:8090
ufw limit ssh/tcp
ufw allow from 192.168.0.0/16 to any app Samba
и т.д., которые разворачиваются в несколько сот строчек.
и это фронтэнды. они делают своё дело, а iptables - своё.
>> В ipfw умеет работать с таблицами IP-адресов.
>
>Забавно. А если iptables этого не умеет, то почему жк он так
>называется? :-)По недоразумению. В линуксе вообще многое называется не так, как в точности следовало бы. Это таблицы правил, но на самом деле они представляют собой списки правил, а не таблицы. В ipfw список правил никаким специальным словом не называется, а таблицы - это набор IP-адресов/масок, организованных в radix-дерево для быстрого поиска, т.е. O(log N) вместо O(N) для линейного списка правил в цепочке iptables и ipfw.
Таблицей же это называется потому, что в ней действительно более одного столбца - кроме адреса еще сопоставлено числовое значение, по которому можно дополнительно проверять совпадение либо использовать для сокращения списка правил:
ipfw table 1 add 1.2.3.4
ipfw table 1 add 1.2.3.7 0
ipfw table 1 add 1.2.4.0/24 1
ipfw table 1 add 1.2.5.0/27 1
ipfw table 1 add 1.2.6.0/24 2
...
ipfw add deny all from table(1,2) to www.example.org // 1.2.6.0/24 etc.
ipfw add pipe tablearg all from table(1) to anyиначе была бы портянка вида
ipfw add pipe 1 all from 1.2.4.0/24 to any
ipfw add pipe 2 all from 1.2.6.0/24 to any
...В линуксе для этого есть ipset, но он, во-первых, действительно set (множество), а не таблица, ничего не сопоставлено с адресом, во-вторых, не входит в стандартную поставку, из-за чего админам иногда приходится эмулировать его руками (вспоминается DoS башорга).
>в стандартную поставку, из-за чего админам иногда приходится эмулировать его руками
>(вспоминается DoS башорга).Вообще-то проще его поставить руками.
>
>>в стандартную поставку, из-за чего админам иногда приходится эмулировать его руками
>>(вспоминается DoS башорга).
>
>Вообще-то проще его поставить руками.Более того:
http://packages.ubuntu.com/search?keywords=ipset
ставится apt-get-ом.
>>в стандартную поставку, из-за чего админам иногда приходится эмулировать его руками
>>(вспоминается DoS башорга).
>
>Вообще-то проще его поставить руками.Ну вот поинтересуйтесь у них, почему у них такой возможности не было, хотя они о нём знали. Пришлось им руками дерево эмулировать, 256 цепочек по октету IP-адреса.
>Ну вот поинтересуйтесь у них, почему у них такой возможности не было,
>хотя они о нём знали. Пришлось им руками дерево эмулировать, 256
>цепочек по октету IP-адреса.Радиус кривизны рук наверное большой был, вот и решили не искать лёгких путей.
ага, тут выше приводят ссылку:>Добавляем правила огранечения по меткам. Далее средствами iptables ставим эти метки.
>А теперь покажите мне в ipfw организовать хеш-фильтры http://www.opennet.ru/docs/RUS/LARTC/x1661.htmlпо ссылке эмулируют хеш лол. вот у них спросите почему они так делают. наверное по-другому не получается.
>[оверквотинг удален]
>ipfw table 1 add 1.2.5.0/27 1
>ipfw table 1 add 1.2.6.0/24 2
>...
>ipfw add deny all from table(1,2) to www.example.org // 1.2.6.0/24 etc.
>ipfw add pipe tablearg all from table(1) to any
>
>иначе была бы портянка вида
>ipfw add pipe 1 all from 1.2.4.0/24 to any
>ipfw add pipe 2 all from 1.2.6.0/24 to any
>...Это уже отдаёт самоцелью. Даже теоретически не могу представить зачем это нужно. А даже если это и нужно, то это как разгребать спагетти бейсика с его goto.
>В линуксе для этого есть ipset, но он, во-первых, действительно set (множество),
>а не таблица, ничего не сопоставлено с адресом, во-вторых, не входит
>в стандартную поставкуСпециально для вас мини-хау-ту для Debian Lenny:
1. устанавливаем пакеты:
# apt-get install ipset
# apt-get build-dep netfilter-extensions-source
# apg-get install netfilter-extensions-source
# cd /usr/src
# tar xjf netfilter-extensions.tar.bz22. собираем и устанавливаем:
# m-a a-i netfilter-extension
3. пользуемся!
>из-за чего админам иногда приходится эмулировать его руками
>(вспоминается DoS башорга).Кстати, даже для эмуляции у iptables средства не так уж и плохи. Цепочки по сути являются подпрограммами обработки трафика и позволяют писать довольно сложные, но ТЕМ НЕ МЕНЕЕ гораздо более понятные правила, чем конструкции вида
>ipfw add pipe tablearg all from table(1) to any
>[оверквотинг удален]
>>ipfw add pipe tablearg all from table(1) to any
>>
>>иначе была бы портянка вида
>>ipfw add pipe 1 all from 1.2.4.0/24 to any
>>ipfw add pipe 2 all from 1.2.6.0/24 to any
>>...
>
>Это уже отдаёт самоцелью. Даже теоретически не могу представить зачем это нужно.
>А даже если это и нужно, то это как разгребать спагетти
>бейсика с его goto.Как раз-таки наоборот. Линейная последовательность правил - это пачка if'ов и goto. А tablearg - это диспетчеризация вызова функции по указателю. ОДНО правило вместо пачки - это гораздо понятнее и эффективнее.
Что же касается того, зачем это нужно - тренируйте воображение, что ли. Одно из применений этой штуки (люди реально пользуются) - есть семейство тарифов (полос), клиентов много, каждый купил один из тарифов, нужно шейпить соответственно. Чтобы не писать по правилу на каждого клиента - мы вгоняем их адреса в таблицу с указанием номера. И всё!
>>из-за чего админам иногда приходится эмулировать его руками
>>(вспоминается DoS башорга).
>
>Кстати, даже для эмуляции у iptables средства не так уж и плохи.
>Цепочки по сути являются подпрограммами обработки трафика и позволяют писать довольно
>сложные, но ТЕМ НЕ МЕНЕЕ гораздо более понятные правила, чем конструкции
>вида
>>ipfw add pipe tablearg all from table(1) to anyКак средство эмуляции оно хуже - внутри подпрограммы поиск всё равно линейный. Очень странно, если вы приводите аналогии из програмирования, и не понимаете, чем одна строка с индексацией по таблице (массиву) лучше и _понятнее_, чем пачка if-else if для каждого варианта значения индекса.
>>Это уже отдаёт самоцелью. Даже теоретически не могу представить зачем это нужно.
>>А даже если это и нужно, то это как разгребать спагетти
>>бейсика с его goto.
>
>Как раз-таки наоборот. Линейная последовательность правил - это пачка if'ов и goto.Не согласен. В iptables не бывает переходов на правило с произвольным номером, только цепочки - аналог подпрограмм. А вот в ipfw есть skipto - элемент, образующий спагетти.
>А tablearg - это диспетчеризация вызова функции по указателю. ОДНО правило
>вместо пачки - это гораздо понятнее и эффективнее.А, понятно, теперь до меня дошла семантика правила:
>ipfw add pipe tablearg all from table(1) to anyМне показалось это будет просто правило для одного (первого) элемента таблицы, а это оказывается номер столбца. Да, интересная возможность.
>Не согласен. В iptables не бывает переходов на правило с произвольным номером, только цепочки - аналог подпрограмм. А вот в ipfw есть skipto - элемент, образующий спагетти.ну вообще-то ещё есть:
$ man iptables
.................
-g, --goto chain
This specifies that the processing should continue in a user specified chain. Unlike the --jump option return will not continue processing in this chain but instead in the chain that called us via --jump.но это так, к слову.
1) iptables -P INPUT DROP
2) iptables -A INPUT -i lo -j ACCEPT
3) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
4) echo bingo-bingo
>1) iptables -P INPUT DROP
>2) iptables -A INPUT -i lo -j ACCEPT
>3) iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>4) echo bingo-bingoХотел запостить то же самое.
И echo bingo-bingo тоже? :-D
>И echo bingo-bingo тоже? :-DНет, тут я признаю ваше авторство!
echo bingo-bingo (с) poige
>Нет, тут я признаю ваше авторство!
>
>echo bingo-bingo (с) poigeПоржал, спасибо. :-)
Вы считаете, что это более читаемо, чем приведённый выше пример??
Вы правда хотите услышать поговорку про то, что мешает плохому танцору, ещё раз? :-)
> ipfw проще в настройке, например, минимальный файрволл настраивается в четыре наглядных строки:
>
> ipfw flush
> ipfw add check-state
> ipfw add allow all from me to any out keep-state
> ipfw add deny all from any to anyА в чём сакральный смысл этого набора правил? Разве не достаточно просто не запускать ненужных сервисов? Или дело в атаках типа "from me to me in"?
Отличная новость!! Долгоя этого момента ждал )))
Шейпить в 10 раз проще станет!
>Отличная новость!! Долгоя этого момента ждал )))Забыл съесть сникерса?Кому оно было надо - уже давно шейпили.Не, если у кого радиус кривизны рук заточен именно под эту штуку - отлично.Но как бы есть ряд решений по шейпингу и без этой штуки.На разные вкусы.Еще +1 - не есть плохо, но и супер-дупер достижением не является.Просто очередной прибабах на выбор.
Я как раз ищу решения для шейпинга, может подскажите? http://www.opennet.ru/openforum/vsluhforumID1/85691.html#0
УРАААААА!!!! ждем теперь PF!! вот его то особо не хватает!
>УРАААААА!!!! ждем теперь PF!! вот его то особо не хватает!да сносите вы нафиг свой Linux, сетапте опенка и будет вам еще много много счастья кроме PF =))
не ради холивора будет сказано, но как поддерживать то его??
поставил убунту - всё обновляется со скоростью света. и adobe flash player(!!!!!) и firefox и thunderbird... а с опнбсд? всё старое, дыревое, рекомендуемый способ установки - из прекомпилированных пакаджей. а оно там обновляется раз в год.. в общем возни с ним - не оберешься..
и где безопасность? да.. компилять.... каждый день что ли? мне же РАБОТАТЬ надо.
простите но это не для меня..
опенбсд на серваке хорош, где не много сервсисов крутится. Или где нужно вылизанное ядро(в плане секурити)... В общем не для нас.
Не вижу смысла в шейпинге на воркстейшене -> нет проблем с флешплеером. Сама система не дырявая. Если вам нужен свежий софт - ваш путь называется following current. Рекомендуемый способ установки из пакаджей обоснован экономией времени и потребления электроэнергии. Обновляется оно два раза в год ;) А вы на линуксе каждый день софт обновляете? Не глядя?
Вы как-то смешали требования к десктопам и сервакам.
На личном опыте скажу, что на данный момент единственную нишу среди юникс серверов у меня на работе, которую не смогла занять опенбсд - это файлосервер с самбой на 300 юзеров. Есть подозрение, что проблема в отсутствие ядерных тредов. Так что там стоит фря. Хостинг, машины с рейдами для файлсервера, впн, почтарь и прокся - всё на опене. И никаких проблем. И поверьте, не так необходимо и не сильно хочется обновлять 8 серверов раз в неделю. Саму ось обновить - не проблема, а вот с некотроым софтом бывают заковырки - типа изменили формат конфига...
По большому счету, хоть я линукс не использую и не люблю, но я считаю, что для линукс коммьюнити ipfw+dummynet - очень хорошее приобретение. Это серьезно расширяет ваш потенциал.
А насчет портирования pf - думаю это дело времени. Не забываете, что это требует очень серьезной подготовки ядра.
>Не вижу смысла в шейпинге на воркстейшене -> нет проблем с флешплеером.Интересная логика...
> и потребления электроэнергии.
А что, в OpenBSD какие-то крутые технологии энергосбережения, лучше чем у других?Или это намек на то что компьютер с оным, особенно если десктопный, имеет смысл включать только по праздникам?Ну там посмотреть, обновить и выключить.Все-равно большинству юзеров (почувствуйте разницу - не "фанатов марки" а именно обычных юзеров) такая "десктопная" система никуда не впилась.Конечно и ежа можно научить летать при помощи пинков.А опенка - быть десктопом.А это надо?Ну, фанатам марки - да, из принципа.А остальным оно нафига?
>>Не вижу смысла в шейпинге на воркстейшене -> нет проблем с флешплеером.
>
>Интересная логика...Логика простая - мы, вроде, про серверное применение говорили.
>
>> и потребления электроэнергии.
>
>А что, в OpenBSD какие-то крутые технологии энергосбережения, лучше чем у других?Нет. Но вы подумайте что будет, если каждый будет себе компилять ОпенОффис3.
>Или
>это намек на то что компьютер с оным, особенно если десктопный,
>имеет смысл включать только по праздникам?Ну там посмотреть, обновить и выключить.Все-равно
>большинству юзеров (почувствуйте разницу - не "фанатов марки" а именно обычных
>юзеров) такая "десктопная" система никуда не впилась.Конечно и ежа можно научить
>летать при помощи пинков.А опенка - быть десктопом.А это надо?Ну, фанатам
>марки - да, из принципа.А остальным оно нафига?Мы опять же говорим не про десктопы. И я вам не предлагаю взять и поставить дома ОпенБСД.
>А это надо?Ну, фанатам марки - да, из принципа.А остальным оно нафига?Как фанат фанату? :) Или все-таки каждый пользует то, что ему больше нравится и удобнее?
>- не проблема, а вот с некотроым софтом бывают заковырки -
>типа изменили формат конфига...Дебианщики и убунтуйцы это достаточно хитро разруливают.До обновления версии системы они как максимум подновляют минорные версии софта в репах, а то и вовсе бэкпортят секурити фиксы на старые версии софта.Что отстреливает подобный тип проблем и достаточно кардинально.Зато порождает иные - иногда имеется несколько устаревший софт и убедить фруктов содержащих репы подтянуть его версию - геморрой тот еще.Они в этом плане весьма нервные.Что в убунте что в дебиане.
>убедить фруктов содержащих репы подтянуть его версию - геморрой тот
>еще.Они в этом плане весьма нервные.Что в убунте что в дебиане.Про убунту не знаю, зато скажу про дебиан. Бога ради, даже не пытайтесь рассчитывать на положительный ответ. Это строгая регламентированная документом политика - это всё равно что пытаться подбить на преступление у всей общественности на глазах.
>это всё равно что пытаться подбить на преступление у всей общественности
>на глазах.Ослиное упрямство не делает чести людям ИМХО.Я бы предпочел если бы вместо ослиного упрямства была бы разумная ориентировка по ситуации.Нацеленная не на формализм до буквы а на реальное качество дистрибутива.
А то очень уж все это напоминает фантастический рассказ про железного Бисмарка и тосты.
(http://lib.ru/INOFANT/SILVERBERG/rob.txt)
>>это всё равно что пытаться подбить на преступление у всей общественности
>>на глазах.
>
>Ослиное упрямство не делает чести людям ИМХО. Я бы предпочел если бы вместо
>ослиного упрямства была бы разумная ориентировка по ситуации.А кто будет определять степень и грань разумности? Не получится ли так, что каждый будет трактовать небольшую свободу в любую угодную себе сторону? Это у разработчика слаквари может быть одно единственное авторитетное мнение, потому что это авторский дистрибутив, дистрибутив одного человека. А в больших дистрибутивах отклонение от формальных правил, разброд и шатание попросту убъёт дистрибутив, уж лучше формализм до последней точки. А если что не нравится - нужно вносить изменения в правила или по-мужски решать свои проблемы самому (бэкпортировать что нужно - именно так большинство и поступает).
>Нацеленная не на формализм до буквы а на реальное качество дистрибутива.
Для начала нужно формально определить показатели качества. Желательно в количественной форме. Чтобы любой мог провести независимый расчёт показателя качества по единому рецепту и сказать: "если сделать так, то это будет 3 балла качества, а если вот так - то 53, мы выбираем второе", и чтобы ему никто ничего не возразил.
>А то очень уж все это напоминает фантастический рассказ про железного Бисмарка
>и тосты.
>(http://lib.ru/INOFANT/SILVERBERG/rob.txt)Будьте мужчиной или платите за решение ваших проблем или решайте их сами. Если есть какие-то претензии к весьма качественной халяве, то вас даже слушать не стоит (да и просто противно).
>Ослиное упрямство не делает чести людям ИМХО.Я бы предпочел если бы вместо
>ослиного упрямства была бы разумная ориентировка по ситуации.Нацеленная не на формализм
>до буквы а на реальное качество дистрибутива.Вы бы предпочли, чтобы с вашей точки зрения упрямство было бы..... ну и т.д.
Странно, но возможно они имеют прямо противоположное мнение. Вы же ну никак не можете этого понять.
>Вы бы предпочли, чтобы упрямство было бы с вашей стороныfixed
>Странно, но возможно они имеют прямо противоположное мнение.Да, а в итоге все порой приходит к пичканию всех древним софтом for no reasons.При том заявы что это ради стабильности выглядят по-идиотски.Скажем взять тот же нжынкс.Новые его версии сроду чинят всякие там краши.И, пардон, как старая версия оного может быть стабильнее новой, если в новой починен краш?А вот дебианщики будут "ради стабильности" до упора пичкать древнючей версией.Что вынудит ... правильно, собрать нормальную версию самому, например.Только вот напуркуа тогда пакетная система и репы вообще нужны, если половину софта приходится руками собирать?В итоге очень уж напоминает того робота, который был готов ради блага своих подопечных (снижения веса) заморить их нафиг голодом.Вот дебианщики с их упорством похожи на этого железного болвана иной раз."Ради вашего же блага" пичкают древним хламом времен царя гороха."Ради стабильности".Ну да, я помню стабильность с ключами ssl и т.п. - рекеить вагон машин мне понравилось, да :).И помню как стабильно обламывался снос нжынксы.Так что мало того что поставится древнее г... так потом еще и не снесешь стандартным методом.Как мило.В свете этого декларации по части стабильности не всегда выглядят убедительно.В моем понимании - если вместо ослиного упрямства и тупого формализма использовать человеческий разум - могло бы быть и лучше.
>>Странно, но возможно они имеют прямо противоположное мнение.
>
>Да, а в итоге все порой приходит к пичканию всех древним софтом
>for no reasons.При том заявы что это ради стабильности выглядят по-идиотски.Скажем
>взять тот же нжынкс. Новые его версии сроду чинят всякие там краши.И,
>пардон, как старая версия оного может быть стабильнее новой, если в
>новой починен краш?А вот дебианщики будут "ради стабильности" до упора пичкать
>древнючей версией.У nginx вообще до недавних пор стабильных версий не было. А это значит, что наряду с исправлениями багов в него вносились и различные изменения, мог поменяться формат конфигов или какая-то деталь поведения.
Бездумные скачки с версии nginx на версию могут привести к тому, что в результате обновления на стабильно и без участия админа работающем сервере что-нибудь отвалится. Оно нам нужно? Нет, спасибо, не охота повторять чужие ошибки (каких было вагон и маленькая тележка у Microsoft с её обновлениями).
Вместо замены версии мэнтейнеры Debian, в соответствии с политикой разработки, могут бэкпортировать только исправления ошибок или править их сами, всё.
Если выбрали недоделку (nginx), то уж тогда будьте добры, ловите ваши шишки по полной программе и не говорите, что в этом виноват кто-то кроме вас.
>Что вынудит ... правильно, собрать нормальную версию самому, например.Только вот
>напуркуа тогда пакетная система и репы вообще нужны, если половину софта
>приходится руками собирать?В итоге очень уж напоминает того робота, который был
>готов ради блага своих подопечных (снижения веса) заморить их нафиг голодом.Вот
>дебианщики с их упорством похожи на этого железного болвана иной раз."Ради
>вашего же блага" пичкают древним хламом времен царя гороха."Ради стабильности".Ну да,
>я помню стабильность с ключами ssl и т.п. - рекеить вагон
>машин мне понравилось, да :)У вас пластинка на канавке со словами "ssl" и "debian" заела. Пните уже себя чем-нибудь.
>И помню как стабильно обламывался снос нжынксы.Так
>что мало того что поставится древнее г... так потом еще и
>не снесешь стандартным методом.Как мило.В свете этого декларации по части стабильности
>не всегда выглядят убедительно.В моем понимании - если вместо ослиного упрямства
>и тупого формализма использовать человеческий разум - могло бы быть и
>лучше."Человеческий разум" не поддаётся формализации. В любой системе самое слабое звено - человек. Что русскому хорошо, то немцу - смерть. Если в результате вашей "разумности" у меня что-то отвалится, то идите вы лучше на... более другие дистрибутивы, дерите свою лужёную глотку там.
</thread>
>Бездумные скачки с версии nginx на версию могут привести к тому, что
>в результате обновления на стабильно и без участия админа работающем сервере
>что-нибудь отвалится.Вот это - хорошо сказано.И именно в этом плане дебиан хорошая система.Иногда.
>Оно нам нужно? Нет, спасибо, не охота повторять чужие ошибки
Да я и своих проблем честно говоря в дебиане вижу.Думаете, у них только с нжинксом кривизна?Например если взять lighttpd 1.4.х который стабильный и формат конфига обычно не ломается - да, до упора пичкали антикварным 1.4.13. Зато вот косяков с правами на логи особенно если юзать недефолтного юзера у этих молодчиков - есть.Стабильночть чтопиндец, да.Древним шытом напичкать не забыли.А вот зато то ради чего это якобы делается (стабильность и безпроблемность) - оно где?Бесспорно иногда оно работает (как в случае фокусов мистера Ульриха с glibc сломавших народу LDAP серваки).Но иногда - просто упорное пичкание хламом при полной совместимости новой версии со старой и фактическом отсутствии той самой стабильности.
>Вместо замены версии мэнтейнеры Debian, в соответствии с политикой разработки, могут бэкпортировать
>только исправления ошибок или править их сами, всё.Ну я в курсе.В итоге порой до упора пичкают древним и нерабочим или полурабочим дерьмом с завидным упорством.Политика достойная уважения, да.Нет, иногда она здорово выручает(от саботажников типа Ульриха спасет однозначно и это - гут).Но иногда от такой политики больше вреда чем пользы.Вот я и не понимаю что
>Если выбрали недоделку (nginx), то уж тогда будьте добры, ловите ваши шишки
>по полной программе и не говорите, что в этом виноват кто-то
>кроме вас.Эээ ну если они недоделку засунули в реп и что-то такое втирают про стабильность - пусть тогда бэкпортят фиксы крэшей, раз такие умные?Зачем же пичкать нестабильной недоделкой с багами и втирать про стабильность?Это попахивает на$%аловом.Когда на словах одно а на деле - другое.В моем понимании - нормальный подход это удостовериться что новая *минорная* версия ничего не рушит и положить ее, если это и правда вот так :).Новые мажорные или несовместимые - упаси боже, ессно.Как раз из изложенных вами соображений про обновления.Чтоб не дай боже не порушилось ничего на живых машинах.
>У вас пластинка на канавке со словами "ssl" и "debian" заела. Пните
>уже себя чем-нибудь.Ну я понимаю что вам сие досадно, но рекеинг пачки машин - это незабываемо!Такое бывает наверное считанные разы в жизни.И да - поэтому я буду это иногда мстительно припоминать.При всем уважении к Дебиану.Который хорошая система в целом но со своими недостатками ;).
>"Человеческий разум" не поддаётся формализации.
А, знаете, панацеи вообще не бывает.Нельзя сделть формализованную заведомо выигрышную тактику поддержания репозиториев.В моем понимании - лучше бы они иногда ориентировались по ситуации.Вместо втюхивания "стабильного" фуфла которое может вообще не заработать в итоге.Особенно сие касается сетевых программ и т.п. - где все остальные могут на раз-два-три просто отказаться работать с вашей старой версией программы.Решив что им ни к чему ждать пару лет тормозов и потому, кто не проапгрейдился - тот пролетает.В таких случаях от дебиановской политики иногда выходит больше вреда чем пользы (впаривается заведомо неработоспособный пакет достаточно продолжительное время, а сие в общем то немного так саботажем попахивает - впечатление от системы у юзерей резонно портится).
>В любой системе самое слабое звено - человек.
Но покуда программы пищут люди - вам придется с этим жить.И как правило - я доверяю авторам программы больше чем майнтайнерам(потому что саботажа от авторов я видел меньше чем впаривания заведомого хлама который не работает или страдает проблемами от майнтайнеров).Их попытки быть святее авторов - порой анноят.Более того - иногда доходит до идиотизмов и по сути обычного саботажа как результата такой политики.Например дебианщики упорно пихали (и вроде даже до сих пор продолжают?) тот же Nexuiz 2.4 насколько я помню.А то что практически все серваки резко обновились до 2.5.х и не совместимы с этим хламом (он с ними просто не работает корректно и крутит назойливую надпись насчет обновления) - их, ессно, не волнует.В итоге имеется фактически СТАБИЛЬНО БЕСПОЛЕЗНЫЙ пакет, годный только на то чтобы отправить его в треш.Потому как юзать этот хлам разумеется невозможно - остальные не собираются взаимодействовать по сети с древним говном.В итоге - проблем нет у кого угодно.Кроме дебианщиков и, порой, по наследству - у убунтуйцев(эти имеют в запасе козырной чит - обновление версий предсказуемо и случается раз в полгода).
>Что русскому хорошо, то немцу - смерть. Если в результате
>вашей "разумности" у меня что-то отвалится, то идите вы лучше на...Это вы хорошо и правильно говорите.Но если в результате консервативности впаривается чуть ли не годами неработспособный или убогий и бажный софт - тоже нехорошо, а?Вот я и хотел бы - не просто машинной долбежки а некоторой гибкости под ситуацию.Скажем - что мешает обновить Nexuiz до 2.5.х чтобы юзерье дебиана\убунты перестало неизвестно за что иметь мозг его разработчикам, например?И что и у кого при этом отвалится?Особенно учтя что оно УЖЕ НЕ РАБОТАЕТ, потому что админы серверов в гробу видали это 2.4.х, обновились до 2.5.х и более того - 2.4.х попросту не работает нормально с серверами 2.5.х а других серверов как бы и не осталось особо.В итоге у всех все работает.Кроме ... юзеров дебиана.Ну и убунты по наследству.Отличная политика, да.Ну а если кто на свою жопу юзал дебиан и допустим гонял сервер?Правильно - ему придется как лоху компилячить самому или качать блобы с сайта авторов.Ну а пакетный манагер, гордость и достоинство дебианщиов - в энный раз остается не у дел у кучи юзеров, заставляя их переходить к неандертальским методам управления софтом на уровне достойном разве что Виндовс 95 да LFS :\
>более другие дистрибутивы, дерите свою лужёную глотку там.
Эээ т.е. "дебиан с человеческим лицом" не возможет в принципе?И пичкание заведомо неработоспособным или горбатым софтом вас не смущает и вы не считаете что надо попытаться это исправить?Разумеется, не создавая проблем тем у кого и так все работает - такое должно применяться избирательно и только там где это реально надо (как то впаривается пакет который в новых обстоятельствах вообще не может работать корректно например и т.п.) ;).И вот ей-богу - я зуб дам что дохакать например Nexuiz 2.4 до совместимости с серваками 2.5 кишка тонка у всех.Никто не будет это делать.А честно заменить пакет на новую версию (единственный вменяемый вариант действий) не позволит дебиановская религия ;).Ну как же, на костер еретиков.Пусть лучше юзерье и дальше думает что земля плоская а nexuiz 2.5 не вышел (правда с этим некоторые проблемы - весь остаьной мир так не считает и потому такие юзеры просто не велкам с их древним клиентом вообще).Безусловно, это способствует безгеморройному использованию системы, да.
>Да я и своих проблем честно говоря в дебиане вижу.Думаете, у них
>только с нжинксом кривизна?Например если взять lighttpd 1.4.х который стабильный и
>формат конфига обычно не ломаетсяЕсли _обычно_ - это уже не подходит.
>>Если выбрали недоделку (nginx), то уж тогда будьте добры, ловите ваши шишки
>>по полной программе и не говорите, что в этом виноват кто-то
>>кроме вас.
>
>Эээ ну если они недоделку засунули в реп и что-то такое втирают
>про стабильность - пусть тогда бэкпортят фиксы крэшей, раз такие умные?(На брудершафт не пили, но Вы вызываете у меня своими криками очень гадливое чувство, поэтому буду обращаться на ты.)
Если такой умный, может перестанешь на время флудить и пойдёшь сделаешь бэкпорт? Всё свободное ПО держится на тихих и скромных людях, которые просто делают своё дело, а не на таких крикунах-потребителях как ты. Только такие как ты могут плеваться в кормящую их руку.
>Зачем
>же пичкать нестабильной недоделкой с багами и втирать про стабильность?Это попахивает
>на$%аловом.Когда на словах одно а на деле - другое.В моем понимании
>- нормальный подход это удостовериться что новая *минорная* версия ничего не
>рушит и положить ее, если это и правда вот так :)Вам на CentOS (http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3/Russia...). А ещё лучше - на платный RHEL. Или организуйте свой Debian, с блэк-джеком и шлюхами. Препятствовать вам никто не будет, тем более что нужно всего-то организовать небольшой репозиторий, в который поместить бэкпортированные версии программ, исходя из ваших представлений о разумности.
>>У вас пластинка на канавке со словами "ssl" и "debian" заела. Пните
>>уже себя чем-нибудь.
>
>Ну я понимаю что вам сие досадно, но рекеинг пачки машин -
>это незабываемо!Такое бывает наверное считанные разы в жизни.И да - поэтому
>я буду это иногда мстительно припоминать.При всем уважении к Дебиану.Который хорошая
>система в целом но со своими недостатками ;)Меня это не коснулось. На тот момент на машинах, за которые отвечал я, доступ по ключам не использовался. Недостатки есть везде, вам никто и не хочет предложить панацею. Достаточно припомнить про отсутствие проприетарных пакетов и прошивок в умолчальном Debian. Но трактовать ли это как недостаток или как достоинство, это зависит от личных предпочтений каждого.
>
>>"Человеческий разум" не поддаётся формализации.
>
>А, знаете, панацеи вообще не бывает.Нельзя сделть формализованную заведомо выигрышную тактику поддержания
>репозиториев.В моем понимании - лучше бы они иногда ориентировались по ситуации.Ну вот, опять 25. А как определить когда наступит это "иногда", когда можно будет отступить от правил?
>Но покуда программы пищут люди - вам придется с этим жить.И как
>правило - я доверяю авторам программы больше чем майнтайнерам(потому что саботажа
>от авторов я видел меньше чем впаривания заведомого хлама который не
>работает или страдает проблемами от майнтайнеров).А я больше доверяю мэнтейнерам. Я знаю чем отличается программист от инженера. Мэнтейнеры - это инженеры. Хотя конечно мэнтейнеры тоже люди и бывают очень разными. Но цель создания формальной политики разработки как раз и состоит в том, чтобы задать некий уровень, ниже которого опускаться нельзя. У меня есть претензии к мэнтейнеру пакета pppoe: пакет собран без поддержки pppoe на уровне ядра, не имеет сценариев инициализации для pppoe-server и pppoe-relay. Я написал недостающие сценарии и собрал pppoe необходимым образом, собираюсь (да всё пока не соберусь) отправить свои наработки мэнтейнеру. Я не ору на форумах какое всё в Debian говно и когда же наконец это исправят.
>тот же Nexuiz 2.4 насколько я
>помню.А то что практически все серваки резко обновились до 2.5.хДа, бля, это о*уенная проблема. Возьми его из бубунты (http://www.getdeb.net/release/4236), а лучше сразу вали на неё.
>Эээ т.е. "дебиан с человеческим лицом" не возможет в принципе?И пичкание заведомо
>неработоспособным или горбатым софтом вас не смущает и вы не считаете
>что надо попытаться это исправить?Я считаю что Debian предоставляет наилучшую базу, оттолкнувшись от которой можно собрать персональную полностью устраивающую себя систему. И я не считаю нужным это исправлять, по крайней мере не в стабильной ветке.
Если Debian настолько глубоко задел вашу ранимую душу, предлагаю закончить нытик-тред и немедленно сделать вдоль.
>Если _обычно_ - это уже не подходит.Т.е. предполагается что для майнтайнера включить мозг при пересборке пакета и провести минимальное изучение ченжлога и т.п. - непосильная задача, а уж тесты и вовсе придумал трус?Или WTF?
>гадливое чувство, поэтому буду обращаться на ты.)
А мне пофиг :P.Более того - в фидохе например обращение на "вы" вообще считалось формой наезда.В итоге очень трудно понять - что же по факту следует считать наездом.Иногда например подчеркнутая вежливость - это не супер-культура а наезд.Такие вот чудеса общения :)
>Если такой умный, может перестанешь на время флудить и пойдёшь сделаешь бэкпорт?
Это я так понимаю предложение в стиле "если гора не идет к Магомеду"?Ну ладно, тогда см.ниже вопрос про репы :)
>Всё свободное ПО держится на тихих и скромных людях, которые просто
>делают своё дело, а не на таких крикунах-потребителях как ты. Только
>такие как ты могут плеваться в кормящую их руку.Да, я так смотрю - кормят какой-то полутухлой фигней.А за попытку посоветовать улучшения рецепта еще и в бубен хотят отсыпать.Малацца, так держать, даешь "качество" в массы.Вы думаете, я ругаюсь чисто для того чтобы поплеваться?А я думал несколько иначе - озвучил то что мешало лично мне иметь дело без геморроя с данным дистром.
>Вам на CentOS (http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3/Russia...-
>2f3c83399b8430f0b35eb6405c6447352259ec7d).Это у которого вообще софта с гулькин нос?Я его пробовал.Есть одна проблемка - yum имхо гадость несусветная.Дебиановскому пакетному манагеру сливает на всех фронтах.Тормозная и неудобная гадость :).Как-то не пришелся мне по вкусу.Ну а если пакетной системой пользоваться противно даже на уровне юзера, то уж пакеты под нее строить я и подавно не буду, пардон.
>А ещё лучше - на платный RHEL.
Опять же - смотря где.Если на продакшн серверах, когда контора платит - почему бы и нет?Администрячить сие скрепя сердце - можно. Для души? Не, штуки с yum для души быть не могут.Потому как гадость этот yum несусветная.Тормозная, глючная и в сумме - противная в юзеже.У дебианщиков пакетный манагер на голову лучше имхо.Да и не заметил я у редхата мании по части свежего софта.Свежий у них в федоре.А как минимум в том же центосе можно и древний шыт получить.Ничуть не хуже дебиана в общем то.При том если это новая инсталляция - кто б мне сказал: зафиг мне совместимость с хламом чуть ли не с эпохи мсдос? :)
>Или организуйте свой Debian, с блэк-джеком и шлюхами.
Погодите, что-то я такое припоминаю.А разве не так появилась Убунту?А потом начинается бухтеж - дескать сволочи, незаслуженно популярность набрали!Вот уроды!У убунтуйцев в плане древности софта кстати есть некое преимущество.Хоть у них и действует в общем случае та же политика, но иногда для нее делают исключения, например, в случае Firefox.
И моменты мажорных подтяжек версий - известны и предсказуемы.И их можно вручную проконтролировать.Это лишь раз в полгода и совсем не обязательно делать апгрейд версии дистриба автоматом.Зато подтяжка версий софта дважды в год - это хорошо.Несколько лимитирует последствия дебиановского наследия когда могут до упора пичкать древним или даже уже не работающим софтом "для вашего же блага".
>Препятствовать вам никто не будет, тем более что нужно всего-то организовать
>небольшой репозиторий, в который поместить бэкпортированные версии программ,
>исходя из ваших представлений о разумности.Вообще, знаете, в принципе уже давно вертится подобная мысль.Потому как если никто не делает... в общем данная мысль меня уже посещала.Потому что вот чесслово - запарило видеть нытье юзеров убунты и дебиана по части старья.Когда их всякий сетевой и прочий подобный софт футболит - "У вас слишком старая версия. Пройдите, пожалуйста, нафиг, мы более не поддерживаем этот древний булшит". И так до полугода в убунте и фиг знает сколько в дебиане - как-то не очень весело.
Раз уж вы тут такой умный и злой - может подскажете о том как технически создается свой реп?В смысле, что для этого со стороны веб-сервака надо сделать? (какие файлы и каталоги нужны, etc и как это цивильно и безгеморно генерячить). Разжевывать не надо, просто скажите где почитать.А то уже пробовал гуглить но нормальных руководств что-то не попалось пока.Как злющий дебианщик вы наверное сможете выдать пинка в правильную сторону :)
>и прошивок в умолчальном Debian. Но трактовать ли это как недостаток
>или как достоинство, это зависит от личных предпочтений каждого.Это факт.Тем более что это благо для например тех кто хочет сделать свой дистр на основе дебиана.Отсутствие лицензионных подстав - ценное свойство.За что дебиан достаточно широко используют как некую базу для создания чего-то своего.Сие правда ему пакостит когда он в роли десктопной системы.Если для сетевой железки нет фирмваре а через нее то и работал интернет - упс... может получиться модернизированный вариант шутки pkunzip.zip ;)
>Ну вот, опять 25. А как определить когда наступит это "иногда", когда
>можно будет отступить от правил?Ну например, для "некритичных" пакетов, скажем, игр, P2P и прочая можно было бы использовать более гибкую политику.А то когда легендарная стабильность выливается в только то что древнего клиента отовсюду стабильно футболят как мячик "мы не собираемся поддерживать 100 лет совместимость с вашим хламом, please update, Luke!" сие как-то не очень правильно.Стабильно нерабочий\полурабочий софт - suxx.Вы так не считаете?Да, можно там заменить софтинку левыми методами, сям заменить... но когда таких оказывается с десяток, возникает вопрос: а какого черта юзер вручную педалит работу пакетного манагера без его помощи?Отслеживать десяток или более софтин самолично - уже некая возня.
>А я больше доверяю мэнтейнерам. Я знаю чем отличается программист от инженера.
Ну я понимаю чем разработчик и майнтайнер отличается - goals у них разные.Вот только ИМХО майнтайнерам не зазорно бы следить за тем к чему в итоге *по* *факту* приводит следование их goals'ам а не чисто по технологии "на отвали" долбить до упора формальную политику.Выдавая на гора софт который уже никому не нужен а то и попросту уже не работает т.к. все остальные отказываются взаимодействовать с столь древним хламом по сети, etc.Вот с nexuiz например такой подход во весь рост.И не только с ним.Это как наиболее свежий пример с которым пришлось столкнуться.
>состоит в том, чтобы задать некий уровень, ниже которого опускаться нельзя.
Да я как бы прекрасно понимаю что ломать работающую систему людям - зло.Большое зло.Но я также понимаю и то что впаривание заведомо дохлых или ну совсем уж морально устаревших пакетов - тоже зло.Т.к. ведет к не особо положительному мнению юзеров о такой системе.Чего хорошего если вам отгрузили пакет который например вообще почти не работает в современных реалиях?
>не ору на форумах какое всё в Debian говно и когда же наконец это исправят.
Я вроде не орал про то что "дебиан говно".Я всего лишь ворчал про некоторые объективно существующие минусы.С которыми, черт возьми, пришлось столкнуться на практике.В сумме Дебиан неплохая система, особенно на серваках и т.п..Если б не отдельные досадные моменты вот такого плана.
>Да, бля, это о*уенная проблема. Возьми его из бубунты
Ха-ха, вы будете смеяться, но там он тоже в основном репе 2.4.х. И тоже не рабочий по сути, т.к. все админы серверов поставили 2.5 и - более того, ставить даже сервер 2.4 лишено смысла т.к. 99% клиентов в силу этого обновились до 2.5 :).Зато дебианщики и убунтуйцы мило выносят мозг окружающим, которые никак не виноваты в тормозах майнтайнеров и дурацких дебиановских политиках которым до буквы следуют даже когда это создает больше проблем чем решает.В итоге такой типовой диалог:
- А чего это у меня баги когда я конекчусь к серверу?
- А у вас какой клиент?
- 2.4.х
- А этот древних хлам уже не поддерживается - он когда вышел, вашу мать?!
Далее юзерье вынуждено делать что угодно.Кроме нормального использования пакетного манагера по назначению штатным образом.Потому что мало кого устроит "стабильная" но, увы, попросту неработоспособная в новых реалиях версия.>сразу вали на неё.
Самый лол - это в данном случае не помогает.Дебиановское наследие, фигли :D.При том хоть застрелите - не понимаю какой смысл печься о "стабильности" того что уже и так по сути не работает out of the box (ну, сервера 2.5 попросту не будут нормально работать с 2.4.х и маячит назойливый баннер - обновите, дескать, ваш клиент).И если б это только с nexuiz.Такого добра - хватает.Он - как наиболее колоритное и злободневное на что я недавно наткнулся.
>Я считаю что Debian предоставляет наилучшую базу, оттолкнувшись от которой можно собрать
>персональную полностью устраивающую себя систему.Вот это - хорошо сказано.Только вот это заставляет всех быть немножечко майнтайнерами и т.п. по сути :).Нету работающего nexuiz?Хаха - сами скомпиляете!Или грузите дедовскими методами блобы с сайта, как в виндах.Или там еще что придумывайте.Но только не цивильными способами поставить 1 пакет без всяких "стоя, в гамаке".Как это называется?Правильно - майнтенанс пакета по принципу "на отвали".Номинально - пакет вроде как есть.Политикам дебиана - соответствует.Можно гордо задекларить - "у нас почти 20 000 пакетов".А то что не работает нифига - да и ладно, наши юзеры не тупые, как-нибудь сами вырулят.Мне кажется что в ряде случаев можно и лучше было бы.Если озаботиться фактическим результатом "все работает без проблем" несколько больше чем унылым формализмом который в итоге не всегда достигает цели "все работает без проблем".
>И я не считаю нужным это исправлять, по крайней мере не в стабильной ветке.
Ну, могли бы завести какую-то хитрую ветку - типа стабильной ветки но с обновлениями некоторого не слишком критичного софта.
>Если Debian настолько глубоко задел вашу ранимую душу,
А почему - глубоко?Я просто показываю некоторые существующие проблемы.Такое ощущение что это вас почему-то сильно задело.Что вообще-то странно, учтя что идеал вообще недостижим.Но стремиться то надо, и желательно не формально а нацелившись на фактический результат.А то получается "мы тут собрали какой-то пакет, как он работает в современных реалиях мы не проверяли, на его и отвали от нас в туман, чувачок!А если заявишь что надо версию подтянуть - мы тебе в бубен настучим!Потому что наши религиозные чувства и формалии важнее чем работающий пакет!И ты, сволочь, их оскорбил!Урррод!Потребитель!Быдло!Потому что не хочешь наши геморные правила соблюдать и жрать старье!Каааазел!".
>Т.е. предполагается что для майнтайнера включить мозг при пересборке пакета и провести
>минимальное изучение ченжлога и т.п. - непосильная задача, а уж тесты
>и вовсе придумал трус?Или WTF?Предполагается что пользователи Debian должны быть на 100% уверены, что изменения в дистрибутиве не зависят от желания левой пятки мэнтейнера. Оттестировать на всех возможных конфигурациях пакет невозможно. Для тестирования есть ветка с таким же названием - testing.
>Да, я так смотрю - кормят какой-то полутухлой фигней.
Не ешь, тебе в рот это не суют.
>>Вам на CentOS (http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.3/Russia...-
>>2f3c83399b8430f0b35eb6405c6447352259ec7d).
>
>Это у которого вообще софта с гулькин нос?Я его пробовал.Суть в том, что там в стабильной ветке версии программ иногда меняются, в отличие от Debian. И срок поддержки значительно дольше.
>>Или организуйте свой Debian, с блэк-джеком и шлюхами.
>Погодите, что-то я такое припоминаю.А разве не так появилась Убунту?Х.з. мне цели Ubuntu не очень понятны. Желание захватить мир?
>А потом начинается бухтеж - дескать сволочи, незаслуженно популярность набрали!Вот уроды!
Это орут идиоты, не понимающие целей свободного программного обеспечения.
>[оверквотинг удален]
>>небольшой репозиторий, в который поместить бэкпортированные версии программ,
>>исходя из ваших представлений о разумности.
>
>Вообще, знаете, в принципе уже давно вертится подобная мысль.Потому как если никто
>не делает... в общем данная мысль меня уже посещала.Потому что вот
>чесслово - запарило видеть нытье юзеров убунты и дебиана по части
>старья.Когда их всякий сетевой и прочий подобный софт футболит - "У
>вас слишком старая версия. Пройдите, пожалуйста, нафиг, мы более не поддерживаем
>этот древний булшит". И так до полугода в убунте и фиг
>знает сколько в дебиане - как-то не очень весело.Во-первых, у Debian есть официальный репозиторий backports. Во-вторых, есть официальный репозиторий volatile. В третьих, есть полуофициальный (неофициальный, но поддерживаемый теми же людьми) репозиторий multimedia. Это первое средство для смягчения недостатков. Второе средство - пользоваться смешанной системой. Например я пользуюсь stable, но у меня подключены репозитории testing, unstable и experimental, из которых я при желании могу установить те пакеты, которые в stable мне кажутся устаревшими.
Например, содержимое моего файла /etc/apt/sources.list (это локальное зеркало, при желании найдёте подходящие вам зеркала):
deb http://ufadeb.homelinux.org/debian/ lenny main contrib non-free
#deb http://ufadeb.homelinux.org/backports/ backports-lenny main contrib non-free
deb http://ufadeb.homelinux.org/security/ lenny/updates main contrib non-free
deb http://ufadeb.homelinux.org/volatile/ lenny/volatile main contrib non-free
deb http://ufadeb.homelinux.org/multimedia/ lenny main contrib non-free
deb http://ufadeb.homelinux.org/debian/ testing main contrib non-free
deb http://ufadeb.homelinux.org/debian/ sid main contrib non-free
deb http://ufadeb.homelinux.org/experimental/ experimental main contrib non-freeИ в файле /etc/apt/preferences:
Package: *
Pin: release a=stable
Pin-Priority: 1001Package: *
Pin: release a=lenny
Pin-Priority: 1001Package: *
Pin: release a=testing
Pin-Priority: 50Package: *
Pin: release a=squeeze
Pin-Priority: 50Package: *
Pin: release a=unstable
Pin-Priority: 50Package: *
Pin: release a=sid
Pin-Priority: 50Package: *
Pin: release a=experimental
Pin-Priority: 50Посмотреть версии определённого пакета во всех репозиториях:
apt-cache policy iceweaselПоставить пакет из нужного репозитория:
apt-get install iceweasel/unstableНу и третий способ - самостоятельное бэкпортирование необходимых пакетов.
>Раз уж вы тут такой умный и злой - может подскажете о
>том как технически создается свой реп?В смысле, что для этого со
>стороны веб-сервака надо сделать? (какие файлы и каталоги нужны, etc и
>как это цивильно и безгеморно генерячить). Разжевывать не надо, просто скажите
>где почитать.А то уже пробовал гуглить но нормальных руководств что-то не
>попалось пока.Как злющий дебианщик вы наверное сможете выдать пинка в правильную
>сторону :)Это легко гуглится: http://l10n-russian.alioth.debian.org/repository-howto.ru.html
>Ну например, для "некритичных" пакетов, скажем, игр, P2P и прочая можно было
>бы использовать более гибкую политику.А то когда легендарная стабильность выливается в
>только то что древнего клиента отовсюду стабильно футболят как мячик "мы
>не собираемся поддерживать 100 лет совместимость с вашим хламом, please update,
>Luke!" сие как-то не очень правильно.Стабильно нерабочий\полурабочий софт - suxx.Вы так
>не считаете?Да, можно там заменить софтинку левыми методами, сям заменить... но
>когда таких оказывается с десяток, возникает вопрос: а какого черта юзер
>вручную педалит работу пакетного манагера без его помощи?Отслеживать десяток или более
>софтин самолично - уже некая возня.Вы не считаете что в этой ситуации виноваты все понемножку? Разработчик - потому что не выпускает стабильные ветки и периодически что-то ломает. Мэнтейнеры одних дистрибутивов - потому что тащат всё свежее, мэнтейнеры других - потому что слишком консервативны. Пользователи - потому что в большинстве случаев им не важно, что всё и так работает, им нужна цифра. Чем больше цифра в номере релиза и версии, тем круче. Из-за них админы игровых серверов могут поспешить заменить исправно работающую версию программы на новую. Потом те, кто спешит обновляться, постоянно орут, что всё свежее - глючное говно (и обобщают свой вывод вообще на всё СПО), а всё надёжное - засохшее говно мамонта.
>>состоит в том, чтобы задать некий уровень, ниже которого опускаться нельзя.
>
>Да я как бы прекрасно понимаю что ломать работающую систему людям -
>зло.Большое зло.Но я также понимаю и то что впаривание заведомо дохлых
>или ну совсем уж морально устаревших пакетов - тоже зло.Т.к. ведет
>к не особо положительному мнению юзеров о такой системе.Мнение таких юзеров мэнтейнеров Debian волнует мало. Если человек не может выбрать себе подходящий дистрибутив, а лезет в чужой монастырь со своим уставом - его мнение какбэ ничего не стоит.
>Чего хорошего если
>вам отгрузили пакет который например вообще почти не работает в современных
>реалиях?Какое-то мутное утверждение "не работает в современных реалиях". Либо программа работает либо нет. Программа - что, сломается по прошествии двух-трёх лет сама по себе? Ни одна по-настоящему серьёзная вещь за такое время не поменяется настолько сильно, чтобы потерять совместимость с предыдущими версиями, а всё остальное - игрушки.
>>Да, бля, это о*уенная проблема. Возьми его из бубунты
>Ха-ха, вы будете смеяться, но там он тоже в основном репе 2.4.х.
>>сразу вали на неё.
>Самый лол - это в данном случае не помогает.Дебиановское наследие, фигли :D.При
>том хоть застрелите - не понимаю какой смысл печься о "стабильности"
>того что уже и так по сути не работает out of
>the box (ну, сервера 2.5 попросту не будут нормально работать с
>2.4.х и маячит назойливый баннер - обновите, дескать, ваш клиент).И если
>б это только с nexuiz.Такого добра - хватает.Он - как наиболее
>колоритное и злободневное на что я недавно наткнулся.Аш писец какое злободневное, играть невозможно! А я дмуаю, что это вы на Opennet флудить чаще стали?
>>Я считаю что Debian предоставляет наилучшую базу, оттолкнувшись от которой можно собрать
>>персональную полностью устраивающую себя систему.
>
>Вот это - хорошо сказано.Только вот это заставляет всех быть немножечко майнтайнерами
>и т.п. по сути :). Нету работающего nexuiz? Хаха - сами скомпиляете! Или грузите
>дедовскими методами блобы с сайта, как в виндах.Или там еще что
>придумывайте.Вообще Debian stable - это система для людей, которые РАБОТАЮТ. Для них обычно игры не настолько важны. А кому всё-таки настолько сильно, в кровь из носа, захочется поиграть - тот соберёт себе нужный пакет, либо поставит в дуалбут другую систему специально для игр.
>Но только не цивильными способами поставить 1 пакет без всяких "стоя,
>в гамаке".Как это называется?Правильно - майнтенанс пакета по принципу "на отвали".Номинально
>- пакет вроде как есть.Политикам дебиана - соответствует.Можно гордо задекларить -
>"у нас почти 20 000 пакетов".А то что не работает нифига
>- да и ладно, наши юзеры не тупые, как-нибудь сами вырулят.Мне
>кажется что в ряде случаев можно и лучше было бы.Если озаботиться
>фактическим результатом "все работает без проблем" несколько больше чем унылым формализмом
>который в итоге не всегда достигает цели "все работает без проблем".Вам на убунту. Вы уже сказали, что это попытка избавиться от недостатков Debian. Только видимо кишка всё таки тонка сделать правильную вещь, раз Вы орёте, что даже в ней нет нужной версии Nexuiz.
>>И я не считаю нужным это исправлять, по крайней мере не в стабильной ветке.
>Ну, могли бы завести какую-то хитрую ветку - типа стабильной ветки но
>с обновлениями некоторого не слишком критичного софта.Репозитории backports, volatile, multimedia, testing, sid, experimental, дистрибутивы sidux, ubuntu - выбор есть.
>>Если Debian настолько глубоко задел вашу ранимую душу,
>
>А почему - глубоко?Я просто показываю некоторые существующие проблемы.Такое ощущение что это
>вас почему-то сильно задело.Меня задевает настойчивая дурость пытаться залезть в чужой монастырь со своим уставом - попытка подбить мэнтейнера на нарушение политики. Всё, больше претензий у меня к Вам нет.
>Что вообще-то странно, учтя что идеал вообще недостижим.Но
>стремиться то надо, и желательно не формально а нацелившись на фактический
>результат. А то получается "мы тут собрали какой-то пакет, как он работает
>в современных реалиях мы не проверяли, на его и отвали от
>нас в туман, чувачок!А если заявишь что надо версию подтянуть -
>мы тебе в бубен настучим! Потому что наши религиозные чувства и формалии
>важнее чем работающий пакет!И ты, сволочь, их оскорбил!Урррод!Потребитель!Быдло!Потому >что не хочешь наши геморные правила соблюдать и жрать старье!Каааазел!".Так я вам же говорю - есть варианты. Никто не заставляет вас использовать стабильную ветку Debian. Считайте, что её для вас не существует, раз политика её разработки вас не устраивает. Если вы не можете понять и принять для себя это простое правило (запрет изменять версии программ в стабильной ветке) - то вы действительно урод, потребитель и быдло.
Ну и сколько всего серверов? И что нибудь посерьёзней чем почта и proxy есть?
VPN сколько тянет подключений и на какой скорости?
>Ну и сколько всего серверов? И что нибудь посерьёзней чем почта и
>proxy есть?
>VPN сколько тянет подключений и на какой скорости?А что вы понимаете под "посерьёзней"? У меня всё это для работы стоит.
3 сервера с рейд-массивами (своеобразное разделение файлсервера)
1 сервер бэкапов
1 почтарь с постфиксом, спамд и кламавом
1 прокся со сквидом, дружащим с AD
1 веб сервер
1 ВПН - конечная точка ipsec туннеля. Работает шлюзом для прокси и дает где-то 8 мбитный туннель до удалённого офиса. Плюс по мелочам пару человек из дома через него ходят в рабочую сеть.
>не ради холивора будет сказано, но как поддерживать то его??
>поставил убунту - всё обновляется со скоростью света. и adobe flash player(!!!!!)
>и firefox и thunderbird...OMG. Я нашел человека который шейпит на десктопе. Или Вам на сервере нужен флешь и прочие продукты тормозилло фаундешн?;))
>а с опнбсд? всё старое, дыревое, рекомендуемый
>способ установки - из прекомпилированных пакаджей. а оно там обновляется раз
>в год.. в общем возни с ним - не оберешься..А мужики из openbsd team и не знали, напишите им об этом.
p.s. поздравляю юзеров linux с появлением фаервола у них.
Пипец. Во фре порты обновляются можно сказать мнгоновенно. Недавно вышел clamav обновил сразу после оповещения новости на опеннете. А в генту 2 недели ждал пока закинут.
Это ж от конкретного ментейнера зависит а не от системы.
Наверное Марта очень красивая, раз смогла возбудить, тфу, побудить Луиджи Риццо так быстро портировать то, что долгое время считалось не портабельным. :)
М-да... Вот что значит, выдернутая из контекста новость. Марта провела работу по ревизии кода и по четкому разделению userspace и kernel-dependent кода ipfw. Одним из следствий этой работы должно было стать простота портирования front-end'а ipfw на любую другую платформу. Что собственно и было продемонстрировано.Сомневаюсь что кто-то всерьез будет поддерживать ipfw на платформе Linux. Никаких принципиальных преимуществ у ipfw перед iptables кроме чуть более простой интеграции за счет простоты структуры конфига, нет.
А вот от порта pf я бы действительно не отказался. Pf за счет поддержки внешних таблиц ip-адресов в плане возможностей автоматизации и интеграции наилучший на сегодняшний день.
Стоит сторонний софт, который по ssh работает только с ipfw. Фряху держали только ради него. Теперь там будет линукс и два сервера сольются в один.
А что вам мешало создать bash-скрипт /sbin/ipfw, который бы
элементарно синтаксис команд конвертил?! Уверен, что софт ничего сложного не делал - банальные allow/deny...
>А что вам мешало создать bash-скрипт /sbin/ipfw, который бы
>элементарно синтаксис команд конвертил?! Уверен, что софт ничего сложного не делал -
>банальные allow/deny...Фигня вопрос.
Тогда может полный синтаксис ipfw сделаешь ?
Там вообще одна полезная команда - add.
Ну что тебе стоит сделать одну команду ?
> Pf за счет поддержки внешних таблиц ip-адресов в плане возможностей автоматизации
> и интеграции наилучший на сегодняшний день.man ipset (google linux ipset)
этот способ абсолютно не годится. ipset везде надо вручную вкомпиливать в ядро. Ядро Линукса обновляется почти каждый месяц. Вы думаете всем нефиг больше делать?
Если Вы обновляете ядро на всех доступных машинах "почти каждый месяц" - Вам действительно нефиг делать :) Ничего личного, если что.
>Если Вы обновляете ядро на всех доступных машинах "почти каждый месяц" -
>Вам действительно нефиг делать :) Ничего личного, если что.я обновляю ядро по мере появления критичных ошибок безопасности. И такое бывает весьма часто.
>man ipset (google linux ipset)Ну, я бы сильно удивился, если бы на Linux'е не было вообще никакого аналога. Кстати, спасибо за подсказку, посмотрю. Правда Linux у меня на десктопе стоит, тут ipset вряд ли работа найдется. Но для общей эрудиции будет полезно...
лучше-бы под винду портанули
>лучше-бы под винду портанулиipfw под винду УЖЕ НЕСКОЛЬКО ЛЕТ как есть
с 2004 года есть.http://sourceforge.net/project/showfiles.php?group_id=113599
experimental 0.3.2
current 0.2.8
stable 0.2.7
1. Под Windows есть
2. но только для до Windows XP включительно:
на Vista не работаетхуже того: похоже и не будет его под вистой: Microsoft поменяла ядро, и сняла все те механизмы.
А как на счет совместимости лицензий?
>А как на счет совместимости лицензий?А что с ними? Лицензия BSD позволяет брать код и выпускать его под любой лицензией. GPL'щики в BSD-кода кормятся точно так же, как и проприетарщики.
>>А как на счет совместимости лицензий?
>
>А что с ними? Лицензия BSD позволяет брать код и выпускать его
>под любой лицензией.Лицензия BSD позволяет брать код, но лицензия на это код остается BSD.
GPL'щики в BSD-кода кормятся точно так же, как
>и проприетарщики.Все кормятся друг у друга. Только с GPL это не афишируется.
>>>А как на счет совместимости лицензий?
>>
>>А что с ними? Лицензия BSD позволяет брать код и выпускать его
>>под любой лицензией.
>Пиз..ж. Лицензия BSD позволяет брать код, но лицензия на это код остается
>BSD.Ну-ка ну-ка, попросите у мицросовт BSD-шный сетевой стек из винды. Или BSD-код JunOS или прошивки iPhone или прошивки Wasabi Systems. То, что открыто под BSD, таковым и останется, а кто что успел ухватить и подрихтовать, тот имеет право не делиться доработанным кодом и продавать его за деньги.
И ещё. Любой код, слинкованный статически или динамически с кодом GPL, становится автоматически GPL-кодом. Это вам не CDDL и не MPL.
>GPL'щики в BSD-кода кормятся точно так же, как
>>и проприетарщики.
>
>Все кормятся друг у друга. Только с GPL это не афишируется.С GPL тоже кормятся, но не настолько нагло, там всё по-другому. Если каким-то образом доработал GPL-код и продал его кому-то, то обязан отдать ему исходники под той же лицензией. Если доработал код под BSD, то можешь продавать его в открытую, а на просьбы дать исходники можешь ложить здоровенный болт.
Не путаем теплое с мягким. Я не говорю про дележку. Мой код остается МОИМ куда бы его не включили. Используете? - на здоровье. Т.е. применяя BSD я говорю - "господа, я тут что-то накропал. Если пригодится - берите ради бога". И потому сплю спокойно и имею хороший аппетит. Т.к. не переживаю, что кто-то заныкал часть собственного творчества. Не моего!.
>Не путаем теплое с мягким. Я не говорю про дележку. Мой код
>остается МОИМ куда бы его не включили. Используете? - на здоровье.
>Т.е. применяя BSD я говорю - "господа, я тут что-то накропал.
>Если пригодится - берите ради бога". И потому сплю спокойно и
>имею хороший аппетит. Т.к. не переживаю, что кто-то заныкал часть собственного
>творчества. Не моего!.И о чём спор? Вернитесь по ветке выше к самому первому вопросу: "А как на счет совместимости лицензий?" GLP+BSD=GPL Всё совместимо в пользу GPL, пользоваться фаерволлом из FreeBSD в Linux'е можно.
давайте вернемся:
> Лицензия BSD позволяет брать код и выпускать его под любой лицензиейэто в корне неверно.
зато в хоме отлично отрабатывает.
Один раз вы уже попробовали.
http://www.opennet.ru/opennews/art.shtml?num=11844
>Один раз вы уже попробовали.
>http://www.opennet.ru/opennews/art.shtml?num=11844Это называется Тео развонялся. Он начал требовать изменения в коде драйвера ath5k под лицензией BSD только из-за того, что исходники под GPL тоже оказались открыты и он смог увидеть изменения.
А теперь представим на секунду, что абсолютно та же самая ситуация произошла бы, допустим, в MS. MS доработала бы BSD-код под свои нужды, а исходники заперла на замок. Тео бы ничего не увидел и лаять бы не стал.
Требования сохранять лицензию BSD на код в самой лицензии не существует, существует лишь требование сохранить сам текст лицензии в исходном тексте (http://ru.wikipedia.org/wiki/%D0%9B%D0%B...), но добавить новые ограничения к этой лицензии можно (что и сделает лицензия GPL, если в исходники добавить ещё и её текст). Текст лицензии в исходном тексте присутствует? Присутствует! Тогда какие ещё могут быть претензии?
>GPL, если в исходники добавить ещё и её текст). Текст лицензии
>в исходном тексте присутствует? Присутствует! Тогда какие ещё могут быть претензии?Походу кому-то не нравятся последствия выбора лицензии.А чем они думали выбирая эту лицензию?Ну, они хотели дать всем свободу делать что угодно.Они это сделали.И остальные начали делать как раз это самое.Свободно использовать как угодно.Если хотелось чего-то иного - очевидно, следовало выбирать иную лицензию :D
>это в корне неверно.Ну да, под "почти любой".Ограничений в BSDL немного.Поэтому можно переиначить сие почти как угодно.Если эти немногочисленные ограничения соблюдены - все чики-пуки.
Вопрос уважаемым знатокам!
Поставил себе на убунту ipfwнастроил раздачу инета через NAT в iptables
подгружаю модуль ipfw_mod, NAT прекращаетсясчетчик пакетов тикает в iptables цепочке FORWARD и правиле ipfw
но на POSTROUTING в iptables правила не срабатывают
в linux как понимаю нет natd, а inkernel nat просто не реализован в текущей версии ipfw для linux.
есть и ещё какие-нибудь решения по одновременно работе NAT и ipfw под linux?
Если я правильно протелепатировал, в модуле_ipfw по умолчанию "deny from any to any". Добавь разрешающее правило.
+ ipfw nat смотрите
Некоторые так возмущаются о портирование будто вас призвали портировать а вы не хотите этого делать, раз начали портировать значит кому то это интересно а значит это имеет место быть
по шейпу вход. трафика есть IMQ
http://www.linuximq.net/usage.html
вот такое напишите на iptables ?
ipfw add 1 prob 0.01 deny icmp from any to me recv em0 xmit em2
>ipfw add 1 prob 0.01 deny icmp from any to me recv
>em0 xmit em2Вот такое напишите на ipfw2: http://www.netfilter.org/projects/patch-o-matic/pom-external...
>вот такое напишите на iptables ?
>
>
>ipfw add 1 prob 0.01 deny icmp from any to me recv em0 xmit em2Илья мне кажется вы плохо знаете ipfw. Обьясню почему.
Чисто со стороны логики если пакет forward(recv em0 xmit em2) то как он может быть to me, все же мне кажется что там должно быть from any to any recv em0 xmit em2Дальше, почитыйте ман:
So out is required (and in is invalid) whenever xmit is used.
вроде мне кажется что это обязательное условие.
В итоге имеем:ipfw add 1 prob 0.01 deny icmp from any to [out] [out] recv em0 xmit em2
Для такого правила я еще аналог в iptables приведу а к вашему оригиналу увы нет.
iptables -t mangle -A POSTROUTING -p icmp -i eth1 -o eth2 -j PROB
iptables -t mangle -A PROB -m statistic --mode random --probability 0.01 -j DROPМожно и в одно уложится если для вас это существенно, но я боюсь вы не осилите синтаксис.
>оригиналу увы нет.
>
>iptables -t mangle -A POSTROUTING -p icmp -i eth1 -o eth2 -j
>PROB
>iptables -t mangle -A PROB -m statistic --mode random --probability 0.01 -j
>DROPТак не покатит -- "Can't use -i with POSTROUTING" (но это можно обойти при помощи меток для пакетов). Что касается не/-правильности синтаксиса у приведённой строки на ipfw, то, увы, человек действительно не понимает, что он пишет.
у iptables к сожалению нет понятия "me", этого наиболее жаль. с вероятностями и in/out - практически одинаково, что на iptables, что на ipfw
Илья я конечно может многово не знаю, но мне вот на вскидку трудно найти применение этому правилу.Это знаете типа - Илья умеет какать в бутылку, это никому на*ер не нужно но он умеет :-)
>Илья я конечно может многово не знаю, но мне вот на вскидку
>трудно найти применение этому правилу.
>
>Это знаете типа - Илья умеет какать в бутылку, это никому на*ер
>не нужно но он умеет :-)хотя бы аналог "me" покажите в iptables
>хотя бы аналог "me" покажите в iptablesЯ не знаю, кто такой "me", но цепочки INPUT и OUTPUT - не оно?
>хотя бы аналог "me" покажите в iptablesДа без БЭ - -m addrtype --dst-type LOCAL.
Если вы не осилили man iptables то это еще не говорит о том что ipfw конкурент iptables'у
Если бы сравнивали с pf - я еще понимаю, а ipfw не конкурент :-)
насколько я помню в линуксе собирались переписать iptables ради человеческого синтаксиса. Как с этим обстоит дело?
google.ru + nftables...рассказал бы Вам, что http://www.netfilter.org/news.html#2009-03-18 вышел его первый релиз, который "is considered alpha quality and is not meant for users at this time", о чём писали многие новостные сайты. // http://marc.info/?l=linux-netdev&m=123735060618579 http://lwn.net/Articles/324989/ http:/openforum/vsluhforumID3/50862.html
А так -- "мыж никогда не узнаем"(тм)
http://www.rootconf.ru/papers2009/12352.html
Интересная инфа по ipfw
Думаю ng пока непортирован под linux так что линуксоидам остается ждать ...
>http://www.rootconf.ru/papers2009/12352.html
>Интересная инфа по ipfw
>Думаю ng пока непортирован под linux так что линуксоидам остается ждать ...Чего ждать-то? Каких-то абстрактных вкусностей?
Линуксоиды решают конкретные практические задачи. В том числе с помощью Xen (полноценной поддержки которого во FreeBSD нет), OpenVZ (аналога которому во FreeBSD вообще нет). Наслаждаются полноценной работой системы на архитектурах MIPS и ARM, гоняют без геморроя Oracle, пользуются полноценными системами пакетного менеджмента, которые позволяют не пересобирать программу на каждый чих.
А вы о каком-то NetGraph и ipfw, который NAT на уровне ядра только-только научился (и до сих пор не позволяет несколько PPTP-подключений из-за NAT'а).
Вопрос к знатокам ipfw. Можно ли в нем реализовать нечто подобное?$IPTABLES -A INPUT -p TCP --dport 22 -m state --state NEW -m recent --name SSHR --set
$IPTABLES -A INPUT -p TCP --dport 22 -m state --state NEW -m recent --name SSHR --update --seconds 60 --hitcount 4 -j DROP
$IPTABLES -A INPUT -p TCP --dport 22 -m state --state NEW -j ACCEPTp.s. Вопрос не флэйма ради, а чисто из практической необходимости использовать аналогичную штуку под фрей.