Re: NFTables To Replace iptables In the Linux Kernel
On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 signature.asc Description: OpenPGP digital signature
Re: NFTables To Replace iptables In the Linux Kernel
On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Yasha Karant
Re: NFTables To Replace iptables In the Linux Kernel
EL7 is coming, probably, with kernel 3.11 so, the changes in kernel 3.13 and later will (probably) affect EL = 8. --- Henrique C. S. Junior http://about.me/henriquejunior Química Industrial - UFRRJ Prefeitura Muncipal de Paracambi Centro de Processamento de Dados On Monday, October 21, 2013 1:36 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Yasha Karant
Re: NFTables To Replace iptables In the Linux Kernel
On 10/21/2013 10:34 AM, Yasha Karant wrote: On 10/21/2013 01:07 AM, Steven Haigh wrote: On 21/10/2013 4:09 AM, Henrique C. S. Junior wrote: As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? Does it matter? EL6 won't ever have NFTables support. EL7 probably won't either. Don't stress and keep doing what you're doing. Perhaps someone familiar with the choices made by TUV will clarify the above statement: EL7 probably won't either. SL and other TUV re-distributors of EL simply build and re-package the TUV product (removing the logos and non-open copyrighted material, but keeping all of the internal TUV developer statements -- the actual name of TUV, that evidently is taboo on this list, is plastered all over the source code for EL). Thus, the decision as to which family of Linux kernels to use is a TUV decision. Redhat Enterprise Linux! It isn't taboo, just takes longer to type than TUV. Their trademarks must be removed from documentation and distributed materials. Internet discussions really don't matter. However, as fundamental new functionality, or repackaging of existing functionality with a new API, is incorporated into the Linux kernel -- not in an experimental way that may be removed, but in the stable production released version - the high reliability approach requires that the kernel receives extensive field testing (as happens with Fedora) as well as stress testing and internal hardening against threats and compromises that may not be as needed in an enthusiast distribution. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. If one takes the time to read up on NFTables (e.g. the articles previously linked), they would find that there is an iptables compatibility layer under development alongside this new project. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Like was previously said. I wouldn't get flustered or worked up over this. NFTables has been in the works for 4 years and is just making it into forked development tree (not mainline) and will be some time before it trickles into the enterprise. Look at how far ahead KDE, Gnome, and other technologies are from the current SL6 offering for comparison. -Mark -- Mr. Mark V. Stodola Senior Control Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: NFTables To Replace iptables In the Linux Kernel
On Mon, Oct 21, 2013 at 08:34:58AM -0700, Yasha Karant wrote: [...] -- the actual name of TUV, that evidently is taboo on this list, [...] Evidently? It's complete nonsense to NOT use the name of TUV here or at whatever place, as long as you don't say things about SL in relation to TUV and/or their products that are illegal. I thought only the CentOS community was (for no good reason) paranoid. In the time I created and released X/OS Linux, being also rebuild of the Red Hat Enterprise Linux 3/4/5 sources, I did mention Red Hat, RHEL, etc., but only as far as appropriate and allowed of course. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Fedora 20 seems to use the 3.11 kernel, so it won't have a kernel with NFTables. RHEL 7 is already being developed (and in alpha stage as far as I've heard) and will most likely have a kernel = 3.11, so this makes the statement that EL7 probably won't either very trustworthy. There are no statistics about delays etc. needed to just see that RHEL 7 won't use a kernel that supports NFTables. So, there is no artificial delay created by RH to postpone things in RHEL, it's just common sense when someone says this about NFTables in relattion to RHEL 7. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204
Re: NFTables To Replace iptables In the Linux Kernel
Well I've heard this before Nf-Hipac http://www.hipac.org/ was at one time slated to be the next big thing. I'm not holding my breath on this one and if it does replace all of the existing tools expect it to be a few years before you see it in production any where. On Mon, Oct 21, 2013 at 1:47 PM, Jos Vos j...@xos.nl wrote: On Mon, Oct 21, 2013 at 08:34:58AM -0700, Yasha Karant wrote: [...] -- the actual name of TUV, that evidently is taboo on this list, [...] Evidently? It's complete nonsense to NOT use the name of TUV here or at whatever place, as long as you don't say things about SL in relation to TUV and/or their products that are illegal. I thought only the CentOS community was (for no good reason) paranoid. In the time I created and released X/OS Linux, being also rebuild of the Red Hat Enterprise Linux 3/4/5 sources, I did mention Red Hat, RHEL, etc., but only as far as appropriate and allowed of course. Nonetheless, once a major change (e.g., NFTables replacing iptables) is done in the base source, the production enterprise version must reflect the change -- and in less than a decade. Why less than a decade? Unless there is a fully backward compatible set of APIs, new applications and revisions typically use the current not historical APIs. Presumably, there will be NFTables features that application developers will use that have no iptables backport. Thus -- how long is the delay? Typically, are two major releases (e.g., NFTables in EL8) the usual delay? Does anyone have historical data from EL/TUV? Fedora 20 seems to use the 3.11 kernel, so it won't have a kernel with NFTables. RHEL 7 is already being developed (and in alpha stage as far as I've heard) and will most likely have a kernel = 3.11, so this makes the statement that EL7 probably won't either very trustworthy. There are no statistics about delays etc. needed to just see that RHEL 7 won't use a kernel that supports NFTables. So, there is no artificial delay created by RH to postpone things in RHEL, it's just common sense when someone says this about NFTables in relattion to RHEL 7. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204
Re: NFTables To Replace iptables In the Linux Kernel
Precisely my point. Compatibility modes often are incomplete, unfaithful, and unreliable. I am not singing the praises of any new fundamental change in a basic kernel utility/configuration entity that has been integrated into many application and configuration packages/environments/situations . However, if the change is forced upon the community, then developers either must maintain two (or more) fundamentally incompatible versions (e.g., native STL and the rest for an ANSI open systems environment and MFC for a proprietary monopoly environment), or select one and let those lacking the environment to find another solution (e.g., VirtualBox to run native MS Windows as a guest/application to run a monopoly only application or environment under a Linux host). Admittedly, the change coming to the linux kernel (unless the change is abandoned) is not as drastic as having to use the monopoly MFC, but it certainly could prove to be highly inconvenient. My timeline question was less directed towards application end user environments such as KDE or Gnome, but more towards actual fundamental kernel or Xwindows internals and the APIs required to use these fundamentals. Does anyone have an average time interval from history when a major change was declared stable production in the fundamental internals and then actually appeared in RHEL production (as it appears RHEL is no longer taboo)? It is Red Hat that determines this timeline, not the clone distributions such as SL or CentOS. Yasha Karant On 10/21/2013 03:53 PM, Nico Kadel-Garcia wrote: If one takes the time to read up on NFTables (e.g. the articles previously linked), they would find that there is an iptables compatibility layer under development alongside this new project. I hear there's plans at NASA for a manned return to the moon, too. Don't hold your breath. Under development by the core authors of nftables itself does not mean they know the iptables configuration tools well enough to write such a layer to work across the broad variety of RPM based and configuration tool managed oddities. Even the system-config-security tool is seriously awkward and underpowered for any complex iptables configurations. I'll be pleased, and surprised, if their nftables compatibility toolkit tool can manage even the well documented configurations and layout of system-config-security.
NFTables To Replace iptables In the Linux Kernel
As reported in Slashdot[1] in the near future iptables is going to be replaced by NFTables in the linux kernel. The project[2] is said to be a new and best package filtering framework. Have any of you, guys, tried it already and have some experiences to share? [1] - http://linux.slashdot.org/story/13/10/19/2118247/nftables-to-replace-iptables-in-the-linux-kernel [2] -http://netfilter.org/projects/nftables/ --- Henrique C. S. Junior http://about.me/henriquejunior Química Industrial - UFRRJ PrefeituraMuncipaldeParacambi CentrodeProcessamentodeDados
