Bug 1702678 - Settings are not saved with "yum config-manager --save --setopt=<repoid>.<option>=<value>"
Summary: Settings are not saved with "yum config-manager --save --setopt=<repoid>.<opt...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf-plugins-core
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Jaroslav Rohel
QA Contact: Eva Mrakova
URL:
Whiteboard:
Depends On: 1681085 1746349
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-24 12:54 UTC by Kyle Walker
Modified: 2019-11-05 22:22 UTC (History)
6 users (show)

Fixed In Version: dnf-plugins-core-4.0.8-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:21:49 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3583 None None None 2019-11-05 22:22:01 UTC

Description Kyle Walker 2019-04-24 12:54:43 UTC
Description of problem:
 Contrary to YUM3 behaviour, settings are not saved with "yum config-manager --save --setopt=<repoid>.<option>=<value>".


Version-Release number of selected component (if applicable):
 python3-dnf-plugins-core-4.0.2.2-3.el8.noarch


How reproducible:
 Easily

Steps to Reproduce:
1. Create an example repository that is not managed by subscription-manager

# cat > /etc/yum.repos.d/example.repo << EOF
[example]
name=Example Repo 
baseurl=http://example.example.com/
enabled=1
gpgcheck=0
EOF

2. Verify the state of the default "enabled"

# yum config-manager --dump example | grep enabled\ 

3. Change the value with "yum config-manager"

# yum config-manager --save --setopt=example.enabled=0

4. Verify the results

# yum config-manager --dump example | grep enabled\


Actual results:
# yum config-manager --dump example | grep enabled\ 
enabled = 1
# yum config-manager --save --setopt=example.enabled=0
<snip>
# yum config-manager --dump example | grep enabled\ 
enabled = 1


Expected results:
# yum config-manager --dump example | grep enabled\ 
enabled = 1
# yum config-manager --save --setopt=example.enabled=0
<snip>
# yum config-manager --dump example | grep enabled\ 
enabled = 0


Additional info:
This differs from the YUMv3 (RHEL 7 and before) state. YUMv3 results in the repository configuration file being updated with the new values.

Comment 2 Jaroslav Rohel 2019-06-20 09:57:14 UTC
> 3. Change the value with "yum config-manager"
> # yum config-manager --save --setopt=example.enabled=0

According to documentation the right syntax is:
yum config-manager --save --setopt=enabled=0 example

Fragments from manpage:
dnf config-manager [options] <repoid>...
<repoid> ...If not specified, display / modify main DNF configuration...

So, in your example you want to change "example" repo but list of repos "<repoid>..." was not specified. That means a list with one item "main" repo is used. So "example" repo is not contained in the list of repos for modifying and "--setopt=example.enabled=0" is dropped out. We can improve the "dnf" to wrote some warning message that the value was not saved and why.

Example:
dnf config-manager --save --setopt=deltarpm=1 --setopt=virtualbox.skip_if_unavailable=0 --setopt=myrepo.skip_if_unavailable=1 virtualbox fedora

* "--setopt=deltarpm=1" sets "deltarpm=1" for "virtualbox" and "fedora" repo
* "--setopt=virtualbox.skip_if_unavailable=0" sets "skip_if_unavailable=0" for "virtualbox" repo
* "--setopt=myrepo.skip_if_unavailable=1" does nothing because "myrepo" is not listed in "<repoid>..."

