net-firewall/iptables should provide systemd unit file. Reproducible: Always
If you are able to prepare one, that will make things go faster for sure
*** Bug 479496 has been marked as a duplicate of this bug. ***
I am using this one for ip6tables. Similar for iptables. [Unit] Description=ip6tables Before=network.target [Service] Type=oneshot RemainAfterExit=yes EnvironmentFile=/etc/conf.d/ip6tables ExecStart=/sbin/ip6tables-restore ${SAVE_RESTORE_OPTIONS} ${IP6TABLES_SAVE} [Install] WantedBy=multi-user.target Got it from a no longer available gentoo systemd wiki
I would drop the EnvironmentFile, and inline the default options. We could also add a ContitionPathExists item for the rules file.
Created attachment 354982 [details] iptables.service
Created attachment 354984 [details] ip6tables.service
Units in Archlinux also have ExecReload and ExecStop commands. The latter use helper script. https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/iptables
Wouldn't it be better to go more like our scripts and save the rules on stop?
Created attachment 355276 [details] iptables-save.service
Created attachment 355278 [details] ip6tables-save.service
IMHO, saving iptables rules should be optional. That's why I created dedicated service for that purpose. Some notes: - Requisite=iptables.service If iptables.service fails to start (e.g. netfilter modules couldn't be loaded), then iptables-save.service also will not start. This is to avoid overwriting existing "rules-save" file with an empty ruleset. - ExecStop=/bin/sh -c "" I/O redirection is not allowed in Exec* options. That's why "/bin/sh -c" is here.
If you dislike this solution, we may go the same way as fedora: ExecStart=/usr/libexec/iptables/iptables.init start ExecStop=/usr/libexec/iptables/iptables.init stop where iptables.init is a script, that load options from config file. This makes saving rules and some other things configurable.
ConditionPathIsDirectory is not needed in ip6?tables-save.service. This path is checked only when the service starts.
(In reply to Alexander Tsoy from comment #12) > If you dislike this solution, we may go the same way as fedora: > ExecStart=/usr/libexec/iptables/iptables.init start > ExecStop=/usr/libexec/iptables/iptables.init stop > where iptables.init is a script, that load options from config file. This > makes saving rules and some other things configurable. I have the same problem with other services I'd like to provide systemd support for. But what I don't like about this approach is, that we will write duplicated code: We need and have the logic already for OpenRC. Now, systemd needs the same logic (and any other service-manager which may come one time thanks to virtual/service-manager). Does systemd supports e{info,warn,error,begin,end} like every OpenRC runscript do? If yes, it should be possible to outsource the logic into a directory like /usr/libexec/${PN}/${PN}.init which will be consumed by /etc/init.d/${PN} and systemd's service file. Of course it is possible to strip the e{info,warn,error,begin,end} and other OpenRC specific stuff from the logic, but this would remove the beauty of some OpenRC init scripts (I am thinking of the ebegin/eend constructions) and I would vote for duplicated code (but I am not sure if every package maintainer wants to maintain multiple scripts for the same purpose..). BTW: Howsoever this bug will be solved, the same solution should also be applied to net-firewall/ipset.
(In reply to Alexander Tsoy from comment #12) > If you dislike this solution, we may go the same way as fedora: > ExecStart=/usr/libexec/iptables/iptables.init start > ExecStop=/usr/libexec/iptables/iptables.init stop > where iptables.init is a script, that load options from config file. This > makes saving rules and some other things configurable. I will review, test and commit latest attached service files at beginning of September if nobody disagrees, but I would like to see other systemd team members opinions regarding *this* case for Exec* usage. Thanks
Irrespective of whether iptables.service will save the rules or not when stopped, shouldn't it at least flush all tables? In other words, I would expect that "systemctl stop iptables" would disable the firewall, just like the openrc init script does.
(In reply to redneb from comment #16) Then we really need a helper script. But where it should be placed? Arch uses "/usr/lib/systemd/scripts/" for that purpose.
Why not simply /usr/libexec?
(In reply to Alexander Tsoy from comment #17) > Then we really need a helper script. In that case, maybe /etc/conf.d/iptables should be used as an EnvironmentFile and the helper script could use the variables from there to determine where to restore the rules from on start (IPTABLES_SAVE) and whether to save the rules on stop (SAVE_ON_STOP). It's a shame that /etc/init.d/iptables cannot be reused somehow. It seems that the helper script will have to replicate a lot of functionality from it.
(In reply to redneb from comment #19) [...] > It's a shame that /etc/init.d/iptables cannot be reused somehow. It seems > that the helper script will have to replicate a lot of functionality from it. I guess you can put whatever you need from conf.d file in the /etc/systemd one :)
Latest ntp ebuild shows how to deal with conf files and unit files ;)
(In reply to Pacho Ramos from comment #21) > Latest ntp ebuild shows how to deal with conf files and unit files ;) Knowing how to deal with conf and unit files is one part. But the important part regarding net-firewall/iptables and other packages, which is still unclear or I have missed the solution, is how to deal with things which require wrapper scripts. See http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-firewall/iptables/files/iptables-1.4.13.init?view=markup This will require a wrapper script or do you know another solution? If it will require a wrapper solution, what could be done to to prevent duplicated code? E.g. it would be nice to call the wrapper script from systemd *and* from init.d... (like Fedora, see c12). But I don't want to remove the e*-function calls for example (see c14), so I guess this isn't possible at the moment, because these functions aren't yet available in a separate packages (was it bug 373219?). Or don't we want to prevent duplicated code, like we now have to maintain two config files... (but this would be a problem, because not every maintainer is using systemd, so how should we test systemd support? I don't like to add things to packages I did not test, so I would stop adding systemd support and only provide systemd support if contributed *and* tested by a systemd user).
For wrappers we provide a helper not relying in init.d file (in general, we want to separate conf.d/init.d from systemd stuff as they tend to break from time to time). For example, VirtualGL is installing a helper :|
Exherbo unit files look pretty simple, maybe we should give them a try: http://git.exherbo.org/arbor.git/tree/packages/net-firewall/iptables/files/systemd/iptables.service
(In reply to Pacho Ramos from comment #24) > Exherbo unit files look pretty simple, maybe we should give them a try: > http://git.exherbo.org/arbor.git/tree/packages/net-firewall/iptables/files/ > systemd/iptables.service I will go for this if it's not a problem
(In reply to Pacho Ramos from comment #25) > (In reply to Pacho Ramos from comment #24) > > Exherbo unit files look pretty simple, maybe we should give them a try: > > http://git.exherbo.org/arbor.git/tree/packages/net-firewall/iptables/files/ > > systemd/iptables.service > > I will go for this if it's not a problem It's broken. Symbol '>' is passed as an argument to iptables-save: ... iptables-save[20366]: Unknown arguments found on commandline So stop command should be changed as follows: ExecStop=/bin/sh -c "/sbin/iptables-save -c > /var/lib/iptables/rules-save" ExecStop=/bin/sh -c "/sbin/ip6tables-save -c > /var/lib/ip6tables/rules-save" And would be nice to have separate units for iptables and ip6tables.
Also would be nice to have service.d file with an example of how to disable saving rules (IIRC "ExecStop=" should do the trick).
(In reply to Alexander Tsoy from comment #26) > And would be nice to have separate units for iptables and ip6tables. If net-firewall/iptables is compiled with USE=-ipv6, then ip6tables* utilities are not installed.
OK, will try to look at that at weekend, if you have time to work on, please attach your work, would be highly appreciated :)
Also, as I said above, "systemctl stop iptables" should flush all tables.
*** Bug 491754 has been marked as a duplicate of this bug. ***
Created attachment 366492 [details] iptables.service What about this one?
Created attachment 366494 [details] /var/lib/iptables/iptables-stop /var/lib/iptables/iptables-stop
Created attachment 366496 [details] /var/lib/iptables/ip6tables-stop /var/lib/iptables/ip6tables-stop
Have you think in using tmpfiles.d to create /var/lib/iptables/iptables*start files instead of using touch? http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
That is an option. At least this also starts the service successfully when no config is available yet. A better alternative for the touch might be to let the ebuild make sure the iptables-start files exist. And optionally, the ip*tables-stop files can easily be modified to a custom desired stop state, I was in the moment ;)
(In reply to Evert from comment #33) > Created attachment 366494 [details] > /var/lib/iptables/iptables-stop > > /var/lib/iptables/iptables-stop One problem with this approach is that the iptables-stop file contains a hardcoded list of tables to be reset (mangle, nat and filter in this case). But the actual tables present in a system depends on the kernel configuration. This is why the init script reads the list of tables from /proc/net/ip_tables_names. I don't think you can solve that problem without a script. A script will also make it possible to implement the quite useful SAVE_ON_STOP feature that the init script offers.
Comment on attachment 366494 [details] /var/lib/iptables/iptables-stop packages may not install anything into /var/lib/
I'd say trying to add a service file to iptables is quite pointless. We'd rather start by creating a new front-end that does all the necessary magic, and add the services there.
(In reply to SpanKY from comment #38) > Comment on attachment 366494 [details] > /var/lib/iptables/iptables-stop > > packages may not install anything into /var/lib/ Is that right? # qlist net-dns/bind-9.9.3_p2 |grep ^/var/ /var/bind/named.cache /var/bind/sec/.keep_net-dns_bind-0 /var/bind/dyn/.keep_net-dns_bind-0 /var/bind/pri/localhost.zone /var/bind/pri/.keep_net-dns_bind-0 /var/bind/pri/127.zone /var/bind/root.cache
(In reply to Evert from comment #40) those packages should be fixed at some point. for now, i'm not allowing any new violations to leak into base-system packages.
(In reply to SpanKY from comment #41) > (In reply to Evert from comment #40) > > those packages should be fixed at some point. for now, i'm not allowing any > new violations to leak into base-system packages. As a side note, have you think in mailing gentoo-dev (CCing QA) to let all people know that policy and prevent inconsistent ebuilds from landing in the future? Thanks
Created attachment 366536 [details] iptables.service OK, got a new one - no files in /var/ needed - save and flush at stop - no hardcoded tables - no need to know the defined chains per table By the way, the current /etc/init.d/iptables script misses the INPUT chain for the nat table ;)
Created attachment 366556 [details] /usr/lib/tmpfiles.d/iptables.conf This one also fulfilles the tmpfiled.d request ...
Created attachment 366558 [details] iptables.service ... which obsoletes ConditionPathIsDirectory and the touch statements
(In reply to Pacho Ramos from comment #42) portage has a QA check committed already and will be in the next release
Here's my attempt. It uses a helper script to properly flush all tables/chains when the service is stopped. The script is also used to handle the case when the service is started but there are no saved rules. In that case, it creates an empty set of rules (i.e. rules that ACCEPT everything). The unit also supports the SAVE_ON_STOP feature (on by default, can be disabled). The code is mostly based on the rc script. Unfortunately, this means that there is some code duplication.
Created attachment 366616 [details] /usr/libexec/iptables-systemd-helper.sh The helper script. Along with the script, a symlink of it as /usr/libexec/ip6tables-systemd-helper.sh has to be installed.
Created attachment 366618 [details] /usr/lib/systemd/system/iptables.service The unit file. A copy of this file has to be installed as /usr/lib/systemd/system/ip6tables.service and adjusted with sed -i -e 's/iptables/ip6tables/g' ip6tables.service
Created attachment 366628 [details] /etc/systemd/system/iptables.service.d/00gentoo.conf iptables.service config file - configurable save on stop purpose - option to restore counters
Created attachment 366632 [details] iptables.service Final version - configurable save on stop purpose using 00gentoo.conf - optionally restore counters configurable in 00gentoo.conf - flush on stop - use of systemd-tmpfiles to make sure required dir & files exist - no helper script needed - no hardcoded tables & chains
Created attachment 367550 [details] Alternative iptables.service
Created attachment 367552 [details] Alternative iptables.service Missed ip6 variant.
Created attachment 367736 [details] Separate units for each service After a bit of fiddling I've came up with the following setup: - separate units for ip6?tables save/restore for flexibility - ensure that restore finishes before any daemon can start - source /etc/conf.d/ip6?tables to ease transition from openrc - saved rules can be reloaded by starting ip6?tables-restore.service again - current rules can be saved at any time by starting ip6?tables-save.service I don't find flushing on stop feature useful. AFAIK people usualy manage their rules by some external means anyway (scripts, etc.). Hope this will be useful.
Created attachment 367810 [details] ip*tables.service files (tar.gz) /usr/lib/systemd/system/iptables.service /usr/lib/systemd/system/ip6tables.service /etc/systemd/system/iptables.service.d/00gentoo.conf /etc/systemd/system/ip6tables.service.d/00gentoo.conf /usr/lib/tmpfiles.d/iptables.conf The latest & greatest version - separate iptables & ip6tables units - no need to install or enable the ip6tables unit - automatic ip6tables start/stop/reload/restart when iptables is - ip6tables 00gentoo.conf inherits iptables 00gentoo.conf using a softlink - start - loads rules from /var/lib/iptables/ip*tables-start - save on stop/restart (default to ip*tables-start) - flush on stop - reload - reloads the last saved rules from ip*tables-start - option to save to a different file than ip*tables-start (00gentoo.conf) - option to restore counters (default) configurable in 00gentoo.conf - save-only function is not needed since ip*tables-save should be used for that - use of systemd-tmpfiles to make sure required dir & files exist - no mixing with OpenRC config (which should never be done anyway!) - no hardcoded tables & chains - no chance for missing any chains (like /etc/init.d/iptables does) - no helper script needed - clean - no separate iptables-save or iptables-restore units needed - flexible - all the features one (reasonably) can think of - the fastest implementation ever - Note: check for iptables kernel support should be done in the ebuild Maybe the ExecStop needs some clarification. ExecStop=/bin/sh -c '/sbin/iptables-save --counters | tee "/var/lib/iptables/iptables-${SAVE}" \ | sed -nr "/^[*C]/p;s/^(:[A-Z]+ )[A-Z].*/\1ACCEPT/p" | /sbin/iptables-restore' ip*tables-save outputs the current tables, chains & rules which tee saves to a file and passes it on. This output (tee) is also used to flush the tables. Flushing ip*tables using ip*tables-restore requires all *tables with their :BUILTIN chains on policy ACCEPT followed by a COMMIT, so: *table :BUILTIN1 ACCEPT :BUILTIN2 ACCEPT COMMIT ... /^[*C]/p lets *table and COMMIT pass s/^(:[A-Z]+ )[A-Z].*/\1ACCEPT/p lets all :BUILTIN chains pass but changed to policy ACCEPT. :User-defined chains should/do not pass because they don't match the 2nd [A-Z] since they have a "-" which means no policy. Rules are not passed either since they start with "[" (or "-" when counters are not saved). So basically, everything that should pass will be passed to ip*tables-restore, the rest not. This way, all tables are flushed since --noflush is not specified. In addition, we don't need to hardcode chains or look in /proc for available tables. Furthermode, separate ip*tables commands for -F (flush) and -X (delete) like in other implementations make it slower since every ip*tables command consults, locks and unlocks the xtables which makes this implementation real fast! :) While I tested this thoroughly, I'd appreciate if others test this implementation too and provide some feedback. Thank U!
For your convenious, a simple installation & testing procedure: Download attachment 367810 [details] (iptables-systemd-service.tar.gz) tar xvzf iptables-systemd-service.tar.gz -C / systemctl daemon-reload # reload changed files systemctl disable iptables # remove current wants-links (if any) systemctl disable ip6tables # remove current wants-links (if any) systemctl enable iptables # enable iptables at boot systemctl enable ip6tables # enable ip6tables at boot & chain to iptables for openrc rules to be effective, you may have to cp /var/lib/iptables/rules.save /var/lib/iptables/iptables-start cp /var/lib/ip6tables/rules.save /var/lib/iptables/ip6tables-start systemctl start iptables # start iptables & ip6tables systemctl status iptables # iptables should be active systemctl status ip6tables # ip6tables should be active systemctl restart iptables # ip*tables-start should get the current timestamp ls -l /var/lib/iptables/ip*tables-start # check current timestamp Play with it, and don't forget to report some feedback! :)
Addition to comment #56: > tar xvzf iptables-systemd-service.tar.gz -C / It seems like the archive is dubble gzipped for some reason, so you may have to extract using: zcat iptables-systemd-service.tar.gz | tar xvzf - -C /
Created attachment 369384 [details] iptables-1.4.20-r1.ebuild.tar net-firewall/iptables/iptables-1.4.20-r1.ebuild net-firewall/iptables/iptables-1.4.21-r1.ebuild net-firewall/iptables/files/iptables.tmpfiles net-firewall/iptables/files/iptables.service net-firewall/iptables/files/iptables.service.conf net-firewall/iptables/files/ip6tables.tmpfiles net-firewall/iptables/files/ip6tables.service
I created an ebuild and applied some changes: - Created ebuilds for iptables-1.4.20-r1 & iptables-1.4.21-r1 - These ebuilds now check for IP_NF_IPTABLES & IP6_NF_IPTABLES too - Use the same rules files as OpenRC does - Configurable location of rules files for start - Configurable location of rules files to save at stop/restart - Possiblility to not save the rules files at all - Moved the symlink so ip6tables uses the same config dir/file(s) as iptables How to install? mkdir -p /usr/local/portage/net-firewall cp -rp /usr/portage/net-firewall/iptables /usr/local/portage/net-firewall/ tar xvf iptables-1.4.20-r1.ebuild.tar -C /usr/local/portage repoman manifest echo =net-firewall/iptables-1.4.20-r1 >>/etc/portage/package.accept_keywords rm -rf /etc/systemd/system/ip6tables.service.d # if using the previous version emerge -av net-firewall/iptables How to use? systemctl enable iptables systemctl enable ip6tables # if using ipv6 of course systemctl start iptables # now configure ip*tables with whatever tool you normally do systemctl restart iptables # now check the saved rules & the current ip6tables state I'd say, let's make iptables for systemd finally happen!
Please do this in systemd way and not OpenRC way. Take a look at ALSA units, for example. That is: 1. iptables-store.service that stores the state in ExecStart= and DOES ONLY THAT, 2. iptables-restore.service that restores the state in ExecStart= and DOES ONLY THAT, 3. no extra magic, defaults, seds, shells, configuration. (and same for ip6tables)
(In reply to Michał Górny from comment #60) > Please do this in systemd way and not OpenRC way. Take a look at ALSA units, > for example.r ip6tables) That's simply put unacceptable: 1. system administrators need a way to be able to mess with the firewall and say oops and quickly do a systemctl reload iptables 2. system administrators need a way to temporary stop the firewall to be able to troubleshoot a new service: systemctl stop iptables 3. system administrators need a way to be able to boot with rules they specified which is not necessary the last (possibly messed-up) state Besides that, alsa is a non-service and lacks a feature to reset or forget about deleted controls: - alsa cannot be enabled, disabled, started, stopped, restarted or reloaded - controls, once defined in /etc/asound.conf (and deleted), will *never* leave /var/lib/alsa/asound.state unless - https://bbs.archlinux.org/viewtopic.php?id=157290 or - you unload all alsa snd* modules and rm /var/lib/alsa/asound.state If you don't like my solution you're free, but simply saying I'm doing things the OpenRC way (which I didn't) isn't going to help us. Now, if you can do a better job which actually is acceptable & usable, be our guest!
(In reply to Evert from comment #61) > (In reply to Michał Górny from comment #60) > > Please do this in systemd way and not OpenRC way. Take a look at ALSA units, > > for example.r ip6tables) > > That's simply put unacceptable: > 1. system administrators need a way to be able to mess with the firewall and > say > oops and quickly do a systemctl reload iptables Just FYI, 'reloading' a service usually means *reloading configuration*, not *restoring configuration to previous state*. In fact, that is exact opposite of reloading. And anyway, what's the problem with: systemctl restart iptables-restore It sounds much more sane than overriding the meaning of 'reload'. > 2. system administrators need a way to temporary stop the firewall to be > able to > troubleshoot a new service: systemctl stop iptables Just because you are doing something wrong doesn't mean everyone's gotta do it the same way. 'Disabling' firewall on a production server temporarily either means you don't need firewall at all, or you need to find a new job. Not to mention that there will be no agreement upon what 'disabling' is. > 3. system administrators need a way to be able to boot with rules they > specified > which is not necessary the last (possibly messed-up) state And how does your script help with that? You stop the service, you mess up the state. Anyway, those are the issues to be solved by administrative tools. They are out of scope of init system. If you don't understand the purpose of init system, you shouldn't work on unit files in the first place.
I'm working on it.
Created attachment 369548 [details, diff] Patch adding units to the ebuild tree Could you test those units, please?
So basic usage instructions are: $ systemctl enable iptables-store $ systemctl enable iptables-restore and that's it? (I don't need ipv6) Anything else to consider?
Please introduce a systemd use flag in the ebuild...
(In reply to Leho Kraav (:macmaN @lkraav) from comment #65) > So basic usage instructions are: > > $ systemctl enable iptables-store > $ systemctl enable iptables-restore > > and that's it? (I don't need ipv6) Anything else to consider? Well, at this point they are enabled by default. However, that's open to discussion if someone sees a real issue with that.
(In reply to Evert from comment #66) > Please introduce a systemd use flag in the ebuild... There is no need for a use flag just to control the install of a few small flat files. The bikeshed is green, and you like green.
(In reply to Rick Farina (Zero_Chaos) from comment #68) > (In reply to Evert from comment #66) > > Please introduce a systemd use flag in the ebuild... > > There is no need for a use flag just to control the install of a few small > flat files. The bikeshed is green, and you like green. Actually, it is needed since this implementation would conflict with other implementations. Above all that, it's only 2 "if use" staments, so no big deal. Another option would be to remove the default enabling.
(In reply to Evert from comment #69) > (In reply to Rick Farina (Zero_Chaos) from comment #68) > > (In reply to Evert from comment #66) > > > Please introduce a systemd use flag in the ebuild... > > > > There is no need for a use flag just to control the install of a few small > > flat files. The bikeshed is green, and you like green. > > Actually, it is needed since this implementation would conflict with other > implementations. Above all that, it's only 2 "if use" staments, so no big > deal. > Another option would be to remove the default enabling. Please explain how the systemd unit files conflict when people aren't using systemd?
I would personally prefer that the units not be enabled by default. However, I suppose it doesn't really matter since there are no rules defined by default and the default policy is "ACCEPT".
(In reply to Rick Farina (Zero_Chaos) from comment #70) > (In reply to Evert from comment #69) > > (In reply to Rick Farina (Zero_Chaos) from comment #68) > > > (In reply to Evert from comment #66) > > > > Please introduce a systemd use flag in the ebuild... > > > > > > There is no need for a use flag just to control the install of a few small > > > flat files. The bikeshed is green, and you like green. > > > > Actually, it is needed since this implementation would conflict with other > > implementations. Above all that, it's only 2 "if use" staments, so no big > > deal. > > Another option would be to remove the default enabling. > > Please explain how the systemd unit files conflict when people aren't using > systemd? People should be given the possibility to override the default implementation and since I for one prefer another implementation, it will conflict with the implementation you suggest. Besides that, it's just not necessary to pollute the filesystem for non-systemd users and it will make my life easier. And, I agree with Mike and prefer units not be enabled by default too.
(In reply to Evert from comment #72) > People should be given the possibility to override the default They are, it's called INSTALL_MASK > implementation and since I for one prefer another implementation, it will > conflict with the implementation you suggest. Besides that, it's just not Having systemd unit files on a system with systemd causes exactly 0 conflict. > necessary to pollute the filesystem for non-systemd users and it will make > my life easier. > And, I agree with Mike and prefer units not be enabled by default too. QA policy is to not use flags to control the install of small files that don't cause issues. You might not use log rotate but those files are installed unconditionally as well. If you have a TECHNICAL issue please present it, otherwise there will be no use flag as per standard policy.
(In reply to Mike Gilbert from comment #71) > I would personally prefer that the units not be enabled by default. +1
I don't mind either way. However, are you sure that the majority of users will prefer that iptables rules are not persistent by default? Please remember that there's at least a few ways of solving this for corner cases, including 'systemctl mask'.
(In reply to Mike Gilbert from comment #71) > I would personally prefer that the units not be enabled by default. +1 (In reply to Michał Górny from comment #75) > I don't mind either way. However, are you sure that the majority of users > will prefer that iptables rules are not persistent by default? Please > remember that there's at least a few ways of solving this for corner cases, > including 'systemctl mask'. When people start playing with iptables, they may do things they didn't want to do (=lock themselves out). Normally, a reboot is often a last resort for those people... but when every changes you made are persistent per default, well.. And don't forget... someone wanted to implement a stop/clear function the user may know from the init.d version... but if I haven't missed something, the current systemd solution don't offer such a helper function.. I really don't understand what's wrong with Evert's solution: It had all the functionality from the runscript (so people switching to systemd don't need to learn something new), it was working.. Yes, he created a helper/wrapper script... but iptables is not a daemon/service! So why is that a problem? PS: There were reasons why services won't be enabled without user interaction before systemd. Doesn't that apply to systemd or has it changed in general (e.g. also with OpenRC, services should be enabled without user interaction)?
Regarding "restore" unit, you need to put DefaultDependencies=no Wants=sysinit.target After=sysinit.target Before=basic.target declarations there to ensure that iptables are fully restored before any network-related daemons start. Defaults may cause random problems depending on rule setup and startup sequence. For example, sudden activation of connection tracking will break already established connections. We can not know in general which services users have in their startup targets, so better to play it safe IMHO. And I'm not sure Conflicts=shutdown.target is necessary because the service is oneshot anyway.
(In reply to Rick Farina (Zero_Chaos) from comment #73) > (In reply to Evert from comment #72) > > > People should be given the possibility to override the default > > They are, it's called INSTALL_MASK > Nice, thanks for pointing thay out, but see below... > > implementation and since I for one prefer another implementation, it will > > conflict with the implementation you suggest. Besides that, it's just not > > Having systemd unit files on a system with systemd causes exactly 0 conflict. > > > necessary to pollute the filesystem for non-systemd users and it will make > > my life easier. > > And, I agree with Mike and prefer units not be enabled by default too. > > QA policy is to not use flags to control the install of small files that > don't cause issues. You might not use log rotate but those files are > installed unconditionally as well. > > If you have a TECHNICAL issue please present it, otherwise there will be no > use flag as per standard policy. Problem: Many users don't want a firewall to be turned on (enabled) by default just because they installed some package and they want to turn it off. Technical issue: Enabling per default installs some symlinks. INSTALL_MASK does not work on symlinks.
*** Bug 501610 has been marked as a duplicate of this bug. ***
(In reply to Evert from comment #78) > > If you have a TECHNICAL issue please present it, otherwise there will be no > > use flag as per standard policy. > > Problem: > Many users don't want a firewall to be turned on (enabled) by default just > because they installed some package and they want to turn it off. In this case, the service *does not* enable the firewall. The service only loads the previous configuration that could either enable or disable it. The firewall gets enabled by kernel, and not running the service leaves it in some random state. So if people want no firewall (like I do), they can just set the policy on all chains, and the service is going to respect that. > Technical issue: > Enabling per default installs some symlinks. > INSTALL_MASK does not work on symlinks. Then file a bug against portage instead of using that as an excuse to prove your point. That said, you can still mask the unit using 'systemctl mask'.
No. This is n(In reply to Michał Górny from comment #80) > > Problem: > > Many users don't want a firewall to be turned on (enabled) by default just > > because they installed some package and they want to turn it off. > > In this case, the service *does not* enable the firewall. The service only > loads the previous configuration that could either enable or disable it. The > firewall gets enabled by kernel, and not running the service leaves it in > some random state. > > So if people want no firewall (like I do), they can just set the policy on > all chains, and the service is going to respect that. No. This is not good. Think about people using net-firewall/shorewall or net-firewall/arno-iptables-firewall or any other solution based on iptables. They don't expect that any iptables will be restored automatically. Also, people coming from other Init systems won't expect such a change. This will cause many many problems. Please don't enable the service automatically.
(In reply to Thomas D. from comment #81) > > So if people want no firewall (like I do), they can just set the policy on > > all chains, and the service is going to respect that. > > No. This is not good. Think about people using net-firewall/shorewall or > net-firewall/arno-iptables-firewall or any other solution based on iptables. This is a fair point I have missed. I'll commit it disabled by default then, with an easy alias to enable it: $ systemctl enable iptables ln -s '/usr/lib/systemd/system/iptables-store.service' '/etc/systemd/system/shutdown.target.wants/iptables-store.service' ln -s '/usr/lib/systemd/system/iptables-restore.service' '/etc/systemd/system/basic.target.wants/iptables-restore.service' $ systemctl disable iptables rm '/etc/systemd/system/shutdown.target.wants/iptables-store.service' rm '/etc/systemd/system/basic.target.wants/iptables-restore.service'
Thanks Michał! By the way, does your unit really work for you? I have to admit I reviewed it, but never tested it until now and found the store part doesn't work for me.
(In reply to Evert from comment #83) > By the way, does your unit really work for you? I have to admit I reviewed > it, but never tested it until now and found the store part doesn't work for > me. Well, that depends on what you mean by 'works'. If you mean 'stores the data when asked to', then yes, it does. If you mean 'starts during shutdown to store the data', then it doesn't :). But I have a fix already, so don't worry. I'll do one more review of the deps and commit afterwards.
Committed as 1.4.21-r1.
Created attachment 379124 [details] iptables systemd real service implementation All other distributions including Gentoo/OpenRC implement iptables as a real service (where the init system keeps track about the start/stop state) while Gentoo/Systemd does not! That's why I'd like to share this systemd service implementation. This might eventually be a serious candidate for a next release. You might want to take a look at the iptables.conf file and the helper script. Constructive criticisms are welcome. If you like it, simply use it. If you love it, tell about it!
Hi there, This isn't a bugg and sorry for posting here. Looks like only few people is running systemd profile in the gentoo forum. However, I didn't understand how iptables is called in a systemd profile. From the above, looks like iptables and rules are working, but not sure what going on with the service itself. Could, please, someone drop me a line? Best mephisto etc # systemctl start iptables-restore.service mephisto etc # more /var/lib/iptables/rules-save # Generated by iptables-save v1.4.21 on Tue May 12 13:59:15 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1923:223521] [0:0] -A INPUT -s 127.0.0.1/32 -j ACCEPT [2111:1466367] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -i eno1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --mask 255.255.255.255 --rsource [0:0] -A INPUT -i eno1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --rcheck --seconds 60 --hitcount 5 --rttl --name SSH --mask 255.255.255.255 --r source -j DROP [22547:3344930] -A INPUT -j DROP COMMIT # Completed on Tue May 12 13:59:15 2015 mephisto etc # systemctl status iptables.service ● iptables.service - Store and restore iptables firewall rules Loaded: error (Reason: Invalid argument) Active: inactive (dead) Mai 12 14:00:31 mephisto.incor.usp.br systemd[1]: iptables.service lacks both ExecStart= and ExecStop= setting. Refusing.
Created attachment 403168 [details] iptables.service - real systemd service Hi Frederico, Gentoo decided not to implement ip*tables as a service but instead load ip*tables at boot and save at shutdown. However, this voids the purpose of the init system which should provide a uniform way to start/stop/restart/reload any service. To be able to stop/start/restart/reload/save ip*tables, system administrators need to create their own script. Besides that, this introduces the risk of loosing the firewall configuration (at shutdown) since the init system doesn't keep track of the start/stop state of the service which IMHO is very undesirable. Fortunately, I created a real iptables.service implementation for systemd which does an excellent job and keeps track of the start/stop state of the service. This implementation uses a helper script which handles both iptables and ip6tables (if available) and eliminates the ugly need for separate iptables and ip6tables service units. This implementation can easily be installed using this procedure: # disable the braindead units systemctl disable iptables systemctl disable ip6tables cd / tar xvf /path/to/iptables.service-systemd.tar systemctl daemon-reload # start & enable the real service implementation systemctl start iptables systemctl enable iptables # at this point, you might want to check or (re)configure your iptables rules iptables -nvL ip6tables -nvL Note: If you change the ip*tables firewall rules, you can save it manually just like you're used to with OpenRC: systemctl start iptables-save However, this is not mandatory since it will be saved at shutdown anyway (unless iptables has not been enabled and started). Let me know how this works for you if you decide to go this way too. Cheers!
(In reply to Frederico from comment #87) > Mai 12 14:00:31 mephisto.incor.usp.br systemd[1]: iptables.service lacks > both ExecStart= and ExecStop= setting. Refusing. This is broken and should be fixed. Please file a new bug for this.
(In reply to Evert from comment #88) > Created attachment 403168 [details] > iptables.service - real systemd service > > > This implementation can easily be installed using this procedure: > # disable the braindead units > systemctl disable iptables > systemctl disable ip6tables > cd / > tar xvf /path/to/iptables.service-systemd.tar > systemctl daemon-reload > # start & enable the real service implementation > systemctl start iptables > systemctl enable iptables > # at this point, you might want to check or (re)configure your iptables rules > iptables -nvL > ip6tables -nvL > > > Let me know how this works for you if you decide to go this way too. > > Cheers! Hi Evert, Thanks for helping. I've downloaded the tar file and followed your instructions. I'm stopped at the "systemctl start iptables", which I supposed to be executed before enable iptables. Here goes the error message: """Job for iptables.service failed. See "systemctl status iptables.service" and "journalctl -xe" for details.""" I don't intend to change the iptables rules all the time. Also, I'm not running a server, this is only my work desktop. So perhaps a dirt overcome would be to run "ipatable-restore < /etc/iptables.rules" from the system profile or somewhere. Can I have you opinion? Best.
Created attachment 403348 [details] iptables.service - real systemd service Frederico, Can you paste the output of this command? # systemctl -l status iptables.service or if it doesn't say much: # journalctl -eu iptables --no-pager |tail -n 25 Also, here is the latest version...
