Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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/`.
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.
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
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!
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.