I think the old "yum" behaviour was similar to "dnf". But later (after "dnf" fork) there was done incompatible change in "yum" and "myrepo" was automatically added to "<repoid>..." list.
(Probably https://bugzilla.redhat.com/show_bug.cgi?id=1403015 is the reason).

May be better is to add warning message with information instead of changing the behaviour of "dnf".

Comment 3 Kyle Walker 2019-06-20 13:38:02 UTC
(In reply to Jaroslav Rohel from comment #2)
> > 3. Change the value with "yum config-manager"
> > # yum config-manager --save --setopt=example.enabled=0
> 
> According to documentation the right syntax is:
> yum config-manager --save --setopt=enabled=0 example
> 
> Fragments from manpage:
> dnf config-manager [options] <repoid>...
> <repoid> ...If not specified, display / modify main DNF configuration...
> 
> So, in your example you want to change "example" repo but list of repos
> "<repoid>..." was not specified. That means a list with one item "main" repo
> is used. So "example" repo is not contained in the list of repos for
> modifying and "--setopt=example.enabled=0" is dropped out. We can improve
> the "dnf" to wrote some warning message that the value was not saved and why.

Ahh, that mention slipped past me. Though, I have a few complaints with the "yum-config-manager" man page in general. It actually doesn't show "--setopt" as an option at all. It only mentions it in conjunction with "--save" and subsequently shows it as an example.

    https://github.com/rpm-software-management/dnf-plugins-core/blob/master/doc/config_manager.rst

I understand that this is supposed to be an inherited document from the "man {yum,dnf}" level, but that could be called out in the "man yum-config-manager" document. In addition, even that infers that you can include a repoid in the "--setopt" flag:

       --setopt=<option>=<value>
              override  a  config  option  from  the  config file. To override config options from repo files, use
              repoid.option for the <option>. Conf options like  excludepkgs,  includepkgs,  installonlypkgs,  and
              tsflags work as append option, therefore they are not overridden but the value is appended. If there
              is no value like --setopt=tsflags= it remove all values in append options.


Meanwhile, the content it replaces (from an up-to-date RHEL 7 installation) indicates:

man yum-config-manager:
<snip>
       --setopt=option=value
              Set  any  config  option  in  yum  config  or  repo  files. For options in the global config just use:
              --setopt=option=value for repo options use: --setopt=repoid.option=value.   The  latter  form  accepts
              wildcards  in  repoid that will be expanded to the selected sections.  If repoid contains no wildcard,
              it will automatically be selected; this is useful if you are addressing a disabled repo, in which case
              you don't have to additionally pass it as an argument.

       --save Save the current options (useful with --setopt).
<snip>

And testing the option shows that the "--setopt=repoid.option=value" syntax does indeed result in the desired behaviour:

    # yum repolist
    Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
    repo id                                              repo name                                                   status
    rhel-7-server-rpms/7Server/x86_64                    Red Hat Enterprise Linux 7 Server (RPMs)                    24,357
    repolist: 24,357                        

    # yum-config-manager --save --setopt=rhel-7-server-rpms.enabled=0
    Loaded plugins: langpacks, product-id, subscription-manager
    ======================================================== main =======================================================
    <snip>

    # yum repolist
    Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
    repolist: 0


> I think the old "yum" behaviour was similar to "dnf". But later (after "dnf"
> fork) there was done incompatible change in "yum" and "myrepo" was
> automatically added to "<repoid>..." list.
> (Probably https://bugzilla.redhat.com/show_bug.cgi?id=1403015 is the reason).
> 
> May be better is to add warning message with information instead of changing
> the behaviour of "dnf".

I would say that this change is a behaviour regression between the two releases, and that we need to work to preserve the previous behaviour. We have a large amount of documentation that shows the "--setopt=repoid.option=value" syntax. What is more, we have trained end users to rely on that behaviour.

To illustrate, the previous legacy yum repo connectivity failure message indicated the following:

    <snip>
    # yum update
    Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
    https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/optional/os/repodata/repomd.xml: [Errno 14] curl#35 - "Encountered end of file"
    <snip>
         5. Configure the failing repository to be skipped, if it is unavailable.
            Note that yum will try to contact the repo. when it runs most commands,
            so will have to try and fail each time (and thus. yum will be be much
            slower). If it is a very temporary problem though, this is often a nice
            compromise:

                yum-config-manager --save --setopt=rhel-7-server-optional-rpms.skip_if_unavailable=true
    <snip>


I see no reason why we can't simply add the "--setopt=<repoid>.<option>=<value>" compatibility layer so that we don't make users switch to the new command syntax arbitrarily. Especially when the fix can be as simple as:

    <snip>
        def modify_repo(self):
            """ process --set-enabled, --set-disabled and --setopt options """
    <snip>
            if self.opts.crepo:
                matched = []
                for name in self.opts.crepo:
                    matched.extend(self.base.repos.get_matching(name))
            else:
                matched = []
                for name in self.opts.repo_setopts.keys():
                    matched.extend(self.base.repos.get_matching(name))
                    if matched:
                        break
                else:
                    return

    <snip>

With the above:

    # yum repolist
    Updating Subscription Management repositories.
    Last metadata expiration check: 0:03:00 ago on Thu 20 Jun 2019 09:34:05 AM EDT.
    repo id                                    repo name                                                           status
    rhel-8-for-x86_64-appstream-rpms           Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)            5,336
    rhel-8-for-x86_64-baseos-rpms              Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)               2,022

    # yum config-manager --save --setopt=rhel-8-for-x86_64-appstream-rpms.enabled=0
    Updating Subscription Management repositories.

    # yum repolist
    Updating Subscription Management repositories.
    Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)                                3.4 kB/s | 4.0 kB     00:01
    repo id                                    repo name                                                           status
    rhel-8-for-x86_64-baseos-rpms              Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)               2,024

