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 2042529 - backport sysconfig file removal
Summary: backport sysconfig file removal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libvirt
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: yafu
URL:
Whiteboard:
Depends On:
Blocks: 2032980
TreeView+ depends on / blocked
 
Reported: 2022-01-19 16:29 UTC by Peter Krempa
Modified: 2023-04-05 08:52 UTC (History)
6 users (show)

Fixed In Version: libvirt-8.0.0-2.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 12:46:17 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-108744 0 None None None 2022-01-19 16:35:48 UTC
Red Hat Product Errata RHBA-2022:2390 0 None None None 2022-05-17 12:46:49 UTC

Description Peter Krempa 2022-01-19 16:29:09 UTC
Description of problem:
Upstream removed the distribution of 'sysconfig' files with following justification:

    sysconfig files are owned by the admin of the host. They have the
    liberty to put anything they want into these files. This makes it
    difficult to provide different built-in defaults.
    
    Remove the sysconfig file and place the current desired default into
    the service file.
    
    Local customizations can now go either into /etc/sysconfig/name
    or /etc/systemd/system/name.service.d/my-knobs.conf
    
    Attempt to handle upgrades in libvirt.spec.
    Dirty files which are marked as %config will be renamed to file.rpmsave.
    To restore them automatically, move stale .rpmsave files away, and
    catch any new rpmsave files in %posttrans.
    
    Signed-off-by: Olaf Hering <olaf>
    Reviewed-by: Andrea Bolognani <abologna>

Backport the patch to prevent future headaches when rebasing.

Required commits:

commit 8eb4461645c5738674232ee26c15f5555230b7ff
Author: Olaf Hering <olaf>
Date:   Wed Jan 12 11:45:08 2022 +0100

    remove sysconfig files
    
    sysconfig files are owned by the admin of the host. They have the
    liberty to put anything they want into these files. This makes it
    difficult to provide different built-in defaults.
    
    Remove the sysconfig file and place the current desired default into
    the service file.
    
    Local customizations can now go either into /etc/sysconfig/name
    or /etc/systemd/system/name.service.d/my-knobs.conf
    
    Attempt to handle upgrades in libvirt.spec.
    Dirty files which are marked as %config will be renamed to file.rpmsave.
    To restore them automatically, move stale .rpmsave files away, and
    catch any new rpmsave files in %posttrans.
    
    Signed-off-by: Olaf Hering <olaf>
    Reviewed-by: Andrea Bolognani <abologna>

commit 161727417a91bdddf8f3167cf70c3de2829be81c
Author: Jim Fehlig <jfehlig>
Date:   Fri Jan 7 14:35:10 2022 -0700

    docs: Add man page for libvirt-guests
    
    Signed-off-by: Jim Fehlig <jfehlig>
    Reviewed-by: Andrea Bolognani <abologna>

commit 3be5ba11a2c6fcb2dfdffa03ab4f847113f36b85
Author: Jim Fehlig <jfehlig>
Date:   Mon Jan 10 11:42:58 2022 -0700

    build: Only install libvirt-guests when building libvirtd
    
    libvirt-guests was already moved to the libvirt daemon package in commit
    d800c50349. It only needs to be installed when building libvirtd.
    
    Signed-off-by: Jim Fehlig <jfehlig>
    Reviewed-by: Andrea Bolognani <abologna>

Comment 2 yafu 2022-01-20 11:36:19 UTC
Hi Peter,

I tested the patches with v8.0.0-118-g755b16d10a. And I have 2 questions about the patches.
Q1: If I edit /etc/sysconfig/virtqemud with the libvirt pkgs without the patches, then upgrade to libvirt-v8.0.0-118-g755b16d10a and remove all libvirt pkgs, /etc/sysconfig/virtqemud did not remove.
Q2: In man manual of libvirt-guests, it says " libvirt-guests defines several variables to control service behavior.  The default value  of  these  variables
       can be overridden in: /etc/sysconfig/libvirt-guests", but i did not find file "/etc/sysconfig/libvirt-guests" and also could not find the setting in other files.

Would you help to check it please? Thanks a lot.

Comment 3 Peter Krempa 2022-01-20 11:57:48 UTC
(In reply to yafu from comment #2)
> Hi Peter,
> 
> I tested the patches with v8.0.0-118-g755b16d10a. And I have 2 questions
> about the patches.
> Q1: If I edit /etc/sysconfig/virtqemud with the libvirt pkgs without the
> patches, then upgrade to libvirt-v8.0.0-118-g755b16d10a and remove all
> libvirt pkgs, /etc/sysconfig/virtqemud did not remove.

The main idea is (also outlined in the commit message) that files in /etc/sysconfig are owned by the system administrator and not by the package.

The scenario you are describing is actually also covered by the commit message and is a deliberate "upgrade" path. In case you modified the file, the new package will preserve your modifications, effectively putting you in control of the file. That's also the reason why it wasn't removed.

Thus:

1) if you didn't edit the files, they should be removed, defaults are taken from the new location (defaults should not change)
2) if you did edit the files, after upgrade they become ownership of the admin, thus are not removed
3) if you add new file to override config once the new version is installed that also will not be removed as it was added manually.

