Hello- Linux 3.13 is out, and with it comes support for nftables (IPTables are still an option, but I'm sure at some point in the future they won't be). Would it be a good idea to start including (keyworded, of course) an ebuild for the current betas of the nftables userland? It is worth noting that nftables has a few dependencies (notably libnftnl and libmnl), and I can submit ebuild requests for those as well if nothing shows up in the next 12 hours. I will also try to cobble a basic ebuild, but for something as important as a firewall utility, I would much rather defer to someone who has experience with the iptables ebuilds or other Linux userland firewall utilities. Thank you very much for your time and attention. -Robin K.
+*libnftnl-1.0.0 (20 Jan 2014) + + 20 Jan 2014; Tony Vroon <chainsaw@gentoo.org> +libnftnl-1.0.0.ebuild, + +metadata.xml: + Initial commit, ebuild by me. Dependency of net-firewall/nftables, as + requested by Robin Kauffman in bug #498724.
(In reply to Tony Vroon from comment #1) > +*libnftnl-1.0.0 (20 Jan 2014) > + > + 20 Jan 2014; Tony Vroon <chainsaw@gentoo.org> +libnftnl-1.0.0.ebuild, > + +metadata.xml: > + Initial commit, ebuild by me. Dependency of net-firewall/nftables, as > + requested by Robin Kauffman in bug #498724. Hi- Thank you very much! No need to credit me or otherwise complect the attribution/credit/blame(:-)) portion of an in-tree ChangeLog unless the ebuild came, in complete, unmodified form, top to bottom, from me. I'll get started on the libmnl and nftables ebuilds now that I've synced from upstream, but even if a subcomponent of those ebuilds is miraculously acceptable enough to commit to gentoo-x86 CVS, I *do not* want credit for it unless it went in wholesale. If that's the criterion, at least I can not only get the occasional fuzzie from having contributed a whole ebuild to my current favorite distro, but can also get info from people who rightly assume that with great attribution comes great blame when things go pear-shaped. Thanks, though :-) Expect an ebuild for libmnl by 0300 UTC (201401210300Z) and hopefully an ebuild for nftables not long after that. -Robin K.
I should probably point out that the needed version of libmnl is already in the tree, so you don't really need a new ebuild for that. I'm working on fixing up the libnftnl ebuild, and should have that done after I've had some sleep. I've already started an nftables ebuild, and should also have that finished later today, if you don't want to waste effort.
(In reply to dwfreed from comment #3) > I've already started an nftables ebuild Great! The current version is now 0.100. And could you please include a systemd unit? Then sys-apps/systemd-units from the systemd overlay could finally be obsoleted.
Hi, from ebuild of dwfreed relative to libntnl I create ebuild for nftables-0.099 with patch (same of trunk before tag 0.100) relative to rename of libntnl. Release 0.100 it isn't available on site and I used so v. 0.099. Ebuild is available on my overlay: https://github.com/geaaru/geaaru_overlay/blob/master/net-firewall/nftables/nftables-0.099.ebuild I hope that this could be permit a more fast integration with portage. Regards, G.
There's also iptables-nftables, a rewrite of iptables that uses the kernel's underlying nftables components: http://git.netfilter.org/iptables-nftables/ A separate ebuild could be made of this, as a drop in replacement for iptables.
Both libnftnl and nftables are done, and live in my overlay, "dwfreed", in the main overlays list. I've compile-tested both to death, but I do not yet have a working 3.13 system to test on, so could somebody please install them from my overlay and give them a shot? I've stable-keyworded the release versions to ease getting them installed for this purpose. Once they've been tested and work, then I'll go through the fun of getting them all attached to this bug so they can be included in the main tree (unless Chainsaw doesn't mind just copying them wholesale out of my overlay, and then touching up KEYWORDS). I should have the iptables-nftables ebuild written tomorrow, as it shouldn't be that difficult. Things that have not yet been done: * OpenRC runscript: I'm not yet familiar with nftables, so I'm not sure how to implement this * Systemd unit: I'm not familiar with systemd at all, nor do I plan to be, plus the above unfamiliarity with nftables, so again, not sure how to implement If somebody would like contribute either of these, I'd be happy to integrate them into my ebuilds.
Hi dwfreed, for both systemd, openrc script could be a valid solution initialize normal chain like for iptables with these commands: nft -f /etc/nftables/ipv4-filter nft -f /etc/nftables/ipv4-nat nft -f /etc/nftables/ipv4-mangle and optionally enable same files for ipv6 support. However, about save rules currently nft is not so powerfull for this task ... a solution could be something like this: save_chain_filter () { echo "#!/sbin/nft -f" > /etc/nftables/ipv4-filter nft list table filter >> /etc/nftables/ipv4-filter } About test ebuild ... I see your ebuild and it is equal to my (only few changes relatives to man) and I confirm that with kernel 3.13.0 it works fine nft. If you prefer I try to create these scripts and upload here a first version. G. Bye
Created attachment 368428 [details] nftables.openrc Here a first version of nftables openrc script. With a conf.d file like this: ------------------------------------------------------ # /etc/conf.d/nftables # Author: geaaru # Nftables script directory. Default /etc/nftables NFTABLES_SCRIPT_DIR="/etc/nftables" # Save state on stopping nftables SAVE_ON_STOP="yes" # Set nftables chain to load. Default is filter nat mangle #NFTABLES_CHAINS="filter nat mangle" --------------------------------------------------------- G.
Created attachment 368464 [details] libnftnl-1.0.0-r2.ebuild
Created attachment 368466 [details] libnftnl-9999.ebuild
Created attachment 368468 [details, diff] libnftnl-1.0.0-91264d8.patch
Created attachment 368470 [details, diff] nftables-0.099-94300c7.patch
Created attachment 368472 [details] libnftnl-1.0.0-r2.ebuild Proposed ebuild; mostly a simplification of that proposed.
+*libnftnl-1.0.0-r2 (22 Jan 2014) + + 22 Jan 2014; Tony Vroon <chainsaw@gentoo.org> -libnftnl-1.0.0-r1.ebuild, + +libnftnl-1.0.0-r2.ebuild, +files/libnftnl-1.0.0-91264d8.patch: + My previous revert was unnecessary. This is an improved ebuild by dwfreed + which brings in an upstream patch and additional functionality.
Created attachment 368476 [details] nftables.8 nftables man page Reasoning for including prebuilt man page: Building the man page would require a dependency on >=app-text/docbook2X-0.8.8-r4, which would need to be stabilized before this could be. As docbook2X is maintainer-needed, that may be difficult. The man page for release versions shouldn't change frequently anyway, so we can just include it. In the event that the upstream man page changes, we can just start versioning the file in FILESDIR, and pluck out the right one for installation.
Created attachment 368478 [details] nftables-9999.ebuild
Created attachment 368480 [details] nftables-0.099.ebuild
+*nftables-0.099 (24 Jan 2014) + + 24 Jan 2014; Tony Vroon <chainsaw@gentoo.org> +nftables-0.099.ebuild, + +files/nftables-0.099-94300c7.patch, +files/nftables.8, +metadata.xml: + Initial commit. Patches & ebuilds by dwfreed, with some minor tweaks by me.
How about the suggested iptables-nftables ebuild in comment #6? Should there be a separate bug?
