Unsure if there's a better alternative, but inserting the following into the iptables.service file fixes this for me: [Service] ExecStart=/bin/true ExecStop=/bin/true
Alternative is to convert it to .target.
Please provide "emerge --info" and also look at running "systemctl status $(failing unit files)" to try to know what is really occurring with them
You might want to check out https://bugs.gentoo.org/attachment.cgi?id=403348 from bug #479490. It contains a real systemd iptables.service
Oh and for installation, make sure you read https://bugs.gentoo.org/show_bug.cgi?id=479490#c88 And... I'm even willing to support that one so if you try it, let me know if/how it works for you.
Same problem for me # systemctl start iptables Failed to start iptables.service: Unit iptables.service failed to load: Invalid argument. See system logs and 'systemctl status iptables.service' for details. # systemctl status iptables.service iptables.service - Store and restore iptables firewall rules Loaded: error (Reason: Invalid argument) Active: inactive (dead) août 09 23:09:25 seb-pc systemd[1]: iptables.service lacks both ExecStart= and ExecStop= setting. Refusing. août 09 23:09:44 seb-pc systemd[1]: iptables.service lacks both ExecStart= and ExecStop= setting. Refusing.
Created attachment 408686 [details] emerge --info
Created attachment 408688 [details] systemctl status $(failing unit files)
the intended use is to use "systemctl enable iptables", which will enable both. the error message is a side effect and does not affect operation. if you want to run it manually, you must specify whether you want iptables*-store* or iptables*-restore*. I believe that making it a .target would not work as intended.
(In reply to Rick Harris from comment #0) > Unsure if there's a better alternative, but inserting the following into the > iptables.service file fixes this for me: > > [Service] > ExecStart=/bin/true > ExecStop=/bin/true Yeah, that seems like the most straightforward solution here, short of eliminating iptables.service entirely. Tweaked slightly: [Service] Type=oneshot ExecStart=/bin/false This will cause a nice error to appear if someone runs systemctl start iptables.service. mgorny: Your thoughts?
(In reply to Mike Gilbert from comment #9) > Tweaked slightly: > > [Service] > Type=oneshot > ExecStart=/bin/false This is worse. Please don't do that. With ExecStart=/bin/false systemd tries to start the unit, it fails and after that the system state is "degraded": # systemctl status [...] State: degraded [...] and the unit shows up in # systemctl iptables.service loaded failed failed Store and restore iptables firewall rules (In reply to Rick Harris from comment #0) > [Service] > ExecStart=/bin/true > ExecStop=/bin/true This is equally bad because it promotes iptables.service to look like a fully functional service (showing up a started, and listed in systemctl output)- but this is not the case. The current behavior of iptables.service is to be just a short cut for # systemctl enable iptables.service The only "error message" it produces is a notification in the journal that it is not considered a functional service file. And as such it does not show up in systemctl output. Further, any action like # systemctl start iptables results in an error. A target is also not an option because this would still require to enable both iptables-* services...
Yeah, I guess /bin/true would work. Not sure if we can deliver any useful message somehow. Maybe /bin/echo :).
(In reply to Matthias Maier from comment #10) > > A target is also not an option because this would still require to enable > both iptables-* services... Would it make sense to instead just have one service that both restores and stores state (restoring on start, storing on exit)? Then you just enable that and you're done. You would just set RemainAfterExit=yes so that systemd still tracks the state of whether the iptables rules are loaded or not.
(In reply to Richard Freeman from comment #12) > (In reply to Matthias Maier from comment #10) > > > > A target is also not an option because this would still require to enable > > both iptables-* services... > > Would it make sense to instead just have one service that both restores and > stores state (restoring on start, storing on exit)? Then you just enable > that and you're done. > > You would just set RemainAfterExit=yes so that systemd still tracks the > state of whether the iptables rules are loaded or not. No, that's typical OpenRC non-sense. Starting a service isn't equivalent to restoring rules, and stopping isn't equivalent to storing them. Explicit is better than magical.
Since the only reason for ip{,6}tables.service seems to be that both the *-store and *-restore services are enabled/disabled together, I suggest adding the respective services into the [Install] section of the store and restore services. E.g. for iptables-store.service: [Install] WantedBy=shutdown.target Also=iptables-restore.service and for iptables-restore.service: [Install] WantedBy=basic.target Also=iptables-store.service Enabling/disabling any one of the store or restore services automatically affects the other one, too.
Created attachment 443592 [details] Proposed iptables-store.service
Created attachment 443594 [details] Proposed iptables-restore.service
Created attachment 443596 [details] Proposed ip6tables-store.service
Created attachment 443598 [details] Proposed ip6tables-restore.service
Created attachment 443600 [details] iptables systemd unit What about a real iptables service which includes start/stop/save and dynamically supports ip6tables & ipset too
(In reply to Evert from comment #19) > Created attachment 443600 [details] > iptables systemd unit > > What about a real iptables service which includes start/stop/save and > dynamically supports ip6tables & ipset too What about you install OpenRC and stop trying to turn systemd into a non-sense like it?
I'll try to actually take a look at this soon. The current situation is certainly not optimal.
commit 746c559118d7b3c95a1f78d4d7730d9ba4c8e4f6 Author: Mike Gilbert <floppym@gentoo.org> Date: Thu Aug 18 21:49:49 2016 -0400 net-firewall/iptables: drop iptables.service This unit really serves no real purpose. The utility of being able to call "systemctl enable iptables" is questionable at best. Given that iptables is not really a daemon but rather a kernel process, having as single unit that persists with RemainAfterExit seems wrong as well. Bug: https://bugs.gentoo.org/555920 Package-Manager: portage-2.3.0_p16 .../iptables/{iptables-1.6.0.ebuild => iptables-1.6.0-r1.ebuild} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Created attachment 467454 [details] iptables systemd service unit Since this bug is idle for a long time and I only see people adding themselves to the cc, let's release another update: Systemd is all about doing things in a standardized way. System Administators want/expect to be able to start, stop, restart or even reload services in a standardized way. In RHEL-6 etc, the standardized way to handle services is to use the service command. Since systemd, the standardized way to handle services is using the systemctl command. Lennart Poettering (I've met him twice) is one of the main developers of systemd and currently works for Red Hat. For iptables, Red Hat provides the firewalld service, but for those who don't want/like/need firewald, Red Hat provides the iptables-services and ipset-service packages which include the iptables.service, ip6tables.service and ipset.service systemd service units. Currently, Gentoo Linux is the only distro which hasn't adopted systemd as the default init system. However, that doesn't mean Gentoo should not provide decent service units since other distros do. This bug is all about the System Administator and doing thing in a standardized & reliable way. System Administator want/expect to be able to - systemctl start iptables - systemctl status iptables - systemctl enable iptables - systemctl restart iptables - systemctl reload iptables - systemctl stop iptables - systemctl disable iptables without having to think about scripts like for ipv in ip ip6; do for table in $(cat /proc/net/${ipv}_tables_names); do ${ipv}tables -t $table -F ${ipv}tables -t $table -X done done ipset destroy only to stop the iptables firewall which implies the risc of losing the current state too since systemd will not be aware of that. This iptables systemd implementation is all about System Administrator friendliness and doing things in a standardized way. - it can be started - it can be stopped (no additional script/knowledge needed to stop) - it can be restarted - it can be reloaded - it can be enabled - it can be disabled - it can save the current iptables/ip6tables/ipset states at once (manually & at shutdown) - only one systemctl command / systemd unit is required to start/stop/restart/reload the iptables/ip6tables/ipset states including its dependencies at once - systemd remembers its current (started/stopped) state - it prevents system administrators from saving a "stopped" state - it dynamically supports iptables, ip6tables & ipset depending on kernel support & installed binaries - service units, config & helper file are well documented - both units use the same config file - save @ shutdown (iptables-save) will implicitely be enabled when enabling iptables - it supports hardened servers & development servers as well: - iptables-save can save the current state to alternate files (for inspection purposes) - save @ shutdown (iptables-save) can be disabled - supports the paranoia during reload (of ipset definitions) - supports OpenRC to Systemd migration - great information when using systemctl -l status <iptables|iptables-save> Some people however don't seem to be charmed by this implementation since iptables, ip6tables and ipset are techically not services but kernel states. However in a system administrator point of view, any firewall implementation (daemon or kernel state) functionally *is* a service. On top of that, sooner of later, many system administrators would like to have the opportunity to use a standardized way to quickly, easily & reliably stop/start/save/reload the iptables/ip6tables/ipset states using a single systemctl command, without any risc, hassle or advanced knowlegde. This implementation makes all that possible. Installation: Download the attached iptables systemd service unit tar xvf iptables.service-systemd.tar -C / systemctl daemon-reload Disable the default implementation: systemctl disable iptables-restore systemctl disable iptables-store Usage: systemctl start iptables # start the new implementation systemctl -l status iptables # look at it, it shows what it did If you were previously using OpenRC or the current systemd implementation, it has been migrated by now. Otherwise, configure your firewall now using iptables, ip6tables, ipset or whatever tool you like to use. After that, check your firewall: iptables -nvL # etc ... If all is fine, enable the service: systemctl enable iptables System Administrators who run a hardenened or development server might want to: vi /etc/systemd/system/iptables.service.d/10iptables.conf and e.g. edit the SAVE_PREFIX. At shutdown, the firewall will be saved to disk. However, if you don't want to wait for shutdown, you can save it right now: systemctl start iptables-save systemctl -l status iptables-save Try it and check: ls -ltr /var/lib/iptables/ If (for whatever reason) you don't want to save your firewall at shutdown, you can disable auto-save using: systemctl disable iptables-save You can mess up ip(6)tables or ipset and (as long as you can access your tty) still revert to the last saved state too using: systemctl reload iptables Last but not least, systemd remembers the service state and prevents you from saving a stopped state systemctl stop iptables # implies auto-save systemctl start iptables-save # fails/prevents from saving a stopped state systemctl start iptables # start again ... systemctl -l status iptables # check service state systemctl start iptables-save # should be fine now systemctl -l status iptables-save # :) Note 1: This is something like Red Hat and other distros provide, but in a far more comfortable way. Note 2: People on the cc list, if you use & like this implementation, please share your experience here! (if you don't show your positive experience, this bug will not be solved within the next 3 years) Note 3: Any issues or comments, please contact me by email since currently I personally support this implementation and like to improve it where possible. Thank you!
(In reply to Michał Górny from comment #13) > (In reply to Richard Freeman from comment #12) > > (In reply to Matthias Maier from comment #10) > > > > > > A target is also not an option because this would still require to enable > > > both iptables-* services... > > > > Would it make sense to instead just have one service that both restores and > > stores state (restoring on start, storing on exit)? Then you just enable > > that and you're done. > > > > You would just set RemainAfterExit=yes so that systemd still tracks the > > state of whether the iptables rules are loaded or not. > > No, that's typical OpenRC non-sense. Starting a service isn't equivalent to > restoring rules, and stopping isn't equivalent to storing them. Explicit is > better than magical. Well, why would you say that RemainAfterExit even exists if not to do stuff like this? I suspect most distros handle iptables rules in a manner like this.
It would be nice to get some feedback from the maintainer(s) here. Does anyone on base-system actually use iptables and systemd?
(In reply to Mike Gilbert from comment #25) at this point, i'm happy to have you make changes to the systemd unit files as you see fit if they're in harmony with what the openrc init files are doing and how systemd normally handles such firewall settings (if such a common behavior exists). yes, that's vague, but i trust your judgement ;).
(In reply to SpanKY from comment #26) systemd doesn't really have a "standard" behavior for this. ;) Evert's proposed change looks reasonable, if a little over-engineered.
I completely agree with Evert's proposal. Current iptables/systemd Gentoo state is broken. iptables-store.service should not be executed if iptables-restore.service is not started for any reason - so first should check state of late. Multiple times Gentoo's iptables/systemd erased my iptables configuration.
I agree too. I've recently migrated to systemd and I found that the current Gentoo iptables service implementation is not good, and ipset service is missing at all. I'm using another systemd-based distro (Arch), so at first I tried to copy their implementation. But it is very simple and dumb - iptables-restore at start and flush at shutdown (by doing iptables-restore < empty.rules). No auto-save. I've found this bug report and tried the Evert's implementation. But it has some issues too: 1) Startup fails if the kernel IP tables support is compiled as a module (default genkernel config): Jan 25 18:45:17 localhost iptables-helper[3303]: iptables - kernel support: no, binaries: installed Jan 25 18:45:17 localhost systemd[1]: iptables.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED Jan 25 18:45:17 localhost systemd[1]: iptables.service: Failed with result 'exit-code'. Jan 25 18:45:17 localhost systemd[1]: Failed to start iptables firewall. Startup check needs to be either removed or modified. 2) One service for 2 packages: iptables & ipset. Is it acceptable? 3) Auto-save on shutdown is implemented as a separate iptables-save.service. This does not integrate well with a software that relies on iptables (for example, fail2ban). iptables-save + fail2ban = broken save. I think we should drop iptables-save in favor of a single service.
Created attachment 516892 [details] iptables systemd service unit 1) This should fix the kernel support issue you're experiencing (modprobe added) 2) IMHO, ipset is an extension for any *tables which makes it (an optional) part of ... Especially with the eye on security (not letting any packet go through during reload) I think it's more than acceptable to integrate it into the iptables service. Of course you're free to disagree with me on this one ;-) 3) If you send me an email with your fail2ban config including detailed instructions how to reproduce your "iptables-save + fail2ban = broken save" issue, I will take a look into that one too.
(In reply to Evert from comment #30) > I think it's more than acceptable to integrate it > into the iptables service. Of course you're free to disagree with me on this > one ;-) It was a question to Gentoo developers. It's ok for me. But is it acceptable for inclusion into the official Portage tree?
(In reply to Andrey Tikhomirov from comment #29) > 2) One service for 2 packages: iptables & ipset. Is it acceptable? > > 3) Auto-save on shutdown is implemented as a separate iptables-save.service. > This does not integrate well with a software that relies on iptables (for > example, fail2ban). iptables-save + fail2ban = broken save. I think we > should drop iptables-save in favor of a single service. iptables and ipset are separate packages. Their services shouldn't depend on each other in a "helper" script nor should they interact (ipsets aren't just used by iptables... so you don't want iptables to flush all ipsets). Just make sure ipset service starts before iptables services and that it will be stopped after iptables services. So short answer: No, not acceptable. That the whole idea is based on a helper script is also ridiculous. Especially for systemd. We also don't do "modprobe", we will use modules-load service these days. I understand that this isn't very user-friendly. That it will require additional steps (because we will not install /usr/lib/modules-load.d/iptables per default and so on). But ipset/iptables packages are raw packages. If you need a firewall, create your own one or use net-firewall/shorewall... we have multiple solutions in the repository. But we won't convert iptables package into a fully fledged firewall for systemd using helpers...
(In reply to Thomas Deutschmann from comment #32) > But we won't convert iptables package into a fully fledged firewall for > systemd using helpers... To clarify this: We will not just convert _for_ systemd. If we would decide to convert iptables into a fully fledged firewall with a bunch of logic which doesn't belong into this package if you ask me, we would have to ensure that OpenRC, systemd or any other init system we will support at this time would behave the same (=i.e. uses the same helpers/logic). It isn't an option to provide a fully fledged firewall just for init system X.
(In reply to Thomas Deutschmann from comment #33) > > It isn't an option to provide a fully fledged firewall just for init system > X. IMO something like this really should go into a separate package - just like shorewall or other tools that use iptables. Put it on a github page or whatever and proxy-maintain it (if you can find a dev willing to commit it - I might be willing). It could support whatever init systems it wants to, and install units/init.ds/etc with the upstream build system.
Well, I've made a new simple systemd service, without any helpers. - one service file (no store/restore) for unification with other distros - restore on start or reload, save (can be disabled) and flush on stop
Created attachment 518736 [details] iptables.service
Created attachment 518738 [details] ip6tables.service
Created attachment 518740 [details] iptables.service.conf
Created attachment 518742 [details] ip6tables.service.conf
Created attachment 518744 [details, diff] iptables-1.6.1-r2.ebuild.diff
Here are the latest systemd unit files for iptables 1.8 from my personal overlay.
Created attachment 661008 [details] ip6tables-r2.service
Created attachment 661011 [details] ip6tables-r1.service.conf
Created attachment 661014 [details] iptables-r2.service
Created attachment 661017 [details] iptables-r1.service.conf
Created attachment 661020 [details, diff] iptables-1.8.4-r2.ebuild.patch
Created attachment 661023 [details, diff] iptables-1.8.5.ebuild.patch
commit 746c559118d7b3c95a1f78d4d7730d9ba4c8e4f6 Author: Mike Gilbert <floppym@gentoo.org> Date: Thu Aug 18 21:49:49 2016 -0400 net-firewall/iptables: drop iptables.service This unit really serves no real purpose. The utility of being able to call "systemctl enable iptables" is questionable at best. Given that iptables is not really a daemon but rather a kernel process, having as single unit that persists with RemainAfterExit seems wrong as well. Bug: https://bugs.gentoo.org/555920 Package-Manager: portage-2.3.0_p16