Additionally the reason for this backport is to eliminate the upgrade step in a subsequent rhel-9 upgrades where libvirt would be rebased, so ideally almost all users will not deal with the upgrade scenario ever in rhel-9.

> Q2: In man manual of libvirt-guests, it says " libvirt-guests defines
> several variables to control service behavior.  The default value  of  these
> variables
>        can be overridden in: /etc/sysconfig/libvirt-guests", but i did not
> find file "/etc/sysconfig/libvirt-guests" and also could not find the
> setting in other files.

You should create your own and put the overrides into that file.

Comment 4 yafu 2022-01-21 04:52:34 UTC
(In reply to Peter Krempa from comment #3)
> (In reply to yafu from comment #2)
> > Hi Peter,
> > 
> > I tested the patches with v8.0.0-118-g755b16d10a. And I have 2 questions
> > about the patches.
> > Q1: If I edit /etc/sysconfig/virtqemud with the libvirt pkgs without the
> > patches, then upgrade to libvirt-v8.0.0-118-g755b16d10a and remove all
> > libvirt pkgs, /etc/sysconfig/virtqemud did not remove.
> 
> The main idea is (also outlined in the commit message) that files in
> /etc/sysconfig are owned by the system administrator and not by the package.
> 
> The scenario you are describing is actually also covered by the commit
> message and is a deliberate "upgrade" path. In case you modified the file,
> the new package will preserve your modifications, effectively putting you in
> control of the file. That's also the reason why it wasn't removed.
> 
> Thus:
> 
> 1) if you didn't edit the files, they should be removed, defaults are taken
> from the new location (defaults should not change)
> 2) if you did edit the files, after upgrade they become ownership of the
> admin, thus are not removed
> 3) if you add new file to override config once the new version is installed
> that also will not be removed as it was added manually.
> 
> Additionally the reason for this backport is to eliminate the upgrade step
> in a subsequent rhel-9 upgrades where libvirt would be rebased, so ideally
> almost all users will not deal with the upgrade scenario ever in rhel-9.
> 
> > Q2: In man manual of libvirt-guests, it says " libvirt-guests defines
> > several variables to control service behavior.  The default value  of  these
> > variables
> >        can be overridden in: /etc/sysconfig/libvirt-guests", but i did not
> > find file "/etc/sysconfig/libvirt-guests" and also could not find the
> > setting in other files.
> 
> You should create your own and put the overrides into that file.

Got it. Thanks for your clarification.

Comment 7 yafu 2022-01-27 02:52:30 UTC
Verified with libvirt-8.0.0-2.el9.x86_64.

Test steps:
1.Install libvirt*8.0.0-2* pkgs;

2.There is no config file in /etc/sysconfig/ dir:
#ls /etc/sysconfig/*virt*
ls: cannot access '/etc/sysconfig/*virt*': No such file or directory

3.Check the listen timeout option was moved to systemd config file:
# for drv in qemu interface network nodedev nwfilter secret storage proxy; do systemctl cat virt${drv}d | grep -i timeout; done
Environment=VIRTQEMUD_ARGS="--timeout 120"
Environment=VIRTINTERFACED_ARGS="--timeout 120"
Environment=VIRTNETWORKD_ARGS="--timeout 120"
Environment=VIRTNODEDEVD_ARGS="--timeout 120"
Environment=VIRTNWFILTERD_ARGS="--timeout 120"
Environment=VIRTSECRETD_ARGS="--timeout 120"
Environment=VIRTSTORAGED_ARGS="--timeout 120"
Environment=VIRTPROXYD_ARGS="--timeout 120"

4.Check all the sub-daemons are started with '--timeout 120' option:
(1)# for drv in qemu interface network nodedev nwfilter secret storage; do virsh connect ${drv}:///system; ps aux | grep -i virt${drv}d | grep -v grep ; done

root        1171  0.0  0.0 1513308 33948 ?       Ssl  Jan25   0:00 /usr/sbin/virtqemud --timeout 120

root        7021  0.0  0.0 1362264 23852 ?       Ssl  21:29   0:00 /usr/sbin/virtinterfaced --timeout 120

root        7049  0.0  0.0 1362176 25060 ?       Ssl  21:29   0:00 /usr/sbin/virtnetworkd --timeout 120

root        7125  0.1  0.0 1510164 26656 ?       Ssl  21:29   0:00 /usr/sbin/virtnodedevd --timeout 120

root        7155  0.0  0.0 1363172 23784 ?       Ssl  21:29   0:00 /usr/sbin/virtnwfilterd --timeout 120