Comment 5 Jaroslav Rohel 2019-07-19 09:00:15 UTC
I tested "yum-config-manager --save --setopt=..." in Fedora 29, centos7/rhel7, and rhel8.

There are differences between each version.
I prepared PR. It will fix crash and modifies behavior of new DNF based "config-manager" to be more compatible with f29 and RHEL7.
PR https://github.com/rpm-software-management/dnf-plugins-core/pull/347


I had to done some compromise. But "yum config-manager --save --setopt=<repoid>.<option>=<value>" will be usable like in YUM3.

================================================================================================================
Test of yum-config-manager in Fedora 29, contos7/rhel7, and rhel8.
"main" - global configuration main section
"a", "b" ,"c" - repositories

------------------------------------------------------------------------------------------------------------------------
                             |            Modified config sections (repositories)
                             |------------------------------------------------------------------------------------------
       options               |  f29   | centos7/rhel7 | rhel8                                | rhel8 with PR
------------------------------------------------------------------------------------------------------------------------
--setopt=gpgcheck=0          |  main  | main          | main                                 | main
--setopt=gpgcheck=0 a b      |        |               | a b                                  |
--setopt=b.gpgcheck=0        |  b     | b             |                                      | b
--setopt=b.gpgcheck=0 a b    |  b     | b             | b                                    | b
--setopt=b.gpgcheck=0 \*     |  b     | b             | b                                    | b
--setopt=c.gpgcheck=0 a b    |        | c             |                                      | 
--setopt=*.gpgcheck=0 a b    |  a b   | a b           |                                      | a b
--setopt=*.gpgcheck=0 \*     |  a b c | a b c         |                                      | a b c
--setopt=gpgcheck=0 e        |        |               | Error: No matching repo to modify: e | Error: No matching repo to modify: e

Comment 6 Michal Domonkos 2019-07-22 11:43:58 UTC
Fixed upstream:
https://github.com/rpm-software-management/dnf-plugins-core/pull/347

Comment 11 Jaroslav Rohel 2019-08-28 09:06:55 UTC
The "--setopt" have a problem with repositories with dots. The problem is not related to config-manager plugin but it is a bug in DNF code (in setopt option parser).  It is not regression but long standing bug (which is detected in config-manager plugin now).
The option parser uses first dot as a delimiter. Repository id may contain dots. Option name can't contain dots. -> So, the last dot is delimiter and not the first one.

I created a bugzilla report for the bug https://bugzilla.redhat.com/show_bug.cgi?id=1746349 .

And I made a fix to upstream DNF https://github.com/rpm-software-management/dnf/pull/1466 .

Comment 15 errata-xmlrpc 2019-11-05 22:21:49 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/RHSA-2019:3583


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