Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 555920 - net-firewall/iptables: iptables.service systemd unit fails to start - iptables.service lacks both ExecStart= and ExecStop= setting. Refusing.
Summary: net-firewall/iptables: iptables.service systemd unit fails to start - iptable...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2015-07-26 06:16 UTC by Rick Harris
Modified: 2020-09-23 14:22 UTC (History)
13 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info,5.07 KB, text/plain)
2015-08-09 21:15 UTC, sebB
Details
systemctl status $(failing unit files) (systemctl,5.93 KB, application/octet-stream)
2015-08-09 21:16 UTC, sebB
Details
Proposed iptables-store.service (iptables-store.service,270 bytes, text/plain)
2016-08-17 12:59 UTC, Magnus Kessler
Details
Proposed iptables-restore.service (iptables-restore.service,419 bytes, text/plain)
2016-08-17 13:00 UTC, Magnus Kessler
Details
Proposed ip6tables-store.service (ip6tables-store.service,274 bytes, text/plain)
2016-08-17 13:00 UTC, Magnus Kessler
Details
Proposed ip6tables-restore.service (ip6tables-restore.service,424 bytes, text/plain)
2016-08-17 13:01 UTC, Magnus Kessler
Details
iptables systemd unit (iptables.service-systemd.tar,20.00 KB, application/x-tar)
2016-08-17 13:42 UTC, Evert
Details
iptables systemd service unit (iptables.service-systemd.tar,20.00 KB, application/x-tar)
2017-03-18 16:36 UTC, Evert
Details
iptables systemd service unit (iptables.service-systemd.tar,20.00 KB, application/x-tar)
2018-01-27 12:17 UTC, Evert
Details
iptables.service (file_555920.txt,631 bytes, text/plain)
2018-02-09 15:47 UTC, Anna Tikhomirova
Details
ip6tables.service (file_555920.txt,670 bytes, text/plain)
2018-02-09 15:48 UTC, Anna Tikhomirova
Details
iptables.service.conf (file_555920.txt,222 bytes, text/plain)
2018-02-09 15:48 UTC, Anna Tikhomirova
Details
ip6tables.service.conf (file_555920.txt,224 bytes, text/plain)
2018-02-09 15:49 UTC, Anna Tikhomirova
Details
iptables-1.6.1-r2.ebuild.diff (file_555920.txt,863 bytes, patch)
2018-02-09 15:51 UTC, Anna Tikhomirova
Details | Diff
ip6tables-r2.service (ip6tables-r2.service,913 bytes, text/plain)
2020-09-17 14:53 UTC, Anna Tikhomirova
Details
ip6tables-r1.service.conf (ip6tables-r1.service.conf,449 bytes, text/plain)
2020-09-17 14:54 UTC, Anna Tikhomirova
Details
iptables-r2.service (iptables-r2.service,874 bytes, text/plain)
2020-09-17 14:54 UTC, Anna Tikhomirova
Details
iptables-r1.service.conf (iptables-r1.service.conf,445 bytes, text/plain)
2020-09-17 14:54 UTC, Anna Tikhomirova
Details
iptables-1.8.4-r2.ebuild.patch (iptables-1.8.4-r2.ebuild.patch,773 bytes, patch)
2020-09-17 14:55 UTC, Anna Tikhomirova
Details | Diff
iptables-1.8.5.ebuild.patch (iptables-1.8.5.ebuild.patch,1.12 KB, patch)
2020-09-17 14:55 UTC, Anna Tikhomirova
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Harris 2015-07-26 06:16:09 UTC
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
Comment 1 Alexander Tsoy 2015-07-26 08:51:08 UTC
Alternative is to convert it to .target.
Comment 2 Pacho Ramos gentoo-dev 2015-08-04 16:53:07 UTC
Please provide "emerge --info" and also look at running "systemctl status $(failing unit files)" to try to know what is really occurring with them
Comment 3 Evert 2015-08-04 18:52:30 UTC
You might want to check out https://bugs.gentoo.org/attachment.cgi?id=403348 from bug #479490. It contains a real systemd iptables.service
Comment 4 Evert 2015-08-04 19:04:33 UTC
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.
Comment 5 sebB 2015-08-09 21:13:25 UTC
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.
Comment 6 sebB 2015-08-09 21:15:19 UTC
Created attachment 408686 [details]
emerge --info
Comment 7 sebB 2015-08-09 21:16:58 UTC
Created attachment 408688 [details]
systemctl status $(failing unit files)
Comment 8 Alex Xu (Hello71) 2015-08-13 00:00:53 UTC
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.
Comment 9 Mike Gilbert gentoo-dev 2015-08-13 03:15:02 UTC
(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?
Comment 10 Matthias Maier gentoo-dev 2015-08-13 05:40:02 UTC
(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...
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-08-13 06:29:12 UTC
Yeah, I guess /bin/true would work. Not sure if we can deliver any useful message somehow. Maybe /bin/echo :).
Comment 12 Richard Freeman gentoo-dev 2015-08-13 10:51:34 UTC
(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.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-08-13 10:55:24 UTC
(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.
Comment 14 Magnus Kessler 2016-08-17 12:58:04 UTC
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.
Comment 15 Magnus Kessler 2016-08-17 12:59:30 UTC
Created attachment 443592 [details]
Proposed iptables-store.service
Comment 16 Magnus Kessler 2016-08-17 13:00:09 UTC
Created attachment 443594 [details]
Proposed iptables-restore.service
Comment 17 Magnus Kessler 2016-08-17 13:00:49 UTC
Created attachment 443596 [details]
Proposed ip6tables-store.service
Comment 18 Magnus Kessler 2016-08-17 13:01:18 UTC
Created attachment 443598 [details]
Proposed ip6tables-restore.service
Comment 19 Evert 2016-08-17 13:42:34 UTC
Created attachment 443600 [details]
iptables systemd unit

What about a real iptables service which includes start/stop/save and dynamically supports ip6tables & ipset too
Comment 20 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-08-17 13:52:42 UTC
(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?
Comment 21 Mike Gilbert gentoo-dev 2016-08-17 14:46:10 UTC
I'll try to actually take a look at this soon. The current situation is certainly not optimal.
Comment 22 Mike Gilbert gentoo-dev 2016-08-19 01:51:14 UTC
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(-)
Comment 23 Evert 2017-03-18 16:36:58 UTC
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!
Comment 24 Richard Freeman gentoo-dev 2017-03-18 16:57:59 UTC
(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.
Comment 25 Mike Gilbert gentoo-dev 2017-03-22 03:16:28 UTC
It would be nice to get some feedback from the maintainer(s) here. Does anyone on base-system actually use iptables and systemd?
Comment 26 SpanKY gentoo-dev 2017-03-22 17:54:02 UTC
(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 ;).
Comment 27 Mike Gilbert gentoo-dev 2017-03-22 18:04:31 UTC
(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.
Comment 28 nE0sIghT 2018-01-05 22:20:42 UTC
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.
Comment 29 Anna Tikhomirova 2018-01-26 07:33:42 UTC
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.
Comment 30 Evert 2018-01-27 12:17:37 UTC
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.
Comment 31 Anna Tikhomirova 2018-01-27 13:16:56 UTC
(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?
Comment 32 Thomas Deutschmann gentoo-dev Security 2018-01-27 13:51:30 UTC
(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...
Comment 33 Thomas Deutschmann gentoo-dev Security 2018-01-27 14:01:13 UTC
(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.
Comment 34 Richard Freeman gentoo-dev 2018-01-27 14:24:36 UTC
(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.
Comment 35 Anna Tikhomirova 2018-02-09 15:46:32 UTC
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
Comment 36 Anna Tikhomirova 2018-02-09 15:47:39 UTC
Created attachment 518736 [details]
iptables.service
Comment 37 Anna Tikhomirova 2018-02-09 15:48:25 UTC
Created attachment 518738 [details]
ip6tables.service
Comment 38 Anna Tikhomirova 2018-02-09 15:48:53 UTC
Created attachment 518740 [details]
iptables.service.conf
Comment 39 Anna Tikhomirova 2018-02-09 15:49:23 UTC
Created attachment 518742 [details]
ip6tables.service.conf
Comment 40 Anna Tikhomirova 2018-02-09 15:51:18 UTC
Created attachment 518744 [details, diff]
iptables-1.6.1-r2.ebuild.diff
Comment 41 Anna Tikhomirova 2020-09-17 14:52:55 UTC
Here are the latest systemd unit files for iptables 1.8 from my personal overlay.
Comment 42 Anna Tikhomirova 2020-09-17 14:53:46 UTC
Created attachment 661008 [details]
ip6tables-r2.service
Comment 43 Anna Tikhomirova 2020-09-17 14:54:08 UTC
Created attachment 661011 [details]
ip6tables-r1.service.conf
Comment 44 Anna Tikhomirova 2020-09-17 14:54:29 UTC
Created attachment 661014 [details]
iptables-r2.service
Comment 45 Anna Tikhomirova 2020-09-17 14:54:54 UTC
Created attachment 661017 [details]
iptables-r1.service.conf
Comment 46 Anna Tikhomirova 2020-09-17 14:55:39 UTC
Created attachment 661020 [details, diff]
iptables-1.8.4-r2.ebuild.patch
Comment 47 Anna Tikhomirova 2020-09-17 14:55:55 UTC
Created attachment 661023 [details, diff]
iptables-1.8.5.ebuild.patch
Comment 48 Mike Gilbert gentoo-dev 2020-09-23 14:22:32 UTC
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