нужно обновить iptables до современной версии. при сборке xtables-addons-3.3 вылезло: checking for xtables >= 1.6.0... no configure: error: Package requirements (xtables >= 1.6.0) were not met: Requested 'xtables >= 1.6.0' but version of xtables is 1.4.21
Современная версия использует другой механизм в ядре - nft.
Да, я понимаю. У нас он не собран ?
сделал тестовое задание #225610 Посмотрим как работает.
Там с миграцией на nft не всё просто: https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables
да, я прочитал этот документ уже. Понятно что это кусок работы, но её надо всё-равно делать, пока не прижало. У нас может поломаться efw в etcnet ещё.
(In reply to comment #1) > Современная версия использует другой механизм в ядре - nft. Где-то видел обсуждение, что при сборке пока ещё можно выбрать.
*** Bug 31651 has been marked as a duplicate of this bug. ***
http://git.altlinux.org/tasks/225610/ Можно попробовать.
В legacy mode я разницы с текущим не особо заметил. Дима, что скажешь ?
(In reply to comment #9) > В legacy mode я разницы с текущим не особо заметил. iptables-legacy, насколько я помню - это практически то же самое, что у нас есть сейчас, и если все его модули на месте, должно работать так же. Я не понял, в какой мере предполагается сосуществование этих двух режимов. Они вроде бы предлагают дистрибутивам устанавливать одновременно и -legacy, и -nft, но как этим пользоваться?
по умолчанию iptables смотрит на iptables-legacy, но при этом появляется стек iptables-nft. Если у тебя не задействован iptables, то отлично работает iptables-ntf. Если же ты начал использовать iptables-legacy, то iptables-nft начинают выводить warning по этому поводу. Ну и iptables-save не меняется, но появляется iptables-nft-save, выполняющий аналогичную функцию. # rpm -ql iptables |grep nft /sbin/arptables-nft /sbin/arptables-nft-restore /sbin/arptables-nft-save /sbin/ebtables-nft /sbin/ebtables-nft-restore /sbin/ebtables-nft-save /sbin/ip6tables-nft /sbin/ip6tables-nft-restore /sbin/ip6tables-nft-save /sbin/iptables-nft /sbin/iptables-nft-restore /sbin/iptables-nft-save /sbin/xtables-nft-multi /usr/share/man/man8/xtables-nft.8.xz Ничего не ломаем и даём возможность плавно перейти.
Мы сегодня обсудили этот вопрос и пришли к выводу, что - поддержка nft по умолчанию не нужна; - поддержку nft можно либо не собирать совсем, либо упаковать в отдельный подпакет.
Упакуйте её, пожалуйста, в отдельный подпакет. Кому нужна - поставит, а нас это ни к чему не обязывает.
(В ответ на комментарий №13) > Упакуйте её, пожалуйста, в отдельный подпакет. +1
(В ответ на комментарий №14) > (В ответ на комментарий №13) > > Упакуйте её, пожалуйста, в отдельный подпакет. > > +1 Судя по relnotes RHEL8, в нем -- The nftables framework replaces iptables in the role of the default network packet filtering facility. Таким образом, поддержка nft, пусть пока опциональная, становится для нас важной, учитывая появление клонов.
Можно тестировать: [#229848] [test-only] EPERM (try 3) iptables.git=1.8.3-alt1
Я посмотрел и регрессий у себя не заметил. Мне кажется, что надо в сизифе обкатать пару недель.
Т.е. - в сизифе ничего не должно взорваться, можно пропускать в репозиторий и смореть.
(In reply to comment #17) > Я посмотрел и регрессий у себя не заметил. Не регрессия, но в теории кого-то может зацепить: $ compare_packages -- \ iptables-1.4.21-alt4.x86_64.rpm -- \ iptables-1.8.3-alt1.x86_64.rpm |grep '^-.*lib64' --rw-r--r-- root root , /lib64/iptables/libipt_MIRROR.so --rw-r--r-- root root , /lib64/iptables/libipt_SAME.so --rw-r--r-- root root , /lib64/iptables/libipt_unclean.so iptables-nft - это, по аналогии с федорой, отдельный подпакет и при обновлении никого зацепить не должен.
В сизифе такие изменения - нормальная практика, так что пускай цепляет.
по MIRROR, кстати, я не уверен что в ядре есть такой интерфейс. всегда пользовался для подобных целей -j TEE
(In reply to comment #19) > (In reply to comment #17) > > Я посмотрел и регрессий у себя не заметил. > > Не регрессия, но в теории кого-то может зацепить: Видимо, сейчас уже никого не зацепит, потому что из ядер поддержка была удалена гораздо раньше. > $ compare_packages -- \ > iptables-1.4.21-alt4.x86_64.rpm -- \ > iptables-1.8.3-alt1.x86_64.rpm |grep '^-.*lib64' > --rw-r--r-- root root , /lib64/iptables/libipt_MIRROR.so commit 73f453bb816d038792a849743d5055ad31b8ad76 Author: Florian Westphal <fw@strlen.de> Date: Thu Feb 19 01:17:18 2015 +0100 extensions: remove MIRROR removed from the kernel back in 2003. > --rw-r--r-- root root , /lib64/iptables/libipt_SAME.so commit 28972c60d7595e5a4986165ea6ae62a85f20d2e6 Author: Florian Westphal <fw@strlen.de> Date: Thu Feb 19 01:20:15 2015 +0100 extensions: remove SAME target removed from the kernel December 2007. > --rw-r--r-- root root , /lib64/iptables/libipt_unclean.so commit d81dc8e5f7e33646b3e56e274c46c3599275cbc1 Author: Florian Westphal <fw@strlen.de> Date: Thu Feb 19 01:27:36 2015 +0100 extensions: remove 'unclean' match removed from kernel in 2003.
[#229848] EPERM (try 4) iptables.git=1.8.3-alt1 ... #240 build 242-alt8 from /gears/s/systemd.git fetched at 2019-May-28 16:26:12 ... #400 build 2.0.15-alt2 from /gears/k/keepalived.git fetched at 2019-May-28 16:12:59 ... girar-check-perms: access to systemd DENIED for ldv: does not belong to approved builders list: shaba systemd: Operation not permitted girar-check-perms: access to keepalived DENIED for ldv: does not belong to approved builders list: rider shaba keepalived: Operation not permitted
keepalived approved.
iptables-1.8.3-alt1 -> sisyphus: Mon May 27 2019 Dmitry V. Levin <ldv@altlinux> 1.8.3-alt1 - 1.4.21 -> 1.8.3 (closes: #36371). - Packaged -nft subpackage with nftables compatibility for iptables, arptables and ebtables.
Спасибо!
