RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1440741 - IPSet Service Monolithic Operation
Summary: IPSet Service Monolithic Operation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipset
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Stefano Brivio
QA Contact: Vaclav Danek
Ioanna Gkioka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-10 12:07 UTC by NOYB
Modified: 2018-11-26 10:27 UTC (History)
8 users (show)

Fixed In Version: 6.38-1
Doc Type: Enhancement
Doc Text:
Each IP set is saved and restored from an individual file With this update, when the `ipset` `systemd` service is used, each IP set is saved in its own file in the `/etc/sysconfig/ipset.d/` directory. When the `ipset` service loads the `ipset` configuration, these files are also restored from each corresponding set. This feature provides easier maintenance and configuration of single sets. Note that using one single file containing all configured sets in `/etc/sysconfig/ipset` is still possible. However, if the `ipset` service is configured to save files on the `stop` action, or when the `save` operation is explicitly invoked, this legacy file will be removed, and the contents of all configured sets will be split into different files in `/etc/sysconfig/ipset.d/`.
Clone Of:
Environment:
Last Closed: 2018-10-30 10:45:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Modified ipset.start-stop script - operates on sets individually (2.03 KB, application/x-gzip)
2017-04-10 12:07 UTC, NOYB 		no flags Details
Modified ipset.start-stop script - operates on sets individually - Update-1 (594 bytes, patch)
2017-09-21 01:37 UTC, NOYB 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3167 0 None None None 2018-10-30 10:45:51 UTC

Description NOYB 2017-04-10 12:07:12 UTC 
Created attachment 1270476 [details]
Modified ipset.start-stop script - operates on sets individually

Description of problem:
The ipset service package saves all sets as large monolithic file.  Would be better to operate on individual set_name.ipset files in /etc/sysconfig/ipset directory instead of a monolithic ipset file.

This would be more flexible for keeping smaller more dynamic sets up to date without having to save all sets even though they are not being changed.

Saving to and restoring from individual set files rather than monolithic allows each set to be maintained and updated on an individual basis and schedule that is appropriate for each set.

Version-Release number of selected component (if applicable):
ipset-service-6.19-6.el7.noarch

How reproducible:
100%  It's how it works.

Steps to Reproduce:
1. /usr/libexec/ipset/ipset.start-stop save
2. /usr/libexec/ipset/ipset.start-stop start
3.

Actual results:
1. All sets saved to monolithic file.
2. All sets restored from monolithic file.

Expected results:
1. Each set saved to individual file: /etc/sysconfig/ipset/set_name.ipset
2. Each set restored from individual file: /etc/sysconfig/ipset/set_name.ipset

Additional info:
Attached is modified /usr/libexec/ipset/ipset.start-stop script that operates on each set individually.

If an /etc/sysconfig/ipset file exists it will need to be removed or renamed so that the /etc/sysconfig/ipset directory can be created.
Comment 2 NOYB 2017-09-21 01:37:56 UTC 
Created attachment 1328718 [details]
Modified ipset.start-stop script - operates on sets individually - Update-1

Update for: ipset-service-6.29-1.el7.noarch
Which includes: https://bugzilla.redhat.com/show_bug.cgi?id=1377621
Comment 9 errata-xmlrpc 2018-10-30 10:45:38 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3167
Comment 11 Stefano Brivio 2018-11-22 16:49:23 UTC 
Ioanna,

Just a few comments:

> Each IP set is saved in an individual file and restored from the same file

> With this update, when running the `ipset` `systemd` service, each IP set is
> saved in its own separate file created under the `/etc/sysconfig/ipset.d/`

When the service is running, sets are not actually saved, sets get saved when the service is stopped, that's why I originally wrote "when IP sets are saved by the `ipset` `systemd` service, a separate file for each set is created [...]".

But you could approximate that with:

    when the `ipset` `systemd` service is used, each IP set is saved [...]

> folder. When the `ipset` service is loading the `ipset` configuration, these

I'd go with "loads" here.

> files are also restored from each corresponding set. This feature makes
> maintenance and user configuration of single sets easier.
>
> Note that using one single file containing all configured set at

This should be "sets".

> `/etc/sysconfig/ipset` is still possible. However, if the `ipset` service is
> configured to save files on the `stop` action, or when the `save` operation is
> explicitly set, this legacy file will be removed, and the contents of all

[...] explicitly "called" or "invoked" ("issued", even) I'd rather say. An operation can't be "set".

> configured sets will be split into different files under
> `/etc/sysconfig/ipset.d/`.

The rest looks good to me!
Note You need to log in before you can comment on or make changes to this bug.