Created attachment 928274 [details] Patch implementing the "service ipset save" command. Description of problem: There is no easy way to manually save loaded ipsets for later reload by service. The only save support currently implemented involves modifying systemd script and applies at each service stop/restart. A legacy "save" service command should be implemented for that purpose, like iptables does. The attached patch implements this command. It must be applied to the fedora SCM directory (rawhide). Spec file versioning and changelog are not updated. A backport to F20 (as well as "Requires: kernel" suppression) would be welcome. Thanks
> There is no easy way to manually save loaded ipsets for later reload by service. Yes there is: # ipset save > /etc/ipset/ipset And that's it, next time you restart the service, it will load the sets you saved. (note: if this doesn't work, then that's an actual bug we need to fix) > A legacy "save" service command should be implemented for that purpose, like iptables does. No, those legacy actions were only a way to help the transition to systemd for admins who had used the services under sysvinit. The ipset service appeared after the move to systemd, so such a legacy action makes no sense. ---- Given that there already is a way to save sets, and that your proposed patch adds something I disagree with, I'm inclined to close this as NOTABUG. Unless I missed something... Did I? Leaving this open a bit, to give you a chance to convince me. :)
> Unless I missed something... Did I? No you did'nt. But (trying to convince you :-)) 1) The save() script seems to do a lot more (even if the result is the same). 2) The save() script is already present. 3) With the command you mention, people have to know the internal service mechanism, while "service something save" is almost standard, even if not directly implemented in systemd. This is the first thing people try: they don't even have to know the file name, neither the internal mechanism/format. 4) This is a kind of "service normalization": after all, "service iptables save" can also be performed with shell commands. Sorry that you disagree with this: I know this is a kind of wart in terms of design, but this feature is much valuable to the end user. And yes, this is not a bug, this is a caveat + improvement ;-)
(In reply to Patrick Monnerat from comment #2) > "service something save" is almost standard, Not any more. The « service » command is purely kept for compatibility reasons, but we now use « systemctl » ;) Eventually, the « service » command might be deprecated (no idea whether there are plans for it, but it wouldn't surprise me) so I don't really want to create new ways to depend on it. ----- Also, you don't need to modify the systemd unit file, you could just drop a snippet in /etc/systemd/system/ipset.service.d/autosave.conf containing something like (untested) : [Service] Environment=IPSET_SAVE_ON_STOP=yes IPSET_SAVE_ON_RESTART=yes And that's it, from now on stopping/restarting the service will automatically save (if that's what you want, of course, and provided I got the syntax right ;) ). So all in all, I'm really not in favor of this change. Sorry.
Never mind. Maybe add a README for the package explaining it to end users: this will avoid them to dig into the systemd scripts to discover what you explain in this thread... just a constructive suggestion :-) Thanks