root        7184  0.0  0.0 1362076 22008 ?       Ssl  21:29   0:00 /usr/sbin/virtsecretd --timeout 120

root        7214  0.0  0.0 1523688 37396 ?       Ssl  21:29   0:00 /usr/sbin/virtstoraged --timeout 120

(2)Also check virtproxyd after connecting with direct mode virsh client:
#ps aux | grep -i virtproxyd
root        7253  0.0  0.0 1362120 21648 ?       Ssl  21:29   0:00 /usr/sbin/virtproxyd --timeout 120

5.Check the man page of libvirt-guests:
#man 8 libvirt-guests
LIBVIRT-GUESTS(8)                                           Virtualization Support                                           LIBVIRT-GUESTS(8)

NAME
       libvirt-guests - suspend/resume running libvirt guests
...


6.Because libvirt-guests does not support modular daemon now, just test libvirt-guests in bug: 
Bug 1868537 - RFE: Support libvirt-guests.service working with libvirt modular daemon

Comment 9 errata-xmlrpc 2022-05-17 12:46:17 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 (new packages: libvirt), 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-2022:2390

Comment 10 John 2023-04-05 04:38:21 UTC
Absolute sheer bloody-minded idiocy.

/etc/sysconfig contains config files which should be owned and installed by various rpms, and which may then be edited just like a myriad of other files under /etc.

Just like so many pointless, annoying, destructive pain in the ass decisions by developers who hold their customers in contempt, this change serves absolutely no purpose and achieves nothing besides causing grief and annoyance for users & customers.

The libvirt packages should install a default /etc/sysconfig/libvirt-guests, containing all the valid settings and comments and explanations and so on.

Now we have the situation where documentation all over the web says libvirt-guetss is configured via /etc/sysconfig/libvirt-guests, and yet when I look there on one of my el9 kvm hosts, the file is not there.

That makes me wonder whether the file has been deprecated and will be ignored if I do create it and put settings in there.
It cause grief and consternation, and I end up trawling the internet for clues as to what happened.

As the file is no longer there, it means i have to trawl through other servers or the interweb to check the syntax of the settings in the file or to check what the unmodified default settings are, rather than just look in the file on the server in question.

And do i find any documentation explaining why the file is gone?
No, not until I end up here.

Like so many other decisions made by idiots, this change is an absolute disgrace.

DO YOUR JOBS PROPERLY, AND STOP CHANGING AND BREAKING THINGS AND MAKING THINGS MORE DIFFICULT FOR YOUR CUSTOMERS FOR NO REASON.

Comment 11 Peter Krempa 2023-04-05 08:01:40 UTC
Note that this bug and corresponding backport of the upstream patches was done so that all rhel-9 releases have the same behaviour and the change doesn't happen during the lifecycle when libvirt will be rebased to a new upstream version which we do regularly.

If you wish to discuss the merit of the change feel free to contact the upstream project:

  https://www.libvirt.org/contact.html#mailing-lists

or file an upstream issue:

 https://www.libvirt.org/bugs.html#general-libvirt-bug-reports

or even file a proper rhel-9 bug report if you have reasons for it.

Before doing so ...

(In reply to John from comment #10)
> Absolute sheer bloody-minded idiocy.

[...]

> Like so many other decisions made by idiots, this change is an absolute
> disgrace.

... I **VERY STRONGLY** recommend you read the following document first:

  https://www.libvirt.org/governance.html#code-of-conduct

Comment 12 John 2023-04-05 08:35:45 UTC
I don't remember ever agreeing to be bound by that code of conduct.

And such codes are nonsense anyway, when they're predicated on principles of respect, which developers clearly do NOT have for users/customers.
There is zero excuse for this change.
The reasons given are illogical nonsense.
It is just pure laziness, which will not persuade me to bow, scrape and grovel to developers, asking them to reconsider.

I'm happy to just make it very clear here, that this is yet another incredibly poor decision by lazy Linux developers, and that customers do notice these things.
So, clap clap clap & well done to all involved, instead of making things better, you've just made libvirt & linux in general worse. Brilliant.

Comment 13 John 2023-04-05 08:52:53 UTC
I mean, what utter nonsense is this:
    "sysconfig files are owned by the admin of the host. They have the
    liberty to put anything they want into these files. This makes it
    difficult to provide different built-in defaults."

If there is ANY sense to that idiotic statement, then logically, I will now expect all other packages to immediately cease installing ANYTHING under /etc/
So we can expect /etc/ to be empty in RHEL10 can we?

How are the files under /etc/sysconfig/ really any different to all the other config files under /etc/?
They're no different - except they often start with everything commented out, so default settings are used.

It's not hard. Just show some basic consideration and respect for your users, and leave the sysconfig file there.


Note You need to log in before you can comment on or make changes to this bug.